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

WH>>>>Ну ты эта зайди в форум по С++ и спроси почему нельзя использовать void*...
A>>>То есть вопрос класса "goto или без goto"?
WH>>Да. Только я скажу по другому. Класса прямые руки или кривые.
DOO>Видимо в основе у нас лежат диаметрально противоположные школы, поскольку, если Вас послушать то Сшный union это вообще ужас какой-то который надо убрать подальше. А я не представлаю себе нормальной работы без возможности смотреть на память так как это угодно мне, а не компилятору!
Именно. Оно реально бывает нужно раз в два года.

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

WH>>Не гони. Выкачать один раз фреймворк если прога ДЕЙСТВИТЕЛЬНО нужна не проблема. А если надо разрабатывать с нуля прогу из дельфевой ниши то на шарпе дешевле и сильно.
DOO>Это получится как в известном ералаше: "Ты куда? А батарейки?". Очень плохой тон, когда программа требует для своей работы дополнительного софта.
Так можно договориться что под винду писать дурной тон.

A>>>Ну а кто сейчас заботится об оптимизации?
WH>>Я.
DOO>Что-то помнится, что рост exe-шника за счет шаблонов Вас не напугал.
Оптимизация по размеру давно ни кого не волнует(ну кроме кристальщиков). К томуже это очень не плохо ужимается.
DOO>Да и в чем Дельфи так не оптимально? Работает во многом даже быстрее.
Конкретней.

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

WH>Скорее C# окончательно добьет дельфю, а на счет нативных компиляторов это ты зря VC++7.1 практически полностью держит стандарт и оптимизитор у него весьма крутой.

Посмотри
http://www.osp.ru/news/soft/2003/09/15_01_print.htm
А JIT компиляторы одни и теже а в сгенерить IL код думаю не представляет особого труда .
Будут идти рука об руку и благодаря этому быстрее совершенствоваться.

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

S>>> Ну это ты загнул. Любая БД работает с нетипизированной памятью и почему-то большенству нравится, хотя скорость желает быть в десятки сотни и тысячи раз больше.
WH>>И в какой БД ты не типизированую пимять нашол?
S> Как по твоему обрабатываются записи таблицы являющиеся некой структурой ??????
И где ты нашол базу которая может в бинарных данных копаться? Засунуть в базу блоб это я еще понимаю но чтобы БАЗА в нем копалась это уже слишком.
хъ
S> И по поводу C# и Delphi.Net не рано ли говорить кто кого вытеснит????
Ну мне так думается что те кто на дельфе не писал не будут и на Delphi.Net писать, а учитывая что он опаздывает относительно С# и сильно то многие дельфисты уже перешли на шарп, а начатый проект переписывать... И вернутся ли они после пары лет шарпа на дельфю очень большой вопрос.

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

S>> Ну это ты загнул. Любая БД работает с нетипизированной памятью и почему-то большенству нравится, хотя скорость желает быть в десятки сотни и тысячи раз больше.
WH>И в какой БД ты не типизированую пимять нашол?
S>>Да и API написан на Asme и С где типизацией если и пахнет то ...
WH>И очень на прасно. Хотя в те времена когда это все писалось выбора небыло. К томуже это язаки низкого и среднего уровня, а мы про ЯВУ разговариваем.
S>> Зачем огульно бросаться словами??? Не прав.
WH>Нда? Смотри выделеное и скажи что из этого не нужно в ЯВУ? Разве что смартпоинтеры там где есть GC и то иногда хочется детерминированого управления жизнью объекта.

В Net есть возможность детерминированого управления жизнью объекта.
Inline не нужен т.к. JIT компилятор следит за возможностью вставки кода и при этом оптимизируя под конкретный процессор.
Про шаблоны уже прошелся.

S>> Время рассудит, но Delphi найдет свою нишу в Net да и у Delphi с C# намного больше общего чем у C# с С++, да и M$ помоему не особо горит желанием развивать Native компиляторы.
WH>Скорее C# окончательно добьет дельфю, а на счет нативных компиляторов это ты зря VC++7.1 практически полностью держит стандарт и оптимизитор у него весьма крутой.

WH>>>Вот только пока далеко не все лучшие идеи используются в шарпе.
S>> Например???? Шаблоны будут, что еще???
WH>Ну на эти шаблоны еще посмотреть надо. Еще надо подключение реализации. Короче я жду .NET 2 там будет видно.
WH>А сейчас все очень убого. Почти на уровне дельфи.

А вот на шаблонах ты зря зациклился. Шаблоны по сравнению со ссылками на определенные структуры (с применением виртуальных функций ли интерфесов) имеют премущество в скорости и полную типизацию, но при этом значительно выигрывают только при вызове быстрых функций. Кроме всего прочего полно вариантов, где должны хранится ссылки на различные объекты и здесь премущество шаблонов как корова языком слизала.
И при всей твоей нелюбви к Copy-Paste-Replace названные тобой аргументы (ошибки в базовом классе, неудобство) не выдерживают критики.

M>>А чем TList не устраивает? Религиозные причины?
WH>Ну ты эта зайди в форум по С++ и спроси почему нельзя использовать void*...

Ох уж мне эти суеверные старушки!

M>>>>Или крутизна шаблонов как раз и заключается в работе со встроенными типами?
WH>>>Не со встроеными, а со всеми.
M>>А какие проблемы применить TList ко всем типам?
WH>ТИПИЗАРОВАНОСТЬ такое слово знаешь?

Типизированость? Не знаю такого слова. Знаю "надёжность". Знаю "удобство". Знаю "скорость разработки". А типизированность ради типизированности — это какие-то эстетские категории.

M>>Хм. Ты хочешь сказать, что размер C-плюснутого кода в разы меньше Дельфийского? Что-то сомневаюсь.
WH>Повторюсь
...
WH>Такие помошники позволяют не задумоватся о исключениях, их использование прозрачно и не навязчиво, пишутся раз и навсегда.
WH>Слабо на дельфях написить такого помошника?

Что-то сложное. Я в C++ не силён, ты бы словами кратко сказал.

Видимо, этот помощник — это что-то универсальное и крутое. Только толку-то от всего этого хитроумия? Если мои классы должны действовать некоторым стандартным образом — я их в соответствующей иерархии и скомпоную. И сэкономлю вагон времени.

M>>Возможно, смартпойнтеры действительно помогают в разы — но только по сравнению с тем же C++ без смартпойнтеров. А в Дельфи и без них всё уже легко, аккуратно и прозрачно.

WH>Ой не надо на дельфе начинается try finaly hell.

Не вижу в этой конструкции ничего инфернального. Можно, конечно, придумать случай, где try/finally будет доставать. Но я лично такого практически не встречал.

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

WH>Во первых: Не путай С и С++ это разные языки. С++ с самого начала строго типизирован.

А посмотреть историю. C, Pascal, Object Pascal, C++, ??? (то чудо, которое некоторые называют "язык Дельфи", а на самом деле всё тот же OP. Ну, да, мощный RAD, IDE, ...) OP — он древний, кто-бы взял смелость его немного "подправить" в соответствии с накопленным опытом ООП... Ну а C++ так долго обсуждали, стандартизировали...

WH>Во врорых посмотри на дельфевые контейнеры...

Старые мы, древние, приходится использовать старые способы без поддержки на уровне языка.

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

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

WH>>>ТИПИЗАРОВАНОСТЬ такое слово знаешь? А можешь мне сказать какая структура данных лежат в основе TList?
A>>Знаем. В основе — массив указателей.
WH>Как гибко А если критична произвольная вставка/удаление? А если поиск? А если вставка/удаление с конца/начала?

А мы будем выбирать тогда, как реализовать. К услугам [коллекции, списки] (это для объектов), [динамические массивы, тип записи, вариантные массивы] для чего другого. Нужно очень быстро — возмём массивы и record.

A>>Для хранения списка чего угодно.
WH>Вот тут и начинаются проблемы.

Да нет. Опыт сказывается.

A>>Потому что поддержка вариантов пришла позже.
WH>А вот это совсем изврат

Даже соглашусь. Зачем их так в COM любят? Или зачем Дельфи позволяет передавать/получать от COM-объектов эти OleVariant и Variant? Нет бы динмассивы...

WH>И как можно добится автоматического уничтожкния при удалении из списка? А если объект надо хранить в нескольких списках?

Разумным проектированием. Перекрытием (перегрузкой, override) методов, написанием своих классов-оболочек.

WH> А если мне нужен не список, а КЧ дерево?

Написанием класса-оболочки, инкапсулирующего это дело. Возможно, он и есть, мне не было нужды в таком.

WH>Это у вас в паскакале надо долго и нудно извращаться, а потом долго и нудно отлаживать. В С++ все просто.
WH>...

Код опустил.

Нет, вы (к другим слушателям ) мне скажите! Нас обвиняют в смертном грехе — кликерстве, настройке свойств и поведения классов визуально. Более того, мы уши опускаем, согдашаясь, что да, виновны, уровень знаний падает, т.к. для кликанья много знать не надо.

И кто нас обвиняют? Эти Си и Си плюплюснутые (абсолютно беззлобно ), которые всё пишут ручками? Да где ручками, я вас (других) спрашиваю? У них теперь шаблоны и помощники. Так вот, это теперь у них уровень знаний падает, это они теперь сбанзали шаблон и вуалля. Я понимаю, шаблоны серьёзно облегчают и упрощают дело — ну и пришли они к тому же корыту, у которого мы стоИм уже сколько?... Они что, не видят как и сколько мы стоИм...

А теперь о стратегии: Борланд ушёл в RAD — и далеко зашёл, надо признать, что их продукты очень привлекательны и функциональны. А MS (просто представитель отдельный мира Cx) ответил на это шаблонами (или кто там ответил на самом деле...) — облегчением ручного труда, возможностью придавать функциональность шаблона произвольным (почти) данным. По терминологии OP хорошую библиотеку и её поддержку в языке и компиляторе предложил.

Ну, не так?

WH>Ты что думаешь я не понимаю try finaly? Напрасно. Просто я не хочу освобождать ресурсы РУЧКАМИ. В С++ за этим следит компилятор.

Вот, вот, вот! Та же лень. Думаешь, я не знаю про эти манипуляции с временем жизни и областью видимости. Знаю. Я даже знаю, какую цену я плачу за необходимость объявлять типы и переменные заранее. Я проникся этой идеей настолько, что она для меня также естественна, как дышать. Я не ошибусь с декларированием переменных и буду всегда знать, где их найти. Для проверки мне достаточно распечатать блок var, а на C# надо лазить по телу метода да собирать переменные по сусекам...


И мы ещё не затронули любимый мозоль — case sensetive.

WH>... и если мне не изменяет сколероз try finaly не ловит exit.

Правда? Надо будет покопаться что-ли...

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

WH>>> И всеравно против шарпа не тянет. Ну ни как.

Я признаю C# одним из желаемых вариантов развития OP. Дело за Борланд, что она предложит...

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

А то! И C/C++ тоже. А вот C# ни ногой...

WH> статическая линковка не хило утяжеляет ехешник что при частом обновлении софта выдет бОльшим траффиком.

Абсолютно согласен. Пример — тот же компактный KOL и "изврат", которым это достигнуто. А будь компилятор поумнее, выкусывай он и dynamic/virtual, создавай ресурсы по требованию — мы бы резко уменьшились в размерах.

WH>Не гони. Выкачать один раз фреймворк если прога ДЕЙСТВИТЕЛЬНО нужна не проблема. А если надо разрабатывать с нуля прогу из дельфевой ниши то на шарпе дешевле и сильно.

Не гоню. Пример — Янус. А о тех случаях, когда действительно что-то нужно... Так это кому нужно? Кто платит деньги, тот заказывает музыку. Не убедишь в правильности своего подхода, и этот уйдёт к другим или конкурентам.

A>>Ну а кто сейчас заботится об оптимизации?
WH>Я.

Ну вот, на двое будет. Время это, однако, отнимает.

WH>А это все к чему?

Пример жрущих приложений.

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

S>... А в том, что Net уже в скором времени займет главенствующие роли у меня лично сомнений не вызывает.

Как только выпустят такую винду, в которой фреймворк будет составной частью плюс она займёт нишу порядка 25-25% парка компьютеров.

И ещё Борланд с Майкрософт снова дружат.

Но насчёт полезности этого Net для программирования и применения компьютеров можно долго рассуждать. Это же чёртов новый взгляд на интерпретаторы при ощутимом росте мощностей и производительности компьютеров...

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

WH>>>Я бы сказал безнадежно уступает.
A>>Я бы нет. А почему, ответил в нашей беседе.
WH>Ни чего ты не ответил.

Я имел ввиду в других ветках. Мы тут в нескольких сразу беседу ведём, повторться не хотелось.

WH>В эту область применения пришол гораздо болие мощьный инструмент.

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

WH>На С++ компилятор

Не скромничай.

A>>Ещё одна. Почему французы упорно говорят на французском, немцы — на немецком, а мы на русском? Хотя, конечно, есть исключения...
WH>Это еще кривее. Разговорные языки по функциональности практически равноценны. Но С++ и делфи... ой не смешите мои тапочки.

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

A>>Даже писал в своё время.
WH>Ну дай посмотреть.

Не могу. Скрипт-язык в коммерческой программе. На BP.

A>>Даже в Сети найти можно и не одну.
WH>Линки пожалуйста.

Пока не пощупаешь — не поверишь? И само собой простенькие скромные скриптоподобные языки тебе не подойдут? Типа из RA Lib? Т.е. надо подать в студию как минимум реализацию клона C/C++, но на Паскале?...

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

WH>Ну мне так думается что те кто на дельфе не писал не будут и на Delphi.Net писать, а учитывая что он опаздывает относительно С# и сильно то многие дельфисты уже перешли на шарп, а начатый проект переписывать... И вернутся ли они после пары лет шарпа на дельфю очень большой вопрос.

Ну а как же хвалёная (заявленная) совместимость и независимость от языка. Просто дописываем блоки на C#, и используем их уже на Дельфи.

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

WH>>Нда? Смотри выделеное и скажи что из этого не нужно в ЯВУ? Разве что смартпоинтеры там где есть GC и то иногда хочется детерминированого управления жизнью объекта.
S> В Net есть возможность детерминированого управления жизнью объекта.
Ну знаю я по using жутко не удобно. К томуже Dispose может бросать исключения
S> Inline не нужен т.к. JIT компилятор следит за возможностью вставки кода и при этом оптимизируя под конкретный процессор.
А что это как не инлайн? А в дельфе инлайнов вобще нет.
S> Про шаблоны уже прошелся.
Где?

WH>>>>Вот только пока далеко не все лучшие идеи используются в шарпе.
S>>> Например???? Шаблоны будут, что еще???
WH>>Ну на эти шаблоны еще посмотреть надо. Еще надо подключение реализации. Короче я жду .NET 2 там будет видно.
WH>>А сейчас все очень убого. Почти на уровне дельфи.
S>А вот на шаблонах ты зря зациклился.
И что ты предлагаешь? Copy-Paste-Replace? Писать скрипты для генерации?
S>Шаблоны по сравнению со ссылками на определенные структуры (с применением виртуальных функций ли интерфесов) имеют премущество в скорости и полную типизацию, но при этом значительно выигрывают только при вызове быстрых функций.
S>Кроме всего прочего полно вариантов, где должны хранится ссылки на различные объекты и здесь премущество шаблонов как корова языком слизала.
S> И при всей твоей нелюбви к Copy-Paste-Replace названные тобой аргументы (ошибки в базовом классе, неудобство) не выдерживают критики.
Что ты тут нагнал вобще не понятно. Если ты про хранение потомков какого либо класса в одном контейнере то в С++ это делается на раз. Вот только генерацию такого контейнера берут на себя шаблоны.

typedef boost::shared_ptr<base> base_ptr;
std::list<base_ptr> base_list;
base_list.push_back(base_ptr(new derived));

Или используя мои смартпоинтеры и объекты со встроенным подсчетом ссылок

std::list<ref_t<base_ptr> > base_list;
base_list.push_back(new derived);

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

WH>>Как гибко А если критична произвольная вставка/удаление? А если поиск? А если вставка/удаление с конца/начала?
A>А мы будем выбирать тогда, как реализовать. К услугам [коллекции, списки] (это для объектов), [динамические массивы, тип записи, вариантные массивы] для чего другого. Нужно очень быстро — возмём массивы и record.
А я просто возму STL.

A>>>Для хранения списка чего угодно.
WH>>Вот тут и начинаются проблемы.
A>Да нет. Опыт сказывается.
А ну-ну.

A>>>Потому что поддержка вариантов пришла позже.
WH>>А вот это совсем изврат
A>Даже соглашусь. Зачем их так в COM любят? Или зачем Дельфи позволяет передавать/получать от COM-объектов эти OleVariant и Variant? Нет бы динмассивы...
А нафига их на уровень языка выводить было?

WH>>И как можно добится автоматического уничтожкния при удалении из списка? А если объект надо хранить в нескольких списках?
A>Разумным проектированием.

A>Перекрытием (перегрузкой, override) методов, написанием своих классов-оболочек.
А нафига это все писать если это может сделать компилятор?
У меня есть совершенно не зависимый шаблон коллекции.
Есть совершенно не зависимый умный указатель.
Есть совершенно не зависимый базовый класс.
И я просто создаю контейнер смартпоинтеров на мой класс. Зачем что-то еще писать?

WH>> А если мне нужен не список, а КЧ дерево?
A>Написанием класса-оболочки, инкапсулирующего это дело. Возможно, он и есть, мне не было нужды в таком.
Опять что-то писать

A>Нет, вы (к другим слушателям ) мне скажите! Нас обвиняют в смертном грехе — кликерстве, настройке свойств и поведения классов визуально. Более того, мы уши опускаем, согдашаясь, что да, виновны, уровень знаний падает, т.к. для кликанья много знать не надо.
Я хоть слово сказал что рисовать ГУЙ это плохо?
хъ
A>Ну, не так?
Нет не так. ГУЙ это в большинстве задачь ничтожно малая часть работы.

WH>>Ты что думаешь я не понимаю try finaly? Напрасно. Просто я не хочу освобождать ресурсы РУЧКАМИ. В С++ за этим следит компилятор.

A>Вот, вот, вот! Та же лень. Думаешь, я не знаю про эти манипуляции с временем жизни и областью видимости. Знаю. Я даже знаю, какую цену я плачу за необходимость объявлять типы и переменные заранее. Я проникся этой идеей настолько, что она для меня также естественна, как дышать. Я не ошибусь с декларированием переменных и буду всегда знать, где их найти. Для проверки мне достаточно распечатать блок var, а на C# надо лазить по телу метода да собирать переменные по сусекам...
Вопрос: А нафига искать переменные? У меня таких проблем нет. Ибо и дроблю функции строчек по 10 максимум(ну за ооочень редким исключением). Ах да я же забыл в дельфе нет инлайнов и дробление сказывается на производительности...

A>И мы ещё не затронули любимый мозоль — case sensetive.
Чесное слово не мой.

WH>>... и если мне не изменяет сколероз try finaly не ловит exit.
A>Правда? Надо будет покопаться что-ли...
Ну покопайся. А то мне дельфи ставить не охота.

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

WH>>Ну ты эта зайди в форум по С++ и спроси почему нельзя использовать void*...
M>Ох уж мне эти суеверные старушки!
От старушки слышу.

M>Типизированость? Не знаю такого слова. Знаю "надёжность". Знаю "удобство". Знаю "скорость разработки". А типизированность ради типизированности — это какие-то эстетские категории.
Нет типизированиесть нежна для повышения надежности, удобства и корости разработки.

M>Что-то сложное. Я в C++ не силён, ты бы словами кратко сказал.
http://www.rsdn.ru/forum/Message.aspx?mid=383399&only=1

Автор: WolfHound
Дата: 15.09.03

M>Видимо, этот помощник — это что-то универсальное и крутое. Только толку-то от всего этого хитроумия? Если мои классы должны действовать некоторым стандартным образом — я их в соответствующей иерархии и скомпоную. И сэкономлю вагон времени.
ХА. Я же сказал это ПОМОШНИК он делает грязную работу.

WH>>Ой не надо на дельфе начинается try finaly hell.
M>Не вижу в этой конструкции ничего инфернального. Можно, конечно, придумать случай, где try/finally будет доставать. Но я лично такого практически не встречал.
Сам факт его существования достает. Зачем он нужен? Я не понимаю. (вернее зачем это надо в дельфе я знаю) В С++ этого нет вобще и никто не жалеет об этом.

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

A>Пока не пощупаешь — не поверишь? И само собой простенькие скромные скриптоподобные языки тебе не подойдут? Типа из RA Lib? Т.е. надо подать в студию как минимум реализацию клона C/C++, но на Паскале?...
Ни фига ты не понял. С++ САМ превращается в другие язаки. boost::spirit превращает его в язык для записи EBNF грамматики. Дельфя на такое не спасобна.

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

DOO>Очень часто в потверждение превосходства С++(а именно VC++), над Дельфи люди начинают сравнивать его(С++) с BCB. Я этим BCB в жизни не пользовался и насколько понял не зря, поскольку, видимо, это хуже даже Visual Studio.
Ну это ты зря. VS7 неплохой продукт.

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

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

WH>>>Скорее C# окончательно добьет дельфю, а на счет нативных компиляторов это ты зря VC++7.1 практически полностью держит стандарт и оптимизитор у него весьма крутой.
FWP>>C# и Delphi — это близнецы братья (или сестры?)
WH>Общего у них только то что редактор форм немного похож.
Ну если ты так говоришь, то видимо Delphi ты и вправду забыл или не знал или знал какую-либо древнюю версию.

FWP>>Какое самомнение! Ну почти господь бог.
WH> А что не похож?

FWP>>А хотя бы задумался с чего бы это в Java уже почти 8 лет нет шаблонов.
WH>Ибо реализовать их нАмного сложнее чем кажется.
Вот и я о том же.
FWP>>Разговоры идут, планы ввода есть. А реализаций нет. И в C# тож самое. Видно не все так просто с надежностью.
WH>С надежностью то как раз все хорошо, а вот реализовать это...
... без ущерба надежности!
FWP>>А ведь для разработки именно НАДЕЖНЫХ приложений создавались эти среды.
WH>А это тут причем?
А при том, что из языков были сознательно удалены заманчивые, но потенциально опасные возможности.
FWP>>А вот интересно! После ввода шаблонов в С# куда они будут отнесены: к безопасному программированию или нет?
WH>К безопасному. К томуже в шарпе шаблоны не будут обладать такойже мощью как в С++.
Вот и я о том же.

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

FWP>>>C# и Delphi — это близнецы братья (или сестры?)
WH>>Общего у них только то что редактор форм немного похож.
FWP>Ну если ты так говоришь, то видимо Delphi ты и вправду забыл или не знал или знал какую-либо древнюю версию.
Ну и что же у них общего? Если заглянешь шарпу под капот то сам увидишь что ни чего общего.

FWP>>>Разговоры идут, планы ввода есть. А реализаций нет. И в C# тож самое. Видно не все так просто с надежностью.
WH>>С надежностью то как раз все хорошо, а вот реализовать это...
FWP>... без ущерба надежности!
Это где это ты ущерб надежности нашол? Мне очень интересно.

FWP>>>А ведь для разработки именно НАДЕЖНЫХ приложений создавались эти среды.
WH>>А это тут причем?
FWP>А при том, что из языков были сознательно удалены заманчивые, но потенциально опасные возможности.
А шаблоны тут причем?

WH>>К безопасному. К томуже в шарпе шаблоны не будут обладать такойже мощью как в С++.
FWP>Вот и я о том же.
Это о том что опять придется извращаться для того что в С++ делалось на раз и без проблем?

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

WH>Нет не так. ГУЙ это в большинстве задачь ничтожно малая часть работы.
Это в Delphi ничтожно малая часть. Потому ручная работа сведена к минимуму. А в C++ все ручками, да ручками

WH>>>Ты что думаешь я не понимаю try finaly? Напрасно. Просто я не хочу освобождать ресурсы РУЧКАМИ. В С++ за этим следит компилятор.
И он в некотрых случаях может принять неправильное решение. И следить за этим надо и обходить такие ситуации вручную. Да и надежности это не добавляет.