그런데, 여기 컴파일러 직접 만드시는 분들도 많이 계신 것 같아서
호기심에서 여쭤보는 건데요.
컴파일러에서 그런 문제를 처리해주는 것이 어려운가여?
사용자 편의성을 고려해서 컴파일러 좀 만드면
어디가 덧나나 싶어서..^^;;
전처리기랑 컴파일러랑 분리되어 있는 구조라서
좀 어려울 것 같다는 생각이 불쑥 들기도 하는군요...
모듈화와 그 trade-off 관점에서 생각해야 되는 문제인지..
원래 유닉스의 철학이 최대한 모듈화시키는겁니다. 그래서 컴파일 같은것도 전처리하고 어셈블리로 만들고 실제 링크하고 이 작업들이 분리시킨겁니다.
이런 방식의 장점은 이식이 쉽고 에러날 확률이 적어진다는겁니다.
실제로 gcc이식시에는 전처리기는 신경쓸 필요가 없습니다.
어셉블리로 만들어주는 부분만 신경쓰면 됩니다.
그리고 사용자는 이런 내부적인거 신경쓸 필요없이 그냥 gcc만 치면 끝입니다.
컴파일러가 특별히 알아서 처리하지 않는한, 정상적인 방법으론 힘듭니다.
컴파일러가 특별히 알아서 처리하지 않는한, 정상적인 방법으론 힘듭니다.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
Korean Ver: http://cinsk.github.io/cfaqs/
정작 없는 거였군여. ㅜㅜ컴파일러에서 그거 처리좀 해주면 좋겠구만.
정작 없는 거였군여. ㅜㅜ
컴파일러에서 그거 처리좀 해주면 좋겠구만.
CINSK님 그거 처리하는 컴파일러 좀 만들어주세용~~^^;;
권위를 의심할 것,어긋남을 존경할 것,자리잡기를 거부할 것,항상 자신을 재창조할 것 - MIT 미디어랩 -
매크로 함수 만들때 '잘' 만들면 됩니다. 에러메시지를 확인해야 할 정도
매크로 함수 만들때 '잘' 만들면 됩니다. 에러메시지를 확인해야 할 정도의 긴 함수를 매크로 함수로 만든다는게 이해가 안되는군요. inline 키워드도 있는데...
저 같은 경우는 preprocessor를 이용해서 다시 컴파일을 해 봅니
저 같은 경우는 preprocessor를 이용해서 다시 컴파일을 해 봅니다.
이러면 대충 어디가 에러인지 확인해 볼수 있습니다.
음... 이제 부터 생각해 봐야겠다.
아 좋은 방법 알려주셔서 감솨~inline은 저도 많이 쓰기는 합
아 좋은 방법 알려주셔서 감솨~
inline은 저도 많이 쓰기는 합니다.
그런데 굉장히 cpu-intensive 한 부분에서는
매크로랑 inline도 차이가 나는 것 같던데요.
그리고 inline은 gcc매뉴얼인가를 보면
어셈블러로 몇 라인 이상인거는 inline으로 컴파일 하지 않는다고
본 것 같기도 하구요.
혹시 이 부분에 대해 자세히 아시면 좀 알려주세요.
권위를 의심할 것,어긋남을 존경할 것,자리잡기를 거부할 것,항상 자신을 재창조할 것 - MIT 미디어랩 -
[quote="spacelee"]아 좋은 방법 알려주셔서 감솨~i
EC++ Item 33 을 보시면
라고 적혀 있습니다.
저는 inline 을 굳이 넣어서 코딩하진 않습니다. optimization 옵션을 주면 inline 키워드를 넣지 않은 코드라도 inline 했을 때 더 유리하다면 컴파일러가 inline 처리를 합니다.
성능에 관련된 문제들은 대체로 컴파일러에게 맡겨버리는게 속 편합니다.
그리고 대부분의 컴파일러들이 preprocessing 과정만을 거친 코드를 얻을 수 있는 방법을 제공합니다.
gcc 의 경우에는 cpp 라는 분리된 전처리기를 가지고 있지만, 제가 겪어본 다른 컴파일러들도 다들 옵션을 가지고 있더군요. 잘 찾아보세요 ^^;
즐겁게 살아 볼까나~*
참고로 Emacs를 쓰시면, 영역(블럭)을 지정해서, 그 부분만 prep
참고로 Emacs를 쓰시면, 영역(블럭)을 지정해서, 그 부분만 preprocessor를 돌려볼 수 있습니다. 예를 들어. 다음과 같은 코드 블럭이 있다 치고,
#include <fcntl.h> #include <unistd.h> #include <sys/types.h> #define MIN(a, b) (((a) > (b)) ? (b) : (a)) void foo(int a) { int a, b; int c; int fd; c = MIN(a, b); fd = open("/tmp/tmp.tmp", O_RDONLY | O_EXCL); }여기에서 맨 마지막에서 두 줄 (c = ... 와 fd = ...)을 영역 지정하고 C-c C-e를 누르면, 영역을 C preprocessor 처리 후, 다음과 같이 보여줍니다:
c = (((a) > (b)) ? (b) : (a)); fd = open("/tmp/tmp.tmp", 00 | 0200);C-c C-e는 M-x c-macro-expand와 같은 기능입니다.
참고하세요.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
Korean Ver: http://cinsk.github.io/cfaqs/
여러가지 좋은 정보 감사드립니다.^^그런데, 여기 컴파일러 직접
여러가지 좋은 정보 감사드립니다.^^
그런데, 여기 컴파일러 직접 만드시는 분들도 많이 계신 것 같아서
호기심에서 여쭤보는 건데요.
컴파일러에서 그런 문제를 처리해주는 것이 어려운가여?
사용자 편의성을 고려해서 컴파일러 좀 만드면
어디가 덧나나 싶어서..^^;;
전처리기랑 컴파일러랑 분리되어 있는 구조라서
좀 어려울 것 같다는 생각이 불쑥 들기도 하는군요...
모듈화와 그 trade-off 관점에서 생각해야 되는 문제인지..
권위를 의심할 것,어긋남을 존경할 것,자리잡기를 거부할 것,항상 자신을 재창조할 것 - MIT 미디어랩 -
[quote="spacelee"]여러가지 좋은 정보 감사드립니다.^^
원래 유닉스의 철학이 최대한 모듈화시키는겁니다. 그래서 컴파일 같은것도 전처리하고 어셈블리로 만들고 실제 링크하고 이 작업들이 분리시킨겁니다.
이런 방식의 장점은 이식이 쉽고 에러날 확률이 적어진다는겁니다.
실제로 gcc이식시에는 전처리기는 신경쓸 필요가 없습니다.
어셉블리로 만들어주는 부분만 신경쓰면 됩니다.
그리고 사용자는 이런 내부적인거 신경쓸 필요없이 그냥 gcc만 치면 끝입니다.
댓글 달기