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

PD>Можно и так. Только делать это придется каждый раз, иначе ты после последнего удалишь второй, а не первый.

Ну и что?

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

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

PE>>>Это удаление следующего элемента + копирование его данных в текущий. Являются ли эти действия эквивалентными -- вопрос спорный. Я, например, так не считаю

PD>>Доказательства в студию.

E>Доказательства чего?

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

PD>>Можно и так. Только делать это придется каждый раз, иначе ты после последнего удалишь второй, а не первый.

E>Ну и что?

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

Век живи — век учись

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

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

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

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

PD>Век живи — век учись
Полезный совет

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

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

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

PE>>>>Это удаление следующего элемента + копирование его данных в текущий. Являются ли эти действия эквивалентными -- вопрос спорный. Я, например, так не считаю
PD>>>Доказательства в студию.

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

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

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

E>Например, представь себе, что аллокатору, на котором выделены элементы не всё равно в каком порядке их освобождают, или, например, что данные вообще нельзя скопировать. Например, что это открытые файлы

Ай-яй -яй. А на открытые файлы есть, между прочим, дескрипторы, которые вполне можно копировать. Файл при этом копировать совсем не надо.

struct ListElement 
{
  FILE* file;
  ListElement* next;
};

И что за проблемы тут возникнут при удалении списка ? Хоть с закрытием файлов, хоть без.

E>Кроме того, я ещё всё же думаю, что ты в целом некорректно интерпретируешь условие задачи

Разумеется. Я об этом с самого начала сказал


PD>>Век живи — век учись
E>Полезный совет

Вот и прими его во внимание, и пиши, сначала подумав.

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

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

E>Смешно то, как ты позорно изворачиваешься, не желая признать того, что закольцовывать список в этой задаче никогда не надо.
E>Брякнул глупость и никак не признаешь этого очевидного факта

Скорее уж именно ты тут изворачиваешься. Поставил смайлик Вирту , а теперь не знаешь, как из этой ситуации выйти. Вполне достаточно того, что ты в этой подветке пытаешься перевести разговор на меня, хотя я задал тебе четкий вопрос — что тебя заставило улыбнуться в тексте из Вирта. Это и называется изворачиваться.

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

E>Во-вторых, могут быть какие-то ссылки на элементы списка снаружи. И деструкторы элементов могут их откуда-то вымарывать, где-то что-то логгироватьи т. д.

Если же есть ссылки на элементы списка снаружи, то интересно было бы знать, куда они будут показывать после уничтожения списка любым способом ? . Зарапортовались, батенька.

On 19/08/10 12:31, Pavel Dvorkin wrote:

> Если же есть ссылки на элементы списка снаружи, то интересно было бы
> знать, куда они будут показывать после уничтожения списка *любым
> способом* ? . Зарапортовались, батенька.
Так он и пишет, что деструктор элемента может что-то делать с этими ссылками, например, посылать сообщение: "я удаляюсь, забудьте про меня".

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

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

.>Так он и пишет, что деструктор элемента может что-то делать с этими ссылками, например, посылать сообщение: "я удаляюсь, забудьте про меня".

Пишет он нечто иное

E>Во-вторых, могут быть какие-то ссылки на элементы списка снаружи

То есть снаружи есть ссылки на уничтожаемые элементы. И деструктор зачем-то разыскивает эти ссылки где-то снаружи, чтобы по ним добраться к элементу, который он сейчас уничтожает и послать ему сообщение ?

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

On 19/08/10 14:30, Pavel Dvorkin wrote:

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

Вот на псеводязыке:

class ElemSubscriber
{
   virtual void onDoSomethingElse(Elem *e);
   virtual void onDestroy(Elem *e);
}

class ListElem()
{
   private Set<ElemSubscriber> subscribers;
   void subscribe(ElemSubscriber *s)
   {
     subscribers.add(s);
   }
   ~ListElem()
   {
     for(s in subscribers) {s->onDestroy(this);}
   }
}

Что делают подписчики — неизвестно. Вероятно могут хранить ссылку на ListElem.

Так что не всегда можно тупо переместить объект в памяти и сказать, мол, шо так и былО.

Во всяких Явах такое можно, этим даже GC любит заниматься, но там указателей нет, а ссылки, управляемые GC...

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

.>Вот на псеводязыке:

Хм...

.>[c]
.>class ElemSubscriber
.>{
.> virtual void onDoSomethingElse(Elem *e);
.> virtual void onDestroy(Elem *e);
.>}

Кто такой Elem ? Судя по вызову s->onDestroy(this); тут должен быть не Elem,а ListElem , так ? А если так — зачем хранить ссылку на ListElem, если она передается в эти методы ? Но это так, к слову.

.>Что делают подписчики — неизвестно. Вероятно могут хранить ссылку на ListElem.

Вообще-то могут, верно.

.>Так что не всегда можно тупо переместить объект в памяти и сказать, мол, шо так и былО.

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

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

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

Я тебе чётко ответил что -- невтемность этого текста в обсуждаемой теме

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

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

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

E>Я тебе чётко ответил что -- невтемность этого текста в обсуждаемой теме

Ну да, конечно. Что же можно еще сказать

Ладно, я думаю, хватит.

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

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

E>>Во-вторых, могут быть какие-то ссылки на элементы списка снаружи. И деструкторы элементов могут их откуда-то вымарывать, где-то что-то логгироватьи т. д.

PD>Если же есть ссылки на элементы списка снаружи, то интересно было бы знать, куда они будут показывать после уничтожения списка любым способом ? . Зарапортовались, батенька.

Например, деструкторы могут сниматьобъекты с регистрации. При этом порядок съема с регистрации может быть важен

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

Но это всего лишь обсужденеи того, как интерпретировать условие. Можно и так и так, но как не интерпретируй, всё равно закольцовывать список нет никакой нужды.

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


PD>Ай-яй -яй. А на открытые файлы есть, между прочим, дескрипторы, которые вполне можно копировать. Файл при этом копировать совсем не надо.

Ай-ай говоришь? А если это не FILE*, а CFile, например?
Ты воообще можешь представить себе некопируемый объект какой-нибудь? Или у тебя таки все объекты имеют семантику значения?


PD>

PD>struct ListElement 
PD>{
PD>  FILE* file;
PD>  ListElement* next;
PD>};
PD>

PD>И что за проблемы тут возникнут при удалении списка ? Хоть с закрытием файлов, хоть без.
Ну как же. Пусть деструктор узла закрывает файл. При применении схемы с копированием некоторые будут закрыты дважды, а некоторые ни разу. Можно, конечно, при присваивании, предыдущий закрывать, но тогда всё равно некоторые файлы будут закрыты по нескольку раз...
Правда копирование можно заменить на обмен. Но, к сожалению, даже менять можно не все объекты...


PD>Вот и прими его во внимание, и пиши, сначала подумав.
И ты тоже %)~

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

E>Ай-ай говоришь? А если это не FILE*, а CFile, например?

Там нет копирования при Виртовской операции. Там побитовая пересылка.

E>Ты воообще можешь представить себе некопируемый объект какой-нибудь? Или у тебя таки все объекты имеют семантику значения?

PD>>

PD>>struct ListElement 
PD>>{
PD>>  FILE* file;
PD>>  ListElement* next;
PD>>};
PD>>

PD>>И что за проблемы тут возникнут при удалении списка ? Хоть с закрытием файлов, хоть без.
E>Ну как же. Пусть деструктор узла закрывает файл. При применении схемы с копированием некоторые будут закрыты дважды, а некоторые ни разу.

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

E>Правда копирование можно заменить на обмен. Но, к сожалению, даже менять можно не все объекты...

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

On 19/08/10 15:48, Pavel Dvorkin wrote:

> Кто такой Elem ? Судя по вызову s->onDestroy(this); тут должен быть не
> Elem,а ListElem , так ?
Верно, просто опечатка.

>если так — зачем хранить ссылку на ListElem,
> если она передается в эти методы ? Но это так, к слову.
Для удобства. Во многих случаях позволяет создавать один экземпляр ElemSubsriber:

class MyClass
{
   private Set<ListElem *> myElems;
   public void doIt(ListElem *e)
   {
     if(something(e)) { myElemes.add(e); e->subscribe(subscriber); }
   }
   private ElemSubscriber subscriber = new ElemSubscriber()
   {
     void onDestroy(Elem *e) { myElems.remove(e); }
   }
}

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

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

PD>Там нет копирования при Виртовской операции. Там побитовая пересылка.
Бинго! Вот он самый безопасный паттерн! Кстати, про Вирта, как эта самая побитовая пересылка выглядит на паскале?
И, прости, а что происходит с оригиналом пересылки-то? Он разрушается или как? И кто зовёт деструктор того объекта, который затирают.

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

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

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

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