Комментарии 128
Кто-нибудь помнит Microsoft Pascal? А Microsoft C (без приставки Visual)?.
Я помню MS QuickC. Помещался на дискетку.. По скорости сборки уделывал в разы борланда. При запуске в пробирке пробирки для дос (среды DOS в OS/2 под VBOX) по прежнему уделывает всё, что шевелится Да, хелп там был и быстрый, и понятный, в отличии от багланда.. Не QuickC. тоже помню, но с трудом. 6 версия, 7ая вроде уже стала называться Visual
У-у-у, так ты поди еще и с Наполеоном повоевать успел?
Подпишусь под каждым словом, особенно про паскаль и справочник
Правильно помнишь. Еще оба эти компилера были первыми, котрые имели серьезную, шокирующую по тем временам, оптимизацию кода.
Семантик запомнился еще тем, что имел уникальные библиотеки, для той же графики, математики и писания резидентов, когда ризидентом висело только ядро, а вункционал подгружался при импользовании.
Как то обойдена вниманием компонентная база.
Что там нового в компонентах, что нового в VCL , в RTL в Alexandria?
Что можно сделать в бесплатной версии C++Builder Community Edition?
Когда я пользовал Builder, то всегда приходилось использовать гибридный способ редактирования: основную массу работы по вводу текстов делал в SlickEdit, контекстный выбор методов, классы и проч. делал в IDE билдера. Оба редактора умеют подхватывать сторонние изменения поэтому все получалось довольно складно.
Гибридный метод очень характерен при разработке встраиваемых систем, поскольку такие IDE как Keil или IAR тоже очень бедны в плане функциональности редактирования и приходится использовать сторонние редакторы.
Clang имеет «гнусные» корни
Вы ошибаетесь, хоть у Clang и GCC совместимые аргументы командной строки, это два абсолютно разных продукта с разными кодовыми базами, разным внутренним устройством, разными лицензиями и разным происхождением.
Он существенно отстает по всем могущим прийти в голову фронтам от аналога, используемого Microsoft
Приведите пример хотя бы одного такого фронта. Сишный компилятор от ms поддержкой стандарта C11 обзавёлся только в 2020 году, это же посмешище, а не компилятор.
По поводу жалоб на скорость Clang - а в нынешнем сибильдере есть возможность использовать предкомпилированные заголовки? Уверен, это ускорит компиляцию (если, конечно, эта возможность там есть; последний сибильдер, который я трогал вживую, был версии 6.0, и там ничего подобного, конечно, не было).
Приведите пример хотя бы одного такого фронта
В последней студии, которую я трогал силанг был именно дефолтным компиллером.
А фронты - это: поддержка всех прагм и ключевых слов именно в вижуальном их синтаксисе и значении, полная поддержка вижуальных ключей строчником. Он даже определяется как __MSVC__, в от личии от билдера, где __BRLANDC и __clang - это 2 разных компирера. А то что оно там не самый свежий стандарт поддерживает, мне глубоко по барабану, если честно. Добавят потихоньку и при лбом раскладе это случится гораздо раньше чем у Embarcadero.
А в остальном... а зачем вообще комментить, если текущее средство Вы не видели и его описанны особенностей не знаете?
А фронты - это: поддержка всех прагм и ключевых слов именно в вижуальном их синтаксисе и значении, полная поддержка вижуальных ключей строчником
А, ну то есть совместимость с нестандартными расширениями Microsoft вами считается плюсом? Стратегия трёх E в действии, да.
Не защищаю позицию автора поста. Clang поддерживает как многие расширения GCC, так и многие расширения MSVC, что упрощает портирование кода, написанного изначально под один из этих компиляторов. Это большой плюс Clang, хоть совместимость и не полная.
Разумеется плюсом.
Не все раз в неделю пишут новую курсовую с нуля. В своем тексте я подразумеваю разработчиков, делающих долгосрочные проекты. Средство, которое они используют может развиваться, но не меняться. Разницу понимаете?
Cишный компилятор от ms поддержкой стандарта C11 обзавёлся только в 2020 году
Вроде в 2015
Статья в девблоге Microsoft утверждает, что официальная полная поддержка появилась 2020.
это же посмешище, а не компилятор.Зря вы так. У Microsoft C++ в приоритете, и по поддержке C++20 он опережает всех остальных.
По Clang-компилятору очень жёстко проехали, учитывая, что лозунг C++Builder 11 -- Build Native Windows C++ and iOS Apps 10x Faster with Less Code.
А есть ли хоть какие-то преимущества у C++Builder перед Delphi для Windows-разработки? Если бы волшебным образом ваш легаси-код был бы конвертирован в Delphi, вы бы предпочли с ним работать, или остались бы с C++?
Могу сказать для Delphi VCL проектов, сейчас для меня основным вызовом является корректный переход на HighDPI. По усилиям внедрение High DPI, а заодно и векторных иконок вместо растровых в интерфейсе, сопоставимо с переходом на Unicode. Но оно несомненно стоит того.
Попробую ответить за автора. Да, C++ Builder удобнее дельфей, когда надо залезть в низкоуровневые системные дебри, например, руками импортировать какую-нибудь из коробки недоступную функцию WinAPI. В остальном примерно все то же самое.
Вообще-то Делфи легко и просто импортирует функции winapi. Также просто. Название функции, ее название в экспорте dll и название dll. Готово. Одна строка. Если надо, описываем и структуру, если таковая передается в параметрах по указателю
Правды ради структуру для билдера описывать не надо, т.к. инклюдник подключается без танцев с бубном.
Правды ради, есть инструмент для генерации модуля pas из хидеров)
Те что я видел были крайне тупы. Вернее так: они полностью ломались при использовании сложных макросов, а это один из мощнейших инструментов в С.
Второе, что делало подобные инструменты практически бесполезными - это условная компиляция.
Если учесть еще и то, что крайне редко дело ограничивается одним единственным заголовочным файлом, чаще их несколько, связанных друг с другом, а в паскале жесткие ограничения на модульность, то я не видел средства, которое бы позволяло создать готовые описания в сколько-нибудь сложных условиях.
Есть такие?
А есть ли хоть какие-то преимущества у C++Builder перед Delphi для Windows-разработки?
Если рассуждать в принципе, то таких преимуществ одно - это возможность использовать АПИ напрямую, без его заново. Это касается как самого виндового АПИ, так львиной доли сторонних библиотек, т.к. процент чего-то стоящего написанного на паскале, в сравнении с С - незначителен.
Если же рассматривать только создание приложений, где полностью хватает функционала VCL, то преимуществ я не вижу. Только архитектурные, связанные с различиями языков в принципе.
был бы конвертирован в Delphi, вы бы предпочли с ним работать, или остались бы с C++?
Это два разных языка. Рассматривать переход с одного на другой разумно только если один из них предоставляет какие-то средства, вообще не реализуемые в другом.
К примеру, в свое время одним из критериев перехода на С для меня стала практически полная невозможность в паскале использовать ни ассемблер, ни код из С. Т.е. в те времена, если под что-то не было TPU (то что в дельфи DCU), то ты не можешь это реализовать практически никак. А в те времена как раз играли в видео с прямым доступом к памяти, перекодировали тектовый кодогенератор, чтобы сделать "графическую мышь в тексте", пимали резидентов и прочее.
Сейчас возможность средств различается не принципиально. Да и язык этот мне уже не нравится. Меня бесит подход "один класс - один файл". С ужасом смотрю на компоненты дельфи, пипа инспектора объектов, котрые занмают мегабайт одним файлом. Я так думать уже разучился :)
Путаете вы Делфи и Шарп. В делфи нет правила и ни кто не делает "один файл - один класс". В шарпе как раз это типично.
И код на асм в Делфи можно писать напрямую. Не знаю уж, в какой версии вы писали, но эта возможность существует наверно с первых версий языка.
Ну а по поводу компонентов вообще не понятна претензия. Речь о разметке? Ну и в разметку лезть нет ни какого смысла. Можно считать этот файл бинарным, потому что он полностью управляется средой.
Ну и если речь о различии, то в делфи есть кроссплатформенный фреймворк с возможностью одно и то же приложение нативно запускать на почти любой платформе. Не внося изменений в код. Просто переключая вариант сборки
Я не путаю, я неточно выразился. В паскале невозможно разделить объявление и имплементацию. Это все должно быть в одном файле, "юните". Если имплементация занимает мегабайт - файл будет в мегабайт.
В шарпе-то как раз есть штатный синтаксис для разделения кода имплементации.
Остальной текст я просто не понял. То с чем Вы спорите я вообще нигде не писал.
В паскале (Delphi) легко и просто можно описать класс в одном файле частично и расширить его интерфейсами, классы для которых описаны в других файлах или вообще в dll.
Достаточно сказать, что класс реализует этот функционал
TMyClass = class(TObject, IMyInterface)И объявить свойство такого вида
property MyInterface: IMyInterface read FMyInterface implements IMyInterface;После чего нам не нужно в этом классе реализовать методы интерфейса, а взять их в любом другом классе. В том числе, как я уже сказал выше, загрузить класс из dll динамически
Ничего не понял. Зачем какие-то свойства из интерфейсов, кто их будет использовать? Как можно создать финальный класс без реализации? В каких других файлах и длл-ах?
Поясню что я имел в виду. Я пишу наследника какого-нить TWinControl. Мне его нужно использовать напрямую, т.е. создавать объекты такого класса. Как мне помогут какие-то интерфейсы разделить код реализации этого класса на несколько файлов?
Это не свойства из интерфейса, это добавление функционала класса из другого класса. Свойством ты лишь подключаешь нужный тебе класс, который реализует указанный интерфейс.
Все методы будут доступны напрямую, а не через обращение к свойству.
Я знаком с концепцией интерфейсов :)
Вопрос был в другом: зачем они вообще нужны в описанной мной задаче и как они позволят разделить код физически, если предположить (на практике так оно и есть), что логически он не разделим.
Если часть класса описал ты у себя, а другую часть класса взял из dll это не разделение?
Если класс описал ты в файле м1, а другой класс в файле м2, а затем через интерфейс их объединил это не разделение?
Да разделение, конечно. Но, ИМХО, выглядит, как интересный способ почесать правое ухо левой пяткой
Ну, по крайней мере, по сравнению с C#
Если класс описал ты в файле м1, а другой класс в файле м2, а затем через интерфейс их объединил это не разделение?
Подразумевается вто в м1 и м2 реализации интерфейсов?
Да такой подход к разделению возможен. Оптимален в бесконечно малом числе случаев, а остальные делятся на 2 варианта: либо количество оверхера будет превышать кодирование, либо это вообще не выполнимо т.к. в реализации нужно оперировать prtected-ными члемами базы.
Учитывая все это я и написал что невозможно. Не в теории. На практике.
Конечно спорить можно бесконечно, но я вижу тут одну прослеживаемую нить. Вся твоя "претензия" основывается именно на проблемах шарпа, т.к. описывая класс ты его сразу реализуешь, т.е. всё в кучу и навигация просто напросто не помогает. В то время как в Паскале ты четко разделяешь описание класса и его реализацию изначально. Открыва модуль с классом (или даже классами) ты можешь без проблем увидеть что содержит класс не сворачивая блоки с помощью редактора и не копаясь в куче кода.
А есть ли хоть какие-то преимущества у C++Builder перед Delphi для Windows-разработки?
Я думал об использовании C-Builder в дополнение к Дельфи для оптимизации узких мест. То есть основная программа на Дельфи (более простой и приятный язык), а то, что раньше делалось ассемблерными вставками, делается функциями на Си (который всё-таки более читабельный по сравнению с ассемблером). Си как замена ассемблеру - назад в 1970-е :)
Но это имеет смысл только если вам нужна вот такая суровая оптимизация, с ассемблерными или сишными вставками. Для большинства Дельфи-проектов (разного рода морд к БД) - очевидно, не нужна.
И C-Builder в конечном итоге оказался для этого неудобен, использую сишный код через dll, собранную CodeBlocks и Clang/gcc.
Не очень понимаю о какой опитимизации паскаля с помощью С Вы пишете. Либы Вы не очень понимаете :)
Касательно встроенного АСМа дельфи намного мощнее и удобнее чем С и, если иметь в виде такую оптимизацию, то гораздо логичнее, наоборот, реализовавыть ее на паскале.
Если же Вы почему-то считаете, что код на С будет более оптимальным сам по себе, то дело обстоит ровно наоборот. Из-за архитектуры паскаля код, котрый генерит компилер, будет в большинстве случаев компактнее и, часто, быстрее аналогичной реализации на С.
Я собирался использовать не классический компилятор Билдера, конечно, а как раз Clang-based. Который по идее должен уметь векторизацию, развёртку циклов, эффективный инлайн - во всяком случае оригинальный Clang умеет.
И тормозит он не (не только) потому, что у разработчиков руки кривые, а потому что там гораздо более сложная оптимизация.
В таком ключе, если дельфи умеет прозрачно подключать файлы С в проект (последнее что явидел так не умело), этот подход вполне имеет право на жизнь.
Единственный момент из моего опыта молодости, когда сочинение всяких кейсов и их проверка на оптимизированность еще было интересно: чтобы получить оптимизированный код нужно уметь правильно писать исходный. Т.е. нужно понимать что и как может оптимизировать компилятор и в каких условиях это работает, а в каких нет. Если такие знания есть или есть желание их приобрести, то вполне разумная замена ручной оптимизации. Ее это заменить не сможет все равно, но будет значительно быстрее.
ПС: То что более навороченные компиляторы будут работать медленнее для меня не неожиданность. Неожиданным стало НАСКОЛЬКО медленнее. Для меня такая разница попросту ставит крест на использовании, хотя если речь идет о точечной оптимизации можно свести тормоза к вполне приемлемым.
Из-за архитектуры паскаля код, котрый генерит компилер, будет в большинстве случаев компактнее и, часто, быстрее аналогичной реализации на С.
Это какое то безосновательное заблуждение.
Для начала, код от компилятора Дельфи х64 10.3 почти втрое быстрее, чем тот же код от Дельфи х32. 26сек vs 71с
При этих же условиях, код от современного С-компилятора укладывается в 11с.
Исходники доступны - проверьте у себя.
Посмотрел... если честно, то всерьез сравнивать код на С, на 90% состоящий из инлайнов с чисто процедурным кодом на паскале... мне как-то бы даже в голову не пришло. Переведите весь С код в функции либо в паскале inline используйте. Иначе вообще непонятно что с чем сравниваем.
Это если вообще всерьез рассматривать пример из 3х вложенных циклов как базу для выводов о возможностях оптимизации. Что, на мой взгляд, несколько странно.
Когда-то давно, когда только появился perl, один мой товарищ, который им заболел, на примере синтетического парсера доказывал, что php быстрее С. В его случае, в сравнении с влоб написанным кодом на С ровно так и выходило. Но тогда все, даже он, воспринимали этот результат не более чем прикол.
ПС: Я не знаю как сейчас, а в свое время intel делал билиотеки для вижуала с очень быстрой математикой и у них даже был свой вариант компилятора. Если они все еще живы, то просто соберите любой сишный кусок из приведенного вами репозитория им (правда оно было жутко коммерческое, но вдруг найдете). Только наличие pow во внутренних циклах подсказывает мне, что этот кусок сразу взлетит по скорости в разы. Вопрос только в том, скажут ли эти новые цифры что-то о качестве оптимизации?...
Там весь код написан в едином стиле для разных языков (порт с единого исходника). Можете выбрать для теста удобную себе, а не абстрактно рассуждать о высоком. Вот, без инлайнов и тоже менее 11сек (хотя чем ключевое слово inline мешает? тот же билдер втыкает близкий аналог __fastcall где только можно)
Серьезно? Т.е. вы считаете, что убирав ключевое слово, но оставив тело в структуре Вы избавились от инлайна? Вы где учились?
Впрочем бог с ним. Спорить с Вашим мнением я не хочу.
Код на Паскале и на С++ аналогичен - процедурный. Проблемы неумения компилятора инлайнить самостоятельно или оптимизировать операции с плавающей точкой меня не волнуют. Итоговую скорость видно.
А про "где учились" - я Вам верну - проблемы с компиляцией С++ кода, описанные как "ая-яй-яй" в статье Clang'om у Вас от непонимания стандарта С++ и написания некорректного кода, который более строгие компиляторы не пропускают (GCC кстати, тоже).
Более того, вся статья показывает Ваше неумение пользоваться инструментами :
Обычно везде пишут количество строк, но я понятия не имею, как его посчитать
https://superuser.com/questions/959036/what-is-the-windows-equivalent-of-wc-l
У меня о Билдере достаточно теплые воспоминания, я начинал с него (вместе с Borland C++ 3.1 для DOS). Нативный набор виждетов, но при этом гораздо более богатый чем в MFC (с которым я познакомился позже). В результате приложения получались весьма красивые и достаточно быстрые. Приятное расширение языка - "свойства", его порой нехватало в других диалектах С++. Дальше уже перешел на Qt, embedded, немного C# и всякое прочее.
По уму, компании Embarcadero следует открыть исходники их компилятора (как минимум), а в идеале и всей системы, исключая разве что какие-то чисто бизнес-ориентированные компоненты. Какой бы древний код там ни был, а энтузиасты всегда найдутся. И это просто интересно. И очень жалко, когда закрытые исходники уходят в небытие, потому что компания по тем или иным причинам закрывается.
Watcom C открытие исходников не помогло.
Я могу ошибаться, но кажется некоторые исходники были использованы для компилятора языка D.
Не помогла стать популярным на винде? А как наличип исходников в этом ему могло помочь? Он не может предложить ничего, ради чего его стоило бы предпочесть конкурентам.
Открыли исходники они вовсе не для набора популярности, а чтобы перейти в нишу специфических ОСей. К примеру я писал одно время под QNX (линуксоподобное микроядро под х86ю платформу). В нем единственный компилятор - это именно ватком. Есть еще некоторые места, где ватком используется. Возможно из-за того, что он оказался открытым в нужное время, или более дешовым или еще что.
Начинал на Делфи, последняя установленная версия 7я. Сейчас сижу на c#. По моим воспоминаниям Делфи IDE намного быстрее чем Студия на сопоставимом оборудовании. Недавно ставил 1ю Делфи на ретрокомп. Очень удивился потрясающей скорости работы.
Какое-то время назад преимуществом Delphi/Builder перед C# была возможность собрать "монолитное" приложение в которое залинковано все что надо, без необходимости тащить огромный рантайм.
Сейчас, конечно, рантайм C# есть везде, за исключением самых экзотических случаев. Но, имхо, рантайм все равно может доставить головной боли своими версиями, если стоит задача поддерживать приложение на сотнях машин
В теории .net должен быть вшит в винду, но на практике регулярно докачиваю пакеты при установке приложений. Наверное, когда пишешь на шарпе, об просто не знаешь.
Справедливости ради, сейчас можно собирать C# приложения в здоровый exe на 100 метров, внутри которого будет и рантайм запакован.
Теперь перестану называть электрон жирным)
Подскажите, возможно ли на C# написать простое портативное приложение котрое будет "из коробки" работать хотя бы на Win 7-8-10?
Я когда-то очень давно писал несложные приложения на С++ Builder 6, всё очень нравилось. Приложения создавались играючи, весили не много, работали везде, и мне кажется, что то, что было скомпилировано под Win 2000-XP скорее всего запустится и будет работать даже на Win 11 (не проверял, к сожалению файлы потерял, но на 10-ке 2016 года точно работало).
Сейчас вот появилась нужда сделать пару приложений под Windows. Решил в сторону .NET смотреть, но не могу разобраться - у каждой версии Windows свой .NET фреймворк. Помимо этого был .NET Core который затем умер. Теперь уже просто .NET - целых 6 разных версий.
Как написать на шарпе простое приложение которое без танцев с бубном будет запускаться на всех версиях 10-ки, 8-ки, и 7-ки?
Простой ответ - да, можно.
Расширенный ответ - вы немного заблуждаетесь про версии .net.
Сейчас актуальны net framework 4.8 для Windows, но он в режиме поддержки живёт. С какого-то момента он по умолчанию устанавливается вместе с Windows или прилетает с обновлениями. Можно написать приложение на нем или на framework 4.6 и с высокой долей вероятности оно будет просто работать на Windows начиная с win7.
Теперь про core. Он не умер, а переименовался. То есть от 1.0 до 3.1 это был net core. Потом пропуск версии, а начиная с 5 версии платформа называется просто ".NET". И вот тут уже можно создавать self contained приложения, которые будут таскать с собой фроймфорк. Плюс есть возможность поиграться с "урезанием", когда лишние части платформы будут выкидываться и self contained приложение будет становится легче.
В итоге уже сейчас можно просто взять и написать кросс платформенное .net приложение(естественно, что под разные платформы будут разные self contained сборки). А если взять avalonia, то тогда вообще сможете сделать GUI крос платформенное приложение.
Вы очень поверхностно знакомы либо с С#, либо с VCL. Общего у этих идеалогий практически нет. Сильно вводит в заблуждение что и там и там есть какая-то форма и какие-то компоненты, которые вроде бы можно перетаскивать мышкой (в случае WinForms, в WPF уже даже это не так), но эта похожесть - заблуждение. Под капотом они работают абсолютно по разному.
Различие настолько большое, что если пытаться писать в том же С# опираясь на свой опыт VCL, то быдет очень тяжело. Придется сильно переучиваться.
Не совсем и не всегда это так.
Во-первых, в львиной доли ПО время ужодит не на работу, а на ожидание. Девайсов, инпута и т.д. Во-вторых, плохо написанная программа без gc почти всегда будет работать менее оптимально чем плохо написанная программа с gc. Язык неважен. Все "не нативные" языки были придуманы для того, чтобы понизить порог ими владения. Т.е. снизить требования к квалификации разработчика. С ростом производительности компов это стрельнуло в обратную сторону: всю работу, котора раньше требовала большей квалификации теперь может выполнять человек с заметно меньшей. Как следствие, снизилась потребность в квалифицированных разработчиках, их перестали готовить, мест приложения их сил стало меньше - они почти вымерли. Я это к тому, что в большинстве случаев, сравнивая "среднюю по больнице" программу написанную на языке без gc и с ним, нам придется сравнивать именно плохо написанные программы. Это сильно нивелирует разницу между этими средствами.
У VisualAssist был неплохой code completion для C++, не знаю конечно как он справится с вашим куском кода, проверять нет желания :)
До сих пор регулярно пользуюсь бесплатной версией от 2005 года, которая тогда шла под названием Borland Turbo C++, но это самый обычный Builder без части компонентов. Пригождается для очень быстрого набрасывания всяких одноразовых утилит, где требуется GUI. Наверное сейчас есть что-то значительно получше, но привычка страшная сила, и легаси - скорость в том числе повышается за счёт копи-паста из старых аналогичных проектов, которых накопились десятки.
Автор, принимайте в клуб. Легаси поддерживаю на Builder 6 (до сих пор!), нулячее пишу на шарпе.
Я зайду со стороны VCL. Так полуилось, что я, как и автор статьи, в определённое время, "пристрастился" к C++ Builder и многое делал на нём. Каюсь. Страшно ленивый. Мог бы много попробовать, сравнить... Но сейчас, для меня, разговор о Builder'е — это разговор о VCL. На определённом этапе это была довольно продвинутая библиотека. (Интересно, кто-нибудь, кроме старожилов, помнит о Turbo|Object Professional, Turbo Vision и OWL??!) Но! У VCL было три существенных недостатка:
VCL — это (как и все остальные библиотеки подобного рода) объектная надстройка над стандартными виндовыми компонентами и WINAPI. Все те особенности построения и функционирования стандартных компонентов и способ управления ими, во многом, предопределили неповоротливость VCL.
VCL представляет собою довольно внушительную библиотеку классов. И, хотя, принятый подход помогает быстрее создавать приложения, чем MFC, то, в отличие от того же MFC, не предлагает никакой концепции. Отсюда и обилие классов, и обилие компонентов, созданными сторонними разработчиками. В своё время, это был настоящий бум создания компонентов! А если учитывать, что нужно создавать собственную библиотеку классов для решения конкретных задач, то такой зоопарк классов и компонентов становиться уже практически неуправляемым.
VCL построена на модели, в которой не предусмотрено множественное наследование. Это связано с тем, что VCL, фактически, написана на Object Pascal, где в те далекие времена такого понятия как множественное наследование не сущестовавло в природе. (Как, там, сейчас, не подскажете?) Между тем, множественное наследование могло бы существенным образом упростить построение компонентов.
Embarcadero могло бы попытаться, сначала, написать с нуля принципиально новую библиотеку компонентов без опоры на особенности конкретной операционной системы, аккуратно разложив по полочкам все задачи, но, вместо этого, появилась библиотека FireMonkey с претензией на клоссплатворменность, но наследующую почти все родовые особенности VCL.
Лично мне было бы крайне любопытно, если бы пошли бы по пути расширения языка, когда на языке программирования описываются конктрукции, которые может подхватить компилятор, и в нужном месте использовать такие расширения.
Помнится, был такой эпизод у Embarcadero — AppMethod, где можно было использовать атрибуты. Может быть, в других языках программирования сейчас всё это уже реализовано. Я здорово отстал от жизни. Но! Тем не менее, всегда есть возможность предложить что-то новое.
Например, было бы крайне интересно иметь возможность перегружать обыкновенные скобки или операцию разыменовывания указателя. Можно было бы встроить технологию умных указателей и шаблонов непосредственно в язык программирования.
И ещё. Самый интересный аспект, связанный с Object Pascal/C++ Builder, это — свойства. Было бы крайне любопытно посмотреть на то, как этот подход можно было развить...
Ой, ой, ой как у Вас все неправильно! :)
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# сейчас был бы совсем другим.
Паскаль - это язык, с одной стороны лишенный попугайской зависимости отконкурентов и, с другой, не страдающий от самопровозглашенных стандартов. Он сам себе конкурент и сам себе стандарт. К счастью, люди которые определяют его развитие достаточно адекватны, чтобы не тащить, как вороны все блестящее в одну кучу мучительно воюя с рассыпающейся песчаной башней, как это происходит в С. Результатом, к примеру, является то, что уровень владения инструментарием среди паскалистов на порядки выше, чем в среде С разработчиков. Т.е. людей, которые понимают как оно работает, какие техники оптимально использовать и где, на порядок выше. Я это все к тому, что, возможно, то, что в нем нет перегрузки скобочек и операторов это к лучшему.
Если на свете вообще существуют какие-то причины применять его в рамках этого продукта, то я с интересом бы о них узнал. Мне в голову не приходит ни одной.
x64 же?
Классический компилятор x86 only
Классический компилитор и в х64 может. BCC64.
Правда я тут немного плаваю, т.к. я работаю в основном в Delphi.
Именно в этом и была мысь: зачем на билдере вообще что-то кроме классики? Все остальные делают это лучше и быстрее.
Мой ответ на это в статье: Embarcadero не может.
Rapid development x64 приложений под Windows с VCL?
Да.
Если бы силанг работал вменяемо быстро и был бы совместим по фичам с классикой, его наличие было бы оправдано и являлось бы премуществом (ну или достойной фичей) билдера. Пока это не так, его наличие на мой взгляд исключительно для галочки.
Учитывая, что силанг - это целевой тренд, возможно его допилят когда-то в будущем. Правда надеяться на это... сам билдер-то в рад-студии - это приставка к паскалю, а силанг это вторая производная :)
[bcc32c Error] File1.cpp(18): use of undeclared identifier 'Item'
Это можно назвать нестандартным расширением компилятора или неточным следованием стандарту. Такое же было у VC++. Есль подозрение, что clang можно научить пропускать этот код, у него есть ключи поддержки расширений GCC и VC++ (но это не точно).
По поводу классического компилятора. Embracadero, конечно, не потянет полноценный компилятор. BOOST некоторое время поддерживал C++ Builder, но из-за глубоких несоответствий стандарту поддержку дропнули где-то в районе ~1.3x версий буста.
А концепция RAD в своё время была просто бомбой, не зря Microsoft делал всё, чтобы максимально не допустить Delphi на американский рынок. В результате Delphi был популярен в России, Японии, Бразилии, но не в США. Кстати, интересный факт, архитектором .NET был чувак, который разработал Delphi 1.0.
Так же нужно учитывать, что средств, предоставляющих тот же code-completion уровня java для С++ в природе не существует и, даже лучшие из них работают весьма условно.
Ну это же не правда. В open source есть решения на основе clangd: одноименное расширение для Visual Studio Code, YouCompleteMe для Vim, наверняка есть и др. примеры. От JetBrains есть Resharper и Clion, хотя я не уверен, что Clion годится для разработки под Windows. Когда-то давно было расширение Visual Assist для Visual Studio. В Qt Creator вроде бы было какое-то подобие автодополнения и навигации по коду было, но это не точно.
То, что clang у вас 12 сек собирает cpp-файл - тут посмотреть бы, на каком железе, и как настроена сборка. Я последние 5 лет собираю С++ код исключительно clang'ом (не в С++ Builder'е и не под windows) и к скорости компилятора у меня больших претензий нет. Местами собирается долго, но это связано с размером кодовой базы, злоупотреблением кодом в хедерах и лишними зависимостями. Сборочный кэш, распределенная сборка в целом решают проблему с долгой сборкой.
Скорее всего там где-нибудь торчал "предкопилированный" хедер, куда была включена вообще вся стандартная библиотека( а возможно и не только она ). Отсюда и время компиляции такое. Clang конечно не образчик скорости( он, вроде, ещё от gcc отстаёт ), но не настолько
Clion для разработки под винду подходит, но средств формошлёпства в нём нет. Так что если что-то и делать, то долго и мучительно ручками из кода. Или притащить на пару минут Qt creator, дизайнер которого вполне себе приличный( в отличии от остальной IDE имхо )
Скорее всего там где-нибудь торчал "предкопилированный" хедер, куда была включена вообще вся стандартная библиотека
Какая разница что там торчало, если сравнение скорости одних и тех же сорсов, собирающихся под одинаковую платформу с одинаковыми ключами. Если и "торчит", то в обоих одинаково. Классика умудряется это пережевывать в 60 раз быстрее.
В принципе, если бы существовала бы какая-то форма precompiled-ов, то разница была бы "всего" раз в 10, наверное. Но 64-и битная версия не поддерживает вообще никакую форму precompiled. Ни классик-стайл по прагме, ни вижуал-стайл по заранее сохраненному слепку с одного файла.
И проблема при его использовании еще в том, что речь идет не о использовании абстрактного кода в вакууме, а про сборку VCL, которая тащит за собой очень много всегда.
Какая разница что там торчало, если сравнение скорости одних и тех же
сорсов, собирающихся под одинаковую платформу с одинаковыми ключами.
Если и "торчит", то в обоих одинаково. Классика умудряется это
пережевывать в 60 раз быстрее.
Если один компилятор использовал предкомпилированный хедер, куда входило очень большое количество кода, а второй компилятор вынужден парсить весь этот код каждый раз с нуля, то это проблема не компилятора и это могло бы объяснить даже 100-кратную разницу в скорости. А если учитвать тормозное дисковое IO под windows, то это может объяснить дополнительную разницу.
Просто ваш текст создаёт впечатление, что такие тормоза - проблема clang. Но это, скорее всего, не так
Я же написал "средств уровня java", где Вы прочитали что их вообще нет? Хорошие анализаторы кода для явы на лету интерпретируют код, по мере его ввода, что позволяет добиться изумительной точности и адекватности советов по подстановке и замене. Если что-то подобное для С существует, то я этого не видел.
Во-первых, clang собирает не 12 секунд, а 12 минут! Во-вторых, опять-же, я нигде не писал что ЛЮБОЙ силанг будет рабоать так же. Наоборот, я даже явно написал что в той же вижуал студии он работает на порядо быстрее (в том числе из-за того что они прикрутили к нему precompiled). Смысл статьи же не в обзоре всех возможных вариантов, а в узком обзоре конкретного средства. Пока у embarcadero силанг чудовищно медленный, несовместимый с классикой и сам с собой.
В Билдере, очень старый Цланг, был версии 3.5 в Билдере10.2. При том, что на транке уже Цланг11
В 10.4 обновили до Clang 5.0 и есть поддержка предкомпиляции. Может стоит обновить 12-минутный тест?
В комплекте 2 разных силанга (я там не знаю про базовые версии, по факту). 32-и битный поддерживает precompiled по дампу с одного файла, а 64-и битный не поддерживает вообще никакого.
Для 32 бит можно было бы сделать отдельное измерение... если бы эта шляпа корректно работала. Мои эксперименты показали, что более 1 раза силанг с прекомпайледами не справляется и обсыпается ошибками. Далее либо полный ребилд, либо удаление дампа вручную. В сумме получается, так же по времени.
Если что-то подобное для С существует, то я этого не видел.
Не видели, но это не мешает вам в тексте писать "не существует в природе". Вы уж определитесь, не существует в природе, или все-таки вы не видели?
Вот к примеру Resharper - богатое на фичи расширение к Visual Studio. Там и автодополнение, и навигация по коду и рефакторинг есть. Вам там какой фичи не хватает, чтоб было ближе к "уровню java" ?
Про долгую сборку - тут надо разбираться что тормозит, неправильно из одного частного случая делать вывод, что компилятор медленный. 12 мин - это как-то совсем из ряда вон. Благо для clang'а есть средства профилирования компиляции: https://aras-p.info/blog/2019/01/16/time-trace-timeline-flame-chart-profiler-for-Clang/
BTW clang читается, как "клэнк", а на "силанг"
Вот к примеру Resharper - богатое на фичи расширение к Visual Studio
Спасибо. В какой версии он уже есть максимально функциональный? Сам вижуал мне применить негде, но для теста интересно было бы посмотреть.
Вам там какой фичи не хватает, чтоб было ближе к "уровню java" ?
Мне лично всего хватает. Львиную долю сорсов я набиваю вообще в редакторе FARа. Если же говорить о том, что мне понравилось при писании на том же Kotlin - это:
контекстная подстановка конструкций. Если я написал if и закрыл скобку, то при наборе "е" я получаю "else"; находясь в скопе класса по "pu" public и не наоборот. И т.д.
по мере ввода моментально получаю список того, что возможно использовать в этом месте, отсортированный по локальности. Т.е. сначала локальные переменные, потом классовые, предков, привязок и т.д.
в списке подстановки находится только то, что можно применить. Если в месте использования нужна функция, то будут только функции, которые возвращают то, что нужно в месте использования, если нужен енум определенного типа, то будут только его элементы и т.д.
Это конечно больше таракан явы, в которой нет хелпа, но часто очень сильно помогает javadoc, который вспывает когда ты ходишь по списку предложений. Как найти что-то новое, так то, что ты забыл как называется или что именно точно делает.
В результате работы такого средства, часто, набор кода заключается в наборе разделителей, пары первых букв и нажатие пробела (или enter у кого как настроено).
Спасибо. В какой версии он уже есть максимально функциональный? Сам вижуал мне применить негде, но для теста интересно было бы посмотреть.
За версиями Решарпера я не слежу, последний раз пользовался 5 лет назад и уже тогда были фичи, которые я упоминал. Для теста имеет смысл брать последнюю версию.
контекстная подстановка конструкций
Такое умеют многие редакторы. Я сам не пользуюсь, т.к. вместо else там легко может быть вызов метода на букву e - по контексту вполне подходит. Мне такие фичи скорее мешают.
П. 2 и 3 тоже есть, но точность списка подстановки, конечно, везде разная. Особенности С++ не позволяют добиться той точности, которой вы хотите, т.к. макросы можно использовать почти везде, а тип возвращаемый шаблонной функцией не всегда можно вывести, в особенности, когда еще не весь код набран. В целом чем меньше шаблонов и чем меньше размер кодовой базы, тем точнее будет список подстановки.
П.4 - показывать комменты к коду редакторы умеют.
На данный момент решил проблему неспешным переписыванием кусочков кода на C#, благо это всё относительно совместимо. (не считая всяких подлянок на границе managed и unmanaged кода).
У меня ровно та же проблема: зависимость от либо умершего, либо модифицированного до несовместимости паскалевского кода. Трата времени на переписывание с нуля всех этих кусков не опревдана.
К сожалению специфика моих программ не дает возможности дописывать что-либо на том же C# или чем-то еще. Чтобы это сделать придется практически переписать заново все, что было создано за последние лет 20. Вот и сижу где сижу :)
А можно привести конкретный пример? Из общих соображений всё и так понятно. Но пример помог бы более полной понять тяжесть ситуации.
Пример чего?
специфика моих программ не дает возможности дописывать что-либо на том же C#
В чём специфика?
Неправильно я сформулировал. Не какая-то специфика, а набор факторов. Накидаю бессистемно, может понятнее станет.
Софт, который я пишу, в конечном итоге, в сетапе, состоит из 50 библиотек общего плана (dll/bpl), 54 экзешников и 25 плагинов (bpl) к разным частям. Где-то %20 от числа библиотек можно, наверное, выкинуть заменив штатными средствами того же шарпа, касающихся работы с электронной почтой и бащами данных. Остольного все равно очень много.
Софт эксплуатируется неподготовленными людьми и один из важных критериев - это "стандартность". Т.е. он должен выглядеть и управляться так же как стандартный виндовый софт. Т.е. всякие решения с плиточными интерфейсами и прочей альтернативщиной сразу идут лесом. Т.е. в С# у меня выбор только из WinForms. Возможно можно как-то извернуться и в WFP, но я не уверен.
Для иллюстрации разных аспектов написано около 60 собственных компонентов. Где-то половину из них можно, наверное, будет выкинуть найдя аналогичный по функциональности штатный аналог шарпа, или довольно быстро реализовать новый. Из оставшегося штук 5 являются довольно эксклюзивными штуками, существенными по коду. Полных аналогов я не видел. Т.е. придется довольно много реализовывать с нуля, чтобы получить аналогичные средства отображения.
VCL предоставляет механизм "легких" контролов, имея свои собственные деревья объектов, ктоторые не мапятся в виндовые контролы. В результате даже очень нагруженный интерфейс может на практическе иметь единственный HWND - контейнера. В WinForms, если я правильно читаю описание Contol, все интерфейсные элементы - это прямые враперы виндовых контролов. Ранее, работа с сотнями объектов у одного родителя приводила к жутким тормозам. Как дело обстоит сейчас я не знаю, но мест где у меня создается МНОГО интерфейсных объектов есть у меня.
Большая часть моего софта - это клиенты для моего же сервера, общающиеся с ним по бинарному протоколу по IP стремными сокетами. Чтобы дописывать что-ибо к существующей системе придется реализовывать этот интерфейс на шарпе. Бинома ньютона тут, конечно, нет, но это делает полностью бессмысленным "дописать что-то новое на шарпе" т.к. без средств связи оно будет бесполезно.
В итоге. Для того чтобы делать что-то интерфейсное на шарпе мне необходимо реализовать существенный объем собственных контролов, работать это будет виндовыми средствами (т.е. возможна ситуация, когда аналогичный существующему гуй будет работать хуже).
Что я получу, переведя код в шарп? Если не учитывать времени, которое потребуется на овладение этим инструментом на том же уровне, на каком я владею используемыми сейчас, и времени, которое потребуется на собственно кодирование и тестирование, я получу... всего 2 преимущества:
Надежду на то, что WinForms просуществует в поддержке дольше чем поддержка 32 битного кода виндой. Т.е. микрософт завтра может сказать "мы WinForms дропаем" и я поимею дикие проблемы. Писать же на древнем билдере я могу до тех пор, пока 32 битные приложения будут запускаться на винде.
Возможность использовать стабильные средства для работы с интернет. Не то чтобы это было бы мне нужно прямо сейчас, но сам факт, что можно использовать гарантированно работающее, штатное средство вместо подъема http для реализации REST или WebSockets на каком-нить Mangoose - это несомненный плюс.
Что я получу в "минусах", если переведу софт на шарп:
Значительно более сложный и трудоемкий процесс по созданию новых интерфейсных частей и поддержке существующих. Я экспериментировал с шарпом, конечно, не много, но пришел к выводу, что скорость разработки интерфейсов на нем не сравнима со скоростью с VCL. Это в винформс, с WPF ситуация еще хуже.
Мизерность готовой кодовой базы. Все-таки я изобретаю не все на свете велосипеды и часть кода у меня используется из различных сторонних библиотек. Даже если отфильтровать только то, что мой 5й билдер способен собирать, то количество готового кода для Delphi превышает весь доступный код для шарпа, наверное, на порядки. Это может закончится тем, что мне понадобится реализовывать каку-то сложныю хрень, типа рантайм дизайнера компонентов или текстового редактора. Чего делать бы не хотелось.
Некоторые сложности и странности доступных срадств. К примеру, OLE - это число виндовая технология от микрософт, но ее штатная поддержка в шарпе отсутствует. Если в том же вижуал васике я могу написать практически только название класса с гуидом и все кишки автоматически подтянуться сами и класс можно использовать сразу же как нативный, то в шарпе для этого придется постараться. В частности OLE я использую для работы с OPC. У меня есть и сервер и клиент. Реализация этого на шарпе быдет существенно сложнее того что я делаю сейчас. Второе что использую - это прямая работа с ком-портами для работы с оборудованием, к примеру GSM модемами. Возможно, в шарпе с этим не будет проблем, а может и возникнут. Во всяком случае ничего сложнее поделок на эту тему на шарпе я не находил.
В общем как-то так. Стало понятнее?
У всех своя правда... Стоит и стояла задача сделать десктопное приложение под винду и мак... Так как весь код на C++ - выбор пал на билдер и мульиплатформенный FireMonkey. Главный фокус был в том, что один и тот же код работает как под виндой так и под маком, и выглядят приложения одинаково. Но Емберкадеро убило поддержку макОс в билдере, со времен перехода на 64бит. Причем не могло в этом признаться полтора года, кормя завтраками и след. релизом. И до сих пор ее не сделало. Нам пришлось переписать весь код на Делфи, а непереводимое засунуть в DLL. После этого я прсто люто ненавижу Емберкадеро. К сожалению я не знаю годной альтернативы, для приложений под вин+мак. Есть фреймворки типа JUCE для С++, но они проигрывают по удобству разработки Делфи....
Сочуствую, но, на мой взгляд, Вы изначально выбрали неправильное средство. Нужно было либо сразу писать на дельфи, либо использовать вообще другие инструменты.
У меня была однажды сходная задача, только с андроидом. После рассмотрения того что и как делает билдер в плане многоплатформенности я поставил крест на билдере и потратил 2 недели на написание нативного приложения под андроид, о чем не жалею. Если бы сейчас встала аналогичная задача, то не думаю, что использование для этого билдера мне вообще пришло бы в голову.
Почему изначально выбрал не правильнео средсьво? Они везде декларировали кросс-платформеноость среди разработки, как Делфи так и С++. Но когда дошло дело до обновлений, то С++ они перестали обновлять, а обновляли только Делфи! Причем полтора года не могли признаться что все-таки С++ они притормозили. А пользователи приложения нам полтора года саппорт выносили поддержкой мак 64 бит. А мы ничего не могли сделать....
И на счет совсем другие инструменты? Это что, например? Чтобы один и тот же код работал по разными ОС, и выглядел одинаково. JUCE и Qt только приходят на ум. JUCE не подошел бы по возможности с GUI. У Qt - свои тараканы....
Я же привел свой аналогичный пример. Я не знаю в какое время Вы выбирали средство, но тогда когда его смотрел я пол дня экспериментотв оказалось достаточным, чтобы его исключить. Я это и имел в виду, что Вы недостаточно ответственно подошли к выбору инструмента для долгосрочной разработки. Возможно это и не так, я Вас понял неправильно. Если на берегу все было (в реальности, а не в рекламе), шикарно, а потом блдер сломали, то в этом случае да, "казлы" и прочее. Но для справедливости стоило бы все же отметить что такие же точно "казлы" и маковцы, котрые сделали невозможным использование старого средства (если, опять же, я правильно понял проблему).
А другие средства - это другие. Если под набор критериев не подходит ничего, то нужно менять этот набор. Нет того что умеет одинаково и удобно, значит либо пишите на разном, либо миритесь с неудобствами, чтож поделать-то? Я как-то написал морду под мобилку для своего сервера вообще на LUA с помощью Corona. Случай, разумеется, очень далек от Вашего.
Проблема в том, что билдер мог создавать только 32-ух битные приложения под макос. Мак Ос перевели на 64 бит. И 32-ух битные приложения перестали работать в новых версиях ОС. Для делфи сделали поддержку 64 бит, а для Билдера нет - и тянули полтора года с этим. Теперь Эпл выпустили АРМ М1. Делфи сделали поддержку, а Билдер все в том же состоянии. И это вот за последние 3 года -) Когда мы выбирали Билдер - он был на равне с Делфи. Но в процессе его задвинули на не приоритетное направлние - и по сути не развивают, или развивают по остаточному принципу. Эпл тут не причем. Эмбаркадеро - козлы. Согласитесь сделать сборку под 64-бит в 2019-2021 году для С++ компилятора не сверх задача! Тоже самое у них было с 64 бит для Андроида.
Не соглашусь. По описанию проблемы казлы именно эппл. Это как взять сейчас и в винде запретить все 32битные приложения. Меньшее что меня при этом будет интересовать - это поддерживают там что-то отдельные компиляторы или нет. В макоси крошечная экосистема, конечно, но для меня, как потребителя, это все равно выглядит как форменное свинство.
Но Ваше негодование я вполне понимаю :) Хотя, все же, рассчитывать на что-либо от продукта, проходящего уже четвертую (вроде) стадию перепродажи я бы не стал уже на берегу. Другое дело дельфи, тут еще есть какая-то надежда на уверенность. Желаю Вам не получить фаталити с дельфи, когда маковцы опять развернут оглобли куда-нибудь :)
Я как-то споткнулся о книги Архангельского и восхитился удобством программирования. Накидали менюшек-окошек, накидали компонентов, описали свойства… и всё работает.
В какой-то момент заметил, что мне стало лениво писать что-то самому и я прежде всего ищу компоненты.
Собственно для своих научных нужд сейчас пишем в основном консольные штуки, а если нужны менюшки-окошки — на BCB6.
Стало интересно, а что сейчас происходит — заглянул на форум (https://www.cyberforum.ru/cpp-builder) — вполне всё живо, народ задает вопросы и на вопросы отвечает.
К сожалению, проста старта оборачивается, затем, большими трудностями. Если бы написание самого программного кода можно было бы реализовать как работу с компонентами, то это было бы уже кое-что.
Главный вопрос — это вопрос о том, какой именно объект должен обрабатывать реакцию на событие, то есть — где сидит фазан обработчик события.Была бы чёткая концепция реализации типа MVC...
Собственно для своих научных нужд сейчас пишем в основном консольные штуки, а если нужны менюшки-окошки — на BCB6.
А почему не C# (Win Forms) или Qt?
А почему не C# (Win Forms) или Qt?
Ну так Си знаком с детства — со времен DOSа, Qt — я так понимаю, там главная фишка в кросс-платформенности, а у нас её не наблюдается — только зоопарк разных окон.
Главный вопрос — это вопрос о том, какой именно объект должен обрабатывать реакцию на событие,
Вот это не понял, честно говоря. Можно распространить?
У компонентов бывают события. А у событий должны быть обработчики. В визуальном редакторе Вы выбираете событие и создаёте требуемый обработчик. Но этот обрабочкик — некая функция, являющаяся частью формы. Мой вопрос заключается в том, нет ли более эффективного способа создания обработчиков. Я имею в виду, что, логичнее, иметь набор взаимоувязанных компонентов, где, скажем, компонент A имеет некторое событие, а у компонента B имеется обработчик этого события. По идее, таким образом можно распределить обязанности между компонентами, а не "валить" всё в кучу в виде методов формы.
Нет у компонентов событий. В QT есть, в VCL нет.
То, что в инспекторе объектов отображается на второй закладке - это просто проперти с типом "указатель на функцию", не более того. Уточню, т.к. есть у меня подозрения в непонимании: указатель на функцию именно члена класса. Любого класса. Хоть формы, хоть любого другого. Дизайнер создает такие функции "обработчики" автоматически в том что редактирует (оно как бы и логично) - в форме. Но никто не мешает их иметь вообще где угодно. Хоть заведи синглетон для с функциями обработчиками событий вообще всех компонентов приложения.
Если вопрос был в том, что "можно ли сказать дизайнеру, что функции создавать в другом месте", то скорее нет чем да, но нужно покопаться в интерфесах для плагинов дизайнера, может и можно. Но никто не мешает задавать обработчики вручную, в коде. У меня так %в 30 гуя обрабатывается.
ПС: Разумеется, нужно помнить что указатель не на функцию класса, а на функцию объекта класса. Ибо __closure. Надеюсь это очевидно.
Нет у компонентов событий. В QT есть, в VCL нет.
Событие — это когда что-то происходит. Например, на визуальном компоненте устанавливается фокус, когда мышка дёрнулась, когда надо нарисовать элемент списка...
То, что в инспекторе объектов отображается на второй закладке - это просто проперти с типом "указатель на функцию", не более того.
Совершенно верно. И эти функции, если они каким-либо образом определяются, то они становятся обработчиками событий. Обработчика может не быть, и событие пройдёт незамеченным. Будет обработчик — можно будет сделать что-нибудь полезное.
Если вопрос был в том, что "можно ли сказать дизайнеру, что функции создавать в другом месте", то скорее нет чем да, но нужно покопаться в интерфесах для плагинов дизайнера, может и можно.
На самом деле, ответ на этот вопрос должен быть положительным. Я никогда (увы и ах) не создавал своих собственных компонентов (о чёи сильно жалею; хотя, может быть мне ещё удастья это сделать, пока есть ещё на ходу [надо ещё проверить!] IDE С++ Игшдвук 6.0), но знаю, что всегда можно сделать собственный редактор публичного свойства, и подозреваю, что можно создать что-то вроде модуля данных для компонентов управления данными (соделинения, источники данных, наборы данных, таблицы и запросы), где можно было бы предоставить разработчику возможность задания нетривиальных зависимостей между компонентами.
ПС: Разумеется, нужно помнить что указатель не на функцию класса, а на функцию объекта класса. Ибо __closure
А вот это мне уже не совсем понятно. Вы называете функцией класса то, что в дельфиской традиции называется method of class? И что означает __closure? Не задумывался об этом.
Пишу на Дельфи dllки для 1С, утилиты для 1С и немного мобильной разработки на firemonkey для 1С. Нравитца.
>На мой взгляд, переход на компилятор из «вражеского» лагеря объясняется
тем, что Embarcadero просто не имеет ресурсов (возможно и желания) для
того чтобы создать и поддерживать собственный. Получив в «наследство» от
Borland какой-то инструмент они оказались не способны на существенную
его модификацию.
дело в том, что стандарт c++ распухает быстрее, чем его возможно реализовать при разумных расходах. митуация почти как с html5, где все производители движков потеряди надежду поспевать за темпами разработки хрома и мозиллы, да и последняя может не выдержать.
поэтому в эмбаркадеро решили поддерживать наборы патчей к не гну, а бсд компилятору, потому что бсд лицензия оставляет право не раскрывать исходники патчей.
Вы правы конечно. Тем не менее, отдельные гениальные специалисты успешно пытаются поддерживать стандарты даже в одиночку: https://www.delphihtmlcomponents.com/
Решается абсолютно глупо
Действительно. Более умно решается так:
this->Item
C++ Builder. Есть ли жизнь после смерти? Мнение одного динозавра