M>>А без C++ можно определение дать? А то получается, детерминированное осовобождение — чисто внутренне понятие C++.

WF>Детерминированное == определенное. Т.е когда точно известен момент (и им можно управлять), например, смерти объекта.

Определённое? Кем определённое?

В .NET объекты освобождаются тоже строго в определённый срок. Этот срок определяет GC.

Конечно, ты скажешь, что определять время освобождения должен программист. Но тогда встаёт вопрос, какой программист? Если один компонент использует другой, то на ком должна лежать ответственность за освобождение?

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

Циклические ссылки внутри одной библиотеки можно (со скрипом) разешить. Но как быть с циклическими ссылками между компонентами разных библиотек? Кто тут будет определять время жизни?

WF>Кстати, потенциальные циклические графы можно ведь и автоматически искать. Например есть модель в Розе ("умный" указатель — ассоциация с неким стереотипом, например, "shared ptr"). А потом просто все циклы таких ассоциаций искать. На бейсике наверняка довольно быстро ищется.

А междубиблиотечные циклы?

WF>По аналогии. Если важный сервер в банке будет падать "не так уж часто" (от нехватки памяти), ребята будут очень недовольны.

Ну тут не .NET виноват, а программисты. Нечего делегаты использовать не по назначению.

M>>Проблема автоматического вызова деструкторов — та же архитектурная проблема циклических ссылок.

WF>Проблема в том, что когда я подписываю на событие (например, в конструкторе, да еще и на статическое событие) — это часть логики. Если я забуду подписаться, это, скорее всего, легко обнаружится. А вот отписывание — уже не часть логики, я могу с легкостью забыть отписаться и получу утечку. Вот почему "умные" указатели существенно облегчают работу — нужно лишь захватить ресурс, а освободится он сам, причем управляемо.

Как тенденция это хорошо. Но дело-то происходит на реальной земле. А тут автоматически не всё можно сделать.

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

WF>>Детерминированное == определенное. Т.е когда точно известен момент (и им можно управлять), например, смерти объекта.

M>Определённое? Кем определённое?

Семантикой умных указателей, например. Т.е известно, последовательность каких действий с интерфейсом умного указателя приводит к смерти объекта. Или областью видимости, если это переменная на стеке.

M>В .NET объекты освобождаются тоже строго в определённый срок. Этот срок определяет GC.

Нет. Неизвестно точно, какие действия с интерфейсом GC в конечном итоге приведут к смерти данного объекта.

Пояснение: Интерфейс GC — это выделение объекта. Вызов GC.Collect() по очевидным причинам не рассматриваем в данной ситуации. Он, конечно, дает некоторую определенность, но слишком большой ценой .

M>Конечно, ты скажешь, что определять время освобождения должен программист. Но тогда встаёт вопрос, какой программист? Если один компонент использует другой, то на ком должна лежать ответственность за освобождение?

M>С одной стороны, это дело автора компонента, с другой — только пользователь компонента знает, когда он уже перестал его использовать.

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

M>Циклические ссылки внутри одной библиотеки можно (со скрипом) разешить. Но как быть с циклическими ссылками между компонентами разных библиотек? Кто тут будет определять время жизни?

Тут, конечно, сложнее. Надо подумать. Хотя действительно, в этой ситуации стоимость решения существенно возрастает.

WF>>По аналогии. Если важный сервер в банке будет падать "не так уж часто" (от нехватки памяти), ребята будут очень недовольны.

M>Ну тут не .NET виноват, а программисты. Нечего делегаты использовать не по назначению.

.NET не может быть виноватым. И C++ тоже. Виноват всегда программист. Стоит лишь вопрос цены. Правда, тут .NET наверняка выигрывает (если не стоит вопрос производительности). Хм, надо тогда подумать, в чем все же может быть преимущество C++

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

M>Как тенденция это хорошо. Но дело-то происходит на реальной земле. А тут автоматически не всё можно сделать.

Ну и что. Это ведь не повод отказываться от автоматизации вообще.

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

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

WF>>>Детерминированное == определенное. Т.е когда точно известен момент (и им можно управлять), например, смерти объекта.

M>>Определённое? Кем определённое?

WF>Семантикой умных указателей, например. Т.е известно, последовательность каких действий с интерфейсом умного указателя приводит к смерти объекта. Или областью видимости, если это переменная на стеке.

Время на ослеживание. С таким же успехом, можно выделять память и в куче а и передвигать указатель конца использумой памяти. А дефрагментация памяти. Оссобенно при реаллоках когда памяти куча и Оут Оф Память. И в общем зачем тратить ресурсы если эта память не нужна. Другое дело системные ресурсы. Но об этом должен заботится программист ди не так их уж и много. Да и отслеживание мертвых объектов может происходить в момент простоя. Для многопроцессорных серверов вообще не проблема. Я думаю они провели немало времени за тестами и GC еще молод и будет развиваться. Идея правильная!!!!

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

WF>Проблема в том, что когда я подписываю на событие (например, в конструкторе, да еще и на статическое событие) — это часть логики. Если я забуду подписаться, это, скорее всего, легко обнаружится. А вот отписывание — уже не часть логики, я могу с легкостью забыть отписаться и получу утечку. Вот почему "умные" указатели существенно облегчают работу — нужно лишь захватить ресурс, а освободится он сам, причем управляемо.

Расслабляют они умные мозги, заставляют их думать, что кто-то за них всё сделает, да ещё и как надо.

Странная какая-то проблема. Я вот о чём подумал — что проблема эта связана с определённымим стереотипами, накладываемыми основным (часто используемым) языком программирования. Вот Сишники привыкли, что освобождение ресурсов за них делает компилятор и всякие сборщики, переменные по коду объявляют, где хотят, опять же чувствительность к регистру. Те же, кто OP использует привыкли в конструкторах захватывать, а в деструкторах освобождать. Ну или там захватывать, когда понадобилось, но освобождать всегда ручками в деструкторах.

Т.е. в голове крутится — если подписался на событие, значит надо и отписаться. Как-то переложить это на (какой-то там) компилятор и в голову не приходит...

За это мне этот C# Коллектор так не нравится . Чё хочет делает, не управляемый в пень какой-то.

Вот ещё вспомнил, раньше, во времена DOS, в Борланд Паскале была такая возможность запомнить процедурой Mark (по моему) текущий указатель кучи, потом дико распределять её как угодно, до дыр, что называется. А потом одним махом по заверщении действий приказать всё освободить вызовом Release (кажется). Так было удобно, не надо тебе о дырах и щелях в памяти заботиться, и памятью можно было управлять явно. А это всёже какой-никакой элемент оптимизации работы программы.

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

Вопрос про свойства несколько сложнее, чем просто "удобные псевдонимы для get... и set...".
При таком отношении теряется семантика. Свойства вообще противоречат концепции поведенческой объектной модели. В этой модели объект обладает некоторым поведением, при этом его повадки определяются его интерфейсом. Все "внутреннее наполнение" объекта служит только для того, чтобы поведение, задаваемое интерфейсом, имело контекст. (В таком подходе публикация полей является членовредительством, т.к. мы даем тем самым возможность управлять состоянием объекта, минуя его интерфейс.) Судить о состоянии объекта можно только косвенным образом, сравнивая его реакцию на одно и то же сообщение в разные моменты времени.

Однако в некоторых случаях хочется все же иметь некий доступ к состоянию объекта, пусть даже и контролируемый. Как раз эту задачу и решают свойства. С точки зрения внешнего наблюдателя, свойство — это некоторый атрибут состояния. Он отличается от поля тем, что его можно безопасно менять (здесь безопасность подразумевает гарантию того, что результатом воздействия станет целостное состояние). Таким образом, свойство можно рассматривать как некую специфическую "надстройку" над поведением объекта — мы придаем специальную семантику некоторым сообщениям из его интерфейса.
Это накладывает определенные обязанности на реализацию свойства. В частности, как правило ожидается сохранность значения свойства: если мы записали что-то в некоторое свойство, и сразу же (т.е. до посылки еще каких-либо сообщений этому объекту (или вообще любым объектам в системе)) читаем из него, то мы должны получить записанное значение (или близкое к нему).
С этой точки зрения, плохой идеей является обьъявление свойств вот таким образом:

type TPerversiveObject = class
private
  FA, FB: integer;
public
  property A: integer write FA read FB;
    property B: integer write FB read FA;
end;

А вот такой пример является "хорошим":

type TPoint = class
private
  FX, FY: extended;
public
  property X: extended read FX write FX;
    property Y: extended read FY write FY;
    property R: extended read GetR write SetR; // имеется в виду R = sqrt(x*x+y*y)
    property Alpha: extended read GetAlpha write SetAlpha // полярный угол

Дальнейшее развитие этой идеи приводит к введению базиса — набора свойств, значения которых однозначно определяют состояние объекта. (очевидно, что не для всех объектов это возможно).
На этом построена VCL: базисом считаются те свойства, которые расположены в секции published.

Если быть более точным, то Delphi предоставляет возможность динамически определять базис при помощи ключевого слова stored. Кроме того, поверх базовых возможностей языка реализован механизм "псевдосвойств", но они определяются исключительно процедурным способом, в отличие от декларативных published/stored.

Это совершенно другой подход к управлению состоянием объекта, нежели принятая в чисто-поведенческих системах концепция сохраняемости. Там объект наделяется при необходимости специальным поведением "сохранить/восстановить свое состояние", что позволяет ему самостоятельно заначивать и доставать свое состояние, не давая посторонним доступа к нему.

Такая реализация кажется, с теоретической (да иногда и с практической) точки зрения, несколько громоздкой. В конце концов борланд пришлось написать свой собственный уникальный компилятор, иначе программисты убились бы следовать этому тернистому пути. (желающие убедиться могут сравнить TurboVision с VCL).
Зато она дает более гранулярный доступ к состоянию объекта. Вместо конверсии состояния в монолитный битовый поток, мы получаем поименный самодокументированный набор примитивных значений. Это позволяет нам отделить логику конструирования состояния объекта от его "собственного" поведения, и иметь ту самую RADость, которой так не хватало все эти годы программистам на MS VC.

Однако нужно отдавать себе отчет в том, что целостность системы иногда важнее полировки отдельных фич. И бездумное внесение синтаксических возможностей в некоторую среду может привести к плохо управляемым последствиям. Не стоит валить все вкусности из холодильника в одну кастрюлю — вряд ли мороженое с картофельным пюре, вареньем и горчицей порадует ваших гостей. С++Builder в свое время меня просто потряс неожиданностью трактовок выражения X.y[i]=X.y[i]+someconst. Учитывая то, что y — индексированное свойство, для типа которого нетривиальным образом перегружены операторы присваивания и сложения .

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

S> Применение Маккросов и Шаблонов наложили отпечаток и на сам язык, так перегрузки операций и функций прекрасно вписываются в Шаблонную систему и неявное приведение типов, но их переизбыток иногда ведет к непониманию кода, особенно когда перегруженная функция имеет совсем другой смысл, но написание ее будет темже. Перегрузка операторов для элементарных типов тоже может вести к неправильному восприятию (например сложение указателей и неявное приведение к LongWord).
Супер аргумент этим же мотивировали отсутствие перегрузки операторов в жабе.
S> Отсутствие шаблонов в Delphi, заставляет мыслить Виртуально, а не Шаблонно.
Ага типа я в С++ не могу мыслить виртуально. Вся разница в том что в С++ у меня есть выбор и очень часто шаблон оказывается оптимальным решением, но иногда и виртуальность нужна.
S> Вернемся к сортировке. Для элементарных типов шаблоны впереди планеты всей, но со сложными структурами, когда нужно сортировать по любому сочетанию полей и во время выполнения программы шаблоны бессмыслены, если вспомнить комбинаторику и посчитать все сочетания.
S> Решение выглядит приблизительно так.
хъ
Какой кошмар
В С++ существует такое понятие "функтор" это объект который ведет себя как функция.

struct some
{
//...
};
struct some_dynamic_cmp
{
    bool operator()(const some& lhs, const some& rhs)
    {
    //Тут сравниваем
    }
};
void main()
{
    std::vector<some> some_vec;
    //Заполняем
    some_dynamic_cmp cmp;
    //Устанавлеваем правила сравнения
    std::sort(some_vec.begin(), some_vec.end(), cmp);
}

Все.
S> И в отличие от шаблонов, скорость падает, но я имею универсальность, а при выборе оптимальных алгоритмов в прктических диапозонах вычислений ловит тысячные секунды не имеет смысла. Все зависит от задачи.

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

M>Именно. Всё должно быть как можно проще.
Вот именно все должно быть проще. Вот скажи мне какого черта я должен прописать создание десятка объектов (конструктор по умолчению которых мне прекрасно подходит) в конструкторе и удаление всех в деструкторе если я могу их лишь одан раз описать?

M>Именно, что слабо. Никому не нужная экзотика.
Ну ладно не int а класс написаный неизвесно кем не извесно когда и менять его ты не можешь. Ы?

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

M>Прекрасно понял. Когда ты говоришь "всё остальное", это означает "узкий круг задач, которыми я сейчас занимаюсь"
Узкий круг задачь это тонны ГУИ к БД который надо быстро нарисовать. А С++ решает очень широкий круг задач от СОМ серверов до игр. Можно и на дельфе я не спорю но какой ценой.

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

A>Вот это, кстати, в точку. Этим, кстати, многое определяется в высказываниях.

Ты что, предлагаешь и в браузерах скрипты на C++ писать? Или ты какое-то конкретное "остальное" имеешь ввиду?

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

M>Хе-хе. Мелочь, а приятно.
Ну и нахрена нужны отмазки в место инструментов?

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

WF>>А насчет синтаксиса — тоже не очень навороченно, описание поля, да в конструкторе свойству адрес внешнего класса дать. И все. В C++ бывают ситуации с гораздо более тяжелым синтаксисом. Так что они не сильно-то и нужны.

M>Вот он, булыжник в огород сишников!
Ага ты посмотри посты Serginio1 где он пытается реализовать элементарные вещи.

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

WF>Да нет, в использовании вне класса — как в C#. В использовани в классе — тоже ничего сложного. Просто не так логично, как в C#, не get/set, а два метода, переменная и в конструкторе немного буковок.
Либо не парится и использовать расширения ибо всеравно большинство программ не будут портироваться.

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

M>Ну, в Дельфи тоже можно много чего эмулировать. Те же шаблоны можно эмулировать.
Это как? Уж не про ту ли ты фиговину с королевства?

M>Ага. А в начале прошлого века говорили: не дело это, домохозяек за руль пускать. Но когда машины стали удобны, надёжны и просты в управлении, домохозяйки сели за руль.
А ты сядешь за автомобиль собранный домохозяйкой?

M>С языками/компьютерами/программированием будет точно то же самое.
А ну-ну.

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

A>Расслабляют они умные мозги, заставляют их думать, что кто-то за них всё сделает, да ещё и как надо.
Вот именно нахрена делать то что очень хорошо может сделать компилятор.

A>Странная какая-то проблема. Я вот о чём подумал — что проблема эта связана с определённымим стереотипами, накладываемыми основным (часто используемым) языком программирования. Вот Сишники привыкли, что освобождение ресурсов за них делает компилятор и всякие сборщики, переменные по коду объявляют, где хотят, опять же чувствительность к регистру. Те же, кто OP использует привыкли в конструкторах захватывать, а в деструкторах освобождать. Ну или там захватывать, когда понадобилось, но освобождать всегда ручками в деструкторах.
Вот скажи мне зачем отпускать ресурс ручками? Ведь логика работы с ресурсом обычно весьма громоздка дык зачем захламлять код? Зачем думать об исключениях?

A>Т.е. в голове крутится — если подписался на событие, значит надо и отписаться. Как-то переложить это на (какой-то там) компилятор и в голову не приходит...
Вот именно потомушто нельзя по нормальному это сделать, а вот еслибы было мохно то я уверен что ты бы этим пользовался.

A>За это мне этот C# Коллектор так не нравится . Чё хочет делает, не управляемый в пень какой-то.
Мне тоже очень не нравится, а вот смартпоинтеры это совсем другое дело. Всегда знаешь кого и главное когда они пристрелят.

A>Вот ещё вспомнил, раньше, во времена DOS, в Борланд Паскале была такая возможность запомнить процедурой Mark (по моему) текущий указатель кучи, потом дико распределять её как угодно, до дыр, что называется. А потом одним махом по заверщении действий приказать всё освободить вызовом Release (кажется). Так было удобно, не надо тебе о дырах и щелях в памяти заботиться, и памятью можно было управлять явно. А это всёже какой-никакой элемент оптимизации работы программы.
Какой ужас.

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

S> Время на ослеживание. С таким же успехом, можно выделять память и в куче а и передвигать указатель конца использумой памяти. А дефрагментация памяти. Оссобенно при реаллоках когда памяти куча и Оут Оф Память. И в общем зачем тратить ресурсы если эта память не нужна. Другое дело системные ресурсы. Но об этом должен заботится программист ди не так их уж и много. Да и отслеживание мертвых объектов может происходить в момент простоя. Для многопроцессорных серверов вообще не проблема. Я думаю они провели немало времени за тестами и GC еще молод и будет развиваться. Идея правильная!!!!
У мнея такое ощущение что кто-то чего-то сильно не понимает.
Допустим у нас есть некий объект который держит ресурс. Этот объект использовало куча других и через некоторое время он перестал быть нужен. Вопрос как узнать когда именно нужно освободить ресурс, а если легика была довольно сложной? В конце концов после долгих мучений выяснится что оптимальным решением будет именно подсчет ссылок. А вот как его реализовать в .НЕТ чтобы не было мучительно больно при использовании это уже придется хорошо подумать.
Хотя некоторые объекты (строки,...) лучше на GC.

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

M>Я не знаю, насколько STL зависит от платформы.
STL от платформы не зависит вобще.

WH>>Слова человека не знающего о существовании такого понятия в STL как allocator.
M>Для профессионального программиста на C++ ты делаешь удивительно тривиальные выводы. Да, я не знаю, что такое STL allocator. И именно поэтому, я не понимаю твоего аргумента
Это такая дурь скармливается последним аргументом шаблона(обычно используется аллокатор по умолчанию) Короче можно заставить контейнер использовать тот распределитель памяти который тебе нужен.

WH>>Но даже если забить на STL то ни что не мешает просто пользоваться всеми благами шаблонов.
M>Думаю, без хороших библиотек шаблоны среднеполезны.
Думаю без шаблонов хороших библиотек не напишешь.

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

WH>У мнея такое ощущение что кто-то чего-то сильно не понимает.
WH>Допустим у нас есть некий объект который держит ресурс. Этот объект использовало куча других и через некоторое время он перестал быть нужен. Вопрос как узнать когда именно нужно освободить ресурс, а если легика была довольно сложной? В конце концов после долгих мучений выяснится что оптимальным решением будет именно подсчет ссылок.
Почему ты так думаешь? Проблема GC ровно в одном — простой ресурсов. Т.е. дефицитный ресурс может некоторое время простоять из-за того, что его овнер еще не финализировался. Давай рассмотрим такой случай. Пусть у нас есть пул из, скажем, 10 ресурсов. И вот толпа народу их разбирает. Теперь у нас есть 10 хозяев, каждый из которых держит ссылки на эти ресурсы. Пусть восемь из них циклически ссылаются друг на друга, остальные двое присутствуют в графе достижимости. Итого, восемь простаивают зря. Еще толпа народу стоит и ждет, когда освободятся эти ресурсы. Что делает GC? Рано или поздно он проснется и пристрелит этих восьмерых козлят, вернув ресурсы в пул. Причем чем сильнее нужны эти ресурсы, тем больше потоков встанут в ожидание — это повышает шансы GC проснуться и заработать. На пальцах картина получается примерно такой.
Подсчет ссылок в этом случае вообще встрянет, так как есть цикл, который ему неподвластен. Итого, мы имеем некоторую задержку возврата супротив невосполнимой утечки. Кто победит?
Да, можно программировать так, чтобы такие объекты никогда не вступали в циклы. Но почти с тем же успехом можно прораммировать так, чтобы ресурсы освобождались детерминистически, при помощи IDisposable.
Причем, стоит отметить, что GC наплевать на то, насколько сложна логика. Он собирает любые циклы. В то время как при подсчете ссылок в сложной логике можно нечаянно замутить-таки цикл. И дооолго думать, откуда он взялся.
WH>Хотя некоторые объекты (строки,...) лучше на GC.
Ты не мог бы пояснить, в чем принципиальная разница между строками и... другими ресурсами? Дело в том, что я знаком с различиями технологий управления памятью в реальных системах в основном теоретически (ни разу не видел, чтобы одна и та же система была реализована сразу в обоих вариантах ), так что может не знаю каких-нибудь удручающих фактов из жизни мусоросборщиков.

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

S> Время на ослеживание. С таким же успехом, можно выделять память и в куче а и передвигать указатель конца использумой памяти. А дефрагментация памяти. Оссобенно при реаллоках когда памяти куча и Оут Оф Память. И в общем зачем тратить ресурсы если эта память не нужна. Другое дело системные ресурсы. Но об этом должен заботится программист ди не так их уж и много. Да и отслеживание мертвых объектов может происходить в момент простоя. Для многопроцессорных серверов вообще не проблема. Я думаю они провели немало времени за тестами и GC еще молод и будет развиваться. Идея правильная!!!!

Я не думаю, что стоит от GC ожидать существенного прироста производительности. По-моему, он принципиально медленный. Ведь когда убираем мусор по крайней мере объекты в окрестнсти (в графе) исследуемой на предмет мертвых объектов области должны быть заблокированы. Я так понимаю. Хотя в теории построения GC я не особо силен.

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

WH>>Допустим у нас есть некий объект который держит ресурс. Этот объект использовало куча других и через некоторое время он перестал быть нужен. Вопрос как узнать когда именно нужно освободить ресурс, а если легика была довольно сложной? В конце концов после долгих мучений выяснится что оптимальным решением будет именно подсчет ссылок.
S>Почему ты так думаешь? Проблема GC ровно в одном — простой ресурсов. хъ
Вот только однажды ктото долго матерился когда на слабой машине софтина на любых стресстестах работала как часы, а на серваке падала в месте с системой.
S>Подсчет ссылок в этом случае вообще встрянет, так как есть цикл, который ему неподвластен. Итого, мы имеем некоторую задержку возврата супротив невосполнимой утечки. Кто победит?
Чесно говоря не могу себе представить случай когда могут возникнуть циклические ссылки. Особенно в объектах которые используют внешние ресурсы. Проблема GC в том что ему не надо циклов для того чтобы держать ресурсы. К томуже он не риагирует на нехватку внешних ресурсов, а только на нехватку памяти.
S>Да, можно программировать так, чтобы такие объекты никогда не вступали в циклы. Но почти с тем же успехом можно прораммировать так, чтобы ресурсы освобождались детерминистически, при помощи IDisposable.
Проблема какраз в том чтобы узнать когда именно вызвать Dispose особенно если однозначно не возможно определить хозяина, а вот если использовать подсчет ссылок и GC одновременно(для того чтобы рано или позно но убить цикл)то это может дать очень не плохие результаты.
S>Причем, стоит отметить, что GC наплевать на то, насколько сложна логика. Он собирает любые циклы. В то время как при подсчете ссылок в сложной логике можно нечаянно замутить-таки цикл. И дооолго думать, откуда он взялся.
Ну не знаю как тако можно замутить особенно в той части программы которая работает с внешними ресурсами.
WH>>Хотя некоторые объекты (строки,...) лучше на GC.
S>Ты не мог бы пояснить, в чем принципиальная разница между строками и... другими ресурсами? Дело в том, что я знаком с различиями технологий управления памятью в реальных системах в основном теоретически (ни разу не видел, чтобы одна и та же система была реализована сразу в обоих вариантах ), так что может не знаю каких-нибудь удручающих фактов из жизни мусоросборщиков.
Да просто строки и компания используют ТОЛЬКО память, а именно не ее нехватку реагирует GC а вот колличество открытых файлов в системе ограничено и GC на это не риагирует. Тоже самое касается других ресурсов.

Здравствуйте, WolfHound, Вы писали:
WH>Вот только однажды ктото долго матерился когда на слабой машине софтина на любых стресстестах работала как часы, а на серваке падала в месте с системой.
Ну у нас софтина под java работала как часы под очень жесткой нагрузкой. Ну, это не так важно. Хотя я вообще не очень понимаю, как Java или .NET может вообще положить систему. Надо бы изучить эту тему.
WH>Чесно говоря не могу себе представить случай когда могут возникнуть циклические ссылки. Особенно в объектах которые используют внешние ресурсы.
Ну, вообще представить себе такой случай особой фантазии не надо. Практически любое отношение в бизнес-системе позволяет двустороннюю навигацию. Его можно, конечно, искусственно разорвать, но это не всегда удобно. Ну там накладная->клиент->список накладных->накладная. пипец.
Согласен насчет внешнересурсных ссылок. Но они как-то не очень часто имеют неопределенный scope. Из моего опыта все сценарии ровно такие: захватили-трай-попользовали-финалли-отпустили. Тут неважно, GC или еще кто.
WH>Проблема GC в том что ему не надо циклов для того чтобы держать ресурсы. К томуже он не риагирует на нехватку внешних ресурсов, а только на нехватку памяти.
WH>Проблема какраз в том чтобы узнать когда именно вызвать Dispose особенно если однозначно не возможно определить хозяина, а вот если использовать подсчет ссылок и GC одновременно(для того чтобы рано или позно но убить цикл)то это может дать очень не плохие результаты.
А! вот одновременно — неплохая идея. Поверх GC можно реализовать подсчет ссылок. Очень даже вполне.
WH>Да просто строки и компания используют ТОЛЬКО память, а именно не ее нехватку реагирует GC а вот колличество открытых файлов в системе ограничено и GC на это не риагирует. Тоже самое касается других ресурсов.
Ну я бы так пессимистично не относился. Если у нас есть в одном домене потоки двух типов, один из которых не требует ресурсов типа А и все время работает, тогда да — у GC не будет стимула проснуться и убрать для потоков типа B. Но по-моему, такие потоки проще разнести по разным доменам. А для симметричных потоков GC неизбежно проснется, когда будут исчерпаны любые ресурсы, т.к. пользовательским потокам просто нечего без них делать.

WF>>>Детерминированное == определенное. Т.е когда точно известен момент (и им можно управлять), например, смерти объекта.

M>>Определённое? Кем определённое?

WF>Семантикой умных указателей, например. Т.е известно, последовательность каких действий с интерфейсом умного указателя приводит к смерти объекта. Или областью видимости, если это переменная на стеке.

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

M>>В .NET объекты освобождаются тоже строго в определённый срок. Этот срок определяет GC.

WF>Нет. Неизвестно точно, какие действия с интерфейсом GC в конечном итоге приведут к смерти данного объекта.

WF>Пояснение: Интерфейс GC — это выделение объекта. Вызов GC.Collect() по очевидным причинам не рассматриваем в данной ситуации. Он, конечно, дает некоторую определенность, но слишком большой ценой .

В том то и дело, что нестрогие определения как раз и приводят к таким вот доопределениям "на ходу". Чтобы объяснить, что такое "детерменированное освобождение" тебе пришлось и от умных указателей отталкиваться, и от GC, и от цены. Как будто этот детерминизм — не реальное понятие, а что-то из области гуманитарных наук. Что нельзя понять, только сердцем почувствовать

M>>Конечно, ты скажешь, что определять время освобождения должен программист. Но тогда встаёт вопрос, какой программист? Если один компонент использует другой, то на ком должна лежать ответственность за освобождение?

M>>С одной стороны, это дело автора компонента, с другой — только пользователь компонента знает, когда он уже перестал его использовать.

WF>Мне все равно, кто как и зачем кого использует. Я использую некий компонент. Как он мне становится не нужен, я неявным образом (посредством области видимости, например) освобождаю его.

Ага. А если кто-то другой тоже его использует — сам виноват. Мы объект уже убили. Нечего было на одной дорожке пересекаться.