. CodeBlocks :: не просто ещё одна IDE
CodeBlocks :: не просто ещё одна IDE

CodeBlocks :: не просто ещё одна IDE

Видя регулярные холивары «студия vs эклипс» или «programmers notepad против vim», каждый раз собираюсь поведать миру об универсальном инструменте, которым сам пользуюсь в течение уже нескольких лет. Это многофункциональная IDE для С/С++ разработки Code::Blocks.

CodeBlocks — это свободная кроссплатформенная среда, заполняющая нишу между монструальными и неповоротливыми «взрослыми» системами для больших проектов, типа Eclipse, Visual Studio, Net Beans, и убогими по функционалу, но шустрыми блокнотами типа Scintilla, причем преимущества и тех, и других складываются и позволяют использовать данную систему как для написания небольших проектов для встраиваемых приложений, так и для программирования приложений для РС под Windows, Linux и MacOs.

Основные характерные особенности среды:
  • Кроссплатформенная IDE с открытым кодом, основанная на библиотеке wxWidgets
  • Компактное ядро и расширение функционала посредством множества плагинов
  • Встроенный интерфейс под множество компиляторов и тулчейнов, как свободных, так и проприетарных
  • Множество визардов для быстрого создания шаблона проекта как для разнообразных микропроцессорных архитектур (AVR, ARM, PowerPC), так и для библиотек и тулкитов под РС: GTK, Qt, WxWidgets, OpenGL итд.
  • Компактная и интуитивно понятная структура меню, обеспечивающая быструю настройку среды
  • Огромное количество забавных и полезных рюшечек, которые я до сих пор с удивлением иногда нахожу :)

Итак, начнем по порядку.

  • GCC (MingW / GNU GCC)
  • MSVC++
  • Digital Mars
  • Borland C++ 5.5
  • Open Watcom . and more
  • AVR (WinAvr)
  • MSP430 (MSPGCC)
  • ARM
  • PowerPC
  • MathLab
  • OpenGL
  • GTK+, Qt, wxWidgets, WinGUI … и многое другое

CodeBlocks имеет быструю встроенную систему сборки, способную реализовывать параллельную сборку (задействуя при этом «лишние» головы процессора), но одновременно с этим допускает сборку внешними инструментами (GNU Make, Cmake, etc) с рукописными скриптами типа makefile, причем тоже многопоточно.

Как и мощные профессиональные оболочки, имеет развитые средства поддержки проектов, включая workspace для объединения родственных проектов, общие межпроектные зависимости, множественные цели (target)

Предусмотрен механизм импорта проектов из других сред разработки

а также экспорта открытого файла в разнообразные форматы:

Отладка

Как и эклипс, кодеблокс позволяет отлаживать проекты через интерфейс GNU GDB (и даже «Also supports MS CDB»).

Лично я никогда отладками не пользовался, и даже ноги JTAG на платах остаются неразведенными, но многие жизни без него не представляют. Поэтому спешу успокоить: CodeBlocks ничуть не хуже в этом плане, чем остальные. Вот цитата с оф. сайта:

  • Full breakpoints support:
    • Code breakpoints
    • Data breakpoints (read, write and read/write)
    • Breakpoint conditions (break only when an expression is true)
    • Breakpoint ignore counts (break only after certain number of hits)
    Интерфейс
    • Подсветка синтаксиса, настраиваемая и расширяемая (хотя куда уж шире — см. скриншоты ниже)
    • Сворачивание кода (folding) для С/С++ и XML
    • Система вкладок в рабочем окне и дополнительных фреймах
    • Свободная планировка фреймов и произвольное деление (split) рабочего окна
    • Автодополнение кода
    • Обозреватель классов
    • Быстрое переключение между .c и .h файлами (swap)
    • Список открытых файлов для быстрой навигации, когда табов уже не хватает
    • TODO list ну и многое другое, реализуемое плагинами.

    Автодополнение (Code-completion). После ввода 4-х символов выпадает список с подходящими идентификаторами. Количество начальных символов настраивается, как и многие другие параметры.

    Вводим точку после имени структуры — выпадает список полей. То же самое со структурными операторами -> и ::

    Выбор варианта подсветки исходного текста — без комментариев:

    Обратите внимание на опции для управления комментариями: Comment/Uncomment имеют хоткеи и позволяют быстро комментировать и раскомментировать строки и куски текста. Что характерно, комментарии вставляет именно такие, какие требуются для данного типа файлов. Например, для.с и .h — "//", а для makefile или python — "#"

    Контекстное меню (правой кнопкой в окне редактора) весьма развито:

    Пункты меню «Find declaration of» и «Find implementation of» служат для поиска объявления и реализации (имплементации) выделенного объекта, а «Find occurrences of» — все включения во всех файлах проекта.

    В этом же меню видим упоминавшийся ранее «Swap header/source».

    Чуть ниже — запуск плагина автоформатирования AStyle, который форматирует текущий файл по одному из шаблонов:

    То, что в меню указаны хоткеи не для всех пунктов, отнюдь не означает, что их нельзя настроить.

    Более того, настройки можно разложить по разным профилям.

    Можно сплитить рабочий экран на произвольное количество окошек.

    Легко и непринужденно — простым перетаскиванием вкладок к границам основного окна. Перетаскивая вкладки из дополнительных окон в основное или соседние, можно объединять их обратно.

    Ещё одна мегафича, которая мне нравилась ещё в IARe, это быстрая навигация вперед/назад: Alt + стрелки вправо/влево.

    Также, очень удобная фишка под названием Default code. Можно задать «шапку» для файлов, отдельно для.с и .h, которая будет автоматически подставляться при создании новых файлов. Плюс, при создании .h файлов может автоматически добавляться стандартный предохранитель от множественного включения:

    Наверно, я уже утомил своим перечислением, хотя не затронул многих интересных вещей. Пора переходить к практической части.

    Установка

    Если Вы пользователь Windows, то идем на страницу загрузки и готовимся потратить от 23 до 74М траффика (в зависимости от MinGW). Сторонники Светлой Стороны могут для начала поискать в своем менеджере пакетов. Имеются готовые сборки .deb (debian/ubuntu) и .rpm (Fedora, SUSE, Mandriva)

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

    Также, при установке в windows присутствует опция MinGW, по которой C::B устанавливает свой личный экземпляр MinGW внутри себя. Забегая вперед, скажу, что эта штука может конфликтовать с другими win-gcc тулчейнами, находящимися в системе, например, с CygWin, так что в случае необъяснимых ошибок или подвисаний проблема скорее всего в этом. В некоторых источниках рекомендуют ставить в последовательности wxWidgets (если нужно) — MinGW — CB(без MinGW).

    Итак, установили. Пока пыл не угас, попробуем по-быстрому чего-нибудь состряпать. Например, окошко WinGUI.

    1. Создаем новый проект. File-> New-> Project (или ссылку Create a new project на странице приветствия).

    2. Из кучи визардов выбираем Win32 GUI project (придется ещё вниз помотать) и жмем «Go».

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

    Запускаем. Жмем Build, Run или Build and run

    Ну, кто тут спрашивал, в чем бы под винду написать? :) Шучу, конечно. На самом деле это была просто иллюстрация, естественно, что на голом WinGUI никто писать не будет, когда есть возможность пользоваться удобными фреймворками типа wxWidgets или Qt.

    В общем, немного сумбурно получилось, но общее представление, надеюсь, дает.

    Свободная кроссплатформенная среда с открытым кодом и расширяемая с помощью плагинов, которая имеет большинство функций, имеющихся в других продуктах, как коммерческих, так и свободных, весьма нетребовательна как к объему памяти и носителей, так и к производительности системы. В частности, работает заметно шустрее эклипса. На мой взгляд, идеальное средство для разработки программ для микроконтроллеров и небольших сервисных программ (например, консольных).

    Если будет интерес к теме, в следующий раз опишу процесс создания микроконтроллерного проекта.

    Материалы по теме:

      , ,
    • +9
    • 30 мая 2012, 15:39
    Комментарии ( 145 )

    >> например, поддерживаются только языки С и С++

    Странно, а я как-то по незнанию в нём на Верилоге писал… Вот блин, а оказывается нельзя… =\

    Ну да, Упомянули МК, показали убунту, а приложение создали под винду, после чего повтыкали скриншотов в неуловимой последовательности. И всё это без каких-либо разделов.

    Статья сырая и только отобьёт интерес к среде.

    не совсем. выделяем текст, ПКМ и далее 2 версии: N пунктов вниз (что чаще) либо M пунктов вверх. При использовании же кнопок тулбара расстояние всегда зависит от месторасположения выделенного текста. Казалось бы мелочь, но знаете как к ней привыкаешь. Рука на автомате выполняет требуемую последовательность при пкм, без привлечения глаз для поиска тулбара и кнопок.

    Вообщем «тёплый ламповый звук».

    Я бы не сказал. Agile методологии рулят даже в небольших проектах.

    А касательно рефакторинга – классический поход «сверху вниз» (водопад) тоже не избавляет от необходимости иногда проводить рефакторинг (хотя, конечно, при грамотном подходе рефакторинга в этом случае должно быть на порядок меньше ).

    Да, Agile рулит, безусловно. Я бы даже сказал «особенно в небольших проектах». Но, на мой взгляд, в эмбеддед проектах, где софт часто пишется одним-двумя программистами, большой разницы нет, там своего рода «agile» складывается автоматически. Ну и «маленький» проект на жабе легко может быть на порядок сложнее (в смысле собственного кода и реализуемой бизнес-логики), чем «большой» эмбеддед проект на всю флешку средней стм-ки. Тут уже сложность диктует необходимость применения более-менее формализованных методик и подходов, иначе есть большой риск утонуть в «изобретении велосипедов» и «беге по граблям» в ходе выработки собственной методологии.

    По поводу рефакторинга: я бы даже сказал так: водопад категорически требует рефакторинга, причем в гораздо больших объемах, чем agile. Это неизбежное последствие «априорного» проектирования. Другой вопрос что он же сильно затрудняет рефакторинг, в итоге программу чаще проще переписать заново полностью или, как минимум, бОльшую ее часть. К примеру: я сейчас участвую в проекте, который пережил минимум три глобальных изменения в архитектуре. При этом процентов 70 первоначального кода живы в первоначальном виде или с небольшими модификациями. Если бы это был водопад, то программу надо было бы переписывать с нуля каждый раз. И никакой грамотный подход не может предусмотреть изменений требований (которые диктует сама жизнь и опыт применения софта в продакшне). А из-за желания сделать «поуниверсальнее», что бы «если что, меньше переписывать», приводит к тому, что код оказывается обвешан ненужными фишками, которые при переписывании просто идут в мусор. В agile такого мусора, обычно, на два порядка меньше, а в идеале — нет совсем.

    Рассказывая новичкам об agile, я часто приводу такое сравнение: водопад это стрельба неуправляемым артиллерийским снарядом из-за горизонта. Agile — это стрельба самонаводящимися ракетами. Если цель неподвижна и ее координаты точно известны — то без разницы чем стрелять. А если мы только приблизительно знаем, где эта цель находится или цель движется, то накрыть ее артиллерией можно только залпом, а самонаводящейся ракеты хватит и одной. Снаряд/ракета — это, по сути, код проекта. Цель — требования заказчика.