Стандарты и лицензии на программное обеспечение
3.1. Стандарты семейства UNIX
Дальнейший материал приводится в хронологическом порядке появления стандартов.
Стандарты языка программирования C
Этот стандарт не относится непосредственно к UNIX. Но поскольку C является базовым как для этого семейства, так и других ОС, упомянем о стандарте этого языка программирования. Начало ему было положено выходом в 1978 году первой редакции книги Б.Кернигана и Д.Ритчи. Этот стандарт часто называют K&R. Программисты, авторы этого труда, работали над UNIX вместе с Кеном Томпсоном. При этом первый из них предложил название системы, а второй изобрел этот язык программирования. Соответствующий текст доступен в Интернете [45].
Однако промышленный стандарт языка программирования С был выпущен в 1989 году ANSI и имел имя X3. 159 – 1989. Вот что написано про этот стандарт [46]:
«Стандарт был принят для улучшения переносимости написанных на языке Си программ между различными типами ОС. Таким образом, в стандарт, кроме синтаксиса и семантики языка Си, вошли рекомендации по содержанию стандартной библиотеки. О наличии поддержки стандарта ANSI C говорит предопределенное символьное имя _STDC».
В 1988 году на основе этого стандарта языка программирования была выпущена вторая редакция книги Кернигана и Ритчи о С. Заметим, что фирмы, производящие программные продукты для разработки программ на языке С, могут формировать свой состав библиотек и даже несколько расширять состав других средств языка.
System V Interface Definition (SVID)
Отметим, что положение дел со стандартом SVID в чем-то сходно со стандартом языка программирования С. Изданная авторами этого языка программирования книга является одним из эталонов, но не единственным. Выпущенный позже стандарт С является результатом коллективного труда, прошел этап обсуждения широкой общественности и, видимо, может претендовать на ведущую роль в списке стандартов. Так и SVVS является набором тестов, позволяющих судить, достойна ли система соответствовать имени System V, только одной из версий UNIX. При этом не учитывается весь опыт разработки операционных систем от разных производителей.
Комитеты POSIX
Работа по оформлению стандартов UNIX началась группой энтузиастов в 1980 году. Была сформулирована цель – формально определить услуги, которые операционные системы обеспечивают приложениям. Такой стандарт программного интерфейса стал основой документа POSIX (Portable Operating System Interface for Computing Environment – переносимый интерфейс операционной системы для вычислительной среды) [14]. Первая рабочая группа POSIX была образована в 1985 году на основе UNIX-ориентированного комитета по стандартизации /usr/group, также называемой UniForum [47]. Название POSIX было предложено родоначальником GNU Ричардом Столмэном.
Ранние версии POSIX определяют множество системных сервисов, необходимых для функционирования прикладных программ, которые описаны в рамках интерфейса, специфицированного для языка С (интерфейс системных вызовов). Заложенные в нем идеи использовались комитетом ANSI (American National Standards Institute) при создании стандарта языка C, упомянутого ранее. Исходный состав функций, закладываемый в первые версии, опирался на UNIX AT&T (версия SVR4 [48]). Но в дальнейшем происходит отрыв спецификаций стандартов POSIX от этой конкретной ОС. Подход к организации системы на основе множества базовых системных функций был применен не только в UNIX (например, WinAPI фирмы Microsoft).
В 1988 году был опубликован стандарт 1003.1 – 1988, определяющий API (Application Programming Interface, программный интерфейс приложений). Через два года был принят новый вариант стандарта IEEE 1003.1 – 1990. В нем были определены общие правила программного интерфейса, как для системных вызовов, так и для библиотечных функций. Далее утверждаются дополнения к нему, определяющие сервисы для систем реального времени, «нитей» POSIX и др. Важным является стандарт POSIX 1003.2 – 1992 – определение командного интерпретатора и утилит.
Для тех, кто знаком с алгоритмическим языком программирования С, приведем пример фрагментов описания. Фактически такое описание дает представление о том, как специфицируется «Интерфейс системных вызовов». В пункте «Синтаксис» про функцию readdir приведены такие строки:
Второй пункт («Описание») содержит следующий текст:
А вот что приводится в пункте «Возвращаемое значение»:
В пункте «Ошибки стандарта» указано следующее:
» Readdir и closedir обнаруживают ошибку. [EBADF] Dirp не являются указателем на открытый каталог».
Этот пример показывает, как описываются представляемые приложением услуги. Требования к операционной системе (реализации) заключается в том, что она «…должна поддерживать все обязательные служебные программы, функции, заголовочные файлы с обеспечением специфицированного в стандарте поведения. Константа _POSIX_VERSION имеет значение 200112L [49]».
Как же проверить соответствие конкретной системы стандарту POSIX? Формализация такого вопроса не так проста, как кажется на первый взгляд. В современных версиях предлагается 4 вида соответствия (четыре семантических значения слова «соответствие»: полное, международное, национальное, расширенное).
Отметим, что набор документов POSIX изменяется уже много лет. Но разработчики новых версий всегда стараются максимально сохранить преемственность с предыдущими версиями, В более свежих редакциях может появиться что-то новое. Например, в документе 2004 года были объединены четыре части [50]:
Как и первые редакции, документ в своей основной части описывает группы представляемых услуг. Каждый элемент там описан в следующих пунктах: NAME (Имя), SINOPSIS (Синтаксис), DISCRIPTION (Описание), RETURN VALUE (Возвращаемое значение), ERRORS (Ошибки) и в заключении EXAMPLE (Примеры).
Современные версии стандарта определяют требования как к операционной системе, так и к прикладным программам. Приведем пример [51].
Функция readdir() должна возвращать указатель на структуру, относящуюся к очередному элементу каталога. Возвращаются ли элементы каталога с именами «точка» и «точка-точка», стандартом не специфицировано. В этом примере возможно четыре исхода, а требование к прикладной программе состоит в том, что она должна быть рассчитана на любой из них.
И в заключение приведем отрывок из курса лекций Сухомлинова («ВВЕДЕНИЕ В АНАЛИЗ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ», Сухомлинов В.А. Часть V. Методология и система стандартов POSIX OSE), посвященным области применимости стандартов [52]:
«Область применимости стандартов POSIX OSE (Open System Environment) – обеспечение следующих возможностей (называемых еще свойствами открытости) для разрабатываемых информационных систем:
Это позволяет решать следующие задачи:
Всего в списке стандартов POSIX более трех десятков элементов. Их имена традиционно начинаются буквой «Р», после которой расположено четырехзначное число с дополнительными символами. Существуют также групповые имена стандартов POSIX1, POSIX2 и т.д. Например, POSIX1 связан со стандартами на базовые интерфейсы ОС (Р1003.1х, где вместо х либо пусто, либо символы от a до g; таким образом, в этой группе 7 документов), а POSIX3 – методы тестирования (два документа – Р2003 и Р2003n).
X/Open, OSF и Open Group
Основанная в 1984 году рядом компьютерных фирм организация X/Open своей основной задачей ставила согласование и утверждение для разных версий UNIX стандартов общего программного интерфейса и программной среды для приложений. В 1988 году появился документ XPG3 (X/Open Portability Guide3). Он включал POSIX 1003.1 – 1988 и стандарт на графическую систему X Window System (MTI). Этот документ был развит, включая последние идеи UNIX версии BSD и System V. Он получил название XPG4.2 [14].
Заметим, что OSF была образована рядом организаций в ответ на объединение Sun Microsystems и AT&T для разработки операционной системы, претендующей на универсальность. Сегодня организация The Open Group является главным держателем стандартов UNIX. Она размещает на своем сайте много самой разнообразной информации, начиная от истории описания «What is UNIX» («Что такое UNIX») и заканчивая серией стандартов Single Unix, Unix95, Unix98, Unix03, ISO/IEC 9945:2003, а также UNIX System API Table.
В этот неправительственный консорциум входят около 200 членов. В их числе правительственные организации, учебные заведения и представители бизнеса разных стран. Приведем (в алфавитном порядке) нескольких представителей компьютерного бизнеса членов The Open Group :
| AT&T | Hewlett-Packard | IBM |
| Intel | NEC Corporation | Oracle |
| Red Hat (R), Inc. | Sun Microsystems | SUSE LINUX Products GmbH |
В заключение этого раздела заметим, что существует еще много менее значимых стандартов на программное обеспечение. Один из них, Linux Standard Base ( LSB ), создавался Free Standards Group. Но последняя объединилась с Open Source Development Labs (OSDL) и образовала новую организацию The Linux Foundation. Назовем и еще один документ – лицензию BSD (программная лицензия университета Беркли, применяемая для распространения UNIX-подобных операционных систем BSD).
Стандарт C++: общие сведения
1.1. Область применения
1. Этот Международный Стандарт устанавливает требования для реализации языка программирования С++. Первым таким требованием является то, что эти требования реализуют язык, и таким образом Международный Стандарт также определяет С++. Другие требования и допущения (послабления) относительно первого требования будут появляться в разных местах этого Международного Стандарта.
1.2. Ссылки на нормативные документы
1. Документы, перечисленные в этом разделе, обязательны для применения настоящего документа. Для датированных ссылок используются только указанные издания. Если дата не указана, то используется последнее издание (включая любые поправки).
1.1. Ecma International, ECMAScript Language Specification, Standard Ecma-262, third edition, 1999.
1.2. ISO/IEC 2382 (all parts), Information technology — Vocabulary
1.3. ISO/IEC 9899:1999, Programming languages — C
1.4. ISO/IEC 9899:1999/Cor.1:2001(E), Programming languages — C, Technical Corrigendum 1
1.5. ISO/IEC 9899:1999/Cor.2:2004(E), Programming languages — C, Technical Corrigendum 2
1.6. ISO/IEC 9899:1999/Cor.3:2007(E), Programming languages — C, Technical Corrigendum 3
1.7. ISO/IEC 9945:2003, Information Technology — Portable Operating System Interface (POSIX)
1.8. ISO/IEC 10646-1:1993, Information technology — Universal Multiple-Octet Coded Character Set (UCS). Part 1: Architecture and Basic Multilingual Plane
1.9. ISO/IEC TR 19769:2004, Information technology — Programming languages, their environments and system software interfaces — Extensions for the programming language C to support new character data types
2. Библиотеки, описанные в п. 7 документа ISO/IEC 9899:1999 and Clause 7 of ISO/IEC 9899:1999/Cor.1:2001и в пункте 7 документа ISO/IEC 9899:1999/Cor.2:2003 далее будут называться стандартными библиотеками Си (в оговорках, отмеченных в пунктах с 18 по 30 в С.5, стандартные библиотеки С являются подмножеством стандартных библиотек С++).
3. Библиотека, описанная в ISO/IEC TR 19769:2004 далее будет называться C Unicode TR.
4. Интерфейс операционной системы, описанный в ISO/IEC 9945:2003, далее будет называться POSIX.
5. ECMAScript Language Specification, описанная в стандарте Standard Ecma-262, далее будет называться ECMA-262.
1.3. Термины и определения
1. В этом документе применяются следующие определения.
2. 17.3 определяет дополнительные термины, которые используются только в пунктах с 17 по 30 и приложении D.
3. Термины, которые используются редко в этом Международном Стандарте, определены там, где они используются, а определение этих терминов выделено курсивом.
1.3.1. [defns.argument]
1.3.2. [defns.argument.macro]
1.3.3. [defns.argument.throw]
1.3.4. [defns.argument.templ]
1.3.5. [defns.cond.supp]
conditionally-supported (условно поддерживается)
Программная конструкция, реализация которой не требует поддержки. [Примечание: Все условно-поддерживаемые конструкции, которые не поддерживаются, должны быть документированы в каждой реализации].
1.3.6. [defns.diagnostic]
diagnostic message (сообщение диагностики, сообщение об ошибке)
Сообщение, принадлежащее к определённому во время выполнения поднабору выходных сообщений.
1.3.7. [defns.dynamic.type]
dynamic type (динамический тип)
тип наиболее наследуемого объекта (1.8), для которого значение glvalue указывает на ссылочное выражение glvalue.
1.3.8. [defns.dynamic.type.prvalue]
dynamic type (динамический тип)
статический тип выражения prvalue.
1.3.9. [defns.ill.formed]
ill-formed program (нерациональная программа, плохо построенная программа)
Программа, которая не является правильно построенной (сформированной).
1.3.10. [defns.impl.defined]
implementation-defined behavior (поведение, определяемое реализацией)
Поведение правильно построенной программной конструкции с правильными данными, которое зависит от реализации и которое должно быть документировано каждой реализацией.
1.3.11. [defns.impl.limits]
implementation limits (ограничения реализации)
Ограничения, налагаемые на программы реализацией языка.
1.3.12. [defns.locale.specific]
locale-specific behavior (поведение, специфическое для местности)
Поведение, которое зависит от местных национальных соглашений, культуры и языка, и которое должно быть документировано каждой реализацией. http://alenacpp.blogspot.ru/2005/08/unspecified-behavior-undefined.html
1.3.13. [defns.multibyte]
multibyte character (многобайтовый символ)
Последовательность из одного или более байтов, представляющая элемент расширенного набора символов источника или среды выполнения. [Примечание: Расширенный набор символов включает в себя базовый набор символов (2.3)].
1.3.14. [defns.parameter]
1.3.15. [defns.parameter.macro]
1.3.16. [defns.parameter.templ]
1.3.17. [defns.signature]
signature
имя, список параметров типа (см. раздел 8.3.5), и пространство имён (если таковое имеется). [Примечание: Сигнатуры (подписи) используются как основа для декорирования имён и ссылок]
1.3.18. [defns.signature.templ]
1.3.19. [defns.signature.spec]
1.3.20. [defns.signature.member]
1.3.21. [defns.signature.member.templ]
1.3.22. [defns.signature.member.spec]
1.3.23. [defns.static.type]
static type (статический тип)
Тип выражения (подробности в разделе 3.9 этого стандарта) в результате анализа программы без учёта семантики исполнения. [Примечание: Статический тип выражения зависит только от программы, в которой появляется выражение, и не изменяется до завершения программы]
1.3.24. [defns.undefined]
undefined behavior (неопределённое поведение)
Поведение, на которое этот Международный Стандарт не накладывает никаких требований. [Примечание: Поведение можно считать неопределённым, когда этот Международный Стандарт не содержит чёткого определения поведения или когда программа использует ошибочные конструкции или ошибочные данные. Допустимое неопределённое поведение находится в границах от полного игнорирования ситуации с совершенно непредсказуемым результатом, до ведения документирования параметров окружения (с выдачей сообщения об ошибке или без выдачи такового), и до прерывания трансляции или выполнения программы (с выдачей диагностического сообщения). Многие ошибочные программные конструкции не приводят к неопределённому поведению; они должны диагностироваться] (http://alenacpp.blogspot.ru/2005/08/unspecified-behavior-undefined.html)
1.3.25. [defns.unspecified]
unspecified behavior (неуточняемое или неспецифицированное поведение)
Поведение правильно построенной программной конструкции с правильными данными, которое зависит от реализации. [Примечание: Реализация не обязана документировать выбор поведения. Как правило, диапазон допустимых поведений указан в данном Международном стандарте]
1.3.26. [defns.well.formed]
1.4. Соответствие реализации
1. Набор диагностируемых правил состоит из всех синтаксических и семантических правил в этом Международном стандарте, за исключением тех правил, которые содержат явное указание на то, что “диагностика не требуется” или которые описаны как приводящие к “неопределенному поведению”.
2. Хотя этот Международный стандарт устанавливает только требования к реализациям C++, эти требования часто легче понять, если они сформулированы как требования к программам, частям программ или выполнению программ. Такие требования имеют следующее значение:
2.1. Если программа не содержит нарушений правил настоящего Международного стандарта, соответствующая реализация в пределах своих ресурсов должна принять и правильно исполнить эту программу (“Правильное выполнение” может включать неопределенное поведение, в зависимости от обрабатываемых данных; см. 1.3 и 1.9).
2.2. Если программа содержит нарушение какого-либо диагностируемого правила или появление конструкции, описанной в этом Стандарте как “условно поддерживаемая”, когда реализация не поддерживает эту конструкцию, соответствующая реализация должна выдать по крайней мере одно диагностическое сообщение.
2.3. Если программа содержит нарушение правила, для которого не требуется диагностика, этот Международный стандарт не предъявляет никаких требований к реализации в отношении этой программы.
3. Для классов и шаблонов классов в разделах библиотеки указываются частичные определения. Частные члены (пункт 11) не указываются, но каждая реализация должна предоставлять их для заполнения определений в соответствии с описанием в разделах библиотеки.
4. Для функций, шаблонов функций, объектов и значений в разделах библиотеки указываются объявления. Реализации должны предоставлять определения, соответствующие описаниям в разделах библиотеки.
5. Имена, определенные в библиотеке, имеют область пространства имен (7.3). Модуль транслятора C++ (2.2) получает доступ к этим именам, включая соответствующий заголовок стандартной библиотеки (16.2).
6. Шаблоны, классы, функции и объекты в библиотеке имеют внешнюю связь (3.5). Реализация предоставляет определения для стандартных библиотечных объектов, по мере необходимости, при объединении единиц перевода для формирования полной программы на C++ (2.2).
8. Соответствующая реализация может иметь расширения (включая дополнительные библиотечные функции) при условии, что они не изменяют поведение какой-либо хорошо сформированной программы. Реализации необходимы для диагностики программ, использующих такие расширения, которые неправильно сформированы в соответствии с настоящим Международным стандартом. Однако, сделав это, они могут компилировать и выполнять такие программы.
9. Каждая реализация должна включать документацию, которая идентифицирует все условно поддерживаемые конструкции, которые она не поддерживает, и определяет все характеристики, зависящие от локали (эта документация также определяет поведение, определяемое реализацией; см. 1.9.).
1.5. Структура настоящего Международного стандарта
1. Пункты 2-16 описывают язык программирования C++. Это описание включает подробные синтаксические спецификации в форме, описанной в 1.6. Для удобства в Приложении А повторяются все такие синтаксические спецификации.
2. Пункты с 18 по 30 и Приложение D (пункты о библиотеке) описывают стандартную библиотеку C++. Это описание включает подробные описания шаблонов, классов, функций, констант и макросов, составляющих библиотеку, в форме, описанной в пункте 17.
3. В приложении В рекомендуются нижние границы возможностей соответствующих реализаций.
4. Приложение C кратко описывает эволюцию C++ с момента его первого опубликованного описания и подробно объясняет различия между C++ и C. Некоторые функции C++ существуют исключительно в целях совместимости; Приложение D описывает эти функции.
§ 8.1. Общие сведения о языке программирования С++
Текст программы говорит о том, как, а комментарии должны объяснять, почему
Содержание
История языка
Язык C++ (читается си-плюс-плюс) возник в начале 1980-х годов, когда сотрудник фирмы Bell Labs Бьёрн Страуструп придумал ряд усовершенствований к языку C под собственные нужды. Страуструп решил дополнить язык C возможностями, имеющимися в языке Симула. Из этого языка были позаимствованы возможности объектно-оринтированного программирования (возможность работы с классами и объектами). К 1983 году в язык были добавлены новые возможности, такие как виртуальные функции, перегрузка функций и операторов, ссылки, константы, пользовательский контроль над управлением свободной памятью, улучшенная проверка типов и новый стиль комментариев ( // ). Получившийся язык уже перестал быть просто дополненной версией классического C (“C с классами“) и был переименован в «C++». Его первый коммерческий выпуск состоялся в октябре 1985 года. 
Вот как повествует историю создания C++ сам разработчик языка:
До начала официальной стандартизации язык развивался в основном силами Страуструпа в ответ на запросы программистского сообщества. Функцию стандартных описаний языка выполняли написанные Страуструпом печатные работы по C++ (описание языка, справочное руководство и так далее). Лишь в 1998 году был ратифицирован международный стандарт языка C++: ISO/IEC 14882:1998 «Standard for the C++ Programming Language». В настоящее время стандарт языка C++ разрабатывает Комитет ISO C++, который называется WG21 (официально ISO/IEC JTC1 (Объединенный технический комитет 1) / SC22 (Подкомитет 22) / WG21 (Рабочая группа 21)). WG21 был создан в 1990/91 годах и состоит из аккредитованных экспертов из стран-членов ISO/IEC JTC1/SC22, которые заинтересованы в разработке C++.
Более 20 лет С++ находится в тройке самых популярных и востребованных языков программирования. (В этом можно убедиться, посетив сайт TIOBE).
C++ продолжает развиваться, чтобы отвечать современным требованиям. Одна из групп, разрабатывающих язык C++ и направляющих комитету по стандартизации C++ предложения по его улучшению — это Boost. Последний стандарт языка вышел в 2020 году и носит наименование С++20. Следующий стандарт не заставит себя долго ждать и появится, как ожидают, в 2023 году.
Никто не обладает правами на язык C++, он является свободным.
Общая характеристика языка
C++ — компилируемый, статически типизированный язык программирования общего назначения, на котором можно создавать программы любого уровня сложности. С++ – это мультипарадигмальный язык (от слова парадигма – стиль написания компьютерных программ), включающий широкий спектр различных стилей и технологий программирования. Часто его причисляют к объектно-ориентированным языкам, но, строго говоря, это не так. В процессе работы разработчик получает абсолютную свободу в выборе инструментов для того, чтобы задача, решаемая с помощью того или иного подхода, была решена максимально эффективно. Иными словами, С++ не понуждает программиста придерживаться только одного стиля разработки программы (например, объектно-ориентированного).
Синтаксис C++ унаследован от языка C. Одним из принципов разработки было сохранение совместимости с C. Тем не менее, C++ не является в строгом смысле надмножеством C. Со временем, практическая совместимость между языками C и C++ постепенно будет утрачиваться, так как языки разрабатывают разные группы по стандартизации, не взаимодействующие друг с другом.
C++ повлиял на многие языки программирования, в их числе: Java, C#, PHP, Perl, D, Lua, Rust.
C++ имеет богатую стандартную библиотеку, которая включает в себя распространённые контейнеры и алгоритмы, ввод-вывод, регулярные выражения, поддержку многопоточности и другие возможности. (Подробнее)
За время своего существования за языком С++ закрепились устойчивые мифы, которые легко опровергаются (см. здесь: Часть1 и Часть2)
Алфавит языка
.
Символы алфавита образуют лексемы. Лексема (англ. – token) – это минимальная единица языка, имеющая самостоятельный смысл. Лексемы – формируют базовый словарь языка, понятный компилятору.
Набор лексем представляет собой текст на языке программирования, который понятен компилятору языка. Текст программы на языке программирования называется исходным кодом (или, на жаргоне программистов, “исходником“).
Всего существует пять видов лексем:
- Ключевые слова (keywords) Идентификаторы (identifiers) Литералы (literals) Операции (operators) Знаки пунктуации (разделители, punctuators)
Комментарии
Комментарии служат для описания и документирования исходного кода. В C++ применяются два вида комментариев: многострочный и однострочный. Например:
В комментариях можно использовать любые, доступные в среде, символы – компилятор игнорирует содержимое закомментированного блока или строки.
Далеко не все программисты позитивно относятся к комментариям (“лучший комментарий – это его отсутствие”). Они считают, что хорошо написанный код сам говорит о том, для чего составлена данная программа и как она работает. С этим не поспоришь. Но когда текст программы должен быть задокументирован (например, по требованию заказчика), то к комментированию кода нужно отнестись достаточно серьезно.
Структура программы на языке C++
Самая простая программа на C++ может содержать следующий код:
Первая программа
Традиционно, первой программой на изучаемом языке является программа вывода на экран строки приветствия “Здравствуй, мир!”. Чтобы в консольном окне появился текст приветствия, программу необходимо дополнить следующими инструкциями и директивами:
Для вывода символьной строки необходимо использовать объект потока cout и операцию вставки “ ” (два символа “меньше”, следующих друг за другом, без пробела). Символьная строка должна быть заключена в двойные кавычки. Завершает вывод данных манипулятор endl (end line – конец строки). Конец программы обозначен инструкцией return (возврат значения). Эта инструкция является необязательной (поскольку программа, в случае её отсутствия, будет возвращать значения операционной системе не явно). Но мы возьмем за хороший навык всегда использовать эту инструкцию в конце программы. Возвращаемое значение – 0 (признак успешного завершения). Обратите внимание, что любая инструкция (предложение языка) в C++ должна заканчиваться точкой с запятой.
Объявление
говорит о том, что мы будем использовать пространство имен стандартной библиотеки ( STD ). Это позволит сделать код более лаконичным. В противном случае, строка 5 выглядела бы следующим образом:
Результат работы программы будет выведен строкой ниже.
Интегрированные среды разработки (IDE)
Ниже, в порядке увеличения функциональных возможностей, перечислены свободно распространяемые среды разработки на C++. Этим списком, конечно, не исчерпывается все разнообразие существующих IDE, как свободных, так и коммерческих, но данное ПО (кроме QT Creator) является рекомендованным на Всероссийской предметной олимпиаде школьников по информатике. Обратите внимание, что из легковесности среды вовсе не вытекает удобство верстки программного кода. Легковесные среды предназначены для разработчиков, которые хорошо понимают особенности языка без навязчивых подсказок IDE и предупреждений дотошных анализаторов. С другой стороны, составлять небольшие программы (в несколько строк кода) гораздо удобнее и быстрее как раз в такой легковесной среде, как Geany.
Пользователи Windows должны обратить внимание на то, что данные среды поставляются без компилятора! Только для Qt Creator и Code::Blocks можно установить компилятор совместо со средой разработки. Но, как правило, это будет не самая свежая версия GCC. Последнии версии копилятора необходимо устанавливать отдельно. Для пользователей GNU/Linux этот процесс является менее трудоемким, т. к. все необходимое ПО уже находится в пакетной базе дистрибутива, включая последние версии компиляторов. Как установить компилятор GCC в ОС Windows см. здесь.
Geany
Code::Blocks
Code::Blocks является базовой средой для разработки консольных приложений курса.
Сайт Code::Blocks: https://www.codeblocks.org/
Qt Creator
Qt Creator — кроссплатформенная свободная IDE для разработки на С, С++ и QML. Разработана Trolltech для работы с фреймворком Qt. Включает в себя графический интерфейс отладчика и визуальные средства разработки интерфейса как с использованием QtWidgets, так и QML. 
Данная IDE является базовой средой курса для разработки как консольных приложений, так и приложений с оконным интерфейсом.
Сайт фреймворка Qt5: https://www.qt.io/
Eclipse CDT
Более подробные сведения об Eclipse вы можете найти в этом разделе нашего сайта: Eclipse Platform
Сайт CDT Downloads: https://www.eclipse.org/cdt/downloads.php