vector :: at 대 vector :: operator []

C ++ Vector at / [] operator speed 또는 :: std :: vector :: at () vs operator [] << 와 같은 유사한 질문에서도 논의되는 경계 검사로 인해 at()속도가 느리다는 것을 알고 []있습니다 . 5 ~ 10 배 더 느리게 / 빠르게! . 나는 그 방법이 무엇에 좋은지 이해하지 못합니다 .at()

이와 같은 간단한 벡터가있는 경우 : 인덱스가있는 상황에서 대신 std::vector<int> v(10);사용하여 해당 요소에 액세스하기로 결정하고 벡터 내 경계가 있는지 확실하지 않으면 try-catch 로 래핑해야합니다. 블록 :at()[]i

try
{
    v.at(i) = 2;
}
catch (std::out_of_range& oor)
{
    ...
}

size()색인을 직접 사용 하고 확인 하여 동일한 동작을 수행 할 수 있지만 이는 나에게 더 쉽고 편리해 보입니다.

if (i < v.size())
    v[i] = 2;

그래서 내 질문은 : vector :: operator [] 보다 vector :: at
사용의 장점은 무엇입니까 ? vector :: size 대신 vector :: at를
사용해야 하는 경우 + vector :: operator [] 합니까?

vector::at()던지는 예외 는 바로 주변 코드에 의해 잡히도록 의도 된 것이 아닙니다. 주로 코드에서 버그를 잡는 데 유용합니다. 예를 들어 인덱스가 사용자 입력에서 나오기 때문에 런타임에 경계 검사가 필요한 경우 실제로 if명령문을 사용하는 것이 가장 좋습니다 . 요약하면, vector::at()예외를 던지지 않을 의도로 코드를 디자인하십시오. 그러면 예외가 발생하고 프로그램이 중단되면 버그의 신호입니다. (처럼 assert())

그것은 나를 try-catch 블록으로 감싸도록 강요합니다.

아니요 (try / catch 블록은 업스트림 일 수 있음). 프로그램이 정의되지 않은 동작 영역에 들어가는 대신 예외가 발생하기를 원할 때 유용합니다.

벡터에 대한 대부분의 경계를 벗어난 액세스는 프로그래머의 실수라는 데 동의합니다 (이 경우 assert이러한 실수를 더 쉽게 찾을 수 있도록 사용해야 합니다. 대부분의 표준 라이브러리 디버그 버전은 자동으로 수행합니다). 프로그래머 실수를보고하기 위해 업스트림으로 삼킬 수있는 예외를 사용하고 싶지 않습니다 . 버그 를 수정할 수 있기를 원합니다 .

벡터에 대한 경계를 벗어난 액세스가 정상적인 프로그램 흐름의 일부일 가능성이 낮기 때문에 (그렇다면 당신이 옳습니다 : size예외가 발생하도록하는 대신 미리 확인하십시오 ), 귀하의 진단에 동의합니다. at본질적으로 쓸모가 없습니다.

vector :: operator []보다 vector :: at를 사용하면 어떤 이점이 있습니까? vector :: size + vector :: operator [] 대신 vector :: at를 언제 사용해야합니까?

여기서 중요한 점은 예외를 사용하면 오류 처리 논리에서 코드의 정상적인 흐름을 분리 할 수 ​​있으며 단일 catch 블록은 함수 호출 내에 흩어져 있어도 무수한 throw 사이트에서 생성 된 문제를 처리 할 수 ​​있다는 것입니다. 따라서 at()한 번만 사용 하는 것이 반드시 더 쉬운 것은 아니지만 유효성을 검사 할 인덱싱이 많을 때 때때로 더 쉬워지고 일반 사례 논리의 난독 화가 줄어 듭니다.

또한 일부 코드 유형에서는 인덱스가 복잡한 방식으로 증가하고 배열을 찾는 데 계속 사용된다는 점도 주목할 만합니다. 이러한 경우 at().

실제 예로서 C ++를 어휘 요소로 토큰 화하는 코드와 토큰 벡터 위로 인덱스를 이동하는 다른 코드가 있습니다. 발생한 사항에 따라 다음과 같이 다음 요소를 증분하고 확인할 수 있습니다.

if (token.at(i) == Token::Keyword_Enum)
{
    ASSERT_EQ(tokens.at(++i), Token::Idn);
    if (tokens.at(++i) == Left_Brace)
        ...
    or whatever

이런 상황 에서 입력의 끝에 부적절하게 도달 했는지 여부를 확인하는 것은 매우 어렵 습니다. 이는 발생하는 정확한 토큰에 매우 의존하기 때문입니다. 각 사용 지점에서의 명시 적 검사는 고통스럽고 사전 / 사후 증분, 사용 지점에서의 오프셋, 일부 이전 테스트의 지속적인 유효성에 대한 잘못된 추론 등으로 인해 프로그래머 오류가 발생할 여지가 훨씬 더 많습니다.

at 벡터에 대한 포인터가 있으면 더 명확해질 수 있습니다.

return pVector->at(n);
return (*pVector)[n];
return pVector->operator[](n);

성능을 제외하고 첫 번째는 더 간단하고 명확한 코드입니다.

첫째, 여부 at()또는 operator[]느리게 지정되지 않습니다. 경계 오류가 없으면 적어도 디버깅 빌드에서 거의 같은 속도 일 것으로 예상합니다. 차이점은 at()경계 오류 (예외)가있을 때 발생할 일을 정확히 지정 한다는 것입니다. 여기서의 경우와 같이 operator[]정의되지 않은 동작입니다. 최소한 사용하는 모든 시스템 (g ++ 및 VC ++)에서 충돌이 발생합니다. 일반 디버깅 플래그가 사용됩니다. (또 다른 차이점은 일단 내 코드를 확신 operator[] 하면 디버깅을 해제 하여 상당한 속도 향상을 얻을 수 있다는 것입니다. 성능에 필요한 경우 — 필요하지 않으면 수행하지 않을 것입니다.)

실제로 at()는 거의 적합하지 않습니다. 만약 인덱스가 유효하지 않다는 것을 알고있는 컨텍스트라면, 아마도 명시적인 테스트를 원할 것입니다 (예를 들어, 기본값이나 무언가를 반환하는 것). 그리고 그것이 유효하지 않다는 것을 알고 있다면 중단하고 싶을 것입니다. 유효하지 않은지 여부를 알지 못하므로 함수의 인터페이스를 더 정확하게 지정하는 것이 좋습니다.) 그러나 몇 가지 예외가 있습니다. 여기서 잘못된 인덱스는 사용자 데이터 구문 분석으로 인해 발생할 수 있으며 오류로 인해 전체 요청이 중단되지만 서버가 중단되지는 않습니다. 이러한 경우 예외가 적절 at()하며 귀하를 위해 그렇게 할 것입니다.

예외 사용의 요점은 오류 처리 코드가 더 멀리 떨어져있을 수 있다는 것입니다.

이 특정 경우에 사용자 입력은 실제로 좋은 예입니다. 인덱스를 사용하여 .NET Framework에 내부적으로 저장하는 일종의 리소스를 참조하는 XML 데이터 구조를 의미 론적으로 분석한다고 가정 해보십시오 std::vector. 이제 XML 트리는 트리이므로 재귀를 사용하여 분석 할 수 있습니다. 재귀에서 XML 파일 작성자의 액세스 위반이있을 수 있습니다. 이 경우 일반적으로 모든 수준의 재귀에서 벗어나 전체 파일 (또는 모든 종류의 "거친"구조)을 거부하려고합니다. 이것이 편리합니다. 파일이 유효한 것처럼 분석 코드를 작성할 수 있습니다. 라이브러리 코드는 오류 감지를 처리하고 대략적인 수준에서 오류를 포착 할 수 있습니다.

또한,와 같은 다른 컨테이너 std::map도 : at std::map::at과 약간 다른 의미를 가지고 있습니다 std::map::operator[]. const 맵에서 operator[]사용할 수 있지만 할 수 없습니다. 이제 당신도 다룰 수있는 일처럼 쓰기 컨테이너 무관 코드를 원하는 경우 const std::vector<T>&또는 const std::map<std::size_t, T>&, ContainerType::at선택의 무기가 될 것입니다.

그러나 이러한 모든 경우는 일반적으로 일종의 검증되지 않은 데이터 입력을 처리 할 때 나타납니다. 당신이 당신의 유효한 범위에 대해 확신하는 경우 일반적으로해야로서, 일반적으로 사용할 수 operator[]있지만, 더 나은 아직,와 반복자 begin()와 end().

이 기사 에 따르면 성능은 제쳐두고 액세스가 벡터의 크기 내에서 보장되는 경우에만 at또는 을 사용하는 데 아무런 차이가 없습니다 operator[]. 그렇지 않으면 액세스가 벡터의 용량을 기반으로하는 경우 사용하는 것이 더 안전합니다 at.

참고 : 일부 새로운 사람들은 무엇이 잘못되었는지 예의없이이 답변에 반대하는 것으로 보입니다. 아래 답변은 정확하며 여기에서 확인할 수 있습니다 .

실제로 한 가지 차이점이 있습니다. at경계를 확인하는 반면 operator[]그렇지 않은 경우입니다. 이것은 디버그 빌드와 릴리스 빌드에 적용되며 표준에 의해 매우 잘 지정됩니다. 그렇게 간단합니다.

이것은 at더 느린 방법을 만들지 만 사용하지 않는 것은 정말 나쁜 조언 at입니다. 상대 숫자가 아닌 절대 숫자를 봐야합니다. 대부분의 코드가 at. 개인적으로 나는 at정의되지 않은 동작을 생성하고 프로덕션에 몰래 들어가는 불쾌한 버그를 원하지 않기 때문에 사용하려고합니다 .