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

H>Чисто ремарка: Для переменного числа параметров есть константные массивы.

H>

H>Procedure SomeProc(Const Array Of const);
H>Begin
H>End;

H>...

H>SomeProc([1]);
H>SomeProc([1, '1024']);
H>SomeProc([1, '1024', Now]);
H>SomeProc([1, '1024', Now, TStringList]);
H>

Моя плакать "Const Array Of const" — убей себя об стену кто такое придумал.
А ведь паскаль создавался как язык для обучения с практически очевидной семантикой.

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

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

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

MC>>15 мб. Один раз поставить — и забыть (ну разве что обновлять изредка). Офигеть как много, да?
_>Это не мало. У меня на машине JRE нет, захочу такую программу -- буду качать все.
Вы и ОС небось не обновляете? Сам долго на диалапе сидел — но даже 20-30мб проблемой никогда не были.

_>Ну когда примитивный конфигуратор, вся работа которого ini-файл записать, начинает тридцать метров жрать, то значит что-то неладное в самой среде. ... Производители новые техпроцессы осваивают не для того чтобы очередная джава с ... сожрала подчистую и все осталось точно так же как и было!
Это очень распространенный и необдуманный аргумент — когда берут в качестве примера какое-то совсем простое приложение на java (да и на любой управляемой платформе) — дай Бог, не "hello world" — и начинают распинаться, как же много простейшее приложение жрет памяти, как (в сравнении с аналогом на C, например) долго грузится и тэ дэ и тэ пэ. Надо ведь понимать, кое-какие вещи:
1)Ресурсоемкость java-приложений не растет прямо пропорционально их "сложности". Т.е. ясное дело, что у "hello world" (или конфигуратора вашего) большая часть съедаемой памяти — память, съедаемая самой jre. Однако для более сложных приложений все будет совсем не так.
2)Ресурсоемкость нескольких java-приложений не растет прямо пропорционально количеству этих приложений. Где-то мелькало на форуме — т.к в этом случае не бдет нескольких копий jre в памяти.
3)Важно знать, какой процент из этих 30мб входит в "рабочее множество", а какой просто загружен про запас, валяется в свопе и никому не мешает. Лично у меня такой информации нет, но я больше чем уверен, что большая часть этих 30мб — именно про запас загружается.

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

MC>>>15 мб. Один раз поставить — и забыть (ну разве что обновлять изредка). Офигеть как много, да?
_>>Это не мало. У меня на машине JRE нет, захочу такую программу -- буду качать все.
MC>Вы и ОС небось не обновляете? Сам долго на диалапе сидел — но даже 20-30мб проблемой никогда не были.
Я сейчас сижу на выделенке 128k с безлимитным трафиком. Но как программист я думаю о пользователях, которые и на модемах сидят и через CDMA с GPRS-ом ходят, платя ощутимые деньги за каждый скачанный мегабайт.

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

_>>Ну когда примитивный конфигуратор, вся работа которого ini-файл записать, начинает тридцать метров жрать, то значит что-то неладное в самой среде. ... Производители новые техпроцессы осваивают не для того чтобы очередная джава с ... сожрала подчистую и все осталось точно так же как и было!
MC>Это очень распространенный и необдуманный аргумент — когда берут в качестве примера какое-то совсем простое приложение на java (да и на любой управляемой платформе) — дай Бог, не "hello world" — и начинают распинаться, как же много простейшее приложение жрет памяти, как (в сравнении с аналогом на C, например) долго грузится и тэ дэ и тэ пэ. Надо ведь понимать, кое-какие вещи:
MC>1)Ресурсоемкость java-приложений не растет прямо пропорционально их "сложности". Т.е. ясное дело, что у "hello world" (или конфигуратора вашего) большая часть съедаемой памяти — память, съедаемая самой jre. Однако для более сложных приложений все будет совсем не так.
Не спорю. Но нижняя планка слишком высокая.

MC>2)Ресурсоемкость нескольких java-приложений не растет прямо пропорционально количеству этих приложений. Где-то мелькало на форуме — т.к в этом случае не бдет нескольких копий jre в памяти.
Это стандартная фича винды. Сегменты кода используются процессами совместно, однако данные либо copy-on-write, либо вообще отдельные. А т.к. большая часть виртуальной машины ИМХО данные (байт-код всяких библиотек и т.п., что с точки зрения процессора кодом не является), то каждая следующая копия отжирает пусть не 30, но 20-25 метров -- запросто (это то что сам видел). Конечно со стороны саой виртуальной машины тоже могут быть предприняты меры по совместному использованию всего что можно, может уже так и есть, но еще пару лет назад было так, как я написал выше.

MC>3)Важно знать, какой процент из этих 30мб входит в "рабочее множество", а какой просто загружен про запас, валяется в свопе и никому не мешает. Лично у меня такой информации нет, но я больше чем уверен, что большая часть этих 30мб — именно про запас загружается.
Может быть, но своп тоже не резиновый ведь. Хотя согласен, это не настолько критично.

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

_>Отвечал на ваш вопрос, если не понятно. Кроме формошлепства кое-что еще имеется.
В Delphi тоже много чего имеется. И кроме формошлепства он позволяет писать и консольные приложения (по вашему посту у меня возникло очень стойкое ощущение что вы этого просто не знали) и сервисы (аналогично). Что касается горячелюбимого веба, то не нужно его сюда приплетать, ибо на джаве в отличие од делфей, win-сервис, например, тоже не напишешь.

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

_>Я сейчас сижу на выделенке 128k с безлимитным трафиком. Но как программист я думаю о пользователях, которые и на модемах сидят и через CDMA с GPRS-ом ходят, платя ощутимые деньги за каждый скачанный мегабайт.

Сколько из них качает из интернета программы, требующие jre?
Если программа распространяется на диске, то зачем что-то качать?

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

_>Я сейчас сижу на выделенке 128k с безлимитным трафиком. Но как программист я думаю о пользователях, которые и на модемах сидят и через CDMA с GPRS-ом ходят, платя ощутимые деньги за каждый скачанный мегабайт.
_>Некоторым кажется что проблем с интернетом уже ни укого нет (особенно это сквозит во всем, что написанно столичными жителями), однако это не так. Реальность очень большого количества пользователей -- это модем на гнилой телефонной линии с повременнной оплатой или 10-20 центов за мегабайт при подключении локалкой или по воздуху.
О таких пользователях лучше "думать" по-другому: например, предлагать сервис доставки ПО на диске по почте. У меня вообще складывается картина, что не так уж плохо с инетом в России на самом деле. Из общения с иногородними знакомыми/френдами по MMOG/etc. вроде как получается, что кому нужен нормальный инет, тот найдет для себя приемлемый вариант, а кто сидит на гнилом диалапе и жалуется на жизнь, тот ССЗБ. Впрочем все это только ИМХИ, так что просьба особо не пинать и в профиль не заглядывать.

_>Не спорю. Но нижняя планка слишком высокая.
А по мне — не слишком. Впрочем, тут как с фломастерами.

MC>>2)Ресурсоемкость нескольких java-приложений не растет прямо пропорционально количеству этих приложений. Где-то мелькало на форуме — т.к в этом случае не бдет нескольких копий jre в памяти.
_>Это стандартная фича винды. Сегменты кода используются процессами совместно, однако данные либо copy-on-write, либо вообще отдельные. А т.к. большая часть виртуальной машины ИМХО данные (байт-код всяких библиотек и т.п., что с точки зрения процессора кодом не является), то каждая следующая копия отжирает пусть не 30, но 20-25 метров -- запросто (это то что сам видел). Конечно со стороны саой виртуальной машины тоже могут быть предприняты меры по совместному использованию всего что можно, может уже так и есть, но еще пару лет назад было так, как я написал выше.
Не только винды, а любой нормальной ОС. Лично я больше, чем уверен (на проверку сейчас свободного времени нет, хотя по-хорошему надо проверить), что шарится все, что только можно (в т.ч. байт-коды библиотек, которые ведь не меняются в ходе выполнения). Не совсем понятно, при чем тут точка зрения процессора, т.к. разделяемые страницы это механизм ОС, а не процессора. А ОС по барабану, что в зашаренных страницах находится. Также не совсем понятно, что именно Вы видели. Насколько я знаю, стандартные виндовые средства не позволяют определить, какую часть виртуального АП составляют разделяемые сраницы, а какую — "приватные". Так что понять, что копируется просто так не получится.

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

H>>Ни к чему страшному не приведет. Ну будут пустые вызовы IntfClear, и что?

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

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

H>>Я еще раз говорю, если ты работаешь с инструментом и не знаешь, как он работает -- ССЗБ. Обвинять компилятор в "интеллектуальных изысках", с твоей стороны, это расписываться в своей некомпетености. Не зная броду -- не лезь в воду.

K>Отключать их надо нах! Вот смотри сам — ты вроде бы знаешь об этих "изысках", тем не менее просмотрел Access Violation. Ну и кто тут после этого ССЗБ?

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

H>>Попытка по-громче хлопнуть дверью? Код не изменится, я это и без перекомпиляции знаю (но вообще в Delphi нет Debug/Release. под Release можно принимать компиляцию с отключенными проверками и debug info). Но это не проблема оптимизации. В реальном приложении, вполне, могут быть причины для такого кода (это не лучший способ, но тем не менее). Ручного управления подсчетом ссылок ни кто не запрещает.

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

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

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

H>>Чисто ремарка: Для переменного числа параметров есть константные массивы.

H>>

H>>Procedure SomeProc(Const Array Of const);
H>>Begin
H>>End;

H>>...

H>>SomeProc([1]);
H>>SomeProc([1, '1024']);
H>>SomeProc([1, '1024', Now]);
H>>SomeProc([1, '1024', Now, TStringList]);
H>>

G>Моя плакать "Const Array Of const" — убей себя об стену кто такое придумал.
G>А ведь паскаль создавался как язык для обучения с практически очевидной семантикой.

Мой косяк

Procedure SomeProc(Const AParams : Array Of Const);

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

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

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

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

kuj>>Ты не описывал реальную ситуацию а сослался на какие-то там форумы, где кто-кто кому-то когда-то рекомендовал "понатыкать GC.Collect".
H>Здесь
Какоето гадание на кофейной гуще.
Что там у него подвисает ХЗ.

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

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

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

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

kuj>>>Ты не описывал реальную ситуацию а сослался на какие-то там форумы, где кто-кто кому-то когда-то рекомендовал "понатыкать GC.Collect".
H>>Здесь
WH>Какоето гадание на кофейной гуще.
WH>Что там у него подвисает ХЗ.

Насколько я помню, с этим ХЗ так и не разобрались.

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

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

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

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

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

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

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

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

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

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

Лучше факты приведу, почему на .NET писать проще.
1)Нет утечек памяти.
2)Нет таких проблем с COM, как описано выше.
3)Нет проблем с организацией сетевого взаимодействия — не надо изучать "тяжелые" технологии типа DCOM, CORBA и др.
4)В .NET 3.5 практически не требуется писать DAL: типизированные запросы, проверяемые при компиляции; не надо писать SQL в программе; практически отсутсвие SQL-Injection уязвимостей
5)В .NET 3.5 очень лекая работа с XML (твой метод XmlUnescapeString даже писать не надо).

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

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

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

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

kuj>В .Net от множественного наследования сразу отказались.
По хорошему вобще нужно было отказаться от наследование реализаций.
Интерфейсы + миксины (чтобы код реюзать) и все типы финализированные.
Ибо нефиг разводить связанность на ровном месте.

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

DOO>>>Шаблон — это скорее развитый препроцессор. Препроцессор отношения к языку не имеет (что мне мешает взять и мои исходники на дельфях обработать препроцессором того же gcc?).
kuj>>Ой ли?
DOO>А что нет что ли? Ноги-то откуда растут? Понятно, что со временем это обрастало фичами, появилась обратная связь с компилятором и т.п. Но идея абсолютно "макросной" природы — готов поспорить, что изначально это и реализовывалось исключительно препроцессором.
Шаблоны в С++ настолько глубоко провязанны в систему типов что реализовать их препроцессором задачка не решаемая.
Вобще говоря С++ имеет очень мощьную систему типов.
Одно то что она теоритически полна по Тьрингу уже говонрит о многом.
На практике компиляторы очень сильно ограничивают глубину рекурсии да и медленный интерпритатор из компилятора С++ получается так что сильно не разойдешься.
Но даже на том что есть можно творить очень веселые и иногда даже практичные вещи.

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

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

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

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

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

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

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