C++의 제한은 C언어와 비교했을 때 어떻게 됩니까?

C++의 제한은 C언어와 비교했을 때 어떻게 됩니까?

닫았습니다. 이 질문은의견 기반의현재 답변을 받고 있지 않습니다.

---

이 질문을 개선하시겠습니까?이 게시물을 편집하여 사실과 인용문으로 답변할 수 있도록 질문을 업데이트하십시오.

8년 전에 문을 닫았어요

이 질문을 개선하다

C++의 이점은 다음과 같습니다.

• C++는 고객이 요구하는 특정 기능을 제공합니다.
• 그들의 C 컴파일러는 거의 확실히 C++ 컴파일러이기 때문에 소프트웨어 비용에 대한 영향은 없습니다.
• C++는 C와 같은 휴대성
• C++ 코드는 C와 마찬가지로 효율적입니다(또는 그 이상 또는 그 이하).

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

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

중복되지 않습니다.왜냐하면 이 질문은 언어의 제한에 대한 질문이기 때문입니다.한 언어를 다른 언어에 대해 배우거나 배우거나 배우거나 해서는 안 되는 것에 대한 질문이 아닙니다.

Peter Kirkham의 투고는 특히 C99에 관해 제가 미처 생각하지 못했던 가장 유익한 것이었기 때문에 저는 그것을 받아들였습니다.참여해주신 모든 분들께 감사드립니다.

전문가답지도 않고, 특별히 좋은 답변도 아닌 것은 알지만, 단순히 C를 정말 좋아하기 때문입니다.C는 작고 심플해서 내 머릿속에 있는 언어 전체를 맞출 수 있다.C++는 항상 내가 찾기가 어려운 여러 층으로 이루어진 거대한 엉망진창처럼 보였다.이 때문에 C++를 쓸 때마다 C를 코드화할 때보다 디버깅하고 딱딱한 표면에 머리를 부딪히는 데 훨씬 더 많은 시간을 할애하게 됩니다.다시 한번 나는 이것의 많은 부분이 내 자신의 '무시함'의 결과라는 것을 깨달았다.

선택하게 되면 인터페이스와 데이터베이스의 상호작용과 같은 모든 고급 정보를 python(또는 C#)으로 작성하고 C로 빨라야 하는 모든 정보를 작성합니다.내게는 세상에서 가장 좋은 것을 준다.모든 것을 C++로 쓰는 것은 세상에서 가장 나쁜 것을 얻는 것 같은 느낌이다.

편집: 몇 가지 C++ 기능을 가진 C는 프로젝트에 여러 명이 참여하거나 유지보수가 우선되는 경우 대부분 좋지 않은 아이디어라고 생각합니다.무엇이 '소수'를 구성하며, 어떤 비트가 C에서 수행되어야 하는지, 그리고 C++에서 어떤 비트가 최종적으로 매우 정신분열적인 코드베이스로 이어지는지에 대해서는 이견이 있을 것이다.

임베디드 프로그래밍, 퍼포먼스 등에 대해 많은 논쟁이 있습니다만, 저는 그것을 믿지 않습니다.C++는 이러한 영역에서 C와 쉽게 비교됩니다.단,

최근 15년 이상 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:

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

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

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

더 이상 유효하지 않은 C입니다.(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++ 표준 사용'을 제안합니다.:queue class'는 C에서 큐의 라이브러리 구현을 찾는 질문에 대한 답변으로 '목적 C를 사용한다'와 'Java.util을 호출한다'를 제안하는 것보다 더 복잡합니다.JNI를 사용한 큐클래스 또는 'CPython 라이브러리 호출' - 목표 C는 실제로 C의 적절한 슈퍼셋(C99 포함)이며 Java 및 CPython 라이브러리는 모두 C++ 언어에 관련 없는 코드를 포트하지 않고 C에서 직접 호출할 수 있습니다.

물론 C++ 라이브러리에 Cfacade를 제공할 수 있지만, C++는 Java나 Python과 다르지 않습니다.

낮은 수준의 임베디드 환경에서는 일부 "소프트웨어 엔지니어"가 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가 선호되고, 다른 모든 작업은 다른 언어로 수행되어야 한다는 것을 강하게 느끼기 시작했습니다. (특정 고성능 문제 도메인만 해당됩니다.)블릿츠++)

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

게다가 사람들은 항상 C++ 컴파일러가 존재하지 않는 플랫폼의 상황을 제기하는 것 같습니다.물론 이곳에는 C가 적합하겠지만, 요즘은 그런 플랫폼을 찾기가 힘들 것 같습니다.

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

누군가 언어 복잡도 측정을 "발명"했는지 모르겠습니다.

C++는 8-10 사이인 반면, 0-10의 척도로는 C를 2 또는 3으로 평가할 수 있습니다.C++는 가장 복잡한 언어 중 하나라고 생각합니다만, Ada나 PL1 같은 것은 모르기 때문에, 다른 언어에 비하면 그다지 복잡하지 않을지도 모릅니다.

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

저로서는 스크립트 언어와 C를 사용하는 것이 훨씬 편할 것입니다.그래서 결국 다음과 같은 질문에 답해야 한다."더 많은 것이 항상 좋은가?"

C의 주된 장점은 코드 조각을 보면 실제로 무슨 일이 일어나고 있는지 알 수 있다는 것입니다(예, 프리프로세서: -E로 컴파일하면 알 수 있습니다).C++ 코드를 보면 사실이 아닌 경우가 너무 많습니다.여기에는 범위나 할당에 따라 암묵적으로 호출되는 생성자와 파괴자가 있습니다. 연산자의 과부하가 심하지 않은 경우에도 놀라운 동작을 일으킬 수 있습니다.제가 통제광이라는 것은 인정하지만, 신뢰할 수 있는 소프트웨어를 만들고 싶어하는 소프트웨어 개발자에게 이것은 나쁜 습관이 아니라는 결론에 도달했습니다.저는 단지 제 소프트웨어가 제대로 작동하면서 동시에 제 뱃속에 나쁜 느낌이 들지 않는다는 것을 말하고 싶을 뿐입니다. 왜냐하면 저는 아직도 버그가 너무 많아서 제가 버그를 일으키는 코드를 봐도 알아차리지 못할 수도 있다는 것을 알고 있기 때문입니다.

C++에는 템플릿도 있습니다.나는 그들을 싫어하고 사랑하지만, 만약 누군가가 그들을 완전히 이해한다고 말한다면 나는 그/그녀를 거짓말쟁이라고 부른다!여기에는 컴파일러 라이터뿐만 아니라 표준을 정의하는 데 관여하는 사람도 포함됩니다(읽으려고 하면 알 수 있습니다).터무니없이 오해의 소지가 있는 코너 케이스가 너무 많아서 실제 코드를 작성할 때 그것들을 모두 고려하는 것은 불가능하다.C++ 템플릿은 파워가 뛰어납니다.여러분이 그들과 함께 할 수 있는 것은 정말 놀랍지만, 그들도 마찬가지로 상상할 수 없는 가장 이상하고 찾기 어려운 오류를 야기할 수 있습니다.그리고 이러한 오류는 실제로 발생하기도 하고 드물지도 않습니다.C++ ARM에서 템플릿을 해결하기 위한 규칙을 읽으면 머리가 터질 것 같습니다.또한 컴파일러가 실제로 무엇을 원하는지 이해하기 위해 10분 이상 걸리는 1000자 길이의 컴파일러 오류 메시지를 읽어야 하는 시간을 낭비하는 것 같은 기분이 듭니다.일반적인 C++(라이브러리) 코드에서는 헤더 파일에 많은 코드가 포함되어 있어 특정 템플릿이 가능한 경우가 많습니다.이것에 의해, 고속 머신에서도 컴파일/실행 사이클이 매우 느려져, 코드의 대부분을 재컴파일 할 필요가 있습니다.

C++에는 const 트랩도 있습니다.가장 사소한 사용 사례를 제외한 모든 사용 사례에 대한 제약을 피하거나, 조만간 이를 버리거나, 특히 훌륭하고 유연한 OOO 디자인을 개발하려고 할 때 코드 베이스의 상당 부분을 수정해야 합니다.

C++는 C보다 타이핑이 강하기 때문에 좋지만, C++ 코드를 컴파일하려고 하면 타마고치를 먹이는 것 같은 느낌이 들 때가 있습니다.제가 보통 받는 경고와 오류의 대부분은 제가 제대로 작동하지 않는 일을 하는 것이 아니라 컴파일러가 제가 이런 식으로 하는 것을 싫어하는지 아닌지에 따라 여기저기서 추가 키워드를 넣거나 하지 않는 것입니다.

이러한 이유로, 견고한 외부 라이브러리만을 사용해 단독으로 작성하는 소프트웨어의 C++를 좋아하지 않습니다.진짜 공포는 당신이 다른 사람들과 팀을 이루어 코드를 쓸 때 시작된다.그들이 매우 영리한 C++ 해커인지 아니면 순진한 초보자인지는 거의 중요하지 않다.누구나 실수를 하지만, C++는 의도적으로 오류를 발견하는 것을 어렵게 만들고, 오류가 발생하기 전에 이를 발견하는 것을 더욱 어렵게 합니다.

C++를 사용하면 항상 디버거를 사용하지 않고 단순히 길을 잃지만, 나는 내 코드의 정확성을 머릿속에서 확인할 수 있고, 내가 전혀 예상하지 못했던 경로에서 실행되는 코드를 디버거에 의존하지 않아도 된다.저는 실제로 모든 코드를 머릿속으로 실행하려고 하고, 서브루틴 등에서도 가지고 있는 모든 브랜치를 사용하려고 합니다.또한 디버거를 사용하는 것은 디버거를 위해 준비한 모든 아늑한 장소에서 디버거가 얼마나 잘 동작하는지 보기 위해서입니다.모든 코드 경로가 모든 종류의 이상한 입력 데이터와 조합되어 사용될 정도로 많은 테스트 케이스를 작성하고 실행하는 것은 단순히 불가능합니다.따라서 C++ 프로그램의 버그를 모를 수도 있지만 그것이 존재하지 않는 것은 아닙니다.C++ 프로젝트의 규모가 클수록, 수중에 있는 모든 테스트 데이터를 사용해 완전하게 동작해도, 검출되지 않는 버그가 많지 않을 것이라는 확신이 듭니다.결국 나는 그것을 버리고 다른 언어나 다른 언어의 조합으로 다시 시작한다.

나는 계속할 수 있지만 지금쯤 내 요점을 분명히 했을 것이다.이 모든 것이 C++로 프로그램 할 때 비생산적인 느낌이 들었고, 20여 년 전에 작성한 C코드를 그대로 사용하고 의지하면서 더 이상 사용하지 않겠다는 자신의 코드의 정확성에 대한 자신감을 잃게 만들었다.단순히 내가 C++프로그래머가 아니기 때문인지, C나 다른 언어에 능통하기 때문에 C++에 관해서는 내가 실제로 얼마나 어두운지 알 수 있고, 그것을 완전히 이해할 수 없을지도 모른다.

인생은 짧다...

왜 영어로 말하는 것을 제한합니까?세르비아어로 좀 더 창의적인 작가가 되실 수도 있겠네요

그것은 명백한 오류와 같은 주장이다.작업이 있고 편리한 도구가 작업을 효율적으로 해결한다면 편리한 도구를 사용할 수 있습니다.

C++는 로우 레벨의 임베디드 시스템과 같은 일부 실제 환경에서는 지원되지 않습니다.그럴 만한 이유가 있습니다.C는 그런 일을 쉽게 할 수 있는데 왜 더 큰 것을 사용합니까?

아직 제기되지 않은 한 가지 점이 가장 중요하다고 생각합니다.

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

예를 들어, 저는 카이로를 한 번 배웠고, 그 후 서너 개의 다른 언어로 그것을 사용했습니다.대박이다!앞으로 다시 사용할 수 있는 프로그램을 만들고 싶은데, 다른 프로그래밍 언어에 쉽게 적용할 수 있는 프로그램을 쓰는 것은 극단적인 경우입니다.

C++ 라이브러리를 바인드할 수 있는 것은 알고 있습니다만, AFAICT는 다릅니다.Qt(v3 및 v4)를 다른 언어로 사용해 본 적이 있지만 사용하기에는 그다지 좋지 않습니다.원어민 라이브러리가 아닌 다른 언어로 C++를 쓰는 것 같은 느낌이 듭니다.(C++ 메서드 sig를 문자열로 전달해야 합니다.)

한 번 사용할 함수를 쓰거나 모든 세상이 C++라고 생각되는 경우 C++가 더 좋은 언어일 수 있습니다.처음부터 언어 휴대성을 염두에 둔 설계라면 C가 더 쉬운 언어인 것 같습니다.

Windows 커널 개발은 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 인터페이스를 내보냅니다.

나는 정의되지 않은 ABI의 번거로움을 원하지 않는다.

대부분의 사람들은 C와 C++가 어떤 식으로든 연관되어 있다고 생각하는 것 같지만, 그들은 슬프게도 잘못 알고 있다.C++는 C와는 전혀 다른 언어입니다.

C++에서는 오브젝트나 오브젝트간의 관련성을 생각할 수 있습니다.C에서는 API의 관점에서 생각합니다.낮과 17일의 차이 같아요.

좋지 않은 비유: 만약 누군가가 영어에 중국어를 추가하고 영어++라고 부른다면, 당신은 아마도 최근의 연애편지에 중국어를 추가하는 것이 편안하지 않을 것이다. 왜냐하면 영어++의 이 부분에서는 사랑을 표현하는 것이 훨씬 더 쉽기 때문이다.

리누스 토발즈가 왜 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++는 2개의 다른 언어이며 시간이 지남에 따라 점점 더 달라지고 있다는 점에 유의하십시오.C++의 C-like 서브셋을 사용하면 C++의 장점 대부분을 놓칠 수 있습니다.

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

• vector그리고.string어레이 메모리 관리에서 벗어나기 위해
• 그렇지 않으면 놓칠 수 있는 모든 뉘앙스를 경고하거나 포착하기 위해 엄격한 활자 검사와 캐스팅을 합니다.

그래서 C는 실제로 몇 개의 c++를 빌리고 있지만 가능한 한 c++ 컴파일러를 사용하고 있습니다.다른 사람이 답변에서 말한 것처럼, 나는 실제로 더 많은 C++를 이런 식으로 집어 들었고, C가 지나치게 관여하는 곳에서는 C++를 사용한다는 것을 알게 되었습니다.RAII를 사용한 모니터/잠금은 최근 멀티 스레드 프로그램이나 파일을 열거나 닫을 때 사용한 것 중 하나입니다.

C가 더 휴대성이 좋은 것 같아요.약 5년 전에 많은 유닉스(AIX, Irix, HPUX, Linux)에 코드를 이식하는 작업을 했습니다.C 코드는 포팅이 용이했지만 C++ 코드 중 일부를 포팅하는 데 여러 가지 문제가 있었습니다.미숙한 개발 환경일 수도 있지만, 저는 이런 이유로 C++보다 C를 사용하는 것이 더 좋습니다.

2개 언어를 사용하는 환경에서 작업하는 경우 일부 성능 크리티컬 하위 수준 기능에는 C를 사용하고 비즈니스 로직에는 C#/Java와 같은 기능/고급 언어를 사용할 수 있습니다.이러한 함수에 C++ 코드를 사용하는 경우 JNI/미관리 코드에는 C-Wrappers가 필요하며 C를 사용하는 것보다 더 복잡합니다.

대부분의 프로그래머들은 누구나 품질을 최우선시하는 것을 당연하게 여긴다.항상 그렇지는 않아요.C에 익숙하다면, C++는 뒤에서 당신에게 너무 많은 것을 하는 것처럼 보일 수 있습니다.C++에서의 타입 체크의 엄격함도 제약으로 보일 수 있습니다.많은 사람들은 이러한 "누이"를 피하기 위해 C++가 예방하는 데 도움이 되는 버그를 도입하는 위험을 감수할 용의가 있습니다.

There are three reasons I can think of. One is that C is more suited for embedded systems, due to the small size of its binaries and the wider availability of C compilers on any system. The second is portability: C is a smaller language, and and ANSI C code will compile anywhere. It's easier to break portability in C++. The last one is the language itself. C++ is harder, and is most definitely a very poorly designed language. Torvalds gripes are reported above. You may also want to look at the C++ Frequently Questioned Answers (http://yosefk.com/c++fqa/).

Portability may be an issue. Different to Gordon Carpenter-Thomp's answer, I would suggest that it's rather the runtime support of different versions of libstdc++ on different linux/unix versions. See this link for a good discussion about this. A little excerpt:

The runtime support code used by different parts of a C++ application needs to be compatible. If one part of the program needs to dynamic_cast or catch objects provided by another, both parts must agree on certain implementation details: how to find vtables, how to unwind the stack, and so on.

For C++ and a few other GCC-supported languages with similar features, such details are specified by a C++ ABI. Whenever the ABI used by GCC changes you'll end up with incompatible libraries produced by the different GCC versions. The same is true for plain C, but the C ABI is much simpler and has been around a lot longer so it's fairly stable.

The most useful thing I found in C is the lack of namespaces and overloads: function and symbol names are unique identifiers. To find the places where these symbols are used you can just grep through the source code files and search results will shows the locations.

It's essential when wiring in a new feature or component to an old and tangled system.

You cannot do this easily in C++, without a sophisticated call graph building tool.

The following are all reasons why it may be beneficial to limit a project to C:

• faster compilation because the language is much simpler
• requires less runtime support, making it more suitable low-level environments
• much easier to interface with other languages
• supports variable sized arrays on the stack
• easier to read assembly code because there is no name mangling
• allows code produced by different compilers to be easily combined since it is the de facto standard application binary interface

There are various flavours of attempts of enhancing C into an object-oriented language: C++, C# and Objective-C. (Java and friends are just a flavour of C#, with even more problems)

C# implemented OO well and completely, but at the cost of the possibility of reverting to procedural design without introducing either hassle or code smell. Also, the introduction of a virtual machine made it difficult to write code that is anywhere near low level and it can never be self-hosted as the virtual machine itself have to be implemented in some language that can run natively. Java is even more problematic by making primitive types second-order citizen. (In C#, you have System.Int32 (a primitive type, int) : System.ValueType : System.Object, which makes primitive types still objects, but in Java primitive types are not objects at all). However, it is the most portable as compiled binaries that runs under virtual machines are inherently binary compatible under different platforms.

C++ did not use any virtual machine, and retained the C pointers, which make it still suitable for system development. (The kernel of OS X, Darwin, is largely written in C++, but a tight subset of which that does not have templates, multiple inheritance or STL, essentially a C++-looking dialect of Objective-C. Look at OS X IOKit documentation and you will find out) However C++ did not resolve those classical C issues at all while introducing more issues, including portability issues which is clearly the most obvious.

Objective-C went half ways in the middle of C++ and C#, as it is a simple mix of C (any version) and a modified Smalltalk dialect. Smalltalk, just like C#, treats everything as objects. It does not use a virtual machine as well, and it can still (requires!) use pointers, thus it can still be used as a system development language. (Weird why there is nobody doing it? I want to fork Minix and try implement a kernel with minimal assembler and C, and mostly Objective-C) With appropriate libraries Objective-C is largely code-compatible (that is, requires a recompile but no code change) between platforms just like C.

ReferenceURL : https://stackoverflow.com/questions/649789/what-would-be-c-limitations-compared-c-language