C++은 과연 C의 완벽한 파생어인가?
글쓴이: hayataeul / 작성시간: 수, 2008/08/27 - 8:15오후
"C++이 과연 C언어로부터 파생된, 완전한 C언어의 후속 언어일까요?"
아는 분이 해 준 말인데, 그 분이 C++은 멀티패러다임 랭귀지로 가장 큰 장점이자 단점이 템플릿이란 이야기를 해 줬던 기억이 있네요. 그리고 문법적 유사성이 언어의 특징을 평가하지 못한다는 이야기도 같이.
흔히들 C++은 C언어의 파생어라서 C언어를 먼저 배우고 C++을 배우는 쪽이 유리하다고 하는데, 과연 C언어를 배우는 것이 C++언어 학습의 선행조건이 맞는지, C++언어로 프로그램을 짠다고 하면서 혹시 C언어 식으로 프로그램을 짜고 있진 않는지, C언어에서 클래스만 추가한다고 과연 C++이 될 수 있는지. 그 분 이야기를 듣다가 굉장히 놀랐던 게, C++에서는 C언어 컴파일링이 안 된다고 하더라고요. Obj-C에서는 C언어 컴파일링이 가능한데. 정확히는 C언어를 C++에 적응 시킨 반쯤은 C++인 코드를 컴파일하게 된다고.
C++언어라는 것이 객체지향을 배우는 데 과연 바람직한 언어인가, 라는 점에 대해서도 생각해볼만한 문제같고, 아무튼, C++언어가 좀 어렵긴 많이 어려운 언어 같아요. 굉장히 생각할 것도 많고.
Forums:
당연히 아닙니다
다음 프로그램을 gcc와 g++로 컴파일해 보세요. 한 쪽에서만 컴파일 에러가 납니다.
이 외에도 많습니다.
struct node *n =
struct node *n = malloc(sizeof(struct node));
C++에서는 이것 역시 컴파일이 되지 않는다고 들었습니다.
꽤나 놀랐습니다. 전 지금까지 C++을 C의 발전형으로 이해하고 있었거든요
아마 저 말고도 C++이 C의 단순한 발전형으로 알고 계실 분들이 많을거라 생각되는데...
---
puts "Hello, Ruby!"
---
#include
main(){
printf("hello, C!");
}
puts "Hello, Ruby!"
---
#include
main(){
printf("hello, C!");
}
참고로 보통 C 에서도
참고로 보통 C 에서도 이 코드는
로 해주는게 정석이고 이렇게 해주면 c++ 에서도 컴파일 잘 됩니다.
이건 흠잡기로밖에 안보입니다.
오히려 C99 쪽에서 지원하는 것을 C++ 에서 지원 못하는 부분을 지적하거나 하는것이 옳다고 생각합니다.
Neogeo - Future is Now.
Neogeo - Future is Now.
malloc()의 선언을 보면
malloc()의 선언을 보면 void *malloc(size_t) 이구요, C99에서 void * 는 캐스팅 없이 사용합니다.
----
Let's shut up and code.
----
Let's shut up and code.
제가 알기론 C99
제가 알기론 C99 에서가 아니라 C89(90 , ANSI) 에서도 위의 케이스는 문제 없습니다.
다만 위의 케이스가 C++/C 의 차이를 드러내기위한 것이라는 예제로는 전혀 적합하지 않고,
C99 에 추가된 많은 부분이 C++ 에서 커버하지 않은 측면이 많기때문에 그부분을 주목하는게 훨씬 적절한 예제가 될 수 있기에 위에 예제는 적합지 않은 흠잡기에 지나지 않는다고 한 것입니다.
Neogeo - Future is Now.
Neogeo - Future is Now.
그게 정석인지는 이해가 어렵네요.
표준에서 opsolete(흔히 deprecated라고 불리는)라고 지정되지 않은 이상 흠잡기라고 보는 것은 지나친 견해라고 생각합니다.
만약, struct node
만약,
라고 하는 상황이오면, n 의 type 이 무엇인지 코드보는 사람 입장에서 추측하기가 난해하기 때문입니다. ( sizeof 연산이 반복될 경우 overhead가 있을 수 있기에 미리 계산해 두고 여러번 할당할때 사용하곤 합니다. ) 요즘엔 관계없지만 예전엔 포인터를 미리 선언하고 한참 아래에서 사용하는 식으로 코딩해야만 했었죠. ( C99 이전 이야기 입니다. ) 그래서 저게 어느정도 프로그래머 라면 '정석' 처럼 활용해 왔기에 정석이라고 표현했습니다.
casting 은 어차피 자동으로 되니, casting 하는 overhead 가 존재하는 것도 아니겠지요. ( 이부분은 확실하게 모르겠습니다만, 전 void* 가 자동으로 n 의 type 으로 casting 될 것이라고 공부했었습니다. )
흠잡기라고 표현한것은 바로 윗글의 리플에 이유를 달았습니다.
Neogeo - Future is Now.
Neogeo - Future is Now.
C99도 문제없는 것으로 알고 있습니다.
에 대해서는 어떻게 생각하시나요?
Casting의 문제점이라고 생각하는 사람들이 있거든요.
그런 사람들은 아예 casting을 요구하지 않는 방식이 적절하다고 생각하는 것으로 압니다.
이것도 흠잡기일 뿐일까요?
사실 저도 판단이 잘 서지가 않습니다.
제가 malloc에 casting을 하는 것은 다른 사람들과 같이 작업할 때
다른 사람들이 C 언어로 작성한다고 해놓고, 확장자를 cpp로 하기 때문이죠... -_-.
말씀하신 코드가
말씀하신 코드가 무슨 관계가 있는지 전혀 모르겠군요.
malloc 이 return 하는 void * 가 어차피 assign 하는 순간 자동 casting 되는것을 명시적으로 써주는 것과
올바르지 않게 casting 을 시도하는것은 전혀 다른 문제입니다.
Neogeo - Future is Now.
Neogeo - Future is Now.
C FAQ를 다시 읽어봤습니다.
Q 7.7에 관련내용이 있는데 malloc이 선언되지 않았을 경우를 이야기하더군요.
그부분은 제가 정확히 공부하지 않아 이야기할만한 능력은 없군요.
그런데
int *n = (int *) malloc(intsize);
의 code가 동어반복적이라고 생각하지 않으신가요?
그것이 더 안전하다고 생각하신다면 적어도 이부분에 대해서는 더 이상 할 말은 없네요.
(물론 저는 더 안전할 이유는 없다고 생각합니다.)
제가 드린 글은 n 을
제가 드린 글은 n 을 미리 선언한 케이스를 말씀드렸습니다.
함수 파라미터등의 케이스에선 미리 선언된 변수에 값을 담을 수 밖에 없지요.
( 혹은 C99 이전의 C 언어라면 역시 변수가 미리 함수 초기에 선언되어 있어야 합니다. )
선언과 동시에 값을 담는 경우는 당연히 동어반복적이고 그부분에 대해서까지 casting을 명시적으로 표현하는건 제가 생각하는 기준으로도 좋은 것은 아닌거 같습니다.
그리고 저게 안전하다는게 아니라 코드를 읽는 사람 입장에선 중간에 malloc 이 튀어나와도 이 메모리의 용도가 명확히 눈에 보이기 때문에 정석이라고 생각한다는 것입니다. 제글 어디에도 casting 더 안전하다고 한경우는 전혀 없습니다. ( 당연히 더 안전할리도 없구요. ) 뭔가 오해가 있으셨군요.
Neogeo - Future is Now.
Neogeo - Future is Now.
sizeof 는
sizeof 연산은 컴파일 타임에 계산됩니다. (C99의 가변배열은 잘 모르겠는데 그 이전에는 모든 타입의 크기가 컴파일 타임에 정해져 있죠.)
스타일상의 문제라면 캐스팅으로 타입을 표현하는 것 보다 변수의 이름으로 타입을 표현하는 것이 더 정석적이라고 생각합니다.
sizeof 가
sizeof 가 정해져있다고해도 일정 사이즈의 메모리를 반복 할당할때는 뒤에 피연산이 붙고, 이경우는 변수에 할당하는게 편했습니다.
( 주로 array를 사용할 때나 char 를 buffe로 사용할 때 그랬습니다. )
또, network 쪽에선 packing ( padding ) 옵션을 자주 바꿔가면서 사용하는데, 이경우 sizeof 가 고정인지도 조금 의문이구요.
( 물론 고정이겠지만 같은 헤더에 대해서 padding 을 바꿔가며 컴파일 할일이 좀 많았습니다. hacking 막아보려고 별짓 다 해봐야했었으니까요. 그런 경우가 많아지면 전 확실하게 sizeof 를 미리 계산해두는쪽을 택했습니다. 그게 코딩 노가다 양도 줄고요. )
변수이름으로 타입을 표현하는 헝가리안 같은 방식은 오히려 버리는 추세라고 생각하고 있습니다.
type 을 변수이름으로 알 수 있게 코딩을 한다고 하더라도,
int init_array_of_node(struct node* p_node,struct node** pp_node,struct node*** ppp_node) { size_t size = sizeof(struct node) * MAX_SIZE; p_node = malloc(size); *pp_node = malloc(size); **ppp_node = malloc(size); p_node = (struct node*)malloc(size); *pp_node = (struct node*)malloc(size); **ppp_node = (struct node*)malloc(size); }전 아래쪽이 아무리 봐도 가독성이 더 높게 느껴집니다.
코드가 길면 길수록 malloc 이 반환하는 메모리가 어떤 용도인지 정확하게 알 수 있는 상황을 더 좋아합니다.
Neogeo - Future is Now.
Neogeo - Future is Now.
일단 변수명에 해당
일단 변수명에 해당 변수가 무엇인지 명시하는것은 헝가리안적 표시요건이 아닙니다.
camel case나 pascal case에서도 그런 방법을 사용하고 있습니다
그 값이 int인지 float인지 globar인지 local인지를 표현하는게 아니라
단순히 size_of_node 식으로 표현될 필요가 있음을 이야기 한 것입니다.
오히려 리팩토링이 되어있질 않아 해당 메서드가 길때 -예로 드신 경우는 그다지 길지 않지만-
이후 size라는 변수만 달랑등장했을때 그 값이 어떠한 사이즈를 말하는지“명확하지 않을 가능성”이 높아 코드를 회기적으로 찾아야 합니다.
또한 위의 캐스트에 대한 언급들은 malloc의 문제 보다는 void*의 경우 형성되는 자동타입변화 과정에서
컴파일러가 A가 B로 변하고 있다 라는 워링메시지를 제공하지 않게 되기 때문에 문제가 된다는 의미입니다.
올바르지 않은 assign의 경우도 존재할 수 있는데 void*에 들어있는 값이 정상적이지 않은 경우 역시도 무조건 적으로 cast해버립니다.
malloc으로 예를 들어 미묘한데
와 같은 코드가 에러없이 넘어가고, 런타임에 에러를 발생시킵니다.
물론 이것은 cast가 있건 없건 동일하게 동작합니다만, 이후에 이러한 경우 어떠한 라인에서 에러가 발생했는지를 찾기위해 굉장히 많은 노력이 들어갈 가능성이 높아진다는 점이 문제입니다.
위 문제는 void* 자체보다는 캐스팅의 문제이기 때문에 c++에서도 static cast를 최대한 사용하지 않도록 권고하고 있습니다
미학적 언급에 대해서는 제 생각으로는 size라는 변수를 별도로 빼면서 명시적으로 쟤가 무엇인지를 알리기 위해 cast를 사용하신것 같습니다만, 일반적으로는 sizeof를 직접사용하고 해당 크기는 컴파일 타임에 최적화되어 별도의 오버헤드가 생길 가능성이 낮고, 또한 변수를 따로 뺀다면 오히려 그것이 무엇에 대한 사이즈인지를 알 수 있도록 변수명으로 표현하는것이 더 깔끔하리라 생각합니다.
표기법적 관점에서 해당 메서드에서 사용한 size는 언제나 sizeof(node) 와 같다면(const라 변하지 않는다면)
당연히 cast의 구문을 제거하더라도 동일한 의미를 가집니다.
-----
cast는 c언어로 한정할때는 정석적 방법은 절대 아닙니다. 단지 c++이 c에 비해서 좀더 강하게 타입체킹을 할 뿐이고, c언어에서 void* 에 대해 캐스트를 하는것은 단순히 c++과의 호환에 한정되는 경우가 많습니다.
질문자인 hayataeul 님은 애초에 c++이 c의 파생어인지를 질문하셨습니다.
그런면에서 neogeo님 말씀대로 c/c++의 차이를 설명하는데에 cast에 대한 언급은 확실히 단순한 트집잡기이긴 합니다.
정석적인 C 코드는
정석적인 C 코드는 아닙니다.
위에 보면
라고 하신댔는데 저라면 이런 코드가 많이 나온다면
처음부터 변수명을 size가 아니라 node_size 로 짓던지
#define NODE_SIZE size
라고 할것 같습니다.
malloc뿐 아니라 단순하게 void*에 대해서 캐스트를 하는 것은 값이 변환되고 있음의 위험성을 경고하기 위해 일부러 발생시키는 컴파일러의 메시지를 제거하는 것 밖에는 되지 않습니다.
C++이 C를 기반으로
C++이 C를 기반으로 삼긴 하지만
다른 언어로 보는 게 좋을 듯 합니다.
그렇기 때문에 C++를 배울 때
꼭 C를 먼저 배울 필요는 없다고 봅니다.
하지만 그렇다고 해서 처음 배우는 언어로 C++을 고르는 건 말리고 싶습니다.
C 언어를 처음에 보통
C 언어를 처음에 보통 배우는 언어로 많이 권하기때문에 C 를 먼저 접하고 C++ 을 접하는 케이스가 많습니다. 그래서 사람들이 대부분 선행 운운하는거겠죠. 전통적으로 약 10년전 정도면 C++ 배우기 전에 C 를 배우는게 옳은 선택이었을런지도 모릅니다.
C++ 은 상당히 defacto 적인 언어로 태생부터 C 언어의 Lib 을 되도록 변형없이 쓰려는게 어느정도 목표가 있었고 C89 당시의 표준을 상당수 지원하는데 중점을 두었고 이를 확장한 측면이 있습니다. 하지만 지금의 C와 C++ 은 이미 가는 방향이 갈라진 상태입니다. 서로 연관은 많지만 어느게 어느것을 포함하고 있다 라던가 어느게 어느것으로부터 출발했다를 이제 따지는 것은 전혀 무의미합니다. 다만 C 로 된 소스코드는 C++로 옮기는 비용이 거의 0 에 가깝다는 장점이 있지요. ( 거의 .. 입니다. ) 그리고 일부를 제외하고 C 가 돌아가는 환경에선 아마 C++ 컴파일러도 존재할 확률이 굉장히 높습니다.
저도 OOP를 처음 배우는데 C++ 로 시작한다면 상당히 반대를 하고 싶군요. 차라리 JAVA 가 훨씬 낫습니다.
지금 프로그래밍 공부를 새로하신다면 차라리 어떤일을 앞으로 할까 고민해보고 선택하는게 100번 옳습니다.
임베디드나 하드웨어쪽 하시려면 되도록 C를 피할 수 없고, 보통 C 를 배우고 나면 기계 구조도 자연스럽게 익히기 쉽게 되어 ( ASM 등 )전산(컴공)전공자에겐 굉장히 도움이 많이 되기때문에 처음으로 하는 언어로써 C 언어도 상당히 좋습니다.
OOP 위주로 공부하면서 각종 소프트웨어 개발에 큰 관심이 있다면 ( 일반 APP 등등... ) JAVA가 옳은 선택같습니다. 현시점에선...
다만 C를 선행한 상태에서 처음으로 OOP를 익히기 시작하려면 C++도 꼭 나쁘지는 않습니다. 완전한 OOP에 굳이 목매달 필요도 없구요. 어차피 실무는 defacto 로 돌아가는게 많으니까요.
C++ 은 다만 잘하기가 상당히 어려운 언어입니다. 프로그래밍의 경험은 둘째치고라도 언어 자체를 '기초적으로' 익히려면 적어도 책 5~10 권은 봐둬야 합니다. ( 절대 농담이 아닙니다. ) 다른 언어에 비해 크게 무슨 매리트가 있는 언어도 아닙니다. 다만 게임쪽 하시려면 피할수가 없죠. ( XNA 같이 C# 이나 JAVA , 모바일쪽의 C 도 게임에선 꽤 자주 쓰이지만 C++ 을 모른다고 하면 대부분의 게임회사의 프로그래머 자리는 아예 문턱도 다가가기 힘들겁니다. )
여하튼 C 를 선행을 이미 했다면 C++ 익히는게 나쁜선택은 아니지만 ( OOP 익히기용이나 혹은 다른목적으로라도.. ) 처음부터 C++ 은 저도 반대고, C++ 을 꼭 해야하는 상황에 있더라도 C를 꼭 선행학습할 필요는 없습니다. 어차피 pointer 개념과 reference 개념( C++ 의 int& 같은 타입을 말한겁니다. ) , instance 개념 등은 배우게 되어있으니까요. C를 선행하면 C++ 을 배우는데 마치 한자를 좀 알고 ( 한국식으로 ) 중국어 공부를 하는것과 비슷하다고 비유할 수 있겠네요.
결국 언어의 선택은 자신이 무엇을 할것인가에 대해 먼저 고민해 보고 선택하시는게 좋을것 같습니다.
제 경험상 C 를 해두면 -> PHP 정도는 언어적 측면으로는 거의 껌으로 익힐 수 있습니다. 하드웨어를 다루는 직종에 취업 할 수 있을 확률이 훨씬 높아집니다. 커널 코드를 보거나 작성하는 공부를 할 수 있습니다. 포인터 개념을 확실히 다지고 넘어갈 수 있습니다. ( ASM 의 indirect 라는게 무엇인지 이해가 조금 용이합니다. )
C++ 을 잘 해두면 -> JAVA 의 프레임웍을 제외한 언어적 측면은 아주 쉽게 익힐 수 있습니다. 게임쪽으로 취직하기 유리합니다. MFC 등 부가적인 APP 작성이 용이해집니다. C# 을 익히기가 쉬워집니다.
Neogeo - Future is Now.
Neogeo - Future is Now.
말꼬리잡기입니다만 practice랑 defacto랑 혼동하신 듯...
어찌 되었든 재미있게 공부했으면 좋겠다고 생각합니다.
다른분도 이미
다른분도 이미 말씀하셨지만, C++은 C와 호환성이 뛰어난 별개의 언어일뿐입니다.
C++이면 C++이고, C면 C이지, 'C++에서의 C언어'라는 건 무슨 말인지 모르겠네요.
그리고 C코드면 C로 컴파일을 해야지 왜 C++로 컴파일을 한답니까-_-;
Obj-C가 C를 완전히 포함한다고 해서, C코드를 굳이 Obj-C컴파일러로 컴파일하진 않지요.
이게 무엇을 정확히 말한건지 모르겠습니다. 'C++에 적응 시킨 반쯤인 C++인코드'라는 것 자체가 의미 불명입니다.
예전에 긴 이야기가
예전에 긴 이야기가 있었지요.
http://kldp.org/node/25930
_Bool b =
_Bool b = true;
C++에서는 _Bool이 없어서 오류, C에서는 true가 없어서 오류입니다. :)
디버깅 모드 - return문에 닿기까지의 5줄, 그러나 언제까지나 영원한 5줄... (from 天上智喜 - Graceful 4 - 07. 5cm)
Real programmers /* don't */ comment their code.
If it was hard to write, it should be /* hard to */ read.
완벽한 파생어
완벽한 파생어 일수는 없죠. C 의 영향을 많이 받아 이름도 C++ 이지만, 개체 지향 개념은 ( 그것이 C 로도 가능하다 할지라도 ) C 에서 영향 받았다고 볼 수는 없으니까요.
C 의 모든 문법을 C++ 에서 컴파일 되게 할 수는 없지만, C 와 C++ 컴파일러에서 모두 문제 없이 컴파일 되는 C 코드를 만들 수는 있습니다. 그래서, 반론도 있겠지만, C는 C++ 의 subset 이라고 하는 얘기도 있습니다.하지만, 이걸 가지고 완벽한 파생어냐 아니냐를 따질 건 아니고 그럴 필요도 없다고 생각합니다. 그냥 역사적으로 어떻게 탄생되었나를 보면 알 수 있는 얘기 아닌가요?
C 를 C++ 보다 선행해서 배우면 유리하다기보다는, C 를 알고 있는 상태에서는 C++ 을 배우기 쉽다고 봐야겠지요. 아무튼 제 생각은 어떤 언어를 먼저 배워야된다기보다는, 언어는 도구일 뿐이기 때문에 필요에 의해 배우시면 된다고 생각합니다.
영어가 필요하면 영어를 하는 것이고, 아프리카 오지의 언어가 필요하다면 그 언어를 하는 것이죠. 컴퓨터 언어도 마찬가지입니다만, 경험상으론 C 를 배워두면 장점이 많다는 것입니다. 시스템 프로그래밍이 가능한 언어이기 때문에, 좀 더 깊은 지식까지 습득해야 할 기회가 많고, C 언어 이후 등장한 대부분의 컴파일 언어들은 문법이 C 를 닮아있는 등의 이유 때문입니다.
Orion Project : http://orionids.org
아래에 나는오리
아래에 나는오리 님도 지적하셨지만, C를 알고 있는게 오히려 C++를 배우는데 방해가 되는 경우도 있습니다. (C 언어에 대한 지식 자체가 도움이 된다는 얘기에는 동감합니다만.)
특정한 언어를 안다는 것은 그 언어의 문법과(if 뒤에는 괄호로 묶은 표현식이 와야 한다 등) 의미론(변수는 그 변수가 선언된 블록을 나갈 때 invalidate된다 등), 그리고 해당 언어를 사용하는 사람들의 문화(goto는 자제해야 한다 등)가 모두 포함된 이야기입니다. 실제로 쓸만해지려면 언어 뿐만 아니라 해당 언어와 함께 사용되는 라이브러리 등에 대한 이해도 필요하겠지만 언어 얘기니까 빼고요. C를 알고 있는게 C++를 배우는데 도움이 크게 되지 않는 이유는 C와 C++의 문화가 심각하게 다르기 때문입니다. C를 배운 사람이 C++의 문화에 익숙해지려면, 적어도 C에 익숙해지는데 걸린 시간만큼 문화에 익숙해져야 합니다.
의문이 많았던 것인데 공부하고 정리를 좀 해보자면 ^_^
우선 제가 올린 code 중
struct node *n;
n = (struct node *) 3;
n = 3; /* compile error */
에서 compile 오류를 내는 것은 C++ compiler 입니다.
C compiler는 경고를 내더군요.
http://www.cinsk.org/cfaqs/index-ko.html
C FAQs의 Q 7.7은 malloc 선언을 위한 stdlib.h가 포함(#include)되지 않았을 경우를
말하는데 이것은 예전 표준의 암시적 선언과 관련이 있는데 이것은 C99에 와서
표준에서 제외된 것으로 알고 있습니다.
http://gcc.gnu.org/gcc-4.3/c99status.html
(remove implicit function declaration)
따라서 이것을 근거로 C와 C++의 차이점을 이야기하는 것은 올바르지 않아 보입니다.
비록 C99이 실질적으로 많이 통용되지 않는다해도 말이죠.
제가 쓴 '안전'이라는 단어는 적절하지 않은 것 같네요. 쓰면서도 좀 찜찜했었는데... -_-.
'심리적 안전'이라는 말을 쓰고 싶었다고 이해해주시면 좋겠네요.
이 문제에서 malloc을 빼면 결국 void *에 대한 이야기가 되는데요.
저는 이것이 C와 C++의 입장차라고 생각합니다.
C++에서도 void *가 필요할 수 있겠지만 왠만해서는 쓰지 말자는 형태로 가고 있는 것으로 보입니다.
왜냐하면 C++에서는 template이 있으니까요.
현재 void *가 가장 필요하다고 할 수 있는 null pointer (0)의 type을 명시화하기 위한 casting
문제도 차기 표준에서 등장할 nullptr에 의해서 사라질 것으로 보입니다.
결국 void *의 사용은 C언어와의 호환을 위한 용도로만 남지 않을까 싶은게 제 예측입니다.
void *의 casting 요구가 C와 C++의 차이를 설명하는데 얼마나 중요한가는 저로서는 모르겠습니다만
글타래를 연 질문자의 이야기대로 C로 작성된 source를 C++ compiler에서 그대로 compile 하지 못하는
중요 요인 중 하나입니다.
이야기가 진행되다가 헝가리식 표기법 이야기가 나왔는데
물론 헝가리식은 많이 안 쓰이는 추세가 되었습니다만 여전히 남아 있기도 합니다.
어느 정도 따라야 하느냐라는 문제이지 모두 쓰지 말자는 이야기는 아니라고 생각합니다.
헝가리식이 쇠퇴한 이유는 여러가지가 있습니다.
하지만 해당문맥에서 변수의 정체성을 표현하는 핵심이 type일 경우는
여전히 헝가리식을 쓰게 만드는 요인이 아닐런지요.
예를 들어 흔히 책에서 등장하는 iter(iterator)나 pWidget(Widget에 대한 pointer)
같은 경우가 흔한 예지요.
실제 잘 쓰이는지는 모르겠습니다만 접두어로 a나 the를 쓰는 경우가 논의되기도 하는데
접두표기는 아닙니다만 이것도 헝가리식처럼 변수명에 type이 들어가지요.
aColor, theSun 처럼 말입니다.
the의 경우는 Singleton에서 잘 쓰일 수 있지요.
Design Pattern중 생성패턴(Creational Pattern)의 경우는 변수명이 잘 들어가는 예이기도 합니다.
저는 neogeo님의 p_node, pp_node, ppp_node의 예제에서 casting을 하는 것은
동어반복으로 밖에 보이지 않습니다.
만일 변수명을 통해 적절한 관계가 묘사된다면 casting은 함부로 하지 않는 것이 좋다고 생각합니다.
특히 pointer는 C와 C++에서 Java나 기타 고급언어들의 형변환과는 차이를 보입니다.
즉 저수준을 다루기 위한 방법으로 쓰이니까요.
Stroustrup이 이야기했던 C 형변환이 모호하다고 한 것은 제 생각에
pointer 변환이 저수준을 다루는 방식이었기 때문이라고 봅니다.
Compiler는 programmer가 저수준을 다루기 위한 방법으로 pointer 변환을
할 수 있으므로 경고조치도 내리기 곤란하지요.
C++을 공부하려는
C++을 공부하려는 분들에게
항상 사람들이 하는말이 'C부터 공부하고 하라'는 겁니다.
근데 C++은 C가 아니며
TC++PL저자도 C++은 C문법을 사용할 수 있게 했다고 말했습니다.
고로 C++의 C를 어느정도 포함하고 있는것이지 C가 아니라는 겁니다.
그리고 C++을 하기위해 C를 공부하라는 사람들의 대부분의 이유가
C++을 배우려면 C문법을 배워야 한다는 것인데
C문법을 배워야 C++을 이해하고 배울수 있는건 아니라는거죠
결국 C++은 기존의 언어형태에서 한단계 발전된 형태의 언어이지
단순히 한 언어의 업그레이드 판은 아니라는 겁니다.
C++가 C에서
C++가 C에서 파생했다는 것은 역사적인 문제고, C의 명세가 C++ 명세의 부분집합(subset)이냐 하는 것은 또 다른 문제겠지요?
경험적으로 보면 C를
경험적으로 보면 C를 보고 C++을 하는 분들중에 10에 8명 정도는
C++ 책을 아예 안보고 나서 그까이꺼 하면서 코딩을 진행 하더군요.
C처럼 코딩하고 메모리와 스트링관련 문제를 똑같이 발생시키고,
하여간에 제가 볼 때는 C++로 개발 하면서 제가 겪은 문제는
C는 C답게 C++은 C++ 답게 라면 쉽게 해결이 되지 않았을까 잠깐 생각해 봅니다. ㅋㅋ
높이 날다 떨어지면.
아푸다 ㅡ,.ㅡ
높이 날다 떨어지면.
아푸다 ㅡ,.ㅡ
C++은 어렵습니다.
다만...그만큼 얻는것도 좀 있긴하죠.
그냥 보면...만능칼 같습니다. 다만 다루기가 힘든...ㅎㅎ 그래서 재밌는? ^^
------------------------------------------
Let`s Smart Move!!
http://kalstein.tistory.com/
------------------------------------------
Let`s Smart Move!!
http://kalstein.tistory.com/