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

C++/CLI について語ろ ..

331:デフォルトの名無しさん
07/07/25 22:11:43
Applicationにあったのか！
ありがとう。
ずっとProcessとかを探してたよ
Win32APIのときGetModuleDirectoryとかなんとかだったから

332:デフォルトの名無しさん
07/07/25 22:51:56
>>331
その線も惜しい。
Win32はGetModuleFileNameだったでしょ。
.NETだとモジュール (EXE/DLL)に対応するものはアセンブリだから、
その方向でやるならAssemblyクラスが正解だった。

URLﾘﾝｸ(www.atmarkit.co.jp)

333:デフォルトの名無しさん
07/07/27 12:14:00
Visual Studio 2005 で C++/CLI を使おうとしています。
std::vector<System::String^> のように標準のSTLのコンテナには
ハンドルを格納することはできないのでしょうか？
C++/CLI にはマネージドな世界独自のコンテナクラスライブラリが
用意されているのでしょうか？今の自分は array<String^>
しか使えずさみしい毎日を過ごしています。

std::vector<System::String^>^ lines;
try{
for(;;)
lines->push_back(stream_reader->ReadLine());
} catch
以下略

のようにぶん回してファイルを行単位で全行
読み込みたいだけなのですが・・・

334:デフォルトの名無しさん
07/07/27 12:19:12
>>333
＞C++/CLI　にはマネージドな世界独自のコンテナクラスライブラリが
つSystem::Collections::Generic

STL.NET構想はどっかいっちゃったけどな

335:デフォルトの名無しさん
07/07/27 12:26:29
>>334
おお、「コレクション」というのですか。
どうりで C++ CLI コンテナ　で検索していても
昔の managed C++ の資料や gcroot でがんばる
という方法しか見つからず難儀していました。
しかも cliext::vector なんかも見つかってしまい、
余計に混乱していました。cliext 名前空間以下の
識別子ってのが STL.NET なんですかね？

336:デフォルトの名無しさん
07/07/27 12:42:30
>335
STL.NET は STL/CLR という名前で VS2008 に同梱
ただ、.net fx 2.0 では動かない

こういう後方互換性がないものを C++/CLI で出してほしくなかった

337:デフォルトの名無しさん
07/07/27 12:47:04
＞後方互換性

上位互換が無いってことか？

338:デフォルトの名無しさん
07/07/27 12:49:22
>>336
それで困るやつはどれだけいるんだ

339:デフォルトの名無しさん
07/07/27 12:51:29
STLってのはC++では最重要なんだが...

340:デフォルトの名無しさん
07/07/27 12:55:13
>>336
それ本当？
.NET Framework 3.0も3.5もCLRのバージョンは2.0のままだろ。

341:デフォルトの名無しさん
07/07/27 13:07:08
.net fx 2.0 で作ってた既存アプリに STL/CLR を使って修正すると、アプリの実行に
3.5 が必要になるのは嫌じゃね？
前のCTPの頃はライブラリだけ持って行けばよかったんだが

342:デフォルトの名無しさん
07/07/27 13:22:05
>340
Beta1 で Microsoft.VisualC.Stlclr.Dll ＋ヘッダ抜き出しで駄目だったという報告があった

とりあえず、Beta2 が来てるんで、入れて試してみる
一応、「Microsoft.VisualC.Stlclr.Dll は .net fx 3.5 の一部ではない」はずなんだが

343:デフォルトの名無しさん
07/07/27 13:47:59
>>341
>.net fx 2.0 で作ってた既存アプリに STL/CLR を使って修正すると、アプリの実行に
>3.5 が必要になるのは嫌じゃね？
>前のCTPの頃はライブラリだけ持って行けばよかったんだが

コンパイルし直すんだろ？
どうせmsvcp90.dllとか増えてるんじゃないの？
VC++のランタイムライブラリに同梱ってのが幸せになる道かねぇ。

まあ3.5のサイズにもよるな。

344:デフォルトの名無しさん
07/07/27 14:43:50
>343
客先に説明するのが面倒なんだよね。でも、STL/CLR は使いたい
できれば、CTP同様に VS2005 + ヘッダ + Microsoft.VisualC.Stlclr.Dll で STL/CLR を
使った開発ができる方がうれしい。SP2 で来ないものかな

345:デフォルトの名無しさん
07/07/27 17:14:22
std::vector<int> v;
　　　：
for each(int i in v)
{}

for eachでbegin(), end()が呼ばれているようですが
ECMA-372にはこの振る舞いの記述が見あたりません。
MSの独自拡張なのでしょうか?

346:デフォルトの名無しさん
07/07/28 00:28:26
>345

これでも行けますね

int vec[] = { 1, 2, 3, 4, 5 };

for each ( int num in vec )
{
　　std::cout << num <<std::endl;
}

配列アクセスが可能なものは Array のラップを掛けて渡されているのでは
ないでしょうか。Array は IEnumerable ですし

347:デフォルトの名無しさん
07/07/28 00:34:44
>346
ごめん。これはできて当たり前だわ
array<int>^ vec = { 1, 2, 3, 4, 5 };
と同等だもんな

348:デフォルトの名無しさん
07/07/28 07:12:42
>>346
Cタイプ配列とarray<T>は同等じゃないから346は通らないのでは？

349:デフォルトの名無しさん
07/07/28 07:20:17
std::vectorに対するfor　each　inはネイティブでコンパイルしても使えてるな。
/Zeで拡張構文を抑制するとeachが構文エラーになった。
//　cl　/EHsc　hoge.cpp
#include　<iostream>
#include　<vector>
int　main()　{
　　std::vector<int>　v;　v.push_back(1);　v.push_back(5);
　　for　each　(int　i　in　v)　std::cout　<<　i　<<　std::endl;
return　0;　}

350:デフォルトの名無しさん
07/07/28 18:16:58
>348
Cタイプ配列は C++/CLI では array<Type> でラップされるよ。だから、346 は動く
>347 がそれを言ってる

ヘッダ見たけど、特に ecma-372 で必要とされている IEnumerable の定義も
見あたらないから、CLR・・・で定義されている所に、拡張構文で潜んでるっぽい

351:デフォルトの名無しさん
07/07/28 18:24:10
VS2008 Beta2 試してみた。コンパイル対象となる .net fx が選べるようになったんだが
2.0, 3.0 を選んだとき、STLCLR.dll は使えなかった
STL/CLR を使いたかったら、3.5 を普及させろと言うことらしい

　　(　ﾟдﾟ)　Feedback ﾏﾝﾄﾞｸｻ
＿(__つ/￣￣￣/＿
　　＼/　　　　 /
　　　　￣￣￣

　　( ﾟдﾟ )
＿(__つ/￣￣￣/＿
　　＼/　　　　 /
　　　　￣￣￣

352:デフォルトの名無しさん
07/07/28 19:47:41
>>350
C#のCタイプ配列はCLR配列だが、C++/CLI　のCタイプ配列はCLR配列じゃないぞ。
>>346を実際にコンパイルしてみろ、C3285でしっかりコンパイルエラーが出る。　

353:デフォルトの名無しさん
07/07/28 23:12:16
VC8 SP1で試したけど/clrの有無に関わらずC3285になるね。

当たり前だけど、boost::arrayはOK。
どうせならレンジに使えればいいのに、
ってそれなんてBOOST_FOREACHなんだけどね。

354:名無しさん＠そうだ選挙に行こう
07/07/29 14:40:44
>352-353
悪禁食らっていたので返答が遅れた
ごめん。漏れが試したのは、VS2008 Beta2 だった。こちらは >346 でコンパイルできるし
動く。また、ecma-372 でも、仕様上 346 で正しいから、VC8 で取りこぼしてた仕様が
いくつかあったやつを VC9 で準拠したんだと思う

/clr の有無に関わらずって、/clr なくて for each が使えるの？

355:名無しさん＠そうだ選挙に行こう
07/07/29 19:24:33
>>354
349でネイティブでも使えるという報告があるよ。

356:デフォルトの名無しさん
07/07/30 14:40:51
ファイル名をキーとするstd::mapのようなものを作りたく、Generic::Dictionaryのキー型にString^
比較にStringComparer:::CurrentCultureIgnoreCaseを指定してるのですが
全角アルファベットの大文字・小文字も同一視されてしまいます。
要するにNTFSやFATと同じようなファイル名の比較をしたいのですが、どうすればいいんでしょうか?

357:デフォルトの名無しさん
07/07/30 15:16:49
つネイティブC++

358:デフォルトの名無しさん
07/07/30 15:50:00
>>356
WindowsのNTFSファイルシステムドライバは"Ａ"と"ａ"は同じ文字とみなしてるよ？

359:デフォルトの名無しさん
07/07/30 16:11:47
>>358
あ、ほんとだ。区別されるものと思ってた。

360:デフォルトの名無しさん
07/07/31 10:22:34
>>356
カーネルの中には比較する関数あるんだけどね・・・
なんでユーザーモードに無いのかは謎

まじめにやると日本語やアルファベット以外の文字（ヨーロッパ圏など）でも
全角半角を問わず大文字小文字を区別しないので
割と面倒だった気がする。

361:デフォルトの名無しさん
07/08/01 04:25:12
Visual Studio 2005 で C++/CLI を使っています。
フォームデザイナの機能で C++/CLI と C# の間に
違いはあるのでしょうか？
つまり C# でのフォームデザイナと、C++/CLi での
フォームデザイナの間に、利用できるコントロールの
種類などで違いがあるのでしょうか？
.NET Framework で用意されている機能なら言語によらず
利用可能だとおもうので差はないと思っているのですが。

362:デフォルトの名無しさん
07/08/01 04:54:48
マネージドなプログラム組むならＣ＋＋なんか使わねっつの！ｗ

363:デフォルトの名無しさん
07/08/01 08:38:47
＞マネージドなプログラム

これってメリットある？
いや、一般論じゃなくて実際のところ。

364:デフォルトの名無しさん
07/08/01 09:07:42
プラットフォームにVistaが使えるじゃねーか。

365:デフォルトの名無しさん
07/08/01 09:14:12
いや、Vi$taにあうのはネイティブアプリ。

366:デフォルトの名無しさん
07/08/01 11:44:46
>>363
自分専用ツールにはクラスライブラリが充実しているので便利。

367:デフォルトの名無しさん
07/08/01 12:01:52
>>366
それにしては、Win32で出来るものが出来なかったり、中途半端。

だったらVCLみたくネイティブクラスライブラリ充実させろよ。

368:デフォルトの名無しさん
07/08/01 12:05:21
＞クラスライブラリが充実しているので

これって、ネイティブ版クラスライブラリを作成すれば完璧だおね。

M$のﾄﾞﾄﾈﾄ囲い込み戦略に嵌められてるだけじゃないの？
ﾄﾞﾄﾈﾄは終焉したわけだし、無視した方が良いよ。

369:デフォルトの名無しさん
07/08/01 12:37:37
ドトネト君っていろんなスレにいるな。
飽きないの？

370:デフォルトの名無しさん
07/08/01 13:00:03
＞プラットフォームにVista

つ　URLﾘﾝｸ(gigazine.net)

企業ユーザーの大多数はVistaへの移行を考えていない

371:デフォルトの名無しさん
07/08/01 16:47:45
そりゃ、CreateFile系のAPI自体がバグでロックしちゃうんだもの。
企業ユーザが使おうとするわけがない。 >> VISTA

372:デフォルトの名無しさん
07/08/01 17:10:29
>CreateFile系のAPI自体がバグでロックしちゃうんだもの。

kwsk

373:デフォルトの名無しさん
07/08/01 17:12:17
これか
URLﾘﾝｸ(d.hatena.ne.jp)

374:デフォルトの名無しさん
07/08/01 22:23:38
Form.hに実装を書かせられるの嫌なんだけど、どうにかならない？
てか、なんでForm.hに実装させるような仕組みにしたんだろう？

375:デフォルトの名無しさん
07/08/01 23:02:47
Form.cppに実装を移せば？

376:デフォルトの名無しさん
07/08/01 23:59:06
実装を書かせるといっても、イベント用に開発環境が自動生成したものですよね。
これをcppにということになると、たとえば、フォームデザインの変更を
ちょこちょこやる場合、Formのデザイナとヘッダとcppを行ったり来たりでは
やっぱり大変だよね。

377:デフォルトの名無しさん
07/08/02 00:59:04
ぶっちゃけVC++8の.NETサポートは「諦めろ」としか言えないよ・・・

378:デフォルトの名無しさん
07/08/02 04:03:15
VC++9 では何か変わってるの？

379:デフォルトの名無しさん
07/08/02 09:44:37
そりゃ変わってますよw

380:デフォルトの名無しさん
07/08/02 18:35:26
VC2008先行して使っている人、
デサイナが生成するコードに何か大きな変化は有りましたか？

381:デフォルトの名無しさん
07/08/02 21:36:34
試してみたけど変わってないみたいだね。残念だ…

382:デフォルトの名無しさん
07/08/02 22:27:36
C++/CLI に関してはろくに対応されていないね。STL/CLR なんか作ってる場合じゃないと
思うんだが。結局、ネイティブ・アプリの ClickOnce 対応もしていないし

383:デフォルトの名無しさん
07/08/02 22:53:42
いや、STL/CLRは「ろくな対応」なんじゃないか？

384:デフォルトの名無しさん
07/08/03 01:11:20
ネイティブの STL にマネージド・オブジェクトが格納できればいらない対応でしょ
むしろ、2種類のライブラリに混乱しかねない

385:デフォルトの名無しさん
07/08/03 01:41:52
マネージドなSTLはそれになりに便利だと思う。
標準C++ & boost萌えな俺には、C++/CLIやC#はきついんだが…

386:デフォルトの名無しさん
07/08/03 08:17:10
>>384
確かに。少なくともクラス定義だけでも、
ネイティブクラスと値クラスに違いがなければいける。

前にも書いた気がするけど、ハンドル用のアロケータ書いてみたが、
ネイティブクラスはハンドルを持てないのでだめだった。

387:デフォルトの名無しさん
07/08/03 08:27:31
C++0x の concept map が C++/CLI に実装されたら、それつかって managed class を STL コンテナにいれられるのでは...

388:デフォルトの名無しさん
07/08/03 10:16:37
だとしたら、ほんとに STL/CLR は C++0x が確定するまでの繋ぎでしかなくなるな

389:デフォルトの名無しさん
07/08/03 11:18:52
いや、一応STL/CLRは一度覚えればC#でも使えるんだろ?

390:デフォルトの名無しさん
07/08/03 11:21:41
STL/CLR は C++/CLI せんよーだってさ
テンプレートで実装してるしね

391:デフォルトの名無しさん
07/08/03 11:22:36
じゃあ、意味ねーなw

392:デフォルトの名無しさん
07/08/03 11:33:20
なんかグダグダ

393:デフォルトの名無しさん
07/08/03 16:46:48
でもまだSTL/CLRのコンテナは、System::CollectionsやSystem::Collections::Genericの
インタフェースを実装しているのが強みと言えるかもしれない。

394:デフォルトの名無しさん
07/08/03 16:51:41
STLがあればGenerics要らんやん。

395:デフォルトの名無しさん
07/08/03 17:49:38
C# にも展開してくれれば良かったんだけどなぁ

396:デフォルトの名無しさん
07/08/04 00:58:40
まぁどっちかっつーと.NET言語の態勢を保ちつつ
コンパイル時のコード生成であるC++テンプレートをサポートするってのが
端から無茶やってるとは思うけどねぇ。

397:デフォルトの名無しさん
07/08/04 13:00:12
C++/CLIでは
stringstream
に相当するものは用意されているのでしょうか？

398:デフォルトの名無しさん
07/08/04 13:03:09
.NETのクラスライブラリにはMemoryStreamが似ている存在。
でもstringstreamだって使いたければ使えばいいし。

399:デフォルトの名無しさん
07/08/04 15:31:51
StringBuilder や StringReader, StringWriter を使ってもいいな

400:デフォルトの名無しさん
07/08/04 23:23:24
C++/CLIでも派生させるクラスのデストラクタはvirtualにすべき？
勝手になる？

401:397
07/08/04 23:41:29
長さの単位がString,StringBuilderはInt32でStreamはInt64くさいけど
System::IO::Streamとしても使いたかったんで
MemoryStreamから派生することにした。

順序つきで使える operator >>　は面倒だからやめた・・・。

generic <typename T> MyStringStream% operator << (T x)
{
cli::array<unsigned char>^ buffer = System::Text::Encoding::Unicode->GetBytes(x->ToString());
this->Write(buffer,0,buffer->Length);
return *this;
}

402:デフォルトの名無しさん
07/08/05 00:21:56
>>400

ポインタを使った場合だと、virtual 付けないとダメね
ハンドル型だと、virtualなしでもいける

403:デフォルトの名無しさん
07/08/05 00:23:24
>>402
へえ、boost::shared_ptrみたいだな

404:デフォルトの名無しさん
07/08/05 00:26:44
「リソース管理できてデストラクタに罠がない賢い手段」
目指してるものが同じだからな。

405:デフォルトの名無しさん
07/08/05 00:54:52
>>402
トンクス！

406:デフォルトの名無しさん
07/08/05 01:28:41
ハンドル型っていまいち概念がわからん。
マネージドヒープにある実体を指すポインタなんだろうか？

407:デフォルトの名無しさん
07/08/05 01:35:03
ガベコレの都合から考えたほうが早いかも

408:デフォルトの名無しさん
07/08/05 02:07:15
ref class だと
デストラクタってDisposeじゃなかった？
だからvirtualにならないとつじつまが合わない気が・・・

409:デフォルトの名無しさん
07/08/05 05:28:45
>>408
ref　classのデストラクタはDispose()ナマじゃなからvirtualかどうかは意味がない。
デストラクタを宣言すると暗黙でDispose(bool)とDispose()とFinalize()が定義されて、
デストラクタはDispose(bool)から間接的に呼ばれるので、
結果、継承ツリーの下位のほうから順にデストラクタが呼ばれる形になる。

410:デフォルトの名無しさん
07/08/05 08:36:27
>>406
ようするにそういうこと。ただしポインタ演算禁止で、演算子多重定義が使える。
ポインタ演算がやりたければinterior_ptr<>。

411:デフォルトの名無しさん
07/08/05 13:26:15
>>406
> マネージドヒープにある実体を指すポインタ

が含まれてます。ハンドルには。
そのポインタ(あるいはID)を直接操作するのは危険なので、
(たとえばGCで、場所を移動されるかも知れないので)
ハンドルを介して、その対象を操作するのです。

用語としては、車を運転する時に、直接タイヤを動かすのではなくて、
ハンドルを回して、タイヤを動かすあのハンドルと同じです。

CでFILE型がファイルハンドルと呼ばれるのと同じ。

412:デフォルトの名無しさん
07/08/05 17:38:01
>>410,411
thx

引数にint^で受け取ると勝手にSystem::Int32^になってるんだな。
int main(){
int x=10;
plusA(x);//値は変わらない
plusB(x);//値が変わる
}
void plusA(int^ x){
((int)x)++; //int型へのキャストが必要
}
void plusB(int% x){
x++; //いまいち理解できない
}

ところでConsole::WriteLineっていうのがあったと思うけど、
どうなったのでしょうか？VS2005のどこにも出力されないんですけど。

413:デフォルトの名無しさん
07/08/05 18:48:52
>>412
%は参照&のマネージド版。

ハンドルは、一応ポインタになぞらえられることを示すとするとこんな感じ。
値型をボックス化したハンドル絡みではこういうことになる。
void plusA(int^ x) {
(*x)++;
}

int x = 10;
int ^h = x;
plusA(h);
std::cout << x << ' ' << *h << '\n';

414:デフォルトの名無しさん
07/08/06 00:13:39
void plusA(int^ x) {
(*x)++;
}

int ^x=10;
plusA(x); //書き換わる
plusA(*x); //そのまま

ようするに参照ということかな？VBのByrefみたいな。

std::coutもprintfもWriteLineもどこにも出力されないんだが、
どうやって出力結果を見てるの？

415:デフォルトの名無しさん
07/08/06 00:48:01
>>414
Console::ReadLine();などででプログラム止めてる？

plusA(*x);　って、*xがplusA関数に渡されるときに、
*xのコピーオブジェクトが作成され、そのハンドルがplusA関数の仮引数に
格納されるから、値が変わらないってことでいいのかな？

そうそう、
(10).Equals(11);
みたいに定数もオブジェクトとして扱われるんだね。

416:デフォルトの名無しさん
07/08/06 01:21:27
>>414
コンソールプログラムのプロジェクトにしている？
そうしないと、cout, printf, WriteLineの出力先は現れないよ。

コンソールプログラムのプロジェクトでなかったのなら、
プロジェクトのプロパティのリンカのシステムか何かのとこにサブシステムの設定があるから、
その中のコンソールを選べばいい。
URLﾘﾝｸ(msdn2.microsoft.com)(VS.80).aspx

>>415
plusA(*x);でコピーが作成されるのはそのとおり。ボクシングとは、
結局マネージドヒープに新しくオブジェクトを作って、そこへコピーすること。
値型のハンドルを引数に受け渡しすること自体はVBのByRefや
Cのポインタ渡しそっくりでいいんだが、ボクシングという
暗黙のオブジェクトのコピーが働くから話が少々厄介になっている。

417:デフォルトの名無しさん
07/08/06 21:48:15
boostみたいにprivateもシリアライズできる
非侵入型のシリアライズはないのでしょうか？

418:デフォルトの名無しさん
07/08/07 19:32:08
最初2003のManaged C++で作ってたんだが
都合により2005のC++/CLIに移ることにした。
プロジェクトを変換してコンパイルエラーを片付け、
いったんは動くようになったんだが
しばらくしてリビルドしようとすると

リンクエラーLNK2020「メタデータの操作に失敗しました」

が発生する。

今環境がないんで詳しいエラー内容は書けないんだが
「プロパティの数が違う」みたいなことを言われていた。

LNK2020にはいろいろ種類があるらしく、
「重複する型に、適合しないフィールド宣言があります」なら
リビルドすればいいらしいんだが、リビルドしてみても直らなかった。
プロジェクトを新規作成してファイルを全部入れても同じエラー。

ググっても英語のページすら出てこなかった。

誰か対処方法知ってたらｐｌｚ

419:デフォルトの名無しさん
07/08/07 19:38:50
最低限のコードを入れてリビルドして、どうなる？

420:デフォルトの名無しさん
07/08/07 19:42:36
>>419
stdafx.h
stdafx.cpp
main.cpp
resource.h

だけの状態？

421:デフォルトの名無しさん
07/08/07 20:48:11
すまんLNK2022だった

422:デフォルトの名無しさん
07/08/07 23:26:28
アノニマスな構造体があったの？

423:418
07/08/08 20:34:16
どうやらプロジェクトファイルが壊れていた模様。
もう一回プロジェクト変換しなおして
ソースとヘッダ入れたら動いた。

お騒がせｽﾏｿ

>>422
なかった

424:デフォルトの名無しさん
07/08/18 04:43:41
VC++ expressで
C++/CLIを使うときの制限事項ってどんなのがありますか？

425:デフォルトの名無しさん
07/08/18 12:05:30
別に何も無いよ

426:デフォルトの名無しさん
07/08/19 05:45:05
え？そうなの？

デバッグ機能とかGUIのデザインあたりが
はしょられてるんかと思ってた

427:デフォルトの名無しさん
07/08/19 08:36:21
>>424
URLﾘﾝｸ(msdn2.microsoft.com)(VS.80).aspx

428:デフォルトの名無しさん
07/08/19 21:32:30
intからenum（enum classじゃない）に変換したいんだが
普通のC言語のようにただのキャストじゃ変換できない？
どうもできていないような気がするんだが。

429:デフォルトの名無しさん
07/08/19 22:09:33
>>428
enum　classじゃないenumはC++のそのままですよね？
単に使い方がおかしいだけでは。ソースを示してみたらどうです。

430:デフォルトの名無しさん
07/08/19 22:34:08
DirectXのコードなんだが

D3DFORMAT fmt = (D3DFORMAT)21;

431:デフォルトの名無しさん
07/08/19 22:38:04
実際のコードでは21の部分は変数になってる。
ユーザの入力。

432:デフォルトの名無しさん
07/08/19 22:44:36
実体が unsigned long int なんじゃね？

433:デフォルトの名無しさん
07/08/19 23:03:15
ヘッダではこうなってる
typedef enum _D3DFORMAT
{
（省略）
D3DFMT_A8R8G8B8 = 21,
（省略）
} D3DFORMAT;

434:デフォルトの名無しさん
07/08/19 23:05:14
直後にブレークポイントつけてウォッチすると
fmtが「未定義の値」になってる。

435:デフォルトの名無しさん
07/08/19 23:48:25
これで普通に代入できたぞ？

int val = 21;
D3DFORMAT fmt = (D3DFORMAT) val;
std::cout << fmt << std::endl;

VS 2008 Beta2 なんで、2005でも大丈夫かわからんが

436:デフォルトの名無しさん
07/08/19 23:52:56
version違いの*.hがあって、21がない方のをincludeしてるとか。

437:デフォルトの名無しさん
07/08/20 00:53:44
d3d9types.h なんて前からあるっしょ
これでリリース・ビルドしていたせいで変数がデバッガ上で正常に表示されていなかった
なんてオチだったら指さして笑うが

438:デフォルトの名無しさん
07/08/20 23:24:44
C++/CLIって実際どのくらい使われてるの？

439:デフォルトの名無しさん
07/08/21 01:02:33
Dの5倍くらい。

440:デフォルトの名無しさん
07/08/21 06:26:53
>>438
俺仕事で使ってる
ただのラッパークラスだが

441:デフォルトの名無しさん
07/08/21 09:18:49
>>440
ネイティブのライブラリをドトネトから使うため？

442:デフォルトの名無しさん
07/08/21 20:54:43
>>411
前の製品の再利用可能な部分
GUIはC#になっちまった

443:デフォルトの名無しさん
07/08/21 20:55:14
安価ミス
>>441な

444:デフォルトの名無しさん
07/08/21 23:01:14
>435
enumは int だし。ってのはCの仕様だっけか。

445:428
07/08/22 21:45:58
どうやらint関係なしに
直接D3DFMT_R8G8B8を入れても
<未定義の値>になる。

デバッグにはなってるんだが。

446:デフォルトの名無しさん
07/08/22 22:32:24
enum は含まれる値を全て表現可能なサイズの型になる。

447:デフォルトの名無しさん
07/08/23 08:38:13
>445
直接、D3DFORMAT の enum 値を出力してみたら?
TRACE でも cout でも何でもいいけど

ちなみに、コンパイラは VC8 なんだよな?

448:デフォルトの名無しさん
07/08/23 21:02:06
>>447
ちゃんと21が出たｗ
VC8です

デバッガがミスっただけかな。

449:デフォルトの名無しさん
07/08/29 18:29:40
フォームを多言語化して、ニュートラルと日本語のリソースを交互にいじってると
設定した値が元に戻ったりするんですが、これについて何かご存じな方
いらっしゃいますか？

450:デフォルトの名無しさん
07/08/29 18:35:42
追記です
VS2005上での話です。

451:デフォルトの名無しさん
07/09/01 15:44:35
この言語ほんとに流行りそうなの？

452:デフォルトの名無しさん
07/09/01 20:26:10
.NET が流行れば。
だって既存の C++ のライブラリの
ラッパーとしての存在価値は少なくともあるから。

で、.NET というか CLR ってこれからはやるのかね？
mono でも ASP.NET をはじめとしていろいろ動く
ようになってるし、.NET Compact Framework も
広がりを見せているようだけど。

453:デフォルトの名無しさん
07/09/01 21:22:06
C++/CLI自体が単体で流行ることはないと思う。
あくまでもC++の資産を.NETで利用するためのツール。

454:デフォルトの名無しさん
07/09/01 22:30:15
C++/CLI 自体は JDirect の正当な発展系だと思う
.net が COM 拡張として発生したように、外部管理オブジェクトのハンドリング用言語として
C++ を拡張したものだから
Windows 用の Objective-C みたいなものなんだけどなぁ

455:デフォルトの名無しさん
07/09/01 23:46:12
Objective-C つかったことないや

456:デフォルトの名無しさん
07/09/01 23:48:42
はいはい死滅死滅

457:デフォルトの名無しさん
07/09/02 14:31:02
2008になったらC++CLIは何かかわんの？

458:デフォルトの名無しさん
07/09/02 14:47:34
>>457
STL/CLRとこれまで規格に非準拠だった部分の対応。
例えばC型配列がarrayと同等に扱えるようななった。

459:デフォルトの名無しさん
07/09/02 16:07:58
がるぽっ

460:デフォルトの名無しさん
07/09/02 16:09:48
C++0x が確定するまでは、大きな修正は入れてこないだろうね
また、いろいろと言われるから（ｗ

461:デフォルトの名無しさん
07/09/02 16:50:15
なんか、見た目が変態的なソースコードになるよな・・・

無理矢理.netに対応させた文法を追加せずに、
C++にライブラリで誤魔化したほうがマシな気が・・・

.netに最適化した言語、とかならC#ってのをやってるのだし、
あんまりC++/CLIの存在意味がないような・・・

462:デフォルトの名無しさん
07/09/02 18:05:21
それをやったのが mc++ で、マネージド・オブジェクトの判別が付かなくなったので
明示的に分離するように変更したんだよ
C++ は既存のままで、CLI を追加構文で、これでようやく見通しが良くなったのさ

oldSyntax で一度書いてみると、ライブラリで対応って言うのが以下に非現実的か
よくわかるよ

463:デフォルトの名無しさん
07/09/02 20:13:36
正直 Managed C++ は「よけいわかりにくいわ！」って
感じだったからな。マネージドな部分とそうでない部分が
明確に分かれている C++/CLI のほうがわかりやすい。
確かに上にあった Objective C の Microsoft 版だという
たとえは的を射ていると思う。

464:デフォルトの名無しさん
07/09/02 21:16:36
漏れにスキルさえあれば、JVM や Squeek に CLI ラッパをかぶせて、GCC の C++/CLI
実装を作ってみるのになぁ

465:デフォルトの名無しさん
07/09/07 18:04:21
.NET2005 C++/CLIで開発しています。
設定情報をapp.comfigから読みだすために
app.config(appはプログラム名へ後に変換)へ例えば
<?xml version="1.0" encoding="utf-8"?>
<configuration>
　<appSettings>
　　<add key="HOGE" value="ほげほげ" />
　</appSettings>
</configuration>
と書いて、C++/CLIのコード(フォームアプリ)からは、
MessageBox::Show(System::Configuration::ConfigurationSettings::AppSettings[ "HOGEHOGE"]);
MessageBox::Show(System::Configuration::ConfigurationManager::AppSettings[ "HOGEHOGE"]);
と呼び出して表示しているのですが、OSがXP(SP2)だとうまくいき、
Win2000(SP4)だと表示が空文字になってしまいます。
MSDNにはWin2000(SP4)もサポートしているように書いてありますし、
vcregist_x86.exeやdotnetfx.exeも実行してあるのですが。。。
このあたりの情報(こうすれば動く、実はサポート外など)を
お持ちの方、いましたら教えていただけませんか。
ネットで散々探しましたが、意外とこの話題少ないんです。
よろしくお願い板します。

466:465です
07/09/07 18:08:54
ごめんなさい。
<add key="HOGE" value="ほげほげ" />
は
<add key="HOGEHOGE" value="ほげほげ" />
の間違いです。

467:デフォルトの名無しさん
07/09/08 09:39:16
レベル高すぎ

468:デフォルトの名無しさん
07/09/08 12:14:40
>>465
うちの環境だと正常に読めてる。Vertual　PCでWin2k(SP4)。
xx.exe.configの名前はあってる？

469:デフォルトの名無しさん
07/09/11 02:02:27
>>468
>xx.exe.configの名前はあってる？
それ、ビンゴです！
C#やVBはビルド時に自動でファイル名つけてくれるのに。。。

470:デフォルトの名無しさん
07/09/22 02:10:50
過疎ってんなー
やっぱりC++/CLIは
流行らないってことでおｋ？

471:デフォルトの名無しさん
07/09/22 03:07:29
だってマネージ・アンマネージの橋渡し専用言語だもん

472:デフォルトの名無しさん
07/09/22 10:36:17
GDI+死ぬほどのろいんで、ペイントルーチンをC++/CLIでGDI使って
組めばいいんじゃね
テキスト描画すんのもGDIのが楽なような

473:デフォルトの名無しさん
07/09/22 11:09:00
>>472
VistaでDDBの速度的有利さは事実上消滅したけどな

474:デフォルトの名無しさん
07/09/22 12:22:14
DirectDraw（笑）

475:デフォルトの名無しさん
07/09/22 13:28:37
>>473
.NETがのろくて誰も使ってくれないから全員平等にのろくしたって感じだな

476:デフォルトの名無しさん
07/09/22 15:55:56
馬鹿?

477:デフォルトの名無しさん
07/09/22 20:13:30
.NETは最初から馬鹿だよ。

478:デフォルトの名無しさん
07/09/22 20:14:39
>>475
Direct3DとWPFは仲間はずれ？

479:デフォルトの名無しさん
07/09/23 04:10:23
>>471
まぁそうなんだろうけど、そういう言語が CLI 上にちゃんと
用意されているところが Java VM とは違うところだよな。
といってドトネトを擁護してみる。

いや、漏れは好きだよ C++/CLI。というかこれがないと困る。
研究用のシミュレータをC++で boost とかのライブラリ使って
書いてるけど、フロントエンドの GUI が Windows Forms で
組めるのは楽だよ。

480:デフォルトの名無しさん
07/09/23 07:26:58
それって逆に選択肢がないんじゃ… > シミュ&Win Forms

481:デフォルトの名無しさん
07/09/23 08:18:37
>>480 そうともいう。
シミュレータ自体はライブラリ化していて、コマンドライン版は
Linuxクラスタで動かしているんだけど、同じライブラリを
リンクしてWindowsで動くGUI版を作れるというのはかなり便利。

C# と C++/CLI と両方使って思うんだけど、 Windows Form デザイナ
って両者の言語でかなり安定感ちがわないか？
C++/CLI だとちょっとでも自動生成されたコードいじると
もうデザイナが発狂してしまう感じ。どの程度いじってもOKなのか
基準がよくわからない。C# のほうも基準がわからないという点では
同じなんだけど、結構いじっても Windows Form デザイナが
ちゃんと認識してくれる気がする。気がするだけか？

482:デフォルトの名無しさん
07/09/23 12:28:25
C#のほうが解析しやすい言語だから

483:デフォルトの名無しさん
07/09/23 12:57:21
解析なんてしてないだろw

484:デフォルトの名無しさん
07/09/23 13:05:02
>>483

485:デフォルトの名無しさん
07/09/25 14:00:50
プリコンパイル済みヘッダーは
C++/CLIで使えるのでしょうか？

486:デフォルトの名無しさん
07/09/25 17:51:40
使える

487:デフォルトの名無しさん
07/09/26 23:29:57
プロパチー見ろ

488:デフォルトの名無しさん
07/09/27 01:24:24
C++で今まで書いてきて
GUIをもっとバリバリやりたくなってきたんですが
かといってMFCは嫌い。
C#は書き直すのがめんどいし
そんな漏れはC++/CLIがいい？

489:デフォルトの名無しさん
07/09/27 06:58:21
>>488
Win32

490:デフォルトの名無しさん
07/09/27 09:23:42
ネイティブで書かれた関数(数値計算のエンジン)を別のスレッドで動かして、
結果をグラフィカルに表示するなんてことができます？
ネイティブの_begin_thread 関数を呼び出す必要が有りますか？
それともドトネトのなにかを呼び出すべきなんでしょうか？

491:デフォルトの名無しさん
07/09/27 09:42:20
>>490
どちらでも可能だが、
マネージドのスレッドを使ったほうが取り扱いが楽だと思う。

492:デフォルトの名無しさん
07/09/27 09:44:11
ネイティブを混ぜるマネージドアプリに何の意味がある。

493:デフォルトの名無しさん
07/09/27 09:47:20
>>492
C++/CLIスレでそれを言うなよ。/safeにどの程度の意味があるんだ？

494:デフォルトの名無しさん
07/09/27 11:09:31
>>492
ネイティブってどういう意味で使ってるの?

495:デフォルトの名無しさん
07/09/27 11:10:25
>>494
マネージドアプリをアンマネージドアプリにする混ぜ物。

496:デフォルトの名無しさん
07/09/27 12:42:32
むしろ逆だろ
pureでやりたいなら C# で十分じゃん
C++/CLI はそれだけじゃ物足りない人向けだろ

497:デフォルトの名無しさん
07/09/27 12:50:00
WTLを忘れるな

498:デフォルトの名無しさん
07/09/27 15:31:12
数値演算をC++にさせて「何の意味がある」って言われるなら、
<funcional>すら駄目ってことになるが…

499:デフォルトの名無しさん
07/09/27 15:41:05
C#って初期バージョンで完成形だったのに
だんだん拡張されてキモクなってるよな。

500:デフォルトの名無しさん
07/09/27 16:21:17
全然

501:デフォルトの名無しさん
07/09/27 18:14:05
C#程度でキモいっつーんならC++とか使えないだろ

502:デフォルトの名無しさん
07/09/27 18:18:33
>>488
楽したいならC# + C++/CLIとかWPFとか
厳しい道を行きたいなら DirectX Graphics

503:デフォルトの名無しさん
07/09/27 20:00:15
おまえ、なんかものすごい勘違いしてない？

504:デフォルトの名無しさん
07/09/28 01:23:51
C#にある delegate の ThreadInvoke メソッドを使った
○ちスレッド処理って、同様のことは C++/CLI では
できないのかな。そもそも delegate がないから無理か。

505:デフォルトの名無しさん
07/09/28 01:25:43
ThreadInvoke じゃなかった、BeginInvoke だった。
それに、そもそも C++/CLI にも delegate はあるんだった。

506:デフォルトの名無しさん
07/09/28 01:44:23
なにを言っているんだ

507:デフォルトの名無しさん
07/09/28 06:58:38
C++/CLIではコンテナクラスライブラリとして STL.NET
なるものを使うべきなんですか？それとも .NET Framework
にはほかにも（言語独立の）コンテナが用意されていて
そちらを使うべきなんですか？

508:デフォルトの名無しさん
07/09/28 09:23:21
好きな方を使えばいい
C# で慣れてるなら .net の Collections を使えばいいし、違和感がないなら STL.NET で
いい。格納するものがネイティブだったら、既存のライブラリでもいいだろうし

509:デフォルトの名無しさん
07/09/28 21:18:24
C++/CLI では単純型の配列って初期化されるんでしょうか？
あと、配列の持つ Clone メソッドっていわゆる浅いコピー
しか作ってくれないんですよね？ハンドルを深くたどって
完全にコピーを作ってくれるようなメソッドはありませんか？
自分でディープコピーしないとだめ？

510:デフォルトの名無しさん
07/09/28 21:32:10
一般論だけどDeepCopyの仕様はクラス作成者にしか決められないんじゃないかな。

511:デフォルトの名無しさん
07/09/29 00:18:26
>509
Primitive型と値型は初期化される

512:デフォルトの名無しさん
07/09/29 09:20:50
ディープコピーのためのインターフェイスを実装していれば
自動的にディープコピーまでやってくれるなんてことは
ないんですかね。Microsoft では「簡易コピー」と「詳細コピー」
って呼んでるみたいですが、たとえば　System::Array の
Clone は簡易コピーですよね？

513:デフォルトの名無しさん
07/09/29 15:17:17
自動でディープコピーやったら、循環参照のときコピー終わらなくなっちゃうよ。

ArrayのCloneは簡易コピーだけど、
一般的にICloneableインターフェース実装が
簡易コピーでないといけないということはない。
Cloneメソッドが簡易と詳細どちらのコピーをするかは、
実装者に任せるというのが一般的じゃない？

だから、既存のコピー実装が気に入らなければ、
外部で独自のコピー方法を定義するしかないよ。

514:デフォルトの名無しさん
07/09/30 16:50:24
CEDEC2007で
3ds maxは、C++/CLI使ってるようなこと言ってた。
プラグインもC++/CLIだし

515:デフォルトの名無しさん
07/09/30 17:49:50
コンテナはC++CLIならSTL+Boostがいいのかな？

516:デフォルトの名無しさん
07/09/30 18:17:40
>>515
ネイティブなクラスのインスタンスを格納するか
マネージドなクラスのインスタンスへのハンドルを格納するかに
よるんじゃね？boost::shared_ptr で格納するなら
また話は発散する。

517:デフォルトの名無しさん
07/09/30 19:02:28
スタティックライブラリを利用しようとしたところ
（libcmtd.lib等とぶつかる系も回避しました）

DotNetTest2003_00 error LNK2020: 未解決のトークン (0A000013) exception.__ctor
DotNetTest2003_00 error LNK2020: 未解決のトークン (0A000030) exception.__dtor
DotNetTest2003_00 fatal error LNK1120: 外部参照 2 が未解決です。

って出ました。
これは何が原因なのでしょうか？

518:デフォルトの名無しさん
07/09/30 19:52:08
>517
それは C++/CLI なの？

519:デフォルトの名無しさん
07/09/30 23:09:35
プロジェクトは、C++/CLIです。
stdafx.hに
#include <windows.h>
#pragma comment(lib, "user32.lib")
書いてます

ライブラリのほうは、C++/CLIじゃありません

520:デフォルトの名無しさん
07/09/30 23:37:16
>>519
ライブラリは　/MDでコンパイルしてます？

521:デフォルトの名無しさん
07/09/30 23:42:45
　　　　～～～～
　　／　　　　　　　　ヽ
　/　　　＞~~~~~~~~/
　|　　∠　＼　／ |
｜　√　　⌒　 <⌒ |　　　／￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　(6 ≡　　　　　＼｜　　|　　やる前から負けることを
　　 ≡　 ┌ ＿＿「｜　＜
　　　＼　　＼＿( ｜　　　|　　考えるﾊﾞｶがいるかｺﾉﾔﾛｰ！
　　　　＼　　　ー｜　　　|
　　　　　　＼＿＿＿|　　　＼＿＿＿＿＿＿＿＿＿＿＿＿＿

522:デフォルトの名無しさん
07/09/30 23:44:19
誤爆ｽﾝﾏｿ

523:デフォルトの名無しさん
07/10/01 12:13:11
ネイティブコード吐かないんなら、C++使う意味無くない？

524:デフォルトの名無しさん
07/10/01 12:15:21
無くない

525:デフォルトの名無しさん
07/10/01 13:00:02
ドトネトにはｲﾐﾅｲ

526:デフォルトの名無しさん
07/10/01 17:40:21
>>520
おおおお
いけました。
ありがとうございます。
ありがとうございます。
ありがとうございます。

527:デフォルトの名無しさん
07/10/01 18:04:15
修行するぞ。
修行するぞ。
修行するぞ。

528:デフォルトの名無しさん
07/10/01 18:17:04
C++なのに遅いとか泣けるよな・・・
いや、C++/CLIをC++に含めるのは問題だと、ISOにバッサリ斬られたけど。

529:デフォルトの名無しさん
07/10/01 18:22:30
ISOがﾀﾀﾞｼｲ

530:デフォルトの名無しさん
07/10/01 19:11:49
C※にでもすればいいのに。

531:デフォルトの名無しさん
07/10/01 20:59:18
左を向けば変態的な/CLI
右を向けば変態的な0x
振り返っても変態的なC++

532:デフォルトの名無しさん
07/10/01 21:01:04
>531
ウホッ！　最高だな（ｗ

533:デフォルトの名無しさん
07/10/02 16:13:50
変態の俺にピッタリだ。

534:デフォルトの名無しさん
07/10/02 16:31:05
おまいら、まだまだ子供だな。俺を満足させたかったら、MixedType を持ってこい
CLI もネイティブも多重継承してやるぜ

535:デフォルトの名無しさん
07/10/02 17:49:09
MixedType ってなに？
boost::any とか？
boost::optional とか？

536:デフォルトの名無しさん
07/10/02 18:13:20
混合型

ネイティブクラスがマネージ型のメンバを持ったり、
マネージクラスがネイティブクラスから派生したりするなど。

537:デフォルトの名無しさん
07/10/02 18:26:01
そうだ、Ｍ＄がマネージドをネイティブに書き換えれば準備完了！

538:デフォルトの名無しさん
07/10/03 20:17:09
C++/CLI でも当然純粋仮想関数って認められているはずだよね？
ネイティブのライブラリの中で、純粋仮想関数を持つ
クラス X があるんだけど、そのライブラリを /clr なアプリから
リンクすると X のインスタンスなんて一切生成しようと
していないにもかかわらずリンカに怒られるんだよ。
なんでだろう。わかる人いる？

539:デフォルトの名無しさん
07/10/03 20:30:52
人に聞くときゃ、エラーを出せよ

540:538
07/10/03 20:47:24
ごめん、C++/CLI とか全然関係なかった。
よく考えたらコンストラクタの中で巡り巡って
純粋仮想関数が呼び出されているところがあった。

コンストラクタの中で仮想関数を呼ぶようなコードは
実際には仮想関数テーブルを見に行くようなバイナリが
生成されるわけじゃなくて静的に解決された _thiscall
を呼びに行くバイナリが生成されるわけだけど、
純粋仮想関数だとそれは定義されてないから
リンカに怒られているだけだった。

541:デフォルトの名無しさん
07/10/03 22:05:05
そういうのは Init みたいな初期化関数を使うってのが C++ の定石だけど、
ちょっとカッコ悪いよね。

542:デフォルトの名無しさん
07/10/04 18:59:17
うんかっこわるい
Initialize()でないと

543:デフォルトの名無しさん
07/10/05 13:18:06
C++/CLIって検索に引っ掛けにくいキーワードなので、
もっと、こう、いい名前を考えてやらないか？
記号を含まずに検索エンジンでインデックス化しやすく、
かつ独創的で他の言語とは差別化できそうな名前。
しかも人間にとっても発音しやすい名前。

俺は卑猥な名前しか思いつかない。

544:デフォルトの名無しさん
07/10/05 14:28:39
C++xCLI とか CLI++ とか？

545:デフォルトの名無しさん
07/10/05 15:08:34
C#ってのはどうだろ?

546:デフォルトの名無しさん
07/10/05 15:19:30
>545
巣に（・∀・）ｶｴﾚ!!

547:デフォルトの名無しさん
07/10/05 15:37:04
VBってのはどうだろ?

548:デフォルトの名無しさん
07/10/05 15:44:20
VB から生まれしもの、元いたDLL地獄へ（・∀・）ｶｴﾚ!!

549:デフォルトの名無しさん
07/10/05 15:55:36
普通に検索できないか？

550:デフォルトの名無しさん
07/10/05 16:55:58
Googleでは C++/CLI で一単語として認識しているみたいだね。
Googleって形態素解析してないと思ったたんだけど、
いつの間にかリッチな辞書使ってるんだなぁ。

551:デフォルトの名無しさん
07/10/05 18:39:54
昔はC#とかも検索できんかったけどな

552:デフォルトの名無しさん
07/10/07 13:27:43
GCは構文のシンメトリーが崩れるから糞

553:デフォルトの名無しさん
07/10/07 13:31:57
明示的にdeleteすればおｋ

554:デフォルトの名無しさん
07/10/07 23:08:41
>>552
爆破すれ

555:デフォルトの名無しさん
07/10/08 02:30:34
>>554
ECMAに通報しました(･∀･)

556:デフォルトの名無しさん
07/10/08 07:26:39
コナンか

557:デフォルトの名無しさん
07/10/08 07:45:17
C++/CLIより懐の広い言語って
存在するの？

558:デフォルトの名無しさん
07/10/08 10:43:31
D言語

559:デフォルトの名無しさん
07/10/08 11:16:37
>>558
多重継承ができないじゃん。

560:デフォルトの名無しさん
07/10/09 13:57:19
多重継承いらないし。

561:デフォルトの名無しさん
07/10/09 14:08:14
>>560 もっと広い心を持てよ。

562:デフォルトの名無しさん
07/10/10 07:33:54
Mixinは素晴らしい世界

563:デフォルトの名無しさん
07/10/10 10:38:20
しかし、未だにデザイン以降の仕様の影すらみえない罠

564:デフォルトの名無しさん
07/10/10 16:33:13
VC2005さんに
/clr:pure または /clr:safe と共にコンパイルされた関数に対する呼び出し規約 '__stdcall' が無効です
言われた。
仲直りするにはどうしたらいいですか？
stdcallは譲れない

565:デフォルトの名無しさん
07/10/10 17:01:07
pure safeを諦める

566:デフォルトの名無しさん
07/10/10 17:36:17
＞pure safe

これって、価値ある？

567:デフォルトの名無しさん
07/10/10 19:05:03
C#やVB.NET並みには

568:デフォルトの名無しさん
07/10/11 02:43:15
/clr
に変更したら、
d3d9.lib系エラーが出まくったった
1>d3dx9.lib(cfont.obj) : error LNK2019: 未解決の外部シンボル __imp__GetGlyphOutlineA@28 が関数 "private: int __thiscall D3DXCore::CFont::ValidGlyph(unsigned int)" (?ValidGlyph@CFont@D3DXCore@@AAEHI@Z) で参照されました。
1>d3dx9.lib(cfont.obj) : error LNK2019: 未解決の外部シンボル __imp__DeleteDC@4 が関数 "public: __thiscall D3DXCore::CFont::~CFont(void)" (??1CFont@D3DXCore@@QAE@XZ) で参照されました。
...

/clr:pure
で
STDMETHOD
は、使えないんですか？

569:デフォルトの名無しさん
07/10/11 10:09:14
pure は .net Framework 専用だろ
/clr をつけたら、必要なライブラリは明示的に追加しろや
それか MDX か XNA でも使うんだな

570:デフォルトの名無しさん
07/10/11 18:22:36
>>568
手順4だけでいいからやれ。
URLﾘﾝｸ(www.microsoft.com)

571:デフォルトの名無しさん
07/10/11 22:06:35
生成元のクラスから生成したクラスに、自クラスのメソッドを渡し、
生成したクラスから生成元のクラスへコールバックしたいと思ってます。
AsyncDeligateを使えばいいのかと思うんですが、
この関数って実は、自クラス内のメソッドのコールバックにしか使えないの
でしょうか？

ref class MyClass{

void Method{
AsyncDeligate^ asyncDeligate = gcnew(this, &MyClass::Func);

}
void Func(IAsyncResult ar)
{
}
};
と自クラスでAsyncDeligateは使えそうだけど、生成したクラス→生成元
クラスへのコールバックを実現するために、生成元のクラスで、どのように
関数を渡したらいいのか(AsyncDeligateをどのように使うのか？)が
不明です。
そもそもAsyncDeligateでこれを実現することはできるのでしょうか？

572:デフォルトの名無しさん
07/10/11 22:23:12
自クラスのインスタンス生成時に親クラスの参照渡しとけばいいんじゃないの？

573:571
07/10/11 22:31:31
自クラス→生成するインスタンス
親クラス→生成元インスタンスってことですか？
生成するクラスをDestClassとすると
DestClass destClass(this);
みたいなことでしょうか？

次ページ