Поскольку мы (я и люди, с которыми я работаю) все больше и больше расстраиваются при работе с проектами на С++ 250 000+ LOC в VS2010 sp1 (медленность этой IDE просто невероятна), в моей компании мы говорили о миграции наших кода для некоторых IDE. Мы провели некоторое исследование, и сильным кандидатом, похоже, является Embarcadero С++ builder 2011 XE. Любые мысли об этом? Это хорошо? Как он сравнивается с VS2010?
Является ли Embarcadero С++ Builder хорошим выбором в качестве среды IDE?
Ответ 1
На самом деле не ответ, но я просто оставлю его здесь:
- Это стоит денег (да, VS тоже, но у вас уже есть это, не так ли?)
- Нелегко перенести достаточно большой проект на новую IDE (и компилятор), чтобы не говорить о людях, с которыми вы работаете, и о своих привычках (я бы просто бросил, вероятно).
- Там также есть новый компилятор, с его ошибками и оговорками, чтобы узнать об этом. И это гораздо менее широко используется, чем VС++. Тем не менее, он основан на Clang, который должен поддерживать стандарты лучше, чем VС++, и проще переносить существующий код на С++.
- Трудность миграции чрезвычайно зависит от характера вашего проекта (основывается ли это на графическом интерфейсе, насколько глубоко он полагается на MS VС++, являющемся компилятором?)
Ответ 2
Я пользуюсь C++ Builder с 1.0 года и ненавижу его со страстью. Вы могли бы подумать, что после всех этих лет простые маленькие неприятности будут исправлены, но это не так. Вот список проблем, с которыми я столкнулся в C++ Builder IDE.
Ваш макет или личность никогда не поддерживается. Вы создаете один, сохраняете его, и это относится только к определенным вещам. Например, окно отладчика не будет сохранять свою позицию, как и окно сообщения. Если вы отключите проводник проекта, он иногда исчезнет. Большую часть времени перезагрузка вашей личности не исправляет это либо. Вы застряли, перетаскивая окна на место.
Отладчик иногда будет работать, а иногда не работать. В отладочной сборке, если вы устанавливаете точку останова и начинаете пошаговое выполнение кода, вы можете навести курсор на переменную, чтобы проверить ее. Иногда это работает, а иногда это не работает с одной и той же переменной. Сумасшедший!
Eclipse ищет ошибки в коде, например, если вы забыли поставить точку с запятой в конце своего утверждения, это немного? отметьте на полях. C++ Строитель не делает ничего подобного. Это дает загадочное сообщение об ошибке времени компиляции.
Последние версии C++ Builder используют make файл, похожий на VS; это беспорядок XML. Eclipse работает с CMake и Makefiles. Я читал в некоторых местах, что сопровождающие CMake ищут генератор C++ Builder, но в последний раз я проверял, что его не существует. Я выполняю встроенную и кросс-компиляцию, поэтому иногда мой код C++ Builder копируется в мою встроенную среду разработки или используется совместно с ним, и я получаю поддержку двух сред сборки.
Не совсем IDE, но C++ Builder не использует преимущества нескольких процессоров для компиляции кода. Однако есть сторонний инструмент, на который вы можете потратить больше денег, чтобы получить это. Он называется TwineCompile (http://www.jomitech.com/twine.php). С Eclipse они вызывают любой используемый вами компилятор (gcc и т.д.) И эти компиляторы и поддерживают опцию -j.
C++ Builder поставляется с ограниченной версией AQTime, которая является профилировщиком динамического кода. Потратьте больше, и вы получите более продвинутую версию. Eclipse поддерживает много динамического и статического анализа кода (который также стоит $$), но по крайней мере плагины есть. Мы используем Klockworx.
C++ У Builder, как я знаю, нет поддержки внешнего управления источниками, такого как GIT. Затмение делает. C++ Builder поставляется с Subversion, я думаю, встроенным. Если он поддерживает GIT, я бы никогда не смог заставить его работать. Он говорит мне, что не понимает схему URL, когда я даю ему путь git.
Определенный шаблонный код, который я пишу, приводит к тому, что компилятор переходит на segfault и должен полностью перезапустить IDE. Это безумие для меня. У вас есть компилятор, которому 10+ лет, и он до сих пор работает с ошибками. У меня есть фрагмент кода шаблона C++, который, когда я беру его на свой рабочий компьютер, работающий с точно такой же версией C++ Builder, компилируется нормально, но на моей домашней машине он вызывает сбои. Я абсолютно уверен, что в игре нет таких негативных факторов, как вирусы и т.д.
При компиляции большого проекта, который может занять много времени, вы не можете просматривать код в IDE. Иногда вы можете увидеть прокрутку предупреждений компилятора, и вам придется либо дождаться завершения задания компиляции, чтобы проверить упомянутую строку, либо использовать альтернативные средства для открытия файла.
C++ Builder IDE имеет концепцию группы проектов с подпроектами, которые более или менее самодостаточны. Проектная группа не имеет концепции группового пути включения/ссылки, как в подпроектах. Подпроекты имеют базовые пути, пути отладки, выпуска, где отладка и выпуск могут наследоваться или блокироваться от базы, но у вас нет этого на уровне группы проектов. В среде IDE есть глобальные параметры, которые могут быть унаследованы, но это относится ко всему, что вы делаете в среде IDE. Таким образом, нет никакого способа изменить для данной группы проектов, только пути включения/компоновщика для набора подпроектов. Я просто думаю, что они могли бы сделать лучше с этим.
C++ Вывод Builder Build не имеет цветовой кодировки, например, для отображения ошибок в красном и предупреждений в другом цвете. Все черно-белое. VC и Eclipse цветовой код и дают возможность менять цвета для различных предупреждений и ошибок. Вкладка вывода в C++ Builder аналогична. На больших проектах очень трудно исследовать предупреждения компилятора с другим шумом. В C++ Builder IDE вы можете выбрать уровень предупреждений, но это влияет только на вывод на вкладке "Вывод", и вы по-прежнему получаете другие глупые помехи, такие как сообщение мне об удалении файлов состояния компоновщика "CleanLinkerStateFiles".
Если вы не занимаетесь разработкой графического интерфейса пользователя для Windows, держитесь подальше от Embarcadero/C++ Builder. Я начал использовать C++ Builder версии 1 еще в дни Borland, и у меня есть несколько крупных проектов, которые вложены в VCL, поэтому я застрял с ним в этих проектах, но во всех моих новых проектах я использовал Eclipse.
На положительной ноте о C++ Builder VCL довольно хорош. Он не многопоточный, но очень приятный для быстрого создания приложения с графическим интерфейсом. Я думаю, что гораздо быстрее запустить приложение с графическим интерфейсом C++ в CBuilder, чем в VS. И кажется, что есть тонна бесплатных и платных компонентов GUI для CBuilder; снова с фокусом C++. Я знаю, что С# + VS имеет множество элементов управления графическим интерфейсом.
UPDATE: Я только что столкнулся с проблемой сегодня, которая такая же, как упомянутая на этом форуме: http://qc.embarcadero.com/wc/qcmain.aspx?d=57631
[ILINK32 Warning] Warning: Error detected (ILI4536)
Прими решение. Это предупреждение или ошибка Богоматери?
Прокрутите весь путь до конца, где вы найдете людей, которые изменяют ILINK32.EXE, чтобы он снова заработал. С этого утра наши сборки перестают работать. Мы мертвы в воде, когда мы карабкаемся, чтобы понять и выяснить, что с этим делать.
Это тот тип компилятора /IDE, от которого вы хотите зависеть? Опять же, этот продукт существует уже более десяти лет, и у него все еще есть такие проблемы. Я считаю это совершенно неприемлемым. Дерьмовый продукт от компании, которая не дает дерьма.
Ответ 3
В Embarcadero XE нет ничего позитивного, ни их стареющая среда IDE ни их стареющий компилятор. Используйте его только в том случае, если вы привязаны к нему (устаревшее программное обеспечение) или хотите сделать Delphi.
Для С++ сделайте себе одолжение и присоединитесь к 21-му веку: придерживайтесь чего-то более мощного, универсального и современного, такого как VС++ или Qt.
Ответ 4
Я предлагаю Eclipse.
- В качестве IDE требуется некоторое время, чтобы привыкнуть, но это хорошо стоит усилий.
- Он доступен для Mac OS, Linux и Windows.
- Вам нужно, чтобы на вашем компьютере была установлена Java, но это действительно не проблема.
- Он поддерживает Cygwin, MinGW и инструментальные средства MicrosoftVisual С++. Построение в CDT Builder тоже неплохо.
- Вы можете использовать его для разработки для языков, отличных от С++ (Java, JavaScript, PHP..)
- Вы можете расширить его функциональность, установив плагины
- БЕСПЛАТНО!
- Я упоминал, что он имеет встроенный веб-браузер? Действительно полезно для ссылки на онлайн-документацию при кодировании.
Ответ 5
1. У нас есть решение над 1M LOC и VS2010 обрабатывает его нормально. Нам особенно нравится/MP-переключатель для компиляции на всех доступных ядрах CPU.
Вы не указали свое оборудование. Если вы еще не запустили хотя бы i7-2600 + быстрый SSD, я предлагаю сначала попробовать обновление аппаратного обеспечения.
2. Раньше я использовал инструменты Borland в прошлом. Delphi был довольно стабильным; С++ Builder был гораздо более неудачным. Несколько лет назад я помог обновить старые проекты Delphi до более новой среды Delphi с установленными пакетами обновлений. И у него были ошибки даже в базовых API файлов IO, которые работали с Turbo Pascal. Нам пришлось перейти на предыдущую версию. Я ожидаю, что качество С++ Builder будет не намного лучше, чем VS2010.
3. Вы не указали, что именно медленно. Возможно, вы захотите преобразовать некоторые проекты в компоненты, скомпилированные отдельно. Также убедитесь, что вы используете PCH.
Также стоит исследовать, злоупотребляете ли вы моделью включения С++, включая множество ненужных файлов заголовков в каждом устройстве. Если после предварительной обработки Intellisense и компилятор должны иметь дело с огромным количеством кода, никакая IDE не может помочь.
Ответ 6
Этот вопрос действительно вопрос личного мнения.
Я лично ненавижу Visual Studio со страстью, я избегаю этого, как чума. Моя подверженность Eclipse была ограничена Java, но даже тогда мне было трудно работать с ней.
Я использую С++ Builder в течение 15 лет, начиная с версии v3.0 вплоть до новейшего XE6. Да, у него есть причуды и ограничения, но я по-прежнему считаю это самой простой IDE для меня, чтобы работать и работать с вами, как только вы знаете, как работать с ними (или вокруг них). Возможно, мой опыт работы с ним мешает моей работе с другими IDE, но пусть будет так. Я по-прежнему предпочитаю С++ Builder над любым другим. Но я использую его только для разработки Windows (VCL очень зрелый и надежный), я еще не занимаюсь кросс-платформенной разработкой (FireMonkey все еще имеет способы развиваться и развиваться). И я использую много проектов с открытым исходным кодом. Да, иногда мне приходится настраивать свои проекты и/или код, чтобы они скомпилировались, но обычно это одноразовая сделка, и тогда они работают нормально.
Ответ 7
Я не использовал Visual Studio 2010 Ultimate для С++, а не С# и С#. При этом, как тест между VS 2010 Ultimate и С++ Builder XE, я создал простое приложение VS С++ Windows Forms, чтобы нажать кнопку и показать "Hello World" через обработчик событий. Получение кнопки в VS Window Designer в порядке, если вы не забыли открыть View | Ящик для инструментов. Если нет, потребуется некоторое время, чтобы отслеживать, где виденные компоненты висят.
По причинам, которые не имеют никакого языка, обработчик события нажатия кнопки имеет подпись, которая выглядит так:
System::Void button1_Click(System::Object^ sender, System::EventArgs^ e) {
}
и он попадает в заголовочный файл, как и следовало ожидать. Символ ^
имеет мало смысла. Использует ли он связь с CLI/CLR лучше? Я ожидал, что *
укажет указатель.
После использования стандартного Form1 (только созданного файла заголовка) и последующего добавления новой формы окна я, наконец, получил соответствующий файл cpp. Может быть, у С++ Windows Form Wizard есть ошибка. Кто знает? Во всяком случае, при добавлении события нажатия кнопки, дважды щелкнув кнопку в дизайнере, cpp не получит метод в той или другой форме cpp, которую я тестировал. Может быть, это нормально, я не знаю. Конечным результатом этого является то, что после попытки использовать функцию MessageBox внутри cpp это вызвало ошибки компиляции. Я уверен, что есть еще один заголовочный файл, который должен быть включен в путь include. Я не тратил времени на это. Попытка установить свойство текста компонента метки также вызвала ошибки компиляции. Примерно через 20 минут я с разочарованием пошел на С++ Builder XE3.
В С++ Builder я проверил VCL Forms, FireMonkey Desktop и приложение FireMonkey Metropolis от мастера проекта. Разумеется, у меня есть три разных приложения, говорящих "Hello World", всего за три минуты, все вызывающие С++ Builder, встроенные в глобальную функцию быстрого вызова, называются ShowMessage("insert message here")
. Сроки могли быть немного разными, так как я не наставил время с секундомером. Потребовалось больше времени для сохранения файлов со значимыми именами, кроме самого кода: одна строка ввода в соответствующем элементе события click в каждом cpp (а не в заголовке).
Другое основное ежедневное использование getcha с VS, для тех из нас, кто любит красную карту ключей, состоит в том, что VS очень сложно настроить в Brief. Когда я делаю тяжелую разработку в С#, я использую редактор С++ Builder в кратком режиме, сохраняя файлы так часто, как я хочу. VS корректно обнаруживает обновления файлов при повторном нажатии на VS IDE.
О медленности, упомянутой выше в OP, я предлагаю также очень внимательно изучить аппаратную платформу относительно работы Visual Studio. Я заметил, что если инфраструктура .Net устарела, VS будет медленным в среде IDE. Кажется, не имеет значения, на каком языке находится проект. Я использую Visual Studio 2010 Ultimate на Parallels с Windows XP Pro с двумя виртуальными ядрами. Как правило, VS отвечает нормально в среде IDE. При использовании этого я не думаю, что "VS очень медленно".
Что касается миграции четверть миллиона строк в С++ Builder из VS, я не уверен, будут ли обработчики событий VS преобразовываться каким-либо мастером или другим средством миграции. Символ ^
, если он постоянно используется во всех обработчиках событий, может не иметь большого значения для преобразования регулярного выражения, которое написано на заказ. Если проект очень тонкий на уровне пользовательского интерфейса и тяжелый бизнес-правила и данные, преобразование в С++ Builder должно быть относительно простым. Я бы ожидал, что новое кодирование нового пользовательского интерфейса приведет к событиям, проходящим через взаимодействие пользователя с другими слоями. Для прототипирования, используя компоненты, осведомленные о данных, вероятно, ваш лучший выбор. В обычном запуске приложений ожидайте, что уровень бизнес-правил будет использовать STL и встроенные структуры данных С++ Builder (даже метод AnsiString c_str()
) для взаимодействия с компонентами, не поддерживающими данные. Производительность и пользовательский опыт, скорее всего, улучшатся.
Начать редактирование
Большой стук в С++ Builder XE3 (обратите внимание, что это два релиза за текущим из пяти) заключается в том, что 64-разрядная поддержка Windows предназначена только для консольных приложений. Стук больше не часто транслируется о том, как использовать подменю Add Platform, которое появляется при щелчке правой кнопкой мыши над выбором Target Platforms в представлении дерева проектов. Этот быстрый метод добавления дополнительных платформ в проект после того, как он может ориентироваться на 32-битную Windows, практически безболезнен. После выбора единственного подменю появится новый поддиалог, и появится раскрывающееся окно, чтобы выбрать новую операционную систему и соответствующие 32-разрядные или 64-разрядные версии. На мой взгляд, Embarcadero не демонстрирует достаточно часто, насколько просто добавлять другие целевые платформы. Итак, чтобы облегчить всю боль проявлять, если это неизвестно заранее, я нашел три веб-страницы на сайте Embarcadero. Первая имеет красивые фотографии создания рабочего стола FireMonkey. Шаг 5 имеет захват экрана целевых платформ | Добавьте дополнительный подменю Platform для добавления платформы Mac OS X. Здесь вызывается Создание первого приложения FireMonkey для настольных платформ (С++): http://docwiki.embarcadero.com/RADStudio/XE2/en/Creating_Your_First_FireMonkey_Application_for_Desktop_Platforms_%28C%2B%2B%29
Более сложная процедура без рисунка здесь называется Шаги по созданию кросс-платформенных приложений. http://docwiki.embarcadero.com/RADStudio/XE2/en/Steps_in_Creating_Cross-Platform_Applications
Центральная процедура Windows и небольшой захват экрана здесь называются 64-битной кросс-платформенной разработкой приложений для Windows: http://docwiki.embarcadero.com/RADStudio/XE3/en/64-bit_Cross-Platform_Application_Development_for_Windows
Я нашел на форуме форума Embarcadero, что обновление до версии 1 XE3 от оригинальной версии XE3 имеет проблему выбора целевой платформы. Может быть установлен внутренний путь или два, что неверно, и, возможно, необходимо изменить исходный файл проекта XE3 (.cbproj), чтобы включить Win64. По-видимому, исходный файл проекта выпуска имеет значение false.
XE5 (примечание, версия 5 по состоянию на декабрь 2013 года), как предполагается, поддерживает 64-битную Windows для приложений консоли и форм (например, VCL, FireMonkey Desktop, FireMonkey Metropolis), OS X, iOS (Android скоро появится). Для получения полного списка просмотрите техническую матрицу С++ Builder pdf для всех деталей XE5:
http://www.embarcadero.com/products/cbuilder/cbuilder-feature-matrix.pdf
Так как было показано, что обновление XE3 1 устраняет проблемы выбора целевой платформы, по сравнению с исходным XE3, не должно быть никаких странных поведений. Я также столкнулся с сообщением Embarcadero, в котором говорится о члене TeamB, что для мобильных приложений выбор целевой платформы фильтруется таким образом, что смешивание проекта настольной платформы с мобильным не допускается. Итак, если вы хотите попробовать создать настольное приложение, а затем щелкнуть мышью в iPhone, вам понадобится использовать другой инструмент разработки. С++ Builder и/или Delphi не будут пытаться сжать компоненты рабочего стола на мобильное устройство. Вы должны начать с проекта мобильного приложения. Вот ссылка на форум: https://forums.embarcadero.com/thread.jspa?threadID=96371
(Редактировать конец)
Если мне интересно об общем фоне, я использовал С++ Builder с первой версии, Visual Studio.NET(С# 1.0) и Visual Studio 2010 Ultimate. Похоже, Visual Studio концентрируется на С# больше, чем на любом другом языке. Есть восемнадцать проектов С# и пятнадцать проектов на С++ при выборе File | Новый проект. Чтобы достичь области проекта Visual Studio С++, убедитесь, что вы достигли ее, открыв поддерево "Другие языки".
В последних интернет-сообщениях между последней и последней версиями Visual Studio и С++ Builder последние и самые большие цены покупки варьируются в тысячах долларов. Даже если никогда не будет установки для обновления любого инструмента, С++ Builder по-прежнему стоит по сравнению с Visual Studio. Проводя тщательные исследования, прежде чем тратить свои с трудом заработанные деньги. Надеемся, что оба инструмента имеют 30-дневную пробную установку для сравнения бок о бок, так как ваш пробег может меняться.