Можете добавить «constexpr» изменить поведение?

Question

Учитывая две программы, где единственная разница в исходном коде - наличие или отсутствие одного constexpr, возможно ли, что значение программы изменится?

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

Представьте, что вы имеете дело с кодовой базой, в которой первоначальный разработчик забыл включить constexpr в места, где это было возможно, возможно, код написан до C++ 11. Было бы здорово, если бы компилятор вывел constexpr, чтобы помочь вам справиться с вашей работой. Конечно, возможно, он также должен предупреждать каждый раз, когда он делает это заключение, и побуждает вас явно добавить constexpr. Но это было бы полезно. Мое беспокойство в том, что это может нарушить ситуацию?

До сих пор я могу думать только о том, что функции constexpr неявно inline, и могут быть ситуации, когда добавление inline может изменить ситуацию в плохом режиме; например, если вы нарушите правило с одним определением.

Answer 1

Существует простой трюк:

template<int n>struct i{}; 
int foo(int){return 0;} 
constexpr int foo(char){return 'a';} 

template<class T=int, T x=1,i<foo(x)>* =nullptr> 
bool bar(){return true;} 
template<class T=int, T x=1,class...Ts> 
bool bar(Ts...){return false;} 

если int foo(int) является constexpr, другая перегрузка bar выбирается по умолчанию.

При использовании другого кода может произойти любое изменение поведения.

live example (просто измените, что #define X закомментировано).

---

Дизайн Например:

Перегрузка char предотвращает код выше от того плохо формируется, никаких диагностическое не требуется, так как все шаблоны должны иметь действительную специализацию. foo<char> принадлежности это. На практике его существование не требуется: ADL может найти foo издалека, перегруженный на some_type*, затем пройдите some_type* как T. Это означает, что никакая единица компиляции не может доказать, что код плохо сформирован.

Ts... делает это bar перегрузка менее предпочтительной. Поэтому, если первый соответствует, нет никакой двусмысленности. Только если первый из них не соответствует (из-за SFINAE, вызванного foo(x), не являющегося constexpr), вызывает ли вторая перегрузка (или, если, скажем, кто-то передал ей аргументы).

Answer 2

Учитывая две программы, в которых единственное различие в исходном коде является наличие или отсутствие одного constexpr, возможно, что смысл изменений программы?

Да, это, по крайней мере, верно для функций constexpr. Именно по этой причине реализациям не разрешено выбирать, какие стандартные функции отмечены как constexpr, основная проблема заключается в том, что пользователи могут наблюдать разные поведения через SFINAE. Это отражено в LWG issue 2013: Do library implementers have the freedom to add constexpr?, который говорит (курсив мой):

Некоторые опасения, высказанные при представлении полной комиссии для голосования к статусу РГ, что этот вопрос был решен без достаточного мысли о последствиях для расходящихся библиотечные реализации, , поскольку пользователи могут использовать SFINAE для наблюдения за другим поведением от идентичного кода. Проблема вернулась к статусу обзора и будет снова обсуждена в Портленде с большей группой. Примечание для Портленда: John Spicer согласился представить озабоченность Core во время любого такого обсуждения в LWG.