メインソリューションにリンクされているDLLをターゲットにしたライブラリを構築しています。
この新しいDLLは非常に複雑で、C ++ 11の機能を利用したいのですが、それをリンクするプログラムは確実に利用しません。実際、メインプログラムは現在、VS2008とVS2010を使用して「クリーンに」構築されています（Linux用のGCC 4.3だと思いますか？）。
私が提案するもの：
VS2012をIDEとして使用し、IntelC++コンパイラ2013を使用して.dll/.so（Linuxの場合）にコンパイルします。これは、私が理解しているように、基本的にマシン形式（.exeなど）に依存します。
私はC++を使用して問題を解決することに精通していますが、コンパイル/リンクなどの基本に精通していません。したがって、コミュニティに質問したいと思います。
- これは可能です
- 可能であれば、それはどれほど簡単ですか（私が説明したように単純ですか？）/途中でどのような落とし穴や問題が予想されますか（それは価値がありますか）？
私が予想する懸念事項：
- ランタイムライブラリ-これがこの取り組みを妨げる要因になると思います。問題になるかもしれないことを除いて、私はそれらについて/それらがどのように機能するかについて何も知りません。
- 標準ライブラリの実装の違い-DLL形式であるかどうかは重要ですか？
- スレッドの競合-dllスレッドとメインプログラムスレッドが同じデータを変更することはなく、実際にはメインプログラムのスレッドの1つがDLL関数を呼び出します。
ボーナス：上記は私がとることを期待しているルートですが、理想的には、このコードをインテリセンス、一般的な表示などのために開いておく必要があります（基本的にはメインソリューションのプロジェクトになるためです）。別のランタイムライブラリ/コンパイラを指定する方法はありますか？これはできますか？
編集：このボーナス部分の主な理由は、メインプログラムとこのライブラリが別々に構築されている場合に発生する必要な「バージョン管理」の競合を排除することです。
注：私は新しいためだけにC ++ 11を使用していません-強く型付けされた列挙型とクロスプラットフォームのスレッデッドコードは、ライブラリにとって大きなボーナスになります。