очень интересное поведение

у меня класс-менеджер устройства. я хочу по деструктору отправить ему "досвидос" через Modbus, который в свою очередь юзает COM-порт вот тред завершается, деструктор наступает, а Modbus-объекта уже и нету((((

у меня класс-менеджер устройства. я хочу по деструктору отправить ему "досвидос" через Modbus, который в свою очередь юзает COM-порт вот тред завершается, деструктор наступает, а Modbus-объекта уже и нету((((

круто! но с D как тебе здесь помогут?

Типа в D не завезли raii?

Интересно чем руководствовался александреску когда уходил в него

видать, ему хотелось нормального метапрограммирования

Ну там Саттер чтото мутит лучшеб ему помог

ну в D уже завезли, а в крестах всё нет да нет....

Кстати куда pro.dlang пропал

гц собрал

на самом деле я был бы не против GC в крестах. но я видел пока что только один проект более-менее на эту тему (и да - он мёртв)

блин, но что-то в такие косяки слабо верится в D

такое поведение GC противоречит его принципу работы

на самом деле я был бы не против GC в крестах. но я видел пока что только один проект более-менее на эту тему (и да - он мёртв)

есть же boehmgc

я даже с ним игрался

есть же boehmgc

так он как раз таки и мёртв вроде

неа

в моно юзают его

в самом gcc

не-не, юзают и жив - разные вещи. а можно ссылку на актуальное состояние?

я с гитхаба качал

так и зовется репозиторий

с чего взял что умер? \

это просто старый проект там типо все давно работает

хз есть ли баги

но у меня все работало четко

я хотел на нем замутить самописный скриптовый движок

но потом забил

хм, вижу... странно. тогда почему думал, что он помер?... моя ошибка, извиняюсь

и спасибо за инфу

он и деструкторы умеет сам звать и там циклические ссылки собирать, правда там надо его пнуть для этого, из коробки не собирает

GC_register_finalizer_no_order зарегать надо. вспомнил

тогда все собирает

но вообще при наличии деструкторов как собирать циклические ссылки? вот если например А и Б друг на друга ссылаются, вызвал деструктор А, а на него обьект Б ссылался?

че делать с полем?

слабо себе представляю как можно променять строго детерминированный цикл жизни объекта в C++ на непредсказуемый.

вдруг в деструкторе образаются к полю, а там обьект уже протух

слабо себе представляю как можно променять строго детерминированный цикл жизни объекта в C++ на непредсказуемый.

Ну с шрд птрами же делаете такое

почему тогда не жавка?

поэтому по умолчанию в боеме отключена сборка циклических ссылок

почему тогда не жавка?

Потомучто у нее так себе экосистема

Ну с шрд птрами же делаете такое

момент смерти объекта строго детерминирован, тем не менее

Строго детерминирован данными сгенериреными в процессе работы?

Чот такое себе

Строго детерминирован данными сгенериреными в процессе работы?

условием вызова деструктора

Не, именно данными(счётчиком)

вообще мне кажется в джаве гц впилили больше по причине того что компилятор писать проще. я когда сам пробовал компилер писать ощутил на своей шкуре. прикиньте привыходе из скоупа любом надо генерить код вызова деструкторов. а в ЯП с гц не надо, само потом удалится. профит? с другой стороны для обьектов которые всегда на стеке надо городить гц с поколениями. вместо того чтобы просто позвать деструкторы когда управление вышло из скоупа

а выходы из скоупа бывают нетривиальные. толи континуе в цикле или брек, толи в свитче, толи исключение. и все надо обработать

а еще есть область видимости в заголовке цикла фор

ERROR: S client not available

понимаю разрабов, прошще плюнуть и впилить гц

как gcc писали я хз марсиане какието

Не, именно данными(счётчиком)

Окей ладно я могу сказать что ещё определено где он есть но не определено где его нет

Предложения о работе в отдельный канал через постель с @AlexFails

Интересная статья https://akrzemi1.wordpress.com/2018/05/16/rvalues-redefined/. "In this post we will explore what I consider the most significant language change in C++17" - это автор про guaranteed copy elision, который позволяет возвращать объекты классов без copy/move конструкторов из функций. Нет move конструктора -> нет moved from состояния -> логика в классе упрощается.

В узлах деки в деках строки в строках утка, в утке яйцо, в яйце игла, а на конце иглы смерть кощеева

Мехмат?)

не знаю было ли тут уже

C++ Insights is a new Clang-based tool by Andreas Fertig which tries to reveal the sort of "magic" the compiler does behind the scenes, e.g. compiler provided functions or automatic downcasts. It does this via a source-to-source transformation. Be sure to check out the online demo. https://github.com/andreasfertig/cppinsights https://cppinsights.io/

Господа, вот в языке C есть такой паттерн стрельбы в ногу. (Встречается например в ядре Linux). Есть такая структура, внутри которой размещается другая структура: struct base { // ... struct nest m; // ... }; И есть указатель типа struct nest*. Тогда, предварительно помолясь и считая, что мы имеем дело со стркутурой хранимой внутри другой структуры, вычиаем смещение offsetof(struct base, m) и преобразуем к указателю struct base*. Получаем доступ ко всем членам struct base. А вопрос в следующем. Можно ли сказать, что с точки зрения конечного кода при доступе к элементам есть некоторые параллели с множественным наследованием?

Вопрос носит сугубо академический характер

boost intrusive, там что то вроде этого, member hook

Альтернатива ему base_hook

Наследование вроде не множественное...

Хотя если включить в насколько контейнеров, как раз оно. Либо разные member hooks либо разные через тегирование base hooks.

Вот не могу понять, есть ли теоретическая возможность совсем исключить этот C-шный паттерн. Т.е. сказать, во всех возможных случаях в C++ это однозначно делается так-то и так-то.

это же не множественное наследование

это просто наследование

и static_cast

Вопрос носит сугубо академический характер

Считаю что нет, множественное наследование - это все же некоторая программная абстракция. В данном случае тебе нужно будет все равно явно учитывать смещение

Konstantin а в чём причина такого странного рецепта к Wt в бинкрафтерах?

Считаю что нет, множественное наследование - это все же некоторая программная абстракция. В данном случае тебе нужно будет все равно явно учитывать смещение

Да, компиляторы емнип даже по разному относятся к empty base при множеством наследовании. Могут схлопнуть а могут и нет.

Да, компиляторы емнип даже по разному относятся к empty base при множеством наследовании. Могут схлопнуть а могут и нет.

Обязаны схлопнуть

Одну точно, а вот две помнится msvc не схлапывал.