Может кто нибудь показать красоту с++?

Меня ничего не смущает же. Я просто сказал, что надо знать, что это так работает прежде, чем бросать исключения из конструктора.

Вы сказали: «Например знать, что юзая исключения в конструкторах нельзя делать так.»

Но что именно нельзя делать?

Точнее держать это в голве, потому что скорее всего это знают все кто не первый день пишет на плюсах.

Но что именно нельзя делать?

Наполнять тело деструктора важной логикой. ~B() тут не вызывается вообще.

http://coliru.stacked-crooked.com/a/cf2806f23582c544

Точнее так. http://coliru.stacked-crooked.com/a/33790bb80448d372

Это ничем не отличается от, например, такого:

int f() {
  int * a = new int(30);
  int * b = new int(40);
  ...
  if(!something) return -1;
  ...
  delete a;
  delete b;
  return 0;
}

Вы бы перед тем, как что-то скипать и высказывать свое веское мнение из категории «не слышал», прочитали бы то, что поскипали.
А потом, например, вот это для лучшего осознания:
https://stackoverflow.com/questions/13835817/are-exceptions-in-c-really-slow
https://monoinfinito.wordpress.com/series/exception-handling-in-c/

Мое мнение по весу такое же как и мнение остальных.
За ссылки по теме спасибо. Вторая TL;DR (точнее R'ead позже), но в первой тема вроде как раскрыта:

So, yes, exceptions are slow on the exceptional path, but they are otherwise quicker than explicit checks (if strategy) in general.

Does it matter ?

I would claim it does not. A program should be written with readability in mind, not performance (at least, no as first criterion)...

Не сильно отличается от моего представления вопроса до прочтения материалла. Правда, я не думал, что в некоторых случаях исключения могут быть быстрее if...

Мое мнение по весу такое же как и мнение остальных.

Есть ощущение, что вы полезли озвучивать свое мнение не прочитав того, что было написано, а именно:

Корни растут из тех времен, когда исключения еще только-только появились и их реализация была не zero-cost. Сейчас уже широко используются zero-cost реализация, в которой если исключения не бросаются, то это ничего не стоит (что не совсем так, т.к. некоторая стоимость все-таки есть — это специальные таблицы, на основании которых ищется затем обработчик для исключения). Однако, если исключения бросаются, то они стоят очень дорого (замедление по сравнению с кодами возврата в десятки раз).

Есть ощущение, что вы полезли озвучивать свое мнение не прочитав того, что было написано, а именно:

Да, похоже что не дочитал.
И тем не менее нельзя нападать на людей выражающих свое мнение, даже если они до этого что-то пропустили; в особенности если эти люди открыты к обсуждению.

То есть допустимо, что в компиляторе в процессе компиляции может возникнуть UB, вызванный исполнением constexpr функции?

Нет, просто допустимо не обнаруживать UB от нарушения предусловий использования конструкций стандартной библиотеки, если такое нарушение не является «core language undefined behavior».

если такое нарушение не является «core language undefined behavior».

В драфте C++17 этот термин не появляется. Это что-то из релиза, который за отдельные деньги?

Нет, просто допустимо не обнаруживать UB от нарушения предусловий использования конструкций стандартной библиотеки

«Не обнаруживать UB» = «исполнять код, содержащий UB». Или есть способ не исполнять код, если в нём есть UB, не обнаружив этот самый UB?

В драфте C++17 этот термин не появляется. Это что-то из релиза, который за отдельные деньги?

Термин с того васянского сайта, который цитировал ты.

«Не обнаруживать UB» = «исполнять код, содержащий UB». Или есть способ не исполнять код, если в нём есть UB, не обнаружив этот самый UB?

Вот тебе соответствующие твоей цитате куски из стандарта

an operation that would have undefined behavior as specified in Clause 4 through Clause 19 of this International Standard [ Note: including, for example, signed integer overflow (Clause 8), certain pointer arithmetic (8.7), division by zero (8.6), or certain shift operations (8.8) — end note ] ;

If e satisfies the constraints of a core constant expression, but evaluation of e would evaluate an operation that has undefined behavior as specified in Clause 20 through Clause 33 of this International Standard, it is unspecified whether e is a core constant expression.

Можно было и простыми словами сказать: при вычислении constexpr компилятору разрешено выполнить код, приводящий к UB, если этот код из стандартной библиотеки. То, что стандартная библиотека не должна содержать код безусловно приводящий к UB, и так понятно.

при вычислении constexpr компилятору разрешено выполнить код, приводящий к UB, если этот код из стандартной библиотеки.

Тогда в компиляторе возникнет UB?

Естественно. Видимо предполагается, что разработчики компилятора могут позаботиться, чтобы ничего страшного при этом не произошло. Код стандартной библиотеки им известен.

Естественно.

🤦

Что тут непонятного?

but evaluation of e would evaluate an operation that has undefined behavior as specified in Clause 20 through Clause 33 of this International Standard, it is unspecified whether e is a core constant expression.

Core constant expression выполняются во время компиляции. Допустимо иметь core constant expression, приводящую к UB в коде стандартной библиотеки, при его вычислении.

Какой ещё вывод может из этого следовать, кроме «допустимо, что в компиляторе выполнится код содержащий UB»?

Что тут непонятного?

Мне тоже непонятно, что непонятного в том, что в компиляторе никакого UB не возникает.

Допустимо иметь core constant expression, приводящую к UB в коде стандартной библиотеки, при его вычислении.

Нет, не допустимо. Т.к. если это код, написанный на языке, описанном «in Clause 4 through Clause 19 of this International Standard» и там возникает UB, то компилятор должен это определить.

Т.к. если это код, написанный на языке, описанном «in Clause 4 through Clause 19 of this International Standard»

Хех. Так стандарт нигде не говорит, что стандартная библиотека должна быть написана на C++, соответствующем стандарту. Стандарт определяет только интерфейс стандартной библиотеки. А раз не определяет, то behavior разработчиков компилятора is undefined, в соотвествии со стандартом (3.27).

Так стандарт нигде не говорит, что стандартная библиотека должна быть написана на C++, соответствующем стандарту.

Да. Всё, что он говорит, это

If e satisfies the constraints of a core constant expression, but evaluation of e would evaluate an operation that has undefined behavior as specified in Clause 20 through Clause 33 of this International Standard, it is unspecified whether e is a core constant expression.

Всё остальное вроде «в компиляторе возникнет UB» ­ — это нелепые фантазии.

И что произойдёт, если разработчики специфицировали, что константное выражение e, удовлетворяющее приведённому условию, является core constant expression, и требуется вычисление выражения e во время компиляции?

И что произойдёт, если разработчики специфицировали, что константное выражение e, удовлетворяющее приведённому условию, является core constant expression, и требуется вычисление выражения e во время компиляции?

Оно вычислится во время компиляции.

И что произойдёт при вычислении?

Напоминаю: «evaluation of e would evaluate an operation that has undefined behavior as specified in Clause 20 through Clause 33»

И что произойдёт при вычислении?

Что разработчики специфицировали.