C ++コードを構造からクラスに移行します

Question

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

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

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

Answer 1

名前はできません すべて 本質的なことですが、名前を付けることができます。 カプセル化.

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

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

1. 変更 struct キーワード class そして、呼び出しコードがどこで壊れるかを確認します。それはあなたにどこで使用されているタイプの部分についての手がかりを与えます。
2. それから、どのタイプの要素が公開されるべきかを決定します。これはプライベートである必要があります。
3. パブリックパーツのアクセサ機能を書き込み、呼び出しコードを変更して使用します。
4. プライベートパーツへのアクセスが必要なコードをクラス自体に移動します。

Answer 2

レガシーコードベースをCからC ++に更新する場合、私の経験は、実際にあなたのアプリケーションを従来のC ++オブジェクトに変換するためにアプリケーションを調べることに関与する価値がほとんどなく、完全にあまりにも多くの努力があることです。間違いを犯さないので、それはあなたがすることになるでしょう。最初はそうではありませんが、最終的にはアプリケーションを再設計していることに気付くでしょう。

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

Answer 3

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

Answer 4

初め, 、私は他の人に参加し、すべてのコードを構造からクラスに移動することは最良の動きではないかもしれないと言います。あなたがそれをうまくやるなら（つまり、単に変化する以上のもの struct X { と class X { public:）それは、アプリケーションの再設計を意味します（多かれ少なかれ完全に書き直します）。

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

2番, 、あなたがこれを行う正当な理由があるかもしれないことを考えると（私にとっては「ただの楽しみのために」、「できるかどうかを確認する」ことは、状況によっては正当な理由になる可能性があります：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つの変更/領域を1つずつ配置してから、変更を集中させることができます。

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

• アプリケーションは、努力が価値がないことを途中で決定した場合（または、経営陣が努力に価値がないと判断した場合）

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

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

幸運を！