MS Visual Studio 이대로 좋은가?

magingax의 이미지

VS 6.0 부터 사용중인데..이게 새버젼이 나올때 마다 고생시키내요. 전 버젼에서 개발한 코드들이 꽤많은 수정 없이 신버젼에서 컴파일 안되는군요.
그동안은 어떻게 꾸역꾸역 참고 넘어 갔는데..VS2005 -> VS2008 로 가면서 너무 많이 바뀌고 표준 C 함수들을 _s 가 붙은
마소 전용함수로 바꾸라고 난리치는 바람에 홍역을 치르는중.
거기다 STL 함수들에 내부구조가 빠뀌어서 끊임없이 exception 을 토해내고있습니다.
어떻게들 생각하시는지..

klara의 이미지

표준 함수를 지멋대로 deprecate시킨 건 좀 그렇지만, 아예못쓰는 것은 아니니...
그보다, STL의 내부구조가 바뀐게 문제가 된다는건 좀 이상하네요.
혹시 표준에 명세되있지 않은, VC++에서만 구현된 것으로 이용하신 것은 아니신가요...?
그나저나 visual studio가 아니라 visual C++에 대한 내용이네요...

cppig1995의 이미지

그냥 전처리 조건문으로 컴파일러를 조사하신 후 상큼하게 #pragma warning(disable:996)을 때려 주세요.
그런데 STL의 내부 구조 변경 때문에 기존에 작성한 코드에서 예외가 발생한다는 것은 의외군요. 어떤 경우인지 자세히 알려주세요. (제가 해결할 능력은 없겠지만) 궁금해서요. ^^;;

※ scanf, fopen 등의 많은 표준 라이브러리 함수에 대해 'deprecated', 즉 낡았으니 사용하지 말고 안전한 고유 확장을 사용하라고 권고하여 논란이 되어 온 경고 C4996은 (2008이 아닌) Visual Studio 2005부터 발생했습니다.



한말글 프로그래밍 언어 "열정" http://me-lang.wo.tc

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

Necromancer의 이미지

저도 안 좋게 봅니다.
vs 버전이 올라가면 이전버전것은 그대로 다 지원되는 것이 아니라 뭔가 변환작업 같은것을 꼭 해줘야 합니다.

vb.net도 vs2003과 vs2005가 문법이 조금 틀립니다.
vs2003기준 vb.net 책보고 짠 소스코드가 vs2005에서 컴파일 안되는 경우가 종종 있습니다. 특히 배열 같은거 쓸때 그런일 많을겁니다.

Written By the Black Knight of Destruction

Written By the Black Knight of Destruction

feanor의 이미지

g++도 새 버전 나오면 거의 모든 오픈 소스 C++ 프로젝트들이 새 컴파일러에서 프로그램이 돌아가게 하느라 홍역을 치릅니다. C++ 컴파일러같은 복잡한 소프트웨어의 새 버전이 이전 버전과 100% 호환되리라고 생각하는 것이 너무 낙관적인 기대인 것 같습니다.

chungjs9의 이미지

오픈소스도 아니구요.
6.0에서 2005 넘어가는것도 좀 짜증났는데 2008도 심하네요.
어쩌겠습니까 MS

JuEUS-U의 이미지

VB는 5.0 때부터, VC는 6.0부터 써봤지만 (생각해보면 그 옛날에 용케 불법판을 구했군요 -_-;)
VS 버전업하면 언어를 새로 배우는 느낌이 듭니다...
실제로 VB는 계속 언어가 바뀌었고, (5 -> 6 -> .net 전부 다릅니다.)
표준이 있는 C++ 조차 VS .net 이후부터는 코딩을 제대로 못합니다...
여튼, .net 이후부터는 개인적인 목적을 가지고 써본 일이 없는 것 같습니다...

근데 .net부터 건드린 사람은 어떻게 생각하는지 궁금하군요.

noblepylon의 이미지

VS가 C++표준을 제대로 지키지 않습니까?
템플릿을 제대로 지원하는 몇 안되는 컴파일러 중의 하나로 알고 있는데요.
---
“내게 능력주시는 자 안에서 내가 모든 것을 할 수 있느니라.”(빌립보서 4:13)

---
“내게 능력주시는 자 안에서 내가 모든 것을 할 수 있느니라.”(빌립보서 4:13)

나는오리의 이미지

VC6은 98년도 버전이라 C99를 제대로 지원못했지만
VC7부터는 C99를 거의 완벽하게 지원하는걸로 알고 있습니다.

아마도 표준이 아니라 IDE툴의 사용법이 바뀌어서 그렇게 느끼신것 같네요.

winner의 이미지

지원하는 것은 // 주석 정도...

하지만 개인적으로 Visual C++를 좋아합니다.
무엇보다 성능이 좋더군요.

cppig1995의 이미지

음? 진짜요? //로 시작되는 행 주석(C++-style line comments)은 C++의 일부로서 지원하는 것이고,
_Bool이라던지 long long, long double 같은 새 자료형들도 지원하고 (_Complex와 _Imaginary는 잘 모르겠네요.)
새로운 헤더 파일 - iso646이라던지 stdint, inttypes 같은 것도 모두 지원합니다.

C99를 전혀 지원하지 않는다는 데에 대한 근거가 있으신지요?



한말글 프로그래밍 언어 "열정" http://me-lang.wo.tc

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

winner의 이미지

http://msdn.microsoft.com/ko-kr/library/ms235629.aspx

long double은 C90에서도 표준이었습니다.
다만 표준에 근거해서(?) double하고 동일하게 처리하더군요.
아마도 msvcrt.dll의 호환성 때문인 것으로 아는데 좀 당황스럽더군요.

iso646.h은 C90인지 C95에서 채택되었는지 모르겠습니다만 C99에서 확장된 부분이 있는지 모르겠군요.

inttypes.h와 stdint.h는 이상하게 제 Visual Studio 2008 Professional Edition에는 없군요.

long long은 limits.h에 최대최소가 명시되어 있는 것으로 봐서는 지원하는 모양이군요.

나머지는 test 해 보고 싶지는 않고, 그냥 믿도록 하겠습니다. ^_^
가르쳐 주셔서 감사합니다.

jj의 이미지

올바른 방향으로만 가고 있다면, 참아줘야죠... ^^;
(첨부수정: STL을 올바르게 사용했는데도 오류가 난다면, 올바른 방향은 아닌듯?)

PS. Windows는 업데이이트를 꼭 해야하지만, VS 업그레이드는 결정할 수 있는문제 아닌가요?

--
Life is short. damn short...

--
Life is short. damn short...

shint의 이미지

언젠가 누군가는
VC같은 개발툴을 개발할거 같습니다.

매일 1억명이 사용하는 프로그램을 함께 만들어보고 싶습니다.

----------------------------------------------------------------------------
젊음'은 모든것을 가능하게 만든다.

매일 1억명이 사용하는 프로그램을 함께 만들어보고 싶습니다.
정규 근로 시간을 지키는. 야근 없는 회사와 거래합니다.

각 분야별. 좋은 책'이나 사이트' 블로그' 링크 소개 받습니다. shintx@naver.com

codebank의 이미지

VC가 아니라 VS아닌가요? 그리고 그러한 개발툴은 이미 나와있습니다.
DEV-C++이라든가 그것을 발전시킨 code::blocks 같은 훌륭한 개발툴이 나와있긴합니다.
DEV-C++은 현재 개발이 중지되어있지만...
code::blocks를 이용해서 개발을 해봤는데 약간의 불편함은 있지만 상당히 편리하더군요.
특히나 플랫폼을 구별하지 않아서 저처럼 취미로 개발하는 사람들에게는 비싼돈 들여서 VS같은
개발툴을 구입할 필요도 없어서 더 좋은것 같습니다. ^^
------------------------------
좋은 하루 되세요.

------------------------------
좋은 하루 되세요.

codebank의 이미지

제가 공식적으로 사용해본 개발툴은 VS 6.0이 전부입니다.
들리는 소문에 의하면 VS 2003, 2005, 2008이 나왔다고는 하지만 가격이 너무비싸서
개인적인 용도로 구입하기에는 감당이 안되더군요.
VS 2008의 공개버젼이라고 있다고해서 설치해봤는데 VS 6.0과는 너무 많은 차이가있고
관리 파일자체도 변하고 메뉴도 너무 복잡해지고 단축키도 바뀐거 같고 결정적으로 과거
VS 6.0으로 만든 프로젝트를 변환했더니 많은 경고와 몇몇에러는 쉽게 포기하도록 유도
하더군요.
저야 어차피 취미로 하는 부분이니 속편하게 공개용 개발툴을 사용하는 편입니다.
그런것보면 회사에서 VS 버젼이 바뀌는 2~3년마다 개발툴을 바꾸는 개발자들은 2~3년마다
똑같은 일을 반복해야하는 고통이 있겠군요.

그래도 개발툴이 버젼업될 때마다 바꿔 주는 회사도 상당히 좋은 회사가 아닌가 생각되네요.
------------------------------
좋은 하루 되세요.

------------------------------
좋은 하루 되세요.

sandy의 이미지

..글쎄요
VS 6.0으로 만든 프로젝트를 변환했을때의 많은 경고와 몇몇에러가
그렇게 쉽게 포기하도록 유도할만큼은 아니던데요?

약간의 검색과 조금의 고민만 있으면
대부분 해결되었습니다.제 경우엔.

..

codebank의 이미지

물론 해결은 가능하겠지요. ^^
하지만 저는 예전에 생각했던 행동을 반복적으로 한다는 것은 별로 효율적이지 않다고 생각하고 있습니다.
제가 오픈소스를 좋아하는 이유중에 하나도 어렵게 만든 코드를 다른사람들과 공유할 수 있기 때문이기도
합니다.

어쨌든 문제의 요점은 2008에 맞춰서 같은 동작을하는 다른 코드를 만들기는 귀찮아서 싫다는 개인적인
이유라는 것이죠.(차라리 전혀 다른 언어로 변환하는거라면 모르겠지만요...)

그걸로 밥벌어먹어야만한다면 어쩔 수 없이 해결하겠지만 그렇지 않은이상에는 뭐 별로 신경쓰고 싶지않는
부분이기도 합니다.
아~ 그리고 VS 2008(2005 버젼도 그렇다고 들었습니다.)에서 작성된 실행파일은 무슨 매니인가 뭔가가
있어야 실행이 가능하다고 하더군요. 많은 자료는 찾아보지 않았지만 VS 6.0은 그냥 실행파일만 있어도
되었는데 무슨 그런 제한기능까지 걸어두는지하는 의문에서 작은 테스트를 해보니 진짜 인스톨하지 않으면
실행도 안되더군요.(물론 피해가는 방법도 찾았지만... :-))
어쨌든 이런저런 이유들이 있기 때문에 결정적으로 너무 비싸고 제가 사용하는 5년전 컴퓨터에서는 너무
실행속도가 느려서 포기했습니다. :-)
------------------------------
좋은 하루 되세요.

------------------------------
좋은 하루 되세요.

danskesb의 이미지

VC++ 6.0의 IDE는 그 이후 버전의 IDE보다 편하다고 생각하는 사람이 많은데, VC++ 6.0의 컴파일러는 그 이후 버전의 컴파일러보다 좋다고는 말할 수 없겠습니다.

그래서 새로운 버전의 컴파일러가 아무리 많은 기능을 지원하고 버그가 고쳐졌다고 해도 그놈의 IDE 때문에 못 올라가는 거 아닌가 생각합니다.
---- 절취선 ----
http://blog.peremen.name

JuEUS-U의 이미지

100% 동감입니다 -ㅅ-)/

그리고 신버전은 솔직히 너무 무겁습니다.
간단한걸 테스트 해볼래도 육중한 몸을 끌고나오니.....
VS를 키면 코딩밖에 못합니다... orz (과장..)

M.W.Park의 이미지

migration tool도 없이 눈물흘리며 노가다 해야하는 건가요?
만약 그렇다면 이상한 기능 탑재보다는 개념부터 탑재해야겠군요.

-----
오늘 의 취미는 끝없는, 끝없는 인내다. 1973 法頂

-----
오늘 의 취미는 끝없는, 끝없는 인내다. 1973 法頂

nbx2의 이미지

당연히 migration은 자동으로 돼죠.

얼마전에 VC6.0으로 된 프로젝트를 VS2008로 변환하는 작업을했습니다.
코드량은 대략 10만줄 정도인 프로젝트였습니다.
한 3일 노가다 뛰었습니다.

STL에서 문제가있다면 내부구조가 바꿔서 그런게 아니라
이터레이터에 대한 검사가 엄격해져서 발생하는 문제일겁니다.

아래와 같은 경우 vc6.0에선 컴파일이 되는데 vs2008에서 에러가 납니다

vector< int >::iterator it = NULL;  // 에러
it = vec1.begin();
…
int * value = it;  // 에러

전 다음과 같은방법으로 처리했습니다.
vector< int >::iterator it = vec1.end();
it = vec1.begin();
…
int * value = &(*it);

이밖에 변수스코프, 함수포인터, MFC의 사용자메시지처리 등 몇몇 부분에서 코드수정은 불가피하지만 그리 어렵지 않습니다.

오히려 프로젝트변환과정중 잠재적인 버그도 잡을수 있었습니다.