Читаю тут: http://www.wikiservice.at/dse/wiki.cgi?ExceptionsConsideredHarmful, но пока не дочитал до конца.
Шеф против исключений, а я - за, ну и понятно, чья в итоге возьмет. Как бы мне его переубедить?.. Или переубедите меня, в конце концов.

А что использовать вместо исключений ? goto обработчик ошибок ?
Ну и конечно исключения втыкать везде тоже не надо .

Определенно надо его переубеждать. Иначе начнет программа у клиента выпадать, выдавая только разработчику ОС понятное сообщения. Они ему жалится начнут, а он тебя кушать. Где-то на заре .NET у М$ была статья для переходящих с VB на VB.NET, в чем преимущества обработки Exception, там достаточно хорошо аргументировалось. А может это где в другом месте было. Дома поискаю.

Есть в Exceptions оверхед, но он не слишком большой. Разумеется, если не вотнут тру-катцх куда-нибудь в тяжелый цикл.
Так что - юзабилитно.
У нас было даже спец.требование - тру-катчить использование каждого внешнего (из внешней ДЛЛки) объекта и тру-катчить полностью содержимое конструктора. Остальное - по мере необходимости.

return codes.

Наша система уже давно на рынке и стабильна. Дело не в этом. Я хочу их использовать, а они даже не включены. Если же их просто так включить, то возможны осложнения, или нет?

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

Я имел в виду опцию компилятора. Если она не выставлена, никаких исключений ваще нет.

На мой взгляд - бессмыссленно отключать.
Бо, если исключение возникает - оно все одно возникает. А тру-кэтч - только инструмент его обработки.
Кроме этого - программист, использующий Ексептионы, мыслит несколько иначе, чем такой же бедолага,
неимеющий возможности для этого. К примеру, твои ретурн-коде использоваться не будут, а будет полное
текстовое сообщение об месте и причине ошибки, обрабатываемое не в функции вызова, а там где оно
будет получено/откэчено.
Т.е. если не используется - будет один код, если используется - другой. И этот другой код написан и работает
по-другому. Так что если используется и выключено - становится непонятно кто и как должен обрабатывать
возникающие ошибки.
Еще существенный момент - ошибки, возникающие в конструкторах - отследить их по ретурн-коде просто
невозможно.
Ну и писать в старом стиле, при использовании Ехсепртион, станет неудобно в самом ближайшем будущем.
Представь себе, что есть иерархия классов - десяток уровней, 10-12 тыс классов - каким образом пасовать
ретурн-коде и разбираться с ними? Так что альтернативы то и нет - надо юзать и на полную...

Ты как будто только себя читаешь. Исключения не используются и отключены - это факт.

C++ exceptions: за и против vs Исключения не используются и отключены - это факт.
------
Ты уж определись со своей ситуацией...

К сожалению не всегда применимо .
Пишу в данный момент софтину , работаю с УСБ картой , меряю напряжение на нескольких каналах.
В функции создается task , channels , sample clock и т.д. в общем
резервирую рессурсы и потом всё это дело читается и посылается сигналом (кстати бустовским ;-))
Сишные функции сам завёртывал в классы , при ошибках запускаю исключения.
Если бы писал без исключений , пришлось бы проверять каждое возвращённое значение и вызывать функцию зачистки или
прыгать на метку и зачищать ,не важно , на что был бы похож код ?
А так всё акуратно - try catch - рессурсы освободили .

Ну а как же голый С работает? :)
У меня примерно такая же ситуация, и указание не использовать исключения слегка напрягает.

Исключения не используются и отключены - это факт. Я бы хотел их использовать в дальнейшем, но установки проекта делают это невозможным. Чтобы изменить установки проекта, нужно переубедить шефа. Что тут непонятного?

Чтобы изменить установки проекта, нужно переубедить шефа.
------
Тебе и дан набор аргументов. И За, и Против. Со стороны разработчика. Что тут непонятного?
Могу дать набор аргументов Шефа, имеющего работающий проект. Тоже - и За, и Против.
Но, работая в С++ и имея возможность пользоваться исключениями - не пользоваться ими - глупо.

У него главный аргумент: new при включенных исключениях швыряет bad_alloc, при выключенных - возвращает NULL. И что я ему на это скажу?

Ну вот так и работает .
Все пестрит goto .
Соглашусь с Murr что не пользоваться исключениями в плюсах по меньшей мере глупо ,
так и скажи своему шефу :-)
+ код становится проще , значит потенциальных багов меньше .

У него главный аргумент: new при включенных исключениях швыряет bad_alloc, при выключенных - возвращает NULL.
И что я ему на это скажу?
------
Что будет делать твой шеф, если потребуется локализовать место возникновения bad_alloc в иерархии? 10-12 уровней?
У меня было 6 уровней, часть из них - в сторонней ДЛЛ, и я в них полностью зашивался из-за невозможности определить
место возникновения проблемы...
Ты выше читал или просматривал? Там четко сказано, что одно из спец.требований - тру-кэтч на весь конструктор. Как раз для таких случаев.
Кроме этого, когда придет scorpi_, он объяснит (мне лень) как перегрузить new, чтобы не было внешних исключений. Хотя, насколько Я помню, он уже это делал...

Зачем его локализовывать? Указатель проверяется на месте на ноль, и все дела.
Как перегрузить new, я и сам знаю/найду.
зы Где-то читал, что не рекомендуется швырять через границы dll, а уж перехватывать исключения в самом конструкторе ваще смысла нет.

Зачем его локализовывать?
-----
Затем, что возникновение ошибки есть ситуация не нормальная - подлежит исследованию на предмет причины возникновения и доработке на предмет устранения - что затруднительно, не зная где оно возникло...
Указатель проверяется на месте на ноль
-----
Ексептион кэтчится на заданном уровне, устраняется причина, при возможности - пересоздается объект и все продолжает работать как если бы ситуации не возникало... и это - без всяких глупостей с проверками на ноль...
зы Где-то читал, что не рекомендуется швырять через границы dll,
-----
Не скажу за все - возможно, что где-то, например, когда длл-ка "исполняется" как отдельная задача, есть смысл для такого ограничения.
У меня, однако, гораздо чаще ситуация, когда расширяется объект из длл-ки - так что без этого - никак.
а уж перехватывать исключения в самом конструкторе ваще смысла нет.
------
Да ну? Я вот как-то привык к тому, что выбрасываемое исключение, если уж оно выпало, т.е. не обработано/разрезолвлено, из конструктора, содержит не "смещение в коде относительно соответствующего сегмента", а нормальное описание проблемы - в конструкторе класса такого-то, невозможно создать агрегированный объект такой-то, по причине... дальше идет описание проблемы возникшей в конструкторе или методе агрегированного объекта... и т.п. Чем более полная и точная информация получается - тем проще понять что именно не так и устранить причину проблемы.