C++/CLI part3

>>935
ええー。今時、WindowsでGUIを書くのにC++を使うなんて、マゾとしか思えん。
逆ならわかるがねぇ。
GUIをC#で書いてモデルや下回りをC++でってなら。

すまん枠描くのはControlPaintだった
よっぽど深い相互運用しない限りはexport/DllImportの手間を差し引いてもC#の方が楽だし
安全だし取り回ししやすいよ

>>936-937
むう、再検討します。

いわゆる普通の ウィンドウ枠は WS_BORDER だぞと。
普通は CreateParams オーバーライドして Style プロパティに
WS_BORDER のビットフラグ立てたのにするだけ。
3D 枠とかも基本は一緒な

いやWindowsネイティブのコントロールに対応しない独自描画のカスタムコントロールの場合は
枠も自分で描くべき
標準のコントロールもそうなってる

そもそもコモンコントロールだってただの画像だしな

C++/CLI と C# embedded C++ どっちがいい？

3択な上に比較対象がおかしい。

何がしたいのかも判らんのに「どれがいい」も糞もないけどな。
WM (CE) の話で C++/CLI or C# or eVC++ のどれか、っていうなら
…いや、やっぱり好きにしろとしか言えないｗ

(C++ in C#) の意味では？

>>942-943
ﾜﾛｗ

これからはC++0x/CLIの時代だろ

敵はObjective-C++0xだな

今までC++とC#ばかりいじくっていたが、Google様にお伺いを立てると
実行速度は

C++ > C++/CLI > C#, VB.NET らしい

C++/CLIの方が効率よく高速なMSILに変換される仕組みでもあるのかな？

無いし実際同じ

C++/CLI はネイティブコードで書いた部分の実行速度が速いからとかじゃ？

ボックス化された値型とかトラッキング参照とか駆使して低レベルな最適化をやれば速くなるかもしれないけど
JITのバージョンアップであっさり逆転したりしそうだ

検証に使用したコードがないと話にならんだろ。

C#よりもC++/CLIの方ができることの制限が少ないから、速いコードを書くこと余地は大きいだろうね。
C++はUnsafeだから、こういうのを単純に比較しても意味ないと思うんだけどな。

一般に将来的な最適化の妨げになるしなあ

C++/CLIの速さはこの2つを足して2で割ったところとしているんでしょ。
マネージ部分の速さ = C#, VB.NET
ネイティブ部分の速さ = C++

まあアンマネージだけで書いたらC++もC++/CLIも変わらんわな
マネージだけで書いたらC++/CLIもC#も変わらんわな

測ってないけど

くだすれ落ちているのでここで失礼します。

unmanagedなバイト配列(unsigned char* byteArray, int len)を
managedな配列(array<Byte>)に変換したいと考えています。
とりあえずインデクサをつけて一個一個代入していったり、
Addしてみたりしたのですが、随分と処理に時間を喰ってしまいます。
そこまで速度に神経質なプログラムでも無いのですが、
もっとスマートに配列を変換する方法は無いものでしょうか。

Marshal.Copy(IntPtr, byte[], int, int) とか。

>>959
Marshal探せば良かったんですね。
Managedメモリを固定して確保してからmemcopyとか、明後日の方向に向かって努力していました……。
どうもありがとうございました。

C++/CLIは/clr /clr:pureでは常にunsafeであり、
Cタイプの配列を使った場合のパフォーマンスが良い。１〜２割程度。
C++/CLIの暗黙のP/InvokeはSuppressUnmanagedCodeSecurityAttributeがデフォルトでオンなので、
C#のP/Invokeに対してパフォーマンスが良い。２〜３倍程度。
C#のP/InvokeにSuppressUnmanagedCodeSecurityAttributeを追加するとその差はなくなる。
またC++/CLIのリンク時に/CLRUNMANAGEDCODECHECKを付けると、
この属性がオフになるためパフォーマンスはC#と変わらなくなる。

C#でも一応スタックに配列取ったりマネージ配列やアンマネージ配列にポインタでアクセスしたりできるよ

マネージドで書いとけばいいのにやたらアンマネージド呼び出して
結果マーシャリングコストばっかりかかってパフォーマンス悪化とか、ありそうな話

VS2010でインテリセンス外されたね
どうせ2008でもロクに機能してなかったし所詮ちょっとした橋渡しに使うだけだからどうでもいいけど
MSにとってのC++/CLIの優先度の低さは凄いな

MS特有の言語なんて使う奴は馬鹿

もともとから橋渡し専用言語だ
勘違いした奴が悪い

J言語とかと同じような扱いだろ

役に立たない機能ならなくなってもいい。
だがC++/CLI自体がなくなっては困る。
たとえ使う頻度が少なくても。

.Netごとなくなればいいだろ

MSがネイティブコード非推奨なら、unixと棲み分けができて丸く収まるんじゃないの

思うんだけど
/clr:safeとかclr:pureだったりするとインテリの構文解析も
それほど手間がかからないと思うんだが。

STLとかほかのヘッダ使うときより

それならC++/CLIなんかわざわざ使いません

それだとC++/CLIあんまり使わないだろ。

ネイティブいらないなら普通C#使う。

あえてC++/CLIを使う必要があるのってどんな時だ？

C++用ミドルウェアのC#用ラッパー作る時

HOGEHOGE *hoge
open(&hoge)
ってやるとhogeを自動的に割り当てるCで書かれたDLLがあって

これを呼び出そうとしてるんだけど
マネージド側からHOGEHOGE*をどう渡せばいいのか分かりません

cli::interior_ptr<Type>' から 'HOGEHOGE **' に変換できません。
とか言われてます

事故解決

クラスメンバに定数を持たせるにはどうすれば？

Hoge.Func(Hoge.Options.Option1)みたいな

literalかinitonlyで変数を宣言する
literalはコンパイル時定数でinitonlyは普通の読み取り専用フィールド
でもクラス外から見えるような定数をliteralにするのはバージョン管理上の問題があるので
.NETではなるべくinitonlyを使う

public ref Class HOGE
{
public:
ref struct Options
{
literal Int32 Option1=1;
};
};

ってやるとInt32の前に;が必要ですとか言われます
調べた限りこれでいいと思うんだけどなんででしょう

literal System::Int32 Option1 = 1;

>>981
同じですね
コンパイラにliteralが認識されてないみたいです
青色になってるからＩＤＥは認識してるみたいなんですけどね
なんか宣言とか要るんですか？

ああ、原因が分かりました
C++のヘッダをincludeした所から下がunmanagedでコンパイルされてたみたいです

それより>>979のような使い方をするならenum classにすればいいのに