堕天使の煉獄

うーん。

一応QT5.6のMinGWは…gcc4.9.1？　4.9.2じゃないのかな。古い情報なのかもしれないけど。とにかく、そこそこc++14にも対応してるわけなのですが。

いかんせん、IDEであるQT Creatorがc++14対応がまだ不完全なようで。

もうvc++ではとっくに使えていたような物がうまく動かない（インテリセンスが効かない）

auto data = SmfFile::Open();
data->ここでインテリセンス効かずに候補が出ない。

std::shared_ptr<SmfData> data = SmfFile::Open();
data->だと出る。

と、もはやauto使うのが常套になってるので不便極まりない。

for(const auto& v : data->track_list()){
v->これもインテリセンス効かない。
}

QTには、独自のforeach文があったりするのだけども、いまではもうｖｃ++とかとコードの共有考えると普通にstdのrange-based forを使うのが好ましいのだけども。
困ったことに上記の場合、要素がstd::mapのとき、firstやsecondすら出てくれ無かったりして。

せっかくautoでさっくり書けるのに、インテリセンス効かせるために型名書くのも面倒＆型が変更されたときにコードの書き換えが必要と、利便性も悪いコードになってしまう。
かといってインテリセンス効かないのもめんどくさい……。

一時はｃ++は進歩が停滞していたので、ＱＴは独自の拡張で一歩リードしていた感じだったのだけども、ここに来て急激に革新的な進歩を遂げはじめたｃ++に、今度はＱＴが置いてきぼりを食っちゃってる感じぽ。

んで、ｖｃ++の方でもそういう話が出てきてるのですが、ＱＴでもコードモデルにclangを採用ってな話があって。
んでもQT Creatorのオプションの所にclangコードモデルを使用するっていうチェックボックスがあるのは気にはなってたんですよね。
でも、なぜかグレー表示で、使用するにチェック出来ない状態で。
何か別途で入れなきゃ行けないのかなーとか思ってたんですが。でもclangのコードモデル適応したら、上記の型推論（auto）周りでもインテリセンス使える用になるのでわ？
とおもって、ちょっとググってみたら……。

メニューの「ヘルプ」→「プラグインについて」の所から、プラグインの一覧がでて。そこでclangのコードモデルのプラグインの所にチェックを入れてQT Creator再起動。
したらグレーになってたclangコードモデル使用するのチェックボックスがチェック可能になるという。

なぜデフォルトでないのかというと、clangコードモデル使用すると、コードの解析やエラー検出＆エラー文字なんかは秀逸なのだけども、その分遅いってのと、なんかclangコードモデル使うと良く落ちる……みたいな記事もあったりして。
まだまだ安定した機能ではないっぽい？

が、とりあえずオンにしてみたらば。
おお、autoからのインテリセンス効くようになってるぅ！

これはもう、使わないとやってられないだろ……とかおもったんですけど。

SFINAEでよく使うstd::enable_if_tがclangコードモデルだと定義されてないとかエラーになるんですよね。
ｖｃ++だとstd::enable_if_tは

namespace std{
template< bool B, class T = void >
using enable_if_t = typename enable_if<B,T>::type;
}

とすでに用意されていて、ＱＴでも（gccでもというべきか）用意されているようで、特に問題無くビルド出来ていたんだけども。（clangコードモデル適用前ではSFINAEのところで下線エラーになってたけどｗ　この辺のコードはvc++で使ってたコードの移植なので、コンパイラの対応はｖｃ++のが遅れてるけど、コードモデルの対応はｖｃ++のが進んでたと言う感じなのかなぁ。ああややこしい）
ていうかclangはコードモデル使うだけでコンパイラとして使うわけではないのでclangコードモデルとしてのエラー表示はでるけど、ビルドは出来る状態なので、それほどこまりはしないのだけども、エラーの赤いのがでるのは気持ち悪い。

うーん。でもなんか、clangコードモデルを使用するのチェックボックスのしたに、オプション指定するところがあるのだけども。その中にc++98とかの文字がはいってたりして。
なんかこれ、ここでもc++14とかのオプション指定がいるんじゃないのかな。
ＱＴのほうも、プロジェクトファイルに

CONFIG +=c++14

とかオプション必要だったりするので。

が、そもそもこのオプションの所。

-Wno-c++98-compat
-Wno-c++98-compat-pedantic

とか-Wno何とかって感じのがずらっとならんでるんだけど、Wnoってなんぞや？
……Warning no の略っぽい？？
うーん。
ここにコマンドラインオプション書くらしいんだけど……。

-std=c++14

とか？

と試しに書いて見たらば、std::enable_if_tのところのエラーが消えた……。

-std=c++1z

ｖｃ++の現行のサポート範囲を越えちゃいそうだけど、こっちの指定のがよさげかな。
てか、これでうまくいってるのかよくわからん。
全然ドキュメントが見あたらないので。それっぽいところは英語ページばっかだし……。


地味にenum classで内部型指定するとき

enum class EventState : quint8{
...
}

この型指定の部分上の例だとquint8の部分がハイライタ効いてなかったんだけど、clangコードモデル適応したらハイライトついたりして。

んでもenum classてc++11のそれもかなり早い時期に出てたような機能だとおもうんだけど。
コレすら対応してないQT Creatorのc++11以降の対応はかなり遅れてるんだなぁというのが今更ながらに。

ほんのちょっと前までは、ＱＴではSTLをあんまし使わないで、とくにコンテナ周りなんかはQTで用意されてるものをつかう感じだったのだけども（qtのコンテナ類はstlのよりも基本性能が良かったりもして）

ここ最近はすっかりc++11以降の書き方が馴染んでしまって、ＱＴのコンテナ系だとemplace系がなかったりするので、今回のように、midiの1イベントを1オブジェクトとか扱う場合、数千、数万のオブジェクトを生成するので、、生成→コピーは無駄がおおい。
生成と同時に挿入できるemplace使わないと精神衛生上気持ち悪い……となって、結局QObjectをリストに入れて使う様な時のみＱＴのコンテナ使って、それ以外の単純なデータではstlのコンテナを使う形になったりして。

コンテナ操作系も、ＱＴで用意されてるのよりはstlのアルゴリズム系とか使った方が、ｖｃ++に戻ったときに混乱少ないし……と、むしろＱＴ独自の部分をstlの共通コードに置き換えていく感じの運用の方向に進んでいったりと、なんだかＱＴでのコーディングスタイルもいろいろ変わっちゃったかんじぽ。

進歩の停滞してたｃ++を補完する形で進んでたＱＴの部分が、今になってちょっと邪魔に感じるのはなんとも皮肉というか、面倒なかんじになってるなぁと……。


しかしqt5.7はいつになるのか……
5.6はかなり予定が遅れてのリリースだったのだけど、5.7も順調に遅れているようで。
予定では6/15にリリースらしいんだけど。

5.7は、ｃ++11対応コンパイラが必須になるとかで、そうなると当然QT Creatorの方の対応も進んでくれるんだろうかなぁ。
今のところコンパイラよりもＩＤＥのQT Creatorが足を引っ張ってる感じなので……。

まだまだこの辺の環境はｖｃ++のほうもだけど、整備待ちな部分がおおいなぁ……。
やきもき。