헛배웠군요...

frombc7197의 이미지

http://bookworm.pe.kr/wordpress/2005/05/10/20 에서

Quote:
main()은 C++에서는 표준에 적합한 코드이며 C언어에서는 선언이 아닌 정의로만 쓰인다면 맞는 것으로 알고 있습니다.

위의 코드보다는 void main(void)를 쓰는 개발자가 더 문제겠지요. (..) 실력이 없어서라는 말에는 동감합니다.

...

그동안 독학 하려고 산 책들이 전부 쓰레기가 되는 진귀한 경험을 했습니다.

제대로 배우려면 역시 원서를 사야 합니까?

으흑. :twisted:

Necromancer의 이미지

웹 접근성 관련 프로젝트를 하는 회사에 다니게 됐는데...
activex를 써먹어야 하니 좀 거시기 하네요.
제가 회사 중에서도 가장 말단이라 힘이 있는 것도
아니니.

물론 여기서 말하는 "웹 접근성 프로젝트"란 거는
타 브라우저나 OS를 고려하는게 아니라 장애인들이
m$ windows와 ie를 써서 홈페이지 무난하게 방문하는 걸 말하는겁니다.
특히 눈대신 귀로 정보를 입력받는 시각장애인들이 타겟이죠.
여기 위에 토론란에도 올라왔었죠.

Written By the Black Knight of Destruction

Deios의 이미지

제주대학교는 잘못된 코딩 스타일을 가르치고 있는 건가요??? ㅠㅠ
공대 교수님이 직접 쓰신 책에서도 void main(void)를 쓰고 있고...
얼마전에 들었던 수업(다른 자대 교수님)에서도 void main(void)가 쓰였습니다...

================================
http://deios.kr
$find / -perm 750 | grep girl

$

gongchoo의 이미지

뮈에서 말하고자 하는 대의는 이해가 가지만 예를 든 메인문은 좀 수긍이 되질 않는군요.

메인문의 리턴값이나 인자들의 용도를 모르고 사용한다면 문제가 되겠지만...(표준을 지켰냐 아니냐의 문제가 아니라 8) )

위에서 예를 든 메인문은 (일반 개발자 입장에서) 표준 준수를 논하는 데에는 좀 동떨어진 예라 생각됩니다.

일반 개발자보다는 차라리 컴파일러 제작자나 플랫폼 라이브러리 제작자에 대한 표준 준수를 말하는 것이라면 모를까... :D

-----------------------
좋은거 함 만들어보자...^^

wkpark의 이미지

frombc7197 wrote:
http://bookworm.pe.kr/wordpress/2005/05/10/20 에서
Quote:
main()은 C++에서는 표준에 적합한 코드이며 C언어에서는 선언이 아닌 정의로만 쓰인다면 맞는 것으로 알고 있습니다.

위의 코드보다는 void main(void)를 쓰는 개발자가 더 문제겠지요. (..) 실력이 없어서라는 말에는 동감합니다.

...

그동안 독학 하려고 산 책들이 전부 쓰레기가 되는 진귀한 경험을 했습니다.

제대로 배우려면 역시 원서를 사야 합니까?

으흑. :twisted:


뭐 그정도 가지고 쓰레기 운운하는 것은 좀 넌센스 같습니다.

이건 마치 어떤 건물의 몇개 나사 부품이 B급으로 판명나서 설계도 문제 운운하는 것과 비슷하다고 생각합니다 (아니면 좀 과장된 표현으로 :twisted: )

결국은 어떤 주어진 문제를 해결하고자 하는 것이 언어를 배우는 목적이 아닐까 합니다. (다른 것을 배우는 목적도 비슷하겠지만)
예제 많이 보시고, 다른 OSS프로젝트에 참여도 해보고, 기타 등등등 수많은 문제를 해결해 나아가다 보면 예전에 이해되지 않던 것도 이해 되게 되고, *제대로 배운다*는 것의 의미를 어떻게 이해하고 계시냐에 따라서 뭘 공부해야 할지 가닥이 잡히겠죠.
이상 허접설이었습니다~

온갖 참된 삶은 만남이다 --Martin Buber

죠커의 이미지

gongchoo wrote:
뮈에서 말하고자 하는 대의는 이해가 가지만 예를 든 메인문은 좀 수긍이 되질 않는군요.

메인문의 리턴값이나 인자들의 용도를 모르고 사용한다면 문제가 되겠지만...(표준을 지켰냐 아니냐의 문제가 아니라 8) )

위에서 예를 든 메인문은 (일반 개발자 입장에서) 표준 준수를 논하는 데에는 좀 동떨어진 예라 생각됩니다.

일반 개발자보다는 차라리 컴파일러 제작자나 플랫폼 라이브러리 제작자에 대한 표준 준수를 말하는 것이라면 모를까... :D

CN은 main의 반환형을 int가 아닌형태로 설명하는 책에서 다른 개념이나 문법을 제대로 설명하는 경우를 본적이 없습니다.

표준에 조금이나마 관심이 있다면 void main(void)가 담긴 책은 바로 버리는게 옳다는 것을 동의하시게 될겁니다.

kihongss의 이미지

이전 문법들이 구 문법인것을 알면 그만입니다.
여러가지 여건상 항상 C99를 지원하는 최신 컴파일러를
사용할수는 없는 노릇이니까요.
그때그때 맞춰가야죠.

gongchoo의 이미지

CN wrote:
gongchoo wrote:
뮈에서 말하고자 하는 대의는 이해가 가지만 예를 든 메인문은 좀 수긍이 되질 않는군요.

메인문의 리턴값이나 인자들의 용도를 모르고 사용한다면 문제가 되겠지만...(표준을 지켰냐 아니냐의 문제가 아니라 8) )

위에서 예를 든 메인문은 (일반 개발자 입장에서) 표준 준수를 논하는 데에는 좀 동떨어진 예라 생각됩니다.

일반 개발자보다는 차라리 컴파일러 제작자나 플랫폼 라이브러리 제작자에 대한 표준 준수를 말하는 것이라면 모를까... :D

CN은 main의 반환형을 int가 아닌형태로 설명하는 책에서 다른 개념이나 문법을 제대로 설명하는 경우를 본적이 없습니다.

표준에 조금이나마 관심이 있다면 void main(void)가 담긴 책은 바로 버리는게 옳다는 것을 동의하시게 될겁니다.

'main의 반환형을 int가 아닌형태로(만?) 설명하는 책'은 저도 본 적이 없지만 반환형을 void로 한 샘플들은 수없이 봐왔습니다. :wink:

표준에 관심이 없지 않은 사람으로서 'void main(void)가 담긴 책은 바로 버리는게 옳다'는 데에는 동의를 못하겠네요...

저도 'main(){...}'처럼 사용하는 것은 구식이고 새롭게 정의되는 개념에 걸맞지 않다고 알고 있지만, 'void main(void){...}'가 더 문제있다는 말은 금시초문입니다.

'형'지정 없이 사용되던 반환값과 인자를 구체적으로 '형'을 명시하는 방향으로 바뀐 것 아닌가요? 반환값이 없으면 void...뭐가 문제죠?

PS:

참고로 마소의 main문은 'int main( int argc, char *argv[ ], char *envp[ ] );'입니다.
표준에서 좀 확장 시켰는데, 만약 마소가 컴파일러나 플랫폼 라이브러리에서 마지막 인자를 꼭 사용하게끔 구성했다면 표준을 지키지 않았다고 지탄 받을 꺼리가 하나 더 추가됐을 겁니다.

-----------------------
좋은거 함 만들어보자...^^

죠커의 이미지

gongchoo wrote:
CN wrote:
gongchoo wrote:
뮈에서 말하고자 하는 대의는 이해가 가지만 예를 든 메인문은 좀 수긍이 되질 않는군요.

메인문의 리턴값이나 인자들의 용도를 모르고 사용한다면 문제가 되겠지만...(표준을 지켰냐 아니냐의 문제가 아니라 8) )

위에서 예를 든 메인문은 (일반 개발자 입장에서) 표준 준수를 논하는 데에는 좀 동떨어진 예라 생각됩니다.

일반 개발자보다는 차라리 컴파일러 제작자나 플랫폼 라이브러리 제작자에 대한 표준 준수를 말하는 것이라면 모를까... :D

CN은 main의 반환형을 int가 아닌형태로 설명하는 책에서 다른 개념이나 문법을 제대로 설명하는 경우를 본적이 없습니다.

표준에 조금이나마 관심이 있다면 void main(void)가 담긴 책은 바로 버리는게 옳다는 것을 동의하시게 될겁니다.

'main의 반환형을 int가 아닌형태로(만?) 설명하는 책'은 저도 본 적이 없지만 반환형을 void로 한 샘플들은 수없이 봐왔습니다. :wink:

표준에 관심이 없지 않은 사람으로서 'void main(void)가 담긴 책은 바로 버리는게 옳다'는 데에는 동의를 못하겠네요...

저도 'main(){...}'처럼 사용하는 것은 구식이고 새롭게 정의되는 개념에 걸맞지 않다고 알고 있지만, 'void main(void){...}'가 더 문제있다는 말은 금시초문입니다.

'형'지정 없이 사용되던 반환값과 인자를 구체적으로 '형'을 명시하는 방향으로 바뀐 것 아닌가요? 반환값이 없으면 void...뭐가 문제죠?

PS:

참고로 마소의 main문은 'int main( int argc, char *argv[ ], char *envp[ ] );'입니다.
표준에서 좀 확장 시켰는데, 만약 마소가 컴파일러나 플랫폼 라이브러리에서 마지막 인자를 꼭 사용하게끔 구성했다면 표준을 지키지 않았다고 지탄 받을 꺼리가 하나 더 추가됐을 겁니다.

main()은 int main(void)와 호완되는 형이라서 오히려 문제가 덜합니다. void main()은 turbo C 유저이거나 main이 반환이 없다고 자의적으로 해석한 유저 둘 중의 하나입니다. 전자와 후자가 쓴 책을 몇번 본적이 있는데 둘다 표준 C 90이나 95를 모르거나 오해하고 있었습니다. 잘못된 정보를 학습하는 일은 큰일이라고 생각합니다. 상당 수 사람들은 자신들이 잘못 알게 된 내용을 갱신하지 않거든요.

왜 void main(void)가 안되는지는 KLDP에서도 몇 차례 나왔던 이야기였던 걸로 기억합니다. 잘못된 정보가 워낙 널리 퍼져 있어서 또 나오는 것이겠지요.

덧붙여 PS로 언급하신 main 형태는 Unix 계열에도 비슷합니니다. 그런 형태는 여느 플랫폼에서나 옵션으로 제공하는 것입니다.

gongchoo의 이미지

CN wrote:
gongchoo wrote:
CN wrote:
gongchoo wrote:
뮈에서 말하고자 하는 대의는 이해가 가지만 예를 든 메인문은 좀 수긍이 되질 않는군요.

메인문의 리턴값이나 인자들의 용도를 모르고 사용한다면 문제가 되겠지만...(표준을 지켰냐 아니냐의 문제가 아니라 8) )

위에서 예를 든 메인문은 (일반 개발자 입장에서) 표준 준수를 논하는 데에는 좀 동떨어진 예라 생각됩니다.

일반 개발자보다는 차라리 컴파일러 제작자나 플랫폼 라이브러리 제작자에 대한 표준 준수를 말하는 것이라면 모를까... :D

CN은 main의 반환형을 int가 아닌형태로 설명하는 책에서 다른 개념이나 문법을 제대로 설명하는 경우를 본적이 없습니다.

표준에 조금이나마 관심이 있다면 void main(void)가 담긴 책은 바로 버리는게 옳다는 것을 동의하시게 될겁니다.

'main의 반환형을 int가 아닌형태로(만?) 설명하는 책'은 저도 본 적이 없지만 반환형을 void로 한 샘플들은 수없이 봐왔습니다. :wink:

표준에 관심이 없지 않은 사람으로서 'void main(void)가 담긴 책은 바로 버리는게 옳다'는 데에는 동의를 못하겠네요...

저도 'main(){...}'처럼 사용하는 것은 구식이고 새롭게 정의되는 개념에 걸맞지 않다고 알고 있지만, 'void main(void){...}'가 더 문제있다는 말은 금시초문입니다.

'형'지정 없이 사용되던 반환값과 인자를 구체적으로 '형'을 명시하는 방향으로 바뀐 것 아닌가요? 반환값이 없으면 void...뭐가 문제죠?

PS:

참고로 마소의 main문은 'int main( int argc, char *argv[ ], char *envp[ ] );'입니다.
표준에서 좀 확장 시켰는데, 만약 마소가 컴파일러나 플랫폼 라이브러리에서 마지막 인자를 꼭 사용하게끔 구성했다면 표준을 지키지 않았다고 지탄 받을 꺼리가 하나 더 추가됐을 겁니다.

main()은 int main(void)와 호완되는 형이라서 오히려 문제가 덜합니다. void main()은 turbo C 유저이거나 main이 반환이 없다고 자의적으로 해석한 유저 둘 중의 하나입니다. 전자와 후자가 쓴 책을 몇번 본적이 있는데 둘다 표준 C 90이나 95를 모르거나 오해하고 있었습니다. 잘못된 정보를 학습하는 일은 큰일이라고 생각합니다. 상당 수 사람들은 자신들이 잘못 알게 된 내용을 갱신하지 않거든요.

왜 void main(void)가 안되는지는 KLDP에서도 몇 차례 나왔던 이야기였던 걸로 기억합니다. 잘못된 정보가 워낙 널리 퍼져 있어서 또 나오는 것이겠지요.

덧붙여 PS로 언급하신 main 형태는 Unix 계열에도 비슷합니니다. 그런 형태는 여느 플랫폼에서나 옵션으로 제공하는 것입니다.

좀 난감하군요... 불필요한 오해가 없길 바라면서 글을 적겠습니다.

첫째
'void main(void){...}'가 표준에 어긋나지 않는다는 주장을 하는 것이 아닙니다.

둘째
'main(){...}'과 같이 '형'을 지정하지 않을 경우 기본형인 int형으로 자동 지정되지만, 그런 코드는 C90에서도 이미 구식으로 명시하고 있지 않습니까?
C99도 아직 과도기이고 과거에 void형이 생겨난 이유를 좀 생각해 본다면... main함수 형을 void로 명시하는 것 보다 더 안좋은 사용법이라 봅니다.

셋째
PS로 언급한 것이 잘못 전달된 것 같습니다.
'마소에는 이런 것도 있다'는 뜻으로 자랑한 게 아닙니다.
'만약 (누군가)가 컴파일러나 플랫폼 라이브러리에서 (표준이 아닌 main 문만)을 꼭 사용하게끔 구성했다면, 표준을 지키지 않았으므로 지탄 받아 마땅하다'로 이해해주시면 고맙겠습니다.
또한, '현재 'void main(void){...}'를 사용한 일반적인 코드를 놓고 표준 준수냐 아니냐를 논하는 것은 무리고, 표준 비준수를 이유로 쓰레기 취급 받을 이유는 더더욱 없다'는 것이 제가 말하고자 하는 바입니다.

PS:
'일반적인 코드'의 정의가 뭐냐에 대한 논란의 여지가 있겠군요... 그냥 제가 아는 범위 안에서라고 하겠습니다.

-----------------------
좋은거 함 만들어보자...^^

죠커의 이미지

void main(void)는 C90에 의해 선택되지 못했고 int의 생략은 C99에서 금지되어 있습니다. C90에서 main의 형을 규정했지만 implicit int는 금지하지 않았고 나중에 C99에 와서야 금지시킨 것이지요. 최초의 C언어 표준에서 조차 undefine된 형태를 사용하는 것이 implicit int보다 더 해악이 크다는 주장은 도저히 이해하기 힘들군요. 특히나 아직 C99가 널리 사용되지 않는 상황에서 C90에 금지된 것과 C99에 금지된 것 중 어느 것이 해악이 큰지는 분명합니다. undefined behaviour이기 ㅤㄸㅒㅤ문에 표준 준수냐 아니냐를 논하느냐는 주장은 의미가 없습니다.

처음부터 잘못가리키는 것은 오히려 안 가르키는 것만 못하다고 봅니다. 내 경험으로는 int main()조차 제대로 가르키지 못하는 서적이 다른 것을 제대로 가르키는 경우를 거의 본적이 없기 때문에 이런 이야기를 드리는 것입니다.

futari의 이미지

CN wrote:
처음부터 잘못가리키는 것은 오히려 안 가르키는 것만 못하다고 봅니다. 내 경험으로는 int main()조차 제대로 가르키지 못하는 서적이 다른 것을 제대로 가르키는 경우를 거의 본적이 없기 때문에 이런 이야기를 드리는 것입니다.

첫 문장에 전적으로 동의합니다.
그런데 그 다음 이야기는 약간 과도한 것이 아닌가 합니다.
int main()이 중요하지 않은건 아니지만 수학에서의 더하기 같은 것도 아니고, 딱히 기초라고 하기도 힘들구요. 저걸 잘 못 배워서 잘 못 알았다고 해서 그 사람이 쓴 책이 전혀 볼 가치가 없다고 하긴 힘들겠지요.
더군다나 개인적인 경험으로 세상 많은 책들을 무용지물로 만드는 것도 과도한 것 같구요.
즐거운 예는 아니지만 예를 들어 CN님이 "가르치다"와 "가리키다"를 제대로 알고 있지 못해서 "가르키다"라고 했다고 해서 CN님의 문장은 봐 줄 가치가 없다고 하는건 잘못이지요. 그 부분을 잘 몰랐을 뿐 다른 부분은 잘 알고 있을 수 있습니다.
책 쓰는것도 맘대로 되는게 아니더군요. 놓치는 부분도 많이 있을 수 있구요. KLDP에도 책 몇권씩 내신 분들도 계실텐데 몇부분 틀렸다고 해서 쓰레기 생산자로 취급해버리면 슬픈 일이죠. 정말로 쓰레기를 만들어 내 버리는 경우도 있지만요. 그런건 스스로도 알테지만..

-------------------------
The universe is run by the complex interweaving of three elements: matter, energy, and enlightened self-interest.
- G'kar, Babylon 5

uriel의 이미지

위에서도 나온 말입니다만 지금 main 주제가 나오는 이유는 main 자체는 사실 사소한 것이지만 문제는 저런 것도 신경 안쓰는 책은 다른 부분에서도 문제가 생길 가능성이 더 높기 때문이죠.

hyperhidrosis의 이미지

위에서 오타를 언급 하셨습니다만, 실제로 오타가 많은 책은
내용도 쓸모 없는 경우가 많았습니다.

마찬가지로 기초적인 main() 에 대한 설명도 제대로 못하는 책은
그 내용도 엉망일 "가능성" 이 높다고 생각 합니다.

eou4의 이미지

OS없는 것들을 많이 하다보니..

표준인지도 몰랐습니다.. :oops:

ㅎㅁㅎ

죠커의 이미지

futari wrote:
CN wrote:
처음부터 잘못가리키는 것은 오히려 안 가르키는 것만 못하다고 봅니다. 내 경험으로는 int main()조차 제대로 가르키지 못하는 서적이 다른 것을 제대로 가르키는 경우를 거의 본적이 없기 때문에 이런 이야기를 드리는 것입니다.

첫 문장에 전적으로 동의합니다.
그런데 그 다음 이야기는 약간 과도한 것이 아닌가 합니다.
int main()이 중요하지 않은건 아니지만 수학에서의 더하기 같은 것도 아니고, 딱히 기초라고 하기도 힘들구요. 저걸 잘 못 배워서 잘 못 알았다고 해서 그 사람이 쓴 책이 전혀 볼 가치가 없다고 하긴 힘들겠지요.
더군다나 개인적인 경험으로 세상 많은 책들을 무용지물로 만드는 것도 과도한 것 같구요.
즐거운 예는 아니지만 예를 들어 CN님이 "가르치다"와 "가리키다"를 제대로 알고 있지 못해서 "가르키다"라고 했다고 해서 CN님의 문장은 봐 줄 가치가 없다고 하는건 잘못이지요. 그 부분을 잘 몰랐을 뿐 다른 부분은 잘 알고 있을 수 있습니다.
책 쓰는것도 맘대로 되는게 아니더군요. 놓치는 부분도 많이 있을 수 있구요. KLDP에도 책 몇권씩 내신 분들도 계실텐데 몇부분 틀렸다고 해서 쓰레기 생산자로 취급해버리면 슬픈 일이죠. 정말로 쓰레기를 만들어 내 버리는 경우도 있지만요. 그런건 스스로도 알테지만..

아 오타가 있었군요. 감사합니다. 이미 지나갔으니 수정하지 않겠습니다만 앞으로 염두하고 써야 겠습니다.

서지훈의 이미지

frombc7197 wrote:
http://bookworm.pe.kr/wordpress/2005/05/10/20 에서
Quote:
main()은 C++에서는 표준에 적합한 코드이며 C언어에서는 선언이 아닌 정의로만 쓰인다면 맞는 것으로 알고 있습니다.

위의 코드보다는 void main(void)를 쓰는 개발자가 더 문제겠지요. (..) 실력이 없어서라는 말에는 동감합니다.

...

그동안 독학 하려고 산 책들이 전부 쓰레기가 되는 진귀한 경험을 했습니다.

제대로 배우려면 역시 원서를 사야 합니까?

으흑. :twisted:


역시나 책은 참고용 또는 교양을 위해서 필요한 것입니다.
좀 더 깊이 더 많이 알고자 한다면 이와 같은 커뮤니티 사이트를 많이 돌아 보시고 좋은글을 일고 쓰시면 종말 많이 도움이 됩니다.
가끔 정말 실력은 있다고 하는데 전혀 커뮤니티에는 관심이 없는 사람이 있는데...
정말 이건 자신의 가두고 많은 지식을 사장 하는 것입니다.
자신이 정말 많이 알고 많이 알고자 하면 더욱더 밖으로 나가야합니다.

<어떠한 역경에도 굴하지 않는 '하양 지훈'>

#include <com.h> <C2H5OH.h> <woman.h>
do { if (com) hacking(); if (money) drinking(); if (women) loving(); } while (1);

gongchoo의 이미지

CN wrote:
void main(void)는 C90에 의해 선택되지 못했고 int의 생략은 C99에서 금지되어 있습니다. C90에서 main의 형을 규정했지만 implicit int는 금지하지 않았고 나중에 C99에 와서야 금지시킨 것이지요. 최초의 C언어 표준에서 조차 undefine된 형태를 사용하는 것이 implicit int보다 더 해악이 크다는 주장은 도저히 이해하기 힘들군요. 특히나 아직 C99가 널리 사용되지 않는 상황에서 C90에 금지된 것과 C99에 금지된 것 중 어느 것이 해악이 큰지는 분명합니다. undefined behaviour이기 ㅤㄸㅒㅤ문에 표준 준수냐 아니냐를 논하느냐는 주장은 의미가 없습니다.

처음부터 잘못가리키는 것은 오히려 안 가르키는 것만 못하다고 봅니다. 내 경험으로는 int main()조차 제대로 가르키지 못하는 서적이 다른 것을 제대로 가르키는 경우를 거의 본적이 없기 때문에 이런 이야기를 드리는 것입니다.

void형은 C90에서 처음 공식적으로 도입된 걸로 압니다. 제가 알기로 'void main(void)는 C90에 의해 선택되지 못했다'는 말은 있을 수가 없습니다.

그 전까지는 함수의 반환값과 관련해서, B, BCPL에서 유전된 implicit int의 잦은 사용으로 모호한 부분이 많았다고 알고 있습니다.

implicit int로 정의된 함수에서 수식 있는 return과 수식 없는 return의 혼용이 가능하다는 점이 문제를 일으킬 여지가 많은 대표적인 모호한 부분입니다.

C95까지도 이러한 흔적은 남아있습니다. '형'이 지정된 함수에서 조차도 이런 구식 관습은 남아있습니다.

오히려 표준을 준수하지 않기로 유명한 마소의 VC에서는 이런 문제점을 비교적 일찍 해소한 것이 놀랍다면 놀라운 일입니다.

(주의해서 쓴다면 별 문제가 없는 것이지만, 그렇게 본다면 애초에 이런 토론도 의미없는 것이지요.)

이런 모호한 점을 명료하게 하고자 C90에서부터 void형을 도입하여 반환값이 없다면 void로 할 것으로 하고, implicit int는 구식 기술로 명시하고 사용하지 말 것을 권고해온 걸로 압니다.

C90에서 implicit int를 금지하지 않은 것이 아니라 기존 코드들과의 호환성을 우선시한다는 원칙 때문에 금지를 유보해왔고 C99에 와서야 비로소 결단을 내린 것입니다.

'해악'이라고까지 표현하셨지만(중간에 한번 거꾸로 표현하셨지만), implicit int라는 구시대적 관습은 분명 문제점을 안고 있고 이런 문제점은 80년대부터 논의가 있었습니다.

'void main(void){...}'는 분명 현재 표준에 맞지 않는 표현입니다. 하지만 '해악'이라고까지 생각되는 건 없군요. 오히려 implicit int로 표현하는 것 보단 현재 표준에서 권장하는 바에 걸맞습니다.

제가 보기에... 표준에 관심이 많고, 'void main(void){...}'에 이렇게 민감하게 반응하시는 분이 implicit int에는 너무 관대하신 것 같습니다.

어떤 책을 보셨는지 모르겠지만 implicit int로 함수를 기술한 책중 '다른 것을 제대로' 가르치는 책을 추천해주시면 고맙겠습니다. 문법적인게 되겠죠...? :wink:

-----------------------
좋은거 함 만들어보자...^^

죠커의 이미지

gongchoo wrote:
void형은 C90에서 처음 공식적으로 도입된 걸로 압니다. 제가 알기로 'void main(void)는 C90에 의해 선택되지 못했다'는 말은 있을 수가 없습니다.

그 전까지는 함수의 반환값과 관련해서, B, BCPL에서 유전된 implicit int의 잦은 사용으로 모호한 부분이 많았다고 알고 있습니다.

기존에 널리 쓰여지던 main의 형태중에서 두가지 형태만이 ISO 표준에 의해 받아지게 된 것입니다. 그리고 int main(void)와 int main(int argc, char *argv[])이외의 형은 C90에서 정의되지 않은 행동을 유발한다고 기록이 되었습니다. 그래서 void main(void)가 선택되지 못했다고 이야기 한것입니다. 여기에 무슨 문제가 있나요?

C99에서 implicit int의 제거는 프로그래머들이 implicit int를 void와 같은 형태로 보아서 return없는 함수를 만들어 내었고 그것이 문제가 될 가능성이 있어서 제거해야 한다는 것이 주된 논리였습니다. 현재 대부분의 C 컴파일러와 프로그램이 C90을 위주로 하고 있습니다. 어느 쪽이 표준에 맞지 않은 프로그램인가요?

foo의 이미지

조금 원론적인 얘기를 해보겠습니다.

왜 main()이 리턴값을 그것도 int로 가져야 하느냐는 얘기인데,
예를 들어 유닉스상에서 여러 프로그램을 조합한 스크립트를 만들었다고 합시다.
처음 프로그램 실행 되고 그 다음 프로그램을 실행할 때 첫번째 프로그램이 제대로 실행되었는지 그렇지 않은지에 따라 분기를 해야 하는 경우가 생깁니다.

유닉스의 철학이 덩치큰 커다란 프로그램을 만드는 것이 아닌 제 역할만 하는 작은 프로그램을 batch로 실행시키는 경우가 많으므로, 위와 같은 경우를 위해서 모든 프로그램들은 return값을 그것도 int로 가져야 하는 것은 실행 결과에 따른 분기를 하기 쉽도록 만들어줍니다.

그런데 main()이 리턴하는 값이 없게되면(void) 문제가 발생할 소지가 있는것이겠죠. 그래서 main은 무조건 return을 하도록 표준에서 규정하게 된 것이겠죠. 이건 최소한도의 규정일 뿐입니다. 정상종료를 했을 경우 1을 하라거나 0을 하라거나 -1로 하라는 규정은 없습니다. 나머지는 관습대로 플밍하게 되겠죠.

int main()은 최소한의 규정일 뿐이고 그만큼의 가치만 가질 뿐입니다.
그런 점에서 최근 Linus가 spec에 관해 한 말은 눈여겨볼만 하다고 생각합니다. (그다지 연관성 없다고 생각하실 지 모르겠지만, 어떤 정해진 규칙/spec은 그것이 있어야 하는 이유만큼만의 가치를 가질 뿐입니다. 만약, spec이 실제 상황을 고려하지 않은 경우가 있다면
spec이 쓰레기가 되는 경우도 있게됩니다. 예를 들어 int main()이라고 선언해놓고서 정상적인 종료인데 return을 0을 한 경우도 있고 -1을 한 경우도 있고 그 둘이 모두 정상적으로 종료되었다는 것을 나타낸다고 하면, 이 프로그램을 쓰는 사람들은 batch를 짤때 상당히 난감해 하게 될 것입니다. spec을 따른 프로그램이 spec의 의도를 파악하지 못한경우가 되겠죠.)

http://kerneltrap.org/node/5725

cppig1995의 이미지

C99 표준에 의하면 main에서 return문을 생략할 수 있지 않나요?
하지만 void로 하면 안되는 이유는 calling covention 때문으로 알고 있습니다.

Real programmers /* don't */ comment their code.
If it was hard to write, it should be /* hard to */ read.

죠커의 이미지

foo wrote:
그런데 main()이 리턴하는 값이 없게되면(void) 문제가 발생할 소지가 있는것이겠죠. 그래서 main은 무조건 return을 하도록 표준에서 규정하게 된 것이겠죠. 이건 최소한도의 규정일 뿐입니다. 정상종료를 했을 경우 1을 하라거나 0을 하라거나 -1로 하라는 규정은 없습니다. 나머지는 관습대로 플밍하게 되겠죠.

0과 EXIT_SUCCESS, EXIT_FAILURE를 반환하도록은 되어 있습니다. 그 값이 어떤 값인지 규정되어 있지 않으니 배치 프로그래밍에서 이용할 경우 배치 프로그래밍의 이식성은 없겠군요.

cinsk의 이미지

C 언어 표준 (ISO C, C99)에 따르면, EXIT_SUCESS나 0을 리턴할 경우, 성공적인 종료로 인식하게 되고, EXIT_FAILURE를 쓰게 되면 실패한 종료로 인식하게 되며, 이 외의 값을 쓰면 implementation-defined behavior가 발생합니다.

Single UNIX 표준 (POSIX로 알려진..)에 따르면, shell 명령 test(1)는 주어진 expression의 exit status가 0인 경우 참으로 여긴다고 나와 있습니다.

물론 이것이 EXIT_SUCCESS가 0이라는 보장은 아닙니다. 또 모든 시스템이 Single UNIX 표준을 따른다고 할 수 있는 것도 아니기 때문에 항상 참이라고 할 수는 없지만, 적어도, 상대적으로 이식성이 높은 프로그램을 작성하려면, 그리고 CN님이 말씀하신 배치 프로그래밍에 이용될 것을 감안한다면,

대부분의 시스템에서 EXIT_SUCCESS는 0으로 구현되어 있을 것이며,
main()에서 0 또는 EXIT_SUCCESS를 써야, test(1)이 참으로 인식해서 후에 shell script 등에서 올바르게 쓰일 수 있습니다.

foo의 이미지

cinsk wrote:
C 언어 표준 (ISO C, C99)에 따르면, EXIT_SUCESS나 0을 리턴할 경우, 성공적인 종료로 인식하게 되고, EXIT_FAILURE를 쓰게 되면 실패한 종료로 인식하게 되며, 이 외의 값을 쓰면 implementation-defined behavior가 발생합니다.

Single UNIX 표준 (POSIX로 알려진..)에 따르면, shell 명령 test(1)는 주어진 expression의 exit status가 0인 경우 참으로 여긴다고 나와 있습니다.

물론 이것이 EXIT_SUCCESS가 0이라는 보장은 아닙니다. 또 모든 시스템이 Single UNIX 표준을 따른다고 할 수 있는 것도 아니기 때문에 항상 참이라고 할 수는 없지만, 적어도, 상대적으로 이식성이 높은 프로그램을 작성하려면, 그리고 CN님이 말씀하신 배치 프로그래밍에 이용될 것을 감안한다면,

대부분의 시스템에서 EXIT_SUCCESS는 0으로 구현되어 있을 것이며,
main()에서 0 또는 EXIT_SUCCESS를 써야, test(1)이 참으로 인식해서 후에 shell script 등에서 올바르게 쓰일 수 있습니다.


저는 그냥 exit 0;를 주로 썼는데, 조금 확인해보니 EXIT_SUCCESS를 0으로 구현해놓을 가능성이 매우 높군요

http://www.opengroup.org/onlinepubs/009695399/functions/exit.html

EXIT_SUCCESS, which is required to be zero

$ grep EXIT_SUCCESS /usr/include/*h
/usr/include/stdlib.h:#define   EXIT_SUCCESS    0       /* Successful exit status.  */

HelloWorld 프로그램 짤때마다 #include <stdio.h>만을 넣었는데, exit(EXIT_SUCCESS);를 넣어야 된다면 <stdlib.h>도 include해야겠네요.

그리고,
http://www.gnu.org/fun/jokes/helloworld.html
에 보니 다음과 같이 c 예제가 되어있습니다.

New professional

 #include <stdio.h>
 
 void main(void)
 {
  char *message[] = {"Hello ", "World"};
  int i;
  for(i = 0; i < 2; ++i)
  printf("%s", message[i]);
  printf("\n");
 }
 

이런 정황을 미루어보아 void main(void)는 관습적으로(아무 생각 없이) 자주 쓰여왔던 것 같군요..
encoguy의 이미지

이런 댓글을 잘 못 달았네요

지나간 쓰레스에 수면위로 살짝 올려서 죄송합니다;