トップページ⇒tech
1001コメント304KB

【.NET】 C++/CLI について語ろうぜ 【最適】

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん2005/09/11(日) 23:54:01
おそらく、.NET開発でデファクトスタンダードに最も近い
であろうC++/CLIについて語ろうぜ！
06536482006/02/19(日) 21:44:16
>>649
Byte を cli::array<Byte> にしたところ、できました。

cli::array<Byte> ^ myDataBuffer = wc->DownloadData("http://www.yahoo.co.jp/");
Encoding^ enc = Encoding::GetEncoding("euc-jp");
String^ out = enc->GetString(myDataBuffer);

ばっちりです。これで先に進めます。

つい最近まで C++ Builder 使いだったので、いろいろと戸惑ってます。
ポインタは使えず、^ というものが必要だとわかるまで、延べ1日くらいかかってます。
勉強がてら少しずつ移植していきます。

どうもありがとうございました。
0654Pascal2006/02/19(日) 23:09:23
>>650
呼んだ?
0655デフォルトの名無しさん2006/02/20(月) 00:22:49
>>650
あなたの心が汚れてるからですよ(^^;;;
0656デフォルトの名無しさん2006/02/20(月) 00:30:26
そんなばかな^^;
0657デフォルトの名無しさん2006/02/20(月) 01:26:15
>>650-652
ヤベ、ツボにはまったｗ
0658デフォルトの名無しさん2006/02/21(火) 10:07:18
>>422-423
＞ダイレクトに C++ を知らずに、C++/CLI に手を出すのは、止めた方がいいだろ
＞さっさとC#かVBで始めたほうがいいと思う。

とりあえずＣ＃で始めようと思った矢先、C++/CLI とかいうのが目に入って、
「ファイナライザいいな」とか思ってしまったんですが、
やっぱりＣ＃から始めることにします。

>>424
関数単位ですか。
つまり、関数呼び出しを共通化することで様々な実行環境にあるコードを一つのプログラムにまとめることができたと言うことでしょうかね。
0659デフォルトの名無しさん2006/02/21(火) 11:10:22
>>658
ああ、C#にしたのか。まぁそうしとけ。C++/CLIはネイティブの知識(C++)とCLRの
知識(C#)が両方要求されるひどい言語だ。最低限どっちかぐらい自由に使える
ようになってからおいで。…両方自由に使えるぐらいじゃないと使える言語でも
ないかもしれないが。

ファイナライザ？C#にもあるぞ。というかCLR用語だそれ。
まぁDisposeがスタックオブジェクトのように書けることをいいたかったんだろうけど。
川俣とかが取り上げているほど、たいしたものじゃない。あの人は大げさに書く文体
が売りだからな。いい悪いは別にして。
0660デフォルトの名無しさん2006/02/21(火) 21:17:52
通のお勧めは関数のオーバーライド
ディスポーズ・パターンの変形に目が眩んでちゃ、まだまだ
0661デフォルトの名無しさん2006/02/21(火) 21:25:46
>>660 ポリモにならんじゃん
0662デフォルトの名無しさん2006/02/21(火) 21:32:20
>>658
~hogeか!hogeが使われている場合に下のようなコードを自動生成してくれる。
GC.SuppressFinalize(this)がむき出しにならないだけスマートだね。VB.NETにもほしい機能だと思う。
void Dispose(bool disposing) { if (disposing) ~hoge(); else !hoge() }
void Dispose() { Dispose(true); GC::SuppressFinalize(this); };
void Finalize() { Dispose(false); }
deleteしたり { ClassA a(); ...; } でスコープから離れた場合は
Dispose()が呼び出されるだけでその場でGCされるわけではない。
0663デフォルトの名無しさん2006/02/22(水) 00:50:01
!hogeなんてあったんだ
0664デフォルトの名無しさん2006/02/22(水) 07:21:27
>>662
いや、えーと、このスレにいる以上知っている。
ildasmでも確認したしな。ああ、そうか、それをC++/CLI用語でFinalizerというのか。
0665デフォルトの名無しさん2006/02/22(水) 12:42:51
>661
おまいはC++/CLIにおける関数上書きの奥の深さに気付いていない

ここに IEnumerable を継承したインターフェイス IEA と IEB がある
その双方を実装した ref クラス RAB は明示的オーバーライドによって列挙の方式を
IEA と IEB によって変更できる
つまり、RAB から取得したインターフェイスによって、for each のオーダーを自由に
選択できるわけだ
0666デフォルトの名無しさん2006/02/22(水) 16:05:53
MSがC++/CLIを捨てるのは何年後くらいですか？
0667デフォルトの名無しさん2006/02/22(水) 16:13:12
MFCの如くこの劣悪貧を１０年使うかも。
C++ってだけでもSTLやBoostが混ざってくると複雑なのに、正直CLIはカンベンて感じだおね。
0668デフォルトの名無しさん2006/02/22(水) 17:22:04
>>667
駄菓子菓子、これがないとネイティブとかからCLRが非常に使いにくい。
ほら、次でWPFとかなんかたくさんあるし。
0669デフォルトの名無しさん2006/02/22(水) 23:36:01
マイクロソフトがもうｲﾗﾈと思ったら容赦なく捨てにくるさ。
0670デフォルトの名無しさん2006/02/23(木) 02:00:23
>>669

そりゃ日本だけ。海外ではVBerが反乱おこして、msも今では Love VB, Love C#だとよ。
0671デフォルトの名無しさん2006/02/23(木) 02:53:32
C#は、VC++とVBの中間を行くような言語だから、
どっちからも反発が強いだろうね。
0672デフォルトの名無しさん2006/02/23(木) 03:03:54
反発はしないけど、C++で出来るなら C++ Nativeでやっちゃうよ。
必要なとこだけ CLIで .Netなんてライブラリ感覚で使えばいい。
0673デフォルトの名無しさん2006/02/23(木) 03:20:44
/clrでNativeコンパイルすると遅くなる？

0674デフォルトの名無しさん2006/02/23(木) 08:50:40
>673
>348
0675デフォルトの名無しさん2006/02/23(木) 09:37:51
>>669
要るだろ。

だって、C++市場をCLIで混乱させることにより、
開発者をWin＠ﾌﾞﾋﾞ or Win＠Ｃ丼で留めておける。
0676デフォルトの名無しさん2006/02/23(木) 10:00:24
>>674

遅くなるのは事実としても、何で遅くなるんだろ?
異なるライブラリがリンクされるからか?　lstrcmp自体の実装が異なるのか?

それとも呼び出し時にスタックチェックでも入ってるのかね…。
0677デフォルトの名無しさん2006/02/23(木) 14:21:46
>676
単純なループでは簡単に結論が出ない問題かもしれない
ちなみに漏れの環境では
CLR 6 - 7 sec.
Native 8 sec.
となった。意外だがCLRの方が早い
Win のほうは -02 -0t を付けた状態で、CLRの方はデフォルトのリリースモジュールだ
0678 2006/02/23(木) 22:30:11
>>670
そんな話しきいたことネ
0679デフォルトの名無しさん2006/02/23(木) 22:47:11
誰か、C++/CLI で吐いた実行ファイル、
mono で動かした奴いる？？

以前 VS.NET 2003 の C# で書いたコンソールアプリなら
mono で動かしたことあるんだけど。
0680デフォルトの名無しさん2006/02/23(木) 23:22:55
mono がそもそも .net framework 2.0 に対応してたか？
してるなら、/clr:pure で動くだろう
0681デフォルトの名無しさん2006/02/24(金) 08:17:28
nullptr
0682デフォルトの名無しさん2006/02/24(金) 11:48:08
ｶﾞｯ^
0683デフォルトの名無しさん2006/02/24(金) 17:24:15
>>678

http://blogs.msdn.com/hiroyask/archive/2006/02/13/530769.aspx

ケツの穴が広がるぐらい、ハードに読めや。
0684デフォルトの名無しさん2006/02/24(金) 21:07:35
>>683
良く読んだよ

>表の顔の日記　

> 裏の顔の日記
> さっさと消えてくんないかな。 うざいんだけど、 まじで。
0685デフォルトの名無しさん2006/02/25(土) 04:29:20
という電波でも飛んでるのか?
06866482006/02/25(土) 11:39:03
また教えてください。

C++での構造体の以下の宣言
typedef struct tagHOGE{
　　int x;
　　long y[4];
}HOGE;

これをマネージ環境にしようとした場合
typedef struct tagHOGE{
　　int x;
　　long y[4];　← ここが混合型らしい
}HOGE;

.\MainForm.cpp(26) : error C4368: 'y' をマネージ 'HOGE' のメンバとして定義できません。混合型はサポートされていません

というエラーが出ます。
単に4つのlong型の配列の定義がしたいのですが、マネージ環境では、どのようなやり方があるでしょうか?
0687デフォルトの名無しさん2006/02/25(土) 11:43:26
typedef struct → typedef value struct
では？
06886482006/02/25(土) 12:05:23
>>687
そうです。コピペ間違いました。

value struct HOGE{
　　int x;
　　int y[4];
};

と記述してます。
0689デフォルトの名無しさん2006/02/25(土) 12:17:18
・・・value型使わず、ネイティブ型で定義すれば？
0690デフォルトの名無しさん2006/02/25(土) 12:20:37
あとは ref にして array<long>^ y で宣言して、コンストラクタで初期化するか
0691デフォルトの名無しさん2006/02/25(土) 12:23:04
value struct HOGE
{
　　int x;
　　array<long>^ y;
};
はコンパイルが通るが、仕様上これでいいのか？
0692デフォルトの名無しさん2006/02/25(土) 12:38:17
ok
ハンドルは nullptr で初期化される
06936482006/02/25(土) 12:58:50
皆さん、早速のレス、ありがとうございます。

>>689

ネイティブで定義すればできることは確認してます。
ただそうすると少し複雑なソフトを組んだ場合、きちんとメモリの後処理をしないと
メモリリークが発生するので、マネージにすればメモリガベージの効用であまり複雑に
考えなくともよいかな、と思っているのです。

>>691

そのやり方もわかります。

各関数で、
void func1(void)
{
　　HOGE wk1;
　　wk2.y[2] = 123;
}

void func2(void)
{
　　HOGE wk2;
　　wk2.y[2] = 456;
}

というようなことをしたいのです。

2〜3日あがいてみて自分ではできなそうだったら、ネイティブで定義してやっていきます。
マネージ環境に慣れていけば、そのうち、何か気づきがあると信じて進むしかありません。
0694デフォルトの名無しさん2006/02/25(土) 13:05:44
2〜3日あがくなら2〜3日かけてマニュアル読んだほうがいいような気がする
0695デフォルトの名無しさん2006/02/25(土) 13:45:46
>>693
値型にGCを求める必要がある？
0696デフォルトの名無しさん2006/02/25(土) 14:23:50
C++/CLIのスレ見てると無意味にvalueを使いたがる人が多い気がするな。
valueは動作に癖があるから基本refで作ったほうがいいと思う。
0697デフォルトの名無しさん2006/02/25(土) 16:22:08
value使ったほうが処理速度が速いとでも思い込んでいるんじゃ？
クセがあるには同意。
06986482006/02/25(土) 17:38:04
いろいろとサイトをまわりまして、以下のようにしたところ動いているように見えます。
public ref struct HOGE {
　　int x;
　　array<long>^ y;
　　HOGE() {
　　　　y = gcnew array<long>(4);
　　}
};

void func(void)
{
　　HOGE^ abc = gcnew HOGE;
　　abc->x = 10;
　　abc->y[2] = 20;
　　for(int i=0; i<4; i++){
　　　　Debug::WriteLine(abc->y[i]);
　　}
}

検討違いのコードでなければよいですが。

みなさん、いろいろとレスありがとう。
0699デフォルトの名無しさん2006/02/25(土) 20:55:45
>>698
これでも平気。
void func()
{
    HOGE abc;
    abc.x = 10;
    abc.y[2] = 20;
    for (int i = 0; i < 4; i++) {
        Debug::WriteLine(abc->y[i]);
    }
}
0700デフォルトの名無しさん2006/02/25(土) 22:33:45
C++は真のローカル変数を使える言語なんだから、（ユーザー定義オブジェクト
がスタック上に配置できる）GCが必要な場合ってのはそんなに多くはならない
ってビョーン先生が言ってた。
0701デフォルトの名無しさん2006/02/25(土) 23:11:17
>>700
それはわかるけれど、C++/CLIはCLIの世界にあわせないといけないからさ。
0702デフォルトの名無しさん2006/02/25(土) 23:42:48
C++/CLIは二つの言語が同居しているようなものだからな。
C++の拡張というより建て増し。
0703デフォルトの名無しさん2006/02/25(土) 23:49:05
>699
それだと、配列のサイズが3で固定されちゃわない？
0704デフォルトの名無しさん2006/02/26(日) 00:22:20
>>702
二世帯住宅
0705デフォルトの名無しさん2006/02/26(日) 00:49:18
ビョーン先生が取り扱っている案件はそうかもしれんけどな。
動的にオブジェクトが増えたり減ったりする案件のほうが多い。
0706デフォルトの名無しさん2006/02/26(日) 00:56:47
>>700
しかしビョーン先生はGCをそんなに否定していない。
既存のC/C++のコードと互換性を保ったまま導入できるのなら、
C++に入れてもいいというようなことをD&Eで書いている。
0707デフォルトの名無しさん2006/02/26(日) 20:57:17
>>705
vector使えばええやん。メンバかローカルにしておけばdeleteいらん。
0708デフォルトの名無しさん2006/02/26(日) 21:08:56
>>707
グローバルでもdeleteいらんぞ
0709デフォルトの名無しさん2006/02/26(日) 21:14:38
別に GC なんて C++/CLI の利点じゃないだろ
単に .net framework を既存の C++ と混同することなく使えるってとこが一番重要さ

C++/Smalltalk とか C++/Squeak とか出てこないかな
0710デフォルトの名無しさん2006/02/27(月) 01:56:21
【初心者歓迎】C/C++室 Ver.25【環境依存OK】から誘導されてきました( ｀・ω・´)ﾉﾖﾛｼｸｰ
VC8でopenFileDialogを使いたくて
MSDNのソースを試してみようと
ttp://msdn2.microsoft.com/ja-jp/library/system.windows.forms.openfiledialog.aspx
説明を読み
フォームに Button を配置して
using namespace System;を宣言して、
下記のコードを試したのですがエラーが出ます、何か読み込んでいないファイルがあるか設定のミスだと思うのですが、原因が分かりませんよろしくお願いします。
private:
　　voidbutton1_Click(Object^/*sender*/,System::EventArgs^/*e*/)
　　{
　　　　Stream^myStream;
　　　　OpenFileDialog^openFileDialog1=gcnewOpenFileDialog;

　　　　openFileDialog1->InitialDirectory="c:\\";
　　　　openFileDialog1->Filter="txtfiles(*.txt)|*.txt|Allfiles(*.*)|*.*";
　　　　openFileDialog1->FilterIndex=2;
　　　　openFileDialog1->RestoreDirectory=true;

　　　　if(openFileDialog1->ShowDialog()==::DialogResult::OK)
　　　　{
　　　　　　if((myStream=openFileDialog1->OpenFile())!=nullptr)
　　　　　　{
　　　　　　　　//Insertcodetoreadthestreamhere.
　　　　　　　　myStream->Close();
　　　　　　}
　　　　}
　　}
error C3083: 'DialogResult': '::' の左側のシンボルには、型を指定しなければなりません
error C2039: 'OK' : '`global namespace'' のメンバではありません。
error C2065: 'OK' : 定義されていない識別子です。
0711デフォルトの名無しさん2006/02/27(月) 07:06:19
>>710
System::Windows::Forms::DialogResult::OK とフルで書く。
0712デフォルトの名無しさん2006/02/27(月) 07:26:28
>>711
最後まで仕様が揺れた所かも知れないね。
0713デフォルトの名無しさん2006/02/27(月) 10:47:00
この状況って System::Windows::Forms まで using で指定しているから、単純にグローバル
スコープ指定していることが問題なんじゃね？
12行目の ::DialogResult を意味なく、:: で始めるな、と
0714デフォルトの名無しさん2006/02/27(月) 11:06:47
>>713
ところがどっこい
DialogResult::OK　と書くと今度は
System::Windows::Forms::Form::DialogResultが無いというエラーになる。
using namespace は探しに行ってくれないらしい。
0715デフォルトの名無しさん2006/02/27(月) 11:38:26
ん、サンプルだと :: で始めてるな
っていうか、>710 って名前空間 System しか宣言してないって言ってるが
using namespace System::Windows::Forms が宣言されている環境では
::DialogResult::OK でエラーなくコンパイルできるな

先頭 :: の名前検索ルールって、グローバル指定じゃないんだ・・・
0716デフォルトの名無しさん2006/02/27(月) 13:38:23
>>714
using namespace System::Windows::Forms;
してあるということ? その"Form"は何よ?

>>715
namespace N { int x; };
using namespace N;
int x;
int f(void) { return x; } ←このxはambiguousになる。それで正しい。
07177152006/02/27(月) 13:45:08
まず、 >710 の問題は、単に System::Windows::Forms が using 指定していないから
using namespace System::Windows::Form;
を付ければおっけー

>716
::DialogResult ってなっているから、先頭に :: を付ける場合ってグローバル名前空間の
名前空間指定だと思ってた。カレント解決してくれるんだ
07187162006/02/27(月) 13:55:54
>>717
いや、「正しい」はグローバル参照の方。

> using namespace System::Windows::Form;
> を付ければおっけー

Forms
07197152006/02/27(月) 18:46:14
ということは、MSの実装はバグかMS独自仕様か、微妙なとこだな
07207102006/02/27(月) 19:46:54
皆さんどうもありがとう、遅くなってすみません
今帰宅しました

ヘッダー部分ですが
#pragma once
#include <fstream>
#include <vcclr.h>
#include <stdlib.h>

namespace hoge {

using namespace System;
using namespace System::IO;
using namespace System::ComponentModel;
using namespace System::Collections;
using namespace System::Windows::Forms;
using namespace System::Data;
using namespace System::Drawing;
using namespace std;
と宣言しているのですが
皆さんの、ご指導通りやってみましたが、

error C3083: 'DialogResult': '::' の左側のシンボルには、型を指定しなければなりません
error C2039: 'OK' : '`global namespace'' のメンバではありません。
error C2065: 'OK' : 定義されていない識別子です。
.\hoge(8) : error C2337: 'STAThreadAttribute' : 属性が見つかりません。
とこんな感じで、
ﾜｹ 川・∀・川 ﾜｶﾒです
0721デフォルトの名無しさん2006/02/27(月) 20:17:53
>>720
その一
using namespace ...
using namespace ...
namespace hoge {
と順番を変えたら ::DialogResult::OK でコンパイルが通る。

その二
hoge::DialogResult::OK　 でコンパイルが通る。
恐らく下のも通るはず。
[hoge::STAThreadAttribute]

その三
namespace hoge {　を使わずすべてGlobalに書く

これが仕様なのかバグなのかは俺にもわかんね〜
0722デフォルトの名無しさん2006/02/27(月) 20:17:53
気になって少々試してみたが、関数内でusingすればDialogResult::OKと書いてもエラーにならなかった。
void button1_Click(System::Object^ sender, System::EventArgs^ e)
{
    using ::System::Windows::Forms::DialogResult;

    OpenFileDialog ofd;
    ofd.InitialDirectory = "c:\\";
    ofd.Filter = "txtfiles(*.txt)|*.txt|Allfiles(*.*)|*.*";
    ofd.FilterIndex = 2;
    ofd.RestoreDirectory = true;

    if (ofd.ShowDialog() == DialogResult::OK)
0723デフォルトの名無しさん2006/02/27(月) 20:39:09
ほとんど素のC++の話題になってるけど、まあいいか。
なんでDialogResultが重なってんだろ?

using ::System::Windows::Forms::DialogResult;
if (ofd.ShowDialog() == OK)
か
using ::System::Windows::Forms;
if (ofd.ShowDialog() == DialogResult::OK)
ならわかるけど。
0724デフォルトの名無しさん2006/02/27(月) 20:45:59
>>723
C++/CLIの列挙子は列挙型の中のスコープにある。
0725デフォルトの名無しさん2006/02/27(月) 23:10:50
>>721
*.h でこれをやると　using が include 先に伝播してしまうので思わぬ名前の重複が起きてしまう。
＞using namespace ... 
＞using namespace ... 
＞namespace hoge { 

妥協案としては、メンバー関数の実態を *.c に分離してから::DialogResult::OKと指定する。
using namespace hoge;
namespace hoge {
   void hoge::button1_Click(System::Object^ sender, System::EventArgs^ e) 
{ 
    if (ofd.ShowDialog() == ::DialogResult::OK) 
0726デフォルトの名無しさん2006/02/28(火) 00:29:25
ISO C++だとusingディレクティブは名前を可視にするだけで、
usingディレクティブが書かれた名前空間へ名前を持ってくるものではなかったはず。

namespace foo {int x;}
namespace bar {int y;}

using namespace foo;
using bar::y;

::x = 10; //NG. x = 0;或いはfoo::x = 0;としなければならない。
::y = 20; //OK. もちろんy = 0;或いはfoo::y = 0;も問題ない。
0727デフォルトの名無しさん2006/02/28(火) 00:59:11
namespace N { namespace M { enum E { zero = 0 }; }; };
using namespace N;
int f(void) { return M::zero; }
あるいは、
namespace N { namespace M { enum E { zero = 0 }; }; };
using namespace N::M;
int f(void) { return zero; }
なんじゃないのか?
// Eのenum名指定なしでanonymous enumにしても同じ。
0728デフォルトの名無しさん2006/02/28(火) 01:38:12
>>727
CLRタイプのenum class と Cタイプのenumの２種類あって、
後者の話ならそのとおり。
07297102006/02/28(火) 21:38:39
皆さんのおかげで、openFileDialogを動かす事ができたのですが
肝心な事を忘れていました、ファイルを選択してボタンを押しても
実際にファイルが開かないんですよね（；^ω^）
// Insert code to read the stream here.
ってコメントアウトしてある部分が気になるけど、ここに何か
書かないといけないのかな？
0730デフォルトの名無しさん2006/02/28(火) 21:43:05
教えてクンマンセー！
0731デフォルトの名無しさん2006/02/28(火) 21:53:32
コメントが何のために有るのかわかってるのか？
っていうか読めよ。
07327102006/02/28(火) 21:54:54
>>731
英語読めません(´･ω･`)
0733デフォルトの名無しさん2006/02/28(火) 21:57:00
>>732
んじゃ、英語の勉強から。英語書けないならともかく、読めないんじゃ
プログラミングなんてやってられない。
0734デフォルトの名無しさん2006/02/28(火) 22:35:55
翻訳サイトも使えないようなヤツはプログラミングやめれ
0735デフォルトの名無しさん2006/02/28(火) 22:40:27
ていうか、732は710の偽なんですが
07367322006/03/01(水) 00:45:52
俺は嘘つきだから俺の言うことは嘘ばっかりさ。さてこの嘘はホントかわかるかねｗｗｗ
0737デフォルトの名無しさん2006/03/01(水) 01:08:24
そんなおもしろくないよ?
0738デフォルトの名無しさん2006/03/01(水) 01:32:16
>>733
ひまわりが専門なので関係ないでしょ
07397102006/03/01(水) 02:21:51
ﾟ･*:.｡..｡.:*･゜ヽ( ´∀｀)人(´∀｀ )ノ･゜ﾟ･*:.｡..｡.:*
できたYO!
英語のサイトで(・∀・)ｲｲ!!ヒント見つけて
多少漏れのセンスでアレンジしましたがなにか
つーかさー"StreamReader c++ textBox"で具具っても
C#のサンプルや話題が多くて、参考にならなかったんで
英語でぐぐったら
ｷﾀｷﾀｷﾀｷﾀ━━━(ﾟ∀ﾟ≡(ﾟ∀ﾟ≡ﾟ∀ﾟ)≡ﾟ∀ﾟ)━━━━!!
やっぱり本場はいいサンプルが多いな、でもそのものズバリはなかったが
{
// Insert code to read the stream here.
System::IO::StreamReader ^ sr = gcnew
System::IO::StreamReader(openFileDialog1->FileName);
String ^temp = sr->ReadToEnd();
textBox2->Text=temp;

//MessageBox::Show(sr->ReadToEnd());
sr->Close();
myStream->Close();
}
0740デフォルトの名無しさん2006/03/01(水) 02:32:10
C++/CLI の場合でも .NET Framework のサンプルがほしければ
C#やVBのをそのまま使えるってのに
07417102006/03/01(水) 02:37:58
|∀・).｡oO(・・・)
そうなのか？
0742デフォルトの名無しさん2006/03/01(水) 02:38:23
ｶﾞﾝｶﾞﾚ
07437102006/03/01(水) 02:43:27
ﾑﾘｯﾎﾟ
0744デフォルトの名無しさん2006/03/01(水) 07:19:26
>>740 うむ。
ちょっと間接参照の記述が違うくらいで、
流れは C# のコードのままでいいな。
まぁそれが C++/CLI の真骨頂でもある。
0745デフォルトの名無しさん2006/03/01(水) 14:15:46
>>739
C++/CLIなんだからいちいちgcnewする必要はないと思う。
0746デフォルトの名無しさん2006/03/01(水) 14:50:01
>>739
つかCloseもfinally句に書いてないし。
C#ならusing、C++/CLIならスタックオブジェクトにしろよなほんと。
0747デフォルトの名無しさん2006/03/01(水) 16:30:41
で、STLはどうしてるんだ、おまえら?
0748デフォルトの名無しさん2006/03/01(水) 16:49:26
C++/CLI でGUIなアプリつくるべ、と、フォームをデザインして
遊んでます。で、みなさん、アプリで必要となる大量の
変数たちは、class Form1 のメンバとしてずらずら宣言してしまって
構わないんでしょうか？

今までは UNIX 系でのコンソールアプリ主体で、自前の
アプリケーションクラスを用意して main() の中から
そいつをインスタンス化して、という感じでやってました。

Windows でのグラフィカルなアプリでの作法では、
自動生成された class Form1 にどんどんメンバを
追加しちゃっていいんですか？

当然イベントハンドラなどはデザイナで追加されていくわけで、
手動で追加したメンバのためにフォームデザイナが混乱して
しまわないかすごく不安です。
0749デフォルトの名無しさん2006/03/01(水) 16:54:58
STLが無い、C++なんて。

クソ。
0750デフォルトの名無しさん2006/03/01(水) 16:57:44
>>749 え？C++/CLI で STL つかえないの？
0751デフォルトの名無しさん2006/03/01(水) 17:06:05
>>750
ネイティブ型に対しては使える。

そしてマネージ型対応のSTL/CLI(旧称STL.Net）がVC++ 2005と同時に公開されるはずだったのだが、
伸びに伸びて未だ公開されていない。

http://www.microsoft.com/japan/msdn/vs05/visualc/stl-netprimer.asp

いっそのこと俺たちで作るかｗ。
0752デフォルトの名無しさん2006/03/01(水) 17:18:06
>>751 あ〜びっくりした。
そうだよな、ネイティブ型に対しては使えるよな？

C++ で書きためてきた std::vector 使ってる
数値計算用のライブラリがあって、どうしても
それから逃れられない + DirectX で可視化したい、
という要求があって、それ満たすには C++/CLI しか
ないだろ、ってことでこれから使おうと思ってたんで、
ちょっと焦った。
■ このスレッドは過去ログ倉庫に格納されています