리눅스에서 C++....
리눅스에서 C++로 프로그래밍을 하고 싶어하는 사람입니다. 그런데, 리눅스에서 C와 C++의 호환이 좀 이상하게 안되는 듯 해서 어려움을 겪고 있습니다. 지금 하고 있는게 XML Query Processor를 만드는 건데 yacc 문법 파일로 파서 만들어주는 게 제 리눅스 배포판엔 yacc도 있고 bison도 있던데 둘다 C++을 지원하지 않더군요. action에 C++ 코드를 넣어서 g++로 컴파일하면 컴파일 에러가 납니다. C코드로 하고 gcc로 컴파일하면 잘 되구요. 근데 이게 flex는 flex++로 컴파일하면 잘 되는데 bison은 그렇게 안되나요? 이게 XML Parser 라이브러리를 불러서 써야되는데 그게 C++로 되어 있어서 C++을 꼭 써야하거든요. 게다가 전 C++을 C보다 훨씬 좋아하기도 하고.. 어떻게 해야하는지 방법을 좀 가르쳐주세요. Solaris에서는 그냥 하니까 컴파일이 잘 되고 실행도 잘 되던데 linux에서는 어떻게 하면 할 수 있는지..
그리고, 이 외에도 C++로 작성한 코드랑 C로 작성한 코드랑 따로 컴파일해서 링크시키면 링크 에러가 날 때가 많던데 그게 보니까 C 링크 방법과 C++ 링크 방법이 다르다고 하더군요. 정확히 어떻게 다른 건지 아시는 분 좀 가르쳐주세요. 또, 함수 호출 방법이라든지 여러 가지 면에서 차이가 많다고 하던데 C와 C++의 정확한 차이를 좀 알고 싶습니다.
지난 번에 여기서 리눅스에서의 C와 C++에 대한 토론이 있던데 C가 C++보다 퍼포먼스가 좋다고 하더군요. 어느 정도로 차이가 나는지 정확한 데이터 같은 것이 있나요? 그리고 실행파일의 크기 같은 것도 정확한 데이터를 들어서 설명해주셨으면 좋겠습니다. 개인적인 생각으론, 유닉스 머신은 이제 거의 다 cc가 C++이 디폴트가 된 것 같은데 리눅스도 gcc에서 C++이 디폴트가 되어야하지 않을까..하는 생각입니다.
댓글
리눅스에서 Multithread 하고 C++를 어떻게 접목시키시나요?
리눅스에서 Multithread 하고 C++를 어떻게 접목시키시나요?
C++에서는 Static 밖에 Multithread 가 안 된다는데,
다들 어떻게 해결 하시는지 궁금하네요.
제 경우에는 class member function을 thread로 쓰지
제 경우에는 class member function을 thread로 쓰지않고, thread function을 해당 class의 friend 함수로 지정해 둡니다.. 그리고
class A *a;
a = new A;
pthread_create(..., thread_function, a);
thread_function(void *ptr)
{
(A *)ptr->....
}
대강 이런 식으로 씁니다만....
class thread{public: int create
class thread
{
public:
int create() { return pthread_create( ... entry, this ); }
int run() = 0;
private:
static int entry(void* self){return ((thread*)self)->run();}
};
모 이런 식으로 쓰기도 하지요
여기 질문란의 성격(?)이 어떻게 되지요? RTFM이라는 소리가 나올만한
여기 질문란의 성격(?)이 어떻게 되지요? RTFM이라는 소리가 나올만한 성격의 질문이라도 토론의 여지가 된다면 여기 올라올 수 있다는 건가요..?
s/토론의 여지가 된다면/토론이 가능할 정도라면/g(저렇게 하는게
s/토론의 여지가 된다면/토론이 가능할 정도라면/g
(저렇게 하는게 맞는지 원;)
...-_-포럼란, 모더레이션 아니던가요?그리고 질문 항목도
...-_-
포럼란, 모더레이션 아니던가요?
그리고 질문 항목도 있지 않던가요?
왜 그렇게 질문글에 대해 알레르기를 일으키는지
모르겠군요.-_-
차라리 이렇게 하자고 요구하시죠.
한글 리눅스 문서 프로젝트에서는 일체의 질문을
할 수 없게 하자고...
왜 그래야 하는지는 모르겠지만...
저는 토론성 질문글에 대해서는 좋게 생각합니다.. : )
저는 토론성 질문글에 대해서는 좋게 생각합니다.. : )
저는 개인적인 일 때문에 Fortran, c, c++ 가 섞여있는 코드로
저는 개인적인 일 때문에 Fortran, c, c++ 가 섞여있는 코드로 작업을 하고 있습니다. 글쓴 분이 c++ 를 선호한다고 하셨으니까 몇자 적습니다. 제 개인적으로 선호하는 방식은 필요한 c 라이브러리를 위한 wrapping 클라스를 만드는 것입니다. 물론 클라스 이름은 라이브러리 이름과 관련되어 지어주면 되겠지요. 이 경우 장점은 extern "C" 선언이 모두 wrapping 클라스에 오게 되어 프로그램이 지저분해지지 않고, 해당 C 라이브러리 함수가 멤버함수인지 c 라이브러리 함수인지 구분하기가 쉬워집니다. 물론 wrapping 클라스를 처음 만들때는 노가다작업이 필요하지만, 일단 한번 만들어 놓으면 두고두고 사용할 수 있고, C++ 만으로 프로그램을 하는 느낌을 가질 수 있어 좋은 것 같습니다.
하하..논의의 방향이 많이 벗어났네요.1.질문을 올리신 님
하하..
논의의 방향이 많이 벗어났네요.
1.
질문을 올리신 님이 하시는 작업은 XML 쿼리를 처리하는 프로그램을 리눅스에서 구현하고 계시는 것이고,
2.
XML 쿼리를 처리하자면 당연히 파싱 부분이 들어가야 되고,
3.파싱모듈을 전부 코딩하자면(이거 엄청 노가다죠) 힘드니까 yacc나 bison 같은 파서 생성기를 쓰려고 한다.
4. 그런데 이놈은 C 코드를 생성해 준다.
5. 헌데 님은 시스템의 전반적인 부분을 C++로 구현하고 계신다.
6. 그래서 하나의 모듈로 합칠 때 문제가 발생한다.
위에 제가 이해한 것이 맞죠?
음..
1.
가장 심플한 방법은 bison으로 생성해내는 코드를 C++로 만드는 것인데,
다행히 bison은 C++ 코드를 지원한다고 합니다.
그냥은 안되고 C++Parser라는 놈을 써서 bison이 생성해 낸 코드를 C++ 코드로 바꿀 수 있다고 하는데..
이 C++parser도 GNU 관련 사이트에서 찾을 수 있답니다.
아쉽게도 저 또한 yacc 등을 써서 C++ 코드를 만들어 낸 적은 없답니다.
아래의 사이트를 참고하십시요.
http://www.cs.cmu.edu/~AUIS/bison-a26.html
2. 뭐 파서 부분을 C 모듈로 두고 다른 부분을 C++로 구현해서 합칠 수도 있습니다.
그런데, 헤더 화일의 작성과 정의,선언에서 상당히 세심하게 주의를 해야하는데 윗 글 중에 현차리 님이 자상하게 적어 놓으셨네요.
하지만, bison 등을 이용해서 만들어진 코드를 붙일 때는 자동으로 생성된 코드를 그냥 쓸 수 없고 그 코드에 손을 좀 봐야 될겁니다.
그리고 그 해당 소스에 대해 헤더 화일을 두어서 그 타입 처리에 대한 것을 제어하셔야 되고요.
!! 여기서 주의
제가 알기로는 HTML이나 XML을 파싱해 주는 코드를 yacc 등을 써서 생성해 낼 수는 없는 것으로 알고 있습니다.
이 부분은 컴파일러나 오토마타 부분하고 관련이 있는데
각 Gramma 마다 문법의 파워가 틀리기 때문인데,
제 기억이 맞다면(죄송합니다. 학교 졸업한 지 좀 됐습니다.^^)
yacc가 생성해 내는 코드의 문법 범주는 CFG인데 html 등은 그 범주를 벗어나거든요.
음.. XML은 어떤지 제가 잘 몰라서리...
이 점을 알고 싶은데요..
제 생각에는 yacc 등으로부터는 부분적인 도움 밖에 못받고 상당 부분을 핸드 코딩하셔야 될 겁니다.
!!!
또 하나 gcc는 단순 컴파일러가 아닙니다.
gcc는 여러개의 툴을 합쳐 놓은 것이랍니다.
소스 화일의 확장자에 따라, C 컴파일러와 C++ 컴파일러, 포트란 컴파일러를 불러 줄 뿐만 아니라, 어셈블러와 링커, 로더 까지 같이 불러주기 때문에 일종의 전체적인 개발 툴로 보는 것이 나을 거라 생각합니다.
!! 위의 분 중에 어셈블러가 낫니, 시스템에서는 아직 C라느니, XML 파서를 왜 만드니 하는 분들이 있는데 왜 논의의 방향과 상관없는 글을 쓰는지 이해가 안가는 군요.-_-;
세상에 에셈블리가 안들어간 OS는 없을 겁니다.그리고 C도 어셈블로
세상에 에셈블리가 안들어간 OS는 없을 겁니다.
그리고 C도 어셈블로 만들어 졌고요...
껄껄껄...^^
모든 프로그램의 핵심을 얘기하자면 어셈만한게 없겠지만도...
C도 어셈을 제외한 언어 중에선 가장 강력한 기능을 가지고 있지않나 생각이드네요...
시스템 관련에선...^^
<어떠한 역경에도 굴하지 않는 '하양 지훈'>
어떠한 역경에도 굴하지 않는 '하양 지훈' - It's Now or Never!!!
어셈에 관한 광신도 같으신데 ^^어셈은 C와 같이 문법이 통일된 언어
어셈에 관한 광신도 같으신데 ^^
어셈은 C와 같이 문법이 통일된 언어가 아닙니다.
오히려 Instruction Set Architecture를 표현하는 하나의 방법정도로 생각할 수 있구요.
물론 해당 CPU의 Assembly 언어를 잘 안다는 것은 Instruction Set Architecture를 잘 안다는 것이 되겠고, 분명히 프로그램할 때 많은 도움이 될 것입니다.
하지만, 최근의 CPU 들이 성능 향상을 위해서 clock speed를 높이는 것 이외에 pipe-lining을 한다던가 instruction level에서 병행적으로 처리한다던가 ( 동시에 여러 instruction을 수행한다는 뜻이죠 ) 하는 것이 당연시 되고 그 정도가 점점 복잡해지고 있습니다.
이런 CPU들에서는 어떤 instruction 다음의 몇 클락 동안은 어떤 instruction이 올 수가 없고, 어떤 instruction 들끼리는 동시에 수행이 가능하기 때문에 요렇게 요렇게 묶으면 더 빨리 수행되고 하는 사항들이 많이 존재하게 됩니다.
이런 여러 사항들을 모두 머리속에 넣고 일일히 지켜가면서 컴파일러에 비해 더 좋은 Assem 수동으로 생성한다는 것은 점점 더 불가능에 가까운 일이 되어가는 것 같구요.
특히 RISC가 도입되면서 컴파일러가 최적화된 코드를 만들기가 더욱 쉬워진 상황에서는 더욱 어셈 코딩을 할 필요성이 더 줄어드는 것 같습니다.
어셈블리가 C와 같이 문법이 통일된 언어가 아니라는건어셈블러 한번
어셈블리가 C와 같이 문법이 통일된 언어가 아니라는건
어셈블러 한번이라도 써본 사람이라면 다 아는 얘기일텐데
언급을 하셨군요..
앞으로는 어셈블리를 거의 쓸 필요가 없다는 식으로 말씀하시는데
그건좀 아닌거 같습니다.
여러 os 부트로더 소스들 같은데 보면 c로 하기에는
어려운 부분들이 많이 있습니다.
예를 들면 coprocessor 제어라든가
pc 레지스터 변경 등등..
c로 일반적인 레지스터 세팅 같은건 다 됩니다만..
또 새로운 cpu 가 나오면
기본적으로 해당 cpu 에 맞는 어셈블러는 나오는걸로 알고 있습니다.
cpu 회사에서 어셈블리 제작사에 돈주고 인스트럭션 셋 라이센스 판다고 합니다.
cpu 회사에서도 해당 어셈블러가 기본적으로
반드시 필요하다는걸 알기때문이 아닐까요??
글쎄요... 제가 위에 글 읽으니까 어셈을 안쓴다는 얘기가 아닌거 같은데
글쎄요... 제가 위에 글 읽으니까 어셈을 안쓴다는 얘기가 아닌거 같은데..
단순히 어셈으로 프로그램 하기가 요즘 요구하는 프로그램들이 커졌다는 얘기 같네요..
물론 님이 말씀하시는 것은 확실히 맞습니다. 아무리 어떠한 편리한 언어가 나온다고
하더라도 기계어 수준으로 처리해야 하는 부분은 있으니까요..
음... 쓰다 보니 말이 이상해졌는데... 제 말의 요점은..
어셈이 필요없다가 아니라 점점 필요성은 줄어 간다는 말입니다.
물론 중요부분은 어셈을 사용해도 말입니다
요즘은 C 를 C 로 맹글지 않나여?
요즘은 C 를 C 로 맹글지 않나여?
리눅스에서 egcs가 기본적으로 깔려있기는 합니다만,워낙 linux관
리눅스에서 egcs가 기본적으로 깔려있기는 합니다만,
워낙 linux관련 코드들이 C로 되어있는 것들이 대부분
이라서리...(정확히 말하면 유닉스 자체가 그렇죠...)
그전에 몬테 카를로 시뮬레이션을 하는데
라이브러리가 모두 포트란으로 되어있어서
선배에게 물어본적이 있습니다.
왜 지금까지 포트란을 쓰냐고?
선배왈
라이브러리 코드가 수백만라인인데,
그게 전부 포트란이랍니다.
그거다 C로 컨버팅하려면
노가다 꽤나 들거라구....
시간이 흘러가면 C++이 유닉스계열 기본이
될지도 모르겠지만, 아직은 아닌거 같습니다.
그리고 사실 C++ 쓴다고 해봐야
주요한 부분(시스템 제어)들은 모두 C를
쓸 수 밖에 없기 땜시로...
에구 쓰고 보니 이상하네~~~
리눅스에서는시스템 제어 부분은 모두 C 를 쓰는것은 아닙니다.
리눅스에서는
시스템 제어 부분은 모두 C 를 쓰는것은 아닙니다.
다 아실테지만
cpu 종속적인 부분과 그래픽 카드 제어부분, 초기 압축 커널 이미지
풀고 램에 재 적재 하는 부분 등등 많은 핵심 부분은 어셈블리로 되어있습니다..
java가 unix의 기본이 된다는건 납득이 가도c++은 별로 납득이
java가 unix의 기본이 된다는건 납득이 가도
c++은 별로 납득이 안가네요.
적어도 solaris에서는 말입니다
저도 자바를 좋아하지만.. 리눅스의 기본 언어가 자바가 되야한다는건
저도 자바를 좋아하지만..
리눅스의 기본 언어가 자바가 되야한다는건 납득하기 힘드네요..
그 느린속도를 생각한다면 말이죠.. (서버 프로그램으론 괞찮을지 몰라도.. GUI 가 좀 들어가면.. 진짜 장난 아니죠..) 기본 언어가 될려면 여러 조건을.. 만족해야 하는데..
java 가 system program 이 가능한가여? 이 땀시 C++
java 가 system program 이 가능한가여? 이 땀시 C++ 로 O/S 맹글다 실패 했다 하던디.
우선 여기 질문 올려도 되냐는 것에 대해.. 여기 분명히 질문 올려도 되
우선 여기 질문 올려도 되냐는 것에 대해.. 여기 분명히 질문 올려도 되는 걸로 압니다. 분류에 분명히 질문이라는 부분이 있는데요. 그리고 좀 토론이 오고 갈만한 질문이라고 생각되는데요. 관리자분께서 일단 여기 올려주신 것이면 그 정도 판단은 하고 올려주신 거 아닙니까? 왜 자기 생각대로 판단하고 그런 식으로 말합니까? 뭐 하나 도와주는 것도 아니면서 말입니다. 상당히 유감이군요.
그리고 제가 만들려는 것은 그 많고 많은 XML Parser가 아니라 XML Query Processor입니다. 많고 많기는 커녕 C++로 만들어진 XQuery 1.0 spec을 지원하는 건 거의 없는 걸로 압니다. 있으면 좀 알려주시겠습니까? 글을 제대로 읽지도 않고 비판부터 하기 바쁜 사람들이 보이는군요. 그리고, 저는 학생입니다. 공부하려는 목적으로 만들어보는 건데, 뭐 잘못되었습니까? 이미 있는 XML Parser만들면 안될 이유라도 있습니까? 한 카테고리에는 한 프로그램만 있으면 충분하다고새생각하시나요?
저는 아직 학생이고 여기 보면 나이도 좀 있고 경험도 많으신 분들이 많이 오는 것 같아서 다른 사람들 생각을 듣고 싶었는데 저보다도 생각이 짧으신 분들이 많군요.
이상하지요???항상 논란의 대상이 되는 글은 질문성 글이네요.왜
이상하지요???
항상 논란의 대상이 되는 글은 질문성 글이네요.
왜 질문(성) 글은 써서는 안되지???
음냥... 넘치고 넘친게 XML 파썬데...바퀴, 또 만들 필요
음냥... 넘치고 넘친게 XML 파썬데...
바퀴, 또 만들 필요 있나요?
바퀴.... 종류 많이 있습니다.바퀴가 있는데 머하러 만드는지..
바퀴....
종류 많이 있습니다.
바퀴가 있는데 머하러 만드는지..
모르겠다면.
자동차는 있는데 왜 또 나오며
무기..공구... 이런것들이
왜 발전을 하는지 생각해보세요 ..
많이 만들고 도태되어야지요..
바퀴있어도..
지금 또 다른 디자인.. 다른 기능의 바퀴는 만들어집니다.
음..flex,bison 으로 c++ 프로그램 가능합니다.다만 삽
음..
flex,bison 으로 c++ 프로그램 가능합니다.
다만 삽질이 필요합니다. ㅡ.ㅡ
c 를 섞어서 연결해야 합니다..
스크립트 언어를 개발한 iron영재꿈나무 = iron
스크립트 언어를 개발한 iron
영재꿈나무 = iron
-.-++
-.-++
이런것이 포럼내용이 될 수 있나여?단순 질문에 가까와보이는데?
이런것이 포럼내용이 될 수 있나여?
단순 질문에 가까와보이는데?
올리시는 분은 생각을 좀 하셔야겠슴다.
문의와 관계없이 제가 여쭈어보고 싶은게 있네요.xml 파서 많은데 왜
문의와 관계없이 제가 여쭈어보고 싶은게 있네요.
xml 파서 많은데 왜 새로 만드시려고 하시뇨?
그리고 C와 C++의 성능에 대해서 아는바 없이 의견을
말하면 C++이 당연히 기능이 많기 때문에 최적화하기
어렵고 또한 필요한 라이브러리도 많기 때문에 조금은
느릴 것입니다. 그렇지만 지금은 CPU가 많이 빨라져서
거의 무시할만하다고 생각합니다.
참고1. 저희의 많은 임베디드 소프트웨어가 C++로 되어
있습니다만 잘 돕니다. 임베디드 시스템보다
속도에 민감한 부분이 없기 때문에 믿으셔도 됩니다.
참고2: 레드햇에서 C++ 튜닝 작업을 하고 있습니다.
이 결과가 나오면 차이는 더 줄 것 입니다.
흠... 컴파일 에러라면 고치면 되는거 아닌가여?그리고 C++은 표준
흠... 컴파일 에러라면 고치면 되는거 아닌가여?
그리고 C++은 표준을 지원하는 정도가 컴파일러마다 달라서
컴파일러마다 약간 고쳐야 하는 경우가 많습니다.
이번에 나온 GCC 3.0 (GNU Compiler Collection)의 g++을
써보는 것도 좋은 생각중 하나인 것 같군요..
그리고, cc의 default가 C++이라는 것은 무슨 말인지...
cc는 C Compiler이고, c++은 C++ Compiler 아닌가요?
GCC에서는 gcc가 C Compiler이고, g++이 C++ Compiler이고..
C와 C++은 다른 컴파일러를 써야 하니 기본이라는 것은 의미가 없는 말이군요.
(내부적으로는 C++ Compiler가 C Compiler의 frontend라고 하더라도)
마지막으로 C에서 C++의 함수를 링크하려면
extern "C" {
}
블럭 사이에 C++함수의 선언을 넣어야 하는 것으로 알고 있습니다.
#ifndef __cplusplus
extern "C" {
#endif
//C++ 함수의 선언
#ifndef __cpluscplus
}
#endif
이런 식으로 사용하시면 될 듯 하네요.
아..저는 그냥 cc해도 C++이 그냥 컴파일이 되길래 솔라리스에서는 C
아..저는 그냥 cc해도 C++이 그냥 컴파일이 되길래 솔라리스에서는 C++이 디폴트인 줄 알았습니다. 근데 그게 아닌 모양이네요.--;
그리고 질문 하나 더..--; C에서 C++의 class를 쓰고 싶으면 어떻게 해야하죠? 사실 이게 어떻게 하는지 몰라서 질문한 건데.. 이것도 extern "C" {} 안에 클래스 선언을 넣어주면 되는 건가요? 좀 자세히 설명 부탁드립니다.
class 라는 keyword를 C에서는 모르기 때문에extern "
class 라는 keyword를 C에서는 모르기 때문에
extern "C" 안에 넣었다고 무조건 쓸 수 있는 것이 아닙니다.
extern "C" 의 경우.
C++ 소스파일에 쓰였을 경우는 name mangling(혹은 decoration)을 하지 않고 오브젝트파일을 만들어라라는 뜻으로 해석하면 되구요.
원래 C++에서 void a(int)라는 함수를 만들면 컴파일시 함수를 가리키는 심볼이 _a 가 되지 않고, 타입정보까지 섞인 형태... ?a@@YAXH@Z(Visual C++)가 되는데 이렇게 만드는 걸 name mangling이라고 합니다. C++이 strongly typed 언어이기 때문에 필요하답니다.
하지만 extern "C" 안에 있으면 void a(int)는 C에서의 convention인 _a 라는 심볼로 남습니다.
C에서 링크할 땐 _a를 찾고
C++에서 링크할 때는 ?a@@YAXH@Z를 찾겠지만
C++의 헤더파일에 쓰였을 경우는 이 녀석은 mangling되지 않은 함수라는 것을 것을 알기 때문에 라이브러리에서 _a를 찾겠지요.
#ifdef __cplusplus 이런 것은 extern "C" 라는 것 자체가 C에서 필요가 없기 때문에 그런 겁니다.
같은 헤더를 C와 C++ 모두 공유하기 위한 방법이지요.
실제로 stdio.h나 stdlib.h 같은거 열어보면 알 수 있을 듯...
아, 밑에도 이야길 했었는데
object의 바이너리 모델과 똑같이 struct로 정의해놓고 쓰시면 일단 멤버함수가 아닌 이상 주고 받는 것은 됩니다만.
컴파일러마다 C++ object에서, vfptr, vbptr의 위치가 다를 수 있고
때로는 (제가 알기로는 대부분 다 같습니다만) 접근제한(public, private, protected)을 어떻게 구현했느냐에 따라
바이너리 형태가 달라지기 때문에
일단 테스트를 하시고, 컴파일러에서 struct로 매핑하셔야 되구요.
강조하지만, 컴파일러마다 다르기 땜시롱, 다른 라이브러리랑 붙이실 때 조심하셔야 합니다.
전부 public으로 선언되었으며 가상함수가 하나도 없고, 가상베이스클래스를 상속하지 않는 class라면
class를 struct로 바꾸면 바로 쓸 수 있겠죠.
그리고 사람들의 반응은
토론란에 여태 이런 질문이 없어서 당황해서 그런 것이 아닐까 싶네요.
너무 열내시지 마시구요.
좀더 정중하게 질문하는 걸 바라는 건 인지상정이겠죠.
제가 뭐 대단해서 답변을 다는 것은 아닙니다만, 님이 적은 글도 썩 기분좋지는 않네요. :)
윗 분이 불쾌해 하는 건 당연해 보이는군요.잘못하신 분들은 '쓸데없는
윗 분이 불쾌해 하는 건 당연해 보이는군요.
잘못하신 분들은 '쓸데없는' 댓글 다신 분들이죠.
박영록님께 '정중한 질문'을 요구할 수는 없죠.
왜냐하면 박영록님은 충분히 '정중'했기 때문입니다.
문제를 일으킨 사람(?)과 그런 사람들 때문에
곤혹스러워 하는 사람을 한꺼번에 몽뚱거려 말할 수는
없다고 봅니다.
기술적 토의에서 기술 외적인 문제로 딴지를 걸어, 결국
기술적 논의 자체를 불가능하게 하는 분위기를 많이 봐왔지
않습니까?
이런 식이면 누가 또 이런 글을 올리겠습니까?
좋은 글 끝에 다신 글이 조금 아쉬워 저도 '쓸데없는' 댓글을
달았습니다. 좋은 정보 알려 주셔서 감사합니다.
원글도 이상하다 했더니 역시 질문이었군요.C++지원이 이상한 게
원글도 이상하다 했더니 역시 질문이었군요.
C++지원이 이상한 게 아니라 쓰는 사람의 무지때문이 아닌가요? 이정도는
리눅스가 아니라 어떤 플랫폼에서도 C++를 쓰려면 알고 있어야 하는 건데.
님이 정말 저 정도는 기본으로 알고 있는 거라면 저 질문 사항들에 대해
님이 정말 저 정도는 기본으로 알고 있는 거라면 저 질문 사항들에 대해 답을 해보시는 게 어떨까요?
여기는 질문하는 곳이 아닙니다..게시판 성격을 보고 글을 올리셔야죠.
여기는 질문하는 곳이 아닙니다..
게시판 성격을 보고 글을 올리셔야죠..
C++ class 를 C 에서 사용은 절대 불가~~!앞의 exte
C++ class 를 C 에서 사용은 절대 불가~~!
앞의 extern "C"는 님의 야그 처럼 이름을 C++ Type 으로 확장하지 않구 기냥 원래
Function Name 으로 표출 하는거죠...., 그러므로 이건 Class 를 이용하는것과는 분명 구분되죠..., 그럼 총총총
절대 불가능하지는 않습니다.컴파일러마다 구현이 다르긴 하지만,바이
절대 불가능하지는 않습니다.
컴파일러마다 구현이 다르긴 하지만,
바이너리 레벨만 잘 맞춰주면 쓸 수 있습니다.
대신 C에서는 C++의 클래스와 바이너리레벨에서 호환가능한 구조체를 정의해야 하지만요.
vbptr, vfptr 자리를 패딩한다든지의 일을 해야겠지요.
심지어 멤버함수를 호출하는 부분도 fastcall(this 포인터를 레지스터로 넘기는 방식) 인지 잘 살펴서 맞춰주기만 하면,(this 대신 구조체의 포인터를 넣는 식으로) 쓸 수 있답니다.
뭐, 가장 안전하고, 편한 것은
extern "C" 로 인터페이스를 만들어 놓는 것이지만요.
extern "C"에 대한 것을 설명하려다보니 짧은 지식때문에...이
extern "C"에 대한 것을 설명하려다보니 짧은 지식때문에...
이름 어쩌구하고 알고 있었는데 아래 설명을 보니 Name mangling이라네요... *^^*
어디선가 퍼왔는데... 참고하세요... (C++을 설명한 서적을 보시면 더욱 자세하게
나와있을 겁니다.)
- linkage 란?
- 컴파일시에 컴파일러가 오브젝트 파일에 남겨놓는 링크에 관한
정보를 말한다. 따라서 링커는 linkage 정보를 보고 어떤 함수
가 결합되어야 할지 판단하게 된다. C에서는 함수끼리 이름만
으로 구분이 가능했었으나 C++ 에서는 다형성에 의해서 이름
만으로는 구분이 불가능하게 되었다.
따라서 C++에서 C 함수를 사용하기 위해서 컴파일러가 linkage
를 C++에 알맞게 변화시키는데 이것을 네임 맹글링
(name mangling)이라고 한다.
형식 : 함수의 프로토타입 앞에 extern "C" 를 붙여주면 된다.
댓글 달기