새로운 키워드(C++11 ~) 1

auto 키워드

• 자료형 추론

• JavaScript 등의 언어에 있는 동적인 type 과는 다르다. -> 런타임에 결정된다 ;;

• 실제 자료형은 컴파일하는 동안 결정된다. -> 컴파일 타임에 정해진 자료형은 이후 변경되지 않는다!(JavaScript var 와 다른 점)

• 따라서, 반드시 auto 변수를 초기화해야 됨 -> 초기화 하지 않으면 추론할 수 없자나..

• 특별한 케이스를 제외하고는, 명시적인 자료형을 사용하자! -> 반복자 대체하기, 템플릿형 받기

베스트 프렉티스

• 런타임 성능은 동일하다!

• 명시적이어야 한다. -> 전부 가독성과 관련된 것이다!

  • auto 보다 실제 자료형 사용을 권장

  • 예외 : 템플릿 매개변수와 반복자에는 auto 사용

  • auto 보다 auto* 를 사용

  • auto& 보다 const auto& 를 사용

포인터 및 참조 받기

포인터 (가독성 때문에, 포인터의 경우는 auto* 를 사용하자)

• auto 또는 auto*

참조

• auto& -> auto 로 참조도 받을 수 있다면, 컴파일러가 참조와 복사를 구분할 수 없다. -> 때문에, 당연하게 & 를 붙여야 한다!

const 받기, 함수 반환값 저장하기

const

• 컴파일러가 충분히 추론 가능하기에 가능하다.

• 하지만, 아래의 코드에서는 한눈에 const 인지 판단하기가 어렵다. auto& name = object.GetName();

• 가능하더라도 가독성을 위해서 다음과 같이 const auto& 를 사용하자. const auto& name = object.GetName();

함수 반환값

• 가능은 하지만, 가독성이 너무 떨어진다 ;;

• 아직 auto 관해 모두가 동의하는 코딩 표준이 없다.

반복자 대체하기, 템플릿형 받기

반복자

• 너무나 긴 자료형을 명시적으로 적어주어야 하는 경우에는, auto 를 사용하자.

• 대부분 STL 컨테이너를 반복하는 경우 자료형이 복잡하다.

템플릿

• 오른쪽에서 타입을 예상 가능하기 때문에, 가독성 측면에서 크게 영향을 끼치지 않는다.

static_assert

assert

• 실행 중에 가정(assertion)이 맞는 지 평가

• 오직 디버그 빌드에서만 작동 -> 릴리즈 빌드에서는 assert 는 사라져 프로그래밍 성능에는 전혀 영향을 끼치지 않는 좋은 기능

• 실패한 assert 를 보려면 반드시 프로그램을 실행해야 하는데, 거기에 다음 두가지 문제가 있다.

  • 모든 코드 경로가 실행되지 않을수도 있다. -> assert 가 들어있는 메서드를 호출하지 않을 수도 있다.

  • 일부 assert 은 프로그램을 실행하기도 전에 알 수 있다. (컴파일 에러) -> 컴파일 에러를 통해 확인 할 수 있는 내용도 assert 에서 확인을 위해서 프로그램을 돌린다? (이는 컴파일 에러를 만들기 위한 노력을 물거품으로 만든다)

• 모든 곳에 assert 를 쓰자는 조언은 여전히 유효하다.

static_assert

• 컴파일 중에 가정(assertion) 이 맞는지 평가 -> 컴파일러가 assert 조건이 참인지 아닌지 안다.

• 실패하면 컴파일러는 컴파일 에러를 뱉는다. -> 컴파일 에러를 도출하기 위한 노력 중 하나

• 많은 경우에 유용하다!

예제 1 : 구조체의 크기

예제 2 : version 확인하기

예제 3 : 배열의 길이

베스트 프랙티스

• 최대한 assert 보다 static_assert 를 사용하자!

  • 첫째, "모든 곳에 static_assert 를 쓰자"

  • 그리고 나서, "남은 곳에 assert 를 쓰자"

• assert 를 사용한다면,,

  • 여전히 프로그램을 실행시켜야만 한다.

  • 실행 도중에만 가정(assertion) 을 포작, 그것도 오직 디버그 빌드에서만,,,

• static_assert 를 사용한다면!

  • 컴파일 중에 모든 문제를 즉시 알아챈다.

  • 또한 컴파일러처럼 생각하는데 도움이 된다. -> 컴퓨터를 이해하는데 매우 큰 영향을 끼친다.