Здравствуйте, Сергей Губанов, Вы писали:
СГ>А если не хочется вызывать его вовсе? Например, в Delphi конструктор базового класса можно вызвать, а можно не вызывать, как больше нравится (аналогично — деструктор).
Конструктор — это не просто метод, это часть процесса инициализации объекта. Если не вызывать базовый конструктор, то нет никакой формальной гарантии и возможности инициализации базовых приватных переменных объекта.
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, L.C.R., Вы писали:
LCR>А вот обратная сторона медали: в Delphi невозможны умные указатели (и вообще, умные классы).
Странно, а какая связь между вирутальными (абстрактными) конструкторами (с которых началаясь эта ветка форума) и умными указателями . Я всегда думал, что умные указатели растут из templates + автоматический вызов деструкторов при выходе из блока.
С другой стороны, Вы говорите об уже устаревшей Delphi-7, ведь Delphi-8 (на же Delphi for .NET) и Delphi-9 (она же Delphi 2005) стали писаться под .NET, потребность в умных указателях как бы пропала — работает натуральная сборка мусора.
Re[10]: ЧАСТЬ 3: Конструкторы, деструкторы, и RAII
Сергей Губанов wrote:
> С другой стороны, Вы говорите об уже устаревшей Delphi-7, ведь > Delphi-8 (на же Delphi for .NET) и Delphi-9 (она же Delphi 2005) стали > писаться под .NET, потребность в умных указателях как бы пропала — > работает натуральная сборка мусора.
С появлением .NET просто отпала потребность в самой Дельфи....
--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[10]: ЧАСТЬ 3: Конструкторы, деструкторы, и RAII
Сергей Губанов,
LCR>>А вот обратная сторона медали: в Delphi невозможны умные указатели (и вообще, умные классы).
СГ>Странно, а какая связь между вирутальными (абстрактными) конструкторами (с которых началаясь эта ветка форума) и умными указателями . Я всегда думал, что умные указатели растут из templates + автоматический вызов деструкторов при выходе из блока.
Умный указатель возможен и без использования шаблонов — просто возникает необходимость в приведении типов на стороне клиента, а это неудобно. С шаблонами проще и надёжней. А вот автоматический вызов конструкторов и деструкторов — ключевой механизм.
СГ>С другой стороны, Вы говорите об уже устаревшей Delphi-7, ведь Delphi-8 (на же Delphi for .NET) и Delphi-9 (она же Delphi 2005) стали писаться под .NET, потребность в умных указателях как бы пропала — работает натуральная сборка мусора.
Сборка мусора обкладывается на таких простых вещах:
lock.acquire(obj);
Если lock недолгоживущий, то в случае Delphi мы пишем:
lock.aquire(obj);
...
lock.release(); // do not forget!
в случае С++ мы пишем
{
Lock lock(obj);
...
// free your mind!
}
Lock — это умный класс, он захватывает ресурс в конструкторе и освобождает в деструкторе. Если же lock — долгоживущий, то тут только взгляд и руки.
finally. В случае Дельфи мы пишем:
try
res.acquire();
obj.explode(random(2)); // рванёт - не рванётfinally
res.release(); // do not forget!end;
В случае C++ мы пишем:
{
ResGuard guard(res);
obj.explode(random(2));
// free your mind and be happy.
}
И это — единственный юзкейс finally. Поэтому добавлять в язык шоб було ((c) Vlad2) нет смысла. Нужно обходиться эффективно существующими средствами, а не обвешивать язык кренделями.
Здравствуйте, IT, Вы писали:
CS>>Что есть (GC и delete вместе) *очень* разумно.
IT>Я очень сильно сомневаюсь. Как бы не получился совершенно обратный эффект
А в чем сомнения?
delete в C++ есть? есть...
хорошо это или плохо? Хорошо. Для задач которые решает C++.
GC в .NET есть? есть...
хорошо это или плохо? Хорошо. Для задач которые решает .NET
В D есть и то и то.
Значит D может решать задачи С++ и .NET не выходя из одной среды.
В D такой проблемы выбора — managed/не managed — просто нет.
Т.е. если у тебя есть некий временный объект
который тебе более не нужен — удали его.
И работы GC будет меньше — т.е. сборка мусора будет
занимать меньше времени.
Достоинства по моему очевидны.
delete оператор еще одним свойством обладает
как и в C++ — вызов деструктора и метода delete
класса (В D можно переопределять new и delete).
Недостаток единственный — можно "выплеснуть младенца".
Но это решается легко — если есть малейшие сомнения —
не удаляй.
Наличие выбора мне лично очень нравится.
Re[11]: ЧАСТЬ 3: Конструкторы, деструкторы, и RAII
Здравствуйте, c-smile, Вы писали:
CS>delete в C++ есть? есть... CS>хорошо это или плохо? Хорошо. Для задач которые решает C++.
CS>GC в .NET есть? есть... CS>хорошо это или плохо? Хорошо. Для задач которые решает .NET
CS>В D есть и то и то. CS>Значит D может решать задачи С++ и .NET не выходя из одной среды.
Ага. Я бы сказал консолидирует проблемы обоих подходв.
Чдо до решаемых задачь, то что-то не видать на Ди драйверов и риалтайм-систем. А остальные задачи можно решать и на дотнете и на С++.
... << RSDN@Home 1.1.4 beta 4 rev. 351>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, IT, Вы писали:
IT>Конструктор — это не просто метод, это часть процесса инициализации объекта. Если не вызывать базовый конструктор, то нет никакой формальной гарантии и возможности инициализации базовых приватных переменных объекта.
1. Может быть предварительная инициализация. Как в том же дотнете.
2. Можно заставлять вызывать конструктор. Компилятору не сложно отследить, что все ветви выполнения содержат вызов базового конструктора.
3. В базовом конструкторе можно декларировать необязательность вызова конструктора.
В общем, это все решаемые проблемы. Я в свое время повозился с Дельфи и могу сказать с уверенностью, что отсутствие контроля компилятора за вызовом базовых конструкторов на практике проблем не создает. А вот кибкость от этого несколько увеличивается. Все же возможность вызова виртуальных функций в конструкторе позволяет создавать довольно хитрые схемы инициализации не прибегая к нагораживанию кучи паттеров на ровном месте.
... << RSDN@Home 1.1.4 beta 4 rev. 351>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, c-smile, Вы писали:
CS>Т.е. если у тебя есть некий временный объект который тебе более не нужен — удали его. CS>И работы GC будет меньше — т.е. сборка мусора будет занимать меньше времени.
Знаешь какая функция больше всего мешает нормальной работе многопоточных приложений? Правильно, Sleep. Ты думаешь она передаёт управление другому потоку и сохраняет тем самым процессорные тики. Но на самом деле она вмешивается в процесс переключения задач и заставляет систему по новой пересчитывать своё состояние.
Процесс вмешательства в работу GC ничем не лучше. Есть только один способ этому не повредить — delete ничего не должен делать с памятью. Т.е. программисты пусть свято верят и радуются жизни, но delete не трогает память. Память потом подчистит GC. Я искренне надеюсь, что в D это реализовано именно так, в противном случае при использовании деструкторов тормозов не избежать.
CS>Достоинства по моему очевидны.
Совсем не очевидны. Я не знаю как работает диспетчер памяти в D, но зато очень хорошо представляю как работает GC в .NET и сишный хип. GC по скорости легко ложит сишный хип на лопатки на выделении большого количества маленьких объектов. Достигается это тем, что выделение памяти сводится к простому сдвигу одного указателя на величину запрашиваемой памяти. Никаких поисков наиболее подходящих кусков памяти, как в хипах. Теперь, в D, я вызываю деструктор и ты утверждаешь что память освобождается. Куда она освобождается? Запускается GC? Бред. Заносится в список неиспользуеых блоков памяти как в хипах? А потом что? При выделении памяти будем их просматривать? Тогда теряем всё преимущество скорости GC. В общем, я бы попытался с этим разобраться прежде чем столь наивно радоваться такой фиче.
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, VladD2, Вы писали:
VD>В общем, это все решаемые проблемы. Я в свое время повозился с Дельфи и могу сказать с уверенностью, что отсутствие контроля компилятора за вызовом базовых конструкторов на практике проблем не создает. А вот кибкость от этого несколько увеличивается.
Каким образом?
VD>Все же возможность вызова виртуальных функций в конструкторе позволяет создавать довольно хитрые схемы инициализации не прибегая к нагораживанию кучи паттеров на ровном месте.
А в .NET виртуальные методы в конструкторах разве не вызываются?
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, VladD2, Вы писали:
VD>Чдо до решаемых задачь, то что-то не видать на Ди драйверов и риалтайм-систем. А остальные задачи можно решать и на дотнете и на С++.
Здравствуйте, IT, Вы писали:
IT>Процесс вмешательства в работу GC ничем не лучше. Есть только один способ этому не повредить — delete ничего не должен делать с памятью. Т.е. программисты пусть свято верят и радуются жизни, но delete не трогает память. Память потом подчистит GC. Я искренне надеюсь, что в D это реализовано именно так, в противном случае при использовании деструкторов тормозов не избежать.
delete удаляет блок их хипа.
В D имплементирован вариант http://www.hpl.hp.com/personal/Hans_Boehm/gc/
Но в отличие от C++ на D из за его структуры объектов этот GC работает
детерминистки.
CS>>Достоинства по моему очевидны. IT>Совсем не очевидны. Я не знаю как работает диспетчер памяти в D, но зато очень хорошо представляю как работает GC в .NET и сишный хип. GC по скорости легко ложит сишный хип на лопатки на выделении большого количества маленьких объектов. Достигается это тем, что выделение памяти сводится к простому сдвигу одного указателя на величину запрашиваемой памяти. Никаких поисков наиболее подходящих кусков памяти, как в хипах. Теперь, в D, я вызываю деструктор и ты утверждаешь что память освобождается. Куда она освобождается? Запускается GC? Бред. Заносится в список неиспользуеых блоков памяти как в хипах? А потом что? При выделении памяти будем их просматривать? Тогда теряем всё преимущество скорости GC. В общем, я бы попытался с этим разобраться прежде чем столь наивно радоваться такой фиче.
Мон шер IT, у меня такое ощущение что ты в плену стереотипов .NET
Начать с того что выражение "выделение памяти сводится к простому сдвигу одного указателя на величину запрашиваемой памяти" вернО до тех пор пока ты говоришь только о выделении памяти.
Но если рассматривать весь объем затрат на GC включая copying/generation management то тут
имхо имеем паритет с C++. В С++ выделение памяти медленне но нет таких "менопауз".
Вообще как ты понимаешь чудес нет в memory management. Мы как-то постоянно об этом забываем.
Тут всегда trade-off: где-то теряем, где-то находим.
Выжать максимум можно только если ты можешь варьировать обеими подходами в "тонких" местах.
Что в D как раз и возможно.
И еще. И в С++ и в D написание своего domain specific аллокатора делающего
"выделение памяти сводится к простому сдвигу одного указателя на величину запрашиваемой памяти"
это дело 15 минут. Переопределить new/delete и выбрать способ выделения буфера.
Далее. "ложит сишный хип на лопатки на выделении большого количества маленьких объектов."
А зачем собственно выделять это самое большое количество маленьких объектов?
Когда это можно сделать одним единственным выделением?
Это мне напоминает процедуру создания себе трудностей с последующим их героическим преодолением. Вельми благодатный процесс. Т.е. создателям потребовались динамические конструкции например приснопамятный ArrayList чтобы все было "как у настоящих пацанов" для этого потребовался boxing который и повлек за собой потребность в "выделении большого количества маленьких объектов".
И т.д.
В D и в C++ такой ерундой не занимаются. vector<int> там это один кусок памяти, а не
массив указателей на int выделенных в managed memory space.
Еще раз говорю истина как всегда посредине — между "только heap" и "только GC".
И вот там, в этой золотой середине, и сидит D
На самом деле я Вальтеру предложил ввести механизм memory pools —
тогда вообще можно говорить
new(myGenerationalMemoryPool) MyObject,
new(myMarkAndSweepMemoryPool) MyObject,
new(Heap) MyObject.
Это лучше спрашивать у действующих дельфистов. Мой опыт с дельфи был в 97-ом (что ли, в общем с дельфи 2-3).
В общих чертах дельфийский конструктор — это как бы виртуальный фабричный метод с всеми вытекающими.
IT>А в .NET виртуальные методы в конструкторах разве не вызываются?
Вызваются. Но ты надесь знашь, как это раздражает С++-ных теоретиков. Для них это как пенопастом по стеклу.
Но тут есть очень похожий момент с конструкторами в дельфи. Так же как возможность виртуальных вызовов в шарпе раздражает С++-ников, так же конструкторы дельфи разражают всех кто не пописал на Дельфи.
Я не говорю что в Дельфи сделано все как надо. Я просто утверждаю, что бенефитов от такого решения больше чем проблем. А вот от решения С++ проблем больше чем бенефитов. Всто это я говорю на собственном опыте и наблюдении за другими программистами.
... << RSDN@Home 1.1.4 beta 4 rev. 351>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, c-smile, Вы писали:
CS>Вот DKernel — OS kernel на D. CS>http://www.prowiki.org/wiki4d/wiki.cgi?KernelWithD CS>Проект не закончен но на digital mars news в среднем раз в месяц CS>бойцы выходят с написанием очередной ОС.
Ну, что же. Может быть это и есть предназначение Ди. В принципе он мне нравится намного больше чем С++.
Вот игры что-то какие-то не вразумительные. Ну, да может тоже прорвется. Хотя тут уже приемуществ не так много. Для игр компонентность и рантайм очень полезны.
... << RSDN@Home 1.1.4 beta 4 rev. 351>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, c-smile, Вы писали:
CS>Мон шер IT, у меня такое ощущение что ты в плену стереотипов .NET
Хочешь со мной пообщаться в подобном стиле? Можно конечно было бы задвинуть что-нибудь типа "Вам бы, уважаемый, сначала калькулятором научиться пользоваться, а уже потом рассуждать о программировании..", но мне это уже давно не интересно. Да и бывает что в баню я за это отправляю, придётся потом самого себя банить. Так что давай оставим другим сарказм, сатиру и юмор, переходящие в неуклюжие упражнения в демагогии. Ok?
А в плену я у здравого смысла. И подобный механизм у меня вызывает вполне законное недоверие. Если у тебя есть убедительные цифры и аргументы, то я с удовольствием их выслушаю. Точно такое же недоверие в своё время у меня вызывала производительность GC, по-этому я это дело тщательно проверял.
CS>Начать с того что выражение "выделение памяти сводится к простому сдвигу одного указателя на величину запрашиваемой памяти" вернО до тех пор пока ты говоришь только о выделении памяти. CS>Но если рассматривать весь объем затрат на GC включая copying/generation management то тут имхо имеем паритет с C++. В С++ выделение памяти медленне но нет таких "менопауз".
Ты на основании чего судишь? На основании собственных догадок или научных экспериментов? Я это утверждаю на основании проведённых тестов
.
CS>Вообще как ты понимаешь чудес нет в memory management. Мы как-то постоянно об этом забываем. CS>Тут всегда trade-off: где-то теряем, где-то находим.
Именно об этом я говорю. Чудес не бывает.
CS>Выжать максимум можно только если ты можешь варьировать обеими подходами в "тонких" местах. CS>Что в D как раз и возможно.
Мда... Хип и GC — это две принципиально разные вещи. Как можно скрестить бульдога с носорогом и получить в результате белого лебедя я совершенно не понимаю Объясни мне убогому.
CS>И еще. И в С++ и в D написание своего domain specific аллокатора делающего "выделение памяти сводится к простому сдвигу одного указателя на величину запрашиваемой памяти" это дело 15 минут. Переопределить new/delete и выбрать способ выделения буфера.
Только не забудь упомянуть про цену такого решения
CS>Далее. "ложит сишный хип на лопатки на выделении большого количества маленьких объектов."
CS>А зачем собственно выделять это самое большое количество маленьких объектов? CS>Когда это можно сделать одним единственным выделением?
А зачем мне одно единственное выделение, когда я могу выделять по мере необходимости? С GC результат будет тот же.
CS>Это мне напоминает процедуру создания себе трудностей с последующим их героическим преодолением. Вельми благодатный процесс. Т.е. создателям потребовались динамические конструкции например приснопамятный ArrayList чтобы все было "как у настоящих пацанов" для этого потребовался boxing который и повлек за собой потребность в "выделении большого количества маленьких объектов". CS>И т.д.
При чём тут боксинг? Речь именно об объектах, полноценных референс-типах, тех же строках.
CS>В D и в C++ такой ерундой не занимаются. vector<int> там это один кусок памяти, а не массив указателей на int выделенных в managed memory space.
Вот только не надо нам рассказывать про vector, более тупого варианта распределения памяти я не встречал. Без явного вызова reserve на больших объёмах данных можно легко "дать фору" любому GC.
CS>Еще раз говорю истина как всегда посредине — между "только heap" и "только GC". CS>И вот там, в этой золотой середине, и сидит D
Не верю. (c)
CS>На самом деле я Вальтеру предложил ввести механизм memory pools — CS>тогда вообще можно говорить CS>new(myGenerationalMemoryPool) MyObject, CS>new(myMarkAndSweepMemoryPool) MyObject, CS>new(Heap) MyObject.
И что это даст? Добавление в результате ещё одного менеджера менеджеров памяти?
CS>Вот такие вот пироги с котятами.
Да уж... мы их едим, а они пищат.
А вообще, котята такие — мне не нравится, что вместо доказательств в защиту D ты всё время скатываешься на поиск недостатков в .NET. Странная манера. Мы же в этом топике не .NET обсуждаем, правда? Но если тебе хочется, давай исходить из того, что .NET плохой, даже очень плохой, можешь больше не пытаться мне это доказать. Лучше докажи, что D хороший. Если получится, то кто знает, может потом вместе доказывать будем
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, c-smile, Вы писали:
CS>>Мон шер IT, у меня такое ощущение что ты в плену стереотипов .NET
IT>Хочешь со мной пообщаться в подобном стиле? Можно конечно было бы задвинуть что-нибудь типа "Вам бы, уважаемый, сначала калькулятором научиться пользоваться, а уже потом рассуждать о программировании..", но мне это уже давно не интересно. Да и бывает что в баню я за это отправляю, придётся потом самого себя банить. Так что давай оставим другим сарказм, сатиру и юмор, переходящие в неуклюжие упражнения в демагогии. Ok?
Это угроза или я чего-то не понял?
Игорь, если я обидел чем приношу свои извинения.
IT>А в плену я у здравого смысла. И подобный механизм у меня вызывает вполне законное недоверие. Если у тебя есть убедительные цифры и аргументы, то я с удовольствием их выслушаю. Точно такое же недоверие в своё время у меня вызывала производительность GC, по-этому я это дело тщательно проверял.
Игорь Ткачев:
При увеличении числа одновременно живущих объектов ещё на порядок ситуация стала ещё более печальной для GC. Теперь выигрыш заканчивается на 75 байтах, и далее GC начинает отставать, проигрывая в десятки раз, а при размере объектов в 5000 байт GC вообще впал в анабиоз часа на три, в то время как хипы уверенно справились с задачей за несколько минут.
Automatic vs. Explicit Memory Management:
Settling the Performance Debate
Matthew Hertz and Emery D. Berger
Dept. of Computer Science
University of Massachusetts
... we execute a range of unaltered
Java benchmarks using both garbage collection and explicit
memory management. Comparing runtime, space consumption,
and virtual memory footprints, we find that when space is plentiful,
the runtime performance of garbage collection can be competitive
with explicit memory management, and can even outperform
it by up to 4%. We find that copying garbage collection can
require six times the physical memory as the Lea or Kingsley allocators
to provide comparable performance. We also show that garbage
collection suffers orders-of-magnitude performance penalties
when paging occurs. This first-ever comparison of explicit memory
management and copying garbage collection shows where garbage
collectionmust improve in the future. While we expect the incorporation
of L3 caches to minimize the impact of garbage collection’s
poor L2 locality, the relative cost of disk latency continues to grow.
Improving the space efficiency and page-level locality of garbage
collection will thus become increasingly important.
Источник вот здесь.
CS>>Начать с того что выражение "выделение памяти сводится к простому сдвигу одного указателя на величину запрашиваемой памяти" вернО до тех пор пока ты говоришь только о выделении памяти. CS>>Но если рассматривать весь объем затрат на GC включая copying/generation management то тут имхо имеем паритет с C++. В С++ выделение памяти медленне но нет таких "менопауз".
IT>Ты на основании чего судишь? На основании собственных догадок или научных экспериментов? Я это утверждаю на основании проведённых тестов
Я руками сделал generational GC для своей VM. На самом деле для трех на сегодняшний момент.
Смею думать что и я тоже имею право судить о достоинсвах и недостатках GC и heap.
CS>>Вообще как ты понимаешь чудес нет в memory management. Мы как-то постоянно об этом забываем. CS>>Тут всегда trade-off: где-то теряем, где-то находим.
IT>Именно об этом я говорю. Чудес не бывает.
Вот. Можем же договариваться если непредвзято подходить?
CS>>Выжать максимум можно только если ты можешь варьировать обеими подходами в "тонких" местах. CS>>Что в D как раз и возможно.
IT>Мда... Хип и GC — это две принципиально разные вещи. Как можно скрестить бульдога с носорогом и получить в результате белого лебедя я совершенно не понимаю Объясни мне убогому.
Да все очень просто. Оставь GC функции именно garbage collector'а а не компактификатора
памяти и всего прочего.
Т.е. new аллоцирует объекты на хипе и регистрирует их в (глобальном) списке.
Т.е. ты можешь сделать delete конкретного объекта как обычно.
А можешь попросить все объекты в хипе просканировать себя (mark)
и выполнить затем опять же delete тех объектов которые не помечены (sweep)
Что тебе это дает?
Те же возможности работы с памятью что и в C/C++ плюс
устраняет потребность во всякого рода "умных" указателях
и жесткой потребности в explicit deletion.
И все! и не надо из GC вообще делать краеугольный камень.
Одна из многих фич которая решает отдельную задачу.
CS>>И еще. И в С++ и в D написание своего domain specific аллокатора делающего "выделение памяти сводится к простому сдвигу одного указателя на величину запрашиваемой памяти" это дело 15 минут. Переопределить new/delete и выбрать способ выделения буфера.
IT>Только не забудь упомянуть про цену такого решения
Я не понял про цену. цена чего?
На этом принципе (domain specific аллокатор) работают
такие штуки как Apache и Subversion. Там вообще все еще красивее устроено.
memory pools которыми можно независимо управлять.
There are four general-purpose pools always available in Apache:
the request pool, with the lifetime of an HTTP request.
the process pool, with the lifetime of an server process.
the connection pool, with the lifetime of a TCP connection.
the configuration pool.
CS>>Далее. "ложит сишный хип на лопатки на выделении большого количества маленьких объектов."
CS>>А зачем собственно выделять это самое большое количество маленьких объектов? CS>>Когда это можно сделать одним единственным выделением?
IT>А зачем мне одно единственное выделение, когда я могу выделять по мере необходимости? С GC результат будет тот же.
Ну вот снова... А удалять как?
А кто твою тучу объектов сканировать будет на предмет обнаружения ссылок.
Без фазы mark еще никто не обошелся.
А кто потом копировать оставшиеся объекты будет?
Ты ж вроде сам об этих проблемах написал?
CS>>В D и в C++ такой ерундой не занимаются. vector<int> там это один кусок памяти, а не массив указателей на int выделенных в managed memory space.
IT>Вот только не надо нам рассказывать про vector, более тупого варианта распределения памяти я не встречал. Без явного вызова reserve на больших объёмах данных можно легко "дать фору" любому GC.
Согласен обеими руками!
Ну дык думающий мозг ((С) McSeem2) он везде ж нужен.
И GC можно "посадить" и explicit memory allocators с не меньшим успехом.
CS>>Еще раз говорю истина как всегда посредине — между "только heap" и "только GC". CS>>И вот там, в этой золотой середине, и сидит D
IT>Не верю. (c)
Ну вот допишу свою Harmonia увидишь.
Честно, D — рулез.
Уже в общем и так видно.
Я думаю для людей серьезно программирующих на Java
и .NET и познавших "блеск и нищету куртизанок"
D представляет очень серьезный интерес. ИМХО, конечно.
Да, где-то местами своеобразный, но в общем и целом — кайф.
CS>>На самом деле я Вальтеру предложил ввести механизм memory pools — CS>>тогда вообще можно говорить CS>>new(myGenerationalMemoryPool) MyObject, CS>>new(myMarkAndSweepMemoryPool) MyObject, CS>>new(Heap) MyObject.
IT>И что это даст? Добавление в результате ещё одного менеджера менеджеров памяти?
Возможность оптимально выбирать в первую очередь.
На каких-то задачах один GC лучше на других — другой. На третьих — хип.
Возможность например "грохнуть" пул как одно целое и забыть
про все объекты там нааллоцированные. Например HTML страница со своим DOMом
при выгрузке оной может быть просто удалена как одно целое.
IT>А вообще, котята такие — мне не нравится, что вместо доказательств в защиту D ты всё время скатываешься на поиск недостатков в .NET. Странная манера. Мы же в этом топике не .NET обсуждаем, правда? Но если тебе хочется, давай исходить из того, что .NET плохой, даже очень плохой, можешь больше не пытаться мне это доказать. Лучше докажи, что D хороший. Если получится, то кто знает, может потом вместе доказывать будем
Да не скатываюсь я. Меня скатывают это да.
Ты прочти внимательно любую ветку от root и до конца.
Я никогда ничего про .NET на пустом месте и по своей инциативе
не говорю. У меня просто идиосинкразия на любые попытки меня "построить строем".
Все на .NET! А зачем, а почему и кому это выгодно?
Никто толком не показывает, не рассказывает и не демонстрирует.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, c-smile, Вы писали:
CS>>Вот DKernel — OS kernel на D. CS>>http://www.prowiki.org/wiki4d/wiki.cgi?KernelWithD CS>>Проект не закончен но на digital mars news в среднем раз в месяц CS>>бойцы выходят с написанием очередной ОС.
VD>Ну, что же. Может быть это и есть предназначение Ди. В принципе он мне нравится намного больше чем С++.
Не думаю что именно в этом предназначение D.
Хотя, может ты и прав. Мног чего-то желающих писать
ситемные вещи.
GUI задачи я оченно даже вижу на D.
CS>>C играми желающих не меньше...
.... VD>Вот игры что-то какие-то не вразумительные. Ну, да может тоже прорвется. Хотя тут уже приемуществ не так много.
Думаю да.
VD> ... Для игр компонентность и рантайм очень полезны.
У нас тут вообще-то Electronoc Arts под боком. Иногда встречаюсь с бойцами оттуда.
Вот бы тебе с ними поговорить про "компонентность и рантайм" ...
У них все свое и все внутри на голых сях плюсовых с темплейтами.
Здравствуйте, IT, Вы писали:
VD>>В общем, это все решаемые проблемы. Я в свое время повозился с Дельфи и могу сказать с уверенностью, что отсутствие контроля компилятора за вызовом базовых конструкторов на практике проблем не создает. А вот кибкость от этого несколько увеличивается.
IT>Каким образом?
Давай ты решишь простую задачку. На шарпе. Итак — имеем некий псевдокод:
public class Node
{
private Node _parent;
public Node(Node parent)
{
_parent = parent;
}
public Node Parent
{
get { return _parent; }
}
}
public RootNode : Node
{
public RootNode()
{
base(this);
}
}
VladD2 wrote:
> C>С появлением .NET просто отпала потребность в самой Дельфи.... > Дельфи — это язык. От платформы он не особо зависит. По крайней мере > для перехода на дотнет костылей ему понадобилось гораздо меньше чем > плюсам.
В том-то и дело, что Дельфи — не ЯЗЫК, а технология. Ее плюс — она
позволяет достаточно просто создавать сравнительно небольшие
_автономные_ GUI-приложения. Отсутствие GC в Дельфи вполне понятно, так
как он тянет за собой лавину измений, да и не особо нужен GC в
формочко-ориентированых приложениях.
С приходом .NET тоже появилась возможность достаточно просто создавать
GUIшные приложения, только теперь уже не автономные, а зависящие от
двадцатимегабайтного фреймворка.
Здравствуйте, c-smile, Вы писали:
CS>Не думаю что именно в этом предназначение D. CS>Хотя, может ты и прав. Мног чего-то желающих писать CS>ситемные вещи.
Дык что не говори, а Ди мог бы резко понизить планку вхождения в системное программирование и резко его упростить.
Забвано было бы написать VM c JIT-компиляцией на Ди.
CS>GUI задачи я оченно даже вижу на D.
Если только шаравари мелкие. А так лично я предпочту все же Шарп с дотнетом. Во-первых, кучу работы не прицдется делать, так как есть компонентная модель, а во-вторых, сама компонетность среды для ГУИ очень полезна.
VD>> ... Для игр компонентность и рантайм очень полезны.
CS>У нас тут вообще-то Electronoc Arts под боком. Иногда встречаюсь с бойцами оттуда. CS>Вот бы тебе с ними поговорить про "компонентность и рантайм" ...
Если там есть русские, то зави их сюда. А по англицки я свободно балакать не мгу. Слушать и читать еще ничего, а вот писать и говорить к сожалению тяжеловато.
CS>У них все свое и все внутри на голых сях плюсовых с темплейтами.
Оно и понятно. У них на это и деньги есть. А вот если, например, нам с тобой захочется их потеснить, то на плюсах это будет сделать очень не просто. На Ди еще туды-сюды, а вот на чем дотнете или какой-нить яве с костылями очень даже возможно. Памть становится все менее значимым ресурсом, а в сотальном... В общем, так и кончаются гегемонии богатых буратинов.
... << RSDN@Home 1.1.4 beta 4 rev. 351>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Если нам не помогут, то мы тоже никого не пощадим.
. Я всегда думал, что умные указатели растут из templates + автоматический вызов деструкторов при выходе из блока.
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
Хип и GC — это две принципиально разные вещи. Как можно скрестить бульдога с носорогом и получить в результате белого лебедя я совершенно не понимаю 
