質問

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

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

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

役に立ちましたか?

解決

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

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

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

他のヒント

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

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

多くの人が考慮し忘れることが多いのは、今日私たちの世界を走っている数百万行のC ++です。別の言語への切り替えは非常に費用がかかり、気まぐれに行うことはできません。そのサイズのアプリケーションの書き換えに時間と労力を費やすには、大きな正当化が必要です。これが、C ++が死なない理由です。少なくともいつでもすぐに。

C ++は、最高のシステムプログラミング言語であるため、C ++を使用しています(25年近く使用しています)。いわゆる<!> quot; warts <!> quot;を認識していないと思います。あなたが説明する-それらは機能です!

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

  

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

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

  

その文法を決定不能にする構文の癖(<!> lt; <!> gt;テンプレート宣言の山括弧など)、実質的に構文上の砂糖はありません、

この言語は非常に大きく、完全に理解するのが難しい場合がありますが、それでもあらゆる場所に適用されるいくつかの論理的なルールにガイドされています。この言語は実際には、関数と演算子のオーバーロードを通じて、問題の簡潔な表現を可能にするテンプレートを使用して、使用をカスタマイズする多くの方法を提供します

  

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

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

  

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

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

  

およびスレッド、ガベージコレクション、デリゲート/クロージャなどの近代的な機能の一般的な欠如(注:はい、非常にメモリが制限された環境またはリアルタイム環境では、ガベージコレクションを望まない十分な理由があるかもしれませんが、簡単にできますオプトアウトにし、メモリを管理するデフォルトの方法にします。)

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

はい、私はJavaよりもC ++の方がずっと好きです-自分自身を表現するのがはるかに自由だからです。

C ++は、現時点で唯一の真にスケーラブルな言語であるため必要です。プログラムのあらゆる側面を微調整する方法があり、蒸気が尽きることはありません。

もう1つの良い点は、<!> quot; usage <!> quotではなく、冗長性がライブラリコードにあることです。コード。ライブラリが正常に動作すると、通常、使用法のコードは素晴らしく簡潔になります(ライブラリを正しく実行した場合は読みやすくなります)。

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

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

C ++が実際に落ちる唯一の場所はリフレクションにあります(ただし、COMのように並べ替えることもできます)。

はい、より厳密な構文のクリーンアップされたC ++は良いでしょうが、それは決して起こらないことを知っています。構文に慣れることができ、全体として、見返りに得たものに支払うのは少額です。

  

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

これはかなり大きなニッチです! 1つのソフトウェアに1,000万人を超えるユーザーがいる場合、C ++で記述されている可能性があります。

  • Windows
  • IE
  • PhotoShop
  • Firefox
  • オフィス
  • SQL Server
  • MySQL
  • Google検索エンジン
  • AutoDesk

出典: http://www.research.att.com/~bs /applications.html

私にとって、私はC ++を好んでいます。

  • それは、ハードウェアが何をしようとしているかのかなり単純な表現であるか、実際のプログラムの振る舞いとパフォーマンスについての経験に基づいた推論を行うことができるほど近いものです
  • 柔軟性が高いため、ほとんどのプログラミングパラダイムを使用または実装できます
  • 他のライブラリやモジュールとの高い互換性があり、既存の最大の参照ベースおよび直接使用可能なコードをサポートします
  • ほとんどの<!> quot;いぼ<!> quot; <!> quot; warts <!> quot;である他の言語とは対照的に、優れたプログラミングプラクティスやユーティリティライブラリを使用すると簡単に削除できます。あまり修正できない(たとえば、スマートポインターを使用してメモリリークを簡単に修正でき、直接メモリ分析でメモリ破損を簡単に診断できます。C#などの高レベル言語でメモリ破損の問題を簡単にデバッグすることはできません。
  • C ++アプリは一般に、OSバージョンで実行するようにできますが、唯一の制限は労力です。高レベルの言語は通常、存在する場合と存在しない場合があるランタイムを必要とします

主な開発のために他の何かを好むには、何が必要ですか?さて、何らかの理由で上記の理由に対処することに加えて、他の<!> quot; higher-level <!> quot;言語は、私がC ++でできることをすべて実装してデバッグできるという気持ちを伝えなければなりません。本当に私に近づいた唯一のものはC ++ / CLIですが、それは構文的にさらに悪く、理解するのが難しく、<!> quot; runtime required <!> quot;に失敗します。テストします(そして、おそらく、他の望ましい利点に関してはあまり追加しません)。

引退する前の30年以上後に、C ++以外の何かを書くための報酬が支払われると思います。確かに、C ++が好ましくない開発分野があり、言語ベンダーが開発者にプロプライエタリおよび/またはベンダー制御のランタイム(Java、C#など)で実行される高レベル言語を強制する強い動機があります。しかし、今のところ、私にとっては、C ++が仕事に適したツールであり、執筆を続けることで報酬を得ることを楽しんでいます。 :)

私の意見では、C ++が提供するのと同じパワーを提供するような高レベルの言語が人々には必要だと思います。 JNIのようなものに頼らずに、より高速、ネイティブバイナリコンパイル、およびその他の機能を実行しながら、高レベル言語(Javaなど)で何かをするのは<!> quot; C ++ <! > quot;。

より少ないメモリでより高速に実行され、より広くサポートされる言語を思いついた場合。

率直に言って、それはうまく機能し、私はそれを書いてお金を払っています。それを制御する単一のベンダーのマーケティングの気まぐれに絡まっていない。市場に出回っているC ++エキスパートの数は少なく、少ないため、私の価値は時間とともに増加しています。市場が持続不可能になるまで使用し続けます。

あなたが説明したように、C ++には確かにイボがあり、この C ++ FQA はうまく機能しています。それらの多くを指摘する仕事。ただし、かなり以前から言語を使用している人々や組織は、多数のイディオムを網羅しています。 、gotchas およびガイドラインにより、より多くの作業を行うことができます耐えられる。 C ++のプログラミングスタイルには、長年にわたって進化しました。ネイティブコンパイルと成熟したツールセットにより、多くのプラットフォームで、C ++は依然として難しい候補です。

C ++が急速にその位置を失う唯一の方法は、私の意見では、IBMやGoogleのような大手企業が D言語を使用して、力を尽くしてプッシュします。しかし、独自のコードベースに既に存在するC ++の膨大な量を考えると、これは実際には不可能です。

C ++の現状を理解し、その成果を理解するための最良の方法は、<!> quot; The Design and Evolution of C ++ <!> quot;を読むことです。

すべてのいぼでは、C ++は非常に優れた言語です。

私は主に、ハードウェアとの多くの密接な相互作用を通常必要とする組み込みプラットフォームにC ++を使用します。ここにはオブジェクト指向の代替は実際にはありません。ここで何かをC ++に置き換えれば、コンパイル時にすべてのinclude-perksを解決できるので、それらについて心配する必要はありません。オーバーヘッド(リフレクション、ガベージコレクションなど)。

私にとって、C ++とは実行時のパフォーマンスと絶対的な制御に関するものです。 <!> quot; behind-the-the-scenes <!> quot;。

で動作する、ファンシーで豪華なランタイム機能はありません。

科学計算を行います。GUIはC#で、バックエンドはC ++です。 C#がパフォーマンスの点で少なくともC ++に匹敵する可能性の領域ではありませんが、C#/挿入マネージ言語の焦点がここでグループ化されるわけではありません。 ILはマシンコードにコンパイルされるため、数値計算でC#(またはそれに非常に近い)を実行する可能性の範囲内で困難になります。その場合は、喜んで切り替えます。

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

Cに加えて、これはおそらくCで行うのが難しいでしょう。なぜなら、とても無駄がなく強力だからです。このため、Cは低レベルアリーナで勝ちます。また、CはC ++と客観的なCの適切な裏付けを作成します。

一言で言えば、あなたはまだCとC ++を長い間見ています。

私が C++ を使用するという個人的な選択 (選択肢がある場合) は、C++ が解釈されない唯一の多目的プログラミング言語の 1 つであり、比較的迅速に作業を完了するのに十分な「付加機能」を備えているためです。機会があれば他の言語 (Python、Java、Perl、ksh など) を選択する理由はたくさんあります。私は、パフォーマンスが問題にならず、「現場での導入可能性」も問題にならない「一回限りの」アプリケーションやスクリプトに他の言語を使用します。多くのスクリプト言語の展開サポートは非​​常に Web 中心であり、私は現在、インフラストラクチャと「目に見えない接着剤」業界に多く携わっています。私たちは、展開とサポートの問題を解決してくれる J2EE アプリケーション サーバーを探していますが、実行可能なサービスのための優れた方法がすでにいくつかあります。

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

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

私が他の言語ではなく C++ を選択する最後の理由は、実際には C++ が他の言語よりも決定論的であると考えているからです。Java が プラットフォームニュートラル 最適なソリューション、Ruby と Python は、 急速な発展 代替案。問題は、インタプリタされるアプリケーションが常にインタプリタの気まぐれに応じて実行されることです。これは必ずしも悪いことではありませんし、必ずしも良いことでもありません。

おそらく C++ はもう少し長く存在し続けるでしょう。私の推測では、より純粋な OOP 言語の多くが、より汎用的な動的言語 (おそらく Ruby と Python) に市場シェアを失い始め、それらの言語もより深刻な OO の切り口をいくつか拾うだろうということです。C++ に本格的に日が傾き始め、「業界」に広く受け入れられている別の言語が存在するようになったら、私は別の言語に切り替えるつもりです。きっといつかそうなるだろう…結局のところ、何年も前に実際に C++ が私の選択言語として C に代わったのです。

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

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

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

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

なぜですか?別の言語でコードを書き始めた場合、あなたは利益を上げることができますか? :-P

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

  1. 大学には十分な供給がある で十分な卒業生 彼らが達成できるC ++ ビジネス目標。
  2. C ++は goodを提供します     リアルタイムで十分なパフォーマンス     分散システム。

残念ながら、この言語の基本的な優雅さと概念的な整合性を発見できていません。長年の継続的な使用に反映されているように、他の言語と同じくらい快適で一貫した世界観を提供します。 YMMV、ただし同じことを考慮してください。

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

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

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

最近、プロジェクトの高レベル部分と低レベル部分を同じ言語で書く必要はない(そして一般的にそうすべきではない)と認められていると思います。したがって、雇用主が複数の言語で作業する開発者を見つけるのは難しいが、実際には良い開発者を見つけるのは簡単であることを認識するのを待つか、ポリグロットプログラムで取得する無能な軍隊。

<!> quot;問題<!> quot;のリストの確認。 C ++の場合、私が同意しそうなのは、問題がSTL / C文字列の変換だけだということです。

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

ライセンス: CC-BY-SA帰属
所属していません StackOverflow
scroll top