Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[13.59.154.143] |
|
Страницы: (13) « Первая ... 8 9 [10] 11 12 ... Последняя » все ( Перейти к последнему сообщению ) |
Сообщ.
#136
,
|
|
|
У меня нет желания продолжать с тобой дискуссию - не вижу смысла. Скажу только, что 99% производимых в мире процессоров - DSP и микроконтроллеры, доля Delphi в программировании для них - ноль целых ноль десятых процента.
|
Сообщ.
#137
,
|
|
|
http://www.rsdn.ru/Forum/?mid=3762
|
Сообщ.
#138
,
|
|
|
Будешь отрицать, что managed код медленнее? Сойдут. Цитата Guderian @ У меня есть несколько иная инфомация по крайне мере для 3ds max до 2.0 включительно и очень сильные сомнения по поводу Maya, учитывая историю Alias & Wavefront. Так что вы с Флексом определитесь. А то один говорит, что нормальные компиляторы C++ появились с 1999, а ты мне говоришь о продуктах с более чем десятилетней историей и говоришь, что на C++. Я не написал, что они были изначально на С++ написаны. Оба продукта были переписаны заново с использованием С++. А отсутствие компиляторов, например, нормально поддерживающих шаблоны, не говорит о полном их отсутствии. Считаем объемы продаж (в денежном эквиваленте) задач, не требуемых стандартного GUI, требовательных к производительности и т.д. Цитата Guderian @ Покажи мне хоть один CAD/3D/2D продукт где в координатах точек смешиваются целочисленные и вещественные значения? Очень простой пример - кроссплатформенный графический движок для мобильных и немобильных платформ. Так как в большинстве мобильных платформах нет поддержки вещественных чисел, то они эмулируются целочисленными. Цитата s-mike @ А может решим визуальную задачку? Создание какого-то контрола (элемента управления)? Эта задача встречается довольно часто. Где она встречается часто? Для каких программистов? У меня такой задачи вообще не возникает и ни у кого из моих коллег. Могу назвать сотни областей программирования, в которых нет такой задачи. Цитата trainer @ Здесь дело даже не в объеме кода, а в том, что в случае внесения изменений/исправлений править нужно только в одном месте, а не для каждого типа отдельно и где-то забыть внести изменения. Вот это точно. Особенно когда такого кода много. Лучше один раз написать шаблон, чем плодить ошибки. |
Сообщ.
#139
,
|
|
|
Цитата Лучше один раз написать шаблон, чем плодить ошибки. Ну, про шаблоны вообще должна быть отдельная песня о главном. Процедура вывода параметра шаблона - не самая тривиальная. К тому же не факт, что бага, исправленная для типа int автоматически будет исправлена (не факт, что исправление не породит новых ошибок!!) для типа CMyClass *, но в целом это не очень страшно, потому что есть специализации А вообще, конечно, шаблоны рулят. |
Сообщ.
#140
,
|
|
|
Что-то противоположная сторона притихла. Наверное, задачу придумывает.
|
Сообщ.
#141
,
|
|
|
Цитата Flex Ferrum @ Зайди в директорию известного тебе проекта, и загляни в файл include/geometry.h (это по поводу надуманности задачи ). Потом скажи мне - где там производится смешивание целочисленных и вещественных значений, а также в каком месте будут потери производительности при учете того, что компилятор прекрасно раскрывает циклы с заведомо известным количеством итераций? Способы использования можешь посмотреть там же в Test/Test.cpp. Прошу прощения, я опирался на твою фразу: Цитата Flex Ferrum @ При этом координаты всего этого счастья могут быть как целочисленные, так и с плавающей точкой причем, еще и разной точности. Которую можно интерпретировать как угодно. Что же касается известного нам проекта, то после гетласта я имею ругань на отсутствие geometry.h и hierarchy_gen.h, так что ничего сказать не могу. Цитата Flex Ferrum @ Отлично! Другое дело, что в этой теме идет упор на то, что, де, Delphi - удобное RAD-средство... Т. е. предполагается, что народ по большей части именно контролы на формы кидает (ИМХО, конечно). Возьму для примера свои последние проекты на дельфи. Ты где-нибудь видел готовые компоненты планирования производства и поставок, бюджетирования, HR-менеджмента? Не думаю. Так вот, Delphi мне позволяла сконцентрироваться в большей стемени на предметных задачах, которые, уверяю тебя, не являются простыми и кодирования там немало. Цитата Flex Ferrum @ Именно по этому я и предложил накидать на Delphi решение такой достаточно простенькой задачи. А зачем нам простенькие? Давай возьмем сложную систему с гетерогенной средой СУБД, middle-tier крутящий бизнес-компоненты, GUI-rich АРМы и т.п. Идет? Цитата trainer @ У меня нет желания продолжать с тобой дискуссию - не вижу смысла. Скажу только, что 99% производимых в мире процессоров - DSP и микроконтроллеры, доля Delphi в программировании для них - ноль целых ноль десятых процента. Ну поговори со мной, ну пожалуйста, а то я себе места не найду А могу еще подумать, что это проявление инфантилизма в отсутствие аргументов. Ведь я изначально говорил о преимуществах в секторе заказных enterprise-продуктов, а мне вдруг DSP стали тыкать. Цитата x0ras @ Будешь отрицать, что managed код медленнее? Причем здесь это, если мы говорили об оверхеде при смешивании managed/unmanaged кода. Цитата x0ras @ Сойдут. Ну и многие из них на C++ писались? Цитата x0ras @ Я не написал, что они были изначально на С++ написаны. Оба продукта были переписаны заново с использованием С++. А отсутствие компиляторов, например, нормально поддерживающих шаблоны, не говорит о полном их отсутствии. Тогда могу я предположить, что выбор C++ был помимо прочего связан с тем, что предшественники были написаны на C? Цитата x0ras @ Считаем объемы продаж (в денежном эквиваленте) задач, не требуемых стандартного GUI, требовательных к производительности и т.д. По моим наюлюдениям, начиная от сегментированных финансовых отчетов Microsoft и статистики различных онлайновых магазинов, настольное ПО уверенно лидирует. Цитата x0ras @ Очень простой пример - кроссплатформенный графический движок для мобильных и немобильных платформ. Так как в большинстве мобильных платформах нет поддержки вещественных чисел, то они эмулируются целочисленными. Ну так значит не происходит смешения типов и в дельфи эта задача легко решается с использованием алиасов. Цитата Flex Ferrum @ Что-то противоположная сторона притихла. Наверное, задачу придумывает. Очень странно слышать это от тебя, учитывая, что ты в курсе причины по которой я не могу в ближайшее время участвовать в дискуссии. А s-mike не может зайти в "директорию тебе известного проекта". Так в чем проблема это нетерпения? В общем вы тут пока без меня отдохните |
Сообщ.
#142
,
|
|
|
Цитата Guderian @ Что же касается известного нам проекта, то после гетласта я имею ругань на отсутствие geometry.h и hierarchy_gen.h, так что ничего сказать не могу. Засада... Будем разбираться. Цитата Guderian @ А зачем нам простенькие? Давай возьмем сложную систему с гетерогенной средой СУБД, middle-tier крутящий бизнес-компоненты, GUI-rich АРМы и т.п. Идет? Ух. Даа... Что-то мне подсказывает, что немалая часть из этого решается с помощью готовых контролов (для Delphi), о которых ты только что упомянул... Цитата Guderian @ Тогда могу я предположить, что выбор C++ был помимо прочего связан с тем, что предшественники были написаны на C? Как я тебе уже когда-то говорил, сделать кальку с С кода на С++ невозможно. Это при любом раскладе приведет к серьезному рефакторнигу всего продукта, и получится, что легче переписать большую его часть "с нуля". Цитата Guderian @ Ну так значит не происходит смешения типов и в дельфи эта задача легко решается с использованием алиасов. Тогда ждем решения (а от тебя - письма с датой, когда делал последний Get Last). Цитата Guderian @ Очень странно слышать это от тебя, учитывая, что ты в курсе причины по которой я не могу в ближайшее время участвовать в дискуссии. Тут я имел в виду s-mike'а, а не тебя. |
Сообщ.
#143
,
|
|
|
Цитата Guderian @ Цитата (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; Где кода меньше и код понятнее? |
Сообщ.
#144
,
|
|
|
Цитата s-mike @ Я красивое решение той вашей задачи придумывал. Первый вариант приянт. Вопросы: 1. Что есть такое Precision? 2. (если ответ на 1-ое - "глубина"), то где координата Z? 3. Судя по всему, я могу использовать либо 2D-фигуру с целочисленными координатами, либо 3D с вещественными координатами? 4. Как мне использовать это решение для описания объектов в n-мерном пространстве? Добавлено Приведу кальку с этого кода на С++ (для симметрии): Файл 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; //... |
Сообщ.
#145
,
|
|
|
Фиг его знает, зачем я назвал 2Д и 3Д, что-то в голову не то пришло. Названия классов поправил. Я имел ввиду именно обекты с целочисленными и вещественными координатами. Это там и реализовано. Precision - точность.
|
Сообщ.
#146
,
|
|
|
В С++ по сравнению с Паскалеи есть одно колоссальное удобство: возможность объявлять переменные в месте их использования и ограничивать область видимости блоками.
|
Сообщ.
#147
,
|
|
|
Цитата s-mike @ Фиг его знает, зачем я назвал 2Д и 3Д, что-то в голову не то пришло. Названия классов поправил. Ну тогда еще проще: template<class T> class Figure2D { public: T X, Y, Width, Height; }; |
Сообщ.
#148
,
|
|
|
Цитата Guderian @ Это бессмысленно. Ты предъявляешь тезисы. Когда тебе предъявляют контраргументы, ты меняешь тезисы и выясняется, что ты имел в виду другое. Когда у тебя заранее пытаются выяснить, что же ты имел в виду, ты говоришь, что это флуд.Ну поговори со мной Цитата Guderian @ Можешь думать что угодно. Это ты здесь воюешь(у тебя тут и языки осуждаемые), а я дискутировал. А могу еще подумать, что это проявление инфантилизма в отсутствие аргументов. |
Сообщ.
#149
,
|
|
|
Цитата Flex Ferrum @ Цитата (Guderian @ Сегодня, 10:11) Цитата А зачем нам простенькие? Давай возьмем сложную систему с гетерогенной средой СУБД, middle-tier крутящий бизнес-компоненты, GUI-rich АРМы и т.п. Идет? Ух. Даа... Что-то мне подсказывает, что немалая часть из этого решается с помощью готовых контролов (для Delphi), о которых ты только что упомянул... И потом. Скорость решения предлагаемого тобой типа задачи зависит далеко не от языка, а от выбранного инструментария. Сам посуди. Оно, конечно, можно пытаться реализовать все это и на ассемблере. Но если я возьму тот-же билдер, студию .NET, что-нибудь типа PowerBuilder и т. п., то дело пойдет гораздо быстрее. Только сдается мне (поправь, если я не прав) все дело сведется к связи некоторого количества готовых контролов между сбой с добавлением необходимой бизнес-логики, завязанной на уже готовые классы и компоненты. Ибо весь этот инструментарий стремиться к обозначенному мною (и ты с этим согласился) иделу - сборке системы из готовых компонент с минимальной программной доводкой. По этому я и говорю - язык в таких случаях существенной роли не играет - лишь бы позволял связно и без лишних выкрутасов излагать свои мысли. Но если ты можешь предолжить ральную задачу на кодирование из вышеобозначенного класса задач, то она, конечно же, будет принята к рассмотрению. |
Сообщ.
#150
,
|
|
|
Цитата Guderian @ Причем здесь это, если мы говорили об оверхеде при смешивании managed/unmanaged кода. При смешении managed/unmanaged кода нет оверхедов. Они могут возникать при преобразовании типов и неправильном выборе линкера развертываемого кода шаблонов. Надеюсь ты не будешь отрицать, что возможно написать библиотеку на С++ и использовать ее в любом .NET проекте, написав обертку. В С++ проекте для .NET я могу без извратов (оберток и лишнего геморроя) писать такой код прямо в проекте. Цитата Guderian @ Ну и многие из них на C++ писались? Что ты упорно хочешь доказать? Что: Цитата Guderian @ Так что получается? Они у нас результат реализации мощи С++ или просто волей истории переводимые на него с C? Ты считаешь, что все большие/серьезные продукты на С++ это волей истории переведенные с С, а сейчас ничего серьезного не пишется и никому не нужно? Или все что не БД и не ОС - это не серьезный продукт. Может стоит оглянутьтся вокруг деревни и увидеть, что помимо заказных enterprise-продуктов есть что-то еще? Цитата Guderian @ По моим наюлюдениям, начиная от сегментированных финансовых отчетов Microsoft и статистики различных онлайновых магазинов, настольное ПО уверенно лидирует. Из подобных отчетов и статистики можно делать вывод о мировом рынке всех продуктов, хоть как-то связанных с программированием? Сомневаюсь. Если это так, то цифры в студию! |