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

Итак, начнём с древнегреческой науки

Было бы неплохо сделать серию статей, в которых описывались различные не очевидные «особенности» языков программирования. Во-первых, «предупреждён — значит, вооружён», во-вторых, знание их позволяет глубже понимать язык и объяснить, в случае чего, чем они опасны. Даже если в своём собственном коде такие конструкции не используются, с этими ловушками можно встретиться при разборе чужого кода или работая в команде.

Продолжение вот этой статьи habrahabr.ru/post/131212, где я собирался показать, как «и ошибки удобно обрабатывать и exceptions при этом не использовать», да всё руки не доходили.

Итак, будем считать, что у нас ситуация, что «настоящие C++ exceptions» использовать нельзя — например, языком разработки является C или компилятор С++ для нашей платформы не поддерживает exceptions (или формально поддерживает, а реально этим пользоваться нельзя). Это, конечно, нетипично для desktop приложений, но вполне обычно для embedded разработки.

Решил выложить небольшое исследование на тему того, как влияет поддержка исключений С++ на общую производительность кода.

Мой опыт работы включает в себя несколько лет разработки под разные встроенные системы, где производительность постоянно приходится учитывать при написании кода (системы реального времени, обрабатывающие большой объём информации — скорости процессора и памяти там никогда не бывало «много»). Соответственно, в этой среде программисты обычно достаточно хорошо представляют себе, какие накладные расходы несёт (или не несёт) та или иная возможность, предоставляемая языком С++. К примеру,

GNU make — широко известная утилита для автоматической сборки проектов. В мире UNIX она является стандартом де-факто для этой задачи. Являясь не такой популярной среди Windows-разработчиков, тем не менее, привела к появлению таких аналогов, как nmake от Microsoft.

Однако, несмотря на свою популярность, make — во многом ущербный инструмент.

Замечательные статьи публиковались в последнее время, хотелось бы добавить ещё несколько абзацев по данной теме.

Уважаемые авторы предыдущих топиков как-то упускали тот момент (или мне показалось? или это само-собой подразумевается?) что exceptions возникли как инструмент для решения весьма утилитарной задачи —

 

Ниже по тексту термином «платформа» будем называть любой заданный набор из процессора, компилятора и операционной системы, под которой скомпилированный код будет запускаться.

Исторически язык C создавался таким, что среди главных целей, положенных в его основу есть такие:

• быть максимально независимым от какой-то конкретной платформы,
• быть максимально эффективным на всех платформах. В идеале — на всех.

Немножко о разнообразии платформ. Их (платформ) существует огромное количество — среди процессоров есть и 16-битные, и 32-битные, и 64-битные. Есть такие, которые умеют выполнять операции с плавающей точкой на аппаратном уровне, какие-то поддерживают операции с двойной точностью, а в каких-то процессорах FPU отсутствует полностью. Процессоры отличаются также внутренним порядком следования байт в слове (big/little endian), как именно процессор работает с внешней памятью, и т.д. и т.п.

И на весь этот зоопарк существует один-единственный Стандарт языка C. Как же это удалось? Вот тут и начинается самое интересное.