В этой статье я опишу собственные впечатления о последних версиях среды разработки RADStudio от Embarcadero и, возможно, постараюсь помочь кому-то в ответе на вопрос: «А оно мне надо?».
Сразу оговорюсь. Все описанное в этой статье является моим личным мнением и любые сравнения и характеристики, являющиеся плюсами или минусами, являются таковыми только для меня и моего способа использования инструментом. Если для Вас какие-то из указанных достоинств или недостатков так же являются таковыми – очень хорошо, но если это не так, то не стоит впадать в берсерк и начинать крестовую войну. Тут никто не воюет.
Введение
Начну небольшой вводной о себе, чтобы стало понятнее мое отношение в средству разработки и требованиям к нему, которые для меня являются ключевыми и определяющими но, для многих, таковыми могут не оказаться.
Чтобы излишне не растягивать текст, я уберу отвлеченный текст под спойлер.
Обо мне
Моя судьба сложилась так, что я всю свою сознательную жизнь занимался именно программированием. Причем именно прикладным, с небольшим уклоном в системное.
Свой трагичный путь по жизни я начал, когда родителям на работе выдали программируемый микро калькулятор МК-61 и лежать бы ему на полке, если бы я случайно не наткнулся на статью в журнале с программой для него. С этих пор я покатился по наклонной: УПК по информатике с 8го класса, аналогичная кафедра в институте и трата 100% на сидение перед компьютером в течении многих лет. Вначале казалось что это так, баловство, что это несерьезно, но, как это обычно и бывает, начав с легких веществ в виде Pascal я закономерно скатился на тяжелые ASM и С++. Казалось что еще недавно я сочиняю безобидные утилиты для Robotron 1715, и вот, не успев оглянуться, я уже клепаю резидентов для DOS, графические интерфейсы под VESA и даже уже пробую Win16 под Windows 3.0. К тому времени, когда появилась Ebony, я был уже полностью конченный, и оставалось только дождаться появления подобного продукта для C++.
Немного истории CPP Builder
Borland выпустил свой CPP Builder 1.0 с заметным отставанием от аналога для Pascal, но его появление было сравнимо со взрывом сверхновой в области разработки. Это был первый в истории RAD, и, на мой взгляд, единственный. Мне кажется, что ничего сравнимого с ним именно с точки зрения Rapid Application Development нет даже сейчас, на момент написания статьи. И не думаю, что уже появится.
Некоторым в жизни повезло, и они закончили сисадминами, хакерами или смогли завязать и ушли в бизнес. Мне так не повезло, и в своем развитии у меня просто не было выбора. К сожалению, за почти 30 лет своего стажа, я стал заложником именно продукта под названием C++ Builder.
Появление VCL стало революционным прорывом и, следующие почти два десятка лет, альтернатив Borland в разработке прикладного ПО просто не существовало. Были изделия от Microsoft, с самой первой своей попытки создать хоть какое-то средство программирования, никакого сравнения с продуктами от Borland не выдерживающие. Кто-нибудь помнит Microsoft Pascal? А Microsoft C (без приставки Visual)?. Даже в 6й своей версии, это отставало от Borland на поколения, предоставляя программисту средства сравнимые с Turbo C. А ранние версии Visual C со средой программирования, которая названия-то такого не заслуживала - «среда разработки», представляя из себя чахлый редактор с функционалом Notepad и вызовом строчника для компиляции и сборки. И даже уже приобретя гордое звание «Visual Studio», средство от Microsoft оставалось нишевым продуктом для отдельных гиков или тех несчастных, которые не имели другой альтернативы. Еще были и жадный Watcom и прекрасный Symantec с гениальными библиотеками, но никто не мог предложить комплексного решения по действительно быстрому созданию приложений для Windows.
Что же мы имеем сейчас?
Сразу оговорюсь, что рассматривать создание приложений для каких-либо платформ кроме Windows я не буду. С++ Builder, как те гастробайтеры, которые ходят по дачным товариществам с вопросом: «Хозяйка, работа есть?», что-то сделать за пределами Windows может, но делает это «плохо, долго и дорого». По моему, никто в здравом уме современные продукты от Embarcadero для этого использовать не будет. Если это не так, то я рад был бы узнать те обстоятельства, когда выбор именно этого инструмента для кросс-платформенной разработки оптимален.
Я буду рассуждать только о создании приложений для Windows и только с использованием VCL. Это, на мой взгляд, единственная ниша, где Delphi и Builder могут что-то стоящее внимания среди множества современных конкурентов.
В настоящее время Builder поставляется с двумя принципиально разными компиляторами. Существует «классический» компилятор для win32, который является очень вяло и слабо адаптированным компилятором от Borland, и пучок изделий на основе LLVM.
Различия классического компилятора и LLVM (clang) - кардинальные. Это продукты из разных экосистем и, в отличии от Microsoft, которая оказалась способной сделать из концепции LLVM что-то работоспособное и совместимое, Embarcadero это не удалось. Clang имеет «гнусные» корни и, соответственно, огромное количество различий с классическим компилятором. Они поддерживают разные стандарты С++, у них разные наборы директив препроцессора, ключевых слов (некоторые общие интерпретируются по разному), разные требования к языку, разная интерпретация предупреждений и ошибок.
Вот несколько примеров.
Найдите ошибку в коде:
struct LZHFileHeader {
DWORD OriginalFileSize;
time_t OriginalFileTime_Create;
time_t OriginalFileTime_Write;
time_t OriginalFileTime_Access;
WORD OriginalFileNameSize;
char OriginalFileName[];
};
struct LZHFileHeaderName : public LZHFileHeader {
char _name_place[ MAX_PATH_SIZE ];
};Если Вы считаете, что ее тут нет, то Вы ошибаетесь:
[bcc32c Error] hs_lz.h(42): base class 'LZHFileHeader' has a flexible array memberКорни проблемы в «char OriginalFileName[]» и, к счастью, решается она всего лишь с помощью добавления нолика в «[0]». Вроде мелочь, но то, что приходится на пустом месте копаться в древнем бинарном упаковщике, немного напрягает.
Вот проблема посложнее, во всяком случае, для меня:
template <class T> class _AccessBASE {
protected:
T *Item;
public:
_AccessBASE( T *p ) : Item(p) {}
int LockRead( void ) { return 1; }
};
template <class T> class ReadAccess : public _AccessBASE<T> {
int lrc;
public:
ReadAccess( T *p ) : _AccessBASE<T>(p) {
lrc = Item ? Item->LockRead() : 0;
}
};По мнению clang ошибок две:
[bcc32c Error] File1.cpp(18): use of undeclared identifier 'Item'
[bcc32c Error] File1.cpp(18): use of undeclared identifier 'Item'Элемент «Item» в наследнике оказывается даже не недоступным, а вообще неизвестным. Решается абсолютно глупо:
lrc = _AccessBASE<T>::Item ? _AccessBASE<T>::Item->LockRead() : 0;Возможно, в этом и есть какой-то скрытый смысл, но это только иллюстрации того, в каких дебрях придется копаться в попытке адаптировать код.
Компиляторы эти настолько разные, что собрать ими обоими совместно какой-то более-менее сложный код попросту невозможно. Для иллюстрации напишем супер интеллектуальную консольную программу без использования VCL:
int main(int argc, char* argv[])
{
return 0;
}Соберем ее clang, после чего переключаем настройку «Use classic Borland compiler» в проекте, изменяем что-то в тексте и нажимаем make. Получаем:
bcc32 command line for "File1.cpp"
brcc32 command line for "conTmp.vrc"
ilink32 command line
[ilink32 Error] Error: Unresolved external '___terminatePTR' referenced from D:\BDS21\LIB\WIN32\RELEASE\CW32MT.LIB|xxv
[ilink32 Error] Error: Unresolved external '__stkchk' referenced from D:\BDS21\LIB\WIN32\RELEASE\CW32MT.LIB|except
[ilink32 Error] Error: Unresolved external '___DefHandler' referenced from D:\BDS21\LIB\WIN32\RELEASE\CW32MT.LIB|except
[ilink32 Error] Error: Unresolved external '___unexpectdPTR' referenced from D:\BDS21\LIB\WIN32\RELEASE\CW32MT.LIB|xxv
[ilink32 Error] Error: Unresolved external '_InitTermAndUnexPtrs()' referenced from D:\BDS21\LIB\WIN32\RELEASE\CW32MT.LIB|xxv
[ilink32 Error] Error: Unable to perform linkВ зависимости от того, в каком начальном положении была настройка «классики» букет будет разный. Бакграунд, который используют компиляторы при генерации кода совершенно разный и несовместимый. В данном случае все решает полный ребилд проекта, но осадочек остался, так ведь?
Для полноты иллюстрации совместимости, давайте немного усложним задачу, дописав в нашу программу строчку:
__declspec(dllexport) void F( int n, char str ) {}
Вполне банальный код, но результат у компиляторов разный: оба для win32 экспортируют привычное «@F$qipc», но при переключении на win64 мы получим «_Z1Fic». Вы можете возразить, что закладываться на формат манглинга имен неправильно и нельзя. В идеальном мире это, возможно и так, но, во-первых, ровно так и происходит в VCL загрузка пекаджей и даже у меня в коде есть пара мест, где делается именно это и, во-вторых, даже при добавлении логичного «extern “C”», мы все равно получим разный результат. Теперь уже «F» и «_F». В одном и том же проекте, лишь поменяв платформу, мы получаем другой calling-conversion. Если кто-то считает, что это мелочь незаслуживающая внимания, то я Вам искренне завидую.
Мелочи типа SEH, поведение которого в зависимости от платформы и даже конфигурации билда будет разное, я упоминаю чисто для галочки. Т.е. если Вы, вдруг, использовали подобие такого условного кода:
__try{
((int *)0)[1] = 10;
}__except(1){}то с большой вероятностью Вам придется очень весело провести время при поддержке когда-то в будущем, если Вы на берегу не вспомните обо всех местах, где есть подобные конструкции.
Понятно, что многие вещи можно адаптировать, для многих можно найти способ «так не делать», вопрос не в этом. Проблема в том количестве времени, которое может вдруг понадобится, совершенно незапланированно на, казалось бы, пустом месте. Я это к тому, что заявленная Embarcadero «на коробке» поддержка кучи платформ в текущей реализации является фикцией даже не из-за различия платформ, а из-за различия в самих средствах компиляции.
На мой взгляд, переход на компилятор из «вражеского» лагеря объясняется тем, что Embarcadero просто не имеет ресурсов (возможно и желания) для того чтобы создать и поддерживать собственный. Получив в «наследство» от Borland какой-то инструмент они оказались не способны на существенную его модификацию. Я не знаю как обстоят дела в стане Delphi, но в области С++ мы наблюдаем сползание в сторону наименьшего сопротивления: взять что-то чужое готовое и хоть как-нибудь допилить его в общую экосистему лишь бы закрыть позицию в прайсе. В настоящее время старый компилятор существует в виде «наследия», галочки в проекте «use classic compiler» и, скорее всего, в каких-то будущих версиях будет выброшен.
Классика
Но пока классика еще присутствует, давайте посмотрим, что мы в ней имеем.
При ближайшем рассмотрении, к сожалению, оказывается, что практически ничего. Если Вы, как и я, провели последние лет 15 на неведомой планете, на которой ничего страшнее Builder 5.0 не существовало, то в попытках обнаружить кардинальные изменения в современном «классическом» инструментарии Вы не обнаружите практически ничего. Пара новых ключевых слов из стандарта С++ посвежее, которые не нужны, измененный способ вывода справки о ключах командной строки и несколько новых ключей для совместимости с тем, что Вам все равно не пригодится. На этом, собственно, и все. Если Вы, вдруг, рассчитывали обогатить свой код конструкциями из свежих стандартов С++, то Вам не сюда. Вы не ослышались, на главной странице С++ Builder про С++17 Вас нагло обманули. К классике это не имеет ни малейшего отношения точно так же как и раньше. Если Вы рассчитываете на появление какой-то оптимизации кода или вообще на изменение в его генерации, то нет – это не тут. Лучшее на что Вы можете рассчитывать – это на то, что Ваш существующий код соберется без лишних ошибок времени исполнения.
Для примера возьмем нашу гениальную программу описанную выше. Собрав ее классическим компилятором в «статике» мы получаем файл размером в 70 килобайт. Собрав ее clang для win32, мы получаем файл размером в 174 килобайта. Изменив платформу на win64, мы получим уже 470 килобайт. Чисто для смеха, из аналогично пустой программы на паскале получается 43 килобайта. В принципе, это ни о чем особо не говорит, конечно.
С компилятором clang ситуация другая. Это современный компилятор. Он существенно отстает по всем могущим прийти в голову фронтам от аналога, используемого Microsoft, но, в сравнении с «классическим» компилятором, крайне современный. Другой вопрос,
который меня волнует - это «зачем»? Да, Embarcadero справились с задачей внедрения во «вражеский» стан __closure, биндинга с кодом из Pascal, но я не могу увидеть в этих их усилиях никакого смысла. В теории с использованием clang можно собирать приложения на VCL и, если Вы вообще часто выигрываете в лотерею, они даже соберутся и, возможно, будут работать. Но смысла в этом подвиге не так уж и много, и причин тому несколько:
Существующий код, сколько-нибудь завязанный на специфику платформы (оптимизированный с использованием ассемблера вставками или целиком), часто будет проще выкинуть, чем адаптировать. Виной тому, как синтаксические мелочи типа невозможность использования меток в блоках asm, так и обилие тараканов с caling-conversion.
Существующий С++ код, завязанный на чужие или даже свои, но от которых не осталось исходников, библиотеки можно будет выкинуть. Один только фиктивный «__fastcall» ставит жирный крест на попытках подобного code-reusing.
Использование всей мощи современного С++ в связке с VCL не имеет никакого смысла т.к. VCL написан исключительно на Pascal и места для применения фич из другого языка в этой библиотеке попросту нет.
Embarcadero – это Вам не Microsoft и адаптировать чужеродный язык к существовавшим исторически реалиям они оказались не способны. Реализация clang из комплекта напоминает престарелого франкенштейна: он еще не способен корректно работать со всем старым кодом из Builder, но уже устарел.
То, что лично для меня является определяющим: clang чудовищно, непредставимо медленный.
Итого
Использование классического компилятора дает Вам теоретическую возможность использовать новый продукт от Embarcadero со своими проектами с минимальными усилиями, но с большой вероятностью этот компилятор скоро перестанет существовать.
Использование же clang бессмысленно из-за того, что сопряжено с огромным количеством проблем как по адаптации существующего текста, так и с последующим «осторожным, но крайне интенсивным» его тестированием. И, даже если Вы преодолеете все возникшие трудности, это все равно не даст практически никакой выгоды.
RAD
RAD был бы не RAD, если бы все упиралось только в компилятор.
Компилятор, каким бы он ни был, если он вообще способен генерировать работающий код из текста программы, является только частью общей схемы по разработке программ и, если считать потраченное на его исполнение время, наиболее мизерной частью.
Большая часть RAD – это именно среда разработки и отладки.
Что мы получим в новой среде разработки?
На удивление, текущая среда оставляет о себе приятное впечатление. К счастью, ушли времена чудовищного монстра, написанного на Java, жрущего ресурсы, тормозящего и не умеющего ничего кроме понтов. От многих «модных-и-современных» веяний в «средостроении» Embarcadero почему-то отказались и, в результате, мы имеем вполне адекватную, не перегруженную кучей функций и окошек, вполне привычную для любого разработчика на Delphi\Builder среду, с нормальными и привычными средствами управления проектами, встроенной отладкой и кое-какими украшательствами и удобствами, облегчающими жизнь рядового набивателя текста.
Если Вы застали времена, когда в среде не было человеческой палитры с компонентами, менеджер проектов заключался в задании ключей для утилит командной строки, а отладчик представлял из себя убогий gdb, то можете выдохнуть. Ничего этого больше нет. Все средства вернули в «прошлое», как они и были. Все функционирует очень слитно и ощущается вполне «нативным».
Разумеется, т.к. вся среда разработки теперь снова написана на Pascal и разработчики лишены возможности делать «import github/*», то в прошлое так же ушли практически все современные средства облегчения модификации, контроля и навигации по текстам программ. Если Вы вообще не способны обходиться без разлапистого рефакторинга, code-completion, classes-tree и прочих инструментов, то… Вам наверное стоит вернуться обратно в IDEA. Тут Вам будет очень грустно.
Многие, ставшие стандартными для любой среды разработки, инструменты тут есть и работают, многие просто есть, а многих нет. К примеру, code-completion для С++, в сравнении со старыми версиями теперь просто работает (во всяком случае для «классики»), но работает он с такими условностями и ограничениями, что на практике можно считать, что его вообще нет. В 70% случаев, когда я пытался его использовать, он либо вообще не имеет вариантов, либо предлагает всякий бред, типа каких-то глобальный констант. Пользоваться им можно, но пользы в этом не много просто из-за обилия «холостых» выстрелов в моем случае. Если любить обширную писанину, то, возможно, он будет кому-то полезен.
Refactor же я вообще не смог заставить работать, хотя штука, часто, очень удобная.
В общем, на текущий момент среда разработки представляет из себя стабильную программу, которая работает адекватно быстро, не сыпется под собственным весом и не тормозит. Она позволяет выполнять все необходимые для работы операции.
Лично у меня была единственная проблема связанная именно со средой: к проекту приложения невозможно приписать использование пекаджа. Вообще. Нет такой настройки. Можно указать только общий список пекаджей проекта, но указать, линковать пекадж в виде статической библиотеки или динамической - невозможно. Пришлось править файл проекта руками, благо формат не заумный.
Функционал редактора находится на уровне Notepad++ древних версий, но лично для меня этот критерий находится в самом конце списка важного. Так же нужно учитывать, что средств, предоставляющих тот же code-completion уровня java для С++ в природе не существует и, даже лучшие из них работают весьма условно.
Если кто-то знает инструмент, корректно работающий на основании кода типа такого:
double TWGAViewForm::GetGasData( TxDBGridNode *node, GasTypes tp, GasDataTypes dt )
{
switch( tp ) {
#define D( nm ) \
case gt##nm: switch( dt ) { \
case gdState: return node->IntValues[ gridSTATUS##nm->Index ];\
case gdAlarm: return node->IntValues[ gridALARM##nm->Index ];\
case gdValue: return node->DoubleValues[ grid##nm->Index ];\
case gdError: return node->IntValues[ gridSTATUSERR##nm->Index ];\
} break;
D( CH4 )
D( CO )
D( O2 )
D( H2S )
D( CO2 )
D( TEMP )
D( PRESS )
#undef D
}
return 0.0;
}то я бы очень хотел узнать, что это за средство.
Из плюсов стоит отметить наличие локальной документации. Большая часть ее, к сожалению, уже создается в формате:
void SetXX( int value );
Функция устанавливает ХХ в значение value.
(пол страницы копирайтов и ссылок в никуда)
…Но такова селяви, и это еще не самый тяжелый случай. В подавляющем большинстве случаев документацией можно пользоваться и, часто, даже можно понять что, как и, главное, зачем можно и нужно использовать. В конце-концов все еще можно вызвать справку по слову под курсором, а это уже гораздо больше того, что может предложить львиная доля инструментов, позиционирующихся как средства разработки. Если кто-то считает, что документация у Builder плоха, то рекомендую осветлить чакры, полистав документацию по Andriod.
Средства для работы с «классическим» инструментарием.
Они абсолютно привычны, находятся в тех же местах, делают то же самое и точно так же, как это было во всех Builder-ах и 10 и 20 лет назад. К примеру, окно Code view осталось точно таким же тупым и убогим, каким оно было, кажется, с версии 1.0.
В сравнении с ним, окно в 64й версии выглядит чуть умнее:
Тут уже хотя бы некоторые символы подписывают. Но принципиальной разницы нет. Остальные окошки изменились с древних времен минимально.
Вообще, ничего, что работало бы хуже, чем раньше я не увидел. Все изменения, которые есть, оставили все инструменты либо на том же уровне, либо сделали их более удобными. Исключение - это разве что дизайнер форм, в котором мне крайне неудобно пользоваться одним окном вместо трех (как это есть в Builder 5) из-за невозможности однозначно перемещаться между ними с клавиатуры, но этот вид внедрен уже очень давно, и считать это недостатком текущей оболочки неправильно.
Многие современные среды могут похвастаться более удобными и интеллектуальными инструментами для отладки и управления. Но для меня лично, в Builder нет ничего, чего мне бы не хватало для комфортной и эффективной работы.
Особенность clang
Самое важное при эксплуатации clang – это компиляция и линковка. Компилятор чудовищно медленный. Неработоспособность precompiled headers во всей «гнусной» линейке инструментов добавляет к этому еще одну бочку дегтя. Возможность параллельной компиляции по ощущениям проблему не только не решает, с ней становится только хуже. Во всяком случае, у меня получалось почему-то именно так. В общем, я абсолютно не могу представить, как должен быть мотивирован разработчик, чтобы использовать clang в C++ Builder.
Чуть практики
Чтобы хоть как-то разбавить словестный понос этой статьи, я приведу некоторые фактические измерения.
За свою жизнь я писал на куче разных компиляторов и под кучу разных платформ, поэтому у меня есть несколько кусков, которые способны собираться вообще чем угодно. Они собирались в разное время такими эксклюзивами как Symantec, Watcom или DMC. Поэтому я решил, что адаптировать их еще под пару компиляторов будет довольно простым занятием.
Полный переход на современный VCL, для меня, к сожалению, невозможен, поэтому собрать какой-то сложный VCL проект я не могу. Я экспериментировал на одной из своих базовых библиотек, которая, чисто для информации, состоит из 151 файла, суммарным объемом около 1.1Мб. Обычно везде пишут количество строк, но я понятия не имею, как его посчитать, да и этот параметр вообще крайне странный на мой взгляд. Объема, думаю, будет достаточно, чтобы получить представление о масштабе теста.
Несмотря на то, что «на берегу» задача адаптировать существующий код под 3 компилятора (win32 classic, win32 и win64 clang ) казалась не очень сложной, на ее решение я потратил несколько дней. Процентов 10 времени ушло на допиливание компиляторо-зависимых кусков, процентов 30 на адаптацию кода под 64 бита и все остальное время на войну с clang. Последнее удалось частично т.к. хоть я и смог добиться того, чтобы оптимизированные под х86 куски кода вообще собирались, но тесты под них рассыпались, поэтому я на этот функционал попросту плюнул т.к. слишком много времени уходило на бесцельное ожидание.
К слову, возможно кому-нибудь пригодится табличка версий компилятора (значение константы «__BORLANDC__»).
__BORLANDC__
#define __BC31__ 0x0410
#define __BC402__ 0x0452
#define __BC450__ 0x0460
#define __BC500__ 0x0500
#define __BCB10__ 0x0520
#define __BCB30__ 0x0530
#define __BCB40__ 0x0540
#define __BCB50__ 0x0550
#define __BCB60__ 0x0560
#define __BCB2006__ 0x0570 // Developer Studio 2006.
#define __BCB2007__ 0x0590 // C++Builder 2007.
#define __BCB2007x__ 0x0591 // update 1 to C++Builder 2007.
#define __BCB_RAD2007__ 0x0592 // RAD Studio 2007.
#define __BCB_RAD2007x__ 0x0593 // the December update to RAD Studio 2007.
#define __BCB_RAD2009__ 0x0610 // C++Builder 2009 and for C++Builder 2009 Update 1.
#define __BCB_RAD2010__ 0x0620 // C++Builder 2010 and for C++Builder 2010 Update 1.
#define __BCB_RAD2010x__ 0x0621 // C++Builder 2010 Update 2.
#define __BCB_RADXE__ 0x0630 // C++Builder XE.
#define __BCB_RADXEx__ 0x0631 // C++Builder XE Update 1.
#define __BCB_RADXE2__ 0x0640 // C++Builder XE2.
#define __BCB_RADXE3__ 0x0650 // C++Builder XE3 and C++Builder XE3 Update 1.
#define __BCB_RADXE2x__ 0x0651 // January 2013 update (BCC32); BCC64 remained at 0x0650.
#define __BCB_RADXE4__ 0x0660 // C++Builder XE4 (BCC32 and BCCOSX); BCC64 remained at 0x0650.
#define __BCB_RADXE5__ 0x0670 // C++Builder XE5 (BCC32, BCC64, BCCOSX, and BCCIOSARM).
#define __BCB_RADXE6__ 0x0680 // C++Builder XE6 (BCC32, BCC64, BCCOSX, BCCIOSARM, and BCCAARM).
#define __BCB_RADXE7__ 0x0690 // C++Builder XE7 (BCC32, BCC64, BCCOSX, BCCIOSARM, and BCCAARM).
#define __BCB_RADXE8__ 0x0700 // C++Builder XE8 (BCC32, BCC64, BCCOSX, BCCIOSARM, BCCIOSARM64, and BCCAARM).
#define __BCB_RAD90__ 0x0710 // C++Builder Seattle (BCC32C, BCC32, BCC64, BCCOSX, BCCIOSARM, BCCIOSARM64, and BCCAARM).
#define __BCB_RAD90x__ 0x0711 // C++Builder Seattle Subscription Update 1 (BCC32); other compilers remained at 0x0710.
#define __BCB_RAD100__ 0x0720 // C++Builder Berlin (BCC32C, BCC32, BCC64, BCCOSX, BCCIOSARM, BCCIOSARM64, and BCCAARM).
#define __BCB_RAD101__ 0x0730 // C++Builder Tokyo (BCC32C, BCC32, BCC64, BCCOSX, BCCIOSARM, BCCIOSARM64, and BCCAARM).
#define __BCB_RAD102__ 0x0740 // C++Builder Rio (BCC32C, BCC32, BCC64, BCCOSX, BCCIOSARM, BCCIOSARM64, BCCAARM, and BCC32X).
#define __BCB_RAD104__ 0x0750 // C++Builder 10.4 Sydney (BCC32C, BCC32, BCC64, BCCOSX, BCCIOSARM, BCCIOSARM64, BCCAARM, and BCC32X).Сборка проекта классическиv компилятором, занимает всего в 2-3 раза больше времени чем в С++ Builder 5.0 (при сравнении нужно учитывать, что современное средство компилирует одни и те же тексты дважды).
bcc32 command line for "..\FastMM\FastMM_Client.cpp"
Success
Elapsed time: 00:00:12.8Сборка проекта силангом… Вот попробуйте догадаться не открывая спойлер, сколько требуется силангу на сборку того же набора исходных текстов, и сравните свою догадку с реальностью.
Clang
[bcc32c Warning] hdl_loc.h(21): Forced PKG packaging used
Success
Elapsed time: 00:12:06.1 Удивительно, не правда ли? Во всяком случае я сильно удивился.
Размер кода и оптимизацию я не сравнивал вообще т.к. оптимизация от Borland всегда была посмешищем, а в используемом мной Builder 5.0 сборка в release вообще не работоспособна при многих обстоятельствах и ее нельзя использовать. Как ситуация обстоит в современной версии компилятора глянул только краем глаза. Ситуация прежняя, т.е. никакая. Ну и бог с ней.
Впрочем, кого в наше время волнует оптимизация? Во времена, когда из неокрепших умов с помощью различных STL-ей активно куют профессиональных профанов, от которых потом приходится охранять целые области применения, о чем вообще можно говорить?
Несмотря на оптимизацию (установлена в минимальный размер) результат получился довольно странным:
Classic debug
stds_bds_p.bpl – 428Кб
stds_bds_p.lib – 13628Кб
Classic release
stds_bds_p.bpl – 644Кб
stds_bds_p.lib – 2800Кб
Clang win32 release
stds_bds_p.bpl – 433Кб
stds_bds_p.lib – 970Кб
Clang win32 debug
stds_bds_p.bpl – 695Кб
stds_bds_p.lib – 10753КбРазбираться в причинах при таком объеме затруднительно, поэтому я и не стал.
Если это читает кто-нибудь их тех, кто преимущественно работает на продуктах наследниках Borland, то он может не до конца оценить всю глубину страданий, которая постигнет любого, пытающегося использовать инструменты с «гнусными» корнями. В них нет не только precompiled headers, но даже file dependency по человечески не работает. Это приводит к тому, что при отладке с мелкими правками при использовании clang накладные расходы на ожидание сборки становятся просто огромными. Т.е. после любой правки текста, от завершения редактирования до запуска нужно каждый раз ждать минуты.
Если Вам кажется, что Delphi собирает проект быстрее чем Builder в разы, то это ничто, между различием «классикой» и clang. Лично у меня нет столько свободного времени в жизни.
Заключение
В заключение, исходя из полученного опыта, я могу дать следующую оценку современному продукту с именем Embarcadero C++ Builder.
О любых применениях clang в этой среде я рекомендую забыть. При работе с VCL он совершенно не нужен, а в тех задачах, где его применение стоит усилий, гораздо оправданнее выбрать другое средство. Его реализация в Builder ущербна, тормозна, громоздка и неудобна. Если на свете вообще существуют какие-то причины применять его в рамках этого продукта, то я с интересом бы о них узнал. Мне в голову не приходит ни одной.
Если Вы разрабатываете приложения на какой-то из версий С++ Builder и, в отличии от меня, в своей работе уже проскочили момент, когда VCL созрел для UNICODE, то я вполне могу рекомендовать Вам рассмотреть современный Builder как цель миграции своих проектов. В VCL появилось очень много нового и часть из этого может оказаться действительно полезным. Некоторые баги библиотеки и средств разработки поправили, средой вполне успешно можно пользоваться. Если у Вас есть достаточно энтузиазма и свободного времени, то рекомендую попробовать. Возможно, Вы получите от перехода на новое средство какую-то выгоду.
Если Вы случайно споткнулись о книгу «C++ Builder за Х дней», если Вы молодой и горячий или перед Вами просто стоит задача выбора средства для быстрого написания интерфейсно-нагруженных приложений под Windows, то С++ Builder это все еще самый лучший RAD на рынке для выполнения этой задачи. Текущее его состояние вполне позволит Вам создавать качественные приложения за минимальное время с вменяемыми усилиями.
Если Вам нужно писать на современном С++, если Вы горите желанием создавать модные интерфейсы и использовать наисвежайшие библиотеки из развалов гов… эээ, шедевров open-sorce разработок, то крайне рекомендую – не тратьте свое время на Builder. Изучайте что-нибудь более живое, модное и современное. Например, Visual Studio.
ПС
Я не могу дать ответ на вопрос заданный в заголовке статьи. Ответ на него каждый должен сформировать самостоятельно. Со своей стороны я только изложил наблюдения и соображения по поводу текущей версии C++ Builder, которые сложились у меня. Мой опыт, оценки и суждений, скорее всего, крайне не типичен для современных реалий но, возможно, он кому-нибудь окажется полезным.
Комментарии (105)
buratino
23.12.2021 09:46+3Кто-нибудь помнит Microsoft Pascal? А Microsoft C (без приставки Visual)?.
Я помню MS QuickC. Помещался на дискетку.. По скорости сборки уделывал в разы борланда. При запуске в пробирке пробирки для дос (среды DOS в OS/2 под VBOX) по прежнему уделывает всё, что шевелится Да, хелп там был и быстрый, и понятный, в отличии от багланда.. Не QuickC. тоже помню, но с трудом. 6 версия, 7ая вроде уже стала называться Visual
kovserg
23.12.2021 11:58+2Под дос лучше всех был symantec c/c++, qbasic и turbo pascal7. И еще справочник.
vdasus
23.12.2021 14:40+1Zortech c++ (если я правильно помню — из него вырос symantec c++)… А zortech был бомбой. Особенно его офигенно быстрая FlashGraphics в отличие от тормозного BGI от борланда. Вроде правильно вспомнил названия. Давно это было…
JouriM Автор
23.12.2021 23:31+2Правильно помнишь. Еще оба эти компилера были первыми, котрые имели серьезную, шокирующую по тем временам, оптимизацию кода.
Семантик запомнился еще тем, что имел уникальные библиотеки, для той же графики, математики и писания резидентов, когда ризидентом висело только ядро, а вункционал подгружался при импользовании.
Indemsys
23.12.2021 10:47+1Как то обойдена вниманием компонентная база.
Что там нового в компонентах, что нового в VCL , в RTL в Alexandria?
Что можно сделать в бесплатной версии C++Builder Community Edition?Когда я пользовал Builder, то всегда приходилось использовать гибридный способ редактирования: основную массу работы по вводу текстов делал в SlickEdit, контекстный выбор методов, классы и проч. делал в IDE билдера. Оба редактора умеют подхватывать сторонние изменения поэтому все получалось довольно складно.
Гибридный метод очень характерен при разработке встраиваемых систем, поскольку такие IDE как Keil или IAR тоже очень бедны в плане функциональности редактирования и приходится использовать сторонние редакторы.
prefrontalCortex
23.12.2021 11:00+11Clang имеет «гнусные» корни
Вы ошибаетесь, хоть у Clang и GCC совместимые аргументы командной строки, это два абсолютно разных продукта с разными кодовыми базами, разным внутренним устройством, разными лицензиями и разным происхождением.
Он существенно отстает по всем могущим прийти в голову фронтам от аналога, используемого Microsoft
Приведите пример хотя бы одного такого фронта. Сишный компилятор от ms поддержкой стандарта C11 обзавёлся только в 2020 году, это же посмешище, а не компилятор.
По поводу жалоб на скорость Clang - а в нынешнем сибильдере есть возможность использовать предкомпилированные заголовки? Уверен, это ускорит компиляцию (если, конечно, эта возможность там есть; последний сибильдер, который я трогал вживую, был версии 6.0, и там ничего подобного, конечно, не было).
JouriM Автор
24.12.2021 02:44Приведите пример хотя бы одного такого фронта
В последней студии, которую я трогал силанг был именно дефолтным компиллером.
А фронты - это: поддержка всех прагм и ключевых слов именно в вижуальном их синтаксисе и значении, полная поддержка вижуальных ключей строчником. Он даже определяется как __MSVC__, в от личии от билдера, где __BRLANDC и __clang - это 2 разных компирера. А то что оно там не самый свежий стандарт поддерживает, мне глубоко по барабану, если честно. Добавят потихоньку и при лбом раскладе это случится гораздо раньше чем у Embarcadero.
А в остальном... а зачем вообще комментить, если текущее средство Вы не видели и его описанны особенностей не знаете?
kryvichh
23.12.2021 11:12По 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. Но оно несомненно стоит того.
dMac
23.12.2021 13:23Попробую ответить за автора. Да, C++ Builder удобнее дельфей, когда надо залезть в низкоуровневые системные дебри, например, руками импортировать какую-нибудь из коробки недоступную функцию WinAPI. В остальном примерно все то же самое.
HemulGM
23.12.2021 14:41+4Вообще-то Делфи легко и просто импортирует функции winapi. Также просто. Название функции, ее название в экспорте dll и название dll. Готово. Одна строка. Если надо, описываем и структуру, если таковая передается в параметрах по указателю
sshmakov
23.12.2021 16:13+1Правды ради структуру для билдера описывать не надо, т.к. инклюдник подключается без танцев с бубном.
HemulGM
23.12.2021 16:27+1Правды ради, есть инструмент для генерации модуля pas из хидеров)
JouriM Автор
24.12.2021 00:08+1Те что я видел были крайне тупы. Вернее так: они полностью ломались при использовании сложных макросов, а это один из мощнейших инструментов в С.
Второе, что делало подобные инструменты практически бесполезными - это условная компиляция.
Если учесть еще и то, что крайне редко дело ограничивается одним единственным заголовочным файлом, чаще их несколько, связанных друг с другом, а в паскале жесткие ограничения на модульность, то я не видел средства, которое бы позволяло создать готовые описания в сколько-нибудь сложных условиях.
Есть такие?
JouriM Автор
24.12.2021 00:02А есть ли хоть какие-то преимущества у C++Builder перед Delphi для Windows-разработки?
Если рассуждать в принципе, то таких преимуществ одно - это возможность использовать АПИ напрямую, без его заново. Это касается как самого виндового АПИ, так львиной доли сторонних библиотек, т.к. процент чего-то стоящего написанного на паскале, в сравнении с С - незначителен.
Если же рассматривать только создание приложений, где полностью хватает функционала VCL, то преимуществ я не вижу. Только архитектурные, связанные с различиями языков в принципе.
был бы конвертирован в Delphi, вы бы предпочли с ним работать, или остались бы с C++?
Это два разных языка. Рассматривать переход с одного на другой разумно только если один из них предоставляет какие-то средства, вообще не реализуемые в другом.
К примеру, в свое время одним из критериев перехода на С для меня стала практически полная невозможность в паскале использовать ни ассемблер, ни код из С. Т.е. в те времена, если под что-то не было TPU (то что в дельфи DCU), то ты не можешь это реализовать практически никак. А в те времена как раз играли в видео с прямым доступом к памяти, перекодировали тектовый кодогенератор, чтобы сделать "графическую мышь в тексте", пимали резидентов и прочее.
Сейчас возможность средств различается не принципиально. Да и язык этот мне уже не нравится. Меня бесит подход "один класс - один файл". С ужасом смотрю на компоненты дельфи, пипа инспектора объектов, котрые занмают мегабайт одним файлом. Я так думать уже разучился :)
HemulGM
24.12.2021 00:15Путаете вы Делфи и Шарп. В делфи нет правила и ни кто не делает "один файл - один класс". В шарпе как раз это типично.
И код на асм в Делфи можно писать напрямую. Не знаю уж, в какой версии вы писали, но эта возможность существует наверно с первых версий языка.
Ну а по поводу компонентов вообще не понятна претензия. Речь о разметке? Ну и в разметку лезть нет ни какого смысла. Можно считать этот файл бинарным, потому что он полностью управляется средой.
Ну и если речь о различии, то в делфи есть кроссплатформенный фреймворк с возможностью одно и то же приложение нативно запускать на почти любой платформе. Не внося изменений в код. Просто переключая вариант сборки
JouriM Автор
24.12.2021 10:30+1Я не путаю, я неточно выразился. В паскале невозможно разделить объявление и имплементацию. Это все должно быть в одном файле, "юните". Если имплементация занимает мегабайт - файл будет в мегабайт.
В шарпе-то как раз есть штатный синтаксис для разделения кода имплементации.
Остальной текст я просто не понял. То с чем Вы спорите я вообще нигде не писал.
kovserg
24.12.2021 11:12Там юнит складывается в бинарном виде, а не парсится тысячи раз текст как у некоторых.
HemulGM
25.12.2021 14:06В паскале (Delphi) легко и просто можно описать класс в одном файле частично и расширить его интерфейсами, классы для которых описаны в других файлах или вообще в dll.
Достаточно сказать, что класс реализует этот функционалTMyClass = class(TObject, IMyInterface)И объявить свойство такого вида
property MyInterface: IMyInterface read FMyInterface implements IMyInterface;После чего нам не нужно в этом классе реализовать методы интерфейса, а взять их в любом другом классе. В том числе, как я уже сказал выше, загрузить класс из dll динамически
JouriM Автор
25.12.2021 14:30Ничего не понял. Зачем какие-то свойства из интерфейсов, кто их будет использовать? Как можно создать финальный класс без реализации? В каких других файлах и длл-ах?
Поясню что я имел в виду. Я пишу наследника какого-нить TWinControl. Мне его нужно использовать напрямую, т.е. создавать объекты такого класса. Как мне помогут какие-то интерфейсы разделить код реализации этого класса на несколько файлов?
HemulGM
25.12.2021 14:46Это не свойства из интерфейса, это добавление функционала класса из другого класса. Свойством ты лишь подключаешь нужный тебе класс, который реализует указанный интерфейс.
Все методы будут доступны напрямую, а не через обращение к свойству.
JouriM Автор
25.12.2021 16:00Я знаком с концепцией интерфейсов :)
Вопрос был в другом: зачем они вообще нужны в описанной мной задаче и как они позволят разделить код физически, если предположить (на практике так оно и есть), что логически он не разделим.
HemulGM
25.12.2021 16:56Если часть класса описал ты у себя, а другую часть класса взял из dll это не разделение?
Если класс описал ты в файле м1, а другой класс в файле м2, а затем через интерфейс их объединил это не разделение?
Massacre
24.12.2021 18:38+1Это в какой версии паскаля нельзя было использовать ассемблер и код из C? Даже Borland/Turbo Pascal 7.0 отлично делал и то (вставка asm) и другое (obj модуль, с какой-то минимальной обвязкой в виде декларации процедур).
LittleAlien
24.12.2021 00:37А есть ли хоть какие-то преимущества у C++Builder перед Delphi для Windows-разработки?
Я думал об использовании C-Builder в дополнение к Дельфи для оптимизации узких мест. То есть основная программа на Дельфи (более простой и приятный язык), а то, что раньше делалось ассемблерными вставками, делается функциями на Си (который всё-таки более читабельный по сравнению с ассемблером). Си как замена ассемблеру - назад в 1970-е :)
Но это имеет смысл только если вам нужна вот такая суровая оптимизация, с ассемблерными или сишными вставками. Для большинства Дельфи-проектов (разного рода морд к БД) - очевидно, не нужна.
И C-Builder в конечном итоге оказался для этого неудобен, использую сишный код через dll, собранную CodeBlocks и Clang/gcc.JouriM Автор
24.12.2021 00:41Не очень понимаю о какой опитимизации паскаля с помощью С Вы пишете. Либы Вы не очень понимаете :)
Касательно встроенного АСМа дельфи намного мощнее и удобнее чем С и, если иметь в виде такую оптимизацию, то гораздо логичнее, наоборот, реализовавыть ее на паскале.
Если же Вы почему-то считаете, что код на С будет более оптимальным сам по себе, то дело обстоит ровно наоборот. Из-за архитектуры паскаля код, котрый генерит компилер, будет в большинстве случаев компактнее и, часто, быстрее аналогичной реализации на С.
LittleAlien
24.12.2021 03:47+1Я собирался использовать не классический компилятор Билдера, конечно, а как раз Clang-based. Который по идее должен уметь векторизацию, развёртку циклов, эффективный инлайн - во всяком случае оригинальный Clang умеет.
И тормозит он не (не только) потому, что у разработчиков руки кривые, а потому что там гораздо более сложная оптимизация.JouriM Автор
24.12.2021 06:53В таком ключе, если дельфи умеет прозрачно подключать файлы С в проект (последнее что явидел так не умело), этот подход вполне имеет право на жизнь.
Единственный момент из моего опыта молодости, когда сочинение всяких кейсов и их проверка на оптимизированность еще было интересно: чтобы получить оптимизированный код нужно уметь правильно писать исходный. Т.е. нужно понимать что и как может оптимизировать компилятор и в каких условиях это работает, а в каких нет. Если такие знания есть или есть желание их приобрести, то вполне разумная замена ручной оптимизации. Ее это заменить не сможет все равно, но будет значительно быстрее.
ПС: То что более навороченные компиляторы будут работать медленнее для меня не неожиданность. Неожиданным стало НАСКОЛЬКО медленнее. Для меня такая разница попросту ставит крест на использовании, хотя если речь идет о точечной оптимизации можно свести тормоза к вполне приемлемым.
Siemargl
24.12.2021 07:56Из-за архитектуры паскаля код, котрый генерит компилер, будет в большинстве случаев компактнее и, часто, быстрее аналогичной реализации на С.
Это какое то безосновательное заблуждение.
Для начала, код от компилятора Дельфи х64 10.3 почти втрое быстрее, чем тот же код от Дельфи х32. 26сек vs 71с
При этих же условиях, код от современного С-компилятора укладывается в 11с.
Исходники доступны - проверьте у себя.
JouriM Автор
24.12.2021 08:21Посмотрел... если честно, то всерьез сравнивать код на С, на 90% состоящий из инлайнов с чисто процедурным кодом на паскале... мне как-то бы даже в голову не пришло. Переведите весь С код в функции либо в паскале inline используйте. Иначе вообще непонятно что с чем сравниваем.
Это если вообще всерьез рассматривать пример из 3х вложенных циклов как базу для выводов о возможностях оптимизации. Что, на мой взгляд, несколько странно.
Когда-то давно, когда только появился perl, один мой товарищ, который им заболел, на примере синтетического парсера доказывал, что php быстрее С. В его случае, в сравнении с влоб написанным кодом на С ровно так и выходило. Но тогда все, даже он, воспринимали этот результат не более чем прикол.
ПС: Я не знаю как сейчас, а в свое время intel делал билиотеки для вижуала с очень быстрой математикой и у них даже был свой вариант компилятора. Если они все еще живы, то просто соберите любой сишный кусок из приведенного вами репозитория им (правда оно было жутко коммерческое, но вдруг найдете). Только наличие pow во внутренних циклах подсказывает мне, что этот кусок сразу взлетит по скорости в разы. Вопрос только в том, скажут ли эти новые цифры что-то о качестве оптимизации?...
Siemargl
24.12.2021 08:27+2Там весь код написан в едином стиле для разных языков (порт с единого исходника). Можете выбрать для теста удобную себе, а не абстрактно рассуждать о высоком. Вот, без инлайнов и тоже менее 11сек (хотя чем ключевое слово inline мешает? тот же билдер втыкает близкий аналог __fastcall где только можно)
JouriM Автор
24.12.2021 08:47-1Серьезно? Т.е. вы считаете, что убирав ключевое слово, но оставив тело в структуре Вы избавились от инлайна? Вы где учились?
Впрочем бог с ним. Спорить с Вашим мнением я не хочу.
Siemargl
24.12.2021 08:55+1Код на Паскале и на С++ аналогичен - процедурный. Проблемы неумения компилятора инлайнить самостоятельно или оптимизировать операции с плавающей точкой меня не волнуют. Итоговую скорость видно.
А про "где учились" - я Вам верну - проблемы с компиляцией С++ кода, описанные как "ая-яй-яй" в статье Clang'om у Вас от непонимания стандарта С++ и написания некорректного кода, который более строгие компиляторы не пропускают (GCC кстати, тоже).
Более того, вся статья показывает Ваше неумение пользоваться инструментами :
Обычно везде пишут количество строк, но я понятия не имею, как его посчитать
https://superuser.com/questions/959036/what-is-the-windows-equivalent-of-wc-l
NeoCode
23.12.2021 11:17+4У меня о Билдере достаточно теплые воспоминания, я начинал с него (вместе с Borland C++ 3.1 для DOS). Нативный набор виждетов, но при этом гораздо более богатый чем в MFC (с которым я познакомился позже). В результате приложения получались весьма красивые и достаточно быстрые. Приятное расширение языка - "свойства", его порой нехватало в других диалектах С++. Дальше уже перешел на Qt, embedded, немного C# и всякое прочее.
По уму, компании Embarcadero следует открыть исходники их компилятора (как минимум), а в идеале и всей системы, исключая разве что какие-то чисто бизнес-ориентированные компоненты. Какой бы древний код там ни был, а энтузиасты всегда найдутся. И это просто интересно. И очень жалко, когда закрытые исходники уходят в небытие, потому что компания по тем или иным причинам закрывается.
sidorovmax
23.12.2021 11:24Watcom C открытие исходников не помогло.
NeoCode
23.12.2021 11:29+1Я могу ошибаться, но кажется некоторые исходники были использованы для компилятора языка D.
Siemargl
24.12.2021 07:59Нет. D вырос из DMC (Digital Mars Compiler), бывший Symantec C++, бывший Zortech C++. Это если говорить о референсном DMD компиляторе.
Сейчас уже впрочем уже другая кодовая база и есть 3 разных компилятора D - на LLVM базе LDC и на GCC - GDC (начиная с GCC 9.2)
JouriM Автор
24.12.2021 02:51Не помогла стать популярным на винде? А как наличип исходников в этом ему могло помочь? Он не может предложить ничего, ради чего его стоило бы предпочесть конкурентам.
Открыли исходники они вовсе не для набора популярности, а чтобы перейти в нишу специфических ОСей. К примеру я писал одно время под QNX (линуксоподобное микроядро под х86ю платформу). В нем единственный компилятор - это именно ватком. Есть еще некоторые места, где ватком используется. Возможно из-за того, что он оказался открытым в нужное время, или более дешовым или еще что.
Mozhaiskiy
23.12.2021 11:26Кстати о RAD. А между прочим, тёплая и ламповая Delphi всё ещё жива, Embarcadero её даже развивает, несколько лет назад даже завезли некое подобие кросплатформенности. Чем не быстрая среда разработки? Другой вопрос, что в 2021-м у Delphi практически нет преимуществ перед VS — C# не сложнее и куда мощнее ObjectPascal (даром, что у них общий отец), а прицнип "накидали компонентов на форму и связали события" и там, и там одинаковый.
ciuafm
23.12.2021 11:48Начинал на Делфи, последняя установленная версия 7я. Сейчас сижу на c#. По моим воспоминаниям Делфи IDE намного быстрее чем Студия на сопоставимом оборудовании. Недавно ставил 1ю Делфи на ретрокомп. Очень удивился потрясающей скорости работы.
HemulGM
23.12.2021 17:00-2Помимо этого, кроссплатформенность там действительно кроссплатформенность. Т.к. позволяет собирать на все платформы (в отличии wpf), а авалония до сих пор не имеет дизайнера
Mozhaiskiy
23.12.2021 21:29ЕМНЕИП, Delphi многократно побеждала в разных тестах по критерию "скорость сборки проектов", в ней это действительно магия. И имхо, Reference Counting куда более крутая идеология, чем топорный GC. В ObjectPascal нет сложных бесконечных malloc, но и бросать не приятно, почти любой объект имет простой и понятный метод .Free();
Честно говоря, ужасно скучаю по ObjectPascal, хоть и знаю C#. Да, в шарпе возможностей больше на порядок, но в объектном паскале была какая-то психологическая комфортность написания, не было ощущения непрерывной войны с кодом. Ну и как бы скорость нативного исполнения, никаких управляемых прослоек. Не даром Skype (когда он ещё был быстрым и нативным) был написан именно на Delphi.
PS. Вы прямо читаете мои мысли. Буквально на днях запускал Delphi 1 в Win311 под DosBox. Чёрт, оно реально летает, включая BDE. Конечно, по меркам 2021 это примитивно, но скорость и простота настройек (фактически, их отсутствия) какие-то запредельные. В плане написания мелких утилит "для себя" конечно она была вне конкуренции. Добрая половина корпоративного ПО конца 90-х в РФ писалась на Delphi, это же прямо конструктор. Вспомнил великую и прекрасную RXLib, на которую все молились :) Эх, ностальгия.
Antohin
23.12.2021 13:24+1Какое-то время назад преимуществом Delphi/Builder перед C# была возможность собрать "монолитное" приложение в которое залинковано все что надо, без необходимости тащить огромный рантайм.
Сейчас, конечно, рантайм C# есть везде, за исключением самых экзотических случаев. Но, имхо, рантайм все равно может доставить головной боли своими версиями, если стоит задача поддерживать приложение на сотнях машин
jaiprakash
23.12.2021 15:35В теории .net должен быть вшит в винду, но на практике регулярно докачиваю пакеты при установке приложений. Наверное, когда пишешь на шарпе, об просто не знаешь.
buldo
23.12.2021 19:19+1Справедливости ради, сейчас можно собирать C# приложения в здоровый exe на 100 метров, внутри которого будет и рантайм запакован.
JouriM Автор
24.12.2021 00:18Вы очень поверхностно знакомы либо с С#, либо с VCL. Общего у этих идеалогий практически нет. Сильно вводит в заблуждение что и там и там есть какая-то форма и какие-то компоненты, которые вроде бы можно перетаскивать мышкой (в случае WinForms, в WPF уже даже это не так), но эта похожесть - заблуждение. Под капотом они работают абсолютно по разному.
Различие настолько большое, что если пытаться писать в том же С# опираясь на свой опыт VCL, то быдет очень тяжело. Придется сильно переучиваться.
Massacre
24.12.2021 18:46С другой стороны, есть определённые преимущества в плане производительности, в Delphi-то нет сборки мусора :)
JouriM Автор
25.12.2021 01:28+1Не совсем и не всегда это так.
Во-первых, в львиной доли ПО время ужодит не на работу, а на ожидание. Девайсов, инпута и т.д. Во-вторых, плохо написанная программа без gc почти всегда будет работать менее оптимально чем плохо написанная программа с gc. Язык неважен. Все "не нативные" языки были придуманы для того, чтобы понизить порог ими владения. Т.е. снизить требования к квалификации разработчика. С ростом производительности компов это стрельнуло в обратную сторону: всю работу, котора раньше требовала большей квалификации теперь может выполнять человек с заметно меньшей. Как следствие, снизилась потребность в квалифицированных разработчиках, их перестали готовить, мест приложения их сил стало меньше - они почти вымерли. Я это к тому, что в большинстве случаев, сравнивая "среднюю по больнице" программу написанную на языке без gc и с ним, нам придется сравнивать именно плохо написанные программы. Это сильно нивелирует разницу между этими средствами.
Massacre
25.12.2021 10:53А потом на Хабре появляются статьи на тему «куда скатился софт», да… Хотя Delphi-то особо высокой квалификации разработчика не должен требовать.
gdt
23.12.2021 12:32+1У VisualAssist был неплохой code completion для C++, не знаю конечно как он справится с вашим куском кода, проверять нет желания :)
sergegers
23.12.2021 18:04С Решарпером ни в какое сравнение не идёт по точости. Собственно, кроме Решарпера никто не справляется со сложным кодом ни VA (быстрый, но абсурдные suggestions у code completion'а), ни нативный Intellisence (медленный и неправильный одновременно).
shiru8bit
23.12.2021 12:34До сих пор регулярно пользуюсь бесплатной версией от 2005 года, которая тогда шла под названием Borland Turbo C++, но это самый обычный Builder без части компонентов. Пригождается для очень быстрого набрасывания всяких одноразовых утилит, где требуется GUI. Наверное сейчас есть что-то значительно получше, но привычка страшная сила, и легаси - скорость в том числе повышается за счёт копи-паста из старых аналогичных проектов, которых накопились десятки.
OlegZH
23.12.2021 16:13Я зайду со стороны 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, это — свойства. Было бы крайне любопытно посмотреть на то, как этот подход можно было развить...
JouriM Автор
24.12.2021 01:17Ой, ой, ой как у Вас все неправильно! :)
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# сейчас был бы совсем другим.
Паскаль - это язык, с одной стороны лишенный попугайской зависимости отконкурентов и, с другой, не страдающий от самопровозглашенных стандартов. Он сам себе конкурент и сам себе стандарт. К счастью, люди которые определяют его развитие достаточно адекватны, чтобы не тащить, как вороны все блестящее в одну кучу мучительно воюя с рассыпающейся песчаной башней, как это происходит в С. Результатом, к примеру, является то, что уровень владения инструментарием среди паскалистов на порядки выше, чем в среде С разработчиков. Т.е. людей, которые понимают как оно работает, какие техники оптимально использовать и где, на порядок выше. Я это все к тому, что, возможно, то, что в нем нет перегрузки скобочек и операторов это к лучшему.
OlegZH
25.12.2021 22:26Вы не возражаете, если я вернусь к этому Вашему колмментарию сильно позже. Он потребует вдумчивого чтения.
DavisR
23.12.2021 16:50Если на свете вообще существуют какие-то причины применять его в рамках этого продукта, то я с интересом бы о них узнал. Мне в голову не приходит ни одной.
x64 же?
Классический компилятор x86 onlyHemulGM
23.12.2021 17:11Классический компилитор и в х64 может. BCC64.
Правда я тут немного плаваю, т.к. я работаю в основном в Delphi.
DavisR
23.12.2021 17:40+1Classic не может.
docwiki.embarcadero.com/RADStudio/Sydney/en/BCC64BCC64 is based on Clang
JouriM Автор
24.12.2021 01:22+2Именно в этом и была мысь: зачем на билдере вообще что-то кроме классики? Все остальные делают это лучше и быстрее.
Мой ответ на это в статье: Embarcadero не может.
DavisR
24.12.2021 11:50Что — «это»?
Rapid development x64 приложений под Windows с VCL?JouriM Автор
24.12.2021 12:21Да.
Если бы силанг работал вменяемо быстро и был бы совместим по фичам с классикой, его наличие было бы оправдано и являлось бы премуществом (ну или достойной фичей) билдера. Пока это не так, его наличие на мой взгляд исключительно для галочки.
Учитывая, что силанг - это целевой тренд, возможно его допилят когда-то в будущем. Правда надеяться на это... сам билдер-то в рад-студии - это приставка к паскалю, а силанг это вторая производная :)
DavisR
24.12.2021 12:33Еще раз, как создать в C++ Builder x64 приложение под Windows, используя только классический компилятор?
sergegers
23.12.2021 18:19[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.
alexeibs
24.12.2021 00:48+1Так же нужно учитывать, что средств, предоставляющих тот же 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) и к скорости компилятора у меня больших претензий нет. Местами собирается долго, но это связано с размером кодовой базы, злоупотреблением кодом в хедерах и лишними зависимостями. Сборочный кэш, распределенная сборка в целом решают проблему с долгой сборкой.
Ritan
24.12.2021 02:22Скорее всего там где-нибудь торчал "предкопилированный" хедер, куда была включена вообще вся стандартная библиотека( а возможно и не только она ). Отсюда и время компиляции такое. Clang конечно не образчик скорости( он, вроде, ещё от gcc отстаёт ), но не настолько
Clion для разработки под винду подходит, но средств формошлёпства в нём нет. Так что если что-то и делать, то долго и мучительно ручками из кода. Или притащить на пару минут Qt creator, дизайнер которого вполне себе приличный( в отличии от остальной IDE имхо )
JouriM Автор
24.12.2021 12:35Скорее всего там где-нибудь торчал "предкопилированный" хедер, куда была включена вообще вся стандартная библиотека
Какая разница что там торчало, если сравнение скорости одних и тех же сорсов, собирающихся под одинаковую платформу с одинаковыми ключами. Если и "торчит", то в обоих одинаково. Классика умудряется это пережевывать в 60 раз быстрее.
В принципе, если бы существовала бы какая-то форма precompiled-ов, то разница была бы "всего" раз в 10, наверное. Но 64-и битная версия не поддерживает вообще никакую форму precompiled. Ни классик-стайл по прагме, ни вижуал-стайл по заранее сохраненному слепку с одного файла.
И проблема при его использовании еще в том, что речь идет не о использовании абстрактного кода в вакууме, а про сборку VCL, которая тащит за собой очень много всегда.
Ritan
24.12.2021 16:22+1Какая разница что там торчало, если сравнение скорости одних и тех же
сорсов, собирающихся под одинаковую платформу с одинаковыми ключами.
Если и "торчит", то в обоих одинаково. Классика умудряется это
пережевывать в 60 раз быстрее.Если один компилятор использовал предкомпилированный хедер, куда входило очень большое количество кода, а второй компилятор вынужден парсить весь этот код каждый раз с нуля, то это проблема не компилятора и это могло бы объяснить даже 100-кратную разницу в скорости. А если учитвать тормозное дисковое IO под windows, то это может объяснить дополнительную разницу.
Просто ваш текст создаёт впечатление, что такие тормоза - проблема clang. Но это, скорее всего, не так
JouriM Автор
24.12.2021 03:04Я же написал "средств уровня java", где Вы прочитали что их вообще нет? Хорошие анализаторы кода для явы на лету интерпретируют код, по мере его ввода, что позволяет добиться изумительной точности и адекватности советов по подстановке и замене. Если что-то подобное для С существует, то я этого не видел.
Во-первых, clang собирает не 12 секунд, а 12 минут! Во-вторых, опять-же, я нигде не писал что ЛЮБОЙ силанг будет рабоать так же. Наоборот, я даже явно написал что в той же вижуал студии он работает на порядо быстрее (в том числе из-за того что они прикрутили к нему precompiled). Смысл статьи же не в обзоре всех возможных вариантов, а в узком обзоре конкретного средства. Пока у embarcadero силанг чудовищно медленный, несовместимый с классикой и сам с собой.
Siemargl
24.12.2021 08:09В Билдере, очень старый Цланг, был версии 3.5 в Билдере10.2. При том, что на транке уже Цланг11
В 10.4 обновили до Clang 5.0 и есть поддержка предкомпиляции. Может стоит обновить 12-минутный тест?
JouriM Автор
24.12.2021 12:42В комплекте 2 разных силанга (я там не знаю про базовые версии, по факту). 32-и битный поддерживает precompiled по дампу с одного файла, а 64-и битный не поддерживает вообще никакого.
Для 32 бит можно было бы сделать отдельное измерение... если бы эта шляпа корректно работала. Мои эксперименты показали, что более 1 раза силанг с прекомпайледами не справляется и обсыпается ошибками. Далее либо полный ребилд, либо удаление дампа вручную. В сумме получается, так же по времени.
alexeibs
24.12.2021 23:06Если что-то подобное для С существует, то я этого не видел.
Не видели, но это не мешает вам в тексте писать "не существует в природе". Вы уж определитесь, не существует в природе, или все-таки вы не видели?
Вот к примеру Resharper - богатое на фичи расширение к Visual Studio. Там и автодополнение, и навигация по коду и рефакторинг есть. Вам там какой фичи не хватает, чтоб было ближе к "уровню java" ?
Про долгую сборку - тут надо разбираться что тормозит, неправильно из одного частного случая делать вывод, что компилятор медленный. 12 мин - это как-то совсем из ряда вон. Благо для clang'а есть средства профилирования компиляции: https://aras-p.info/blog/2019/01/16/time-trace-timeline-flame-chart-profiler-for-Clang/
BTW clang читается, как "клэнк", а на "силанг"JouriM Автор
25.12.2021 01:47Вот к примеру Resharper - богатое на фичи расширение к Visual Studio
Спасибо. В какой версии он уже есть максимально функциональный? Сам вижуал мне применить негде, но для теста интересно было бы посмотреть.
Вам там какой фичи не хватает, чтоб было ближе к "уровню java" ?
Мне лично всего хватает. Львиную долю сорсов я набиваю вообще в редакторе FARа. Если же говорить о том, что мне понравилось при писании на том же Kotlin - это:
контекстная подстановка конструкций. Если я написал if и закрыл скобку, то при наборе "е" я получаю "else"; находясь в скопе класса по "pu" public и не наоборот. И т.д.
по мере ввода моментально получаю список того, что возможно использовать в этом месте, отсортированный по локальности. Т.е. сначала локальные переменные, потом классовые, предков, привязок и т.д.
в списке подстановки находится только то, что можно применить. Если в месте использования нужна функция, то будут только функции, которые возвращают то, что нужно в месте использования, если нужен енум определенного типа, то будут только его элементы и т.д.
-
Это конечно больше таракан явы, в которой нет хелпа, но часто очень сильно помогает javadoc, который вспывает когда ты ходишь по списку предложений. Как найти что-то новое, так то, что ты забыл как называется или что именно точно делает.
В результате работы такого средства, часто, набор кода заключается в наборе разделителей, пары первых букв и нажатие пробела (или enter у кого как настроено).
ArtZilla
24.12.2021 01:23+1У меня сейчас на работе достаточно большая часть кода до сих пор на смеси Delphi 2007 и C++ Builder 2007. Эта та последняя до юникодовская версия, конечно, хотелось бы перейти на более новую, но придётся проделать работы столько же, сколько займёт переписывание на чём-то более современном. Значительную проблему представляют различные компоненты, которые либо надо заново покупать, либо их уже давно забросили. А так же асемблерные вставки, которые были оставлены прошлыми разработчиками шутки ради. Стоит ещё отметить, что сама RAD Studio, по моему субъективному мнению, значительно менее удобная, чем Visual Studio 2022 или JetBrains Rider.
На данный момент решил проблему неспешным переписыванием кусочков кода на C#, благо это всё относительно совместимо. (не считая всяких подлянок на границе managed и unmanaged кода).JouriM Автор
24.12.2021 01:26У меня ровно та же проблема: зависимость от либо умершего, либо модифицированного до несовместимости паскалевского кода. Трата времени на переписывание с нуля всех этих кусков не опревдана.
К сожалению специфика моих программ не дает возможности дописывать что-либо на том же C# или чем-то еще. Чтобы это сделать придется практически переписать заново все, что было создано за последние лет 20. Вот и сижу где сижу :)
vasiliuz
24.12.2021 03:06У всех своя правда... Стоит и стояла задача сделать десктопное приложение под винду и мак... Так как весь код на C++ - выбор пал на билдер и мульиплатформенный FireMonkey. Главный фокус был в том, что один и тот же код работает как под виндой так и под маком, и выглядят приложения одинаково. Но Емберкадеро убило поддержку макОс в билдере, со времен перехода на 64бит. Причем не могло в этом признаться полтора года, кормя завтраками и след. релизом. И до сих пор ее не сделало. Нам пришлось переписать весь код на Делфи, а непереводимое засунуть в DLL. После этого я прсто люто ненавижу Емберкадеро. К сожалению я не знаю годной альтернативы, для приложений под вин+мак. Есть фреймворки типа JUCE для С++, но они проигрывают по удобству разработки Делфи....
JouriM Автор
24.12.2021 03:15Сочуствую, но, на мой взгляд, Вы изначально выбрали неправильное средство. Нужно было либо сразу писать на дельфи, либо использовать вообще другие инструменты.
У меня была однажды сходная задача, только с андроидом. После рассмотрения того что и как делает билдер в плане многоплатформенности я поставил крест на билдере и потратил 2 недели на написание нативного приложения под андроид, о чем не жалею. Если бы сейчас встала аналогичная задача, то не думаю, что использование для этого билдера мне вообще пришло бы в голову.
vasiliuz
24.12.2021 03:22+1Почему изначально выбрал не правильнео средсьво? Они везде декларировали кросс-платформеноость среди разработки, как Делфи так и С++. Но когда дошло дело до обновлений, то С++ они перестали обновлять, а обновляли только Делфи! Причем полтора года не могли признаться что все-таки С++ они притормозили. А пользователи приложения нам полтора года саппорт выносили поддержкой мак 64 бит. А мы ничего не могли сделать....
И на счет совсем другие инструменты? Это что, например? Чтобы один и тот же код работал по разными ОС, и выглядел одинаково. JUCE и Qt только приходят на ум. JUCE не подошел бы по возможности с GUI. У Qt - свои тараканы....
JouriM Автор
24.12.2021 03:35Я же привел свой аналогичный пример. Я не знаю в какое время Вы выбирали средство, но тогда когда его смотрел я пол дня экспериментотв оказалось достаточным, чтобы его исключить. Я это и имел в виду, что Вы недостаточно ответственно подошли к выбору инструмента для долгосрочной разработки. Возможно это и не так, я Вас понял неправильно. Если на берегу все было (в реальности, а не в рекламе), шикарно, а потом блдер сломали, то в этом случае да, "казлы" и прочее. Но для справедливости стоило бы все же отметить что такие же точно "казлы" и маковцы, котрые сделали невозможным использование старого средства (если, опять же, я правильно понял проблему).
А другие средства - это другие. Если под набор критериев не подходит ничего, то нужно менять этот набор. Нет того что умеет одинаково и удобно, значит либо пишите на разном, либо миритесь с неудобствами, чтож поделать-то? Я как-то написал морду под мобилку для своего сервера вообще на LUA с помощью Corona. Случай, разумеется, очень далек от Вашего.
vasiliuz
24.12.2021 03:45Проблема в том, что билдер мог создавать только 32-ух битные приложения под макос. Мак Ос перевели на 64 бит. И 32-ух битные приложения перестали работать в новых версиях ОС. Для делфи сделали поддержку 64 бит, а для Билдера нет - и тянули полтора года с этим. Теперь Эпл выпустили АРМ М1. Делфи сделали поддержку, а Билдер все в том же состоянии. И это вот за последние 3 года -) Когда мы выбирали Билдер - он был на равне с Делфи. Но в процессе его задвинули на не приоритетное направлние - и по сути не развивают, или развивают по остаточному принципу. Эпл тут не причем. Эмбаркадеро - козлы. Согласитесь сделать сборку под 64-бит в 2019-2021 году для С++ компилятора не сверх задача! Тоже самое у них было с 64 бит для Андроида.
JouriM Автор
24.12.2021 07:04+1Не соглашусь. По описанию проблемы казлы именно эппл. Это как взять сейчас и в винде запретить все 32битные приложения. Меньшее что меня при этом будет интересовать - это поддерживают там что-то отдельные компиляторы или нет. В макоси крошечная экосистема, конечно, но для меня, как потребителя, это все равно выглядит как форменное свинство.
Но Ваше негодование я вполне понимаю :) Хотя, все же, рассчитывать на что-либо от продукта, проходящего уже четвертую (вроде) стадию перепродажи я бы не стал уже на берегу. Другое дело дельфи, тут еще есть какая-то надежда на уверенность. Желаю Вам не получить фаталити с дельфи, когда маковцы опять развернут оглобли куда-нибудь :)
Daddy_Cool
25.12.2021 22:57Очень интересная статья!
Я как-то споткнулся о книги Архангельского и восхитился удобством программирования. Накидали менюшек-окошек, накидали компонентов, описали свойства… и всё работает.
В какой-то момент заметил, что мне стало лениво писать что-то самому и я прежде всего ищу компоненты.
Собственно для своих научных нужд сейчас пишем в основном консольные штуки, а если нужны менюшки-окошки — на BCB6.
Стало интересно, а что сейчас происходит — заглянул на форум (https://www.cyberforum.ru/cpp-builder) — вполне всё живо, народ задает вопросы и на вопросы отвечает.
HADGEHOGs
26.12.2021 04:12Пишу на Дельфи dllки для 1С, утилиты для 1С и немного мобильной разработки на firemonkey для 1С. Нравитца.
tanakian
26.12.2021 04:12>На мой взгляд, переход на компилятор из «вражеского» лагеря объясняется
тем, что Embarcadero просто не имеет ресурсов (возможно и желания) для
того чтобы создать и поддерживать собственный. Получив в «наследство» от
Borland какой-то инструмент они оказались не способны на существенную
его модификацию.дело в том, что стандарт c++ распухает быстрее, чем его возможно реализовать при разумных расходах. митуация почти как с html5, где все производители движков потеряди надежду поспевать за темпами разработки хрома и мозиллы, да и последняя может не выдержать.
поэтому в эмбаркадеро решили поддерживать наборы патчей к не гну, а бсд компилятору, потому что бсд лицензия оставляет право не раскрывать исходники патчей.
kovserg
В топку Builder когда есть Ultimate++ и QT
unsignedchar
Есть такое слово legacy.
K36
VCL в оличии от QT работает с нативными windows контролами => гораздо эффективнее.
sshmakov
Qt, в отличие от VCL, не создаёт WindowHandle на каждый чих, если их никто не просит.