[過去ﾛｸﾞ] Go language part 1 (1002ﾚｽ)
上下前次1-新
抽出解除 ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
984(1): デフォルトの名無しさん [sage] 2017/11/11(土) 15:36:08.28 ID:proXGFSN(3/3) AAS
>>983983(2): デフォルトの名無しさん [sage] 2017/11/11(土) 15:20:24.76 ID:LLMRc4SD(5/9) AAS
>>982
誰もCで書くとは言ってないが、仮にCで書くとして、
ライブラリが揃っていれば、大して苦労しないと思うよ。
Goとは大差ないだろう。
ほぼローカルで動作してしまうのでGCがないと苦労するってこともないし、
型システムも100行程度のプログラムならウザイくらいで大してメリットないし。
動的言語の場合は既に言われているようにスキーマ管理が一元化出来る
（正確にはやらなくてもそのまま動くだけだが）
分だけ書く量は少なくて済む。
プロトタイピングには動的言語の方が向いてる。
なお今回の場合はGoがCに劣ることもないので、わざわざCで書き直すメリットはない。
(GCをほぼ使わないから速度低下もないし)
>動的言語の場合は既に言われているようにスキーマ管理が一元化出来る
>（正確にはやらなくてもそのまま動くだけだが）
> 分だけ書く量は少なくて済む。
> プロトタイピングには動的言語の方が向いてる。
同意する。Goでデータベース操作の決定版がでないのが物語ってる。
逆にGAE/goのdatastoreを使うときはGoとの相性の良さを感じる。
スキーマがGo側に設定することが決まっているから。
986: デフォルトの名無しさん [sage] 2017/11/11(土) 16:18:54.52 ID:LLMRc4SD(6/9) AAS
というか、これはAPIが足りてないんだね。
（以下コードは文法があやふやなので参考程度で）
database/sqlはScanを使うのが定番のようだが、Scanではargsの可変長指定しかないのがいけない。
だから構造体の中身を確認するのにリフレクションが必要になってしまう。
type Thread struct {
no int
time int
body string
}
th := Thread{}
rows, err := db.Query("SELECT * from threads;")
err = rows.Scan(&th.no, &th.time, &th.body) // ここでばらすから中身を知らないといけない
とりあえずScanが構造体を受け、その構造体にScannerインタフェースを実装する方式なら、
リフレクションは回避出来るし、おそらく最高速度で動く。
ただ、このためのAPIがない。
err = rows.Scan(&th) // ばらさずに構造体を与える
func (th Thread) Scan(src interface{}) err // 各構造体でばらす。手間は増えるが最速のはず
DBを生で叩いたことがないから知らないが、DBからの出力が既に配列なのか？
或いは同様のことはポインタ配列で受ければいいので割り切ったか。(972参照）
>>984
GAE/Goはググってみたがよく分からん。
ただ今回はCREATE TABLE部分も自前で持つ為、スキーマ管理はGo側でも「本来は」出来る。
SQLの構造上、CREATE TABLE と INSERT はほぼ同じなのでPHP等ではSQL文字列を共有出来る。
だから1箇所にしか書かずに済んでた。ところがGoはリード側も必要だからぐぬぬ、ってなってる。
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.169s*