c++ 11, 14

왼값, 오른값 쉽게 판별법

일반적으로, 주소를 취할수 있다면 ★왼값★

주소를 취할 수 없다면 ★오른값★

class Widget {

public:

Widget(Widget&& rhs); // rhs 의 형식은 오른값 참조이지만, rhs 자체는 왼값이다.

}

auto

1. 템플릿에 대한 형식 연역을 기반으로 작동

template<typename T>

void f(const ParamType& param);

f(expr); // T 표현식으로 f 호출

-> ParamType, param 두가지를 각각 연역한다.

ParamType -> const ParamType& 

param -> int

delete 키워드 적극 사용 권장.

private:

widget(const widget&); // not defined

widget& operator=(const widget&); // not defined

부작용 -> friend 함수에서 widget 객체를 복사하는 시점에 컴파일 실패 (링크시점에 발견됨-빡침)

public:

widget(const widget&) = delete;

widget& operator=(const widget&) = delete;

직관적이다. 바로 컴파일 실패내줌, 깔끔함.

override -> 적극 사용 권장

기반 클래스는 가상 함수여야하고, 기반 함수와 파생 함수 완벽 일치 해야 함.

parent class

virtual void m() &;

child class

virtual m() &&;

안된다. 빌드 에러도 안난다 ㅡㅡ (누가 저렇게 써둔거 발견하면 개빡침)

parent class

virtual void m() &;

child class

virtual m() && override; // 재정의할때는 꼭 override 를 써주자. 빌드 에러라도 보게

또한

parent class

virtual void m() & override; // 상위 클래스에서 override를 해주면, child에서 override를 안했을경우 컴파일러가 지적해줌. 편함

noexcept; 선언

int f(int x) throw();

int f(int x) noexcept;

noexcept 를 적용하면 컴파일러가 더 좋은 object code를 만들 수 있다.

c++98에서는 예외 명세가 위반되면 호출 스택이 f를 호출한 지점에 도달할때까지 풀린다.

c++11은 풀릴수도 있고, 안풀릴수도 있다.

noexcept를 선언하면 컴파일러의 최적화기는 실행시점 스택을 풀기 가능 상태로 유지 할 필요가 없다.

또한 반드시 생성의 반대 순서로 파괴해야 하는것도 아니다.

그러나 throw는 그런 최적화 유연성이 없고, 예외명세가 아예 없는 함수역시 그런 유연성이 없다.

std::lock_guard<std::mutex> g(m); // 이거 좋다 자동 지역

++callcout // 이거도 좋다. // 그러나 하나의 변수 또는 하나의 메모리 장소를 다룰때만 적합.

private:

mutable std::mutex m;

mutable std::atomic<unsigned> callcount{0};

volatile -> 컴파일러 최적화 방지

explicit -> 묵시적변환 금지

mutable -> const 로 선언된 함수 내에서 값 변경 가능.