[過去ﾛｸﾞ] Go language part 3 (1002ﾚｽ)
上下前次1-新
抽出解除 必死ﾁｪｯｶｰ(本家) (べ) 自ID ﾚｽ栞 あぼーん
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
719(1): デフォルトの名無しさん [sage] 2020/09/29(火) 08:42:58 ID:ztORdlGy(1/5) AAS
>>718
718(1): デフォルトの名無しさん [sage] 2020/09/29(火) 08:17:01 ID:1HGJd50O(1) AAS
引数を値渡しするか、ポインタ渡しするか
それが問題だ

sliceは値渡しでも良いよね
要素を追加しようとすると結局新しいsliceが必要
ポインタのポインタとかやりたくないし
stringは普通は変化させる時は新しい物を作るから、値渡しで充分
空を表現するには空文字列で良いし

構造体はどうすべきか
全部ポインタ渡し？
基本的にポインタで渡すべきと思ってる
値を使うには細心の注意が必要になるから

速度的に有利とかいう話はあるけど
スライスなんかは内部にポインタ入ってるし、文字列だってポインタだから、メンバとしてそれらを持ってる構造体を値渡しするのもナンセンスじゃね？
それらのメンバにアクセスしたとたんにページフォルト起こる可能性があるから、速度面での優位は怪しくなるという意味でナンセンスだろうという
値渡しはスタックに積むだろう(それ以外に方法があるのか知らない)から、スタックを圧迫するはずという理屈も加味
721: デフォルトの名無しさん [sage] 2020/09/29(火) 15:53:59 ID:ztORdlGy(2/5) AAS
>>720
720(1): デフォルトの名無しさん [sage] 2020/09/29(火) 09:38:24 ID:rZRnYPTQ(1) AAS
>>719
いや、サイズが大きいのは基本的に可変長であるスライス、string、mapなのだから、それらだけは内部的にポインタを持って実質的に常にポインタ渡しとなるようにしておけば、常に値渡しでもパフォーマンス的にほぼ問題にならんだろうというのがGoの設計意図だよ
個人的には、同一の実体として振る舞うようなOOのインスタンスに近い性質の構造体はポインタ渡し、単なる値の寄せ集めは値渡しとして使い分ける
ググってみたら、goではスタック足りなくなると拡張すんのか……すげーな
723(2): デフォルトの名無しさん [sage] 2020/09/29(火) 17:34:34 ID:ztORdlGy(3/5) AAS
例えばjavaではStackOverflowErrorになるし、cだと検出すらされない(今は知らない
goでは関数呼び出し時にオーバーフローをチェックして拡張するらしく、初期値は4KBだとか
ほんまかいな？
724: デフォルトの名無しさん [sage] 2020/09/29(火) 17:41:44 ID:ztORdlGy(4/5) AAS
考えてみれば何万とgoroutine作ってもびくともしないようにするには、それくらいやらなきゃダメだろうから納得すべきか
725: デフォルトの名無しさん [sage] 2020/09/29(火) 20:23:20 ID:ztORdlGy(5/5) AAS
>>723
1.4までは8kB、今は2kB
1.4リリースノート
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.042s