Есть ли список интерфейсов стандартной библиотеки С++ 11, для которых требуются исключения?

Из чтения версии N3242 проекта С++ 11 видно, что некоторые компоненты интерфейсов стандартной библиотеки (в частности, многопоточность и блокировка) зависят от обработки исключений.

Поскольку я много работаю с отключенными исключениями, мне интересно, какие компоненты/функции библиотеки будут (практически или логически) непригодными для использования без включенной обработки исключений?


person justin    schedule 12.09.2011    source источник
comment
Практически все функции можно использовать, пока не возникнет фактическое исключение. Затем ваша программа падает. Если библиотечная функция может генерировать ошибки, это указано в стандарте, так что в каком-то смысле существует список — сам стандарт.   -  person n. 1.8e9-where's-my-share m.    schedule 12.09.2011
comment
@н.м. кажется, вы могли прочитать мой пост, используя неправильное определение «практически»: dictionary.reference.com /browse/практически. в противном случае существует разница в сложности и локальности таких вещей, как std::vector.at(size_t), по сравнению с потоками и блокировками программы/среды. реализовав библиотеки потоков и блокировок, я могу сказать вам, что вы можете легко и предсказуемо защитить себя от первого. (продолжение)   -  person justin    schedule 13.09.2011
comment
(продолжение) защитить себя от последнего гораздо сложнее. когда что-то идет не так, необработанное исключение не является решением (для некоторых из нас). я не могу просто игнорировать эти ошибки :) таким образом, я не могу полагаться на реализацию потоковой передачи и блокировки библиотеки, потому что единственная защита, предлагаемая библиотекой, - это исключения. в заключение, многопоточный и блокирующий интерфейсы не подходят для программ, в которых отключены исключения. надеюсь, это поможет.   -  person justin    schedule 13.09.2011


Ответы (2)


Прежде всего (как напоминание), отключение исключений и RTTI — это специфичные для компилятора расширения, которые Стандарт не рассматривает.

Поскольку стандартная библиотека обычно привязана к компилятору, может случиться так, что ваша реализация стандартной библиотеки была специально разработана, чтобы справляться с этим (и, в частности, справляться с при этом new возвращает нулевые указатели вместо повышения std::bad_alloc).

Поэтому то, о чем вы просите, бессмысленно. Полный список смотрите в документации вашей собственной библиотеки.

При этом Стандарт действительно гарантирует, что ряд операций никогда не будет генерировать ошибки. Я не знаю ни одной операции, которая проглатывает исключения, я полагаю, что большинство из них на самом деле безопасно использовать как есть.

Например, все алгоритмы должны быть безопасными.

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

person Matthieu M.    schedule 13.09.2011
comment
есть распространенные варианты new, чтобы избежать bad_alloc. nothrow_t — это встроенная форма, предоставляемая библиотекой, другие (включая определяемые пользователем распределители) могут быть определены пользователем посредством размещения new. для коллекций можно указать распределитель, который не выбрасывает: std::vector<double, my_nonthrowing_allocator<double> > и тогда интерфейс вектора в значительной степени пригоден для использования, если вы придерживаетесь правил. (продолжение) - person justin; 13.09.2011
comment
(продолжение) существуют сложные высококачественные программы на С++, которые не полагаются на исключения. у вашего сообщения есть достоинства (+1), но я думаю, что в этом случае можно сделать некоторые обобщения -- опять же, мои примеры многопоточности (небезопасно), блокировки (небезопасно) и теперь вектора (интерфейс можно безопасно использовать, если от этого не зависит чья-то жизнь). - person justin; 13.09.2011
comment
@Justin: я не говорю, что это невозможно, я просто говорю, что это не стандарт. Например, даже если new (nothrow_t) существует, vector может его не использовать. Теперь я знаю, что некоторые библиотеки компилируются без исключений, например, LLVM/Clang. Однако они также переопределили большинство служебных классов. - person Matthieu M.; 14.09.2011
comment
ах, извините за недоразумение. - person justin; 14.09.2011

Этому вопросу больше месяца, и он остался без ответа.

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

  • std::thread Раздел 30.2.2. переходный. Абстракция реализована с использованием нативных реализаций.

  • std::mutex, std::recursive_mutex, std::timed_mutex, std::recursive_timed_mutex. Раздел 30.4.1, непереходный, если вы указываете собственную блокировку без исключений (через BasicLockable, Lockable, TimedLockable). Абстракция реализована с использованием нативных реализаций.

  • std::condition_variable Раздел 30.5. переходный. Абстракция реализована с использованием нативных реализаций.

примечание: будет больше.

person Community    schedule 14.10.2011