2021年3月17日編集
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 のものと比べて、同じファイルのソースコードを左右に同時に複数開くことができるので、コードの探索や編集には非常に重宝します。
Visual Studioのエディタは見通しが悪い
Visual Studioのエディタは同じファイルを上下にしか開くことができませんので、同じファイルの複数箇所で、コードスニペット的な編集をするとき、非常に見通しが悪いです。 本格的なクラスを作るときは、1クラスが数千行になることはめずらしくなく、複数箇所を同時に開きたいことがよくあります。
上下表示だと見える範囲が狭く作業しにくいこと極まりないです。
また、ポップアップで多重表示できますが、上下表示には変わりありません。
ディスプレイは横長ですからね。左右表示が自然でしょう。
昔からそうですが、どうもコンパイラや開発ツールを作る人は、数十万ステップとなる本格的なアプリを作成したことがないのか、比較的小規模のプログラム開発を想定しているようです。 恐らく、小規模のプログラムでしかテストしていないのでしょうね。 数十万ステップの中から、オーバーロードやオーバーライドされたメソッドのサーチ・編集作業のテストなどしていないと思います。
Visual Studioの検索履歴も二つしか保存されないのも使いにくく、見通しの悪さに拍車を掛けています。 これらは20年以上変わっていません。 一方、Qt Creator は、検索履歴の記録には制限がありません。
また、インテリジェントセンスやエディタ上部にあるクラスのメソッドリストも、少し、コードが大きいと端折られます(一部しか出てこない)。 デバックやコード編集なのど作業では、検索漏れは致命的です。 つまり、unixのgrep コマンドのような文字検索に頼るしかないのです。
結論、開発フェーズで使い分け
結局、新たクラスやメソッドを作るという作業では、Qt Creator を使い、実行時の込み入ったデバッグをするには、Visual Studioを使うことになります。 また、最終的にパフォーマンス上げるためインテルコンパイラでコンパイルまた、並列化のチューニングするためにも、開発後半の段階で、Visual Studio + Intel Parallel Studioを
Qtの問題点
Qtは良いライブラリなのですがいくつか制約や問題点があります。
ソフトハウスが採用するには、技術的にも・経営的にもそれなりの覚悟が必要です。
- Qt 5が出てから10年以上日にちが経っていますが、入門レベルのものを除き、日本語の適切な書籍はありません。 まともに、自分のアプリに使用するには、英文とサンプルコードに対しての検索力が必要です。 また、Qtは頻繁に更新されますので、書籍に頼ることはほぼできないでしょう。
- ライセンスの問題があります。 LGPLとして使用する場合、ダイナミックリンクでなければなりません。 また、Qtのソースを改変して利用した場合もその部分のソースをGPLとして公開しなければなりません。
※スタティックリンクしてしまうと、GPLとして自分のものを含めすべてソースを公開しなければなりません。 つまり、著作権放棄・複製し放題になるので商用アプリとしては使えないに等しいのです。 LGPL(劣化GPL)の場合は、自分のソース部分は公開しなくてよいので、決まりを守らねばなりません。 - LTS(長期安定バージョン)がLGPLで使用できなくなりました。 制限が付き、金儲けに少し走り出したみたいです。 コロナ禍で経済が縮小している中、固定費削減がIT系でも課題となっていることから、MSやインテルをはじめ、値下げ・制限解除を傾向であるのに、この経営戦略は反対に走っていると思います。 ユーザー離れが生じなければよいのですが。
- ソースをかなり汚染します。 Qt独自のマクロや設定をソース側に取り込まなくてはなりません。 従ってQtのバージョンが変わるとソースレベルで修正が生じます。
- Qtの作法でプログラム・クラスを設計しなければなりません。 これについては後述。
- 大抵の場合は自分がやりたい操作はQtが用意してくれていますが、設計が悪いのかもしれませんが、たまに想定外のことをしようとする大変難しいです。 Qtは、イベント関係がユーザのソースだけ見れば比較的簡単になりますが、モッキングでUI のためコンパイル時にソースを自動生成する部分があります。 つまり、これはコンパイル時に決まってしまう静的なものなので、例えばUIの部品動作を既定のものと違う動的な造作にしようとするとかなり難しくなります。 また、生成されたソースがエラーを起こした場合、その解決も困難を極めます。
- 商用版は目が飛び出るほど高い。 とても、シェアウェアを作成している個人や弱小ソフトメーカーには使えません。 LGPL版から考えると商用版はとてつもない崖となるのです。
VS2019との連携の問題
ここでは、私が最近経験した VS2019との連携問題を記します。
Qt_INCLUDEPATH_ が定義されない。
VS2019に .Proプロジェクトをオープンするとき、Qt_INCLUDEPATH_ が生成されない問題があります。 これ以外に3つくらいマクロが生成されていません。
ビルドすると、Qtのインクルードファイルが見つからないとなり、コンパイルできません。
QMakeの問題であるらしい。
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
