08/03/25 21:13:54
おそらく、.NET開発でデファクトスタンダードに最も近い
であろうC++/CLIについて語ろうぜ！
このスレはC++および.NET Frameworkについて一定以上の知識を持っている人が対象となります。
.NETのクラスライブラリの使い方といった質問は姉妹スレ「くだすれC++/CLI（初心者用）」に
お願いします。
前スレッドはこちら
(p)ｽﾚﾘﾝｸ(tech板)
(p)ｽﾚﾘﾝｸ(tech板)l50
姉妹スレ
くだすれC++/CLI（初心者用）
(p)ｽﾚﾘﾝｸ(tech板)l50
managed C++ やろうぜ！！ 002
(p)ｽﾚﾘﾝｸ(tech板)l50
2:デフォルトの名無しさん
08/03/25 22:32:54
おつ
3:デフォルトの名無しさん
08/03/26 00:54:20
いらんたせろ
4:デフォルトの名無しさん
08/03/26 15:15:12
dataGridView等で、選択されてる行を消すって処理を
エレガントに描くにはどうすればいいですか？
今のところ
for( int i = 0 ; i < this->dataGridView->Rows->Count ; ++i )
{
System::Windows::Forms::DataGridViewRow^ row = this->dataGridView->Rows[i];
if( row->Selected )
{
dataGridView->Rows->Remove( row );
i=0;
}
}
です
5:デフォルトの名無しさん
08/03/26 15:40:32
それって最終的に全部消さないか？
6:デフォルトの名無しさん
08/03/26 16:06:45
>>5
selectedの時しか消さない(i=0)から問題なし
selectedしてない場合、ループの最後まで行くお
7:デフォルトの名無しさん
08/03/26 16:12:40
自動選択は？
8:デフォルトの名無しさん
08/03/26 16:17:19
自動選択って何？
上のコードでとりあえず動いてるから問題ないというか
質問を質問で返さないで
9:デフォルトの名無しさん
08/03/26 16:28:02
あああ、デフォルトでそんな機能あるやんね
10:デフォルトの名無しさん
08/03/26 20:12:53
List<Scene^> scenes;
// いろいろ
for each(Scene s in scenes)
{
delete s;
}
何か問題はありますか？
11:デフォルトの名無しさん
08/03/26 20:24:45
いろいろの最中に例外が投げられたらオワタ＼(^o^)／になる。
といってもGCとファイナライザで救済されるから
ネイティブC++のときほど気にかける必要はないかもしれない。
12:デフォルトの名無しさん
08/03/28 15:20:34
System::Collections::Generics～のコンテナ郡に
auto_handleは入れられますか？
13:デフォルトの名無しさん
08/03/28 15:22:51
はい
14:デフォルトの名無しさん
08/03/28 15:48:18
入れたところで、自分でauto_handleのデストラクタを呼ばない限り、
auto_handleの中身のインスタンスのデストラクタは呼ばれないぞ。
中身のデストラクタはauto_handleのデストラクタ (Dispose)から呼ばれるのだが、
BCLのコレクションは要素のDispose（デストラクタ）を呼ばないため。
15:デフォルトの名無しさん
08/03/28 15:54:16
意味ね～
16:デフォルトの名無しさん
08/03/28 15:57:17
おとなしくGCに従うのだ ははは
17:デフォルトの名無しさん
08/03/28 16:07:33
STL/CLRのコンテナでも無理なの？
18:デフォルトの名無しさん
08/03/28 16:14:24
無理。
19:デフォルトの名無しさん
08/03/28 16:20:33
無理ですかorz
20:デフォルトの名無しさん
08/03/28 20:55:35
ref class Banana;
List<Banana^> bananas;
for each (Banana^ b in bananas)
{
delete b;
}
21:デフォルトの名無しさん
08/03/28 21:01:32
Disposableなコンテナつくればいいじゃない
22:デフォルトの名無しさん
08/03/28 21:15:31
value型でauto_handleみたいの作ろうとしたらデストラクタが定義できなかった。
23:デフォルトの名無しさん
08/03/28 21:17:13
STLのコンテナだってstd::auto_ptr入れられないしね。
24:デフォルトの名無しさん
08/03/28 21:18:27
>>23
それとこれとは関係ないだろ。
25:デフォルトの名無しさん
08/03/28 23:44:30
でもさーGCはモノが使われなくなったら消えるんだから。
Vector<boost::shared_ptr<Hoge>>
と一緒じゃね？
26:デフォルトの名無しさん
08/03/29 02:16:39
25はわかるけど、それと23とのつながりがわからない。
27:デフォルトの名無しさん
08/03/29 08:41:05
>>25
タイミング
28:デフォルトの名無しさん
08/03/29 10:58:40
COMにすればよくね？
29:デフォルトの名無しさん
08/03/29 13:24:49
COMにもリリースのタイミングがあってだな
30:デフォルトの名無しさん
08/04/01 21:59:31
過疎
31:デフォルトの名無しさん
08/04/02 21:46:36
踏んだら孕んだ！
孕んだ振る降る般若だ！
童貞擦る無駄、フン出る春巻きはむ無理！
チン毛ちぎり、看板塗る飛騨！
安眠煮る焼酎！
安打！？半田ゴテ適時打！！
原チャリ盗んだ！
よくちょん切れるハサミだ！
∧__∧ ________
<丶｀Д´>/￣/￣/
（ 二二二つ / と）
32:デフォルトの名無しさん
08/04/08 06:12:29
const参照で受け取ったref classのプロパティって触れないの？
ref struct Foo
{
property int Bar;
static void Hoge(const Foo% foo)
{
foo.Bar;
}
}
error C2662: 'Foo::Bar::get' : 'const Foo' から 'Foo %' へ 'this' ポインタを変換できません。
const外すとコンパイル通ります。
getterちゃんと書いて、 int get() const とかやろうとすると
const 付けんなって怒られるし…
33:デフォルトの名無しさん
08/04/08 10:30:03
追跡参照の中身が固定されたらGCが起きたとき、追跡できないだろ
34:デフォルトの名無しさん
08/04/08 14:59:36
単にCLIにconstの概念がないから、
マネージ型にconst使おうと考えるなということ。
35:32
08/04/08 18:12:22
>>33
え？それは Foo * const foo とした場合の話じゃないの？
「中身」っていう言葉が何を指してるのかよくわからないけど…。
C++だったら、そもそも参照自体がポイント先の変更を許さない概念なわけだけど、
CLIで%なんてもの導入したからには、そのへんは宜しくやってるんじゃないの？
const参照はあくまでポイント先のメンバの不変性を宣言するものだと思うんだけど
>>34
CLIでは「このメソッドは引数のメンバフィールドを変更しません」って
明言する事はできないの？
C++常習者としては、それってすげー不安なんですけど…
36:デフォルトの名無しさん
08/04/08 22:10:35
>>33
とんでもないかんちがいをしている椰子ｗ
37:デフォルトの名無しさん
08/04/09 16:56:50
VC++2008のexpressでmsclr/marshal.h が見あたらないんですが、
もしかしてこれStandard以上にしか付いてないんですか？
38:デフォルトの名無しさん
08/04/09 22:00:49
error C4959: アンマネージ struct 'Microsoft::DirectX::PrivateImplementationDetails::_D3DPRESENT_PARAMETERS_' は、そのメンバへのアクセスによって検証不可能なコードを生成するため、/clr:safe で定義できません
とエラーが出ます。
39:デフォルトの名無しさん
08/04/09 22:13:02
>>35
というか.NETの参照渡しは呼び出し側に変更してほしい時にしか使わないお約束
40:デフォルトの名無しさん
08/04/09 22:27:20
^だけだと nullptr渡されない？
41:デフォルトの名無しさん
08/04/09 22:29:39
そうだよ。それで困るメソッドはArgumentNullExceptionを投げてくる。
42:デフォルトの名無しさん
08/04/09 23:30:38
モノ渡したら4バイト超えてたら遅くなるんじゃないの？
43:デフォルトの名無しさん
08/04/10 00:05:45
いや、^のハンドル型の実態はGC追跡付ポインタ。
引数や戻り値でも4/8バイトのアドレス値が受け渡されるだけ（少なくともCLRでは）。
.NET Frameworkのライブラリのクラスに、
コピーコンストラクタや代入演算子が定義されていないのは、
そういうわけで不要だから。
44:デフォルトの名無しさん
08/04/10 00:06:05
実際、XNAの算術ライブラリなんてガイドラインと逆走してるよ。
45:デフォルトの名無しさん
08/04/14 22:39:17
(一般ゲーム) [050325] [工画堂スタジオ] 蒼い空のネオスフィア -Neosphere of The Deep-blue Sky- (bin+cue).rar
46:デフォルトの名無しさん
08/04/15 23:23:14
このスレの住人なら知っていますね、あの糞開発ツールのことを
・自分のプログラムのバグなのかコンパイラのバグなのかわからない
・他の仕事に応用できない糞開発ツールの独自世界を必死に学習している
・テキストエディタで書いたほうが効率的なのに糞UIツールを懸命に使っている
・糞開発ツールを批判すると「性格が悪いから糞ツールを批判するんだ」と言われる
糞だけど、政治的な理由で無理やり使わされているんですよね。
もう、あんな厨の作った糞ツールを我慢して使うのはやめましょう。
・糞開発ツールを部下に押し付ける上司の命令は無視しましょう。
上司は糞開発ツールが使われる実績を作ることであの会社のごきげんをとっているのです。
・糞開発ツールを使わせる上司の下では働けません、と上司の上司に直訴しましょう。
・あの糞開発ツール提供会社には「おたくの糞開発ツールは話にならない」と突き放しましょう。
バグレポートなどしてはいけません。改善要求などもってのほかです。
あの会社はあなたたちのことをテスター/モルモットとしか思っていません。
・あの会議で「糞開発ツールを使ったら生産性がxx％アップしました」
なんて話が出たら力強く机を叩き、会議室を出ましょう。
あの人たちは糞開発ツールをマンセーすることで立場を確保しているのです。
糞な開発ツールを糞だと言える、そんな当たり前の環境をみんなの力で取り戻しましょう。
47:デフォルトの名無しさん
08/04/15 23:25:01
VisualAge のことですね。わかります
48:デフォルトの名無しさん
08/04/20 15:16:43
VisualAge
49:デフォルトの名無しさん
08/05/15 12:45:00
過疎るな
50:デフォルトの名無しさん
08/05/15 15:20:37
C++/CLIの達人になる意味って、ある？
51:デフォルトの名無しさん
08/05/15 15:54:40
「C++/CLIの達人」⊂「C++の達人」
だから考えるまでもなく意味はあるだろ
52:デフォルトの名無しさん
08/05/15 16:22:00
C++の達人とはまたベクトルが違うような
53:デフォルトの名無しさん
08/05/15 17:39:28
/ってorの意味じゃないの？
包含関係逆だろ！？
54:デフォルトの名無しさん
08/05/15 18:28:36
withの意味だよ。
55:デフォルトの名無しさん
08/05/16 23:33:06
「C++/CLIの達人」＝「C++の達人」 ∩「CLIの達人」
「C++/CLIの達人」⊂「C++の達人」
「C++/CLIの達人」⊂「CLIの達人」
56:デフォルトの名無しさん
08/05/17 03:40:44
下二つ反対だろ（ｗ
57:デフォルトの名無しさん
08/05/17 03:43:38
上も反対
58:デフォルトの名無しさん
08/05/17 08:55:34
おっぱい！
おっぱい！ おっぱい！
おっぱい おっぱい！ おっぱい！
おっぱい！ ∩ ∩ ﾉ) おっぱい！
おっぱい！ 川 ∩ 川彡'三つ おっぱい！
おっぱい！ ⊂ミ∩､⊂ミ∩彡⊃ おっぱい！
おっぱい！⊂三ミ( ﾟ∀ﾟ)彡三彡三⊃ おっぱい！
おっぱい！ ⊂彡川⊂彡川ミ⊃ おっぱい！
おっぱい！⊂彡川∪⊃ Ｕ川彡⊃ おっぱい！
おっぱい！ (ノ ∪ 川 ∪ミ) おっぱい！
おっぱい！ ∪ おっぱい！
おっぱい！ おっぱい！ おっぱい！
おっぱい！ おっぱい！
おっぱい！
59:デフォルトの名無しさん
08/05/17 20:32:41
C++/CLIの達人ってのが
C++ or CLIの達人だったら、
標準C++だけ知ってる達人とか、CLIのことだけ知ってる達人も
C++/CLIの達人になるけどいいの?
60:デフォルトの名無しさん
08/05/17 20:47:46
/clr:safe の達人というのがいるとすれば、C++が使えるかどうか怪しいよな。
61:デフォルトの名無しさん
08/05/17 23:23:05
それじゃ、Ｃ＃使え、だよな
62:デフォルトの名無しさん
08/05/18 15:14:16
C++/CLIのメリットってなんだろな。
safeで使いたいならC#だし、でなければC++でいいだろうし。
C++とmanagedのオブジェクトを両方使うのもあまり使い勝手が良くないし。
63:デフォルトの名無しさん
08/05/18 16:00:41
C++でしか使えない（使いにくい）ライブラリをラップするぐらいしか
64:デフォルトの名無しさん
08/05/18 17:23:00
だから>>55が正しいと思わんか？
65:デフォルトの名無しさん
08/05/19 10:55:20
C#でusingの嵐に嫌気がさした人にはC++/CLIは悪くない。
66:デフォルトの名無しさん
08/05/19 12:20:12
だらだらと長い名前空間を書かされるとしてもか？
67:デフォルトの名無しさん
08/05/19 12:35:56
using namespace書いとけばってのはC#だって一緒だが…。
ひょっとして、名前空間のインポートするときのusingディレクティブの話と、オブジェクトーのスコープを
定義する場合のusingステートメントの話をごっちゃにしてないか?
68:デフォルトの名無しさん
08/05/20 12:58:28
C++で作ったやつが
簡単？に.Netな画面のアプリで動かせるんだよ
69:デフォルトの名無しさん
08/05/20 16:30:17
printf()とか関数の呼び出しを書いたとき、
それがネイティブなのか違うのか、
コンパイラは、どうやって判断してコードを吐いてるのだ？
70:デフォルトの名無しさん
08/05/20 16:50:22
C++ではプロトタイプのない関数は呼べない。
71:デフォルトの名無しさん
08/05/20 19:03:52
>>69
リンク時に解決する。
実際にILからネイティブの呼び出す部分はJITで生成される。
72:デフォルトの名無しさん
08/05/20 19:26:59
この言語最高！
73:デフォルトの名無しさん
08/05/20 20:11:17
普通のクラスや関数とrefクラスが混ざったDLLを作るとわけわかめ全開になるよね。
74:デフォルトの名無しさん
08/05/20 20:34:58
確かに冗談みたいな汚さw
75:デフォルトの名無しさん
08/05/21 12:22:19
>>68
簡単だったらな。
76:デフォルトの名無しさん
08/05/21 18:01:48
簡単じゃないの？
77:デフォルトの名無しさん
08/05/21 18:23:20
＾
78:デフォルトの名無しさん
08/05/22 18:56:45
Sizeをいちいち、System::Drawing::Sizeって書くのがめんどくさいんだけど、
どうにかならんの？
なんで型名なのに、メンバのSizeが優先されちゃうの？
79:デフォルトの名無しさん
08/05/22 19:40:44
namespace dr = System::Drawing;
これでdr::Sizeってできる。
<windows.h>をインクルードして、Windows APIの名前と
.NETクラスライブラリの名前が被るときにも使える。
80:デフォルトの名無しさん
08/05/25 12:47:41
C# と比較して C++/CLI ってやってる人少いの？
81:デフォルトの名無しさん
08/05/25 13:09:03
C#とC++の橋渡し以外使う価値無いから、少ないだろ
82:デフォルトの名無しさん
08/05/25 13:35:04
C#かVBと組み合わせて初めて価値が出る言語だし
83:デフォルトの名無しさん
08/05/25 17:56:15
俺はCLIがメインｗ
84:デフォルトの名無しさん
08/05/26 01:54:15
すいません、WebBrowserで選択中のテキストを取得する方法はありますでしょうか？
WebBrowserやDocumentクラスにないですし、ExecCommandにも該当する方法はないみたいです。
クリップボードにコピーして取得する方法もないではないですが、クリップボードの内容を壊したくないので・・・
85:デフォルトの名無しさん
08/05/26 05:33:06
selection
createRange
text
86:デフォルトの名無しさん
08/05/26 07:46:28
>> 83
おれは、全部、C++ or C++/CLI でいいのにって思ってしまう
87:デフォルトの名無しさん
08/05/26 14:18:34
^
88:デフォルトの名無しさん
08/05/27 09:26:26
C#のP/Invokeめんどくせ。
この言語って、windows.hインクルードすれば、APIそのまま呼べるようになる？
89:デフォルトの名無しさん
08/05/27 09:32:36
呼べる
90:デフォルトの名無しさん
08/05/27 09:37:06
MFC で ＵＩ 周り作って、/clr オプションつけて内部で .net fx 使ってるけど、かなり楽
C++0x もいいけど、便利なライブラリフレームワークも重要だと思うんだ
91:デフォルトの名無しさん
08/05/27 12:02:26
MFCランタイムと.NETランタイムを両方使ってると思うだけで萎えるわ。
92:デフォルトの名無しさん
08/05/27 12:16:27
使い方が逆だろう
93:デフォルトの名無しさん
08/05/27 22:54:03
まあCWinFormsControlとかあるくらいだし、
そういう使い方も想定されてはいると思う。
主目的は移行用だろうけど。
94:デフォルトの名無しさん
08/05/28 05:12:11
CLIでDirectXとか使えんの？
95:デフォルトの名無しさん
08/05/28 05:42:15
XNA FrameworkはC++/CLIで書かれている
96:デフォルトの名無しさん
08/05/28 06:17:25
Managed Direct Xはどこにいったよ？
97:デフォルトの名無しさん
08/05/28 06:43:21
>>89
thanks
本格的に移行しようかな。
罠とかある？
98:デフォルトの名無しさん
08/05/28 09:17:47
.NET Frameworkがないと動かない。
あと罠ではないが、ハンドルの扱いは
SafeHandle が使いやすいぶんC#のほうが楽だと思う。
C++/CLIで確実にハンドルが解放されるようにするのは
ちょっと面倒なんだよね。
どっかで SafeHandle 使うようにした Win32API の DllImport集
公開されてないかなあ。
99:デフォルトの名無しさん
08/05/28 09:32:06
>97
ヘッダで定義されたdefineの衝突に注意。後、enum を混在させない
リソースの管理は、マネージドはマネージド、ネイティブはネイティブで管理する
.net fx をライブラリとして使える C++ と言う位置付けを忘れない
こんなところかな
COM の扱いが、com::ptr で済むのが楽だね
100:98
08/05/28 10:16:11
ごめん。やってみたら C++/CLI でも
C# と同じやり方で SafeHandle 使えたわ。
検索してもC#とVBの資料しか出てこないからできないもんだと思ってた。
コールバック関数要求するアンマネージド関数に
delegate 渡すこともできるな。
なんでこういうの紹介してるページがないんだ。
C#のコードばっか載せやがって。
ただし、こういう小技を使おうとすると結局自分で
DllImport書かなきゃいけないので windows.h との親和性は低いけど。
こういうの全部取り込んだ windows.h があればいいのに。
101:デフォルトの名無しさん
08/05/28 13:05:09
>>98－100
ありがとうございます。
API？STL？NET？
なんでもドンと来い。サクッと受け止めてやる！
って感じの言語みたいだね。
なんでもこいは諸刃の剣なので気をつけないと・・・
102:デフォルトの名無しさん
08/05/28 18:03:35
>>95
全部C++/CLIじゃなくて，C#を併用してるっぽい
103:デフォルトの名無しさん
08/05/28 18:29:52
>>100
Marshal.GetFuctionPointerForDelegate使えば、<windows.h>を活かせる。
ただreinterpret_castをしないといけないから、結局ラップしたくなる罠。
104:デフォルトの名無しさん
08/05/28 19:37:11
C# でできて C++/CLI でできないことは、あんまりない
105:デフォルトの名無しさん
08/05/28 21:47:27
WPF使えないしたぶんSilverlightも同じだろうね
106:デフォルトの名無しさん
08/05/29 00:46:31
WPF は普通に使えるだろ
XamlReader 使ってもよし、普通にコードで GUI 使ってもよし
Silverlight だって、アセンブリは C++/CLI の Safe コードで書けるんじゃないかな
試してみるか
107:デフォルトの名無しさん
08/05/29 09:25:26
あげるならXNAか
108:デフォルトの名無しさん
08/05/30 11:07:30
>>106
それで使おうと思う?
WPF自体が糞とかいうのは置いといて
109:デフォルトの名無しさん
08/05/30 11:10:08
WTL を使うのに比べれば、インテリセンスが標準で効くだけまし
110:デフォルトの名無しさん
08/05/30 14:46:01
マニアックな人しか使わんのかこれは
111:デフォルトの名無しさん
08/05/30 15:06:25
必要になったら使う、って感じじゃないか?
112:デフォルトの名無しさん
08/05/30 15:43:54
マネージ埋め込みリソースの参照がかなり面倒なんだけど、
なんでC#みたいに、Properties.Resources.リソース名で
一発アクセス出来ないの？
113:84
08/05/31 22:12:20
>>85
遅レスですが、
Document->DomDocumentを取得後に
その手順でできました。
ありがとうございます。
114:デフォルトの名無しさん
08/06/01 01:56:08
仕事で他の人間に頼まれて、何日かCLIでバリバリ書いた後、
C++に戻ると、ついつい"gcnew"を連発してしまう
115:デフォルトの名無しさん
08/06/02 17:32:52
C#のあとの配列newみたいなもんですね
わかります
116:デフォルトの名無しさん
08/06/03 15:50:13
C#のあとのfor eachみたいなもんですね
わかります
117:デフォルトの名無しさん
08/06/03 16:22:02
それは無い
118:デフォルトの名無しさん
08/06/03 19:09:28
あるあｒｙ
119:デフォルトの名無しさん
08/06/04 00:21:57
＾←これなに？
ポインタモドキ？
120:デフォルトの名無しさん
08/06/04 00:39:41
それはハット
121:デフォルトの名無しさん
08/06/04 08:21:37
マネージドアプリを C++/CLI で作るのは邪道ですか？
122:98
08/06/04 08:46:51
あんまりメリットはないと思う。
123:デフォルトの名無しさん
08/06/04 18:00:03
MS的には事実上非推奨
124:デフォルトの名無しさん
08/06/04 20:36:39
C++/CLIのメリットって何？
125:デフォルトの名無しさん
08/06/04 20:44:05
C++でしか使えないライブラリを.NET用にラップするのが簡単になることじゃないか？
126:デフォルトの名無しさん
08/06/04 23:19:21
あとはCOMのインターフェースを扱うときとかな
OSが実装しているCOMのインターフェースをC#やVB.NETで書き直すのは馬鹿らしい
127:デフォルトの名無しさん
08/06/04 23:22:01
逆にC#のメリットって何？
128:デフォルトの名無しさん
08/06/04 23:56:57
書きやすい
129:デフォルトの名無しさん
08/06/05 00:28:30
情報（サンプルソースなど）が豊富。
130:デフォルトの名無しさん
08/06/05 00:35:15
ヘジたんが好きです
131:デフォルトの名無しさん
08/06/05 14:05:42
なんか、この手の質問ループしてないか？
132:デフォルトの名無しさん
08/06/06 15:58:50
過疎るな
それ以外の話題がないのかｗｗｗｗｗｗｗｗ
133:デフォルトの名無しさん
08/06/06 18:56:24
.NET各言語のまとめ
C++/CLI 闇ナベ言語
C# ヘルスバーグ萌え言語
VB 建て増しを繰り返した温泉旅館言語
J# J++手切れ金言語
JScript.NET （´･∀･`）ｹﾞﾝｺﾞ
F# 趣味言語
134:デフォルトの名無しさん
08/06/06 19:58:55
Spec#とSing#……勝手に☆拡張！
135:デフォルトの名無しさん
08/06/06 21:30:05
>>133
F#ってFortran#かForth#のどっち？
136:デフォルトの名無しさん
08/06/06 21:40:18
>>135
OCamlのクローン
スレ立ってるよ
ｽﾚﾘﾝｸ(tech板)l50
137:デフォルトの名無しさん
08/06/06 21:53:12
JScript .NETスレがこのスレより伸びているのは不思議でいけない
ｽﾚﾘﾝｸ(tech板)l50
138:デフォルトの名無しさん
08/06/06 22:01:12
見に行ってみたけどあれは伸びてるって言っていいのか？ｗ
139:デフォルトの名無しさん
08/06/09 10:26:58
で、どうしろと？
140:デフォルトの名無しさん
08/06/10 22:09:43
Thread^ jisure = gcnew Thread("C++/CLI part4");
jisure->build("プログラム板");
for(int i=0; i<1000; i++) {
// TO DO
}
jisure->Close();
141:デフォルトの名無しさん
08/06/11 18:11:10
ヘッダーのみで書いてるけど
生のC++と比べて
C++/CLIだとコンパイルが数倍速い気がする。
142:デフォルトの名無しさん
08/06/12 19:00:13
>>141
ほとんどref classだけで書くとコンパイル速度は速くなる。
C#のコンパイルが早いのと同じ理由。
生のC++で書いてただそれを/clr でコンパイルしただけの場合はかわらない。
143:デフォルトの名無しさん
08/06/15 15:36:54
c++/cliでxnaって使えるんですか？
ウィンドウを出すまでは出来たって人がいるみたいですけど
144:デフォルトの名無しさん
08/06/15 17:17:46
少なくとも/clr:safeは必須だろうな。
145:デフォルトの名無しさん
08/06/15 17:34:19
>>143
Xbox 360で動かすなら/d1clr:nostdlibも必要になるかも。
146:デフォルトの名無しさん
08/06/16 19:35:50
Windowsなら普通に使えるけど意味ないわな
147:デフォルトの名無しさん
08/06/28 13:39:34
STL/CLIでIntellisenseの効きが悪すぎる
148:デフォルトの名無しさん
08/07/01 20:08:34
メインのフォームに
別のフォームを
・タスクバーのアイコン無し
・閉じるボタンをなくす、もしくはCloseじゃなくSW_HIDEみたいにしたい
んですが
どうすればいいのでしょうか？
149:148
08/07/01 20:17:29
事故しました
150:デフォルトの名無しさん
08/07/01 20:28:19
メインフォームのLoad～
で
サブフォームを作成（gcnew してShow）
サブフォームを閉じてしまった場合、
再度表示するには、どうすればいいでしょうか？
もしくは、そのオブジェクトが閉じられてるかどうかを確認するには何をチェックすればいいのでしょうか？
151:デフォルトの名無しさん
08/07/01 21:15:41
CloseしないでHideすればいいんじゃね
152:デフォルトの名無しさん
08/07/01 21:20:20
MSDN で、Visible プロパティとShowメソッドを10遍読んでこい
153:デフォルトの名無しさん
08/07/03 16:48:57
hideの身長は何センチですか？
154:デフォルトの名無しさん
08/07/03 20:07:21
hydeだろ
155:デフォルトの名無しさん
08/07/09 16:15:57
ネイティブのDirectX使いたいんですけど、
初期化時に必要なフォームのウィンドウハンドルはどうやって取得すればいいのでしょうか？
156:デフォルトの名無しさん
08/07/09 16:21:24
(HWND)this->Handle.ToInt32();
157:デフォルトの名無しさん
08/07/09 16:28:57
>>156
ToPointerだな
158:デフォルトの名無しさん
08/07/09 17:09:56
どっちでもいけたお
159:デフォルトの名無しさん
08/07/09 17:54:50
64bit
160:デフォルトの名無しさん
08/07/14 17:45:14
FormやPictureBoxのイベントハンドラを見ても出てないのですが、.
net 2003ではMouseWheelイベントは定義されていないのでしょうか？
161:デフォルトの名無しさん
08/07/14 17:52:14
隠されてんじゃね
基底であるControlで定義されてるから存在しないわけじゃない
162:160
08/07/15 16:47:11
>>161
ありました。VB以外だと自分で定義してやらないといけないのですね。
163:デフォルトの名無しさん
08/07/16 07:28:12
別のイベントが連鎖的におきてそちらのイベントを使うことが多いから
[Browsable(false)] にしてあるのだろう。
164:デフォルトの名無しさん
08/07/16 21:47:24
関数ポインタ配列の宣言がどうしてもコンパイル通らないんです。
よかったら何がだめなのか教えてください。
public ref class Form1 : public System::Windows::Forms::Form
{
public:
...
int fn1(int,int);
int fn2(int,int);
int fn3(int,int);
int (*fp[])(int,int){
fn1,
fn2,
fn3
};
...
ちなみにerror C4368です。
165:デフォルトの名無しさん
08/07/16 21:55:08
関数ポインタはアンマネージ
デリゲート使いな
166:デフォルトの名無しさん
08/07/16 22:08:11
>>165
アンマネージだったんですか。ポインタはだめとかそんなことを聞いたきがします。
ありがとうございます。
167:デフォルトの名無しさん
08/07/17 09:30:03
>>164
普通の関数とメンバ関数は、ポインタ型にすると別物だけど、
わかってるのかな？
168:デフォルトの名無しさん
08/07/17 17:00:04
C#でやるより少々手間がかかりますな。
delegate int fd(int x, int y);
array<fd^>^ fp;
fp = gcnew array<fd^> { gcnew fd(this, fn1), gcnew fd(this, fn2), gcnew fd(this, fn3) }
ネイティブクラスの関数ポインタは ->* が出てきて泥沼に陥るからやめたほうがいい。
169:デフォルトの名無しさん
08/07/17 21:20:42
>>167
わかっていないですorz調べてみます。ありがとうございます。
>>168
デリケートを使うことでコンパイルも通り,プログラムも完全はしましたが,>>168が何をいっているのかわかりませんorz
まだまだです…
本当にありがとうございました。
170:デフォルトの名無しさん
08/07/17 21:25:59
>168
イベント使ったら？
171:デフォルトの名無しさん
08/07/18 09:43:55
うん普通はイベント使うよね
172:デフォルトの名無しさん
08/07/18 10:35:31
>>164
＞関数ポインタ配列の宣言がどうしてもコンパイル通らないんです。
という問いだからあえてデリゲートの配列にしたまでで、
そりゃ普通マルチキャストデリゲートとかイベント使うよ。
イベントでadd/remove/raiseを明示的に実装する場合は・・・まあ普通はコレクションだな。
言いたかったのはネイティブクラスもrefクラスの関数ポインタはthisを内包していないことと、
関数ポインタを使う場合やデリゲートにする場合はthisを明示的に指定する必要があること。
C#と比べてうんぬんというのはC#でデリゲートを作るときはthisを暗黙に補ってくれるので
気にしなくて良いということ。
173:デフォルトの名無しさん
08/07/22 09:16:10
A classのメンバにB classの配列を加えるということはできないのでしょうか
174:デフォルトの名無しさん
08/07/22 09:21:39
array<T^>^なら入れられるよ
175:デフォルトの名無しさん
08/07/22 09:33:38
ref class A{
public:
static array<L_SAMPLINGDATA^>^ hoge;
};
ref class B{
public:
static int piyo;
};
---------------------------------
レスありがとうございます。
こんなかんじでしょうか。
176:デフォルトの名無しさん
08/07/22 09:36:50
ref class A{
public:
static array<B^>^ hoge;
};
ref class B{
public:
static int piyo;
};
---------------------------------
まちがえました
177:デフォルトの名無しさん
08/07/23 02:19:37
どういう意図があるのかわからんが static でいいのか？
178:デフォルトの名無しさん
08/08/20 02:17:19
自分からテスト専門です、って宣言してる派遣テスターって何なの？
将来プログラマとかSEになりたい、とかならわかるけど。
向上心ないよね、頑固だし。
そういう派遣テスターって、仕様書は読めない、
テスト仕様書も作れない、テストプログラムも作れない
やれることは「テキトーにプログラムを触る」ことだけ。
俺は派遣プだけどさ、こういう派遣テスターがいると
派遣全体がバカにされるんだよ。
テスト専門派遣なんて氏んで欲しいよ、まったく。
今日も正社員の人が派遣テスターに仕様書を読んで
テスト仕様書を作ってください、って説教してたよ。
その派遣は頑固に「何故、仕様書が必要なんですか？」って
反論してたから、きっとテスト専門派遣テスターだな。
仕様書も読まず、テスト仕様書も作らず、ただテキトーに
プログラム触るだけで給料もらおうなんて頭おかしいんじゃねーの？
あ～あ、あの派遣テスターが3ヵ月後に切られるまで、
仕様書も読まねーでテキトーにテストしたバグ票がまわってくんのかよ。
そんな糞なもん、読んで処理する派遣プの身にもなってくれよ。
うわ～、しかもそいつが切られる3ヵ月以内に中間納品あるじゃねーか！
テスト仕様書もなしにテキトーにテストして納品か。
中間納品後にソッコウクレームでデスマ必至だな。俺の休みも返上かよ。
派遣専門テスターさんよ、少しは向上心持てよ！
頑固な性格直して仕様書読めよ！テスト仕様書作れよ！
179:デフォルトの名無しさん
08/08/28 14:39:28
誘導されました
マネージコードでdllを作成することってできる？
dllのソース内でSytem::Stringを使おうとしたらC4747エラーがでちゃった
ソースの方に「#pragma unmanaged」宣言してるから仕方ないんだけどさ
なんかやり方あるんでしょうか？
環境はvc++2005でc++/cliでやってます
180:デフォルトの名無しさん
08/08/28 14:44:01
どんなDLLが作りたいの？
181:デフォルトの名無しさん
08/08/28 15:11:28
#pragma managedができない差し迫った理由でもあんのけ？
ちゅーかCLRでプロジェクト作ればまんまマネージアセンブリができるはずだが。
182:デフォルトの名無しさん
08/08/28 15:21:07
>>179
#pragma unmanagedなしでも__declspec(dllexport)な関数は作れるぞ。
183:デフォルトの名無しさん
08/08/28 16:04:26
関係ないけど、C++/CLIでSusieプラグインのコールバック書いたらすごく遅くてビビった。
何回も呼ばれるとアンマネージ-マネージ間のオーバーヘッドも馬鹿にならんな。
184:デフォルトの名無しさん
08/09/07 23:04:10
既存のNativeのC++コードをC++/CLI
でくるんでC#から呼び出す方法がいくつか検索できるけど
(MicrosoftのC++開発チームもそれを奨励しているみたい)、
これって実際に余程、腕が習熟してないとトラブルに見舞
われそうだと思うけどどうですか？
もう、MFCなんか使ってnativeのC++で押し通した方が
良いように思うけど。とくに、カーネルの数値計算部
がNativeコードでできている場合
185:デフォルトの名無しさん
08/09/08 00:15:06
それでいいんじゃない？
その時、/clr 付けておけば、.net framework も使えるし
C# のライブラリも使える
186:デフォルトの名無しさん
08/09/08 00:21:19
ｽﾚﾘﾝｸ(gamedev板)
749 名前：名前は開発中のものです。[sage] 投稿日：2008/09/07(日) 13:50:13 ID:TzkL+YXR
C++/CLIなら.NETの便利なクラスライブラリやビジュアルデザイナを
C++から都合よく使えるとか思ってるなら大間違い
187:デフォルトの名無しさん
08/09/08 00:32:05
は？ GUI は MFC か WTL だろ
>184 もそう言ってるじゃないか
188:デフォルトの名無しさん
08/09/08 01:49:41
>>184
別にネイティブコード呼び出すだけならC#からP/Invokeでも良いじゃん。
一度C#+WinForms+ビジュアルデザイナの開発に浸っちまうとMFCとか戻りたくない。
というかC++/CLIは使うかどうか迷うようなもんではないだろ。
C++/CLIのプロジェクト自体ほとんど見たことないが、
例えばアンタがXNAやSlimDX（DirectXのマネージラッパー）
みたいなアセンブリを作ろう思った時に、欲しい言語はどんな感じになると思う？
189:デフォルトの名無しさん
08/09/08 09:20:33
dllimport並べたC#
190:デフォルトの名無しさん
08/09/08 10:33:14
>>189
DirectXインターフェイスみたいなクラスのメンバ関数はどうするの？
FBX SDKみたいなバイナリ提供しかされていないライブラリが沢山ある場合は？
C#+DllImportにこだわって関数テーブルからのオフセット調べたり
API変換のみのネイティブDLLをライブラリ毎に作るくらいなら
C++/CLIでマネージクラス書いた方が多少はマシだぞ思うぞ。
191:デフォルトの名無しさん
08/09/08 11:05:30
すでにC++のコードがある場合、それをC#から使うのにいいな。
192:デフォルトの名無しさん
08/09/08 11:09:30
>>190
>DirectXインターフェイスみたいなクラスのメンバ関数はどうするの？
DirectXインターフェイスならCOM準拠なんだからCOM Interopでいいじゃん。
>FBX SDKみたいなバイナリ提供しかされていないライブラリが沢山ある場合は？
Interop Assistantでヘッダファイルを構文解析して、P/Invoke定義をコード生成する。
URLﾘﾝｸ(blogs.msdn.com)
193:デフォルトの名無しさん
08/09/08 11:11:31
FBX SDKってもしかして*.libのみ提供？
194:デフォルトの名無しさん
08/09/08 12:10:02
>>192
>DirectXインターフェイスならCOM準拠なんだから
DirectShow以外は準拠しとらんよ。tlbもidlもない状態からinteropできたっけ？
まぁDirectXに限らずCOM以外のC++クラスライブラリは無理だわな。
>Interop Assistantでヘッダファイルを構文解析して、P/Invoke定義をコード生成する
言葉足らずで悪かったが、スタティックライブラリのみの提供の場合ね。
195:デフォルトの名無しさん
08/09/08 21:18:14
>>194
>DirectShow以外は準拠しとらんよ。tlbもidlもない状態からinteropできたっけ？
できるよ。tlbやidlはコードジェネレータの種に使っているだけで、
実行時にはMSILのメタデータしか使ってないから。
同じものをC#で書ける。
196:デフォルトの名無しさん
08/09/08 22:30:35
そもそもAPIからIUｎknown弄ればどうとでもなる
197:デフォルトの名無しさん
08/09/08 23:01:19
C++もC#も理解していて、さらにC++/CLIをやってやろうという意気込みがあれば、
DllImport並べたりCOMInteropでどうにかするより楽に感じると思う。
つまりそれくらいの意気込みがないとつらいかなとも思う。
198:デフォルトの名無しさん
08/09/09 23:04:31
実現したい機能がリフレクションを使わないと書けないかめんどくさい
・Type.getType()相当のプリミティブ
・Invoke()相当のプリミティブ
があれば文字列をえっちらおっちらこさえれば.NET Frameworkのコードが呼べるはず。
これならスタック二段増えるだけなので手間じゃないはず。(文字列こさえるのはともかくとしてね……)
大本のプリミティブの下に積んでやれば下位互換性も保たれる。
199:デフォルトの名無しさん
08/09/14 07:17:54
447 名前：デフォルトの名無しさん[] 投稿日：2008/09/14(日) 01:09:45
Express 2005で３連休プログラマーなんだけど、
String^ folderName;
の ^ ってなに？
200:デフォルトの名無しさん
08/09/14 07:27:27
マネージドオブジェクトの参照。それ基本だから入門サイトで勉強しなおせ。
201:デフォルトの名無しさん
08/09/14 14:24:38
.NETでiniファイルの読み書き詳しく
202:デフォルトの名無しさん
08/09/14 14:27:51
C++/CLIならAPIをじかに呼べる。/clr:safeやC#などからならP/Invokeを使う。
その前にini使うようなデザインはもうするな。
203:デフォルトの名無しさん
08/09/14 17:31:54
仕様に書いてあるから訊いているのであって
お前ごときが意見するのはおこがましいちは思わんかね？
204:デフォルトの名無しさん
08/09/14 17:35:18
ｸｽｸｽ ｸｽｸｽ
205:デフォルトの名無しさん
08/09/14 17:37:55
このレベルのことはプログラマの権限の範疇だろ。
そうじゃなかったらプログラマでなくお前はコーダーだ。
206:デフォルトの名無しさん
08/09/14 17:40:57
あげてるし釣りだろ
そろそろ後釣り宣言が来るかもね
207:デフォルトの名無しさん
08/09/14 20:48:40
iniファイルは釣りでした。
起動してるプロセス（リスト）の取得教えて
208:デフォルトの名無しさん
08/09/14 20:49:53
起動時にPIDをファイルに書いとけ
209:デフォルトの名無しさん
08/09/14 21:36:58
そもそもC++/CLI関係なくね
210:デフォルトの名無しさん
08/09/14 21:59:34
くだすれ.NET逝け
211:デフォルトの名無しさん
08/09/14 23:36:22
>>197
しかし DllImport, COMInterop にも利点があってアセンブリが
AnyCPU に出来るという一部受けする魅力が
パワーがあるんならだからそっちのほうがと思うとやっぱり
C++/CLI って移行移行言っているのはそういう話なのではと。
言語的な話もあれども。
212:デフォルトの名無しさん
08/09/15 01:40:00
日本語ぎりぎりだな
213:デフォルトの名無しさん
08/09/15 17:30:40
もうやだこの世界
214:デフォルトの名無しさん
08/09/15 17:42:28
C++/CLIこそ.NET
215:デフォルトの名無しさん
08/09/19 15:24:08
自分以外のユーザのマイドキュメントのパスを取るAPIってない？
216:98
08/09/19 15:38:38
なぜここで訊く
217:デフォルトの名無しさん
08/09/19 15:46:18
c++/cliでやってるもんで・・・
フレームワークにうまいのがないかなと
218:デフォルトの名無しさん
08/09/19 20:48:41
>>215
基本的にアクセスできない & プロファイルのロードは重いのでないん
じゃない。
というか偽装してプロファイルロードしてとりゃいいんじゃないかなぁ。
219:デフォルトの名無しさん
08/09/22 14:31:38
>>218
返信遅くなったんだが教えてくれ
ユーザプロファイルを読み込んで後はどうやってマイドキュメント取ればいいの？
後、ユーザプロファイル取れてるかも自信ないんだが、下で合ってる？
IntPtr lt = IntPtr::Zero;
PROFILEINFO pfi;
LogonUser(L"test", L"", L"test",
LOGON32_LOGON_INTERACTIVE, LOGON32_PROVIDER_DEFAULT,
(PHANDLE)<)
::ZeroMemory(&pfi, sizeof( PROFILEINFO ));
pfi.dwSize = sizeof( PROFILEINFO );
pfi.lpUserName = L"test";
LoadUserProfile((HANDLE)lt, &pfi);
220:デフォルトの名無しさん
08/09/22 23:47:22
>>219
C++なんだから、IntPtrよりHANDLEとか適切な型を使おうぜ。
それはともかく、SHGetFolderPathがトークンハンドルを引数を取る。
もしかしたら、ユーザプロファイルを読み込まなくても使えるかもしれない。
221:デフォルトの名無しさん
08/09/24 09:13:10
>>221
レスあり
ユーザプロファイルのロードはしなくても取れました
222:デフォルトの名無しさん
08/09/24 20:36:52
というかそのコードだと LogonUser で自動的にロードしてるな>プロファイル
223:デフォルトの名無しさん
08/10/01 17:16:46
C++/CLIでprintDialogが開くのが遅くて、
printDocument->Print()してからプリントアウトが始まるのも遅いんですが早くする方法ってありますか？
224:デフォルトの名無しさん
08/10/03 21:51:11
C#の
if(hoge is Nazo)
{
// hogeはNazo型
}
みたいのはどうやって書くの？
225:デフォルトの名無しさん
08/10/03 21:59:13
if (dynamic_cast<Naze^>(hoge))
{
}
dynamic_castはC#のas相当で、C#のisとasは同じILにコンパイルされるということから。
226:デフォルトの名無しさん
08/10/03 22:12:10
できました
227:デフォルトの名無しさん
08/10/04 12:35:06
as は safe_cast 相当じゃないの？
228:デフォルトの名無しさん
08/10/04 12:50:42
safe_castはキャスト失敗した時例外投げる
229:デフォルトの名無しさん
08/10/05 21:43:43
List<T>::Find(System::Predicate<T>(T))
あたりのやつってC++/CLIだと使えないの？
230:デフォルトの名無しさん
08/10/05 21:48:12
別に使えないってこたーない
匿名メソッドやラムダ式が無いから使いづらいけどな
231:デフォルトの名無しさん
08/10/05 22:02:12
匿名メソッドないから、
条件の数だけデリゲートの関数が要る。
232:デフォルトの名無しさん
08/10/05 22:16:36
そこでBoost.Lambdaが……、使えない。
233:デフォルトの名無しさん
08/10/05 22:25:28
比較対象を変数に仕込んだり…
234:デフォルトの名無しさん
08/10/05 22:32:27
こんなカオスな方法が
URLﾘﾝｸ(blogs.wankuma.com)
235:デフォルトの名無しさん
08/10/06 00:14:38
collection_adapterにぶち込んで、cliext::find_ifを使うんだ。
bind1stとか使えるぞ。
236:デフォルトの名無しさん
08/10/08 01:49:56
文字列スイッチはできないの?
237:デフォルトの名無しさん
08/10/08 02:35:14
そこはC++ですから。
238:デフォルトの名無しさん
08/10/09 22:18:18
ひんと はっしゅ
239:デフォルトの名無しさん
08/10/10 14:52:36
C++/CLIのフォームデザイナのコード、あれなんとかならない…？
240:デフォルトの名無しさん
08/10/11 09:10:20
まあそもそもフォームデザイナ使うようなところに使う言語じゃないしね
おまけと割り切るべき
241:デフォルトの名無しさん
08/10/13 10:55:06
C#はISO,JIS承認されたけど、
C++/CLIはISOに蹴られてその後どーなったの？
242:デフォルトの名無しさん
08/10/14 01:18:52
C++0x 待ちじゃね？
243:デフォルトの名無しさん
08/10/15 10:47:55
Bette Cを標榜するならC99のコードは動作してもらいたい。
C++/CLIIはNGになってよかったけど、これに変わるとなると、もう素直にC++0x→D言語でいいんじゃないの？
244:デフォルトの名無しさん
08/11/11 23:17:15
VSで開発してC++用のライブラリ使ってて、
内部で標準C++ライブラリが使われてmsvcr80.dllとかが要求されるんだが、
完成間近にいざ別の環境に持っていくと動かなかった。
.net入れてたら動くかと思ったんだが･･･
CRTオプションが/clrだから/MT（without DLL）が併用できないと怒られたし。
どうしよう(・ω・`)
正味CLRの実装レベルの話分かってない俺を誰か助けてくれ。
245:デフォルトの名無しさん
08/11/11 23:19:24
>>244
それはランタイムが足りないから。
Visual C++ 再頒布可能パッケージってのをインストールするんだ。
バージョン（SPの有無も）、x86/x64/IA64で別々だからそこんとこ間違えないように。
246:デフォルトの名無しさん
08/11/12 06:20:13
xp以降はおなじmsvcr80.dllでもビルドやリビジョンが下位の場合は読み込まない。
.NET2.0を導入すると.NET2.0が使ってる8.0.50727.42(or163？)が、
.NET3.0を導入すると.NET3.0が使ってる8.0.50727.1833がインストールされるが、
VS2005の最新パッチ状態でコンパイルしたものは8.0.50727.3053を必要とする。
このために.NET2.0が入っていてもmsvcr80.dllがあっても見つからないというエラーが発生する。
247:デフォルトの名無しさん
08/11/12 07:52:30
別に .net 関係ない話だし
248:デフォルトの名無しさん
08/11/12 08:46:47
CRTを使ってるからたまたま一緒にインストールされるという話だね。
インストーラーやClickOnce、または再配布モジュールで導入するのが筋だろう。
.NETでCRTを使ってるのはCSC.EXEとかMSCORWKS.DLLあたりだね。
249:デフォルトの名無しさん
08/11/12 08:53:36
C++/CLIでCRTを使いたくないなら、/clr:safeにする必要がある
250:デフォルトの名無しさん
08/11/12 20:22:04
ねーよ
251:デフォルトの名無しさん
08/11/12 22:01:08
CLIの機能(プロパティやGC)は使用したいけれど.net frameworkは使用しない場合で、
.net frameworkのランタイムが入っていない環境で動作する様にできるんですか？
252:デフォルトの名無しさん
08/11/12 22:16:09
Monoでも入れてみるかね
253:デフォルトの名無しさん
08/11/12 23:48:07
CLIって.NET Frameworkの仕様のことなんだが
254:デフォルトの名無しさん
08/11/12 23:58:02
>>253
おそらくC++/CLIのつもりなんだろ
255:デフォルトの名無しさん
08/11/13 00:10:24
CLIの機能を使いたいが、.NETは嫌だというなら、>>252しかないな。
256:デフォルトの名無しさん
08/11/13 00:19:45
そういえばなんでSTL/CLRはCLIじゃなくてCLRなんだろう
仕様を定めてるんじゃなくて、あくまでCLR用のライブラリそのものを指すから?
257:デフォルトの名無しさん
08/11/13 20:18:48
Mono調べてみました
・・・素直に. netを使おうかと思います＾＾；
C++/CLIは独自仕様で直接.net frameworkとは関係ない所なので
C++/CLIだけ利用できないかな？と思ったので質問しました。
258:デフォルトの名無しさん
08/11/13 20:37:48
C++/CLIっていうのは文字通りCLI(.NET Frameworkのコア仕様を定めるもの)
をサポートしたC++なんだよ?
その点C#は言語仕様が直接CLIに依存してないから
C++/CLIに比べて.NETとの繋がりがむしろ弱いともいえる
259:デフォルトの名無しさん
08/11/13 21:54:38
まあ現実にはCLIなしのC#なんて考えられないけどな。
260:デフォルトの名無しさん
08/11/13 22:01:39
コンパイラとGCとBCL一通りさえ実装すればC#と名乗れるんでしょ?
誰かやりそうだけど誰もやらないね
261:デフォルトの名無しさん
08/11/13 22:09:01
そうなんですか、それでもやっぱりC++/CLIだけ使用して
.net frameworkを使用しないっていうことはできないんですよね。残念です
262:デフォルトの名無しさん
08/11/13 22:21:49
>>260
mono
263:デフォルトの名無しさん
08/11/13 22:38:24
プロパティに夢見てCLIにソースコピペ
↓
プロパティ追加したらアンマネージにマネージは作れないと怒られる
↓
クラスをマネージにしてみる
↓
処理速度激減。なぜかインライン展開できてないorz
アンマネージクラスにプロパティとか新しい列挙とか作る方法ってないの？
マネージ系はインラインできないの？
264:デフォルトの名無しさん
08/11/13 23:03:44
マネージコードでのインライン展開はJITの仕事。
ネイティブでのプロパティはCOM対応のおかげで昔からあったが別構文。
URLﾘﾝｸ(msdn.microsoft.com)
265:デフォルトの名無しさん
08/11/13 23:06:46
遅くなってるのは、インライン展開やマネージコードになったことよりも、
アンマネージコードとマネージコードの境界を意識してなくて行き来が多発しているのが原因だと思う
266:デフォルトの名無しさん
08/11/14 08:16:06
まぁ、素人はネイティブをメインに gcroot でも使ってろってこった
267:デフォルトの名無しさん
08/11/14 08:42:35
monoでのC++/CLIの対応状況。
コンパイラのサポートはなし。
Microsoft.VisualC.Dllは存在していてsafeモードでコンパイルされたものは動く。
その内訳。
mono2.0.1現在ではVS2005でコンパイルしたものは動く。
vs2008でコンパイルしたものは動かない。STL/CLRも未サポート。
mix, pureモードでコンパイルされたものは動かない。
268:デフォルトの名無しさん
08/11/15 20:47:23
VC2008EEで勉強してます。
アップウィザードの自動生成が嫌なので、
空のCLRプロジェクトを選択して
int main()
{
Application::Run(gcnew Form());
return 0;
}
という最小限のプログラムを作ってみました。
プロンプトを表示させないようにするには
どうすれば良いのか教えて下さい。
269:デフォルトの名無しさん
08/11/15 21:01:33
まず普通のWinFormプロジェクトを作ってみてそれを参考にすれば良いよ
270:268
08/11/15 21:04:17
プロジェクト->プロパティ->リンカ->システム
で Windows(/SUBSYSTEM:WINDOWS)
を設定。
int main()を
int __stdcall WinMain(HINSTANCE hInst, HINSTANCE hPrevInst, LPSTR cmdLine, int cmdShow)
に置き変えて，
#include <windows.h>
を書いたらできました。
でも、なんか違う気も。。
CLR用のやり方があるんだろうか？
271:268
08/11/15 21:10:32
>>268
やってみてます。
Form1クラスの
System::ComponentModel::Container ^components;
メンバって使われてます？
272:268
08/11/15 21:11:51
>>269
だった。。 自分に返信 ＯＲＺ
273:デフォルトの名無しさん
08/11/15 23:03:06
>>270
それでいいと思う。
どうしても気になるなら、リンカ→詳細のエントリポイントを書き換えろ。
サブシステムが/SUBSYSTEM:WINDOWSにさえなっていれば大丈夫。
例えば、mainCRTStartupにすればint main(int argc, char **argv)で始められる。
?mainCRTStartupStrArray@@$$FYMHP$01AP$AAVString@System@@@Zだと
int main(array<System::String^>^ args)になる。
CRTの初期化が要らなければ、自分の関数を直接指定する。
274:268
08/11/16 10:17:18
>>273
ありがとうございます。
教えて頂いたところを試してみて、以下がわかりました。
・int __stdcall WinMain(HINSTANCE hInst ... )
を使った場合には、サブシステム：設定なし で動くようです。
・int main(array<System::String ^> ^args)
を使いたい場合には、サブシステム：/SUBSYSTEM:WINDOWS
エントリポイントmainで動くようです。
アップウィザードはの設定は後者ですが、
メイン関数からの引数が不要なら前者の方が楽ですね。
275:268
08/11/16 10:58:51
自分で作成したフォームクラス（MyForm.h, MyForm.cpp）
に対して，デザイナを使えるようにしようとしています．
とりあえず新しい項目の追加でWindowsフォームを選び，
作成されたFoo.hとFoo.cppの内容をMyForm.hとMyForm.cpp
に全て変更したら動きました．
デザイナで編集して，MyFormのコンストラクタから
InitializeComponent();を呼んでいます．
でもこれもやり方が違う気が．．
276:デフォルトの名無しさん
08/11/16 15:36:02
何がいいたいの？
277:268
08/11/16 18:57:42
MyForm.resx というXMLファイルを追加し，
ProjectName.vcproj というXMLファイルに変更を加えたら
MyForm.hがデザイナから認識され，編集できました．
既存のMyFormクラスに対して上記のXMLファイルの
設定を自動で行ってくれる方法は無いみたいです．
278:デフォルトの名無しさん
08/11/16 19:51:31
日記は自分の blog にでも書いたらいいんじゃないか
279:デフォルトの名無しさん
08/11/16 19:58:39
何の情報も提供せずに教えてくれってのよりは良いんじゃない？
280:デフォルトの名無しさん
08/11/16 20:31:19
この人、自分がやってることをぼそぼそ呟いて、自己満足してるだけだろ
ウィザードがやってることを見もせずに、ウィザードと同じことやってりゃ世話無い罠
281:デフォルトの名無しさん
08/11/18 23:52:34
自動的に作成されるメソッドに日本語が入らないようにするにはどうすればおｋ
282:デフォルトの名無しさん
08/11/20 20:59:21
過去の資源を再利用できること以外にC++/CLIがC#より優れてる点はどこですか？
283:デフォルトの名無しさん
08/11/20 21:09:52
Disposeパターンが言語に組み込まれてる
テンプレートが使える
マクロが使える
一番目は相互運用絡みだから除外するべきかも
284:デフォルトの名無しさん
08/11/20 22:09:49
__fastcallが使えないのが痛い
285:デフォルトの名無しさん
08/11/20 22:55:26
#pragma unmanaged
286:デフォルトの名無しさん
08/11/21 09:27:31
C#（検証可能アセンブリ？）はリバースエンジニアリングが簡単という話を聞いたんですが
C++/CLIの混在アセンブリ、純粋アセンブリや検証可能アセンブリも同じなんですか？
287:デフォルトの名無しさん
08/11/21 09:46:21
マネージコードで書かれた部分は読み放題
Reflectorでほぼ完璧に逆コンパイル可能
C#ほどILが綺麗じゃないから若干読みづらいかも
288:デフォルトの名無しさん
08/11/22 17:46:58
>>285
#pragma unmanaged
int __fastcall func( int a, int b)
{
return a + b;
}
#pragma managed
これじゃ駄目なようですが
289:デフォルトの名無しさん
08/11/28 02:10:49
MSの常
・勝手に仕様拡張する
・なかなか、正規仕様に準拠しない
どやしつけられたのがJ++
総スカン食らったC++/CLI
J#でどやしつけられ、性根入れ替えてC#はよかったのに
またC++/CLIで汚点。
J#はみあたらんぞ
290:デフォルトの名無しさん
08/11/28 02:13:24
忘れてた
・勝手にサポートを打ち切る
291:デフォルトの名無しさん
08/11/28 10:56:03
今どうしても必要なときに必要なところだけ使う言語だもん
中途半端なフォームデザイナなんか付けたりするから勘違いする奴がいる
292:デフォルトの名無しさん
08/11/30 11:55:31
property TKey First;
のような省略記法って、何の意味がありますか？
アクセサを使わない場合と比べて、何か利点はあります？
293:デフォルトの名無しさん
08/11/30 12:07:44
記述を省略できる
294:デフォルトの名無しさん
08/11/30 12:15:20
generic< typename TKey, typename TValue >
public ref class Pair
{
public:
property TKey First;
property TValue Second;
//TKey First;
//TValue Second;
Pair(){}
};
stl::pairのようなクラスを作ったのですが、propertyを使うと、
テンプレートの型によって、代入出来たり出来なかったりするようです。
propertyを削除すると、代入出来るようになります。
何か理由わかりますか？
（続く)
295:デフォルトの名無しさん
08/11/30 12:19:11
(続き)
public value struct ValueTypeStruct
{
unsigned int A;
unsigned int B;
};
array< Pair< unsigned int, ValueTypeStruct >^ >^ arry;
arry = gcnew array< Pair< unsigned int, ValueTypeStruct >^ >(10);
for each( Pair< unsigned int, ValueTypeStruct >^% inv in arry)
{
inv = gcnew Pair< unsigned int, ValueTypeStruct >();
inv->First = ...; // <- OK
inv->Second.A = ...; // <- NG
inv->Second.B = ...; // <- NG
}
>>293
記述を省略して、デフォルトのアクセサを作ったとして
それのメリットは何ですか？
別にget、setに別にアクセサビリティを設定出来る訳ではないし、、
メンバ変数のアドレスを取れなくさせるとかですか？
296:デフォルトの名無しさん
08/11/30 13:06:46
>>290
いやいや、RedHatにはかなわんよ。
新版のLinuxパッケージをリリースしたら、旧版は即日サポート終了だからな。
あれには驚いた。
297:デフォルトの名無しさん
08/11/30 13:08:30
> inv->Second.A = ...; // <- NG
> inv->Second.B = ...; // <- NG
プロパティは実質的にメソッドなので値型だとコピーが作られる
> 記述を省略して、デフォルトのアクセサを作ったとして
> それのメリットは何ですか？
ILレベルじゃまったく別物
途中で検証が必要だからフィールドからプロパティに変えるか、ってほど気楽な変更ではない
そもそもインスタンスフィールドを公開するのはガイドラインに逆らってるしな
> 別にget、setに別にアクセサビリティを設定出来る訳ではないし、、
これは単にコンパイラの実装の手抜きだろ
C#じゃ設定できるし
298:294
08/11/30 13:08:31
自己解決しました。
inv->Second.Aとした場合、Secondはメンバではなく
get()の戻り値である一時変数であった為でした。
299:デフォルトの名無しさん
08/11/30 13:19:08
>>297
理解しました、ありがとうございました。
300:デフォルトの名無しさん
08/11/30 13:20:21
valuetypeは変更不可で設計したほうがこの手の間違いが少なくてすむよね。
301:デフォルトの名無しさん
08/11/30 13:33:23
>>300
値型と参照型の違いもそうなのですが、
プロパティの
inv->First = ...; // <- OK
と
inv->Second.A = ...; // <- NG
が、表面上は同じ代入なのに
内部的には、
inv->set_First( ...);
と
inv->get_Second().A = ...;
と、正反対の関数に分かれるってのは
デンジャラスだなーと思いました。
propertyのgetには、何か足りてないものがあるような感じです。
302:デフォルトの名無しさん
08/11/30 13:51:03
値型とプロパティは相性が悪いのよ。参照型のクラスだと問題ないでしょう。
だからP/Invokeのような特殊な用途を除いてイミュータブルにするルールになってる。
・・・のだけど、WindowsFormのPointやSizeはしっかり変更可能になってる（笑
ヘジたんの目が届かなかったのだろう。
303:デフォルトの名無しさん
08/11/30 13:52:10
>>302
ここで言う値型はプリミティブ型を除いたユーザー定義型の構造体のことです。念のために。
304:デフォルトの名無しさん
08/11/30 13:55:09
WinFormじゃなくてGDI+だな
その辺はむしろラップしてるアンマネージドとの兼ね合いじゃないか
305:デフォルトの名無しさん
08/11/30 14:03:29
WPFの構造体だってたいがい変更可能だよ
そのへんは割り切り設計
ちゃんとわかってたら問題ない
306:デフォルトの名無しさん
08/11/30 23:05:30
C++/CLIっていうか、.NETって
typedefのようなエイリアスって無いんですかね？
これじゃ何も作れないような、、皆さんはどうしてるんですか？
307:デフォルトの名無しさん
08/11/30 23:12:46
何を作りたいんだ？
308:デフォルトの名無しさん
08/11/30 23:20:20
マクロでも書けば委員者ね？
309:デフォルトの名無しさん
08/11/30 23:21:35
トリビアル・プロパティとトリビアル・イベントの存在意義はロック処理を自動でしてくれること
だった気がする
310:デフォルトの名無しさん
08/11/30 23:25:52
>>307
何か特定のソフトウェアに依存する話ではなく
一般的なものだと思います。
typedef classA< classB< classC > > > arg_type;
void func( arg_type a );
C++ではこう出来ていたものが、
void func( classA< classB< classC > > > a );
.NETではこれしか出来ないというのは
利用者側は、いちいちclassA< classB< classC > > >型のオブジェクトを宣言しろってことですか？
311:デフォルトの名無しさん
08/11/30 23:30:57
で、それだけで何も作れなくなるの？
312:デフォルトの名無しさん
08/11/30 23:33:12
>>310
アセンブリ横断ではその機能はないが、C++/CLIつまり同じソースか
includeするHeaderファイルの範囲なら使えると思うけど。
C#の場合は using xxx = System.YYY.ZZZ; 同じソースないなら出来る。
313:デフォルトの名無しさん
08/11/30 23:34:09
今のC#とVB.NETにはローカル変数の型推論もあるし、
常にclassA<classB<classC>>>と書かねばならないわけでもなかろう。
（もちろんクラスメンバや戻り値など、その必要性がある場面も依然として存在するが）
314:デフォルトの名無しさん
08/11/30 23:34:48
C++/CLIはtypedef使えるぞ。
315:デフォルトの名無しさん
08/11/30 23:39:54
>>310
むしろ出来ないってデマをどこで教わったんだ？
2,3行書けば検証できる話だぞ？
その例から「でもBoostのようなメタプログラミングが～」とか飛躍しないでくれよ。
316:デフォルトの名無しさん
08/11/30 23:45:16
>>311
激しく意欲を削がれます。
他にも、const参照が出来ないとか、
ちょこちょこ退化してる？みたいな部分が見え隠れするんで。
いろんなサイトの紹介文ではマンセー意見しか書いてなかったんで
余計にです。
>>312
CLRで使えないと、C++/CLI使う意味ないです。
>>314, >>315
>>312のいうアセンブリ横断のことです。
もちろん書いて試したし、検索もしました。
317:デフォルトの名無しさん
08/11/30 23:48:47
>>313
型推論について調べてみます。
アドバイスありがとうございます。
318:デフォルトの名無しさん
08/12/01 00:04:36
C++のconst参照みたいなコンパイラを騙くらかすだけのまがい物ではなく
実際に参照されているオブジェクトを変更不可として扱うconst参照を導入しようとすると
オブジェクトの検証にパフォーマンス上の問題が発生するのであえて採用してないそうだ。
319:デフォルトの名無しさん
08/12/01 00:28:26
オブジェクト指向では、内部の実装を隠蔽するわけだが、
それによって、一見読み取りだけのメソッドでも内部では何か状態を
更新してるかもわからないし。
const参照は、なんちゃってオブジェクト指向のC++と違って現代的な
オブジェクト指向とは相性悪いってことだな。
320:デフォルトの名無しさん
08/12/01 00:54:17
基のC++でもmutableとかあるしね。
逆に、.NETで表現するとしたら、IReadOnlyHogeとIHogeって2本立てにするのが落としどころだと思う。
321:デフォルトの名無しさん
08/12/01 20:19:45
複雑なジェネリック型を晒すなと.NETのガイドラインに書いてあるんだよね
322:デフォルトの名無しさん
08/12/01 20:31:51
Native C++の2次元配列から、C++/CLIの2次元配列に値をコピーしたいのですが、1つ1つの要素を代入する以外の、
一発でコピーできる方法が分からなくて困っています。
1次元配列の場合は、
double nativeVec[3] = {1, 2, 3};
array<double> ^cliVec = gcnew array<double>(3);
System::Runtime::InteropServices::Marshal::Copy(IntPtr(nativeVec), cliVec, 0, cliVec->Length);
でコピーできますが、
2次元配列の場合はどうすればいいのでしょうか？
以下のコードでは動きませんでした。
double native2DVec[3][3] = {{1, 2, 3}, {4, 5, 6}, {7, 8, 9}};
array<double> ^cli2DVec = gcnew array<double, 2>(3, 3);
System::Runtime::InteropServices::Marshal::Copy(IntPtr(native2DVec), cli2DVec, 0, cli2DVec->Length); // ここでエラー
エラーは、
error C2665: 'System::Runtime::InteropServices::Marshal::Copy' : 16 オーバーロードのどれも、すべての引数の型を変換できませんでした
です。
323:デフォルトの名無しさん
08/12/01 21:08:52
ピンしてmemcpyでどうだ。
#include <cstring>
double native2DVec[3][3] = {{1, 2, 3}, {4, 5, 6}, {7, 8, 9}};
array<double, 2> ^cli2DVec = gcnew array<double, 2>(3, 3);
pin_ptr<double> p = &cli2DVec[0, 0];
std::memcpy(p, native2DVec, sizeof native2DVec);
std::copyでもできたけど、書くのが面倒だった。
ところで多次元配列の要素の連続性の保証ってあるよね？
324:デフォルトの名無しさん
08/12/01 21:52:35
>>323
できました！
連続性の保障は怪しい気もしますが、とりあえずは手元で動くのでokということにしておきたいと思います…
325:デフォルトの名無しさん
08/12/02 00:28:22
マネージ多次元配列はメモリレイアウトに関してなんら保障してなかったような・・・
ジャグ配列にして一行ずつコピーした方がいいんでね？
マーシャリングはともかくアクセスはジャグの方が速いし。
326:デフォルトの名無しさん
08/12/02 03:54:37
>>325
3x3行列なので、ジャグ配列にするのもなんかなあ、という気分なのです。
最悪2重forでコピーかなあ。
327:デフォルトの名無しさん
08/12/02 20:04:50
小さい行列を大量に扱うんだったら>>322-323みたいなのはかなり非効率だと思うよ
3×3と決まってるなら手打ちでいいじゃん
328:デフォルトの名無しさん
08/12/12 00:25:00
MFCのダイアログアプリで質問です。
画面上のボタンを押すとWindowsForm画面を開いています。
こんな感じです
ボタンの処理
Form1 ^ fm = gcnew Form1;
fm->Show();
画面は普通に開きますが
別プロセスみたいにメイン画面の下に隠れます
親ハンドルを指定すればいいのかな？と思い
下のようにしても裏に隠れます
Form1 ^ fm = gcnew Form1;
fm->Show(fm->FromHandle(GetSafeHwnd()));
親子関係にするにはどうやればいいのかわからないです。
fm->Parentやfm->Ownerを設定してもダメでした
MFCダイアログとWindowsForm画面の親子関係は無理なんでしょうか？
やりたいことはMFC画面上に.NETコンポーネントである
グラフコントロールを表示したいだけです。
素ではダイアログに組み込めないのでWindowsForm画面に組み込み
子画面として特定の位置に固定させようとしています。
画面は表示できたのに位置合わせだけがダメです。
329:デフォルトの名無しさん
08/12/12 08:05:01
MFC 側で Window Activate 時に Form を前にしてやればいいんじゃね？
330:デフォルトの名無しさん
08/12/12 08:07:09
後は、ホストするか
URLﾘﾝｸ(msdn.microsoft.com)(VS.80).aspx
331:328
08/12/12 08:28:12
レスありがとうございます。
少し進展がありました。
ラッパーというのを作って
public ref class HwndWrapper : public IWin32Window
{
public:
HwndWrapper(HWND handle)
{
this->handle = static_cast<System::IntPtr>(handle);
}
virtual property System::IntPtr Handle
{
System::IntPtr get()
{
return handle;
}
}
private:
System::IntPtr handle;
};
332:328
08/12/12 08:29:03
Showのところでこうやると親子関係できました。
HwndWrapper ^ww = gcnew HwndWrapper(GetSafeHwnd());
fm->Show(ww);
ただ、親が動いても子は元の位置のままなのでちょっと不便です
ウインドウ上にボタンが乗ってるように一緒に移動してくれません。
MFC側でコントロールするとどうしても遅れが生じるので不自然っぽいです。
どうもうまくいかないので教えていただいた
「MFC ダイアログ ボックスとしての Windows フォーム ユーザー コントロールのホス」
の方をやってみます。
333:デフォルトの名無しさん
08/12/12 10:02:59
子ウィンドウとownedウィンドウの区別も付いてないのか
334:328
08/12/12 10:52:09
ホストの方法でいけました
ありがとうございました
335:デフォルトの名無しさん
08/12/13 18:30:25
ぬこでも～のwindows SDK編のイントロダクションのコードが
cygwinでコンパイルで通りませぬ・・・
VSでも無理だったんですが原因わかりますか？
URLﾘﾝｸ(www.kumei.ne.jp)
336:デフォルトの名無しさん
08/12/13 18:38:46
スレチ、winAPIスレへ行け
337:デフォルトの名無しさん
08/12/13 18:53:26
char使ってるからunicodeがらみだろうが
すれ違いの上エラーの内容も書かない阿呆か。
338:デフォルトの名無しさん
08/12/15 01:57:38
VS2005の環境でプログラム書いていたのですが、
テキスト形式のデータを読みだそうとすると以下のエラーが出てきてしまいました。
System.ObjectDisposedException' のハンドルされていない例外が mscorlib.dll で発生しました。
追加情報: 閉じている TextReader から読み取ることはできません。
System.ObjectDisposedExceptionのことを調べてもいま一つどういうことなのかがわからなかったので、
何がダメだと言われているのか教えていただけないでしょうか？
初心者なので意味不明な質問になってしまっているかもしれませんが、よろしくお願いします。
339:デフォルトの名無しさん
08/12/15 02:03:39
端的に言えば、Close/Disposeを読んだ後に、まだ何かやろうとしてるということ。
自分でそれらを呼んでいるか、自動変数のスコープを抜けるときに自動的に呼ばれたか。
340:デフォルトの名無しさん
08/12/15 10:29:08
元のコードに原因がある。
341:デフォルトの名無しさん
08/12/15 13:12:47
>338
こっち池
くだすれ．NET（超初心者向け）
ｽﾚﾘﾝｸ(tech板)
342:デフォルトの名無しさん
09/01/04 04:35:53
参照クラスって、使用しなくなったインスタンスを自動開放してくれるって
ことでいいんだよね？
343:デフォルトの名無しさん
09/01/04 14:11:08
そんな単純なものじゃない
住む世界が違う
344:デフォルトの名無しさん
09/01/11 01:45:20
この言語でMFCは使えるんですか？
345:デフォルトの名無しさん
09/01/11 01:46:21
使える
346:デフォルトの名無しさん
09/01/11 02:07:07
フォームアプリからMFCサポートに変更
MFCアプリから.NET使用＆フォームアプリダイアログ作成
できるんですか？
347:デフォルトの名無しさん
09/01/11 02:08:36
できる。聞くばかりじゃなくて、やってみればいいだろ
単純な MFC アプリケーション作って、そこで CLR サポート有りにすればいい
348:デフォルトの名無しさん
09/01/11 02:11:00
MFCウィンドウ内に.NETコントロールを置くほうはCWinFormsControl/View/Dialgのクラスもある。
349:デフォルトの名無しさん
09/01/11 16:10:30
全然わかりません、MFCで共通言語ランタイムサポートを選ぶと/MTと一緒はダメと言われます。どの項目を選んでもダメです。
これはどうすればいいんですか？
350:デフォルトの名無しさん
09/01/11 16:38:36
MFC の共有DLLを使えよ。どの項目を選んでも駄目ですって条件反射で書いてるんじゃねぇ
351:デフォルトの名無しさん
09/01/12 11:22:55
VS2008を再インストールしたら治る可能性があります。とかいうからやったらほんとに治った
共通言語ランタイムサポートにできました！
352:デフォルトの名無しさん
09/01/18 05:10:12
アンマネージからrefクラスの関数を呼び出すにはどうすればいいんですか？
353:デフォルトの名無しさん
09/01/18 05:36:03
managed -> managed で呼び出すのと同じ
354:デフォルトの名無しさん
09/01/18 05:39:11
>>352
静的メンバなら>>353の言うとおり。
非静的メンバの場合、#pragma unmanagedや/clrなしの領域から直接呼ぶことは不可能。
#pragma managedな領域にそれを呼び出すだけのラッパー関数を置くしかない。
インスタンスの保持だけは、<msclr/gcroot.h>してmsclr::gcroot<>で可能。
例えばこんな感じ。
#include <msclr/gcroot.h>
msclr::gcroot<System::Object^> CreateObject()
{
return gcnew System::Object;
}
int GetHashCode(msclr::gcroot<System::Object^> const& h)
{
return h->GetHashCode();
}
#pragma unmanaged
#include <iostream>
int main()
{
msclr::gcroot<System::Object^> h = CreateObject();
std::cout << GetHashCode(h) << std::endl;
}
355:デフォルトの名無しさん
09/01/18 05:40:25
ラッパーはmanaged領域でのネイティブクラスでも可能。ただし、依然としてmsclr::gcrootは必要。
#include <msclr/gcroot.h>
class XObject {
public:
XObject() : o(gcnew System::Object) {}
int GetHashCode() {return o->GetHashCode();}
private:
msclr::gcroot<System::Object^> o;
};
#pragma unmanaged
#include <iostream>
int main()
{
XObject o;
std::cout << o.GetHashCode() << std::endl;
}
356:デフォルトの名無しさん
09/01/18 05:51:22
はっきり言って全然わかりません。同時に使うのは厳しすぎますね
じっくり解読しますありがとうございます。
357:デフォルトの名無しさん
09/01/18 07:01:49
354と355のコードでは、refクラス = System::Object、関数 = GetHashCodeとして書いてある、一応。
358:デフォルトの名無しさん
09/01/30 01:24:35
なぜに、MFC＋.NETなんて使う必要があるんだ？
.NETが許される案件なら.NETで押し通せばいいじゃん
大抵の案件は、.NETは拒否られる
359:デフォルトの名無しさん
09/01/30 01:28:02
自分の狭い世界で語られてもな
360:デフォルトの名無しさん
09/01/30 02:06:05
.NETは遅い
361:デフォルトの名無しさん
09/01/30 02:35:18
そーだね
でもrubyよりは速いよ
起動以外は
362:デフォルトの名無しさん
09/01/30 21:08:41
Visual Studio 2008がやたら、重いんで
ちょっとしたテストプログラムはテキストエディタで作成して
コマンドラインからビルドしたいんですけど、どうすればいいのかしらん？
363:デフォルトの名無しさん
09/01/30 21:16:08
nmake か VCBuild を使う
364:デフォルトの名無しさん
09/01/30 22:18:18
C++/CLIのString型とC言語のchar文字列は、
どのようにデータをやり取りさせればいいのでしょう？
char c_str[]="1234";
String ^cli_str;
cli_str = c_str; // cli_strに"1234"をコピー
と言った事をやりたいのですが。
365:デフォルトの名無しさん
09/01/30 22:31:23
cli_str = gcnew String(c_str);
366:デフォルトの名無しさん
09/01/30 22:34:52
2008以降ならmarshal_asおよびそのソースコード
367:デフォルトの名無しさん
09/01/30 22:40:43
バカ正直にやるならASCIIEncoding
368:デフォルトの名無しさん
09/01/30 22:46:30
その実体はMultiByteToWideChar
369:デフォルトの名無しさん
09/01/30 22:49:20
ありがとうございます。
コンパイルやってみて上手く動きました。
String型文字列をchar型にコピーするのについても質問したいのですが、
c_str[0]=cli_str[0];
というのを繰り返す事でコピーできる事まで調べました。
これを行う為の関数のようなものはあるのでしょうか？
370:デフォルトの名無しさん
09/01/30 23:00:33
・・・みんないっぱい検索キーワード出してるじゃん
まじめに探したの？
371:デフォルトの名無しさん
09/01/30 23:08:35
marshal_contextを使うか、CString/CStringA/CStringWを使うか。
どっちもexpress edtionだと使えなかったと思う。
裏技的にはsprintfを使う方法がある。
372:デフォルトの名無しさん
09/01/30 23:12:30
だから、WideCharToMultiByte があるじゃないか
373:デフォルトの名無しさん
09/01/30 23:17:04
>>372
それは単なるUNICODE-ANSI変換でない？
残りの方法はこんなとこ、使い方はぐぐってね。
Marshal::StringToHGlobalAnsi
Marshal::StringToHGlobalUni
PtrToStringChars
374:デフォルトの名無しさん
09/01/30 23:18:12
>>369
それ仮名・漢字が入ると死ぬよ。
375:デフォルトの名無しさん
09/01/30 23:19:24
Encodingが一番確実か
376:デフォルトの名無しさん
09/01/30 23:25:26
>>373
Unicode -> MBCS変換だろうけど
WideCharToMultiByteは変換に使えないの？
377:デフォルトの名無しさん
09/01/30 23:28:02
>376
そのまえにToArrayしてpin_ptrして、サイズ計算して、領域確保して変換だから
ほかの方法のほうが断然楽
378:デフォルトの名無しさん
09/01/31 01:33:06
>>377
ToArrayよりPtrToStringCharsだろ。
いずれにせよ、pin_ptr<const wchar_t>化してしまえば、
既存のライブラリが使えるので、持ち合わせがあればそんなに悪くない選択肢だと思う。
379:デフォルトの名無しさん
09/01/31 14:04:04
C++/CLIで書いたプログラムって
Monoで動く？
380:デフォルトの名無しさん
09/01/31 14:09:57
動くのもあるし、動かないのもある
381:デフォルトの名無しさん
09/01/31 14:23:46
/clr:safeのものは動く。
ただしSTL/CLIのサポートはまだのようだった。
382:デフォルトの名無しさん
09/02/01 01:06:00
cl.exe でコマンドラインからコンパイルすると
～.exe.manifest
なるものも生成され、削除すると～.exeが起動しなくなります。
ｅｘｅ単体で起動できるようにするにはどうしたらいいのですか？
383:デフォルトの名無しさん
09/02/01 01:13:32
>>382
mt -manifest HOGE.exe.manifest -outputresource:HOGE.exe;#1
これやると、manifestがexe内に埋め込まれるので、manifest無しで動く。
384:デフォルトの名無しさん
09/02/01 01:29:08
>>383
ありがとう
できました。多謝です
385:デフォルトの名無しさん
09/02/01 23:49:39
CLIｽﾚ伸びませんねｗ
実際に使ってるところある？
386:デフォルトの名無しさん
09/02/02 00:27:50
仕事で事前調査用に使ったが、周りに理解されず、本番はVC++6.0でMFC4.2ときたもんだｗｗｗ
なんか、布教にいい道具があればいいのだけど…。
387:デフォルトの名無しさん
09/02/02 01:41:31
WPFとかに対応しない限りまず消滅すると思った方がいいだろうね。
388:デフォルトの名無しさん
09/02/02 02:25:50
WPFが俺の思ってる物と同じなら、対応するとかナニ言ってるんだって感じ。
まあ、Cのポインタ全部絶滅させられるならどっちでもいいがw
389:デフォルトの名無しさん
09/02/02 02:27:19
>>388
絶滅させられないからこそのC++/CLIじゃないの？ｗ
390:デフォルトの名無しさん
09/02/02 08:48:55
今のところMFCのCArchive使ってファイル保存していた古いデータを
.NET側から簡単に読み込むためのモジュールを作るのに重宝してるってぐらいだなぁ。
391:デフォルトの名無しさん
09/02/02 19:55:31
WPFみたいなほとんどマネージコードによるマネージコードのための超高レベルフレームワークを
わざわざC++で使う意味がわからない
392:デフォルトの名無しさん
09/02/03 01:32:22
まぁP/InvokeやCOWだけじゃ困る場面もたまにはあるわけだし。
やってることは凄いんだが評価されないC++/CLI。
とりあえず「C++屋のための.NET言語」という勘違いをされ気味なのはなんとかすれ。
393:デフォルトの名無しさん
09/02/03 02:17:17
進化したMS版C++Builderくらいにしか思ってませんでしたｗ
394:デフォルトの名無しさん
09/02/03 02:20:41
使いやすいGUIライブラリ付きのC++という捉え方は誤解の元だね
395:デフォルトの名無しさん
09/02/03 02:27:14
どうして誤解なのか解説しちくりくり
396:デフォルトの名無しさん
09/02/03 03:16:05
使いやすくないからな。
GUI部分はC#でいいべ。
397:デフォルトの名無しさん
09/02/03 09:07:45
C#の「＃」は、++++ で C++++の略でしたっけ？
398:デフォルトの名無しさん
09/02/03 09:21:42
>>396
まあそうなんだが、GUIだけ分けるのもかえって面倒だったりするしな。
399:デフォルトの名無しさん
09/02/03 15:51:47
>>389
何言ってんだお前
400:デフォルトの名無しさん
09/02/04 00:28:07
>>397
別に略ではないな
401:デフォルトの名無しさん
09/02/04 15:17:24
で、どうしろと？
402:デフォルトの名無しさん
09/02/04 21:50:29
とりあえずチンコでも揉んでみたら
403:デフォルトの名無しさん
09/02/04 22:13:08
チンコとかの話しかしない人に必要な言語は
C++/クリ(ry
C++/CLIは地味だけど、商用デスクトップアプリで
.NET使う場合はよけて通れない言語じゃないかなぁ。
.NETなアプリはまだ本家MS様も出してないよね？
Expression もハイブリッドだし。
404:デフォルトの名無しさん
09/02/04 22:18:08
ネイティブとマネージドのミックスタイプのアプリはMSのプロダクトに増えたけど、
基本的にホスティングがおおいな。
C++/CLIはあまり見かけない。
405:デフォルトの名無しさん
09/02/04 22:53:46
>>404
あ～。ホスティングだったのか。
勘違いを正してくれてありがトン
406:デフォルトの名無しさん
09/02/04 22:59:00
XNAのWindows向けアセンブリくらいだろうなぁ。
407:デフォルトの名無しさん
09/02/04 23:36:35
俺の言ったカンファレンスじゃ、ベンダーがC++/CLI がベストと言って楽しそうだった
408:デフォルトの名無しさん
09/02/04 23:51:11
WPFも一部C++/CLIだな
XNAのフレームワーク部分はC#だよ
409:デフォルトの名無しさん
09/02/05 00:03:15
>>408
んー？ Reflectorで眺めた結果で予想してるだけだが、
Microsoft.Xna.Framework.Game.dll以外はほぼC++/CLIのアセンブリでしょ。
FBXインポータが3MB超なのも、もろにfbxsdkのバイナリとマージしてるからかと。
410:デフォルトの名無しさん
09/02/05 01:17:05
ネイティブとマネージドのミックスタイプのアプリは現在、どの程度可能
なのか？
C++Builderでは、確かDelphi(Object Pascal)のコードがコンパイルできたと思う
が、こういうことがネイティブとマネージドの間で透過的にできるのか？
もちろん、マネージドコードとネイティブコードの混在ははるかに難しいと
思うが、これを簡単に実現できる方法を提示してもらわないとマネージドは
使う気になれない。
大体、トラブルがリンカエラーで出てくるというのは、エラー箇所の特定が
非常に難しく、最悪の状態ではないか？
まぁ、C＃が良いみたいだけど、結局、VBだろが、VC++だろが、C#だろが
Windowsプログラミングになるとどの言語だろが関係ない。
結局、MIcrosofが決めた訳の分からん取り決めに振り回されることになる
から。
411:デフォルトの名無しさん
09/02/05 01:18:58
日記もつけたし今日は寝る。お休み。
412:デフォルトの名無しさん
09/02/05 01:29:23
>>410
その混在を実現しているのが今のところC++/CLIだけ。
#pragmaでネイティブとマネージドどっちのコードを吐くか切り替えられる。
ネイティブクラスとマネージクラスの混在（has Aでの包含）は
透過的ではないものの、手段は用意されている。
413:デフォルトの名無しさん
09/02/05 02:22:24
URLﾘﾝｸ(blogs.msdn.com)
ただのネイティブ関数呼び出しであるP/Invokeですら
導入した瞬間にこんだけの「隙」が出てきてしまうのだから
簡単に実現できる方法って言われてもお花畑だよなぁ。
理想に対する泥臭い現実解としてはイイ線いってると思うけどねぇC++/CLI。
414:デフォルトの名無しさん
09/02/05 02:58:44
とりあえずガンガン使っていくので今後ともよろしく＞C++/CLI
使って情報を出さないとね。ググった結果に引っかかるサンプル増やせば
ちったあ底辺広がるだろうし。
415:デフォルトの名無しさん
09/02/10 09:57:12
バイナリフォーマットで100MBほどのデータを
シリアライズしようとしているのですが、
デシリアライズするときにメモリを数倍も消費して
ロードできないのですが、
デシリアライズをカスタマイズしないとできないのでしょうか？
GC::Collectするとメモリがいっぱい回収できます。
416:デフォルトの名無しさん
09/02/10 20:58:03
諦めてXmlReaderかストリーミングでLINQ to XML使った方がいい
417:415
09/02/10 23:00:48
結局、自前で読み書きするようにしました。
418:デフォルトの名無しさん
09/02/11 13:54:41
>>392
> やってることは凄いんだが評価されないC++/CLI。
MSがC#を前面に押し出したから見向きされなくなったよね。
それにC++はもともと敷居が高い言語だけど、
マネージドが入るとさらに敷居が高くなるからね。
員数仕事じゃ使うの無理じゃない？
419:デフォルトの名無しさん
09/02/11 13:58:36
>>418
＞MSがC#を前面に押し出したから見向きされなくなったよね。
その頃はまだmanaged C++といってほとんど試作品」だったよ
420:デフォルトの名無しさん
09/02/11 13:59:16
C++/CLIのコンパイラのソース出してくれないかなあ。
CLIじゃなくて、JVMのバインディング、面白そう。
421:デフォルトの名無しさん
09/02/11 14:00:00
>>419
「その頃」違いです。
422:デフォルトの名無しさん
09/02/11 17:01:01
そもそも、.NETはお金を頂くソフトウェア作るには不向き
・遅い
・ソース丸見え
・フレームワークインストール必須
・FAでは絶対に無理
枚挙に暇がない
423:デフォルトの名無しさん
09/02/11 17:35:54
今時そんなのが問題になるのか？
424:デフォルトの名無しさん
09/02/11 17:48:12
＞・ソース丸見え
あっちこちでネガネガしてる奴のようだ。ほっとくに限る。
425:デフォルトの名無しさん
09/02/11 18:58:12
組込みでC言語、VB6を少々
しかやった事無いけど、CLRでデータロガ作ってみた。
Windowsの知識はほとんど無いけど、すごく簡単ね
Win32Apiでやろうと思ってたけど、自分のツール程度ならCLRでいいかな。
とりあえず田舎で本が手に入らないからゴリ押し(ほぼC言語ｗ)で作成中、
勉強すればもっと便利に使えると思うんだけど・・・。
皆さんはどうやってC++/CLRを勉強したの？
426:デフォルトの名無しさん
09/02/11 19:00:29
勉強？
どこをどう勉強する必要があるんだ？？
427:デフォルトの名無しさん
09/02/11 19:17:43
>>425
C++の経験者が使う言語だと思ったほうがいい。
Win32APIやCのライブラリを使わないならVB.netやC#やったほうがいい。
428:デフォルトの名無しさん
09/02/11 19:18:12
デフォルトでスマートポインタなCOMの一種と考えるとそれほどでもない
429:デフォルトの名無しさん
09/02/11 21:36:59
C++とC#の経験があればそのまま使える
というか，そういう人にしか旨味のない言語
簡単だと思うのはC#やVB.NETを触ったことがないから
430:425
09/02/12 03:33:22
>>426-429
ありがとう、意見を参考に、ずっとC#のサンプルコードいじってた。
とりあえず腹減ったので寝ようかな。
>>427
当初Win32APIをやろうと思ったけど、開発効率重視で諦めました。
*組込み屋なんで速度と柔軟な処理が可能かが気になりましたが、
そんな難しいもの作るわけじゃ無いので。
431:デフォルトの名無しさん
09/02/14 19:15:48
E-mail欄ってほとんどE-mail欄の役割は果たしてないよね。