Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Здравствуйте, ., Вы писали:

PD>Я бы понял, если бы, наоборот, в элементе была ссылка во внешний мир, и при уничтожении надо эту ссылку задействовать. Но в этой ситуации нет ничего особенного. В деструкторе надо уничтожить блок памяти, закрыть файл и послать сообщение по внешней ссылке...

Никогда слушателя сообщения в деструкторе не снимал?

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>В общем случае — да. Но это уже не список объектов, а некая иная структура. Более того, ситуация, когда извне списка имеются указатели на его ListElem — мягко говоря, не очень хорошая. Тут и без всяких пересылок до неприятностей один шаг. В этом случае надо вообще-то заводить некий новый класс, инкапсулирующий в себе и List, и эти Subscriber'ы. А это уже иная песня.

Зачем?
Вот представь себе, что есть список открытых файлов/документов и список вьюшек, и каждая вьшка подписана на один или несколько файлов, чтобы улавливать изменения в них. Как файлов у вьюшки не остаётся, она закрывается.
И куда и как ты это будешь инкапсулировать? И почему списки вьюшек и документов не могут быть просто списками, ничего не знающими про вьюшки и документы?

Здравствуйте, Erop, Вы писали:

E>Бинго! Вот он самый безопасный паттерн!

Только про паттерны не надо, пожалуйста.

>Кстати, про Вирта, как эта самая побитовая пересылка выглядит на паскале?

t1^ = t2^;

E>И, прости, а что происходит с оригиналом пересылки-то? Он разрушается или как? И кто зовёт деструктор того объекта, который затирают.

О господи! Еще раз — имеет место обмен.

PD>>Еще раз, внятно. FILE* file из текущего элемента обменивается с FILE* file из следующего элемента. Побитовый обмен. Никакие деструкторы тут не вызываются. После чего все идет как идет.

E>Про побитовый обмен -- это уже ново. До этого, у Вирта, например, речь шла о затирании одного другим вроде бы.

Тебе же очень нужно деструктор вызвать. Поэтому придется пойти на обмен. У Вирта только POD, так что достаточно переслать — удаление данных в ListElem у Вирта проблем не вызовет.

E>>>Правда копирование можно заменить на обмен. Но, к сожалению, даже менять можно не все объекты...
PD>>Пример, пожалуйста. Наследование не предлагать — все элементы списка имеют всегда один и тот же тип.
E>Почему это все элементы списка всегда имеют один и тот же тип? Скажем список контролов окна чем плох?

Тебе , видимо, надо азбучные истины объяснять.
Тип элемента списка ListElem. В него, конечно, может входить что угодно, но все элементы списка имеют один и тот же тип — ListElem. Список контролов окна сделать можно, если его поле данных — HWND, или HWND*, или CWnd* или даже CWnd, но тогда только CWnd, а не его наследники. Список из CWnd и CButton сделать нельзя.

E>Ну а пример простой очень. Объект, который где-то зарегистрирован вне списка.
E>Ну, например, буфер для асинхронного получения данных из трубы. У меня список таких буферов. В деструкторах они себя разрегистрируют, и коннекшен закрывают. Ваши действия, уважаемый?

Опять деструкторы! При той операции, о которой говорилось, никаких лишних вызовов деструкторов нет. Деструктор вызывается, когда уничтожается объект, а не когда он пересылается в другой элемент списка.

struct ListElem
{ 
  AnyType a;
  ListElem* next;
};

ListElem* t1 = указатель на некий элемент в списке
ListElem* t2 = указатель на некий иной элемент в списке

 swap(*t1, *t2 ;// побитовый обмен
 delete t1; // реально уничтожаем объект бывший t2

Где тут лишние деструкторы ?

Здравствуйте, Erop, Вы писали:


E>Никогда слушателя сообщения в деструкторе не снимал?

Слушай, ты хоть определись наконец, о чем ты говоришь. Я за твоим полетом мыслей уже не в силах угнаться. То у тебя из внешнего мира какие-то ссылки на элементы списка. Теперь слушатели появились. Они в элементе списка или во внешнем мире ? Если в элементе списка, то их снятие ничем не отличается логически от удаления char*. Если же во внешнем мире, то объясни бога ради, как деструктор их разыскивает.

On 19/08/10 18:28, Pavel Dvorkin wrote:

> Если же во внешнем мире, то объясни бога ради, как деструктор их разыскивает.
Я же всё показал. Даже код нарисовал.

Здравствуйте, Erop, Вы писали:

PD>>В общем случае — да. Но это уже не список объектов, а некая иная структура. Более того, ситуация, когда извне списка имеются указатели на его ListElem — мягко говоря, не очень хорошая. Тут и без всяких пересылок до неприятностей один шаг. В этом случае надо вообще-то заводить некий новый класс, инкапсулирующий в себе и List, и эти Subscriber'ы. А это уже иная песня.

E>Зачем?
E>Вот представь себе, что есть список открытых файлов/документов и список вьюшек, и каждая вьшка подписана на один или несколько файлов, чтобы улавливать изменения в них. Как файлов у вьюшки не остаётся, она закрывается.
E>И куда и как ты это будешь инкапсулировать? И почему списки вьюшек и документов не могут быть просто списками, ничего не знающими про вьюшки и документы?

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

On 19/08/10 18:24, Pavel Dvorkin wrote:
> Тебе , видимо, надо азбучные истины объяснять.
> Тип элемента списка ListElem. В него, конечно, может входить что угодно,
> но все элементы списка имеют один и тот же тип — ListElem.
Это так называемый intrusive container. Знаешь что такое non-intrusive containers?

> AnyType a;
Не AnyType, а AnyBitwiseSwapableType!!!

> swap(*t1, *t2 ;// побитовый обмен
Ты хочешь сказать, что абсолютно любые 2 объекта можно обменять побитово? Ты точно уверен?

Здравствуйте, ., Вы писали:

.>On 19/08/10 18:28, Pavel Dvorkin wrote:

>> Если же во внешнем мире, то объясни бога ради, как деструктор их разыскивает.
.>Я же всё показал. Даже код нарисовал.

У тебя же внутри класса Set из этих ссылок. Или я что-то не так понял ?

On 19/08/10 18:38, Pavel Dvorkin wrote:

>> > Если же во внешнем мире, то объясни бога ради, как деструктор их разыскивает.
> .>Я же всё показал. Даже код нарисовал.
> У тебя же внутри класса Set из этих ссылок. Или я что-то не так понял ?
Да. И что? В чём вопрос-то?

Здравствуйте, ., Вы писали:

>> swap(*t1, *t2 ;// побитовый обмен
.>Ты хочешь сказать, что абсолютно любые 2 объекта можно обменять побитово? Ты точно уверен?

Нет, конечно. Если внутри элемента есть указатели на его внутренние поля — конечно нет. И , разумееется, не должно быть внешних указателей, это мы уже обсуждали. Кажется, все, по крайней мере для 22:42 вечера (у меня уже голова пухнет от дискуссии с Егором . В остальных случаях я не вижу причин, почему по адресу P1 объект жить может, а по адресу P2 — нет. Может, есть что-то еще, сейчас что-то не соображу.

On 19/08/10 18:43, Pavel Dvorkin wrote:

> .>Ты хочешь сказать, что абсолютно любые 2 объекта можно обменять побитово? Ты точно уверен?
> Нет, конечно.
Вот и замечательно. А значит алгоритм меняющий связи в списке и алгоритм меняющий значения узлов в списке — разные алгоритмы, не эквивалентные. Нельзя просто так один заменить на другой.

Здравствуйте, ., Вы писали:

>> Тип элемента списка ListElem. В него, конечно, может входить что угодно,
>> но все элементы списка имеют один и тот же тип — ListElem.
.>Это так называемый intrusive container. Знаешь что такое non-intrusive containers?

А ты не путаешь ?

http://www.boost.org/doc/libs/1_38_0/doc/html/intrusive/intrusive_vs_nontrusive.html

The main difference between intrusive containers and non-intrusive containers is that in C++ non-intrusive containers store copies of values passed by the user

А я о другом

struct ListElem
{
  ListElem* pNext;
  AnyType data;
};

Все эти элементы в списке одного и того же типа — ListElem. Если можно иначе (кроме того что см. ниже) — объясни как.

Я про другое знаю — как в ядре ОС реализованы списки. Там, действительно, есть специальная структура с двумя указателями. к которой можно пришить любые данные. Строго говоря, совсем не обязательно, чтобы все ListElem были одного типа — достаточно, если из каждого ListElem можно добраться до следующего или предыдущего и определить объем данных. Но это уже не классический список.

struct ListElem
{
 ListElem* pPrev, * pNext;
 int ListElemSize;
 char data[1];

Выделение памяти делается под реальный объем данных, его записывают в ListElemSize.

Здравствуйте, ., Вы писали:

>> У тебя же внутри класса Set из этих ссылок. Или я что-то не так понял ?
.>Да. И что? В чём вопрос-то?

А у Егора вроде как предполагалось, что эти ссылки где-то во внешнем мире, а не в классе списка или его элементов. Вот и все.

Здравствуйте, ., Вы писали:

>> Нет, конечно.
.>Вот и замечательно. А значит алгоритм меняющий связи в списке и алгоритм меняющий значения узлов в списке — разные алгоритмы, не эквивалентные. Нельзя просто так один заменить на другой.

Да бога ради. Ничего против не имею. Но речь-то шла не об этой экзотике, а об обычной ситуации. То. что алгоритмы неэквивалентны — формально согласен, но из этого для случаев без этой экзотики ничего не следует. А это экзотика, и мне она малоинтересна.

.>>Ты хочешь сказать, что абсолютно любые 2 объекта можно обменять побитово? Ты точно уверен?

PD>Нет, конечно. Если внутри элемента есть указатели на его внутренние поля — конечно нет.

Кстати, по крайней мере в принципе эта ситуация легко разруливается. Если в ListElem есть поля, являющиеся указателями на что-то внутри ListElem, то эти указатели можно заменить на смещения относительно начала ListElem, после чего такие элементы можно свопировать.

Здравствуйте, Pavel Dvorkin, Вы писали:

>>Кстати, про Вирта, как эта самая побитовая пересылка выглядит на паскале?
PD>t1^ = t2^;

А почему это побитовая?
Например, где гарантии пересылки прокладок между полями записи?

PD>О господи! Еще раз — имеет место обмен.
IMHO, не обмен, а обман

PD>Тебе же очень нужно деструктор вызвать. Поэтому придется пойти на обмен. У Вирта только POD,
Вроде бы у него там на паскале всё было. Так что термин POD там нерелевантен...

PD>так что достаточно переслать — удаление данных в ListElem у Вирта проблем не вызовет.
В постановке Вирта такого рода требования на порядок разрушения элементов списка невозможны.
Но всё равно вызможны требования со стороны аллокатора...

E>>Почему это все элементы списка всегда имеют один и тот же тип? Скажем список контролов окна чем плох?

PD>Тебе , видимо, надо азбучные истины объяснять.
PD>Тип элемента списка ListElem. В него, конечно, может входить что угодно, но все элементы списка имеют один и тот же тип — ListElem. Список контролов окна сделать можно, если его поле данных — HWND, или HWND*, или CWnd* или даже CWnd, но тогда только CWnd, а не его наследники. Список из CWnd и CButton сделать нельзя.
Это почему это нельзя, когда все ими пользуются?

Правда изучи что такое интрузивный список. Не будешь таким смешным.

PD>Опять деструкторы! При той операции, о которой говорилось, никаких лишних вызовов деструкторов нет. Деструктор вызывается, когда уничтожается объект, а не когда он пересылается в другой элемент списка.

Ну как бы тебе пояснить, что НЕ ВСЕ ОБЪЕКТЫ МОЖНО ПЕРЕСЛАТЬ!!!

PD>Где тут лишние деструкторы ?
Тут хуже. Тут UB, так как побитовый обмен не POD данных

А потом некорректно отработают деструкторы.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Если же во внешнем мире, то объясни бога ради, как деструктор их разыскивает.

Так же как и всегда. Рассылает им уведомление

Вот представь себе, что мы пишем какой-то редактор-визуализатор каких-то сложных данных. Данные хранятся в файлах/документах. Ну, например, это редактор/смотрелка описаний гаджетов.

Когда мы открываем документ, мы создаём ему view. При этом у документа может быть много view. Все view должны узнавать о том, что документ изменился, чтобы эти изменения отобразить. Поэтому документ будет рассылать уведомления о изменениях в себе, а view, когда они будут подключаться к документу, будут подписываться на эти уведомления.
Когда документ закрывают/разрушают, он всем ещё не отписавшимся слушателям шлёт уведомление, что типа пора отписываться, и проверяет в конце, что все отписались.
При этом некоторые view могут отображать сразу несколько документов, например (то есть они могут, например, показывать результаты сравнения содержимого документов).

Ну вот, в этом приложении, например, документы могут лежать в списке.

Это всё довольно обычная архитектура, если честно. Мне странно, что для тебя это всё новость.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Ничего не понимаю. Они, стало быть, должны быть просто списками, ничего не знающими про вьюшки и документы, но при этом хранить внутри указатели на элементы иного списка ?

Вьюшки знают про документы. Документы про вьюшки, по крайней мере про какие-то интерфейсы к ним. А списки ни про что не знают. Они просто контейнеры, параметризованные типом элемента...

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Да бога ради. Ничего против не имею. Но речь-то шла не об этой экзотике, а об обычной ситуации. То. что алгоритмы неэквивалентны — формально согласен, но из этого для случаев без этой экзотики ничего не следует. А это экзотика, и мне она малоинтересна.

Эта "экзотика" присутствует в половине GUI...

On 19/08/10 22:45, Erop wrote:
> Это всё довольно обычная архитектура, если честно.
Можешь не стараться описывать. Он называет это всё малоинтересной экзотикой.