Delphi vs C++

Цитата Guderian @ 16.08.05, 14:30

Да по всем, чего мелочиться.

У меня нет желания продолжать с тобой дискуссию - не вижу смысла. Скажу только, что 99% производимых в мире процессоров - DSP и микроконтроллеры, доля Delphi в программировании для них - ноль целых ноль десятых процента.

http://www.rsdn.ru/Forum/?mid=3762

Цитата Guderian @ 16.08.05, 14:30

Ну очень алчу примера, особенно для .NET 2.0.

Будешь отрицать, что managed код медленнее?

Цитата Guderian @ 16.08.05, 14:30

Может исходники Unix/BSD/Linux возьмем?

Сойдут.

Цитата Guderian @ 16.08.05, 14:30

У меня есть несколько иная инфомация по крайне мере для 3ds max до 2.0 включительно и очень сильные сомнения по поводу Maya, учитывая историю Alias & Wavefront. Так что вы с Флексом определитесь. А то один говорит, что нормальные компиляторы C++ появились с 1999, а ты мне говоришь о продуктах с более чем десятилетней историей и говоришь, что на C++.

Я не написал, что они были изначально на С++ написаны. Оба продукта были переписаны заново с использованием С++. А отсутствие компиляторов, например, нормально поддерживающих шаблоны, не говорит о полном их отсутствии.

Цитата Guderian @ 16.08.05, 14:30

Тут сложно что-то сказать, поскольку не понятно, что считаем и кого кроем.

Считаем объемы продаж (в денежном эквиваленте) задач, не требуемых стандартного GUI, требовательных к производительности и т.д.

Цитата Guderian @ 16.08.05, 14:30

Покажи мне хоть один CAD/3D/2D продукт где в координатах точек смешиваются целочисленные и вещественные значения?

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

Цитата s-mike @ 17.08.05, 09:24

А может решим визуальную задачку? Создание какого-то контрола (элемента управления)? Эта задача встречается довольно часто.

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

Цитата trainer @ 16.08.05, 12:49

Здесь дело даже не в объеме кода, а в том, что в случае внесения изменений/исправлений править нужно только в одном месте, а не для каждого типа отдельно и где-то забыть внести изменения.

Вот это точно. Особенно когда такого кода много. Лучше один раз написать шаблон, чем плодить ошибки.

Цитата

Лучше один раз написать шаблон, чем плодить ошибки.

Ну, про шаблоны вообще должна быть отдельная песня о главном. Процедура вывода параметра шаблона - не самая тривиальная. К тому же не факт, что бага, исправленная для типа int автоматически будет исправлена (не факт, что исправление не породит новых ошибок!!) для типа CMyClass *, но в целом это не очень страшно, потому что есть специализации А вообще, конечно, шаблоны рулят.

Что-то противоположная сторона притихла. Наверное, задачу придумывает.

Цитата Flex Ferrum @ 16.08.05, 14:45

Зайди в директорию известного тебе проекта, и загляни в файл include/geometry.h (это по поводу надуманности задачи ). Потом скажи мне - где там производится смешивание целочисленных и вещественных значений, а также в каком месте будут потери производительности при учете того, что компилятор прекрасно раскрывает циклы с заведомо известным количеством итераций?
Способы использования можешь посмотреть там же в Test/Test.cpp.

Прошу прощения, я опирался на твою фразу:

Цитата Flex Ferrum @ 16.08.05, 12:06

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

Которую можно интерпретировать как угодно. Что же касается известного нам проекта, то после гетласта я имею ругань на отсутствие geometry.h и hierarchy_gen.h, так что ничего сказать не могу.

Цитата Flex Ferrum @ 16.08.05, 14:45

Отлично! Другое дело, что в этой теме идет упор на то, что, де, Delphi - удобное RAD-средство... Т. е. предполагается, что народ по большей части именно контролы на формы кидает (ИМХО, конечно).

Возьму для примера свои последние проекты на дельфи. Ты где-нибудь видел готовые компоненты планирования производства и поставок, бюджетирования, HR-менеджмента? Не думаю. Так вот, Delphi мне позволяла сконцентрироваться в большей стемени на предметных задачах, которые, уверяю тебя, не являются простыми и кодирования там немало.

Цитата Flex Ferrum @ 17.08.05, 08:43

Именно по этому я и предложил накидать на Delphi решение такой достаточно простенькой задачи.

А зачем нам простенькие? Давай возьмем сложную систему с гетерогенной средой СУБД, middle-tier крутящий бизнес-компоненты, GUI-rich АРМы и т.п. Идет?

Цитата trainer @ 17.08.05, 10:21

У меня нет желания продолжать с тобой дискуссию - не вижу смысла. Скажу только, что 99% производимых в мире процессоров - DSP и микроконтроллеры, доля Delphi в программировании для них - ноль целых ноль десятых процента.

Ну поговори со мной, ну пожалуйста, а то я себе места не найду А могу еще подумать, что это проявление инфантилизма в отсутствие аргументов. Ведь я изначально говорил о преимуществах в секторе заказных enterprise-продуктов, а мне вдруг DSP стали тыкать.

Цитата x0ras @ 17.08.05, 10:54

Будешь отрицать, что managed код медленнее?

Причем здесь это, если мы говорили об оверхеде при смешивании managed/unmanaged кода.

Цитата x0ras @ 17.08.05, 10:54

Сойдут.

Ну и многие из них на C++ писались?

Цитата x0ras @ 17.08.05, 10:54

Я не написал, что они были изначально на С++ написаны. Оба продукта были переписаны заново с использованием С++. А отсутствие компиляторов, например, нормально поддерживающих шаблоны, не говорит о полном их отсутствии.

Тогда могу я предположить, что выбор C++ был помимо прочего связан с тем, что предшественники были написаны на C?

Цитата x0ras @ 17.08.05, 10:54

Считаем объемы продаж (в денежном эквиваленте) задач, не требуемых стандартного GUI, требовательных к производительности и т.д.

По моим наюлюдениям, начиная от сегментированных финансовых отчетов Microsoft и статистики различных онлайновых магазинов, настольное ПО уверенно лидирует.

Цитата x0ras @ 17.08.05, 10:54

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

Ну так значит не происходит смешения типов и в дельфи эта задача легко решается с использованием алиасов.

Цитата Flex Ferrum @ 17.08.05, 11:07

Что-то противоположная сторона притихла. Наверное, задачу придумывает.

Очень странно слышать это от тебя, учитывая, что ты в курсе причины по которой я не могу в ближайшее время участвовать в дискуссии. А s-mike не может зайти в "директорию тебе известного проекта". Так в чем проблема это нетерпения?

В общем вы тут пока без меня отдохните

Цитата Guderian @ 18.08.05, 06:11

Что же касается известного нам проекта, то после гетласта я имею ругань на отсутствие geometry.h и hierarchy_gen.h, так что ничего сказать не могу.

Засада... Будем разбираться.

Цитата Guderian @ 18.08.05, 06:11

А зачем нам простенькие? Давай возьмем сложную систему с гетерогенной средой СУБД, middle-tier крутящий бизнес-компоненты, GUI-rich АРМы и т.п. Идет?

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

Цитата Guderian @ 18.08.05, 06:11

Тогда могу я предположить, что выбор C++ был помимо прочего связан с тем, что предшественники были написаны на C?

Как я тебе уже когда-то говорил, сделать кальку с С кода на С++ невозможно. Это при любом раскладе приведет к серьезному рефакторнигу всего продукта, и получится, что легче переписать большую его часть "с нуля".

Цитата Guderian @ 18.08.05, 06:11

Ну так значит не происходит смешения типов и в дельфи эта задача легко решается с использованием алиасов.

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

Цитата Guderian @ 18.08.05, 06:11

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

Тут я имел в виду s-mike'а, а не тебя.

Цитата Guderian @ 18.08.05, 06:11

Цитата (Flex Ferrum @ Вчера, 14:07)
Что-то противоположная сторона притихла. Наверное, задачу придумывает.

Я красивое решение той вашей задачи придумывал.

Points.pas

unit Points;
 
interface
 
{$DEFINE POINT_FLOAT}
{$I Points.inc}
{$UNDEF POINT_FLOAT}
{$I Points.inc}
 
implementation
 
end.

Points.inc

type
  {$IFDEF POINT_FLOAT}TFigureFloat{$ELSE}TFigureInt{$ENDIF} = class
    X, Y, Width, Height: {$IFDEF POINT_FLOAT}Extended{$ELSE}Integer{$ENDIF};
    {$IFDEF POINT_FLOAT}Precision: Integer{$ENDIF}
  end;

Где кода меньше и код понятнее?

Цитата s-mike @ 18.08.05, 06:37

Я красивое решение той вашей задачи придумывал.

Первый вариант приянт. Вопросы:
1. Что есть такое Precision?
2. (если ответ на 1-ое - "глубина"), то где координата Z?
3. Судя по всему, я могу использовать либо 2D-фигуру с целочисленными координатами, либо 3D с вещественными координатами?
4. Как мне использовать это решение для описания объектов в n-мерном пространстве?

Добавлено 18.08.05, 07:13
Приведу кальку с этого кода на С++ (для симметрии):
Файл point.cpp

#define FLOAT_COORDS
#include "point.h"
#undef FLOAT_COORDS
#include "point.h"

Файл point.h

#ifdef FLOAT_COORDS
class Figure3D
{
double Precision,
#else
class Figure2D
{
int
#endif
X, Y, Width, Height;
};

Тут больше только строчек (для улучшения читаемости). Количество ключевых слов - такое же, если не меньшее. Но это решение - не в стиле С++. Приавильное решение было бы таким (функциональность пока не увеличиваем):

template<class T, class D> class FigureND
{
public:
T Coords[D];
T Sizes[D];
};
 
//...
// Объявляем объекты
FigureND<int, 2> _2d_int_figure;
FigureND<float, 2> _2d_float_figure;
FigureND<double, 4> _4d_double_figure;
//...

Фиг его знает, зачем я назвал 2Д и 3Д, что-то в голову не то пришло. Названия классов поправил. Я имел ввиду именно обекты с целочисленными и вещественными координатами. Это там и реализовано. Precision - точность.

В С++ по сравнению с Паскалеи есть одно колоссальное удобство: возможность объявлять переменные в месте их использования и ограничивать область видимости блоками.

Цитата s-mike @ 18.08.05, 07:25

Фиг его знает, зачем я назвал 2Д и 3Д, что-то в голову не то пришло. Названия классов поправил.

Ну тогда еще проще:

template<class T> class Figure2D
{
public:
T X, Y, Width, Height;
};

Цитата Guderian @ 18.08.05, 06:11

Ну поговори со мной

Это бессмысленно. Ты предъявляешь тезисы. Когда тебе предъявляют контраргументы, ты меняешь тезисы и выясняется, что ты имел в виду другое. Когда у тебя заранее пытаются выяснить, что же ты имел в виду, ты говоришь, что это флуд.

Цитата Guderian @ 18.08.05, 06:11

А могу еще подумать, что это проявление инфантилизма в отсутствие аргументов.

Можешь думать что угодно. Это ты здесь воюешь(у тебя тут и языки осуждаемые), а я дискутировал.

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

Цитата (Guderian @ Сегодня, 10:11)

Цитата

А зачем нам простенькие? Давай возьмем сложную систему с гетерогенной средой СУБД, middle-tier крутящий бизнес-компоненты, GUI-rich АРМы и т.п. Идет?

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

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

Цитата Guderian @ 18.08.05, 06:11

Причем здесь это, если мы говорили об оверхеде при смешивании managed/unmanaged кода.

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

Цитата Guderian @ 18.08.05, 06:11

Ну и многие из них на C++ писались?

Что ты упорно хочешь доказать? Что:

Цитата Guderian @ 16.08.05, 09:35

Так что получается? Они у нас результат реализации мощи С++ или просто волей истории переводимые на него с C?

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

Цитата Guderian @ 18.08.05, 06:11

По моим наюлюдениям, начиная от сегментированных финансовых отчетов Microsoft и статистики различных онлайновых магазинов, настольное ПО уверенно лидирует.

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