1013:デフォルトの名無しさん (ﾜｯﾁｮｲ bcbf-7Gsa)
16/05/20 22:45:59.15 91VA6wxC0.net
>>983
ライブラリの数値を使うか自分で数値を定義しておくかな…
piとかeは数学関数で計算できるだけマシってことね
M_PI使わない理由として俺は十分納得できるかな
1014:デフォルトの名無しさん (ﾜｯﾁｮｲ caa6-xKv1)
16/05/20 22:51:15.37 RvnBIaae0.net
>>985
オブジェクト指向であることとか「刻む」ことの意義と
インナークラスにすることがあまり結びつかないなあ。
内側のクラスの存在が外側から完全に隠れる以外の効果あったっけ？
1015:デフォルトの名無しさん (ﾜｯﾁｮｲ bd6c-dqc0)
16/05/20 22:53:44.87 BayA8c/P0.net
内側クラスは外側クラスのプライベートにアクセスできる
1016:デフォルトの名無しさん (ﾌﾞｰｲﾓ MM28-MTTD)
16/05/20 22:56:32.97 4DucW+JdM.net
>>984
マクロやstaticメンバを使った汚い手から一時的な処理用のクラスを作るなどまで想像してましたが、どのみち一手間かかるので必要性次第でしょうね(Innerのメソッドが多くてそうでもしないと…とか)
結局それほどケチる必要がなくてコンストラクタで渡すので十分な予感
本当にポインタ1個分が問題になるような細かいInnerClassを多数作るようなケースなら、このアドレスの範囲にあるInnerのオブジェクトはどのOuterに対応する、という表が作れると検索時間と引き替えにメモリを節約できたり
1017:デフォルトの名無しさん (ﾌﾞｰｲﾓ MM28-MTTD)
16/05/20 23:07:25.77 4DucW+JdM.net
>>985
最近追加されたラムダですらどのようにキャプチャするかを細かく指定しなければならない言語だということを理解した方がいいと思う
今後そういう機能が追加されるかどうかはしらないけど、されたらいいね
1018:デフォルトの名無しさん (ﾜｯﾁｮｲ bc42-MTTD)
16/05/20 23:17:26.67 soKi6pqK0.net
innerクラスなんて完全なアンチパターンだろ
馬鹿じゃねーの
1019:デフォルトの名無しさん (ﾜｯﾁｮｲ 7b5b-xKv1)
16/05/20 23:24:48.47 gU7EupTq0.net
>>988
インナーにするのは、DotはLifeGameでしか使わないからです。（他から見える必要がない）
オブジェクト指向にするのは、多分制御が簡単になりそうだからなのと、
その際に記述が抽象階層で分離でき、見やすくなると予想されるからです。
もっと良い例がありました。「文書内の不完全マッチによる最有力候補探索」です。
これはほぼやりたいことと同じです。
例えばテキスト文書があったとして、「あいうえおかきくけこ」を探索するとします。
ここで、そのまま「あいうえおかきくけこ」があれば100点、それを示して終わりです。
これがない場合、欠け方それぞれで得点付けし、とにかく一番得点が高い候補を一つ出します。
（例えば「あ」がないのなら-20点とか、「う」が抜けているのなら-10点とか）
実際は多分100～200字同士のマッチングと等価で、完全一致は期待できないため、
Dotに分枝の作成まで含めてlife_exeさせます。
結果、LifeGameからは「やっとけ。」だけで済み、詳細な実行ルーチンはDot側に集約されます。
といってもこれは分離されるだけで、どちらに書くかの違いだけなのですが、
それでも後々効いてきます�
1020:ﾌで、Dot側に集約できる部分は集約しておきたいのです。 Dotは分枝の作成時に自分自身からforkする感じで、たぶんかなり増えます。 ただし親は一つなので、ここの部分は勿体ないかな、という感じでした。 （問題になるほど増えないとは思います） life_exe内には親のmapへのアクセスは大量に存在しますが、 life_exeはDot内で自走するので、引数として親ポインタを渡すことは出来ません。 従って、親ポインタはコンストラクタでメンバ変数として確保することになります。 コンストラクタで親ポインタを渡すのは、記述的には全く問題ないです。 （最初にもらった親ポインタを大事に抱えて再帰しまくることも出来ますが、、、）
1021:デフォルトの名無しさん (ﾜｯﾁｮｲ b0ab-/fHo)
16/05/20 23:24:55.51 G62tMzQY0.net
馬鹿じゃねーよ
おまえ以外は
1022:デフォルトの名無しさん (ﾜｯﾁｮｲ 7b5b-xKv1)
16/05/20 23:52:28.35 gU7EupTq0.net
>>991
> 最近追加されたラムダですら
見てみましたが、確かにこのラムダはちょっと見にくいですし、使いにくいですね。
元はといえばC++には関数内関数が無い為、レキシカルスコープ（※）を導入できず、
ラムダのうまみも少し欠けている気がします。
（※一つずつ上の階層を探して名前が一致したらそれと見なす）
g++では既に拡張が行われていると聞きましたが、先に関数内関数が欲しかったですね。
とはいえ、回答して頂いた皆様、ありがとうございました。
1023:デフォルトの名無しさん (ﾌﾞｰｲﾓ MM28-MTTD)
16/05/21 00:00:28.24 z244ST7/M.net
>>995
使いにくいのにはそれなりの理由があって、それを理解しましょうねという話
その上で適切な言語を選びましょう
1024:デフォルトの名無しさん (ﾜｯﾁｮｲ 9102-xKv1)
16/05/21 00:01:00.93 EJBeUkkD0.net
動けば良いんだよ
1025:デフォルトの名無しさん (ﾜｯﾁｮｲ caa6-xKv1)
16/05/21 00:27:26.30 jGVAnHGn0.net
>>995
よくわかんないけど、名前が一致した「それ」は型が揃っているのかな？
一致してる度合いに微妙に差があるのでは？
1026:デフォルトの名無しさん (ﾜｯﾁｮｲ bc7b-xKv1)
16/05/21 00:56:40.25 Uqmc4lbY0.net
>>983
宇宙物理のシミュレーションだと万有引力定数が1になるような単位系で計算する
1027:デフォルトの名無しさん (ﾜｯﾁｮｲ caa6-xKv1)
16/05/21 01:08:07.17 jGVAnHGn0.net
外部からはOuter::Innerはautoでしか受けられない型か
1028:デフォルトの名無しさん (ﾜｯﾁｮｲ 7b5b-xKv1)
16/05/21 01:23:16.26 HBQ7d37R0.net
次スレ
C++相談室 part125
ｽﾚﾘﾝｸ(tech板)
1029:デフォルトの名無しさん (ﾜｯﾁｮｲ 7b5b-xKv1)
16/05/21 01:29:43.83 HBQ7d37R0.net
>>998
自分がイメージしたのはJavaScriptで、あの言語はnamespaceがないので関数内関数がデフォ、
そして型がないので名前さえ一致すればそこで決まりですね。
ラムダで数階層上の変数を掴みに行くこともよくあります。
C++はnamespaceで細かく切れということなのでしょうが、
やはりユーザの意志で階層が切れないのは使いにくいですね。
C++のインナークラスはメリットがないといえばそうですが、JavaScriptだとインナークラスがデフォです。
（外に見せる必要がなければインナークラス）
これに関しては「余分な物は見せない」というJavaScriptの方がプログラミングとしては正しいと思われます。
ただ、ラムダはGCヒープならほぼ問題ありませんが、スタックが基本のC/C++だと実装も難しいはずで、
C++のラムダは分かりやすくはないけど妥当な仕様の気もしますね。
現実的にはヒープポインタを値キャプチャでラムダでしょうし、この仕様で実害はありません。
スタック変数をラムダで参照キャプチャは使い方として不自然ですし。
それでもやりたければ出来るところがC++っぽいですが。
1030:1001
Over 1000 Thread.net
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。
life time: 48日 1時間 7分 19秒
1031:1002
Over 1000 Thread.net
２ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
──────────
《プレミアム会員の主な特典》
★ ２ちゃんねる専用ブラウザからの広告除去
★ ２ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
──────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
URLﾘﾝｸ(premium.2ch.net)
URLﾘﾝｸ(pink-chan-store.myshopify.com)
1032:過去ログ ★
[過去ログ]
■ このスレッドは過去ログ倉庫に格納されています