http://moogi.new21.org/tc/ 철도를 명절 때에나 떠오르는 4대 교통수단 중 하나로만 아는 것은, 예수님을 사대성인· 성인군자 중 하나로만 아는 것과 같다. 2022-02-11T08:35:48+09:00 Textcube 1.7.8 : Con moto (김 기윤) http://moogi.new21.org/tc/347#comment747 2010-08-13T14:52:59+09:00

STL을 쓰는 저로써는 qsort() 는 한두번 써봤나? 싶고 그냥 sort() 함수 쓰는걸로 끝냅니다.. 훨씬 간편하고 쓰기도 쉽죠 -_-; 성능상으로도 sort 가 더 빠르다고 하는 글도 본 적이 있습니다. (아무래도 qsort 는 함수 포인터를 호출 해야 할 테니)

(사무엘) http://moogi.new21.org/tc/347#comment748 2010-08-14T00:16:58+09:00

C++ 버전은 간단한 int 배열은 qsort처럼 매번 비교 함수를 호출 안 하고 바로 비교 연산만 수행하며 정렬하는 코드를 생성할 수도 있을 테니, 그 점에서는 유리하지요. 비슷한 맥락에서, cout은 언제쯤 printf의 성능을 따라잡을지 모르겠습니다. 32비트와 64비트가 막 섞이면서 % 문자는 이식성 면에서 굉장히 골치 아픈 존재가 돼 있기도 하고요.

(김재주) http://moogi.new21.org/tc/347#comment749 2010-08-14T01:23:14+09:00

사실 fstream, iostream 같은 C++ 입출력 스트림은 C++ 표준 라이브러리 중에 가장 최적화 연구가 덜 된 분야이긴 합니다. 파싱 과정 없이 타입만 가지고 오버로딩된 함수 중에 어떤 걸 이용해야 되는지 결정할 수 있는 C++ 라이브러리가 C의 scanf, printf보다 더 빠른 속도로 동작하는 걸 기대해도 무리는 아닐 텐데요.

(아라크넹) http://moogi.new21.org/tc/347#comment750 2010-08-14T04:58:10+09:00

iostream 라이브러리의 가장 큰 문제는 (C 라이브러리 같은 데서도 흔히 볼 수 있는) locale 관련 처리가 지나치게 복잡하다는 데 있습니다. 정작 실제로 프로그래밍을 할 때 언어 차원에서 지원하는 locale 라이브러리는 거의 전혀 쓸모 없는 게 현실이라는 걸 감안하면 더더욱 큰 문제가 되지요. gettext 같은 매우 간단한 지역화 툴이나, 그걸로 부족하면 아예 ICU 같은 걸 쓰는 게 상식적입니다. (유닉스 계열에서는 POSIX locale의 존재 때문에 눈꼽만큼 상황이 낫습니다만, 결국 각자 구현해서 쓰게 되더군요.) 보통 #include <iostream> 해서 cin과 cout을 받아 오면 정적 링크한 바이너리 크기가 급격히 불어나는 걸 볼 수 있는데 (상황에 따라 다르지만 200~500K 정도는 흔할 겁니다) 이 부분이 바로 locale 처리 코드가 들어 가서 그런 것입니다. 게다가 C++ locale의 구현은 locale 관련 정보를 제공하는 각종 클래스들(facet라고 합니다)의 "생짜 배열"로 구성되어 있어서 가독성을 좀 희생해서 모처럼 얻어낸 inline 가능한 구현을 망쳐버립니다. 차라리 이 부분을 최대한 템플릿으로 만들어서 컴파일 시간에 필요 없는 코드를 없애 버리는 쪽이 더 낫지 않을까 하는 망상까지 하게 되지요.

(사무엘) http://moogi.new21.org/tc/347#comment751 2010-08-15T01:20:12+09:00

김재주, 아라크넹: 그렇죠. % 문자를 해석하는 일도 만만한 작업이 아닐 텐데, C++ iostream은 지금보다 더 똑똑한 최적화가 아쉽습니다. 하지만 현실에선... 속도는 그렇다 치더라도 code bloat도 말씀하셨듯이 너무 심해요. 복잡한 추상화 계층 때문이겠죠.