다른 답변은 “변수의 유형이 무엇인지 실제로 모른다”와 같은 단점을 언급하고 있습니다. 나는 이것이 코드의 조잡한 명명 규칙과 관련이 있다고 말합니다. 인터페이스 이름이 명확 하면 정확한 유형 을 신경 쓸 필요가 없습니다 . 물론, auto result = callSomeFunction(a, b);당신에게 많은 말을하지 않습니다. 그러나 정확한 유형을 신경 쓰지 않고 auto valid = isValid(xmlFile, schema);사용할 수 있다고 충분히 알려줍니다 valid. 결국, 그냥 if (callSomeFunction(a, b))을 사용하면 유형도 알 수 없습니다. 다른 하위 표현식 임시 개체와 동일합니다. 그래서 나는 이것이 실제 단점이라고 생각하지 않습니다 auto.

가장 큰 단점은 때로는 정확한 반환 유형이 작업하려는 것이 아니라는 것입니다. 실제로 실제 반환 유형이 구현 / 최적화 세부 사항으로 “논리적”반환 유형과 다른 경우가 있습니다. 식 템플릿이 대표적인 예입니다. 우리가 이것을 가지고 있다고 가정 해 봅시다.

SomeType operator* (const Matrix &lhs, const Vector &rhs);

논리적으로, 우리는을 기대할 SomeType것이며 Vector, 코드에서 그것을 그대로 취급하고 싶습니다. 그러나 최적화를 위해 우리가 사용하는 대수 라이브러리가 표현식 템플릿을 구현할 수 있으며 실제 반환 유형은 다음과 같습니다.

MultExpression<Matrix, Vector> operator* (const Matrix &lhs, const Vector &rhs);

이제 문제는 즉 MultExpression<Matrix, Vector>모든 가능성 상점 A의 의지 const Matrix&와 const Vector&내부적으로는; Vector전체 표현식이 끝나기 전에 로 변환 될 것으로 예상합니다 . 이 코드가 있다면 모든 것이 잘됩니다.

extern Matrix a, b, c;
extern Vector v;

void compute()
{
  Vector res = a * (b * (c * v));
  // do something with res
}

그러나 auto여기서 사용했다면 문제가 생길 수 있습니다.

void compute()
{
  auto res = a * (b * (c * v));
  // Oops! Now `res` is referring to temporaries (such as (c * v)) which no longer exist
}

답변

map<string,int> usa;
//...init usa
auto city_it = usa.find("New York");

auto output = doSomethingWithData(variables);