http://moogi.new21.org/tc/ 그런즉 이제 애호박, 단호박, 늙은호박 이 셋은 항상 있으나, 그 중에 제일은 늙은호박이니라. 2025-03-14T06:16:39+09:00 Textcube 1.7.8 : Con moto (주의사신) http://moogi.new21.org/tc/743#comment3520 2012-10-13T09:40:06+09:00

1. 조엘 온 소프트웨어를 읽다 보면 저자가 해 본 프로젝트 중에서 CF***edString이라는 자료형이 있었다고 합니다. 얼마나 만드는 사람이 화가 났으면 이름을 그렇게 지었을까 싶은 문자열 클래스입니다. 2. C++에 이제는 문자열 자료형을 포함하지 않으면 안 되는 이유가 없을 것 같은데, 어떠한 이유인지 전혀 관련된 논의를 하지 않는 것 같더군요. 3. std::string의 경우에는 modify-on-copy를 하지 않는데, 이렇게 하는 이유가 Multithread 프로그래밍을 하게 되면, string 관련 연산을 할 때 Lock을 자주 걸어 주어야 해서 성능 저하가 엄청나기 때문에 그랬다고 합니다. (Code Craft라는 책에 그렇게 나와 있었습니다.)

(사무엘) http://moogi.new21.org/tc/743#comment3522 2012-10-13T10:10:56+09:00

1. 하하하!!! 흠좀무스러운 작명이군요. 2. string은 C++ 라이브러리에 포함된 것으로도 감지덕지지, 개념적으로 customization의 여지가 너무 많아서 C++ 같은 언어의 기본 자료형으로 들어가는 건 이제 무리일 것 같습니다. 그리고 넣어 봤자 이제는 이미 중복 구현체들이 역할을 대신 수행하고 있고요. 당장 wchar_t만 해도 int만큼이나 크기가 들쭉날쭉.. Windows에서는 UTF16이 짱입니다만, 유닉스 계열로 가면 아예 1글자당 4바이트인 UTF32도 많이 쓰이지요? 3. std::string이 그렇게 설계된 것은 스레드 안전성 같은 걸 차지하고라도, 문자열을 뭔가 serious한 객체라기보다는 primitive한 약간 덩치 큰 기본 자료형으로 간주한 사상이 크게 작용해서인 것 같습니다. 아무튼, 문자열이라는 물건은 프로그래머로서 생각할 주제가 굉장히 많은 주제임은 분명합니다. ^^

(kippler) http://moogi.new21.org/tc/743#comment3523 2012-10-13T12:51:35+09:00

* 이러니 저러니 해도 저는 개인적으로 CString 이 제일 좋더군요. 효율성도 좋고, %s 파라메터로 쓸 수 있는것도 좋고, 편리한 메쏘드도 많이 갖춰져 있고.. * windows 2000 이전은 UCS2 였고, 2000 부터는 공식적으로 UTF-16이라고 하더군요. 사실 그 당시는 아직 유니코드가 UCS2 만 있고, UCS4 는 없던 시절이라.... * 그리고 utf16 이 유닉스의 ucs4 보다는 확실히 편한듯 합니다. 어차피 ucs2 를 넘어가는 문자열 다룰일이 많지 않고, 메모리도 절약되니깐요. * 고급언어만 쓰던 개발자는 문자열 타입을 추상적으로 생각하는 경우가 많더군요. 그래서 replace 같은 함수가 얼마나 cpu를 많이 쓰는지에 대해서는 생각해 본 적이 없는 경우도 많고요. 그래서 신입사원 뽑을때 문자열 관련 함수를 직접 구현해 보게 시키는것(strlen, strcpy..) 이 c 의 로우레벨이나 포인터에 대한 이해도를 측정하기 좋더군요.

(김 기윤) http://moogi.new21.org/tc/743#comment3524 2012-10-13T13:13:14+09:00

옛날부터 단순히 char* 또는 char[] 형 만 계속해서 다루다 보니까 std::string 이나 CString 같은 것을 쓰다가도 문자열 조작을 하려면 c_str() 같은 것으로 char* 로 변환 한 뒤 변환하고 다시 원래대로 되돌리는 등의 연산을 하는 삽질(..)을 하는 저입니다. std::string 이나 CString 쪽도 익숙해져야 할텐데, 그냥 버릇이 버릇이다보니 기회를 잡지를 못하고 있네요..;

(Lyn) http://moogi.new21.org/tc/743#comment3525 2012-10-13T15:47:57+09:00

copy-on-modify 보다는 copy-on-write 가 좀더 일반적으로 쓰이는 명칭일듯 합니다

(사무엘) http://moogi.new21.org/tc/743#comment3526 2012-10-13T21:25:03+09:00

앗, 유명하신 그분께서...! (형님, 반갑습니다.. 이렇게 불러 드려도 되죠? ^^) 저도 문자열 클래스라는 걸 제일 먼저 접한 게 CString이다 보니, 그 디자인이 가장 무난하고 마음에 드는 것 같습니다. 사실, thread safety라는 게 절대적으로 보장돼야 하는 상황은 그리 많지 않거든요. 멀티스레딩을 하는 상위 소프트웨어 계층에서 동기화를 알아서 해 줘야겠죠. 굳이 포인터 단위의 저수준 조작이 필요하면 GetBuffer 함수를 써서 내부 버퍼를 변형 가능한 형태로 잠시 까 볼 수도 있다는 점도 더욱 좋습니다. UCS와 UTF 사이의 관계는 말씀하신 대로이구요. 진짜로 UC2 범위를 넘어가는 문자를 일상생활에서 접할 일은 거의 없는 게 사실이죠. 아무리 메모리가 남아 돈다고 해도, 한 글자당 32비트는 솔직히 정서적으로 기억장소 낭비가 너무 심한 감이 있죠. 또한, 마치 실수가 정수보다 다루기 힘들듯, 문자열은 단순 문자나 숫자에 비해 컴퓨터가 다루기 힘들어하는 타입이라는 것을 프로그래머라면 알 필요가 있습니다. ^^;;

(사무엘) http://moogi.new21.org/tc/743#comment3527 2012-10-13T21:25:13+09:00

포인터 덕질을 하다가 string 클래스로 갈아타자니, 내가 원하는 조작을 마음대로 못 하는 게 좀 마음에 걸리기도 하지요. 저의 <날개셋> 한글 입력기도 자체적인 문자열 클래스 구현체가 있는데요, 주어진 구간의 문자열을 특정 문자열로 대체하는 Substitute 함수가 있고(대체 대상 문자열은 굳이 null-terminate가 아니어도 됨!), Format된 문자열을 기존 문자열의 앞이나 뒤에다 추가하는 FormatBefore, FormatAfter라는 함수를 제 식대로 만들어서 제공하고 있답니다.

(사무엘) http://moogi.new21.org/tc/743#comment3528 2012-10-13T21:25:26+09:00

제가 CString 클래스의 메커니즘을 처음으로 알게 된 곳이 바로 MSDN에서 전설적인 개발자였던 Paul DiLascia의 글인데요, 거기서 처음부터 'modify'라는 용어를 쓰더군요. 저는 그냥 그 영향을 받은 것입니다. http://www.microsoft.com/msj/archive/S1F0A.aspx First off, if you're not using CStrings, shame on you! Come on guys, the year 2000 is almost upon us! “세상에 아직도 CString도 모르다니, 부끄러운 줄 아셈!”... 1996년에 작성된 글입니다. ㅎㅎ