오늘 Visual Studio 2010 출시 일정이 나왔습니다. Rob Caron 말에 의하면 2010년 4월 12일에 출시가 된다고 합니다. Microsoft 직원이 전하는 이야기이니 아마도 이 날에 출시하는 것을 신뢰하시면 될 것 같습니다.
Rob Caron 은 Microsoft 에서 마케팅 커뮤니케이션 매니저로 일하고 있으며, Developer, User Experience Runtime, Tools 과 관련된 일을 하고 있는 분입니다. Microsoft 에 입사 하기 전에 개발자 출신인데, Microsoft 에서 이전에는 개발자 마케팅과 MSDN 개발자 센터, Visual Studio 마케팅 사이트, 개발자 이벤트, MSDN Library 에 콘텐트를 게시하는 일도 하셨다고 합니다.
좀 아쉬운 것은 현재 문제나 개선되고 있는 부분을 좀 더 자세히 알고 싶은데, 출시 일정 외에 다른 언급은 전혀 없네요.
Visual Studio 2010 의 처음 출시 일정은 2010년 1월에 RC 버전, 3월에 정식 버전을 출시하기로 예정하였습니다. 그러나 가상 메모리 관련, 성능 최적화 문제로 정확한 출시 일정을 공개하지 않고 출시 기간을 연장하였습니다. 일정이 연기된 것은 개인적으로 아쉽지만, 보다 충실한 플랫폼을 만들기 위해서라면 충분히 기다릴만 하다고 생각합니다. 써본 후에 투덜댈봐엔 좀 더 완성도 높은 플랫픔을 위한 것이라면 말이죠^^
언제나 언급했던 이야기 이지만, 예전의 Visual Studio 2008 까지는 기능에 충실했던 강력한 개발 도구임이 틀림이 없습니다. 하지만 Visual Studio 2010 과 관련된 플랫폼은 기능은 기대 이상 완벽히 충실하고 있으며, 편의성까지 갖추게 될 그야말로 차세대 플랫폼입니다. 앞으로 다가올 4월이 정말 기대가 됩니다.
네. 확실히 C# 4.0의 가장 큰 키워드는 Dynamic이기 때문에, dynamic은 스타일지도 모르겠습니다. 하지만, 화려한 모습뒤에 감쳐진 그들의 일상사는 때때로 자살같은 비극적인 사건을 통해서 세간에 알려지곤 하죠. 그럴때마다 세삼스럽게 사람들은 화려한 일상뒤의 모습은 변비때문에 우울해하는 것 같이, 보통사람과 전혀 다르지 않음을 재확인 합니다..... 왜 이런 헛소리를 또 하고 있을까요-_-;;; 아무튼. dynamic은 초큼 외로운 아이입니다. 증거를 제시해드리죠.
네. 다른 타입들은 System.Object로 부터 아주 사이좋게 이리저리 연결되어 있습니다만, dynamic은 천상천하유아독존입니다. 그저 혼자 있을 뿐이지요. 어린이집에서도 유별난 애들은 꼭 걔네들 기분에 잘 맞춰줘야 해서 선생님들이 고생을 하기도 하는데요. dynamic역시 독특한 면을 갖고 있습니다. 지난 포스트에 이어서 dynamic의 형변환 룰에 대해서 알아보면 아래와 같습니다.
1. dynamic에서 dynamic으로 동일한 형변환이 가능 2. 모든 참조형 타입에서 dynamic으로 암시적인 참조형변환이 가능 3. 모든 값형 타입에서 dynamic으로 암시적인 박싱형변환이 가능 4. dynamic에서 모든 참조형 타입으로 명시적인 참조형변환이 가능 5. dynamic에서 모든 값형 타입으로 명시적인 언박싱 형변환이 가능
리스트1. dynamic에서 다른 타입으로 형변환 가능여부.
아래부분에 줄로 그어 버린 부분은 정식버전이 출시되면서 개념이 바뀐 부분들입니다. 그리고 밑에서 설명드리는 '대입형변환'이라는 용어도 여전히 의미가 있는지 불분명합니다. 다만, C# 4.0 명세서에 보면 '대입형변환'이라는 개념이 없는 걸로 봐서는 설명을 위해서 도입한 개념이 아닌가 싶은데요, 이에 관해서 Chris Burrows에게 질문을 남겨놨는데요, 답이 오면 바로 업데이트 하겠습니다. 바뀐 내용에 대해서는 이 글을 참조하시기 바랍니다.
매우 직관적으로 보이긴 하지만, 좀 생각해보면 이상한 점들이 발견됩니다. 그 첫번째가 바로 dynamic에서 object로 암시적인 형변환이 없다는 사실인데요. 위에서 1, 4번에서 언급했듯이 dynamic에서 dynamic을 제외한 모든 참조형타입으로 암시적인 형변환이 없다고 하고 있습니다. 그 이유는 연산을 하는 도중에 둘을 구분해내기가 매우 어렵기 때문이라고 합니다. 근데, 아래와 같은 코드가 컴파일 되고 실행되는 걸 확인할 수 있습니다.
dynamic d = null; object o = d;
이건 분명히 암시적 형변환 처럼 보이는데, 왜 이게 컴파일이 되는 걸까요? 사실, 두번째줄은 암시적 형변환이 아니라 대입 형변환입니다. 대입 형변환은 또 뭘까요?
위 그림을 보시면, 형변환이 총 3가지로 분류가 되는 걸 확인하실 수 있습니다. 대입 형변환은 명시적 형변환과 암시적 형변환의 사이에 위치해 있는데요. 모든 대입 형변환은 사실 명시적 형변환이며, 모든 암시적 형변환은 대입 형변환 인거죠. 왜 이런 걸 새로 도입했어야 할까요? 사실 C# 4.0작업을 하면서 dynamic에서 다른 타입으로 암시적 형변환 도입을 검토했었다고 합니다. 그런데, 이렇게 하게 되면 문제가 생기는데요. 바로, dynamic을 통해서 아무타입에서 아무타입으로 형변환이 가능하기 때문입니다. 이 문제를 오버로드 판별을 예로 들어서 설명해보겠습니다.
public class C { public static void M(int i){}
public static void M(string s){} static void Main(string[] args) { dynamic d = GetSomeDynamic(); C.M(d); } }
코드1. 만약 암시적 형변환이 가능하다면?
위와 같은 코드가 있다고 할때요, 과연 어떤 메서드가 실행되어야 할까요? dynamic에서 모든 타입으로 암시적 형변환이 있다면, dynamic에서 int도 dynamic에서 string도 가능한 상황이 됩니다. 물론, dynamic에서 object같이 dynamic에서 int보다 더 나은 걸 찾을 수도 있겠지만, 그렇지 않은 경우가 훨씬 많이 발생하게 됩니다. 이런 모호함 때문에 dynamic에서 다른 타입으로 형변환을 할때는 명시적으로 선언을 하게 제한을 둔 거죠.
그렇다면, 대입 형변환은 또 뭘까요?
1. dynamic에서 모든 참조형 타입으로 대입 참조 형변환이 가능 2. dynamic에서 모든 값형 타입으로 대입 언박싱 형변환이 가능
리스트2. 대입 형변환의 설명
[리스트1]에서 4,5번을 보면 명시적 형변환에 대해서 이야기 하고 있죠? 사실은 그 명시적 형변환이 바로 이 대입 형변환을 말하는 겁니다. 모든 대입 형변환은 명시적 형변환이라고 말씀드렸던 걸 떠올리시면 고개가 절로 끄덕끄덕....교회 다니시는 분들은 교회로 끄덕끄덕 하실겁니다. 그리고 리스트2의 모든 형변환과 암시적 형변환을 모두 합하면 바로 대입 형변환이 되는 거죠.
- 그래그래 어디 계속 해봐.
대입이 일어나는 곳이 바로 컴파일러가 대입 형변환을 시전하는 곳입니다.
dynamic d = GetSomeDynamic(); Worksheet ws = d; //대입 형변환
이거 말고도, 대입 비스무리한 것들은 모두 대입 형변환을 사용합니다. return과 yield 그리고 프로퍼티와 인덱서, 배열 초기화구문, 그리고 foreach나 using같은 구문말이죠.
return d; //return할 타입으로 대입 형변환 yield return d; //반복자의 타입으로 대입 형변환 foo.Prop; //Prop의 타입으로 대입 형변환 foo[1] = d; //인덱서의 타입으로 대입 형변환 bool[] ba = new bool[] { true, d }; //bool로 대입 형변환 foreach(var x in d) {} //IEnumerable로 대입 형변환 using (d) {} //IDisposable로 대입 형변환
리스트3. 대입 형변환이 어디어디서 끼어드는지!
하지만, 이런 대입 형변환을 사용하지 않는 곳 중에 하나가 오버로드 판별입니다. [코드1]에서 보셨듯이 만약에 메서드를 호출하는데 대입 형변환을 적용하게 되면, 매번 메서드를 호출할때마다 모호함때문에 캐고생을 하게 될겁니다. 하지만, 대입 형변환을 적용하지 않는다고 해도, [코드1]은 제대로 컴파일 되지 않을거 같습니다. 왜냐면, d의 타입인 dynamic에서 C의 두 오버로드가 받는 파라미터 타입인 int와 string으로 형변환이 불가능 하기 때문입니다. 하지만, 이런 코드가 컴파일 되고 잘 돌아가야만 하니깐, 바로 지난 포스트에서 언급했던 유령 메서드가 끼어들게 되는거죠.
- 마치면서
어찌 퍼즐 조각이 좀 맞아 들어가시나요? 저도 글을 쓰면서 다시한번 자세히 읽다보니 퍼즐조각이 조금씩 맞아들어가는 느낌이 드는데요. 꼭 무슨 그것이 알고싶다에서 사건 조사하는 거 같은 기분이네요-_-. 그럼 다음 포스트에서 뵙져!!!
concurrent_queue는 사용 용도가 concurrent_vector 보다 더 많을 것 같아서 좀 더 자세하게 설명하겠습니다.
온라인 서버 애플리케이션의 경우 ‘Producer-Consumer 모델’이나 이와 비슷한 모델로 네트웍을 통해서 받은 패킷을 처리합니다. 즉
스레드 A는 네트웍을 통해서 패킷을 받으면 Queue에 넣습니다. 그리고 스레드 B는 Queue에서
패킷을 꺼내와서 처리합니다. 이 때 Queue는 스레드 A와 B가 같이 사용하므로 공유 객체입니다. 공유 객체이므로 패킷을 넣고 뺄 때 크리티컬섹션과 같은 동기 객체로 동기화를 해야 합니다. 이런 곳에 concurrent_queue를 사용하면 아주 좋습니다.
concurrent_queue를
사용하기 위한 준비 단계
너무 당연하듯이 헤더 파일과 네임스페이스를 선언해야 합니다.
헤더파일
#include <concurrent_queue.h>
네임스페이스
using namespace Concurrency;
을 선언합니다.
이제 사전 준비는 끝났습니다. concurrent_queue를 선언한
후 사용하면 됩니다.
concurrent_queue< int > queue1;
concurrent_queue에 데이터 추가
concurrent_queue에 새로운 데이터를 넣을 때는push라는 멤버를 사용합니다.
원형
void
push( const _Ty& _Src );
STL의 deque의 push_back과 같은 사용 방법과 기능도 같습니다. 다만 스레스
세이프 하다는 것이 다릅니다. concurrent_queue는 앞 회에서 이야기 했듯이 스레드 세이프한
컨테이너이므로 제약이 있습니다. 그래서 deque 와
다르게 제일 뒤로만 새로운 데이터를 넣을 수 있습니다.
concurrent_queue< int > queue1;
queue1.push( 11 );
concurrent_queue에서
데이터 가져오기
데이터를 가져올 때는try_pop멤버를 사용합니다. 앞의 push의 경우는 STL의 deque와 비슷했지만 try_pop은 꽤 다릅니다.
원형
bool
try_pop( _Ty& _Dest );
try_pop을 호출 했을 때
concurrent_queue에 데이터가 있다면 true를 반환하고 _Dest에 데이터가 담기며 concurrent_queue에 있는
해당 데이터는 삭제됩니다. 그러나 concurrent_queue에
데이터가 없다면 false를 즉시 반환하고 _Dest에는
호출했을 때의 그대로 됩니다.
concurrent_queue< int > queue1;
queue1.push( 12 );
queue1.push( 14 );
int Value = 0;
if( queue1.try_pop( Value ) )
{
//
queue1에서 데이터를 가져왔음
}
else
{
//
queue1은 비어 있었음.
}
concurrent_queue가
비어 있는지 검사
concurrent_queue가 비어 있는지 알고 싶을 때는empty()를 사용합니다. 이것은
STL의 deque와 같습니다.
원형
bool
empty() const;
비어 있을 때는 true를 반환하고 비어 있지 않을 때는 false를 반환합니다. 다만
empty를 호출할 때 비어 있는지 검사하므로 100% 정확하지 않습니다. 100% 정확하지 않다라는 것은 empty와 push, try_pop 이 셋은 스레드 세이프하여 동시에 사용될 수 있으므로
empty를 호출할 시점에는 데이터가 있어서 false를 반환했지만 바로 직후에 다른 스레드에서 try_pop으로 삭제를 해버렸다면 empty 호출 후 false를 반환했어 try_pop을 호출했는데 false가 반환 될 수 있습니다.
concurrent_queue에 있는 데이터의 개수를 알고 싶을 때
concurrent_queue에 있는 데이터의 개수를 알고 싶을 때는unsafe_size멤버를 사용합니다.
원형
size_type
unsafe_size() const;
이것은 이름에서도 알 수 있듯이 스레드 세이프 하지 않습니다. 그래서 unsafe_size를 호출할 때 push나 try_pop이 호출되면 unsafe_size를 통해서 얻은 결과는
올바르지 않습니다.
concurrent_queue에
있는 데이터 순차 접근
concurrent_queue에 있는 데이터를 모두 순차적으로 접근하고
싶을 때는unsafe_begin과 unsafe_end를
사용합니다.
원형
iterator
unsafe_begin();
const_iterator
unsafe_begin() const;
iterator
unsafe_end();
const_iterator
unsafe_end() const;
unsafe_begin을 사용하여 선두 위치를 얻고, unsafe_end를 사용하여 마지막 다음 위치(미 사용 영역)를 얻을 수 있습니다. 이것도 이름에 나와 있듯이 스레드 세이프 하지
않습니다.
모든 데이터 삭제
모든 데이터를 삭제할 때는clear를 사용합니다. 이것은 이름에 unsafe라는 것이 없지만 스레드 세이프 하지 않습니다.
원형
template< typename _Ty, class _Ax >
void
concurrent_queue<_Ty,_Ax>::clear();
제 글을 보는 분들은 C++을 알고 있다는 가정하고 있기 때문에 STL을 알고 있다고 생각하여 아주 간단하게 concurrent_queue를
설명 하였습니다.
concurrent_queue 정말 간단하지 않습니까? 전체적으로 STL의 deque와
비슷해서 어렵지 않을 것입니다. 다만 스레드 세이프 하지 않은 것들이 있기 때문에 이것들을 사용할 때는
조심해야 된다는 것만 유의하면 됩니다.
이것으로 Concurrency Runtime의 PPL에 대한 설명은 일단락 되었습니다.
이후에는 Concurrency Runtime의 다른 부분을 설명할지
아니면 Beta2에서 새로 추가된 C++0x의 기능이나 또는
이전에 설명한 것들을 더 깊게 설명할지 고민을 한 후 다시 찾아 뵙겠습니다.^^
