Qtの危険なコーナーは何ですか？[閉まっている]

太陽の下では完璧なものはありません。Qtも例外ではなく、制限もあります。GUI以外のスレッドではピックスマップを使用できません。16ビット/チャネルの画像形式でQImageを使用することはできません。

Qtの制限のために設計を台無しにせざるを得なかったのはどの状況ですか？
最も嫌われている癖は何ですか？
Qtをプロジェクトで使用する際に避けるべき設計上の決定はどれですか？

皮肉なことに、Qtのパワーも欠点の1つだと思います。非常に多くの強力な構造と拡張があり、Qtで記述したコードは「Qtの方法」で簡単に高度に固定化されます。機能を別の言語に抽出しようとすることは、書き換えを意味するだけでなく、Qt固有の多くのテクノロジーを知る必要があります。

Qtの幅広さは、プログラマーを雇うことは、Qtの経験を持つ誰かにコミットするか、その専門知識のためのトレーニングを意味することを意味します。請負業者を迅速に受け入れることは、バニラC ++よりも困難です。

Qtが3.xから4.xに変更されたとき、私たちのチームは移植に約9か月を要しましたが、その間、新しい機能はほとんど追加されませんでした。あなたは、残りの時間に開発効率を向上させることで、その主要なアップグレード費用を補うことを望んでいます。（注意：Qtの利点は省略しましたが、その中にもたくさんあります）

Qtは標準C ++ライブラリを使用しませんが、独自のQString、QVector、QMapなどを備えています...

つまり、重要な設計上の決定を行う必要があります。アプリケーションのどの部分がQStringを使用し、どの部分がstd :: stringを使用するのですか？

一部の部分でstd :: stringを使用し、他の部分でQStringを使用することは、境界でQStringとstd :: stringの間で変換する必要があることを意味します。

このオーバーヘッドを回避するために、アプリケーション全体でQStringを使用することを決定できます。しかし、それはQtに基づいていないサードパーティのライブラリ、たとえばboostを使用することをはるかに困難にします。

（同じことがstd :: map対QMap、std :: vector対QVectorなどにも当てはまります）

決定Qtのタイプを使用している部品は、STLを使用している部品大きな意味を持つ主要な設計上の決定、です。また、Qtが標準のC ++ライブラリの使用を拒否しているためです。

私見、その決定は、プロジェクトに応じて、どちらにでも行くことができます。そのため、どちらを避けるべきかという質問には答えられません。

これは質問に直接答えるものではありませんが、言及する価値があると思います。おそらく、Qtの最も「危険な」側面は、NokiaがMSoftに乗り込んだことです...

最近、QCharはその名前にもかかわらず、実際には1文字ではなくUTF-16コード単位に対応していることがわかりました。したがって、任意のUnicodeテキストを文字ごとにスキャンする場合は、上位および下位サロゲートを処理したり、文字を組み合わせたりするためのアルゴリズムを追加する必要があります。