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

H>>Я не буду меряться органами Мой бенчь (а я реально рассматривал перспективу перехода под .Net) был очень прост: в цикле (100.000.000) выполнялись несложные расчеты (основные операции +,-,/,*). Время замерялось именно Stopwatch, под Delphi перф-коунтером. Все лишнее выгружалось. Частота устанавливалась на максимум (у меня бука) без возможности тротлинга. Делалось несколько прогонов, как одного бенча так и другого. Потом откидывались лучшие и худшие результаты и бралось среднее значение. По этому бенчу я не оценивал общую производительность .Net. Померял только то, что померял.

G>У тебя в пограмме такие серьезные вычисления, что требуется нереальное быстродействие?

Мне нужно было сравнить -- я сравнил.

G>Тогда можен написать отдельную библиотеку на асме и для всего остального юзать C# ?

А можно остаться на Delphi, что я и сделал.

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

H>>Мы говорим об интерфейсах, а точне о COM-интерфейсах (где есть AddRef и Release).

Э>Если говорить о COM, то он базируется на подсчете ссылок, это одна из его основ. А у подсчета ссылок есть ограничение — он не может корректно работать с циклическими зависимостями.

Автоматически разумеется не может. Но для этого есть возможность ручного управления.

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

При возможности ручного управления это не ограничения. Я решил задачу переписав метод Release родительского интерфейса.

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

_>Сам я от большого программинга уже отошел

"Вот и ответ," — сказал Шекспир.
Походу, тут большинство спорщиков "уже отошли". 500 постов, однако, больше ничем не объяснить.

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

H>>Хотя в Delphi интерфейсы могут иметь не только COM-объекты.

MC>Так Вы когда говорили
MC>

MC>Для интерфейсов существует только один способ GC -- подсчет ссылок.

MC>Вы какие интерфейсы имели в виду? Если COM-интерфейсы (технический аспект) — это одно. Если, скажем так, ООП-интерфейсы (теоретический аспект) — то Вы абсолютно не правы. Рекомендую Вам все же почитать про то, как реализуется сборка мусора в java или .NET (ссылки Вам уже дали).

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

MC>В Вашем случае с деревом объектов GC сможет выявить, что дерево целиком недоступно — это раз. Далее он в неопределенном порядке выполнит финализаторы объектов, а потом и освободит память. Соответственно, в финализаторах родители и потомки никак не взаимодействуют.

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

MC>Можете сколько угодно критиковать такую схему, но она реально работает ака успешно применяется (и без всякого Вашего подсчета ссылок).

Я еще раз говорю: .Net критиковать не собираюсь. Живите, как умеете Спасибо за развернутый ответ

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

H>Если люди чего-то там не знали/забывали, это характеризует только их, но не инструмент. Если выражаться простым языком: не можешь срать -- не мучай жопу. В управляемых средах, таки, есть место ручной очистке (пусть даже семантически скрываемой) для объектов владеющих ресурсами. Что начнется, когда

В оригинале вобще-то звучит вобще-то "не хочешь срать — не мучай жопу". Разница существенная. В дальнейшем просьба быть точнее, а то минусы буду ставить нещадно!

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

MC>>>>Речь не о SOAP-сервисах, а о создании веб-морд. Т.е. упрощенно — когда есть HTML-шаблоны и java/.net код, который на их основе хитро генерит динамические страницы. Ну, короче, как в php.

H>>>WebSnap. Ребята, оно было еще в 6 версии. Intraweb еще круче

Ну вот здесь говришь...

kuj>>Хочу полноценный MVC с unit test`ами и расширяемым view-engine по типу Brail (из Castle Monorail)! Где?

H>Я не занимаюсь вебом, ничего сказать не могу.

А здесь ничего не можешь сказать. Как так?

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

H>>>>>Кто-то недавно эту феню материл из-за шаловливых ручек юзеров. Да и вообще прикол: пропали конфиги -- отвалились протоколы

kuj>>>>Угу, пропал exe-шник — отвалилась голова.

H>>>У тебя конфиги ни разу не слетали? Если у меня слетит конфиг, моя прилага не забудет как по XML-RPC разговаривать

kuj>>Не знаю как оно в Делфи, но в .NET и Java конфиги не имеют такой привычки — куда-то там слетать...

H>И юзеры с админами ну прям небожители. Охотно верю.

Ну так какое отношение .Net имеет к админам? Если уж ты такой любитель народных поговорок (впрочем как и я): с дуру можно и х.. сломать"

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

ДГ>>Гы. Это был аргумент из серии "я вот тут комп с десятого этажа уронил, теперь он гад загружаться не хочет". Догадываешься, что случится, если в линухе все конфиги пропадут? Конфиги — такие же файлы, как и екзешники.

H>Какое мне дело до Линукса? Ни одного юзера не допрет править руками exe'шник, а конфиг за милу душу. Но если тебе приятно не замечать проблемы, чтож, хозяин -- барин.

Мужики, он против Линукса — налетай

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

H>Я с Паскалем 13 лет. Спасибо.

Пора завязывать.

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

kuj>>FxCop поможет... И не только с этой проблемой, кстати.

H>Я знаю, что такое FxCop У Борланда давно уже был CodeGuadr для C++ (задачи примерно те же).

Бгга Я наелся дерьма C++ Builder даже не считая CodeGuard-а еще 5 лет назад. Ф топку .

До сих пор помню такой замечательный глюк CodeGuard-a: компилирую проект, в рантайме летит ошибка на ровном месте, я меняю местами объявления шаблонрв класса в исходном файле — все работает нормально. После этого отказался от CodeGuard-а, через некоторое время понял, что глюкавый компилятор тоже меня не устравает. Начинал я вообще с Turbo C++ 1.0.

Про Дельфи не скажу, но от поделий Богланд меня что-то воротит. Может вспомним еще угробище под названием Interbase?

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

kuj>

kuj>int x = 3;

kuj>x += x++;

kuj>

kuj>Вопрос: чему равен x?

6

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

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

TEO>>Кто-нибудь может то же самое написать для Delphi?

kuj>К счастью нет.

Тэкс, запишем — еще один недостаток дельфи

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

OCT>TheEvilOne пишет:
>> Как так не хакерская? Некоторые особо одаренные люди пишут на дельфях не
>> только драйвера уровня ядра для виндовс ХР, но и вирусы
>> различные
OCT>Встречал один раз вирус на Visual Basic. Он мониторил открытые папки, и
OCT>эвакуировал себя в другую папку, как только там появлялся пользователь.
OCT>Т. е. заходишь ФАРом в WINDOWS/HELP, в листинге он есть, но на самом
OCT>деле он уже WINDOWS/INF, заходишь в WINDOWS/INF, а он уже в
OCT>WINDOWS/ещё–что–нибудь. При этом меняет запись в реестре для своей
OCT>автозагрузки. А если ключ автозагрузки убрать, то добавляет его через
OCT>полминуты.

OCT>Не руткит, но всё равно занятная поделка.

На C# этот вирус работал бы лучше и эффективнее

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

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

L>>>Нет, я топики не ношу. Максимум — майки.

kuj>>А минимум топлес?

L>Не, минимум — это еще и даунлесс.

Может ботомлесс?

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

G>>4)ref и out параметры.

Обычная передача по указателю, здесь нет никакой прерогативы дельфи. Передача праметров по ссылке была и есть даже в васике не говоря уже про С/С++.

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

H>Здравствуйте, gandjustas, Вы писали:
G>>Если у объектов есть финализаторы, то они еще некоторое время проживут. Сначала выполнятся финализаторы для всех, а только на следующем проходе их GC уберет все объекты.

H>Есть гарантия, что финализатор родителя выполнится последним?
Нет, а оно вам надо?

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

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

H>>>Мы говорим об интерфейсах, а точне о COM-интерфейсах (где есть AddRef и Release).

G>>Еще раз, запомни простую вещь: в .NET нету разницы между COM и не-COM

H>Ок. У .Net-интерфейсов есть механизм подсчета ссылок? И почему мне Mr.Cat говорил, что не в курсе, как устроен GC для COM-интерфейсов? Есть какое-то различие? Просвети.
Нет различий.

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

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

MC>>В Вашем случае с деревом объектов GC сможет выявить, что дерево целиком недоступно — это раз. Далее он в неопределенном порядке выполнит финализаторы объектов, а потом и освободит память. Соответственно, в финализаторах родители и потомки никак не взаимодействуют.
H>Вот (неопределенный порядок, невозможность взаимодействия в финализаторах). Значит тут, и таким способом, задачу не решить. Не смертельно, конечно, но не сильно приятно.

Теперь приведи 3 причины почему финализаторы должны ввыполняться в определенном порядке.

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

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

G>>>>1)Свойства
kuj>>>Java get/set
G>>Это не свойства

kuj>Как это не свойства, а что это?
Это пара случайно обозванных методов. На всякий случай напомню, что свойства в дельфи и в дотнете проверяет компилятор, так что невозможно допустить опечатку в имени или поменять тип свойства несогласованным образом. Также на всякий случай напомню, что свойства в дельфи и дотнете хранят свои метаданные, независимые от методов, которыми свойства реализованы. Ничего похожего на свойства в джаве нет.

kuj>(далекий 1996 год)
kuj>http://java.sys-con.com/read/49097.htm
На всякий случай напомню, что в дельфи и дотнете делегаты контролируются компилятором и средой исполнения, так что, к примеру, невозможно положить в делегат ссылку на метод с неподходящей сигнатурой. В предлагаемом примере выполняется late binding, который никак не контролируется компилятором. Кроме того, приходится вручную даункастить результат вызова "делегата". Так что, ничего похожего на делегаты в джаве нет.

kuj>>>В C# гораздо больше взято от Java, чем от Object Pascal.
Смею предположить, что сие утверждение просто говорит о том, что ты плохо знаешь Object Pascal, и хорошо — Java.

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

kuj>В действительности вышеописанных граблей ни в одной нормальной среде разработки быть не должно.

kuj>Конечно определенные грабли есть везде — где-то меньше, где-то больше. Регулярно пользуюсь VS 2005, VS 2008, пару лет тому назад еще IntelliJ IDEA в арсенале была. Все отлично — на грабли натыкаться не приходиться, работать одно удовольствие.

Да есть тоже немножко. Сейчас пользуем VS 2005 SP1:
— Если попробовать в док. комментариях добавить для достаточно большого файла
/// <summary>
/// asda
/// </summary>
/// <param name="dsda"> asas /</param>
вот например в этом месте попытаться напечатать слэш — студия виснет.

— До SP1 одолевал WinForms дизайнер — открываешь допустим свой контрол, а на нем кнопки съехали. Ну это уже не в счет.

— WinForms дизайнер — шрифты в дизайнере могут оказаться другого размера, чем на реальной форме.

— Есть проблемы с дизайнером ReportViewer-а — преобразование единиц измерения, например мм-см, и прочие мелочи типа неверного преобразования margins страницы — это самое неприятное.

Это все, на что наткнулся лично я. Но все это мелочи. А работать и правда одно удовольствие.