株式会社シフトロック(電磁場解析)のサイトへ

Qt5.12.2 の使用ついて

C++のGUIライブラリ

私は、アプリケーションの開発に、GUIをリッチにするため、Qtライブラリを使用しています。 以前は、MFCを使用していましたが、あるときから(MSがMFCをC++で書き直してから?)、DDXなどで結構酷い不具合があり、使うのを止めました。 それに、かなりレガシーでかなり前からMSのサポートも心もとないこともありました。 また、MFCは多言語化が容易ではないという理由もあります。

C++は優れた言語ですが、いかんせん、UIライブラリが切り離されているので、どのUIライブラリを使うかによって、大きく実装が変わってしまいます。 つまり、言語仕様としては、まともなUIライブラリがないとても不幸な言語でもあります。 その点、VB, Java, C# など後発のプログラミング言語は、フレームワークやライブラリ付きで提供されていますので、他からライブラリを導入しなくても実装できます。 Wordなどのワープロソフトに例えると、単純なプレーンテキストは書けても、およそ、通常の文書では必要とされる目次・索引・図表や画像の編集に関するものが付属していないという感じです。 具体例で言いますと、Hello World を単純に画面表示させる方法に違いはなくても、ボタンを押してグラフィックスで六角形を描く方法はどのライブラリを使うかによって全く異なった実装になってしまうのです。

まあ、FORTRANやPL/I, COBOL など GUIが広まる前からあった言語ですので仕方がないと言えばそれまでなんですが、C++17になろうとしている時代でも、紐付きでない決定的なライブラリがないのです。

Qt5.15.2 は LGPLで使用できるLTSとしての最終?バージョンのようです。

Visual Studio 2019は必須?

Windowsで開発する場合ですが、Visual Studioを使う場合、Qt5.15.2は、Visual Studio 2019 との連携になります。 Visual Studio 2017 のプラグインはありません。 もちろん、それ以外のものもありません。 従いまして、Qt5.12.2または、Visual Studio 2019 のいずれかを選択したとき他方が自動的にペアとなります。

Qt Creatorはデバッグが難

Qt付属の、Qt Creatorでも開発できますが、CDBかGDBを使うことになり、本格的な?デバックはまともにできません。

また、Visual Studioと違い、エディタで開いていたコードを覚えていません。 再び開いたときは、全部閉じられています。

しかし、Qt CreatorのエディタはVisual Studio のものと比べて、同じファイルのソースコードを左右に同時に複数開くことができるので、コードの探索や編集には非常に重宝します。

Qt Creator のコードエディタ
Qt Creator のコードエディタ

 

Visual Studioのエディタは見通しが悪い

Visual Studioのエディタは同じファイルを上下にしか開くことができませんので、同じファイルの複数箇所で、コードスニペット的な編集をするとき、非常に見通しが悪いです。 本格的なクラスを作るときは、1クラスが数千行になることはめずらしくなく、複数箇所を同時に開きたいことがよくあります。
上下表示だと見える範囲が狭く作業しにくいこと極まりないです。
また、ポップアップで多重表示できますが、上下表示には変わりありません。

Visual Studio 2019 のコードエディタ


ディスプレイは横長ですからね。左右表示が自然でしょう。

昔からそうですが、どうもコンパイラや開発ツールを作る人は、数十万ステップとなる本格的なアプリを作成したことがないのか、比較的小規模のプログラム開発を想定しているようです。 恐らく、小規模のプログラムでしかテストしていないのでしょうね。 数十万ステップの中から、オーバーロードやオーバーライドされたメソッドのサーチ・編集作業のテストなどしていないと思います。

Visual Studioの検索履歴も二つしか保存されないのも使いにくく、見通しの悪さに拍車を掛けています。 これらは20年以上変わっていません。 Qt Creator は、検索履歴の記録には制限がありません。

また、インテリジェントセンスやエディタ上部にあるクラスのメソッドリストも、少し、コードが大きいと端折られます(一部しか出てこない)ので文字検索に頼るしかないのです。

結論、開発フェーズで使い分け

結局、新たクラスやメソッドを作るという作業では、Qt Creator を使い、実行時の込み入ったデバッグをするには、Visual Studioを使うことになります。 また、最終的にパフォーマンス上げるためインテルコンパイラでコンパイルまた、並列化のチューニングするためにも、開発後半の段階で、Visual Studio + Intel Parallel Studioを

Qtの問題点


Qtは良いライブラリなのですがいくつか制約や問題点があります。
ソフトハウスが採用するには、技術的にも・経営的にもそれなりの覚悟が必要です。

  1. Qt 5が出てから10年以上日にちが経っていますが、入門レベルのものを除き、日本語の適切な書籍はありません。 まともに、自分のアプリに使用するには、英文とサンプルコードに対しての検索力が必要です。 また、Qtは頻繁に更新されますので、書籍に頼ることはほぼできないでしょう。
  2. ライセンスの問題があります。 LGPLとして使用する場合、ダイナミックリンクでなければなりません。 また、Qtのソースを改変して利用した場合もその部分のソースをGPLとして公開しなければなりません。
    ※スタティックリンクしてしまうと、GPLとして自分のものを含めすべてソースを公開しなければなりません。 つまり、著作権放棄・複製し放題になるので商用アプリとしては使えないに等しいのです。 LGPL(劣化GPL)の場合は、自分のソース部分は公開しなくてよいので、決まりを守らねばなりません。
  3. LTS(長期安定バージョン)がLGPLで使用できなくなりました。 制限が付き、金儲けに少し走り出したみたいです。 コロナ禍で経済が縮小している中、固定費削減がIT系でも課題となっていることから、MSやインテルをはじめ、値下げ・制限解除を傾向であるのに、この経営戦略は反対に走っていると思います。 ユーザー離れが生じなければよいのですが。
  4. ソースをかなり汚染します。 Qt独自のマクロや設定をソース側に取り込まなくてはなりません。 従ってQtのバージョンが変わるとソースレベルで修正が生じます。
  5. Qtの作法でプログラム・クラスを設計しなければなりません。 これについては後述。
  6. 大抵の場合は自分がやりたい操作はQtが用意してくれていますが、設計が悪いのかもしれませんが、たまに想定外のことをしようとする大変難しいです。 Qtは、イベント関係がユーザのソースだけ見れば比較的簡単になりますが、モッキングでUI のためコンパイル時にソースを自動生成する部分があります。 つまり、これはコンパイル時に決まってしまう静的なものなので、例えばUIの部品動作を既定のものと違う動的な造作にしようとするとかなり難しくなります。 また、生成されたソースがエラーを起こした場合、その解決も困難を極めます。
  7. 商用版は目が飛び出るほど高い。 とても、シェアウェアを作成している個人や弱小ソフトメーカーには使えません。 LGPL版から考えると商用版はとてつもない崖となるのです。

モノやサービスの値段は、需要と供給、相場、付加価値で決まりますが、ソフト開発者側からみた付加価値として、付属ツールは、コンパイラを含めたIDEの製品の価格より価値が低いと思っています。 なぜなら、メインの作業は、IDE・コンパイラ・リンカ・デバッガがするのでそれ以外はあくまで、補助であるからです。 従って、例えば、他にも選択枝があるライブラリや有名な某インストールツール、アドインで使う補助ツールは、有料のVisual Studio Proより高いので、価値からいって適正価格ではありません。(あくまで使う側から見た判断) ただ、インテルのMath Kernel Library とかは、非常に価値が高いです。 使うソフトウェアのパフォーマンスに直接大きく貢献するからです。 適正価格でないとそのうち、開発者から見放されてしまうか、本当にその価値があるならIDEなどに吸収されてしまうでしょう。 かつて有名であったI社では、Visual Studioにその機能が追加されたため、それで1度破綻しています。 I社のソフト(インストーラですが基本的にはコピーソフトです)がその機能に対して非常に高価だったからです。 また、開発ツールではありませんが、最近では性能が良くなってきたWindows Defender がOS標準で搭載されいることで、ユーザーのウィルス・セキュリティソフト会社離れなどがあります。

Qtを使う上で、GUIのライブラリに関係なくその作法に従わなければならないところが多数あります。

例えば、文字列の扱いです。
ATL/MFC ではCString, STLではstd::string ですが、QtではQStringを使います。 ほとんどのコードでストレスなくQtを使うには、QStringに書き換えることになると思います。 Qtの優れた機能の一つとして、多言語対応がかなり簡素化できるという特徴があります。 単一言語のアプリを多言語対応にするため、追加・変更すべき部分が少なく、特別な仕込みを強いられることが少ないのです。 (もちろん、言語の違いによる文字列サイズ・語順・翻訳文に関する作業は必要です。) この点に関しては、MSは過去大きな失敗?(大幅な仕様変更を余儀なくされた)いくつかしています。
まぁ、かつては、ユニコードが広まっていなかったせいもありましたが…

VS2019との連携の問題

ここでは、私が最近経験した VS2019との連携問題を記します。

Qt_INCLUDEPATH_ が定義されない。

VS2019に .Proプロジェクトをオープンするとき、Qt_INCLUDEPATH_ が生成されない問題があります。 これ以外に3つくらいマクロが生成されていません。

ビルドすると、Qtのインクルードファイルが見つからないとなり、コンパイルできません。
QMakeの問題であるらしい。

  1. QTVSADDINBUG-819

Qt_INCLUDEPATH_ not defined で報告されていますが

インクルードパスだけの問題ではなく、UIファイルもできないようであるのでこのパスの追加だけではNGです。 
5.15.2で修正されるであろうというレポートがありましたが、依然修正されていません。

回避方法

回避するには、システムの環境変数 VSINSTALLDIR にVS2019のインストール場所、
例えば以下のようなパス

%ProgramFiles(x86)%\Microsoft Visual Studio\2019\Professional\

を設定した後、.Proプロジェクトをオープンします。
取りあえず(work around)上記の問題を避けることができます。

ここで重要なポイントがあります。 パスの最後に必ず\を付けて下さい。
QTVSADDINBUG-819 の work around では \ がありません。
\ がないと、cl.exe が見つからないエラーが Qt Creatorのビルドで出ます。
私はこれで、少し嵌まりました。

ちなみに最後の \ がないと、Windows のスタートボタンから始まる
Visual Studio 2019 フォルダの
 x64 Native Tools Command Prompt for VS 2019 メニューのバッチを実行しても

[ERROR:team_explorer.bat] Directory not found : "CommonExtensions\Microsoft\TeamFoundation\Team Explorer"

のようなエラーを起こしてしまいます。

プロジェクトプロパティの調整

proファイルの新規読込または、再読込後、Visual Studio 2019(v142) に修正して下さい。 何故がデフォルトでは、Visual Studio 2017(v141)になってしまいます。
また私は、Debug, Releaseとも 以下に設定します。

出力ディレクトリは 

$(Platform)_$(Configuration)

中間ディレクトリは 

$(Platform)\$(Configuration)

これにするのには、深い訳があります。 生成された exeファイルから見たパスの問題があります。 一般に、アプリケーションは、exeファイルだけではなく、dll, ヘルプファイル、ドキュメント、サンプルデータ、などと配布されることが常で、それらも一元管理し、ビルドと同時にインストールしたときと同じようなパス構成にして、動作確認するためです。 それに都合がよいのです。

出力ディレクトリにdll類をコピー

上記以外の設定は、例えばインテルコンパイラやMath Kernel Libraryを使うとかによって子追加の設定が要ります。

また、出力ディレクトリには、Qt のdll やその他必要なdllを配置しておきましょう。

Qt のrelease用のdll は以下のようなバッチを使えば、一括して出力ディレクトリにコピーできます。

set STARTDIR=%0\..
call C:\Qt\5.15.2\msvc2019_64\bin\qtenv2.bat
echo on
pushd %STARTDIR%
call "C:\Program Files (x86)\Microsoft VisualStudio\2017\Professional\VC\Auxiliary\Build\vcvarsall.bat" x64
echo on
pushd %STARTDIR%
windeployqt.exe --release .
rename D3Dcompiler_47.dll d3dcompiler_47.dll
pause

Qt のdebug用のdll は pdbファイルも必要ですので以下のようなバッチになります。
debug ビルとするとMyProg.exe, MyProg.ilk, MyProg.pdb はあると思います。

set STARTDIR=%0\..
call C:\Qt\5.15.2\msvc2019_64\bin\qtenv2.bat
echo on
pushd %STARTDIR%
call "C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\VC\Auxiliary\Build\vcvarsall.bat" x64
echo on
pushd %STARTDIR%
windeployqt.exe . --pdb --debug
rename D3Dcompiler_47.dll d3dcompiler_47.dll
pause

コメント

タイトルとURLをコピーしました