C++/CLI について語ろうぜ Part2

>>936
C#は標準でP/Invokeの呼び出しのたびにセキュリティチェックがかかるようになっている。
一方C++/CLIはデフォルトではチェックは発生しない。
C++/CLIで/CLRUNMANAGEDCODECHECKリンクオプションでC#と同等になる。
C#の方はSuppressUnmanagedCodeSecurity属性でチェックを無効に出来る。
双方の条件を合わせるとパフォーマンスの差はない。

クラスに型と同名のプロパティーが在った場合、
その型を名前空間なしで使うとあいまいエラーがでるのね。
C#だと大丈夫なのに。

それはそれは

そんなもの作るなよ

http://dobon.net/vb/dotnet/beginner/namingrules.html
プロパティには、その型と同じ名前をつけることができる。例えば、CacheLevel という名前の列挙型がある場合、その値を返すプロパティにも CacheLevel という名前を付けることができる。

コンストラクタとも被るな

>>949
そりゃ名前つけるのは自由でしょ
C++/CLIの場合は型名よりメンバ名が優先されるから不便なだけで

.NETのクラスライブラリに普通にたくさんあるだろ型名と同じ名前のプロパティなんて

それなんてアンチパターン？

C#だとVSで型名が色分け表示されてるからわかりにくくはならない

色分けしないと分からないソースコードｗ

http://msdn2.microsoft.com/ja-jp/library/ms229012(VS.80).aspx
>プロパティには、その型と同じ名前を付けるようにしてください。
>列挙型に厳密に型指定されたプロパティを使用する場合は、
>プロパティの名前を列挙型の名前と同じにできます。
>たとえば、CacheLevel という名前の列挙型がある場合は、
>その値のいずれかを返すプロパティにも CacheLevel という名前を付けることができます。

こういう衝撃的なガイドラインがあるんだ

それ、何て、要Option Explicit？

文盲現る。

Ｃ丼ダサダサ

例えばフォーム等で Size を返すプロパティが Size なのはとても自然だと思うが。

using System::Drawing;

ref class Hoge
{
public: property Size Size;
private: Size m_size; ←えらー
}

Sizeとだけ書くと全部Hoge::Size扱いになるよね。

System::Drawing::Sizeと書けばよい

俺はnamespace dr = System::Drawing;派。
C++でusingディレクティブは使うなって言われるけど、
C++/CLIだと使えないということをよく実感する。

System::Collections::Generics::List<clr::autohandle<Apple>> apples;
で要素を削除しても、~Apple()は呼ばれないみたいです。
どうしますか？

ファイナライザ書いたら？

リストに入ってるうちに殺れば？

Javaやってるとnewしたまんまほったらかしにするのは
道具をしまったりゴミをゴミ箱にまとめるのをサボってるようで
あまりいい気がしない。

>>964
何で削除されないかと言えば、Listで要素を削除しても
Listは削除した要素のデストラクタを呼ぶわけではないから。

>964
auto_handle による解放タイミングが GC での回収時なんじゃね？

>>964
auto_handleがdeleteされないからAppleもdeleteされない。

デストラクタやファイナライザはどうしても必要な場合でなければ書いてはいけない
特にファイナライザ

ゲームとかヤバイ

この言語って機能が多すぎて大人数でプログラム組むの大変じゃない？

機能をアセンブリ化で分類して適切なスキルの人間に適切な言語で触らせればいい
問題になった場合、それができていないと言うこと
スキルがなければ、VB や C# で書けばいい。なにもかも、C++/CLI のみでやる必要はない

CとC#の橋渡し以外は使う必要ないだろ

o 取り込みたいネイティブライブラリがDLLでのエクスポートを考慮してくれていない
o 取り込みたいネイティブライブラリがクラスライブラリ
o C#で書こうとするとP/Invokeのための宣言や型定義がめんどくさそうな状況
o パフォーマンス上の理由でマーシャラの仕事が邪魔

こんな時に仕方なく使う言語ってところだな。
逆に言うと「こんな時」が多すぎて無いと困るんだけどさ。
.NETのネイティブとのダイレクトっぷりはJavaに対する優位性のひとつだと思うんだけど、
あんまりその文脈では語られないよなぁ。
むこうはそのために発生した複雑性が欠点と思ってるからかしら。

ネイティブを全く考えないで良い状態が理想郷だからな

/clr:pure

中身を書かない property で set だけ protected: に出来ますか？

できるよ

むり

中身書かないトリビアル・プロパティはアクセス指定書くところがないからな

>>974
無駄に機能拡張しただけの印象を受ける

>>983
具体的にどんなところが無駄だと思う？
達成目標がアクロバットすぎるので誰が作ってもこんなもんだと思ってるんだけど。

一度Managed C++を経ているからずいぶん考えられていると思うが。

STLのコンテナに入れたものは
削除した時点でつぶされますか？

std::vector<T> v; として、
要素を削除した際、T のデストラクタは呼ばれる。

T がポインタで、そこに new したアドレスを入れているような場合、
それは delete されない。
その目的には boost::ptr_vector が使える。

( ･∀･)つ〃∩ ﾍｪｰﾍｪｰﾍｪｰﾍｪｰﾍｪｰ~

^付けないと入れられなかったorz

いや、^ つけても、STLコンテナにマネージド・オブジェクト入れちゃ駄目だろ
そのための STL/CLR じゃまいか

勝手に作られる関数
インデントおかしい。
インデント設定、もしくは、インデントをきれいにする方法ってありあすか？

C++エディタにはそういうの一切無いよ。
たしかにC++/CLIのフォームデザイナの吐くコードは
ケンカ売ってるとしか思えないｗ

コレクションの中身を自動変数風にすることは出来ないの？

value class Hoge;
List<Hoge> hoges;