自明であるリスクを承知で言っておきますが、心に留めておくべき主なことは、壊れていないものを修正しないことです。
動作中の C ライブラリがあり、より「C++ 風」なインターフェイスが必要な場合は、変換するよりもクラスにラップする方が賢明な場合があります。確かに、これは DLL フレンドリーな C インターフェイスを提供するという要件を満たしています。
Cプログラマーとして、C++プログラマーがCをC++に「移植」しようとすると面倒だと思います。C ++言語構造を使用することには多くの利点がありますが、Cの単純な関数指向のアプローチを常に改善するとは限りません。を介してC機能をいつでも利用できるextern "C"ため、動作するコードを変更する理由はほとんどありません。私が取り組んできたプロジェクトでは、Cコードの周りにオブジェクトラッパーを作成することはうまくいきました。そうすれば、コアコードをどちらの言語で作業しているチーム間でも共有でき、誰もが自分の環境に合ったインターフェイスを使用できます。コードの再利用を促進するために、一部のC++コードをCに「バックポート」しました。
私は、データベースアクセスにCコアの周りにC++ラッパーを使用するいくつかの異なるプロジェクトチームと協力しています。一部のチームはC++を使用し、他のチームはCのみですが、コア機能はチーム間で共有されます。私たちはメンテナンス期間中なので、CチームがC ++に移植したいと思っても、それは実現可能ではありません。私がCをC++に変換するのを見た試みは、より長く、より複雑な結果になりましたが、それ以上表現力のあるコードはありませんでした。もちろん、YMMV。
私の経験を伝える前に、いくつかのCプロジェクトをC++に移植したので:
あなたが本当に意味しているのは、「すでに正常に動作するコードからクラスとオブジェクトを作成する」ことであると思いCますC++. それはおそらくあなたがしていることです。移植を行う理由は、コードをより再利用可能で保守しやすくするためだと思います。これは中規模から大規模のプロジェクト (少なくとも 10000 LOC) であると想定していることに注意してください。
もしそうなら、私はあなたが直面するいくつかの問題を想像することができますが、一般的に C++ で遭遇する問題でもあります:
'OO'**
C は手続き型であるため、C++ のオブジェクトの意味で何が「再利用可能」であるかについての判断が求められます。おそらく、最初の観察が間違っていたことに気付くことがあります。コードがコンパイルされないからではなく、ロジックが以前と同じように実行されないためです。その場合: 基本的な C++ オブジェクトが C プログラムの元の意図したロジックを壊していないことがわかっている場合は、テスト、テスト、テスト (段階的に) を行い、最後に設計パターンを使用して凝ったリファクタリングをすべて実行します。
C のmallocandfreeと C++ のnewanddeleteは、非常に異なることを行います。C++ オブジェクトの割り当てがどうなるかは、C コードが何を行っているかについての理解をどのように再解釈したかに大きく依存するため、両方に非常に熟練している必要があります。しかし、最初は、malloc と free の呼び出しを保持し、特に理由がない限り、C++ でそれらを抽象化します。したがって、クラスが作成され、メモリの割り当てと割り当て解除が行われると、アプリケーションでメモリ リークが発生します。これは保証であり、段階的にテストする必要があるまさにその理由です。
コードをより「リート」にするために、継承と設計パターンに夢中になりたいという誘惑が時々あると思います。デザインパターンは本質的にコードを最適化してより効率的で保守しやすいようにするための方法であるため、移植の開始時にこの誘惑に抵抗するようにしてください。リファクタリングと「今はうまくいかない」と「変更する必要がある前に間違ったデザインパターンを使用しました」...ご覧のとおり、非常に迅速に制御不能になる可能性があるため、一度に1つのことを行うことに集中してください圧倒されないように、移植プロセスにバグがなく、気楽に行えるようにしてください。
グローバルを分割し、そのスコープをどこで制限するかを決定する必要があります。単純な C++ オブジェクトを一度に 1 つずつ作成することで、C コードの意味と機能を保持するようにしてください。名前空間、継承、デザイン パターンなどの点で凝ったものは何もありません。ここでも、コードがクラスに変換された後に実行することをお勧めします。 .
生の C コードを C++ プロジェクトにいつでも含めることができます。したがって、C++ をいじる C ライブラリがある場合でも、extern "C" {}参照用に使用してから、C++ コード内で呼び出してください。
https://isocpp.org/wiki/faq/mixing-c-and-cpp
C オブジェクト ファイルを C++ オブジェクト ファイルにリンクすることも完全に可能です。
これ (c++ Super-FAQ へのリンク) は基本的に、プロジェクトを C++ に変換し、レガシー互換性を維持するために知っているすべてです。
多重継承が悪い理由
おい。多重継承は非常に優れています。悪用しやすいだけです。複数の抽象基底クラスを継承するのに適した多重継承の一例。
主な問題はキーワードです。変数名として「new」、「private」、「public」などを使用しましたか?
特定の組み込みプラットフォームまたはカーネル モード ドライバーをターゲットにしている場合を除き、「c」に制限する必要はありません。
もちろん、単に C++ コンパイラで C コードを書くだけでは、C++ の利点をすべて享受できるわけではありません。それよりも、もう少し考え直す必要があります。
Cを使用する理由はありますか？
まれではありますが、実行可能な C++ コンパイラを持たないプラットフォームを見つけることは依然として可能です。ADI の Blackfin チップは数年前にこのカテゴリに分類されましたが、現在まともなチップが存在するかどうかはわかりません。
Cを使用する理由はありますか？
C++ コードは、小さなプロジェクトではコンパイルに時間がかかりすぎます。
長いコンパイルはループを妨げます: コードを書きます -> テストします -> さらにコードを書きます -> テストします ...
はい。小規模なプロジェクトでは、C コードの方が単純なようです。LOC ワイズおよびバイナリワイズ。