C 언어 제너릭...?
글쓴이: cleol / 작성시간: 목, 2007/03/29 - 10:36오후
C++ 약간 알고, 주로 자바 프로그래밍을 하는 사람입니다. 요새 C로 뭘 짤일이 생겼는데, 정렬 알고리즘이 필요해서 하나 짰습니다. 그런데 문제는...이거 타입이 바뀌면 일일이 다시 짜야하는건가요?
C++ 이라면 템플릿을 사용하면 되고, 자바라면 5.0 에 추가된 제너릭을 사용하거나 아님 캐스팅으로 해결할 수 있는데, C에서는 어떻게 할지 모르겠습니다.
일단 int 배열을 정렬하도록 짰는데, double 을 정렬하려니 이거 다시 짜는 것 밖에는 방법이 없어보이네요. void 포인터를 사용하는 방법도 생각해봤지만 매번 포인터를 사용해 간접적으로 접근하는 것은 효율에 문제가 있을 것 같아서요. 제법 큰 배열을 자주 정렬해야하기 때문에 효율 문제가 중요합니다. 정렬 말고도 C++ 벡터, 자바의 ArrayList 같은 녀석도 있으면 좋겠어서 int 에 대해 하나 짰는데 이것도 도무지 다른 타입으로 확장할 방법이 안보이는군요...
C를 주로 사용하시는 분들은 어떻게 처리하는지 궁금합니다.
Forums:
매크로를 쓰시면
매크로를 쓰시면 됩니다.
다음은 wikipedia에 있는 버블소트 pseudocode입니다.
procedure bubbleSort( A : list of sortable items ) defined as: do swapped := false for each i in 0 to length( A ) - 2 do: if A[ i ] > A[ i + 1 ] then swap( A[ i ], A[ i + 1 ] ) swapped := true end if end for while swapped end procedureC로 하면
void bsort(int* A, size_t sz) { int swapped; int temp; size_t i; do { swapped = 0; for (i=0; i < sz-1; ++i) { if (A[i] > A[i+1]) { temp = A[i]; A[i] = A[i+1]; A[i+1] = temp; swapped = 1; } } } while (swapped); }얘를 다시 매크로로 하면
#define BSORT(type)\ void bsort_##type(type* A, size_t sz)\ {\ int swapped;\ type temp;\ size_t i;\ do {\ swapped = 0;\ for (i=0; i < sz-1; ++i) {\ if (A[i] > A[i+1]) {\ temp = A[i];\ A[i] = A[i+1];\ A[i+1] = temp;\ swapped = 1;\ }\ }\ } while (swapped);\ } BSORT(int) BSORT(double) ... int main() { bsort_int(xx, sizeof(xx)/sizeof(xx[0])); bsort_double(xxx, sizeof(xxx)/sizeof(xxx[0])); return 0; }___________________________________
Less is More (Robert Browning)
___________________________________
Less is More (Robert Browning)
void 형으로 받아서
void 형으로 받아서 함수 내에서 캐스팅해서 쓰는게 속도 저하를 유발하나요? 제 생각엔 별 차이 없을것 같은데요. 실제로 qsort 함수도 아래와 같이 void 형으로 받으면서 원소의 개수와 사이즈, 그리고 compare 함수의 포인터를 받습니다.
#include <stdlib.h> void qsort(void *base, size_t nel, size_t width, int (*compar)(const void *, const void *));======================
BLOG : http://superkkt.com
======================
BLOG : http://superkkt.com
C에서의 타입
C에서의 타입 캐스팅은 컴파일 타임에 일어나므로 속도 저하를 유발하진 않습니다. CPU는 타입이란 걸 모르잖아요. :)
$ruby.is_a?(Object){|oriented| language} #=> true
http://rubykr.org
----
http://nohmad.tumblr.com/
우선 compare 함수
우선 compare 함수 포인터를 사용하는게 성능 저하가 있지 않나요? 그리고 어차피 타입마다 compare 함수를 다시 작성해야 한다는 점에서는 차이가 없어보입니다. 물론 비교 부분만 구현하면 되니까 알고리즘 전체를 다시 구현하는 것보다는 낫지만...적어도 int, double 같이 기본적으로 제공되는 타입에 대해서는 비교 함수를 전달하지 않아도 작동되도록 하고 싶어서요.
그건 C로
그건 C로 불가능합니다.
함수 포인터 쓰는게,
함수 포인터 쓰는게, 로드가 될정도는 아닙니다. 단순히 포인터값 하나 복사하는 정도의 로드일텐데요? 그것도 무시 못하신다면, 간단한 전처리기를 만드시는건?
--
콘쏠의힘
--
Life is short. damn short...
수만 번 이상
수만 번 이상 호출되는 함수는 호출하는 것만으로도 상당한 부하를 가져 옵니다. 컴파일러가 최적화를 얼마나 하느냐에 달리긴 했지만, 함수 안에서 레지스터의 상태를 저장하고 되돌리는 것만 생각해도 만만치는 않을 것 같습니다.
저는 매크로 삽질이
저는 매크로 삽질이 그나마 젤 나은 방법 같아보이네요..
리눅스 커널내의 리스트 구현도 매크로 삽질로 해결하는걸로 알고 있습니다.
BSD 같은 경우는 간단하게나마 에서 매크로 삽질된 자료구조를 제공해 주더군요..
glib에서 제공하는 자료구조도 괜찮은거 같던데.. 이건 gobject 를 쓰던가.. 기억이 가물가물하네요..
제기억엔 타이핑하기가 쫌 짜증났지-_-(칠게 좀 많더군요;;) 쓸만했던거 같습니다.
union 을 쓰는 것도
union 을 쓰는 것도 한가지 방법일지도... ( --);
------------------------------------------------------------
이 멍청이~! 나한테 이길 수 있다고 생각했었냐~?
광란의 귀공자 데코스 와이즈멜 님이라구~!
------------------------------------------------------------
이 멍청이~! 나한테 이길 수 있다고 생각했었냐~?
광란의 귀공자 데코스 와이즈멜 님이라구~!
meta programming 을 하시는 것이...
제 기억으로 그런 type generic 을 지원하는 C99 의 tgmath library 는 순수 C 만으로 작성하기 어렵다고 하더군요.
하여간 C 로 표현은 곤란하죠.
void 로 받아서 compare 로 처리하는게 젤 무난한데...
매클보다 코드영역도 적고...
정렬 함수하나에 각형별 compare 함수들.
유니온은
유니온은 엄청, 매우, 상당히, 대빵 느립니다.
그리고 매크로로 함수를 직접 기입하면 수정하는데 애로사항이 꽃피니깐, 간단한 쉘스크립트를 만들어서 매크로해더를 생성해서 쓰세요.
음... union이 특별히
음... union이 특별히 느린 이유가 있나요?
union이 느리다는 소리는 처음 들어서....;;
(전 원래 안써서 더 모르는지도... ( --); )
------------------------------------------------------------
이 멍청이~! 나한테 이길 수 있다고 생각했었냐~?
광란의 귀공자 데코스 와이즈멜 님이라구~!
------------------------------------------------------------
이 멍청이~! 나한테 이길 수 있다고 생각했었냐~?
광란의 귀공자 데코스 와이즈멜 님이라구~!
typeof() 가 C 표준이
typeof() 가 C 표준이 되야할텐데...
----------------------------------------------------------------------------
C Library Development Project
----------------------------------------------------------------------------
진심이시라면
C 에 어느 정도 수준의 type generic 을 원하시나요?
제가 알기로 typeof 는 C++ 에조차도 표준이 아닌데요.
저는 macro 를 대체할만한 수준이 있으면 좋겠다는 생각입니다.
inline 을 받아들였듯이 말입니다.
C 언어의 정신상 typeof
C 언어의 정신상 typeof 를 받아들일 계획은 없어 보입니다. 더구나
typeof 를 지원함으로써 생기는 어려움 (단순히 typeof 를 "구현"하는
것과 이를 체계적으로 "정의하고 기술"하는 것에는 엄연한 차이가 존재
합니다) 도 무시 못할 수준입니다.
"매크로를 대체"할 수준이라고 말씀하셨는데 전처리 단계에서는 개념상
불가능합니다 (전처리기는 type 은 커녕 keyword 도 인식하지 못합니다).
결국, 전처리 이후 단계에 적용해야 된다는 이야기가 되는데, 또 다시
위의 답변이 적용됩니다. --;
--
Jun, Woong (woong at icu.ac.kr)
Web: http://www.woong.org (서버 공사중)
--
Jun, Woong (woong at gmail.com)
http://www.woong.org
그 C 의 정신이라는 것이
가능한 단순하고, 작은 언어를 목표로 한다는 것을 말하는 것이겠지요.
하지만 hosted implementation 에서 자신의 언어로 자신의 기능들을 모두 설명하지 못하는 것은 역시 문제가 아닌가 싶습니다.
tgmath 를 구현할 수 있을 정도의 기능은 필요하지 않을까요?
정확히 단순하고, 작은 언어라는 것이 단지 compiler 만을 말하는 것인가요?
전처리기 역시 분명 표준이 포함하는 것으로 알고 있습니다.
동일한 용도로 활용되는 macro 함수 swap 과 template 함수 swap 중 어느 것이 좋은지는 자명하다고 볼 때
저로서는 역시 아쉽다는 생각을 많이 합니다.
template 내에서 template 을 활용할 때 복잡성이 심각하게 증대된다는 것은 이해하지만
C 에서 많이 사용되는 macro 기능들을 대체할 수 있는 기술이 매우 아쉽습니다.
> 그 C 의 정신이라는
> 그 C 의 정신이라는 것이 가능한 단순하고, 작은 언어를 목표로 한다는
> 것을 말하는 것이겠지요.
>
C 언어는 polymorphic language 가 아님을 의미하는 것입니다.
> 하지만 hosted implementation 에서 자신의 언어로 자신의 기능들을 모두
> 설명하지 못하는 것은 역시 문제가 아닌가 싶습니다.
>
C99 이전에는 가능했다고 생각하십니까? "현실적인" 구현을 생각하면 그
이전부터 불가능했습니다. <setjmp.h> 같은 경우 거의 "모든"
implementation 에서 (inline assembly 를 사용하지 않은) C 언어만으로는
구현이 불가능합니다 - 저 역시 x86 환경에서 시도해 보았지만 floating-
point register 처리하는 부분 때문에 어셈블리어의 힘을 빌려야 했습니다.
> tgmath 를 구현할 수 있을 정도의 기능은 필요하지 않을까요?
>
typeof 나 그와 동등한 기능이 언어에 지원되면 tgmath 를 "모든"
implementation 에서 순수한 C 언어만으로 구현할 수 있다고 생각
하십니까? typeof 가 지원되는 환경에서도 tgmath 구현은 여러 가정을
바탕에 깔고 온갖 trick 을 동원하고 있습니다.
>
> 정확히 단순하고, 작은 언어라는 것이 단지 compiler 만을 말하는 것인가요?
> 전처리기 역시 분명 표준이 포함하는 것으로 알고 있습니다.
>
뭔가 오해하고 계신듯 합니다. typeof 는 type 에 대한 기능(feature)
입니다. 반면, 전처리기에는 type 이라는 것이 (전처리기 지시자에 주어진
수식 평가를 위해 매우 제한적으로 사용되는 경우를 제외하면) 존재하지
않습니다. 따라서 typeof 가 도입된다면 전처리 과정이 아닌 그 이후 과정
(표준의 translation phase 7 이후) 으로 도입되어야 합니다.
typeof 를 바라면서 전처리 과정에 도입되기를 바란다는 것 자체가
어불성설이라는 뜻입니다.
>
> 동일한 용도로 활용되는 macro 함수 swap 과 template 함수 swap 중 어느 것이 좋은지는 자명하다고 볼 때
> 저로서는 역시 아쉽다는 생각을 많이 합니다.
> template 내에서 template 을 활용할 때 복잡성이 심각하게 증대된다는 것은 이해하지만
> C 에서 많이 사용되는 macro 기능들을 대체할 수 있는 기술이 매우 아쉽습니다.
>
C++ 의 기술이 필요하면 C++ 를 쓰시면 됩니다. 왜 C 언어가 template 에
준하는 기능을 포함해야 한다고 생각하시는지 모르겠습니다. "다른 곳에서
써보니 좋으니까 여기에서도 지원되어야 한다"는 식의 사고방식은 일정한
방향을 정하고 진행되는 언어 표준화에서는 도움이 되지 않습니다.
C++0x 가 typeof 도입을 검토하고 있는(했던?) 것으로 알고 있습니다. 그
이후 C0x 에서도 typeof 도입을 검토할 수 있습니다. 하지만, 현재 진행
되는 (지극히 C 언어다운) 여러 TR 을 볼 때 과연 위원회가 typeof 에
얼마만큼의 무게를 둘지는 미지수입니다. 개인적으로는 <tgmath.h> 가
C99 표준 라이브러리로 나왔다는 것 자체가 표준 언어 상에서 typeof
도입의 가능성이 "적음"을 암시하는 일이라 생각합니다.
--
Jun, Woong (woong at icu.ac.kr)
Web: http://www.woong.org (서버 공사중)
--
Jun, Woong (woong at gmail.com)
http://www.woong.org
답변 감사합니다.
약간의 오해가 있기에 설명을(변명?) 하겠습니다.
사실 전 C++ 의 최신기술을 그렇게 잘 사용하지는 못합니다.
그리고 C++ 에 typeof 가 등장하게 되면 어떤 상황이 벌어질지 역시 가늠하지 못합니다.
따라서(그래서) C 는 물론 C++ 에 typeof 의 필요성을 주장하지는 않습니다.
제가 보기에 C++ 는 이미 충분히 복잡하고, 솔직히 복잡성을 해소하는 기술이 아니라면 좋은 기술이라고 해도 그리 달갑지 않습니다.
C0x 에 typeof 는 아무리 생각해도 무리같구요.
C++0x 의 경우 TR1에서 result_of 가 등장한 것을 보면 C++ 에서도 typeof 는 거부된 안건이 아닌가 싶습니다.
tgmath 가 typeof 가 지원이 된다해도 온갖 trick 을 써야한다니 정말 무시무시하군요. ^_^
제가 바랬던 수준은 type generic 을 위하여 현재 practice 에서 자주 쓰이는 macro 기능들에 대한 대안입니다.
표준에 전처리기가 포함된다는 이야기를 한 것은 macro 가 너무 과도하게 사용되고 있다고 생각되지만
이것은 분명 표준의 테두리 안에 있고, 올바른 code 이지만 좀더 나은 대안을 표준이 제시해줄 수 없느냐는 것이었습니다.
(물론 해결책은 전처리기에서 나오지 않아도 좋습니다.)
하지만 골수 C programmer 들에게는 이것은 문제가 되지 못한다고 생각할지 모르겠군요.
물론 다른 곳에서 써보니 좋으니까 여기에서도 지원되어야 한다는 사고방식은 좋지 않습니다.
또한 C 표준화 위원회가 지금 type generic 에 관심이 없다는 것 또한 알고 있습니다.
하지만 C 로 객체지향을 하기도 하는 등(심지어 Assembly 로도 한다고 하죠...) C++ 만이 아닌 다른 언어들과 장단점을
비교해서 결국 C 를 선택했지만 역시 아쉬운 상황이 벌어지기도 합니다. 각 언어들의 발전이 서로 영향을 주는 것도
사실이니 언젠가는(C 표준화 위원회가 할 일이 없어질 때?...) 지원할 수도 있지 않냐는 것인데...
뭐 그 때 쯤이면 아예 새로운 언어가 programming 언어의 대세를 바꿔버릴지도 모르겠죠.
에궁... 요새 C++ 에 대한 애정도 예전만 못하고 Objective C 나 공부해 볼까나?!.
한가지 Bjarne Stroustrup 이 한 말 중 결국 programming 언어는 발전하면서 거대해질 수 밖에 없다는 말은 사실이라고 생각합니다.
물론 거대해진 복잡성을 해소하고 새로운 관점으로 제작이 시작된 programming 언어도 등장하겠죠.. ^_^
> 약간의 오해가
> 약간의 오해가 있기에 설명을(변명?) 하겠습니다.
>
> 사실 전 C++ 의 최신기술을 그렇게 잘 사용하지는 못합니다.
> 그리고 C++ 에 typeof 가 등장하게 되면 어떤 상황이 벌어질지 역시 가늠하지 못합니다.
> 따라서(그래서) C 는 물론 C++ 에 typeof 의 필요성을 주장하지는 않습니다.
> 제가 보기에 C++ 는 이미 충분히 복잡하고, 솔직히 복잡성을 해소하는 기술이 아니라면 좋은 기술이라고 해도 그리 달갑지 않습니다.
> C0x 에 typeof 는 아무리 생각해도 무리같구요.
> C++0x 의 경우 TR1에서 result_of 가 등장한 것을 보면 C++ 에서도 typeof 는 거부된 안건이 아닌가 싶습니다.
>
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1705.pdf
이름을 decltype 으로 바꿔 진행중입니다. 기존 typeof 구현과는 차이가
있지만 기본 아이디어는 typeof 에 기반하고 있습니다.
>
> tgmath 가 typeof 가 지원이 된다해도 온갖 trick 을 써야한다니 정말 무시무시하군요. ^_^
typeof 를 가지고 인자의 type 만으로 호출될 함수를 결정하는 것이 쉬운
문제는 아닙니다. 더구나 C99 에서는 complex type 까지 고려해야 합니다.
간단히 사용하고 계시는 환경의 tgmath.h 를 열어보시면 어떤 트릭이
쓰이고 있는지 확인하실 수 있습니다.
> 제가 바랬던 수준은 type generic 을 위하여 현재 practice 에서 자주 쓰이는 macro 기능들에 대한 대안입니다.
"C 언어" 코드에서 어떤 매크로 기능들이 type generic 을 위해 쓰이고
있는지요? 왜 type generic 을 언어 차원에서 지원하지 않음에도
사용하려고 하는 것일까요?
사실 OP 가 질문한 내용에 대한 지극히 "C 언어다운" 답변은 명백합니다.
그 방법이 실제 코드에 사용되었을 때 전체 프로그램 성능의 bottle-neck
으로 작용할지는 실제 테스트 전에는 확신하기 어려운 부분입니다. 만약,
그렇다면 언어가 제공하는 generality 에 대한 욕심을 버리고 성능을
추구할 수도 있는 부분입니다. 두 가지를 모두 가져야 되겠다는 고집이
언어의 중요한 철학을 포기할 수 없다는 고집보다 소중한 것인지는
모르겠습니다.
탱크를 부셔야 한다면 미사일을 쓰십시오. 권총에 미사일 점화 장치를
달아달라는 요구는 무리일 수밖에 없습니다.
> 표준에 전처리기가 포함된다는 이야기를 한 것은 macro 가 너무 과도하게 사용되고 있다고 생각되지만
> 이것은 분명 표준의 테두리 안에 있고, 올바른 code 이지만 좀더 나은 대안을 표준이 제시해줄 수 없느냐는 것이었습니다.
> (물론 해결책은 전처리기에서 나오지 않아도 좋습니다.)
기막힌 아이디어를 가지고 계시다면 잘 정리해서 제안해 보시기
바랍니다. 표준은 기존에 구현된 바가 없는 새로운 기능을 섣불리 언어
정의로 편입시키길 원치 않습니다. 여러 컴파일러 벤더에 제안한 후에
받아들여지고 그만큼 여러 코드에서 가치가 인정된다면 자연스레 표준
한쪽에 자리잡고 있을 것입니다. 제가 구현한 컴파일러의 성능은 영
아니지만, 전처리기는 제법 쓸만합니다. 저한테도 알려주시면 추후 소스
공개할 때 제안하신 기능을 포함할 수 있도록 하겠습니다.
> 물론 다른 곳에서 써보니 좋으니까 여기에서도 지원되어야 한다는 사고방식은 좋지 않습니다.
> 또한 C 표준화 위원회가 지금 type generic 에 관심이 없다는 것 또한 알고 있습니다.
>
> 하지만 C 로 객체지향을 하기도 하는 등(심지어 Assembly 로도 한다고 하죠...) C++ 만이 아닌 다른 언어들과 장단점을
> 비교해서 결국 C 를 선택했지만 역시 아쉬운 상황이 벌어지기도 합니다.
>
다른 언어들과 장단점을 비교해 C 를 선택했다면 객체지향 언어가 제공하는
"장점을 어느 정도 포기하는 것"도 고려가 되었음을 의미하는 것 아닐까요?
언어를 선택할 단계일 정도로 프로젝트 초기라면 이젠 다른 언어를 "사용할
수 없어" C 언어를 선택해야만 했다는 변명이 통하는 환경이 그리 많지
않습니다.
> 각 언어들의 발전이 서로 영향을 주는 것도
> 사실이니 언젠가는(C 표준화 위원회가 할 일이 없어질 때?...) 지원할 수도 있지 않냐는 것인데...
>
언어의 발전이 서로 다른 테두리(패러다임)에서 이루어진다면 서로 영향을
주지 않을 수도, 혹은 주어서는 안 될 수도 있습니다.
--
Jun, Woong (woong at icu.ac.kr)
Web: http://www.woong.org (서버 공사중)
--
Jun, Woong (woong at gmail.com)
http://www.woong.org
C++98에서 표준인
C++98에서 표준인 것으로 알고 있습니다만...
------------------------------------------------------
In simplexitate est opportunitas. --cppig1995
"x86-64 운영체제를 만들자" 강좌: http://kldp.org/taxonomy/term/3663
2007학년도 대전월평중학교 1학년 3반 학급카페: http://103.wo.tc
Real programmers /* don't */ comment their code.
If it was hard to write, it should be /* hard to */ read.
typeid 와 typeof 는
typeid 와 typeof 는 다릅니다.
typeof 는 C++0x 를 위해 제안되어 있는 상태입니다. 진행 상태는
살펴본지가 오래 전이라 잘 모르겠군요 - 찾아보기가 귀찮네요.
--
Jun, Woong (woong at icu.ac.kr)
Web: http://www.woong.org (서버 공사중)
--
Jun, Woong (woong at gmail.com)
http://www.woong.org
댓글 달기