静的、動的の基準は?

[戻る]
みさこ 2009/11/30(月) 20:20:19
この二つの言語、C++ およびjava において、クラス、メンバー関数、メソッド、メンバ
変数、フィールド値を
静的 にするか、動的にするかその判断基準を教えていただけないでしょうか。

επιστημη [E-Mail] [HomePage] 2009/11/30(月) 21:32:59
それらが クラスに属するか/インスタンスに属するか です。

wclrp ( 'o') 2009/11/30(月) 21:45:52
静的やstaticっていろいろな場面があり
違う意味だったりするので静的の反対は動的とは限らないんじゃない。
# 俺はstaticの反対のことは知らないけど。

数学のsin、cos、タンジェントは、
インスタンスに関係ないのでstaticメンバ関数だな。
どんな時でも決められた値である定数はstaticだな。
# 別に無理にstaticにしなくてもいいんじゃね。

インスタンス関するものは非staticメンバ関数だね。
変数abcウィンドウの幅はabc.getWidth()とか。

επιστημη [E-Mail] [HomePage] 2009/11/30(月) 21:50:12
> 数学のsin、cos、タンジェントは、
> インスタンスに関係ないのでstaticメンバ関数だな。

数のインスタンス・メソッドと考えられなくもないすけどね ^^;
# 実際C#だとそんな実装が可能だし。

みさこ 2009/11/30(月) 22:15:57
お世話になります
>それらが クラスに属するか/インスタンスに属するか です。
変数という括りに絞り込んでお聞きしますと
クラスに属する変数 → static変数
インスタンスに属する変数 → 非satic変数
ということでしょうか?
例えば
クラスに属する変数 → 非static変数
インスタンスに属する変数 → satic変数
これではよくないのでしょうか?

>違う意味だったりするので静的の反対は動的とは限らないんじゃない。
確かにそうです。
>数学のsin、cos、タンジェントは、
>インスタンスに関係ないのでstaticメンバ関数だな。
定理、公式は不変のものなので、これらがstaticである理由は理解できるのですが
なぜ非staticではいけないという、積極的理由はどこにあるのでしょうか?
もう一段掘り下げて説明を、お願いできないでしょうか。

επιστημη [E-Mail] [HomePage] 2009/11/30(月) 22:28:33
> クラスに属する変数 → 非static変数
> インスタンスに属する変数 → satic変数
> これではよくないのでしょうか?

よくないもなにも「不可能」でしょ?

> なぜ非staticではいけないという、積極的理由はどこにあるのでしょうか?

ありませんよ。たとえば逆数を求めるメソッド reciprocal() が 実数(Real) のインス
タンスメソッド(non-staticメンバ関数)であっても構わんですから。

Real x = 12.3;
Real y = x.reciprocal();

bun 2009/12/01(火) 09:15:48
何というか、そもそも論点は何なんでしょう?
それが、全く見えてきませんので、まとまりのない話にしかならない気がします。

PATIO 2009/12/01(火) 10:02:10
絶対的な基準と言うのは多分無いと思いますよ。
実装可能であれば、どちらでも有りうる話ですし。
インスタンスに属させる必要があるのにstaticというのは実装上
だめと言うのは分かりますよね?
(ここの所でなぜと言われると話が進みません)

後は、概念としてすんなり理解できる形にするのが良いと言うくらいでは
ないかと思います。非staticではいけないのではなくてstaticの方が
すんなり理解できると言うのは理由になりませんか?

仲澤@失業者 2009/12/01(火) 10:06:03
>例えば
>クラスに属する変数 → 非static変数
>インスタンスに属する変数 → satic変数
>これではよくないのでしょうか?

型と型から作られた実体(インスタンス)の区別がついていないのかも
しれませんね。メンバ(変数/関数)は、それが修飾する対象が

 ・型の修飾(つまり全インスタンスで共用)をする場合はstatic
 ・実体(インスタンス)毎の修飾をする場合は非static

に、自明的にならざるを得ません。プログラマに選択の余地はありません。

「道路交通信号」クラスの「現在の点灯状態取得」メンバは各実体の属性ですが、
「停止指示状態の色を取得」メンバはクラスstaticであるのは自明なわけです。

bun 2009/12/01(火) 11:02:46
先の話だけじゃ、冷たい気がするので、
一応、私の見解を述べると、

> 静的、動的の基準は?
というのが、static / auto の話だと仮定するなら、
επιστημηさんの話通りだと思います。
> それらが クラスに属するか/インスタンスに属するか です。

話の前提として、クラスとオブジェクトの違いを認識してください。
以下の話が分かりやすいように思います。
http://hp.vector.co.jp/authors/VA010766/memo/WhatIsClass.html

その上でクラスに属するメンバ(変数/関数とも)をstaticとして扱い、
オブジェクトに属するメンバをautoとして扱うのです。

上記の鳥類図鑑の例で言うなら、
[auto]
・鳥類図鑑に載っている動物の名前
・鳥類図鑑に載っている動物の大きさ
・鳥類図鑑に載っている動物の生息区域
    :
といったオブジェクト毎に値の変わるものがautoです。
そして、
[static]
・鳥類図鑑に載っている動物の数
・鳥類図鑑の最終更新日時
    :
といったオブジェクト毎に値の変わらないものがstaticです。
なんとなく分かるかな?

[追伸]
ちなみに、
静的/動的って境目が曖昧なのでは?

staticを静的、autoを動的というのは1つの見方であり、
そもそも、プログラムは想定されたパターンしか処理できない。
決められたパターンという意味では、基本的に全てのプログラムは静的とも言
える。非常に複雑な静的機構という見方ですな。

じゃあ、何が動的なの?乱数処理を含めば不確定要素が入り込むから動的か?
いや、これだって疑似乱数なんて予測可能では?と言われれば元も子もない。

逆に考えれば、static変数だって別の値を代入可能である。
次々と値が変わる = 動的に状態が変わる と見なせば、static変数だって動
的と見なすことも可能。

みさこ 2009/12/01(火) 20:59:00
お世話になります。
> 静的、動的の基準は?
というのが、static / auto の話だと仮定するなら、
new やtemplateのように、必要な場面でインスタンスシエードする実体という意味です
勉強不足でauto の意味がいまひとつ理解できていないのですが
ststic とは、プログラムが開始され終了するまで、常に同じアドレスに存在するもの
new または、templateでインスタンスシエードされてヒープに作成される実体(インス
タンス)としますと
私の理解できていない部分は、両者の使い分けの基準をどのように考えたらいいのかと
いうことなのです
必要なときに、インスタンスを生成し必要なくなったらデストラクタで破棄されなくと
もどの道、そのプログラムで必要で且つ、サイズがあらかじめ、予測できるものであれ
ば、
最初から特定のメモリアドレスにいてはまずいのでしょうか?

επιστημη [E-Mail] [HomePage] 2009/12/01(火) 21:57:02
> 両者の使い分けの基準をどのように考えたらいいのかということなのです

関数/変数が クラスに属するか/インスタンスに属するか です

# 堂々巡りやね。

みさこ 2009/12/01(火) 22:20:52
[[解決]]
理解力がなくてごめんなさい、よくわかりませんでした。

επιστημη [E-Mail] [HomePage] 2009/12/01(火) 22:22:00
あ...life-timeを問題にしてるんですか?
最初の質問はメンバを静的/動的のどっちに置くかだったけど、

> 最初から特定のメモリアドレスにいてはまずいのでしょうか?

これはインスタンスを最初っから用意しておくか否か、ですよね。

> 最初から特定のメモリアドレスにいてはまずいのでしょうか?

構いませんよ。あらかじめ用意できるならば。

ああ 2009/12/01(火) 22:38:55
やはり
そうきたか

メモリ領域とメンバのstaticはごっちゃにして欲しくない

maru 2009/12/01(火) 23:00:29
> 最初から特定のメモリアドレスにいてはまずいのでしょうか?
ということは静的/動的とはアドレスが変わるかどうかをいっているの?

とすると、επιστημη さんの
> 関数/変数が クラスに属するか/インスタンスに属するか です
は話が難しすぎるでしょうね。

変数が「最初から特定のメモリアドレス」にいるということはプログラムが動作して
いる間ずっと必要な変数であり、その変数の寿命がプログラムと同じであるというこ
とです。
しかし、変数が「そのプログラムで必要で且つ、サイズがあらかじめ、予測できる
もの」であってもプログラムが動作している間ずっと必要ではないのであれば、
つまり変数の寿命とプログラムの寿命が異なっているのであれば、必要になったとき
に実体化したほうがメモリを有効に使用できます。そして、ほとんどの場合、プログ
ラムの寿命と変数の寿命は異なっているんのです。

maru 2009/12/01(火) 23:08:53
あっちゃー!

文章を考えている間に、επιστημηさんの別の回答がでてた。
まあ、補足ということで。

wclrp ( 'o') 2009/12/01(火) 23:32:58
質問が
>C++ およびjava において、クラス、メンバー関数、メソッド、メンバ>ststic とは、プログラムが開始され終了するまで、常に同じアドレスに存在するもの
ってなっているから
回答が難しいな。
メンバー関数はプログラムコードであってデータじゃないから
アドレス変わるとかnewするとかヒープに置くとか無いから。
それとJavaってクラスのインスタンスはnewするものでしょ。

-------------------------------------------------------

ところでインスタンスシエードって何?

tetrapod 2009/12/02(水) 08:14:11
instantiate ぢゃないの?まあどうみてもシエードとは発音せんけど。
http://ejje.weblio.jp/content/instantiate

一般的でない俺俺独自用語が使われているので本題に対しては返信保留中

PATIO 2009/12/02(水) 11:11:36
もう解決になっちゃってますけれど、

メモリ上の配置の話とクラスとかオブジェクト指向の概念をごっちゃにしているから
話がややこしくなっていると思います。
オブジェクト指向の概念的な話をする時は一旦メモリ上の話は置いておいて良いと思います。
メモリ上のどう配置されるかはコンパイラの実装に任せて概念的な部分の理解に集中した
方が良いかなと。
クラスとの関連でstaticの話をするのであれば、メモリ上の配置に関しては結果的な話何
じゃないですかねぇ。
クラスとしてどう扱うのかとかそっちを理解されたほうが良いと思います。

PATIO 2009/12/02(水) 11:27:37
クラスとしてどれだけ自然なモデルにできるか、
無理なく対象を表現できるかが問題になると思うので
メモリ上に配置しておくとかはコンパイラを通した結果でしかない
という気がしますね。この辺を気にしすぎると概念的な部分を
理解することを目的にしているのであれば、本来の目的から反れて
しまう事になります。概念は概念として理解して結果的に
それがメモリ上ではこうなっていると言う理解の方が良いのではないかなぁ。

犬と言うクラスに体色というメンバーがあったとして
犬それぞれで体色は違う可能性があるわけですから
アプリケーションでひとつのメンバーではアプリ内に存在する犬の
体色を犬毎に持てませんよね。
何匹の犬を扱うかが最初から分かっていれば固定で持つ事も出来ますが、
それってリーズナブルな実装と言えるでしょうか?
必要な分だけ犬クラスのインスタンスを作成した時にセットで管理できた方が
分かりやすいし、扱い安くないでしょうか。
そういう概念の方に目を向けて理解された方が良いと思います。

επιστημη [E-Mail] [HomePage] 2009/12/02(水) 11:39:06
> 何匹の犬を扱うかが最初から分かっていれば固定で持つ事も出来ますが、
> それってリーズナブルな実装と言えるでしょうか?

最大101匹のわんちゃんが扱えるようにと最初っから101匹分の
わんちゃん用意しても、おかあさんが「1匹しかダメ!」って言うたら
残る100匹は"みんな目が死んでる"ことになるわけでぇ。

古いスレッドには追加発言できません。