Сначала оговорюсь, что в данной статье я буду рассматривать C++ Builder именно как "builder", т.е. программный инструмент класса RAD (Rapid Application Development, быстрое создание приложений) и, в общем-то, большая часть здесь написанного в одинаковой степени применимо ко всем подобным средствам.

Итак, C++ Builder упрощает процесс создания программ для ОС Windows с графическим интерфейсом пользователя. При его помощи одинаково просто создать диалог с тремя кнопочками "Yes", "No", "Cancel" или окно текстового WYSIWYG редактора с возможностью выбора шрифтов, форматирования, работы с файлами формата rtf. При этом C++ Builder автоматически создает исходный текст для пользовательского интерфейса: создает новые классы, объекты, вводит нужные переменные и функции. После всего этого "рисование" пользовательского интерфейса превращается, буквально, в удовольствие для эстетов: сюда добавим градиент, здесь цвет изменим, тут шрифт поменяем, а сюда мы поместим картинку.

После того, как вся эта красота нарисована, начинается менее интересная работа --- написание функциональной части. Тут C++ Builder ничем помочь не может, все приходиться делать по старинке, забыв про "манипулятор мышь" и касаясь исключительно клавиатуры.

Итог?.. как обычно: красота неписанная на экране. Этих программ, которые рисовали эстествующие программисты теперь хоть пруд пруди, ими можно любоваться, распечатывать картинки с экрана и делать из них художественные галереи...

Что же тут плохого? Ничего, если не считать того, что при таком подходе к программированию создание программного продукта начинает идти не от его "внутренностей" (функционального наполнения), а от пользовательского интерфейса и в итоге получается, если "наполнение" достаточно сложное (сложнее передачи текста от одного элемента пользовательского интерфейса другому), то оно становится не только системнозависимым, но и компиляторозависимым, что уж совсем неприятно.

Кроме того, простота "рисования" пользовательского интерфейса, а, точнее, ненаказуемость (например, объемным программированием) использования различных сложных компонентов таит в себе некоторые опасности. Связано это с тем, что построение удобного пользовательского интерфейса это задача сама по себе достаточно сложная и требующая особенного образования. При этом каждый уважающий себя программист всегда уверен в том, что уж он-то точно сможет сделать пользовательский интерфейс максимально удобным и красивым.

Почему настолько разительно отличаются домашние страницы (включая мою) и страницы профессиональных web-дизайнеров? Потому что последние имеют очень много узкоспециализированных знаний о восприятии человеком информации на экране монитора и, вследствие этого, могут разместить информацию не "красиво", а так, как это будет удобным. То же самое и с пользовательским интерфейсом --- вопрос о том, как должна выглядеть конкретная кнопка и в каком месте она должна находиться не настолько прост, как кажется. Вообще, дизайнер пользовательского интерфейса это совершенно отдельная специальность, которая, к сожалению, у нас еще не распространена.

Тот факт, что функциональное наполнение становится зависимым от используемой библиотеки пользовательского интерфейса, просто смешон. Подставьте в предыдущее предложение вместо "функционального наполнения" конкретный продукт, и вы поймете о чем я хочу сказать: "рассчет химических реакций", "анализ текста" и т.д.

Кроме того, сама библиотека пользовательского интерфейса в C++ Builder достаточно оригинальна. Это VCL (Visual Component Library), целиком и полностью взятая из Delphi, т.е. написанная на Паскале. По Паскалевским исходникам автоматически создаются заголовочные файлы, которые потом включаются в файлы, написанные на C++. Надо сказать, что классы, которые представляют из себя VCL-компоненты это не обычные C++ классы; для совместимости с Delphi их пришлось несколько изменить (например, VCL-классы не могут участвовать во множественном наследовании); т.е. в С++ Builder есть два вида классов: обычные C++ классы и VCL-классы.

Кроме всего прочего, я считаю, что C++ Builder еще и вреден. Потому что очень много начинающих программистов используют его, рассхваливают за то, что при его помощи все так просто делается и не подозревают о том, что это, на самом деле, не правильно. Ведь область применения C++ Builder, в общем-то, достаточно хорошо определена --- это клиентские части для каких-либо БД. В нем все есть для этого: быстрое создание интерфейса, генераторы отчетов, средства сопряжения с таблиацми. Но все, что выходит за границы этой области, извините, надо писать "как обычно".

Связано это с тем, что, на мой взгляд, создание программ, которые в принципе не переносимы это просто издевательство над идеями C++. Понятно, что написать программу, которая компилируется несколькими компиляторами это в принципе сложно, но сделать так, что бы это было ко всему прочему и невозможно, в высшей степени неприлично. Любая программа, на мой взгляд, уже должна изначально (и это даже не вопрос для обсуждения) иметь очень четкую грань между своим "содержанием" и "пользовательским интерфейсом", между которыми должна быть некоторая прослойка (программный интерфейс) при помощи которой "пользовательский интерфейс" общается с "содержанием". В таком виде можно сделать хоть десяток пользовательских интерфейсов на различных платформах, очень просто "прикрутить" COM или CORBA, написать соответствующий этой же программе CGI скрипт и т.д. В общем, много преимуществ по сравнению с жестким внедрением библиотеки пользовательского интерфейса внутрь программы против одного преимущества обратного подхода: отсутствие необходимости думать перед тем, как начать программировать.

Резюме

Надо сказать, что C++ Builder или Delphi такой популярности как у нас, за границей не имеют. Там эту же нишу прочно занял Visual Basic, что достаточно точно говорит об области применения RAD-средств.

C++ Builder буквально навязывает программисту свой собственный стиль программирования, при котором, даже при особом желании, перейти с C++ Builder на что-то другое уже не предоставляется возможным.

Кроме того, быстрое создание интерфейса это еще не панацея от всех бед, а, скорее, еще одна новая беда, в частности из-за того, что программисту приходится выполнять не свойственную ему задачу построения пользовательского интерфейса.

Все вышесказанное не затрагивает непосредственно компилятор bcc, о котором, возможно, стоит поговорить отдельно.