[過去ログ] Go language part 1 (1002レス)
前次1-
抽出解除 レス栞

このスレッドは過去ログ倉庫に格納されています。
次スレ検索 歴削→次スレ 栞削→次スレ 過去ログメニュー
リロード規制です。10分ほどで解除するので、他のブラウザへ避難してください。
161
(1): デフォルトの名無しさん [sage] 2014/07/18(金) 22:10:34.84 ID:DOB4ifCF(2/2) AAS
>>156
156(1): デフォルトの名無しさん [sage] 2014/07/18(金) 12:55:38.48 ID:hMlFBsak(1/2) AAS
匂いがしないなら使わなければいいんじゃない
ユーザにとって美味しい餌が無いと言語も流行らないんだよ。

なんで三項演算子( ? : ) すら作らないんだろう。文法に無駄が多い。

// 入力値iが正の整数の場合iの2乗が、iが0以下の整数の場合0が返されるfunction

// Go
func Fx(i int) (ret int) {
if i > 0 { ret = i*i } else { ret = 0 }
return;
}

// Swift 三項演算子
func fx( i: Int ) -> Int { return i > 0 ? i*i : 0 }

// Swift 三項演算子を使わない場合。
func fx( i: Int ) -> Int {
if i > 0 { return i*i } else { return 0 }
}
166: デフォルトの名無しさん [sage] 2014/07/19(土) 09:59:22.84 ID:yYW1nc9J(1) AAS
とりあえずフレームワークを1つ覚えとけばいいかな
374: デフォルトの名無しさん [sage] 2014/11/18(火) 00:13:06.84 ID:zcJbx4rP(1) AAS
失禁した
410
(1): 名無しさん@そうだ選挙に行こう [sage] 2014/12/13(土) 12:12:47.84 ID:imyzRhSY(1/3) AAS
>>409
409(1): デフォルトの名無しさん [sage] 2014/12/13(土) 12:01:31.39 ID:BVSGhnq7(1/2) AAS
>>404
structは値型だからね
m["unko"]はmに格納されてるVertexのコピーが返される
これに修正加えても反映されないよーっていうエラー
だからそう言う書き方がしたいなら
map[string]*Vertex
って宣言するといい
var m map[string]*Vertex

func main() {
m = make(map[string]*Vertex)
m["Bell Labs"] = &Vertex{
40.68433, -74.39967,
}
m["Bell Labs"].Lat = float64(1)
fmt.Println(m["Bell Labs"])
}

これで行けました。ありがとうございます!

便乗で質問なのですが、
var m map[string]*Vertex
mapに関しては個人的に全部これでいいんじゃないかなと思ってしまうのですが
リファレンス型(ポインタ型?)を使うデメリットってあるんでしょうか。
自分で思いつくのは、
           値                リファレンス
メリット       ?               アドレス情報にしかメモリを使わない
デメリット    コピー分メモリを食う     ソースがやや煩雑に

とう感じなのですが…
454: デフォルトの名無しさん [sage] 2015/12/19(土) 15:53:57.84 ID:TV8OiN+s(1) AAS
goのEditorで今のおすすめは何かな?
俺の中ではVisualStudioCodeなんですが。
676
(1): デフォルトの名無しさん [sage] 2016/09/22(木) 21:41:56.84 ID:sBPmoePF(3/3) AAS
>>670
670(1): ◆SEdFBOkLSw [sage] 2016/09/22(木) 13:36:58.94 ID:3pIcfs21(1) AAS
ORM使うからじゃないの?
JOINして使う結果とJOINせず単独で使う結果はそれぞれ別の構造体になってしかるべきな気がする。
あんまRDB使わないけど。
集合検索結合集計なシステムと手続き型とオブジェクト型と関数型、どれ同士を組み合わせても、インピーダンスミスマッチは仕方ないんだから、どっちかで歩み寄らなきゃ何ともならんような。

階層型とばっかり組み合わせてるけど、言語側はわりと世代交代早いからDB側でストアド書いてるわ。
結局ビジネスロジックをどっち側に寄せるかという話になるんだろうけど
ストアドプロシージャは素朴なコードしかかけないから抽象化しづらいと思うんだけど
書いたことがないから想像でしかないけど。

でもgolangの場合は抽象化しきれないからストアドプロシージャ側にロジックを寄せて実装はありなのかもしれない
前次1-
スレ情報 赤レス抽出 画像レス抽出 歴の未読スレ AAサムネイル

ぬこの手 ぬこTOP 0.041s