11월 초에 C++0x와 관련된 회의가 있었습니다. 관련된 이야기를 정리한 글이 있어서 한글로 정리해봅니다.

 

클래스 멤버의 기능에 대한 attribute가 키워드로

언어의 기능은 특별한 문법을 주는 것이 적합하다는 사상에서 나왔다.

 

struct Base

{

   virtual void f() { }

   int x ;

} ;

 

struct Derived final explicit : Base

{

   virtual void f() override { }

   int x new ;

} ;

 

위 코드는 기능적으로 attribute에서 제공하던 것과 같다. 다만 base_check 대신에 explicit를 사용하고, hiding 대신에 new를 사용하는 것으로 바뀌었다.

C++0x에서 멤버 선언에 initializer를 기술할 수 있으므로 다음과 같이 된다.

struct Derived final explicit : Base

{

   virtual void f() override { }

   int x new = 0;

} ;

 

참고로 위에서 사용한 키워드 new는 진짜 키워드가 아니다. 문맥의존 키워드(contextual keyword)라고 부르는 것이다. 즉 어떤 장소에서만 키워드로서 취급되는 것이다. 이것에 의해 final, override라는 identifier를 사용할 수 있다. 이것은 하위 호환성을 위한 배치이다. 이 키워드들이 사용하는 경우는 식별자를 쓸 수 없는 경우이므로 구현이 가능하고 contextual keywork는 이미 C#에서 사용된 적이 있다.

 

 

 

암묵적인 복사 생성자 문제

표준 위원회 멤버 중 David Abrahams는 암묵적인 move는 심각한 호환성 문제가 생기므로 만들지 않아야 한다고 주장했는데 Bjarne Stroustrup은 암묵적 복사에서도 문제는 같다고 주장해서 격전이 벌어졌지만 결과적으로는 Bjarne가 이겼다.

그래서

 

암묵적 복사 생성자는 유저 정의 소멸자가 있는 경우 생성된다. 이것은 deprecated이다,

 

struct X

{

    ~X() { } // 유저 정의 소멸자

} ;

 

int main()

{

    X a ;

    X b = a ; // 경고! deprecated!

}

 

구조체 X는 소멸자를 정의했기 때문에 암묵적으로 복사 생성자가 만들어진다. 그런데 복사 생성자를 명시적으로 정의하지 않았기 때문에 이것은 deprecated이다. deprecated라는 것은 장래에는 규격에서 삭제될 수도 있다라는 것이다. 위의 코드는 아래와 같이 하는 것이 좋다.

 

struct X

{

    X( X const & ) = default ; // 명시적인 default

    ~X() { } // 유저 정의 소멸자

} ;

 

int main()

{

    X a ; X b ;

    a = b ; // 올바른 코드

}

 

 

이번 회의에서는 또 유저 정의 move 생성자, move 대입 연사자가 있는 경우에도 암묵적인 복사 생성자가 만들어진다고 정했다. 하지만 앞서 이야기 했듯이 이것은 deprecated이므로 올바른 C++ 프로그래머라면 암묵적인 복사 생성자가 만들지 않도록 해야 한다.

 



 

참고 : http://cpplover.blogspot.com/2010/11/c0x.html

 

 

저작자 표시
신고
by 흥배 2010.12.07 09:00

C++0x 작업은 현재도 진행 중입니다. Rapperswill 회의에서 공개된 드래프트 내용입니다.

 

최신 드래프트는 N3126입니다. 하지만 이 드래프트에는 Rapperswill 회의에서 변경하기로 한 것을 다 포함하지 않고 있다고 합니다. 이유는 세세한 부분을 고민 중이라고 합니다.

 

 

N3103: Security impact of noexcept

단순한 예시를 위한 페이퍼. noexcept라고 선언 함수가 예외를 밖으로 던졌을 경우 즉시 terminate해야 한다. 이 룰을 지켜지지 않는 경우 어느 실행 환경에서는 보안 상의 문제를 일으킨다. 따라서 반드시 terminate되도록 구현해야 한다.

 

 

N3106

min/max/minmax에 있어서의 문면의 변경 실수의 수정.

 

 

N3108

std::basic_string의 최적화 수법으로서 현재 주류의 small-string optimization이라는 것이 있다.

대충 아래의 코드와 같다. 이미 VC++에서는 구현되어 있다

 

// char의 문자열을 저장하는 클래스

class String

{

    char * ptr ;

size_t size ;

 

    // 문자열 길이가 충분히 작은 경우 동적 할당을 하지 않고 이것을 사용

    char small_string_buffer[8] ;

} ;

 

std::string에 저장하는 문자열이 짧은 문자열 이라는 것은 자주 있는 케이스이다. 이런 경우 특별히 small_string_buffer를 사용하면 일부러 동적으로 메모리를 확보할 필요가 없어진다.

std::basic_string는 컨테이너의 요건을 충족하고 있다. 그런데 새로운 swap의 정의를 충족하려고 하면 이 small-string optimization를 사용할 수 없게 된다. 이 때문에 std::basic_string에 한계, swap 후의 이터레이터가 무효가 된다고 하는 조건을 덧붙여 이러한 최적화를 할 수 있도록 하는 제안.

 

 

N3109: US 108

C++0xrvalue 레퍼런스를 추가한 목적은 rvalue에 대한 Move semantics 때문이다. auto_ptr과 같은 lvalue에 대한 Move sematnics를 제공하는 라이브러리는 deprecated 이다. 그 때문에unique_ptr의 생성자는 rvalueauto_ptr만을 인수에 취하도록 한다. lvalueauto_ptr를 인수로 있는 생성자는 삭제한다.

 

 

N3112: Proposed Resolution for CH 15

Pittsburgh 회의에서 Move 생성자와 Move 대입 연산자의 의미를 바꾸었지만 그 변경이 라이브러리의 기존의 문장에 영향을 미치고 있다. 그에 대한 수정.

 

 

N3113: Async Launch Policies (CH36)

asynclaunch에는 세 개의 옵션이 있다. Async, sync, any 이다. anyasync이면서도 sync도 아닌 구현 의존의 방법이라는 것이 되지만 이렇게 애매모호한 정의로는 벤더는 온전히 의미가 있는 구현을 제공할 수 없고, 또한 유저는 포터블한 코드를 쓸 수 없다. 그 때문에 이것을 구현 의존의 식별자로 한다.

, sync라는 이름은 오해를 부르기 쉽기 때문에 deferred라고 개명하는 것을 제안.

 

 

N3114 - throw() becomes noexcept

타이틀 대로 라이브러리의 throw()noexcept로 변경하는 제안.

 

 

N3122: Observers for the three handler functions

C++0x에는 multi-thread라고 하는 개념이 들어간다. 그렇게 되면 당연 나오는 문제는 데이터 경합(data race)이다. 이 때문에 operator newoperator delete, C 라이브러리의calloc/malloc/realloc/free은 데이터 경합을 일으켜서는 안 된다고 규정되었다.

 

이 제약은 유저에 의한 operator newoperator delete overload 시에도 당연 지키지 않으면 안 된다. 그러나 set_new_handler는 값을 변경하면서 앞의 값을 얻는다고 하는 사양이다. 그렇다면 set_new_handler의 사양에는 어떠한 배타적 처리를 강구하지 않으면 안 되지만 유저 코드와 라이브러리 코드와의 사이로의 공통의 배타적 처리라고 하는 것은 무리다. 그렇다면 유저 코드의operator new 중에서 set_new_handler가 사용할 수 없는 것은 아닌가?

이 문제에 대처하기 위해 new handlerget 하기 위한 라이브러리가 추가 되었다. get_new_handler() 이다. 오히려 지금까지 없는 것이 이상했던 것. 한층 더 get_unexpected()get_terminate()도 추가 되었다.

 

set_unexpected()set_terminate()nullpointer를 사수는 안 된다고 하는 룰을 완화하기로 했다. 그러나 이것은 set_unexpected()set_terminate()nullpointer를 지정한다고 하는 코드의 거동을 미 규정(undefined는 아니고 unspecified)으로 해버릴 수 도 있다

 

 

N3123: Bringing result_of near to INVOKE

result_of의 문면을 INVOKE를 사용하여 기술하도록 했다.

 

 

N3124: C and C++ Alignment Compatibility

Alignment 지정 문법을 attribute로부터 specifier으로 옮기는 제안. 이것에 의해 alignas라고 하는 키워드가 도입. 이것은 specifier이다. 아래와 같이 기술할 예정.

alignas(16) char buffer[128] ;

 

 

N3125: Omnibus Memory Model and Atomics Paper

현재의 기획의 문면에 있어서의 메모리 모델과 동기 처리의 문제점을 ML 상에서 논의하고 있었다. 그 정리.

 

 

N3128: C++ Timeout Specification

스레드의 스케줄링 등의 지연을 quality of implementation라고 부른다. 또 프로세서나 메모리의 코스트를 쓸데 없이 올리지 않기 위한 지연을 quality of management라고 부른다. 그렇다면현실의 환경에 있어서의 타임 아웃의 실시간이라는 것은 목적의 시간 + quality of implementation + quality of management로 나타내질 것이다. 규격에서도 이 개념을 도입한 문면에 바꾸어 넣는다.

 

 

N3129: Managing C++ Associated Asynchronous State

Associated Asynchronous State 주위의 문면을 이해하기 어렵기 때문에 새로운 용어를 정의하고 그 용어를 이용하여 문면을 고쳐 쓰는 제안.

 

 

N3130: Lockable Requirements for C++0x

문면의 섬세한 수정.

 

 

N3131: Compile-time rational arithmetic and overflow

Compile-time rational arithmetic이 결과는 표현할 수 있다고 해도 계산 과정에서 오버플로우를 일으키는 경우는 어떻게 하면 좋을까?. 예를 들어  ratio_multiply<ratio<INTMAX_MAX,2>, ratio<2,INTMAX_MAX>>는 최종적으로 ratio<1,1>라고 계산된다. 그러나 그 계산 과정에서 오버플로우를 일으킨다. 제안은 최종적인 결과가 표현 가능하면 합법이다. 구현은 다른 알고리즘을 사용하는 것에 의해서 오버플로우를 회피하는 것이 추천.

 

 

N3132: Mathematizing C++ Concurrency: The Post-Rapperswil Model

내용은 FCD에서 합의되었던 C++의 메모리 모델을 수학적으로 기술하여 한층 더 영어에 의한 대역을 붙인 .

 

 

N3136: Coherence Requirements Detailed

Coherence Requirements의 추가。

 

 

C and C++ Liaison: Compatibility for Atomics

C 언어와 C++ 사이의 atomic의 호환성의 비교.

 

 

 

출처:

(영어) http://j2k.naver.com/j2k_frame.php/korean/www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/#mailing2010-08

(일본어) http://cpplover.blogspot.com/2010/08/post-rapperswil-mailing.html

 

 

저작자 표시
신고
by 흥배 2010.09.14 08:00

Danny Kalev

장래에 대해서는 어떻게 생각합니까? 지금부터 어떻게 됩니까? Technical Report 같은 느낌으로Concept를 나중에 추가하는 것입니까? 혹은 완전 초보나 아직도 깨달음을 얻지 않은 우둔한 코더라도 사용할 수 있는 완전히 새로운 규격을 넣는 날이 오는 것입니까? concept의 폐지는 현행 드래프트에 한층 더 큰 영향을 주는 것입니까?

 

Bjarne stroustrup

어휴, 편견이 심한 유도 심문 같은 질문이네요

 

가장 먼저 C++0x는 이미 합의된 개량을 모두 도입하여 제정되었어요. 예를 들어 concurrency의 지원, 표준 라이브러리의 개량과 확장, 통일적인 초기화, lambda, move semantics, 범용적인 정수 표현 등등. 제가 썼던 C++0x FAQ를 읽어보세요. 이미 이 단계에서는 대규모 변경은 들어가지 않아요. C++0x에는 중요한 개량이 많이 있어요. 몇 개인가는 이미 GCCMicrosoft 등이 구현하고 있어요. 새로운 언어와 같다고 느낄 것이에요.

 

2번째로 C++은 모든 유행을 쫓는 일은 하지 않아요. 실용을 위해 천천히 호환성을 생각하면서 진화해 나가요. 최첨단 기능이 가득한 언어라든지 극단적으로 작은 언어라든지 독자 기능이 가득한 언어라고 하는 오징어 한 언어를 갖고 싶다면 그 외에 얼마든지 있을 것이요. 다만 만약 이 앞 몇 십년 이라도 사용하는 프로그램을 위해 충분히 유연하고 보다 성능이 좋은 그 외 예를 볼 수 없을 정도 범용적이고 어떤 하드웨어에도 움직이는 언어를 갖고 싶으면 C++로 하세요.

 

3번째로 많은 사람이 어떠한 방법으로 C++에 있어서의 Concept의 좋은 점과 올바른 이용 방법을 찾아낼 것이에요. 「나중에 추가」하는 것은 아무도 생각하고 있지 않아요. C++의 표준화는 그처럼 되지 않아요. 프랑크푸르트 이전의 Concept 규격에 "simplifying the use of concepts" 제안으로 개량을 더하면 개인적으로는 만족이 가는 것이 수개월에 완성될 것이에요. 하지만 그런 일은 없을거에요. concept을 기본으로부터 다시 생각히여 지금까지 얻을 수 있던 경험을 바탕으로 한다고 해도 거의 스크래치로부터 규격을 고쳐 써고 실험할 것이에요. 5년 단위의 시간이 걸릴 것이겠죠. 무엇보다 concept은 다른 아이디어에 이길 정도의 이점을 나타내지 않으면 되지 않아요. 만약 리플렉션이 우수하다면 대신에 그쪽에 주력 할 것이에요.

conceptTR(Technical Report)에 향하고 있다고는 생각되지 않아요. 형태 시스템에 깊게 관련되고 있기 때문에 TR라고 하는 것은 그것 없이도 해 나갈 수 있는 만큼 분리할 수 있는 것에 대해서 실시해요. 형태 시스템은 완전하게 완수할지 아무것도 하지 않을 지의 양자택일이에요.

 

 

 

Danny Kalev

그러면 C++에 관해서는 낙관적인 견해를 하고 있군요.

 

Bjarne stroustrup

저는 옛날도 지금도 주의 깊고 낙관적으로 생각하고 있어요. 저는 「 나의 언어, , 설계 사상을 가지고 있으면 너희들의 별볼일 없는 문제 전부 해결해 줄 수 있어! 내일이라도 세계를 정복해 주지! 후하하하하!」등의 낙관적인 견해는 있지 않아요. 저시는 C++이 「단지 단지」 몇 백 만명의 프로그래머를 지원할 수 있고 많은 환경에 소프트웨어의 개발 환경을 제공하여 고도의 어플리케이션 개발에 사용된다고 하는 것만으로 충분히 만족해요. 「소프트웨어의 환경」이라고 하는 것은 임베디드계이거나 시스템 개발이거나 자원의 제약이 어려운 환경이거나 C++에 최적인 분야의 것이에요. C++0xC++98보다 보다 좋은 툴이 될 것이에요.

 

지금으로서는 위원회는 C++0x를 아담하게 포장하고 출하하지 않으면 않되요. x16진수가 되지만. 그리고 구현이 다 모일 것이에요. 몇 개의 기능이나 라이브러리는 이미 나돌고 있어요. 거기서 프로그래머는 위원회의 다대한 작업의 혜택을 얻을 수 있다는 것이에요.

 


< 끝 >


Bjarne Stroustrup Concept와 미래를 말하다 - 1  http://jacking.tistory.com/443

Bjarne Stroustrup Concept와 미래를 말하다 - 2  http://jacking.tistory.com/467

Bjarne Stroustrup Concept와 미래를 말하다 - 3  http://jacking.tistory.com/474

Bjarne Stroustrup Concept와 미래를 말하다 – 4 http://jacking.tistory.com/559

Bjarne Stroustrup Concept와 미래를 말하다 – 5  http://jacking.tistory.com/652

Bjarne Stroustrup Concept와 미래를 말하다 – 6  http://jacking.tistory.com/678

Bjarne Stroustrup Concept와 미래를 말하다 – 7  http://jacking.tistory.com/679

Bjarne Stroustrup Concept와 미래를 말하다 – 8  http://jacking.tistory.com/686

Bjarne Stroustrup Concept와 미래를 말하다 – 9  http://jacking.tistory.com/695

 

저작자 표시
신고
by 흥배 2010.07.21 08:30

Danny Kalev

흥미롭네요. C++98template의 컴파일 방법으로서 현실적으로 사용되고 있는 inclusion 모델과 exportDouglas Gregor가 텍사스와 인디애나라고 말하는 같고, 두 개의 사상을 하나의 제안에 정리하려고 한 결과입니까? 아무래도 그런 식으로 동일 시 하는 것은 잘 되지 않을 것 같네요.

 

 

Bjarne stroustrup

그래요. export의 실패는 templateinclusion 모델) separate compilation 모델을 하나로 정리하려고 한 것입니다. 다만 당신이나 모두에게 알려 주고 싶은 것은 당시 어느 쪽의 방법도 실제로 사용되고 있었던 것입니다. 표준의 방법이 아무래도 필요했고 어느 쪽의 모델도 강하게 지지를 받고 있었습니다. 그러한 이유로 절충안은 만들기 힘들었습니다. 이쪽을 세우면 저쪽이 서지 않으니까요.


반성해 보면 양쪽 모두의 모델을 절대로 지원할 필요가 없었기 때문에 벤더는 inclusion 모델만을 구현했을 것입니다. EDGexport를 구현하고 있습니다. 하지만 모든 주요한 벤더가 다 할 때까지 는 아무리 귀찮아도 사용하고 싶어하지 않는 것 같습니다. 당시의 저는 그런 것은 고려하고 있지 않았으며 위원회가 실패했던 것도 명확한 사용 구분을 생각하지 않았던 것이라고 생각합니다. 위원회를 꾸짖기 전에 조금 더 생각해 주세요. 「지금 현재 문제가 있다」라는 거소가 「장래 문제가 될지 모른다」 어느 쪽을 선택하는가 라는 것은 개인으로서는 매우 어려운 일이에요. 머리가 좋은 사람끼리 생각해도 어렵습니다.

 

concept 제안의 근본적인 차이를 분별하는 것은 매우 어려운 일입니다. 이 문제를 깨닫고 있지 않는 사람마저 있어요. 어려운 것은 「도대체 무엇이 근본적인 차이인가?」라고 하는 것입니다. 당연 논의의 상당수는 concept map이었습니다. 이미 나타난 것처럼 concept mapmapping을 위해서 필요한 기능입니다. 그 자체가 훌륭하다고 생각하는 사람도 있었습니다. 비록 비어서 무슨 형이나 조작도 정의하지 않는다고 하더라도 말이죠. 프랑크푸르트 이전의 concept의 규격 설계에서는 빈 concept map을 요구하는 concept과(explicit concept, mapping이 필요하지 않은 한 concept map을 필요로 하지 않는 conceptautomatic concept)이 있었습니다. "simplifying the use of concepts" 페이퍼로의 논점은 concept map은 애매성의 해결에 적절하지 않다는 것입니다. 이것이 당신의 질문에 대한 답입니다. concept map의 올바른 사용법에 관한 논의의 결론은 표준화 위원회에 의한 언어 사양에 반영 되는 것이 당연하고 concept와의 순조로운 해결의 방법이 제공되어야 한다는 것입니다. 다른 안은 다른 사상의 코드를 동일시로 하는 것으로 쓰기의 좋은 것은 아니었습니다. 거기서 올바른 사용법이라고 하는 것에 관련해서 격렬한 논의가 있었습니다.

 

 

 

Danny Kalev

C++유저는 적당히 하라고 생각하고 있는 것은 아닐까요? 논의가 좋은 예인 것 같습니다. concept만이 아니었죠. 가베지컬렉션이든가 리플렉션이라든지 GUI라고 하는 매우 갖고 싶은 기능이 C++에는 절대 들어갈 것 같지 않지요. 거기에 비하면 실험적으로 난해한 기능만 논의되고 있고. 이 코멘트에 있듯이 이제 C++라는 것은 끝난 것일까요? 언어 자체가 너무 복잡하여 더 이상 온전하게 개량 할 수 없게 되고 있는 것은 아닐까요?

 

 

Bjarne stroustrup

그 「매우 갖고 싶은 기능」이라는 것들이 이론이 많은 것이 문제예요. 단지 고함치듯이 주장만 하고 온전하게 논의를 하지 못했어요. 저는 개인적으로 GC를 좋아하고 C++0x에는 GC ABI도 들어갑니다. 단지 유감스럽지만 표준 GUI 따위는 무리입니다. 왜냐하면 세상에는 독자 구현이 너무 많기 때문입니다. 많은 업계가 자신의 GUI로 둘러싸고 싶어합니다. 「실험적으로 난해」라고 하는 것은 대체로 「내가 좋아하는 다른 언어에는 없어서 나에게 있어서는 이해 불가능한 기능」을 의미하는 것은 아닐까요? 이전에는 클래스 계층과 가상 함수가 그러한 기능이었습니다.

 

C++이 끝나는 것 일은 없습니다. 그러 말은 C++의 흉내를 내고 있는 무리들이 하는 말입니다.

C++의 표준화 방법은 확실히 늦고 어렵습니다. 단지 이미 말한 것처럼 가벼운 느낌의 실험적인 방법보다는 좋아요. 다른 방법이라고 하면 상업 언어의 진화는 빠릅니다. 왜냐하면 돈도 있고 다수의 환경을 고려 하지 않아도 되고 C++ 정도의 하위 호환성을 신경 쓸 필요가 없어니까요. Visual Basic을 기억하겠죠? C++VB만큼 빨리 진화하지 않는다고 자주 말해지고 있습니다. 하지만 C++은 기존의 코드를 가능한 한 부수지 않고 진화해 왔던 것입니다. 저는 아직도 숭고한 벨 연구소 같은 연구실이 새로운 아이디어를 실험하려면 최적의 장소라고 생각합니다.

많은 현장은 아직껏 C++98 조차 따라잡고 있지 않아요. 이것은 다른 언어에 말할 수 있는 것이지만.




Bjarne Stroustrup Concept와 미래를 말하다 - 1  http://jacking.tistory.com/443

Bjarne Stroustrup Concept와 미래를 말하다 - 2  http://jacking.tistory.com/467

Bjarne Stroustrup Concept와 미래를 말하다 - 3  http://jacking.tistory.com/474

Bjarne Stroustrup Concept와 미래를 말하다 – 4 http://jacking.tistory.com/559

Bjarne Stroustrup Concept와 미래를 말하다 – 5  http://jacking.tistory.com/652

Bjarne Stroustrup Concept와 미래를 말하다 – 6  http://jacking.tistory.com/678

Bjarne Stroustrup Concept와 미래를 말하다 – 7  http://jacking.tistory.com/679

Bjarne Stroustrup Concept와 미래를 말하다 – 8  http://jacking.tistory.com/686


저작자 표시
신고
by 흥배 2010.07.19 09:00

Danny Kalev

「위원회에 의한 설계」라고 하는 접근은 실패의 원인이군요. concept이 비판 받는 것도 그 때문인 것 같군요. 예를 들면 export입니다.(나중에 알았지만 John SpicerBerlin 회의에서 비슷한 것을 말한다. 회의록은 여기. 무엇으로 위원회가 표준화 하는 것을 기존의 유효성이 보증되고 있는 것으로 한정하지 않을까요? 실제 그렇게 해서 STL이 만들어졌었죠. 그러면 C++0x도 좀 더 빨리 규격을 제정 할 수 있었지 않았을까요?

 

 

Bjarne stroustrup

1996년 시점에서 STL을 「기존의 유효성이 보증되고 있는」 물건이라고 생각하는 사람은 많이 있었다고는 생각되지 않습니다. 한층 더 라이브러리의 제안과 언어 기능의 제안은 많이 다른 것이에요. 라이브러리의 제안을 예측하는 것은 비교적 간단합니다.

프랑크푸르트 회의에서 제시가 지적한 것은

l  어느 사람은 「상용 구현이 없는 것을 표준화 하지 말아야 한다」라고 주장하고 있습니다.

l  주요한 벤더는 표준 규격 없이 구현을 하지 않습니다(상용적으로 이점이 있는 독자 기능이 아닌 한).

 

이 문제를 피하는 방법으로서는 실증을 위한 실험적인 구현을 제공하는 것입니다. 단지 이것은 논의를「충분히 완전한 구현 이라는 것은 어느 정도인가?」와 「실험적 구현의 표준 규격에 있어서의 기준도는 어느 정도 정확한가?」라고 하는 것으로 바뀔 뿐입니다.

 

Concept에서는 실험적인 구현인 ConceptGCC와 실제로 움직이는 STL이 있었습니다. 어느 사람에게 있어서는 이것으로는 충분하지 않았습니다. 단지 제가 생각컨대 많은 사람이 구현 문제에 너무 신경 쓰고 있어서 설계의 문제에는 무관심했습니다. 설계와 구현만으로는 불충분합니다. 기능을 사용한 라이브러리도 필요합니다. 그 라이브러리를 사용한 실제의 프로젝트도 필요합니다. 뭐 그렇다면 완벽하겠지만 그렇게 몇 년이나 실험만 하고 있을 틈은 없습니다. 누가 그런 실험적인 구현 후에 프로젝트나 제품을 만들까요? 만일 누군가가 했다고 해도 어떻게 그렇게 빠른 단계의 구현상의 경험을 바탕으로 미묘하게 다른 표준 규격을 제정 할 수 있다고 말할까요? 얻을 수 있는 것은 비호환 독자 기능이 증가해 가는 것 정도의 물건입니다. C++98C++0x의 사이가 긴 공백 기간이 Apple이나 Microsoft가 독자「기술」을 내고 있는 이유입니다. 단지 아무것도 그들에게 한정한 이야기는 아닙니다. 기업이라고 하는 것은 업계의 쉐어와 이익을 추구하는 것입니다. 언어 설계의 범용성을 위해 있는 것은 아닙이다.

따라서 일반적으로 새로운 아이디어를 평가하는 것은 어렵고 넓게 사용되고 있는 언어에 대하여 하는 것은 한층 더 곤란합니다. 불가능한 것이라고는 생각하지 않지만 저는 대부분은 실험적인 구현으로 충분하다고 생각합니다. 비록 완전하지 않았다고 하더라도 기능을 100% 구현하고 있지 않을지도 모르고, 다른 기능과의 균형이 충분하지 않을지도 모르고, 성능이 최적화되어 있지 않을지도 모르고, 디버그 기능이 빠져 있거나, 에러 메세지가 완전하지 않을지도 모르는 등등. 현실에서는 어느 정도의 실험이 충분할지 어떨지를 판단하지 않으면 안됩니다. 그러나 이것은 어느 기능에 필요한 것이 모두 받아 들여진다는 것은 아닙니다. 거기에 더해 필요한 것은 규격의 검증, 단순성, 완전성, 범용성, 확장성, usability, 사람에게 가르칠 수 있을지?

 

많은 설계안을 검증하지 않으면 안됩니다. 대부분의 경우 그저 몇 안 되는 규격 설계의 차이가 일반 프로그래머에게 있어서의 편리한 사용을 아득하게 바꿉니다. 구현 중시로 놓치는 것이 많은 것은 여기입니다. 저시는 「전형적인 이용 예」와 「중요한 이용 예」를 모아서 많은 설계를 시험하고 있습니다. WG21 사이트에 있는 initializer listinitialization에 관한 많은 페이퍼가 이 어프로치를 실천하고 있습니다. 한층 더 저는 튜토리얼 쓰기, 학생에게 복수의 설계안을 시험하게 하는 것을 하고 있습니다. 물론 다른 언어 기능과의 균형이나 장래의 확장을 검증하는 것도 필요합니다.

 

더 재 빠르게 라고 단순하게 「위원회에 의한 설계」이외 방법으로 게다가 금전적 원조가 필요 없고, 기업의 영향도 받지 않는 듯한 규격 설계 방법이 있다고 생각하는 것은 실수입니다. WG21에서는 「위원회에 의한 설계」를 가능한 한 없애려고 하고 있습니다. 대부분의 설계는 개개인이 하고 모두의 앞에 가지고 와서 개량해 나갑니다. 그래서 잘 되기도 합니다.

 

John Spicer는 프랑크푸르트 회의에서 export의 문제를 채택하여 제라고 말했습니다. 다른 무리도 말했다고 생각합니다. 그것은 좋은 예입니다. 그러나 그것으로부터 무엇인가 단 하나의 교훈인 듯한 것을 꺼낼 수는 없었습니다. 제가 export에 관해서 말하는 것은 너무 지나치게 규모를 확대하여 복수의 기술 안을 도입하는 것은 좋지 않을까라고 말한 것입니다. 물론 더 명확한 설계를 해야 합니다.




Bjarne Stroustrup Concept와 미래를 말하다 - 1  http://jacking.tistory.com/443

Bjarne Stroustrup Concept와 미래를 말하다 - 2  http://jacking.tistory.com/467

Bjarne Stroustrup Concept와 미래를 말하다 - 3  http://jacking.tistory.com/474

Bjarne Stroustrup Concept와 미래를 말하다 – 4 http://jacking.tistory.com/559

Bjarne Stroustrup Concept와 미래를 말하다 – 5  http://jacking.tistory.com/652

Bjarne Stroustrup Concept와 미래를 말하다 – 6  http://jacking.tistory.com/678

Bjarne Stroustrup Concept와 미래를 말하다 – 7  http://jacking.tistory.com/679

 



출처 : http://www.devx.com/cplus/Article/42448/0/page/1

저작자 표시
신고
by 흥배 2010.06.23 20:30

Page 4: Commitees and Standardization

 

Danny Kalev

당신은 몇 번이나 100명의 위원회라고 하는 것은 「혁신적인 설계에 최적인 장소는 아니다」라고 말하고 있습니다. ISO 표준화 위원회는 너무 사람이 많은 것은 아닌가요? RubyPhtyon은 「선 독재제」(역주:구현이 하나 밖에 없고, 기본적으로 단지 한 명이 독단으로 개발하고 있으며 그 구현이 그대로 사양이 되는 언어를 말하는 것)모델을 사용하여 표준화를 하고 있지요. Linux는 커뮤니티 프로세스군요. 더 무엇인가 지금의 시대에 맞는 다른 프로세스로 표준화 하는 것을 생각해 보면 어떻습니까? 지금 같이 쓸데없이 꼼꼼하고 불편한 것이 아닌 더 모두가 직접 참가할 수 있는 느낌으로

 

 

Bjarne stroustrup

저의 문서를 읽어봐 주세요. 표준화와 진화 모델에 대한 염려가 쓰여져 있습니다.HOPL3 paperHOPL2 paper. 그것은 차치하고 저는 「좀 더 모두가 직접 참가할 수 있다」라는 것이 향상으로 연결된다고는 생각되지 않아요. 언어의 논의에 있어서 보통「목소리」는 대체로 단기적인 것의 견해를 하고 있으며 유행에 좌지우지되고 있고 게다가 단 하나의 기능 밖에 생각하고 있지 않아요. 대부분이 「간단하고 완벽한 해결 방법」인지를 복잡한 문제에 적용할 수 있다고 믿고 있으며기존의 몇 십억 행의 코드、몇 백만 명의 프로그래머에 대한 교육이라고 하는 것에 대한 배려가 충분하지 않아요. 몇 년이나 참을성이 많고, 설계, 표준화를 위해 많은 귀찮은 세부를 명확하게 하는 일을 하고 싶은 사람은 거의 있지 않아요. 제가 본 곳은 「커뮤니티 프로젝트」라고 하는 것들은 이미 잘 알려진 개념이 존재하는 것밖에 유효하지 않아요. 예를 들어 Linux에 있어서의 Unix등이에요. 근본적으로 다른 설계 사상으로부터 추려 나누는 것은 어려운 일이에요. 그것과 C++의 표준화는 완전한 자원봉사 작업인 것을 알아 두어 주었으면 합니다. 만약 C++이 조금이라도 보수를 지불하게 되어 있으면 또 다른 물건이 되었을지도 모르죠.

저는 독재주의를 좋아하지 않지만 단기적으로 보면 효율적으로 선정을 푸는 것일 수도 있겠네요.하지만 제가 생각컨대 대부분의「선 독재자」라고 하는 것은 대체로 그 힘에 빠져서 일반에서 받아 들이지 않는 개인적인 취미의 기능을 넣거나 할 것입니다. 즉 제멋대로인 독단으로 달려버립니다.

 

C++에서는 독재라고 하는 것은 아직 전혀 행해지고 있지 않아요. 최초기를 지나면 단 하나의 구현은 존재하지 않아요. C++은 그 정도의 스크립트 언어와는 비교가 되지 않는 정도로 많은 기업의 근간에 짜 넣어져 왔습니다. 한층 더 1980연대 후반부터 1990연대에는 HPIBMIntelMicrosoftSun과 같은 기업은 단지 한 명의 독단에 좌우되는 언어를 착실한 비즈니스로 사용하고 싶다고는 생각하지 않았습니다. 여태껏 그렇다고 생각합니다. C++ 표준화의 일은 주요한 유저에 의해서 되고 있습니다.





Bjarne Stroustrup Concept와 미래를 말하다 - 1  http://jacking.tistory.com/443

Bjarne Stroustrup Concept와 미래를 말하다 - 2  http://jacking.tistory.com/467

Bjarne Stroustrup Concept와 미래를 말하다 - 3  http://jacking.tistory.com/474

Bjarne Stroustrup Concept와 미래를 말하다 – 4 http://jacking.tistory.com/559

Bjarne Stroustrup Concept와 미래를 말하다 – 5  http://jacking.tistory.com/652

Bjarne Stroustrup Concept와 미래를 말하다 – 6  http://jacking.tistory.com/678


저작자 표시
신고
by 흥배 2010.06.12 08:30

Danny Kalev

최근의 DDJ 기사에서 「ConceptC++0x의 근간을 이루는 신기능이다」라고 쓰고 있지요. 어떤 사람은 C++0x의 「주요 기능」이라고 단언했었어요(N2893. 그렇지만 Concept이 들어가지 않는다고 정한 것은 어쩐지 무정하네요. 예를 들면 Herb Sutter블로그에 쓰고 있습니다만 concept 연기에 관한 Web 상의 코멘트를 읽고 있으면 기술적인 부정확함은 물론이고 C++0xConcept이 들어가지 않는다고 하는 것은 굉장히 중대한 일이라고 생각하고 있는 것 같다. 이상한 일이다」라든가. 결국 Concept 어떻게 되도 상관 없는 것이네요. 어째서 이런 기능에 바보같이 시간과 일손을 소모했습니까?

 

 

Bjarne stroustrup

내가 썼던 것을 전부 인용하면

Concepttemplate의 사용을 보다 논리적으로 하거나 표준 라이브러리의 규격을 고쳐 쓰거나 하는 것에 근간을 이루는 신기능이며 또 제네릭 프로그래밍을 일반적으로도 사용할 수 있도록 하기 위한 주요한 기능이다.

이것은 단지

ConceptC++0x의 근간을 이루는 신기능이다」

라고 하는 것은 꽤 인상이 달라집니다.

그리고 저로서는 concept 자체를 「주요 기능」이라고 말하거나 하지 않았습니다. 그렇다고 하는 것도 어느 하나의 기능만을 가지고 그 언어의 「주요」라고 하는 등이라고 하는 것은 의미를 알 수 없습니다. 대부분의 사람에게 있어서 C++0x의 가장 중요한 신기능이란 병렬처리(concurrency)의 표준 지원이라고 생각하지 말세요. concept과 같이 taskatomic type 등을 직접 사용하는 것은 극히 일부의 프로그래머 뿐이지만 혜택을 받는 사람은 많습니다. C++0x의 개량은 보다 더 프로그램을 쓰거나 개발 환경을 만드는데 도움이 되는 툴에 중점을 두고 있습니다. 단지 그 기능 자체 뿐입이라고 잘라서 말할 수 있는 것은 아닙니다.

제가 생각컨대 concept이란 중요했고 또 장래도 중요하게 될 것입니다. 템플릿의 usability를 향상시켜 제네릭 프로그래밍의 범위를 펼쳐、고품질 라이브러리의 지원을 위한 중요한 기능입니다. 몇 십년의 장기적으로 봐도 중요합니다. 하지만 일반 프로그래머에 있어서 이 앞의 수년의 중요도라고 하는 것은 그만큼은 아닐 것입니다. 손을 쓸 수 없게 되기 전에 concept이 어쩔 수 없이 필요한 시대에 이르기 전에 개량한 concept을 넣을 수도 있을 것입니다.

장기적인 것의 견해가 중요합니다. 원래 Concept은 많은 C++0x의 개량점 중 하나 밖에 지나지 않는 것입니다. 비록 Concept이 없어도 C++0xC++98 보다 아득하게 뛰어난 툴이 될 것입니다.




Bjarne Stroustrup Concept와 미래를 말하다 - 1  http://jacking.tistory.com/443

Bjarne Stroustrup Concept와 미래를 말하다 - 2  http://jacking.tistory.com/467

Bjarne Stroustrup Concept와 미래를 말하다 - 3  http://jacking.tistory.com/474

Bjarne Stroustrup Concept와 미래를 말하다 – 4 http://jacking.tistory.com/559

Bjarne Stroustrup Concept와 미래를 말하다 – 5  http://jacking.tistory.com/652


저작자 표시
신고
by 흥배 2010.06.11 08:30
정말 오랜만에 나머지 번역하고 있습니다. 언제쯤 끝날지...-__-;;;


Bjarne Stroustrup Concept와 미래를 말하다 - 1  http://jacking.tistory.com/443

Bjarne Stroustrup Concept와 미래를 말하다 - 2  http://jacking.tistory.com/467

Bjarne Stroustrup Concept와 미래를 말하다 - 3  http://jacking.tistory.com/474

Bjarne Stroustrup Concept와 미래를 말하다 – 4 http://jacking.tistory.com/559


 


Danny Kalev

저는 그다지 Concept의 팬이 아닙니다만 conceptrequires 키워드의 필요성은 알고 있습니다.

그래도 왜 concept map이나 axiom 등이 필요합니까? 개인적으로는 언어를 무의미하게 복잡화 시키고 탁상 공론으로 비 현실적인 장난감이라고 생각합니다. 도움이 되는 이용 방법도 있겠지만 처음은 기본적인 곳부터 시작하여 나중에 주의 깊게 확장해 가는 것이 좋지 않을까요?

 

 

Bjarne stroustrup

.. ~. 키워드 수의 삭감이 목적은 아닙니다. 제네릭 프로그래밍을 지원하기 위해서 필요합니다. concept을 편리하게 하려면 현행의 성공 예를 명확화 해서 지원하지 않으면 안됩니다. concept이 받아 들여지기 위해서는 현행의 성공 예를 완전하게 지원하지 않으면 안됩니다. 그렇지 않으면constrainedunconstrained template가 뒤죽박죽 될 뿐입니다. concept이 받아 들여지기 위해서는 「구태 의연한 unconstrainedtemplate로부터 「concept baseconstrainedtemplate로의 간단한 변환 방법을 제공하지 않으면 안됩니다. 이야기는 빗나가지만 제가 프랑크푸르트 전의 컨셉 규격의 설계에 대한 usability에의 염려는 이것도 관계하고 있습니다.

 

concept map에 대해서 생각해 보죠. concept에 임의의 형태를 적용시키는 어떠한 기구가 필요합니다. 이 기능이 없으면 그 concept을 염두로 설계된 형태만 사용할 수 있습니다. 당신이 행운의 별에서 태어났다면 우연히 시그너쳐가 일치하고 있을지도 모르겠네요. 원래 완전한 신기능이기 때문에 유저끼리 서로 협조하면 concept에 일치하는 형태를 강제할 수 있을 것이라고 생각할지도 모릅니다. 그런데 C++라고 하는 것은 1972년부터의 역사를 가지고 있고 넓게 사용되고 있는 언어입니다. 이미 많은 상상도 할 수 없는 듯한 형태가 있고, 매일 매일 새로운 형태나 concept이 만들어지고 있습니다.

 

잠시 여기서 말해 둘 것이 최근 10년 정도부터 개발자들은 이미 concept을 발명하였고 템플릿을 그 concept에 따라서 쓰고 있습니다. 그러한 「concept」은 단지 명시화 되어 있지 않은 정도 입니다. 대체로 필요 사항 등 문서도 불완전하고 제멋대로인 가정도 포함되어 있습니다.

 

그러한 이유로 기존의 concept 예를 들면 random access iterator와 기존의 형태 예를 들면 int*를 예로 들겠습니다. 여기서 형태를 concept을 요구하는 템플릿 인수로 사용하고 싶다고 합니다. 도대체 어떻게 하면 좋을까요? 언어에 concept map이 없으면 꾸며낼 수 밖에 없습니다. 예를 들면 RandomAccessIterator는 멤버형(역주:규격적으로 말하면 클래스에 네스트 된 형태)으로서value_type이 없으면 안됩니다. RandomAceessIterator를 사용하는 템플릿 코드는 그 이름을 인수의 형태의 멤버 명으로서 사용합니다. 그런데 int*에는 value_type 등이라고 하는 멤버는 없습니다. 원래 int*에는 멤버 따위가 없습니다. 그렇다고 하는 것은 Dennis Ritche가 포인터에 멤버 등이 필요 없다고 1972년에 결정했기 때문입니다. 타임 머신도 있지 않는한 당시 int*에 멤버를 덧붙이는 것은 할 수 없고, 그 때문에 C with value_type(역주:C with classes의 패러디)등이라고 하는 언어를 1994년 시점에서 발명하는 것도 할 수 없었던 것입니다.

 

언어에 concept map이 없으면 자신이 map을 만들 수 밖에 없습니다. 이 「map」은 int*의 래퍼 클래스로 value_type을 멤버로 가지고 있으며 다른 random access 조작도 할 수 있습니다. 행운과 뛰어난 컴파일러를 타고 나면 int*와 정말 변함 없는 성능을 얻을 수 있을 것입니다. 그리고는 모든 int*Self 클래스의 RandomAccessIterator로 래핑 할 뿐입니다. 제네릭 프로그래밍의 경험이 있으면 이런 류의 래퍼 클래스나 비슷한 아이디어인 traits는 자주 보았을 것입니다. 이러한 workaround 코드는 일반적이고 제네릭 코드에서는 간단합니다. 다만 쓰는 것은 귀찮고 대체로는 범용적이지 않고 극히 한정된 것 밖에 동작하지 않습니다. 전문가가 아니면 이해 하기 어렵습니다. 그래서 문제의 원인입니다.

concept_map은 이러한 현실적이고 근본적인 문제의 직접적인 해결 방법입니다. 예를 들면

 

template<class T> concept_map RandomAccessIterator<T*> {

typedef T value_type;

};

 

이것은 T* RandomAccessIterator로서 사용하면 그 value_typeT라고 하는 의미입니다. 위와 같이 어떤 문법이 제일 좋은 것인가에 대해서는 논의가 있지만 이러한 것을 표현할 필요가 있습니다. 「이러한 것을 표현」하는 것은 실제로 필요합니다. 완벽하고 범용적인 workaround 등이 존재하지 않습니다. 그러니까 언어 기능으로서 반드시 필요합니다. concept map 없이 concept을 사용한 제네릭 코드 등을 쓰고 싶다고는 생각하지 않습니다.

 

simplifying the use of concepts에서의 논의를 또 언급 하지 않겠지만 제가 말하고 싶었던 것은 concept map은 쓸데 없이 너무 사용되고 복잡하고 사용하기 어렵다고 하는 것입니다. 저는 그 문제를 해결하기 위한 제안을 했습니다. 무엇이든 존재하지 않는 조작을 덧붙이거나 이름을 바꾸거나 하여 형태를 concept에 일치시키기 위한 구조로서 concept map은 경험상 필요하고 논의의 여지도 없는 것입니다.

 

이미 설명한 것처럼 concept는 지정된 문법에 대해서 동작합니다. 어느 형태가 구체적인 이름에 의한 조작이나 형태를 가지고 있지 않으면 안 된다고 하는 것을 명시합니다. 예를 들면 random access iterator로서 사용하기 위해서는 그 형태는 *, ++, [], value_type 등을 제공하고 있지 않으면 안 되는 것 등입니다. 상식적으로 생각하면 이러한 조작은 「올바른 일을 한다」라고 보여지고 있으며 그 「올바른 일」은 어딘가 다른 문서에 쓰여져 있습니다. 이 경우 C++ 표준 규격입니다. 이것은 concept이 언어 측에서 지원 되고 있는지 어떤지에 관련되지 않고 하나입니다. 템플릿에 대한 문서라고 하는 것은 의미적인 필요 사항을 모두 쓴 것입니다. 좋은 문서일수록 그 필요 사항도 자세하게 쓰여지게 됩니다. 여기서의 문제란 도대체 어디까지 의미적인 필요 사항을 언어 측에서 지원하면 좋은 것인가? 또 어떻게 지원하는 것인가? 라고 하는 것입니다.

 

axiom에서는 코드 중에 자세한 의미 상의 규약을 간단한 문법으로 기술할 수 있습니다. 예를 들면

 

concept ForwardIterator<typename X> : InputIterator<X>, Regular<X> {

  requires Convertible<postincrement_result, const X&>;

  axiom MultiPass(X a, X b) {

   if (a == b) *a <=> *b;

   if (a == b) ++a <=> ++b;

  }

}

 

이 기술은 ForwardIterator이란 InputIterator이며 == 등을 제공하여 Regular이며 시퀀스에 대해서multiple pass라고 하는 공리가 성립됩니다. <=>라는 것은 동등 연산자입니다. ForwardIteratorab에 대해서 ab가 동일하다면 *a에 대한 조작은 *b에 대한 조작과 동일하다 입니다. 고등학교의 대수학에 약한 녀석들은 맨발로 도망갈 것입니다. 그러나 기술된 논리라고 하는 것은 고전적으로 범용적이고 의미를 기술하는데 효과적입니다.

 

axiom의 규격 설계에는 두 개의 목적이 있습니다.

l  보다 자세한 문서를 기술시키는 것.

l  프로그래머는 코드 상에서 직접 개발 환경에 정보를 전할 수 있는 것.

 

많은 무리는 axiom의 목적을 아래와 같이 잘못 생각하고 있습니다.

 

l  axiom은 컴파일러에 의해 좋은 코드를 생성시키기 위한 것이라는 등.
실제 axiom는 특히 그러한 용도가 뛰어나지 않습니다. 제가 사용하는 형태라고 하는 것은 수학적인 법칙에 따르는 것은 아니기 때문입니다. double과 같은 부동 소수점수(실수)는 실수의 법칙에는 따르지 않습니다. 실수에는 NaN 등이 없기 때문입니다. int의 종류는 정수의 법칙에는 따르지 않습니다. 수학적인 정수는 오버플로우 등이 없습니다. 만약 axiom을 최적화를 위해 설계하고 있었다면 지금쯤 대 실패했을 것입니다.

 

l  axiom은 형태를 증명하기 위한 것이 라는 등등.
수학을 공부할 때 공리라고 하는 것은 증명을 하기 위해서 사용하는 것입니다. 저도 C++ 컴파일러에 정리의 증명 기능 따위를 제안할 생각은 없습니다.

 

l  제안되고 있는 술어 이론(역주:predicate logic)의 문법으로 충분히 의미 기술을 할 수 있는 것인가? 더 확장해서는 안 되는 것인가? 등등.
술어 이론은 매우 길고 또 훌륭한 역사를 자랑하고 있으며 표현력이 있습니다. 저는 모험적으로 확장하거나 하지 않습니다.

 

라는 것은 axiom의 사용 목적과 자주 있는 오해를 설명한 것입니다. 그럼 남은 이용 방법은 도움이 되는가 하면 도움이 된다고 말할 수 있습니다. concept의 문서에는 많은 공리를 이용하고 있다고 하는 현실이 있습니다. 그러나 이점이라고 하는 것은 실제로 나타내 보이는 것이 어렵습니다.

여기서 axiom의 구체적인 사용법을 설명 하거나 하지 않지만(자세한 것은 N2887 참조)concept을 사용하는데 있어서의 어려운 문제에 문법상은 거의 같지만 의미가 다른 복수의concept이라고 하는 것이 있습니다. 예를 들어 foward iteratorinput iterator입니다. 저는 다음의 concept의 설계에서는 더 axiom을 전면적으로 밀어 내고 의미상의 차이를 취급하기 쉽게 할 생각입니다.

 


저작자 표시
신고
by 흥배 2010.05.11 08:30

C++0x 관련 책 "Visual C++ 10 C++0x"가 오늘 한국 MSDN 사이트에 올라왔습니다.

e-book으로 보기를 원하는 분이나 책을 얻지 못한 분들은 다운로드 해서 보세요

 

MSDN : http://msdn.microsoft.com/ko-kr/default.aspx

 


Visual Studio의 시작 페이지에도 다운로드 링크가 표시됩니다.

 

 

그리고 책에 오타가 있습니다.

48페이지 decltype 설명에서 오타가 있습니다.




저작자 표시
신고
by 흥배 2010.04.20 13:20
http://www.techdays.co.kr/


마이크로소프트의 최신 기술들을 소개하고 있습니다.
네이티브 개발부터 Azure까지 총 망라하고 있습니다.

웹에서 바로 볼 수도 있고 동영상 다운로드도 가능합니다.

저는 C++0x의 "RValue Reference와 lambda 완전 이해"라는 제목으로 강연을 했습니다.
예전에 블로그 포스팅을 할 때 부족함 부분이 있다고 느껴져서 처음부터 끝까지 설명하려고 했지만
제가 아직 온라인 강연은 너무 약해서 제대로 전달 될지는 모르겠네요 ;;;;;
만약 제 강연 내용이 제대로 전달 되었다면 제가 여기에서 한 내용만 이해하시면
RValue Reference와 lambda는 거의 대부분 마스터 하셨다고 생각하셔됩니다.

다행히 조만간에 C++0x와 관련된 글을 정리해서 공개할 예정이니 동영상 강의가 많이 부족하시면
이걸로 보충하시면 될듯 합니다.^^;;;;;

http://www.techdays.co.kr/2010spring/view.asp?s3=1&b_no=8



저작자 표시
신고
by 흥배 2010.03.29 19:54
| 1 2 3 4 |

티스토리 툴바