당연히 그렇겠지만 컴파일하시는 내용에 따라 다릅니다.
문제는 6.0은 펜티엄 4 막 시작하던 시절이라 sse2 인가 sse1 인가 까지밖에 지원안하고 그 이후에 나온 cpu 들의 성능을 못받쳐줍니다. 컴파일 옵션에서 적당히 잘 고르시면 '앗 다르다.' 하는 수준의 속도차이를 느끼기도 합니다.
이유는 간단합니다. 비쥬얼 6.0이 9x 시절 코드를 써서 호환성은 좋거든요? 근데 코드가 복잡해지면 자료 형변환이 불분명해져 버그가 많이 생겨난다고 합니다.
쉽게 말해 long int로 할거 귀찮다고 int로 설정해 놔도 컴파일러는 그냥 읽지요. 문제는 실제 구동할때 문제입니다.
dev c 같은 경우는 자료형변환 민감합니다. 짤때는 빡세도 일괄성 있게만 짠다면 자료형 때문에 문제일으켰던 기억은 없던거 같습니다.
완벽하게 코딩된 소스가 아니라면 에러처리가 엄격해서
왠만한 워닝은 에러로 나와 고생했던 기억이 납니다.
프로젝트가 중간 크기 이상이라면 2008 추천합니다.
2003 이나 2005는 생각하지 마시고 바로 2008로 넘어 오세요.
CPU 코어가 갯수가 많다면 프로젝트 셋팅에서 /MP 옵션으로 분산 컴파일로 하실 수 있습니다. 덕분에 Incredibuild 없이도 가벼운 마음으로 컴파일 할 수 있네요.
문제는 6.0은 펜티엄 4 막 시작하던 시절이라 sse2 인가 sse1 인가 까지밖에 지원안하고 그 이후에 나온 cpu 들의 성능을 못받쳐줍니다. 컴파일 옵션에서 적당히 잘 고르시면 '앗 다르다.' 하는 수준의 속도차이를 느끼기도 합니다.
어차피 C라는 프로그래밍 언어가 ANSI 표준이고...
하두 오래전에 개발되서 더 개발될것도 없고... 그래서 dev C 쓰고요. 만족합니다.
개발자들도 GCC 계열로 많이 개발하잖아요.
비쥬얼 6.0 버젼은 교육용으로나 쓰지 개발용으로 쓴다는 사람 한명도 못봤습니다.
이유는 간단합니다. 비쥬얼 6.0이 9x 시절 코드를 써서 호환성은 좋거든요? 근데 코드가 복잡해지면 자료 형변환이 불분명해져 버그가 많이 생겨난다고 합니다.
쉽게 말해 long int로 할거 귀찮다고 int로 설정해 놔도 컴파일러는 그냥 읽지요. 문제는 실제 구동할때 문제입니다.
dev c 같은 경우는 자료형변환 민감합니다. 짤때는 빡세도 일괄성 있게만 짠다면 자료형 때문에 문제일으켰던 기억은 없던거 같습니다.
어차피 애들 가르칠거 짧은 코드라면 어지간히 대충 짜도 컴파일 되주는게 좋거든요.
근데 그이후 버전인 2003 2005에서는 짤없다고 하더라구요.
그리고 visual 6.0에서 짠거 gcc에서 그대로 돌아가는 경우는 거의 없습니다.
조금씩이나마 손을 봐줘야 돌아 갈겁니다.