Delphi vs C++ , Часть 1

Цитата Alex Forth @ 22.10.07, 11:19

А затем, что свои высказывания надо уметь доказывать!

Да, кстати. А зачем я должен перечислять ваши проблемы? Достаточно факта, что они есть. Вроде же я видел сообщения "помогите собрать что-то под что-то"?
Почему я смотрю, например, на Firebird и вижу там перечень ОС? А под остальные - есть беты или прошлые версии, а новых нет? Если все так безоблачно, и ваши программы не зависят от платформы, и вы не видите разницы, то откуда беты? Ведь должно быть достаточно перекомпилировать?

Я то-то не понял...

Цитата Romkin @ 22.10.07, 14:08

Да, кстати. А зачем я должен перечислять ваши проблемы? Достаточно факта, что они есть.

Ну да, а в Delphi проблем не возникает по определению. Смотрим в раздел форума Delphi и не видим там ни одной темы - о боже, да это же настолько прекрасный язык, что ни у кого с ним никаких проблем не возникает!

Цитата Romkin @ 22.10.07, 14:08

Вроде же я видел сообщения "помогите собрать что-то под что-то"?

Мы что, в ответе за то, что кто-то не смог собрать что-то под что-то?

Цитата Romkin @ 22.10.07, 14:08

Почему я смотрю, например, на Firebird и вижу там перечень ОС? А под остальные - есть беты или прошлые версии, а новых нет?

Или может быть мы в ответе за разработчиков Firebird?
Или может быть в данной дискуссии присутствуют разработчики Firebird?

Цитата Romkin @ 22.10.07, 14:08

Если все так безоблачно, и ваши программы не зависят от платформы, и вы не видите разницы, то откуда беты? Ведь должно быть достаточно перекомпилировать?

Вот у разработчиков Firebird и спроси.

Ты к чему всё это? Опять воздух погонять? Опять аргументы, которые можно почти дословно перевести в ущерб Delphi? Не надоело ещё?

Добавлено 22.10.07, 14:19
IMHO, твоя проблема в том, что ты ставишь Delphi во главу угла и не видишь у Delphi никаких недостатков, и делаешь из этого какие-то выводы об ущербности С++, даже не задумавшись о том, что те же самые "недостатки" есть и в Delphi.

Сообщение отредактировано: archimed7592 - 22.10.07, 14:19

Цитата

Да, кстати. А зачем я должен перечислять ваши проблемы? Достаточно факта, что они есть.

Romkin, их НЕТ! Вот это факт.

Цитата Romkin @ 22.10.07, 14:08

Да, кстати. А зачем я должен перечислять ваши проблемы? Достаточно факта, что они есть.

а ты вообще знаешь что они есть ?

Цитата Romkin @ 22.10.07, 11:34

стоимость разработки на С++ все-таки высокая будет.

почему она дороже чем дельфи ?

Цитата

почему она дороже чем дельфи ?

несколько аспектов.

1) реально - более сложный язык. шаблоны, перегрузка, виртуальность, и пр. муть;
2) возможность захватить и более сложные задачи, ориентированные на в первую очередь производительность;
3) неоднородность компиляторов и сред разработки. скажем, Dev C++ - это тоже C++, при этом весьма неудобная. А ещё возможна поддержка всяких реликтовых компиляторов. ну и не только реликтовых.

Цитата Бобёр @ 22.10.07, 17:55

1) реально - более сложный язык. шаблоны, перегрузка, виртуальность, и пр. муть;

для написания реального проекта не обязательно использовать все фенечки.
или раз она есть ее надо обязательно использовать ?

Цитата Бобёр @ 22.10.07, 17:55

2) возможность захватить и более сложные задачи, ориентированные на в первую очередь производительность;

не понял смысла
возможность захватить более сложные задачи ?
а зачем их захватывать если они не нужны ?
прошу пояснить

Цитата Бобёр @ 22.10.07, 17:55

3) неоднородность компиляторов и сред разработки. скажем, Dev C++ - это тоже C++, при этом весьма неудобная. А ещё возможна поддержка всяких реликтовых компиляторов. ну и не только реликтовых.

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

Цитата

А ещё возможна поддержка всяких реликтовых компиляторов

.
а как дельфисты решают такие проблемы (если они конечно возникают, я, честно, не видел такого не разу на С/С++)?

Сообщение отредактировано: impik777 - 22.10.07, 18:40

Цитата Alex Forth @ 22.10.07, 15:22

Romkin, их НЕТ! Вот это факт.

Тогда чем объяснить тот факт, что Firebird 2 до сих пор не компилирован на все платформы для Firebird 1.5 хотя бы?

Цитата Romkin @ 22.10.07, 10:57

Такой платформой могла бы стать COM, но увы.

Почему бы не остановиться на CORBА? Вполне себе мультиплатформенный стандарт... Но ведь на Dephi его нет...
Да и вообще, странноватый подход. Если бы то, что предлагает Delphi в плане стыковки с другими приложениями - было бы именно от Delphi, то и вопросов бы не возникало. А так, получается, что все сводится к тому: "ах как круто на дельфях COM/ActiveX-компоненты писать! Как они замечательно со всем стыкуются!!!". И как-то забывается, что это, в первую очередь, технологии Microsoft, к Delphi отношения имеющие опосредованное. Вот билдер - тот да. Я, например, вполне мог соорудить на нем гуевую библиотеку и прикрутить ее к приложению, разрабатываемому (тогда) в Borland C++ 5.02 с использованием OWL. Чем, собственно, в те славные времена и пользовался.
А вот как мне без славных COM и ActiveX состыковать библиотеку на Delphi с приложением на С++, или Java, или С# - это баааааальшой вопрос. И (если такая стыковка таки осуществится), каким лесом пойдут классы, интерфейсы, проперти, хелперы и проч. проч. проч.?

Цитата

Почему бы не остановиться на CORBА? Вполне себе мультиплатформенный стандарт... Но ведь на Dephi его нет...

Помойму есть.

Чтож, пожалуй возму слова обратно, про то что "на C++ не сделано, и не сделать ничего хорошего"
Работаю сейчас с проектом BOCHS, и мона сказать в восторге

Цитата Бобёр

1) реально - более сложный язык. шаблоны, перегрузка, виртуальность, и пр. муть;
2) возможность захватить и более сложные задачи, ориентированные на в первую очередь производительность
3) неоднородность компиляторов и сред разработки. скажем, Dev C++ - это тоже C++, при этом весьма неудобная. А ещё возможна поддержка всяких реликтовых компиляторов. ну и не только реликтовых.

1) Напрямую зависит от разработчиков, благо что проффесионалы, практически не используют всякого рода "шаблоны" (на расхваливание которых "приплюснутые" израсходовали много пены, толком ничего не доказав в практическом применении), обходясь базовым функционалом C++.
2) Задачи программного кода в проекте BOCHS, во истину потрясающие.. Однако реализованый алгоритм интерпретации x86/x86_64, отличаеться низким быстродействием которой не помогают активация в C++ компиляторе различных фич быстродействия (максимум быстродействия, fastcall вызовы), +перепробованая куча компилеров (VC5/6/NET2003/INTEL)
3) Кстати мне нравиться Ms Developer Studo 97.. Интересно M$ её продают или я могу ее пользовать, без зазрения совести, не отчисляя тугриков мсявкам? А тож за время компиляния обём занимания оперативной памяти не превысил 50метров.

Цитата Flex Ferrum

Если бы то, что предлагает Delphi в плане стыковки с другими приложениями - было бы именно от Delphi, то и вопросов бы не возникало

А что Delphi, как нативный я/п предлагает уровень каких-либо костылей, которых валом в том же .net? Нет... В том же проекте BOCHS, вызываеться библиотека "debug.dll" отладчика, который забаццан на Delphi, без VCL...

antigen, а почему ELF с какимто элементарным кодом парсера весит полмега ?(хоть и для ARM, но догадываюсь что такой обьем выйдет, для x86 тоже).. Вон ексешка, проекта обьемом 14мегабайт текста, занимет в откомпиленом виде, чуть более метра... Причем, никаких "левых хитов" в С++ либы, не делает... Странно
Уметь кодить надо, Господа!

Прикреплённая картинка

Чувствую, еще немного, и N0P станет фанатом C++

Цитата N0P @ 23.10.07, 04:27

благо что проффесионалы, практически не используют всякого рода "шаблоны" (на расхваливание которых "приплюснутые" израсходовали много пены, толком ничего не доказав в практическом применении), обходясь базовым функционалом C++.

Профессионалы, как это ни странно, используют инструмент, соответствующий задаче.

Цитата N0P @ 23.10.07, 04:27

отличаеться низким быстродействием которой не помогают активация в C++ компиляторе различных фич быстродействия (максимум быстродействия, fastcall вызовы), +перепробованая куча компилеров (VC5/6/NET2003/INTEL)

И наличием классических дыр... На приведенном скриншоте прекрасно смотрится вызов функции vsprintf... Тогда как правильный вариант - использование не менее стандартной vsnprintf. Дабы потом этим же отладчиком не искать stack overrun...

Цитата N0P @ 23.10.07, 04:27

А что Delphi, как нативный я/п предлагает уровень каких-либо костылей, которых валом в том же .net?

Ты что-то путаешь. Наверное, как всегда, мягкое с теплым. Нативный уровень - это использование PSAPI, ImgHelp, DbgHelp, а также методов типа WaitForDebugEvent, ContinueDebugEvent и иже с ними, которые идут в поставке с самой системой. И причем тут Delphi - опять же, не понятно. Да и о каких костылях в .NET ведется речь?

Цитата Flex Ferrum @ 22.10.07, 23:23

Почему бы не остановиться на CORBА? Вполне себе мультиплатформенный стандарт... Но ведь на Dephi его нет...

Насколько я помню - есть. Только дельфовый народ очень боится этой аббревиатуры почему-то.

Цитата wind @ 23.10.07, 06:14

Только дельфовый народ очень боится этой аббревиатуры почему-то.

Наверное, потому это что-то кроссплатформенное и непонятное, и не поддерживается на уровне языка?

Цитата

Напрямую зависит от разработчиков, благо что проффесионалы, практически не используют всякого рода "шаблоны" (на расхваливание которых "приплюснутые" израсходовали много пены, толком ничего не доказав в практическом применении), обходясь базовым функционалом C++.

шаблоны относятся к базовому функционалу C++, без них ведь и контейнеры работать не будут

Добавлено 23.10.07, 10:07
а вообще к написанию новых шаблонов я тоже как то странно отношусь, сначала я думал, что я неправ, но потом меня переубедили: "все полезные шаблоны уже написаны, пошукай по базе исходников"