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++ には存在しない機能に関するものです。

楽しみのためにそれらの機能を使用しているわけではありません。それを別の言語に移植するにはかなりの作業が必要です。

したがって、

と提案するのは明らかに間違っています。

既存の C コードを C++ の手続き型サブセットに移植するには、多くの場合、かなりのコストがかかります。

「C++ std::queue クラスを使用する」ことを提案 質問への回答として、C でキューのライブラリ実装を探すことは、「オブジェクティブ C を使用する」 ことを提案するよりも気が遠くなります。 「JNI を使用して Java の java.util.Queue クラスを呼び出す」 または 'CPython ライブラリを呼び出す' - Objective C は実際には C (C99 を含む) の適切なスーパーセットであり、Java と CPython ライブラリは両方とも、無関係なコードを C++ 言語に移植することなく、C から直接呼び出すことができます。

もちろん、C ファサードを C++ ライブラリに提供することもできますが、それを行うと、C++ は Java や Python と変わりません。


それが専門的でも特別な良い答えでもないことはわかっていますが、私にとっては単純に C が本当に好きだからです。C は小さくてシンプルで、言語全体を私の脳に収めることができます。あらゆる種類のレイヤーで、私は理解するのに苦労しています。このため、私は C++ を書くときはいつでも、C をコーディングするときよりもはるかに多くの時間をデバッグに費やしたり、ハードサーフェスに頭をぶつけたりすることに時間を費やしています。繰り返しますが、これの多くは主に自分自身の「無知」の結果であることに気付きました。

選択することができれば、インターフェイスやデータベースのやり取りなどのすべての高レベルのものを python (またはおそらく C#) で記述し、高速でなければならないすべてのものを C で記述します。すべてを C++ で書くことは、すべての世界で最悪の事態を迎えているように感じます。

編集: いくつかの C++ 機能を備えた C は、プロジェクトで複数の人が作業する場合、または保守性が優先される場合、ほとんど悪い考えだと思うことを付け加えたいと思います。何が「いくつか」を構成するか、どのビットを C で行うべきか、および最終的に非常に統合失調症的なコードベースにつながる C++ のどのビットを使用するかについて意見の相違があります。


C++ は、低レベルの組み込みシステムなど、実際の環境ではサポートされていません。それには十分な理由があります:C はそのようなことには十分に対応できるのに、なぜより大きなものを使用するのでしょうか?