http://www.parashift.com/c++-faq-lite/big-picture.html
[6.1] C++은 실용적인 언어입니까?
네.
C++은 실용적인 도구입니다. 완벽하진 않지만, 유용합니다.
기업소프트웨어의 세계에서 C++은 견고하고 성숙하며 주류인 도구로 보여집니다. 전체적인 사업적 관점에서 볼 때 C++을 좋게 끔 해주는 광범위한 기업의 지원이 있습니다.
[6.2] C++은 완전한 언어입니까?
아뇨.
C++은 완벽한 언어가 어떠한지 보여 주기 위해 설계되지 않았습니다. 실제 세계의 문제를 풀기 위한 실용적인 도구로 설계되었죠. 다른 모든 실용적 프로그래밍 도구들 처럼 단점이 있습니다만, 완벽한 무언가 까지 가지고 놀기에 적당함 이라는 건 순수히 학문적인 환경에서의 얘기에요. 그건 C++의 목적이 아니었어요.
[6.3] OO와의 큰 일이란 무엇입니까?
객체지향(Object-oriented) 기술은 우리가 알고 있는 크고 복잡한 소프트웨어 응용과 시스템을 개발하는 데 최고인 방법입니다.
OO hype: 소프트웨어 기업은 크고 복잡한 소프트웨어 시스템의 요구를 만족시키는 데에 실패하고 있습니다. 그러나 사실 이 실패는 우리의 성공 때문이죠, 우리의 성공이 사용자들이 더 요구하도록 몰았으니까요. 불행히도 "구조적 분석, 설계 그리고 프로그래밍" 기술이 만족시킬 수 없는 시장을 만들었어요. 그래서 우리가 더 나은 패러다임을 만들 게 요구했습니다.
C++은 OO 프로그래밍을 지원합니다. 또한 C++은 전통적인 절차식 프로그래밍 언어("보다 나은 C언어")나 일반화 프로그래밍 접근법(generic programming approach)으로 사용될 수 있습니다. 당연히 각각의 접근법에는 장단이 있습니다. 하나를 사용하는 동안 또 다른 하나의 이점을 기대하지 마세요.(오해의 일반적인 경우: C보다 낫기 때문에 C++을 쓰고 있다면 OO의 장점을 기대하지 마세요)
[6.4] 일반화 프로그래밍(generic programming)과의 큰 일이란 무엇입니까?
C++은 일반화 프로그래밍을 지원합니다. 일반화 프로그래밍은 성능의 희생 없이 코드의 재사용을 최대화 하는 개발 방법이죠.("성능" 부분은 까다롭게 필요한 부분은 아니지만, 꽤 요구됩니다.)
일반화 컴포넌트는 잘 설계되어 있고 높은 복잡도를 감춘다면 꽤 쓰기 쉽습니다. 또 다른 흥미로운 특징은 많이 사용할 수록 더욱 당신의 코드를 빠르게 만드는 것이죠. 이것이 유쾌한 이득을 만듭니다. 지루한 작업을 하기 위해 컴포넌트들을 사용하면, 코드가 작고 간결해지며 에러를 낼 확률이 적어지고 코드가 종종 더 빠르게 수행될 것입니다.
대부분의 개발자는 이러한 일반화 컴포넌트를 만들기엔 어울리지 않지만, 사용할 수 있습니다. 일반화 컴포넌트를 만드는 과정이란 비순서적 입니다. 머리를 만지작 거리거나 긁기도 하고 새벽 3시에 기발한 아이디어로 깨어나서 코드를 고치고(고치고 고치고)…. 한 마디로 반복이에요. 10 파운드의 물건을 잘 알려진 5 파운드의 가방에 넣으려고 시도하는거죠. 퍼즐 풀기 같은 생각을 하기 싫어하는 사람에겐 필요 없습니다.
운 좋게도, 일반화 컴포넌트는 말이죠, 음…, 일반화 되어 있기 때문에 당신의 조직은 별로 만들 필요가 없을거에요. 기성의 일반화 컴포넌트의 라이브러리가 많거든요. STL도 그런 라이브러리의 하나이고, Boost는 더 많은 컴포넌트를 가졌고요.
[6.5] C++은 Ada 보다 낫습니까? (혹은 Visual Basic, C, FORTRAN, Pascal, Smalltalk 등의 다른 언어)
그만해요. 이 질문은 빛 보다 더 많은 열을 만들거에요. 이것과 비슷한 질문을 올리기 전에 다음을 읽어주세요.
99%의 경우에, 프로그래밍 언어의 선택은 기술적인 고려가 아니라 사업적인 고려에 의해서 결정됩니다. 개발 기계의 프로그래밍 환경, 개발 기계의 실행 환경, 개발 환경의 라이센스/법적 문제, 숙련된 개발자의 가용성, 컨설팅 서비스의 가용성, 회사의 문화와 정책이 진짜 문제가 되는 것이죠. 이러한 사업적인 고려는 일반적으로 컴파일 시간의 성능, 실행 성능, 정적 대 동적 타입화(typing), 정적 대 동적 묶음(binding), 기타 등등 보다 훨신 많은 역할을 합니다.
순전히 기술적인 이유(중요한 사업적인 문제를 무시하며)로 한 언어를 다른 언어보다 편애하며 주장하는 사람은 자신이 기술적 바보라고 드러내는 것이며 무시당할 만 합니다. "사업적인 문제가 기술적인 문제를 지배" 하며, 이 사실을 직시하지 못한 사람은 끔찍한 사업적인 결과를 갖는 결정을 내리게 되어 있습니다.(고용인에게 위험하죠)
[6.6] 누가 C++을 사용합니까?
많은 회사와 정부의 현장이요.
많은 개발자 수(그리고 벤더, 툴, 교육 등을 포함한 지원 기반의 많은 양의 가용성)는 C++의 주요한 특징들 중 하나입니다.
[6.7] OO/C++을 배우는 데 얼마나 걸립니까?
회사들은 성공적으로 대학의 한 학기 코스가 한 주의 40시간으로 압축된 표준 산업의 "단기 코스" 를 가르칩니다. 그러나 당신이 배웠다 하더라도, 코스가 실제의 요소를 가지고 있는지 확인해보세요. 왜냐면 대부분의 사람들은 개념들을 구체화하기 위해 프로젝트를 할 때 제대로 배우거든요. 잘 배웠어도 준비된 것은 아니니까요.
OO/C++에 능숙해 지려면 6-12개월 정도가 걸립니다. 전문가의 코드에 쉽게 접근할 수 있으면 덜 걸리며, 사용 가능한 "좋은" 일반적인 목적의 C++ 클래스 라이브러리가 없다면 더 걸리고요. 다른 사람에게 조언해 줄 수 있는 전문가 중 하나가 되는 데는 3년 정도 걸립니다.
어떤 사람은 해내지 못합니다. 당신이 가르침을 받을 만하고 개인적인 추진력이 있지 않다면 기회가 없겠죠. 순전히 최소한의 "학습능력" 으로서, 잘못했을 때 받아들일 수 있어야 합니다. 순전히 최소한의 "추진력" 으로서, 기꺼이 별도의 시간을 들여야 합니다. 당신의 패러다임을 바꾸는 것(생각하는 것, 기호에 대한 의견, 정신적 모형을 바꾸는 것)보다 새로운 사실을 배우는 게 훨씬 쉽다는 걸 기억하세요.
해야할 두 가지:
조언자[28.1]를 구할 것
무엇이 적법한지(legal)[28.6], 무엇이 올바른지(moral)[28.5] 알려줄 책을 한권씩 구할 것
(역주: legal은 언어 자체의 문법, moral은 올바른 문법들 중 선호되는 코드나 패턴 등을 의미)
하지 말아야 할 두 가지:
OO/C++을 배우는 데 징검다리로 C를 배우지 말 것[28.2]
OO/C++을 배우는 데 징검다리로 Smalltalk를 배우지 말 것[28.3]
[6.8] 사업적 관점에서 볼 때 C++의 특징은 무엇입니까?
여기 사업적 관점에서 볼 때의 C++의 특징들이 있습니다.
- C++은 툴, 환경, 상담 서비스 등을 위한 다수의 벤더 지원과 당신의 이력서에서 매우 가치있는 한 줄이 될 것임을 의미하는 거대한 기반이 있습니다.
- C++은 개발자들이 단순화 된 인터페이스[7.3]를 소프트웨어 덩어리에게 제공할 수 있게 해주며, 재사용 됐을 때 결함률을 개선합니다.
- C++은 연산자 재정의[13.2]를 통해 개발자의 직관을 이용할 수 있도록 해주며, 재사용자의 습득 어려움을 감소 시킵니다.
- C++은 소프트웨어 덩어리들로의 접근을 지역화[7.4] 해주며, 수정에 의한 비용을 줄입니다.
- C++은 안정성 대 사용성 거래(safety-vs.-usability tradeoff)[7.5]를 줄이며, 소프트웨어 덩어리의 재사용 비용을 개선합니다.
- C++은 안정성 대 속도 거래(safety-vs.-speed tradeoff)[9.4]를 줄이며, 성능의 감소 없이 결함률을 개선합니다.
- C++은 예전 코드가 새로운 코드를 부르도록 하는[6.10] 상속과 동적 묶음[6.9]을 지원하며, 좁은 시장을 두드릴 빠르게 확장/적응 가능한 소프트웨어를 만들도록 해줍니다.
[6.9] 가상함수virtual function (동적 묶음dynamic binding)이 OO/C++의 중심입니까?
네!
가상함수[20] 없이 C++은 객체 지향일 수 없습니다. 연산자 재정의[13]와 비-virtual 멤버 함수는 굉장합니다만, 결국 함수에 구조체의 포인터를 전달하는 전형적인 C의 생각을 문법적으로 편리하게 만든 것 뿐이죠. 표준 라이브러리는 "일반화 프로그래밍" 기술을 표현하는 다양한 템플릿을 포함하고 있으며, 역시 대단하지만 가상함수는 여전히 C++을 이용한 객체 지향 프로그래밍의 중심입니다.
사업적 관점[6.17]에서, 가상함수가 없다면 C에서 C++로 바꿀 이유가 거의 없습니다.(일반화 프로그래밍과 표준 라이브러리를 무시 했을 때) 기술자들은 종종 C와 OO 없는 C++ 사이에 큰 차이가 있다고 생각합니다만, OO가 없다면 그 차이는 개발자들을 교육과 새로운 도구 등의 비용을 정당화 하기에 충분하지 않습니다. 즉, 내가 관리자에게 C에서 OO 없는 C++로의 전환을 조언해야 한다면(언어는 전환하지만 패러다임은 전환하지 않음), 강제적인 도구에 의한 이유가 없는 한 말릴 겁니다. 사업적 관점에서 OO는 시스템을 확장/적응 가능하도록 만드는 데 도움이 될 수 있지만, OO 없는 C++ 클래스의 문법은 유지 비용을 줄일 수 없을 뿐더러 확실히 교육 비용을 꽤 증가시킵니다.
결론: virtual 없는 C++은 OO가 아니다. 클래스를 사용하지만 동적 묶음이 없는 프로그래밍은 "객체 기반" 이지 "객체 지향" 이 아니다. 가삼함수를 없애는 것은 OO를 없애는 것과 같다. 남는 건 최초의 Ada 언어와 비슷한 객체 기반 언어이다.(그러나, 수정된 Ada 언어는 객체 기반 보다는 진정한 객체 지향을 지원한다.)
주: 일반화 프로그래밍을 위해서는 가상함수가 필요없다. 그러나 이것이 단순히 사용한 가상함수의 수를 세는 것 만으로 어떤 패러다임을 사용했는지 말할 수 있다고 의미하지는 않는다.
[6.1] C++은 실용적인 언어입니까?
네.
C++은 실용적인 도구입니다. 완벽하진 않지만, 유용합니다.
기업소프트웨어의 세계에서 C++은 견고하고 성숙하며 주류인 도구로 보여집니다. 전체적인 사업적 관점에서 볼 때 C++을 좋게 끔 해주는 광범위한 기업의 지원이 있습니다.
[6.2] C++은 완전한 언어입니까?
아뇨.
C++은 완벽한 언어가 어떠한지 보여 주기 위해 설계되지 않았습니다. 실제 세계의 문제를 풀기 위한 실용적인 도구로 설계되었죠. 다른 모든 실용적 프로그래밍 도구들 처럼 단점이 있습니다만, 완벽한 무언가 까지 가지고 놀기에 적당함 이라는 건 순수히 학문적인 환경에서의 얘기에요. 그건 C++의 목적이 아니었어요.
[6.3] OO와의 큰 일이란 무엇입니까?
객체지향(Object-oriented) 기술은 우리가 알고 있는 크고 복잡한 소프트웨어 응용과 시스템을 개발하는 데 최고인 방법입니다.
OO hype: 소프트웨어 기업은 크고 복잡한 소프트웨어 시스템의 요구를 만족시키는 데에 실패하고 있습니다. 그러나 사실 이 실패는 우리의 성공 때문이죠, 우리의 성공이 사용자들이 더 요구하도록 몰았으니까요. 불행히도 "구조적 분석, 설계 그리고 프로그래밍" 기술이 만족시킬 수 없는 시장을 만들었어요. 그래서 우리가 더 나은 패러다임을 만들 게 요구했습니다.
C++은 OO 프로그래밍을 지원합니다. 또한 C++은 전통적인 절차식 프로그래밍 언어("보다 나은 C언어")나 일반화 프로그래밍 접근법(generic programming approach)으로 사용될 수 있습니다. 당연히 각각의 접근법에는 장단이 있습니다. 하나를 사용하는 동안 또 다른 하나의 이점을 기대하지 마세요.(오해의 일반적인 경우: C보다 낫기 때문에 C++을 쓰고 있다면 OO의 장점을 기대하지 마세요)
[6.4] 일반화 프로그래밍(generic programming)과의 큰 일이란 무엇입니까?
C++은 일반화 프로그래밍을 지원합니다. 일반화 프로그래밍은 성능의 희생 없이 코드의 재사용을 최대화 하는 개발 방법이죠.("성능" 부분은 까다롭게 필요한 부분은 아니지만, 꽤 요구됩니다.)
일반화 컴포넌트는 잘 설계되어 있고 높은 복잡도를 감춘다면 꽤 쓰기 쉽습니다. 또 다른 흥미로운 특징은 많이 사용할 수록 더욱 당신의 코드를 빠르게 만드는 것이죠. 이것이 유쾌한 이득을 만듭니다. 지루한 작업을 하기 위해 컴포넌트들을 사용하면, 코드가 작고 간결해지며 에러를 낼 확률이 적어지고 코드가 종종 더 빠르게 수행될 것입니다.
대부분의 개발자는 이러한 일반화 컴포넌트를 만들기엔 어울리지 않지만, 사용할 수 있습니다. 일반화 컴포넌트를 만드는 과정이란 비순서적 입니다. 머리를 만지작 거리거나 긁기도 하고 새벽 3시에 기발한 아이디어로 깨어나서 코드를 고치고(고치고 고치고)…. 한 마디로 반복이에요. 10 파운드의 물건을 잘 알려진 5 파운드의 가방에 넣으려고 시도하는거죠. 퍼즐 풀기 같은 생각을 하기 싫어하는 사람에겐 필요 없습니다.
운 좋게도, 일반화 컴포넌트는 말이죠, 음…, 일반화 되어 있기 때문에 당신의 조직은 별로 만들 필요가 없을거에요. 기성의 일반화 컴포넌트의 라이브러리가 많거든요. STL도 그런 라이브러리의 하나이고, Boost는 더 많은 컴포넌트를 가졌고요.
[6.5] C++은 Ada 보다 낫습니까? (혹은 Visual Basic, C, FORTRAN, Pascal, Smalltalk 등의 다른 언어)
그만해요. 이 질문은 빛 보다 더 많은 열을 만들거에요. 이것과 비슷한 질문을 올리기 전에 다음을 읽어주세요.
99%의 경우에, 프로그래밍 언어의 선택은 기술적인 고려가 아니라 사업적인 고려에 의해서 결정됩니다. 개발 기계의 프로그래밍 환경, 개발 기계의 실행 환경, 개발 환경의 라이센스/법적 문제, 숙련된 개발자의 가용성, 컨설팅 서비스의 가용성, 회사의 문화와 정책이 진짜 문제가 되는 것이죠. 이러한 사업적인 고려는 일반적으로 컴파일 시간의 성능, 실행 성능, 정적 대 동적 타입화(typing), 정적 대 동적 묶음(binding), 기타 등등 보다 훨신 많은 역할을 합니다.
순전히 기술적인 이유(중요한 사업적인 문제를 무시하며)로 한 언어를 다른 언어보다 편애하며 주장하는 사람은 자신이 기술적 바보라고 드러내는 것이며 무시당할 만 합니다. "사업적인 문제가 기술적인 문제를 지배" 하며, 이 사실을 직시하지 못한 사람은 끔찍한 사업적인 결과를 갖는 결정을 내리게 되어 있습니다.(고용인에게 위험하죠)
[6.6] 누가 C++을 사용합니까?
많은 회사와 정부의 현장이요.
많은 개발자 수(그리고 벤더, 툴, 교육 등을 포함한 지원 기반의 많은 양의 가용성)는 C++의 주요한 특징들 중 하나입니다.
[6.7] OO/C++을 배우는 데 얼마나 걸립니까?
회사들은 성공적으로 대학의 한 학기 코스가 한 주의 40시간으로 압축된 표준 산업의 "단기 코스" 를 가르칩니다. 그러나 당신이 배웠다 하더라도, 코스가 실제의 요소를 가지고 있는지 확인해보세요. 왜냐면 대부분의 사람들은 개념들을 구체화하기 위해 프로젝트를 할 때 제대로 배우거든요. 잘 배웠어도 준비된 것은 아니니까요.
OO/C++에 능숙해 지려면 6-12개월 정도가 걸립니다. 전문가의 코드에 쉽게 접근할 수 있으면 덜 걸리며, 사용 가능한 "좋은" 일반적인 목적의 C++ 클래스 라이브러리가 없다면 더 걸리고요. 다른 사람에게 조언해 줄 수 있는 전문가 중 하나가 되는 데는 3년 정도 걸립니다.
어떤 사람은 해내지 못합니다. 당신이 가르침을 받을 만하고 개인적인 추진력이 있지 않다면 기회가 없겠죠. 순전히 최소한의 "학습능력" 으로서, 잘못했을 때 받아들일 수 있어야 합니다. 순전히 최소한의 "추진력" 으로서, 기꺼이 별도의 시간을 들여야 합니다. 당신의 패러다임을 바꾸는 것(생각하는 것, 기호에 대한 의견, 정신적 모형을 바꾸는 것)보다 새로운 사실을 배우는 게 훨씬 쉽다는 걸 기억하세요.
해야할 두 가지:
조언자[28.1]를 구할 것
무엇이 적법한지(legal)[28.6], 무엇이 올바른지(moral)[28.5] 알려줄 책을 한권씩 구할 것
(역주: legal은 언어 자체의 문법, moral은 올바른 문법들 중 선호되는 코드나 패턴 등을 의미)
하지 말아야 할 두 가지:
OO/C++을 배우는 데 징검다리로 C를 배우지 말 것[28.2]
OO/C++을 배우는 데 징검다리로 Smalltalk를 배우지 말 것[28.3]
[6.8] 사업적 관점에서 볼 때 C++의 특징은 무엇입니까?
여기 사업적 관점에서 볼 때의 C++의 특징들이 있습니다.
- C++은 툴, 환경, 상담 서비스 등을 위한 다수의 벤더 지원과 당신의 이력서에서 매우 가치있는 한 줄이 될 것임을 의미하는 거대한 기반이 있습니다.
- C++은 개발자들이 단순화 된 인터페이스[7.3]를 소프트웨어 덩어리에게 제공할 수 있게 해주며, 재사용 됐을 때 결함률을 개선합니다.
- C++은 연산자 재정의[13.2]를 통해 개발자의 직관을 이용할 수 있도록 해주며, 재사용자의 습득 어려움을 감소 시킵니다.
- C++은 소프트웨어 덩어리들로의 접근을 지역화[7.4] 해주며, 수정에 의한 비용을 줄입니다.
- C++은 안정성 대 사용성 거래(safety-vs.-usability tradeoff)[7.5]를 줄이며, 소프트웨어 덩어리의 재사용 비용을 개선합니다.
- C++은 안정성 대 속도 거래(safety-vs.-speed tradeoff)[9.4]를 줄이며, 성능의 감소 없이 결함률을 개선합니다.
- C++은 예전 코드가 새로운 코드를 부르도록 하는[6.10] 상속과 동적 묶음[6.9]을 지원하며, 좁은 시장을 두드릴 빠르게 확장/적응 가능한 소프트웨어를 만들도록 해줍니다.
[6.9] 가상함수virtual function (동적 묶음dynamic binding)이 OO/C++의 중심입니까?
네!
가상함수[20] 없이 C++은 객체 지향일 수 없습니다. 연산자 재정의[13]와 비-virtual 멤버 함수는 굉장합니다만, 결국 함수에 구조체의 포인터를 전달하는 전형적인 C의 생각을 문법적으로 편리하게 만든 것 뿐이죠. 표준 라이브러리는 "일반화 프로그래밍" 기술을 표현하는 다양한 템플릿을 포함하고 있으며, 역시 대단하지만 가상함수는 여전히 C++을 이용한 객체 지향 프로그래밍의 중심입니다.
사업적 관점[6.17]에서, 가상함수가 없다면 C에서 C++로 바꿀 이유가 거의 없습니다.(일반화 프로그래밍과 표준 라이브러리를 무시 했을 때) 기술자들은 종종 C와 OO 없는 C++ 사이에 큰 차이가 있다고 생각합니다만, OO가 없다면 그 차이는 개발자들을 교육과 새로운 도구 등의 비용을 정당화 하기에 충분하지 않습니다. 즉, 내가 관리자에게 C에서 OO 없는 C++로의 전환을 조언해야 한다면(언어는 전환하지만 패러다임은 전환하지 않음), 강제적인 도구에 의한 이유가 없는 한 말릴 겁니다. 사업적 관점에서 OO는 시스템을 확장/적응 가능하도록 만드는 데 도움이 될 수 있지만, OO 없는 C++ 클래스의 문법은 유지 비용을 줄일 수 없을 뿐더러 확실히 교육 비용을 꽤 증가시킵니다.
결론: virtual 없는 C++은 OO가 아니다. 클래스를 사용하지만 동적 묶음이 없는 프로그래밍은 "객체 기반" 이지 "객체 지향" 이 아니다. 가삼함수를 없애는 것은 OO를 없애는 것과 같다. 남는 건 최초의 Ada 언어와 비슷한 객체 기반 언어이다.(그러나, 수정된 Ada 언어는 객체 기반 보다는 진정한 객체 지향을 지원한다.)
주: 일반화 프로그래밍을 위해서는 가상함수가 필요없다. 그러나 이것이 단순히 사용한 가상함수의 수를 세는 것 만으로 어떤 패러다임을 사용했는지 말할 수 있다고 의미하지는 않는다.
