C、Perl、Pythonなどの代わりにC ++を使用する理由はありますか？
Linux（サーバー側）開発者として、どこで、なぜC++を使用する必要があるのかわかりません。
私がパフォーマンスに行くとき、最初と最後の選択肢はCです。
「パフォーマンス」が主な問題ではない場合、PerlやPythonなどのプログラミング言語が適切な選択肢となります。
この分野で私が知っているほとんどすべてのオープンソースアプリケーションは、C、Perl、Python、Bashスクリプト、 [〜＃〜] awk [〜＃〜] またはPHPで書かれていますが、誰もC++を使用していません。
GUIやWebアプリケーションのような他の領域については話していません。ただLinux、CLI、デーモンについて話しているだけです。
C++を使用する十分な理由はありますか？
パフォーマンスに行くとき、最初と最後の選択肢はCです。
そして、それがバックアップの必要な場所です。さて、私はまったくサーバー開発について話すことはできません。おそらく、代替案よりもC++を好む説得力のある理由はないでしょう。
しかし、一般的に言えば、他の言語ではなくC++を使用する理由は確かにパフォーマンスです。その理由は、C++が抽象化の手段を提供するためです。これはall私が知っている他の言語とは異なり、実行時のパフォーマンスオーバーヘッドnoです。
これにより、stillが非常に高い抽象化レベルを持つ非常に効率的なコードを記述できます。
通常の抽象化を検討してください：仮想関数、関数ポインター、およびPIMPLイディオム。これらはすべて、実行時にポインター演算によって解決される間接指定に依存しています。言い換えれば、パフォーマンスコストが発生します（ただし、それがわずかであっても）。
一方、C++はno（パフォーマンス）コストが発生する間接メカニズムを提供します：テンプレート。 （この利点は、コンパイル時間が（場合によっては）大幅に増加することで支払われます。）
一般的なソート関数の例を考えてみましょう。
Cでは、関数qsortは、要素が互いに相対的に順序付けされるロジックを実装する関数ポインターを受け取ります。 JavaのArrays.sort関数にはいくつかのバリエーションがあります。それらの1つは任意のオブジェクトをソートし、CのComparatorの関数ポインターのように機能するqsortオブジェクトを渡す必要があります。しかし、「ネイティブ」Java=タイプのオーバーロードはさらにいくつかあります。そして、それらのそれぞれにsortメソッドの独自のコピーがあります。これは恐ろしいコードの重複です。
Javaはここで一般的な二分法を示しています：コードが重複しているか、実行時にオーバーヘッドが発生します。
C++では、sort関数はCのqsortとほとんど同じように機能しますが、1つの小さな基本的な違いがあります。関数に渡されるコンパレーターはtemplateパラメーターです。つまり、その呼び出しはインライン化となる可能性があります。 2つのオブジェクトを比較するために間接指定は必要ありません。タイトなループでは（ここにあるように）、これは実際に大きな違いを生む可能性があります。
当然のことながら、C++のsort関数は、基盤となるアルゴリズムが同じであっても、Cのsortよりも優れています。これは、実際の比較ロジックが安価な場合に特に顕著です。
今、私はnot C++がC（または他の言語）よりもアプリオリにより効率的であり、アプリオリがより高い抽象化を提供すると言っています。それが提供するものは、非常に高く、同時に信じられないほど安価である抽象化であり、効率的なコードと再利用可能なコードのどちらかを選択する必要がないことがよくあります。
C++を嫌うCプログラマーが多すぎると思います。何がいいのか、何が悪いのかをゆっくりと理解するのにかなりの時間がかかりました。私はそれを表現する最良の方法はこれだと思います：
コードが少なく、実行時のオーバーヘッドがなく、より安全です。
私たちが書くコードが少なければ少ないほど良いです。これは、卓越性を追求するすべてのエンジニアですぐに明らかになります。バグを1か所で修正し、多くはしない-アルゴリズムを1回表現して、それを多くの場所で再利用するなど。ギリシャ人は、古代のスパルタ人にさかのぼる格言さえ持っています。あなたがそれについて賢明であること」問題は、正しく使用すると、C++ではランタイム速度を犠牲にすることなく、Cよりもはるかに少ないコードで自分を表現できることです。 Cよりも安全であること（つまり、コンパイル時により多くのエラーをキャッチすること）。
これが私の renderer からの簡略化された例です：三角形のスキャンライン全体にピクセル値を補間する場合。 X座標x1から始め、X座標x2（三角形の左側から右側）に到達する必要があります。そして、各ステップで、渡した各ピクセルで、値を補間する必要があります。
ピクセルに到達する環境光を補間すると、次のようになります。
_ typedef struct tagPixelDataAmbient {
int x;
float ambientLight;
} PixelDataAmbient;
...
// inner loop
currentPixel.ambientLight += dv;
_色を補間すると（「グーロー」シェーディングと呼ばれ、「赤」、「緑」、「青」のフィールドは各ピクセルのステップ値によって補間されます）：
_ typedef struct tagPixelDataGouraud {
int x;
float red;
float green;
float blue; // The RGB color interpolated per pixel
} PixelDataGouraud;
...
// inner loop
currentPixel.red += dred;
currentPixel.green += dgreen;
currentPixel.blue += dblue;
_「フォン」シェーディングでレンダリングするとき、強度（ambientLight）またはカラー（赤/緑/青）を補間しなくなりました-法線ベクトル（nx、ny、nz）を補間し、各ステップで、 -補間された法線ベクトルに基づいて、照明方程式を計算します。
_ typedef struct tagPixelDataPhong {
int x;
float nX;
float nY;
float nZ; // The normal vector interpolated per pixel
} PixelDataPhong;
...
// inner loop
currentPixel.nX += dx;
currentPixel.nY += dy;
currentPixel.nZ += dz;
_さて、Cプログラマの最初の本能は、「一体、値を補間する3つの関数を記述し、設定モードに応じてそれらを呼び出す」ことです。まず第一に、これはタイプの問題があることを意味します-私は何を処理しますか？私のピクセルはPixelDataAmbientですか？ PixelDataGouraud？ PixelDataPhong？ああ、待って、効率的なCプログラマーは、共用体を使用すると言います！
_ typedef union tagSuperPixel {
PixelDataAmbient a;
PixelDataGouraud g;
PixelDataPhong p;
} SuperPixel;
_..そして、あなたは機能を持っています...
_ RasterizeTriangleScanline(
enum mode, // { ambient, gouraud, phong }
SuperPixel left,
SuperPixel right)
{
int i,j;
if (mode == ambient) {
// handle pixels as ambient...
int steps = right.a.x - left.a.x;
float dv = (right.a.ambientLight - left.a.ambientLight)/steps;
float currentIntensity = left.a.ambientLight;
for (i=left.a.x; i<right.a.x; i++) {
WorkOnPixelAmbient(i, dv);
currentIntensity+=dv;
}
} else if (mode == gouraud) {
// handle pixels as gouraud...
int steps = right.g.x - left.g.x;
float dred = (right.g.red - left.g.red)/steps;
float dgreen = (right.g.green - left.a.green)/steps;
float dblue = (right.g.blue - left.g.blue)/steps;
float currentRed = left.g.red;
float currentGreen = left.g.green;
float currentBlue = left.g.blue;
for (j=left.g.x; i<right.g.x; j++) {
WorkOnPixelGouraud(j, currentRed, currentBlue, currentGreen);
currentRed+=dred;
currentGreen+=dgreen;
currentBlue+=dblue;
}
...
_混乱が入り込んでいますか？
まず、コードのクラッシュに必要なのは1つのタイプミスだけです。コンパイラーは、関数の「グーロー」セクションで「.a」に実際にアクセスするのを止めることはないためです。 （環境）値。 Cタイプシステム（つまり、コンパイル中）で捕捉されないバグは、実行時に明らかになり、デバッグが必要なバグを意味します。 「dgreen」の計算で_left.a.green_にアクセスしていることに気づきましたか？コンパイラは確かにそう言っていませんでした。
次に、至る所に繰り返しがあります-forループは、レンダリングモードの数だけ存在します。「右マイナス左をステップで割った」ことを繰り返します。醜く、エラーが発生しやすい。 「j」を使用するべきだったときに、グーローループで「i」を使用して比較していることに気づきましたか？コンパイラは再び、沈黙しています。
モードのif/else /はしごはどうですか？ 3週間後に新しいレンダリングモードを追加するとどうなりますか？すべてのコードのすべての "if mode =="で新しいモードを処理することを覚えていますか？
次に、上記の醜さを、このC++構造体のセットとテンプレート関数と比較します。
_ struct CommonPixelData {
int x;
};
struct AmbientPixelData : CommonPixelData {
float ambientLight;
};
struct GouraudPixelData : CommonPixelData {
float red;
float green;
float blue; // The RGB color interpolated per pixel
};
struct PhongPixelData : CommonPixelData {
float nX;
float nY;
float nZ; // The normal vector interpolated per pixel
};
template <class PixelData>
RasterizeTriangleScanline(
PixelData left,
PixelData right)
{
PixelData interpolated = left;
PixelData step = right;
step -= left;
step /= int(right.x - left.x); // divide by pixel span
for(int i=left.x; i<right.x; i++) {
WorkOnPixel<PixelData>(interpolated);
interpolated += step;
}
}
_これを見てください。ユニオンタイプスープを作成しなくなりました。モードごとに特定のタイプがあります。彼らは、基本クラス（CommonPixelData）から継承することにより、共通のもの（「x」フィールド）を再利用します。また、テンプレートにより、コンパイラーはCで独自に作成した3つの異なる関数をCREATE（つまり、コード生成）しますが、同時に型について非常に厳密です！
テンプレート内のループは無効になり、無効なフィールドにアクセスできません-実行するとコンパイラーが吠えます。
テンプレートは一般的な作業（ループ、毎回「ステップ」ずつ増加するループ）を実行し、実行時エラーが発生しないようにすることができます。タイプごとの補間（AmbientPixelData、GouraudPixelData、PhongPixelData）は、構造体に追加するoperator+=()を使用して行われます-これは基本的にhow各タイプが補間されます。
そして、WorkOnPixel <T>で私たちが何をしたかわかりますか？タイプごとに異なる作業を行いたいですか？私たちは単にテンプレート特殊化と呼びます：
_void WorkOnPixel<AmbientPixelData>(AmbientPixelData& p)
{
// use the p.ambientLight field
}
void WorkOnPixel<GouraudPixelData>(GouraudPixelData& p)
{
// use the p.red/green/blue fields
}
_つまり、呼び出す関数は、タイプに基づいて決定されます。コンパイル時に！
もう一度言い換えると：
- （テンプレートを介して）コードを最小化し、共通のパーツを再利用し、
- 醜いハックは使用せず、厳密な型システムを維持するため、コンパイラーはいつでもチェックできます。
- 何よりも、実行時の影響はありません。このコードは同等のCコードと同じくらい速く実行されます-実際、Cコードが関数ポインターを使用してさまざまな
WorkOnPixelバージョンを呼び出す場合、コンパイラーはインライン化されるため、C++コードはCよりも高速になりますタイプ固有のWorkOnPixelテンプレート特殊化呼び出し！
コードが少なく、実行時のオーバーヘッドがなく、より安全です。
これは、C++がすべての言語であり、すべての言語であるということですか？もちろん違います。あなたはまだトレードオフを測定する必要があります。無知な人は、Bash/Perl/Pythonスクリプトを作成する必要があるときにC++を使用します。トリガーハッピーなC++初心者は、停止してパッキングを送信する前に、仮想多重継承を持つ深いネストされたクラスを作成します。彼らは、これが必要でないことを理解する前に、複雑な Boost メタプログラミングを使用します。それらは、_char*_およびテンプレートの代わりに、_std::string_、strcmpおよびマクロを引き続き使用します。
しかし、これは何を言っているにすぎません...無能なユーザーからあなたを守る言葉はありません（Javaでさえも）。
C++の学習と使用を続けてください-設計しすぎないでください。
[〜＃〜] raii [〜＃〜] 勝利の赤ちゃん。
真剣に、C++の確定的破壊は、コードをより明確かつ安全にし、オーバーヘッドは一切ありません。
C++を使用する満足のいく理由はありますか？
テンプレートとSTL。 lotの有用な抽象化および省力化ツールと少しのビルド時間（および一部の理解できないエラーメッセージ）を交換しますが、実行時のパフォーマンスに大きな影響はありません（ただし、バイナリフットプリントは少し少ないかもしれません）大きい）。
頭をぐるぐるするのにはしばらく時間がかかります（クリックされるまでに数年かかりました）が、一度やれば、人生はlot単純になります。
C++でのテキスト処理は桁違い Cの場合よりも簡単です。
はい
実行可能な効率を探しているなら、CまたはC++にいるので、私はそれに焦点を当てます。
テンプレートが一般的になる前でさえ、2つの非常に単純な理由のために、1990年代中頃に議論した実行可能ファイルの種類には、CではなくC++を使用することを好んだ： object polymorphism および [〜＃〜] raii [〜＃〜] 。
私は、あらゆる種類の興味深いことに、ポリモーフィックC++オブジェクトを使用しました。たとえば、OMAPとXScale ARM CPUのフレームバッファーオーバーレイを備えた組み込みLinuxシステムで作業していました。2つのハードウェアアーキテクチャには、非常に異なるAPIを備えた異なるオーバーレイ機能があります。共通の仮想オーバーレイの理想的なビューを公開するための「オーバーレイ」基本クラス。次に、実行時にコードが検出したアーキテクチャに応じて、実行時に適切にインスタンス化される「OmapOverlay」および「XScaleOverlay」クラスを記述しました。
単純化しすぎると、RAIIは、オブジェクトのコンストラクターの間、またはおそらくオブジェクトの存続期間中にオブジェクトに接続されたリソースを割り当て、リソースがオブジェクトのデストラクタで割り当て解除または解放されるという考え方です。自動変数であるオブジェクトはスコープ外になると破棄されるため、C++ではこれは本当にすばらしいことです。 CとC++で同等の能力を持っている人にとっては、C++でリソースとメモリリークを回避する方がはるかに簡単です。また、関数ブロックのfree()への一連の呼び出しの前に、ラベルの非常に一般的なCのミームが付いたC++コード、および関数ブロック内のさまざまなgotoが含まれるC++コードは多くありません。そこにジャンプします。
私はCでこれらすべてのことを実行できることを十分に認識しています。これは、より多くの作業、より多くのコード行であり、何を使いこなすかは非常に醜く、多くの場合理解が困難です。 Xサーバー の内部、および人間全体にポリモーフィズムコードがありますが、それはあいまいで奇妙で、頻繁に追跡するのが困難です。
また、GTK +やClutterなどのGNOMEテクノロジを使用して多くの作業を行っています。これらはすべて、GObjectシステムを使用してCで記述されています。 GObjectはC++オブジェクトシステムのようなもので、Niceカバーが取り外され、すべての醜い内部が公開されています。通常、1行のC++メソッド呼び出しで行うことを実行するには、何十行ものコードが必要です。私は現在いくつかのClutterActorsを書いており、その数学は本当に興味深いものですが、「これはC++ではもっと簡潔で理解しやすいものになるでしょう」と常に考えています。
私はよく、「CではなくC++でこれを書いていると、リビングルームで外出していて MythBusters 午後9時に自分のオフィスに座っているのではなく、妻と一緒にいるでしょう。 」
C++はCとほぼ同じ速さで（一部は高速で、一部は低速）、抽象化と編成が向上しています。クラスはプリミティブ型と同様に機能するため、気にせずに大量のコードを使用できます。演算子のオーバーロードとテンプレートにより、データ表現が変更された場合により適切に機能するコードを作成できます。例外により、エラー処理が容易になります。コンパイラは、コンパイル時により多くのものをチェックするために使用できます。
あなたがこれに支払う価格はかなり厄介な学習曲線であり、私がよく知っている他のほとんどの言語よりも微妙な間違いを犯しやすいです。
ですから、あなたが今やっていることのためにそれを学ぶ価値があるかどうかはわかりません。確かにPythonまたはPerlとCの組み合わせで問題はありませんが、C++は抽象化とパフォーマンスの両方を1つの使いにくいパッケージで提供します。
私はC++を1990年代の言語、過ぎ去った時代の言語と見なしています。
当時はパフォーマンスの面で低コストで高水準の言語構造とメカニズムを提供していたため、それは大きなものでした。これは、アドレス帳アプリケーションからアビオニクスソフトウェアまですべてを開発するための普遍的なツールであり、OOクレーズ。OOP飢餓とエイズの解決、そしてそうです。私が最初にプログラミングを始めた1990年代後半に、OO以外の言語は学ぶ価値がないと私に洗脳を試みたのはC++のせいです。
ハードウェアが非常に進歩し、新しい現代の言語が登場した今、C++がほとんどのアプリケーションプログラミングに関連する選択肢であるとは思えません。ただし、抽象化が必要な計算集約型ソフトウェア（ゲーム、物理シミュレーション、CADシステムなど）。Cでコンパクトなモジュール式エンジンを記述し、高水準のアプリケーションロジックをきちんとしたスクリプト言語に委任すれば、後者も回避できます。
メタルにダウンする必要がある場合、まともなCを使用し、高レベルにする必要がある場合は、カプセル化をアドバタイズしない最新の言語で行いますが、ポインタを介して各バイトを自由に変更できます。
Linusによると 、いいえ：
最初にGitのソースコードを調べたとき、2つのことを奇妙に感じました。1。C++ではなく純粋なC。なぜだかわかりません。移植性については話さないでください。それはBSです。
[〜＃〜]あなた[〜＃〜]はでたらめでいっぱいです。
C++は恐ろしい言語です。多くの標準以下のプログラマーがそれを使用するという事実により、それはより恐ろしくなります。率直に言って、Cの選択が何もしないがC++プログラマーを除外する場合でも、それ自体がCを使用する大きな理由になります。
言い換えれば、Cの選択が唯一の健全な選択です。 Miles Baderが冗談で「あなたを怒らせる」と言ったのを知っていますが、それは本当です。私は、プロジェクトをCではなくC++にすることを好むすべてのプログラマーが、私が本当に望んでいるプログラマーを怒らせることを好むという結論に達しました彼が来て、私が関わっているプロジェクトを台無しにしないように。
C++は本当に悪いデザインの選択につながります。あなたは常に、STLやBoostなどの言語の「ナイス」なライブラリ機能の使用を開始します。これは、プログラムを「助ける」かもしれませんが、以下を引き起こします。
彼らが機能しないときの無制限の痛み（そしてSTL、特にBoostは安定していてポータブルであるとBSに満ちているので面白くないと私に言う人）
非効率的な抽象化プログラミングモデルでは、2年後には一部の抽象化があまり効率的ではないことに気付きましたが、すべてのコードはその周囲のすべてのNiceオブジェクトモデルに依存しているため、アプリを書き直さなければ修正できません。
言い換えると、システムレベルで移植性の高い、優れた効率的なポータブルC++を実行する唯一の方法は、Cで基本的に利用できるすべてのものに自分自身を制限することになります。つまり、実際に低レベルの問題を理解し、ばかげた「オブジェクトモデル」のがらくたを台無しにしない多くのプログラマーを得るということです。
申し訳ありませんが、効率性が主な目的であるgitなどの場合、C++の「利点」は大きな間違いです。それを見ることができない人たちにも腹を立てているという事実は、単なる大きな追加の利点です。
C++で記述されたVCSが必要な場合は、Monotoneで遊んでください。本当に。彼らは「実際のデータベース」を使用します。彼らは「素敵なオブジェクト指向ライブラリ」を使用しています。 「Nice C++ abstractions」を使用しています。そして率直に言って、一部のCS担当者にとって非常に魅力的に聞こえるこれらすべての設計決定の結果として、最終結果は恐ろしくて維持不可能な混乱になります。
しかし、きっとあなたはそれがgitよりも好きになると確信しています。
Linus
C++を使用する説得力のある理由はないと思います。 OOプログラミングを行う場合は、代わりにPythonを使用して、Cで高速なパフォーマンスが必要な部分を記述できます。
編集：Cとうまく連動する他の言語があるので、Pythonが気に入らない場合は、代替手段があります。
C++を使用する理由はありますか？もちろん。
一部の人々単に好むかもしれません他のオプションよりもC++を使用しています。 C++を使用する理由があるかどうかを尋ねるのは、何百ものフレーバーのアイスクリームが必要な理由を尋ねるようなものです。誰もがバニラにこだわるのが好きというわけではありません。
開発者がすでにC++に精通している場合、開発者にとっての質問は、「なぜそれを使用するのか」ではなく、「なぜ使用しないのか」です。 SO現在、この流行の反C++のことが起こっているようですが、信じられないかもしれませんが、誰もがそれに同意しているわけではありません。他の言語よりもC++を好む人もいます。
アプリにC++を使用する必要がありますか？もちろん違います。しかし、これとまったく同じ質問は、他の言語でも尋ねることができます。アプリケーションで特定の言語を使用する必要があるケースはごくわずかです。
私はCからC++に切り替えているだけです。テンプレートやOOPが必要ない場合でも、かなりの効果が得られると思います。
- より良いメモリ管理
- より強力な型システム
- より良い標準ライブラリ
- 名前空間
- 等.
まだ誰もこれについて言及していないことに驚いていますが、C++が references を紹介してくれたため、ポインタの問題と落とし穴のほとんどすべてを解決できます。
void ModifyVar(int& var)
{
var = 5;
}
int test = 4;
ModifyVar(test);
の代わりに：
void ModifyVar(int * var)
{
*var = 5;
}
int test = 4;
ModifyVar(&test);
はるかに安全で簡単です...そして、値渡しのオーバーヘッドがありません。
どこに、なぜそうなるのか：
- 親しみやすさ
- 必要な言語機能
- 使用したい特定のライブラリ
- 性能要件
サーバー側プログラミングでは、コンパイルまたは解釈された無数の異なる言語から選択できます。通常、言語の選択は、あなたまたはあなたのチームが最も効果的なプラットフォームによって決まります。または、まだチームがない場合は、市場でのスキルの可用性。
余談ですが、多くのスクリプト言語はC/C++で拡張可能であるため、パフォーマンス（のみ）に基づいてC/C++を使用することを決定することは本当にわかりません。遅い部分をC/C++拡張機能に移行する機能と相まって、迅速な開発言語の利点が得られます。確かに、すべての操作がカウントされるシステムプログラミングを行っている場合は理解できますが、ほとんどのアプリ開発では理解できません。
C++ vs Python vs Perlは簡単には判断できません。プロジェクトと要件によって異なります。
C++には、多くのプラットフォームで実行されている、古くからのユーティリティが集められています。しかし、StringをIntegerに渡し、その逆を行うためだけにストリームをウォークし始めるのは困難です。
一方、C++は、ライブラリへの依存関係にひどい取り決めをしています。 GCC XまたはVC++ Yで何かをコンパイルすると、それらのツールの次のバージョンでコードが実行されるとは限りません。同じ地獄がWindowsにもあり、同じ地獄がUnixにもあります。
Perlは、Unixの世界から力を得ていますが、特に正規表現ツールとして使用されています。これは、ほとんどの場合に使用されます。 Javaでも通常の方法では実行できないかなり深刻なツール（ファイルをWebサーバーにアップロードする方法を確認してください））に加えて、Perlは「実行するだけ」です。
Pythonは簡単で柔軟性があり、動的言語です。関数に整数を送信できるほど簡単で、スクリプトは文字列を期待しますが、結果を得ることができます！予想外ですが、結果。したがって、プログラマーは非常に注意深くなる必要があります。 [〜＃〜] idle [〜＃〜] はデバッグを提供しますが、システムにTELNETしたり、3レベル下にSSHしたりして問題を見つけたい場合は、デバッガはあなたの隣に立つことはありません。しかし、それはいくつかの素晴らしい数学の仕事を速くすることができます。
Javaは流行語、エイリアンテクノロジー、ビッグワードのエコシステムであり、ファイルをWebサーバーにアップロードするだけの場合、サーバーに [〜＃〜] jsp [〜＃ 〜] 。監視などのシステムライブラリまたはシステム関数を呼び出す場合は、多くのことを掘り下げる必要があることがわかります。そしておそらく [〜＃〜] jni [〜＃〜] に到達するために、そしてOK ...あなたはそのとき考えます...「なぜ、主ですか？」
それとは別に、Javaはビジネススイートやマルチスレッドに最適なツールです。とても気に入っています。
プログラムを作成し、CVに「ああ、私もそのテクノロジーを知っています」と、あなたのボスになりたいと思っている人を驚かせましょう。とはいえ、テクノロジーはそれほど必要ではないかもしれません...（OK、皆さん、私は嫌いです Spring Framework ....）
言語を選択する際に覚えておくべきことは、言語を使用することで得られるメリットと、言語を取得するのにかかる時間です。
pythonなどの言語とPerlの間の主なアイデアは、より少ない時間でより多くの処理を実行することですが、CPU時間は長くなります。実際、pythonまたはPerlスクリプトを実行するよりもコーディングに多くの時間を費やすことになりますが、あなたの言うとおりです。
C/C++の利点は、高速であることですが、構文と強力なタイピングが犠牲になります。コンパイル時にコンピューターが選択しなくて済むように、多くのことを自分で行う必要があります。
コードを作成すると、一部の行は他の行よりも多く実行され、それらの行は問題を引き起こす行です。一方、残りのコード、つまり多くの時間を費やしたコードは、実行頻度がはるかに低くなります。聞いたことがあるかもしれませんが、それは悪名高い80/20ルールであり、そのようなルールを回避することはできません。
この問題の解決策は、すべてのコードを実行するために、より簡単な言語を使用することです（簡単に言うと、開発者にとってより使いやすい：タイピングが少なく、遅延解釈、多くの既存のルーチンなど）。
CまたはC++で実行する場合と比較して、非常に迅速に実行できます。
プログラムは遅くなりますが、プロファイラーを使用して、80％の時間実行された部分を分離し、CまたはC++で実行します。
この方法でプログラムすることで、多くの時間を節約でき、プログラムは同じくらい効率的であり、非常に速く、メモリリークの可能性がはるかに少なく、時間を節約できます。
スクリプト言語は開発者の側にあるように設計されましたが、最適化はまだ可能です。もちろん、デザインパターンのマジシャン、STLブードゥー、さらにはLISPの戦士、そしておそらくhaskellの僧侶になることができます。しかし、言語は私たちにコンピューターとの会話をさせます、言語は私たちがコンピューターになるために作られていません！
私が使用するC++は、クラスでCと呼ばれます。
いいえ、まったくありません。パフォーマンスが必要なく、他の言語を使用できるライブラリがある場合は、C/C++を気にしないでください。言語を（簡単に）実行できない組み込みシステムを対象とするときだけ、私は今日それをします。プラグインを作成しているためCを使用することもありますが、実際はそうではありません。
ただし、Cの使用を避けるためにPython、Perlなどは使用しません。良いライブラリ（.NETの長所）が好きで、静的に型付けされた言語が好きなので、私の好みは実際にはC＃です。 ブー は良い選択肢です。しかし、実際には Haskell 、 OCaml 、 [〜＃〜] d [〜＃〜] 、 [〜＃〜] ml [ 〜＃〜] などはすべて問題ありません。
このように形成されたすべての質問に対して、実際には単一の回答があります。技術Yの代わりに技術Xを使用する最良の理由（XとYは（ほぼすべての現代のプログラミング言語がそうであるように）同じレベルにあります）は、すでにXを知っていて、Yを知らないためです。
（しかし、Haskellが到着した後は、他に何かを使用する理由はありません）