<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
	<channel>
		<title>김 용묵의 절대공간 - 블로그: C-언어가-제공하는-검색-함수에 달린 최근 댓글/트랙백 목록</title>
		<link>http://moogi.new21.org/tc/</link>
		<description>철도를 명절 때에나 떠오르는 4대 교통수단 중 하나로만 아는 것은, 예수님을 사대성인· 성인군자 중 하나로만 아는 것과 같다.</description>
		<language>ko</language>
		<pubDate>Sun, 09 Jan 2022 16:39:17 +0900</pubDate>
		<generator>Textcube 1.7.8 : Con moto</generator>
		<image>
		<title>김 용묵의 절대공간 - 블로그: C-언어가-제공하는-검색-함수에 달린 최근 댓글/트랙백 목록</title>
		<url>http://moogi.new21.org/tc/attach/1/1404861358.jpg</url>
		<link>http://moogi.new21.org/tc/</link>
		<width>220</width>
		<height>165</height>
		<description>철도를 명절 때에나 떠오르는 4대 교통수단 중 하나로만 아는 것은, 예수님을 사대성인· 성인군자 중 하나로만 아는 것과 같다.</description>
		</image>
		<item>
			<title>김 기윤님의 댓글</title>
			<link>http://moogi.new21.org/tc/347#comment747</link>
			<description>STL을 쓰는 저로써는 qsort() 는 한두번 써봤나? 싶고 그냥 sort() 함수 쓰는걸로 끝냅니다.. 훨씬 간편하고 쓰기도 쉽죠 -_-; 성능상으로도 sort 가 더 빠르다고 하는 글도 본 적이 있습니다. (아무래도 qsort 는 함수 포인터를 호출 해야 할 테니)</description>
			<author>(김 기윤)</author>
			<guid>http://moogi.new21.org/tc/347#comment747</guid>
			<comments>http://moogi.new21.org/tc/347#comment</comments>
			<pubDate>Fri, 13 Aug 2010 14:52:59 +0900</pubDate>
		</item>
		<item>
			<title>사무엘님의 댓글</title>
			<link>http://moogi.new21.org/tc/347#comment748</link>
			<description>C++ 버전은 간단한 int 배열은 qsort처럼 매번 비교 함수를 호출 안 하고 바로 비교 연산만 수행하며 정렬하는 코드를 생성할 수도 있을 테니, 그 점에서는 유리하지요.
비슷한 맥락에서, cout은 언제쯤 printf의 성능을 따라잡을지 모르겠습니다. 32비트와 64비트가 막 섞이면서 % 문자는 이식성 면에서 굉장히 골치 아픈 존재가 돼 있기도 하고요.</description>
			<author>(사무엘)</author>
			<guid>http://moogi.new21.org/tc/347#comment748</guid>
			<comments>http://moogi.new21.org/tc/347#comment</comments>
			<pubDate>Sat, 14 Aug 2010 00:16:58 +0900</pubDate>
		</item>
		<item>
			<title>김재주님의 댓글</title>
			<link>http://moogi.new21.org/tc/347#comment749</link>
			<description>사실 fstream, iostream 같은 C++ 입출력 스트림은 C++ 표준 라이브러리 중에 가장 최적화 연구가 덜 된 분야이긴 합니다. 파싱 과정 없이 타입만 가지고 오버로딩된 함수 중에 어떤 걸 이용해야 되는지 결정할 수 있는 C++ 라이브러리가 C의 scanf, printf보다 더 빠른 속도로 동작하는 걸 기대해도 무리는 아닐 텐데요.</description>
			<author>(김재주)</author>
			<guid>http://moogi.new21.org/tc/347#comment749</guid>
			<comments>http://moogi.new21.org/tc/347#comment</comments>
			<pubDate>Sat, 14 Aug 2010 01:23:14 +0900</pubDate>
		</item>
		<item>
			<title>아라크넹님의 댓글</title>
			<link>http://moogi.new21.org/tc/347#comment750</link>
			<description>iostream 라이브러리의 가장 큰 문제는 (C 라이브러리 같은 데서도 흔히 볼 수 있는) locale 관련 처리가 지나치게 복잡하다는 데 있습니다. 정작 실제로 프로그래밍을 할 때 언어 차원에서 지원하는 locale 라이브러리는 거의 전혀 쓸모 없는 게 현실이라는 걸 감안하면 더더욱 큰 문제가 되지요. gettext 같은 매우 간단한 지역화 툴이나, 그걸로 부족하면 아예 ICU 같은 걸 쓰는 게 상식적입니다. (유닉스 계열에서는 POSIX locale의 존재 때문에 눈꼽만큼 상황이 낫습니다만, 결국 각자 구현해서 쓰게 되더군요.)

보통 #include &amp;lt;iostream&amp;gt; 해서 cin과 cout을 받아 오면 정적 링크한 바이너리 크기가 급격히 불어나는 걸 볼 수 있는데 (상황에 따라 다르지만 200~500K 정도는 흔할 겁니다) 이 부분이 바로 locale 처리 코드가 들어 가서 그런 것입니다. 게다가 C++ locale의 구현은 locale 관련 정보를 제공하는 각종 클래스들(facet라고 합니다)의 &amp;quot;생짜 배열&amp;quot;로 구성되어 있어서 가독성을 좀 희생해서 모처럼 얻어낸 inline 가능한 구현을 망쳐버립니다. 차라리 이 부분을 최대한 템플릿으로 만들어서 컴파일 시간에 필요 없는 코드를 없애 버리는 쪽이 더 낫지 않을까 하는 망상까지 하게 되지요.</description>
			<author>(아라크넹)</author>
			<guid>http://moogi.new21.org/tc/347#comment750</guid>
			<comments>http://moogi.new21.org/tc/347#comment</comments>
			<pubDate>Sat, 14 Aug 2010 04:58:10 +0900</pubDate>
		</item>
		<item>
			<title>사무엘님의 댓글</title>
			<link>http://moogi.new21.org/tc/347#comment751</link>
			<description>김재주, 아라크넹: 그렇죠. % 문자를 해석하는 일도 만만한 작업이 아닐 텐데, C++ iostream은 지금보다 더 똑똑한 최적화가 아쉽습니다.
하지만 현실에선... 속도는 그렇다 치더라도 code bloat도 말씀하셨듯이 너무 심해요. 복잡한 추상화 계층 때문이겠죠.</description>
			<author>(사무엘)</author>
			<guid>http://moogi.new21.org/tc/347#comment751</guid>
			<comments>http://moogi.new21.org/tc/347#comment</comments>
			<pubDate>Sun, 15 Aug 2010 01:20:12 +0900</pubDate>
		</item>
	</channel>
</rss>
