2018年3月10日土曜日

gdbによるQtプログラムのデバッグ

GUIを使わないプログラムなのに、Qtを使いまくっているプログラムがあって、それのデバッグしてて困ったことを。
Qtには、STLより効率がいいとのことで同様のQVector, QLIstが実装されています。同じように使えますが、困ったことにgdbでbreakして変数の中身を見ようとしてもエラーがでてきて見えません。
サンプルのプログラムをいかに示します。

  #include <qlist>
  #include <iostream>

  int main()
  {
    QList< QString> list;

    list << "1st" << "2nd" << "3rd";

    for (int i=0; i<list.size(); i++)
    {
      std::cout << list[i].toStdString() << std::endl;
    }

    return 0;
  }

これでgdbによりfor文のところでbreakして、list[0]の中身を見たいと思います。


(gdb) p list[0]
Could not find operator[].

なんか怒られました。どうもQtのテンプレート定義のoperator []に関する多重定義のところで問題が起きているようです。ちなみに、list自体をprintすると以下の様になります。

(gdb) p list
$15 = {> = {}, {p = {static shared_null = {ref = {atomic = {\
_q_value = -1}}, alloc = 0, begin = 0, end = 0, array = {0x0}}, d = 0x604ee0}, d = 0x604ee0}}

かなり複雑な構造をしているようですが、"d"というメンバがいるのはわかります。Stackoverflowなんかで調べても、中々ヒットせず、唯一呪文のようなものがひっかかり、それが正解でした。以下にそれを示します。


(gdb) p ((QString)list.d->array[0]).toStdString()
$17 = "1st"

要は、"d"というポインタのメンバにarray[]で配列にしているということのようです。それを強引にテンプレートで定義したQString型だとして、toStdString()関数をCallしてやれば、QListの中身も表示できます。

なんというか、こんな手間をかけないとデバッグできないならSTLを素直に使ったほうがいいんでないか?という感じです。


PS
QListはコンテナ・クラスですが、通常このてのものはテンプレートを使い、内容物の型を定義するものです。ところが、Qtは上記のarrayのところを(void*)で定義しているものですから、こんなややこしい事になっています。素直に全部テンプレートで実装してくれれば、こんな面倒なことにならずに済むのですが、Qtは様々なコンパイラに対応しています。テンプレートはc++の第3版で正式に定義されましたが、それまで定義があいまいなところがあり、実装がコンパイラ毎にバラバラな時代が10年くらい続いた記憶があります。今でも、時折、コンパイラが変わると、テンプレートまわりで修正が必要なことが発生したりします。(10年以上前は、大騒ぎでした)おそらくそれを嫌ったのと、とにかく速度を稼ぎたかったんでしょうね。(void*)で定義したほうが、圧倒的に速いですから。(そのかわり、バグが入り込みやすく、面倒はプログラマが見ないといけません。)
ちなみにQtCreatorのデバッグ設定がきちんとできていれば、こんな面倒なことはする必要はありません。GUIは使わない組み込みに近いプログラムを作るのに、Qtの一部だけを使っている場合の特殊な状況の話です。

2018年3月5日月曜日

Qtの開発環境(Windows)

相変わらずQtの開発環境づくりに苦労しています。Qtのデフォルトの言語の設定がg++らしく、WindowsでもMinGWにすれば簡単なんですが、やはりVisual Studioにしたい。
どうも、MSがVisual Studioの外部ツールと連携する際のAPIを変更したらしく、これまでのQtで配布していたAddInが使えなくなってます。
色々調べていたら、VStoolというのがあるのでそれを入れれば、Visual StudioでQtの開発ができるとの情報がありました。早速入れてみると、一瞬はうまくいったようなのですが、すぐにダメになりました。このあたりの理由はよくわかりませんが、ちょうどWindowsの更新が煩雑にあった頃のため、何かまたAPIに変更があったのかもしれません。

QtのHPを調べると、何とVisual Studioとの連携をするVStoolはcommercialライセンスにしかなくなっています。(この前、DLできたのはギリギリのタイミング?)
仕方ないので、Qt Creatorの環境を作ります。一方、Visual Studioの方についたQtのAddInは削除する方法が見つかりません。気持ち悪いので、TotalUninstallerというツールでVisual Studioの環境をバッサリ削除し、再インストールしました。

何だかんだと苦労しましたが、いったんきれいな状態にマシンをしてから再度Qtをインストールするとうまくいきました。Qt Creatorの設定画面でもきれいにVisual Studioが認識されています。
色々やっていた時に、WDKをインストールしてあるせいか、デバッグもきちんとできました。

2018年2月18日日曜日

Qtの開発環境とAnacondaの問題

QtでGUIを作成する環境をWindowsやMacで作ろうとOpenSource版を設定しようとしたんですが、どうもうまくいきません。

しばらく悩んでましたが、別途インストールしていたAnaconda内に既にQtの環境がPyQtのために入っており、Anaconda側が自分の方を優先したPATH設定にしているため、そちらとぶつかっていました。

色々、設定を考えていましたがAnacondaをインストールした状態で、別途C++用に別バージョンのQt開発環境を設定するのは無理なようです。どうしてもPython(Anaconda)とC++でQtを使いたいなら、Anaconda内のQt環境で我慢するしかなさそうです。ちょっとこれは頭が痛い問題です。
PythonでQt使えばいいじゃないかという声もありますが、ちょっと周りではPythonはメジャーでなくて、GUIはC++でばかり開発してたものですから、それも受け入れられそうにありません。

2017年11月25日土曜日

Unity カメラコントロール

ちょっと3Dのプログラムを作ろうとしてUnityをかじっています。(大昔はInventorでやってましたが、今時は流行らないしそもそも皆、OpenGLでガリガリ書く時代に逆戻りしちゃってます)

少し癖が強いですが、わかってくると楽にできそうです。ちょっと難点はスクリプトをべったりと1階層にしか置けなさそうな点。複数人で開発するとき困るんだけど。(それともできるんだろうか?VisualStudioも階層構造が見た目と、実際のディレクトリとはまるで別に管理しているのを見て驚きましたが。Unix系から始めていると、ディレクトリ構造をストレートに見た目に反映してくれたほうが分かりやすいんですが。)

ところで別にゲームを作る気は全然なくて、3DのViewerが作りたいので、カメラコントロールをどうしようかと思い、探してみました。(Inventorだと標準についているViewerで簡単にできて、楽だったんですが)ありました、マウスで簡単に制御できるスクリプトが。本格的にやるならそれ用のボタンも作った方がいいんですが、とりあえずは十分です。このスクリプトをCameraにコンポーネントとしてアタッチするだけで、機能してくれます。

2017年10月14日土曜日

anaconda内のQt

久しぶりに、少しQtを復習しようかと思いました。とりあえず、まずは慣れているmacで初めて、簡単なプログラム(signal, SLOTの復習です)を入力し、
$ qmake
としたら、何かmacx用のテンプレートがない、というようなことを言われました。

はて?macには今年の春、Qt5.8をインストールしたはずと思い、試しにwhichでqmakeの場所を調べてみると、何とanaconda内のqmakeになっています。どうもanaconda内のpythonパッケージに含まれるPyQtが最低限のバイナリとして持っていて、そこにPATHが通ってしまっています。ぐぐってみると、結構記事があり、PyQtでQtの勉強しよう、というのもありましたが、とりあえずanacondaのqtでは単独で使用するのは難しそうです。(独自にPyQt5をbrewでインストールしてしまう、という荒技もありますが、今度はanacondaのパッケージ管理で問題が出そうなのでやめておきます。)

win10にもanacondaをインストールしていたので、調べてみるとこっちも同じ状況です。win10にはQt5.9をanacondaの後にインストールしていますが、なぜかPATHが通ってません。(元々、コンソールで使うつもりなかったし、そのためかな)試しにPATHを通して見ましたが、デフォルトがg++を使う設定で、win10にはcygwinは入れてありません。(Visual Studioで開発するつもりでしたから、それにcygwin好きじゃないし)

これはおそらくLinuxも同じ様な状況になっているんだろうな。仕方ないので、再度Macに戻り、PATH設定をしてqmakeしました。今度はうまく行きましたが、anacondaのpythonでPyQt使う時何か問題でるかな?(今の所、全然使う予定ないので、逆にanacondaからPyQt外した方がいいかもしれません)

PS
ところで、最後にmacでバイナリが作れましたが、macのqmakeでビルド後にできるバイナリは、Finderからクリックできる構造の*.appになっているのにびっくりしました。コンソールから試すだけだから、そんな構造にインストールしてくれなくてもいいのに… .proに何かオプションを追加すればいいのかもしれません。

2017年9月23日土曜日

Visual StudioでのPython(win10でのpython環境)

いつの間にかVisualStudio上でpythonが開発できることに今更気づきました。このところVSCodeでpythonのデバッグ環境を作っていたので、これなら本家のVisual Studioだってできるだろうと思いつき、調べてみたら2013くらいからできるようになったようです。

win10上でのpython環境は、Visual StudioではPython Toolsのパッケージをインストールしないとデバッグできませんが、pythonインタープリタ自体は自分で好きなものをインストールしろとのこと。runtimeには含めていないようです。配布を考えると、どっちが楽なんだろうか微妙なところですが、これまでwindowsではpythonはメジャーではなかったし、元々OS非依存で開発されていましたからこんな形になったんでしょう。

うちにある最新のwin10マシンにはVisual Stuido 2017 Communityが入れてありますが、真っ先にAnacondaが入れてあるため、そちらがデフォルトのpythonインタープリタになっています。もう一つのマシンには2015 Communityが入っていて、2013年に入れたおそらくpython.orgのpython27が入っていました。

しかしおかげで一つのマシン内に複数のpythonがインストールされている状態です。実際、Visual Studioの機能でd「python環境」というwindowがあり、そこでデバッグ/実行するときのpython環境を選べるようになっているくらいです。(いや、それCLIで実行するときはどうするんだよ、と突っ込みを入れたくなりますがそれも含めて考えてデバッグしろということでしょう。面倒くさい。)

この際、古いマシンの方のpythonをpython3にしようかと考えたんですが、ちょっとググってみたら、M$の推奨は悩んだらAnacondaが無難、Visual StudioのC++, C#と連携を考えるならIronPythonとのこと。調べると、IronPythonって、C#で実装されているとのこと。そのおかげで、Cythonもいけるらしい。しかしながら、python3がなくいまだに2.7というところが悲しいですが、ちょっと連携を試してみたいのでIronPythonを入れてみます。

Macもpythonは多数のバージョンがpyenvのおかげで入っていてひどいことになっています。python好きなんだけど、バージョン管理をなんとかして。(配布の時のハードルがかなり高いです)

2017年8月23日水曜日

win10 VSCodeでpython(githubへup)

これまで基本自分はLinuxかMacでプログラムを作り、gitでコード管理、githubへupしていました。ただ一応、windowsでもeclipseではgithubにupしてました。
しかし、このところどうにもwindowsでプログラムを作らないとやっていけなさそうな状況になってきて、更にM$がVScodeをOpenSourceにしてきて、ずいぶん力を入れてきています。まだまだ、eclipseにはかないませんが、かなり頑張ってきています。これは一つ、今のうちに使い方を覚えていこうと試してみました。

とりあえず、せっかくVScodeを使うので言語は好きなpythonで行ってみます。(これはまた設定でかなり悩みましたが、それは別の時に)VScode自体は、ローカルではgitの管理機能を持っていますが、eclipseと違い、残念ながらまだリモートへのpush/pullの手段を持っていません。
そのために、VScodeの「統合ターミナル」で直にgitコマンドを実行しないといけません。しかし、更に問題なのがwindowsは標準ではsshのアクセスコントロール機能を持っていません。つまり、githubにアクセスするRSAキーを素では扱えないんです。
ネットでぐぐると、その他のGUIツール(例えば亀とか)を使えと書いてありますが、それもいやなので、しばらく考えてみました。

思いついたのが、gitのremote originを登録するとき、git@ではなく、https://github.com/ならどうだろうか?ということです。試してみたら、pushしたところで、githubのアカウントとパスワードを問い合わせるDialogが出てきて、入力したらうまくいきました。
一応、1回pushできればアクセス・コントロールは通るので、次からはVScodeのUIでいけるようです。(まあダメでも、アカウントとパスワードの入力くらいなら構いません)

ただ、ローカルのgitの初期化後の最初のcommitもかなり苦労しました(;^_^A もう何度、統合ターミナルで直にgitコマンド打ち込んでやろうと思ったことか。(元々、gitは直にコマンド打ち込む方が好きなんです)しかし、なんかそれでは負けなような気がして、VScodeのエラーログや画面をにらめっこして、やっとうまくいきました。(実は、本日いきなりVScodeの更新が入り、なんか少し設定ファイルやら変わったよう。それもあってかネットの情報そのままでは素直に動いてくれませんでした)