20

C++ が好きなほとんどの人でさえ、C++ にはシステム/パフォーマンス プログラミング言語としてのニッチとは関係のない欠点がたくさんあることを認めています。これらには、時代遅れのモジュール管理システム (ヘッダー ファイル)、前方宣言の要件、文法を決定不能にする構文の癖 (テンプレート宣言の <> 山括弧など)、実際の言語ではなくテキスト レベルで動作するマクロの組み込みが含まれます。マクロが使用されるものに対処する機能、配列や文字列 (これらの型の STL および C バージョン) などの機能の重複、事実上シンタックス シュガーがないこと、スレッド化、ガベージ コレクション、デリゲート/クロージャなどの最新の機能の一般的な欠如など (注: はい、メモリが非常に制約されている環境やリアルタイム環境では、ガベージ コレクションを望まない正当な理由があるかもしれません。

一方、C++ は、コードを効率的かつ金属に近い形で記述できる唯一の主流言語ですが、少なくともある程度の高レベルの抽象化も提供します。成熟し、標準化されており、大量のコンパイラの実装とライブラリ、および大規模なレガシー コードベースがあります。

C++ をメイン言語として使用している皆さん、C++ の疣贅を我慢する価値があると個人的に判断した理由は何ですか? 考えを変えて、この種の疣贅の少ない新しい言語を使用することを決定するには、何が必要でしょうか? あなたは C++ を本当に気に入っているから使っていますか?それともレガシーの問題やニッチ向けの成熟した主流の言語が他に存在しないためにしぶしぶ使っていますか?

4

23 に答える 23

30

あなたの質問の一部には誤った仮定があります。あなたは私たちが言語の選択肢を持っていると仮定します。私が取り組んでいるC++を使用するすべてのプロジェクトでは、本当の選択はありません。それは私が入社するずっと前から存在していて、C++で書かれたプロジェクトです。彼らには長年の歴史があり、それに対応する量のコードがあります。

これは、「C ++は死ぬ」、「なぜ人々はまだC ++を使用しているのか」と言うときに、人々が犯す最大の間違いだと思います。システムレベルのプログラムを除いて、C++で始まる多くの/新しいプロジェクトが表示されないことに間違いなく同意します。私見、それはあまり意味がありません。必ずしも言語に固有の欠点があるためではありませんが、C++のコーディングが得意な人を見つけるのはますます難しくなっています。

人々がしばしば考慮することを忘れているのは、今日私たちの世界を動かしている何百万(何十億?)のC++ラインです。別の言語への切り替えは非常にコストがかかり、気まぐれで行うことはできません。そのサイズのアプリケーションの書き換えに時間と労力を費やすには、非常に正当な理由があります。これがC++が死なない理由です。少なくともすぐに。

于 2009-03-08T21:50:28.243 に答える
27

次のようなプログラミング言語を教えてください。

  1. 標準化されており、単一の企業によって推進されているわけではありません
  2. 1 つのプラットフォームに縛られない (理論上だけではない)
  3. ネイティブコードにコンパイル
  4. C++と同じ効率が得られます
  5. 非常によく考えられた標準ライブラリを提供します
  6. さまざまな重要なプラットフォームの成熟した実装が少なくとも 1 つある

...そして、切り替えを検討するかもしれません;-)

于 2009-03-08T22:14:08.280 に答える
18

私はC++を使用しています(そして25年近く使用しています)。なぜなら、それは周りで最高のシステムプログラミング言語だからです。私はあなたが説明するいわゆる「いぼ」のどれも認識していないと思います-それらは機能です!

システム以外のプログラミングには、PHP、Delphi、bashスクリプト、awk、perl、Smalltalkなどの他の言語を使用します。もちろん、ある種の言語の大物でない限り、1つのサイズですべてに対応できるわけではありません。

于 2009-03-08T21:51:53.763 に答える
14

これらには、時代遅れのモジュール管理システム (ヘッダー ファイル) が含まれます。

C++ がヘッダー ファイルを使用する方法に問題はありません。ヘッダーを含める 2 つの方法を提供することで、シンボルをアプリケーションから取得するか、システムにインストールされた機能から取得するかをソース レベルで指定できます。最新の C++ コンパイラはすべてプリコンパイル済みヘッダーをサポートしているため、パフォーマンスが低下することはありません。ヘッダーを実装から分離することで、開発者は他の言語でプログラムされたライブラリを使用できます。

文法を決定不能にする構文の癖 (テンプレート宣言の <> 山括弧など)、実質的に構文糖衣がない、

この言語は非常に大きく、完全に従うのは難しい場合がありますが、どこにでも適用される多くの論理規則によって導かれています。この言語は実際に、関数と演算子のオーバーロード、および問題を簡潔に表現できるようにするテンプレートを使用して、使用方法をカスタマイズする多くの方法を提供します。

マクロが使用されるものに対処するために、実際の言語機能の代わりにテキストレベルで動作するマクロを含めること、

プリプロセッサには気に入らない点がたくさんありますが、コード生成の観点から、トークンを操作すると非常に便利です。確かに、M4 マクロのようなものは、これを行うためのはるかに強力な方法を提供しますが、欠点は、それが言語の標準部分ではないことです。標準の c/c++ プリプロセッサは、コンパイラがあるところならどこでも利用できます。

配列や文字列などの機能の複製 (これらの型の STL および C バージョン)

この機能は複製ではありません。低レベルのバイトごとのプリミティブ (ポインター演算を除く) は、汎用コンテナーのような高次の概念を実装するために必要です。C++ は、それが実装されているシステムをプログラミングするためのものであるだけでなく、実際の作業を行うための表現力を提供するためのものでもあることを忘れないでください。

スレッド化、ガベージ コレクション、デリゲート/クロージャなどの最新機能の一般的な欠如。 -out であり、メモリを管理するデフォルトの方法です。)

スレッド化は、プログラミング言語が実際に標準化できない方法で、オペレーティング システムからの協力を必要とするものです。多くの言語はこれを単一のインターフェースに抽象化していますが、これは c++ では起こりませんでした (これは明らかに来ているようです)。ガベージ コレクターは C++ で使用できますが、より強力な概念である RAII を提供します。いずれにせよ、オプトアウトは C++ の方法ではありません。ガベージ コレクション機能が言語に標準化されている場合、それは確実にオプトインであるため、使用していない場合は料金を支払う必要はありません。 .

于 2009-03-08T22:39:37.940 に答える
13

はい、Java よりも C++ の方がずっと好きです。

現時点で真にスケーラブルな唯一の言語である C++ が必要です。プログラムのあらゆる側面を微調整して、勢いが尽きることがないようにする方法があります。

もう 1 つの良い点は、冗長性が "使用" コードではなく、ライブラリ コードに含まれていることです。ライブラリが機能するようになると、使用コードは通常、適切で簡潔になります (ライブラリを適切に作成した場合は、読みやすくなります)。

Java/C# では、冗長性はすべて使用コード (try/catch/finally) にまで引き継がれます。これらすべてを何度も何度も入力する必要があります。くっ…!

スタックベースのオブジェクトについて言及しましたか? 人々はそれらなしでどのように生きますか...??

C++ が実際に失敗する唯一の場所はリフレクションです (ただし、COM のようにそれを実行することもできます)。

確かに、より厳密な構文を備えたクリーンアップされた C++ は素晴らしいことですが、それが決して起こらないことはわかっています。構文に慣れることができ、全体として、得られるものに対して支払う代償はわずかです。

于 2009-03-08T22:04:51.533 に答える
10

システム/パフォーマンスプログラミング言語としてのニッチ

それはかなり大きなニッチです!1,000 万人を超えるユーザーがいるソフトウェアは、C++ で書かれている可能性があります。

  • ウィンドウズ
  • IE
  • フォトショップ
  • ファイアフォックス
  • オフィス
  • SQLサーバー
  • MySQL
  • Google 検索エンジン
  • オートデスク

ソース: http://www.research.att.com/~bs/applications.html

于 2009-03-08T22:41:19.417 に答える
6

私にとっては、次の理由から C++ を好みます。

  • ハードウェアが何をしようとしているのか、または実際のプログラムの動作とパフォーマンスについて知識に基づいた推論を行うことができるほど十分に近いものです。
  • ほとんどのプログラミング パラダイムを使用または実装できるほど柔軟です。
  • 他のライブラリやモジュールとの互換性が高く、既存の最大のサポートベースの参照と直接使用可能なコードがあります。
  • ほとんどの「いぼ」は、優れたプログラミング手法やユーティリティ ライブラリを使用して簡単に取り除くことができます。これは、「いぼ」を修正しにくい他の言語とは対照的です (例: スマート ポインターを使用してメモリ リークを簡単に修正し、メモリを簡単に診断できます)。直接メモリ分析による破損、C#のような高レベル言語でのメモリ破損の問題を簡単にデバッグすることはできません。はい、私はそれらを持っていました)
  • 一般に、C++ アプリは任意の OS バージョンで実行できますが、唯一の制限は労力です。高水準言語は通常、存在する場合も存在しない場合もあるランタイムを必要とします

メインの開発に何か他のものを好むとしたら、何が必要ですか? 上記の理由に何らかの方法で対処することに加えて、他の「高レベル」言語は、C++ で実行できるすべてのことを実装およびデバッグできるという感覚を伝える必要があります。本当に私に近づいた唯一のものは C++/CLI ですが、構文的にさらに悪く、理解するのが難しく、「ランタイムが必要」テストに失敗します (そして、おそらく、他の望ましい利点に関してはあまり追加されません)。

引退するまでの今後 30 年以上の間に、C++ 以外の何かを書くために報酬が支払われると思います。確かに C++ が好ましくない開発分野があり、言語ベンダーが開発者に独自のランタイムやベンダー制御のランタイム (Java、C# など) で実行する高レベル言語を強制する強い動機があります。しかし今のところ、私にとって C++ は依然としてこの仕事に適したツールです。:)

于 2009-03-09T03:05:28.113 に答える
5

C ++ 0x

于 2009-03-08T22:26:09.313 に答える
4

私の意見では、人々はC++が提供するのと同じパワーを何らかの形で提供する高級言語を必要としています。JNIのようなものに頼ることなく、より高速なネイティブバイナリコンパイルやその他の機能を実行しながら、高水準言語(Javaなど)で何かを実行することは、「C++から移行するために必要なこと」です。

于 2009-03-08T21:46:11.920 に答える
4

より少ないメモリでより高速に動作し、より広くサポートされている言語を思いついたとき。

于 2009-03-08T23:59:40.790 に答える
3

あなたが説明したように、C ++には確かに疣贅があり、このC++FQAはそれらの多くを指摘するのに良い仕事をしています。しかし、かなり長い間言語を使用してきた人々や組織は、その言語での作業をより耐えられるものにする多くのイディオム、落とし穴ガイドラインを網羅してきました。C ++でのプログラミングのスタイルも、何年にもわたって進化してきました。ネイティブコンパイルと成熟したツールセットを備えた多くのプラットフォームでは、C++は依然として厳しい競争相手です。

私の意見では、C ++が急速にその地位を失う唯一の方法は、IBMやGoogleのような大手企業が、D言語のような実行可能な代替手段の後ろに立ち、それを全力で推進することです。しかし、独自のコードベースにすでに存在するC ++の量が非常に多いことを考えると、これを実現することは事実上不可能です。

于 2009-03-08T22:29:52.270 に答える
3

率直に言って、それはうまく機能し、私はそれを書くために支払われます. それを制御する単一のベンダーのマーケティングの気まぐれに巻き込まれることはありません。市場に出回っている C++ の専門家はますます少なくなっているため、私の価値は時間の経過とともに高まっています。市場が持続不可能になるまで、私はそれを使い続けます。

于 2009-03-08T22:07:07.987 に答える
3

なぜ C++ が現在のようになっているのかを理解し、その成果を評価する最善の方法は、「C++ の設計と進化」を読むことです。

すべての疣贅について言えば、C++ は非常に優れた言語です。

于 2009-03-08T22:50:00.053 に答える
3

私は主に、通常はハードウェアとの密接なやり取りを多く必要とする組み込みプラットフォームに C++ を使用しています。ここでは、OO 代替は実際には見当たりません。ここで何かをC++に置き換えるとしたら、コンパイル時にすべてのインクルード特典を解決できるものになるので、それらについて心配する必要はありません..基本的に、開発を容易にするものですが、ランタイムを提供しませんでしたオーバーヘッド (リフレクション、ガベージ コレクションなど)。

私にとって C++ は、実行時のパフォーマンスと完全な制御がすべてです。「舞台裏」で機能する派手なランタイムのものはありません。

于 2009-03-08T22:50:30.770 に答える
3

私の GUI は C# で、バックエンドは C++ です。C# がパフォーマンスの点で少なくとも C++ に匹敵する可能性はありますが、C#/insert マネージ言語の焦点がここに集まっているわけではありません。難しいかもしれませんが、IL はマシン コードにコンパイルされるため、C# を C++ と同様に (またはそれに非常に近い) 数値計算で実行することは可能性の範囲内です。もし/その時が来たら、私は喜んで切り替えます。

于 2009-03-08T23:41:08.493 に答える
2

私が個人的にC++を使用することを選択したのは、C ++が解釈されず、比較的迅速に処理できる十分な「ベルとホイッスル」を備えた唯一の多目的プログラミング言語の1つだからです。今では、機会があれば他の言語(Python、Java、Perl、kshなど)を選択する理由がたくさんあります。私は、パフォーマンスが問題ではなく、「フィールド展開可能性」でもない「1回限りの」アプリケーションとスクリプトに他の言語を使用しています。多くのスクリプト言語の展開サポートは非​​常にWeb中心であり、私は現在、より多くのインフラストラクチャと「目に見えない接着剤」業界で働いています。デプロイメントとサポートの懸念を支援するJ2EEアプリケーションサーバーを探していますが、実行可能サービスのためのいくつかの優れた方法がすでにあります。

多くの場合、C ++を選択して使用し続ける最大の理由は、プログラミング言語以外のプラットフォームのもの(スレッド、ソケットなど)を処理するために、選択したいくつかのライブラリを追加した後、必要なほとんどすべてをサポートしていることです。そして...はい...私はスレッドをプログラミング言語の外で表現されるべきものだと考えています。それが私が他の言語から離れる傾向がある主な理由です-私は実際には、アドオンライブラリを介して機能が提供される必要最低限​​のコアを持つ言語が好きです。

プログラミング言語に、構文、継承、ポリモーフィズム、モジュール構造、例外処理、ループ構造などについて心配させてください。アプリケーションドメインに入り、アプリケーションをマルチスレッド化するか、代わりに複数のプロセスを使用する場合は、ライブラリについて話します。言語が多すぎると、すべての問題に適用できるわけではない特定のプログラミングパラダイム(OOP)を強制しようとします。私は素晴らしい汎用プログラミング言語を好みます。

最後の理由は、私が他の言語よりもC ++を選択しているということです。それは、他の言語よりも決定論的であると実際に考えているからです。私は、Javaがプラットフォームに中立なソリューションとして選択され、RubyとPythonがdu'jourの迅速な開発の代替手段であることを知っています。問題は、解釈されるアプリケーションが常にインタプリタの気まぐれで実行されることです。これは必ずしも悪いことではなく、間違いなく良いことでもありません。

C++がもう少し長くここにある可能性があります。私の推測では、より純粋なOOP言語の多くは、より汎用的な動的言語(おそらく、RubyとPython)に市場シェアを失い始め、それらの言語は、より深刻なOOチョップも取得するでしょう。太陽が実際にC++に沈み始めたら、別の言語に切り替えます。「業界」に広く受け入れられている別の言語があります。私はそれがいつか起こると確信しています...結局のところ、C++は実際に数年前に私の選択した言語としてCに取って代わりました。

于 2009-03-09T04:28:05.030 に答える
2

新しい言語が C++ と同じくらい表現力を発揮できるとき。高レベルの機能と低レベルの機能の間の利益相反のため、これを達成するのは困難です。これが、そもそも言語とプロセスの相互運用性を備えている理由です。

さらに、C は非常に無駄がなく強力であるため、C でこれを行うのはおそらく難しいでしょう。このため、C は低レベルのアリーナで勝利します。そして C は、C++ と目的の C を適切にサポートします。

要するに、C と C++ はまだ長い間目にすることになります。

于 2009-03-08T22:10:19.117 に答える
2

C++ は私のツールボックスのツールです。Java や Python なども同様です。

便利なことに、私の会社の環境では、適切なものを何でも使用できます。

  • 必要に応じて C++ == perf。
  • Java == パフォーマンスがそれほど必要ではなく (ネットワーク/外部 IO が CPU サイクルを大幅に上回るため)、開発の速度が必要な場合。

ツールボックスのツール。適切なものを使用してください。

于 2009-03-09T06:24:42.533 に答える
1

なんで?私が別の言語でコードを書き始めたら、あなたは利益を上げる立場にありますか?:-P

冗談はさておき、私はC ++コードを書いています。それが、私の雇用主が私にお金を払っている理由です。とても簡単です。彼らが別の言語を使うことに決めたら、私はそれを使い始めるでしょう。さて、なぜ彼らがそれを使うことを選んだのかについて、私は推測することしかできません。私の推測では、2つの主な理由があります。

  1. C ++が得意で、ビジネス目標を達成できる大学卒業生は十分にいます。
  2. C ++は、リアルタイム分散システムで十分なパフォーマンスを提供します。
于 2009-03-08T21:55:40.680 に答える
1

あなたはこれについて逆に進んでいます。人々は、関心のある問題/アプリケーション ドメインを選択します。言語の選択はその決定に基づいており、非常に簡単です。

プログラミング言語を選ぶ人はいません。プログラミング言語自体は退屈で、問題やアプリケーション ドメインに言及せずにプログラミング言語について話すのはばかげています。

個人的には、機械学習に携わりたいと思っていました。卒業生として。巨大なデータセット (IMDB、Netflix) のグラフ表現の分析に取り組みました。ほとんどの作業で C++ を使用しました。私は C# や Java、あるいはもっと良い Python で作業したいと思っていましたが、問題の性質上、C++ を使用する必要がありました。5 年間にわたり、私は C++ が効率性と抽象化の間で達成する黄金のバランスのために C++ に夢中になりました。必要に応じて C++ を使用します。C++ プログラマーは、物事の遂行を妨げるものを一切許さない、頑固なプラグマティストです。彼らは、ただ単に C++ にしがみつくことはありません。

于 2009-03-09T03:12:12.463 に答える
1

残念なことに、言語の基本的なエレガンスと概念の整合性を発見していません。何年にもわたって継続的に使用されていることからもわかるように、他の言語と同じくらい快適で一貫した世界観を提供します。YMMV ですが、すべて同じように考慮してください。

于 2009-03-08T22:00:31.420 に答える
0

C++ での「問題」のリストを確認すると、問題が STL/C 文字列変換であるということに同意できる唯一の可能性があります。

なぜ C++ を C# にしたいのですか?

于 2009-03-09T06:34:18.203 に答える
0

最近では、プロジェクトの高レベル部分と低レベル部分を同じ言語で記述する必要がない (そして一般的にそうすべきではない) ことは受け入れられていると思います。つまり、複数の言語で働く開発者を見つけるのは難しくても、実際には優れた開発者を見つける方が簡単であることに雇用主が気付くのを待つか、無能な人々が多言語プログラムを手に入れるのを待つかのどちらかです。

于 2009-03-09T05:36:42.180 に答える