Ну вообще то я - лентяй. А лень как известно двигатель прогресса. Меня то и С++ в свое время привлек тем, что в нем можно лаконично писать код. С++Builder продолжил эту славную традицию посредством визуального программированя. Умело пользуясь предоставленными компонентами можно создать относительно сложный пользовательский интерфейс не написав ни строчки кода. С учетом того, что разработка интерфейса может в отдельных проекта занимать до 70% рабочего времени, С++Builder любезно берет этот тяжкий труд на себя, оставляя мне больше времени на бизнес логику.
Например программку, которая обеспечивает манипулции со списками межуду двух листбоксов ( копирование или перемещение из одного в другой и обратно, удаление ) я могу создать вообще не написав ни строчки кода ( вообще у меня мания на этот счет - писать как можно меньше) Весь функционал будет создан только средствами дизайна. При этом программа сможет перемещать, копировать выделенные данные из одного списка в другой или удалять их по нажатию соответствующей кнопки, а также следить за состоянием этих кнопок и управлять их доступностью, исходя из конкретной ситуации.
О layout'ах. Да есть такое упущения: разработчики не предусмотрели "стандартного" менеджера. Но кто мешает создать свой менеджер. Кстати , библиотеки с компонетами от сторонних разрабочиков очень часто предоставляют такие менеджеры для своих компонетов (DEV Express, например)
Что касается форм, то я обычно выбирад другой путь. Разработка проекта начиналась обычно с создания своих компонентов и базовых форм со своими нужными мне проперятями и событиями, шаблонов проектов модулей, которые интегрировались в IDE и использовались как стандарные формы. Например в одном из проектов , для создания нового плагина достаточно было открыть соответствующий шаблон проекта, заполнить в соответствии с инструкцией требуемые проперти, в заданном месте написать реализацию функционала. Там же в IDE после тестирования и готовности модуля мог запустить его на инсталяцию ( пунктик был в меню): и соответствующий функционал, встроенный в IDE пересобирал заланный модуль, зачитывал номер версии и билда, регристрировал(обновлял) этот модуль и версию в БД и в нее же загружал исполняемый модуль. После этой процедуры обновленный модуль становился доступным пользователям. Программирование напоминало больше технологический процесс, нежели творчество.
А как Вам например компонент-оболочка вокруг RASDial, написанный мною, который мог осуществлять дозвон и соединение прямо в дизайне или хотя бы те же стандпартные компоненты позволяющие подключаться к БД и выводить содержимое также в дизайне, еще до начала, собственно , самого программирования?
Ну и пару слов о кроссплатформенности. С++Builder 6 предоставлял таку возможность. Наряду с узкозаточенной VCL, в комплект входила и другая визуальная библиотека CLX. Создав приложение на CLX, я мог перенести код на Linux и спомощью C++ Kylix 3 собрать его там.
Это достигалось тем, что CLX, которая обеспечиавоа прицип RAD, являлась настройкой над ... Qt  .
С одной стороны можносделать вывод, что без Qt никуда, а с другой - что возможности предоставляемые QT на уровень RAD не тянут и она по своей сути остается ресурсоориентированной библиотекой, так же как MFC, wxWIndows и пр.
Это был весьма многообещающий проект, но к сожалению во-первых похоже не сошлись по цене с разработчиком, а во-вторых для меня он потерял свою прелесть из-за идиотского подхода Borland : они вокруг QT соззали врапер из дельфийскизх CLX классов и эти классы предложили использовать в C++ Kylix/C++Builder. В результате на выходе получился бутерброд C++(QT)->Delphi(CLX)->C++(приложения ). Соответсвенно получили итог: дельфийцам межплатформенность не нужна - у них уже есть воя ниша. Те, кто пишет на С++Builder - подход показался черезчур экзотичным. CLX и Kylix канули в лету
|
)
.
и результаты есть ? 