inline 과 매크로의 차이점이 궁금합니다.

프로그래밍 일반에 관한 포럼입니다.

운영자: 류광

Locked
사용자 아바타
cluster
전체글: 33
가입일: 2003-07-25 10:20
사는 곳: 전세집

inline 과 매크로의 차이점이 궁금합니다.

전체글 글쓴이: cluster » 2004-03-26 18:46

제목 그대로 입니다.

어떤 건 매크로를 쓰는데 어떤 거는 inline 함수로 만들어서 쓰던데.....

차이점이 있으니 따로 만들어 놨을 것 같은데 차이점을 잘 모르겠습니다....

가르쳐 주세요~~ :)

전외솔
전체글: 518
가입일: 2002-07-03 01:24

인라인함수와 매크로함수

전체글 글쓴이: 전외솔 » 2004-03-26 19:23

인라인 함수는 정상적인 '함수'이지만 매크로 함수는 사실 함수가 아니라 컴파일 이전에 이루어지는 텍스트 치환입니다. 따라서 인라인 함수는 함수가 가질 수 있는 모든 기능 (리턴값돌려주기, 인자/리턴값에대한 형검사, 이름공간에서 이름의 적용, 오버로딩, 가변인자, 등등)을 가질 수 있지만 매크로함수는 힘듭니다.
(여기서 인라인 함수라고 부르기 보다는 '함수의 인라인 확장'이라고 부르는 것이 더 좋을 것 같습니다.)
매크로함수와 함수의 인라인확장은 너무 다른 것이기 때문에 '왜 매크로 함수가 있는데 함수의 인라인확장이 가능하도록 했을까?'하고 묻는 것은 비교하기 힘든 대상을 비교한 것이라 생각합니다.

zelon
전체글: 44
가입일: 2003-12-16 11:17
연락처:

Re: inline 과 매크로의 차이점이 궁금합니다.

전체글 글쓴이: zelon » 2004-03-26 19:43

cluster 작성: 어떤 건 매크로를 쓰는데 어떤 거는 inline 함수로 만들어서 쓰던데.....

차이점이 있으니 따로 만들어 놨을 것 같은데 차이점을 잘 모르겠습니다....
제 짧은 생각으로는 매크로를 쓰는 것은 일종의 기교랄까.. 여튼 변칙이라고 생각합니다. define 의 주된 목적은 매크로 함수를 만드는게 아니라 문자 치환이 아니었을까 생각해봅니다. ^^

그런 후 발전 단계를 거치면서 inline 과 상호 영향을 주면서 발전하는 듯 하네요^^;;

myevan
전체글: 1314
가입일: 2003-03-04 10:21
연락처:

전체글 글쓴이: myevan » 2004-03-26 22:04

원래 c언어에 매크로가 있었고
c++ 이 c언어와의 호환성을 지키면서
oop적인 기능을 붙인거기에
어쩔수 없이 공존해버리게된 산물이라고 생각합니다.

왜 그럼 굳이 매크로가 있는데 (-_-)
인라인이 생겼느냐! 물으신다면...
시간나시는데로 서점에 달려가
이펙티브 C++ 1장을 읽으시면 됩니다.

간단히 설명드리자면;
매크로는 윗분이 말씀하신것처럼 단지 전처리기
즉.. 컴파일시점에 치환되는 부분이기때문에...
몇가지 문제가 발생합니다.
흔한예가 min(a++, b) 같은 것이죠
위의 코드가 컴파일 시점에는

코드: 모두 선택

((a++)<(b)) ? (a++), (b)
형태로 바뀌기때문에 잘못된 결과를 얻을수 있습니다
이외에도 자료형 체크를 안해서 발생하는 문제라던지
등등 (-_-)... 물론 잘쓰면 되지만;; 세상에는 다양한 사람들이 있기 때문에..
그럴바에는 문제소지가 없는 인라인함수가 생기게 된것입니다
빗자루네 http://www.myevan.net >_<b

초보리베로

차이점!!

전체글 글쓴이: 초보리베로 » 2004-03-27 12:09

짧게쓸댄 매크로 쓰고 길때는 인라인 쓴다 -_-;

맞지 않아요?

길어서 인라인쓸대의 장점은.. 작성 스펙이 기존 함수와 다르지않기때문에

편리한것 같네요. 단지 inline 키워드만 제고하면 된까요.. 인라인 함수 만들고 빌드타임에

인라인을 적용할것인지 그 냥 함수로 취급할것인지 옵션으로 선택할수 있기때문에

비교해보기에도 용이한거 같군요. 인라인을 쓸때 중요한 관건이

과연 인라인을 실제 적용했을때 퍼포먼스 향상이 얼마나 있느냐~ 에 있지

않을까 싶군요. 디파인은 함수<->매크로 간의 전환이 좀 불편하니까요 아무래도.

사용자 아바타
Testors
전체글: 557
가입일: 2003-07-26 00:34
사는 곳: (주)nFlavor
연락처:

Re: 차이점!!

전체글 글쓴이: Testors » 2004-04-09 02:35

초보리베로 작성:짧게쓸댄 매크로 쓰고 길때는 인라인 쓴다 -_-;

맞지 않아요?

틀렸습니다.

매크로는 여러가지 문제점을 가지고 있기에 C++ 에서는 어지간하면 쓰지 말아야 합니다. (라고 Stroustrup 아저씨는 말하고 있습니다)

여러가지 문제가 있지만 그중 압권은

컴파일러가 코드를 읽기 전에 텍스트를 바꿔 버린다는 것입니다. - 사람이 보는 코드와 컴파일러가 보는 코드가 달라집니다. -

결과적으로 의도하지 않은 동작이 일어나거나
컴파일러가 에러를 뱉어내긴 하는데 그것으로는 도저히 뭔가 판단을 하기가 힘들게 됩니다.

뭐 요점은 버그가 발생하기가 쉬운데다 그렇게 발생한 버그를 잡기가 매우 힘들다는 것입니다.

가장 알려진 예로는 위에 소개된 max, min 같은 것이나 혹은
assert() 안에 수행코드를 넣는것들이 있겠습니다만
매크로에 대한 주의가 좀더 필요한듯 하여 다른 예를 소개해 보겠습니다.

문제 : http://testors.net/parser_bug.html

컴파일러가 뱉어내는 에러만으로는 절대 잡을수 없는 버그 입니다.

고민해 보시고 도저히 모르겠다 싶으면 아래를 참조하세요.

해답 : http://testors.net/parser_bug_answer.html

초보리베로

음...

전체글 글쓴이: 초보리베로 » 2004-04-10 11:23

윗글 예전에 대강적은거라 제 언급이 좀 경솔해보일수도 있으나.. 틀렸다고 할것까진

없다고봅니다.. 위에예를 보여주셨는데.. 매크로를 잘못사용한 사례겠죠. 물론..

잘못사용했을경우 피해는 매우 큽니다... 매크로명명하실때 앞에 d를붙이신다던지

하는 약속을정하면 그런일 만들려구 해도 만들수 있을가요? 좀 억지스러운 예같네요.

요점은.. 매크로, 인라인을 둘다 잘알고 쓰면 장단점이 있는거라는거죠. 어느한쪽이

우월하고 어느한쪽은 쓰지말라는건 절대 아니라는거죠..

명령어 1줄의 정말 짧은 코드를 일일히 인라인 함수 작성해서 하는것도 상황에따라선

낭비가 될수있다고봐요.

저는 스트럽 아저씨가 쓰지말라고해도 쓸것같군요.

일단 그부분은 프로그래머의 개인적인 코딩 성향에도 영향을 미치는 부분이니까요.

비슷한 예로 혹자는 c++에선 goto가 필요없다구 주장합니다. 그러나 상황에 따라 전 씁니다.

너무도 간단해서 굳이 헷깔릴이유도없는데 바로 goto 나 매크로를 쓰면 해결될일을

무조건적으로 쓰지말자고 선회해서 해결하는것도 에너지가 좀 아깝다고 느껴지네요

저뿐만이 아니라.. Steve Maguire라는사람도 그렇게 말하더군요.

사용자 아바타
Testors
전체글: 557
가입일: 2003-07-26 00:34
사는 곳: (주)nFlavor
연락처:

Re: 음...

전체글 글쓴이: Testors » 2004-04-10 12:44

초보리베로 작성:좀 억지스러운 예같네요.
실제 어떤 게임을 개발하면서 필드에서 일어났던 일이며 해결하는데 꼬박 이틀이 걸린 버그입니다. :)

초보리베로 작성:명령어 1줄의 정말 짧은 코드를 일일히 인라인 함수 작성해서 하는것도 상황에따라선

낭비가 될수있다고봐요.
인라인을 썼다해서 매크로에 비해서 낭비가 일어나거나 하지는 않습니다.

이것은 인라인 함수가 뱉어낸 어셈코드를 보시면 알수 있을듯..

초보리베로 작성:저는 스트럽 아저씨가 쓰지말라고해도 쓸것같군요.

일단 그부분은 프로그래머의 개인적인 코딩 성향에도 영향을 미치는 부분이니까요.
물론 개인의 스타일에 따라 다르지요. C++ 은 모든 길을 열어두고 있으니까요. ^^

제가 하고싶었던 얘기는 "짧게쓸댄 매크로 쓰고 길때는 인라인 쓰는것" 은 아니다 라는 것이었습니다. :)

초보리베로

흠... 서로 오해가 있었던거 같군요..

전체글 글쓴이: 초보리베로 » 2004-04-10 13:21

1." 실제 어떤 게임을 개발하면서 필드에서 일어났던 일이며 해결하는데 꼬박 이틀이 걸린 버그입니다. "

중복된 이름명명 문제는 비단 매크로만의 문제는 아니라고 생각합니다. 매크로이기때문이라기보다

이름이 같다는 그런 행위가 일어난것자체가 위험한거죠. 일례로. 저는 볼랜드 c++ 빌더를 사용했었는데..

제가사용하던 같은 구조체 이름을 누군가 쓰고있어서 ( ms-vc에선 중복된 이름이라고 오류지적이 되는데

이상하게도.. ) 이상한곳으로 분기하다가 뻑나는 말도안되는 경우가 일어난적이 있었습니다.. 이문제는

디버깅하는데 매우 까다로웠습니다. 볼랜드 디버거도 버그가있는지 이상한 곳으로 분기하고 결국 한참후에

디스 어셈블 코드를 하나씩 살펴본후에야 해결할수 있었죠. 요점은 중복명명의 위험함이지 그로인해

매크로까지 같이 위험하게 치부하는것은 옳지 않다고 봅니다.


2. "인라인을 썼다해서 매크로에 비해서 낭비가 일어나거나 하지는 않습니다.
이것은 인라인 함수가 뱉어낸 어셈코드를 보시면 알수 있을듯.. "

수행속도의 낭비가 아니라. 타이핑의 낭비를 지칭하는겁니다. 몇줄 차이나 난다구요? 하지만 상황에따라

매크로가 간결한 경우가 있다는 것은 사실이죠. 사실 개인 취향에 관여된 문제라고 봅니다. 제 생각에

짧을경우 그냥 #define HELLO( X ) ## 식으로 간결하게 정의할수있는 장점이 매력적이라고 느꼈기

떄문입니다.


3. "제가 하고싶었던 얘기는 "짧게쓸댄 매크로 쓰고 길때는 인라인 쓰는것" 은 아니다 라는 것이었습니다. "

매크로와 인라인의 사용자체가 개인 스타일에 관련된문제므로 짧게쓸땐 매크로 쓰고 길때는 인라인

쓰는것은 정답이 아닐지도 모릅니다. 그러나 그렇다고 제말이 틀렸다고 지적하는것도 잘못된거라고

생각합니다. 안되는 이유로 지명하신 중복명명의 문제는 매크로만의 문제가 아니기때문이고,

제가 적은 매크로를 쓴다면 짧을때 사용한다 라는 뜻은 애초부터 제 취향을 적은거니까요.

'틀렸습니다.' 보다는.. 테스터스 님의 경우에 '나는 이러이러 하니 이런식으로 쓴다.' 가 맞지 않을까요?

1+1 = 2 식의 정확한 진리가 있는 문제는 아니라고 보거든요. ^^

사용자 아바타
Testors
전체글: 557
가입일: 2003-07-26 00:34
사는 곳: (주)nFlavor
연락처:

Re: 흠... 서로 오해가 있었던거 같군요..

전체글 글쓴이: Testors » 2004-04-10 15:44

네.. 어떤것을 쓰느냐는 개인의 스타일 문제라고 생각합니다.

그런데.. ;;
초보리베로 작성: 중복된 이름명명 문제는 비단 매크로만의 문제는 아니라고 생각합니다. 매크로이기때문이라기보다 ...
제시된 예는 중복된 이름명명 문제가 아니에요.. -o-;;

매크로로 인해서 코드가 컴파일러에게 전달되기 전에 수정되었고,

그래서 컴파일러가 내는 워닝/에러는 무가치하며.. (무가치하면 그나마 다행인데 되려 오해를 불러 일으키죠)

프로그래머는 해당 코드를 보아도 버그를 발견할 수 없게 되는...

매크로에만 해당되는 문제입니다.. ;

myevan
전체글: 1314
가입일: 2003-03-04 10:21
연락처:

전체글 글쓴이: myevan » 2004-04-10 19:10

매크로 문제도 그렇고
goto 문제도 그렇고
다중 상속도 그렇고
RTTI 도 그렇고..
등등

이런것들은..
잘 써야 문제가 안 생기는 것이라는 것입니다.
이말을 다르게 표현하면-_-
잘못 사용하면 문제가 발생한다라는 것으로;;
자기는 잘 쓸지 모르지만;
다른 사람이 어떻게 쓸지는 아무도 모르기에..
사람들이 위험하다고 하는것입니다.

게다가 의외로 그런 실수들이 많이 발생하죠 -_-)/

개인작업이야 쓰던 안 쓰던
상관없지만..
공동작업이라면 조금 자제하는것이 좋습니다.
매크로쪽은 취향문제라고 할만한 사항은 아니라는 생각입니다.
빗자루네 http://www.myevan.net >_<b

은빛늑대

다중상속도 많이 안좋은가여?

전체글 글쓴이: 은빛늑대 » 2004-04-16 11:20


다중 상속도 그렇고

저 다중 상속도 문제가 돼나요?
다중 상속 없으면 많이 불편할것 같은데..

두가지를 상속 받아서..
새로운 코딩 별로 없이 새로운 클래스가 멋드러지게 만들어지는거..
전 멋지다고 생각해요.

조합(두 클래스를 포함) 하는 것은 쓸데없는 코드가 많이 들어가는 것 같아서..
만들기도 귀찮고... 아 귀차니즘..
소스가 지저분해지는 느낌...
(쓸데 없는 코드가 많이 들어가 있는걸 개인적으로 싫어해서.. )

사용자 아바타
해키스트
전체글: 398
가입일: 2004-02-14 20:11
사는 곳: N거시기
연락처:

다중상속이 문제라기보다..

전체글 글쓴이: 해키스트 » 2004-04-16 13:11

저 다중 상속도 문제가 돼나요?
다중 상속 없으면 많이 불편할것 같은데..
->상속이야 말로 프로그래머의 손발을 편하게해주는 부분이지만..
빗자루님의 말씀은 심하면 독이된다. 라는 뜻이었을거로 이해되네요.

저도 고전하고 있는 부분이지만,

'아버지에, 할아버지에, 증조 할아버지에, 고조 할아버지까지 있는 클래스를 동기화해야 한다.'
라는 문제가 발생할경우.
해당 작업자는.. 문서없인 정말 맨땅에 헤딩하는 식으로 문제를 풀어가야 합니다.
게다가 각 클래스마다 추상클래스가 아닌 구현부를 갖고있다면 피토하죠.
(쿠헤헥..=ㅠ= 피토하는중)

저같은 경우는 클래스 상속은 하되, 그 범위를 작게 잡고있습니다.(추상클래스 + 구현클래스 ->상속 한번 or 두번정도까지)
조상이 많은 클래스는 상세설계문서 없으면 뒷사람 고생시키죠:wink:

p.s 그리고 개인적으로 매크로 치환 별로 안좋아라 합니다. 가독성을 떨어뜨리거든요.
전 차라리 치환하느니 인라인쓰거나 그냥 해당 소스에 적습니다.
Quitters no win, winners no quit.

myevan
전체글: 1314
가입일: 2003-03-04 10:21
연락처:

전체글 글쓴이: myevan » 2004-04-16 14:01

글 주제에는 약간 벗어나지만;; 질문하셨길래...
제가 다중상속으로 인해 많이 겪는 괴로움의 하나는
간단한 동일 함수 명입니다 = =); 예를 들면 Clear같은 흔한 이름 함수들..
다중상속을 많이 사용하는 코드를 보면
꼭 발견하게 되더라구요.
로직상에는 아무런 이상이 없는데;
버그가 발생해서... 며칠 고생해서 보면;;
다중상속 코드라서 잘못된 함수가 호출되고 있었다던지...;;
그런 경우가 많거든요.

또한 클래스가 너무 무거워지는 현상이 발생해서..
리팩토링을 해야겠다 생각했을때..
분리하기도 애로애로해지는 (-_-);;
c++의 경우 암무적인 네임스페이스가 적용되기때문에...
편한만큼 이런 경우 필요한 노가다 량이 많아지죠; (이미 섞어서 짜놓았기때문에...;; 흑흑-_-;; )
그러니 걍 미루게 되고 소스코드는 점점 = =)~ 생명체가...;; <- 제일 두려워하는 현상.

많은 문서에 나왔지만; 다중상속을 사용하신다면..
다중상속시 베이스 클래스는 쫌 심플한 모양을 지키고 (어느정도 규모가 있는 클래스는 왠만하면 조합으로..)
네임스페이스를 활용한다라는 말은 통하지 않을테니 = =);;
메쏘드를 쫌 명확한 네이밍을 한다는 식의 (흔한 이름 사용은 자제; )
룰이 어느정도 필요합니다.
빗자루네 http://www.myevan.net >_<b

사용자 아바타
Testors
전체글: 557
가입일: 2003-07-26 00:34
사는 곳: (주)nFlavor
연락처:

전체글 글쓴이: Testors » 2004-04-16 15:37

myevan 작성:제가 다중상속으로 인해 많이 겪는 괴로움의 하나는
간단한 동일 함수 명입니다 = =); 예를 들면 Clear같은 흔한 이름 함수들..
다중상속을 많이 사용하는 코드를 보면
꼭 발견하게 되더라구요.
로직상에는 아무런 이상이 없는데;
버그가 발생해서... 며칠 고생해서 보면;;
다중상속 코드라서 잘못된 함수가 호출되고 있었다던지...;;
그런 경우가 많거든요.
다중상속시의 이름 충돌은 컴파일러가 컴파일 타임에 모호성 경고를 해줄텐데요?
이름이 같아서 잘못된 함수가 호출되는 경우는 없을듯 합니다.

myevan
전체글: 1314
가입일: 2003-03-04 10:21
연락처:

전체글 글쓴이: myevan » 2004-04-16 18:01

컴파일러 수준의 이름충돌이라기보다는;
프로그래머 수준의 이름충돌 문제인데..
원래 함수를 만들어야 하는데...
기존함수가 있는걸 보고 작성자가 착각하고 안 만들었다던지..
혹은 같은 이름있네 하고;; 그것만 이름만 바꿨다던지 식의 상황..
원래 여기서는 이걸 호출해야하는데
습관대로 이름을 호출했다던지..
등등 의외로 다양하게 황당한 실수를 하는 경우가 많더라구요. 의외로...
여러명이 같은 코드를 손대다보면 발생하는 문제중에 하나였는데..
= =) 뭐 저만 많이 겪은 걸수도 있고요 홋홋홋

사람이 실수도 할수 있고
모든 프로그래머가 여러상황대처에 빠삭할수도 없는것이고..
세세하게 하나하나 메쏘드까지 설계할수 있는게 아닌 상황이라면..
실수가 나오기 쉬운부분은
애초에 막아버리거나
룰을 확실히 하는것이 좋다고 생각합니다
빗자루네 http://www.myevan.net >_<b

은빛늑대

문란한 상속의 예..

전체글 글쓴이: 은빛늑대 » 2004-04-16 21:39

CDialogBase
-> CImage
-> CCheckBox + CText
-> CTextBox
-> CEditBox


흐흐 UI 구현 할 때 일케 했는데..

뒷사람 고생 할까여??

다 필요한 것들이라..

그래도 필요해서 다 만든 것 들이라..

괜찮을거 가튼뎅..

봐주셈.. 담부터 잘할게여..

사용자 아바타
해키스트
전체글: 398
가입일: 2004-02-14 20:11
사는 곳: N거시기
연락처:

전체글 글쓴이: 해키스트 » 2004-04-16 22:10

CDialogBase
-> CImage
-> CCheckBox + CText
-> CTextBox
-> CEditBox
이정도 가지고 다중상속이라고는 안하죠;;(아닌가?)

적어도 CMaterial->CObjectBase->CElectronicObject->CDisplay->CMonitor->CLCDMonitor
정도 상속은 받아야..=ㅁ=; 진정한 다중상속;;
Quitters no win, winners no quit.

사용자 아바타
Testors
전체글: 557
가입일: 2003-07-26 00:34
사는 곳: (주)nFlavor
연락처:

전체글 글쓴이: Testors » 2004-04-17 02:00

해키스트 작성:적어도 CMaterial->CObjectBase->CElectronicObject->CDisplay->CMonitor->CLCDMonitor
정도 상속은 받아야..=ㅁ=; 진정한 다중상속;;
위의 예는 상속계층이 깊은것이지 다중상속은 아닙니다.

자바에서는 금지되어 있고 C++ 에서는 허용된,

클래스 다중 상속(multiple inheritance) 이라 함은 아래와 같은것을 말합니다. :wink:

코드: 모두 선택

class CHannara_Dang : public CStupid, 
                      public CStink,
                      public COutlaw,
                      public CTraitor,
                      /* public CParkJungHee */ public CParkGeunHye
{
    void DoSomething()
    {
        // we love U.S.A.
        std::cout << "나라를 구하겠습니다~!" << std::endl;

        if( CDemocracy::Vote().GetWinner() == HANNARA_DANG )
        {
            ((int*)0x0) = (int)"show me the money";
        }
        else
        {
            new CClone_Of_Hannara_Dang( this );
        }
    }
};

사용자 아바타
해키스트
전체글: 398
가입일: 2004-02-14 20:11
사는 곳: N거시기
연락처:

아 좋은지적 감사합니다.

전체글 글쓴이: 해키스트 » 2004-04-17 09:16

제가 잘못 알고 있었네요 ^-^
좋은 지적 감사드립니다.

역시 Testors님 짱! =ㅅ=/

p.s 저런 방식의 상속은;; 뒤끝이 안좋았던 기억이 있네요
Quitters no win, winners no quit.

Locked

접속 중인 사용자

이 포럼을 보고 있는 사용자: 회원 0 명, 손님 4 명