Плохой бот, который гмпотетически позволяет спаму висеть 30 сек

Или больше

Эмм

За что?

оффтоп

А, пон

аккуратнее с таким, я тоже не идеален

Имелось ввиду немного другое - приведение типа pValue = reinterpret_cast<Value*>(pNode) (и любые другие возможные варианты формирования списка когда Node и Value ни как не связаны а хранится указатель без информации о типе, с чего и началось обсуждение) не имеет смысла. В конце диалога к этому в общем и пришли.

Не, тип тут не нужен. Формально соответствие типу проверяется через it != end. И оно работает, но вот только UB ;)

Всегда есть отдельно сведения о структуре (указатель или ссылка на следующий элемент) и данные. Смешать их нельзя. Union - тип содержащий или структуру или данные работать не будет - нужно одновременно и то и то.

Единственный случай - когда структура и данные семантически одно и тоже или есть однозначное преобразование элемент структуры -> элемент данных.

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

А интрузивные и не интрузивные структуры данных отличаются только направлением композиции - в первом случае структура представлена полем в классе полезной нагрузки (и обычно такое создается программистом), во втором - полезная нагрузка поле в структуре (так устроены контейнеры в stl).

Это, если я правильно понимаю, связано с невозможностью расширить существующий класс иначе как определив потомка (нельзя просто взять и добавить поле в уже определенный класс).

Hi

Потому что есть разные списки. Есть голые списки как в лиспе, там структура представляет собой цепочку узлов, а есть полноценный список, там в интерфейсе узлов не видно вообще (так в с++).

Разница есть даже семантически. Например, в лиспе, не смотря на высокий уровень языка в общем, невозможно из функции вернуть список без присваивания снаружи функции. То есть если ты передашь список в функцию , и там список модифицируешь, без присваивания снаружи функции после возврата новую версию списка получить можно только ещё одним биндом.

В отличии от голого списка,  полноценный список можно передать в функцию по ссылке и модифицировать только в функции.

Я не знаю как это называется в ит-науке, не разу не видел таких исследований, что странно: спискам как структуре очень много лет, а различие очевидно

В общем вот как это получается - есть языки, где список объект первого класса (в том смысле, что в системе типов явно определено понятие списка), LISP (где вообще все, включая программу, - список), Haskell, и где нет (C++), строго говоря они делятся по представлению о списке - это либо контейнер либо монада. Монада разворачивается в цепочку соединений (head . tail) где tail может быть чем угодно, включая  еще одно такое соединение. Так вот - монады штуки не изменяемые - все что с ней можно сделать это создать на ее основе новую. C++ оперирует более низкоуровневыми понятиями (как и C) для нее список это цепочка из кусков памяти вида template <typename T> Node { T data; Node *next } для первого случая операции соединения и получения списка определены на уровне языка, для второго все отдано на откуп разработчиков библиотек.

С точки зрения информатики, наверное как-то так. Разница в общем очень тонкая и связана скорее всего только с «уровневостью» языка.

Точнее даже не так (cons A (cons B (cons C, nil)))

то есть tail это или еще соединение или конец списка