함수를`constexpr`로 선언하지 ** 않는 ** 이유는 무엇입니까?

함수를`constexpr`로 선언하지 ** 않는 ** 이유는 무엇입니까?

---

return 문으로 구성된 모든 함수는 선언 할 수만 있으므로 constexpr모든 인수가 constexpr있고 constexpr본문에서 함수 만 호출 되면 컴파일 타임에 평가 될 수 있습니다 . 선언되지 않은 이유가 있는 등의 기능은 constexpr?

예:

  constexpr int sum(int x, int y) { return x + y; }
  constexpr i = 10;
  static_assert(sum(i, 13) == 23, "sum correct");

누구든지 함수 선언이 constexpr해를 끼치는 예를 제공 할 수 있습니까?

---

몇 가지 초기 생각 :

함수를 선언 할 타당한 이유가 없어도 키워드가 과도기 역할을 constexpr한다고 상상할 수 constexpr는 없습니다. 컴파일 타임 평가가 필요하지 않은 코드에 키워드가 없으면 컴파일 타임 평가를 구현하지 않는 컴파일러가 해당 코드를 컴파일합니다 (그러나를 사용하여 설명 된대로 필요한 코드에서 안정적으로 실패 constexpr).

그러나 내가 이해하지 못하는 것은 : 함수를 선언 할 합당한 이유가 없어야한다면 표준 라이브러리의 모든 함수 constexpr가 선언되지 않은 이유는 무엇입니까? (당신은 그것을 할 시간이 충분하지 않았기 때문에 아직 완료되지 않았다고 주장 할 수 없습니다. 왜냐하면 모든 사람 을 위해 그것을하는 것은 생각할 필요가 없기 때문입니다 .-모든 단일 기능에 대해 만들 것인지 아닌지를 결정하는 것과는 대조적 입니다.)- - 나는 것을 알고 N2976은 의도적으로 너무 가능한 구현을 위해 limitating 것 이와 같은 컨테이너 많은 표준 라이브러리 유형에 대한 cstrs이 필요합니다. 인자에서 그것들을 제외하고 그냥 궁금해하자 : 일단 표준 라이브러리의 타입이 실제로 cstr을 가지면, 왜 모든 함수가 그에 대해 작동하지 않는가 선언constexprconstexprconstexprconstexpr?

대부분의 경우 constexpr컴파일 시간 사용을 고려하지 않기 때문에 함수를 선언하지 않는 것을 선호 할 수도 있다고 주장 할 수 없습니다 . 귀하의 코드를 사용하게되지만 귀하가 사용하지 않는 용도로 사용될 수 있습니다. (물론 유형 특성 유형과 유사한 것들에 대해 허용됩니다.)

그래서 의도적으로 함수를 선언하지 않는 좋은 이유와 좋은 예가 있어야한다고 생각합니다 constexpr.

( "모든 함수"는 항상 의미합니다. constexpr즉, 존재에 대한 요구 사항을 충족하는 모든 함수 는 단일 return 문으로 정의되고 constexpr cstrs가있는 유형의 인수 만 사용하고 constexpr함수 만 호출 합니다.)

문제는 이유는 무엇입니까 std::forward폐기 constexpr-ness를? 이것의 특별한 경우입니다.

---

함수는 동적 캐스트 없음, 메모리 할당 없음 , 비 함수 호출 없음 등에 constexpr대한 규칙을 준수하는 경우 에만 선언 할 수 있습니다 .constexprconstexpr

표준 라이브러리에서 함수를 선언 constexpr하려면 모든 구현이 해당 규칙을 준수해야합니다.

첫째,이를 구현할 수 있는 각 기능을 확인해야 constexpr하며 이는 긴 작업입니다.

둘째, 이것은 구현에 대한 큰 제약이며 많은 디버깅 구현을 금지합니다. 따라서 이점이 비용보다 크거나 요구 사항이 충분히 엄격하여 구현이 constexpr어쨌든 규칙 을 거의 준수해야하는 경우에만 가치가 있습니다 . 각 기능에 대해이 평가를 만드는 것은 다시 한 번 긴 작업입니다.

---

나는 당신이 말하는 것을 부분 평가 라고 생각합니다 . 지금 다루고있는 것은 일부 프로그램은 런타임 정보가 필요한 부분과 런타임 정보없이 수행 할 수있는 부분의 두 부분으로 나눌 수 있으며 이론적으로는 프로그램의 일부를 완전히 평가할 수 있다는 것입니다. 프로그램 실행을 시작하기 전에 런타임 정보가 필요하지 않습니다. 이를 수행하는 몇 가지 프로그래밍 언어가 있습니다. 예를 들어 D 프로그래밍 언어에는 컴파일러에 내장 된 인터프리터가있어 특정 제한을 충족하는 경우 컴파일 타임에 코드를 실행할 수 있습니다.

부분 평가가 작동하는 데에는 몇 가지 주요 과제가 있습니다. 첫째, 컴파일러는 컴파일 타임에 실행 가능한 프로그램에 넣을 수있는 모든 작업을 시뮬레이션 할 수 있어야하기 때문에 컴파일러의 논리를 크게 복잡하게 만듭니다. 이것은 최악의 경우 컴파일러 내부에 완전한 인터프리터가 있어야하므로 어려운 문제 (좋은 C ++ 컴파일러 작성)를 만들고 수행하기가 훨씬 더 어려워집니다.

현재 사양의 이유 constexpr는 단순히 컴파일러의 복잡성을 제한하기 때문이라고 생각합니다 . 제한된 경우는 확인하기가 매우 간단합니다. 컴파일러에서 루프를 구현할 필요가 없습니다 (컴파일러 내부에 무한 루프가 발생하는 경우와 같은 다른 문제를 일으킬 수 있음). 또한 잘못된 포인터를 따르는 것과 같이 런타임에 segfault를 유발할 수있는 명령문을 컴파일러가 잠재적으로 평가해야하는 것을 방지합니다.

염두에 두어야 할 또 다른 고려 사항은 일부 기능에는 cin네트워크 연결 에서 읽기 또는 열기 와 같은 부작용이 있다는 것입니다 . 이와 같은 함수는 기본적으로 컴파일 타임에 최적화 할 수 없습니다. 그렇게하려면 런타임에만 사용할 수있는 지식이 필요하기 때문입니다.

요약하면, 컴파일 타임에 C ++ 프로그램을 부분적으로 평가할 수없는 이론적 인 이유가 없습니다. 사실 사람들은 항상 이것을합니다. 예를 들어 최적화 컴파일러는 기본적으로 가능한 한 많이 수행하려는 프로그램입니다. 템플릿 메타 프로그래밍은 C ++ 프로그래머가 컴파일러 내부에서 코드를 실행하려고 시도하는 한 가지 인스턴스이며, 템플릿 규칙이 함수 언어를 형성하므로 컴파일러가 구현하는 데 더 쉬운 시간이 걸리기 때문에 템플릿으로 일부 멋진 작업을 수행 할 수 있습니다. 또한 컴파일러 작성 시간과 프로그래밍 시간 사이의 균형을 생각한다면 템플릿 메타 프로그래밍은 프로그래머가 원하는 것을 얻기 위해 뒤로 구부리는 것이 괜찮다면 매우 약한 언어 (템플릿 시스템)를 구축하고 유지할 수 있음을 보여줍니다. 언어 복잡성은 간단합니다.

도움이 되었기를 바랍니다!

---

함수에 부작용이있는 경우 표시하고 싶지 않습니다 constexpr. 예

예상치 못한 결과를 얻을 수 없습니다. 실제로 gcc 4.5.1이 무시 하는 것처럼 보입니다.constexpr

참고 URL : https://stackoverflow.com/questions/5112305/whyever-not-declare-a-function-to-be-constexpr