Difference between C++03 throw () specifier C++11 noexcept

Question

Difference between C++03 throw () specifier C++11 noexcept

Czy jest jakaś inna różnica między throw() i noexcept oprócz sprawdzania odpowiednio czasu uruchamiania i kompilacji ?

Wikipedia C++11 artykuł sugeruje, że specyfikatory C++03 są przestarzałe.
Dlaczego tak, czy noexcept jest wystarczająco zdolny, aby pokryć to wszystko w czasie kompilacji ?

[Uwaga: odniosłem się do tego pytania i do tego artykułu , ale nie mogłem uzyskać solidnej przyczyny deprecjacji.]

86

c++c++11 exception noexcept throw

Author: Community, 2012-10-11

Source

3 answers

noexcept nie jest sprawdzane podczas kompilacji.

Implementacja nie może odrzucić wyrażenia tylko dlatego, że po wykonaniu rzuca lub może rzucić wyjątek, na który nie pozwala funkcja zawierająca.

Gdy funkcja zadeklarowana noexcept lub throw() próbuje wyrzucić wyjątek, jedyną różnicą jest to, że wywołuje się terminate i inne wywołania unexpected, a ten ostatni styl obsługi wyjątków został skutecznie wycofany.

30

Author: CB Bailey,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2012-10-11 06:23:58

Std:: unexpected() jest wywoływane przez środowisko uruchomieniowe C++ w przypadku naruszenia dynamicznej specyfikacji wyjątku: wyjątek jest wyrzucany z funkcji, której Specyfikacja wyjątku zabrania WYJĄTKÓW tego typu.

Std:: unexpected () może być również wywołane bezpośrednio z programu.

W obu przypadkach, std::unexpected wywołuje aktualnie zainstalowany std:: unexpected_handler. Domyślne std:: unexpected_handler wywołuje std:: terminate.

1

Author: ma13,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-07-10 17:08:13

score 111 · Accepted Answer

Specyfiki WYJĄTKÓW były przestarzałe, ponieważ specyfiki WYJĄTKÓW są generalnie fatalnym pomysłem . noexcept został dodany, ponieważ jest to jedyne w miarę użyteczne użycie specyfika wyjątku: wiedząc, kiedy funkcja nie wyrzuci wyjątku. W ten sposób staje się wyborem binarnym: funkcje, które będą rzucać i funkcje, które nie rzucają.

noexcept została dodana, a nie tylko usuwa wszystkie dane rzutowe inne niż throw(), Ponieważ noexcept jest potężniejsza. noexcept może mieć parametr, który w czasie kompilacji rozwiązuje się w boolean. Jeśli wartość logiczna jest prawdziwa, to noexcept będzie się trzymać. Jeśli wartość logiczna jest false, to noexcept nie przykleja się i funkcja może rzucać.

Tak więc możesz zrobić coś takiego:

struct<typename T>
{
  void CreateOtherClass() { T t{}; }
};

Czy CreateOtherClass rzuca wyjątki? Może, jeśli konstruktor domyślny T może. Skąd mamy wiedzieć? Tak:

struct<typename T>
{
  void CreateOtherClass() noexcept(is_nothrow_default_constructible<T>::value) { T t{}; }
};

W ten sposób CreateOtherClass() rzuci iff domyślnego konstruktora danego typu rzuca. To rozwiązuje jeden z głównych problemów z specyfiki WYJĄTKÓW: ich niezdolność do propagacji stosu wywołań.

Nie możesz tego zrobić z throw().