곧 나올 LLVM/Clang 3.1에서는 C++11의 기능 중 아래의 것들을 구현한다고 합니다.
[Language Feature]
Initializer lists
Lambda expressions
Declared type of an expression - Incomplete return types
Forward declarations for enums
Generalized constant expressions
Universal character names in literals
User-defined literals
Extending sizeof
Unrestricted unions
[Concurrency]
Atomic operationsx
Strong Compare and Exchange
Bidirectional Fences
Allow atomics use in signal handlers
위 리스트의 기능들이 문제 없이 구현된다면 C++11의 거의 대부분의 기능을 구현하게 되어 남아 있는 것은 Generalized attributes와 Inheriting constructors 정도라고 합니다.
참고 : http://clang.llvm.org/docs/ReleaseNotes.html
Session Topic: Initial Thoughts on Effective C++11 « C++ and Beyond 라는 강연을 근거로 Scott Meyers씨의 새로운 Effective C++ 시리즈를 예상하면 아래와 같다고 합니다.
명시적인 형태 선언보다 auto를 사용하자
오브젝트의 생성에서는 ()와 {}를 구별하자
auto + { expr } == std::initializer_list는
잊지 않도록
(auto x{1};/auto x={1};에서는std::initializer_list<int>형, auto x(1);/auto x=(1);애서는 int형.)
멤버 함수보다 비 멤버 함수 begin/end를 사용하자
std::thread 멤버 선언은 클래스 말미에 두자(멤버 변수 초기화 순서에 기인하는 버그 회피를 위해서)
멤버 함수의 밖에 내는 Lambda 식의 디폴트 캡쳐 모드에 주의(특히 this의 dangling pointer화.)
컨테이너에는 Insertion(삽입) 보다 Emplacement(직접 구축)를 사용하자
비동기 처리가 필수적일 대는 std::launch::async 폴리시를 지정하자
약한 atomic 변수의 이용은 최소한으로(기본 값 std::memory_order_seq_cst 이외의 atomic 변수 접근 최대한 피한다.)
Universal Reference와 Rvalue Reference를 구별하자
move 조작은 존재하는 것도 아니고 낮은 비용이 아닌 것을 기억하자(의도 불명. 「언제라도 낮은 비용으로 move 할 수 있다고 생각하지 말아라」라고 하는 것?)
bind 보다 Lambda 식을 사용하자
스레딩 함수에는 가변 개수 인수보다 Lambda 식을 건네주자
(의도 불명. 아마 std::threadconstructor
인수 이야기.)
오버 서브 스크립션에 조심하자(시스템 병렬 도를 웃도는 스레드를 너무 만들지 않는 것.)
Universal Reference에서 인수를 건네줄 때는 std::forward의 적용을(이른바 “Perfect Forwarding”)
기본 배열보다 std::array를 사용하자
가능한 한 std::make_shared를 사용하자
std::shared_ptr 형태에서는 값 전달 보다 const 참조 전달을 사용하자(→C++의 shared_ptr를 함수로의 인수로서 건네주는 경우는 const 참조로)
인수의 복사가 필요하면 값 전달을 사용하자(복사가 필요하면 함수 호출과 동시에 실시하면 좋다.)
Wide 인터페이스 함수에서는 함부로 noexcept로 하지 않는다(아마→N3248 noexcept Prevents Library Validation)
복사 가능한 형태에서는 무브는 최적화 복사라고 생각하자
열거형(enum) 보다 형태 부착 열거형(enum class)를 사용하자
NULL이나 정수 0 보다 nullptr를 사용하자
std::enable_if, static_assert, =delete를 구별하자
출처 : http://d.hatena.ne.jp/yohhoy/20120418/p1
앞서 소개한 boost::move와 같이 Boost 1.48 버전에서는 C++11의 컨테이너가 추가되었습니다. 그래서 이 컨테이너들을 사용하면 RValue Reference나 Placement Insert 기능이 구현된 것을 사용할 수 있습니다(현재 VC++ 10의 STL 컨테이너들은 Placement Insert는 구현되어 있지 않습니다).
Boost의 컨테이너들은 기본적으로 기존의 STL 컨테이너들과 같으며 다만 C++11의 새로운 기능이 추가되어 있습니다.
기존에는 vector를 사용하기 위해서는
std::vector를 사용했다면 boost용 컨테이너를 사용하기 위해서는
boost::container 라는 이름 공간을 사용하기 때문에
boost::container::vector로 사용합니다.
Placement Insert는 C++11의 기능 중에 하나로 STL 컨테이너와 관계가 있습니다.
struct ITEM
{
ITEM( int nCode )
{
}
};
std::vector< ITEM > Items;
Items.push_back( ITEM( 1 ) );
현재까지는 위 코드처럼 ITEM이라는 객체를 Items 컨테이너에 생성과 동시에 추가를 할 때는 위와 같이해야 합니다. 그런데 위 방식으로 하면 추가를 위해 컨테이너에 한번 생성을 한 후 복사를 해야 하는 문제가 발생합니다(또 임시 객체 만들므로 삭제 비용도 발생하겠죠).
이와 같은 동작은 우리가 원하는 것이 아닙니다.
그래서 C++11에서는 이와 같은 문제를 해결했습니다.
바로 ‘Placement Insert’가 해결했습니다.
C++11의 ‘Placement Insert’를 사용하면 위의 코드는 아래와 같이 할 수 있습니다.
std::vector< ITEM > Items;
Items.emplace_back( 1 );
emplace_back는 push_back과 같지만 Placement Insert 기능이 구현된 것으로 임시 오브젝트를 만들어서 발생하는 비용을 없애줍니다.
C++11의 각 컨테이너에는 Placement Insert와 관련된 멤버로 emplace(insert), emplace_back(push_back), emplace_front(push_front), emplace_hint(insert. 연관 컨테이너 용)가 추가됩니다.
Placement Insert는 C++11의 새로운 기능인 가변 인수 템플릿을 사용하여 구현되었습니다.
그리고 Placement Insert는 주의할 점도 있습니다.
explicit 문제. explicit 생성자도 암묵적으로 호출됩니다.
0 문제. 생성자의 파라미터가 포인터인 경우 인자로 0을 넘기면 int로 추론합니다. 그래서 이 경우에는 nullptr을 사용해야 합니다.
VS2010 팀블로그에서 현재 ‘미리 보는 C++11’과 ‘Direct2D’ 강좌가 연재 되고 있습니다.
‘미리 보는 C++11’은 아직 VC++에서 지원해주지 못하고 있지만 새로운 C++ 표준에 들어가는 기능들을 하나씩 소개하고 있습니다. 컴파일러에서 아직 구현되지 않아서 대부분은 실제 사용해 볼 수가 없지만 새 표준에 들어가는 라이브러리 중 일부는 Boost 라이브러리를 통해서 사용해 볼 수 있습니다.
[미리 보는 C++11] 1. UTF-8, UTF-16(char_16t), UTF-32(char32_t) 문자형
[미리 보는 C++11] 2. override와 final
[미리 보는 C++11] 3. constexpr - 1
[미리 보는 C++11] 4. constexpr - 2
앞으로 새로 등록될 글은 아래에서 볼 수 있습니다
http://vsts2010.net/category/C++0x
‘Direct2D’는 Windows 7에서 새로 생긴 Win32 API로 기존의 GDI를 대체할 수 있는 강력한 것입니다. 이름을 보면 알 수 있듯이 DirectX와 관계가 있습니다. Direct2D를 사용하면 2D 렌더링에 한해서는 어려운 DirectX를 배우지 않고도 DirectX로 할 때의 성능과 효과를 얻을 수 있습니다.
그리고 Direct2D는 Windows 8에서도 데스크탑 환경에서 돌아가는 프로그램을 만들 때는 최적의 선택입니다(C++ + XAML은 WinRT 환경 즉 Metro UI에서만 사용할 수 있습니다)
[StartD2D-3] Direct2D 프로그래밍 시작하기!!!
[StartD2D-4] WIC 를 이용한 이미지 작업하기
[StartD2D-5] Direct2D의 리소스 기본 개념.
[StartD2D-7] 변환의 중심과 확대/축소/찌그러짐
앞으로 새로 등록될 글은 아래에서 볼 수 있습니다
http://vsts2010.net/category/DirectX%2011
Concept이 빠진 이후 Bjarne
Stroustrup와 이것에 대해서 이야기를 한 글을 번역 중이지만 너무 길어서 언제 끝날지 몰라서 간략하게 왜 빠졌는지 간추려봅니다.
Concept이 빠진 이유는 여러가지 있지만 가장 큰 이유는
concept map을 암무적으로 생성할지 안 할지에 대한 것이었음.
어떤 concept에 대해서 대응하는 concept map을 암묵적으로 생성할지, 아니면 만약 concept map이 빈 것이라도 명시적으로 정의를 해야 하느냐의 문제. 즉
어느 타입은 그 concept의 요구를 만족한다는 것을 명시적으로 선언해야만 하느냐에 관한 것이다. 이렇게 하여 시그네쳐의 일치만이 아닌 명확하게 이 타입은 이 concept을
만족하고 있다는 것을 선언 할 수 있다.
하지만 이 방법은 빈 concept map이지만 concept를 만족하기 위해 선언해야만 하므로 귀찮은 일이다.
프랑크프루트 회의에서의 해결책은 기본 concept는 암묵적으로
대응하는 concept map을 생성하고 explicit가
붙어진 경우는 concept map을(만약 빈 것이라도) 명시적으로 선언 해야한다는 것을 제안하였다.
하지만 concept라는 것이 아주 미묘하고, 너무 엄격하고 꽤 어려운 기능이며 concept 코드를 올바르게
쓰는 것도 쉽지 않다. 게다가 프랑크푸르트 회의까지 제대로된 구현도 없었다. Douglas Gregor의 Concept GCC는 꽤 불안전하여
사용할만한 수준이 아니었다.
이런 이유로 표준화 위원회에서도 “이제 됐다’라는 분위가 퍼졌음. 그리고 근본적인 사상의 차이로 표결에 들어갔음. 이미 드래프트에 들어가 있는 Concept를 뺄 것인가 말 것인가…
이 투표에서 Bjarne Stroustrup, Douglas Gregor도
삭제 하는 것에 표를 던졌음.
C++ 표준 회의가 3월 18일 미국 피츠버그에서 개최 되었는데 중요한 것이 결정 되었습니다.
피츠버그 회의에서 Final Committee Draft(FCD)가 결정되어 이제 더 이상의 큰 변경은 없을 것이라고 합니다.
그리고 C++0x는 별 탈이 없으면 2011년에 제정될 것이라고 합니다.
또 표준 작업이 2009년을 넘으면서 C++0x의 x가 0이 아닌 16을 뜻한다는 농담 아닌 농담이 있어서 이름을 C++0x에서 C++11 이라고 부른다고 합니다.
이제 C++0x는 C++11 이라고 부르고, 2011년에는 표준을 끝낸다는 것이 핵심입니다.
출처 : http://herbsutter.wordpress.com/2010/03/13/trip-report-march-2010-iso-c-standards-meeting/
RECENT COMMENT