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

【.NET】 C++/CLI に� ..

548:デフォルトの名無しさん
06/02/06 20:55:37
でも、サービスパックも出てない VisualStudioを使うほどバカじゃなし。
MS製以外でコンパイル通るヤツってある?

549:デフォルトの名無しさん
06/02/06 23:39:31
>>548
無いよ。バカ

550:デフォルトの名無しさん
06/02/07 00:04:25
バカじゃん

551:デフォルトの名無しさん
06/02/07 01:01:12
おまえら、VS2005マジで使うの?　バカじゃん。
すでに、MSはSP出荷を確約してるんだぞ。

552:デフォルトの名無しさん
06/02/07 01:44:04
>>551
じーっと枯れるのまってろこのうすらタコ！

553:デフォルトの名無しさん
06/02/07 02:14:49
>>548
VB6でも使っとけよ wwww

554:デフォルトの名無しさん
06/02/07 02:41:12
>>552
N88　BASIC

555:デフォルトの名無しさん
06/02/07 10:21:32
バカが3匹。

556:デフォルトの名無しさん
06/02/07 10:51:33
Win32コンソールアプリケーションの

int _tmain(int argc, _TCHAR* argv[])
は
int main(int argc, char* argv[])
にしちゃいますけど。いいですよね？引数がアルファとかヌメリックなら。

557:デフォルトの名無しさん
06/02/07 11:32:34
漏れは
int main(const int argc, const char* const argv[])

558:デフォルトの名無しさん
06/02/07 13:00:33
>>557
そこまでいくなら戻り値もconstにしてはどうか？

559:デフォルトの名無しさん
06/02/07 13:21:59
>>558 参照返しじゃないから意味なし。

560:558
06/02/07 13:27:44
>>559
ああ、確かに意味は無いなｗ

でも、argcもconstにしてるけど、これも意味が無いから、
それをさらに徹底させるって意味で返り値もconstにすればいいのにー
っと思っただけ

561:デフォルトの名無しさん
06/02/07 14:04:04
argcの場合、意義はともかくプログラム上の意味が変わる。

562:デフォルトの名無しさん
06/02/07 14:21:19
うっかり書き換えるとコンパイラにゴルァされるとか

563:558
06/02/07 14:26:48
確かに関数内では意味が変わる...か。
関数のオーバーロードでは同一視されるから一緒と思ってたけど、
内部の事は忘れてた。thanks

564:デフォルトの名無しさん
06/02/07 15:01:05
>>558 お前素直な奴だな

565:デフォルトの名無しさん
06/02/08 00:54:04
そこでconst_castの登場だな

566:デフォルトの名無しさん
06/02/08 18:26:06
全部ILで書こうぜ

567:デフォルトの名無しさん
06/02/08 19:24:23
遅いからヤダよ。

568:デフォルトの名無しさん
06/02/09 01:52:44
STL/CLIお蔵入り

569:デフォルトの名無しさん
06/02/09 04:28:08
固定長配列はcli::array以外に用意されてない？

570:デフォルトの名無しさん
06/02/09 11:58:31
>568

STL.NETは別途配布されるんじゃなかったの？

571:デフォルトの名無しさん
06/02/09 12:38:09
BOOST.NETも出たりとか。
正直大混乱。

572:デフォルトの名無しさん
06/02/09 13:44:43
正直いってWinXPのSP2入れたくないからとかいう理由で
SP1を使ってる馬鹿と同レベルの理屈だな

新しいものの方がいいに決まってる。たとえバグ込みでも
長い目で見れば将来性の高いほうを選択する方がよい

573:デフォルトの名無しさん
06/02/09 17:47:52
>>571

BOOST.NETって何？そんなんあんの？

574:デフォルトの名無しさん
06/02/09 22:47:44
>>572

その将来性のおかげで、君の部下が次々と止めていくんだがどう責任取るのかね?

575:デフォルトの名無しさん
06/02/10 21:58:53
値型にデフォルトコンストラクタと代入演算子を定義できる
.NET言語ってあるんかな？

576:デフォルトの名無しさん
06/02/10 22:01:31
フレームワーク内のprivateないくつかの構造体を見ると、
デフォルトコンストラクタ使ってるのがいくつかあるな。

Win32関係の構造体で自分のサイズを設定してるんだが。

577:デフォルトの名無しさん
06/02/10 22:20:02
>>575
つIL (ilasm)
まぁぶっちゃけいらないっていうかあってもまずやっちゃいけないしな

578:575
06/02/10 23:53:50
>>576,577
どうも

Reflectorでみてみたら
staticコンストラクタで代用しているのはありました。

こんな感じで試してみようかな...
URLﾘﾝｸ(www.gdncom.jp)

579:575
06/02/11 01:08:41
やってみたけどよくわからんかった。でも
templateの部分特殊化でCLI型が使えるみたいだから、それでcreateすればいいか.

template <typename T> ref struct Type{ T create(); };
template <typename T> ref struct Type<T^>{ T^ create(); };

580:デフォルトの名無しさん
06/02/11 07:51:31
C++ で boost の shared_ptr とか boost::program_options とか
使いまくりんぐのプログラム作ってきたんだけど、
C++/CLI でそのコード流用できるんですかね？
stl::map とか使いまくりんぐノプログラムは
そのままで動くのか、STL.NET みたいなモノをつかうように
移植しなけりゃならないのか、System::Collections を
使うのが C++/CLI 流なのか・・・・・・

何でも出来るから何使えばいいか迷う。

581:デフォルトの名無しさん
06/02/11 09:40:08
C++/CLIは便利だと思うが、棲み分けに失敗した感じがするな。
C#で統合するはずが、C++/CLIで統合されるとは…。
本当は.NET対応はC#だけでよかったんだと思う。

582:デフォルトの名無しさん
06/02/11 10:25:45
>>580
managedなobjectをどう扱いたいかによるだろ?

例えば数値計算してその結果を3Dグラフ表示するような場合、
数値計算の部分は普通にC++使えばいいけど、(例えばboostなど)
画面表示の部分はどうしてもCLIに頼らないといけない。

C++/CLIは基本的にC++の上位互換と考えていいから。
"spaced keyword"なんていうのは非互換だけどね。

583:デフォルトの名無しさん
06/02/11 10:29:11
おまえら、どのエディション使ってるの？

584:デフォルトの名無しさん
06/02/11 10:35:44
>>582 うむ、いっていることは分かる。
まさに数値計算して可視化、ってのは仕事で必要。
しかも膨大な数値計算用のライブラリ(自作+他作)がすでにある。

今一番の問題は、コマンドラインをパーすするために便利な
boost::program_options を C++/CLI コンソールアプリでも
使いたいってことかな(笑

585:デフォルトの名無しさん
06/02/11 11:10:32
C++/CLIは、CLIに頼らなければいけない時だけ、
managedなコードを書かなければいけないC++だろ?

embedded C++みたいに言語の機能抜かれているわけじゃないから。

ライブラリであるSTL .NETは、C#やHaskelからも使えるSTLライブラリとして、
C++特有のところは抜かれているけれど。(特殊化関連など)

586:デフォルトの名無しさん
06/02/11 11:11:09
>>585
> managedなコードを書かなければいけないC++だろ?

managedなコードも書ける、とも言えるし。

587:デフォルトの名無しさん
06/02/11 11:15:34
>>585 ふむ、いわれてみればそうだな。
俺があまりにも boost 依存なコードを書きすぎていただけだと思う。

588:デフォルトの名無しさん
06/02/11 15:56:27
>>581
いろんな言語が使用できるっていうのが.NETのうたい文句のひとつだったから
C#だけって言うのはいただけない

589:デフォルトの名無しさん
06/02/11 16:22:28
馬鹿はスルーしる

590:デフォルトの名無しさん
06/02/11 16:26:50
.NETって実際複数言語で開発してたりすんの？

591:デフォルトの名無しさん
06/02/11 16:48:36
>>590 俺はドトネトは C# しか使ってないけど、
俺が使ってるアセンブリが C++/CLI や VB.NET
で作られているかどうかは知らない。

592:デフォルトの名無しさん
06/02/11 16:53:16
VC++はVC++で作られていますという件はもはや過去のもの？

593:デフォルトの名無しさん
06/02/11 17:26:02
「ドトネト」って言う呼び方はアンチっぽいからやめてくれ

594:デフォルトの名無しさん
06/02/11 17:31:18
エロビデオのネバスペみたいなもんか。

595:デフォルトの名無しさん
06/02/11 17:39:26
Win32APIなどのネイティブ呼び出しをC++/CLIでラップしてあとはC#で開発してる。
windows.h　の関数や定数の定義をそのまま使える上にInteropで呼び出しも高速なので
P/Invokeよりぜんぜんいいよ。

ドトネトよりポチネットのほうが可愛い

596:デフォルトの名無しさん
06/02/11 18:07:08
>>595
狂おしいほどに同意
アセンブリの中にネイティブコードを突っ込めるから
逆コンパイルにも対抗できるし。

597:デフォルトの名無しさん
06/02/11 20:57:49
そんなことしたら64bitでそのまま動かないじゃん

598:デフォルトの名無しさん
06/02/12 03:52:02
>>597
32bitで何か問題でも?

599:デフォルトの名無しさん
06/02/12 16:51:41
C++/CLIがNativeとManagedの混合アプリを作るのに優秀なのは理解できるが、
/clr:safe　なアプリをあえてC++/CLIで作ることに意味があるのだろうか。

600:デフォルトの名無しさん
06/02/12 17:37:42
>>599
特になし。C++/CLIはC++使い慣れてる(C++ライブラリを膨大に抱えてる)人を
.NETに繋ぎとめておくためのもの。

601:デフォルトの名無しさん
06/02/12 21:00:01
2003のWin32APIやMFCを2005ExpressEditionで使おうと
頑張ってみたが無理だった。
Win32APIはコンパイル通るけど警告出るし、
MFCに関しては全くお手上げ。

602:デフォルトの名無しさん
06/02/12 22:31:04
>>601
WinAPIは2003から持ってこなくても最新のPlatform　SDKを入れればいいだろうに。

603:デフォルトの名無しさん
06/02/12 23:14:27
C++/CLIはVB.NETで作ったクラスライブラリを呼び出すことも可能？

604:デフォルトの名無しさん
06/02/12 23:33:15
可

605:デフォルトの名無しさん
06/02/12 23:51:30
>>602
最新のSDK持ってきたら、警告なくなったよ。ありがと。

606:デフォルトの名無しさん
06/02/13 08:02:58
managed C++ みたいに C++/CLI もやっぱやーめたなんてことにはならんだろうな？
前者はなんか標準化団体には出されてたんだっけ？後者はだされてたよな？

607:デフォルトの名無しさん
06/02/13 08:05:18
>>605
感謝は言葉ではなく物で示せ。

608:デフォルトの名無しさん
06/02/13 12:44:28
>606
今、ISO で標準化の審査中

609:デフォルトの名無しさん
06/02/13 13:03:53
>>608 それは C++/CLI だよね？
もう Managed C++ はいらんでそ。

610:デフォルトの名無しさん
06/02/13 14:01:33
(1)for each( int obj in v)
(2)for each( int^ itr in v)
(3)for each( int% r in v)

for each する場合、どれがお勧め？

611:デフォルトの名無しさん
06/02/13 15:26:41
>>609
URLﾘﾝｸ(www.ecma-international.org)
これがISOに提出された。まあISOになる可能性はないと思うけれど。

612:デフォルトの名無しさん
06/02/13 16:55:39
>>611 あれ？ないの？

613:デフォルトの名無しさん
06/02/13 17:22:33
CLI 自体はすでに ISO 標準になってるんだよな。
Java VM も ISO 標準にすればいいのに。
Java 言語とは切り離して。

614:デフォルトの名無しさん
06/02/13 18:06:42
で、ISO 標準て何の役に立つの？

615:デフォルトの名無しさん
06/02/13 18:07:31
ネームバリュー

616:デフォルトの名無しさん
06/02/13 18:10:32
実質を無視したネームバリューなら、
Java >>>>>>（壁）>>>>>> Ｃ丼（I$O）
だね。

617:デフォルトの名無しさん
06/02/13 18:13:08
>>616 実質的なネームバリューだと思うけど。

618:デフォルトの名無しさん
06/02/13 21:22:11
>>616
Java のネームバリューってかなり実質的なものだと思うぞ。

619:デフォルトの名無しさん
06/02/13 23:26:25
>>613
EMCAの時に、J2EEも同時に採用されることにこだわった。
当時は、IBMその他ベンダーが独自ビジネス向けフレームワークの覇権を争っていた。

Javaはまだまだ言語規格の変化が激しいから、10年前なら見送りも妥当だったと思う。
今は、C++みたいにろくにない実装も規格を作るのに抵抗がなくなってきている。
だからJavaも今からISOの提出してもいいと思うけれど、
EMCAのWin系規格みたいに放置されると困るよね。

C#やCLIもそんなことにならないかと心配。

620:デフォルトの名無しさん
06/02/14 04:09:12
>>618
確かにJavaはネームバリューだけだな

621:デフォルトの名無しさん
06/02/14 09:09:07
ドトネッツは実質ＮＯ．１

（ベーパーウェア部門）

622:デフォルトの名無しさん
06/02/14 13:57:47
>610
vの中身を書き換えたいときは、必然的に(3)
(1)と(2)でコンパイル結果に差が出るかは知らんが、同じなら(2)の方が他の参照型などと統一性が採れると思う

623:デフォルトの名無しさん
06/02/14 22:40:58
int^ だとボックス化のコストが高くない？

624:610
06/02/15 09:08:44
>>622,623
値型の場合、(1)が無難な気がしてきた。(2)はテンポラリGCポインタなのか...(3)はなんか怪しい...
参照型の場合、(2)しか選択もうない気が、第４の選択肢は危険ぽいし...

ref struct Test{
Test(){}int x;Test(int in_x) :x(in_x){}
static void test(){
System::Collections::Generic::List<int> v;v.Add(1);v.Add(2);v.Add(3); //case1
//cli::array<int>^ v = {1,2,3}; //case2
#define SHOW for each(int i in v){Console::WriteLine(i);}
for each(int i in v){i *= 2;}SHOW;//result->{1,2,3}
for each(int^ p in v){(*p) *= 2;}SHOW;//result->{1,2,3}
//for each(int^% p in v){(*p) *= 2;}SHOW;//danger
for each(int% r in v){r *= 2;}SHOW; //case1->{1,2,3},case2->{2,4,6} -> unsafe code
}
static void test2(){
System::Collections::Generic::List<Test^> v;v.Add(%Test(1));v.Add(%Test(2));v.Add(%Test(3));
//cli::array<Test^>^ v ={ %Test(1),%Test(2),%Test(3) };
#define SHOW2 for each(Test^ t in v){Console::WriteLine(t->x);}
for each(Test^ p in v){(*p).x *= 2;}SHOW2;//result->{2,4,6}
for each(Test^% r in v){(*r).x *= 2;}SHOW2;//result->{4,8,12},case2->{2,4,6} -> unsafe code
}
};

625:デフォルトの名無しさん
06/02/15 12:54:23
>624
何を悩んでいるのかよくわからん
列挙する型に合わせれば良いんじゃないか？
適材適所だろ

626:デフォルトの名無しさん
06/02/15 16:25:30
^うざ

627:デフォルトの名無しさん
06/02/15 19:45:53
よーく見ると、顔に見えてくる。

628:デフォルトの名無しさん
06/02/18 14:49:04
VS 2005 C++だす
×　String str = "Hello";
○　String ^str = "Hello";
いちち^付けないといけないみたいですね、
^ってどういう意味ﾃﾞﾂｶ

629:デフォルトの名無しさん
06/02/18 15:09:39
>>628
C++/CLIに於けるポインタ

630:デフォルトの名無しさん
06/02/18 15:17:47
そっか、それで
*を^に変えろって困憊羅が言ってるの、見たような希ガスル
しかしなぁー、なぜ換える必要があるのかと、悩む事小10分
*アスタリスクはなんか他の用途でつかってるのかなぁ？？

631:デフォルトの名無しさん
06/02/18 15:30:01
こう覚えた方が早い
* を使っているのは C++
^ を使っているのは CLI 拡張

632:デフォルトの名無しさん
06/02/18 15:44:42
>>630
*のポインタ型同士はポインタ演算があるから演算子多重定義ができない。
^の追跡ハンドルならそのようなことがないから演算子多重定義ができる。

633:628
06/02/18 16:29:22
>>631
>>632サンクスです
GUIが使えるWin32でアプリケーションを作りたくて、NETや本を読んで
今学習しているところなんです、Visual Studio 2005 C++の
Win32コンソールアプリケーションを開いてボタンを押したら、
テキストボックスにメッセージを表示させたりとかして
動かしているのですけど訳も分からずに、CLIを使っていたんですね（；^ω^）
VS2005C++な環境でネイテイブなC++でコンソールアプリケーションは
作れないのでしょうか？MFCも挑戦しようと思いましたが、又別物のようですし
初心者的にはどの方向で進んだら良いでしょう、小一週間悶々としています

634:628
06/02/18 16:32:13
ｽﾏｿ
×　GUIが使えるWin32でアプリケーションを作りたくて
○　GUIで動作するWindowsアプリケーションを作りたくて

635:デフォルトの名無しさん
06/02/18 16:45:58
初心者ならC#へ行ってみてはどうかと惑わしてみる。
VS2005C++使った事無いけど、アンマネージド(ネイティブ)は作れるはずだ。

636:デフォルトの名無しさん
06/02/18 16:55:38
2005は普通に「Win32コンソールアプリケーション」でネイティブを作れるはずだが…
Expressだと違うのか？

637:デフォルトの名無しさん
06/02/18 17:01:58
>628
GUI でモノを作りたければ、素直に MFC に進んだ方がいいと思われ
C++/CLI はちと初心者にはお勧めできない。普通の方法では満足できなくなった玄人向け
だから
あとは、635 の進めるとおり、C# でモノを作ってみて満足できなくなったら、またこちらに
出戻ってくると言うのもいい

638:デフォルトの名無しさん
06/02/18 17:15:12
>>633
コンソールアプリケーションとテキストボックスのつながりがわからん

639:デフォルトの名無しさん
06/02/18 17:36:48
すんません、又間違えていました
CLRからWindowsフォームアプリケーション作成でした

640:デフォルトの名無しさん
06/02/18 21:12:37
他スレから誘導されてきました。

C++/CLIを使っているんですが、
自分のクラスライブラリのシングルトンのクラスにあるSystem::Drawing::Size型のプロパティを変更しようとしたら
p->Size = System::Drawing::Size(64, 64);
と設定はできるのですが、
p->Size.Width = 64;
のように個別に設定しようとしたら必ず0になってしまいます。

どうすれば個別に設定できるようになりますか。

641:640
06/02/18 21:26:55
投稿して気付いたのですが、Sizeの部分をハンドルにしたら設定出来るようになりました。
何故かがわからないですが・・・。

スレ汚しすいませんでした。

642:デフォルトの名無しさん
06/02/18 21:48:34
>>641
System.Drawing.Sizeは型値だから扱いが面倒だのう。

643:デフォルトの名無しさん
06/02/19 06:34:22
>>633
スレ違い
ｽﾚﾘﾝｸ(tech板)

644:デフォルトの名無しさん
06/02/19 14:36:44
>>641
というかそれはあまりよろしくない。たぶん。

p->Size = Size(64, p->Sizte.Width);

としなさい(こういうCLRの常識みたいなのもいるから
また複雑なんだよな>C++/CLI)。

645:644
06/02/19 14:43:34
にゃー、コード間違いすぎ

p->Size = Size(64, p->Size.Height);

こう。

646:デフォルトの名無しさん
06/02/19 15:20:04
そんなんわからん奴はC#やJavaも微妙だろ。

647:デフォルトの名無しさん
06/02/19 15:28:54
>>646
…まぁな。実体の追跡もできないレベルだし。
C#はまだ動かないだけで安全だけど、こういうやつには特にC++は使わせたくない。
メモリ関係のバグ大量コードを書く。しかもそういう場合デバッグビルドだと動いたり
することもあるから性質が悪い…。

648:デフォルトの名無しさん
06/02/19 20:48:42
Visual C++ 2005 Express Edition の環境で、はまってしまい、皆さんのお知恵を拝借したいです。

Webのダウンロードなのですが、
方法1
　　WebClient^ wc = gcnew WebClient();
　　Stream^ st = wc->OpenRead("URLﾘﾝｸ(www.yahoo.co.jp)");
　　Encoding^ enc = Encoding::GetEncoding("euc-jp");
　　StreamReader^ sr = gcnew StreamReader(st, enc);
　　String^ out = sr->ReadToEnd();
　　Debug::WriteLine(out);
これはうまくいきWebデータの取得ができます。

方法2
WebClient^ wc = gcnew WebClient();
Byte ^ myDataBuffer = wc->DownloadData("URLﾘﾝｸ(www.google.co.jp)");
Encoding^ enc = Encoding::GetEncoding("euc-jp");
String^ out = enc->GetString(data);
このコードだとコンパイルエラーです。
エラーメッセージは、
.\MainForm.cpp(50) : error C2440: '初期化中' : 'cli::array<Type,dimension> ^' から 'System::Byte ^' に変換できません。
　　　　with
　　　　[
　　　　　　Type=unsigned char,
　　　　　　dimension=1
　　　　]
　　　　この変換を実行可能なユーザー定義変換演算子がないか、または演算子を呼び出せません。

とあります。
バイト配列に入れたいだけなのに。

649:デフォルトの名無しさん
06/02/19 21:05:11
>>648
WebClient::DownloadData()の戻り値の型はcli::array<unsigned　char>^。
Encoding::GetString()の引数もcli::array<unsigned　char>^。

650:デフォルトの名無しさん
06/02/19 21:12:35
^　←なんかコレうざい。よくわからないけど腹立たしい。

651:デフォルトの名無しさん
06/02/19 21:18:36
(^^:

652:デフォルトの名無しさん
06/02/19 21:20:18
^<T>^

653:648
06/02/19 21:44:16
>>649
Byte を cli::array<Byte> にしたところ、できました。

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

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

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

どうもありがとうございました。

654:Pascal
06/02/19 23:09:23
>>650
呼んだ?

655:デフォルトの名無しさん
06/02/20 00:22:49
>>650
あなたの心が汚れてるからですよ(^^;;;

656:デフォルトの名無しさん
06/02/20 00:30:26
そんなばかな^^;

657:デフォルトの名無しさん
06/02/20 01:26:15
>>650-652
ヤベ、ツボにはまったｗ

658:デフォルトの名無しさん
06/02/21 10:07:18
>>422-423
＞ダイレクトに C++ を知らずに、C++/CLI に手を出すのは、止めた方がいいだろ
＞さっさとC#かVBで始めたほうがいいと思う。

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

>>424
関数単位ですか。
つまり、関数呼び出しを共通化することで様々な実行環境にあるコードを一つのプログラムにまとめることができたと言うことでしょうかね。

659:デフォルトの名無しさん
06/02/21 11:10:22
>>658
ああ、C#にしたのか。まぁそうしとけ。C++/CLIはネイティブの知識(C++)とCLRの
知識(C#)が両方要求されるひどい言語だ。最低限どっちかぐらい自由に使える
ようになってからおいで。…両方自由に使えるぐらいじゃないと使える言語でも
ないかもしれないが。

ファイナライザ？C#にもあるぞ。というかCLR用語だそれ。
まぁDisposeがスタックオブジェクトのように書けることをいいたかったんだろうけど。
川俣とかが取り上げているほど、たいしたものじゃない。あの人は大げさに書く文体
が売りだからな。いい悪いは別にして。

660:デフォルトの名無しさん
06/02/21 21:17:52
通のお勧めは関数のオーバーライド
ディスポーズ・パターンの変形に目が眩んでちゃ、まだまだ

661:デフォルトの名無しさん
06/02/21 21:25:46
>>660 ポリモにならんじゃん

662:デフォルトの名無しさん
06/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されるわけではない。

663:デフォルトの名無しさん
06/02/22 00:50:01
!hogeなんてあったんだ

664:デフォルトの名無しさん
06/02/22 07:21:27
>>662
いや、えーと、このスレにいる以上知っている。
ildasmでも確認したしな。ああ、そうか、それをC++/CLI用語でFinalizerというのか。

665:デフォルトの名無しさん
06/02/22 12:42:51
>661
おまいはC++/CLIにおける関数上書きの奥の深さに気付いていない

ここに IEnumerable を継承したインターフェイス IEA と IEB がある
その双方を実装した ref クラス RAB は明示的オーバーライドによって列挙の方式を
IEA と IEB によって変更できる
つまり、RAB から取得したインターフェイスによって、for each のオーダーを自由に
選択できるわけだ

666:デフォルトの名無しさん
06/02/22 16:05:53
MSがC++/CLIを捨てるのは何年後くらいですか？

667:デフォルトの名無しさん
06/02/22 16:13:12
MFCの如くこの劣悪貧を１０年使うかも。
C++ってだけでもSTLやBoostが混ざってくると複雑なのに、正直CLIはカンベンて感じだおね。

668:デフォルトの名無しさん
06/02/22 17:22:04
>>667
駄菓子菓子、これがないとネイティブとかからCLRが非常に使いにくい。
ほら、次でWPFとかなんかたくさんあるし。

669:デフォルトの名無しさん
06/02/22 23:36:01
マイクロソフトがもうｲﾗﾈと思ったら容赦なく捨てにくるさ。

670:デフォルトの名無しさん
06/02/23 02:00:23
>>669

そりゃ日本だけ。海外ではVBerが反乱おこして、msも今では Love VB, Love C#だとよ。

671:デフォルトの名無しさん
06/02/23 02:53:32
C#は、VC++とVBの中間を行くような言語だから、
どっちからも反発が強いだろうね。

672:デフォルトの名無しさん
06/02/23 03:03:54
反発はしないけど、C++で出来るなら C++ Nativeでやっちゃうよ。
必要なとこだけ CLIで .Netなんてライブラリ感覚で使えばいい。

673:デフォルトの名無しさん
06/02/23 03:20:44
/clrでNativeコンパイルすると遅くなる？

674:デフォルトの名無しさん
06/02/23 08:50:40
>673
>348

675:デフォルトの名無しさん
06/02/23 09:37:51
>>669
要るだろ。

だって、C++市場をCLIで混乱させることにより、
開発者をWin＠ﾌﾞﾋﾞ or Win＠Ｃ丼で留めておける。

676:デフォルトの名無しさん
06/02/23 10:00:24
>>674

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

それとも呼び出し時にスタックチェックでも入ってるのかね…。

677:デフォルトの名無しさん
06/02/23 14:21:46
>676
単純なループでは簡単に結論が出ない問題かもしれない
ちなみに漏れの環境では
CLR 6 - 7 sec.
Native 8 sec.
となった。意外だがCLRの方が早い
Win のほうは -02 -0t を付けた状態で、CLRの方はデフォルトのリリースモジュールだ

678:
06/02/23 22:30:11
>>670
そんな話しきいたことネ

679:デフォルトの名無しさん
06/02/23 22:47:11
誰か、C++/CLI で吐いた実行ファイル、
mono で動かした奴いる？？

以前 VS.NET 2003 の C# で書いたコンソールアプリなら
mono で動かしたことあるんだけど。

680:デフォルトの名無しさん
06/02/23 23:22:55
mono がそもそも .net framework 2.0 に対応してたか？
してるなら、/clr:pure で動くだろう

681:デフォルトの名無しさん
06/02/24 08:17:28
nullptr

682:デフォルトの名無しさん
06/02/24 11:48:08
ｶﾞｯ^

683:デフォルトの名無しさん
06/02/24 17:24:15
>>678

URLﾘﾝｸ(blogs.msdn.com)

ケツの穴が広がるぐらい、ハードに読めや。

684:デフォルトの名無しさん
06/02/24 21:07:35
>>683
良く読んだよ

>表の顔の日記　

> 裏の顔の日記
> さっさと消えてくんないかな。うざいんだけど、まじで。

685:デフォルトの名無しさん
06/02/25 04:29:20
という電波でも飛んでるのか?

686:648
06/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型の配列の定義がしたいのですが、マネージ環境では、どのようなやり方があるでしょうか?

687:デフォルトの名無しさん
06/02/25 11:43:26
typedef struct → typedef value struct
では？

688:648
06/02/25 12:05:23
>>687
そうです。コピペ間違いました。

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

と記述してます。

689:デフォルトの名無しさん
06/02/25 12:17:18
・・・value型使わず、ネイティブ型で定義すれば？

690:デフォルトの名無しさん
06/02/25 12:20:37
あとは ref にして array<long>^ y で宣言して、コンストラクタで初期化するか

691:デフォルトの名無しさん
06/02/25 12:23:04
value struct HOGE
{
　　int x;
　　array<long>^ y;
};
はコンパイルが通るが、仕様上これでいいのか？

692:デフォルトの名無しさん
06/02/25 12:38:17
ok
ハンドルは nullptr で初期化される

693:648
06/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日あがいてみて自分ではできなそうだったら、ネイティブで定義してやっていきます。
マネージ環境に慣れていけば、そのうち、何か気づきがあると信じて進むしかありません。

694:デフォルトの名無しさん
06/02/25 13:05:44
2～3日あがくなら2～3日かけてマニュアル読んだほうがいいような気がする

695:デフォルトの名無しさん
06/02/25 13:45:46
>>693
値型にGCを求める必要がある？

696:デフォルトの名無しさん
06/02/25 14:23:50
C++/CLIのスレ見てると無意味にvalueを使いたがる人が多い気がするな。
valueは動作に癖があるから基本refで作ったほうがいいと思う。

697:デフォルトの名無しさん
06/02/25 16:22:08
value使ったほうが処理速度が速いとでも思い込んでいるんじゃ？
クセがあるには同意。

698:648
06/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]);
　　}
}

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

みなさん、いろいろとレスありがとう。

699:デフォルトの名無しさん
06/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]);
　　　　}
}

700:デフォルトの名無しさん
06/02/25 22:33:45
C++は真のローカル変数を使える言語なんだから、（ユーザー定義オブジェクト
がスタック上に配置できる）GCが必要な場合ってのはそんなに多くはならない
ってビョーン先生が言ってた。

701:デフォルトの名無しさん
06/02/25 23:11:17
>>700
それはわかるけれど、C++/CLIはCLIの世界にあわせないといけないからさ。

702:デフォルトの名無しさん
06/02/25 23:42:48
C++/CLIは二つの言語が同居しているようなものだからな。
C++の拡張というより建て増し。

703:デフォルトの名無しさん
06/02/25 23:49:05
>699
それだと、配列のサイズが3で固定されちゃわない？

704:デフォルトの名無しさん
06/02/26 00:22:20
>>702
二世帯住宅

705:デフォルトの名無しさん
06/02/26 00:49:18
ビョーン先生が取り扱っている案件はそうかもしれんけどな。
動的にオブジェクトが増えたり減ったりする案件のほうが多い。

706:デフォルトの名無しさん
06/02/26 00:56:47
>>700
しかしビョーン先生はGCをそんなに否定していない。
既存のC/C++のコードと互換性を保ったまま導入できるのなら、
C++に入れてもいいというようなことをD&Eで書いている。

707:デフォルトの名無しさん
06/02/26 20:57:17
>>705
vector使えばええやん。メンバかローカルにしておけばdeleteいらん。

708:デフォルトの名無しさん
06/02/26 21:08:56
>>707
グローバルでもdeleteいらんぞ

709:デフォルトの名無しさん
06/02/26 21:14:38
別に GC なんて C++/CLI の利点じゃないだろ
単に .net framework を既存の C++ と混同することなく使えるってとこが一番重要さ

C++/Smalltalk とか C++/Squeak とか出てこないかな

710:デフォルトの名無しさん
06/02/27 01:56:21
【初心者歓迎】C/C++室 Ver.25【環境依存OK】から誘導されてきました( ｀・ω・´)ﾉﾖﾛｼｸｰ
VC8でopenFileDialogを使いたくて
MSDNのソースを試してみようと
URLﾘﾝｸ(msdn2.microsoft.com)
説明を読み
フォームに 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' : 定義されていない識別子です。

711:デフォルトの名無しさん
06/02/27 07:06:19
>>710
System::Windows::Forms::DialogResult::OK　とフルで書く。

712:デフォルトの名無しさん
06/02/27 07:26:28
>>711
最後まで仕様が揺れた所かも知れないね。

713:デフォルトの名無しさん
06/02/27 10:47:00
この状況って System::Windows::Forms まで using で指定しているから、単純にグローバル
スコープ指定していることが問題なんじゃね？
12行目の ::DialogResult を意味なく、:: で始めるな、と

714:デフォルトの名無しさん
06/02/27 11:06:47
>>713
ところがどっこい
DialogResult::OK　と書くと今度は
System::Windows::Forms::Form::DialogResultが無いというエラーになる。
using　namespace　は探しに行ってくれないらしい。

715:デフォルトの名無しさん
06/02/27 11:38:26
ん、サンプルだと :: で始めてるな
っていうか、>710 って名前空間 System しか宣言してないって言ってるが
using namespace System::Windows::Forms が宣言されている環境では
::DialogResult::OK でエラーなくコンパイルできるな

先頭 :: の名前検索ルールって、グローバル指定じゃないんだ・・・

716:デフォルトの名無しさん
06/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になる。それで正しい。

717:715
06/02/27 13:45:08
まず、 >710 の問題は、単に System::Windows::Forms が using 指定していないから
using namespace System::Windows::Form;
を付ければおっけー

>716
::DialogResult ってなっているから、先頭に :: を付ける場合ってグローバル名前空間の
名前空間指定だと思ってた。カレント解決してくれるんだ

718:716
06/02/27 13:55:54
>>717
いや、「正しい」はグローバル参照の方。

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

Forms

719:715
06/02/27 18:46:14
ということは、MSの実装はバグかMS独自仕様か、微妙なとこだな

720:710
06/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' : 属性が見つかりません。
とこんな感じで、
ﾜｹ川・∀・川ﾜｶﾒです

721:デフォルトの名無しさん
06/02/27 20:17:53
>>720
その一
using　namespace　...
using　namespace　...
namespace　hoge　{
と順番を変えたら　::DialogResult::OK　でコンパイルが通る。

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

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

これが仕様なのかバグなのかは俺にもわかんね～

722:デフォルトの名無しさん
06/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)

723:デフォルトの名無しさん
06/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)
ならわかるけど。

724:デフォルトの名無しさん
06/02/27 20:45:59
>>723
C++/CLIの列挙子は列挙型の中のスコープにある。

725:デフォルトの名無しさん
06/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)　

726:デフォルトの名無しさん
06/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;も問題ない。

727:デフォルトの名無しさん
06/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にしても同じ。

728:デフォルトの名無しさん
06/02/28 01:38:12
>>727
CLRタイプのenum　class　と　Cタイプのenumの２種類あって、
後者の話ならそのとおり。

729:710
06/02/28 21:38:39
皆さんのおかげで、openFileDialogを動かす事ができたのですが
肝心な事を忘れていました、ファイルを選択してボタンを押しても
実際にファイルが開かないんですよね（；^ω^）
// Insert code to read the stream here.
ってコメントアウトしてある部分が気になるけど、ここに何か
書かないといけないのかな？

730:デフォルトの名無しさん
06/02/28 21:43:05
教えてクンマンセー！

731:デフォルトの名無しさん
06/02/28 21:53:32
コメントが何のために有るのかわかってるのか？
っていうか読めよ。

732:710
06/02/28 21:54:54
>>731
英語読めません(´･ω･`)

733:デフォルトの名無しさん
06/02/28 21:57:00
>>732
んじゃ、英語の勉強から。英語書けないならともかく、読めないんじゃ
プログラミングなんてやってられない。

734:デフォルトの名無しさん
06/02/28 22:35:55
翻訳サイトも使えないようなヤツはプログラミングやめれ

735:デフォルトの名無しさん
06/02/28 22:40:27
ていうか、732は710の偽なんですが

736:732
06/03/01 00:45:52
俺は嘘つきだから俺の言うことは嘘ばっかりさ。さてこの嘘はホントかわかるかねｗｗｗ

737:デフォルトの名無しさん
06/03/01 01:08:24
そんなおもしろくないよ?

738:デフォルトの名無しさん
06/03/01 01:32:16
>>733
ひまわりが専門なので関係ないでしょ

739:710
06/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();
}

740:デフォルトの名無しさん
06/03/01 02:32:10
C++/CLI の場合でも .NET Framework のサンプルがほしければ
C#やVBのをそのまま使えるってのに

741:710
06/03/01 02:37:58
|∀・).｡oO(・・・)
そうなのか？

742:デフォルトの名無しさん
06/03/01 02:38:23
ｶﾞﾝｶﾞﾚ

743:710
06/03/01 02:43:27
ﾑﾘｯﾎﾟ

744:デフォルトの名無しさん
06/03/01 07:19:26
>>740 うむ。
ちょっと間接参照の記述が違うくらいで、
流れは C# のコードのままでいいな。
まぁそれが C++/CLI の真骨頂でもある。

745:デフォルトの名無しさん
06/03/01 14:15:46
>>739
C++/CLIなんだからいちいちgcnewする必要はないと思う。

746:デフォルトの名無しさん
06/03/01 14:50:01
>>739
つかCloseもfinally句に書いてないし。
C#ならusing、C++/CLIならスタックオブジェクトにしろよなほんと。

747:デフォルトの名無しさん
06/03/01 16:30:41
で、STLはどうしてるんだ、おまえら?

748:デフォルトの名無しさん
06/03/01 16:49:26
C++/CLI でGUIなアプリつくるべ、と、フォームをデザインして
遊んでます。で、みなさん、アプリで必要となる大量の
変数たちは、class Form1 のメンバとしてずらずら宣言してしまって
構わないんでしょうか？

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

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

当然イベントハンドラなどはデザイナで追加されていくわけで、
手動で追加したメンバのためにフォームデザイナが混乱して
しまわないかすごく不安です。

749:デフォルトの名無しさん
06/03/01 16:54:58
STLが無い、C++なんて。

クソ。

750:デフォルトの名無しさん
06/03/01 16:57:44
>>749 え？C++/CLI で STL つかえないの？

751:デフォルトの名無しさん
06/03/01 17:06:05
>>750
ネイティブ型に対しては使える。

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

URLﾘﾝｸ(www.microsoft.com)

いっそのこと俺たちで作るかｗ。

752:デフォルトの名無しさん
06/03/01 17:18:06
>>751 あ～びっくりした。
そうだよな、ネイティブ型に対しては使えるよな？

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

753:デフォルトの名無しさん
06/03/01 18:24:32
>>752
いやいやいや、お前DirectXをなんと心得る？

754:デフォルトの名無しさん
06/03/01 19:09:05
>>753 まだ、OpenGL のかわりみたいなもん、
くらいの認識です。頂点データの扱いとか
ぜんぜんちがうんですかね？
その話題はスレ違いですが。

目的は動き回る多数の分子模型の
ようなものなんですが。

755:デフォルトの名無しさん
06/03/01 19:16:26
DirectXはまだネイティブがメインなのにどうしてSTLの無いC++/CLIを無理に使おうとするのか

756:デフォルトの名無しさん
06/03/01 19:28:40
com::ptr 型がそこにあるから

次ページ