« 2016年11月 | トップページ

2016年12月18日 (日)

「氷菓」を読んで

本屋に寄ってみたら、
アニメで見たものの原作があったので、
手に取ってみた。

氷菓
米澤穂信:著(角川文庫)

アニメで見てるけど、だいぶ前だから、
なかなかに楽しめた。
人物の描写とアニメの絵に
ちょっと違和感があった気もするけど、
違和感だったり、
アニメの演出だったりするんだろうな。
記憶によれば、アニメは原作そのままな印象。

それよりも、初版が10年以上なのに、驚いた。
初登場はさらに前なんだけど、
アニメはいつだったかな。

小説とライトノベルの境目がよくわからないが、
読みやすい部類だと思う。
ミステリーとなっているけれども、
謎を話題として、学園生活を描いた作品だと感じる。

続きも出会えば、手に取ってみようかな。
どれが2巻なのかがわからないけど(汗)


| | コメント (0) | トラックバック (0)

2016年12月11日 (日)

C言語からGo言語へコールバック登録する(Go 1.7.4)

Go言語でプログラミングするのは楽だな。。
と今だけ思ってる。
だけど、いろいろやろうとすると、
どの言語でもあるけど、面倒だなぁ。

C言語は使う時が多いので、
Go言語でC言語のライブラリを作ろうとしてみた。

簡単に呼ぶならできそうだったので、
C言語からコールバックを登録して、
Go言語から折り返す。

主にポインタとかポインタとか、ポインタがつらい。
C言語だと全部ポインタで、通るけど、
Go言語はそれより型がきっちりしている印象が出た。
夢のポインタ (void*)さんがない影響かな。


まず、C言語から呼ぶとか、Go言語から呼ぶは、
どうにかなりそうな感じだった。

The Go Programming Language
Command cgo

CからGo言語を呼ぶ場合は、
「C references to Go」にあるように、
exportってキーワードを使えば、C言語用のヘッダファイルも出してくれる。
C用のライブラリにするのは、こんなコマンド。

go build -buildmode=c-archive hogehoge.go

反対にGo言語からC言語を呼ぶ場合、
「Go references to C」にあるように、
ブリッジ用のメソッドをGo言語側に用意する必要があるようだった。
fortytwo がC言語側で定義されてるイメージになる例。

これを組み合わせると、何故かトラップが発生する。

メソッドに、export を指定すると、どうも、
import "C" より上のメソッドもC言語向けヘッダに出力される。
そのあとに、C言語向けのヘッダを読むようで、
重複定義になってしまう。

だから、exportを指定するGoファイルでは、
C言語用関数の実体は書けないみたい。
staticにすれば、いいみたいだけど、
それもヘッダに出ちゃってる。


そんなこんなで、
C言語からコールバックを指定するような場合、
export するGoファイルと、
ブリッジの実体を書くGoファイルを分ける必要があるみたい。

実体を書くだけで、
重複とエラーが出るので、
かなりわかりづらいけど、
今のcgoの仕様なのかな。

githubのcgoの
Function pointer callbacks

には、そんな例になってるので、
これが正解なんだろうな。

わかるまでは大変だな。
そして、どの言語も罠があるもんだな。


| | コメント (0) | トラックバック (0)

2016年12月 4日 (日)

makeの代わりにGradleを使ってみる

go言語を始めてみた。

いまだに、いいディレクトリ構成とか、
パッケージとかがよくわからないのだけど、

go build src/package/path

みたいな形でコマンドをうたないとだめっぽいのが分かった。

そして、GOPATH さんをうまいこと使わないといけないらしい。

毎回やるのが面倒くさいのは確かなので、
GOPATHの上書きと、ビルドコマンド実施を簡単にやりたい。
Makefileを作って、make コマンドを実行すればいいのはわかってる。

こんな感じだろうか。

export GOPATH=${GOPATH}:${CD}

all:
go build src/package/path

ただ、Windowsでやると、makeがないんだよね。
Windowsさんは、文字コードもあるし、
あまり使いやすいとは言えなくなってる。

ってことで、Gradleを使ってみようと思い立ったが、
結構、初心者には敷居が高いように感じてしまった。

単に、Makeはインストールしてないけど、
IntelliJ IDEAをインストールしてたので、
Gradleは入ってただけなんだけど・・・

Android Studioとかでは、設定の追加ぐらいはしてるが、
結局、プラグインが頑張ってる感じかな。
逆に、プラグインのマニュアルとにらめっこすることにはなる。

makeの代わりにする分には、
単純で良さそうだけど、
つまづいたなぁ。

Windowsなので、PATHのセミコロンとコロンの違いはあるけど、
こんな感じでいいらしい。
(IntelliJ IDEAで枠だけ作ってもらった)

task build << {

String goProjectName = "src/package/path"
exec {
Map env = new HashMap()
env.putAll(System.getenv())
String goPath = env["GOPATH"]
env.put("GOPATH", goPath + ";" + projectDir)
environment env
commandLine "go", "build", goProjectName
}
}

環境変数とか、もう少しうまくできるんだろうなぁと
思いつつもとりあえず、動かす方を優先。

プラグインがあればいいかもしれないけど、
自分で作る分には、もっとサンプルがほしいな。

それにしても、ココログのpre属性が変。
コード書くときにつらいなぁ。




| | コメント (0) | トラックバック (0)

« 2016年11月 | トップページ