В комплекте 2 разных силанга (я там не знаю про базовые версии, по факту). 32-и битный поддерживает precompiled по дампу с одного файла, а 64-и битный не поддерживает вообще никакого.
Для 32 бит можно было бы сделать отдельное измерение... если бы эта шляпа корректно работала. Мои эксперименты показали, что более 1 раза силанг с прекомпайледами не справляется и обсыпается ошибками. Далее либо полный ребилд, либо удаление дампа вручную. В сумме получается, так же по времени.
Скорее всего там где-нибудь торчал "предкопилированный" хедер, куда была включена вообще вся стандартная библиотека
Какая разница что там торчало, если сравнение скорости одних и тех же сорсов, собирающихся под одинаковую платформу с одинаковыми ключами. Если и "торчит", то в обоих одинаково. Классика умудряется это пережевывать в 60 раз быстрее.
В принципе, если бы существовала бы какая-то форма precompiled-ов, то разница была бы "всего" раз в 10, наверное. Но 64-и битная версия не поддерживает вообще никакую форму precompiled. Ни классик-стайл по прагме, ни вижуал-стайл по заранее сохраненному слепку с одного файла.
И проблема при его использовании еще в том, что речь идет не о использовании абстрактного кода в вакууме, а про сборку VCL, которая тащит за собой очень много всегда.
Если бы силанг работал вменяемо быстро и был бы совместим по фичам с классикой, его наличие было бы оправдано и являлось бы премуществом (ну или достойной фичей) билдера. Пока это не так, его наличие на мой взгляд исключительно для галочки.
Учитывая, что силанг - это целевой тренд, возможно его допилят когда-то в будущем. Правда надеяться на это... сам билдер-то в рад-студии - это приставка к паскалю, а силанг это вторая производная :)
Я не путаю, я неточно выразился. В паскале невозможно разделить объявление и имплементацию. Это все должно быть в одном файле, "юните". Если имплементация занимает мегабайт - файл будет в мегабайт.
В шарпе-то как раз есть штатный синтаксис для разделения кода имплементации.
Остальной текст я просто не понял. То с чем Вы спорите я вообще нигде не писал.
Посмотрел... если честно, то всерьез сравнивать код на С, на 90% состоящий из инлайнов с чисто процедурным кодом на паскале... мне как-то бы даже в голову не пришло. Переведите весь С код в функции либо в паскале inline используйте. Иначе вообще непонятно что с чем сравниваем.
Это если вообще всерьез рассматривать пример из 3х вложенных циклов как базу для выводов о возможностях оптимизации. Что, на мой взгляд, несколько странно.
Когда-то давно, когда только появился perl, один мой товарищ, который им заболел, на примере синтетического парсера доказывал, что php быстрее С. В его случае, в сравнении с влоб написанным кодом на С ровно так и выходило. Но тогда все, даже он, воспринимали этот результат не более чем прикол.
ПС: Я не знаю как сейчас, а в свое время intel делал билиотеки для вижуала с очень быстрой математикой и у них даже был свой вариант компилятора. Если они все еще живы, то просто соберите любой сишный кусок из приведенного вами репозитория им (правда оно было жутко коммерческое, но вдруг найдете). Только наличие pow во внутренних циклах подсказывает мне, что этот кусок сразу взлетит по скорости в разы. Вопрос только в том, скажут ли эти новые цифры что-то о качестве оптимизации?...
Не соглашусь. По описанию проблемы казлы именно эппл. Это как взять сейчас и в винде запретить все 32битные приложения. Меньшее что меня при этом будет интересовать - это поддерживают там что-то отдельные компиляторы или нет. В макоси крошечная экосистема, конечно, но для меня, как потребителя, это все равно выглядит как форменное свинство.
Но Ваше негодование я вполне понимаю :) Хотя, все же, рассчитывать на что-либо от продукта, проходящего уже четвертую (вроде) стадию перепродажи я бы не стал уже на берегу. Другое дело дельфи, тут еще есть какая-то надежда на уверенность. Желаю Вам не получить фаталити с дельфи, когда маковцы опять развернут оглобли куда-нибудь :)
В таком ключе, если дельфи умеет прозрачно подключать файлы С в проект (последнее что явидел так не умело), этот подход вполне имеет право на жизнь.
Единственный момент из моего опыта молодости, когда сочинение всяких кейсов и их проверка на оптимизированность еще было интересно: чтобы получить оптимизированный код нужно уметь правильно писать исходный. Т.е. нужно понимать что и как может оптимизировать компилятор и в каких условиях это работает, а в каких нет. Если такие знания есть или есть желание их приобрести, то вполне разумная замена ручной оптимизации. Ее это заменить не сможет все равно, но будет значительно быстрее.
ПС: То что более навороченные компиляторы будут работать медленнее для меня не неожиданность. Неожиданным стало НАСКОЛЬКО медленнее. Для меня такая разница попросту ставит крест на использовании, хотя если речь идет о точечной оптимизации можно свести тормоза к вполне приемлемым.
Я же привел свой аналогичный пример. Я не знаю в какое время Вы выбирали средство, но тогда когда его смотрел я пол дня экспериментотв оказалось достаточным, чтобы его исключить. Я это и имел в виду, что Вы недостаточно ответственно подошли к выбору инструмента для долгосрочной разработки. Возможно это и не так, я Вас понял неправильно. Если на берегу все было (в реальности, а не в рекламе), шикарно, а потом блдер сломали, то в этом случае да, "казлы" и прочее. Но для справедливости стоило бы все же отметить что такие же точно "казлы" и маковцы, котрые сделали невозможным использование старого средства (если, опять же, я правильно понял проблему).
А другие средства - это другие. Если под набор критериев не подходит ничего, то нужно менять этот набор. Нет того что умеет одинаково и удобно, значит либо пишите на разном, либо миритесь с неудобствами, чтож поделать-то? Я как-то написал морду под мобилку для своего сервера вообще на LUA с помощью Corona. Случай, разумеется, очень далек от Вашего.
Сочуствую, но, на мой взгляд, Вы изначально выбрали неправильное средство. Нужно было либо сразу писать на дельфи, либо использовать вообще другие инструменты.
У меня была однажды сходная задача, только с андроидом. После рассмотрения того что и как делает билдер в плане многоплатформенности я поставил крест на билдере и потратил 2 недели на написание нативного приложения под андроид, о чем не жалею. Если бы сейчас встала аналогичная задача, то не думаю, что использование для этого билдера мне вообще пришло бы в голову.
Я же написал "средств уровня java", где Вы прочитали что их вообще нет? Хорошие анализаторы кода для явы на лету интерпретируют код, по мере его ввода, что позволяет добиться изумительной точности и адекватности советов по подстановке и замене. Если что-то подобное для С существует, то я этого не видел.
Во-первых, clang собирает не 12 секунд, а 12 минут! Во-вторых, опять-же, я нигде не писал что ЛЮБОЙ силанг будет рабоать так же. Наоборот, я даже явно написал что в той же вижуал студии он работает на порядо быстрее (в том числе из-за того что они прикрутили к нему precompiled). Смысл статьи же не в обзоре всех возможных вариантов, а в узком обзоре конкретного средства. Пока у embarcadero силанг чудовищно медленный, несовместимый с классикой и сам с собой.
Не помогла стать популярным на винде? А как наличип исходников в этом ему могло помочь? Он не может предложить ничего, ради чего его стоило бы предпочесть конкурентам.
Открыли исходники они вовсе не для набора популярности, а чтобы перейти в нишу специфических ОСей. К примеру я писал одно время под QNX (линуксоподобное микроядро под х86ю платформу). В нем единственный компилятор - это именно ватком. Есть еще некоторые места, где ватком используется. Возможно из-за того, что он оказался открытым в нужное время, или более дешовым или еще что.
В последней студии, которую я трогал силанг был именно дефолтным компиллером.
А фронты - это: поддержка всех прагм и ключевых слов именно в вижуальном их синтаксисе и значении, полная поддержка вижуальных ключей строчником. Он даже определяется как __MSVC__, в от личии от билдера, где __BRLANDC и __clang - это 2 разных компирера. А то что оно там не самый свежий стандарт поддерживает, мне глубоко по барабану, если честно. Добавят потихоньку и при лбом раскладе это случится гораздо раньше чем у Embarcadero.
А в остальном... а зачем вообще комментить, если текущее средство Вы не видели и его описанны особенностей не знаете?
У меня ровно та же проблема: зависимость от либо умершего, либо модифицированного до несовместимости паскалевского кода. Трата времени на переписывание с нуля всех этих кусков не опревдана.
К сожалению специфика моих программ не дает возможности дописывать что-либо на том же C# или чем-то еще. Чтобы это сделать придется практически переписать заново все, что было создано за последние лет 20. Вот и сижу где сижу :)
VCL не является "прямой надстройкой над API". Наоборот, одна из целей ее создания была именно в расширении количества возможных компонентов до бесконечности. TWinComponent - это только одна из веток раследования TComponent-а и, не самая многочисленная по наследникам.
Я не помню уже как в чикаге, а в Windows 3.x было ограничение на число контрололв наследников в 250 штук. Я упирался в это ограничение еще на поминаемом вами OWL на Borland C++ 4 for Windows. Второй момент - это то, что если посмотреть ресурсы любого более-менее сложного приложения тех времен, то они на 90% состояли из плейсхолдеров, котрые отрисовывались и обрабатывались программно. Именно из-за ограничений и скудности АПИ все эти OWL и MFC вымерли, а VCL решало все эти проблемы.
Бум компонентов случившийся в те времена обясняется очень просто, и никакого отношения к каим-то концепциям это не имело. Наконец-то стало возможным следующее: а) передача своего кода другим людям, у которых он будет работать вообще без каких-то условий, абсолютно прозрачно и внедрять его очень легко. Аналогов этому не было та тот момент вообще. б) Наконец-то появилась возможность создавать произвольное число кастомных контролов, опять-же, с очень прозрачным их переиспользованием и, основное: в) VCL в своей среде разработки, за счет дизайнера и инспектора, позволял использовать компоненты с намного меньшими усилиями. Для полно-фнкционального их использования, как правило, не нужна была даже никакая документация т.к. property и events описывали почти весь функционал компонента и их не нужно было было запоминать, а их назначение было очевидным без описаний. К слову: все это сохраняет актуальность до сих пор :)
Отказ от множественного наследования в паскале был вовсе не из-за того что "они не смогли" или "были позже". Ровно наоборот. К этому моменту уже была изобретена ява, в котороой ООП было доведено до абсурда и именно в те времена уже начинали задумываться о том, что не все идеи ведут в рай. Отказ от множественного наследования в паскеле был введен сознательно. В том числе для того, чтобы обеспечить гарантированность преобразования типов, что в случае с множественным наследованием просто невозможно.
Firemonkey не является концепцией и не собиралась ей становится никогда. Она была написана энтузиастами (если не ошибаюсь, даже русскими), для решения простой задачи: позволить использовать мощь графической карты для отображения интерфейса. С анимациями, прозначностями, градиентами и прочими понтами, котрые были практически недоступны в классической реализации объектов VCL. Основная ее задача было в реализации всего этого при сохранении интуитивности использования. Т.е. Firemonkey что-то типа WPF в сравнении с WinForms если сравнивать с C#, или что-то типа Android для мира linux (если Вы понимаете о чем речь). Далее ее купили, развивали и получили то что получили. Идея была гениальной и, если я правильно помню, первой в своем роде. Не повезло с "продюсером", на мой взгляд. Если бы ее купил не борланд, а микрософт, то мир C# сейчас был бы совсем другим.
Паскаль - это язык, с одной стороны лишенный попугайской зависимости отконкурентов и, с другой, не страдающий от самопровозглашенных стандартов. Он сам себе конкурент и сам себе стандарт. К счастью, люди которые определяют его развитие достаточно адекватны, чтобы не тащить, как вороны все блестящее в одну кучу мучительно воюя с рассыпающейся песчаной башней, как это происходит в С. Результатом, к примеру, является то, что уровень владения инструментарием среди паскалистов на порядки выше, чем в среде С разработчиков. Т.е. людей, которые понимают как оно работает, какие техники оптимально использовать и где, на порядок выше. Я это все к тому, что, возможно, то, что в нем нет перегрузки скобочек и операторов это к лучшему.
Не очень понимаю о какой опитимизации паскаля с помощью С Вы пишете. Либы Вы не очень понимаете :)
Касательно встроенного АСМа дельфи намного мощнее и удобнее чем С и, если иметь в виде такую оптимизацию, то гораздо логичнее, наоборот, реализовавыть ее на паскале.
Если же Вы почему-то считаете, что код на С будет более оптимальным сам по себе, то дело обстоит ровно наоборот. Из-за архитектуры паскаля код, котрый генерит компилер, будет в большинстве случаев компактнее и, часто, быстрее аналогичной реализации на С.
Вы очень поверхностно знакомы либо с С#, либо с VCL. Общего у этих идеалогий практически нет. Сильно вводит в заблуждение что и там и там есть какая-то форма и какие-то компоненты, которые вроде бы можно перетаскивать мышкой (в случае WinForms, в WPF уже даже это не так), но эта похожесть - заблуждение. Под капотом они работают абсолютно по разному.
Различие настолько большое, что если пытаться писать в том же С# опираясь на свой опыт VCL, то быдет очень тяжело. Придется сильно переучиваться.
Те что я видел были крайне тупы. Вернее так: они полностью ломались при использовании сложных макросов, а это один из мощнейших инструментов в С.
Второе, что делало подобные инструменты практически бесполезными - это условная компиляция.
Если учесть еще и то, что крайне редко дело ограничивается одним единственным заголовочным файлом, чаще их несколько, связанных друг с другом, а в паскале жесткие ограничения на модульность, то я не видел средства, которое бы позволяло создать готовые описания в сколько-нибудь сложных условиях.
В комплекте 2 разных силанга (я там не знаю про базовые версии, по факту). 32-и битный поддерживает precompiled по дампу с одного файла, а 64-и битный не поддерживает вообще никакого.
Для 32 бит можно было бы сделать отдельное измерение... если бы эта шляпа корректно работала. Мои эксперименты показали, что более 1 раза силанг с прекомпайледами не справляется и обсыпается ошибками. Далее либо полный ребилд, либо удаление дампа вручную. В сумме получается, так же по времени.
Какая разница что там торчало, если сравнение скорости одних и тех же сорсов, собирающихся под одинаковую платформу с одинаковыми ключами. Если и "торчит", то в обоих одинаково. Классика умудряется это пережевывать в 60 раз быстрее.
В принципе, если бы существовала бы какая-то форма precompiled-ов, то разница была бы "всего" раз в 10, наверное. Но 64-и битная версия не поддерживает вообще никакую форму precompiled. Ни классик-стайл по прагме, ни вижуал-стайл по заранее сохраненному слепку с одного файла.
И проблема при его использовании еще в том, что речь идет не о использовании абстрактного кода в вакууме, а про сборку VCL, которая тащит за собой очень много всегда.
Да.
Если бы силанг работал вменяемо быстро и был бы совместим по фичам с классикой, его наличие было бы оправдано и являлось бы премуществом (ну или достойной фичей) билдера. Пока это не так, его наличие на мой взгляд исключительно для галочки.
Учитывая, что силанг - это целевой тренд, возможно его допилят когда-то в будущем. Правда надеяться на это... сам билдер-то в рад-студии - это приставка к паскалю, а силанг это вторая производная :)
Я не путаю, я неточно выразился. В паскале невозможно разделить объявление и имплементацию. Это все должно быть в одном файле, "юните". Если имплементация занимает мегабайт - файл будет в мегабайт.
В шарпе-то как раз есть штатный синтаксис для разделения кода имплементации.
Остальной текст я просто не понял. То с чем Вы спорите я вообще нигде не писал.
Серьезно? Т.е. вы считаете, что убирав ключевое слово, но оставив тело в структуре Вы избавились от инлайна? Вы где учились?
Впрочем бог с ним. Спорить с Вашим мнением я не хочу.
Посмотрел... если честно, то всерьез сравнивать код на С, на 90% состоящий из инлайнов с чисто процедурным кодом на паскале... мне как-то бы даже в голову не пришло. Переведите весь С код в функции либо в паскале inline используйте. Иначе вообще непонятно что с чем сравниваем.
Это если вообще всерьез рассматривать пример из 3х вложенных циклов как базу для выводов о возможностях оптимизации. Что, на мой взгляд, несколько странно.
Когда-то давно, когда только появился perl, один мой товарищ, который им заболел, на примере синтетического парсера доказывал, что php быстрее С. В его случае, в сравнении с влоб написанным кодом на С ровно так и выходило. Но тогда все, даже он, воспринимали этот результат не более чем прикол.
ПС: Я не знаю как сейчас, а в свое время intel делал билиотеки для вижуала с очень быстрой математикой и у них даже был свой вариант компилятора. Если они все еще живы, то просто соберите любой сишный кусок из приведенного вами репозитория им (правда оно было жутко коммерческое, но вдруг найдете). Только наличие pow во внутренних циклах подсказывает мне, что этот кусок сразу взлетит по скорости в разы. Вопрос только в том, скажут ли эти новые цифры что-то о качестве оптимизации?...
Не соглашусь. По описанию проблемы казлы именно эппл. Это как взять сейчас и в винде запретить все 32битные приложения. Меньшее что меня при этом будет интересовать - это поддерживают там что-то отдельные компиляторы или нет. В макоси крошечная экосистема, конечно, но для меня, как потребителя, это все равно выглядит как форменное свинство.
Но Ваше негодование я вполне понимаю :) Хотя, все же, рассчитывать на что-либо от продукта, проходящего уже четвертую (вроде) стадию перепродажи я бы не стал уже на берегу. Другое дело дельфи, тут еще есть какая-то надежда на уверенность. Желаю Вам не получить фаталити с дельфи, когда маковцы опять развернут оглобли куда-нибудь :)
В таком ключе, если дельфи умеет прозрачно подключать файлы С в проект (последнее что явидел так не умело), этот подход вполне имеет право на жизнь.
Единственный момент из моего опыта молодости, когда сочинение всяких кейсов и их проверка на оптимизированность еще было интересно: чтобы получить оптимизированный код нужно уметь правильно писать исходный. Т.е. нужно понимать что и как может оптимизировать компилятор и в каких условиях это работает, а в каких нет. Если такие знания есть или есть желание их приобрести, то вполне разумная замена ручной оптимизации. Ее это заменить не сможет все равно, но будет значительно быстрее.
ПС: То что более навороченные компиляторы будут работать медленнее для меня не неожиданность. Неожиданным стало НАСКОЛЬКО медленнее. Для меня такая разница попросту ставит крест на использовании, хотя если речь идет о точечной оптимизации можно свести тормоза к вполне приемлемым.
Я же привел свой аналогичный пример. Я не знаю в какое время Вы выбирали средство, но тогда когда его смотрел я пол дня экспериментотв оказалось достаточным, чтобы его исключить. Я это и имел в виду, что Вы недостаточно ответственно подошли к выбору инструмента для долгосрочной разработки. Возможно это и не так, я Вас понял неправильно. Если на берегу все было (в реальности, а не в рекламе), шикарно, а потом блдер сломали, то в этом случае да, "казлы" и прочее. Но для справедливости стоило бы все же отметить что такие же точно "казлы" и маковцы, котрые сделали невозможным использование старого средства (если, опять же, я правильно понял проблему).
А другие средства - это другие. Если под набор критериев не подходит ничего, то нужно менять этот набор. Нет того что умеет одинаково и удобно, значит либо пишите на разном, либо миритесь с неудобствами, чтож поделать-то? Я как-то написал морду под мобилку для своего сервера вообще на LUA с помощью Corona. Случай, разумеется, очень далек от Вашего.
Сочуствую, но, на мой взгляд, Вы изначально выбрали неправильное средство. Нужно было либо сразу писать на дельфи, либо использовать вообще другие инструменты.
У меня была однажды сходная задача, только с андроидом. После рассмотрения того что и как делает билдер в плане многоплатформенности я поставил крест на билдере и потратил 2 недели на написание нативного приложения под андроид, о чем не жалею. Если бы сейчас встала аналогичная задача, то не думаю, что использование для этого билдера мне вообще пришло бы в голову.
Я же написал "средств уровня java", где Вы прочитали что их вообще нет? Хорошие анализаторы кода для явы на лету интерпретируют код, по мере его ввода, что позволяет добиться изумительной точности и адекватности советов по подстановке и замене. Если что-то подобное для С существует, то я этого не видел.
Во-первых, clang собирает не 12 секунд, а 12 минут! Во-вторых, опять-же, я нигде не писал что ЛЮБОЙ силанг будет рабоать так же. Наоборот, я даже явно написал что в той же вижуал студии он работает на порядо быстрее (в том числе из-за того что они прикрутили к нему precompiled). Смысл статьи же не в обзоре всех возможных вариантов, а в узком обзоре конкретного средства. Пока у embarcadero силанг чудовищно медленный, несовместимый с классикой и сам с собой.
Не помогла стать популярным на винде? А как наличип исходников в этом ему могло помочь? Он не может предложить ничего, ради чего его стоило бы предпочесть конкурентам.
Открыли исходники они вовсе не для набора популярности, а чтобы перейти в нишу специфических ОСей. К примеру я писал одно время под QNX (линуксоподобное микроядро под х86ю платформу). В нем единственный компилятор - это именно ватком. Есть еще некоторые места, где ватком используется. Возможно из-за того, что он оказался открытым в нужное время, или более дешовым или еще что.
В последней студии, которую я трогал силанг был именно дефолтным компиллером.
А фронты - это: поддержка всех прагм и ключевых слов именно в вижуальном их синтаксисе и значении, полная поддержка вижуальных ключей строчником. Он даже определяется как __MSVC__, в от личии от билдера, где __BRLANDC и __clang - это 2 разных компирера. А то что оно там не самый свежий стандарт поддерживает, мне глубоко по барабану, если честно. Добавят потихоньку и при лбом раскладе это случится гораздо раньше чем у Embarcadero.
А в остальном... а зачем вообще комментить, если текущее средство Вы не видели и его описанны особенностей не знаете?
У меня ровно та же проблема: зависимость от либо умершего, либо модифицированного до несовместимости паскалевского кода. Трата времени на переписывание с нуля всех этих кусков не опревдана.
К сожалению специфика моих программ не дает возможности дописывать что-либо на том же C# или чем-то еще. Чтобы это сделать придется практически переписать заново все, что было создано за последние лет 20. Вот и сижу где сижу :)
Именно в этом и была мысь: зачем на билдере вообще что-то кроме классики? Все остальные делают это лучше и быстрее.
Мой ответ на это в статье: Embarcadero не может.
Ой, ой, ой как у Вас все неправильно! :)
VCL не является "прямой надстройкой над API". Наоборот, одна из целей ее создания была именно в расширении количества возможных компонентов до бесконечности. TWinComponent - это только одна из веток раследования TComponent-а и, не самая многочисленная по наследникам.
Я не помню уже как в чикаге, а в Windows 3.x было ограничение на число контрололв наследников в 250 штук. Я упирался в это ограничение еще на поминаемом вами OWL на Borland C++ 4 for Windows. Второй момент - это то, что если посмотреть ресурсы любого более-менее сложного приложения тех времен, то они на 90% состояли из плейсхолдеров, котрые отрисовывались и обрабатывались программно. Именно из-за ограничений и скудности АПИ все эти OWL и MFC вымерли, а VCL решало все эти проблемы.
Бум компонентов случившийся в те времена обясняется очень просто, и никакого отношения к каим-то концепциям это не имело. Наконец-то стало возможным следующее: а) передача своего кода другим людям, у которых он будет работать вообще без каких-то условий, абсолютно прозрачно и внедрять его очень легко. Аналогов этому не было та тот момент вообще. б) Наконец-то появилась возможность создавать произвольное число кастомных контролов, опять-же, с очень прозрачным их переиспользованием и, основное: в) VCL в своей среде разработки, за счет дизайнера и инспектора, позволял использовать компоненты с намного меньшими усилиями. Для полно-фнкционального их использования, как правило, не нужна была даже никакая документация т.к. property и events описывали почти весь функционал компонента и их не нужно было было запоминать, а их назначение было очевидным без описаний. К слову: все это сохраняет актуальность до сих пор :)
Отказ от множественного наследования в паскале был вовсе не из-за того что "они не смогли" или "были позже". Ровно наоборот. К этому моменту уже была изобретена ява, в котороой ООП было доведено до абсурда и именно в те времена уже начинали задумываться о том, что не все идеи ведут в рай. Отказ от множественного наследования в паскеле был введен сознательно. В том числе для того, чтобы обеспечить гарантированность преобразования типов, что в случае с множественным наследованием просто невозможно.
Firemonkey не является концепцией и не собиралась ей становится никогда. Она была написана энтузиастами (если не ошибаюсь, даже русскими), для решения простой задачи: позволить использовать мощь графической карты для отображения интерфейса. С анимациями, прозначностями, градиентами и прочими понтами, котрые были практически недоступны в классической реализации объектов VCL. Основная ее задача было в реализации всего этого при сохранении интуитивности использования. Т.е. Firemonkey что-то типа WPF в сравнении с WinForms если сравнивать с C#, или что-то типа Android для мира linux (если Вы понимаете о чем речь). Далее ее купили, развивали и получили то что получили. Идея была гениальной и, если я правильно помню, первой в своем роде. Не повезло с "продюсером", на мой взгляд. Если бы ее купил не борланд, а микрософт, то мир C# сейчас был бы совсем другим.
Паскаль - это язык, с одной стороны лишенный попугайской зависимости отконкурентов и, с другой, не страдающий от самопровозглашенных стандартов. Он сам себе конкурент и сам себе стандарт. К счастью, люди которые определяют его развитие достаточно адекватны, чтобы не тащить, как вороны все блестящее в одну кучу мучительно воюя с рассыпающейся песчаной башней, как это происходит в С. Результатом, к примеру, является то, что уровень владения инструментарием среди паскалистов на порядки выше, чем в среде С разработчиков. Т.е. людей, которые понимают как оно работает, какие техники оптимально использовать и где, на порядок выше. Я это все к тому, что, возможно, то, что в нем нет перегрузки скобочек и операторов это к лучшему.
Welcome! :)
Не очень понимаю о какой опитимизации паскаля с помощью С Вы пишете. Либы Вы не очень понимаете :)
Касательно встроенного АСМа дельфи намного мощнее и удобнее чем С и, если иметь в виде такую оптимизацию, то гораздо логичнее, наоборот, реализовавыть ее на паскале.
Если же Вы почему-то считаете, что код на С будет более оптимальным сам по себе, то дело обстоит ровно наоборот. Из-за архитектуры паскаля код, котрый генерит компилер, будет в большинстве случаев компактнее и, часто, быстрее аналогичной реализации на С.
Вы очень поверхностно знакомы либо с С#, либо с VCL. Общего у этих идеалогий практически нет. Сильно вводит в заблуждение что и там и там есть какая-то форма и какие-то компоненты, которые вроде бы можно перетаскивать мышкой (в случае WinForms, в WPF уже даже это не так), но эта похожесть - заблуждение. Под капотом они работают абсолютно по разному.
Различие настолько большое, что если пытаться писать в том же С# опираясь на свой опыт VCL, то быдет очень тяжело. Придется сильно переучиваться.
Те что я видел были крайне тупы. Вернее так: они полностью ломались при использовании сложных макросов, а это один из мощнейших инструментов в С.
Второе, что делало подобные инструменты практически бесполезными - это условная компиляция.
Если учесть еще и то, что крайне редко дело ограничивается одним единственным заголовочным файлом, чаще их несколько, связанных друг с другом, а в паскале жесткие ограничения на модульность, то я не видел средства, которое бы позволяло создать готовые описания в сколько-нибудь сложных условиях.
Есть такие?