Qtの危険なコーナーは何ですか？
太陽の下では完璧なものはありません。 Qtも例外ではなく、制限もあります。GUI以外のスレッドではピックスマップを使用できません。16ビット/チャネルの画像形式でQImageを使用することはできません。
Qtの制限のために設計を台無しにせざるを得なかったのはどの状況ですか？
最も嫌われている癖は何ですか？
プロジェクトでQtを使用しているときに避けるべき設計上の決定はどれですか？
皮肉なことに、Qtのパワーも欠点の1つだと思います。非常に多くの強力な構成と拡張機能があり、Qtで記述したコードは「Qtの方法」で簡単に高度に固定化されます。機能を別の言語に抽出しようとすることは、書き換えを意味するだけでなく、Qt固有の多くのテクノロジーを知る必要があります。
Qtの幅広さは、プログラマーを雇うことは、Qtの経験を持つ誰かにコミットするか、その専門知識のためのトレーニングを意味することを意味します。請負業者を迅速に受け入れることは、Vanilla C++よりも困難です。
Qtが3.xから4.xに変更されたとき、私たちのチームは移植に約9か月を要しましたが、その間、新しい機能はほとんど追加されませんでした。残りの時間は、開発効率の向上でその大きなアップグレードコストを補うことを望んでいます。 （注意：私はQtの利点を省略しましたが、その中にもたくさんあります）
Qtは標準C++ライブラリを使用しませんですが、独自のQString、QVector、QMapなどがあります...
つまり、アプリケーションのどの部分がQStringを使用し、どの部分がstd :: stringを使用するかという重要な設計上の決定を行う必要があります。
一部の部分でstd :: stringを使用し、他の部分でQStringを使用することは、境界でQStringとstd :: stringの間で変換する必要があることを意味します。
このオーバーヘッドを回避するために、アプリケーション全体でQStringを使用することを決定できます。しかし、それはQtに基づいていないサードパーティのライブラリを使用することをはるかに困難にします。ブースト。
（同じことがstd :: map対QMap、std :: vector対QVectorなどにも当てはまります）
決定どの部分がQtのタイプを使用し、どの部分がSTLを使用するかは、設計に大きな影響を与える主要な決定です。また、Qtが標準のC++ライブラリの使用を拒否したためです。
IMHO、その決定はプロジェクトに応じてどちらの方向にも行くことができます。したがって、どちらを避けるべきかという質問には答えられません。
これは直接質問に答えるものではありませんが、言及する価値があると思います。おそらくQtの最も「危険な」側面は、NokiaがMSoftに乗り込んだことです...
最近、QCharはその名前にもかかわらず、実際には1文字ではなくUTF-16コード単位に対応していることがわかりました。したがって、任意のUnicodeテキストを文字ごとにスキャンする場合は、上位および下位サロゲートを処理したり、文字を組み合わせたりするためのアルゴリズムを追加する必要があります。