[過去ﾛｸﾞ]
Go language part 3 (1002ﾚｽ)
Go language part 3 http://mevius.5ch.net/test/read.cgi/tech/1571315884/
上
下
前次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
抽出解除
ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索
歴削→次ｽﾚ
栞削→次ｽﾚ
過去ﾛｸﾞﾒﾆｭｰ
ﾘﾛｰﾄﾞ規制
です｡10分ほどで解除するので､
他のﾌﾞﾗｳｻﾞ
へ避難してください｡
94: デフォルトの名無しさん [sage] 2019/11/23(土) 20:37:12.05 ID:5HHeTBXj >>88 import "./internal/config" とか相対パス参照を止めて完全パスでインポートしたらエラーが消えた 別マシンだと1.12だったからなのか動いてたんだけど、なんだこりや http://mevius.5ch.net/test/read.cgi/tech/1571315884/94
117: デフォルトの名無しさん [] 2019/11/26(火) 15:32:27.05 ID:+MieSoC5 >>110 パッケージドキュメントだと、やはり基本的にループ待受なのね なんかイメージ的に、その文脈から派生した処理を上手いことその派生分だけ切り上げる、みたいな感じだったけど、contextWithCancel使う＝ループ処理がある、なのかな http://mevius.5ch.net/test/read.cgi/tech/1571315884/117
242: デフォルトの名無しさん [] 2020/01/24(金) 16:06:50.05 ID:D9pKpEah JULIAが最悪 http://mevius.5ch.net/test/read.cgi/tech/1571315884/242
275: デフォルトの名無しさん [sage] 2020/02/04(火) 22:39:33.05 ID:Bi0juC3i 矛盾が少なくて必要最小限の仕様しかない、という意味ならC だから未だに現役なわけで 俺はJavaScriptが好きだけど JSもCと同様Alt-JSが大量に発生したものの殺しきれなかった、という意味ではある程度洗練はしている 言語としての問題は typeof(null)==="object" 位 http://mevius.5ch.net/test/read.cgi/tech/1571315884/275
613: デフォルトの名無しさん [sage] 2020/05/26(火) 19:13:02.05 ID:uV+m0fgU 検索で困るもんな http://mevius.5ch.net/test/read.cgi/tech/1571315884/613
720: デフォルトの名無しさん [sage] 2020/09/29(火) 09:38:24.05 ID:rZRnYPTQ >>719 いや、サイズが大きいのは基本的に可変長であるスライス、string、mapなのだから、それらだけは内部的にポインタを持って実質的に常にポインタ渡しとなるようにしておけば、常に値渡しでもパフォーマンス的にほぼ問題にならんだろうというのがGoの設計意図だよ 個人的には、同一の実体として振る舞うようなOOのインスタンスに近い性質の構造体はポインタ渡し、単なる値の寄せ集めは値渡しとして使い分ける http://mevius.5ch.net/test/read.cgi/tech/1571315884/720
755: デフォルトの名無しさん [] 2020/10/28(水) 09:08:16.05 ID:pr+rUhRZ 俺はコンパイラが無様すぎると思うんだけど、どう思う？ https://play.golang.org/p/XRFmBiqhqJp インタフェース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を返しているとは認められない。 http://mevius.5ch.net/test/read.cgi/tech/1571315884/755
924: デフォルトの名無しさん [sage] 2020/11/05(木) 21:13:05.05 ID:rDKR4t8H >>901 >>905 俺が無知なのはさておき、GCを実装してる連中はそこら辺まで調査して選択してる。 Go含めて重鎮が地味にマーク＆スイープを選択するのは、それなりに理由がある。 ただし、マーク＆スイープは、「大量の生存オブジェクト」には不向きで、Discordの件はそれに該当する。 逆に言えばそれが不向きなだけで、「最小限の生存オブジェクトと大量のゴミ」という、 普通の使い方の場合には、マーク＆スイープの方がいいと判断したからそっちを選択してるわけだ。 kotolin-nativeは多分新しいことを試してみたかったんだろうと思うが、 Pythonはおそらく判断をミスっていて、通常向けに最適化するべきだと思う。 (これがPythonが無駄に遅い理由の一つになっているかも） ただしGC機構についてだけ言えば、Python型なら今回のDiscordみたいなことにはならなかったはずだ。 だからあれはより正確に言えば「『マーク＆スイープ方式の』GCの限界」だな。 http://mevius.5ch.net/test/read.cgi/tech/1571315884/924
978: デフォルトの名無しさん [sage] 2020/11/14(土) 16:11:45.05 ID:AxEpuS5V うーん、全世紀の遺物から、複数の戻り値とか、deferとかみたいなので別方向に進化したものだと思うけどな。 面倒くさいなって思う事もそんなに無くなったが。 後出しジャンケンみたいなインターフェイスはなかなか便利だし他の言語には無いと思うぞ。 まあ名前はひどい。 http://mevius.5ch.net/test/read.cgi/tech/1571315884/978
ﾒﾓ帳
(0/65535文字)
上
下
前次
1-
新
書
関
写
板
覧
索
設
栞
歴
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
AAｻﾑﾈｲﾙ
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.036s