Delphi vs C++

Цитата Flex Ferrum @ 18.08.05, 06:36

Ух. Даа... Что-то мне подсказывает, что немалая часть из этого решается с помощью готовых контролов (для Delphi), о которых ты только что упомянул...

И что из того? Преположим, стоит конкретная задача АРМ сотрудника дилингового центра. Берем какой-нибудь метод "японских свечей", проводим сложный анализ трендов и т.п. Готового компонента естественно нет. Данные о котировках берутся из базы, на рабочем месте должны высвечиваться аналитические таблицы, графики, диаграммы. В итоге имеем определенную алгоритмическую мощность задачи, с которой придется столкнуться обоим лагерям. Другое дело, что на различные сервисные обвески у нас уйдет гораздо меньше времени. При одинаковой компетенции разработчиков и календарном плане мы имеем возможность больше времени уделить сути. Это плохо? И что в данном случае мы говорим, что дельфисты халтурят если решают те же самые задачи высокой сложности не тратясь на мартышкин труд? Я даже не знаю, как толком объяснить, что не все задачи на дельфи сводятся к написанию текстовых редакторов и там тоже приходиться колотить код ручками.

Цитата Flex Ferrum @ 18.08.05, 06:36

Тогда ждем решения (а от тебя - письма с датой, когда делал последний Get Last).

Сразу перед тем как написал сюда пост. И о каком решении может идти речь если ты не ответил ни на один вопрос, подтверждающий удачный дизайн решения в целом. В Test.cpp я ровным счетом ничего полезного не увидел, а имели место конкретные вопросы. Например, я хочу провести единую операцию над всеми координатами всех геометрических объектов для чего у меня есть процедура DoTransform(point: GenericPoint). Покажи, как она будет работать для PointND.
Пока я не увижу те преимущества от использования продемонстрированного подхода решать ее совершенно не имеет смысла и акция может быть просто расценена как прессинг возможностями C++ на которые я буду отвечать соответствующим образом Например покажи мне элементарные типы вроде TYear = 1900..2100, TMonth = (January,February,March,...), продемонстрируй работу с множествами на примере monthset = set of TMonth; monthset := monthSet + [February,March]; if SomeMonth in monthset then... и т.д., многомерные массивы с разными типами TMonthMatrix : array[TYear,TMonth], динамические многомерные массивы в духе TDynamicArray : array of array of Integer, насколько просто осуществляется работа с типизированными файлами вроде file : file of TSomeRecord, Variant parts в записях, скажем

type
  TShapeList = (Rectangle, Triangle, Circle, Ellipse, Other);
  TFigure = record
    case TShapeList of
         Rectangle: (Height, Width: Real);
         Triangle: (Side1, Side2, Angle: Real);
         Circle: (Radius: Real);
         Ellipse, Other: ();
  end;

такие инструменты как threadvar, давай сравним сишные хедеры+либы с дельфийскими dcu+bpl по простоте, размерам, функциональности (с секциями initalization, finalization), наличие конструкции for in и многое другого. Я намеренно никогда не касался всего этого, поскольку отлично понимал, что на C++ все равно найдется решение, пусть и с небольшим оверхедом. Точно так же, как он будет и на дельфи если скажем встанет задача создания нескольких типизированных коллекций. Но разницы эти мизерные, если мы говорим о серьезных проектах и пенальти в размере 10К там или сям при общем размере исходников в десятки магабайт является несущественной.

Цитата Flex Ferrum @ 18.08.05, 11:52

И потом. Скорость решения предлагаемого тобой типа задачи зависит далеко не от языка, а от выбранного инструментария. Сам посуди. Оно, конечно, можно пытаться реализовать все это и на ассемблере. Но если я возьму тот-же билдер, студию .NET, что-нибудь типа PowerBuilder и т. п., то дело пойдет гораздо быстрее. Только сдается мне (поправь, если я не прав) все дело сведется к связи некоторого количества готовых контролов между сбой с добавлением необходимой бизнес-логики, завязанной на уже готовые классы и компоненты. Ибо весь этот инструментарий стремиться к обозначенному мною (и ты с этим согласился) иделу - сборке системы из готовых компонент с минимальной программной доводкой.

Как я уже говорил, компонент на все случаи жизни не существует. И бизнес-логику зачастую ты реализуешь самостоятельно. Другое дело, что общий компонентный подход тебя невольно подтакливает к хорошему дизайну с loose coupling. И именно это подтвержается обилием компонент и их активным использованием. Ты же не станешь отрицать, что это признак удачной архитектуры?

Цитата Flex Ferrum @ 18.08.05, 11:52

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

Так я с самого начала толкую, что язык при решении подавляющего большинства задач роли не играет совершенно. Другое дело, что дельфи изначально предлагала интегрированную инфраструктуру для их решения задолго до появления того же билдера. Что касается задач, то какого рода задачу ты хочешь?

Цитата x0ras @ 18.08.05, 11:59

При смешении managed/unmanaged кода нет оверхедов. Они могут возникать при преобразовании типов и неправильном выборе линкера развертываемого кода шаблонов. Надеюсь ты не будешь отрицать, что возможно написать библиотеку на С++ и использовать ее в любом .NET проекте, написав обертку. В С++ проекте для .NET я могу без извратов (оберток и лишнего геморроя) писать такой код прямо в проекте.

"Преобразование" типов, это если бы я писал public static explicit operator SomeConversionType(int i), создание же managed-copy value-типов и обратная операция называются упоминаемым мною ранее boxing и unboxing соответственно. Если ты утверждаешь, что они не дают оверхеда, то значит Microsoft нисколько не смыслит в .NET, поскольку буквально во всех своих мануалах по .NET Perfomance Tips&Tricks говорится совершенно обратное.

Цитата x0ras @ 18.08.05, 11:59

Что ты упорно хочешь доказать? Что:
Цитата (Guderian @ 16.08.05, 12:35)
Так что получается? Они у нас результат реализации мощи С++ или просто волей истории переводимые на него с C?

Ты считаешь, что все большие/серьезные продукты на С++ это волей истории переведенные с С, а сейчас ничего серьезного не пишется и никому не нужно? Или все что не БД и не ОС - это не серьезный продукт. Может стоит оглянутьтся вокруг деревни и увидеть, что помимо заказных enterprise-продуктов есть что-то еще?

Не надо меня перевирать. Я не хочу сказать, но предполагаю, что популярность С++ может быть отчасти вызвана наличием огромного количества кода написанного на C. Я никогда не говорил, что "БД и не ОС - это не серьезный продукт" и с самого первого сообщения сказал только о преимуществе Delphi на рынке заказных enterprise-level продуктов. Это мода такая повальная - не читать? Или просто переврать в отсутствие аргументов удобней?

Цитата x0ras @ 18.08.05, 11:59

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

У нас игра в одни ворота или я подсудимый? Свои источники я назвал, на их тотальную объективность не претендовал. Теперь твой рапорт на стол!

Блин, вы мою ссылку читали или нет? Я вообщето хотел мнения услышать...
http://www.rsdn.ru/Forum/?mid=3762

Цитата Guderian @ 18.08.05, 12:58

И о каком решении может идти речь если ты не ответил ни на один вопрос, подтверждающий удачный дизайн решения в целом. В Test.cpp я ровным счетом ничего полезного не увидел, а имели место конкретные вопросы. Например, я хочу провести единую операцию над всеми координатами всех геометрических объектов для чего у меня есть процедура DoTransform(point: GenericPoint). Покажи, как она будет работать для PointND.

Ммм... Предположим,

template<typename T> void DoTransform(T& point)
{
//...
}

Подобного рода решения никоим образом не ущемляют и не нарушают прицыпы ОО-дизайна. Просто вместо полиморфизма времени выполнения (вариант с базовым GenericPoint) мы имеем полиморфизм времени компиляции. В случае обобщенного программирования не так важно - связаны ли обощаемые типы общей базой или нет. Главное, чтобы интерфейс у них был унифицирован. Хороший пример - набор контейнеров в пространстве имен std. У всех контейнеров - унифицированный интерфейс вставки, удаления, доступа через итераторы и т. п. При этом общим базовым классом они не объеденены. Да это в данном случае и не нужно...

Цитата Guderian @ 18.08.05, 12:58

типы вроде TYear = 1900..2100

Да. Этого нет.

Цитата Guderian @ 18.08.05, 12:58

TMonth = (January,February,March,...),

enum?

Цитата Guderian @ 18.08.05, 12:58

продемонстрируй работу с множествами на примере monthset = set of TMonth; monthset := monthSet + [February,March]; if SomeMonth in monthset then...

std::set?

Цитата Guderian @ 18.08.05, 12:58

многомерные массивы с разными типами TMonthMatrix : array[TYear,TMonth],

Подозреваю, что enum'ы я могу использовать для индексирования массивов...

Цитата Guderian @ 18.08.05, 12:58

многомерные массивы в духе TDynamicArray : array of array of Integer,

std::vector< std::vector<int> >?

Цитата Guderian @ 18.08.05, 12:58

осуществляется работа с типизированными файлами вроде file : file of TSomeRecord

std::istream_iterator<T>, std::ostream_iterator<T>?

Цитата Guderian @ 18.08.05, 12:58

Variant parts в записях, скажем

union?

Цитата Guderian @ 18.08.05, 12:58

такие инструменты как threadvar

В С++ (пока) нет понятия "поток". По этому нет.

Цитата Guderian @ 18.08.05, 12:58

давай сравним сишные хедеры+либы с дельфийскими dcu+bpl по простоте, размерам, функциональности (с секциями initalization, finalization),

Врядли они чем-то коренным образом различаются.

Цитата Guderian @ 18.08.05, 12:58

наличие конструкции for in и многое другого

Компания алгоритмов std::for_each, std::copy, std::transform и т. д. + итераторы?

Ты не удивляйся, что часть решений - из пространства имен std. STL является частью стандарта С++, а потому считается неотъемлимой частью языка.

Цитата Guderian @ 18.08.05, 12:58

Другое дело, что общий компонентный подход тебя невольно подтакливает к хорошему дизайну с loose coupling.

Это из серии высказывания "в здоровом теле - здоровый дух", которое в оригинале звучит как "было бы здорово, если бы в здоровом теле был еще и здоровый дух". Я к тому, что компонентный подход подталкивает к хорошему дизайну только тех, кто хочет к нему подталкиваться. Помниться, еще в институте было. Лабораторя. Два программиста - я и еще один парень. Рисуем что-то на билдере. Подхожу я как-то к нему, смотрю код - а у него "Unit1.cpp, Unit2.cpp, From1, From2" и т. д. Я спрашиваю - "а почему файлы и формы не переименовываешь?". Он - "а зачем? И так же ведь компилится". А потом разбирайся за ним - что за "Unit1.cpp" и "Form1".

Цитата Guderian @ 18.08.05, 12:58

Ты же не станешь отрицать, что это признак удачной архитектуры?

Грамотное использование компонент - несомненный признак удачной архитектуры.

Цитата Guderian @ 18.08.05, 12:58

Что касается задач, то какого рода задачу ты хочешь?

Любую, которую я мог бы закодировать в студии не прибигая к специальным библиотекам и сторонним компонентам. Грубо говоря чистый язык + системное API (в крайнем случае).

Цитата Guderian @ 18.08.05, 12:58

И что из того? Преположим, стоит конкретная задача АРМ сотрудника дилингового центра. Берем какой-нибудь метод "японских свечей", проводим сложный анализ трендов и т.п. Готового компонента естественно нет. Данные о котировках берутся из базы, на рабочем месте должны высвечиваться аналитические таблицы, графики, диаграммы. В итоге имеем определенную алгоритмическую мощность задачи, с которой придется столкнуться обоим лагерям. Другое дело, что на различные сервисные обвески у нас уйдет гораздо меньше времени. При одинаковой компетенции разработчиков и календарном плане мы имеем возможность больше времени уделить сути. Это плохо?

Гм. Как бы тебе сказать... Ты заведомо предполагаешь, что разработчик на С++ ограничен в "сервисных обвесках" совершенно забывая (или я не прав?), что он может воспользоваться любым удобным для решения поставленной задачи инструментом - тем же Builder'ом, или VC++.NET...

Цитата

одозреваю, что enum'ы я могу использовать для индексирования массивов...

легко

std::vector< std::vector<int> >?

и т.д..., + куча разных deque, list, map, multimap - контейнер можно выбрать под задачку, в зависимости от того, что с данными будут чаще делать: вставлять, читать, вставлять спереди, вставлять сзади, вставлять в середину и т.д.
+ кучка valarray сотоварищи

Цитата

В С++ (пока) нет понятия "поток". По этому нет.

у меня есть неплохой классик потока, такой кошерненький

Цитата

Компания алгоритмов std::for_each, std::copy, std::transform и т. д. + итераторы?

Ты не удивляйся, что часть решений - из пространства имен std. STL является частью стандарта С++, а потому считается неотъемлимой частью языка.

да уж, чёрт в них ногу сломает (cлишком уж много
всяких там accumulate и т.п.), но это - Стандарт

Цитата

"Unit1.cpp, Unit2.cpp, From1, From2"

расстрел на месте!


Rouse - прекрасно. Читаю. Учитываюсь. Да что тут можно сказать.
Мне вообще пофигу на чём писать. Если начальство велит за Кобол сесть - сяду.
Слово начальства закон. Это даже интереснее - сразу жизнь мёдом казаться перестаёт
(тут посидел пару дней за VBA, ничего так, кошерненько).

Цитата

Да, совсем, забыл о профессионалах! Профессионал – это человек зарабатывающий себе на пропитание некоторой профессией. Обычно подразумевается, что делает он это не случайно. То есть профессионал может быть
и дельфист и сионист и кто угодно кроме ламера. Чего себе и Вам желаю.

да пребудут с вами бабки . Много бабок.

Цитата Rouse_ @ 18.08.05, 13:57

Блин, вы мою ссылку читали или нет? Я вообщето хотел мнения услышать...
http://www.rsdn.ru/Forum/?mid=3762

Я читал.

Цитата Guderian @ 18.08.05, 12:58

"Преобразование" типов, это если бы я писал public static explicit operator SomeConversionType(int i), создание же managed-copy value-типов и обратная операция называются упоминаемым мною ранее boxing и unboxing соответственно.

Преобразование типов (пользовательское или нет) - это оверхед (причем обычно значительный). Boxing/unboxing в расчет не берем, т.к. я описал случай в котором нет этих операций. Например, пакет моделирования - GUI на managed C++, а рендер на unmanaged С++. Никаких оверхедов - все быстро и просто.

Цитата Guderian @ 18.08.05, 12:58

Если ты утверждаешь, что они не дают оверхеда, то значит Microsoft нисколько не смыслит в .NET, поскольку буквально во всех своих мануалах по .NET Perfomance Tips&Tricks говорится совершенно обратное.

Твоими же словами: Это мода такая повальная - не читать? Или просто переврать в отсутствие аргументов удобней?

Цитата Guderian @ 18.08.05, 12:58

Я не хочу сказать, но предполагаю...

То есть ты предпологаешь, но не говоришь? В таком случае, о чем же ты писал? Или сказать не хочешь, но все же говоришь? В чем, тогда я неправ?
Может нужно определиться?

Цитата Guderian @ 18.08.05, 12:58

Я никогда не говорил, что "БД и не ОС - это не серьезный продукт" и с самого первого сообщения сказал только о преимуществе Delphi на рынке заказных enterprise-level продуктов.

О чем тогда спор? Half-Life2 серьезный продукт? Doom3? Unreal3? Можем обсудить почему они написаны на С++.
Ты сам сказал, что названием темы ниша не ограничена, так почему все сводится к enterprise-level продуктам?

Цитата Guderian @ 18.08.05, 12:58

У нас игра в одни ворота или я подсудимый? Свои источники я назвал, на их тотальную объективность не претендовал. Теперь твой рапорт на стол!

Давай рассмотрим мировой рынок.
Самый большой рынок - телеком (около 30%). Думаю мы не будем спорить, что в этой отрасли лидирует С++.
Разработка ПО для мобильных устройств (самая большая доля).
Индустрия развлечений (достаточно весомый процент, чтобы управлять развитием платформы x86).
Это уже около 63% мирового рынка. Еще есть серверные приложения, разработка ПО для нестандартного оборудования и ОС.
Точных данных на эти отрасли у меня нет, т.е. не имею доступа. Это данные мирового лидера в ислледовании и аналитики IT-индустрии Gartner.

Сразу скажу, что я программист далеко не опытный, но все же пишу достаточно сложные программы на Delphi (в основном для собственных нужд, т.к. в данный момент не работаю, а учусь на 3 курсе). C/C++ знаю похуже, но иногда приходится писать и на нем. Естественно, все возможности C++ или Object Pascal я не использую (да и не знаю, наверное). Теперь по теме. Очень давно читаю этот форум, хотя почти не пишу. Вот прочитал всю эту ветку, и у меня сложилось очень противоречивое впечатление. С присущем моему возрасту юношеским максимализмом я подумал, неужели мой любимый объектный паскаль настолько слаб? Неужели на Delphi нельзя написать более-менее серьезный и большой проект (типа PhotoShop или 3DMax)? А если можно, то почему все выбирают С++? Ведь действительно все крупные программы пишутся на С++, игры тоже на С++, а на Delphi - ничего! Может стоит пока не поздно изучать С++ и забыть о Delphi?
Отцы, подтвердите мои опасения или развейте их, приведите хоть несколько примеров программ на Delphi. Посоветуйте, что же мне делать?

Аха! Враг деморализован и бежит !
Шутка.

Цитата BuGor @ 14.09.05, 07:31

Отцы, подтвердите мои опасения или развейте их, приведите хоть несколько примеров программ на Delphi.

TheBat, вроде бы.
Ну и парочка лабораторных работ у меня.

Цитата BuGor @ 14.09.05, 07:31

Может стоит пока не поздно изучать С++ и забыть о Delphi?

Стоит. Будет только лучше.

Могу ещё вспомнить оболочку от Dev C++ - тоже написана на Delphi, и ребята сделали правильный выбор - из бесплатных оболочек эта - лучшая. Они не стали извращаться на C++, а взяли что попроще. Хотя им - gcc-шникам ли не знать всю мощь и красоту. Но нет, для оболочки взяли Delphi.
Это - очень известная прога, по крайней мере, среди адептов C++ -а.

Цитата

TheBat, вроде бы.

Это даже я написать могу.

Цитата

Могу ещё вспомнить оболочку от Dev C++ - тоже написана на Delphi

Ну это по серьезнее будет. Но все равно мало

Цитата

Стоит. Будет только лучше.

Вот блин. Что же делать?

Я пытаюсь получить ответ на вопрос: "На Delphi не пишут серьезное ПО из-за убогости самого Delphi или из-за не распространенности последнего и отсутствия профессиональных программистов на нем?"

Цитата BuGor @ 14.09.05, 09:42

Я пытаюсь получить ответ на вопрос: "На Delphi не пишут серьезное ПО из-за убогости самого Delphi или из-за не распространенности последнего и отсутствия профессиональных программистов на нем?"

Из-за того, что в больших программах на первый план выходит сложность моделей данных и их обработки, а не GUI. Т.е. Delphi теряет свое преимущество в плане RAD и выдает недостаток в виде некачественного(неоптимального) кода.

Цитата trainer @ 14.09.05, 10:12

Из-за того, что в больших программах на первый план выходит сложность моделей данных и их обработки, а не GUI. Т.е. Delphi теряет свое преимущество в плане RAD и выдает недостаток в виде некачественного(неоптимального) кода.

trainer! Как ты мог такое сказать про Delphi???? Сейчас же начнут клевать и минусы раздавать!

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

Можно было сказать мягче: "не самого высококачественного". Так лучше?