2

論理的なグループ化を許可するだけですか？

4

6 に答える 6

4

それはあなたに柔軟性を与えます。たとえば、いくつかのコンストラクター、いくつかのパブリック、いくつかの保護された、いくつかのプライベートがあるかもしれません-それらをすべて一緒にグループ化したくないですか？

于 2008-11-21T19:41:15.817 に答える
3

なんで強制するの？コンパイラにとってはまったく役に立たず、物事を客観的に読みやすくすることもありません。C/C++ の哲学の一部は、言語が何らかの機能/機能を有効にしない恣意的なルールを作成しないことです。

コード生成がはるかに簡単になります。多くのコーディング スタイルでは、アクセス指定子をクラスごとに 2 回以上使用します。最初にすべてのローカル型を定義し、次にすべてのコンストラクターを定義し、次にすべてのメソッドを定義し、次にすべてのインスタンス変数などを定義します。

C++ は、自分自身を撃ち落とすのに十分なロープを提供しますが、それと同じ柔軟性により、エレガントで保守しやすく、十分に抽象化されたアプリケーションを構築できます。

于 2008-11-21T20:16:17.010 に答える
1

あなたは正しいと思います。強制しないままにしておくと、ユーザーはコードを読みやすくするために適切と思われるものをグループ化できます。

コンパイラーは、メモリー内で物事を異なる方法で編成する場合があります。

編集：仕様に従って：

§9.2条項12（1998および2003標準）：

アクセス指定子を介さずに宣言された（非ユニオン）クラスの非静的データメンバーは、後のメンバーがクラスオブジェクト内でより高いアドレスを持つように割り当てられます。アクセス指定子で区切られた非静的データメンバーの割り当て順序は指定されていません（11.1）。実装の調整要件により、2つの隣接するメンバーがすぐに割り当てられない場合があります。仮想関数（10.3）と仮想基本クラス（10.1）を管理するためのスペースの要件も同様です。

私はこの情報を関連するSOの質問で見つけました

于 2008-11-21T19:41:57.127 に答える
0

私の推測では、これはCの哲学から派生したものであり、自分が何をしているのかを理解し、最大限の柔軟性を提供することを前提としています。これは、ifステートメントで単一の=を許可するようなものです。

于 2008-11-21T19:46:32.827 に答える
0

私は実際にこれを少し不快な方法で利用しています。私がよく使用するコード イディオムは、パブリック アクセサー関数を持つプライベート メンバーです。

これらを1行から自動的に生成するMACRO（震え）があります。

例：

PROPERTY(int, MyVal);

...生成:...

private:
  int fMyVal;
public:
  void setMyVal(const int f) { fMyVal = f; };
  int getMyVal() { return fMyVal; };

これは、PROPERTY マクロが現在の可視性を切り替えることを覚えていれば問題なく動作しますが、これは好ましくありません....

例えば：

protected:
  int v1;
  PROPERTY (int, v2) // fv2 is  private with public accessors
  int v3;  // whoops. f3 is public,
于 2008-11-21T20:13:28.373 に答える
0

「The C++ Programming Language, 3rd edition」の中で、Stroustrup は、これはコード生成を容易にするためだと述べています。

実際のバイナリ内の各フィールドの位置は、そのフィールドがソースコードで宣言された順序に基づいていることは理にかなっていますが、これにより、C または他の言語/仕様とのレイアウトの互換性を維持することができます。

于 2008-11-21T21:40:10.320 に答える