C 언어와 비교할 때 C ++ 제한은 무엇입니까? [닫은]

다음은 C ++의 이점입니다.

• C ++는 그들이 요구하는 특정 기능을 제공합니다.
• 그들의 C 컴파일러는 거의 확실히 C ++ 컴파일러이므로 소프트웨어 비용에 영향을 미치지 않습니다.
• C ++는 C만큼 이식 가능합니다.
• C ++ 코드는 C만큼 효율적일 수 있습니다 (또는 더 많거나 적음)

C ++보다 C를 사용해야하는 구체적인 이유와 구체적인 시나리오가 있습니까?

이 질문에 대한 참조 : C의 제네릭 라이브러리

이 질문은 언어 제한에 대해 묻고 한 언어를 다른 언어로 배워야 /하지 말아야하기 때문입니다.

Peter Kirkham의 게시물은 특히 내가 고려하지 않은 C99 문제와 관련하여 가장 유익한 것이었기 때문에 수락했습니다. 참여 해주신 모든 분들께 감사드립니다.

이것은 C의 제네릭 라이브러리에 대해 묻는 현재 질문에 대한 대답에 의해 프롬프트됩니다. 질문자는 구체적으로 C ++를 사용하고 싶지 않다고 말합니다.

C는 완전한 프로그래밍 언어입니다. C는 C ++의 임의의 하위 집합이 아닙니다. C는 C ++의 하위 집합이 아닙니다.

이것은 유효한 C :

foo_t* foo = malloc ( sizeof(foo_t) );

C ++로 컴파일하려면 다음과 같이 작성해야합니다.

foo_t* foo = static_cast<foo_t*>( malloc ( sizeof(foo_t) ) );

더 이상 유효한 C가 아닙니다. (C 스타일 캐스트를 사용할 수 있습니다.이 경우 C로 컴파일되지만 대부분의 C ++ 코딩 표준과 많은 C 프로그래머에 의해 피할 수 있습니다. 스택 오버플로 전체에서 "malloc을 캐스팅하지 마십시오"주석을 확인하십시오) .

그들은 같은 언어가 아니며 C로 기존 프로젝트가있는 경우 라이브러리를 사용하기 위해 다른 언어로 다시 작성하고 싶지 않습니다. 작업중인 언어로 인터페이스 할 수있는 라이브러리를 사용하는 것이 좋습니다. (어떤 경우 extern "C"에는 C ++ 라이브러리의 템플릿 / 인라인 방식에 따라 몇 가지 래퍼 함수로 가능합니다 .)

내가 작업중인 프로젝트에서 첫 번째 C 파일을 가져 오면 다음과 같이 바꾸면 gcc std=c99됩니다 g++.

sandiego:$ g++ -g  -O1 -pedantic -mfpmath=sse -DUSE_SSE2 -DUSE_XMM3  -I src/core -L /usr/lib -DARCH=elf64 -D_BSD_SOURCE -DPOSIX -D_ISOC99_SOURCE -D_POSIX_C_SOURCE=200112L -Wall -Wextra -Wwrite-strings -Wredundant-decls -Werror -Isrc  src/core/kin_object.c -c -o obj/kin_object.o | wc -l
In file included from src/core/kin_object.c:22:
src/core/kin_object.h:791:28: error: anonymous variadic macros were introduced in C99
In file included from src/core/kin_object.c:26:
src/core/kin_log.h:42:42: error: anonymous variadic macros were introduced in C99
src/core/kin_log.h:94:29: error: anonymous variadic macros were introduced in C99
...
cc1plus: warnings being treated as errors
src/core/kin_object.c:101: error: ISO C++ does not support the ‘z’ printf length modifier
..
src/core/kin_object.c:160: error: invalid conversion from ‘void*’ to ‘kin_object_t*’
..
src/core/kin_object.c:227: error: unused parameter ‘restrict’
..
src/core/kin_object.c:271: error: ISO C++ does not support the ‘z’ printf length modifier
src/core/kin_object.c:271: error: ISO C++ does not support the ‘z’ printf length modifier

총 69 줄의 오류 중 4 개는 유효하지 않은 변환이지만 대부분 C99에는 있지만 C ++에는없는 기능에 대한 것입니다.

재미를 위해 이러한 기능을 사용하는 것과는 다릅니다. 다른 언어로 이식하려면 상당한 작업이 필요합니다.

따라서 다음과 같이 제안하는 것은 잘못된 것입니다.

[a] C 컴파일러는 거의 확실하게 C ++ 컴파일러이므로 소프트웨어 비용에 영향을주지 않습니다.

기존 C 코드를 C ++의 절차 적 하위 집합으로 이식하는 데 상당한 비용 문제가 발생하는 경우가 많습니다.

따라서 C에서 큐 의 라이브러리 구현을 찾는 질문에 대한 대답으로 'C ++ std :: queue 클래스 사용' 을 제안하는 것은 '목표 C 사용' 및 'JNI를 사용하여 Java java.util.Queue 클래스 호출 '을 제안하는 것보다 더 후회입니다. 또는 'CPython 라이브러리 호출'-Objective C는 실제로 C (C99 포함)의 적절한 상위 집합이며 Java 및 CPython 라이브러리는 모두 관련없는 코드를 C ++ 언어로 이식 할 필요없이 C에서 직접 호출 할 수 있습니다.

물론 C ++ 라이브러리에 C façade를 제공 ​​할 수 있지만 일단 그렇게하면 C ++는 Java 또는 Python과 다르지 않습니다.

나는 그것이 전문적이거나 특별한 좋은 대답이 아니라는 것을 알고 있지만, 나는 C를 정말 좋아하기 때문입니다 .C는 작고 간단하며 내 두뇌에 전체 언어를 맞출 수 있습니다 .C ++는 항상 거대한 엉망처럼 보였습니다. 모든 종류의 레이어로 나는 그로 킹이 힘들다. 이로 인해 C ++를 작성할 때마다 C를 코딩 할 때보 다 디버깅과 딱딱한 표면에 머리를 두드리는 데 훨씬 더 많은 시간을 할애하게됩니다. 다시 한 번 저는이 중 많은 부분이 제 자신의 '무지'의 결과라는 것을 깨달았습니다.

내가 선택하게된다면, 인터페이스와 데이터베이스 상호 작용과 같은 모든 것들을 파이썬 (또는 아마도 C #)으로 작성하고 C에서 빠르어야하는 모든 것들을 작성할 것입니다. 나에게 모든 세계의 최고를 제공합니다. C ++로 모든 것을 작성하는 것은 모든 세상에서 최악의 상황을 겪는 것처럼 느껴집니다.

편집 : 몇 가지 C ++ 기능이있는 C는 프로젝트에서 여러 사람이 작업하거나 유지 관리가 최우선 인 경우 대체로 나쁜 생각이라고 덧붙이고 싶습니다. 무엇이 '몇'을 구성하는지, C에서 어떤 비트를 수행해야하는지, C ++에서 어떤 비트가 결국 매우 정신 분열증적인 코드베이스로 이어지는 지에 대한 의견 차이가있을 것입니다.

C ++는 저수준 임베디드 시스템과 같은 일부 실제 환경에서는 단순히 지원되지 않습니다. 그에 대한 좋은 이유가 있습니다. C는 그러한 일에 쉽게 충분합니다. 그렇다면 왜 더 큰 것을 사용합니까?

나는 C ++로 프로그래밍하는 것을 싫어한다.

몇 가지 이유는 다음과 같습니다.

• 지원 부족-모든 C 컴파일러가 C ++ 컴파일러 인 것은 아닙니다. 모든 컴파일러가 C ++를 지원한다고 주장하더라도 표준을 특별히 준수하는 것은 아닙니다. 그리고 일부 C ++ 컴파일러는 절망적이고 비효율적 인 코드를 생성합니다. 일부 컴파일러는 표준 라이브러리를 끔찍하게 구현합니다. 커널 모드 개발은 일반적으로 C ++ 표준 라이브러리의 사용을 불가능하게 만들고 일부 언어 기능을 사용합니다. 언어의 핵심을 고수하는 경우에도 C ++ 코드를 작성할 수 있지만 C로 전환하는 것이 더 간단 할 수 있습니다.
• 정통. C ++는 복잡한 언어입니다. 누군가에게 C ++보다 C를 가르치는 것이 더 쉽고, 좋은 C ++ 프로그래머보다 좋은 C 프로그래머를 찾는 것이 더 쉽습니다. (여기서 키워드는 "좋다"입니다. C ++ 프로그래머는 많지만 대부분 언어를 제대로 배우지 못했습니다.)
• 학습 곡선-위와 같이 C ++를 가르치는 것은 엄청난 작업입니다. 미래에 다른 사람들이 유지 관리해야하는 앱을 작성하고 다른 사람들은 C ++ 프로그래머가 아닐 수있는 경우 C로 작성하면 이해하기가 훨씬 쉬워집니다.

나는 그것을 피할 수있을 때 여전히 C ++로 작성하는 것을 선호하고, 전반적으로 이점이 단점보다 크다고 생각합니다. 그러나 어떤 경우에는 C 사용에 대한 주장도 볼 수 있습니다.

임베디드 프로그래밍, 성능 등에 대한 많은 논쟁이 있지만 나는 그것을 사지 않습니다. C ++는 이러한 영역에서 C와 쉽게 비교됩니다. 하나:

최근에 저는 15 년 넘게 C ++로 프로그래밍 한 후 제 C 루트를 재발견했습니다. C ++에는 삶을 더 쉽게 만들어주는 좋은 기능이 있지만 많은 함정과 일을하는 "항상 더 나은 방법"이 있습니다. 당신은 실제로 당신이 한 해결책에 대해 결코 행복하지 않습니다. (오해하지 마십시오. 이것은 좋은 일이 될 수 있지만 대부분은 아닙니다).

C ++는 무한한 총격을 제공합니다. 틀림없이 좋을 수도 있지만 어쨌든 항상 너무 많이 사용하게됩니다. 이는 "멋진"및 "예쁜"추상화 계층, 일반성 등으로 솔루션을 위장하고 있음을 의미합니다.

C로 돌아가서 내가 발견 한 것은 실제로 다시 프로그래밍하는 것이 재미 있다는 것입니다. 상속을 가장 잘 사용하는 방법에 대해 모델링하고 생각하는 데 많은 시간을 투자 한 결과 C로 프로그래밍하면 실제로 소스 코드가 더 작고 가독성이 높아진다는 사실을 알게되었습니다. 이것은 물론 자기 훈련 수준에 따라 다릅니다. 그러나 실제로 필요하지 않은 간단한 코드에 너무 많은 추상화를 적용하는 것은 매우 쉽습니다.

C는 코드의 일부를 볼 때 실제로 무슨 일이 일어나고 있는지 볼 수 있다는 주요 이점이 있습니다 (예, 전 처리기 : -E로 컴파일 한 다음 볼 수 있습니다). 일부 C ++ 코드를 볼 때 너무 자주 사실이 아닌 것입니다. 범위 또는 할당으로 인해 암시 적으로 호출되는 생성자와 소멸자가 있으며, 잘못 사용되지 않은 경우에도 놀라운 동작을 일으킬 수있는 연산자 오버로딩이 있습니다. 나는 내가 제어 광이라는 것을 인정하지만, 이것은 신뢰할 수있는 소프트웨어를 작성하고자하는 소프트웨어 개발자에게 그렇게 나쁜 습관이 아니라는 결론에 도달했습니다. 나는 내 소프트웨어가해야 할 일을 정확히 수행하고 동시에 내 위장에 나쁜 느낌을주지 않는다고 말할 수있는 공정한 기회를 원합니다.

C ++에는 템플릿도 있습니다. 나는 그들을 싫어하고 사랑하지만 누군가가 그들을 완전히 이해한다고 말하면 나는 그를 거짓말 쟁이라고 부릅니다! 여기에는 컴파일러 작성자와 표준 정의에 관련된 사람들이 포함됩니다 (읽으려고 할 때 분명해집니다). 어리석게도 오해의 소지가있는 코너 케이스가 너무 많아 실제 코드를 작성하는 동안 모두 고려할 수 없습니다. 저는 C ++ 템플릿을 아주 좋아합니다. 그들과 함께 할 수있는 일은 정말 놀랍지 만, 마찬가지로 상상할 수없는 (아마도) 상상할 수없는 가장 이상하고 찾기 어려운 오류로 이어질 수 있습니다. 그리고 이러한 오류는 실제로 발생하며 드물지 않습니다. C ++ ARM에서 템플릿을 해결하는 데 관련된 규칙에 대해 읽으면 머리가 터질 것입니다. 그리고 그것은 컴파일러가 실제로 원하는 것을 이해하기 위해 이미 10 분 이상이 필요한 1000 자 길이의 컴파일러 오류 메시지를 읽어야하는 시간 낭비라는 느낌을줍니다. 일반적인 C ++ (라이브러리) 코드에서는 특정 템플릿을 가능하게하는 헤더 파일에서 많은 코드를 발견하는 경우가 많습니다. 그러면 빠른 컴퓨터에서도 컴파일 / 실행주기가 고통스럽게 느려지고 무언가를 변경할 때 코드의 많은 부분을 다시 컴파일해야합니다. 그곳에.

C ++에는 const 트랩도 있습니다. 가장 사소한 사용 사례를 제외한 모든 경우에 대해 const를 피하거나 조만간이를 버리거나 코드 기반이 발전 할 때, 특히 멋지고 유연한 OO 디자인을 개발하려고 할 때 코드베이스의 많은 부분을 리팩토링해야합니다.

C ++는 C보다 타이핑이 더 강해서 좋습니다.하지만 가끔 C ++ 코드를 컴파일하려고 할 때 타마 고치에게 먹이를주는 것처럼 느껴집니다. 내가 일반적으로 얻는 경고 및 오류의 대부분은 실제로 작동하지 않는 작업을 수행하는 것이 아니라 컴파일러가 이런 식으로 수행하는 것을 좋아하지 않거나 여기에 추가 키워드를 추가하지 않고 그곳에.

이것들은 내가 강력한 외부 라이브러리만을 사용하여 작성하는 소프트웨어에 대해 C ++를 좋아하지 않는 이유 중 일부일뿐입니다. 진짜 공포는 다른 사람들과 팀을 이루어 코드를 작성할 때 시작됩니다. 그들이 매우 영리한 C ++ 해커인지 순진한 초보자인지는 거의 중요하지 않습니다. 모든 사람이 오류를 만들지 만 C ++는 오류를 발견하기 어렵게 만들고 오류가 발생하기 전에 발견하기도 더 어렵게 만듭니다.

C ++를 사용하면 항상 디버거를 사용하지 않고 길을 잃지 만, 내 머리 속에서 내 코드의 정확성을 확인할 수 있고, 예상하지 못했던 경로에서 실행되는 내 코드를 찾기 위해 디버거에 의존 할 필요가 없습니다. 나는 실제로 내 머리 속에서 모든 코드를 실행하고 서브 루틴 등에서 포함 된 모든 브랜치를 취하려고 노력하고 가끔 만 디버거를 사용하여 내가 준비한 모든 아늑한 장소에서 얼마나 잘 실행되는지 확인하려고합니다. 모든 종류의 이상한 입력 데이터와 모든 조합에서 모든 코드 경로가 사용 된 너무 많은 테스트 케이스를 작성하고 실행하는 것은 단순히 불가능합니다. 따라서 C ++ 프로그램의 버그를 알지 못할 수도 있지만 이것이 버그가 없다는 것을 의미하지는 않습니다. C ++ 프로젝트가 클수록 우리가 가지고있는 모든 테스트 데이터로 완벽하게 실행 되더라도 발견되지 않은 버그가 많지 않을 것이라는 확신이 낮아집니다. 결국 나는 그것을 버리고 다른 언어 또는 다른 언어의 조합으로 다시 시작합니다.

나는 계속할 수 있지만 지금 쯤 내 요점을 분명히 한 것 같습니다. 이 모든 것이 C ++로 프로그래밍 할 때 비생산적인 느낌을 받았고 내 코드의 정확성에 대한 확신을 잃게 만들었습니다. 즉, 20 개 이상 작성한 C 코드를 계속 사용하고 의존하면서 더 이상 사용하지 않을 것입니다. 여러 해 전에. 단순히 내가 좋은 C ++ 프로그래머가 아니기 때문일 수도 있고, C와 다른 언어에 능숙하기 때문에 C ++에 관해서 내가 실제로 어떤 사람인지 알 수 있고 완전히 이해할 수 없을 수도 있습니다. .

인생은 짧다...

낮은 수준의 임베디드 환경에서 일부 "소프트웨어 엔지니어"는 EE에 대한 배경 지식을 갖고 있으며 C를 거의 마스터하지 않았습니다. C ++는 더 복잡하며 일부 사람들은 단순히 새로운 언어를 배우는 것을 두려워합니다. 따라서 C는 가장 낮은 공통 분모로 사용됩니다. (이들 제거를 제안하기 전에 그들은 하드 코어 아날로그를 이해하지 못하는 CS 메이저만큼이나 중요합니다.)

두 가지를 모두 계승하고 유지 한 경험에서 말하면 C의 끔찍한 디자인은 이해하기 어렵고, 풀고, 사용 가능한 것으로 리팩토링하기 어렵습니다.

C ++의 끔찍한 디자인은 임의의 추상화 계층이 어떤 상황에서 어떤 코드가 실행될 것인지 파악하기 위해 코드베이스 주변에 신경을 쏟기 때문에 무한히 더 나쁩니다.

훌륭한 디자인을 만들지 못할 것이라는 것을 알고있는 엔지니어와 함께 일해야한다면 후자보다는 전자를 선호합니다.

나는 임베디드 시스템과 유사한 것을 프로그래밍하는 데에도 개인적으로 싫어하는 것 외에 다른 이유를 보지 못했습니다. C ++에서는 사용하는 기능에 대해서만 오버 헤드를 지불합니다. C ++ 오버 헤드가 너무 높은 특정 상황에서 C ++의 C 하위 집합을 사용할 수 있습니다. 즉, 일부 C 프로그래머는 일부 C ++ 구성의 오버 헤드를 과대 평가한다고 생각합니다. 몇 가지 예를 나열하겠습니다.

• 클래스 및 멤버 함수는 일반 함수에 비해 오버 헤드가 없습니다 (가상 함수를 사용하지 않는 한 함수 포인터를 사용하는 것에 비해 오버 헤드가 없음).
• 템플릿에는 오버 헤드가 거의 없습니다 (대부분 오버 헤드가 전혀 없음)

한 가지 유효한 이유는 괜찮은 C ++ 컴파일러가없는 플랫폼 (C ++ 컴파일러가 전혀 없거나 컴파일러가 존재하지만 제대로 구현되지 않았으며 일부 C ++ 기능에 불필요한 높은 오버 헤드를 부과 함)을 위해 프로그래밍 할 때입니다.

왜 영어로 말하기를 제한합니까? 아마도 당신은 세르비아어로 더 창의적인 작가가 될 것입니다.

그것은 명백한 오류를 가진 동일한 주장입니다. 작업이 있고 편안한 도구가 작업을 효율적으로 해결한다면 적절한 이유에서 편안한 도구를 사용할 것입니다.

C ++는 훨씬 더 긴 학습 곡선을 가지고 있습니다. C에는 알아야 할 구조가 거의 없으며 강력한 소프트웨어 코딩을 시작할 수 있습니다. C ++에서는 C베이스, OO 및 일반 프로그래밍, 예외 등을 배워야합니다. 그리고 시간이 지나면 대부분의 기능을 알고 사용할 수 있지만 컴파일러가 어떻게 작동하는지 알 수 없습니다. 그들에게 어떤 암시 적 오버 헤드가 있는지 아닌지 번역합니다. 이것은 많은 시간과 에너지가 필요합니다.

전문 프로젝트의 경우 이미 C ++를 잘 아는 사람들을 고용 할 수 있기 때문에이 주장은 중요하지 않을 수 있습니다. 그러나 C가 여전히 사용되는 오픈 소스 프로젝트에서는 사람들이 자신이 좋아하는 언어를 선택하고 사용할 수 있습니다. 모든 OS 프로그래머가 전문 프로그래머는 아닙니다.

Dan Olson의 답변에 대해 후속 조치를 취하고 싶습니다. 저는 사람들이 C ++의 잠재적으로 위험하고 비생산적인 기능을 두려워한다고 믿습니다. 그러나 Dan의 말과는 달리 코딩 표준을 결정하는 것이 효과적이라고 생각하지 않는 이유는 다음 두 가지입니다.

1. 코딩 표준은 엄격하게 시행하기 어려울 수 있습니다.
2. 좋은 것을 생각해내는 것은 매우 어려울 수 있습니다.

코딩 표준을 결정하는 것은 쉽게 정치적 문제가되고 나중에 수정 될 수 있기 때문에 여기서 두 번째 이유가 첫 번째 이유보다 훨씬 더 중요하다고 생각합니다. 다음과 같은 단순화 된 경우를 고려하십시오.

1. stl 컨테이너를 사용할 수 있지만 자체 코드에서 템플릿을 사용할 수 없습니다.
2. 사람들은이 클래스 나 템플릿 클래스를 코딩 할 수만 있다면 더 생산적 일 것이라고 불평하기 시작합니다.
3. 이를 허용하도록 코딩 표준이 수정되었습니다.
4. 아무도 따르지 않는 지나치게 복잡한 코딩 표준과 표준을 둘러싼 과도한 관료주의와 결합하여 표준이 방지해야 할 위험 코드의 종류를 정확하게 사용하도록 기울기를 슬라이드합니다.

(3 단계에서 표준이 수정되지 않은 대안은 경험적으로 고려하기에는 너무 가능성이 없으며 어쨌든 그다지 좋지 않을 것입니다.)

몇 년 전에는 거의 모든 작업에 C ++를 사용했지만 C 또는 C ++로 처리해야하는 저수준 작업에서는 C가 더 선호되고 다른 모든 작업은 다른 작업에서 수행되어야한다고 강하게 느끼기 시작했습니다. 언어 전적으로. (일부 특정 고성능 문제 도메인 인 경우에만 가능한 예외, wrt. Blitz ++ )

C를 사용하거나 라이브러리 코드를 작성할 때 적어도 C 인터페이스를 내 보냅니다.

잘못 정의 된 ABI 번거 로움을 원하지 않습니다.

나는 설득력이 있다고 생각되는 C ++ 대신 C를 사용하는 것에 대한 어떤 주장도 본 적이 없다. 나는 대부분의 사람들이 C ++이 제공하는 특정 기능을 두려워한다고 생각합니다. 그러나 이것은 코딩 표준을 통해 특정 기능을 사용할지 여부를 강제 할 수 있기 때문에 나를 설득하지 못합니다. C에서도 피하고 싶은 것이 많이 있습니다. C ++를 완전히 버리는 것은 본질적으로 C에 비해 더 나은 코드를 작성하는 데 도움이되는 실질적인 이점을 제공하지 않는다는 것을 의미합니다. 이것은 제가 상당히 무지하다고 생각하는 관점입니다.

또한 사람들은 항상 C ++ 컴파일러가없는 플랫폼의 상황을 제기하는 것 같습니다. 확실히 C가 여기에 적절할 것이지만 요즘에는 그런 플랫폼을 찾기가 어려울 것이라고 생각합니다.

내가 아직 보지 못한 점 중 하나는 가장 중요하다고 생각합니다.

내가 매일 사용하는 대부분의 라이브러리는 Python, Ruby, Perl, Java 등에 대한 바인딩이있는 C 라이브러리입니다. 내가 본 것보다 19 개의 다른 언어 바인딩으로 C 라이브러리를 래핑하는 것이 훨씬 쉽습니다. C ++ 라이브러리를 래핑합니다.

예를 들어, 저는 카이로를 한 번 배웠고 이후 3-4 개의 다른 언어로 사용했습니다. 큰 승리! 차라리 나중에 다시 사용할 수있는 프로그램을 작성하고 싶은데, 다른 프로그래밍 언어에도 쉽게 적용 할 수있는 프로그램을 작성하는 것이 극단적 인 경우입니다.

C ++ 라이브러리를 바인딩 할 수 있다는 것을 알고 있지만 AFAICT는 동일하지 않습니다. Qt (v3 및 v4)를 다른 언어로 사용해 왔지만 사용하기에는 그다지 좋지 않습니다. 네이티브 라이브러리가 아닌 다른 언어로 C ++를 작성하는 것처럼 느껴집니다. (C ++ 메소드 sigs를 문자열로 전달해야합니다!)

한 번 사용할 함수를 작성하거나 모든 세상이 C ++라고 생각한다면 C ++는 아마도 더 나은 언어 일 것입니다. C는 처음부터 언어 이식성을 위해 디자인하는 경우 더 쉬운 언어처럼 보입니다.

Windows 커널 개발은 C ++를 지원하지 않습니다 (슬프게도).

Linus Torvalds가 C를 선호하는 이유에 대한 재미있는 폭언을 여기서 읽을 수 있습니다.

Mac의 기본 코드는 Objective-c입니다. PC의 기본 코드는 c (window.h) 또는 c ++ (mfc)입니다. 이 두 환경 모두 변경없이 c를 사용할 수 있습니다. 코드 라이브러리가 교차 플랫폼이되기를 원할 때 ansi c는 좋은 선택처럼 보입니다.

몇 가지 이유를 생각할 수 있습니다.

만족스러운 C ++ 컴파일러가 없을 수 있습니다. C ++는 훨씬 더 큰 언어이며 현대 C ++를 처리 할 수없는 시스템에서 C 컴파일러를 실행했습니다.

질문자 또는 함께 일하는 사람들은 C에 익숙하지만 C ++에는 익숙하지 않을 수 있습니다.

프로젝트가 C로되어있을 수 있습니다. C에 일부 C ++ 기능을 추가하는 것은 가능하지만 유지 관리가 불가능한 문제로 이어질 수 있습니다. 한 언어 또는 다른 언어를 선택하는 것이 좋습니다 (실용적인 경우 일반적으로 C ++).

질문자는 C ++의 학습 곡선에 대해 쓸모없는 견해를 가지고있을 수 있습니다. (올바르게 접근하면 C보다 쉽습니다. 내가 본 대부분의 입문서는 올바르게 접근하지 않습니다.)

C와 C ++는 서로 다른 두 언어이며 시간이 지남에 따라 점점 더 달라집니다. 두 가지를 동시에 코딩하는 것은 좋지 않으며 C ++의 C와 유사한 하위 집합을 사용하면 C ++의 대부분의 장점을 놓칠 수 있습니다.

두 가지 언어를 사용하는 환경에서 작업하는 경우 성능이 중요한 하위 수준 기능에는 C를 사용하고 비즈니스 논리에는 C # / Java와 같은 기능적 / 고수준 언어를 사용할 수 있습니다. 이러한 함수에 C ++ 코드를 사용하는 경우 JNI / 관리되지 않는 코드에 C-Wrapper가 필요하므로 C 만 사용하는 것보다 일이 더 복잡해집니다.

두 가지 이유로 C 프로그래밍과 함께 C ++를 사용합니다.

• vector그리고 string어레이 메모리 관리를 멀리하기 위해
• 엄격한 유형 검사 및 캐스트는 그렇지 않으면 놓칠 수있는 모든 성가신 경고 및 / 또는 잡기.

그래서 C는 실제로 몇 가지 C ++를 차용하지만 가능한 한 C ++ 컴파일러를 사용합니다. 다른 사람이 답변에서 말했듯이, 나는 실제로 이런 식으로 더 많은 C ++를 선택하고 C가 너무 관여하는 곳에서 C ++를 사용합니다. RAII를 사용한 모니터링 / 잠금은 최근에 멀티 스레드 프로그램과 파일 열기 / 닫기에 유사한 또 다른 구조를 다룰 때 사용한 것들 중 하나입니다.

나는 C가 더 휴대 가능하다고 생각합니다. 저는 약 5 년 전에 코드를 다양한 유닉스 (AIX, Irix, HPUX, Linux)로 포팅하는 작업을했습니다. C 코드는 이식하기 쉬웠지만 일부 C ++ 코드를 이식하는 데 여러 가지 문제가있었습니다. 어쩌면 미성숙 한 개발 환경이었을 수도 있지만, 이런 이유로 C ++보다 C를 훨씬 더 많이 사용하고 싶습니다.

1. C는 단순한 언어이고 C ++는 그렇지 않습니다. 많은 사람들에게 C ++는 완전히 마스터하기에는 너무 복잡합니다 . http://en.wikipedia.org/wiki/C%2B%2B#Criticism을 참조하십시오 .

2. 복잡성으로 인해 다른 프로그래머는 일반적으로 언어의 다른 하위 집합 만 마스터합니다. 다른 사람의 코드를 읽는 것은 고통 스럽습니다.

3. 언어의 복잡성, 함정으로 인해 너무 많은주의가 산만 해지고 때로는 생산성이 저하됩니다. 직업 자체에 집중하는 대신, 나는 종종 언어 자체와 싸우는 자신을 발견했습니다. Java / python은보다 생산적인 대안입니다.

4. 손상된 C 코드를 디버깅하는 것은 일반적으로 손상된 C ++ 코드를 디버깅하는 것보다 훨씬 간단합니다.

5. Java / C #과 달리 C ++ 표준 라이브러리는 C 표준 라이브러리의 범위를 거의 벗어나지 않습니다.

6. Linus Torvalds (Linux) 및 Richard Stallman (Emacs)과 같은 유명한 프로그래머는 C ++를 싫어합니다.

대부분의 프로그래머는 모든 사람이 품질을 최우선으로 생각한다는 사실을 당연시합니다. 항상 그런 것은 아닙니다. C에 익숙하다면 C ++가 배후에서 너무 많은 일을하는 것처럼 보일 수 있습니다. C ++에서 유형 검사의 엄격함도 제한적으로 보일 수 있습니다. 많은 사람들이 이러한 "성가신"을 방지하기 위해 C ++가 예방할 수있는 버그의 종류를 기꺼이 도입하려고합니다.

내가 생각할 수있는 세 가지 이유가 있습니다. 하나는 C가 바이너리의 크기가 작고 모든 시스템에서 C 컴파일러의 더 넓은 가용성으로 인해 임베디드 시스템에 더 적합하다는 것입니다. 두 번째는 이식성입니다. C는 더 작은 언어이고 ANSI C 코드는 어디에서나 컴파일됩니다. C ++에서 이식성을 깨는 것이 더 쉽습니다. 마지막은 언어 자체입니다. C ++는 더 어렵고 가장 잘 설계된 언어입니다. Torvalds의 불만은 위에보고되었습니다. C ++ 자주 묻는 답변 ( http://yosefk.com/c++fqa/ ) 도 살펴볼 수 있습니다 .

이식성이 문제가 될 수 있습니다. Gordon Carpenter-Thomp의 대답과는 달리 다른 Linux / Unix 버전에서 다른 버전의 libstdc ++에 대한 런타임 지원이라고 제안합니다. 이에 대한 좋은 토론은 이 링크 를 참조하십시오 . 약간의 발췌 :

C ++ 애플리케이션의 여러 부분에서 사용되는 런타임 지원 코드는 호환되어야합니다. 프로그램의 한 부분이 다른 부분에서 제공하는 객체를 dynamic_cast하거나 캐치해야하는 경우 두 부분 모두 특정 구현 세부 사항 (vtable을 찾는 방법, 스택을 해제하는 방법 등)에 동의해야합니다.

유사한 기능을 가진 C ++ 및 기타 GCC 지원 언어의 경우 이러한 세부 정보는 C ++ ABI에 의해 지정됩니다. GCC에서 사용하는 ABI가 변경 될 때마다 다른 GCC 버전에서 생성 된 호환되지 않는 라이브러리로 끝납니다. 일반 C의 경우도 동일하지만 C ABI는 훨씬 더 간단하고 훨씬 더 오래 사용되어 상당히 안정적입니다.

여기에서 양방향으로 많은 제안을 따를 수 있습니다. 그러나 결국 그것은 a) 비교 가능한 단순 b) 비교 가능한 복합물로 귀결됩니다.

누군가가 일종의 언어 복잡성 측정을 "발명"했는지 알지 못합니다.

0-10의 척도에서 나는 아마도 C를 2 또는 3으로 평가하는 반면 C ++는 8-10 사이입니다. 나는 C ++가 가장 복잡한 언어 중 하나라고 주장하고 싶지만 Ada, PL1 등을 알지 못하기 때문에 다른 언어에 비해 그렇게 복잡하지 않을 수도 있습니다.

C ++는 C의 모든 복잡성을 상속하므로 C의 복잡성 수준보다 낮을 수 없습니다.

필자는 스크립팅 언어와 C를 사용하는 것이 훨씬 더 편할 것입니다. 결국 다음 질문에 답해야합니다. "항상 더 좋을까요?"

C에서 찾은 가장 유용한 점은 네임 스페이스와 오버로드가 없다는 것입니다. 함수와 기호 이름은 고유 한 식별자입니다. 이러한 기호가 사용 된 위치를 찾으려면 grep소스 코드 파일을 통해 찾을 수 있으며 검색 결과에 위치가 표시됩니다.

새로운 기능 또는 구성 요소를 오래되고 엉킨 시스템에 연결할 때 필수적입니다.

정교한 콜 그래프 작성 도구 없이는 C ++에서이 작업을 쉽게 수행 할 수 없습니다.

대부분의 사람들은 C와 C ++가 어떻게 든 관련이 있다고 생각하는 것 같지만 슬프게도 착각합니다. C ++는 C와 완전히 다른 언어입니다.

C ++에서는 객체와 객체가 서로 어떻게 관련되어 있는지 생각합니다. C에서는 API 측면에서 생각합니다. 하루와 17 일의 차이와 같습니다.

잘못된 비유 : 누군가가 영어에 중국어를 추가하고 영어 ++라고 부르면 영어 ++의이 부분에서 사랑을 표현하는 것이 훨씬 쉽기 때문에 최신 연애 편지에 중국어 줄을 추가하는 것이 편하지 않을 것입니다.

다음은 프로젝트를 C로 제한하는 것이 유익 할 수있는 모든 이유입니다.

• 언어가 훨씬 간단하기 때문에 더 빠른 컴파일
• 런타임 지원이 적어 저수준 환경에 더 적합합니다.
• 다른 언어와 훨씬 쉽게 인터페이스
• 스택에서 가변 크기 배열 지원
• 이름 변경이 없기 때문에 어셈블리 코드를 읽기가 더 쉽습니다.
• 사실상 표준 애플리케이션 바이너리 인터페이스이기 때문에 서로 다른 컴파일러에서 생성 된 코드를 쉽게 결합 할 수 있습니다.