3

一部のC++コードを構造体からクラスに移行しています。

私は主にビットフィールドの最適化のために構造を使用していましたが、これ以上は必要ありません（現在、スペースを節約するよりも速度が心配です）。

  • この移行を行うための一般的なガイドラインは何ですか？これはコードの大部分に影響を与える非常に大きな動きであるため、私はまだ計画段階にあります。それをする前に、まずすべてを計画したいと思います。 私が心に留めておくべきすべての重要なことは何ですか？
4

4 に答える 4

4

レガシーコードベースをCからC++に更新する場合、私の経験では、構造を従来のC ++オブジェクトに変換するためにアプリケーションを実際に再設計することには、ほとんど価値がなく、非常に多くの労力が必要です。間違いないので、それはあなたがやることになることです。最初はそうは思われませんが、最終的にはアプリケーションを再設計していることに気付くでしょう。

目標について十分に説明していないので、これが目標かもしれませんが、アプリの新しいコードをC ++にできるように、C ++に変換しようとしている場合は、ファイルの名前を変更し、キャストを追加してください。 void *からの暗黙の変換が以前に発生していた場所で、あなたの人生を続けてください。

于 2010-05-07T06:43:19.573 に答える
4

重要なものすべてに名前を付けることはできませんが、カプセル化という名前を付けることはできます。

構造体とクラスのC++の唯一の技術的な違いは、デフォルトのアクセスです。構造体では、デフォルトですべてが公開されます。クラスでは、すべてがプライベートです。ここでは、すべてが公開されているPOD構造体について話していると思います。

私がすることはこれです：

  1. structキーワードをに変更してclass、呼び出しコードがどこで壊れているかを確認します。これにより、タイプのどの部分がどこで使用されているかについての手がかりが得られます。
  2. その中から、タイプのどの要素をパブリックにするか、どの要素をプライベートにするかを決定します。
  3. パブリックパーツのアクセサ関数を記述し、それらを使用するように呼び出しコードを変更します。
  4. プライベートパーツへのアクセスが必要なコードをクラス自体に移動します。
于 2010-05-07T06:25:10.737 に答える
1

C ++の構造とクラスの間に意味のある違いはありません（デフォルトの可視性によってのみ異なります）。意味のある動作も追加しない限り、構造をクラスに移行する必要はありません。

于 2010-05-07T06:22:01.820 に答える
1

まず、他の人たちと一緒に、すべてのコードを構造体からクラスに移動するのは最善の方法ではないかもしれないと言います。あなたがそれをうまくやるなら（つまり、単に変更struct X {するだけではありませんclass X { public:）、それはアプリケーションを再設計することを意味します（多かれ少なかれ完全な書き直し）。

これには、新しいバグの導入、新しい開発サイクル、追加のテスト、ドキュメントの変更などが含まれます。

第二に、あなたがこれを行う正当な理由があるかもしれないことを考えると（私にとって「ただの楽しみのために」そして「私がそれをすることができるかどうか見るために」はいくつかの状況で正当な理由になることがあります：D）ここにあなたの質問に対する私の答えがあります：

1. What are the general guidelines for doing this migration?
2. What are all the essential things I should keep in mind?

ガイドラインと留意事項：

  • 非常に小さな反復で動作し、アプリケーションが反復間で機能することを確認します。ユニットテストを定義している場合は、それらを順を追って実行できます（1つのユニットを選択し、一連の手順に従って再設計し（以下を参照）、テストを適応させて実行します。

  • コードの1つの領域を選択して、それを終了します。

  • 変更ごとに次の手順を実行してみてください。

    • 機能を分析して再設計する
    • 古い実装と並行して新しい実装を作成します
    • 古い実装が使用されているすべての場所で新しい実装に切り替えます
    • アプリケーションがまだ機能することをテストします
    • 古いコードを削除する
    • アプリケーションがまだ機能することをテストします

  • 現時点でそれを行っていない場合は、分岐ソース管理ソフトウェアの使用を開始してください。何よりもそれを完全にカットします。Mercurialをお勧めしますが、GITにはほぼ同じ機能があることを理解しています。後で私に感謝することができます：o）。

  • トランザクションで変更を実行します（最初の領域の変更が途中である間、他の領域からの変更を追加せずに、1つの領域から開始して終了します）。分岐ソース管理と複数の開発者を使用する場合は、開発者ごとに一度に1つの変更/領域を設定してから、変更を一元化できます。

リファクタリング方法の利点：

  • 途中で努力する価値がないと判断した場合（または管理者が努力に価値がないと判断した場合）、アプリケーションは機能し続けます。

  • アプリケーションの安定性は、変更を通じて管理可能なままです

いくつかのマイルストーンを確立する場合、これは非常に管理しやすいはずです。

幸運を！

于 2010-05-07T11:11:19.847 に答える