UI以外のアプリケーションにQtを使用したいと思っています。アプライアンスで実行できる可能性がありますが、デスクトップから開始します。UI部分（私が知っている、非UIと言った）は、HTML（5）/AJAXを備えたWebサーバーになります。
私は実際には、スレッド、同期、シリアル化、リソース（文字列、おそらく画像）、国際化などの基本的なクロスプラットフォームのものにのみQtを使用します。
QtとBoostのどちらがこのようなもので、クロスプラットフォームレイヤーを自分で作成するのに適していますか？
Qtは私が必要としていることに少し重く感じますが、他の人がどんな経験をしているのか聞きたいです。
はい、QtCore（およびその他の非GUIモジュール）を使用すると、必要なことを実行できます。BoostとQtCoreのどちらかを選択すると、どちらも良い仕事をし、時にはインターリーブします。しかしいつもではない。
Qt（Core）は主に機能を提供します。Boostは、主に機能を実現するためのツールを提供します。たとえば、QtではなくBoostにテンプレートとファンクターがあります。OTOH、メッセージポンプなどが必要な場合は、Qtでしか見つかりません。
それは本当にあなたが達成しようとしていることに依存します。
はい、私の意見ではそれは完全に大丈夫です。たとえば、そのようなタスクに非常に広く使用されているJavaと比較して、Qtが重いとは言えません。Qtは非常に強力で、クリーンで、簡単で高速です。私はそれをよく使います、そして私はそれの大きな欠点を知りません。
あなたが提案していることは完全に合理的です。プラットフォーム間で多くの機能（あなたが言及したスレッド化など）を使用したいと考えています。基本的に、次のようないくつかのオプションがあります。
オプション1（悪い）：独自のクロスプラットフォームラッパーを作成します。あなたは車輪の再発明をするでしょう、そしてあなたはおそらくQtがすでにしているほど多くのクロスプラットフォームのケースと機能に取り組むことができないでしょう。このオプションは、コードを継承する人は誰でも、十分にサポートされ、十分に文書化された簡単にアクセスできるライブラリではなく、カスタムライブラリを処理する必要があることも意味します。
オプション2（非推奨）：スレッド化、ネットワーキングなど、必要なすべての機能に個別のクロスプラットフォームソリューションを使用します。これは、将来、多数のライブラリとの互換性を維持する必要があることを意味します。
オプション3（推奨）：すべてのニーズを満たすために、十分に文書化された、簡単にアクセスできる単一のライブラリを使用します。Qtは法案に適合します。