유니코드 아직도 헷깔립니다

wchar_t에서 w는 꼭 유니코드를 지칭하지는 않습니다. 그냥 wide character set 일 뿐이죠. char이 꼭 ASCII 를 지칭하지는 않는 것과 마찬가지라 할 수 있습니다.

1번은 몇가지 가정이 더 붙는다면 맞습니다. 정확하게 쓰자면 "해당 환경에서 사용하는 wide character set 중의 어떤 문자라도 저장할 수 있을 정도로 큰 크기"가 되겠으며, 그 크기는 컴파일러에서 어떤 character set을 wide character set으로 사용하는가에 따라 다릅니다. UTF-16이라면 16비트고, UTF-32라면 32비트가 되겠죠. 여기에 대해 특별한 제한은 없습니다. 일단 8비트 보다는 크겠지만요.

2번은, char *가 그 특성상 모든 주소의 메모리 공간과 모든 타입의 object를 가리킬 수 있으므로 반칙인 질문이라 하겠습니다(정렬제한에 가장 영향을 적게, 혹은 안받는 포인터형이 char*형입니다). 즉 L"한글" 인 wide string literal 이라고 해서 가리키지 못할 이유가 없습니다(타입 캐스팅이 없으면 경고나 에러가 뜰수도 있겠지만요). 하지만, char형(혹은 char*형)에 기반한 문자열 처리 함수들은 char*이 가르키는 wide string literal을 single-byte string처럼 다루고 처리할 것입니다.

한가지 더 참고삼아 말씀드리자면, C에서는 source character set과 execution character set을 구분하고 있습니다. 소스 코드에서는 ASCII를 사용하고 실행 파일은 EBCDIC을 사용한다던가, 혹은 소스 코드에서는 UTF-8을 사용하고 실행 파일에서는 UTF-16을 사용하는 경우가 충분히 가능합니다.

C에서 유니코드(utf8이던 utf16이던)를 사용하는데 반드시 wchar_t와 L"str"이 전제되어야 하는가라고 묻는다면, 아니라고 답하겠습니다. 또한, wchar_t와 L"str"로 소스코드를 작성하면 반드시 유니코드가 지원되는 것이냐라고 묻는다면, 역시 아니라고 답하겠습니다.

결론은? 유니코드와 wchar_t와는 별개의 문제입니다. 다만, C 표준에서는 각각의 C 구현체들이 일관성있는 방법으로 wide character set을 지원할 수 있도록 wchar_t라는 가이드 라인을 제시하고 있고, 어떤 구현체들은 그것을 이용해서 unicode를 지원하고 있을 뿐입니다.

이에 대해서, 실제 C/C++ 구현체들이 어떤 방식으로 유니코드를 구현하는지를 살펴보면 재미있지요.

http://msdn2.microsoft.com/en-us/library/c426s321.aspx

제 기억으로는 윈도우 95 시절부터 MS는 유니코드 환경을 준비했던 것 같군요. TCHAR도 그때부터 있었고...

프로그래머가 그렇게 할 수 있다는게 아니고, C 컴파일러의 구현자가 그렇게 할 수 있다는 것입니다. 즉 컴파일러가 UTF-8로 된 소스 코드를 번역해서, 내부에서 사용되는 문자열을 UTF-16으로 저장한 실행파일을 결과물로 내놓도록 컴파일러를 만들 수 있다는 것입니다. 또다른 예로는, ASCII를 사용하는 컴퓨터 위에서 돌아가는, EBCDIC용 실행 파일을 빌드하는 C 크로스 컴파일러를 예로 들 수 있겠죠(실존하는지 여부는 모르겠지만;;;)

프로그래머 입장에서는 위에서 말씀하신 대로 다음과 같이 해야 됩니다.

wchar_t *p = L"헬로 유니코드!";
if(터미널이 UTF-8이라면)
convert16to8(p);
cout<<p;