C++은 C의 확장?

mastercho의 이미지

관리자 알림 메시지: 이 글은 RisaPapa님의 http://bbs.kldp.org/viewtopic.php?t=27203 로부터 분리한 글입니다.

Quote:
C++은 위험적인 요소나 불필요한 요소를 많이 포함하고 있다고 생각됩니다. 제가 말하는 위험적인 요소는 프로그램 설계를 할때 후에 유지 보수면을 함께 고려하는 것이 쉽지 않고 한번 결정한 것으로 인해 유지보수를 할 수 없어 페기할수밖에 없는 최악의 상황이 나오지 않을까 하는 염려입니다. 아직까지 실력이 부족한 탓인지도 모르겠습니다. 반면에 C의 구문은 상대적으로 단순하고 특별히 고려해줄 필요가 없습니다. 하지만 C++에 비하면 재활용성이 아무리 고려를 하고 구상을 해도 많이 떨어지는 것 같습니다. 두 언어 모두 현재 널리 쓰이고 다른 언어가 굳이 필요할 만큼 나쁘지는 않지만 개선의 여지가 있고 약간 개선되었으면 하는 바램이 있습니다.

이말씀은 C++를 잘 몰라서 하는 말씀으로 이해하겠습니다

위에서 주장하신 말씀은 너무나 답답한 말씀이어서 ,
말이 튀어나갓다간 , 감정이 섞일수 있는 관계로 그만두겠습니다만

C++를 스스로 거의 잘 모른다고 말씀하시면서 너무나 잘아시는것처럼
단점을 꼽으셨는데 , 사실 그런 단점이 있는지 제대로 아시는지 궁금하네요
[꼽은셨던 단점은 오히려 C의 단점으로써 C++에서 오히려 극복이 된점입니다]

모르면 차라리 말을 하지 않는것만 못하다고 생각합니다

[원하시면 하나 하나 인용해서 반박해 드리겠습니다]

그럼

File attachments: 
첨부파일 크기
PDF icon J16.pdf193.41 KB
PDF icon n1457.pdf1.15 MB
파일 main.c72바이트
파일 lib.cpp3.53 KB

댓글

asheap의 이미지

chunsj wrote:
음... Java의 경우는 모르겠습니다만, ObjC는 C++와 다른 방법을 씁니다.
자세한 기술적인 내용은 Brad Cox의 논문이나 책을 보시면 되는데
C++은 가상 함수가 주가 아니기 때문에(수가 작을 것이라고 생각하고)
그 구현이 쉽지만 효율이 떨어지는 방식을 쓰고 있고, ObjC의 경우에는
모든 메시지가 동적인 바인딩을 하기 때문에 다른 방식을 씁니다. C++식으로
하면 그 테이블만으로 메모리를 다 채우고 말겠죠...

mastercho wrote:
chunsj wrote:
제가 알기론
C++에서의 가상함수는 효율이 떨어지는 것으로 알고 있습니다.

제가 알기론 자바나 C#이라고 해도 C++의 가상함수의 동작방식과
별반다를봐 없다고 생각이 되는데요?
[다른 언어들 역시 파생 클래스를 위해 내부적으로 함수포인터를 가진다고 봐지는데요?]

자바 같은 경우 오히려 무조건 가상함수가 되는게 아닌가 싶습니다
[더 비효율적으로 보이죠]

추측밖에 할수 없다면 제 가설은 C++에서 파생된 언어들은 결국
C++의 방법과 별반 다를봐 없다는것입니다

C++의 가상함수보다 더 빠르게 동작하는 메커니즘을 알고 계시는지요?

이런 상속구조에서는 어차피 이방법밖에 없다는 생각이 드네요

위에서 이야기되는 내용에 관해서 메모리 효율과 속도 효율에 관한 약간의 혼돈이 있지는 않았던 것인지 궁금합니다. 한번 확인해 주시기 바랍니다.
그리고 가상함수구현을 위해 만들어진 정적 테이블의 내용때문에 메모리가 가득차려면 도대체 얼마나 많은 가상함수를 사용해야 할지 의문이 생기는 군요.
물론 상황에 따라서 다르지만, 최근의 일반적인 환경에서는 메모리보다는 속도를 중요시해야하는 경우가 많지 않나요?

저같은 경우 게임 프로그래밍을 자주 하는 편이라 C++을 사용함으로써 C에비해 느려지는 부분에 대해서 꽤나 민감해서 C++의 기능을 사용하기 전에 C에 비한 성능 변화에대해 최소한의 테스트를 한 후에 사용하는 편입니다.(그래서 절대 exception은 사용하지 않습니다. stream은 기회비용을 고려해 보고 사용합니다.) 하지만, C++ 가상함수의 경우 많은 사람들이 경고하는 것과는 달리 최적화 옵션으로 컴파일시 거의 성능에 지장을 주지 않는 다는 결과를 얻었습니다. (최적화 끈 상태에서 비교하면 큰 속도 저하가 있었습니다.) 사실 테스트 결과를 보고, 왜 이렇게 가상함수 사용시에도 성능저하가 없는지 매우 궁금했지만, 코딩이 더 급했기 때문에 그냥 넘어갔었는데요. 여기에 계신 고수분들께서 한번 테스트해보시고, 원인 분석을 해주셨으면 정말 고맙겠습니다.

asheap의 이미지

crimsoncream wrote:
c++로 그것도 oo로 만들어진 디바이스드라이버라.
꼭 보고싶은데요. 공개된 것이 있다면 꼭 좀 알려주셨으면 합니다.
제 생각에는 oo가 하드웨어적으로 완전히 표준화가 됐거나 드라이버개발자가 스펙을 정하는 디바이스거나 efi처럼 표준적인 인터페이스를 가진 layer 위에서가 아니면 장점을 가지지 못할 거라고 생각되는데요. 이 경우조차도 가벼운 c가 좀 더 괜찮을 것 같은데.
c++이 무겁다는 건 실행속도나 memory footprint만을 말하는 건 아니고요. 위에 어떤 분이 쓰신 인터뷰에서처럼 개념적으로 디바이스와의 mapping이 간결하다는 의미에서 c가 더 가볍다는 겁니다. 물론 탁월한 c++프로그래머에겐 이것이 작은 차이이겠지만 제 주위에는 그런 경우가 없어서 정말 보고 싶군요.

'윈도우2000 디바이스 드라이버'라는 책에대해서는 어떻게 생각하실지 궁금합니다. 저도 직접 코딩을 하지 않고 그 책을 스터디만 했기 때문에 감히 함부로 머라고 말할 자격은 없지만, 그 책 내용은 상당히 감동할 만한 것들이 꽤나 있더군요.

Necromancer의 이미지

C++의 가상함수는 기계어 레벨로 들어가면 함수포인터와 같은 원리로 구현되죠.

오늘날 컴퓨터 구조에서 이런 플밍은 속도에는 쥐약입니다.
실제 프로세서 최적화 메뉴얼에도 보면 함수포인터류의 사용을 가급적 자제하라고
나와 있고요. 꼭 필요할때만 쓰라고

최적화 켠 상태에서 속도차이 별로 없었다는 것은 아무래도 그만큼 최적화 기술이
발전했다는 의미가 되겠군요. 컴파일러가 소스 흐름도나 길이를 분석해서
포인터로 구현할 부분을 그냥 일반함수호출이나 inline으로 대체하는게 아닌가
싶습니다.

Written By the Black Knight of Destruction

pynoos의 이미지

http://www.cs.ucsb.edu/labs/oocsb/papers/oopsla96.pdf

The Direct Cost of Virtual Function Calls in C++

위 자료를 보면, virtual function call을 하는데 들어간 time 비용은 5.2 %
코드 비용은 전체의 3.7%라 하고 있으며, 모든 함수를 virtual 로 취급하도록 했을 경우 13.7%의 시간을 소모하며, 코드는 13%가 된다고 하는군요.

수치는 사람에 따라 심각하게도 받아 들일 수 있겠지만, all virtual 이 아닌 상황은 괜찮아 보입니다.

최근자료없나요.. 저건 96년도 버전이라..

asheap의 이미지

저는 객체지향을 도입한 C의 경우에 함수포인터를 대량으로 사용하는 것으로 알고 있고, 그렇게 소스분석해왔고, 그렇게 짜왔습니다.(아 짰었습니다. C++을 거부하던 시절까지만 그렇게 했으니) 그렇다면 이문제점은 c에서도 발생하는 것이 아닐까라는 의문이 생깁니다. 그리고 함수 포인터를 사용하지 않는다면 어떤 방법을 사용하는 것인지 궁금하구요. 한번 시간날때 구글님에게 물어봐야겠군요.
그런데 C++의 가상함수 구현 방법은 최적화 기술이 적용가능할 수 있다는 점에서 약간 높이 사줘야 하지 않을까요?

흑기사 wrote:
C++의 가상함수는 기계어 레벨로 들어가면 함수포인터와 같은 원리로 구현되죠.

오늘날 컴퓨터 구조에서 이런 플밍은 속도에는 쥐약입니다.
실제 프로세서 최적화 메뉴얼에도 보면 함수포인터류의 사용을 가급적 자제하라고
나와 있고요. 꼭 필요할때만 쓰라고

최적화 켠 상태에서 속도차이 별로 없었다는 것은 아무래도 그만큼 최적화 기술이
발전했다는 의미가 되겠군요. 컴파일러가 소스 흐름도나 길이를 분석해서
포인터로 구현할 부분을 그냥 일반함수호출이나 inline으로 대체하는게 아닌가
싶습니다.

mastercho의 이미지

유닉스 내부 라는 책 283페이지 객체지향 설계- 여담 부분을 보면

Uresh Vahalia wrote:

vnode/vfs인터페이스는 객체지향 프로그래밍 개념을 이용해서 설계되었다. 이러한 개념들은 그후 메모리 관리,메시지기반 통신,프로세스 스케줄링등과 같은 UNIX커널의 다른 영역에 적용되었다. UNIX 커널의 발전에 적용된 객체지향 프로그래밍의 기초 개념에 대한 간단한 복습은 큰 도움이 될것이다 이러한 기술들은 자연스럽게 C++과 같은 객체지향언어에 적합하지만[Elli90],UNIX 개발자들은 커널의 나머지 부분들과의 일관성을 위해서 이들을 구현하기위해 C를 선택하였다 .... 나머지는 객체지향 이야기

책을 보면
유닉스 커널 구현에 C++이 적합하다고 인정한부분이 나오며
지속적으로 책에서 언급하며
핵심 커널 역시 객체지향을 적용하는게것이 좋다고 인정하는부분이 상당히
자주 나오는걸 볼수 있습니다

위내용을 봐도 C를 써서 커널을 개발하는건 일관성을 위해서 일뿐입니다

커널에서 조차 이렇게 쓰이는데 부적합하다는 말은 듣기가 뭐하네요
간단한 C++ 코드를 C로 삽질한 코드가 더 좋은건 분명 아닐겁니다

물론 이런 개념을 C로도 구현할수 있지만 결국 C++의 구현을 삽질한
결과일뿐이고 , 삽질한 결과가 C++보다 빠르긴 어렵습니다

어차피 C++도 내부적으로는 C로 삽질해 만들어놓은 객체지향과
거의 같기 때문이죠

[이부분은 C++ 책을 보신분이라면 이해가가실거라 믿네요]

승자는 자기보다 우월한 사람을 보면 존경심을 갖고 그로부터 배울 점을 찾지만 패자는 자기보다 우월한 사람을 만나면 질투심을 갖고 어디 구멍난 곳이 없는지 찾는다.
- 하비스

akbar의 이미지

...

chunsj의 이미지

Sorry, I cannot write in Hangul... T_T

The book does not say C++ is more appropriate language, instead,
it says OOPL is more appropriate choice. Then more perfect OOPL such
as Smalltalk(or Objective-C in terms of efficiency) is best choice, isn't it? :-)

mastercho wrote:
유닉스 내부 라는 책 283페이지 객체지향 설계- 여담 부분을 보면

Uresh Vahalia wrote:

vnode/vfs인터페이스는 객체지향 프로그래밍 개념을 이용해서 설계되었다. 이러한 개념들은 그후 메모리 관리,메시지기반 통신,프로세스 스케줄링등과 같은 UNIX커널의 다른 영역에 적용되었다. UNIX 커널의 발전에 적용된 객체지향 프로그래밍의 기초 개념에 대한 간단한 복습은 큰 도움이 될것이다 이러한 기술들은 자연스럽게 C++과 같은 객체지향언어에 적합하지만[Elli90],UNIX 개발자들은 커널의 나머지 부분들과의 일관성을 위해서 이들을 구현하기위해 C를 선택하였다 .... 나머지는 객체지향 이야기

책을 보면
유닉스 커널 구현에 C++이 적합하다고 인정한부분이 나오며
지속적으로 책에서 언급하며
핵심 커널 역시 객체지향을 적용하는게것이 좋다고 인정하는부분이 상당히
자주 나오는걸 볼수 있습니다

위내용을 봐도 C를 써서 커널을 개발하는건 일관성을 위해서 일뿐입니다

커널에서 조차 이렇게 쓰이는데 부적합하다는 말은 듣기가 뭐하네요
간단한 C++ 코드를 C로 삽질한 코드가 더 좋은건 분명 아닐겁니다

물론 이런 개념을 C로도 구현할수 있지만 결국 C++의 구현을 삽질한
결과일뿐이고 , 삽질한 결과가 C++보다 빠르긴 어렵습니다

어차피 C++도 내부적으로는 C로 삽질해 만들어놓은 객체지향과
거의 같기 때문이죠

[이부분은 C++ 책을 보신분이라면 이해가가실거라 믿네요]

mastercho의 이미지

chunsj wrote:
Sorry, I cannot write in Hangul... T_T

The book does not say C++ is more appropriate language, instead,
it says OOPL is more appropriate choice. Then more perfect OOPL such
as Smalltalk(or Objective-C in terms of efficiency) is best choice, isn't it?

여기서부터는 거의 말장난 수준으로 가는거 같네요
객체지향 개념이 필요한데 C로 삽질하는것보다 C++이 낫다는 의미로 받아들여도 무리는 없습니다
스몰토크나 오브젝트-C까지 끌어들이면서 , 그런식으로 옹호하는건
궁색하다는 느낌 마저 드네요

인정할건 인정하고 다른 대안이나 토론을 하는게 좋지 않나 싶네요

승자는 자기보다 우월한 사람을 보면 존경심을 갖고 그로부터 배울 점을 찾지만 패자는 자기보다 우월한 사람을 만나면 질투심을 갖고 어디 구멍난 곳이 없는지 찾는다.
- 하비스

이한길의 이미지

mastercho wrote:
객체지향 개념이 필요한데 C로 삽질하는것보다 C++이 낫다는 의미로 받아들여도 무리는 없습니다

맞습니다. 진정 C로 삽질하는것보다는 C++로 프로그래밍하는것이 낫지요..

예전에 객체지향개념이 필요한 경우에는 C++이 유일한 대안인줄 알았는데, 그래서 C++에 매달리기도 했는데, C로 해결 가능해지고 나서부터 C++을 다시 보게 되었습니다.. 조금 좋지 않을 계기가 되었는지도 모르겠습니다. 아무튼 저도 삽질을 통해 해결이 가능해졌으니... 공부를 위해서는 꼭 나쁘다고만 할수도 없겠지요.

하지만 요즘도 C++로 하다가 갑자기 C로 하려면 답답함을 느끼기도 합니다. 또 그러다가 C로 하다가 C++로 하려면 벅찬 느낌을 받기도 합니다.

그런데 조금 아쉬운건 C++은 컴파일 속도가 C에 비하면 너무 깁니다.
신텍스가 그러니 어쩔수 없는거겠지만 그래도 좀 아쉽네요..

mastercho wrote:
제가 알기론 자바나 C#이라고 해도 C++의 가상함수의 동작방식과
별반다를봐 없다고 생각이 되는데요?
[다른 언어들 역시 파생 클래스를 위해 내부적으로 함수포인터를 가진다고 봐지는데요?]

자바 같은 경우 오히려 무조건 가상함수가 되는게 아닌가 싶습니다
...
C++의 가상함수보다 더 빠르게 동작하는 메커니즘을 알고 계시는지요?
[더 비효율적으로 보이죠]

아직까지 JVM내부 동작원리같은것은 모르지만.. 제가 둔한 생각으로 고려해봤을때는 JVM내부에서는 조금 다를것 같네요. 함수포인터가 함수 이름을 인자로 넘겨서 실행시키는 그런 거지요.. 인터프리터로 실행되는 언어들은 굳이 함수에 대한 포인터를 사용해서 이런 부분을 처리할 필요가 없지 않을까요?

... 써놓고 생각해보니 언급하신분이 계신것 같습니다 ...

그런데 한가지 덛붙이고 싶은것은 가상함수보다 빠르게 동작하는 메커니즘이 있어도 ... 움.. 제가 잘 몰라서인지도 모르겠지만 가상함수 없이 다형성이 가능한가요? 불가능하다면 안쓸수 없잖아요.. 다형성이 없다면 OOP라 할수 없을텐데요.. 또 C에서도 객체지향방식의 프로그래밍을 위해서는 함수에 대한 포인터를 사용하게 되지 않나 싶습니다.

crimsoncream wrote:
c++로 그것도 oo로 만들어진 디바이스드라이버라.
꼭 보고싶은데요. 공개된 것이 있다면 꼭 좀 알려주셨으면 합니다.

예전에 오랄리사의 C/C++로 하는 임베디드 프로그래밍 책을 본적이 있습니다. 임베디드 프로그래밍도 C++로 잘 되는것 같더라구요... 실습은 안해봐서.. 아무튼 그거라도 보시면 좋을것 같습니다.

----
먼저 알게 된 것을 알려주는 것은 즐거운 일이다!
http://hangulee.springnote.com
http://hangulee.egloos.com

방준영의 이미지

아주 간단한 벤치마크 프로그램을 작성해 봤습니다. C++로 프로그램 한지 10년도 넘은 것 같은데 제대로 짠 건지 모르겠네요. :)

#include <sys/types.h>
#include <sys/time.h>
#include <iostream>

using namespace std;

class base {
public:
	int ordinary_func(int a, int b);
	virtual int virtual_func(int a, int b);
};

int base::ordinary_func(int a, int b) { return a + b; }
int base::virtual_func(int a, int b) { return a + b; }

class derived : public base {
public:
	int ordinary_func(int a, int b);
	virtual int virtual_func(int a, int b);
};

int derived::ordinary_func(int a, int b) { return a - b; }
int derived::virtual_func(int a, int b) { return a - b; }

#define NLOOPS 0x80000000

static inline unsigned long long
rdtsc(void)
{
	unsigned long long cnt;

	asm volatile("rdtsc" : "=A" (cnt));
	return cnt;
}

main()
{
	base *parent = new base;
	derived *child = new derived;

	cout << parent->ordinary_func(10, 10) << endl;
	cout << parent->virtual_func(10, 10) << endl << endl;

	cout << child->ordinary_func(10, 10) << endl;
	cout << child->virtual_func(10, 10) << endl << endl;

	child = (derived *)parent;

	cout << child->ordinary_func(10, 10) << endl;
	cout << child->virtual_func(10, 10) << endl << endl;

	unsigned int i;
	volatile unsigned int j;
	unsigned long long last_tsc;
	unsigned long long clock_tick;

	last_tsc = rdtsc();
	for (i = 0; i < NLOOPS; i++)
		j = child->ordinary_func(i, i);
	clock_tick = rdtsc() - last_tsc;
	printf("ordinary function: %lld clock cycles\n", clock_tick);

	last_tsc = rdtsc();
	for (i = 0; i < NLOOPS; i++)
		j = child->virtual_func(i, i);
	clock_tick = rdtsc() - last_tsc;
	printf("virtual function: %lld clock cycles\n", clock_tick);
}

시험 결과를 놓고 보니 아마도 지금쯤 C++이 만들어졌더라면 가상 함수같은 용어는 존재하지도 않았을 것 같습니다. 모든 메쏘드가 가상 함수일 테니까요. :)

mastercho의 이미지

방준영님 컴백하셨네요~ 방가워여~

방준영 wrote:
시험 결과를 놓고 보니 아마도 지금쯤 C++이 만들어졌더라면 가상 함수같은 용어는 존재하지도 않았을 것 같습니다. 모든 메쏘드가 가상 함수일 테니까요.

그래서 요즘 언어는 디폴트로 가상함수를 사용하는거 같드라고요 -_-;
그래도 임베디드 시스템에서 오용하면 성능저하가 있긴 있는거 같습니다

Applied C++ 이라는 책을 보면 , C++로 엄청난 프레임웍을 구축해서
임베디드 시스템에 적용해 프로그래밍하였더니 속도가 엄청느려진 경우가 있긴
있더라고 소개해주더라고요 ,

임베디드 시스템 마다 다르겠지만 , 컴파일러마다도 약간식은 다르겠죠^^

근데 나온 결과가 3%차이네요 -_-; 음.. 너무 적게 차이가 나니까
만족스럽기 보다 오히려 실망스럽기까지 하네요 ㅎㅎ

승자는 자기보다 우월한 사람을 보면 존경심을 갖고 그로부터 배울 점을 찾지만 패자는 자기보다 우월한 사람을 만나면 질투심을 갖고 어디 구멍난 곳이 없는지 찾는다.
- 하비스

girneter의 이미지

저 역시 방준영님 반갑습니다.
앞으로 좋은 글 많이 남겨 주세요.

방준영님 플그림 돌려보니까
저는
ordinary function: 41813811212 clock cycles
virtual function: 56838649872 clock cycles

라는 결과가 나오네요.

이 정도면 큰 차이 아닌가요?
3% 차이는 분명 아닌데...

개념없는 초딩들은 좋은 말로 할때 DC나 웃대가서 놀아라. 응?

죠커의 이미지

akbar wrote:
그러나 C++ 코딩시에 네임맹글링이 일어나지 않아야 되는 상황이 과연 많이 발생할까요
만약에 윈도우 계열에서 라이브러리용 함수를 만든다면 네임맹글링이 일어나서는 안되므로 C++ 은 장점이 없어질 듯도 합니다. 아주 없어질까요.

시스템 프로그래밍의 범위를 한정시켜서 생각하시는 것 같습니다. 크로스 컴파일러가 필요한 경우도 있고 C로 짜여진 코드와 혼합. Objective C로 짜여진 코드와 혼합해야 하는 상황은 생각보다 많습니다. 단순히 링커만 달라져도 수천, 수만개의 에러를 뱉어냅니다.

그리고 많이 발생할까요라는 단어가 프로그래밍에서 위험하다고 생각합니다. C++의 장점은 없어질 듯도 합니다 부분에 대해서는 아래글과 함께 리플을 달겠습니다.

akbar wrote:
그러나 거꾸로 생각해보면 C++ 에서 절반이 없어지는게 아니고 절반이나 활용여지가 남은 것으로 생각하고 싶습니다.

꺼꾸로 생각하면 절반만 이용하려고 C++로 힘들게 프로그래밍하는 것이라고 볼수도 있습니다. 그냥 C만 쓰는 것에 비해서 힘들게 제약조건에 맞춰서 C+을 쓰는게 시스템 프로그래밍을 하기에 편할까요?

방준영의 이미지

girneter wrote:
저 역시 방준영님 반갑습니다.
앞으로 좋은 글 많이 남겨 주세요.

고맙습니다. 8)

Quote:
방준영님 플그림 돌려보니까
저는
ordinary function: 41813811212 clock cycles
virtual function: 56838649872 clock cycles

라는 결과가 나오네요.

이 정도면 큰 차이 아닌가요?
3% 차이는 분명 아닌데...


혹시 펜티엄 4를 쓰시나요? 저는 애슬론에서 mastercho님과 비슷하게 몇% 되지 않는 차이를 얻었습니다만.

하지만 이것은 일반 함수와 가상 함수가 날 수 있는 최악의 속도차이기 때문에, 실제 프로그램 성능에는 거의 영향을 끼치지 않는다고 해도 무방할 정도입니다. 요즘처럼 GHz 프로세서 시대에는 기계어 명령어 몇 개 정도 절약하는 미세최적화는 별로 의미가 없고, 알고리즘을 어떻게 작성하느냐(O(n) 대 O(1)과 같은), 캐시 메모리를 얼마나 잘 활용하느냐 등이 성능의 관건이더군요.

chunsj의 이미지

말장난이 아니라 C의 자원을 활용도 할 수 있으면서 OOP를 지원하는 것이
더 좋다면, OOP가 더 잘되는 ObjC를 쓰는 것이 나을 수도 있다는 말이었
습니다. 왜 C++만 써야 된다고 생각하시나요? 저는 그게 더 이상하다고
생각되는데요?

mastercho wrote:
chunsj wrote:
Sorry, I cannot write in Hangul... T_T

The book does not say C++ is more appropriate language, instead,
it says OOPL is more appropriate choice. Then more perfect OOPL such
as Smalltalk(or Objective-C in terms of efficiency) is best choice, isn't it?

여기서부터는 거의 말장난 수준으로 가는거 같네요
객체지향 개념이 필요한데 C로 삽질하는것보다 C++이 낫다는 의미로 받아들여도 무리는 없습니다
스몰토크나 오브젝트-C까지 끌어들이면서 , 그런식으로 옹호하는건
궁색하다는 느낌 마저 드네요

인정할건 인정하고 다른 대안이나 토론을 하는게 좋지 않나 싶네요

chunsj의 이미지

다시 원론으로 돌아가는 것 같은데... 앞에 누군가가 하신 말처럼 right tool
for right job인 것 같습니다. 그 차이가 중요한 상황이라면 C가 최선의
선택이 될 것이고 그게 아니라면 개발자의 취향에 따르겠지요. 그리고 제가
경험한 바로는 커널에서는 그 차이가 장난이 아니었습니다.(무시할 정도로
작은 것도 뭉치면 장난이 아니더군요...)

방준영 wrote:
girneter wrote:
저 역시 방준영님 반갑습니다.
앞으로 좋은 글 많이 남겨 주세요.

고맙습니다. 8)

Quote:
방준영님 플그림 돌려보니까
저는
ordinary function: 41813811212 clock cycles
virtual function: 56838649872 clock cycles

라는 결과가 나오네요.

이 정도면 큰 차이 아닌가요?
3% 차이는 분명 아닌데...


혹시 펜티엄 4를 쓰시나요? 저는 애슬론에서 mastercho님과 비슷하게 몇% 되지 않는 차이를 얻었습니다만.

하지만 이것은 일반 함수와 가상 함수가 날 수 있는 최악의 속도차이기 때문에, 실제 프로그램 성능에는 거의 영향을 끼치지 않는다고 해도 무방할 정도입니다. 요즘처럼 GHz 프로세서 시대에는 기계어 명령어 몇 개 정도 절약하는 미세최적화는 별로 의미가 없고, 알고리즘을 어떻게 작성하느냐(O(n) 대 O(1)과 같은), 캐시 메모리를 얼마나 잘 활용하느냐 등이 성능의 관건이더군요.

sandro의 이미지

곧 정의되는 새로운 C++ 표준에는 name magling 형식이 들어 있다고 합니다. 뭐 이게 정해지고 한참후에나 컴파일러마다 정착 되겠지만 말입니다.

無心

junghwanz의 이미지

Quote:
다시 원론으로 돌아가는 것 같은데... 앞에 누군가가 하신 말처럼 right tool
for right job인 것 같습니다. 그 차이가 중요한 상황이라면 C가 최선의
선택이 될 것이고 그게 아니라면 개발자의 취향에 따르겠지요. 그리고 제가
경험한 바로는 커널에서는 그 차이가 장난이 아니었습니다.(무시할 정도로
작은 것도 뭉치면 장난이 아니더군요...)

저도 이말씀에 동감을 합니다.
C와 C++의 성능 차이라는 것은 정말 별 의미가 없는것 같습니다.
embedded system 이라고 해도 C로 C++ 흉내를 내야할 경우가 가끔씩은 있죠?? 저같은 경우에는 USART로 시스템 설정 메뉴나 FND로 시스템을 설정하는 메뉴와 같은 경우들에만 그런짓을 합니다. 비용을 따져보았을경우에 훨씬 이득이겠죠. 이때는 C++을 사용해도 상관없을 듯 합니다. 근데 단지 이거하나에 써먹기 위해서 C++을 쓴다는게 좀 말이 안되죠.
중요한건 C/C++의 차이가 아니고 구현의 차이라고 생각이 되어집니다.
embedded system에서는 속도를 희생하면서 C++의 기능을 사용할 일이 많지 않았습니다.

Quote:
그래서 요즘 언어는 디폴트로 가상함수를 사용하는거 같드라고요 -_-;
그래도 임베디드 시스템에서 오용하면 성능저하가 있긴 있는거 같습니다

Applied C++ 이라는 책을 보면 , C++로 엄청난 프레임웍을 구축해서
임베디드 시스템에 적용해 프로그래밍하였더니 속도가 엄청느려진 경우가 있긴
있더라고 소개해주더라고요 ,

임베디드 시스템 마다 다르겠지만 , 컴파일러마다도 약간식은 다르겠죠^^

근데 나온 결과가 3%차이네요 -_-; 음.. 너무 적게 차이가 나니까
만족스럽기 보다 오히려 실망스럽기까지 하네요 ㅎㅎ

그건 당연히 CPU와 O/S 따라서 clock을 소요하는 값이 달라지는것 아닌가요?
그리고 그 예제를 가지고 정확히 virtual 함수가 몇 clock 차이인지 알수가 있죠?? 지금 O/S를 위에서 그 프로그램을 돌리고 그것을 출력해서 본것이 3%로 차이라면 단지 함수 콜만을 따졋을때의 비용은 엄청난 것입니다.
오직 그 process만을 돌려봐야 정확한 clock 차이값을 알수 있을듯한데요. 그 예제는 O/S의 차이에도 엄청나 차이를 보일것입니다.
진짜 정확히 두 call의 차이를 퍼센테이지로 보고 싶으시다면 하려면 모든 interrupt 다 죽이고 process 다내리고 memory data line에 값을 쓰고 scope로 찍어보시죠.
그리고 굳이 예제로 돌려보지 않아도 함수포인터를 이용한 call과 일반함수 call은 비용이 정확히 2배로 아닌가요??
혹시 이글이 C++이 C보다 성능이 나쁘다는 글로 보이신다면 역시 제 글재주는 없는 것이군요. 제 이야기는 C든 C++이든 어떤 기능을 사용할때 성능차이가 있다는 것이구요.
그렇다고 embedded system이 꼭 C만 쓰는것은 아닙니다.
냉장고 같이 허접한 마이크로 프로세서가 들어가는 곳은 C로 충분하구요.
복잡한 상이한 프로토콜을 처리하는 좋은 마이크로 프로세서가 들어가 있는곳은 C++로 짜는것도 좋다고 생각합니다. 이유는 재사용성과 유지보수를 위해서.

암튼 제가 하고 싶은 말은 딱 한마디 였습니다. 닭잡는데 닭잡는칼 쓰고 소잡는데 소잡는칼 씁시다. 소잡는데 닭잡는칼 쓰면 엄청 많이 찔러야하고 닭잡는데 소잡는칼 쓰면 조준하기 힘들 것입니다.

어떠한 충고나 반박도 감사히 받아들이겠습니다.

아 그리고 궁금한게 하나 있는것이 소프트웨어 공학 전공한 박사가 그러는데 C++로는 OOP에 반인가 70%인가만 적용가능하다던데 그 이유를 자세히 물어보지 못했거든요. 그 이유를 아시나요??

junghwanz의 이미지

Quote:
다시 원론으로 돌아가는 것 같은데... 앞에 누군가가 하신 말처럼 right tool
for right job인 것 같습니다. 그 차이가 중요한 상황이라면 C가 최선의
선택이 될 것이고 그게 아니라면 개발자의 취향에 따르겠지요. 그리고 제가
경험한 바로는 커널에서는 그 차이가 장난이 아니었습니다.(무시할 정도로
작은 것도 뭉치면 장난이 아니더군요...)

저도 이말씀에 동감을 합니다.
C와 C++의 성능 차이라는 것은 정말 별 의미가 없는것 같습니다.
embedded system 이라고 해도 C로 C++ 흉내를 내야할 경우가 가끔씩은 있죠?? 저같은 경우에는 USART로 시스템 설정 메뉴나 FND로 시스템을 설정하는 메뉴와 같은 경우들에만 그런짓을 합니다. 비용을 따져보았을경우에 훨씬 이득이겠죠. 이때는 C++을 사용해도 상관없을 듯 합니다. 근데 단지 이거하나에 써먹기 위해서 C++을 쓴다는게 좀 말이 안되죠.
중요한건 C/C++의 차이가 아니고 구현의 차이라고 생각이 되어집니다.
embedded system에서는 속도를 희생하면서 C++의 기능을 사용할 일이 많지 않았습니다.

Quote:
그래서 요즘 언어는 디폴트로 가상함수를 사용하는거 같드라고요 -_-;
그래도 임베디드 시스템에서 오용하면 성능저하가 있긴 있는거 같습니다

Applied C++ 이라는 책을 보면 , C++로 엄청난 프레임웍을 구축해서
임베디드 시스템에 적용해 프로그래밍하였더니 속도가 엄청느려진 경우가 있긴
있더라고 소개해주더라고요 ,

임베디드 시스템 마다 다르겠지만 , 컴파일러마다도 약간식은 다르겠죠^^

근데 나온 결과가 3%차이네요 -_-; 음.. 너무 적게 차이가 나니까
만족스럽기 보다 오히려 실망스럽기까지 하네요 ㅎㅎ

그건 당연히 CPU와 O/S 따라서 clock을 소요하는 값이 달라지는것 아닌가요?
그리고 그 예제를 가지고 정확히 virtual 함수가 몇 clock 차이인지 알수가 있죠?? 지금 O/S를 위에서 그 프로그램을 돌리고 그것을 출력해서 본것이 3%로 차이라면 단지 함수 콜만을 따졋을때의 비용은 엄청난 것입니다.
오직 그 process만을 돌려봐야 정확한 clock 차이값을 알수 있을듯한데요. 그 예제는 O/S의 차이에도 엄청나 차이를 보일것입니다.
진짜 정확히 두 call의 차이를 퍼센테이지로 보고 싶으시다면 하려면 모든 interrupt 다 죽이고 process 다내리고 memory data line에 값을 쓰고 scope로 찍어보시죠.
그리고 굳이 예제로 돌려보지 않아도 함수포인터를 이용한 call과 일반함수 call은 비용이 정확히 2배로 아닌가요??
혹시 이글이 C++이 C보다 성능이 나쁘다는 글로 보이신다면 역시 제 글재주는 없는 것이군요. 제 이야기는 C든 C++이든 어떤 기능을 사용할때 성능차이가 있다는 것이구요.
그렇다고 embedded system이 꼭 C만 쓰는것은 아닙니다.
냉장고 같이 허접한 마이크로 프로세서가 들어가는 곳은 C로 충분하구요.
복잡한 상이한 프로토콜을 처리하는 좋은 마이크로 프로세서가 들어가 있는곳은 C++로 짜는것도 좋다고 생각합니다. 이유는 재사용성과 유지보수를 위해서.

암튼 제가 하고 싶은 말은 딱 한마디 였습니다. 닭잡는데 닭잡는칼 쓰고 소잡는데 소잡는칼 씁시다. 소잡는데 닭잡는칼 쓰면 엄청 많이 찔러야하고 닭잡는데 소잡는칼 쓰면 조준하기 힘들 것입니다.

어떠한 충고나 반박도 감사히 받아들이겠습니다.

아 그리고 궁금한게 하나 있는것이 소프트웨어 공학 전공한 박사가 그러는데 C++로는 OOP에 반인가 70%인가만 적용가능하다던데 그 이유를 자세히 물어보지 못했거든요. 그 이유를 아시나요??

mastercho의 이미지

jhlee1976 wrote:
진짜 정확히 두 call의 차이를 퍼센테이지로 보고 싶으시다면 하려면 모든 interrupt 다 죽이고 process 다내리고 memory data line에 값을 쓰고 scope로 찍어보시죠.

좀 이상한 발상이 아닌가 싶네요

여러가지 변수의 요인이 있겠지만, 다른 프로세스 다 죽였다고 해서
이 차이가 획기적으로 변할거라고는 전혀 생각할수 없습니다

어차피 실제 환경에서도 프로그램이란 프로세스 단하나로 돌아가지 않죠

기타 몇가지 다른 프로세스가 있다고 해서
저 %차이가 크게 변할거라는건 억지 같네요

어차피 virtual사용할때나 사용하지 않을때나 비슷하게 다 영향을 미칠테니까여
여러번 테스트 해서도 마찬가지 결과라면, 어떠시겠습니까?


음 컴퓨터 마다 차이는 분명 존재하긴 하는군요
서버 컴퓨터에서는 3%에 불과 하던것이 다른 일반 컴퓨터에서는
큰 차이를 보이기도 하네요

개인 컴퓨터에서 프로세스 다 죽인 상태에서 테스트를 해보니
30%가까이 차이가 나기도 하는데 , 결국 프로세스를 다 죽인상태나
아닌 상태나 크게 차이가 나진 않았습니다 [%비율은 거의 같음]

개인용 컴퓨터는 cygwin를 써서 테스트했는데 정확한 이유는...
잘 모르겠네여

이러한 차이가 컴퓨터 구조의 차이에서 오는것일지도 모르겠군요
[서버 컴퓨터와[좋은거] 개인용 컴퓨터 와의 차이]

서버 컴퓨터에서는 아무리 많이 해봐도 2-3%내입니다

개인용 컴퓨터에는 , 글세요 , 조금 남아 있던 process까지 죽이지 않아서인지
구조적으로 좀 이런부분이 최적화 들되어서인지는 잘 모르겠습니다만은
분명 30%가 넘게 차이가 날때도 있네요

승자는 자기보다 우월한 사람을 보면 존경심을 갖고 그로부터 배울 점을 찾지만 패자는 자기보다 우월한 사람을 만나면 질투심을 갖고 어디 구멍난 곳이 없는지 찾는다.
- 하비스

방준영의 이미지

jhlee1976 wrote:
그건 당연히 CPU와 O/S 따라서 clock을 소요하는 값이 달라지는것 아닌가요?
그리고 그 예제를 가지고 정확히 virtual 함수가 몇 clock 차이인지 알수가 있죠?? 지금 O/S를 위에서 그 프로그램을 돌리고 그것을 출력해서 본것이 3%로 차이라면 단지 함수 콜만을 따?을때의 비용은 엄청난 것입니다.

그 3%라는 것은 함수 호출 21억 4천 7백만여번을 했을 때 나온 차이입니다. 현실적으로 도저히 일어날 수가 없는 최악의 상황이죠. 마침 제 앞에 있는 어떤 함수의 어셈블리 리스팅을 보니 120라인 중 call 명령이 여섯 개 있군요. 이 경우 실제 성능 차이는 대충 0.03 * 0.05 = 0.0015% 정도 되겠습니다. 0.0015% 차이라는 것은 한 시간 걸리는 일과 한시간 0.054초 걸리는 일의 차이입니다. 그러므로 0.054초라는 시간을 엄청난 비용이라고 말할 수 있다면, 하신 말씀은 맞습니다.

Quote:
오직 그 process만을 돌려봐야 정확한 clock 차이값을 알수 있을듯한데요. 그 예제는 O/S의 차이에도 엄청나 차이를 보일것입니다.
진짜 정확히 두 call의 차이를 퍼센테이지로 보고 싶으시다면 하려면 모든 interrupt 다 죽이고 process 다내리고 memory data line에 값을 쓰고 scope로 찍어보시죠.

같은 컴퓨터에서 NetBSD, FreeBSD, 리눅스로 전부 돌려봤더니 거의 비슷한 결과를 얻었습니다. 직접 해보시고 결과를 말씀해 주시면 감사하겠습니다.

그리고 요즘 마이크로프로세서는 파이프라인 구조이기 때문에 단순히 인터럽트를 끄고 프로세스를 다 죽인다고 해서 명령별로 정확한 클럭 사이클을 구할 수는 없습니다. 인텔이나 AMD라면 모를까요. 물론 정확한 클럭 사이클이라는 것도 여기서는 거의 무의미합니다. 벤치마크는 일정한 경향성을 알아보는 것이지 미미한 수치를 놓고 판가름하는 것은 아니니까요.

Quote:
그리고 굳이 예제로 돌려보지 않아도 함수포인터를 이용한 call과 일반함수 call은 비용이 정확히 2배로 아닌가요??

mov 명령과 call 명령의 비용이 정확히 같다면 그말은 사실입니다. 하지만 실제로는 call 명령이 몇(십) 배 이상 비싸죠.
akbar의 이미지

...

mastercho의 이미지

mastercho wrote:
유닉스 내부 라는 책 283페이지 객체지향 설계- 여담 부분을 보면

Uresh Vahalia wrote:

vnode/vfs인터페이스는 객체지향 프로그래밍 개념을 이용해서 설계되었다. 이러한 개념들은 그후 메모리 관리,메시지기반 통신,프로세스 스케줄링등과 같은 UNIX커널의 다른 영역에 적용되었다. UNIX 커널의 발전에 적용된 객체지향 프로그래밍의 기초 개념에 대한 간단한 복습은 큰 도움이 될것이다 이러한 기술들은 자연스럽게 C++과 같은 객체지향언어에 적합하지만[Elli90],UNIX 개발자들은 커널의 나머지 부분들과의 일관성을 위해서 이들을 구현하기위해 C를 선택하였다 .... 나머지는 객체지향 이야기

이건 결론을 내릴수 있지 않나 싶네요

Quote:
적당한 곳에 적당한 언어를 사용하는것이 옮다

이걸 토대로 , 커널은 C가 적합하다고 결론 내린것은 잘못입니다

어차피 C로 객체지향을 삽질해 놓은 커널코드가 적합하다고 위에 결론을
내리셨다면,
C++로 깔끔하게 객체지향을 구현하는것이 더 좋다는 결론을
쉽게 내릴수 있습니다
[내부는 어차피 서로 같으니까요
굳이 오브젝트 C같은것을 들먹이지 않아도
객체지향의 커널 코드를 C로 삽질한 코드가 적합하다면 C++로 짜놓은 코드도 결국 동일한 코드가 되므로
C++도 적합하다는것입니다 이해를 하시길
]

결론은
분명 운영체제도 객체지향적으로 짜여 졌으며 C++에게도 적합하다는것을
내릴수 있습니다

만약 가상함수가 필요없다면 C++에서도 사용안하면 그만입니다
C적인 요소만 필요하다해도 마찬가지겠죠?

승자는 자기보다 우월한 사람을 보면 존경심을 갖고 그로부터 배울 점을 찾지만 패자는 자기보다 우월한 사람을 만나면 질투심을 갖고 어디 구멍난 곳이 없는지 찾는다.
- 하비스

chunsj의 이미지

Again, sorry for poor english :-)

Yes, C++ could be a languages of choice during OS implementation,
but it's not because it's good OOPL(it's denied by the creator of OOP
concept) nor because it's more compatible with C(Objective-C is more
compatible, actually no difference at all. And Objective-C not Object-C).
If C++ were used in OS impelementation, I'll bet the major reason will
be that they think there's many number of programmers who think
they know OOP(because they know C++), ie., matketing buzz
words(Actually this is why Java team selects C++ alike syntax for Java,
despite that the major concept is closer to Smalltalk and this is
successful at least for popularity).

If UNIX implementors have chosen C as a primary language, there's
much proper reasons other than consistency only.

Again, I do not say C++ should not be used at all, I just say that C++
is not best choice for all cases(Especially for OS implementation, in
terms of speed and efficiency). I also do not use ObjC for all cases. If
efficiency is required, I'll choose C and some hand optimzied assembly
then wrap them up with clean, object oriented API( with ObjC if it's
proper).

PS)
I use C++, too. I built goverment sponsored integrated design
system with C++, because in that case C++ is best choice.
If OOP is major objective, use more proper OOPL, if efficiency is major
objective, use efficient machine oriented languages. If your major
library to use is in C++ and it's required to use static language for
secure, robust system, use C++. Right tool for right job, again.
Choose best tool, not possible tool. This is what I want to say. :-)

mastercho wrote:
mastercho wrote:
유닉스 내부 라는 책 283페이지 객체지향 설계- 여담 부분을 보면

Uresh Vahalia wrote:

vnode/vfs인터페이스는 객체지향 프로그래밍 개념을 이용해서 설계되었다. 이러한 개념들은 그후 메모리 관리,메시지기반 통신,프로세스 스케줄링등과 같은 UNIX커널의 다른 영역에 적용되었다. UNIX 커널의 발전에 적용된 객체지향 프로그래밍의 기초 개념에 대한 간단한 복습은 큰 도움이 될것이다 이러한 기술들은 자연스럽게 C++과 같은 객체지향언어에 적합하지만[Elli90],UNIX 개발자들은 커널의 나머지 부분들과의 일관성을 위해서 이들을 구현하기위해 C를 선택하였다 .... 나머지는 객체지향 이야기

이건 결론을 내릴수 있지 않나 싶네요

Quote:
적당한 곳에 적당한 언어를 사용하는것이 옮다

이걸 토대로 , 커널은 C가 적합하다고 결론 내린것은 잘못입니다

어차피 C로 객체지향을 삽질해 놓은 커널코드가 적합하다고 위에 결론을
내리셨다면,
C++로 깔끔하게 객체지향을 구현하는것이 더 좋다는 결론을
쉽게 내릴수 있습니다
[내부는 어차피 서로 같으니까요
굳이 오브젝트 C같은것을 들먹이지 않아도
객체지향의 커널 코드를 C로 삽질한 코드가 적합하다면 C++로 짜놓은 코드도 결국 동일한 코드가 되므로
C++도 적합하다는것입니다 이해를 하시길
]

결론은
분명 운영체제도 객체지향적으로 짜여 졌으며 C++에게도 적합하다는것을
내릴수 있습니다

만약 가상함수가 필요없다면 C++에서도 사용안하면 그만입니다
C적인 요소만 필요하다해도 마찬가지겠죠?

pynoos의 이미지

C++98 다음 표준화 일정이나 논의되고 있는 것에 대한 자료입니다.

출처는..

http://www-cdserver.fnal.gov/cd_public/sag/J16/

그리고 다른 제안되는 것들을 보시려면..

http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/

댓글 첨부 파일: 
첨부파일 크기
PDF icon 0바이트
mastercho의 이미지

위에 사이트 내용에서 , 진행되는 C++표준에 관한것들중 이런게 있네요

Quote:
Sample Defect Report

Library Issue 69: “Must elements of a vector be contiguous?”
Affects clause 23.2.4
Status: DR (accepted defect w/ agreed resolution)
Resolution: “The elements of a vector are stored contiguously….”

다른 주제로 분리 되어야 할지도 모르는 내용입니다
[^^ 게시판 장님이 알아서 해주시겠죠?]

전에 친구와 배열에 관해 토론을 한게 있는데
배열이 반드시 메모리에서 직열화된것이라고 전 정의했는데

친구는 배열의 인터페이스 사용하면 배열이라 주장하더군요, 즉 STL의 멥과 같이 구성된것도 배열이라 볼수 있다는것입니다

이상해서 자료구조책을 친구가 되져봤는데 , 제 쪽에 손을 들어주었습니다
분명 C언어에서 정의 된 표준은 분명 메모리상에서 직열화된것이 배열이 맞더군요

하지만 친구가 그렇게 주장할만한 근거가 있었습니다
php를 보면 array를 map이라 정의 하였더군요

언어마다 배열의 정의가 틀릴수 있다는것을 알았긴한데
참 애매하다는 생각이 드네요

위에 벡터에 관한 논의도 비슷해서 글한번 남깁니다 :)

승자는 자기보다 우월한 사람을 보면 존경심을 갖고 그로부터 배울 점을 찾지만 패자는 자기보다 우월한 사람을 만나면 질투심을 갖고 어디 구멍난 곳이 없는지 찾는다.
- 하비스

pynoos의 이미지

http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/

C++ 성능에 관계된 흥미로운 보고서이군요. 너무 많은 성능측정을 하다못해.. 189 페이지나 됩니다.

http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1457.pdf

저 사이트가 인증받아 다운로드하는 것으로 바뀔지 몰라 첨부합니다.

댓글 첨부 파일: 
첨부파일 크기
PDF icon 0바이트
mastercho의 이미지

다음 표준 예정?? 내용중에
Core Language Ideas중 이런게 있더군요

Quote:
Remove language impediments to use of garbage-collection for memory management

가비지 컬력션을 지원할 예정에 있나보네요 -_-; 믿기 힘들지만

Quote:
Make default destructor virtual for classes with other virtual functions

이것도 맘에 드는듯 , 파생할때는 부모의 파과자 함수가 반드시 virtual야 문제가 생기지 않는데 , 수동으로 해야했고 까먹기도 한부분인데 자동으로 해줄라보네요 :)

Quote:

Add a few general utilities:
hash_map< >, slist< >, …
Pattern-matching (e.g., regular expressions)
“Properties” (designated getter/setter functions)

드뎌 해쉬맵이 표준으로 T_T

Properties” (designated getter/setter functions)
이건 C#에 있는 properties와 같은건가요?

근데
음 boost의 라이브러리들도 표준으로 지정되었으면 좋을텐데요

다음 표준 제정이 기다려지네요 :)
언제에요? --;;

승자는 자기보다 우월한 사람을 보면 존경심을 갖고 그로부터 배울 점을 찾지만 패자는 자기보다 우월한 사람을 만나면 질투심을 갖고 어디 구멍난 곳이 없는지 찾는다.
- 하비스

vacancy의 이미지

right tool for right job 에는 공감을 합니다만,
이 스레드를 쭉 읽어보면요.

C vs C++ on system programming
C#/Java vs C++ on commonplace

.. 의 두 종류 글들이 섞여있는데요.

C++ 매니아 분들의 글들을 굳이 정리하면,
C++는 시스템 프로그래밍에도, 범용 프로그래밍에도 적합하며
C++에서는 남용이나 오용과 상관없이 최대한 많은 것을 제공하고 있고
그것을 남용하거나 오용하는 것은 당연히 사용자의 책임이다.
.. 라고 정리되는 것 같습니다만.

그럼 C++의 단점은 무엇이고,
다른 언어들이 적합한 - right job은 무엇이죠. -_-;

mastercho의 이미지

vacancy wrote:
right tool for right job 에는 공감을 합니다만,
이 스레드를 쭉 읽어보면요.

C vs C++ on system programming
C#/Java vs C++ on commonplace

.. 의 두 종류 글들이 섞여있는데요.

C++ 매니아 분들의 글들을 굳이 정리하면,
C++는 시스템 프로그래밍에도, 범용 프로그래밍에도 적합하며
C++에서는 남용이나 오용과 상관없이 최대한 많은 것을 제공하고 있고
그것을 남용하거나 오용하는 것은 당연히 사용자의 책임이다.
.. 라고 정리되는 것 같습니다만.

그럼 C++의 단점은 무엇이고,
다른 언어들이 적합한 - right job은 무엇이죠. -_-;

C++의 단점은 워낙많은 패러다임을 포함하다보니 방대해서
익히기 어렵습니다
공부를 해도 해도 끊임 없이 공부할게 나오죠 :)
C++프로그래머는 끊임없이 C++를 탐구해야 될듯 싶습니다
[조금만 배워도 쉽게 쓸수 있는 언어를 찾는다면 C++를 적합하지 않아 보입니다,거기엔 C가 낫겠죠 ,C++를 완벽하게 구사한다면
(몇명이나 될지는 -_-;; ) C와 거의 동일한 성능과
객체지향 ,제네릭 프로그래밍까지 구사할수 있겠죠]

사실 지금도 공부할게 태산인데
다음 표준 제정될것을 보니 공부할게 정말로 만만치 않더군요 -_-

이게 단점이라면 단점이겠네요

vacancy wrote:
다른 언어들이 적합한 - right job은 무엇이죠. -_-;

숙제로 남겨 드리겠습니다 -_-;

승자는 자기보다 우월한 사람을 보면 존경심을 갖고 그로부터 배울 점을 찾지만 패자는 자기보다 우월한 사람을 만나면 질투심을 갖고 어디 구멍난 곳이 없는지 찾는다.
- 하비스

jolasen의 이미지

mastercho wrote:

[조금만 배워도 쉽게 쓸수 있는 언어를 찾는다면 C++를 적합하지 않아 보입니다,거기엔 C가 낫겠죠 ,C++를 완벽하게 구사한다면
(몇명이나 될지는 -_-;; ) C와 거의 동일한 성능과
객체지향 ,제네릭 프로그래밍까지 구사할수 있겠죠]

음...그럼 C는 조금만 배워도 쉽게 쓸수 있다는 말인가요?
C가 조금만 배워도 쉽게 쓸수 있는 이유를 설명 부탁드립니다.
onemind555의 이미지

C가 쉬운건 누구나 다 아는 사실 입니다..

-----------^^ ^^ ^^ ^^ ^^ ----------
..........................................................

maddie의 이미지

진짜요? 전 php에 너무 익숙해진 탓인지 C어렵던데요. (만날 공부해야지 하고 포기해버린다는 ....)

힘없는자의 슬픔

crimsoncream의 이미지

저도 c가 쉽다고 생각합니다. java도 그렇고요.
언어자체가 지나치게 복잡하고 어렵다는건 c++의 치명적인 약점이라고 생각합니다.

c는 언어자체는 매우 간결합니다. 하지만 언어가 적용되는 플랫폼에 따라서 적용하는 프레임웍이나 라이브러리셋에 따라서 그 조합에 대한 탐구와 숙련도가 필요합니다. 자바도 마찬가지지요. 결국 이런 단순한 언어는 개발자를 언어자체의 숙련에 매달리는 것에서 해방시켜 실제 problem domain에 집중할 수 있게 해줍니다.

좋은거 아닌가요.

jolasen wrote:
mastercho wrote:

[조금만 배워도 쉽게 쓸수 있는 언어를 찾는다면 C++를 적합하지 않아 보입니다,거기엔 C가 낫겠죠 ,C++를 완벽하게 구사한다면
(몇명이나 될지는 -_-;; ) C와 거의 동일한 성능과
객체지향 ,제네릭 프로그래밍까지 구사할수 있겠죠]

음...그럼 C는 조금만 배워도 쉽게 쓸수 있다는 말인가요?
C가 조금만 배워도 쉽게 쓸수 있는 이유를 설명 부탁드립니다.

오늘 우리는 동지를 땅에 묻었습니다. 그러나 땅은 이제 우리들의 것입니다.
아직도 우리의 적은 강합니다. 그러나 우리는 그들보다 많습니다.
항상 많을 것입니다.

clhitter의 이미지

얻는게 있으면 잃는 것도 있기 마련이죠 ^^

Quote:

결국 이런 단순한 언어는 개발자를 언어자체의 숙련에 매달리는 것에서 해방시켜 실제 problem domain에 집중할 수 있게 해줍니다.

이 문장을 다음과 같이 살짝 바꾼 다음과 같은 문장도 맞는 말 아닐까요?

c++에서 제공하는 STL등의 라이브러리는 개발자가 직접 자료구조를 만드는데 매달리는 것에서 해방시켜서 실제 problem domain에 집중할 수 있게 해줍니다.

crimsoncream의 이미지

물론 직접 자료구조를 만들고 그 자료구조에 최적화된 알고리즘을 구현하는데 걸리는 시간을 줄여 주겠죠. 하지만 여전히 business logic이나 control policy 같은 핵심적인 요소는 stl 같은 language feature 저편에 남겨진 문제입니다.

stl을 확장하여 특정분야에 접목시킨 템플릿 라이브러리를 만들거나 사용하고 있지 않다면 여전히 stl은 ideal한 상황에서 강력한 툴이라고 생각합니다.

c++은 복잡한 툴이고 복잡한 툴은 잘 통제된 상황에서 사용되지 않는 한 복잡한 해결방법을 낳기 쉽습니다. 실천적 측면에서 통제에 소요되는 비용이 만만치 않은분야에서는 c++을 쓰지 않는게 현명할 것이라는게 제가 드리고자 한 말씀이었습니다.

clhitter wrote:
얻는게 있으면 잃는 것도 있기 마련이죠 ^^

Quote:

결국 이런 단순한 언어는 개발자를 언어자체의 숙련에 매달리는 것에서 해방시켜 실제 problem domain에 집중할 수 있게 해줍니다.

이 문장을 다음과 같이 살짝 바꾼 다음과 같은 문장도 맞는 말 아닐까요?

c++에서 제공하는 STL등의 라이브러리는 개발자가 직접 자료구조를 만드는데 매달리는 것에서 해방시켜서 실제 problem domain에 집중할 수 있게 해줍니다.

오늘 우리는 동지를 땅에 묻었습니다. 그러나 땅은 이제 우리들의 것입니다.
아직도 우리의 적은 강합니다. 그러나 우리는 그들보다 많습니다.
항상 많을 것입니다.

akbar의 이미지

...

junghwanz의 이미지

mastercho wrote:
좀 이상한 발상이 아닌가 싶네요

여러가지 변수의 요인이 있겠지만, 다른 프로세스 다 죽였다고 해서
이 차이가 획기적으로 변할거라고는 전혀 생각할수 없습니다

어차피 실제 환경에서도 프로그램이란 프로세스 단하나로 돌아가지 않죠

기타 몇가지 다른 프로세스가 있다고 해서
저 %차이가 크게 변할거라는건 억지 같네요

어차피 virtual사용할때나 사용하지 않을때나 비슷하게 다 영향을 미칠테니까여
여러번 테스트 해서도 마찬가지 결과라면, 어떠시겠습니까?


전 세상에서 비합리적이고 억지 쓰고 우기는걸 참 실어하죠
그렇게 테스트하면 무한대로 테스트해도 마찬가지일것입니다. 그렇게 테스트한 결과물은 아무 의미도 없구요.
억지쓴다고 하니까 자세히 설명을 드리죠.
왜 프로세스가 단 하나만 살아 있어야 하는가?
일반적으로 OS가 스케줄링을 함에 있어서 기본적으로 한프로세스가 사용할수 있는 최대 시간을 정해주게 됩니다. 어떠한 스케줄링 기법을 썻느냐에 따라서 차이는 분명 존재하겠죠. 그런데 함수를 call하는 것이 단지 8clock정도의 비용밖에 들지 않습니다. 그런데 나머지 것들을 수행하는데 훨신 많은 클럭이 소요되면 어떻게 이것으로 함수 call의 정확한 비용을 %로 볼 수 있나요??
예를 들어서 함수포인터로 call하는것은 12clock이고 일반 함수 call은 8클락(8051 large mode에서)인데 다른것이 1000clock을 소요하면
1012:1008인데 이렇게 되면 당연히 수행 비용이 낮게 보이겠죠.
그런데 사실 process 보다 더 심각한것은 interrupt입니다. interrupt는 무조건 context에 위에 있기때문에 interrupt의 code수행은 무조건 우선하게됩니다. 프로그램상에서 print를 하게 되면 최소한 화면에 문자를 출력하기 위해서 interrupt루틴을 타게 될 것인데 이 수행 비용도 만만치 않다는 것이죠.
그리고 실제 환경이야기는 할 필요가 없습니다. 단지 함수 호출에 관한 비용문제를 이야기 한것이니까요. 그리고 embedded에서는 실제 환경에서도 process가 하나 도는 경우도 있습니다. 암튼 이건 전혀 상관없는 이야기인것 같습니다.

novice wrote:
그 3%라는 것은 함수 호출만 21억 4천 7백만여번을 했을 때 나온 차이입니다. 현실적으로 도저히 일어날 수가 없는 최악의 상황이죠. 마침 제 앞에 있는 어떤 함수의 어셈블리 리스팅을 보니 120라인 중 call 명령이 여섯 개 있군요. 이 경우 실제 성능 차이는 대충 0.03 * 0.05 = 0.0015% 정도 되겠습니다. 0.0015% 차이라는 것은 한 시간 걸리는 일과 한시간 0.054초 걸리는 일의 차이입니다. 그러므로 0.054초라는 시간을 엄청난 비용이라고 말할 수 있다면, 하신 말씀은 맞습니다.

다른것 전혀 안하고 함수 호출만 21억 4천 7백만여번을 했다면 함수호출을 8클락이라고 해도 1GHZ에서 0.01초 안에 수행이 끝나셧겠군요. 이게 맞아야 테스트베드가 갖추어진곳에서 테스트를 한것이라고 할수 있죠. 함수 call만을 이야기 한것이니 0.05한것은 여기서 별의미가 없는것 같구요. 굳이 0.05에 의미를 두자고 한다면 만약 일반 적으로 프로그래밍시 120라인중 6개의함수호출이 가장평균적일경우에 함수호출이 전체 문맥에 미치는 비용정도로 판단하면 되겠군요.

novice wrote:

같은 컴퓨터에서 NetBSD, FreeBSD, 리눅스로 전부 돌려봤더니 거의 비슷한 결과를 얻었습니다. 직접 해보시고 결과를 말씀해 주시면 감사하겠습니다.

그리고 요즘 마이크로프로세서는 파이프라인 구조이기 때문에 단순히 인터럽트를 끄고 프로세스를 다 죽인다고 해서 명령별로 정확한 클럭 사이클을 구할 수는 없습니다. 인텔이나 AMD라면 모를까요. 물론 정확한 클럭 사이클이라는 것도 여기서는 거의 무의미합니다. 벤치마크는 일정한 경향성을 알아보는 것이지 미미한 수치를 놓고 판가름하는 것은 아니니까요.


NetBSD, FreeBSD, 리눅스 뿐만 아니라 하다 못해 Windows 까지 테스트해도 비슷한 결과를 얻을 것입니다. Window는 그렇게 하는 방법을 모르겠고 linux같은 경우는 커널 컴파일을 다시 할수 있으니까. 스케줄링 방법이 비슷하니까요. 스케줄링 방법이 다른 O/S에서 한번 해보시죠.
그리고 명령별로 정확한 클럭 사이클을 구할 수 없다는건 확신하시나요?? CPU 데이타 쉬트들과 함께 나오는 어셈 명령어 쉬트를 함 보시죠 각명령어와 함께 클럭 사이클도 다 나올테니까요. 여기서는 정확한 클럭 사이클이라는 것이 제일 중요합니다. 전 벤치마크성 이야기를 한것이 아니거든요.

novice wrote:
mov 명령과 call 명령의 비용이 정확히 같다면 그말은 사실입니다. 하지만 실제로는 call 명령이 몇(십) 배 이상 비싸죠.

어떤 CPU에서 mov와 call명령의 차이가 그렇게 심하죠??
8051 호환 XA-H4에서는 pagz zero mode일경우 call 은 4클락 그리고 large나 huge모드일경우에는 7클락입니다. mov는 언제나 4클락이구요.

crimsoncream의 이미지

프로젝트 특성상 c가 생산성이 높은 분야가 시스템 프로그래밍 쪽에 많이 있는데 지금 이 쓰레드에서는 c++이 시스템프로그램에 더(?) 적합하다는 말들이 나오고 있습니다. 그래서 이상적으로는 적합할지 몰라도 실제에서는 아닌 경우도 많은 거 같다는 얘기고.
능숙한 c++ 프로그래머가 부족한데 제 생각에는 이건 일시적인 현상이 아니고 언어자체가 복잡하다는 것이 숙련도를 쌓는데 방해가 되는 건 아닐까 하고 생각한 겁니다. 여기 계신 여러분들이 누누히 얘기하듯이 c++을 제대로 사용하는 개발자를 만나기가쉽지 않습니다. 그건 c++을 사용하는 개발자들이 게으르다라는 뜻이 아닌 c++을 숙달하기가 어렵다는 뜻으로 풀이해야 맞다고 생각한겁니다.

akbar wrote:
crimsoncream wrote:

c++은 복잡한 툴이고 복잡한 툴은 잘 통제된 상황에서 사용되지 않는 한 복잡한 해결방법을 낳기 쉽습니다. 실천적 측면에서 통제에 소요되는 비용이 만만치 않은분야에서는 c++을 쓰지 않는게 현명할 것이라는게 제가 드리고자 한 말씀이었습니다.

통제에 소요되는 비용이 만만치 않은 분야에서는 c++ 을 채택하지 않는다면 프로젝트 특성상 다른 언어가 좀 생산성이 빨라지거나 능숙한 C++ 프로그래머가 부족한 경우일 것입니다. C 를 쓰면 통제에 소요되는 비용이 낮아 질까요.

오늘 우리는 동지를 땅에 묻었습니다. 그러나 땅은 이제 우리들의 것입니다.
아직도 우리의 적은 강합니다. 그러나 우리는 그들보다 많습니다.
항상 많을 것입니다.

sDH8988L의 이미지

다른 언어들의 Right Job은 뭐... 당연하게도 현재 그런 넘들이 어디에 가장 많이 쓰이느냐 아니겠습니까???

Java는 여전히 Client보다는 Server Side에서 강세를 보이고 있고 개발의 편의성과 다른 언어랑 비교했을 때 Reasonable한 성능을 보이기 때문에 Server Side에 사용하는 거겠죠...

PHP나 다른 언어들도 마찬가지겠고요...

그리고 C++의 단점은 배우기 어렵고 숙련되기 힘들다... 아닙니까???

물론, 그렇게 생각하지 않으실 'C++ 숙련자' 분들도 계시겠지만, 일반적으로 배우는 사람들 입장에서는 C++이 타 언어에 비해서 어려운 것은 사실입니다...
이건 정말 엄청난 단점이죠!!!

Bjarne Stroustrup이 주장하길...
'늙은 개에서 새로운 기술을 가르치기는 어렵다.'

그러면, 왜... 늙은 개도 쉽게 배울만 하게 만들지 않습니까...

다른 언어들은 어째서 늙은 개들도 배워서 할까요...

IMHO Bjarne Stroustrup은 너무나 자신의 언어에 집착하고 다른 언어들을 무시하는 거 같습니다... 다른 사람들의 평가도 귀담아 들어봐야 겠죠...

그리고 하나 물어보겠는데요...

제가 C++을 사용한 지 오래 되었는데, 그러면, 지금은 C++을 보통 사용할 때, Memory 관리를 해 주나요??? 아니면 안해도 되게끔 되어 있나요...
물론, 보통 상황입니다... 자주 사용되지 않는 상황 말고요...

mastercho의 이미지

sDH8988L wrote:

그리고 하나 물어보겠는데요...

제가 C++을 사용한 지 오래 되었는데, 그러면, 지금은 C++을 보통 사용할 때, Memory 관리를 해 주나요??? 아니면 안해도 되게끔 되어 있나요...
물론, 보통 상황입니다... 자주 사용되지 않는 상황 말고요...

일반적으로 boost의 shared_ptr를 쓰면 저절로 메모리 관리가 됩니다

또한 ,보통 상황이 제 주위사람 기준이라면 거진다 이 방법을 씁니다

승자는 자기보다 우월한 사람을 보면 존경심을 갖고 그로부터 배울 점을 찾지만 패자는 자기보다 우월한 사람을 만나면 질투심을 갖고 어디 구멍난 곳이 없는지 찾는다.
- 하비스

akbar의 이미지

...

이한길의 이미지

mastercho wrote:
C++의 단점은 워낙많은 패러다임을 포함하다보니 방대해서
익히기 어렵습니다
공부를 해도 해도 끊임 없이 공부할게 나오죠
C++프로그래머는 끊임없이 C++를 탐구해야 될듯 싶습니다
[조금만 배워도 쉽게 쓸수 있는 언어를 찾는다면 C++를 적합하지 않아 보입니다,거기엔 C가 낫겠죠 ,C++를 완벽하게 구사한다면
(몇명이나 될지는 -_-;; ) C와 거의 동일한 성능과
객체지향 ,제네릭 프로그래밍까지 구사할수 있겠죠]

저는 mastercho님께서 이런 말씀을 하셨다는것이 조금 이상합니다. 앞서 토론에서 제가 말씀드린 또는 다른 분들이 말씀하신 문제들에 답변하실때.. 언어문제가 아니라 사람문제라고 하셨습니다.(물론 다 그렇게 답변하셨다는 것은 아닙니다.) 다시 말해 사람이 잘못 다룬다는 것이지요. 그런데 위에 말씀을 읽고보니 사람이 잘못다루는 것도 언어탓이군요. 배우기 어렵고 그래서 제대로 구사할 사람도 별로 없으니 말입니다.

꼬투리 잡고 싶어서 드린 말씀이 아닙니다. 제가 볼때 C++의 단점이 있다면 다른데서 찾아야 하지 않나 싶습니다.

----
먼저 알게 된 것을 알려주는 것은 즐거운 일이다!
http://hangulee.springnote.com
http://hangulee.egloos.com

mastercho의 이미지

hangulee wrote:
mastercho wrote:
C++의 단점은 워낙많은 패러다임을 포함하다보니 방대해서
익히기 어렵습니다
공부를 해도 해도 끊임 없이 공부할게 나오죠
C++프로그래머는 끊임없이 C++를 탐구해야 될듯 싶습니다
[조금만 배워도 쉽게 쓸수 있는 언어를 찾는다면 C++를 적합하지 않아 보입니다,거기엔 C가 낫겠죠 ,C++를 완벽하게 구사한다면
(몇명이나 될지는 -_-;; ) C와 거의 동일한 성능과
객체지향 ,제네릭 프로그래밍까지 구사할수 있겠죠]

저는 mastercho님께서 이런 말씀을 하셨다는것이 조금 이상합니다. 앞서 토론에서 제가 말씀드린 또는 다른 분들이 말씀하신 문제들에 답변하실때.. 언어문제가 아니라 사람문제라고 하셨습니다.(물론 다 그렇게 답변하셨다는 것은 아닙니다.) 다시 말해 사람이 잘못 다룬다는 것이지요. 그런데 위에 말씀을 읽고보니 사람이 잘못다루는 것도 언어탓이군요. 배우기 어렵고 그래서 제대로 구사할 사람도 별로 없으니 말입니다.

꼬투리 잡고 싶어서 드린 말씀이 아닙니다. 제가 볼때 C++의 단점이 있다면 다른데서 찾아야 하지 않나 싶습니다.

말이 조금 꼬이게 된듯 싶네요

정리해보겠습니다 , 분명 "제대로 C++를 쓴다면 이상이 없다"고 말한것과
C++이 어려운것은 조금 별개가 아닌듯 싶습니다

"제대로 안배우고 잘못된 방법으로 사용한 경우"에 관한 말을 그런식으로 연관시키면 좀 곤란하지 않을까요?

그리고 잘 쓰기 시작해지면 문제가 안되지만 위에 부정적인 답글을 단분들 처럼 , 잘 쓰기에 노력을 하기보다 부정해버리는 경우가 일반적입니다

이런 사실을 놓고 배우기가 어렵다고 대답을 한것이지요

제대로 배운 사람끼리와 대화를 하면 C++은 배우기 어렵다가 아니라 재밌어로 바뀝니다,

위 말은 현재 KLDP 상황을 두고 얘기한것임을 참조해주시기 바랍니다

승자는 자기보다 우월한 사람을 보면 존경심을 갖고 그로부터 배울 점을 찾지만 패자는 자기보다 우월한 사람을 만나면 질투심을 갖고 어디 구멍난 곳이 없는지 찾는다.
- 하비스

kuma의 이미지

C 냐 C++ 이냐는 의미가 없는 행위입니다.

농사꾼이 논에 갈때 곡괭이를 들고 가든 트랙터를 몰고 가던 그건 그 농사꾼의 그날 기분과 일감에 따라 결정하는겁니다.

우리도 이와같이 C 나 C++ 이라는 도구를 가지고 일을 할 뿐입니다. 단지 일을 완성하는데 더 쉽게, 더 빠르게 목표하는 바를 달성하는것이지요.

왈가왈부 할 얘기는 아니지만 덧붙이자면 저는 집에 사용하는 TV 리모콘의 기능중 파워, 채널 선택, 음량조절 만 사용합니다. 즉 도구가 복잡하면 사람들은 도리어 사용하지 않으려는 경향이 있습니다. 기능이 있어도 필요가 없으므로 사장되게 됩니다.

구냥 띰띰해서 주저리주저리 읊었습니다. 언어 사용법 숙지를 위해 생의 1/3 을 소비하고 싶은 사람은 없겠죠? :D

이한길의 이미지

Quote:
언어 사용법 숙지를 위해 생의 1/3 을 소비하고 싶은 사람은 없겠죠?

조금 심하시군요. 3/1까지... 아무튼 토론이 의미없는 방향으로 흘러가는 것도 그렇고 한 토론이 이렇게까지 방대해지는 것도 그러니 새로운 조금 구체적인 토론을 했으면 싶네요.

----
먼저 알게 된 것을 알려주는 것은 즐거운 일이다!
http://hangulee.springnote.com
http://hangulee.egloos.com

bitwiz의 이미지

C가 쉽다는 것은 C++에 비하면 정말 쉽다는 것이죠 ^^

사람에 따라서 C를 어렵게도 느낄 수 있지만
(저도 처음엔 어려워 했죠 :wink: 뭐. 지금도 그리 잘하진 못합니다만... )

C++에 비한다면 ... ^^;

그리고 위에 분이 말씀하신 생의 1/3이라는 것에는 단지 문법이나 언어의 개념을 익히기 위한 시간만을 말씀하신 것은 아닌 것 같네요 ^^

C던 C++이던 평생을 짜도 모든 프로그램을 다짤 수 있는건 아니니까요

마지막으로 C나 C++ 모두가 서로에 비해서 장단점은 분명 있으니까요.
중요한건 그 장단점을 얼마나 잘알고 사용하느냐가 아닐까요?
(그리고 자신의 손에 잘맞는 도구를 선택하는 것이... :D )

vacancy의 이미지

전 솔직히 C++를 도구로 쓰는 사람은 많이 봤지만
탐구나 연구의 대상으로 보는 사람은
컴파일러나 자연언어처리 전공자들을 제외하면 본적이 없거든요.

저같은 경우는
Assembly, Basic, Fortran, Cobol, C, C++, Pascal, Scheme, Prolog, Java등으로
코딩해본 경험이 있는데요.
( 뭐 Cobol처럼 이젠 전혀 기억이 안나는 Language도 있고, Prolog처럼 어느 정도 맛만 본 Language들도 있고요. )
언어 자체에서 얻어지는 성취감은 솔직히 안생겨서
"C++은 어렵고, 그래서 제대로 배우면 뿌듯하다." 라는 말도
전혀 이해가 가지 않습니다. :?

언어는 그저 도구일 뿐이고 유저의 프로그래밍/코딩을
최대한 편하고 빨리 정확히 할수 있게 도와주는 언어가
가장 좋다고 생각합니다.
이왕이면 소스 가독성이 높아 아름다운 코드가 나온다면 더 좋겠죠.

그런데 이런 조건을 생각해보면 제 기준에서는
- 뭐, 저도 C++로 코딩을 많이 하게 되긴 합니다만 -
C++가 좋은 언어라는 생각이 잘 들지 않는 것 같네요.

범용 프로그래밍에 있어서
'배우기 힘들고 책임은 사용자에게 떠넘기는' C++가
편하고 빠르고 정확하게 코딩하는데 있어서
C#이나 Java에 비해 언어적 특성에서 나은 부분은 별로 보이질 않아서요.
( 자료 구하기 쉽다는 것과 Template만은 정말 좋다고 생각합니다. :wink: )
Productivity라는 요소가 점점 중요해지는 지금은 더욱요.

Mania가 아닌 일반 프로그래머들에게
'C++는 이러저런 면에서 C#이나 Java보다 낫다.'라고 할만한 점을
꼽아주셨으면 좋겠습니다.

akbar의 이미지

...

mastercho의 이미지

akbar wrote:
헤더파일에 정의된 함수가 프로젝트가 진행함에 따라 몇 개의 파일에서 서로 include 되어 나중에는 서로가 서로를 호출함으로써 순환되는 과정이 생겨서 이 부분을 끝내 잡아내지 못해 실패로 돌아갔다고 합니다

자바는 후방 참조를 지원해서 ,클래스간 상호참조가가 include 꼬임같은거 없이

잘 되는거 같습니다

얼마전 제가 디자인 패턴에 관해 토론을 벌인적이 있는데

자바 프로그래머는 클래스간 상호참조를 당연히 여기더라고요

또한 , 서로가 서로를 참조한다라.... ^^ 이건 자바로 하는? 디자인 패턴을 보시면 심심치 않게 볼수 있습니다

특히 자바에서는 거의 모든 패턴이 서로가 서로를 호출하는 상호참조 방법으로
호출하더군요 :) [책에선 상호참조 하지 않고도 가능한데도 불구하고도 상호참조를 꼭 쓰더라는 ]

C++ 프로그래머인 전 그래서 디자인 패턴의 클래스간 상호참조를 반드시 써야하는 패턴은 그리 눈에 들어오지 않았다는 ......

아주 중요한 패턴은 상호참조를 요구하진 않은데, 오히려 이런 패턴이 필요가 있을까 싶은 넘들이 꼭 상호참조 패턴을 사용하더군요
[akbar님 글을 읽으니 제 단방향 설계 방법에 확신이 가지네요 ]

다만 뭐 이렇게도 할수 있그나는 싶었긴 했습니다

위 글을 읽으니 include꼬인 그 프로젝트에 자바 프로그래머가 많았는지 궁금하네요,
저번 디자인 패턴에 관한 주제를 가지고 토론할때, 자바 프로그래머분들
상호참조는 자연스러운것이라 많이들 말씀 하셔서,include 꼬여서 결국 포기한 프로젝트와 대조가 되기에 그냥 답글 달아봅니다

그럼 ^^

승자는 자기보다 우월한 사람을 보면 존경심을 갖고 그로부터 배울 점을 찾지만 패자는 자기보다 우월한 사람을 만나면 질투심을 갖고 어디 구멍난 곳이 없는지 찾는다.
- 하비스

sDH8988L의 이미지

Quote:
그리고 배우기 어려운 면은 자바도 마찬가지 일겁니다. 자바 사양이 C++ 만큼 복잡한 것은 아니지만 쏟아져 나오는 관련 기술을 볼때 자바 프로그래머가 C++ 프로그래머보다 알아야 할 라이브러리의 양은 더욱 많아 보입니다.

흠... 인용을 어떻게 하는 것인지 잘 모르겠네요... 사람들 글 인용하는 거 보면 위에 먼저 누가 썼다는 것이 나오던데... 어떻게 하는 건지... -___-a

Java의 Library는 정말 엄청나게 방대하죠... 그거 종류만 다 볼려고 해도 한 참 걸립니다...

그러나 말입니다... Java의 Library를 Java를 사용하는데, 필요한 필수적인 요소로 보시면 곤란합니다...
Java의 그 많은 Library들은 모두 특정한 목적을 가지고 있는, 말하자면 Utility같은 것들이 많은 것이지 Java를 사용하기 위해서 그런 것들을 알아야 하는 것이 아닙니다...

J2SE Programming하려고 하면, J2EE나 J2ME같은 거 아무것도 몰라도 됩니다...
그런 것들은 Enterprise의 Programming을 아주 쉽게 만들어 주거나 Mobile Program을 쉽게 해주는 Utility Package이지 그걸 알아야 Java로 뭔가를 할 수 있는 것은 절대 아닙니다...

그러니까 제가 드리고 싶은 말은 Library로 인하여 Java가 배우기 어려운 언어가 되는 것이 아니라는 겁니다... 오히려 Library로 인하여 어떤 일을 할 때 좀 더 쌈팍하게 할 수 있는 거죠...
Java로 Programming을 하다보면, 정말 '이런 거 필요하다' 싶은 거는 거의 다 있습니다... 정말 고마울 따름이죠...

Programmer는 그런 기능의 Library가 있다 없다만 알고 있으면 바로 사용할 수 있습니다...

뭐... 있다 없다를 아는 거 자체가 Java를 어렵게 한다면 뭐... 할 말은 없습니다...

onemind555의 이미지

Quote:
위 글을 읽으니 include꼬인 그 프로젝트에 자바 프로그래머가 많았는지 궁금하네요,
저번 디자인 패턴에 관한 주제를 가지고 토론할때, 자바 프로그래머분들
상호참조는 자연스러운것이라 많이들 말씀 하셔서,include 꼬여서 결국 포기한 프로젝트와 대조가 되기에 그냥 답글 달아봅니다

include가 꼬여서 실패했다?
C++도 상호 참조 하면 됩니다. 자바보다 귀찮긴 해도 하면 됩니다...

-----------^^ ^^ ^^ ^^ ^^ ----------
..........................................................

이한길의 이미지

akbar wrote:
헤더파일에 정의된 함수가 프로젝트가 진행함에 따라 몇 개의 파일에서 서로 include 되어 나중에는 서로가 서로를 호출함으로써 순환되는 과정이 생겨서 이 부분을 끝내 잡아내지 못해 실패로 돌아갔다고 합니다

인클루드가 왜 꼬인지 저는 잘 이해가 되지 않습니다. 기본적으로 #ifndef같은 선행처리자(?)를 사용해서 중복을 방지하지 않던가요?? VC++에서는 기본적으로 클래스를 추가하면 헤더 파일에 이런 구문을 붙여서 틀을 만들어 줍니다.

----
먼저 알게 된 것을 알려주는 것은 즐거운 일이다!
http://hangulee.springnote.com
http://hangulee.egloos.com

cleol의 이미지

Quote:
인클루드가 왜 꼬인지 저는 잘 이해가 되지 않습니다. 기본적으로 #ifndef같은 선행처리자(?)를 사용해서 중복을 방지하지 않던가요?? VC++에서는 기본적으로 클래스를 추가하면 헤더 파일에 이런 구문을 붙여서 틀을 만들어 줍니다.

예를 들어 보겠습니다..

file a.h

#ifndef _A_H
#define _A_H

class B;

class A
{
	private:
		B a;
};

#endif

file b.h

#ifndef _B_H
#define _B_H

class A;

class B
{
	private:
		A a;
};

#endif

i.cpp

#include "a.h"
#include "b.h"

int main()
{
	A a;
	B b;
}

이 코드는 컴파일 되지 않습니다. 컴파일이 되게 하려면 클래스 정의에서 멤버를 포인터로 고쳐주면 됩니다. 하지만 포인터를 사용하지 않는 쪽이 좋은 경우거나 복잡한 프로젝트에서는 이런 상호 참조가 문제가 될 수 있습니다.

쓰레드가 길어지니 참 여러 이야기가 나오네요:) 이제는 주제가 있는 토론이 아니라 그냥 대화가 되버린 것 같네요. 제 글도 주제와는 관계가 없군요... :wink:

onemind555의 이미지

당연히 그런건 안 됩니다. 앞에보인 소스는 상호 참조가 아니고 상호 포함입니다.

이렇게 해야죠.. (생성자 , cpp 파일 생략 합니다.)

Quote:
class A {
B &b;
};

class B {
A & a;
};

레퍼런스형은 생성자에서 초기화 하지 않으면 컴파일 조차 안 되기 때문에 포인터 보다 안 전합니다.

상호 참조를 해서 문제가 일어 난다면 그건 설계의 문제 입니다. 언어를 탓할 것이 아닙니다...

-----------^^ ^^ ^^ ^^ ^^ ----------
..........................................................

mastercho의 이미지

onemind555 wrote:
당연히 그런건 안 됩니다. 앞에보인 소스는 상호 참조가 아니고 상호 포함입니다.

이렇게 해야죠.. (생성자 , cpp 파일 생략 합니다.)

Quote:
class A {
B &b;
};

class B {
A & a;
};

레퍼런스형은 생성자에서 초기화 하지 않으면 컴파일 조차 안 되기 때문에 포인터 보다 안 전합니다.

상호 참조를 해서 문제가 일어 난다면 그건 설계의 문제 입니다. 언어를 탓할 것이 아닙니다...

일반적으로는 레퍼런스가 아니라 포인터형을 쓰죠

하지만 이게 위험할수 있는것이 A.aa()함수가 B.bb()함수를 호출하고
B.bb()함수내에선 A.aa()를 호출할 경우 무한 루프에도 빠질수 있지 않나 싶습니다

그리고 저렇게 하면 include는 헤더 파일내에서는 안됩니다
할려면 .h파일에선 선언만 하고 , cpp파일에서 include해야합니다

그럼

승자는 자기보다 우월한 사람을 보면 존경심을 갖고 그로부터 배울 점을 찾지만 패자는 자기보다 우월한 사람을 만나면 질투심을 갖고 어디 구멍난 곳이 없는지 찾는다.
- 하비스

crimsoncream의 이미지

제말은 시스템프로그램계:)에서 프로그래머 개인 취향을 떠나서 현실에서 c가 더 적합하게 쓰이고 있다는 것입니다.
c++로 만든 현실에서 적용되고 있는 프레임웍이나 미들웨어가 c로 구현된 거 보다 더 많이 있나요? 제가 아는 범위에서는 거의 c나 java로 된거라서 드리는 질문입니다. 디바이스컨트롤쪽이든 비즈니스애플리케이션 쪽이든요. ace나 mfc 같은 범용이 아닌 이것이 확장되거나 변형되어서 특정분야의 logic을 내포하고 있는. 그런거 말이죠. video4linux나 jakarta나 뭐 이런류 정도가 될까요? 그리고 요즘은 script language를 통합용 툴로 많이 쓰는데 이런 script language 들이 c++용 인터페이스를 제공하나요? 제가 아는 한도에서는 전부 c interface로 돼있습니다.
전 배우기 즐겁다거나 열매가 달콤한 툴이 좋은 툴이라고 주장하신다면 아예 포인트가 다른 경우니까 상호의견을 존중하고 얘기를 마무리하는게 좋을 것 같고. 그게 아니고 생산성이 높고 효율적인 툴이 좋은 툴이라고 생각하신다면 이 측면에 집중해주시기 바랍니다.

저도 c++이나 lisp을 쓰는게 재밌습니다. 하지만 이걸로 프로젝트를 하지는 않습니다. 왜냐면 일단 팀 구성하기도 쉽지도 않고 문제해결을 위해서는 처음부터 다 만들던가 결국은 c를 이용해 interface를 구현해서 타 구현들과 연동을 하게 됩니다. 또 임베디드 쪽으로 내려서면 요즘은 주요cpu들은 다들 c++까지 포팅돼서 나오니까 괜찮다고 하실지 몰라도 일단 어떤 경우든 제대로 호환되는 c++ 컴파일러 구하기 보다는 제대로 호환되는 c 컴파일러 구하거나 포팅하는게 훨씬 쉽습니다.

제 생각에는 c++은 c와는 다른 layer에 있는 툴입니다. 뭐 java나 python 처럼 말이죠. c++은 java와 python과는 달리 컴파일러나 language 피쳐가 c와 중첩돼있기 때문에 c의 대체물 처럼 얘기되지만 c의 입장에서 보면 c++은 또 다른 고급언어라고 생각합니다. 이 말이 c++을 폄하한다고 생각치는 말아주십시요. 역할이 다르다는 얘기니까요. 막말로 어차피 모든 건 기계어로 변환된다고 해서 기계어로 프로젝트를 진행할 수는 없는 거고. tcp가 ip위에 올라간다고 ip가 더 나은 놈이야라고 얘기할 순 없는 거니까요.

akbar wrote:
crimsoncream wrote:
프로젝트 특성상 c가 생산성이 높은 분야가 시스템 프로그래밍 쪽에 많이 있는데 지금 이 쓰레드에서는 c++이 시스템프로그램에 더(?) 적합하다는 말들이 나오고 있습니다.

그런 말이 있는 것도 같지만 C 가 시스템 프로그램에 적합하다면 (프로그래머에 따라서) C++ 도 적합할 수가 있다는 얘기겠지요.

-- Bjarne Stroustrup이 주장하길...
-- '늙은 개에서 새로운 기술을 가르치기는 어렵다.'

-- 그러면, 왜... 늙은 개도 쉽게 배울만 하게 만들지 않습니까...
-- 다른 언어들은 어째서 늙은 개들도 배워서 할까요...

Bjarne Stroustrup 이 좀 지니친 듯 합니다. 그러나 이 정도의 극성(?)이 있었으니까 C++ 이 이만큼 보급이 된 것이겠지요. "늙은 개" 라고 심하게 표현된 , C++ 에 별로 흥미가 없는 C 프로그래머들에게 C++ 의 위력을 보여주는 것이 C++ 프로그래머들의 또다른 책임인 것 같습니다.
왜 쉽게 배울만 하게 만들지 않냐고 하셨는데
C++ 이 배우기 어렵게 만든게오히려 다행이라는 생각이 듭니다.
어려우니까 정복(?)의 열매는 달콤하겠죠.
그리고 배우기 어려운 면은 자바도 마찬가지 일겁니다. 자바 사양이 C++ 만큼 복잡한 것은 아니지만 쏟아져 나오는 관련 기술을 볼때 자바 프로그래머가 C++ 프로그래머보다 알아야 할 라이브러리의 양은 더욱 많아 보입니다.

오늘 우리는 동지를 땅에 묻었습니다. 그러나 땅은 이제 우리들의 것입니다.
아직도 우리의 적은 강합니다. 그러나 우리는 그들보다 많습니다.
항상 많을 것입니다.

onemind555의 이미지

프로그램이 무한 루프를 돈다...

그건 설계의 문제 입니다.

디자인 패턴에서 상호 참조를 많이 해야 하는데..잘 못 구현 해 버리면 무한 루프에 빠지면서 엉망이 되어 버립니다. 메시지의 시작점이 있으면 항상 종료 점이 있어야 합니다..

a.aa()함수가 b.bb()를 호출 했으면 b.bb()에서는 a.aa()를 절대 호출 하면 안 됩니다. a.aa2()를 호출 하면 되겠죠...

자바에서는 객체 참조하는 것이 1개만 있어 그 한개로 모든것을 다합니다.
그러나 C++에는 여러 가지 있습니다. 방법이 많고 상황에 맞게 적절하게 사용 해야 합니다.
앞에 예제 처럼 하는건 잘 못된 사용 법이라고 할수 있겠죠..

-----------^^ ^^ ^^ ^^ ^^ ----------
..........................................................

방준영의 이미지

제가 쓴 글을 다른 분 이름으로 인용하시다니...쩝.

jhlee1976 wrote:
다른것 전혀 안하고 함수 호출만 21억 4천 7백만여번을 했다면 함수호출을 8클락이라고 해도 1GHZ에서 0.01초 안에 수행이 끝나셧겠군요. 이게 맞아야 테스트베드가 갖추어진곳에서 테스트를 한것이라고 할수 있죠. 함수 call만을 이야기 한것이니 0.05한것은 여기서 별의미가 없는것 같구요. 굳이 0.05에 의미를 두자고 한다면 만약 일반 적으로 프로그래밍시 120라인중 6개의함수호출이 가장평균적일경우에 함수호출이 전체 문맥에 미치는 비용정도로 판단하면 되겠군요.

1기가라는 것은 10의 9승, 즉 10억이지요. 그런데 어떻게 21억 4천 7백만번의 함수 호출을 0.01초안에 할 수 있습니까(더군다나 call이 8클럭이라면). 참고로 클럭 주파수라는 것은 1초에 펄스가 몇번 뛰는지를 나타낸 값입니다.

jhlee1976 wrote:
NetBSD, FreeBSD, 리눅스 뿐만 아니라 하다 못해 Windows 까지 테스트해도 비슷한 결과를 얻을 것입니다. Window는 그렇게 하는 방법을 모르겠고 linux같은 경우는 커널 컴파일을 다시 할수 있으니까. 스케줄링 방법이 비슷하니까요. 스케줄링 방법이 다른 O/S에서 한번 해보시죠.
그리고 명령별로 정확한 클럭 사이클을 구할 수 없다는건 확신하시나요?? CPU 데이타 쉬트들과 함께 나오는 어셈 명령어 쉬트를 함 보시죠 각명령어와 함께 클럭 사이클도 다 나올테니까요. 여기서는 정확한 클럭 사이클이라는 것이 제일 중요합니다. 전 벤치마크성 이야기를 한것이 아니거든요.

몇년전부터 인텔과 AMD 프로세서 매뉴얼에는 더이상 명령어당 정확한 클럭 사이클이 나오지 않습니다. 단지 최악의 상황을 가정한 대략적인 값으로서 지연도(=레이턴시)만 나와있지요. 직접 매뉴얼을 읽고 말씀하시면 될 텐데...

jhlee1976 wrote:
어떤 CPU에서 mov와 call명령의 차이가 그렇게 심하죠??
8051 호환 XA-H4에서는 pagz zero mode일경우 call 은 4클락 그리고 large나 huge모드일경우에는 7클락입니다. mov는 언제나 4클락이구요.

어떤 CPU냐 하면, 지금 쓰고 계신 바로 그 CPU입니다. :roll: 찾아보니 mov 명령과 call 명령의 레이턴시는 펜티엄4 기준으로 10배가 차이나는 것으로 인텔 매뉴얼에 나와 있군요. ... 그런데, 요즘은 8051도 마이크로프로세서로 치나요?

여담으로 8051에서 제가 만든 예제가 얼마나 걸리는지 측정해 보는 것도 재미있는 일이 될 것 같습니다. 8051은 8비트에다 클럭 주파수도 수 MHz 이하일 것이므로 32비트->8비트 오버헤드를 대략 2의 8승으로 잡고 클럭 주파수는 1/1000이라 가정하면, 애슬론에서 10초 걸린 일이 10 * 256000 = 약 30일 걸릴 것 같군요. 흠... 이런 시스템에서 가상 함수를 써야 되나 말아야 하나를 논의한다는 것이 거의 넌센스가 아닌가 싶습니다.

mastercho의 이미지

onemind555 wrote:
프로그램이 무한 루프를 돈다...

그건 설계의 문제 입니다.

디자인 패턴에서 상호 참조를 많이 해야 하는데..잘 못 구현 해 버리면 무한 루프에 빠지면서 엉망이 되어 버립니다. 메시지의 시작점이 있으면 항상 종료 점이 있어야 합니다..

a.aa()함수가 b.bb()를 호출 했으면 b.bb()에서는 a.aa()를 절대 호출 하면 안 됩니다. a.aa2()를 호출 하면 되겠죠...

자바에서는 객체 참조하는 것이 1개만 있어 그 한개로 모든것을 다합니다.
그러나 C++에는 여러 가지 있습니다. 방법이 많고 상황에 맞게 적절하게 사용 해야 합니다.
앞에 예제 처럼 하는건 잘 못된 사용 법이라고 할수 있겠죠..

네 설계의 문제긴 한데 , 공동작업을 한다면 저런 현상이 발생하지 않을거라는 보장을 할수 없죠 , 특히 자바에선 너무 자유롭게 설계가 되다보니 그렇지 않나 싶습니다 , 예를 들면 C++에서는 다중상속이 되는걸 허용했지만 오용할 소지가 있다고 자바에서 막았듯이 ,자바에선 상호참조를 하는 설계를 자유롭게 하지만 , C++에서는 구조상 번거롭고 힘들게 되어 있죠

이런식으로 언어간의 차이점이 존재하는거 같습니다

승자는 자기보다 우월한 사람을 보면 존경심을 갖고 그로부터 배울 점을 찾지만 패자는 자기보다 우월한 사람을 만나면 질투심을 갖고 어디 구멍난 곳이 없는지 찾는다.
- 하비스

junghwanz의 이미지

방준영 wrote:
1기가라는 것은 10의 9승, 즉 10억이지요. 그런데 어떻게 21억 4천 7백만번의 함수 호출을 0.01초안에 할 수 있습니까(더군다나 call이 8클럭이라면). 참고로 클럭 주파수라는 것은 1초에 펄스가 몇번 뛰는지를 나타낸 값입니다.

네 계산 실수구요 곱하기 1000을 더했습니다. ㅎㅎ 클럭 주파수라는것이 몬지 모르는 사람은 없을거 같네요. 어쨋거나 몇초안에 수행은 끝나겠네요.

방준영 wrote:
몇년전부터 인텔과 AMD 프로세서 매뉴얼에는 더이상 명령어당 정확한 클럭 사이클이 나오지 않습니다. 단지 최악의 상황을 가정한 대략적인 값으로서 지연도(=레이턴시)만 나와있지요. 직접 매뉴얼을 읽고 말씀하시면 될 텐데...

솔직히 퍼스널 컴퓨터 용으로는 바이오스와 같은것을 만들일이 없어서 데이타쉬트를 보지는 못했는데요. 그 메뉴얼이라는것이 데이타쉬트를 말하는것인가요?? 거기에 CPU에 모든 레지스터와 port들이 다 나오는것인가요?? 흠 그걸 어디서 구할수 있나요?? 저도 한번 보고 싶은데요. 혹시 가능하면 저에게 멜로 좀 보내주세요. jhlee1976@hotmail.com이거든요.

방준영 wrote:
여담으로 8051에서 제가 만든 예제가 얼마나 걸리는지 측정해 보는 것도 재미있는 일이 될 것 같습니다. 8051은 8비트에다 클럭 주파수도 수 MHz 이하일 것이므로 32비트->8비트 오버헤드를 대략 2의 8승으로 잡고 클럭 주파수는 1/1000이라 가정하면, 애슬론에서 10초 걸린 일이 10 * 256000 = 약 30일 걸릴 것 같군요. 흠... 이런 시스템에서 가상 함수를 써야 되나 말아야 하나를 논의한다는 것이 거의 넌센스가 아닌가 싶습니다.

그 프로그램 말고도 그냥 메모리 체크만 하는 정도만 화면에 뿌릴려고해도 죽음입니다. 그런데 PC를 제외한 시스템이 거의 이런 시스템이죠. 주변에 보이는 거의 대부분의 전자 제품등이요. 솔직히 이것도 좀 많은 일을 하는 전자제품에 들어가죠.
akbar의 이미지

...

notexist의 이미지

jhlee1976 wrote:

방준영 wrote:
몇년전부터 인텔과 AMD 프로세서 매뉴얼에는 더이상 명령어당 정확한 클럭 사이클이 나오지 않습니다. 단지 최악의 상황을 가정한 대략적인 값으로서 지연도(=레이턴시)만 나와있지요. 직접 매뉴얼을 읽고 말씀하시면 될 텐데...

솔직히 퍼스널 컴퓨터 용으로는 바이오스와 같은것을 만들일이 없어서 데이타쉬트를 보지는 못했는데요. 그 메뉴얼이라는것이 데이타쉬트를 말하는것인가요?? 거기에 CPU에 모든 레지스터와 port들이 다 나오는것인가요?? 흠 그걸 어디서 구할수 있나요?? 저도 한번 보고 싶은데요. 혹시 가능하면 저에게 멜로 좀 보내주세요. jhlee1976@hotmail.com이거든요.

http://bbs.kldp.org/viewtopic.php?t=23038&start=0&postdays=0&postorder=asc&highlight=intel

여기 가시면 자세히 나옵니다. 인텔 프로세서 메뉴얼 발송...

최신 P4, SSE2, HT 등의 기술까지 모두 다룹니다.

There is more than one way to do it...

죠커의 이미지

akbar wrote:
물론 C 로 구현된게 많겠죠 그러나 C++ 이 C 보다 프레임웍이나 미들웨어 설계에 부적합해서가 아닙니다.

그래서 현실적으로 C++을 쓰더라도 시스템 프로그래밍에서 C와 혼합을 생각해서 프로그래밍을 해야 할 경우가 많을 것입니다.

akbar wrote:

저도 C 나 C++, 어느쪽으로도 가능한 프로젝트를 다른 사람과 같이 진행한다면 C 를 택하겠습니다. 단 다른 사람은 C 로 진행하더라도 저만은 C 인터페이스에 맞추되 C++ 로 진행을 할 것입니다. 이 말은 extern "C" 블럭으로 네임맹글링을 막되 C++ 의 장점을 그대로 살리겠다는 뜻입니다. 네임맹글링을 막으면C++ 을 쓸 수 없다거나 C++ 의 메리트가 반감된다거나 하는 생각은 마시기 바랍니다. 이 점은 이미 위 몇 번째 이전 글에서 언급하였습니다.

이미 언어가 정해진 프로젝트에서 다른 언어로 혼합프로그래밍하는 것은 보통 힘들것 같은데요. 그건 논외로 두고 네임맹글링에 관해서 다시 이야기를 시작할까 합니다.

네임맹글링을 막은 C++에서는 다형성이 보장되지 않을 듯 합니다. 적어도 제가 가진 임플리멘테이션에서는 오버라이딩, 오버로드, 템플릿과 같은 요소들은 일반적인 경우와 다르거나 에러를 내었습니다. 이런 부분을 해결하는 것은 기술적으로 힘들것 입니다. 적어도 제가 가진 dev-cpp의 테스트에서는 실패했으니 보다 힘들게 프로그래밍을 해야된다는 것일테지요.

맡으신 파트만 C++으로 하신다면 main과 같은 것은 다른 분이 c로 짤수도 있을 것입니다. main이 c언어로 되었을때 정적객체의 할당과 제거같은 문제들은 표준에서는 보장하지 않습니다. 그래서 MEC에서는 c++가 부가 되는 프로그래밍에서도 가짜 main을 c로 짜고 진짜 메인은 C++로 짜서 가짜 main을 호출하라고 권고합니다. c와 c++를 혼합하는 것은 잠재적인 위험이 생길 가능성이 높습니다.

이런 문제들을 해결했다고 칩시다. 그렇다면 과연 생산성 높게 프로그래밍을 하게 되는 것은 아닙니다. 피해야 할 길과 넘어야 할 길이 많고 이후에 다른 프로그래머가 수정했을때 일으킬 문제점을 감안하면 여전히 유지보수 비용은 저렴하지 않습니다.

제 생각엔 괜히 어려운 길을 헤쳐나갈 필요는 없다고 봅니다.

mastercho의 이미지

CN wrote:
그래서 현실적으로 C++을 쓰더라도 시스템 프로그래밍에서 C와 혼합을 생각해서 프로그래밍을 해야 할 경우가 많을 것입니다
.

엄연히 C는 C++에 있는 부분 집합에 불과 합니다
C에서 C++를 호출하는 요소가 있지 않는한 별로 납득이 가지 않네요

만약 기존의 코드와의 일관성을 말하고자 한다면
평생가도 시스템 프로그래밍은
C언어만 써야 한다는 한계적 발상에서 벗어날수 없을것입니다

그렇지 않나요 ? 그런 논리라면
평생 시스템 프로그래밍은 C언어가 좋을수 밖에요

승자는 자기보다 우월한 사람을 보면 존경심을 갖고 그로부터 배울 점을 찾지만 패자는 자기보다 우월한 사람을 만나면 질투심을 갖고 어디 구멍난 곳이 없는지 찾는다.
- 하비스

winner의 이미지

mastercho wrote:
엄연히 C는 C++에 있는 부분 집합에 불과 합니다

이 말은 지나칩니다.

물론 C99 에서 오면서 선언문이 block 처음에 오지 않아도 되고, inline 을 받아들이는 작업이 있었습니다만 전체적으로 많이 벌어지고 있다는 느낌입니다.

C 표준화위원회의 원칙 중 하나가 "C 는 C++ 가 되지 않는다."이니까요.
C 와 C++ 는 독자적으로 발전할 가능성이 큽니다.

C++ 가 Programming Paradigm 을 폭넓게 지원한다는 말로 알아들어도 되겠죠?

죠커의 이미지

mastercho wrote:
엄연히 C는 C++에 있는 부분 집합에 불과 합니다

이 부분은 위에서 부터 얘기해 왔었기 떄문에 서로의 견해차와 의견제시는 다 된 상태라고 봅니다.
mastercho wrote:
만약 기존의 코드와의 일관성을 말하고자 한다면
평생가도 시스템 프로그래밍은
C언어만 써야 한다는 한계적 발상에서 벗어날수 없을것입니다

전 수학에 관련된거라면 무조건 포트란을 쓸테고 어플리케이션을 개발할때는 C++이나 파이썬을 쓸겁니다.

산술연산에 관련된 부분을 C언어로 노력을 한다면 포트란만큼의 효율을 얻을 수 있고 어플리케이션을 만들떄 C언어로 노력을 한다면 C++나 파이썬으로 짠 프로그램 같이 좋은 구성도 나올수도 있을겁니다. 하지만 포트란과 C++,파이썬을 선택했다면 더 편하게 비슷한 결과를 얻었을겁니다.

전 스위스산 빅토리녹스를 쓰기보다는 거실에 여러 도구를 갖추는게 낫다고 봅니다.

onemind555의 이미지

C++을 그리 좋게 생각 안 하는 사람에게 묻고 싶군요..
C만으로 만족을 느끼시는지...

난 C문법은 너무 단순해서 만족이 안 되던데....

-----------^^ ^^ ^^ ^^ ^^ ----------
..........................................................

crimsoncream의 이미지

제글과 쓰신글의 차이점이 뭔지 잘 모르겠군요.

먼저 저는 c++이 부적합하므로 구현결과물이 적다는 식의 논쟁을 하고자 하는게 아닙니다. 구현결과물이 적다 그러므로 부적합하다 입니다. 프레임웍이나 미들웨어를 만들 수도 있다.는 말이 듣고 싶은게 아니라 프레임웍이나 미들웨어를 가져다 쓰거나 만들고 싶은 겁니다. 하지만 가져다 쓸 경우의 수가 적으므로 부적합하고 만들경우에 가져다 쓸 사람이 적으므로 부적합하다는 겁니다. 또 c로만 만들어도 알아서 가져다 쓰는게 이 바닥의 정석인데 뭐하러 c++로 만들까 하는 생각도 들고요.

그리고, 님께서 말씀하신 난 c++을 쓴다 넌 c를 써라는 식의 팀개발이라면 제가 속한 팀이라면 팀원간의 의사소통에 괴리가 생기는 걸 우려해서 재고하기를 권할 겁니다. 소스는 내것이 아니고 팀의 것이니까요. 어쨌거나 결국 말씀하신 대로 했을 때 그 팀의 구현결과물은 c++컴파일러가 필요한 c로 구현된 것이지 c++이 아닙니다. 이게 c++ 프로그래머들이 원하는 c++ 구현결과물인가요? 만약, 그 팀의 다른 팀원이 난 interface만 c로 제공하고 구현은 perl로 할꺼야. 라고 한다면 이게 말씀하신 것과 다른 내용일까요? 그래서 제가 c++은 c 위에 올라간 또 하나의 고급언어라고 했던 겁니다.

끝으로 컴파일러의 문제는 매우 심각합니다. 상용 os하에서 c++컴파일러가 안정적으로 동작하기 시작한지 이제 겨우 10년 정도 지난 거 같은데요. 그 10년 동안 언어의 골격을 흔드는 피처들도 꽤 추가 되었지요. stl 같은 경우는 최근까지도 메이저 컴파일러벤더의 제품에서 조차 삐걱거렸을 정도로 아직 c++은 가야할 길이 먼 언어라는게 제 생각입니다. 물론 앞서간 다른 언어들 특히 c의 역사로 부터 많은 걸 섭취했으니 기존 언어보다 훨씬 짧은 시간에 완성되겠죠. 아직은 좀 더 많은 플랫폼에서 다양한 방식으로 다가오는 도전에 응해서 자신이 c를 사용하는 툴이 아니라 c의 대체물이라는 것을 입증할 과제가 남아있습니다. 제 생각엔 아주 긴시간동안 c++은 c와 유연한 결합을 제공하는 고급언어로 남아 있을 거 같습니다.

gnu coding standard라는 문서였던 거 같은데 거기서 제가 팀원들에게 가능하면 c를 사용해서 코딩할 것을 권하기 위해서 인용하는 말이 있습니다. c는 모든 os 위에서 시간의 시험을 견뎌냈으며 기본적으로 포터빌리티의 측면에서 c외의 다른 언어를 사용하는 것은 비표준적인 방식으로 제품을 구현하는 것과 똑같은 일이다.

akbar wrote:
crimsoncream wrote:
crimsoncream wrote:

C++ 로 만든 현실에서 적용되고 있는 프레임웍이나 미들웨어가 c로 구현된 거 보다 더 많이 있나요?

물론 C 로 구현된게 많겠죠 그러나 C++ 이 C 보다 프레임웍이나 미들웨어 설계에 부적합해서가 아닙니다.

crimsoncream wrote:

저도 c++이나 lisp을 쓰는게 재밌습니다. 하지만 이걸로 프로젝트를 하지는 않습니다.

저도 C 나 C++, 어느쪽으로도 가능한 프로젝트를 다른 사람과 같이 진행한다면 C 를 택하겠습니다. 단 다른 사람은 C 로 진행하더라도 저만은 C 인터페이스에 맞추되 C++ 로 진행을 할 것입니다. 이 말은 extern "C" 블럭으로 네임맹글링을 막되 C++ 의 장점을 그대로 살리겠다는 뜻입니다. 네임맹글링을 막으면C++ 을 쓸 수 없다거나 C++ 의 메리트가 반감된다거나 하는 생각은 마시기 바랍니다. 이 점은 이미 위 몇 번째 이전 글에서 언급하였습니다.
...
...
최소한 C++ 은 시스템 영역에는 어울리지 않는다는 생각은 갖지 마십시요.
(C++ 컴파일러가 지원되지 않는 몇몇 임베디드 영역이나 간단한 라이브러리 제작 같은 경우는 예외로 하겠습니다.)

오늘 우리는 동지를 땅에 묻었습니다. 그러나 땅은 이제 우리들의 것입니다.
아직도 우리의 적은 강합니다. 그러나 우리는 그들보다 많습니다.
항상 많을 것입니다.

crimsoncream의 이미지

정확히 지금 말씀하신 내용 때문에 대부분의 경우에 시스템프로그래밍은 c로 하고 있습니다. 그 상황에 도덕적 의미는 없다고 생각하는데요. 좋고 나쁘고의 문제가 아니라 이다 아니다의 문제 같은데요. 이다에는 이미 동의하고 계신거 같은데 추가로 도덕적인 의미를 부여하고 싶으신건가요?

c++이 c를 포함하고 있다는 것은 c로 하는건 c++도 다한다는 뜻이 아니고. c를 확장해서 구현했고 c와 통신하기 위한 인터페이스가 언어의 피처로 포함돼 있다는 뜻으로 봐야 하지 않을까요. c++로 c처럼 짜는것은 잘못된 게 아니라고 생각하시는 건가요? 그건 c++의 입장에서 보면 제거하고 싶지만 자신의 설계가 c에 기반해서 제거하지 못한 부분이라고 생각하는데. c++과 oo는 다른 거고 c++은 oo를 위해서 만들어진게 아니고 c에 좀 더 강력한 피처들을 추가해주기 위한 거다라고 생각하지 않는다면 c++이 가지고 있는 c의 모습에 문제 의식을 가지고 사용하지 말아야 하는거 아닌가 생각해서요. 누군가 java로 c처럼 코딩을 한다면 ugly code라고 비난이 난무할 겁니다. c++이 c의 확장이라고 해서 여기서 면제된다고 생각하지는 않습니다.

그리고 c와 c++은 프론트엔드를 따로쓰는 다른 컴파일러 구현을 가지고 있습니다. 저한텐 이말이 적용가능한 플랫폼의 목록이 다르다로 들립니다. 즉 기능적으로 c++이 가지고 있다가 중요한게 아니고 c++이기 때문에 안되는 경우가 적지 않다는 거죠.

mastercho wrote:
CN wrote:
그래서 현실적으로 C++을 쓰더라도 시스템 프로그래밍에서 C와 혼합을 생각해서 프로그래밍을 해야 할 경우가 많을 것입니다
.

엄연히 C는 C++에 있는 부분 집합에 불과 합니다
C에서 C++를 호출하는 요소가 있지 않는한 별로 납득이 가지 않네요

만약 기존의 코드와의 일관성을 말하고자 한다면
평생가도 시스템 프로그래밍은
C언어만 써야 한다는 한계적 발상에서 벗어날수 없을것입니다

그렇지 않나요 ? 그런 논리라면
평생 시스템 프로그래밍은 C언어가 좋을수 밖에요

오늘 우리는 동지를 땅에 묻었습니다. 그러나 땅은 이제 우리들의 것입니다.
아직도 우리의 적은 강합니다. 그러나 우리는 그들보다 많습니다.
항상 많을 것입니다.

asheap의 이미지

프레임웍/미들웨어의 경우, ACE( The ADAPTIVE Communication Environment )같은 프레임웍이 C에도 존재하는지 궁금하군요.
프로젝트관해서는 작지만 제경험을 이야기하겠습니다.
다들 C를 쓰는 프로젝트에서 C++을 사용했을때, 대다수는 중수이상 C++프로그래머가 C++로 짠 코드가 C로 짠 코드의 속도가 거의 동일하게 나오면서, 객체지향적으로 이해가 가능하고, 더 직관적이며, 원시적 Copy&Paste를 사용하지 않고 확장/재사용이 가능함을 보면 다들 그 이후부터 C++책을 하나씩 사더군요. 가끔 C로도 그런식으로 짜는게 가능함을 주장하며 직접 짜서 보여주는 사람들이 있었지만(저도 예전에 그랬습니다.) 짜는데 소요되는 시간이 극적으로 차이가 나고, 오히려 C++코드보다 더 복잡하고 이해하기 힘든 C코드를 보며 마음을 돌리더군요.
이런 이유때문에 게임프로그래밍쪽에서는 C++이 C를 대체하게 된 것 같습니다. 시스템 프로그래밍에서 이렇게 되지 않는 이유는 (저의 미숙하고 성급한 판단으로는) 시스템프로그래밍에서는 아직 코드크기와 복잡도가 임계점을 넘지 못하는 경우가 많고, 또는 그 임계점을 넘은 상황에서도 C를 사용해서 그 상황을 극복할 수 있는 실력있는 (또 고집센) 프로그래머들이 괴로움을 무릅쓰고 C를 놓지 않고있고 그리고 표준 C++컴파일러가 아직은 다양한 환경에서 일반적으로 사용되지 못하고 있기 때문인 것 같습니다.
C++컴파일러 문제는 C의 한계에 괴로워하던 프로그래머사회 일부가 너무나도 간절히 C++을 원했기 때문에 C++표준을 완성하지 못한채로 발표한 원죄때문이겠죠. stroustrup씨도 정말 후회하는 부분중에 하나라고 말씀하셨죠.
하지만 이미 중요한 여러 컴파일러들이 거의 표준에 가깝게 C++을 지원하기 시작한 상황이고 최근에 C++책 러쉬를 보면 아직 희망은 있다고 봅니다.

asheap의 이미지

crimsoncream wrote:
정확히 지금 말씀하신 내용 때문에 대부분의 경우에 시스템프로그래밍은 c로 하고 있습니다. 그 상황에 도덕적 의미는 없다고 생각하는데요. 좋고 나쁘고의 문제가 아니라 이다 아니다의 문제 같은데요. 이다에는 이미 동의하고 계신거 같은데 추가로 도덕적인 의미를 부여하고 싶으신건가요?

이런 상황을 억지로 비유하자면, 에어브러쉬로 모형 색칠하는 사람들이 붓만 잡고 색칠하고 있는 사람들에게 가지는 마음에서 나오는 말이랄까요?
왠만하면 돈좀 더 써서 에어브러쉬 하나 장만하라고 권유하는....
(저는 이 비유가 마음에 드네요. 붓만으로도 색칠이 가능하며, 실력에 따라 더 잘할 가능성도 있는 것이 C와 잘 맞는듯. 하지만 에어브러쉬는 더 강력하고 편하며 에어브러쉬만의 특이한 트릭을 사용할 수도 있고, 에어브러쉬만으로만 가능한 기법도 있죠. 아 하지만 붓만이 가능한 일이 있긴하죠. 이것은 C컴파일러만 존재하는 플래폼의 프로그래밍이랄까요?)

crimsoncream wrote:

c++로 c처럼 짜는것은 잘못된 게 아니라고 생각하시는 건가요?

stroustrup 씨는 잘못된 것은 아니라고 말씀하셨죠. C++은 멀티 패러다임 언어니까요. 그중에 C의 패러다임을 사용해서 짜는 것 뿐이죠. 그렇게 짜야될 이유가 있다면 그렇게 짜야겠죠. 함수중간에 변수선언하기위해서 c++컴파일러를 이용해서 c코드를 짜는 경우도 몇번 봤군요. 그런 경우도 그건 당당한 C++ 프로그램입니다.

crimsoncream wrote:

그리고 c와 c++은 프론트엔드를 따로쓰는 다른 컴파일러 구현을 가지고 있습니다. 저한텐 이말이 적용가능한 플랫폼의 목록이 다르다로 들립니다. 즉 기능적으로 c++이 가지고 있다가 중요한게 아니고 c++이기 때문에 안되는 경우가 적지 않다는 거죠.

일부 임베디드 환경빼고는(그런 환경에서는 c조차 제대로 지원하지 않죠)c컴파일러가 존재하는 대부분의 플래폼에서 C++도 적용가능하지 않나요? 적지 않지는 않을 것 같군요. ^^;
죠커의 이미지

asheap wrote:
프레임웍/미들웨어의 경우, ACE( The ADAPTIVE Communication Environment )같은 프레임웍이 C에도 존재하는지 궁금하군요.

wrapper facade를 말씀하시는군요. 시스템 프로그래밍을 하는 사람들이 소켓과 파이프, 스트림만으로도 충분히 잘 프로그래밍해왔습니다. 미션 크리티컬한 부분에서도 안정성과 효율성을 인정받은 상태이지요. ACE가 필요한 분야는 어플리케이션 쪽일듯 합니다.

또 ACE가 STL을 요구한다는 것은 알고 계시겠지요. ACE자체의 문제외에 STL의 문제가 발생할 가능성이 있다는 것이지요. ace와 stl이 충분히 안정화 되어있다고 말씀하실지 모르겠지만 윈도뿐만 아니라 오래동안 안정화된 유닉스도 버그들이 발견되는 경우가 있습니다.

asheap wrote:
객체지향적으로 이해가 가능하고, 더 직관적이며, 원시적 Copy&Paste를 사용하지 않고 확장/재사용이 가능함을 보면 다들 그 이후부터 C++책을 하나씩 사더군요. 가끔 C로도 그런식으로 짜는게 가능함을 주장하며 직접 짜서 보여주는 사람들이 있었지만(저도 예전에 그랬습니다.) 짜는데 소요되는 시간이 극적으로 차이가 나고, 오히려 C++코드보다 더 복잡하고 이해하기 힘든 C코드를 보며 마음을 돌리더군요..

객체지향은 C++의 특성중 하나이지 객체지향적으로 이해가 가능하다는 것이 장점이 된다고 보기는 힘듭니다. c++으로 짠 윈도 어플리케이션도 copy&paste를 하는 사람은 많습니다. c++으로 어플리케이션을 짜는 것은 편합니다. 그것을 c로 대체하는 것도 문제지만 c가 낫은 환경에서 c++을 고집하는 것도 문제라고 봅니다.

asheap wrote:
이런 이유때문에 게임프로그래밍쪽에서는 C++이 C를 대체하게 된 것 같습니다. 시스템 프로그래밍에서 이렇게 되지 않는 이유는 (저의 미숙하고 성급한 판단으로는) 시스템프로그래밍에서는 아직 코드크기와 복잡도가 임계점을 넘지 못하는 경우가 많고, 또는 그 임계점을 넘은 상황에서도 C를 사용해서 그 상황을 극복할 수 있는 실력있는 (또 고집센) 프로그래머들이 괴로움을 무릅쓰고 C를 놓지 않고있고 그리고 표준 C++컴파일러가 아직은 다양한 환경에서 일반적으로 사용되지 못하고 있기 때문인 것 같습니다.

게임프로그래밍은 c++으로 짜는게 당연하고 예외나 메타 템플릿을 쓰는 방향으로 가야 하는게 당연하다고 봅니다. 시스템 프로그래밍과 성격이 틀리다고 봅니다. OS의 아래 계층을 C++으로 짜게된다면 임베디드 뿐만 아니라 PC시장에서 상대적인 이식성에서 밀리게 될겁니다.

asheap wrote:
하지만 이미 중요한 여러 컴파일러들이 거의 표준에 가깝게 C++을 지원하기 시작한 상황이고 최근에 C++책 러쉬를 보면 아직 희망은 있다고 봅니다.

C++의 표준을 완벽히 지원한다고 해서 시스템 프로그래밍쪽에서 상황이 낫아진다는 것은 생각하기 힘들것 같습니다. 메타 프로그래밍 등이 일반화 되고 C++의 라이브러리가 안정화되면 더 어플리케이션 제작이 편해지겠지요.

asheap wrote:
이런 상황을 억지로 비유하자면, 에어브러쉬로 모형 색칠하는 사람들이 붓만 잡고 색칠하고 있는 사람들에게 가지는 마음에서 나오는 말이랄까요?

c++이 에어브러쉬는 아니고 c가 붓인 것도 아닙니다. c++는 빅토리녹스이고 c언어는 시스템 프로그래밍에 맞는 정확한 도구입니다.

asheap wrote:
일부 임베디드 환경빼고는(그런 환경에서는 c조차 제대로 지원하지 않죠)c컴파일러가 존재하는 대부분의 플래폼에서 C++도 적용가능하지 않나요? 적지 않지는 않을 것 같군요. ^^;

c컴파일러는 로컬로 되는데 c++는 크로스 컴파일러를 통해서 다른 개발환경에서만 작업해야 하는 경우도 많습니다. 크로스 컴파일러와 로컬에서 뜨는 컴파일러중에서 선택해야 한다면 어느게 효과적인지는 분명합니다.
akbar의 이미지

...

댓글 첨부 파일: 
첨부파일 크기
파일 0바이트
파일 0바이트
죠커의 이미지

akbar wrote:

#include<cstdio>
#include<iostream>

using namespace std;

class CBase64
{
    private:


    // class CBase64 를 설계하면서 필요한 멤벼변수는 여기에 놓는다.


    public:

    CBase64()
    {
        std::printf("CBase64 Construct !!\r\n");
    }
    //end CBase64

    char* Encode64(const char* pChar)
    {
        printf("Base64 로 인코딩하였습니다.\r\n");
        return const_cast<char*>(pChar);
    }
    //end char* Encode64(const char* pChar)

    char* Decode64(const char* pChar)
    {
        printf("Base64 로 디코딩하였습니다.\r\n");
        return const_cast<char*>(pChar);
    }
    //end char* Decode64(const char* pChar)

    ~CBase64()
    {
        std::printf("CBase64 Destruct !!\r\n");
    }
    //end CBase64
};
//end class class CBase64


extern "C"
{
    char* Encode64(const char* pChar)
    {
        CBase64 Base64;
        return Base64.Encode64(pChar);
    }
    //end char* Encode64(const char* pChar)

    char* Decode64(const char* pChar)
    {
        CBase64 Base64;
        return Base64.Decode64(pChar);
    }
    //end char* Decode64(const char* pChar)

    bool IsVaildMail(const char* pChar)
    {
        //  pChar 이 메일 형식에 맞는지 체크하는 함수

        class CMail
        {
            public:

            bool IsAdjacent(const char* pChar,char Char1,char Char2)
            {
                // 문자열 pChar 에 문자 Char1 과 Char2 가 인접하면 true 를 반환

                return true;
            }
            //end bool IsAdjacent(const char* pChar,char Char1,char Char2)

            int GetCnt(const char* pChar,char CharOne)
            {
                // pChar 에 문자 CharOne 가 나오는 횟수를 구한다.

                return 1;
            }
            //end int GetCnt(const char* pChar,char CharOne)

            int GetFirstPos(const char* pChar,char CharOne)
            {
                // 문자열 pChar 에서 문자 CharOne 가 최초로 나오는 위치를 구한다.

                return 0;
            }
            //end int GetFirstPos(const char* pChar,char CharOne)

            bool IsNotAllowChar(const char* pChar,const char* pNotAllow)
            {
                // 문자열 pChar 에서 허용되지 앟는 문자열 pNotAllow 의
                // 특정 문자를 하나라도 가지고 있다면 true

                return false;
            }
            //end bool IsNotAllowChar(const char* pChar,const char* pNotAllow)
        };
        //end CMail()

        CMail Mail;

        if  (   Mail.IsAdjacent(pChar,'@','.') ||
                Mail.IsAdjacent(pChar,'.','.') ||
                Mail.GetCnt(pChar,'@')>1       ||
                Mail.GetCnt(pChar,'.')<1       ||
                Mail.GetCnt(pChar,'.')>3       ||
                Mail.GetFirstPos(pChar,'@')>Mail.GetFirstPos(pChar,'.')
            )
        {
            return false;
        }
        else
        {
            return true;
        }
        //endif
    }
    //end bool IsVaildMail(const char* pChar)

    bool Mail(const char* pFrom=0,const char* pTo=0,const char* pTitle=0,const char* pContent=0)
    {
        // 여기에서는 일부러 printf 를 쓰지 않고 cout 를 썼다.
        // 일부러 static 으로 선언

        static CBase64 Base64;

        char* pBase64=Base64.Encode64(pContent);

        // 위 객체를 적절히 사용하는 코드를 놓고...

        std::cout<<"Send Mail OK !!\r\n"<<std::endl;

        return true;
    }
    //end bool Mail(const char* pFrom=0,const char* pTo=0,const char* pTitle=0,const char* pContent=0)
}
//end extern "C"

int main(int argc, char *argv[])
{
    Mail();

    return 0;
}

pseudo code이군요. Mail의 반환값이 bool인것이나 패러미터에서 기본값을 지정해준 것들 부터 안먹혀들것 같습니다.

그리고 결정적으로 c로 main을 짜셨습니다. c++은 hidden cost가 있는 언어입니다. main에서 정적객체를 생성하고 삭제할지도 임플리멘테이션에 의지 한다고 알고 있습니다.

정적객체를 안쓴다고 한다면 다음번에도 정적객체를 안쓴다는 보장이 없다고 봅니다. 자신이 나중에 필요에 의해서 만들거나 다른 분이 물려 받아서 정적객체를 만든다면 문제가 달라지는 것이죠. 그리고 정적객체를 써고도 문제가 없었다고 봅시다. 이것은 문제를 본질적으로 해결한 것이 아니라 임플리멘테이션의 특성에 의지한것입니다. 이 환경에서는 되는데 저 환경에서 안된다는 것이 충분히 발생할수 있습니다. c++과 c가 혼합을 할때 main을 c++으로 짜지 않는다면 잠재적인 위협에서 부터 보호 받지 못한다고 봅니다.

akbar의 이미지

...

죠커의 이미지

akbar wrote:
그대로 컴파일 해서 실행해 보시길 바랍니다.
(몇 개의 메시지만 달랑 나오면 성공입니다.)

리눅스는 아니고 솔라리스 환경에서 g++ 명령으로 c++소스를 컴파일해보고 gcc명령로 컴파일 했더니 Mail()에서 에러를 유발하더군요. 제 생각엔 c언어의 소스에서 c++함수에 대한 선언이 빠진듯 한데 어떤 방법으로 컴파일을 시키신 것입니까?

akbar wrote:
"main에서 정적객체를 생성하고 삭제할지도 임플리멘테이션에 의지 한다고 알고 있다" 고 하셨는데 정확히는 main 에서 정적객체를 생성하고 삭제하는 것이 아니고 이진화된 C++ 바이네리 실행 코드가 정적객체를 생성하고 삭제한다고 보아야 합니다.

Scott Meyers에 의하면 main이 이런 형태로 구현되는 c++ 임플리멘테이션이 많다고 합니다.

int main( int argc, char *argv[] )
{
   performStaticInitialization( );  // 컴파일러가 생성한 코드

   // 개발자가 써놓은 코드

  performStaticDestruction();     // 컴파일러가 생성한 코드
}

현재는 그런 방법이 아닌 방법으로 임플리멘테이션이 구현되는 것인가요?

akbar의 이미지

CN wrote:

리눅스는 아니고 솔라리스 환경에서 g++ 명령으로 c++소스를 컴파일해보고 gcc명령로 컴파일 했더니 Mail()에서 에러를 유발하더군요. 제 생각엔 c언어의 소스에서 c++함수에 대한 선언이 빠진듯 한데 어떤 방법으로 컴파일을 시키신 것입니까?

아마도 main.c 에서 Mail() 함수 컴파일 중에 C++ 객체 cout 때문에 컴파일이 안된 것 같습니다. cout::operator<<() 함수는 네임맹글링 되어 있으니까 이 함수정의를 가지는 라이브러리 파일에 링크를 걸어 주어야 합니다. 저의 경우 윈도우(cygwin), 레드햇, 한컴리눅스 모두 C++ 라이브러리 libstdc++ 에 링크를 걸어 주어 실행파일을 만들었습니다.
( gcc main.c lib.o -lstdc++ )
솔라리스를 쓴다고 하셨으니까 거기에 설치된 C++ 라이브러리를 링크시켜주면 될 것입니다.

lib.cpp 파일을 컴파일해서 생긴 lib.o 오브젝트 파일은 여러 개의 영역으로 나누어 집니다.(리눅스의 ELF 파일 포맷을 기준으로 합니다.)

우리가 잘 아는

text 영역 : 여기에 실행코드가 위치하고
data 영역 : 전역변수,정적변수 등이 위치하고
rodata 영역은 읽기전용 데이터가 위치하고
bss 영역 : 런타임시에 할당되는 영역이 있습니다.

이 외에
init 영역과 fini 영역이 있습니다.
init 영역은 프로그램이 시작할 때의 실행 코드가 위치하는 영역이고
fini 영역은 프로그램이 종료할 때의 실행 코드가 위치하는 영역입니다.

바로 이 2 개의 영역이 있으므로 해서 정적 혹은 전역 객체가 정확하게 만들어지고 해제될 수 있는 것입니다. lib.o 오브젝트 파일이 C 로 컴파일 되었다면 이 2 개의 영역은 만들어 지지 않습니다.
그 다음에 메인 함수를 컴파일 하면, 링커는 lib.o 를 참고로 실제 실행파일에 초기화 코드와 종료시 코드를 덧붙이게 되는 것이죠(이 실행 파일에도 init 영역과 fini 영역이 존재하게 됩니다.) 이 시점에서 오브젝트 파일이 C 로 컴파일 되었는가 C++ 로 컴파일 되었는가는 의미가 없고 init 영역과 fini 영역이 있냐 없냐가 중요합니다. 따라서 또다른 객체지향 언어로 lib.cpp 파일을 컴파일 했다면 init 영역과 fini 영역에 관련 코드가 놓이게 될 것입니다.
링커가 오브젝트 파일을 살펴보면서 init 영역과 finit 영역을 찾지 못했을 경우 당연히 실행파일에도 init 영역과 finit 영역이 존재하지 않습니다.

CN wrote:

Scott Meyers에 의하면 main이 이런 형태로 구현되는 c++ 임플리멘테이션이 많다고 합니다.

코드:

int main( int argc, char *argv[] )
{
performStaticInitialization( ); // 컴파일러가 생성한 코드

// 개발자가 써놓은 코드

performStaticDestruction(); // 컴파일러가 생성한 코드
}

현재는 그런 방법이 아닌 방법으로 임플리멘테이션이 구현되는 것인가요?

따지고 보면 Scott Meyers 의 말과 매 한가지입니다.
문제는 위와 같이 오브젝트 파일이나 실행파일에 초기화 혹은 종료코드 들어갈 수 있도록 플랫폼이(플랫폼의 파일 시스템이) 보장하냐는 것이겠지요. 열악한 임베디드 환경을 제외한다면 이런 보장이 안되는 상황이란 그리 많지 않을 것 같습니다.

akbar의 이미지

crimsoncream wrote:

먼저 저는 c++이 부적합하므로 구현결과물이 적다는 식의 논쟁을 하고자 하는게 아닙니다. 구현결과물이 적다 그러므로 부적합하다 입니다.

구현물이 적으면 부적합한 것인 가요. 구현물이 적다는게 C++ 이 시스템프로그래밍이 부적합하다는 증거가 될 수는 없습니다. 다만 C 에 익숙한 프로그래머가 많으니가 C 로 구현된 것이 많은 것 뿐입니다.

crimsoncream wrote:

또 c로만 만들어도 알아서 가져다 쓰는게 이 바닥의 정석인데 뭐하러 c++로 만들까 하는 생각도 들고요.

C++ 로 만드는 것이 힘들다면 그럴 듯 하지만 익숙한 C++ 프로그래머한테는 C 보다 생산성 효율이 전혀 떨이지지 않습니다.

crimsoncream wrote:

그리고, 님께서 말씀하신 난 c++을 쓴다 넌 c를 써라는 식의 팀개발이라면 제가 속한 팀이라면 팀원간의 의사소통에 괴리가 생기는 걸 우려해서 재고하기를 권할 겁니다. 소스는 내것이 아니고 팀의 것이니까요
---
그리고, 님께서 말씀하신 난 c++을 쓴다 넌 c를 써라는 식의 팀개발이라면 제가 속한 팀이라면 팀원간의 의사소통에 괴리가 생기는 걸 우려해서 재고하기를 권할 겁니다. 소스는 내것이 아니고 팀의 것이니까요. 어쨌거나 결국 말씀하신 대로 했을 때 그 팀의 구현결과물은 c++컴파일러가 필요한 c로 구현된 것이지 c++이 아닙니다. 이게 c++ 프로그래머들이 원하는 c++ 구현결과물인가요?

C 로 프로젝트를 진행할 때 C++ 컴파일러가 필요하니까 C++ 을 쓰지 말라고 한다면 과연 함당하겠습니까. 같은 결과물을 C++ 로도 만들 수 있는데 단지 "C++" 컴파일러가 필요하다는 이유로 C++ 의 사용을 배제해야 하겠습니까.

crimsoncream wrote:

만약, 그 팀의 다른 팀원이 난 interface만 c로 제공하고 구현은 perl로 할꺼야. 라고 한다면 이게 말씀하신 것과 다른 내용일까요?

C 와 C++ 은 상호운영이 약간의 제한만으로 가능한 것입니다. 망치가 필요한 곳에 망치와 해머를 같이 운용한다고 할까요. perl 이라면 망치와 해머와는 전혀 어울리자 않는 톱과 같은 것입니다.

crimsoncream wrote:

끝으로 컴파일러의 문제는 매우 심각합니다. 상용 os하에서 c++컴파일러가 안정적으로 동작하기 시작한지 이제 겨우 10년 정도 지난 거 같은데요. 그 10년 동안 언어의 골격을 흔드는 피처들도 꽤 추가 되었지요. stl 같은 경우는 최근까지도 메이저 컴파일러벤더의 제품에서 조차 삐걱거렸을 정도로 아직 c++은 가야할 길이 먼 언어라는게 제 생각입니다.

C++ 이 가야 할 길이 멀다면 C 보다는 더 앞서가가고 있는 것입니다. 그리고 stl 같은 최신 기술들을 써야 C++ 인 것은 아닙니다. 또 경우에 따라서 객체지향 설계를 하지 말아야 할 경우도 있을 것입니다.

chunsj의 이미지

Then, why you use C++? For what? As just "better" C compiler?

akbar wrote:
crimsoncream wrote:

먼저 저는 c++이 부적합하므로 구현결과물이 적다는 식의 논쟁을 하고자 하는게 아닙니다. 구현결과물이 적다 그러므로 부적합하다 입니다.

구현물이 적으면 부적합한 것인 가요. 구현물이 적다는게 C++ 이 시스템프로그래밍이 부적합하다는 증거가 될 수는 없습니다. 다만 C 에 익숙한 프로그래머가 많으니가 C 로 구현된 것이 많은 것 뿐입니다.

crimsoncream wrote:

또 c로만 만들어도 알아서 가져다 쓰는게 이 바닥의 정석인데 뭐하러 c++로 만들까 하는 생각도 들고요.

C++ 로 만드는 것이 힘들다면 그럴 듯 하지만 익숙한 C++ 프로그래머한테는 C 보다 생산성 효율이 전혀 떨이지지 않습니다.

crimsoncream wrote:

그리고, 님께서 말씀하신 난 c++을 쓴다 넌 c를 써라는 식의 팀개발이라면 제가 속한 팀이라면 팀원간의 의사소통에 괴리가 생기는 걸 우려해서 재고하기를 권할 겁니다. 소스는 내것이 아니고 팀의 것이니까요
---
그리고, 님께서 말씀하신 난 c++을 쓴다 넌 c를 써라는 식의 팀개발이라면 제가 속한 팀이라면 팀원간의 의사소통에 괴리가 생기는 걸 우려해서 재고하기를 권할 겁니다. 소스는 내것이 아니고 팀의 것이니까요. 어쨌거나 결국 말씀하신 대로 했을 때 그 팀의 구현결과물은 c++컴파일러가 필요한 c로 구현된 것이지 c++이 아닙니다. 이게 c++ 프로그래머들이 원하는 c++ 구현결과물인가요?

C 로 프로젝트를 진행할 때 C++ 컴파일러가 필요하니까 C++ 을 쓰지 말라고 한다면 과연 함당하겠습니까. 같은 결과물을 C++ 로도 만들 수 있는데 단지 "C++" 컴파일러가 필요하다는 이유로 C++ 의 사용을 배제해야 하겠습니까.

crimsoncream wrote:

만약, 그 팀의 다른 팀원이 난 interface만 c로 제공하고 구현은 perl로 할꺼야. 라고 한다면 이게 말씀하신 것과 다른 내용일까요?

C 와 C++ 은 상호운영이 약간의 제한만으로 가능한 것입니다. 망치가 필요한 곳에 망치와 해머를 같이 운용한다고 할까요. perl 이라면 망치와 해머와는 전혀 어울리자 않는 톱과 같은 것입니다.

crimsoncream wrote:

끝으로 컴파일러의 문제는 매우 심각합니다. 상용 os하에서 c++컴파일러가 안정적으로 동작하기 시작한지 이제 겨우 10년 정도 지난 거 같은데요. 그 10년 동안 언어의 골격을 흔드는 피처들도 꽤 추가 되었지요. stl 같은 경우는 최근까지도 메이저 컴파일러벤더의 제품에서 조차 삐걱거렸을 정도로 아직 c++은 가야할 길이 먼 언어라는게 제 생각입니다.

C++ 이 가야 할 길이 멀다면 C 보다는 더 앞서가가고 있는 것입니다. 그리고 stl 같은 최신 기술들을 써야 C++ 인 것은 아닙니다. 또 경우에 따라서 객체지향 설계를 하지 말아야 할 경우도 있을 것입니다.

akbar의 이미지

chunsj wrote:
Then, why you use C++? For what? As just "better" C compiler?

akbar wrote:
crimsoncream wrote:

먼저 저는 c++이 부적합하므로 구현결과물이 적다는 식의 논쟁을 하고자 하는게 아닙니다. 구현결과물이 적다 그러므로 부적합하다 입니다.

구현물이 적으면 부적합한 것인 가요. 구현물이 적다는게 C++ 이 시스템프로그래밍이 부적합하다는 증거가 될 수는 없습니다. 다만 C 에 익숙한 프로그래머가 많으니가 C 로 구현된 것이 많은 것 뿐입니다.

crimsoncream wrote:

또 c로만 만들어도 알아서 가져다 쓰는게 이 바닥의 정석인데 뭐하러 c++로 만들까 하는 생각도 들고요.

C++ 로 만드는 것이 힘들다면 그럴 듯 하지만 익숙한 C++ 프로그래머한테는 C 보다 생산성 효율이 전혀 떨이지지 않습니다.

crimsoncream wrote:

그리고, 님께서 말씀하신 난 c++을 쓴다 넌 c를 써라는 식의 팀개발이라면 제가 속한 팀이라면 팀원간의 의사소통에 괴리가 생기는 걸 우려해서 재고하기를 권할 겁니다. 소스는 내것이 아니고 팀의 것이니까요
---
그리고, 님께서 말씀하신 난 c++을 쓴다 넌 c를 써라는 식의 팀개발이라면 제가 속한 팀이라면 팀원간의 의사소통에 괴리가 생기는 걸 우려해서 재고하기를 권할 겁니다. 소스는 내것이 아니고 팀의 것이니까요. 어쨌거나 결국 말씀하신 대로 했을 때 그 팀의 구현결과물은 c++컴파일러가 필요한 c로 구현된 것이지 c++이 아닙니다. 이게 c++ 프로그래머들이 원하는 c++ 구현결과물인가요?

C 로 프로젝트를 진행할 때 C++ 컴파일러가 필요하니까 C++ 을 쓰지 말라고 한다면 과연 함당하겠습니까. 같은 결과물을 C++ 로도 만들 수 있는데 단지 "C++" 컴파일러가 필요하다는 이유로 C++ 의 사용을 배제해야 하겠습니까.

crimsoncream wrote:

만약, 그 팀의 다른 팀원이 난 interface만 c로 제공하고 구현은 perl로 할꺼야. 라고 한다면 이게 말씀하신 것과 다른 내용일까요?

C 와 C++ 은 상호운영이 약간의 제한만으로 가능한 것입니다. 망치가 필요한 곳에 망치와 해머를 같이 운용한다고 할까요. perl 이라면 망치와 해머와는 전혀 어울리자 않는 톱과 같은 것입니다.

crimsoncream wrote:

끝으로 컴파일러의 문제는 매우 심각합니다. 상용 os하에서 c++컴파일러가 안정적으로 동작하기 시작한지 이제 겨우 10년 정도 지난 거 같은데요. 그 10년 동안 언어의 골격을 흔드는 피처들도 꽤 추가 되었지요. stl 같은 경우는 최근까지도 메이저 컴파일러벤더의 제품에서 조차 삐걱거렸을 정도로 아직 c++은 가야할 길이 먼 언어라는게 제 생각입니다.

C++ 이 가야 할 길이 멀다면 C 보다는 더 앞서가가고 있는 것입니다. 그리고 stl 같은 최신 기술들을 써야 C++ 인 것은 아닙니다. 또 경우에 따라서 객체지향 설계를 하지 말아야 할 경우도 있을 것입니다.

why you use C++? For what? As just "better" C compiler?
Answer : No, because I neet to perform 객체설계,
AS 프로젝트 규모가 클수록
And I am sure that You are not so good at C++

redrabbit의 이미지

전 초보 개발자 입니다. 그냥 열심히 공부하는 중정도 됩니다. 여기 글들을 남기신 님들처럼 큰프로젝트를 진행해본 경험도 없고, 기겄해야 몇천 라인이 프로그램을 짜봤을 뿐입니다. 그런데... 쭉 읽어보니 제가 그동안 삽질했던 이유가 좀 이해가 되는것도 같고... 어찌보면 혼란 스러워 보이기도 하는데... 결론적으로... 별로 생산성없는 소모적인 논쟁이 아닌가 싶군요... 프로젝트에 적합한 언어를 필요에 따라 쓰고, 용법에 맞춰 인터페이스로 연결하면 되지... 어떤 언어가 좋고 어떤 언어가 나쁘다는건 ... 특히나 C/C++ 이나 JAVA 같이 어느정도 공인된 언어에서의 문제를 말한다면.... 어떤 것이나 문제는 있다고 봅니다. 오래된것일수록 그 해결점이 나타나 깔끔할수도 있고, 혹은 그런점이 개선이 많아 불편함으로 올수도 있고... 새로운게 더 많은 장점을 내포하기도 하고, 아직 작업된것이 없어 개선점이 많을수도 있는듯 합니다. C++ 이냐 JAVA냐의 논쟁만큼이나 이 논쟁도 참으로 소모적이라 생각합니다. 그저 Tool은 Tool 이라고 한다면 너무 원론 적인가요? 여기서는 돼고 안돼고가 불편함이 아니라, 언어를 사용하는 주의사항 내지 숙지사항이 아닌가 싶군요... 그저 그 주의사항을 잘 지켜 문제없이 아니 최소화 하면서 서로 필요한것에 쓰는것이 미력한 소견이나마 정답이 아닌가도 싶군요... 뭐, 대선배님들이 노는데 초보가와서 이러쿵 저러쿵한것에 대해서... 자격이 없다 하실지도 모르지만... 제 생각은 그렇군요....

lsj0713의 이미지

토론이 점차 자존심 싸움으로 나아가고 있는 듯한 느낌마져 듭니다. 실제로는 언어적인 측면 이외의 해당 환경에서의 컴파일러나 그밖의 여러가지를 따진 다음 개발 도구를 선택하게 될 터인데 꼭 어느 한쪽이어야만 한다로 결론을 내릴 필요가 있을까요?

예를 들자면 저는 php보다는 perl을 더 좋아합니다. 언어적인 측면에서 perl이 더 완성도가 높다고 생각하기 때문입니다. 그러나 실제로는 유지보수 측면(본인이 아닌 다른사람들도 봐야 되기 때문에)과 perl이 cgi로 실행되는 점 등 여러가지 요소 때문에 결국 php를 더 많이 쓰게 됩니다.

실제로 프로그래밍을 할 때도 이와 비슷하리라 생각합니다. 암만 C++을 쓰고 싶어도 해당 환경에서의 C++ 컴파일러가 아예 존재하지 않거나 완성도가 꽝이라던지 등등의 문제가 발생할 수 있습니다. 이런 각각의 환경의 차이점이나 작성자의 특성을 고려하지 않은 채 어느 한쪽이다로 결론을 내리려는 시도는 무의미하지 않겠습니까?

ps. 여기는 'K'LDP인데 어째서 영어로 토론이 이루어지는지요? -_-; 어설픈 영어 쓰지 말고 그냥 한국어 씁시다.

akbar의 이미지

crimsoncream wrote:
정확히 지금 말씀하신 내용 때문에 대부분의 경우에 시스템프로그래밍은 c로 하고 있습니다. 그 상황에 도덕적 의미는 없다고 생각하는데요. 좋고 나쁘고의 문제가 아니라 이다 아니다의 문제 같은데요. 이다에는 이미 동의하고 계신거 같은데 추가로 도덕적인 의미를 부여하고 싶으신건가요?

프로그래밍 언어에 도덕이 있다면 구현하는 방법에 있어서 좋고 나쁨이 있겠죠.
만약에 시스템 프로그래밍에 C 가 더 적합하다고 한다면 오히려 C 에 종교적인 의미를 부여하는 것은 아닐까요.

crimsoncream wrote:
c++로 c처럼 짜는것은 잘못된 게 아니라고 생각하시는 건가요? 그건 c++의 입장에서 보면 제거하고 싶지만 자신의 설계가 c에 기반해서 제거하지 못한 부분이라고 생각하는데. c++과 oo는 다른 거고 c++은 oo를 위해서 만들어진게 아니고 c에 좀 더 강력한 피처들을 추가해주기 위한 거다라고 생각하지 않는다면 c++이 가지고 있는 c의 모습에 문제 의식을 가지고 사용하지 말아야 하는거 아닌가 생각해서요. 누군가 java로 c처럼 코딩을 한다면 ugly code라고 비난이 난무할 겁니다. c++이 c의 확장이라고 해서 여기서 면제된다고 생각하지는 않습니다.

C++ 에서 필요에 따라 객체지향 설계를 하지 않는다고 해서 C 처럼 짜는 것이 아닙니다. 옆 동네에 어느 분이

saxboy wrote:
name mangling 때문에 interface 만 extern "C" 에 묶어두고
제가 작성중인 모듈에는 상속이며 오버로딩에
STL 까지 멋대로 쓰고 있습니다.

라고 하셨는데 이게 정답입니다.
C 와의 인터페이스 때문에 객체를 설계할 수 없다면 extern "C" 블럭에서 정의된 함수 뿐입니다. 그 함수안에서나 extern "C" 블럭 밖에서는 함수를 수행하는데 필요한 코드를 얼마든지 객채지향 C++ 로 작성할 수 있는 것입니다. 익숙한 C++ 프로그래머에게는 (간단한 라이브러리 제작같은 것은 예외로 치고) C 인터페이스를 설계한다고 해서 C++ 의 장점이 쇠퇴하지 않습니다.
(이 문제 -- 네임맹글링이나 extern "C"-- 에 대해서는 위 몇번 째 이전 글에서 이미 언급하엿습니다.)
옆 동네에서 C 와 C++ 인터페이스 혼용하는 주제에서 C 와 C++ 컴파일러 호환이 문제된다고 하는 글이 있는데 컴파일러 호환이 실제 프로젝트에 문제가 된다면 C++ 을 부득이 사용치 말아야 하지만
C 도 되고 C++ 도 되는 상황이라면
단지 그때까지 그 상황에 C 가 많이 사용되었기 때문에
C 가 C++ 보다 적당하다는 의견은 갖지 말아 주십시요

akbar의 이미지

redrabbit wrote:
C++ 이냐 JAVA냐의 논쟁만큼이나 이 논쟁도 참으로 소모적이라 생각합니다. 그저 Tool은 Tool 이라고 한다면 너무 원론 적인가요?

C 가 주로 사용되왔던 영역에 C++ 이 사용될 수 있다고 주장하는 측과 그렇지 않다고 생각하는 쪽과의 논쟁이겠죠

lsj0713의 이미지

akbar wrote:
옆 동네에서 C 와 C++ 인터페이스 혼용하는 주제에서 C 와 C++ 컴파일러 호환이 문제된다고 하는 글이 있는데 컴파일러 호환이 실제 프로젝트에 문제가 된다면 C++ 을 부득이 사용치 말아야 하지만
C 도 되고 C++ 도 되는 상황이라면
단지 그때까지 그 상황에 C 가 많이 사용되었기 때문에
C 가 C++ 보다 적당하다는 의견은 갖지 말아 주십시요

하지만 '반드시 C++을 써야만 된다'는 주장도 수긍하기 어렵습니다. C와 C++ 의 공통부분들 중엔 미묘한 차이점들이 존재하며, 앞으로 그러한 차이는 점점 벌어질 것입니다. 만약 개발 인력들이 모두 C에 익숙하고 C++에 익숙하지 않은 상태라면 굳이 C++로 갈 필요는 없다고 생각합니다.

그리고 '그동안 C가 많이 사용되었다'는 것은 굉장히 중요한 사항입니다. 기존 코드가 모두 C로 짜여졌다는 뜻이고, 삽질로 쌓인 경험이나 문서 등등도 모두 C를 기준으로 이루어졌다는 뜻입니다. C++로 옮기려면 모든 소스 코드에 대한 종합적인 검토를 거치지 않으면 의외로 뒤통수 맞을지도 모릅니다.

무엇보다 C++에 추가된 기능들을 쓸 일이 없다면 굳이 힘빼가면서 옮길 필요가 전혀 없지 않습니까?

akbar의 이미지

lsj0713 wrote:
---
하지만 '반드시 C++을 써야만 된다'는 주장도 수긍하기 어렵습니다. C와 C++ 의 공통부분들 중엔 미묘한 차이점들이 존재하며, 앞으로 그러한 차이는 점점 벌어질 것입니다. 만약 개발 인력들이 모두 C에 익숙하고 C++에 익숙하지 않은 상태라면 굳이 C++로 갈 필요는 없다고 생각합니다.

그리고 '그동안 C가 많이 사용되었다'는 것은 굉장히 중요한 사항입니다. 기존 코드가 모두 C로 짜여졌다는 뜻이고, 삽질로 쌓인 경험이나 문서 등등도 모두 C를 기준으로 이루어졌다는 뜻입니다. C++로 옮기려면 모든 소스 코드에 대한 종합적인 검토를 거치지 않으면 의외로 뒤통수 맞을지도 모릅니다.

무엇보다 C++에 추가된 기능들을 쓸 일이 없다면 굳이 힘빼가면서 옮길 필요가 전혀 없지 않습니까?

반드시 C++을 써야 하는 것은 아닙니다. 그런 주장을 하지는 않았습니다.
그리고 기존 C 코드를 일부러 C++ 옮길 필요도 없습니다.
다만 (익숙한 C++ 개발자라면 ) 기존 C 코드를 활용할 때
그 활용을 C 만이 아니고 C++ 로도 힘들이지 않고 할 수 있다는 것을 알려드리고 싶네요

voider의 이미지

이런 스레트가 있었는지 몰랐었네요

전 이렇게 생각합니다.
그 이름 어려운 아저씨는 c 에 많은 부분을 추가 해서 괴물 같은 언어를
만들었습니다.

만들때부터 처음 프로그래밍을 시작하는 사람이 c++을 배우려고 할것이라고는
전혀 예상 못했다고 생각합니다

숙련된 프로그래머에게 보다 강력한 언어를 제공하겠다는 야심찬 계획이었다고
생각됩니다.

그것이 지금은 c언어의 문법학습이 끝나면 그 다음 코스로 당연시 배워야 되는것이
되버렸지만....

저또한 이제 막 프로그램을 배우는 후배들에게 절대로 c++을 추천하지 않습니다

c++을 제대로 사용할려면 컴퓨터 아키텍쳐를 이해해야하고
OS 시스템도 자세히 알고있고
익숙해진 프로그래밍 디자인 패턴을 가지고 있어야 하고
자신의 코드를 컴파일러가 어떻게 해석해 낼지에 관한 부분까지 고려하면서
프로그래밍할수 있어야 한다고 생각됩니다.

물론 그렇지 않아도 골치 아픈 프로그래밍을 이런 괴물같은 언어를 사용하는것
자체가 모순이지만

전 그래도 c++을 열심히 익히고 싶네요...

-- 아쉬운 하루 되세요 --

seeper의 이미지

어쨌건 C++은 C의 확장이고.. (지금은 확장의 의미를 넘어섰지만..)
C++ 이건 C건 java건 용도에 맞는곳이 따로 있다고 생각합니다.

예를 들자면 3D 게임쪽이라면 최고의 스피드를 낼수 있는 C, C++을 선호합니다.

3D 엔진쪽의 경우는 하드웨어가 어떻게 바뀔지 모르므로
그냥 구조화된 C로 잘짜는게 편하다고 합니다. (물론 부분적으로 C++도 섞겠지만요..)
제대로 분석이 안되었을 경우 OOP의 경우 재사용이 무의미해질때도 있죠.
아무리 제대로 분석해도 새하드웨어가 나오면 꽝이니까요...

하지만 게임내용에 대한 프로그램은 C++을 선호합니다.
왜냐면 분석이 가능하고 확장이 용이하게 만들테니까요...

하나의 게임이라도 이처럼 C와 C++을 섞어서 씁니다.
oop가 경우에 따라서 필요할수도 오버일수도 있는것이죠.

게임을 떠나서 중요한것은 무엇을 써야한다 보다... 어떤것을 적절한 경우에 쓰는것이
아닌가 하는군요... 쇼핑몰 운영에서 관리툴은 VC++로 짜는것보다
VB로 짜는것이 훨씬 이득이며 경우에 따라서는 웹프로그램으로 짜는것이
좋을수도 있는 것이죠.

어떤언어가 빠르다 어떤기능이 좋다란 이야기는 가능해도
모든 프로젝트에 맞을 수는 없다고 생각합니다.
결국 프로그래머라면 상항에 맞는걸 선택해야겠죠...

페이지

댓글 달기

Filtered HTML

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

BBCode

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param>
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

Textile

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • You can use Textile markup to format text.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Markdown

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • Quick Tips:
    • Two or more spaces at a line's end = Line break
    • Double returns = Paragraph
    • *Single asterisks* or _single underscores_ = Emphasis
    • **Double** or __double__ = Strong
    • This is [a link](http://the.link.example.com "The optional title text")
    For complete details on the Markdown syntax, see the Markdown documentation and Markdown Extra documentation for tables, footnotes, and more.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Plain text

  • HTML 태그를 사용할 수 없습니다.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 줄과 단락은 자동으로 분리됩니다.
댓글 첨부 파일
이 댓글에 이미지나 파일을 업로드 합니다.
파일 크기는 8 MB보다 작아야 합니다.
허용할 파일 형식: txt pdf doc xls gif jpg jpeg mp3 png rar zip.
CAPTCHA
이것은 자동으로 스팸을 올리는 것을 막기 위해서 제공됩니다.