Delphi vs C++

Цитата s-mike @ 16.08.05, 10:46

Какой процент таких задачь?

По какому критерию? Объем продаж? Количество копий? Количество продуктов?

Кстати, о скорости разработки (x0ras, думаю, оценит). Формы - формами, контролы - контролами, но вот задачка (вполне себе реальная). Разрабатывается некий графический движок. Понятно, что там должны быть определены такие понятия, как точка (в пространстве и на плоскости), размер (опять же, на плоскости и в пространстве), прямоугольник, бокс (паралеллограм). При этом координаты всего этого счастья могут быть как целочисленные, так и с плавающей точкой причем, еще и разной точности. Можно ли реализовать все это на Delphi минимальным количеством исходного текста? Если да, то как?

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

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

Можно ли реализовать все это на Delphi минимальным количеством исходного текста?

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

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

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

Причем сделать можно так, что в итоге концевые классы будут выглядеть так:

template<class T> class Point2D : public GenericPoint<T, 2>
{
public:
Point2D() {;}
Point2D(T x, T y) {...;}
Point2D(const Point2D& pt) : GeneircPoint<T, 2>(pt) {;}
T& X() {...;}
const T& X() const {...;}
T& Y() {...;}
const T& Y() const {...;}
};
template<class T> class Point3D : public GenericPoint<T, 3>
{
public:
Point3D() {;}
Point3D(T x, T y) {...;}
Point3D(const Point3D& pt) : GeneircPoint<T, 3>(pt) {;}
T& X() {...;}
const T& X() const {...;}
T& Y() {...;}
const T& Y() const {...;}
T& Z() {...;}
const T& Z() const {...;}
};
//...
template<typename T> class Rect : public GenericRectOrBox<Point2D<T>, Size2D<T> >
{
public:
Rect();
Rect(const Rect&);
T Left() {...;}
T Top() {...;}
T Right() {...;}
T Bottom() {...;}
};
 
template<typename T> class Box : public GenericRectOrBox<Point3D<T>, Size3D<T> >
{
public:
Rect();
Rect(const Rect&);
T Left() {...;}
T Top() {...;}
T Right() {...;}
T Bottom() {...;}
T Depth() {...;}
};

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

Добавлено 16.08.05, 13:05
Интересно было бы посмотреть решение подобной задачи на Delphi. Ведь разработка приложения - это не только кидание контролов на форму и задание соответствующих свойств в Property Sheet. Иногда ведь и код писать надо...

Цитата s-mike @ 16.08.05, 07:17

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

в Symbian-e почти так и делают. сначала пишут проект в IDE. а потом компилляция под конретный гаджет производится при помощи bat файлов и gcc в командной строке. и файл ресурсов рукам ковыряют.

Цитата Flex Ferrum @ 16.08.05, 10:08

Нет. Но зато есть стандарт С++. И если кто-то называет себя С++ (неважно, с какой приставкой/суффиксом), то предполагается, что он соответствует стандарту С++.

Цитата Flex Ferrum @ 16.08.05, 10:08

Потому что они язык не коверкают.

Тьфу ты Я то думал, что под аббревиатурой MC++ кроется Microsoft C++ Но все равно странно как-то. С одной стороны у MS есть и C++ и Managed C++. Если следовать твоей логике, то они должны быть абсолютно идентичны. Расширения диалекта для Borland C++ и билдера выкидываем, как несоответствующие стандартам или в лучшем случае нервно на них косим Никакого роста и эволюции, тишь да гладь. Все стандартно...

Цитата Flex Ferrum @ 16.08.05, 10:08

Я не говорил, что это рудиментарные задачи. Нисколько. Но (достаточно много с тобой этот вопрос обсуждали) идеал для того софта - развертывание из готовых компонент с необходимой подстройкой под желание клиента. Разве нет? RAD-средства - один из способов такого "развертывания".

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

Цитата Flex Ferrum @ 16.08.05, 10:08

Фуф. Тут ты предлагаешь мне в философию вдарится. Еще раз. С++ в его нынешнем виде существует с момента выхода компиляторов, поддерживающих (по максимуму) стандарт. Соответственно, годки это - с момента выходов следующих версий компиляторов:
BCC 5.5
MSVC 7.1
Intel C++ 7.x (если я не ошибаюсь)
gcc 3.x
Comeau 4.x
Годки это, соответственно, 1999-2002. До этого момента каждый из компиляторов придерживались своей версии С++ (с теми или иными отклонениями от генеральной линии, заданной Страуструпом), и в той или иной степени поддерживали те или иный специфические конструкции языка.
Дальше. Как ты правильно заметил, существует очень много софта, написанного на С. Очевидно, что на С++ он переписывается неохотно (оно и понятно - работает и хорошо). Но необходимо понимать, что то, что ты не видишь образчиков хорошего промышленного софта (в исходниках) на плюсах, это еще не значит, что их нет. Больше чем уверен, что тот же самый .NET писан на плюсах. Longhorn - однозначно, ибо об этом свидетельствует один из его разработчиков-консультантов (Герб Саттер). Большая часть промышленного кода на плюсах защищена авторскими правами и по этим причинам мы этот код никогда не увидим.

Да, в коде .NET cpp кода где-то в 2.5 больше чем си. Про Лонгохрн ничего не скажу по причине незнания. А что ты от Microsoft ожидал? Что они поднимут Quick Pascal 1.0 и будут писать на нем? Все равно я не вижу мощной инфраструктуры поддержки девелоперов для C++. Да, кода написанного на ней огромное количество. Смотришь и видишь 90% велосипедов, а нужного не находишь. Если и находишь, то имеешь проблемы в состыковке творений различных вендоров. Boost - уже неплохо, но этого очень мало.

Цитата Flex Ferrum @ 16.08.05, 10:08

Хех. Тут видимо дело вот в чем. Последнее время (хорошо это или плохо - не знаю), мне по большей части приходится разгребать ошибки времени компиляции, чем времени выполнения. А потому мне практически без разницы - нажму я десяток раз клавишу F7/F8 или введу в консоле next или просто буфифку n. print и dump тоже набрать не влом. А тот же самый ассист - он элементарным образом сокращает время набора кода, что в моем случае существеннее.

Опять же, примеряешь все только на себя, не задумываясь о том, что существуют еще и другие потребности. Взять хотя бы знакомый тебе JA2:Wildfire. Да я бы повесился его с WinDbg отлаживать.

Цитата trainer @ 16.08.05, 10:41

Guderian, ты чего такой горячий и скользкий?

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

Цитата trainer @ 16.08.05, 10:41

Цитата
Лично меня интересуют достижимые результаты, а не пустой звон по поводу богатых возможностей того или другого, которые может быть используются в 0.01% случаев.
Здесь речь идет о том, что возможности C++ используются в 0.01% случаев. Когда же я спрашиваю, почему именно 0.01%, то получаю ответ:

Цитирую: "Богатых возможностей ..., которые может быть используются в 0.01%...".

Цитата trainer @ 16.08.05, 10:41

Цитата (Guderian @ Вчера, 20:57)
Меня можно убедить в какой угодно процентной ставке, если продемонстировать те 100% задач, который решаются исключительно на C++ и не могут быть решены с использованием Delphi.
Это не подмена понятий, в которой ты обвиняешь других? Может надо на себя оборотиться?

Из вышесказанного следует и данный тезис, что мне можно продемонстрировать хоть 100%, поскольку 0.01% с моей стороны было лишь гипотезой. Но мне нужна демонстрация, а "не пустой звон". Теперь укажи мне, что я подменил и к кому надо "оборотиться", чтобы понять, почему мои посты читаются с произвольным выкидыванием слов?

Цитата trainer @ 16.08.05, 10:41

Ты уж определись. Или есть стандарт и они его блюдут, или стандарта нет.

В чем именно я должен определиться? То что у мелкомягких есть C++, который блюдет стандарты и Managed C++ - как собственный эксперимент? И что аббревиатуру MC++ надо расшифровывать, поскольку я ее лично толковал, как Microsoft C++, сиречь реализацию C++ микрософтом, но никак не Managed C++.

Цитата trainer @ 16.08.05, 10:41

Так и я в VCL его не вижу. Я говорил о работе с памятью(копирование, строки), а не об управлении памятью.

Щетильнее смотреть надо. И из каких именно слов я должен был понять, что работа с памятью не подразумевает аллокацию/деаллокацию памяти, ZeroMemory и пр., а подразумевает работу со строками, к примеру?

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

Если все делать бездумно, то не только такое может случиться. Только вот программы с managed/unmanaged работают в 2 раза быстрее managed. И это без выкрутасов. Можно получить прирост и в 3 раза, если захотеть.

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

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

А если взять исходники чего-нибудь посерьезнее?

Давай исходники. Разберем. Может исходники Unix/BSD/Linux возьмем? Сойдут в качестве серьезных или тоже так, фантики?

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

Знаю точно, что 3ds max и maya написаны на С++. Но разве это важно? Если для новых продуктов выбирается С++, но то есть веские (я предпологал, всем известные) причины.

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

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

На самом деле достаточно нескольких платформ (около 5), чтобы перекрыть все разработки на Delphi.

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

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

По какому критерию? Объем продаж? Количество копий? Количество продуктов?

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

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

Кстати, о скорости разработки (x0ras, думаю, оценит). Формы - формами, контролы - контролами, но вот задачка (вполне себе реальная). Разрабатывается некий графический движок. Понятно, что там должны быть определены такие понятия, как точка (в пространстве и на плоскости), размер (опять же, на плоскости и в пространстве), прямоугольник, бокс (паралеллограм). При этом координаты всего этого счастья могут быть как целочисленные, так и с плавающей точкой причем, еще и разной точности. Можно ли реализовать все это на Delphi минимальным количеством исходного текста? Если да, то как?

Реальными задачами, как я понимаю, являются задачи с искуственно подоткнутыми туда шаблонами, дабы продемонстрировать возможности C++? Покажи мне хоть один CAD/3D/2D продукт где в координатах точек смешиваются целочисленные и вещественные значения? И заодно поясни мне смысл данного акта, а также рассчитай потери на преобразовании при операциях с графическими примитивами. Или речь идет о:

type
    TTypeAlias = some original type;

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

Интересно было бы посмотреть решение подобной задачи на Delphi. Ведь разработка приложения - это не только кидание контролов на форму и задание соответствующих свойств в Property Sheet. Иногда ведь и код писать надо...

Очень приятно знать, что когда мы с тобой вместе работали в известной тебе конторе, то из нас двоих только ты занимался разработкой приложений. А я просто контролы лепил и даже в PropSheet'ы не заглядывал. Хоть одно успокаивает, что это мое контролокидание составляло львиную долю бюджета конторы и мне косвенно удавалось не оставить без зарплаты настоящих разработчиков вроде тебя...

Что же касается задачи, то написанное для меня не более чем филькина грамота. В C++ я чайник, в данном коде не вижу кроме абстракций ничего, а мне для понимания эффективности решения нужно видеть способы использования. Грубо говоря, как оно работает. Может использование шаблонов дает здесь пенальти на ОО-дизайн. Например, хочу я сделать итератор, который пройдет по всем PointXD и сохранить их координаты в CSV-файл, а некий лоадер их загрузит. Посему пока я совершенно не вижу никаких преимущест по сравнению с:

type
    PointND = class
    public:
        constructor PointND(Dimensions : Integer);
    end;

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

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

Реальными задачами, как я понимаю, являются задачи с искуственно подоткнутыми туда шаблонами, дабы продемонстрировать возможности C++? Покажи мне хоть один CAD/3D/2D продукт где в координатах точек смешиваются целочисленные и вещественные значения? И заодно поясни мне смысл данного акта, а также рассчитай потери на преобразовании при операциях с графическими примитивами. Или речь идет о:

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

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

Очень приятно знать, что когда мы с тобой вместе работали в известной тебе конторе, то из нас двоих только ты занимался разработкой приложений. А я просто контролы лепил и даже в PropSheet'ы не заглядывал. Хоть одно успокаивает, что это мое контролокидание составляло львиную долю бюджета конторы и мне косвенно удавалось не оставить без зарплаты настоящих разработчиков вроде тебя...

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

А в чем собственно спор? Разве не все используют для решения определенной задачи,
то средство, которое оптимально подходит по срокам реализации?

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

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

А это можно накидать как в Delphi так и в Visual Studio, другое дело, что на Delphi обычно после "набрасывания" контролов ничего не нужно делать, а в С++ нужно и не так уж мало... Может в таком случае поспорить о C# и С++,
это уже более модно...

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

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

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

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

Цитата amk @ 16.08.05, 17:59

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

Вот только не надо на среду и язык валить ошибки неопытных разработчиков.

Цитата s-mike @ 16.08.05, 17:10

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

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

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

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

Задача-то простенькая, но специально подобранная под возможности Си++. Если бы и была практическая необходимость такой задачи (или ее можно было бы представить), то я бы пошел по пути наследования и overload-функций.

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

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

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

Не. Не прокатит. По трем причинам:
1. Понятие "контрол" в С++ нет.
2. Для решения задачи я могу воспользоваться Builder'ом и получть тот же набор инструментальных средств.
3. Контрол - это тоже кусок кода. По этому если выберем задачу на чистое кодирование - будет только лучше. А как потом этот код применять (для контрола, для класса) - другой вопрос.