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

Oxy>Интересно, а где модератор? Спит что ли.

да в командировке он. т.е. считай в отпуске, бо связи практически нет.

Oxy>Такие религиозные войны надо прекращать в зародыше. Они, ИМХО, не несут никакой смысловой нагрузки и только засоряют форум. Ну поумнчают здесь любители этого дела, померцают гранями, а толку? Никто никого не убедит и не переубедит.

для этого форум специательный сделали. голосуйте и переносите.

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

S>> В паскале пришлось бы делать с твоей аналогией
S>>cmp.add(@test.f1,TypeOf(test.f1));
WH>И все в рантайме, а если новый тип появится?
а все будет нормально... RTTI автоматом подгрузится..
S>>Забыл как в RTTI TypeOf, но на C# прямо из типа я могу получить всю информацию о записи и соотвественно прописать все филды.
WH>.НЕТ это отдельная история там вобще все подругому а тут мы разговариваем не о нем, а о C++ и Delphi
Ну... заметим, что как было верно замечено — очень много идей в .Net взято из Delphi.
к тому же появился Delphi .Net... все, конец C++ пришел

S>> Но как быть если у тебя не известна структура test на этапе компиляции.
WH>Надо знать КОНКРТНЫЙ формат информации о типах полей. К томуже в реальной жизни в 99% случаев все извесно компилятору
А вот нифига... возьми саму среду Delphi... при ее компиляции не было известно про всякие "3rd party components" но они нормально инсталлируются и работают... и написать такую оболочку на Delphi не составляет никакого особого труда. А вот написание компонентно ориентированых приложений на C++ — это геморой... даже на C++ Builder, который поддерживается лишь для того, чтобы фанаты C++ имели-таки возможность работать с нормальной компонентно ориентированой средой разработки...
а глючит.... глючит потому, что и так невозможную вешь сделали...

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

C> Кстати, кривая работа при нестандартных настройках видео (Large fonts, например) — классическая болезнь дельфийских прог, а иногда вот и самой делфийской IDE...
Ага... ты еще скажи, что MS'ные проги ей не болеют.... запусти хоть Office 2000 в крупных шрифтах и зайди в какой-нить диалог — куча удовольчтвия гарантирована...

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

WH>Здравствуйте, DOOM, Вы писали:
DOO>>Ну конечно. А в VS я ее жду секунд 6-8. За это время успеваешь расслабиться
WH>ЧАВО???? Она мнгновенно выскакивает.
ну не знаю... у меня в Delphi оно взлетает за 0 секунд...

Здравствуйте, Евгений Коробко, Вы писали:

ЕК>Нет, я с дельфями завязал. Сначала кажется, что удобно. VCL хороша, работа с БД, IDE... Но потом это всё вылазит боком.
ЕК>Во-первых, тормоза. Как в работе с БД, так и просто в перерисовке окон.

Про окна это вообще. Держите меня.

ЕК>Во-вторых, нет STL и вообще типизированных контейнеров
ЕК>В-третьих, всё API и все библиотеки на C.
ЕК>В-четвёртых, нет контроля над ситуацией.

ЕК>Год назад с дуру решил проект делать на Delphi. Готов себя тогдашего убить за дурость. Если бы писал на C++ & WinAPI, всё было бы
ЕК>уже готово!!!

У, батенька, складывается впечатление, что вы залезли в коробку с эфективными и удобными инструментами, не прочитали инструкции и хотели сотворить чудо. А чудо без знаний невозможно, какой инструмент не бери. Не получилось — все отстой. Разобраться сначала было надо. Но видать вам этого не понять. С таким подходом никакой проект не получится. И глючить все будет, и окна будут долго перерисовываться

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

DOO>Здравствуйте, Дарней, Вы писали:

Д>>Какой другой смысл?

DOO>(char *)name — указатель на байт Занимает 4-ре байта...

Да ну?! А если не 4, тогда что делать? А если вообще категорически все равно, сколько там занимает указатель, как и то, что он вообще из себя представляет, а просто нужно привести name к такому-то другому типу — при передаче его в качестве параметра, например?

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

DOO>....Примечание: сразу говорю, что в Дельфи нет макросов, перегрузки операторов и шаблонов, но это все очень, на мой взгляд, сомнительные вещи без которых вполне можно обойтись(макрос меняется inline функцией и результат одинаковый, шаблон вообще автоматизированный Ctrl+Ins,Shift+Ins, а потому плох в использовании, поскольку увеличивает размер конечного продукта).

Не совсем в поддержку плюсов. Хотел обратить ваше внимание на недостаток вашего подхода, ведь хорошие програмисты в первую очередь пытаются избавится от дублирования кода, метод "Ctrl+Ins" плох не только тем что код сильно разбухает, а в значительной мере ещё тем что становится плохо управляемым, сложно контролировать и синхронизировать измененим, а то что шаблоны вещь хорошая и нужная признают сейчас многие, в .NET и Java их собираются ввести. Другое дело, то что шаблоны в плюсах реализированы достаточно сложно и их освоить не каждому под силу, а отсюда растут ноги у мифов о том что щаблоны это вредно.

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

H_D>а глючит.... глючит потому, что и так невозможную вешь сделали...

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

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

S> А какже memcopy. Она на чистом С++ написана. Огромное количество низкоуровневых функций на асме.

memcopy входит в рантайм, эта и ей подобные функции используются в основном для совместимости с програмами на С, и если посмотриш на код генерируемый Делфами то думаю ты получиш код почти аналогичный коду что даёт ета функция, и его судя по копирайтам писала Intel, а их учить как затачивать код под свои камни думаю никто не будет.
Для ООП всё же лучше использовать std::copy, если ты конечно не пишеш драйвера, std::copy будет сторого типизированой и даже если внутри она и будет реализована на базе memcopy тебя это не должно волновать, так как это библиотечная функция, ты ведь не часто лезеш и правиш VCL надеюсь, на той же Делфи тоже предостаточно будет низкоуровневого и legacy кода(Graph,Dos), В VCL внутри тоже есть вызовы низкоуровневых функций.
Ну и наконец если тебе нужна скорость, то ни в Делфе ни в плюсах без асмовых вставок не обойтись, а для других целей их и не применяют почти, разве что драйвера писать и с железом работать.

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

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


M>>Конечно, есть люди, которым по долгу службы приходится на ассемблере писать. Слава богу, я к таким не принадлежу.

DOO>Повреь мне зря... Самый красивый и понятный язык(когда макросами не перегружен по самое нехочу).

Ну вот попрограмируй под современные DSP или микроконтролеры, и раскажеш про красивый и понятный,то ета команда за этой идти не может изза особенностей реализации конвеера, то код не помещается в сегмент кода, а всё изза того что дурацкий компилер сравнение делает 3-юмя камандами, когда можна одной, а ещё производители имеют привычку каждых два года менять номенклатуру и выпускать сырые камни, а потом выпускают кучу еррат, ой извините у нас такой глюк, а посему обходной манёвр продерните нитку через задний проход и втыкните в иголку, хорошо если ещё еррату выпустят, а то могут умолчать и признаться только в частном розговоре да у нас есть проблемы, и о плюсах я пока только мечтаю, да что там говорить дайте мне нормальный ANSI C99, а документацию писали дэбилы с образованием в 6-ть класов и менеджэры по продажам изза чего выяснить технические поробности можно только методом или научного втыка, что иногда опасно кристал сожжёш, или контактируя с разработчиками и такими же как ты нещасными.

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

G>Так что, как говорил товарищ Сталин: "Факты — вещь упрямая". То есть оказывается не нужны людям свойства, не нужны им быстрые кнопочки на формах, не нужны им самопальные реализации контейнеров через наследование и код через Копи/Паст. А нужны им шаблоны, нужен им монстроидальный синтаксис, нужна им, гадам, перегрузка операторов. И готовы они потерпеть лишнее время, так как как ни крути, а на сях прожект сложнее разработать и реализовать (может потому что задачи сложнее). И готовы эти гады (работодатели всмысле) в 2 раза больше денег платить за все эти сишные неудобства, и хотят они их почти в 5 раза больше и сильнее чем все TContainer"ы и ТПрограммер компоненты вместе взятые. Так что королевство дельфей может сушить сухари. Где то я там видел фразу типа "С++ и дельфи — умирающие направления". Ага, жестко они умирают. А лохи эти, из котор программерских — они ж лапти, у них денег куры не клюют — вот и платят специалистам по тупиковым направлениеям по 3000 уе.
G>Вот такие дела
Ну ты несколько не прав... есть еще набор стереотипов типа: C++ — круто, Pascal — отстой... Java — круто... .Net — да так... лабудень... Oracle — супер рулез! MSSQL — поделка наколеночная для неудачников.... и так далее...
стереотипов море... и стереотипы рулят мышлением большинства из неас...

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

DOO>[...] Причем видел я и такой идиолтизм как написание достаточного громоздского интерфейса средствами чистого API. Больно было смотреть как маятся люди, делая тривиальные вещи, стоит только начать использовать VCL.

Я видел ещё веселее — написание на API контролов (типа тулбаров, менюшек, гридов etc) на VB6!!! Блин, до этого мне даже в голову не приходило, что на VB можно вешать хуки, обрабатывать сообытия типа всяких WM_INITMENUPOPUP, WM_MEASUREITEM, WM_DRAWITEM etc. Я вам скажу — вот это всем извратам изврат!

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

DOO>>>В одной книжке я встретил правильную фразу, дословно не помню, что-то вроде, что существует объектно ориентированное пргораммирование и шаблонное программирование.
DOO>>>Очень разные вещи, поскольку в STL нет никакого наследования, например.
Настоятельно рекомендую посмотреть на ATL и WTL... В действительности шаблоны и наследование никак абсолютно друг дружке не мешают.

DOO>

DOO>template <class T>
DOO>class CTemplateClass
DOO>{
DOO>  T member;
DOO>}
DOO>class CSon1 : public CTemplateClass<class1>
DOO>{
DOO>}
DOO>class CSon2 : public CTemplateClass<class2>
DOO>

DOO>И что в итоге получается? CSon1 и CSon2 сложно называть детьми CTemplateClass.
А вот уже от незнания языка...


J>>Так со смартпоинтерами можно не бояться, что забудешь освободить память.
DOO>Волков бояться в лес не ходить
Береженого Бог бережет.

DOO>Мне на работе сказали WTL — хорошо, но MS не поддерживает. Поэтому пиши на MFC.
MFC, вообщем-то, уже тоже не будет развиваться. Теперь только .NET

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

C> А забыть вызвать деструктор в случае "ветвистого" кода, например?
Это еще что... А вот ежели исключение где сгенерируется... расширения вроде __finally не всегда ведь спасут да и забыть проще простого плюс код растет непомерно от всех этих __finally... А вот интеллектуальные указатели помогут... К тому же они еще и о владении позаботятся — ссылки подсчитают... Короче, ни один нормальный проект сейчас без таких патернов на C++ не пишется...

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

WH>В программах на С++ классы делятся на
Ага, размножаются почкованием...

Сам придумал? Или может в книге какой прочитал? Может в какой-то тайной книге для избранных от Страуструпа?

WH>1)Помошники(как правило шаблоны)
WH>Делают всю грязную работу типа захват/освобождение ресурса причем полностью автоматически
WH>В подовляющем большинстве на дельфе не реализуемы
WH>2)Синглетоны
Синглтон — всего-лишь один из патернов. При чем далеко не самый значительный.
Smartpointer` или там object factory на мой взгляд куда полезнее...
WH>3)Логика(самые многочисленые)

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

DOO>Сразу некоторые ответы на вопросы, возникшие в этом

Автор: DOOM
Дата: 26.08.03

топике.

DOO>Дельфи действительно швыряет EAbstractError при попытке создания экземпляра абстрактного класса, и это правильно, что в именно в run-time, поскольку пусть у меня следующая иерархия классов:
DOO>TAbstractClass = class ....
DOO>TClass1 = class(TAbstractClass)...
DOO>TClass2 = class(TAbstractClass)...
DOO>Я хочу создать массив, в котором будут и TClass1 и TClass2 — понятно, что надо создать массив TAbstractClass. В С это можно решить только используя указатели на класс, а в Дельфи есть только указатели на класс, просто это все неявно. И при их организации ООП это единственный способ. Поэтому-то мне и интересно как это сделано в С. К сожалению сейчас у меня нет времени покопаться в VS-ке и погладет как на asm'е все это выглядит.

DOO>По поводу того, что у Дельфи меньше возможностей... Приведите хоть один пример, который нельзя реализовать на Дельфи, но можно на C++. Примечание: сразу говорю, что в Дельфи нет макросов, перегрузки операторов и шаблонов, но это все очень, на мой взгляд, сомнительные вещи без которых вполне можно обойтись(макрос меняется inline функцией и результат одинаковый, шаблон вообще автоматизированный Ctrl+Ins,Shift+Ins, а потому плох в использовании, поскольку увеличивает размер конечного продукта).


DOO>По поводу IDE — тут по-моему вопросов нет. В дельфи оно факт удобнее.

DOO>По поводу библиотек — MFC vs VCL. VCL — действительно объектная библиотека, в которой обработка событий инкапсулированна в объект, а не реализуется посредством вставляемых куда-то макросов и т.п.

DOO>Теперь ваща очередь...


В Delphi очень не удобно то что не существует стековых объектов класса. Т. е для того чтобы использовать класс его нужно создать (.Create) а затем удалить (.Free. Объекты класса существуют как указатели. Очень много совершенно ненужных ключевых слов типа override, overload, reintroduce, (virtual, dinamic).Неудобно что нет перегрузки операторов и шаюлонов.

Однако есть удобная вещь — properties и то что можно очень быстро слепить среней сложности проекты

Здравствуйте, Аноним, Вы писали:

А>В Delphi очень не удобно то что не существует стековых объектов класса. Т. е для того чтобы использовать класс его нужно создать (.Create) а затем удалить (.Free.

И это мне видится очень логично. Есть класс — это как некий шаблон. И есть экземпляр класса — объект построенный по этому шаблону. И да, его нужно создавать и уничтожать, что совершенно естественно. Создал объект — вот он, делай с ним что хочешь. Не нужен — уничтожай его и освобождай пямять. Все вполне логично, а главное ты имеешь полный контроль над кодом так как явно создаешь или уничтожаешь объекты. Иногда это очень даже помогает.

А>Объекты класса существуют как указатели.

Объекты класса существуют как объекты. И есть указатели на эти объекты. Доступ к объекту совершается через указатель. На один объект могут указывать множество указателей. Что тут непонятного, неудобного или нелогичного?

А>Очень много совершенно ненужных ключевых слов типа override, overload, reintroduce, (virtual, dinamic).

Ну это все субъективно. Мне, например, так не кажется. Как и многим другим программерам.
Если бы ты хорошо разобрался со всем этим, то, ИМХО, и тебе бы тоже так не казалось.

А>Неудобно что нет перегрузки операторов и шаюлонов.

Ну чего нет того нет. Полностью согласен. Но лично я от этого не страдаю.

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

Oxy>Здравствуйте, Аноним, Вы писали:

А>>В Delphi очень не удобно то что не существует стековых объектов класса. Т. е для того чтобы использовать класс его нужно создать (.Create) а затем удалить (.Free.

Oxy>И это мне видится очень логично. Есть класс — это как некий шаблон. И есть экземпляр класса — объект построенный по этому шаблону. И да, его нужно создавать и уничтожать, что совершенно естественно. Создал объект — вот он, делай с ним что хочешь. Не нужен — уничтожай его и освобождай пямять. Все вполне логично, а главное ты имеешь полный контроль над кодом так как явно создаешь или уничтожаешь объекты. Иногда это очень даже помогает.

А>>Объекты класса существуют как указатели.

Oxy>Объекты класса существуют как объекты. И есть указатели на эти объекты. Доступ к объекту совершается через указатель. На один объект могут указывать множество указателей. Что тут непонятного, неудобного или нелогичного?

А>>Очень много совершенно ненужных ключевых слов типа override, overload, reintroduce, (virtual, dinamic).

Oxy>Ну это все субъективно. Мне, например, так не кажется. Как и многим другим программерам.
Oxy>Если бы ты хорошо разобрался со всем этим, то, ИМХО, и тебе бы тоже так не казалось.

А>>Неудобно что нет перегрузки операторов и шаюлонов.

Oxy>Ну чего нет того нет. Полностью согласен. Но лично я от этого не страдаю.

Стековые объекты испоьзуются в области видимости и уничтожаются при выходе из нее. Память выделяется гораздо быстрее чем при (.Create или new в С++). Тем более память может вообще не выделяться если это не нужно напрмер в условиях. Это конечно детали но мне в Delphi этот момент не нравится

Еще по поводу библиотеки типов в Delphi. Вроде визуально удобно но много глюков. Если знаешь IDL гораздо легче работать в текстовов редакторе. Это мое мнение. не зняю может я ошибаюсь

Здравствуйте, Аноним, Вы писали:

А>Стековые объекты испоьзуются в области видимости и уничтожаются при выходе из нее. Память выделяется гораздо быстрее чем при (.Create или new в С++). Тем более память может вообще не выделяться если это не нужно напрмер в условиях. Это конечно детали но мне в Delphi этот момент не нравится

Просто в Delphi понятие области видимости намного уже чем в С++, так как все определения даются в начале модуля или процедуры/ф-ции. Кстати мне такая структуированнсть кода больше нравится чем возможность определять переменные и т.п. в любом месте кода. Хотя все зависит от привычки.

А>Еще по поводу библиотеки типов в Delphi. Вроде визуально удобно но много глюков. Если знаешь IDL гораздо легче работать в текстовов редакторе. Это мое мнение. не зняю может я ошибаюсь

Что ты подразумеваешь под "библиотекой типов"?
Если ты имеешь в виду VCL, то она даже очень удобна. И глюков в ней не так уж и много. А уж свою основную ф-ию она выполняет на все 100%. Такого удобства проэктирования интерфейса как с помощью VCL я вообще нигде не встречал. Причем для нее написано великое множество расширений на все случаи жизни. Причем подавляющее большинство их полностью бесплатно и в исходных кодах.
Фактически что бы создать дружественный и красивый интерфейс требуется раз в 10 меньше времени чем в VC++, хотя он гордо называется Visual

Здравствуйте, Аноним, Вы писали:


A>>Как я с тобой согласен! И в C# подобная дребедень. using немного спасает ситуацию, но только в самых простых случаях. Особенно меня прикалывает тот факт, что IDispose.Dispose() может выбросить исключение. После этого я не могу понять как на C# можно писать надежные программы.

А>Вот-вот. Тут народ что-то рассказывает про отсутствие в C# шаблонов, перегрузки некоторых операторов и прочей лабудени. В то время как (на мой взгляд) самый реальный шаг назад — отсутствие надёжного механизма детерминированного освобождения ресурсов. using нифига ситуацию не спасает, т. к.:
Во-первых, rtfm unsafe. Во-вторых, детерминированное освобождение ресурсов требуется крайне редко, а вот сборщик муссора фактически исключаяет вероятность появления утечек памяти. А using — это всего-лишь конструкция try-finally с вызовом dispose
А>1) Каждый раз при создании объекта надо проверять поддержку IDisposable = лезть в MSDN. (Все классы не запомнишь.)
Не каждый раз. Ну что за дурная привычка? using нужен только для классов, использующих какой-либо системный ресурс отличный от памяти (например, файл). В остальных случаях сборщик муссора сам позаботится об уничтожении объектов.
А>2) Попытки систематически использовать using приводят к конструкциям вида:
А>using(....) {
А> using(...) {
А> using(...) {
А вот это уже от незнания языка. RTFM using, а именно возможность использовать using для множества объектов.
А>3) Dispose() может выбрасывать исключения
Деструктор и.у. тоже не застрахован от исключений.
А>4) Рекомендательный характер вызова Dispose(). Поубивал бы за это . Dispose() в половине случаев оставляется самой FCL на попечение Finalize, который, разумеется, вызывается, когда мало памяти, а не того ресурса, которого не хватает.
RTFM, о работе сборщика муссора, например, в книге Рихтера.