K.Maebashi's BBS 削除ページ

>>hoge.h, piyo.hが共にプライベートヘッダファイルならどこかでまとめて >>#define GLOBAL_VARIABLE_DEFINEして#includeしますし、 >そのまとめて include っつーことは globals.c とか作るということですか？ >モジュール切り分け原則に反しているような気がしてなんとなくいやです。 globals.cを作るか、ということですが、 そのglobals.cが、プログラム全域のグローバル変数の定義を行う、 ということなら、Noです。 あるモジュールについて、「そのモジュールの内部だけで使う、ソースを超えた スコープを持つ変数」の定義を行うglobal.cなら、作るかもしれません。 たとえば先のcalcの例だと、電卓モジュール「CLC」内にglobals.cを 置くかもしれません(モジュールごとにディレクトリが分けられていて、 ソースファイル名の重複が許されるとして)。 モジュールをまたがったglobals.cがあるなら「モジュール切り分け 原則に反している」と私も思いますが、モジュール内でしか見ない グローバル変数のためのglobals.cなら、問題ないと思います。 # ここでモジュールは「複数の.cの集合体」と定義しています。 ## Mayerさんの「オブジェクト指向入門」に「ヘッダファイルはモジュールを ## 破壊する」ってあったけど、使い方次第だと思うんだけどなあ。 ただ、実際には、ひとつのモジュールに、そんなにたくさんプライベート ヘッダファイルがあるわけはないので、どこかのソースで代表させて終わりです。 CLCの場合はinterface.cですね。 # どこのソースで代表させるかが不明確なので(たとえ3行しかなくても)globals.c # を書くべきだ、という主張には正当性があると思います。 >組み込み系では「状態保持」のための変数は、プログラムが生きている >＝電源が入っている限り、ずっと必要なので必然的に静的変数(大域変数)になっちゃいます。 >んで getter/setter も最適化の都合でインライン関数化したかったりするんです。 なるほど。アクセサを書くことまではできても、ヘッダファイルを切り分けると、 コンパイル単位が分かれてしまうからインライン展開が効かず効率が悪くなる わけですね。 Javaなんかだと、javacによるコンパイルはソース単位ですが、 JITコンパイラが実行時にソースを超えたインライン展開までやってくれたり するようです。でも組み込みじゃ難しいですよね。