いまがコーディングとき

http://necessitas.kde.org/ http://www.h-online.com/open/ news/item/ The-first-Qt-5-1-alpha-arrives- with-Android-and-iOS-support-1 837368.html Android版はBogDan Vatra氏が３年かけて開発してきた成果です。 １，２年ほど前に BBSで 彼からアドバイスをもらい、助けてもら ったことがあったので、嬉しいです。

gdbとlibstdc++debugマニュアル http://gcc.gnu.org/onlinedocs/libstdc++/manual/debug.html stdcxxの最新のprinterを取得 svn co svn://gcc.gnu.org/svn/gcc/trunk/libstdc++-v3/python qtのQStringなどのprinterはKDE devの中に入っている。 doc http://techbase.kde.org/Development/Tutorials/Debugging/Debugging_with_GDB printer http://quickgit.kde.org/?p=kdevelop.git&a=tree&f=debuggers/gdb/printers gnu推奨スイッチ set print pretty on set print object on set print static-members on set print vtbl on set print demangle on set demangle-style gnu-v3 .gdbinit (qtとstdc++対応) ----------------------------------------------------------------------------------------- python import sys # Qt4 sys.path.insert(0, '/home/macken/develop/gdb_qt_printers') from qt4 import register_qt4_printers register_qt4_printers (None) # stdc++ v6 sys.path.insert(0, '/home/macken/develop/gdb_printers/python') from libstdcxx.v6.printers import register_libstdcxx_printers register_libstdcxx_printers (None) end ...

古典的なことなんですが、 Visual Studioの出力ウィンドウ(Output window)にMFC TRACE(),Qt qDebugやWIN32API OutputDebugStringのメッセージ表示がされなくなったときは、出力ウィンドウを右クリックして、コンテキストメニューのプログラム出力(O)にチェックが入っているか確認してください。 ここの位置は何かの拍子にマウスボタンを押してしまい。 アンチェックになりやすい位置です。 そのため戸惑うことがあります。

どちらを使えばいいか。 たぶん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のスマートポインタについては ココ  

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

Utf-8 BOMを勝手に消さないようになり、やっと日本語環境で使えるようになったのだが、複数モジュール管理の使い勝手が悪いIDE。(BOMはVisual C++で必要なため入れてある) qmakeの仕様通りなのかもしれないが、ちょとやなクセがある。 Qt Creator 64bits (binaryをDownload 使う プロジェクトはQt-4.7.1)の変な動作 (環境は日本語のUbuntu11.4-64bitsでQt CreatorはEnglish設定)があり、ハマったのでメモ 社内用ツール向け自作のプロジェクト製作中におきた不都合。。。 releaseコンパイルなのに暗黙にdebugが定義されている。 したがって、 Build Settings内のreleaseオプションにわざわざ以下の定義を入れなければならない。 CONFIG+=release CONFIG-=debug これを入れなければ暗黙に以下が実行される debug {     実行される } release {     実行されない } もし、暗黙のdebugが仕様ならば、debug版でCONFIG+=debugは必要ないと思われる。 勘違いをおこす原因となった。 PS 置換をおこなうとUTF-8 BOMを消してしまうバグ有り

案外、android開発ではandroid機のメモリ不足でテストができなかったりして非効率になることがあります。　そんなとき、使用しているライブラリが大きい場合は対処があります。　例えばQtCoreのように大きいライブラリがデバック情報を持っていた場合は再コンパイルすると時間が無駄になるのでstrip -gを使って削除すれば簡単です。 e.g. 23MB -> 2.8M command /usr/local/android-ndk-r5/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi-strip -g libQtCore.so.4.8.0 P.S. linux gcc標準のstripはarmを認識できない。

ndk-gdbによるマルチスレッドデバック(Level9から)が可能になり（私はgdb 7.1を使っていますw)、Google Testもどうにか使えている。 Qtもnecessitasができた。が、 あとは、そう　Valgrindです。 残念ながら、動く気配がまだボクには感じられません。。。  

android 2.33がリリースされ、さらにC++/Cの開発がしやすくなった。　そこでQtなどが便利なフレームワークになるのだが。。。 eclipse＋ Qt-plugin + android Qtと動かしたいが、パッとインストールするだけではうまくいかない。 qt-creator for androidがあるのだから、このあたりからヒントがみつかるかもしれない。   とりあえず、手動として ndk-buildは以下のスクリプトを動かしているので これらをカスタマイズすることによって対処してみる。(ndk/docs/NDK-BUILD.html) $GNUMAKE -f $NDK/build/core/build-local.mk [parameters] (android ndk r5b現在) mocは以下のドキュメント参照 http://doc.qt.nokia.com/latest/moc.html      

MacBook Pro 17inchにUbuntu10.10をいれてandroid-lighthouseのcompileはうまくいかなかった。　しかたがなく10.4(64bit os)へ戻しコンパイルすると成功した。 git SHA1 IDは441693fbda67c03d7f6a3459b0a5a86ab48ee43d    

SIGNALは発行するだけ、 どこに届くかなどは一切関係ないし、知る必要もない。   SLOTはSIGNALからトリガーがかかるメソッド、同期で実行されるときもあるし、 Eventによって非同期に実行されるときもある。 どこからシグナルが来るかは知らない。   以上の「知らない」ことによって部品化がより強くなっている。 

MFC版のソフトウェアをQt版へ移植する際、 驚いたのは２個重大なバグが発見されたこと。 それも普通に実行して止まるのである。 ところがそのコードはC++で.hや.cc(.cpp),.cを含め、 800個以上(ちなみに全てをGoogle C++ Styleに変更中)の ソースファイルだが８年以上MFC で動作していたものだ。 それがQt版となり、メモリアロケーションの位置が変わったために、 発見できたのである。  ここには我々がおこなっている、 テストに問題が存在するということを証明している。 尚、バグは以下ことがらだった Bitmapのメモリ算出でバグがあり、メモリオーバーランしていた。 rectの初期化を忘れいた。 さて、これを自動に発見させるにはどう対処したらよいか。。。

MFCからQtヘ移植する際、戸惑うのは。。。  CObjectとQObject     これらは、見た目は同じようだが内容は、まったくことなる。　CObjectはオブジェクトの型チェックやシリアライズを提供するもの。　QObjectは、誤解を恐れずに書くとOSのプロセス管理とおなじような機能がある。 したがって、移植する際は注意するべき。  なお、最近はまったのはQThreadとCWinThread、両者はともイベント（メッセージ）キューをもち、イベント（メッセージ）ループがあるが、Notifyの方法がことなる。　前者はsignal and slotを使い、後者はMessageを使う。 その際、connectのsignal  and slot関数の引数部はQtのプリミティブな型しか受け付けないので注意すること、たとえば移植移行期にはWPARAMやLPARAMなどを使って試すと思われるが、slotを呼んでくれない。　しかも、コンパイルエラーや実行時にエラーメッセージなどは表示されない。　ただ、呼ばないのである。 (補足：これは出来るだけ アプリケーションが強制終了 しないようにと考慮されているため）

ADCへ飛ぶ： Techniclal note TN2185  (English版は ココ ) この資料にはGCC Visiblity(VisualStudioでいうDLL)のことが記載され、 その宣言などのテクニックが書かれている。 注目すべきは、複数あるVisiblity制御方法の優先順。　また、 throwやdynamic_castを行う際はそのオブジェクトはVisibleにすること。    

MFCからQtへの移植で注意しなければならないのは、 CStringをQStringへダイレクトに置換してはいけないこと。 実は、ローケールを設定しても、 QStringはもともとある日本語をUTF16に変換した際、 クセがある。 1 パス指定である「\」これを、 「/」には変えず、日本語に存在しない似た「￥」に変換してしまう。 2 utf-8のファイルはQByteArrayへ読み込むこと、 これもQStringへ読み込む際、意図しない日本語コードへ、 変換されてしまう。 その後、toLocal8Bit()で戻しても、 ムダである。 FormatやTRACE()などでも、そのままでは動作しない。 前者はsprintfではなくargへ。 後者はいちいちtoLocal8Bit().constData()などを、 つけなければならない。

MFCからQtを移植する再、問題になるのはファイル関係です。 MFCとQt、Serializeフィイルの互換性を維持するには、ちょとした工夫が必要です。 *Little Endianにします。 e.g.  ar.setByteOrder(QDataStream::LittleEndian); *CStringとQString。　MFC CStringは長さをかなり持てる機能があります。　その部分を読み込んでQStringへ入れるにはMFCのソースを参考にすると良いでしょう。　通常はQStringの最大値まで使うことはないのでコンバーターを作成すれば互換性を維持できます。 *COleDateTime(CTime)とQDateTime これもコンバーターを作成することにより解決可能です。 上記などを一気に移植するにはQDataStreamを継承したクラスがあると便利です。 CArchiveクラスのようにIsStore()などを作成することにより、もとのソースに対して少ない変更で移行可能です。 この継承したクラスにはEndianの自動変更、QString、QByteArrayやQStringListなどのインターフェースを作成すると使いかっても良くなります。

QtアプリをAndroid上で実行するには、 Qt For Android を今のところ活用します。 ただしQtGUIを組み込むと10MBほどになり、 3MBほどが現在のAndroidアプリの平均的な限度だとすると、 大きすぎるようです。 参考  Qt on Android ep 2 ボクの場合はGUIをAndroid GUI javaで書き、アニメーションエンジンと言語解析部分をQt(Nativeなので場所によっては10倍以上高速)にします。 したがって、QtCoreさえあればよく、必要に応じてQNetwork,QXml等を組み込む予定で、この場合は参考のリンク先内に書かれているように3.5MBほどになるそうです。 QtはNDKを通して使いますが、描画の速度によっては、QADKを使うことになるでしょう。ただし、QADKを使うとNDKに対して変更されているため正式なアプリとは認められない可能性があるため見極めが必要です。

MFCアプリをQtへ移植する際、Google Testを活用しながらだと、 足場を固めつつ前へすすめるので便利です。 ボクは以下のように活用しています。   DLLに対しては外部console MFCアプリからQtを利用しつつテストする。 結果はconsoleへ出力。 EXEに対しては内部にUnit testを組み込んで以下のようにWinApp::InitInstaince()内からコールし、テスト。　結果はOsanpo　project内にGTestOutput.xmlが出力される。 時にはGuitarを利用する。       {// Google Test 10-06-02         int argc=2;         char *comm="Mfc2Qt.exe";         char *comm1="--gtest_output=xml:GTestOutput.xml";         char *argv[3];         argv[0]=comm;         argv[1]=comm1;         argv[2]=0;         testing::InitGoogleTest(&argc, argv);          int nRetCode=RUN_ALL_TESTS();         if( nRetCode ){             return false;         }     } ...

１年前からライセンスの変更を元に使い易くなったQｔ。　DesktopアプリでWindows用をつくる。　もしくはMFCを使うという開発を過去のものにしたのかもしれない。 まぁ、時勢でしょう。(それに.NETは将来不安かも!?) ところでMFCで作られたソースをQtへ移植したい、という要望があると思います。 テストをしながら少しずつ移行するのが一番安全な方法でしょう。　以下のQtのサイトにひとつのアプリケーションでMFCやWin32とQtが使えるフレームワークが提供されています。　もちろん、MFCやWIN32が存在する限りLinuxやMacOSX(将来はandroidやiphone？）では動作しませんが、移行期間としては仕方がないでしょう。 Qt/MFC Migration Framework

ディスクトップ向け開発でクロスプラットフォームといえばNokia  Qt(キュート） 興味ある開発フレームワークだが、しかし、現時点ではホットなプラットフォームであるAndroidやiPhoneに対応していないのが残念である。　iPhoneはある程度実現できても（AppleやNokia自身が邪魔しなければ、だが）、JAVA　VM上であるAndroidへの開発は時間がかかるかもしれない。(あるとすればNDK経由か？) 参考:Qt for android (NDK使用) ついでだが。。。。   Qt CreatorというQt専用の軽いIDEがあるがTutorialをおこなうときに   英語で実行したい。　そのときはQtCreatorの実行コマンドラインの頭にLANGを英語に、   指定するといつも英文で開発ができる。ただし、現時点1.3.1(64bits)では日本語入力ができなくなる。 e.g.   env LANG=en /home/develop/qtsdk-2010.02/bin/qtcreator PS1 QtをINSTALLの際、コンパイルで２，３度止まることがあるが、エラーをサーチするとコンパイルを再開する方法がみつかるので焦らないこと。　コンパイルは２，３時間かかる。 PS2   クロスプラットフォームでは wxWidgets も有力