c에서 c++로의 마이그레이션,포팅,전환 문제
글쓴이: spacelee / 작성시간: 월, 2005/11/14 - 2:27오후
현재 제가 처한 상황은 다음과 같습니다.
<requirement>
1. c로 구현해놓은 전체 소프트웨어 양이 엄청나다.
2. c++로 가고싶다.
3. 전체 소스를 c++로 한번에 포팅할 시간이 없다.
4. 전체 소프트웨어는 유지하고 계속 사용하면서
점진적으로 c++로 이동하고 싶다.
새로 추가, 작성하는 소스는 c++형태로 짜고 싶다.
<해결책>
1. 일단 컴파일러만 c++로 바꾸고 에러가 안나도록
전체 소스를 고친다. (별 에러가 없도록)
새로 추가하는 소스는 c++로 간다.
2. 기존 소스는 c로 컴파일 하고 새 소스는 c++로 컴파일해서
둘이 링크만 한다.
(안정성등의 문제가 없는지?)
3. 기타??
이런 비슷한 경험이나 지식이 있으시면
많은 조언 부탁드립니다.
c에서 c++로의 마이그레이션에 관한
어떠한 조언도 상관없습니다.
감사히 듣겠습니다.^^
Forums:
C로 짠 라이브러리를 C++에서 임포트할때...extern "C"
C로 짠 라이브러리를 C++에서 임포트할때...
extern "C" 아시죠? :D
----------------------------------------------
한번뿐인 인생....
미친듯이 살아보자!
----------------------------------------------
검색해보니 비슷한 주제가 한번 올라왔었네요.http://bbs.kld
검색해보니 비슷한 주제가 한번 올라왔었네요.
http://bbs.kldp.org/viewtopic.php?t=27705&highlight=c%2B%2B+%C6%F7%C6%C3
그런데 답변이 그리 많지 않아서..
이 게시판에 한번 더 올려보겠습니다. ^^;;
아 그리고 extern "C"는 아는데..^^;;
가령 malloc은 그 안에서 부를때랑 밖에서 부를때랑 차이가 있나여?
가령 안에서 malloc한거를 밖에서 free해도 메모리 관리상
문제가 없는지여?
권위를 의심할 것,어긋남을 존경할 것,자리잡기를 거부할 것,항상 자신을 재창조할 것 - MIT 미디어랩 -
마이그레이션의 목적에 따라 달라질 듯 합니다.기존 C 코드를 그대로
마이그레이션의 목적에 따라 달라질 듯 합니다.
기존 C 코드를 그대로 쓰면서 C++ 코드와 링크하는 것도 전혀 문제는 없습니다만,
extern "C"를 써야 하니 C 헤더는 좀 변경을 해야 할 것 같습니다.
참고가 될 만한 글이 있군요.
Migrating from C to C++: A Case Study
안과 밖이 무엇을 말씀하시는 건지는 잘 모르겠으나, malloc/free는 메모리의 할당과
해제 시점을 전적으로 프로그래머가 제어하겠다는 것입니다. 한 프로그램 내에서는
언제 어디서 하든 상관없습니다.
[quote="doldori"]마이그레이션의 목적에 따라 달라질 듯 합니
좋은 사이트 알려주셔서 감솨합니다.^^
제 질문 중 안팎은 extern "C" 기준으로
안팎을 말씀드린 겁니다.^^;;
extern "C" 기준으로 안에서 불리는 malloc과 밖에서 불리는
malloc을 컴파일러가 컴파일 혹은 링크를 다르게 처리하지는
않나해서 여쭤본 겁니다.
현재 소스를 g++로 한번 컴파일 해볼라고 했는데
대부분 malloc쪽에서 캐스팅이 안됐다고 엄청난 수의
에러가 나더라구요.
권위를 의심할 것,어긋남을 존경할 것,자리잡기를 거부할 것,항상 자신을 재창조할 것 - MIT 미디어랩 -
The C++ Programming Language를 보면 초반에 비야네
The C++ Programming Language를 보면 초반에 비야네 후루룹짭짭이 말하길
"C를 C++에서 사용못하게 하면 지금의 고질적인 문제점들을 해결 할 수 있으나 이미 개발되어있는 C코드들이 너무나도 좋은게 많아서 C++에서도 C를 사용할 수 있게 했다. 완벽하게 C의 소스들을 모두 사용할 수는 없지만 어지간하면 다 할 수 있다."고 말했습니다.
(책이 없어서 기억을 더듬었습니다.)
사족으로 저같은 경우 C같은 C++소스들을 보고있는데 이거 미칠지경입니다.
제발 학교/학원 또는 책에서 C와 C++을 분리해서 가르쳐 줬으면 합니다. ㅠ.ㅠ
서로다른언어인데 성의 음이 비슷하다고 같은 족보에 넣어버리다니 ㅠ.ㅠ
[quote="욕심많은오리"]사족으로 저같은 경우 C같은 C++소스들
좋은 정보 감사드립니다.^^
그런데, C 같은 C++소스가 legacy 소스인가여? 아니면 계속 생산되고 있는건가요? 저는 상용 소프트웨어쪽에 있다보니 비슷한 문제에 봉착할 것 같은데, legacy 소스는 말씀드린대로 리소스상 어쩔 수 없을 것 같고, 정책이 전환된 뒤에 계속 생산되는 C 소스는 내부인력 교육의 문제일 것 같네요.
그 부분을 뛰어넘는 것도 하나의 숙제일 것 같네요.^^
세계정복은 잘 되고 계시나요?^^;;
권위를 의심할 것,어긋남을 존경할 것,자리잡기를 거부할 것,항상 자신을 재창조할 것 - MIT 미디어랩 -
[quote="spacelee"]제 질문 중 안팎은 extern "C"
달라지지 않습니다.
malloc()의 반환형이 void*인데 C에서는 void*에서 다른 형의 포인터로 변환이
허용되는 반면에 C++에서는 그렇지 않기 때문입니다.
선택은 몇 가지가 있는데...
1. 기존 코드는 그대로 C로 유지
2. malloc()에 캐스팅을 사용
3. malloc()을 new로 바꿈 : new와 new[]를 구분해서 써야 하고 free()도 같이
바꿔야 함. 물론 delete와 delete[]도 구분해서 써야 함.
ps. 호기심에 그럽니다만, 왜 C++로 바꾸려고 하시나요?
그냥 C함수들을 C++ 클래스로 wrapping하면 될것같습니다만?
그냥 C함수들을 C++ 클래스로 wrapping하면 될것같습니다만?
[quote="doldori"]ps. 호기심에 그럽니다만, 왜 C++
답변 감사합니다.^^
C로 상용 소프트웨어를 5년정도 디자인하고 개발하고 유지보수를 해왔습니다. 초창기에는 C로 핸들러 개념정도만 잘 이용하면 클린하게 모듈화나 리팩토링 하는 것이 어렵지 않아서 그런데로 깨끗하게 잘 구성해온것 같습니다. 그런데 장기간에 걸쳐 고객의 요구사항도 계속 확장, 변해오고, 소프트웨어 사용환경도 예상하고 다르게 많이 변하고, 또 새로운 버젼의 SW를 만들면서도 예전 버젼과의 호환성도 유지해야 하니, 상속개념이나 template 개념등 OO의 기본 도구들이 절실히 필요한 걸 느끼겠더라구요. 그런 개념들이 없으면 리팩토링이 어렵거나, 호환성이 어렵거나, 소스가 redundant 해지거나 좀 불합리한 면들이 많이 생기더군요.
저두 학교에서 C++배우고 프로젝트 할 때는 이런 개념이 유용한가 싶었는데, 요즘들어 필요성을 절실히 느끼고 있습니다. 앞으로를 위해서라도 C++로 전환하는게 반드시 필요한 것 같네요.
권위를 의심할 것,어긋남을 존경할 것,자리잡기를 거부할 것,항상 자신을 재창조할 것 - MIT 미디어랩 -
[quote="Anonymous"]그냥 C함수들을 C++ 클래스로 wra
전체 소스가 워낙 많아서 그 작업조차 상당히 걸릴 것 같습니다.^^;; 저희가 시간이나 인력이 여유있는 상황이 아니라서...^^:;
권위를 의심할 것,어긋남을 존경할 것,자리잡기를 거부할 것,항상 자신을 재창조할 것 - MIT 미디어랩 -
[quote="spacelee"][quote="욕심많은오리"]사족으로
글쎄요.
저같은 경우 처음 취직하고 가르쳐 주는 사람도 없고 던져주는 소스보고 혼자서 해야했기에...
그냥 이건 이렇게 가져와서 이렇게 쓰는거구나 -_-; 라고 읽힌다음
항상 그렇게 씁니다.
즉, C같은 C++소스를 가져와서 C같은 C++코딩을 하면서 씁니다.
클래스보다 구조체를 많이 쓰는 이유도 이것때문일지도 모르겠네요. ㅡ.,ㅡ;
구조체보단 클래스를 쓰라던데 구조체 쓰는 법은 알아도 클래스 쓰는법은 책보고 배웠는데도 사용할때는 까막눈됩니다. ㅡ.,ㅡ;
무척 난감합니다.
이러저러한 이유로 아직도 초보자로서 C++기초서적(TC++PL)을 차례부터 보고있습니다.
다음목표는 STL,Boost, Lua(맞나요?) 순입니다.
참...알고리즘도 중간중간 봐야겠군요.
이거 몇년치 놀이감이군요. 꽥꽥~
[quote="욕심많은오리"]이거 몇년치 놀이감이군요. 꽥꽥~[/qu
지구 정복은 언제 하시려고^^
권위를 의심할 것,어긋남을 존경할 것,자리잡기를 거부할 것,항상 자신을 재창조할 것 - MIT 미디어랩 -
댓글 달기