Jongbin Oh

I write something to think

1 minute read

발표자는 Stephan T. Lavavej. 줄이면 STL. 운명을 받아들여 MS에서 STL을 구현 중이다. tuple에 관한 건 다 훑어본다. C++11, C++14, C++17. 처음 보는 함수도 있었음.

nil

ㅋㅋㅋ 발음. 양인도 발음으로 고통받으니 위안이 된다.

nil

비교 구현에 사용할 수 있다. 각 element를 순서대로 비교하기 때문. 편해서인지 자주 보인다. make_tuple() 함수로 만들어서 비교해도 되는데, 왜 tie()를 사용하냐면 references를 인자로 취하기 때문.

nil

piecewise_construct 태그를 사용하면 pair 객체를 생성할 때, 각 생성자에 tuple을 넘기는 게 아니라 tuple의 element로 분해해서 인자로 넘긴다. pair를 멤버 변수로 가지고 있는 map에서도 활용할 수 있다. 이런 게 있는지 처음 알았다.

nil

vector<tuple<T&>> 객체는 생각만 해도 겁난다. 아직 컴파일러 에러 낼 방법은 없는 모양.

nil

난 다른 이유가 있는 줄 알았다. 통일성? 하지만 진짜 이유는 t.template get<0>() 때문이었다.

nil

다음은 C++14에 추가된 것.

nil

기다렸다. 인덱스가 아닌 타입으로 get<Type>() 함수 호출이 가능하면 더 명확하게 짤 수 있는 곳이 있다.

nil

nil

integer_sequence 클래스가 있으면 재귀로 돌면서 pack하고 unpack 하는 코드를 직접 짤 필요 없어 보인다. 이거 편하겠네. parameter pack 다루기가 훨씬 쉬워질 것 같다.

nil

이제 C++17.

nil

conditionally explicit으로 변경돼서 좀 더 편해졌다. 큰 위험은 쳐내고 편하게 쓰자는 의도가 보인다.

nil

nil

그래 저건 string, int로 해석하는 게 맞다. string, vector로도 인자를 받을 수 있으면 더 혼란스러울 듯. 저런 걸 막으려고 편한 것들을 다 포기하지 않고 conditional explicit을 제안한 건 아주 좋음. 이거 나중에 proposal 찾아봐야지.

nil

nil

타입 간에 is_convertible<> 인지 검사해서 explicit을 추가한다. 위 예에서 int 와 vector<int> 같은 경우엔 is_convertible<> 이 아니므로 explicit 생성자만 허용한다. 안전하게 하려면 explicit이지. 이런 문제가 발생할 수 있거든. 이렇게 안일하게만 생각한 내게 반성을. 그래 편하면서도 위험한 것만 막아버리면 모두 행복해진다.

nil

페이지 번호를 기억했다가 질문할 때, 페이지 번호를 말해라. 발표 스킬 좋다. 이거 없으면 “아 좀 더 앞 페이지요. 방금 지나갔어요. 네 그 페이지요. 거기서요…” 이런 사태가 벌어진다.

링크

You May Also Enjoy