PXL 개발 사이트를 자유게시판에 적어둔 assembla의 사이트(http://www.assembla.com/spaces/show/pxl)로 이동합니다. 향후 볼랜드포럼에 TRAC이 설치되면 다시 옮겨오겠습니다.
현재는 임프님, 세더군 두명만 멤버로 (강제)가입시키고 일단 비공개로 진행중입니다만 조만간 퍼블릭으로 오픈하겠습니다.

개발 방향은 여러가지 사정으로 약간 바뀌었습니다.
일단 AnsiString 클론버전은 포기입니다. 이유는 C++ Builder의 차기버전에서는 유니코드를 제대로 지원하기 위해 새로운 스트링 클래스가 도입되기 때문이라고 간단하게 설명할 수 있습니다만 사실 내막은 좀 더 복잡합니다. 현재 C++ Builder가 지원하는 AnsiString이나 WideString은 모두 완벽하다고는 볼 수 없습니다. 특히 WideString은 유니코드를 표현할 수 있다고는 하지만 UTF-16이 아닌 UCS2기반 문자열로 UCS4에 정의된 유니코드를 모두 표현하지는 못하는 한계점이 있습니다. 특히 Reference Count를 지원하지 않기 때문에 함수의 리턴값으로 사용할 경우 심각한 메모리 복사로 인한 성능저하 문제가 있죠.
저 역시 유니코드를 완벽하게 지원하는 스트링클래스에 대한 필요성은 절감하고 있었고 마침 현재 개발중인 회사 프로젝트가 VC++와 C++Builder로 각각 만든 DLL간의 통신이 중요하기 때문에 기존 PXL의 개발방향을 약간 수정해서 '완벽'한 유니코드를 지원해 줄 수 있는, VCL과 함께 사용해도 '존재의이유'를 가질 수 있는 스트링 클래스를 만들기로 결정했습니다. (WideString 혹은 AnsiString클론은 VCL기반으로 프로그램에서는 존재의 의미가 없습니다.)

무엇보다도 결정적인 계기는 지난번 일본에서 코드기어 디벨로퍼캠프를 통해 코드기어가 유니코드 지원을 위해 AnsiString에 코드페이지 정보를 넣는 방식을 고려중이라는 소식을 들었을 때 약간의 충격을 받았던 것이었습니다.
당시엔 말도 안되는 방식이라고 생각했습니다만... UTF-16와 UCS4의 관계는 사실 ASCII와 Multibyte의 관계와 유사하기 때문에 문제가 많다는 생각이 들면서 나름 합리적인 선택이 될 수도 있다는 생각이 들더군요. 그래서 직접 만들어보기로 했습니다. 어떤 문제가 있을 것인지, 어떻게 해결해야할 것인지.
결과가 성공적이라면 CodeGear에 직접 코드로 제안할 수도 있을 것입니다.

새롭게 개발중인 UString이라는 스트링클래스는 내부적으로 총 4가지 형식의 문자열을 저장할 수 있습니다.
ANSI (Default Codepage), UTF8, UTF-16, UCS4

ANSI 타입의 문자열을 지원하기는 하지만 이는 생성자에서만 사용할 수 있고 일단 UString을 만든 이후에는 모든 연산은 유니코드 기반인 것을 가정하게 됩니다. 따라서 c_str()과 같은 함수는 지원하지 않으며 대신 utf8(), utf16(), ucs4() 함수만을 지원합니다. 결과 값은 각각 char*, wchar_t*, int* 입니다.
서로 같은 형식의 문자열을 보관하고 있는 UString간의 연산은 AnsiString이나 WideString과 동일한 메커니즘을 사용합니다만 서로 다른 형식의 경우엔 둘 중 하나로 통일하기 위해 코드변환이 자동으로 이루어집니다.
단지, UString은 ANSI->Unicode는 지원하지만 Unicode->ANSI의 변환은 공식적으로 지원하지 않기 때문에 약간의 주의가 필요합니다.

예)
UString a("hello"); // ASCII만으로 구성되어 있으므로 바로 코드변환 없이 UTF-8으로 저장됩니다.
UString b("안녕hello"); // Multibyte를 포함하고 있으므로 ANSI(Multibytes) 형식으로 코드변환 없이 저장됩니다.
UString c(L"hello"); // UTF-16으로 코드변환 없이 저장합니다.
UString d;
d = a + b;  // a는 UTF-8이므로 d는 UTF-8로 저장됩니다. b의 형식은 변화하지 않고 그대로 ANSI형식을 유지합니다.
d = b + c; // b는 ANSI이고 c는 UTF-16이므로 전항인 b의 형식으로 바뀌어야 하지만 UString은 ANSI로의 변환을 지원하지 않습니다. 따라서 b의 형식은 c의 형식인 UTF-16으로 변환이 되고 결과 d 역시 UTF-16으로 저장됩니다.
b의 형식이 ANSI->UTF-16으로 변화되고 c는 변화되지 않습니다.
d = a + c // 결과 d는 UTF-8이 됩니다.

스트링클래스의 이름을 결정할때 여러가지 고민을 했습니다. 특히 JitString이라는 이름은 이 스트링클래스의 동작방식을 좀더 명확하게 알려줄 수 있을 것 같아서 아직까지도 심각하게 고민중이기도 합니다.

늦어도 11월 말 안으로는 TRAC사이트를 오픈하겠습니다. 여러분의 많은 관심과 참여를 부탁드립니다.