[過去ﾛｸﾞ] Go language part 3 (1002ﾚｽ)
上下前次1-新
抽出解除 ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
94(1): デフォルトの名無しさん [sage] 2019/11/23(土) 20:37:12.05 ID:5HHeTBXj(3/10) AAS
>>8888(2): デフォルトの名無しさん [sage] 2019/11/21(木) 22:11:47.49 ID:zCme0Fkr(1) AAS
なぜかVScodeでmain.goだけ"fmt"とか全くimportできなくなってしまった
language serverのリスタートもWindowsの再起動も駄目
なんじゃこりゃ、まいったね
import "./internal/config"
とか相対パス参照を止めて完全パスでインポートしたらエラーが消えた
別マシンだと1.12だったからなのか動いてたんだけど、なんだこりや
117: デフォルトの名無しさん [] 2019/11/26(火) 15:32:27.05 ID:+MieSoC5(3/4) AAS
>>110110(1): デフォルトの名無しさん [sage] 2019/11/25(月) 22:24:43.09 ID:ELiIkdft(1/2) AAS
>>109
パッケージドキュメントのExampleが、自分としては分かりやすかった
WithCancelしか使ってないけど
あと、go vet がバグっていて親contextのCancel関数があるのに
子供のCancel関数を_で捨てると怒られる
外部ﾘﾝｸ:github.com
暫定的な解決法は一旦変数に取ってから_に代入
パッケージドキュメントだと、やはり基本的にループ待受なのね
なんかイメージ的に、その文脈から派生した処理を上手いことその派生分だけ切り上げる、みたいな感じだったけど、contextWithCancel使う＝ループ処理がある、なのかな
242: デフォルトの名無しさん [] 2020/01/24(金) 16:06:50.05 ID:D9pKpEah(1) AAS
JULIAが最悪
275: デフォルトの名無しさん [sage] 2020/02/04(火) 22:39:33.05 ID:Bi0juC3i(1) AAS
矛盾が少なくて必要最小限の仕様しかない、という意味ならC
だから未だに現役なわけで
俺はJavaScriptが好きだけど
JSもCと同様Alt-JSが大量に発生したものの殺しきれなかった、という意味ではある程度洗練はしている
言語としての問題は typeof(null)==="object" 位
613: デフォルトの名無しさん [sage] 2020/05/26(火) 19:13:02.05 ID:uV+m0fgU(6/7) AAS
検索で困るもんな
720(1): デフォルトの名無しさん [sage] 2020/09/29(火) 09:38:24.05 ID:rZRnYPTQ(1) AAS
>>719719(1): デフォルトの名無しさん [sage] 2020/09/29(火) 08:42:58.32 ID:ztORdlGy(1/5) AAS
>>718
基本的にポインタで渡すべきと思ってる
値を使うには細心の注意が必要になるから
速度的に有利とかいう話はあるけど
スライスなんかは内部にポインタ入ってるし、文字列だってポインタだから、メンバとしてそれらを持ってる構造体を値渡しするのもナンセンスじゃね？
それらのメンバにアクセスしたとたんにページフォルト起こる可能性があるから、速度面での優位は怪しくなるという意味でナンセンスだろうという
値渡しはスタックに積むだろう(それ以外に方法があるのか知らない)から、スタックを圧迫するはずという理屈も加味
いや、サイズが大きいのは基本的に可変長であるスライス、string、mapなのだから、それらだけは内部的にポインタを持って実質的に常にポインタ渡しとなるようにしておけば、常に値渡しでもパフォーマンス的にほぼ問題にならんだろうというのがGoの設計意図だよ
個人的には、同一の実体として振る舞うようなOOのインスタンスに近い性質の構造体はポインタ渡し、単なる値の寄せ集めは値渡しとして使い分ける
755: デフォルトの名無しさん [] 2020/10/28(水) 09:08:16.05 ID:pr+rUhRZ(1) AAS
俺はコンパイラが無様すぎると思うんだけど、どう思う？
外部ﾘﾝｸ:play.golang.org
インタフェースAを返すメソッドを持つインタフェースB。
そのメソッド実装がインタフェースAを実装しているポインタを返しても、
./prog.go:34:4: cannot use &Base literal (type *Base) as type IBase in assignment:
*Base does not implement IBase (wrong type for Sub method)
have Sub() *Sub
want Sub() ISub
と、インタフェースAを返しているとは認められない。
924(1): デフォルトの名無しさん [sage] 2020/11/05(木) 21:13:05.05 ID:rDKR4t8H(1/4) AAS
>>901>>905俺が無知なのはさておき、GCを実装してる連中はそこら辺まで調査して選択してる。
Go含めて重鎮が地味にマーク＆スイープを選択するのは、それなりに理由がある。
ただし、マーク＆スイープは、「大量の生存オブジェクト」には不向きで、Discordの件はそれに該当する。
逆に言えばそれが不向きなだけで、「最小限の生存オブジェクトと大量のゴミ」という、
普通の使い方の場合には、マーク＆スイープの方がいいと判断したからそっちを選択してるわけだ。
kotolin-nativeは多分新しいことを試してみたかったんだろうと思うが、
Pythonはおそらく判断をミスっていて、通常向けに最適化するべきだと思う。
(これがPythonが無駄に遅い理由の一つになっているかも）
ただしGC機構についてだけ言えば、Python型なら今回のDiscordみたいなことにはならなかったはずだ。
だからあれはより正確に言えば「『マーク＆スイープ方式の』GCの限界」だな。
978: デフォルトの名無しさん [sage] 2020/11/14(土) 16:11:45.05 ID:AxEpuS5V(2/2) AAS
うーん、全世紀の遺物から、複数の戻り値とか、deferとかみたいなので別方向に進化したものだと思うけどな。
面倒くさいなって思う事もそんなに無くなったが。
後出しジャンケンみたいなインターフェイスはなかなか便利だし他の言語には無いと思うぞ。
まあ名前はひどい。
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.055s