이것이 C ++ 11 for 루프의 알려진 함정입니까?

일부 멤버 함수와 함께 3 개의 double을 보유하기위한 구조체가 있다고 가정 해 봅시다.

struct Vector {
  double x, y, z;
  // ...
  Vector &negate() {
    x = -x; y = -y; z = -z;
    return *this;
  }
  Vector &normalize() {
     double s = 1./sqrt(x*x+y*y+z*z);
     x *= s; y *= s; z *= s;
     return *this;
  }
  // ...
};

이것은 단순함을 위해 약간 고안되었지만 유사한 코드가 거기에 있다는 데 동의합니다. 이 메소드를 사용하면 편리하게 연결할 수 있습니다. 예를 들면 다음과 같습니다.

Vector v = ...;
v.normalize().negate();

또는:

Vector v = Vector{1., 2., 3.}.normalize().negate();

이제 begin () 및 end () 함수를 제공하면 새로운 스타일의 for 루프에서 Vector를 사용할 수 있습니다. 예를 들어 x, y, z의 3 개 좌표를 반복 할 수 있습니다 (더 "유용한"예제를 작성할 수 있습니다. Vector를 예를 들어 String으로 대체하여) :

Vector v = ...;
for (double x : v) { ... }

우리는 할 수 있습니다 :

Vector v = ...;
for (double x : v.normalize().negate()) { ... }

그리고 또한:

for (double x : Vector{1., 2., 3.}) { ... }

그러나 다음 (나에게 보인다)이 깨졌습니다.

for (double x : Vector{1., 2., 3.}.normalize()) { ... }

이전 두 가지 사용의 논리적 조합처럼 보이지만이 마지막 사용은 매달린 참조를 생성하고 이전 두 가지 사용은 완전히 괜찮습니다.

• 이것이 정확하고 널리 평가됩니까?
• 위의 "나쁜"부분은 피해야하는 부분입니까?
• for-expression에 구성된 임시가 루프 기간 동안 존재하도록 범위 기반 for 루프의 정의를 변경하여 언어를 개선 할 수 있습니까?

이것이 정확하고 널리 평가됩니까?

예, 사물에 대한 이해가 정확합니다.

위의 "나쁜"부분은 피해야하는 부분입니까?

나쁜 부분은 함수에서 반환 된 임시에 대한 l- 값 참조를 가져 와서 r- 값 참조에 바인딩하는 것입니다. 다음과 같이 나쁩니다.

auto &&t = Vector{1., 2., 3.}.normalize();

임시 Vector{1., 2., 3.}의 수명은 컴파일러가 반환 값이 normalize참조하는 것을 알지 못하기 때문에 연장 할 수 없습니다 .

for-expression에 구성된 임시가 루프 기간 동안 존재하도록 범위 기반 for 루프의 정의를 변경하여 언어를 개선 할 수 있습니까?

그것은 C ++의 작동 방식과 매우 일치하지 않을 것입니다.

일시적으로 연쇄 된 표현을 사용하거나 표현에 대한 다양한 게으른 평가 방법을 사용하는 사람들이 만든 특정 문제를 방지 할 수 있습니까? 예. 그러나 특수한 경우의 컴파일러 코드가 필요하고 다른 표현식 구조 와 작동하지 않는 이유에 대해 혼란 스러울 수도 있습니다 .

훨씬 더 합리적인 해결책은 함수의 반환 값이 항상에 대한 참조임을 컴파일러에 알리는 방법 this이므로 반환 값이 임시 확장 구문에 바인딩 된 경우 올바른 임시를 확장합니다. 그래도 언어 수준의 솔루션입니다.

현재 (컴파일러가 지원하는 경우) 임시로 호출 할 수 없도록 만들 normalize 수 있습니다 .

struct Vector {
  double x, y, z;
  // ...
  Vector &normalize() & {
     double s = 1./sqrt(x*x+y*y+z*z);
     x *= s; y *= s; z *= s;
     return *this;
  }
  Vector &normalize() && = delete;
};

이로 인해 Vector{1., 2., 3.}.normalize()컴파일 오류가 발생하지만 v.normalize()정상적으로 작동합니다. 분명히 다음과 같은 올바른 작업을 수행 할 수 없습니다.

Vector t = Vector{1., 2., 3.}.normalize();

그러나 또한 잘못된 일을 할 수 없습니다.

또는 주석에서 제안한대로 rvalue 참조 버전이 참조가 아닌 값을 반환하도록 만들 수 있습니다.

struct Vector {
  double x, y, z;
  // ...
  Vector &normalize() & {
     double s = 1./sqrt(x*x+y*y+z*z);
     x *= s; y *= s; z *= s;
     return *this;
  }
  Vector normalize() && {
     Vector ret = *this;
     ret.normalize();
     return ret;
  }
};

Vector이동할 실제 자원이있는 유형 이라면 Vector ret = std::move(*this);대신 사용할 수 있습니다 . 명명 된 반환 값 최적화는 성능 측면에서이를 합리적으로 최적화합니다.

for (double x : Vector {1., 2., 3.}. normalize ()) {...}

이는 언어의 제한이 아니라 코드 문제입니다. 표현식 Vector{1., 2., 3.}은 임시를 생성하지만 normalize함수는 lvalue-reference를 반환합니다 . 표현식이 lvalue 이므로 컴파일러는 객체가 살아있을 것이라고 가정하지만 임시에 대한 참조이므로 전체 표현식이 평가 된 후에 객체가 죽으므로 댕글 링 참조가 남습니다.

이제 현재 개체에 대한 참조가 아닌 값으로 새 개체를 반환하도록 디자인을 변경하면 문제가 없으며 코드가 예상대로 작동합니다.

IMHO, 두 번째 예는 이미 결함이 있습니다. 수정 연산자가 반환하는 *this것은 언급 한 방식으로 편리합니다. 수정 자의 연결을 허용합니다. 그것은 수있는 수정의 결과에 단순히 나눠 사용하지만 쉽게 간과 할 수 있기 때문에이 일을하는 것은 오류가 발생하기 쉬운하다. 내가 뭔가를 본다면

Vector v{1., 2., 3.};
auto foo = somefunction1(v, 17);
auto bar = somefunction2(true, v, 2, foo);
auto baz = somefunction3(bar.quun(v), 93.2, v.qwarv(foo));

함수 v가 부작용으로 수정된다고 자동으로 의심하지 않습니다 . 물론 그럴 수도 있지만 혼란 스러울 것입니다. 그래서 제가 이와 같은 것을 작성한다면, 그것이 v일정하게 유지 되도록 할 것 입니다. 예를 들어 무료 기능을 추가합니다.

auto normalized(Vector v) -> Vector {return v.normalize();}
auto negated(Vector v) -> Vector {return v.negate();}

그런 다음 루프를 작성하십시오.

for( double x : negated(normalized(v)) ) { ... }

과

for( double x : normalized(Vector{1., 2., 3}) ) { ... }

그것은 IMO가 더 읽기 쉽고 더 안전합니다. 물론 추가 복사본이 필요하지만 힙 할당 데이터의 경우 저렴한 C ++ 11 이동 작업으로 수행 할 수 있습니다.