読者です 読者をやめる 読者になる 読者になる

プログラムdeタマゴ

nodamushiの著作物は、文章、画像、プログラムにかかわらず全てUnlicenseです

近年神社に人が多いなぁと思うこの頃

雑記

あけましておめでとうございます。今年の抱負は再来年から本気出すです(・ω・)

元旦は皆さんはどのように過ごすんでしょうかね?

私は家族+犬とともに地元の神社に行ってあまりの参拝客の多さに何もせずに引き返してきました。別に、髪も仏も信じていませんし。死後の世界も知ったこっちゃなくて、信じているのは自らの脂肪のみです。あふん


さて、その地元の神社というのは、別に有名な神社とかじゃなくって、ほんとに地元に密着したというか、もう、本当に普通の神社。の、はずなんですが、なんと道にあふれるほどの行列。年々なんか人が増えている気がします。

単に私の地元の人口が増えてきているのか、それとも、SNS等の効果なのか、不景気で神頼みなのか、不毛で髪頼みなのか。


靖国神社の参拝客が年々増えているのと何らかの関係性はあるのでしょうかね?観測しているのが一つの神社しかないし、ちょっとググってみても資料が見当たらないので、ほかの神社や地域でどうなっているのか少し興味があります。




という感じで、今年からは、割と雑記的な内容や不確実だったり、すごく短い技術記事を増やしていこうかなと思います。


これまでこのブログは、それなりに調べてまとめた技術記事ばかりで、私事は書かない方針でやってきました。でも、大学生のころと違ってそんなに時間かけて書くがしんどくなって、更新回数がめちゃめちゃ減ってたんですよね。一つの記事が5000文字とか、1万文字とか多すぎかなと。私の妹の卒論が5万文字だったそうで、それでも多いほうだったそうですよ。なるべく、1000文字以内で収めたいですね。

あ、でも私クソニートなので時間だけは糞あるんですけどね。体重の問題ですね。間違えました、体力の問題ですね。

あとはツイッターがいつ潰れるのかわからん、ってのもありますね。ツイッターで済ましてたようなことも全部ブログのほうに持ってこようかなと。


後は今年の夏ぐらいにブログの内容をまとめたHPを作りたいなぁなんて考えています。これは体力いるからやるかどうかわからないけど。今のところあまりやる気なし。



というわけで、今年もよろしくお願いします。

なお、空白や改行、HTML含めてちょうどこの記事が1000文字です。だいぶ楽。

JavaFX9からPlatformに追加されるAPIについて

JavaFX

 この記事はJavaFX Advent Calender 2016の17日目の記事になります。
 前日はid:skrbさんのSooner or Later - JavaFX in the Boxでした。
 明日はid:aoe-tkさんです。


 前回今年最後とか言ったな。あれは嘘だ。

 はい、というわけで、なんとJavaFX Advent Calender 2016に二度も顔出しですよ。この引きこもりの王者クソニート様が。誰かお仕事くらさい

 というのもですね、JavaFX9で追加される新機能は前回紹介した内容以外にも、PulseListenerの追加やPlatform.startupやら、他にも小さな機能の追加があるのです。これらの使い道が私には思いつかなかったか、そもそもあまり興味を持っていなかったかなどの理由でスルーしたのですが、実はスルーしてた中でPlatformにNested Event Loop関連のAPIが追加になっていたようなのです!

 いや、もうマジでこれ知らなかった。知ってたら前回の記事に絶対追加してた。というわけで、興奮してついうっかり2回も顔出しすることにしました。ほんとスマンかった。

 なお、このことはJavaFX: New & Noteworthy(※PDF)にも書いてあります。しかし、Nested Event Loopの話がPulseとPulse Listenerのページの間に挟まれているんですよね。Pulseとかあまり興味ないせいか、読むのをすっ飛ばした様で気がつかなかったんですね~。アホですね~。

 というわけで、Platformに追加されるAPI(主にNested Event Loop)について解説します。



Platform.startup

 Application.launch使う限り使わないと思われるAPI。SWTとかSwingから使うときとかを想定している模様。

 JavaFX Application Threadを生成直後に引数に渡したRunnableを実行するとかそんな感じっぽいけど、普通に使う場面はないと思う。ないよね?思いつかなかったから前回もスルーしたんだけど。





Platform.requestNextPulse

 Scene.addPostLayoutPulseListener,Scene.addPreLayoutPulseListenerと共に追加されたPulse関連のAPI。次のPulseの要求が出来る。

 JavaFXには我々が扱うJavaFX Application Threadの他にPrism Render Threadという、画面描画用のスレッドがあるのですが、この描画スレッドとJavaFX Application Threadを同期するイベントがPulseになります。

 JavaFXってマウスイベントとかにNodeを追随させようとしても、妙にマウスの動きからNodeの動きがずれるのが、改善されたりしないかとか思ったけど、全くそんなことはなかったぜ。

 これらPulse関連APIの使い道は、今のところ私には思いつきません。PulseListenerの方はレイアウトにどれぐらい時間かかってるか、デバッグ的な使い方くらいかなぁ。私の頭じゃ。



 Pulseについての詳細は以下のページを参照してください。
docs.oracle.com


Nested Event Loop

 さて、今回の記事の本題です。といっても、実はこのNested Event LoopはJavaFX初期からあって、3年前の私の記事でも実はついでに紹介しています。
nodamushi.hatenablog.com


 大ざっぱに書くと、JavaFX Application Threadは通常以下のような処理をしています。

 Nested Event LoopのAPIを使うと、この流れを以下の図のように、複製することが可能になります。

 複製と言っても、新しいスレッドが走っているとかではなくて、単純に呼び出した関数の中でイベント処理のループが走り始めると言うだけです。


 この機能がおもにどこで使われているかというと、showAndWaitメソッドです。showAndWaitでウィンドウが閉じるまで処理を待機しても、JavaFX Application Threadは停止することなく、他の処理を続けることが出来ます。この時に使われているのがNested Event Loopです。


 今までは、Stage.showAndWaitからしかアクセスできなかったこのNested Event LoopのAPIが公開され、いつでもどこでも使えるようになります。
 一番簡単に思いつく使い道で、かつ、効果が高いのは、Stageのダイアログと同様にNode単位でのモーダルダイアログでしょう。

f:id:nodamushi:20161211183827p:plain


 今までは、このようなことを実現しようとしたら、次のような2つに分かれた手順が必要でした。

  1. なんらかのイベントハンドラ等からダイアログ用のNodeを作り、対象ノードの操作を不可能にする。(ここで最初のイベントハンドラの処理終了)
  2. ダイアログのYesやCancelといったボタンが押されたときに動作するイベントハンドラが、残りの処理を行い、ダイアログを消去する。

f:id:nodamushi:20161211183828p:plain

 しかし、Nested Event Loopを使うと、一つのイベントハンドラの中で処理が完結します。

f:id:nodamushi:20161211183829p:plain


 これはかなりプログラムを書くのが楽ですね。
 最近はJavaもラムダを導入したり、実質finalが導入されたりと色々工夫されて、イベントハンドラを書くのが楽になってきましたが、それでも処理が二分割されるようなプログラムを書くのって面倒くさいんですよね。
 処理が二分割で済めば良いですが、何回かダイアログを表示して、しかもそのダイアログ内容が途中で分岐するような処理だったら、面倒なことこの上ないですよね。

 一つのEvent Handlerで処理が済むというのは、それだけで実装面からも保守管理の点からもメリットです。




Nested Event Loopの使い方

Nested Event Loopを利用するには、以下のフィールド変数(ローカル変数は駄目)が必要です。

private Object waitKey = null;
  • waitKey: Nested Event Loopを解除するのに必要になるキー。なくしたらexitできないので要注意。final宣言してしまっても良い。

 フィールド変数を用意したら、後は以下の関数を定義しておけば良いでしょう。
 なお、基本的にはJavaFX Application Threadからしか操作しないので、waitKeyをvolatile等にする必要はありません。

private Object waitKey = null;

public boolean isWait(){return waitKey!=null;}

// 戻り値はintなどに決まっているなら、それに変換しても良い。
protected Object enterWait(){
  if(!isWait()){
    waitKey = new Object();
    Object result = Platform.enterNestedEventLoop(waitKey);
    return result;
  }
  return null;
}
// 引数のresultは上↑のresultになる。
protected void exitWait(Object result){
  if(isWait()){
    Object key=waitKey;
    waitKey=null;
    Platform.exitNestedEventLoop(key,result);
  }
}

 そしたら、後はこんな感じ。

//ダイアログのNodeを作成完了後
cancelButton.setOnAction(e->exitWait(0));
okButton.setOnAction(e->exitWait(1));
noButton.setOnAction(e->exitWait(2));

//何かにダイアログを追加
targetPane.getChildren().add( dialog );

//ダイアログのボタンが押されるまで待機
boolean isOK = enterWait() == 1;

//ダイアログを削除
targetPane.getChildren().remove( dialog );

if(isOK){//OKなら処理
…
}

 むろん、Dialogクラスのように、ダイアログ表示機能と待機機能を何かのクラスにまとめておいても良いでしょう。



 このように、Nested Event Loopを使えば、処理の途中でGUIを介した処理の結果が必要である場面の記述が簡単になります。色々夢が広がリングですね。


 というわけで、今度こそ、良いお年を。

JavaFX9が良い感じになってきた件

JavaFX

 この記事はJavaFX Advent Calender 2016の9日目の@arachan@githubさんの記事になるそうです。
 前日は@skht777さんのJavaFXで動くプロ生ちゃんデスクトップマスコットを作る - Qiitaでした。
 明日は@Yucchi_jpさんのHitInfoを少しだけ…です。


 はい、テンプレってこんなもんで良いんですかね。
 何か今年やたらと参加者が少なくて盛り上がってる風がないですよね。寂しいですな。
 普段はこういうのは眺めてるだけで、関連記事とか書いてても参加しない奴なんですが、人が少なくて寂しいので、珍しく参加してみようかと。




今、JavaFX9が静かに熱い

 
 世にJavaFXが出てからというもの、派手に目立ったことはないように思います。

 私はJavaFX2からさわり初めて、本格的にJavaFX8から利用をしていますが、これまでの印象はおおよそこんな感じ。

  • JavaFX Script : そんな子はいなかった
  • JavaFX2 : え?WebView?あぁ、Qtですか?
  • JavaFX8 : そんな子がいるような気がする


 なんというか、なんだかんだちょっと凝ったことをしようとするとすぐに制限に引っかかったり、実装を追ってハックするような真似をしないといけなくて、正直に言えば、Swingの方が使いやすいと思っていました。

 しかし、そんなこれまでのバージョン達であっても、登場前や直後は話題にする人は結構話題に挙げていたのですが、JavaFX9の話題は全く盛り上がっていないようです。「JavaFX9」でググってみても、2016年12月現在、id:aoe-tkさんの記事ぐらいしかトップに出てきません。なお、JavaFX8ではいろんな記事が出てきます。

 たしかに、新しいコントローラなどが一切追加されない、非常に地味なアップデートしかありません。派手な話題は描きにくいかもしれません。


 だが、私は言いたい。


 JavaFX9はこれまでJavaFXにあった不満を多く解決してきたと。

 これまであってもなくてもぶっちゃけ変わらない、実に微妙な立ち位置でしかなかったあのJavaFXが。
 あのJavaFXがついにJavaFX9で、僅かに痒いところに手が届かないところまで来たと!



 そんなJavaFX9の良いところをちょっとだけ、紹介いたします。


Skinが公開された!

 皆さんもご存じ、ControlのSkinがついに、ついに、ついにjavafx.scene.control.skinパッケージとして公開されます。
 ほんと、ついにですよ。なんで最初から公開していないんですかね。


 本当にジミーな内容ですね。これが目玉の変更点なんだから、まー盛り上がりませんわな。(´・д・`)


 でも、今まではちょっと見た目を追加したいとか、ちょっと機能を追加したい等々、「ちょっとレールから外れたい」ということをやろうと思えば、com.sunパッケージをいやーな気分で操作するか、多大なコストを払って実装するか(それでも結局com.sumパッケージに行き着くんだけど)しかなかったんです。
 いや、もう、ホント、これで大手を振って色々実装できますよ。


 でも、今回公開されるのはSkinだけで、Behaviorは公開されません。BehaviorはControlの機能、動作を決定する重要なクラスです。com.sunパッケージ時代のSkinだと、コンストラクタの引数にBehaviorが要求されていたんですが、これらがなくなってしまいました。


 じゃぁ、Behaviorそのものがパージされてしまったのかというと、そうでもなくて、結局com.sunパッケージとして残っています。で、コンストラクタの引数ではなくて、コンストラクタの中で生成するようになってしまいました。うわぁ~ぃ(泣
 一応、privateなメソッドでgetBehaviorとかがあるので、そのうち公開する気なのかも知れませんね。気長に待っています。



 あ、そういえば、(少なくとも私が読んだ)JavaFX8までのBehaviorの動作って、次のようになっていたと思うんです。

  1. マウスイベントなどを受け取る
  2. マウスイベントなどからアクションに対応する「String」に変換する
  3. BehaviorにStringを投げる
  4. Stringに対応する処理を実行する


 全部が全部って訳ではないと思いますが、少なくともTextAreaのBehaviorは次のような感じに変わったようです。

  1. Behaviorがマウスイベントなどを受け取る
  2. イベントをキーとして、登録しているラムダを取得する
  3. ラムダを実行する


 見えないところも整理が進んでいるようですね。



Tooltipが良くなった!

 去年、私はこんな記事を書きました。
nodamushi.hatenablog.com

 要約すると、ざっと以下の二つが不満点。

  1. 表示の遅延、表示時間が変更できなくて不満だ
  2. フォーカス持っていないウィンドウでもツールチップが表示される上に、画面の最上にウィンドウが表示されてうざい。


 しかし、JavaFX9からは次の3つのPropertyが追加されます。

  • showDelay : 表示するまでの遅延時間。デフォルトは1秒
  • showDuration : 表示時間。デフォルトは5秒
  • hideDelay : マウスがNodeから離れてからTooltipが消えるまでの時間差。デフォルトは0.2秒
Label label = new Label("マウスを置いているとポップアップするよ。");
Tooltip tooltip = new Tooltip("すぐに現れて消えないTooltip!");
tooltip.setShowDuration(Duration.INDEFINITE);
tooltip.setShowDelay(Duration.ZERO);
label.setTooltip(tooltip);
Scene s = new Scene(label);
stage.setScene(s);
stage.show();

f:id:nodamushi:20161208203008p:plain

 いや~、ツールチップが消えないからキャプチャするのも急がなくて良いし楽だね。


 でも、残念なことに二つ目の不満点である、フォーカスを持たないウィンドウでもポップアップする挙げ句、ウィンドウを最上位まで持ち上げてきてしまう問題点は解決されていませんでした。



 これ結構な問題だと思うんだけど、中の人達に認識されていないのかな?



 あ、あと、これの解決方法が新しく追加されていないかと色々見てたときに気がつきましたが、JavaFX9からは現在表示しているJavaFXウィンドウの一覧をWindow.getWindows()で取得できるようになりました。これ、地味に嬉しい。
 私、これを自前で実装してたからね。

ObservableList<Window> windows = Window.getWindows()



子要素の順番を入れ替えなくても表示順序を変えられる!

 いままで、重なっている子要素の表示上下関係を入れ替えようと思ったら、getChildren()で子要素のリストを取得して、並びを入れ替えるしかありませんでした。
 Swingだったらzindexで変化するのに!と思っていたら、ついにJavaFX9でViewOrderプロパティが出来ました!


 ViewOrderは小さいほど手前に来ます。0が基準値です。負数も可能の様です。
 同じViewOrderの場合は子要素のリストに挿入された順番が反映される。

  Circle c1 = new Circle(100, 100, 100, Color.AQUA);
  Circle c2 = new Circle(100, 150, 100, Color.RED);
  Circle c3 = new Circle(300, 100, 100, Color.AQUA);
  Circle c4 = new Circle(300, 150, 100, Color.RED);
  pane.getChildren().addAll(
          c1,c2,//アクア色の円は赤より下
          c3,c4 //アクア色の円は赤より下
  );
  //c3,c4の表示順序を入れ替え、アクア色の円を赤の上に持ってくる
  c3.setViewOrder(0);//※0は初期値です
  c4.setViewOrder(1);

 実行結果の下図をご覧下さい。右側の二つの円はアクア色の円が赤色の円より上に表示され、左側の二つとは重なり方が変わっています。






念願の行番号付きテキストエディタが使える!

 JavaFX9で行番号付きのピュア(com.sunパッケージやリフレクションを利用しないという意味)なエディタが使えるようになります。
 主に私が作っていたアプリケーションの関係でどうしても欲しかったけど諦めてListViewとTextEditorを行き来することでなんとなくそれっぽい動作で諦めた、あの行番号付きエディタが!当時の私が知ったら号泣して喜んだでしょう。




 まぁ、これ、私が実装したんだけどね。ソースコードはGistにおいておきました。
JavaFX9でTextAreaに行番号がついたTextAreaを作ってみた · GitHub


 さて、先にも書いたように、ついにJavaFX9で今まで秘匿されてきたSkinの実装が公開されました。まだまだ公開して欲しいAPIはいっぱいあるのですが、重要なAPIは結構出そろってきました。その中の一つがText関連のAPIです。
 座標とTextの文字の位置を紐付けるHitInfoクラスTextInputControlSkinのgetCharacterBoundsメソッドが公開されたことにより、文字のインデックスとTextシェイプの座標内の対応が取れるようになりました。

 今回はこの二つを利用して行番号を表示すべき位置を取得し、TextAreaに行番号を付けてみました。


手順

 いい加減記事が長いので、詳細はソースコードを適当に眺めていただくとして、実装したものはザックリと説明すると以下の3手順です。

  1. まずは、TextAreaの文字列を行単位に分割する
  2. TextAreaの左上の座標と左下の座標の挿入位置を検出し、その範囲に入る行について3を処理する
  3. 各行の行頭文字のBoundsを取得し、その位置に会うように行番号を配置(空行などは上手いこと何とか処理する)


 まず、1の文字列を行単位に分割するのは別に説明は要らないでしょう。
 3の、表示位置の取得は、各行の行頭文字インデックスが分かれば、getCharacterBounds(index)で簡単に取得可能です。で、問題は2でした。


HitInfoの落とし穴

 さて、TextInputControlSkinから挿入位置を取得するには、getIndex(x,y)でHitInfoを取得するか、getInsertionPoint(x,y)で取得します。これらはどっちも結果は同じです。
 さて、画面左上の座標の挿入位置と、左下の座標の挿入位置を検出したいのだから、単純に考えるとこうなるはず。

int topInsert = getInsertionPoint(0,0);
int bottomInsert = getInsertionPoint(0,height);


 私は最初これで実装して、行番号が表示されなくて悩みました。

 これで取得されるtopInsertとbottomInsertは、topInsertは0で固定、bottomInsertは-1もしくは、画面の大きさ依存の値で飽和するかになります。

 と、言うのもここでの(0,0)や(0,height)の座標は、TextAreaの座標ではなく、あくまでText内での座標を指しています。従って、Textの原点位置での挿入場所は当然最初の0になってしまうし、(0,height)と指定しても、スクロールバーとか考慮されていないので、ある値で飽和してしまう。-1が返ってくるのは、(0,height)の範囲にTextシェイプが存在していなかったからかも知れないが、これに関しては詳しくはまだ追っていません。

 従って、目的のことがしたい場合は次のようにオフセットを考慮してあげる必要があります。

double offsetY = getCharacterBounds(0).getMinY();
int topInsert = getInsertionPoint(0,-offsetY);
int bottomInsert = getInsertionPoint(0,height-offsetY);
if(bottomInsert < 0)bottomInsert = textArea.getLength();

 最初の文字のY座標をオフセットとして引いてやると、上手くいく。
 bottomInsertは-1になる可能性があるから、-1になっていたら、ひとまずTextAreaの文字列長に設定してやれば良いと思われる。



 まぁ、これはHitInfoの落とし穴というよりは、getIndex(x,y)の仕様ミスだと思うけど。
 実際に公開するまでに変わったりするかもね?変えた方が良いと思うよ?


みんなJavaFX9使おうぜ!

 はい、というわけで、どうでしたでしょうか?
 これまでは、「はぁ~、これもできねぇのかよ」とか、「あ~、動きがもっさり」とか、「JavaでもQtでよくね?Swingでよくね?」「男なら黙ってCUI」などなど、散々(主に私に)捻られてきたJavaFXですが、かなり良い子になってきたと思います。

 Swingとは使い勝手がだいぶ違うので、今までSwingをやってたって人だと、それなりに学習コストを払わなくてはなりません。しかし、それを払うだけの価値はJavaFX9でそれなりに出てきたと思います。


 まだ画面がなーんかちらつくとか、3DShapeとかいらねーからOpenGL使わせろとか、シェーダー書かせろとか、KyeEventが使いにくいとか、Behaivor公開しろとか、言いたいことは山ほどありますが。まぁ、要求なんて何年たっても0になることはないので、焦ってもしょうがないですね。



 ぜひ、この機会にJavaFXを本格的に使いはじめてみませんか?ということで、今回の記事はおしまいです。

 最後まで読まれた方がいましたら、長々とおつきあいただきありがとうございました。





 実は、この記事は5日前に最後の行番号付きTextAreaの話だけで公開しようとしてたんです。でも、ついでにAdventカレンダーに登録してやろっかなーと思ったところ、明日のYucchi_jpさんと内容被りそうだったので、誤魔化すために色々追加したらこんなに長くなりましたとさ。も~、今年のブログ更新はこれで最後でいいな。良いお年を。

Javaにlambda修飾子が欲しい

JAVA

 機能(関数)をクラス内に実装せずに、外部に委譲することがある。単純な例ではこんな感じ。

public class Action{
  private Runnable action;
  public void setAction(Runnable action){this.action = action;}
  public void action(){  if(action != null) action.run(); }
}


 Runnableのように引数を取らないような関数なら別に問題ないが、大概の場合は委譲元のインスタンスを引数にとりたい。
 すると、こうなる。

public class Action{
  private Consumer<Action> action;
  public void setAction(Consumer<Action> action){this.action = action;}
  public void action(){if(action!=null)action.accept(this);}
}




委譲は継承が面倒

 機能の委譲をしている場合でも、データの拡張などでクラスを継承する方が合理的な場合もある。

public class Action{
  private Consumer<Action> action;
  public void setAction(Consumer<Action> action){this.action = action;}
  public void action(){action.accept(this);}
}
class ActionB extends Action{
  public int b;
}

 委譲した関数が、ActionBにしか対応する必要がない場合、このままだと一々キャストが発生する。

actionB.setAction(a->{
  ActionB b = (ActionB)a;//キャストめんどい
  System.out.println(b.b);
})   

 かといって<? extends Action>にしておくのも上手くない。

public class Action{
  private Consumer<? extends Action> action;
  public void setAction(Consumer<? extends Action> action){this.action = action;}
  public void action(){if(action!=null)((Consumer)action).accept(this);}
}
public class ActionB extends Action{
 public int b;
}
public class ActionC extends ActionB{
 public int c;
}


ActionB actionB;
actionB.setAction((ActionB b)->System.out.println(b.b));//ActionBの型を書くのめんどい
actionB.setAction((ActionC c)->System.out.println(c.c));//これも通る





安全だし、ラムダで型を書かなくて良い楽な方法もあるにはある

 ただし、マジでめんどい

public class Action <V extends Action<?>>{
  private Consumer<? super V> action;
  protected void setAction(Consumer<? super V> action){this.action = action;}
  public void action(){if(action!=null)((Consumer)action).accept(this);}
}

class ActionB<V extends ActionB<?>> extends Action<V>{//<V extends ActionB<?>>がめんどい
  int b;
}
class ActionC<V extends ActionC<?>> extends ActionB<V>{//<V extends ActionC<?>>がめんどい
  int c;
}


ActionB<?> actionB = new ActionB<>();//<?>と<>を書くのがめんどい
actionB.setAction(b->System.out.println(b.b));//ラムダ式は楽
actionB.action();




ならば、こう書ければ楽なはずだ

 そもそも人間がガンガるから面倒くさいのだ。コンパイラが頑張れば良いのだ。

 たとえば、以下のようなアノテーションとジェネリックを書いておけば、Setter,Getter,メソッドコールの部分は自動的にJavaコンパイラが頑張ってくれればいいんじゃないのかな。

public class Action{
  @TransferMethod //委譲メソッドであること宣言する的な
  private Consumer<this> action;
}
public class ActionB extends Action{
  public int b;
}

ActionB actionB = new ActionB();
actionB.setAction( b -> System.out.println(b.b) );
actionB.action(); 

 

lambda修飾子があればもっと楽なはずだ

 だが、ここまで考えて気がついたのだが、Consumer<this>も書くのがめんどい
 Consumerならまだ楽だが、引数が増えたときは考えたくない。


 コンパイラが頑張るなら、もはやこれで良いはずだ。

public class Action{
  public lambda void action();
}
public class ActionB extends Action{
  public int b;
}

ActionB actionB = new ActionB();
actionB.action = b -> System.out.println(b.b) ;
actionB.action(); 

 なんと、実に楽だ。ついでにdefaultも使えるとさらに良いかもしれない。

public class Action{
  public default lambda void action(){System.out.println("Action");}
}

 マルチスレッド対応のためにvolatileとかsynchronizedとか修飾できても楽しいかも知れない。


 というわけで、nativeとか、abstractみたいな感じで、lambda修飾子があるとラムダがよりいっそう楽しそうな気がするのですが、どうでせうか。Lombokみたいな感じで実現できないだろうか?
 絶対、どっかの誰かが提案してるんじゃないかな?

jshellを自分のプログラムに組み込みたかった

JAVA

はい。タイトルの通りです。しょーもないことしてました。


jshell

JDK9から付属することになっているちまたで話題のJavaのREPL。
私は全く興味がなかったんですけど、ふと思ったんですよ。これ自分のプログラムに組み込めないかな?


GUI系のプログラムは毎回実行して動作確認して終了して直して実行して………が面倒くさいんですよ。
JavaScriptとかGroovyとかを実行できるような簡易GUIを搭載したりしてそこでチマチマ弄れるようにしたりしてるんですけど、これをjshellに置き換えられないかな?と調べてみました。


自分のプログラム内部でJShellを作成して実行する

JShellは以下のような感じで作成できるようです。

try(JShell shell = jdk.jshell.JShell.create()){
}

 というわけで、以下のようなコードを試してみました。

package test;

import java.util.List;
import jdk.jshell.*;

public class TestApplication {
    
    public static String PRINT = "------Not Change-------";
    
    public String method(){//JShellでこのメソッドを呼ぶ
        System.out.println(PRINT);
        return "Test Application";
    }
    
    public static void main(String[] args){
        PRINT = "Print this text?";//ここでPRINTを入れ替えている
        try(JShell shell = JShell.builder()
                //err,outで出力先を変えられる
                .err(System.out)
                .out(System.err)
                .build()){
            shell.addToClasspath(System.getProperty("java.class.path"));
            List<SnippetEvent> evs =  shell.eval("new test.TestApplication().method();"); 

            for(SnippetEvent e:evs){
                if (e.causeSnippet() == null) {
                    switch (e.status()) {
                        case VALID:
                            if(e.value()!=null)
                                System.out.println("eval result = "+e.value());
                            else
                                System.out.println("Success.(no result)");
                            break;
                    }
                }
            }
        }
    }
}

 もし、私の望み通りの動作をするならば、「Print this text?」という文字が出力された後に、「eval result = Test Application」となるはずです。

結果

f:id:nodamushi:20161130221852p:plain

 ………残念でした。------Not Change-------とプリントされてしまいました。
 つまり、JShellエンジンではmain関数は実行されていないことになっているのです。(main関数の一番最初にPRINT変数を入れ替えている)


 どうもJShellは実行時にもう一個別のJVMを立ち上げて、そちらをリモートで操作するような処理をしているようです。
 上記のプログラムのmethod()でsleepするように書き換えてから実行すると、2個Javaのプロセスが増えるのを確認できます。

f:id:nodamushi:20161130221853p:plain


それでもjshellを組み込みたい

>jshell -cp 必要なクラスパス

jshell>test.TestApplication.main(new String[0]);

ん~~………

Java9のVarHandleを使ってみた

JAVA

 AtomicIntegerを使う必要が出てきた場面で、ふとVarHandleのことを思い出し、ちょっと試してみました。
 試したコードは最後に載せておきますが、やってみたことはこんな感じ。

  • staticなint型変数のVarHandleの取得
  • setとsetVolatileの実行
  • int,volatile int,int(synchronized),AtomicIntegerで並列カウントし、結果の出力と簡易的な時間の計測



VarHandleの取得

 まずこの時点でつまった。JavaDocに書いておいてよ、取得方法。
 たぶん、こんな感じ。まず、Hogeにstaticなaと、フィールドメンバのbがあるとする。

public class Hoge{
  static int a;
  int b;
  int[] arr;
}

 これの取得はたぶん、こんな感じ。(後述するテストコードではlookup().in(Test.class)というのをキャッシュしてから実行してる)

java.lang.invoke.MethodHandles.lookup()
                .findStaticVarHandle(Hoge.class,"a",int.class);
java.lang.invoke.MethodHandles.lookup()
                .findVarHandle(Hoge.class,"b",int.class);
//配列の「要素」を操作したい場合は以下のメソッドでVarHandleを取得する
java.lang.invoke.MethodHandles.arrayElementVarHandle(int[].class);




代入

 VarHandleのJavaDocを眺めていると、値を代入する単純なメソッドはsetとsetOpaque,setReleaseとsetVolatileがあるっぽい。

  • setは普通の代入の代わりっぽい。
  • setOpaqueはプログラムオーダーは保証されるけど、スレッド間のメモリの整合性を考慮しない普通の代入?
  • setReleaseはリオーダーがされないことが保証されるっぽい。setReleaseを使えばJavaでダブルチェックロッキングパターンが実装可能な感じかな?
  • setVolatileがvolatileが付与されているかのごとく代入するっぽい。setReleaseとの差はよく分からん。

 まぁ、よくわからんけど、volatile修飾子がついていてもsetで代入できるし、volatile修飾子がついていなくてもsetVolatileが実行できるっぽい。

        //------ set COUNTER ----------------------
        System.out.println("---------Method set------");
        COUNTER_HANDLE.set(10); // volatileではない変数のハンドル
        V_COUNTER_HANDLE.set(10);//volatileな変数のハンドル。setVolatileじゃなくても代入可能

        System.out.println("---------Method setVolatile------");
        COUNTER_HANDLE.setVolatile(0);//volatileではない変数のハンドル。setじゃなくても代入可能
        V_COUNTER_HANDLE.setVolatile(0);////volatileな変数のハンドル。

 なお、staticな変数でない場合は、以下のようにする

handle.set(obj,0)

 配列の要素を操作したい場合は、以下のようにする

handle.set(arr,index,value)




カウンターの測定

 以下の4つの条件でカウンターを動かし、実行時間の測定と、最終結果が正しいかどうかを確認する。

  • volatileな変数をVarHandleでインクリメント
  • volatileな変数をVarHandleでインクリメント
  • 非volatileな変数をsynchronizedした関数でインクリメント
  • AtomicIntegerでインクリメント

 ちなみに、2016/11/28日現在のJDK9のソースコードではAtomicIntegerはまだUnsafeを使っているようです。

 まずは、シングルスレッドで20億回インクリメントして測定したもの。(※後述のソースコードには存在していない

内容 最終結果 計測時間
volatileな変数をVarHandleでインクリメント 2000000000 約10秒
volatileな変数をVarHandleでインクリメント 2000000000 約10秒
非volatileな変数をsynchronizedした関数でインクリメント 2000000000 約40秒
AtomicIntegerでインクリメント 2000000000 約10秒

 
結果からシングルスレッドではVarHandleとAtomicIntegerの速度は同等であることが言える。


 次に200万回インクリメントする関数を、1000スレッド起動して実行し、最終結果と実行時間を計測した。実行時間の計測には本当ならJVMが安定するまでの時間等を考慮するべきだけど、結構時間かかる処理だから誤差でしょってことでその辺は考慮していない。

内容 最終結果 計測時間
volatileな変数をVarHandleでインクリメント 2000000000 約40秒
volatileな変数をVarHandleでインクリメント 2000000000 約40秒
非volatileな変数をsynchronizedした関数でインクリメント 2000000000 約38秒
AtomicIntegerでインクリメント 2000000000 約40秒

 おんや?volatileでなくても結果が正しく、また、何度実行してもsynchronizedが他のよりも2,3秒早いという結果になりました。
 前者についてはJavaDocを読んでみると、VarHandle.getAndAdd()が内部でVarHandle.setVolatile()を使っているようで、volatileがついていなくてもvolatileがついているのと同等に扱われたためかと思います。
 後者については、AtomicIntegerとかVarHandleはCPUが常に100%になるのにたいして、synchronizedするとスレッドが待機状態になるから、あまりCPUリソースを使わないのが原因かと思います。
 
 これではちょっと結果としてどうかという気がしたので、条件を変更して250000000回インクリメントする関数を8スレッド動かしてみました。この位のスレッド数なら、通常でもあり得るでしょう。

内容 最終結果 計測時間
volatileな変数をVarHandleでインクリメント 2000000000 約38秒
volatileな変数をVarHandleでインクリメント 2000000000 約38秒
非volatileな変数をsynchronizedした関数でインクリメント 2000000000 約64秒
AtomicIntegerでインクリメント 2000000000 約38秒

 おんやぁ?私の予想に反して、synchronizedがえっらい遅くなっただけですね。(VarHandleとかがもうちょっと早くなるかと思ってた)
 ま、まぁ、synchronizedが遅いという結果が得られたので良しとしましょう。

 上記の結果をまとめると以下のようになる。

  • AtomicInteger(Unsafeを使用)とVarHandleは速度が同等
  • volatileであってもなくても、VarHandle.getAndAddが中でsetVolatileを使っているためか結果は同じ
  • volatileであってもなくても、VarHandleを使った場合実行時間は同じ



使ってみた所感


 ぶっちゃけ使いにくい。使うの面倒くさいわー。AtomicIntegerで良いと思うわー。


 かつて、以下↓のような構文が使えるようになるとか何とか聞いた気がしたんだけど、早くプリーズ。

 field.volatile.incrementAndGet();



テストコード

 

import java.lang.invoke.*;
import java.util.concurrent.atomic.*;

public class Test{

    private int a = 0;
    private int[] arr = new int[10];
    private final VarHandle aHandle,arrHandle;

    public Test(){
        VarHandle ahandle=null,arrhandle=null;
        try{
            ahandle=MethodHandles.lookup().findVarHandle(Test.class,"a",int.class);
            arrhandle=MethodHandles.arrayElementVarHandle(int[].class);
        }catch(Throwable t){
            t.printStackTrace();
        }
        this.arrHandle =arrhandle;
        this.aHandle =ahandle;
        aHandle.set(this,100);
        System.out.println("a = "+a);
        arrHandle.set(arr,5,100);
        System.out.println("arr[5] = "+arr[5]);
    }



    private static int COUNTER=1234;
    private static final VarHandle COUNTER_HANDLE;//COUNTERのハンドル

    private static volatile int V_COUNTER=5678;//※ volatileを付加
    private static final VarHandle V_COUNTER_HANDLE;//V_COUNTERのハンドル

    private static int S_COUNTER = 0; // synchronizedな関数でカウントする為の変数

    private static final AtomicInteger ACOUNTER=new AtomicInteger(0);



    //----  VarHandleの初期化。たぶんこんな感じ---------
    static{
        VarHandle handle = null,vhandle=null;
        try{
            MethodHandles.Lookup lookup = MethodHandles.lookup().in(Test.class);
            handle = lookup.findStaticVarHandle(Test.class,"COUNTER",int.class);
            vhandle = lookup.findStaticVarHandle(Test.class,"V_COUNTER",int.class);
        }catch(Throwable t){
            t.printStackTrace();
        }
        COUNTER_HANDLE = handle;
        V_COUNTER_HANDLE = vhandle;
    }
    //-----------------------------------

            


    public static void count(){
        COUNTER_HANDLE.getAndAdd(1);
    }

    public static void vcount(){
        V_COUNTER_HANDLE.getAndAdd(1);
    }

    public static synchronized void scount(){
        S_COUNTER++;
    }



    public static final int LOOP = 2000000000/8;
    public static final int THREADS = 8;
    public static void run1(){
        for(int i=0;i<LOOP;i++){
            count();
        }
    }
    public static void run2(){
        for(int i=0;i<LOOP;i++){
            vcount();
        }
    }
    public static void run3(){
        for(int i=0;i<LOOP;i++){
            scount();
        }
    }
    public static void run4(){
        for(int i=0;i<LOOP;i++){
            ACOUNTER.incrementAndGet();
        }
    }


    public static void main(String[] args){
        new Test();


        showCounter();
        showVCounter();
        
        //------ set COUNTER ----------------------
        System.out.println("---------Method set------");
        COUNTER_HANDLE.set(10);
        V_COUNTER_HANDLE.set(10);//setVolatileじゃなくても代入可能
        showCounter();
        showVCounter();
        System.out.println("---------Method setVolatile------");
        COUNTER_HANDLE.setVolatile(0);//setじゃなくても代入可能
        V_COUNTER_HANDLE.setVolatile(0);
        showCounter();
        showVCounter();


        System.out.println("---------Run1 start------");
        long t = System.currentTimeMillis();
        Thread[] ths  = new Thread[THREADS];
        for(int i=0;i<THREADS;i++){
            ths[i] = new Thread(Test::run1);
            ths[i].start();
        }
        for(int i=0;i<THREADS;i++){
            try{
                ths[i].join();
            }catch(InterruptedException e){}
        }
        t = System.currentTimeMillis() - t;
        showCounter();
        System.out.println("Time = " + t/1000d);


        System.out.println("---------Run2 start------");
        t = System.currentTimeMillis();
        for(int i=0;i<THREADS;i++){
            ths[i] = new Thread(Test::run2);
            ths[i].start();
        }
        for(int i=0;i<THREADS;i++){
            try{
                ths[i].join();
            }catch(InterruptedException e){}
        }
        t = System.currentTimeMillis() - t;
        showVCounter();
        System.out.println("Time = " + t/1000d);



        System.out.println("---------Run3 start------");
        t = System.currentTimeMillis();
        for(int i=0;i<THREADS;i++){
            ths[i] = new Thread(Test::run3);
            ths[i].start();
        }
        for(int i=0;i<THREADS;i++){
            try{
                ths[i].join();
            }catch(InterruptedException e){}
        }
        t = System.currentTimeMillis() - t;
        System.out.println("S_COUNTER="+S_COUNTER);
        System.out.println("Time = " + t/1000d);

        System.out.println("---------Run4 start------");
        t = System.currentTimeMillis();
        for(int i=0;i<THREADS;i++){
            ths[i] = new Thread(Test::run4);
            ths[i].start();
        }
        for(int i=0;i<THREADS;i++){
            try{
                ths[i].join();
            }catch(InterruptedException e){}
        }
        t = System.currentTimeMillis() - t;
        System.out.println("ACOUNTER="+ACOUNTER.get());
        System.out.println("Time = " + t/1000d);
        
    }


    public static void showCounter(){
        System.out.print("COUNTER =");
        System.out.println(COUNTER_HANDLE.get());
    }
    public static void showVCounter(){
        System.out.print("V_COUNTER =");
        System.out.println(V_COUNTER_HANDLE.get());
    }

}

組み込み屋初心者さんのためのコーディング技術(C言語)

C/C++

 私が最近生存している業界は、アナログ最後の砦と言われているほどIT化の遅い世界ですが、ここ数年でジワリジワリとソフトの力が増してきている、という業界です。
 あ、なお、お前のブログ読んでるとまるで働いているみたいだな!とか言われましたが、私はクソニートですので誤解なきよう。お仕事くらさい。

 で、そんなもんですから、今までアナログ屋だった人が突然ディジタル屋に突っ込まれたりするわけで、コーディング技術何それおいしいの?状態だっりします。
 そんな方々が書くCコードを見ると、ひたすらコピペの連続のような力業プログラミングだったりするわけです。


 そんな方々に送るちょっとしたアドバイス記事です。別段目新しかったり、難しい内容はありません。

 なお、この記事におけるコーディング技術は主に「保守管理」に関わる様な技術を指しており、アルゴリズムの話や、超絶技法の様な話は含んでおりません。




コーディング技術は何故必要なのか?

 そもそも、なぜコーディング技術が組み込み屋に必要なのでしょうか?
 大規模組み込みならまだしも、ちっこいマイコン相手にしているだけだと、コーディング技術とかただの理想論にしか聞こえないかも知れません。そういった方々にとって大事なことは「動くこと」だけになっています。

 むろん、動くことは何よりも重要です。どれほど素晴らしく、美しいコードであっても、実機で動かなければウンコほどの価値もありません。
 しかし、「簡単に書く」、「簡潔に書く」、「わかりやすく書く」という観点が抜けてしまうと、何故ソフトウェア化するのか?の意義の一つが減ってしまいます。

 ソフトウェア化する意義とは何か?
 今、我々の業界で進んでいるソフトウェア化は、基本的にはハードをソフトで置き換えているだけです。となると、現状あるソフトウェア化のメリットは、「部品点数削減」これだけです。
 ソフト化による製品開発期間の短縮?「今」のあなた方はそれが出来るほど、今のあなた方にソフトの技術がありますか?
 ディジタル化することによる、アナログで出来ない高性能化?それが既に達成されている業界では最も重要なことだと思いますが、我々の業界ではまだ理想論であり、現状は物にするほど理論は完成されていません。それは数年という期間を経て実現することです。もし、それが本当にソフトウェア化のキーワードであるのであれば、短い開発のサイクルで製品化するようなプロジェクトではなく、数年という長い期間を経て市場に出すべきでしょう。


 それでもなお、今、慣れないディジタル技術を用い、短い開発期間で製品開発を強いられている意義は、部品点数削減のためです。
 たしかに、ソフト化することで、コンデンサの数が減れば、物理的な耐久性の向上、部品コストの削減が図れます。しかし、ここで一つ考えなければならないのは、製品の部品は減っていないということです。なぜなら、物理的部品が減った代わりに、プログラムコードという部品が増えたからです。
 コードの価値というのは低く見積もられがちですが、コードは部品であり、使わないコードや重複するコードがあれば、それは在庫です。
 このコードという部品をどう管理するのか?これは当然考えなくてはならない事です。

 果たして、製品コードに問題があると判明したとき、貴方はそのコードを後で見返して、すぐにどこに問題があるかわかるでしょうか?貴方が修正するならまだしも、貴方が忙しくて他人に頼む場合、そもそも貴方がそこにいなくなっていた場合、他人はすぐにどこに問題があるか分かるでしょうか?
 問題がなかったとしても、別な製品でそのプログラムを、使い回したい場合、それがすぐできますか?

 これらが出来る場合、当然出来ない場合に比べて製品のコストが下がることになります。逆にこれが出来ない場合、もしかしたらソフト的なコストで、むしろ製品コストが増加することすら、あるかも知れません。


 そこで必要になるのが、如何に簡潔に、綺麗に、わかりやすく書くかというコーディング技術です。


コーディング技術なんて捨てて良い


 コーディング技術?残念だが、そんなものは糞食らえだ。今すぐ捨てて貰って構わない。


 さっきと言っていることが、真逆で申し訳ないのだが、やはりこれは最初に書いておく必要があると思う。コーディング技術に頼ってはならない。


 組み込みの世界はどうしても、使えるリソースが少ないです。リソースというのは、メモリであったり、実行ステップ数(実行時間)だったり、得られる情報などを指します。
 これらの条件と、コーディング技術は相反する場合があります。そういった場合、迷うことなくコーディング技術を捨てて、泥臭くて汚い力業の世界に持ち込んでください
 如何に綺麗に書くかを悩むだけ時間の無駄です。

 ステップ数が足りない?そうか、そこの関数呼び出し止めて展開しようか。そのループを展開しようか。ポインタ操作の最適化しようか。そこの計算アセンブリにしようか。
 メモリが足りない?なら、この変数とあの変数は同時に使わないから、同じ変数にしよう。
 組み込みでは、どうしてもこういう事態が発生します。


 わかりやすく書くコーディング技術は大切なことですが、捨てて構わないものです。
 大切なのはバランス感覚です。


早すぎる最適化はしない。コーディング技術を大切に

 関数呼び出しをやめて展開する。ループを展開する。ポインタの最適化。メモリ配置の最適化。
 こういったものを行いたいという欲求は、早すぎる最適化を呼んでしまいます。こういった手段は、最後の奥の手です。
 最適化をしなくても動くのであれば、最適化などする必要がありません。汎用性を失うだけです。

 例えば、設定する変数A、B、Cがあり、A,Cが隣り合うアドレスだったとしましょう。
 このとき、「A=1;B=2;C=3;」よりも、「A=1;C=3;B=2;」の方が上手い具合に最適化される可能性が高いですね。
 コンパイラが信用できないなら、こう書けば完璧です。

char *p = &A;
*p = 1;
*(p+1)=3;
B=2;

 さて、このコード、使用しているマイコンの次バージョンを使用するときにも使えるのでしょうか?
 ソースコードレベルでの後方互換があったとしても、アドレスまでは完全に同じとは限りません。そうなると、このコードは再利用は出来ない在庫コードとなります。

 省メモリ、小ステップは確かに大切なことですが、クリティカルな問題にならない限りは、最初は放っておいても良いのです。
 大切なのはバランス感覚です。



数値はdefineで名前を付けましょう

 マジックナンバーと言う言葉をご存じでしょうか?マジックナンバーとは、処理を知っている人だけが理解できる、プログラム中に現れる他人から見たら謎の数値のことです。
 組み込みではこのマジックナンバーが大量に現れます。

MODULE0 = 0x6c;
MODULE0OV = 1234;
MODULE0EN = 0x71;

 さて、この0x6c,1234,0x71って何でしょうね。意味が分からないですね。
 これを理解するには、マイコンの仕様書を片手に各ビットが何なのかを調べなくては、読むことが出来ません。吐き気がします

 それを回避するためにこんなコメントが書かれてたりします。

MODULE0 = 0x6c; // MODULE0の結果転送先を~~に切り替え。Event出力あり。クロックはクロック1
MODULE0OV = 1234; // オフセット値
MODULE0EN = 0x71; // MODULE0をイネーブル。割り込みOn

 確かに少し読めるようになりました。しかし、根本的に何も解決していません。
 例えば、MODULE0の結果転送先を変えたいとき、0x6cはどう数値を弄れば良いのでしょうか?

 なに?仕様書をみろ?
 バカじゃないの?マイコンの仕様書とか分厚いのに、ちょっと数値弄るためだけに何度も見直すなんて。


 こういう場合は、数値の意味を分解します。
 例えば、クロックを決定しているのが、上位2bit(7,6bit)、Event設定がその次のビット(5bit)、4bitは例えばモード切り替えで、下位4bitが転送先設定としましょう。
 すると、次のように意味単位で数値を分離できます。

MODULE0 = 0x40 | 0x20 | 0x00 | 0x0c;//クロックは1 | Eventを送る | モードは0 | 転送先は~~

 別にこの場合は+(加算)でも構わないのですが、|(ビットor)を良く使います。どのみち、組み込み屋はビット演算からは逃げられないので、諦めてビットorに慣れてください。

 さらに、これらの数値にdefineで名前を与えると次のようになります。

#define MODULE_CLOCK0 0x00
#define MODULE_CLOCK1 0x40
#define MODULE_CLOCK2 0x80
#define MODULE_CLOCK3 0xc0

#define MODULE_SEND_EVENT 0x20
#define MODULE_UNSEND_EVENT 0x00

#define MODULE_MODE0 0
#define MODULE_MODE1 0x10

#define MODULE_TRANSFER_C 0x0c

MODULE0 = MODULE_CLOCK1 | MODULE_SEND_EVENT | MODULE_MODE0 | MODULE_TRANSER_C;

 随分わかりやすくなりました。もし、モジュールからイベントを送りたくなくなった場合は以下のように変えれば良いだけです。

MODULE0 = MODULE_CLOCK1 | MODULE_UNSEND_EVENT | MODULE_MODE0 | MODULE_TRANSER_C;


 ちなみに、このように分離することで、無駄な処理が入るから使えないと思うかも知れませんが、0x6cと各コードとこのコードは全くコンパイル結果は同じです。
 定数式は最適化オプションを切っていてもコンパイラが勝手に計算してくれます。





 え、マイコン対応コンパイラがガチで計算してくれないドマイナー糞コンパイラだって………?
 どれほど安いのか知りませんが、そのマイコン使うの辞める事を提案するところから始めませんか?



コメントを書く様にする

 コードを書いた時点ではわかっていることでも、3日もすればすぐに分からなくなるものです。
 明日の自分は他人です。何も知らない人に優しく説明するように、明日の自分のためにコメントと言う名のドキュメントを残しましょう。

 特に、グローバル変数や関数などには、使い方などを残しておくのが吉です。
 呼び出し条件は?この引数の意味は?引数に渡して良い値は?渡してはならない数値は?などはキッチリ残しておかないと、絶対後悔します。
 Javadocの様に後でドキュメント化する場合は、Doxygenを使うと良いでしょう。

/*!
 * 1分の内にHOGE割り込みが起こった回数を記録するためのカウンタ
 * HOGE割り込み関数とタイマの関数以外から触ることを禁ずる
 */
volatile unsigned int hoge_interrupt_counter;

/**
 * @fn
 * モジュールの再初期化をする。
 * モジュールが既に動作しているときのみ呼び出すこと。
 * それ以外で呼び出した場合の動作は保証しない。
 *
 *
 * @param mode 0,1,3だけ。2,4は禁ずる。この責任は呼び出し側にあるとする。
 * @param offset_value 飽和処理はこの関数が責任を持つ。
 */
void reinitModule(char mode,char offset_value)
{


 なるべく呼び出し元の責任が減るように関数内で判断するのが良いのですが、組み込みだとそうもいかないこともあると思いますので、責任関連は絶対残してください。




コメントを書かない様にする

 ソースコード中に現れるコメントは大別すると以下の3つしかありません。

  1. 有害なコメント
  2. いずれ有害になるコメント
  3. ソースコードとしては意味のないコメント


 従って、書いても良いコメントは無害な「ソースコードとしては意味のないコメント」だけです。
 例えば、以下のようなコメントは書いても良いです。

/*
 *  author:nodamushi
 *  Copyright:ニート有限会社
 */


 //-------------------------------------------------------------


/* ごめんなさい。私を探さないでください。本当にごめんなさい。 */

 その他のコメントは有害なので、極力書かないことをお勧めします。

 有害とはどういうことか?それは、コメントに書いてあることと、実際のコードが異なっている状態を指します。


 先ほどの例を再度挙げてみましょう。

MODULE0 = 0x6c; // MODULE0の結果転送先を~~に切り替え。Event出力あり。クロックはクロック1
MODULE0OV = 1234; // オフセット値
MODULE0EN = 0x71; // MODULE0をイネーブル。割り込みOn

 この時点ではまだ有害ではありません。

 さて、仕様が変わり、Event出力をoffにしました。

MODULE0 = 0x4c; // MODULE0の結果転送先を~~に切り替え。Event出力あり。クロックはクロック1
MODULE0OV = 1234; // オフセット値
MODULE0EN = 0x71; // MODULE0をイネーブル。割り込みOn

 この瞬間、コメントが有害化しました。Event出力をしなくなったはずなのに、コメントは修正されず、「Event出力あり」となっています。しかもこれ、コンパイルエラーにはならないので、結構直すの忘れるんですよね。


 生ものは冷蔵庫に放っておくのではなく、すぐに食べるなりして残さない、もしくは完全に凍結してしまうかのどちらか以外扱い方はありません。
 コメントも同じです。コメントは生ものです。いずれ腐ります。コメントは残さない、もしくはソースコードを二度と弄らない凍結状態とすることが鉄則です。

 コメントに頼らなくても、わかりやすく、「読めるコード」を書くことを心がけましょう。
 変数名がa,b,c,dなんかだったりして、コメントがなくて読めるでしょうか?関数名がhogeだったりして、何の関数なのか分かるでしょうか?
 何百行もひたすら、一つの関数のコードだけ書いてあって、果たして全体が把握できるでしょうか?

 コメントに頼らず、読みやすいコードを書こうとすると、自然と構造がわかりやすいプログラムになっていきます。


 読めるコード、「リーダブルコード」というキーワードを頭の片隅に置いておいてください。

 マジックナンバーを消すのもリーダブルコードの一つですね。



 カレーは飲み物、コードは読み物です。



意味の区切りでなるべく関数に分ける 繰り返し出てくる処理は関数にまとめる


 組み込みではないのですが、サブルーチンも使わずひたすら同じ事をコピペによって繰り返すコードを見たことがあります。
 なんでサブルーチンにしないのか?と聞いてみたら、サブルーチンにするより、コピペの方が簡単だし、安心だからとの返答をいただいた。残念ですが、私には何を言っているのか理解できませんでした。


 まず、コピペは危険です。コピペコードの修正し忘れによるバグの発生はよくありますし、そもそもコピペコードがバグってたときは悲惨で、あちこちに散乱したコピペコードを全て修正する必要があります。どう考えても一カ所にまとめて管理した方が安全です。バグってた場合はその一カ所だけ直せば良いのですから。

 次に、コピペでない場合でも、ひたすら処理が何百行と続いているコードよりも、関数で適切に区切りがあるコードの方が読みやすいです。
 でもこれに対しては、あちこちに処理が散らばるよりも、一カ所の関数だけで書いてある方が読みやすいと言われたことがあります。しかし、関数で区切ることは、文章で言えば、漢字や句読点、章立てと同じです。
 なんぜんぺーじもあるほんがかんじもくとうてんもつかわずましてやもくじもないばあいをかんがえてみてくださいあなたはそのほんをさいごまでよみとおすことができますかわたしはこのぶんしょうですらたぶんあしたにはよめません

 また、長すぎるコードはテストが大変です。問題がどこにあるのかの切り分けが難しいのです。(組み込みでのテストの作り方は私は詳しくないので突っ込みませんが………)
 関数は10~100行ぐらいにまとめると良いと思います。

 あとは、ファイルスコープなどを駆使して、グローバル変数が見える範囲とかも最小限にするなど………まぁ、これはいいや………。



マクロを使って、同じ内容を繰り返し書かない様にする


 マイコンでは、各モジュールの設定手順は、変数名レベルでほとんど同じって事がよくあります。

//モジュールAの0の設定
A0PROP =11;
A0PROP2=22;
A0PROP3=33;

//モジュールAの1の設定
A1PROP =111;
A1PROP2=222;
A1PROP3=333;

//モジュールBの0の設定
B0PROP =1111;
B0PROP2=2222;
B0PROP3=3333;


 こういう場合はマクロでさっくりまとめられます。

/*
 各モジュールのPROPを設定するマクロ

  name:モジュール名
  n:モジュール番号
  p1:PROPの値
  p2:PROP2の値
  pe:PROP3の値
*/
#define SetModuleProps(name,n,p1,p2,p3) name##n##PROP = p1;\
                                        name##n##PROP2= p2;\
                                        name##n##PROP3= p3;

//モジュールAの0の設定
SetModuleProps(A,0,11,22,33);

//モジュールAの1の設定
SetModuleProps(A,1,111,222,333);

//モジュールBの0の設定
SetModuleProps(B,0,1111,2222,3333);


 マクロは関数ではなく、ソースコード文字列の置換なので、これら二つのコードは全く同じコードです。



参考:
  プリプロセッサ
  #と##演算子



マクロは使わない

 マクロは定数マクロ以外使わないでください。(定数マクロは「#define A 10」の様に定数に名前を付けるマクロです。)



 次のように、ほとんど書いている内容が同じだからと言うことで、マクロを使ってまとめるアホがいますが、お勧めは出来ません。
 (マクロでまとめることはお勧めしませんが、関数でまとめることはお勧めします)

/*
 各モジュールのPROPを設定するマクロ

  name:モジュール名
  n:モジュール番号
  p1:PROPの値
  p2:PROP2の値
  pe:PROP3の値
*/
#define SetModuleProps(name,n,p1,p2,p3) name##n##PROP = p1;\
                                        name##n##PROP2= p2;\
                                        name##n##PROP3= p3;

//モジュールAの0の設定
SetModuleProps(A,0,11,22,33);

//モジュールAの1の設定
SetModuleProps(A,1,111,222,333);

//モジュールBの0の設定
SetModuleProps(B,0,1111,2222,3333);

 このように書くぐらいなら、下手なことをせず、以下のように書きましょう。

//モジュールAの0の設定
A0PROP =11;
A0PROP2=22;
A0PROP3=33;

//モジュールAの1の設定
A1PROP =111;
A1PROP2=222;
A1PROP3=333;

//モジュールBの0の設定
B0PROP =1111;
B0PROP2=2222;
B0PROP3=3333;


 なぜなら、これら二つのコードは等価ではありません。………ん?同じじゃないかって?

 これね、ブレークポイントが非常に扱いにくいんですよ。
 マクロを展開すると、以下のようになるから、A0PROP2の所にブレークをおきたくても、エディタ上からは設定できなくて、直にブレークするアドレス探して設定するなんて手間がかかる。

//モジュールAの0の設定
A0PROP =11;A0PROP2=22;A0PROP3=33;

//モジュールAの1の設定
A1PROP =111;A1PROP2=222;A1PROP3=333;

//モジュールBの0の設定
B0PROP =1111;B0PROP2=2222;B0PROP3=3333;

 コンパイラやデバッガが頑張ってくれて、A0PROP2,A2PROP2,B0PROP2の場所にブレークポイントを設置できる場合があったとしても残念なことになる。マイコンなんてしょぼいデバイスは大概ブレークポイントも一、二個しかおけないから、今回のように3箇所に展開されてしまうと、どうもならない。


 その他の理由としてはマクロは難しいし、色々面倒くさいという理由もあります。C++ではプリプロセッサ界は魔界と呼ばれております。
 触らぬ神にたたりなし。不必要に関わらないようにしましょう。




ローカル変数は書き換えない、使い回さない

 
 状態が変化するものを完璧に把握し、完璧にプログラムを組み上げるのは中々難しいものです。
 「AならばB」という明快なプログラムは、ミスしにくいです。しかし、「AならばBが基本だけど、状態によってはCで、まれにDとかEにする」ってなると、一気にバグが入り込みやすくなります。
 なので、本当は「状態に依存しないプログラムを書くことを心がける」と書きたかったのです。なのですが……、組み込みで状態に依存しないプログラムなんて不可能です。基本的にほとんど全ての処理が状態に依存しまくりですよね。


 しかし、状態の変化は諦めるとしても、ローカル変数を書き換えない、使い回さないという意識は出来るとおもいます。
 何カ所にも渡って変数が書き換えられると、その都度、変数の意味を再解釈しなくてはなりません。どこで変化し、どのような意味を持つのかを、全て把握するのは大変です。さらに、もうこの変数はここから先で使わないから、再利用しようと変数を初期化したものの、後で前の結果が必要になることもあります。しかし、そのコードを書く頃には、変数を初期化したなんて忘れててバグった………、なんてもうよくありがちですね。

 ローカル変数の再利用は、変数を定義するのが面倒だったのかも知れません。しかし、後々、もっと大きな面倒を運んできてしまいます。面倒だったのではなく、メモリの使用量の最適化だったのかも知れませんが、それは早すぎる最適化です。
 ローカル変数の値は一度決定したら、書き換えないことは徹底しましょう。

int temp = 1;
………
temp += hoge(1);
………
moge(temp);//実はここでtempの値が変わる
………
//しばらくして
temp = 0;//tempを再利用

....

if(temp == a){//実はここのtempはtemp=0されてることを忘れてる
...
}

 

 




まとめ

  1. 数値には名前を付けましょう。ビット単位で区切るとなお良し
  2. コメントをちゃんと書きましょう。どうせ明日には分からなくなります
  3. コメントを書いてはいけません。どうせ明日には腐ります
  4. 関数で小さく意味の単位に分けましょう
  5. マクロを使って処理をまとめましょう
  6. マクロは地雷踏む可能性高いので使うのは止めましょう
  7. 状態が変わらないほどバグりにくいです。せめてローカル変数だけでも変化しないようにしましょう
  8. 最適化は重要だけど、最後の手段。早すぎる最適化は駄目です


 綺麗なコードを書いて苦しい組み込みライフを楽しんでください。
 (´・д・`)ノシ