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

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

H>>Я провел аналогии с форумными ветками. Ок. Тогда объясни мне, как .Net-разработчик, отчего могут эти фризы возникать на ровном месте. Хотя можешь не рассказывать, ты мне сейчас поведаешь об алгоритмах, проектировании и бла-бла-бла. Я все это слышал много раз. Можем завязать на этом.
WH>Скажу как разработчик на всем что компилируется или хотябы интерпритируется.
WH>Я ловил фризы нативного в доску ядра линукса.
WH>При определенных сценариях нагрузки воспроизводилось в 100% случаях.

Тут есть детерминированность в отличие от того случая.

WH>Так что существует огромное колличество причин по которым могут происходить фризы.

С этим никто и не спорит.

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

G>>Во всех программах на делфи, которые я видел, были утечки памяти. Для Java и .NET такого быть не может
WH>Может.

Каким образом? Через таймеры чтоли?

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

H>>Насколько я помню, с этим ХЗ так и не разобрались.
WH>Следовательно делать однозначный вывод о том что подвисает именно ГЦ нельзя.

100% конечно нельзя. Но уж очень на сборку смахивает, или что-то другое внутри FW

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

H>Тут есть детерминированность в отличие от того случая.
Если за раскопки того случая посадить меня то с ооочень большой вероятностью детерминированость очень быстро найдется.
Причем скорей всего просто после чтения кода.

WH>>Так что существует огромное колличество причин по которым могут происходить фризы.
H>С этим никто и не спорит.
Проблема в том что ты нашол какоето упоминание на какомто форуме о непонятно каком фризе и тупо экстраполируешь это упоминание на ГЦ.

К слову есть алгоритмы сборки мусора дающие гарантии реального времени.

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

H>100% конечно нельзя. Но уж очень на сборку смахивает, или что-то другое внутри FW
На сборку это какраз таки очень мало смахивает.

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

G>>>Во всех программах на делфи, которые я видел, были утечки памяти. Для Java и .NET такого быть не может
WH>>Может.
G>Каким образом? Через таймеры чтоли?
Например подписаться на событие долгоживущего объекта.
В Янусе одно время такой таракан жил.

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

H>>>>Я еще раз говорю, если ты работаешь с инструментом и не знаешь, как он работает -- ССЗБ. Обвинять компилятор в "интеллектуальных изысках", с твоей стороны, это расписываться в своей некомпетености. Не зная броду -- не лезь в воду.
G>>>Еще раз тебе говорю: люди реально работают с реальным инструментом (ASP.NET), далеко не все знают как работает каждая строчка написанного кода, там не менее ошибок соврешают гораздо меньше, чем эексперты, программирующие в делфи.

H>>Статистику в студию. Иначе, как я уже говорил, это все бла-бла-бла.

G>Еще раз говорю: эту ситацию вижу своими глазами.

G>Лучше факты приведу, почему на .NET писать проще.
G>1)Нет утечек памяти.

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

G>2)Нет таких проблем с COM, как описано выше.

В Delphi их тоже нет. То что обсуждалось с DX, это ни какая не проблема. Это нарушений правил языка.

G>3)Нет проблем с организацией сетевого взаимодействия — не надо изучать "тяжелые" технологии типа DCOM, CORBA и др.

В Delphi все это тоже есть. Плюс есть качественные сетевые библиотеки Indy, Synapse, ICS.

G>4)В .NET 3.5 практически не требуется писать DAL: типизированные запросы, проверяемые при компиляции; не надо писать SQL в программе; практически отсутсвие SQL-Injection уязвимостей

Не SQL'ем единым, как говорится. Применение Delphi не ограничивается мордами к БД.

G>5)В .NET 3.5 очень лекая работа с XML (твой метод XmlUnescapeString даже писать не надо).

Ты знаешь, я для своей задачи выбирал SAX парсер. Перепробовал более 10 штук. Это ли не богатство выбора? Что касается моей функции, повторяю: она написана с целью сократить расход памяти при модификации строк (в Delphi для Ansi-строк работает правило Copy-On-Write) для чего используется побочный эффект при работе с указателями (т.е. я не позволяю Delphi отследить модификацию строки).

G>То есть для выполнения тоже задачи что на делфи программисту на C# тебуется гораздо меньше специфических знаний и меньше времени на отладку.

Пока ты держишься в рамках продвигаемых MS технологий/решений -- возможно. Шаг в лево и приплыли.

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

kuj>Вместо Delphi пора преподавать .NET технологии.
Можно попробовать.
Только тогда сразу немерле Чтобы народ с юных лет понимал какое Г эти ваши C#'ы и тем болие дельфи.

kuj>Вместо Prolog — Erlang.
Не вместо, а вместе.
Ибо ерланг и пролог имеют очень разные вычислительные модели.

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

K>>> Да что вы говорите? А подумать прежде, чем отвечать, не судьба? Ок, объясняю — произойдёт два вызова Release() — один из них явно, а второй неявно компилятором. И если после явного вызова Release() счётчик ссылок будет равным нулю, то объект себя удаляет из памяти, и второй вызов приведёт к Access Violation.

H>>Таки да, будет проблема в этом случае. Проморгал, трудный день Однако это не дает тебе права наезжать на компилер по причине того, что Сишный подход не подходит в Delphi. Да, не подходит.

G>То есть пришли к выводу что интерфейсы кроме чем для COM использовать не стоит. Посмотри с чего обсуждение началалось.

Вовсе нет. Вывод тот же, что и ранее -- нефиг лезть со своим уставом в чужой монастырь. Играть нужно по правилам. Давайте еще начнем возмущаться по поводу утечек на таком коде:

Var

 Intfs : Array Of IInterface;

Begin

 SetLength(Intfs, 10);

 Intfs[0] := TInterfacedObject.Create;
 Intfs[1] := TInterfacedObject.Create;
 Intfs[2] := TInterfacedObject.Create;
 Intfs[3] := TInterfacedObject.Create;
 Intfs[4] := TInterfacedObject.Create;

 FillChar(Pointer(Intfs)^, Length(Intfs) * SizeOf(IInterface), 0);

 End;

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

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

H>>Тут есть детерминированность в отличие от того случая.
WH>Если за раскопки того случая посадить меня то с ооочень большой вероятностью детерминированость очень быстро найдется.
WH>Причем скорей всего просто после чтения кода.

Может да, а может нет

WH>>>Так что существует огромное колличество причин по которым могут происходить фризы.
H>>С этим никто и не спорит.
WH>Проблема в том что ты нашол какоето упоминание на какомто форуме о непонятно каком фризе и тупо экстраполируешь это упоминание на ГЦ.

Там это дело обсуждали тоже не новички, и советы мониторить GC таки были. Что читал, о том и говорю.

WH>К слову есть алгоритмы сборки мусора дающие гарантии реального времени.

Чудесно. Используются в .Net?

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

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

H>В Delphi их тоже нет. То что обсуждалось с DX, это ни какая не проблема. Это нарушений правил языка.
В C# не надо таких правил даже знать не надо. Просто нет особенностей работы с COM.

H>В Delphi все это тоже есть. Плюс есть качественные сетевые библиотеки Indy, Synapse, ICS.
И как они позволяют хотя бы простенький интерфейс удаленных вызовов сделать с передачой сложных объектов?
.NET Remoting вообще позволяет распределять объекты с помощью конфига, то есть в коде даже не видно где на самом деле проиходит вызвов.

H>Не SQL'ем единым, как говорится. Применение Delphi не ограничивается мордами к БД.
Морда к БД — как раз основное применение делфи. Сложную логику там реализовывать напряжно.
Работа с БД — одна из основных частей бизнес-приложений. Это чуть ли не самый большой рынок сейчас.

H>Ты знаешь, я для своей задачи выбирал SAX парсер. Перепробовал более 10 штук. Это ли не богатство выбора? Что касается моей функции, повторяю: она написана с целью сократить расход памяти при модификации строк (в Delphi для Ansi-строк работает правило Copy-On-Write) для чего используется побочный эффект при работе с указателями (т.е. я не позволяю Delphi отследить модификацию строки).
1)SAX и DOM рядом не валялись новой билиотекой по работе XML в .NET 3.5
2)Зачем алгоритм банальной замены символов надо оптимизировать по памяти? я бы еще понял по быстродействию.

H>Пока ты держишься в рамках продвигаемых MS технологий/решений -- возможно. Шаг в лево и приплыли.
А ты под какую ОС пишешь? И кто придумал COM технологию?

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

H>Вовсе нет. Вывод тот же, что и ранее -- нефиг лезть со своим уставом в чужой монастырь. Играть нужно по правилам. Давайте еще начнем возмущаться по поводу утечек на таком коде:

H>

H>Var

H> Intfs : Array Of IInterface;

H>Begin

H> SetLength(Intfs, 10);

H> Intfs[0] := TInterfacedObject.Create;
H> Intfs[1] := TInterfacedObject.Create;
H> Intfs[2] := TInterfacedObject.Create;
H> Intfs[3] := TInterfacedObject.Create;
H> Intfs[4] := TInterfacedObject.Create;

H> FillChar(Pointer(Intfs)^, Length(Intfs) * SizeOf(IInterface), 0);

H> End;
H>

В C# подобный код утечек не вызовет.

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

WH>>К слову есть алгоритмы сборки мусора дающие гарантии реального времени.
H>Чудесно. Используются в .Net?
Разве Windows — realtime ОС?

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

H>>В Delphi их тоже нет. То что обсуждалось с DX, это ни какая не проблема. Это нарушений правил языка.
G>В C# не надо таких правил даже знать не надо. Просто нет особенностей работы с COM.

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

H>>В Delphi все это тоже есть. Плюс есть качественные сетевые библиотеки Indy, Synapse, ICS.
G>И как они позволяют хотя бы простенький интерфейс удаленных вызовов сделать с передачой сложных объектов?
G>.NET Remoting вообще позволяет распределять объекты с помощью конфига, то есть в коде даже не видно где на самом деле проиходит вызвов.

Элементарно MIDAS, это Delphi трехзвенка, делала это еще в далеком 99 году. И по DCOM, и по CORBA, и OLEEnterprise (была у Inprise такая фенька), и по сокетам. Потом еще SOAP появился, но он вроде не очень юзабельный был.

H>>Не SQL'ем единым, как говорится. Применение Delphi не ограничивается мордами к БД.
G>Морда к БД — как раз основное применение делфи. Сложную логику там реализовывать напряжно.
G>Работа с БД — одна из основных частей бизнес-приложений. Это чуть ли не самый большой рынок сейчас.

Я не об основном предназначении говорю. Я сказал, что этим не ограничивается (в приводимом мною wiki сколько софта для работы с БД?)

H>>Ты знаешь, я для своей задачи выбирал SAX парсер. Перепробовал более 10 штук. Это ли не богатство выбора? Что касается моей функции, повторяю: она написана с целью сократить расход памяти при модификации строк (в Delphi для Ansi-строк работает правило Copy-On-Write) для чего используется побочный эффект при работе с указателями (т.е. я не позволяю Delphi отследить модификацию строки).
G>1)SAX и DOM рядом не валялись новой билиотекой по работе XML в .NET 3.5

Мне не интересно, я все равно напрямую с документом XML не работаю. Мне хватает SAX'а за глаза.

G>2)Зачем алгоритм банальной замены символов надо оптимизировать по памяти? я бы еще понял по быстродействию.

Дело в том, что Delphi при присваивании строк, на самом деле строки не копирует, а просто копирует ссылку и увеличивает счетчик ссылок. В дальнейшем, если в строку вносятся изменения, Delphi уже реально копирует строку (тот самый Copy-On-Write). Этот механизм помогает избежать перерасхода/перемещений памяти при копировании строк. Так вот. Если в мегабайтной строке потребуется поменять символ, нам не избежать копирования мегабайта. Оно нам надо? Поэтому указатели и побочный эффект. Этот код настолько часто вызывается, что оптимизировать есть ради чего.

H>>Пока ты держишься в рамках продвигаемых MS технологий/решений -- возможно. Шаг в лево и приплыли.
G>А ты под какую ОС пишешь? И кто придумал COM технологию?

Я не о том. Что есть в .Net для XML-RPC, JSON, Jabber? Будешь искать либы или сам писать.

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

H>>

H>>Var

H>> Intfs : Array Of IInterface;

H>>Begin

H>> SetLength(Intfs, 10);

H>> Intfs[0] := TInterfacedObject.Create;
H>> Intfs[1] := TInterfacedObject.Create;
H>> Intfs[2] := TInterfacedObject.Create;
H>> Intfs[3] := TInterfacedObject.Create;
H>> Intfs[4] := TInterfacedObject.Create;

H>> FillChar(Pointer(Intfs)^, Length(Intfs) * SizeOf(IInterface), 0);

H>> End;
H>>

G>В C# подобный код утечек не вызовет.

В Delphi, при добавлении строчки Finalize(Intf); перед FillChar, тоже не вызовет. Но мы не об этом.

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

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

WH>>>К слову есть алгоритмы сборки мусора дающие гарантии реального времени.
H>>Чудесно. Используются в .Net?
G>Разве Windows — realtime ОС?

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

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

H> Ты фантазер. Однозначно. Ссылки разумеется будут декрементиться на каждый вызов и Release и IntfClear (что в результате приведет к преждевременной кончине объекта). Но ни каких Access Violation не будет (ты же перед Release проверяешь переменную). Проверь, если не веришь.

Ну давай пройдёмся по строкам (если тут опять нету никакой скрытой семантики ).
Итак, мы имеем:

var intf : IUnknown;
//тут он откуда-то берётся, и счётчик ссылок его равен 1
intf._Release(); //тут счётчик ссылок обнуляется, что приводит к удалению объекта, 
                //а указатель продолжает ссылаться на то место, где был объект.
//Тут я делаю за компилятор его работу - инлайню функцию :)
if (intf <> nil) //проверка проходит, т.к. указатель не равен нулю
begin
  intf._Release(); //тут возможны любые чудеса, т.к. intf по сути является "висящим" указателем
  intf := nil; //допустим здесь, что компилятор не проявляет самодеятельности :)
end;

Так понятнее?

H>Про Access Violation уже ответил -- его там не будет. А твоя позиция меня просто изумляет: пришел в чужой монастырь со своим уставом, и ну права качать. Право, странные замашки...

См. выше.

H>Инлайнинг IntfClear -- это раздувание кода, причем абсолютно неоправданное.

Вот это новость! Единственное место, где реально "размер имеет значение" — это сфера embedded, но это явно не наш случай Во всех остальных случаях предпочтут больший размер файла при повышении производительности.

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

H>Таки да, будет проблема в этом случае. Проморгал, трудный день Однако это не дает тебе права наезжать на компилер по причине того, что Сишный подход не подходит в Delphi. Да, не подходит.

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

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

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

kuj>>Э-э, батенька, ты явно путаешься в понятиях.
kuj>>Во-первых, делегаты прекрасно реализуются в C++ в виде указателей на функцию.
WH>Есть куда болие удобная boost::function.

kuj>>Благодаря DI мой ClassA зависит только от IInterfaceB, который реализуется классами ClassB1, ClassB2 и ClassB3. В любой момент времени я могу открыть конфигурацию IoC и сменить байндинг с ClassB1, например, на ClassB2, совсем не затрагивая при этом ClassA. Да, в Delphi и C++ для этого используется паттерн фабрика, НО появляется зависимость ClassA, от фабрики! Вот такие пироги с капустой...
WH>IoC контейнер что не фабрика?
IoC контейнер это больше, чем классическая фабрика.

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

kuj>>Вместо Delphi пора преподавать .NET технологии.
WH>Можно попробовать.
WH>Только тогда сразу немерле Чтобы народ с юных лет понимал какое Г эти ваши C#'ы и тем болие дельфи.

Тогда уж IronRuby или хотя бы, чтоб народ с юных лет понимал какое Г этот ваш Nemerle.

kuj>>Вместо Prolog — Erlang.
WH>Не вместо, а вместе.
WH>Ибо ерланг и пролог имеют очень разные вычислительные модели.

Не на столько разные, чтоб заморачиваться.