Должны ли мы использовать constexpr везде, где мы можем? - PullRequest
23 голосов
/ 22 июля 2011

Мы, очевидно, не можем сделать все constexpr. И если мы ничего не сделаем constexpr, то больших проблем не будет. До сих пор было написано много кода без него.

Но стоит ли шлепать constexpr по всему, что может иметь это? Есть ли потенциальные проблемы с этим?

Ответы [ 3 ]

14 голосов
/ 22 июля 2011

Это не будет беспокоить компилятор.Компилятор (или должен в любом случае) даст вам диагностику, когда / если вы используете его в коде, который не соответствует требованиям constexpr.

В то же время, я бы немногоне решаясь просто дать ему пощечину, потому что ты мог.Хотя компилятор не беспокоит / не будет беспокоить, ваша основная аудитория - другие люди , читающие код.По крайней мере, IMO, вы должны использовать constexpr, чтобы передать им довольно конкретное значение, и просто добавить его к другим выражениям, потому что вы можете ввести в заблуждение.Я думаю, что было бы справедливо для читателя задаться вопросом, что происходит с функцией, которая помечена как constexpr, но используется только как обычная функция времени выполнения.

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

8 голосов
/ 22 июля 2011

Почему я не пытаюсь ставить constexpr при каждой возможности в форме списка, и в произвольном порядке:

  • Я не пишу однострочные функции, которые часто
  • когда я пишу однострочник, он обычно делегирует функции non-constexpr (например, std::get недавно появлялся несколько раз)
  • типы, с которыми они работают, не всегда являются литеральными типами; да, ссылки являются литеральными типами, но если ссылочный тип сам по себе не является литералом, у меня все равно не будет экземпляра во время компиляции
  • тип, который они возвращают, не всегда буквальный
  • они просто не все полезны или даже значимы во время компиляции с точки зрения их семантики
  • Мне нравится отделять реализацию от декларации

Функции Constexpr имеют так много ограничений, что они являются нишей только для специального использования. Не оптимизация или желательный супер-набор функций в целом. Когда я делаю , пишу один, это часто потому, что метафункция или обычная функция сами по себе не могли бы ее обрезать, и у меня к этому есть особое мышление. Функции Constexpr не вкус , как другие функции.

У меня нет особого мнения или совета по поводу конструкторов constexpr, потому что я не уверен, что могу полностью сосредоточиться на них, а пользовательские литералы еще не доступны.

0 голосов
/ 22 июля 2011

Да .Я полагаю, что помещать такое const - это всегда хорошая практика, где вы можете.Например, в вашем class, если данный метод не модифицирует ни одного члена, вы всегда стремитесь поставить ключевое слово const в конце.

Помимо языкового аспекта, упоминание const ness такжехороший признак будущему программисту / рецензенту, что выражение имеет константность в этом регионе.Это относится к хорошей практике кодирования и также повышает удобочитаемость.например (из @Luc)

constexpr int& f(int& i) { return get(i); }

Теперь, поставив constexpr, можно предположить, что get() также должно быть constexpr.

Я не вижу никаких проблем или следствий из-за constexpr.

Редактировать : есть дополнительное преимущество constexpr в том, что вы можете использовать их в качестве аргумента template в некоторых ситуациях.

...