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

kuj>>1. У Javascript есть нормальный garbage collector. Ему не нужны smart pointer`ы.
DOO>Тем не менее. Мне они не нужны и в C — и так хорошо живется. У всего есть своя ниша.
Кроме Delphi. Ее мини-ниша полностью занята .NET

kuj>>2. Делфи — динамический язык?
DOO>В достаточной мере.
Скажу тебе по секрету Delphi никогда не был, не является, и вряд ли когда-то станет динамическим языком.
В отличии от платформы .NET, для которой Microsoft`ом несколько лет активно разрабатывается DLR — Dynamic Language Runtime.


kuj>>А Борланд об этом знает?
DOO>Да уж наверное. Хотя в 6-й дельфи они стали на многие прикольные фишки выдавать ворнинги, что в .Net версии это уже не будет работать.
И при чем тут динамические языки?


kuj>>Если хочешь посмотреть на динамический язык возьми ruby или python, например.
DOO>Кстати, мое первое впечатление от питона было — о! Дельфи в виде скрипта. Очень много похожего.
Всего-лишь говорит о твоей низкой квалификации, если для тебя "Питон — это дельфи в виде скрипта".

kuj>>Ликбез: Delphi, C++ и C# — статические строго типизированные языки.
DOO>На вскидку из гугла:
DOO>

DOO>TabGrid := VarArrayCreate([0,(R - 1),0,(C - 1)],VarOleStr);
DOO>    I := 0;
DOO>    //  Определяем цикл для заполнения массива-матрицы
DOO>    repeat
DOO>    for J := 0 to (C - 1) do
DOO>      TabGrid[I,J] := GenericStringGrid.Cells[J,I];
DOO>    Inc(I,1);
DOO>    until
DOO>    I > (R - 1);
DOO>

DOO>Опа. Не попадает как-то в узкие рамки статической строгой типизации? Причем заметь — надо писать не что-то вроде SetVariantArrayValue(TabGrid,i,j), а просто TabGrid[i,j] — при этом TabGrid не является массивом до момента выполнения строчки TabGrid := VarArrayCreate([0,(R — 1),0,(C — 1)],VarOleStr);

VarArrayCreate создает массив значений типа Variant. При чем тут динамические языки? Ты, батенька, серьезно не в теме.


kuj>>Неужто ты серьезно думаешь, что если есть generic`и, то пропадает возможность кастинга объекта к суперклассу?
DOO>Нет не пропадает. Я тебе просто говорю, что когда это активно используется в программах проку от твоих универсальных контейнеров — ноль.
Проку от них ровно столько, сколько проку от подобного контейнера в Delрhi. Кроме того, что я могу явно ограничить супертип, что уменьшит поле для ошибок на этапе компиляции. Вообщем, ты снова явно не в теме.

kuj>А GC тут при чем?
При том, что GС не гарантирует отсутствия утечек

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

kuj>>А GC тут при чем?
_>При том, что GС не гарантирует отсутствия утечек
Гарантирует отсутствие утечек в управляемых ресурсах.

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

H>Проектирвать на перспективу нужно.

Программист Делфи, рассуждающий о перспективе, это круто.

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

kuj>>А GC тут при чем?
_>При том, что GС не гарантирует отсутствия утечек
GC в .NET гарантирует отсутствие утечек, то есть гарантирует, что вся занятая память будет рано или позно освобождена.
Есть некоторые ситуации, когда это "поздно" наступает в момент завершения программы, несмотря на то что видимых ссылок на эту память нет, но обнаружить и устранить такое очень легко.

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

G>GC в .NET гарантирует отсутствие утечек, то есть гарантирует, что вся занятая память будет рано или позно освобождена.
Не гарантирует.

G>Есть некоторые ситуации, когда это "поздно" наступает в момент завершения программы,
Так это и есть утечка ибо нормальные ОС по любому освободят всю память которую захапал завершенный процесс.

G>несмотря на то что видимых ссылок на эту память нет, но обнаружить и устранить такое очень легко.
С этим никто не спорит.
Но и говорить что ГЦ дает гарантии отсутствия утечек нельзя.

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

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

G>>Есть некоторые ситуации, когда это "поздно" наступает в момент завершения программы,
WH>Так это и есть утечка ибо нормальные ОС по любому освободят всю память которую захапал завершенный процесс.
Тут еще можно ввспонить про домены приложений. Память освобождается при выгрузке домена.
Поэтому утечки в .NET, не тоже самое что утечки нативной папями.

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

H>>Со ссылками, вроде, разобрались. Но появился другой вопрос: как контролировать последовательность смерти интерфейсов, если она важна?
WH>А когда она важна?
WH>От ответа на этот вопрос зависит ответ как контролировать.

Когда чилдам может потребоваться парент. И нужно гарантировать, что парент будет жив. Со ссылками тоже: если твои интерфейсы отдать во вне, в неуправляемую среду, то GC за ними следить не сможет?

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

H>Когда чилдам может потребоваться парент. И нужно гарантировать, что парент будет жив. Со ссылками тоже: если твои интерфейсы отдать во вне, в неуправляемую среду, то GC за ними следить не сможет?
Хватит решение расказывать.

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

H>>У меня не набор классов. У меня набор интерфейсов.
G>Перестань повторять эту тупость порожденную кривостью делфи. В любом случае это будут какие-то объекты.

Ты так и не понял Как ты у объекта спросишь, может ли он летать? (я надеюсь ты не станешь проверять его предков, типа Object Is TCanFlyObject?) У интерфейса ты позовешь QueryInterface(ICanFly, CanFlyIntf). Теперь понятно?

H>>Ключевое значение имеет обеспечение возможности чилдов иметь парента, когда они хотят.
G>А парент просто хранит ссылки на детей?

Что значит просто? Ну да, имеет список своих чилдов.

G>>>Опишешь задачу, больше чем уверен найдется адекватное решение на .NET.
H>>Так я и так ее описал. Это не решение моим способом, как ты говоришь, это и есть задача. Я тебе могу описать ее в терминах предметной области, но что тебе это даст?
G>Еще раз. Ты описываешь решение задачи, а ты опиши саму задачу. Забудь что у тебя есть компьютер, классы, интерфейсы. Просто скажи что должен увидеть пользователь.

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

G>>>ЗЫ С выделенным категорически не согласен.
H>>Да-да, ведь рефакторинг это круто
G>Не в рефакторигне дело.

А в чем? Будешь по десять раз редизайнить систему при малейших изменениях, вызванных недальновидным проектированием.

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

H>>Кто говорит о рукописном? Есть редактор библиотеки типов, который сам все напишет.
G>С ужасно кривым интерфейсом редактирования. (Надеюсь с седьмой версии улучшили)

Вроде чего-то там переделывали, но я после семерки с DCOM, да и вообще с Enterprise фишками не работаю.

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

kuj>>>А Борланд об этом знает?
DOO>>Да уж наверное. Хотя в 6-й дельфи они стали на многие прикольные фишки выдавать ворнинги, что в .Net версии это уже не будет работать.
G>Наверное ворнинги не от хорошей жизни.

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

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

H>>Когда чилдам может потребоваться парент. И нужно гарантировать, что парент будет жив. Со ссылками тоже: если твои интерфейсы отдать во вне, в неуправляемую среду, то GC за ними следить не сможет?
WH>Хватит решение расказывать.

Еще раз говорю, это не решение. Это этап проектирования (не смотря на то, что и решение уже есть). Я, gandjustas'у уже давно пытаюсь это объяснить.

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

H>Еще раз говорю, это не решение. Это этап проектирования (не смотря на то, что и решение уже есть). Я, gandjustas'у уже давно пытаюсь это объяснить.
Бла-бла-бла.
Задача:
Написать интерпритатор. Делаем xml-based язык. Парсим xml в dom. Далие просто по имени элемента передаем управление соответствующему обработчику. Вот главный цикл:

        for (xmlNodePtr commandNode = xmlFirstChild(commands); commandNode != 0; commandNode = xmlNextChild(commandNode))
        {
            try
            {
                Command::find(xmlName(commandNode))->apply(&context, commandNode);
            }
            catch (std::exception const& ex)
            {
                throw std::logic_error(std::string("Command ") + xmlName(commandNode) + " failed: " + ex.what());
            }
        }

Чтонибдуь понял?

А теперь реальная задача: Сделать пакетную обработку картинок.
Благодоря этому мегадвиглу я на вопрос: А давай сделаем?
За редким исключением (когда нужной комманды еще нет) отвечаю: Делате.

Вот от тебя ничего кроме первого абзаца не слышно.

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

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

DOO>>Тем не менее. Мне они не нужны и в C — и так хорошо живется. У всего есть своя ниша.
kuj>Кроме Delphi. Ее мини-ниша полностью занята .NET

.NET, конечно, занял большую часть ниши Delphi.
Но не полностью, нет.

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

H>>Я читал, спасибо. И раньше еще читал В нативной Delphi тип интерфейсов один -- COM, как вы его называете. Их я и имел ввиду.

kuj>Ты уж определись сколько типов интерфейсов есть в Delphi. Не ты ли недавно говорил, что в Delphi интерфейсы могут быть и не COM?

ignore off

Ты так туп, что не можешь прочитать, что написано COM, как вы их называете. Да, интерфейсы Delphi бинарно совместимы с COM. Но интерфейсы могут иметь не только COM-объекты, и называть такие интерфейсы COM-интерфейсами нельзя.

ignore on

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

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

H>>>У меня не набор классов. У меня набор интерфейсов.
G>>Перестань повторять эту тупость порожденную кривостью делфи. В любом случае это будут какие-то объекты.

H>Ты так и не понял Как ты у объекта спросишь, может ли он летать? (я надеюсь ты не станешь проверять его предков, типа Object Is TCanFlyObject?) У интерфейса ты позовешь QueryInterface(ICanFly, CanFlyIntf). Теперь понятно?
Ну хватит уже показывать свое незнание.
В C# вообще нету QueryInterface, приведение к типу интерфейса осуществляется темеже способами, что обычное приведение типа.
Из одного твоего предложения сразу видно что: а)ты не работал с .NET языками б)ты не работал на С++ в)ты не работал с COM не в Delphi г)ты плохо понимаешь зачем вообще нужны интерфейсы.

H>>>Ключевое значение имеет обеспечение возможности чилдов иметь парента, когда они хотят.
G>>А парент просто хранит ссылки на детей?
H>Что значит просто? Ну да, имеет список своих чилдов.
Тогда такая ситуация нормально разрулится GC.

G>>>>ЗЫ С выделенным категорически не согласен.
H>>>Да-да, ведь рефакторинг это круто
G>>Не в рефакторигне дело.
H>А в чем? Будешь по десять раз редизайнить систему при малейших изменениях, вызванных недальновидным проектированием.
Честно гворя даже не хочу тебе объяснять

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

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

H>>>Когда чилдам может потребоваться парент. И нужно гарантировать, что парент будет жив. Со ссылками тоже: если твои интерфейсы отдать во вне, в неуправляемую среду, то GC за ними следить не сможет?
WH>>Хватит решение расказывать.

H>Еще раз говорю, это не решение. Это этап проектирования (не смотря на то, что и решение уже есть). Я, gandjustas'у уже давно пытаюсь это объяснить.

Тебе уже 3 человека написали чтобы ты сказал исходное условие задачи.

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

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

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

DOO>>>Тем не менее. Мне они не нужны и в C — и так хорошо живется. У всего есть своя ниша.
kuj>>Кроме Delphi. Ее мини-ниша полностью занята .NET

С>.NET, конечно, занял большую часть ниши Delphi.
С>Но не полностью, нет.
Конечно, нужен же инструмент, в котором люди смогут писать программы с бешеными утечками памяти.
Какая часть ниши Delphi еще не занята .NET?

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

DOO>>>Тем не менее. Мне они не нужны и в C — и так хорошо живется. У всего есть своя ниша.
kuj>>Кроме Delphi. Ее мини-ниша полностью занята .NET

С>.NET, конечно, занял большую часть ниши Delphi.
С>Но не полностью, нет.

А что кроме legacy осталось?