いまがコーディングとき

追記：ndk r6で簡単で便利な機能が追加になったので存在価値が減りました。 agdb.pyが便利。 nativeでクラシュした情報は/data/tombstomes/内に書き込まれるが、 Logcatでみられるのはその一部。 それを分かりやすく表示してくれるToolである。 ただし一番の苦労はANDROID_SRC_ROOTの設定(別にcommand option有り) androidのソースの位置が必要 で、androidのソースもゲットする必要がある。 尚、Windowsは動作しないと書いてある。  詳細は以下を参照 blog 「just do IT」 http://rxwen.blogspot.com/2011/01/resolve-stack-trace-of-crashed.html  http://rxwen.blogspot.com/2011/01/utility-for-debugging-android-native.html 本体は以下 http://code.google.com/p/rxwen-blog-stuff/source/browse/trunk/tools/agdb.py androidソース http://source.android.com/source/initializing.html   目的のDEBUG情報設定はmake -j4する前に export TARGET_BUILD_TYPE=debug export PLATFORM_VERSION=2.3.3 などとカスタマイズ   

C++マルチスレッドの専門書を探してるのですが、なかなかよいものが見つかりません。 手持ちには３冊ほどありますが、古い本か、新しいものは抽象的で実用的な本がすくない。 探しているものとしてはJava Concurrency in Practiceのような良書なのです。 そんな中、秋頃に(洋書ですが)TR2を扱った本がでるとのこと、ちょと楽しみにしています。 ps みんなそうかもしれませんが、僕個人が現在C/C++を使う目的は第１にマルチプラットフォーム化、第２に高速性です。  実用化というのはその第１がサポートできるかが判断材料になります。例えばこんな 記事 のことです。   

Galaxy SやTab10.1でも同じですが、  ndk-gdbを実行すると $ ndk-gdb -d (android-ndk-r5bでは) ERROR: Could not setup network redirection to gdbserver? Maybe using --port=<port> to use a different TCP port might help? (android-ndk-r5cまたはr6では) ERROR: Could not extract package's data directory. Are you sure that your installed application is debuggable?   と表示されデバイスでデバッカが起動しません。 理由はsumsungがデバック用パッケージを移動しているためで、ndk-gdbが期待したパスに存在しないようです。 これを解決するのはいまの所、ndk-gdbのスクリプトを合わせるか、rootでリンク化でしょうが、パッと探してみたところ情報が少ない。 (当たり前ですが、javaのデバックはできます、nativeの場合です。 尚、SはAndroid2.2, 2.3.3, Tab10.1はAndroid3.0.1, 3.1を試しました 念の為) ちなみに、最近登場したndk r5cですが、ndk-gdbスクリプト以下の部分でexit 1されます。 DATA_DIRが空になるんですなぁ。  adb_var_shell2 DATA_DIR run-as $PACKAGE_NAME /system/bin/sh -c pwd if [ $? != 0 -o -z "$DATA_DIR" ] ; then     echo "ERROR: Could not extract package's data directory. Are you sure that"     echo "       your installed application is debuggable?"     exit 1 fi log "Found data directory: '$DATA

どちらを使えばいいか。 たぶんBoostだと思います。 それは将来性を考えた上です。 (しかし、 NokiaがQtをOpenソースとして、orgに独立してしまえば別の話です） 理由はQtはNokiaが持っているので微妙にNikiaさらに、ここと提携したMicrosoftの影響が入るからです。 当たり前ですが Nokiaを見てるとAndroidを無視しています。 そのことで開発者の中には不安に映るでしょう。 しかも、BoostにはC++準標準的な立場で、しかもQtの魅力であるsignal&slotを参考にしたSignal2という仕組みまで入っています。 スマートポインターも素晴らしい(*)。などなど。 と、ここまで書いておいて、実際はQtを使っています。 それはMFCから移行しやすいのが大きいからです（といってもQtはmfcやjavaを参考にし、洗礼されていて綺麗な設計）、そしてBoostにはないGUI(ボクは使っていませんがそのための安心感有)があります。  パッケージとしてまとまりがあり導入しやすく、インディーズとはいえandroid版もしっかりしているのがいいのです。    * Qtのスマートポインタについては ココ  

実用に耐えるソフトウェアデザインは各クラスのインタフェースが、 あたかも大工が家の建てるときに木材寸法通りがきれにはまっていくこと。 (Before After というテレビ番組のシーンを浮びます） これと似た感覚がプログラミングしていて感じられることだと、時々実感することがあります。 この感覚が多いとコードへの信頼度や自信が増し、 この感覚がないと、段々イライラしてきて、最後には不機嫌でいる自分に気が付きます。 別の書き方をすると、居心地がわるくなってくる感じです。 そんな中では、 仕事はしたくないですねぇ。 

QTextCodec::setCodecForCStrings(QTextCodec::codecForName("Shift-JIS")) を設定しても、QTextStreamはファイル(Buffer)の先頭にUTF8-BOMがあるとUtf-8としてQStringに読み込みます。 賢いですね。 もちろん、BOMがないとShift-JISとして読んでしまいます。 でも、それを知っていないと思わぬことに時間を取られるかも。。。です。 そんなおそれがあるときはそのディフォルトの振る舞いを切ってしまうのが一番です。 PS Codecは多くのパターンがあり複雑なので、ボクの認識間違いかもしれません。 そのときは教えて頂けると幸いです。

UTF-8 BOM対応のツールが増えるなか(Eclipseや、Qt Creator、無論Visual Studio)、どうしても足止めするツールがある。 それはgun-makeそして、qmakeこれらはBOMがあるとParserを止めてしまう。 深く探していないので、オプション等追加すればたいおうするのだろうが、台無しにしてしまっている。 どうしてもShift-jisをまだ捨てられない環境なのでどうにかしてほしい。 ちなみにBOM非対応のGoogle cpplint.pyですがこれはpythonということもあり簡単だったのでBOMがあっても動作するように改造した。(ついでにoutputオプションにeclipse形式を追加、makeに組み込めば使える)

前にちょと書いていたのですが、プラグインは作成しませんでした。 実際はgnu-makeに自作のコンパイラを動かすようにしたら、CDT上で普通に動作したからです。 ただエラー行はconsoleをクリックしてもジャンプしなかったので、フォーマットをgccと同じようにしたらあっさり動作しました。 また、自作コンパイラはCをベースにしているので専用拡張子をC++Editorにしたら、色分けもされ、動きました。 ということで、実用的だったので、プラグイン制作は止めて、先に自作コンパイラをantlrで作成ししなおす流れとします。

現時点では、WindowsやAndroidでは直接Valgrindを動作させることが出来ない。 マルチプラットフォーム化が当たり前の時代になっている現在、コードのほとんどはLinuxで動作する。 したがって、導入をしなければならない。 しかも、すぐにでも。  

そろそろ出てもいいのではないか？ コードを書くたびに保存もしないのに自動コンパイルされるのは当たり前の今だが、もっと必要なのは、その後、(何もしなくても)自動にテスティングをしてくれる開発システム(IDE)。  どんなのがあるだろうか？ 知っていたら教えてください。  

本当に強力なコードは世の中にだしてから、作り直しが2回は必要。 しかも、そのたびにリリースされ、多くの人に使われなければならい。 例えるとOSでさえ、使い物になるのはVer３．０からである。  この「３」以上まで、リリースされ続けているコードを採用したい。  sqlite3の「３」は使うボクからは印象がいい。(ごまかしはだめですぞ）

量ばかり気になって、本質を忘れてはいけないことでしょうが、有名な sqlite3 の本体コード(Version 3.7.5)は73.0KSLOC、テスティングコードは1251倍の91378.6 KSLOC。 ボクの扱うandroidで実行するコードは500KSLOC以上あるがテスティングコードは１倍もないのではないか？ あまりにも差がありすぎる。 これはちょと恥ずかしいレベルの話ではないかと思っている。