MK
Вы же потом пришли к более менее вменяемому решению. В общем похожему, на то как оно есть.
Size: a a a
2021 February 10
DS
Это же было о идее смешать ноду и данные. Хранить указатель на что-то из них и пытаться кастом получить другое.
В интрузивном списке оно и так смешано. Речь была о том чтобы хранить в node_base указатели на node. И оно даже работает, но UB. Потому что для head cast указатель то даст, но формально он может выйти за пределы определения указателей вообще.
IZ
Подскажите что такое статическая линковка, пожалуйста
Без попадания в словарь внешних ссылок, inline в общем
DS
Это же было о идее смешать ноду и данные. Хранить указатель на что-то из них и пытаться кастом получить другое.
Ну и плюс зная что это UB может поплохеть компилятору.
DS
Это же было о идее смешать ноду и данные. Хранить указатель на что-то из них и пытаться кастом получить другое.
Да и смысла особо нет, разве что вместо абстрактных node_base иметь указатели на value_type сразу, для отладки проще. Но UB :)
MK
В интрузивном списке оно и так смешано. Речь была о том чтобы хранить в node_base указатели на node. И оно даже работает, но UB. Потому что для head cast указатель то даст, но формально он может выйти за пределы определения указателей вообще.
Оно во всех смешано. В интрузивном ноду создает пользователь списка, в не интрузивном ноду создает сам лист вот и вся разница. Вообще, компилятору все равно как называется то место, где хранятся указатели. В реализациях stl что мы видели это так, в других - может быть иначе. Сказать: «есть класс node, но он определен где-то дальше» всегда можно. Тем более что это же шаблон, реальные типы все равно появятся сильно позже.
MK
Да и смысла особо нет, разве что вместо абстрактных node_base иметь указатели на value_type сразу, для отладки проще. Но UB :)
Не так оно все работает...
MK
Да и смысла особо нет, разве что вместо абстрактных node_base иметь указатели на value_type сразу, для отладки проще. Но UB :)
Ну да ладно...
DS
Не так оно все работает...
Речь о том что можно например через CRTP делать класс элементом списка так:
struct X : list_member<X> {}. И получить автоматом внутри X *next, *prev. И потом уже использовать intrusive_list<X>. Но без UB оно можно только если sentinel будет nullptr.MK
Речь о том что можно например через CRTP делать класс элементом списка так:
struct X : list_member<X> {}. И получить автоматом внутри X *next, *prev. И потом уже использовать intrusive_list<X>. Но без UB оно можно только если sentinel будет nullptr.Кажется, понял о чем ты.
MK
Речь о том что можно например через CRTP делать класс элементом списка так:
struct X : list_member<X> {}. И получить автоматом внутри X *next, *prev. И потом уже использовать intrusive_list<X>. Но без UB оно можно только если sentinel будет nullptr.Скорее всего, ничего страшного на самом деле не случится, но надо смотреть реализации интрузивного списка и мембера.
MK
Речь о том что можно например через CRTP делать класс элементом списка так:
struct X : list_member<X> {}. И получить автоматом внутри X *next, *prev. И потом уже использовать intrusive_list<X>. Но без UB оно можно только если sentinel будет nullptr.Правда, и пользы от такой штуки тоже не особо много...
DS
Не так оно все работает...
UB потому что придется делать внутри
list_member<X> end_
X* end_node() { return static_cast<X*>(end_); }
list_member<X> end_
X* end_node() { return static_cast<X*>(end_); }
MK
UB потому что придется делать внутри
list_member<X> end_
X* end_node() { return static_cast<X*>(end_); }
list_member<X> end_
X* end_node() { return static_cast<X*>(end_); }
Просто подумай, как это выглядит в памяти - и все сразу станет понятно.
DS
Просто подумай, как это выглядит в памяти - и все сразу станет понятно.
Да мне и так понятно :) Если рассматривать просто как арифметику, downcast всего лишь вычитание какого то смещения, при обратном касте это же смещение обратно плюсуется. Но тут проблемы не с арифметикой, она то может и работает. Компилятор видит каст правильный с т.з. цепочки наследования типов, но неправильный с т.з. реально отсутствующего наследования. И может начудить.
S
/help@SupaproBot
Я просто помогаю с поддержанием порядка в С++ чатах!
MK
Да мне и так понятно :) Если рассматривать просто как арифметику, downcast всего лишь вычитание какого то смещения, при обратном касте это же смещение обратно плюсуется. Но тут проблемы не с арифметикой, она то может и работает. Компилятор видит каст правильный с т.з. цепочки наследования типов, но неправильный с т.з. реально отсутствующего наследования. И может начудить.
Надо пробовать :) с кастами точно все в порядке - если static_cast работает - значит все хорошо. А вот value в ноде настораживает... Штука, которая состоит из двух указателей на штуку которая состоит из двух указателей и экземпляра штуки которая состоит из двух указателей и экземпляра штуки ... Изящная и в общем безопасная концепция CRTP может тут превратиться в бесконечную рекурсию.
DS
Надо пробовать :) с кастами точно все в порядке - если static_cast работает - значит все хорошо. А вот value в ноде настораживает... Штука, которая состоит из двух указателей на штуку которая состоит из двух указателей и экземпляра штуки которая состоит из двух указателей и экземпляра штуки ... Изящная и в общем безопасная концепция CRTP может тут превратиться в бесконечную рекурсию.
Да не, с кастами то как раз не в порядке, уже дальше пробовать не надо :) Оно так у меня работало давно, а вот десятый gcc нашёл UB и начал странные очень warning'и генерить. Какие то выходы за границы массива по индексу -1 там где массивами даже не пахло. Как раз из за downcast к несуществующей базе.