craudです。

嘘です。元Nanoのソフト担当です。今はNanoと本家の中間の生命体となっています。永遠にさまようことはないと思うので、そのうちちゃんとした発表があるでしょう。

さて、先日ハード担当がへなちょこな記事を書いていました。なんだか情報公開したいみたいなので、波に乗ってソースコードを公開してしまいます(彼の言いたいことをあまり理解してない風)。

ここから落とせます。

Makefileもあるのですが、embedXcodeのものを改造して使用しているという状況なので、アップロードは憚られます。

たいしたプログラムは書いていないので、ほぼ無修正での公開です。ハード担当のツイッターによると、

「誰が読んでも理解できないほど高度な」が彼のこだわりなので、

らしいですが、そんなことは決してありません。自分は常により人間にとって読みやすいプログラムを書く研究をしています。彼によるこの手のソフト担当分析は9割方的外れです。騙されないように気をつけましょう。

今回公開するプログラムも、失敗した箇所はいくつかありますが、それなりにまとまったものができました。C++の基本的な知識があれば、スラスラ読める…と自分では思います。

以下主な失敗点

  • C++11, C++14の新機能をあまり活かせなかった。

以前紹介した`constexpr'くらいしか使ってやれませんでした。多用した`enum'は全て`enum class'にするべきでしたし、関数ポインタの初期化は`nullptr'の方が安全です。また、メンバの初期化をヘッダーに書ける機能もコードを読みやすくします。

  • 静的メンバ定数などに`const'と`constexpr'が混在している。

これは書いている最中に`constexpr'の存在を知った影響です。結局最後まで統一せずに通してしまいました。

  • `AppDelegate'が持つ各インスタンスに`static'と非`static'が混在している。

これは汎用ラムダ式マクロ`LAMBDA'が非`static'なメンバ変数を参照できないことによるものです。いろいろと工夫しましたが、どうしてもローカルな変数を参照するラムダ式は実装できませんでした。おそらく`std::function'が使えないavrの環境ではC++での実装は不可能でしょう(Cなら可能ですが、そもそもOOP向け言語じゃない)。これも面倒で最後まで統一せずにいました。

  • Unit Testがしにくい

今回はそれなりに複雑なアルゴリズムも実装したので、Unit Testが非常に役立ちました。しかし、全体的にテストしにくいコードであることは否めません。しかもテストファーストで開発していませんでした。

  • `GCThreeMotors::move()'が異常に冗長

このメンバ関数が長いこと長いこと。なんと1150行!なぜ分割できなかったのか。これに関してはただのアホです。


主な反省点はこんな感じです。もし万が一詳しい解説が聞きたいという酔狂な方がいらっしゃいましたら、コメント等でお知らせください。