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

おそらく、.NET開発でデファクトスタンダードに最も近い
であろうC++/CLIについて語ろうぜ！

このスレはC++および.NET Frameworkについて一定以上の知識を持っている人が対象となります。
.NETのクラスライブラリの使い方といった質問は姉妹スレ「くだすれC++/CLI（初心者用）」に
お願いします。

前スレッドはこちら
(p)http://pc8.2ch.net/test/read.cgi/tech/1126450441/l50

姉妹スレ
くだすれC++/CLI（初心者用）
(p)http://pc8.2ch.net/test/read.cgi/tech/1142144110/l50
managed C++ やろうぜ！！ 002
(p)http://pc8.2ch.net/test/read.cgi/tech/1139043535/l50

managed C++ → C++/CLI
(p)http://www.microsoft.com/japan/msdn/vs05/visualc/TransGuide.asp#transguide_topic
［特集］ Visual C++ 2005 いままたC++が熱い！「C++/CLI」として大進化したVisual C++ 2005
(p)http://www.atmarkit.co.jp/fdotnet/special/cppcli/cppcli_01.html
Calling Native Functions from Managed Code
(p)http://msdn2.microsoft.com/library/ms235282(en-US,VS.80).aspx

C++/Cli Essentials
(p)http://www.amazon.com/exec/obidos/tg/detail/-/0321174054/
Shared Source Cli Essentials
(p)http://www.amazon.co.jp/exec/obidos/ASIN/059600351X

C++/CLI設計者のblog
(p)http://blogs.msdn.com/hsutter/
(p)http://blogs.msdn.com/slippman/

STL.NET
(p)http://www.microsoft.com/japan/msdn/vs05/visualc/stl-netprimer.asp
(p)http://www.dinkumware.com/

C++の今後
(p)http://216.55.183.63/pdc2005/slides/TLN309_Sutter.ppt

前スレで gcroot と auto_gcroot の存在を教えてもらったんですが、
その後いろいろとググってみたところ、あんまり使われていない
みたいですね。というか、このテンプレートって標準なんだろうか。
なんか裏技でそのうちひっそりと使えなくされてしまうなんて
ことないかちょっと不安。

ごめん、嘘
auto_gcroot Class
http://msdn2.microsoft.com/en-us/library/ms177048.aspx

C++/CLI の規格というわけじゃなくて、VC++ の独自な
テンプレートクラスってことらしい。

逆に ref class の中に std::auto_ptr<NativeClass> みたいに
ネイティブクラスへのポインタを持たせられる？とか期待して
みたけど、それらしいのが見つからなかった。

ref class auto_handle なんてのが見つかったけど、
なんか意味あるんだろうか。普通のハンドルとどこが違うんだろう。
http://msdn2.microsoft.com/en-us/library/ms177066.aspx

Mixing Native and Managed Types in C++
http://weblogs.asp.net/kennykerr/archive/2005/07/12/419102.aspx
標準的なモノはなくて、 std::auto_ptr もどきの
ref struct AutoPtr を自前で作れ、ってことか。

ハッ!? もしかしてぜんぜん追っかけてなかったけど、
STL.NET には含まれてるのか？？

#この程度の話題って、くだスレの方がいい？
#棲み分け具合がまだ把握できてない

C#の話は、禁止だから、そのつもりで。

ここは、C++/CLIのスレだからな。

C#を勧める奴は、C#スレにいけ。

>>6 してないじゃん。gcroot って、C# とは無縁だよ？
そりゃ System::Runtime::InteropServices::GCHandle を
ラップしてるわけだから .NET Framework とは縁があるけど。
なにか過剰反応してるんじゃないですか?

>>7
前スレにいたアレなやつだ。

>>4
auto_handleはauto_gcrootが参照クラスになった感じのようだ。
http://msdn2.microsoft.com/ja-jp/library/ms177069(VS.80).aspx
http://msdn2.microsoft.com/ja-jp/library/ms177046(VS.80).aspx
生のハンドルと違ってスコープを抜けるときにデストラクタが呼ばれると言う利点は存在するようだ。
http://msdn2.microsoft.com/ja-jp/library/ms177068(VS.80).aspx
自動変数にすることに比べて利点がわからないけど。

auto_gcroot って #include <msclr/auto_gcroot.h> しないと
使えないんだね。名前空間は msclr::auto_gcroot になってる。

一方 gcroot の方は #include <vcclr.h> で自動的に
#include <gcroot.h> されて使えるようになる。
名前空間はグローバルになってる。

う〜む、なんで扱いが違うんだろう。というか、gcroot が
グローバルな名前空間で宣言されているのが気持ち悪いな。

たぶん gcroot も msclr::gcroot に配置すべきなんだろうな。
gcroot.h のコメントでは次のように書かれているし。

Use this class to declare gc "pointers" that live in the C++ heap.

Example:
    struct StringList {
        msclr::gcroot<String^> str;
        StringList *next;
        StringList(); // should have ctors and dtors
        ~StringList();
    };

>>10
直接<msclr\gcroot.h>をインクルードすればよい。

<vcclr.h>の中では<gcroot.h>がインクルードされていて、
<gcroot.h>が<msclr\gcroot.h>をインクルードしている。
<msclr\gcroot.h>は<gcroot.h>からインクルードされると名前空間を使わないようにされている。

直接ヘッダを見てみたらそうなっていた。

>>12 THX
msclr\gcroot.h っていうディレクトリと名前空間 msclr から
考えて C++/CLI の標準仕様には gcroot, auto_gcroot は
入れないつもりなのかな。しかしこれが無いと困る場面も
あるんだけどなぁ。標準に入れてくれ>MSの人

>13
言語上の本道は混合型の導入になるから、正式仕様にはならないんじゃないかな
STL/CLIも混合型が使えるようになったら正直いらないし

> おそらく、.NET開発でデファクトスタンダードに最も近い
まじかよ

混合型もいいけどコンパイラスイッチで、
ぱちっと切り替えられるほうがいいな。
逝ったりきたりすると遅くなりそう...

>>15
マジなんだよ。C#とか言うヤツの気がしれんわ。

>>14
今の ECMA の規格じゃぁ mixed type はダメなんだったっけ。
Mixed type に言及してる文献はあるけど、標準化には入ってこないのかな。
http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1557.pdf
http://www.gotw.ca/publications/C++CLIRationale.pdf

----以降 C# は駄目とか C# じゃなきゃ駄目とかいう過激派は発言禁止----

し、C♯じゃなきゃだめなんていってないじゃないっ！
あんたのほかにも代わりはいくらだっているんだから！！！

>18
だめっつーより、開発予定なんだろうけど

ttp://signe.japan.webmatrixhosting.net/ecma372/23_mixed_type.aspx

実際のスケジュールはどうなんだろうね。デリゲート・コンストラクタの方が先に実装
されそうだよ

混合型のサポートは VC++ 2010 がターゲットだってよ
ttp://blogs.msdn.com/branbray/archive/2005/07/20/441099.aspx

CLIをまともなC++言語から使うには2010年までまつ必要があるということ？

完全な混合型は、需要もどの程度あるか疑問だし、とりあえず

１）マネージドなオブジェクトへのハンドルを
　　ネイティブクラスのメンバに

２）ネイティブなオブジェクトへのスマートポインタを
　　マネージドクラスのメンバに

の相互通行ができれば便利なんじゃないかな。
それは gcroot/auto_gcroot と >>5 の AutoPtr 的な
スマートポインタクラスを使えば VC++ 2005 でも
可能なんだけどできれば何か標準があったほうが安心だよなぁ。

何だかプログラミングし難くね？
Winの良さが丸消えじゃん。

ネイティブで多重継承して、それをサポートしたいコントロールに継承させたり、friend の
抜け道をネイティブ側に用意して、マネージドを操作したり、本格的に混合型をサポート
してくれれば、使い方に夢が広がるんだけどねSTLだって、ネイティブとしてキャストして
保持させれば、混合型でマネージドを操作できるだろうし

ただ、相互のデータメンバを保持するだけなら、作りで回避できるからあまり混合型の
メリットは感じないなぁ

それじゃマネージド終焉じゃん。

>>27 どのあたりが？

STLをまともに使えないC++に何の意味があるのか。

だから、結局C++で。必要なところだけ C++/CLIなんだろな。

必要なところって、どこ？

.NETFrameworkを利用するところ。

結局、C++/CLIはラッパーでしか使えないねぇ。

それじゃ、ＣＯＭと変わら（ｒｙ

仕方ないじゃん。
TRONとかいろいろ環境はあるわけで、その中でWinだけ C++/CLIだけでは組めないよ。

あー、翻訳終わったお〜。がんばったよ

うぇねの人？

乙

thx みゅ。どこぞから抗議されたらチキンのように消すんで、適当に見といてくらさい

激しく乙

>>38
キチンと消せよ

>>38
せめてWeb Archiveに残るまでは消さないで。

TextSS　のWindowsXP(Professional)64bit化おながいします

もしくは64bitにネイティブ対応したテキスト置換ソフトありますか？

C++とCLIの統合のまだ道半ばってところなのかね。

>>43　道半ばなんじゃね？
でもネイティブなコードとマネージドなコードが
仲良くできるってビジョンを示した点ではC++/CLI
ってのはかなり意味があるんじゃないかな。

さらに Managed C++ から C++/CLI への移行劇を
見せ付けられて、その道程が険しいってこともわかったし。

ついでながらC++とCOMの統合も目指してくれ

>>45 COM との統合って具体的には？
COM つかうのに言語仕様上の制約ってあったっけ？

クライアントとして使うには#importがあるし、
サーバにはATLがあればまあいいやと思うのだが。

すまん、XBOXが managed になるそうだ。

それは、先代XBOXでしょうか、現行のXBOX360でしょうか？

360だ。ネタ元は、
http://blogs.msdn.com/mswanson/archive/2006/03/23/559456.aspx

それに対するQ&Aのようなコメントは
http://blogs.msdn.com/briankel/archive/2006/03/20/555488.aspx

>45
http://msdn2.microsoft.com/ja-JP/library/ms177101(VS.80).aspx

C++/CLI（っというかMSC++2005EE） でManaged DirectXって使えないのかな？
検索しても見つからないorz
解説されてそうなところ知ってる方いませんか？

SDK入れて参照に追加するだけじゃん

>>53
　#using <microsoft.dirextx.direct3D.dll>
　using namespace microsoft::directx::direct3d;
と入れても
　アセンブリ 'microsoft.dirextx.direct3D.dll' がみつかりませんでした:
って言われちゃうんだよねorz何がいけないんだろう・・・

リンク時の参照に追加してないだけじゃね？

>>55
すいません。#using <>で大文字小文字の区別ができないだけみたいでした。
ありがとうございました。

はどーけん

一週間ぶりの書き込みがそれかよ　もうちょっと考えろよ

普段脳みそ使ってる分の反動ってやつかな…

　　　　　＼ ずどどどーーん
　　　　　　　　　　　　／|[]::::::|_ / ＼/＼＼　　 　　　　　　　／
　　　　 　 　 　 .／|￣￣￣￣ //＼ ＼/　 ＼　　　　　　／/　　　 ＿＿＿
　　　　　　　　　|　 |:::「「「「「「 / ＼/＼　　/＼＼　　　／:::/　 　.／|　　　　|＿＿
　　　　　　　＿..|　 |:::LLLLL//＼ ＼/　　＼/＼＼／::::::/　　／　 |　ロ　 .|lllllllllllll
　　　　 　／ llllll|　 |:::「「「「 / ＼/＼怒/＼ .＼/ ./::::::::/　 ／ .／ .|　　　　|lllllllllllll
＿＿　　　　 llllll|　 |:::LLL.//＼ ＼/涛＼/＼　 /::::::::/ 　 | ／　　.|　ロ　 .|lllllllllllll
　　　　　　　 llllll|　 |:::「「「/ ＼/＼熱　/＼ ＼/　/::::::::/　　 | ||／　..|　　　　|lllllllllllll
　　　　 　 　 llllll|　 |:::LL//＼ ＼/　　＼/＼　./::::::::/　 　 .| ||／　..|
　　　　　　　　　|　 |:::「./ .＼/＼　湯/＼ ＼/ /::::::::/⌒ヽ､ .| ||／　..|
　　　　　　　　　|　 |:::l//＼　＼/　　＼/＼_, -― ､　　''"⌒ヽ,_
　　　　　　　　　　　　　　　　(⌒ヽ､_,ノ⌒Ｙ"　　　　Y　　　　　.....⌒) どーーーーーん
　　　　　　　　　　　　(⌒ヽーﾞ　....::（　　 ..::.......　 .__人.....::::::::::::::::::::
　　　　　　　　　＿ノ⌒ヽ　 Y⌒ヽ;;:::::"':::::::::::::::::::::::::::::　＿＿＿
　　　 　＿＿_(　　 ﾞ　　　....:::.....　　Y"　 ∧＿∧　 　／
　　　／/ ll＿＿ヽ＿::::::::::::::::::::::::::::::ヽ....（　 ´Д｀）＜逃げろ逃げろ！
　　「　　　 ヽＯ≡≡O:::::::::::::::::::::::::::::::::::/ つ　 _つ　 ＼＿＿＿＿
　　ﾞｕ─―ｕ-――-ｕ　　　　　　　　　人

ダブル サンキング
って糞じゃない？
仮想関数使えないじゃん。

C++/CLIのバージョン１というのはC++マネージ拡張のことなのかな？

>>62 C++/CLI にバージョンってあったのか。
Managed C++ → C++/CLI
くらいしか認識してなかった。

Objective-C++/CLI
ﾏﾀﾞｰ?ﾁﾝ､ﾁﾝ｡
//GCCもCLI対応するんだろうか?

Objective-C++ はちょっと意味が分からないな
C++ は C++ でそれなりに Objective だからな

>>64
Objective-C 言語
　　　+
　　C++ 言語
　　　||
Objective-C++

ttp://homepage.mac.com/mkino2/spec/objectiveC++/objectiveC++.html

ここらを見ると、いろんな苦労が共有できる気がするな

Robert Rameyがいらないってんだから要らないんだよ
Sutterも嫌々やってるんですよ

すみません。

Visual Studio2005ですが、MFCのプロジェクトで、
Windowsフォームデザイナで貼り付けられるような
コントロールは使用できるのでしょうか？

またWindowsフォームデザイナで開発した場合は、
.NetFrameworkが必要となり、Windows2000では動作できないなどありますか？

>>69
1.使用できなくはないかもしれないがそれなら正攻法で使ったほうが多分楽
2..NET Framewokは98でも動く。一部2kで使えて98で使えない機能もあるがそれはたいていSDKに依存する問題。

Windows 2000 でも .NET Framework は動くだろ

>>69

正攻法とはどのような方法でしょうか？

また、.NETFrameworkがインストールされていないと
動作しないのですよね？

※すみません。.NETFramework初体験です。

>>72
>正攻法
SDKを使う方法。

>.NE（ｒ
もちろん動作しない。OSがインストールされていないようなもんだ。

>>73
SDKはどのように使えばよいのでしょうか？
お手数ですが、簡単なサンプルとかってありませんか？
もう少し詳細を教えていただけるとたすかります
何しろＭＦＣの標準コントロールは古臭くて。。

>>74
Win32API質問箱 Build42
http://pc8.2ch.net/test/read.cgi/tech/1144962549/

>74
CWinFormsControl を使え
ttp://msdn2.microsoft.com/ja-jp/library/8z4d86s2(VS.80).aspx

というかそもそも何故 MFC なんだろう？

既存のアプリの改良に WinForms を使いたいんじゃね？

>>78

ご名答！！
そもそもVisualStudioの統合環境のツールバーや
メニューバーはどうやってるんだろうと。。

別に何でもかんでもまぜまぜする必要ないじゃん。
混ぜることそのものが目的になってしまってる、みたいな。

>>79 それは全部マネージドなんじゃね？

漏れも手抜きしたくて CWinFormsControl を既存アプリに組み込んだりしたいけどな
さすがに、ユーザーに .net Framework 2.0 を要求できなくてやってないけど

>>79
コントロールは単なるウィンドウを子ウィンドウにしてるだけ。
って言うのは解ってる?

(　´_ゝ｀)

現状のC++ソースをまんまPureCLIに出来ないのが美しくないね。

>>85
災いと引き換えの美しさなんぞいらん。

>>85
むしろこれからはそれを意識したマクロ定義を心がけるべき？

時代に逆行して COM かよ

だから、猛烈にISO化に反対されてるだろ。

災い＝怒涛熱湯
美＝Ｃ＋＋

あの ISO の論議は宗教戦争だよ
C++ だって C とは完全互換性がなくて非互換性の項目作ってるのに、C++/CLI は完全互換じゃ
ないから C++ の名前を使うな、なんて、馬鹿馬鹿しい

C++#にするしかないのか

>>90
逆。
ＣとC++で起きた災いのことだ。

>>91

んなーことはない。互換のない箇所があまりにも C++ を越えてるからな。
誰もが、「C++であれは不味いよ」という実装。

C++の名前は使ってもいいが、正直、ISOにはなって欲しくない。

そうか？　文字列互換性なんて C++ の不始末を便利にしたとこを駄目だとか騒いでるぐらいじゃね
MSのサイトの記述にけちつけて、こいつら営利企業に何求めてるんだ、とか思っちゃったけどな

論争ってなんのことかよく知らないんだけど、
名前に C++ が入ってるのがまずいダロってことになってんの？
まぁ確かにもう少し検索エンジンフレンドリーな名前でもいいかもって気はする。

ま、どっちにせよ、

Windowsのネーミングからはじまり、
J++、J#、managed C++、STL.NETとか、
一般的なものを汚し杉。

そんな、汚すだなんて Java の信者じゃないんだから（ｗ

Bjarne Stroustrup のFAQになってるところがﾜﾗﾀ
ttp://www.research.att.com/~bs/bs_faq.html#CppCLI

ISO UK が強硬に反対していて、その下に ECMA からの回答書も公開されている
ECMA じゃ C++/CLI と C++0x にどうやって巻き込まれないようにするかの調査も
始めてるってさ

ECMA の回答書の最後に、おまいらががたがた言おうともう ECMA 標準であることに代わりは
ねえんだよ、って答えてるとこが笑える

C/C++系を汚すなんて汚杉。
VC++が吐き出すMFCコードからして何語？って感じだった。
ユーザーに変なもん使わせながらM$は別のクラスライブラリ使ってるらしいし。

関係ないがアンダーバーつきまくりの変な修飾子はもう見たくないと思った。

こうやってC++をぐだぐだにすることで、
C#の地位を着々と上げていく作戦なんだな。

何言ってるんだ。 C++/CLI が出てきたせいで、C# がその存在意義を問われてしまったのに

でも、現場では「C++/CLI」と「C++」を完全に切り分けないと仕事にならんのも事実。
ISOにする前に、Mac用の C++/CLIでも出してから言ってくれ、という気分だ。

>>100
おまえさん、そんなこと言ったら、COBAとかCOBA真似 IIS C++ソースなんて見たら目がつぶれるぞ。
MFCなんかは、独自仕様として実装されてるからいいよ。アンダーバー定義でその世界だけで収まってるからな。

しかし、今回の C++/CLI での文字列の扱いはそんなレベルじゃないだろ。
C++の延長線上に C++/CLI があるような ISO 化は止めて欲しいってこった。

C#の存在意義なんて、海外では数年前からいわれてんのに、今頃何言ってンのよ。

>おまえさん、そんなこと言ったら、COBAとかCOBA真似 IIS C++ソースなんて見たら目がつぶれるぞ。

見たい。ＵＲＬ教えれ。


>C++の延長線上に C++/CLI があるような ISO 化は止めて欲しいってこった。

なるほど、ISO化が嫌われてるのね。


>C#の存在意義なんて、海外では数年前からいわれてんのに、今頃何言ってンのよ。

知らなかった。ＫＷＳＫ

>>105
>見たい。ＵＲＬ教えれ。
断る。
comのプログラムを探れ。corbaを参考に ActiveX, COM, DCOMをつくり、その開発メンバーがIISに流れた。
後は自分で探せ。

>なるほど、ISO化が嫌われてるのね。
C++という名前を使うな、という気持ちも理解できるが…、ISOにする必要性は全くない。
MS以外誰も望んでいないからな。

>知らなかった。ＫＷＳＫ
C#を初めとして、その他の多くが失敗したから、「ユーザの望むモノを提供していないンだよ、ボケ社員ども」と方針転換した話は有名。
Vistaで乗るバッチプログラムだって、初めは新しい言語だったのにひっこめて全部作り直す。

そのとき、名言。「すみません。Perl風に作り替えます。」　

MSは既に梶を切ってるのに、古い方針の独善的な仕様でISO化してどうするよ。

>>106
おもしろい情報一杯持ってるね。そういう情報好き。

>comのプログラムを探れ。corbaを参考に ActiveX, COM, DCOMをつくり、その開発メンバーがIISに流れた。

こういうの面白い。さらにＣＯＭのトンデモ文法で作ったＭ＄のアプリサーバなんて装飾子があったら爆笑。

>C#を初めとして、その他の多くが失敗したから、「ユーザの望むモノを提供していないンだよ、ボケ社員ども」と方針転換した話は有名。

方向転換したのはゲイツ氏？

Ｌｏｎｇｈｏｒｎ＠マネージド→Ｖｉｓｔａの方向転換のこと？

>Vistaで乗るバッチプログラムだって、初めは新しい言語だったのにひっこめて全部作り直す。

あの、WinFXスレでマンセーされてたシェル言語？スゲ

自演乙

>>107

だから、corbaを元にしたと言ってるのによ。おかげでIISとC++で組むのは無駄に知識が必要だったりするわけだが。
DON BOXとかsoapに絡んでるから余計に…。
.Netで楽にはなったらしいが。

方向転換したのはゲイツメールじゃない。10年前か!?はゲイツだったけどね。
たしか、そんなに古株じゃないヘッドハンティングされてきた人物だったはず。

方針転換はな、いま口癖のように言ってる Live って奴だ。MSは毎日かかさず Live関連の新機能を発表してるって知ってたか?
まあ、何でもかんでも Live と言ってるって事だけどさ。

とにかく、4/1にエイプリルフールでLiveネタででたジョークでは。shellで ls うつと、存在するファイル名に対応した広告が
ファイル一覧と共に表示される。という奴だった。
マネージド -> Vista なんていう程度の石頭じゃ、これからの10年食っていけないぞ?

レイオジーのこと？

俺はなんだかんだ言っても最後は.NETに落ち着くと思うけどな。
エイプリルフールネタはおもしろい。

＞俺はなんだかんだ言っても最後は.NETに落ち着くと思うけどな。
いや、Ｍ＄がドトネトに決定するかもしれんが、落ち着いたことは過去一度も無いお。
DDE（Win3.1or3.0　1993)
↓
NET　DDE (Win3.1　1994)
↓
埋め込みしたいなぁ．．．
↓
OLE1.0（DDE使用）
↓
OLE2.0=COM　ただし目的はインプレースドキュメント。しかしその背景には本質としてバイナリオブジェクト標準あんどオブジェクト通信の思想あり。この辺で名慮or迷著　InsideOLEあんどIsideOLE2。死者多数。
部品としてVB用のVBX (VB2.0からVB4.0　1995あたり)
↓
COMを使ったOCX (1996あたり）結局コンポーネントビジネスはやんなかったな...
ゲイツがインターネットに熱上げあんどJAVA　Appletはやる (1995）
↓
COMつかってActiveX(1996)
だんだんオブジェクトはやってくる。 （UMLなど1997）オブジェクトもでるとしてCOMの宣伝開始 DCOMなどCORBAとがっぷり。この辺でMTSではじめ
↓
マーケティングてきなWindowsDNA 。MTS2.0それなりに使えそう。つか使った。DCOM糞。(1999)
↓
COM+ （Win2000､2000）In-MemoryDBどこいったゴラァ
COM　Runtimeの情報漏れ始め (2000〜)
↓
セキュリティ→ファイアーウォールのためCOM全滅。しばらくしてから.NETとしてCOMじゃないものに．．．
↓
.NET流行らず(〜2006)
↓
WinFX完成(2007)
↓
オブジェクトベースプログラミングにより、OSは関数コールに戻る(2008)
WinFX下位互換へ

LiveってWinモンリー？

CLR_OR_THIS_CALL

ネイティブとかマネージとかアンマネージとか値とか参照とか
ややこしいっつーの

C#書いてるときに比べてC++/CLI だと IDE が明らかに遅いんだけど。。。
ボタンを設置してダブルクリックして、イベントハンドラのスケルトンができるまでが明らかに遅い。

パソコン買い換えろよ。ボロイのいつまで使ってんだよ。

買い換えても、遅いモノは遅いぞ。相対的なものだからな。

まあ、十分に早くなれば差に意味が無くなるだろう
……ネイティブとCLIの縮図のようだ

System::Runtime::InteropServices::PARAMFLAG::Outって何？
System::Runtime::InteropServices::OutAttributeに変えてもいいの？

ECMAから公開許可をもらったぜ
消す必要はなくなったから、安心してくり

>>120
おお、めちゃ乙。

ECMAって心が広いんだね

ちがうよ、必死なんだヨ。

STL.NETどこイっちゃたの？

思いつきで適当なもん作ってはお蔵入り

今はSTL/CLIだよね。

出てもJavaの新しいcollectionみたいな仕様のクラスライブラリで、
method等の名前がSTL風になっているだけだろうけど。
STLはC++の言語仕様にかなり依存しているから。

なんにしてもそれどころじゃないみたい。
http://blogs.msdn.com/nikolad/archive/2006/02/07/527193.aspx

しかし、すげー、過疎スレだなw

話題がないのにだらだらだべるなんて苦痛だからね
正直、STL/CLI は C++/CLI にとって不要な要素だと思ってる
作るだけ、無駄。だから、あまり力を入れていないのは正解じゃないかな

そうだなあ。
ManagedなobjectをSTLで扱う時のTIPSでいいかな。

コンテナ程度の対応をするより、0x への対応をしっかりとやって欲しいのですよ
それらの要素をどう C++/CLI に持ち込むかの方が重要だと思う

System.Collections.Generics.Listのイテレータを作ってみたことがあるんだ。
最初はそのイテレータも参照型にしたんだけど、Visual C++付属の<algorithm>の関数は、
デバッグ用か何かの仕掛けがあって、ネイティブ型しか受け付けてくれなかった。
結局そのイテレータに対するネイティブ型のラッパを作ってやったんだ。

逆に言えばマネージ型のイテレータがVC++付属の標準ライブラリで使えれば、
STL/CLIなんてなくても自分たちで勝手にイテレータを作ったりして使うことは容易だと思う。

素直に混合型を実現してマネージドとネイティブを継承した型を使えばと・・・

それ、ふつーのネイティブ。

実践C++/CLI
ttp://www.amazon.co.jp/gp/product/4797336277/249-7078532-9380326?v=glance&n=465392

を買った人いる？　どんな感じ？

本屋で立ち読みしてみるのが一番手っ取り早いかと

手っ取り早いどころか、立ち読みしてから買わないと危険な香りがするな。

立ち読みした。実践じゃなくて、実際だな。内容的には。
本の後半で、Visual Studioのダイアログでの指定方法とか書かれてる。

つーか、最近、ソフトバンククリエイティブの本はタイトル詐欺が多すぎ。
噂の真相うんちゃらかんちゃらも、タイトル買いしたら内容は単なる手記だったしよ。

表紙だけ素晴らしくて内容がｳﾝｺなエロ同人誌みたいなもんか

買って読んだが、ちと微妙なできだな
C++/CLI に踏み込んだ記述は少なく、既存の VC++ の開発者向けに .net を使うための
チップス集といった感じだった
記述するべき知識が広範囲すぎて、なるべくいろいろ網羅しようとがんばっているのは
感じたが、前提知識があるものと記述されている部分が多くて、これはさらりと書かれている
部分がわからないのでは、と疑問に感じた

>>137
> 最近

笑うところ?

ページ数が少なすぎるね

C++/CLI 気に入ったんだが、リファクタリングできないのがつらいなぁ。

デバッグでトレースが重いのが致命的だよ・

.NETと無縁の仕事ばかりやってたので思いつきでCLIでもやって
みようと思って買ってみたよ。
ダイヤモンド継承の問題点とかでてきてちょっとなえるが、まあ
もうちょっと読んでみるよ。
Win32と.NETが同時に使えるのはツールとかちょっと作るのには
便利なのかなあくらいに思ってるよ。製品開発に使えるとはまだ
ちょっと思えないけど。。

>>144
去年、C#の案件をやったんだが「ああ、あの時C++/CLIが出てればなぁ」とは思う。

これ読んだ人いる？
ttp://www.amazon.com/gp/product/1590596404/ref=sr_11_1/104-8510614-7138345?ie=UTF8

>>145
Ｃ＋＋　＞　（壁）　＞　Ｃ丼
ということ？

>>147
ヒント：DllImport

今は逆にC++（ただしネイティブ）の案件やってるが「これがC#だったらもっと楽なのに」と思いながらコード書いてる。

BStrWrapper ってどうやって使うんでしょうか？
ググっても、ひっかかりもしねぇっす。

こんにちは。質問です。

VC++EE使ってます。
system以下のライブラリを網羅したページってないですか？
C#やVBで解説されててもかまわないのでどこかご存知ありませんか？

MSDN

検索で引っかからなかったけど、MSDN普通にもぐってったらあった。OTL
なんでMFCなのかわからんけど、見つかってよかった。

ttp://msdn2.microsoft.com/ja-jp/library/ms306608.aspx

>>152
>MSDN ライブラリ > .NET 開発 > .NET Framework SDK > MFC リファレンス
うは、ほんとだｗｗｗ

あまり使ってる人もいないんだろうけど、ごめん、鯖が消えてた(´･ω･`)
引っ越したので、こちらを参照してください

ECMA-372仕様書
ttp://mdjowbnb.sv05.fsdotnet.net/ecma372/StartingState.aspx

>>154
乙です。お世話になってます。

C++/CLI で作ったクラスライブラリって、CLR Profiler 通る？
CLR Profiler いつも落ちるんだけど。

/clr:pure 状態でも？

/clrでコンパイルしたときにアンマネージコードの生成が

『〜〜用にネイティブ コードの生成が発生します』
と自動的に適用される場合と、

『この関数はマネージとしてコンパイルできません。#pragma をアンマネージで使用してください』
と明示しなければエラーになる場合があるんだけど、

両者の違いって分る人居ますか？

ISOは賢明な判断をしたな

>>159

くわしく。

これか
ttp://blogs.wankuma.com/episteme/archive/2006/09/12/38394.aspx

これかな?
http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=42926

間違えた orz
http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=43913&scopelist=PROGRAMME

ま、駄目だった物は駄目、ということで

まあ駄目で当然という気がする。
仕様が汚すぎる。上位互換じゃないのも(C++を名乗るには)問題。

ちょっとホッとした。本当に賢明な判断だ。

どっちの味方なんだよ

最終的にまともなのになってくれれば過程はどうでもい

C++をマネージ拡張するのもいいんだけど、
C#をアンマネージ拡張して欲しいと思うときがある。
まあ、DllImportすればいいんだけど。

よくねーよ。
でもMSが持ってるNativeMethods.cs公開してくれたら、それでいい気がする。

俺もそれほしい
PInvoke.net が不要になっちゃう

結局、/CLIは今のところ使わない方が良いって事だなぁ…。

sage

C++/CLIって結局微妙ってこと？
＠IT：特集：Visual C++ 2005　いままたC++が熱い！「C++/CLI」として大進化したVisual C++ 2005
http://www.atmarkit.co.jp/fdotnet/special/cppcli/cppcli_01.html
これとか見ると随分興奮しているけど

>>174
ヒント: 川俣 晶

海外だと、C++/CLIは凍るほど冷えてる。

>>176
そうなんかぁ〜？

DllImport関係のNativeMethod系以外に結局何が素敵なの？ C++/CLIって
>>145
(言語熟練度はプロジェクト要員の平均レベルでC++/C#ができるものとして）
Manageなコード中に簡単にネイティブっぽいものが書けちゃうと逆にメンテし辛いものにならないのかな。

ところで、C++/CLIってC#3.0みたいな機能って予定されてるの？

ネイティブの方が圧倒的に多かったり、
XP用のポーティングをしたり、
いろいろ便利なケースは想定できるでしょ?

どこまで厚くサポートされるかは分からない。
STL.NETみたいに辞めちゃったプロジェクトもあるし、
C++/CLIの人員削減はあり得ることだと思う。

STL.NETはやめてはいないだろ。
OrcasのCTPにSTL/CLRが入っている。
どんなもんかまだ俺は試していないけど。

void func (String* str1, String* str2, String* str3) {
  String* str;
  str = System::String::Concat( str, str1 );
  str = System::String::Concat( str, '\0' );
  str = System::String::Concat( str, str2 );
  str = System::String::Concat( str, '\0' );
  str = System::String::Concat( str, str3 );
  str = System::String::Concat( str, '\0' );
  str = System::String::Concat( str, '\0' );
}

func("aaa","bbb","ccc");

上記で、"aaa\0bbb\0ccc\0\0"という値を期待していたのですが、\0が消えて"aaabbbccc"となってしまいます。
助けてください

void fucn(string a, string b, string c) {
  string ret = "";
  ret = System.String.Concat( ret, a );
  ret = System.String.Concat( ret, '\0' );
  ret = System.String.Concat( ret, b );
  ret = System.String.Concat( ret, '\0' );
  ret = System.String.Concat( ret, c );
  ret = System.String.Concat( ret, '\0' );
  ret = System.String.Concat( ret, '\0' );
}
func("aaa","bbb","ccc");

あと、C#で上記のようにやった場合は期待通りの値になっているようです。
本当はC#で全部やろうと思ったのですが、C#でWin32APIの呼び出しが解らなくてC++/CLI使ってみました。
そのAPIの引数が、"aaa\0bbb\0ccc\0\0"という形式で指定しろとなっているのですが、
今度は引数が生成できなくて填ってます。

>>182
やったこと無いんだが、
見た感じ、strcatと同じ動作に見えるね。

オペレータの＋ってないの？

>>183
ret += a;
今、上記のようにやってみたのですが、下記のエラーになってしまいました。。。

error C2297: '+=' : 無効な右オペランドです。
error C2845: '+=' : __gc ポインタ 'System::String __gc *' に対してポインタ演算ができません。

CLIは素人なのではずしてたらごめんね。
で、これ通ったよ。

using namespace System;

int main(array<System::String ^> ^args)
{   
    String^ A="Hello";
    String^ B="World";
    String^ C="";
    C=A+B;
    Console::WriteLine(C->ToCharArray());
    return 0;
}

と、ここまで書いて見落とし発見・・・。
なんだ、普通のstd::stringか？
ちょっとまってて。

皆さん、ありがとう。
下記のようにして何とか動きました。

voidfunc(String*str1,String*str2,String*str3){
 LPTSTRpArg;
 LPTSTRpStr1=(LPTSTR)Marshal::StringToHGlobalAnsi(str1).ToPointer();
 LPTSTRpStr2=(LPTSTR)Marshal::StringToHGlobalAnsi(str2).ToPointer();;
 LPTSTRpStr3=(LPTSTR)Marshal::StringToHGlobalAnsi(str3).ToPointer();;

 intlen=0;
 len+=lstrlen(pStr1);
 len+=1;
 len+=lstrlen(pStr2);
 len+=1;
 len+=lstrlen(pStr3);
 len+=1;
 len+=1;

 pArg=(LPTSTR)malloc(len);

 len=0;
 memcpy(&pArg[len],pStr1,lstrlen(pStr1));len+=lstrlen(pStr1);
 memcpy(&pArg[len],"\0",1);len+=1;
 memcpy(&pArg[len],pStr2,lstrlen(pStr2));len+=lstrlen(pStr2);
 memcpy(&pArg[len],"\0",1);len+=1;
 memcpy(&pArg[len],pStr3,lstrlen(pStr3));len+=lstrlen(pStr3);
 memcpy(&pArg[len],"\0",1);len+=1;
 memcpy(&pArg[len],"\0",1);len+=1;

 func(pArg);
 free(pArg);
}

ミスった・・・

voidfunc(String*str1,String*str2,String*str3){
 LPTSTR pArg;
 LPTSTR pStr1=(LPTSTR)Marshal::StringToHGlobalAnsi(str1).ToPointer();
 LPTSTR pStr2=(LPTSTR)Marshal::StringToHGlobalAnsi(str2).ToPointer();;
 LPTSTR pStr3=(LPTSTR)Marshal::StringToHGlobalAnsi(str3).ToPointer();;

 int len=0;
 len+=lstrlen(pStr1);
 len+=1;
 len+=lstrlen(pStr2);
 len+=1;
 len+=lstrlen(pStr3);
 len+=1;
 len+=1;

 pArg=(LPTSTR)malloc(len);

 len=0;
 memcpy(&pArg[len],pStr1,lstrlen(pStr1));len+=lstrlen(pStr1);
 memcpy(&pArg[len],"\0",1);len+=1;
 memcpy(&pArg[len],pStr2,lstrlen(pStr2));len+=lstrlen(pStr2);
 memcpy(&pArg[len],"\0",1);len+=1;
 memcpy(&pArg[len],pStr3,lstrlen(pStr3));len+=lstrlen(pStr3);
 memcpy(&pArg[len],"\0",1);len+=1;
 memcpy(&pArg[len],"\0",1);len+=1;

 func(pArg);

 free(pArg);
}

>>181お前それC++/CLIではなく、マネージドC++だろ。
とりあえず、こうすると.NET 2003の/clrと2005の/clr:OldSyntaxで動く（実行するとaaaしか表示されない）。
#using <mscorlib.dll>
#include <vcclr.h>
#include <windows.h>
#pragma comment(lib, "user32.lib")
void func (System::String* str1, System::String* str2, System::String* str3) {
  using System::String;
  String* str;
  str = String::Concat(str, str1);
  str = String::Concat(str, S"\0");
  str = String::Concat(str, str2);
  str = String::Concat(str, S"\0");
  str = String::Concat(str, str3);
  str = String::Concat(str, S"\0");
  str = String::Concat(str, S"\0");
  const wchar_t __pin* p = PtrToStringChars(str);
  ::MessageBoxW(0, p, L"", MB_OK);
}
int main()
{
  func("aaa","bbb","ccc");
}
まあAPIの相手をするならchar配列のほうが楽。
>>187 せめてsprintf使え。あとLPTSTRをマルチバイト文字列に使うな。

こらこら、ANSI文字列のポインタをLPTSTRで受けちゃダメだぞ。

…なんだか口は悪いけど親切なお兄さんと結婚することになりそうです。

>>188
動きました！

名前欄まちがえた

あと、Marshal::StringToHGlobalAnsiで確保したメモリを開放していないな。

方法は幾通りもある。あんマネージ文字列への変換はCString （ATL/MFC 7以上）使うのと結構楽。
TCHARも適当にやってくれるし。
#using <mscorlib.dll>
#include <atlstr.h>
#include <windows.h>
#pragma comment(lib, "user32.lib")

void func (System::String* str1, System::String* str2, System::String* str3)
{
  using ATL::CString;
  CString cs1(str1), cs2(str2), cs3(str3);
  CString arg;
  arg.Format(TEXT("%s\0%s\0%s\0"), static_cast<PCSTR>(cs1), static_cast<PCSTR>(cs2), static_cast<PCSTR>(cs3));

  ::MessageBox(0, arg, TEXT(""), MB_OK);
} 

>>186-188
ほかの方法があったか。
色々考え出したら止まらなくって困ってたとこだった。
役に立てなくてすまない。

#include <string>
#include <iostream>
int main(array<System::String ^> ^args)
{
    std::string A="BMP",B="Wav";
    std::string C="";
    
    C=A+'\0'+B+'\0'+'\0';
    std::cout<<C<<std::endl;
    //std::cout<<C.c_str()<<std::endl;

    return 0;
}

こういう感じの想定してた。＠VC2005EE

>>193の方法は短いですけど、>>188の方が見やすそうなので、使わせてもらいました。
色々勉強になりました

CLIだが最終的にこんなんなった。

std::string func(String^ str1, String^ str2, String^ str3)
{
    IntPtr ptr1 = System::Runtime::InteropServices::Marshal::StringToHGlobalAnsi(str1);
    IntPtr ptr2 = System::Runtime::InteropServices::Marshal::StringToHGlobalAnsi(str2);
    IntPtr ptr3 = System::Runtime::InteropServices::Marshal::StringToHGlobalAnsi(str3);

    std::string result = std::string()
        + reinterpret_cast<const char *>(ptr1.ToPointer()) + '\0'
        + reinterpret_cast<const char *>(ptr2.ToPointer()) + '\0'
        + reinterpret_cast<const char *>(ptr3.ToPointer()) + '\0'
        + '\0';

    System::Runtime::InteropServices::Marshal::FreeHGlobal(ptr1);
    System::Runtime::InteropServices::Marshal::FreeHGlobal(ptr2);
    System::Runtime::InteropServices::Marshal::FreeHGlobal(ptr3);

    return result;
}

>>195
せめてStringBuilder使え。

ふつうに wstring 使った方が早くね？

String::Format 使えばいいと思う……

>>199
>>193で出たものの、>>195で却下された。

個人的には(作成理由から読むに) C# で DLLImport の方法を探した方が遥かに楽だったんじゃないかという気がするけど。

色んな選択肢を使える懐の深さが C++/CLI の一つの魅力なわけだし、
最速/高効率よりも、本人が理解/吸収しやすい手法を取るのが最良だと思う。

さすがに、それを最良と言い切るのはおかしいな。
言いたいことはわかるが、言葉の選択を誤ってるね。

http://www.rupan.net/uploader/download/1167834884.zip
PASS: CLI

>>203
これってなんだったの？

仕様書のスキャン画像

C++/CLIでWPFの開発できないの？

できないほうが不思議

IDEのサポートがあるかどうかは別問題だけどね。

C++/CLIでのWPF開発ではIDEのサポートは無いの？

XAMLPadで十分じゃん
どうせUIはC++じゃなくてXMLで書くんだし

Visual Studio 2007(2008?)には標準で入るはず。

literalって何のために追加されたの？
constでいいじゃん。

>>212
よく知らんが、名前の通りリテラルの為なんじゃないのか？

いやだってManaged C++ではstatic constで済んでいただろ。

フィールドにCILで言うところのliteral属性をつけるか否かを区別できるようになった

Managed C++ではunmanagedなものとの区別があいまいだったから、
出来るだけ違う名前を付けるようにしたとかそんなのじゃないの？
参照周りとかgcnewとか見ててもそういう思想に見えるんだが

流れぶった切って申し訳ないですが、質問です。

C++/CLIで、既存のネイティブ関数をラップして、
public ref class Test
{
public :
static void show( System::Int32^ x ) {}
static void show( System::Double^ x ) {}
};

というようなクラスを作って、C#から

static void main()
{
Test.show( 1 );
Test.show( 2.0 );
}

という風にオーバーロードして呼び出たんですが、
次のメソッドまたはプロパティ間で呼び出しが不適切です: 'Test.show(System.ValueType)' と 'Test.show(System.ValueType)'
というエラーがでて、コンパイルできませんでした。

エラーをみると、引数のSystem::Int32とSystem::DoubleがSystem::ValueTypeになってる
っぽいんですが、正しくラップするにはどういう風に書くんでしょうか？

＾

>>217
そういうこと。値型はハンドルを使わず生の型を使え。

C++/CLIで値型へのハンドルはボックス化の扱い。
IL上の引数・戻り値は、System.ValueType（これ自体は参照型）となる。
http://vene.wankuma.com/ecma372/33_cli_library.aspx#SS.33.1.5.1

基の型の情報も記録しているので、IL上は多重定義可能で、
C++/CLIでもコンパイラがそれを認識して多重定義解決を行う。
しかしC#コンパイラはそれを知らないので、
単にSystem.ValueTypeを1つ引数に取るメソッドshowが2つあるとしか認識できない。

>>218-219
なるほど。
解決しました！ありがとうございます。

○コンストラクタ
StreamReader^ FormDataReader = gcnew StreamReader("FormData.txt", System::Text::Encoding::GetEncoding("shift-jis"));

String^ locationX = MainFormDataReader->ReadLine();
String^ locationY = MainFormDataReader->ReadLine();
String^ SizeW = MainFormDataReader->ReadLine();
String^ SizeH = MainFormDataReader->ReadLine();

locationX = locationX->Substring(locationX->IndexOf("=") + 1);
locationY = locationY->Substring(locationY->IndexOf("=") + 1, locationY->IndexOf("}") - locationY->IndexOf("=") - 1);

SizeW = SizeW->Substring(SizeW->IndexOf("=") + 1);
SizeH = SizeH->Substring(SizeH->IndexOf("=") + 1, SizeH->IndexOf("}") - SizeH->IndexOf("=") - 1);

this->SetDesktopBounds(int::Parse(locationX), int::Parse(locationY), int::Parse(SizeW), int::Parse(SizeH));

MainFormDataReader->Close();

//最初の表示位置を記録
this->OnResizeEnd(nullptr);

○デストラクタ
StreamWriter^ FormDataWriter = gcnew StreamWriter("FormData.txt", false, System::Text::Encoding::GetEncoding("shift-jis"));

MainFormDataWriter->WriteLine(this->WindowState);
MainFormDataWriter->WriteLine(LocationString->Replace(",", "\r\n"));
MainFormDataWriter->WriteLine(SizeString->Replace(",", "\r\n"));
MainFormDataWriter->WriteLine(splitContainer1->SplitterDistance);
MainFormDataWriter->WriteLine(splitContainer2->SplitterDistance);

MainFormDataWriter->Close();

○初期設定
String^ LocationString;
String^ SizeString;
this->ResizeEnd += gcnew System::EventHandler(this, &MainForm::MainForm_ResizeEnd);

○フォームのサイズと位置を取得する
private: System::Void MainForm_ResizeEnd(System::Object^ sender, System::EventArgs^ e) {
LocationString = "" + this->Location;
SizeString = "" + this->Size;
}

長かったので分割してカキコしました
今日出された課題でフォーム位置を記録するという物があったのですが、どうしても汚くなってしまいます。
もう少し効率の良いフォーム位置の記録方法はありませんか？

なんつうかきったねえな、おい。

Hashtableに格納してシリアライズするとか、
シリアライズ可能な構造体を定義してそれを保存するとか、
自前で読み書きするにしても、せめて、生の整数値で保存しろよ。

>>223
ご指摘ありがとうございます

>自前で読み書きするにしても、せめて、生の整数値で保存しろよ。
苦肉の策で、無理矢理保存してました（汗

String^ a = "a";
String^ b = a;
a = "b";

これでbが"b"にならないのはどういう仕組みなんでしょうか？
いろいろ調べましたが結局わかりません。

int n = 1;
int* a = &n;
int* b = a;

int m = 2;
a = &m;

で b が 2 になりません、って言ってるのと同じこと。

間違えた。*b が 2 に、だった。

>>226
ありがとう。なんかぼけてました。(;´Д｀)

（ﾟДﾟ）

致命的なエラーです。 (HRESULT からの例外: 0x8000FFFF (E_UNEXPECTED))

という警告がデザイナーで急に頻繁に表示されるようになってしまったのですが、
どなたか解決策をご存じありませんか？

コンパイルはちゃんとできるんですけど...

言語伝々自体にドトネトコード自体がお呼びじゃないからな。

誤爆け？

でんでん？
云々の間違いなんだろうが、どうすればそんな間違いが起こるんだｗ

＞伝々
思わずふいてしまた

treeViewの再描画を一時停止したいんだけどどうすれば良いの？

初めまして、VC++のC++/CLIのフォームアプリケーションについて質問があります。

今、LimeChat 2 の様なアプリを作っていています。
そのアプリのテキストボックスには、カーソルが表示されていません。
どのようにすれば、カーソルを表示させないようにできるのでしょうか？

また、TreeViewの再描画を一時停止させたいのですが、どうすればよいのでしょうか？

再描画のハンドラをオーバーロードして
止めたいときだけ無視する。

自己解決しました！
>>また、TreeViewの再描画を一時停止させたいのですが、どうすればよいのでしょうか？
treeView->BeginUpdate();

キャレットが出無くなればいいわけです
Win32 APIにHideCaretという関数があるのですが、C++/CLIではどうしても見つけることができませんでしたorz

iconv (iconv_t cd, const char* * inbuf, size_t *inbytesleft, char* * outbuf, size_t *outbytesleft);

この関数のinbufにString^を渡したいのですがうまくキャストできません。

pin_ptr<const wchar_t> pIn = PtrToStringChars(in);
pin_ptr<const char> pInPass = pin_ptr<const char>pIn; // error

iconv(cd, &pInPass, &inlength, pOutPass, &outlength) )

どうやってキャストすればいいのでしょうか？

pInの段階で既にpinされているのだから、後は普通のC++と同じように
const char* pInPass = reinterpret_cast<const char*>(pIn);でいいと思う。

だれか、ニューメリカルレシピインシーっていう本やったことある人いませんか（？？）

>>239
http://msdn2.microsoft.com/ja-jp/library/1b4az623(VS.80).aspx
String^からstd::stringにしてc_str()で渡せば。

>240
できました。ありがとう。

>242
できればコピーしないでやりたかったので。

こんなものC++の標準が改定されたら置いてきぼりになるじゃんか
志ねMS

C++/CLIはC++ではないと何度言ったら分かるんだね。

C++自体がC99から置いてきぼりになってますが何か？


でもってC++/CLIも世界標準規格のわけだが

世界標準言ったって、盲判で有名なECMAだろ？
ちょっとまえにISOに蹴られたばっかじゃん。

実装がひとつしかないのに世界標準とかいわれても非常に困る

っ Mono

>>249
だから一つしかないんだろ？

MonoにC++/CLIコンパイラなんてあったの？

いずれできる

>246
はあ?　ISOに蹴られてるだろ?　どこが世界標準規格なんだよ。
嘘もいい加減にしろ。

http://www.ecma-international.org/publications/standards/Ecma-372.htm

無知は黙っとけ
おっとお子ちゃまに英語は読めないかなw

>>254
あれ？　なにそれ？　なんで普通になんの制限もないPDFがダウンロードできるの？
単にECMA規格がそーゆーもんなの？　それともドラフトかなんか？

標準規格に制限かける標準化団体はいね。

もう、C++/CLIは死に体。

>>256
IEEE

CLIもDも
C++0xへの叩き台なので問題ない

>>256
ISO も JIS も普通に金取られるぞ

ANSIも

規格がみんな無料で閲覧できるようになればいいのに

コストはともかくトラフィックで死ねるからやらないんだろうけど

いらないものをさも必要があるかのように作って無駄にはやらせようとするM$は死ねばいいのに

開発者に対してろくなアプローチをしないところよりはまだマシさ。

>>263
禿は「ライブラリで出来るところはライブラリでやれよ。
テンプレートで出来るだろ」という見解だったな。
というわけで、ISOでは蹴られ続けるだろうな。
実際5月のミーティングでも駄目だったし。

VC++2005です。
メインフォーム上に置いたコントロールのWndProcをオーバーライド
したいんですが。普通に継承して、メインフォームのコードを書き換えると、
フォームデザイナーがうまく機能しなくなってしまいます。

フォームデザイナをちゃんと動かすためにはいろいろ大変みたいで
できればやりたくないです。もっと簡単にWndProcをオーバーライド
する方法はないでしょうか？

結局、C++/CLIとC++でいつでも分離できるように実装するしかないんだよな。
C++/CLI側は「まだ実装するべき機能はあるから、追加しちゃうよ」とかほざいてるし、
標準じゃないのはいらねぇよ。

about C# Mono
Mono C# compiler version 1.2.2.1

C# Language Specification ECMA-334

Common Language Infrastructure (CLI) ECMA-335

Home Page: http://www.mono-project.com/

Download: http://www.mono-project.com/Downloads

で？

>>268
君さ、何か勘違いしてる気がするよ。

C++/CLIで作ると移植性が落ちる。

ポートも糞もないだろｗ

質問です。

　using namespace System;
　using namespace System::Collections::Generic;
　
　ref class HogeItem;
　
　generic<typename CItem>
　where CItem : HogeItem
　ref class HogeList;
　
　public ref class HogeItem abstract {
　internal:
　　HogeList<HogeItem^>^ list;
　};
　
　generic<typename CItem>
　where CItem : HogeItem
　public ref class HogeList abstract : IList<CItem> {
　public:
　　virtual void Insert(int index, CItem item) {
　　　item->list = this;　　　　←ここでエラー
　　}
　};

HogeItem::list の型は HogeList<HogeItem^>^ なんですが、this が HogeList<CItem>^ なので
変換できないって怒られます。
IList<HogeItem^>^ とかにしてもだめでした。
generic の宣言のほうを変更しても良い方法が見つからず、困っています。

item 側にどの List に格納されたのか知らせる手段がほしいのですが、
うまい方法は無いでしょうか？

＞271 名前： デフォルトの名無しさん [sage] 投稿日： 2007/05/31(木) 20:47:23
＞C++/CLIで作ると移植性が落ちる。

だから世の中の０＄や重要なソフトはC++なのさ。

>>273
item->list =　(HogeList<HogeItem^>^) this;

HogeListは事実上HogeItemの派生クラス専用なのだから、
IList<T>の継承じゃなくてListを包含してしまったほうが楽だと思うけどな。

ネイティブのクラスがハンドルを持てないのはなぜ？

ハンドルはGC管理領域を指すマネージドポインタだから。

>>277
それは織り込み済みです。

ベンダーはECMAを見るだろうからISOとか関係ないっしょ

いや、ベンダーって、誰が実装するのよ？

>>276
ネイティブクラスのインスタンスは、マネージヒープ・スタック以外に作られる可能性がある
しかし、CLRのGCは、自身が管理するメモリ以外を見ない
だからネイティブクラスはハンドルを持てない

おとなしくmsclr::gcrootを使いなさいということ

>>281
ありがとう。
つまりネイティブヒープ上にあると、ハンドルがGC対象にしていいか追跡
できなくなるって理解しました。

gcrootなんてあったんですね。調べてみます。

CreateFileとかCloseHandle呼べばいいんでは？

審議中
　　　 ∧,,∧　 ∧,,∧
　∧ (´・ω・) (・ω・｀) ∧∧
(　´・ω)　Ｕ) ( つと ﾉ(ω・｀ )
｜　Ｕ (　　´・) (・｀　　)　と ﾉ
　ｕ-ｕ （l 　　 ) (　　　ﾉu-ｕ
　　　　 `ｕ-ｕ'.　`ｕ-u'

>>279
つーか、ECMAに最初だけ登録しておいて、
以後のバージョンアップは放置ってのがMSの手法。
で「仕様は公開されてますよ、オープンです」って言う。

C++/CLIで作ったら、各部署、それぞれから大ブーイングだぜ。

C#はJIS通ったんだが

>>286
なんで？

>288
ソースが転用できねーじゃねーか。ぼけ、死ね、くたばれ。
って言われる。

ネットワークドライブ上のファイル　X:\あああああ\いいいいい.txt
があり、ファイル名は日本語とします。

また、ファイル名としてconst char*を受け取るライブラリの関数libfuncがあります。
これは変更不可です。

英語XPでこのlibfuncにパスを渡すいい方法はないでしょうか？
以下のようなコードだとconst char*に変換するとき X:\??????などと
なり、読み込み不可になってしまいます。

String^ filename = L"X:\\あああああ\\いいいいい.txt";
System::IntPtr pp = StringToHGlobalAnsi(filename);
const char* afilename = (const char*)pp.ToPointer();
libfunc(afilename);
FreeHGlobal(pp);

shortpathを使う方法も思いついたのですがGetShortPathNameWで変換しても
X:\ああ~1\ などとなり日本語が残ってしまうためconst char*にうまく変換
できません。

続きです。
さらにもし可能なら、英語版windows98でも動くようにしたいです。

PtrToStringCharsの戻り値をpinして、
自分でWideCharToMultiByteやその他の手段でマルチバイト文字列へ変換
その際マルチバイト文字列の文字コードにShift_JIS (CP932)を指定

XP (NT)なら、Unicode対応でないプログラムの言語の設定（コントロールパネル→地域と言語のオプション→詳細設定）
で日本語を選んでおけばこれで動くと思う。あるいはAppLocaleで個別指定する手もある
98 (9x)は無理

String^ temp;

^って、なんの意味があるんですか？

ポインタ

ハンドル

>>294
ポインタ？

String* temp;

はなくなったんですか？

>>295
すいません、よくわかりません。

ハンドルで分からないなら managed なポインタと思っとけばおｋ

>>297

有難う御座います。
そのように思っておきます。

>>293
C++/CLI の変更点くらい確認しようぜ

ヘルプで C++/CLI Version 2, マネージ拡張 から
変更の概略を見れば出ている

でも、ぶっちゃけ、CLIにメモリ管理を任せる意味はあるのか。

>>300
DLLをまたいでオブジェクトが行き来しても、
メモリアロケータが違ってあぼんとかしないのはイイよ。
もちろんネイティブC++だってわかっている人が使えば問題ないんだけど。

ヘッダファイルにnew書いててそれがDEBUG_NEWに置換されて死亡とかイヤ過ぎる。
ttp://forums.microsoft.com/MSDN-JA/ShowPost.aspx?PostID=1641869&SiteID=7

>301
その為に共有メモリってのがあったわけだが…。

ちょっとコスト対効果のバランスが悪い理由な気がする。

>>302
共有メモリはプロセス間でメモリ共有したいときのものだと思うけど。
DLLはもとからメモリ空間共有してるわけだし、
メモリ共有で何を解決するつもりなのかサパリワカラン

>>303
DLLのスタティック領域がプロセス間で共有されてたのはWindows 3.1時代の話だぜ

>>292
ありがとう。
しかし290の例の日本語は他の言語の場合もあり、またはUnicodeでしか
表わせない混合型の場合もあるので、もっと根本的な解決法があれば
いいんですが。

根本的な解決があるとすれば、そのライブラリをどうにかするしかない
ハンドルやファイルポインタ・ストリーム辺りが渡せればだいぶましなんだが

アンマネージドで格納したバイト配列をcli::array<unsigned char,1>にしたいのですが、
どうすればいいのでしょうか？

int size = 1024;
byte *buf = new byte[size];

cli:array<unsigned char,1> ^arr = gcnew cli:array<unsigned char,1>(size);
System::Runtime::InteropServices::Marshal::Copy((IntPtr)buf, arr, 0, size);
//ここでエラーになる。

IntPtrをSystem::IntPtrにしたこと以外はそのままでも問題なさそうだし、
実際試しに動かしてみても問題なかったぞ

>>308
ありがとうございます。
すみません。問題は別のところにありました。
実際は*bufは関数でネイティブに渡していて、そこにそのまま渡していたという初歩的なミスです。

void nativefunc(byte **buf_p, size_t *size) {
//--- nativefunc(byte *buf_p, size_t *size) これで宣言していた
*size = bitmap.size;
byte *data = new byte[*size];
memcpy(//--- データ書き込み
*buf_p = &data[0]; //--- cliのbufのアドレス書き換え
}

void clifunc() {
　size_t size;
byte *buf;
(new NativeCls)->nativefunc(&buf, &size);
//--- nativefunc(buf, &size); そのまま渡していた
cli:array<unsigned char,1> ^arr = gcnew cli:array<unsigned char,1>(size);
System::Runtime::InteropServices::Marshal::Copy((IntPtr)buf, arr, 0, size);
}

String a("A");

これがコンパイルできないのはなぜですか？

error C3149: 'System::String' : トップレベルの '^' なしに、この型をここに使用することはできません

トップレベルの '^' なしに、この型をここに使用することはできないから。

>>311
その理由を聞いています。

仕様だからとしか

仕様ですか。しかしObjectやStringBuilderなどは^がなくてもOKなので、
Stringのみ特別な事情があると理解すればいいでしょうか？

MSDNには対象外としか書いてないね。
The following reference types are not available for use with stack semantics:
delegate / array / String

予想だけどこれらはIDisposableでないので出来ても意味が少ない。
出来たとしてもハンドルに変換しないと使えない。
String s("A");
String^ x = "abcd" + %s;
String^ x = "abcd" + s.ToString();

>>315
ありがとう。
使い道がないということで理解しようと思います。

delegateは知らんが、arrayやStringは.NET ILレベルで特別扱いしてるからかもな。

VC2005でデバッグしてるとステップ実行で変なところを
さしてしまう場合があってデバッグしづらいんですが
直す方法はありますか？

nop命令があってそこでへんなとへこいきます。

GUIなアプリケーションを作るために
C#の「Windowsアプリケーション」プロジェクトでいくか
C++/CLIの「Windowsフォームアプリケーション」プロジェクトで行くか悩む。

アンマネージドなC++クラス（とboost）で書かれたCUI
アプリケーションのGUI版を作ろうとしています。
C# でもアンマネージドな DLL のエントリを呼び出すことできますし。

でもアンマネージドな C++ のクラスを使いまくりたいんだけど
どうしたものか・・・ COM コンポーネントとして作られていれば
容易に扱うことができたのかもしれないけど。

アンマネージドな C++ で書かれたクラスのインスタンスを
生成したい時って、そのクラスのファクトリメソッドを
用意しておいてそれを C# 側から呼び出すということになるんですかね？
C++ 特有の複雑な（引数の型を反映した）関数名とかどうなるんだろう。
extern "C" つかうのか。

ごめん、書いてる途中で C# な話題になってしまった。

それで、肝心のことなんですが、アンマネージドな C++ のクラスを
.NET 環境で使うためには C++/CLI でラッパークラスを書けば
いいのでしょうか？そうするとマーシャリングなども自動で
やってくれるということなのでしょうか？

DLL は C++ にやさしくない、かといって COM コンポーネント
として書いてしまうとプラットフォームに強く依存しすぎるので
一般的な用途のクラスライブラリには向かない、
でもアンマネージドな C++ のクラスを .NET と仲良くさせたい、
という課題をどう解決すればいいのかを教えてください。

> そうするとマーシャリングなども自動で
> やってくれるということなのでしょうか？
そういうことになるが、ある意味自分で
マーシャリングコードを書く補助をしていると言ってもいいかもしれない。

アンマネージクラスをC#（やその他.NET言語）から呼び出したければ、
C++/CLIでそのクラスをラップしたマネージクラスを含むマネージドDLLを作って、
他の言語から参照設定して使うのが一番率直な手段。

そもそもC#でアンマネージDLLのC++クラスを操作するなんて不可能だぞ。
（COMインタフェース経由を除く）

>C++/CLIでそのクラスをラップしたマネージクラスを含むマネージドDLLを作って、
>他の言語から参照設定して使うのが一番率直な手段。

やっぱそうですか、ある意味安心しました。
System.Runtime.Interop 以下にいろいろあるのを眺めてて、
もしかしてマネージドからなんかうまい具合にごにょごにょ
できる方法が用意されてるのかなぁ、などと疑心暗鬼になってました。

VC2005でデフォルトのフォームアプリを作成して、
CLRサポートを/clrにして以下のインクルードを追加すると
実行時ヒープエラーみたいなのが出ます。

#include <comdef.h>
#pragma comment(lib, "oleaut32.lib")

どうやって直したらいいのでしょうか？

なんで　Void　って大文字になったの？

ヘミvoidが権利を主張するのを避けるため

System::Void のこと？

当たり前のことなんだろうけどvoid代わりに使えるのが少し不思議に感じる。
#include <cstdlib>

int main()
{
&nbsp; System::Void* pv = std::malloc(256);
&nbsp; std::free(pv);
}

自分自身の起動パスを得るにはどうしたらいいの？

CRTの__argv[0]やWin32のGetModuleFileName(0,とか
.NETのSystem::Windows::Forms::Application::ExecutablePathなど。

Applicationにあったのか！
ありがとう。
ずっとProcessとかを探してたよ
Win32APIのときGetModuleDirectoryとかなんとかだったから

>>331
その線も惜しい。
Win32はGetModuleFileNameだったでしょ。
.NETだとモジュール (EXE/DLL)に対応するものはアセンブリだから、
その方向でやるならAssemblyクラスが正解だった。

http://www.atmarkit.co.jp/fdotnet/dotnettips/016exepath/exepath.html

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
以下略

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

>>333
＞C++/CLI にはマネージドな世界独自のコンテナクラスライブラリが
つSystem::Collections::Generic

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

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

>335
STL.NET は STL/CLR という名前で VS2008 に同梱
ただ、.net fx 2.0 では動かない

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

＞後方互換性

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

>>336
それで困るやつはどれだけいるんだ

STLってのはC++では最重要なんだが...

>>336
それ本当？
.NET Framework 3.0も3.5もCLRのバージョンは2.0のままだろ。

.net fx 2.0 で作ってた既存アプリに STL/CLR を使って修正すると、アプリの実行に
3.5 が必要になるのは嫌じゃね？
前のCTPの頃はライブラリだけ持って行けばよかったんだが

>340
Beta1 で Microsoft.VisualC.Stlclr.Dll ＋ヘッダ抜き出しで駄目だったという報告があった

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

>>341
>.net fx 2.0 で作ってた既存アプリに STL/CLR を使って修正すると、アプリの実行に
>3.5 が必要になるのは嫌じゃね？
>前のCTPの頃はライブラリだけ持って行けばよかったんだが

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

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

>343
客先に説明するのが面倒なんだよね。でも、STL/CLR は使いたい
できれば、CTP同様に VS2005 + ヘッダ + Microsoft.VisualC.Stlclr.Dll で STL/CLR を
使った開発ができる方がうれしい。SP2 で来ないものかな

std::vector<int> v;
　　　：
for each(int i in v)
{}

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

>345

これでも行けますね

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

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

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

>346
ごめん。これはできて当たり前だわ
array<int>^ vec = { 1, 2, 3, 4, 5 };
と同等だもんな

>>346
Cタイプ配列とarray<T>は同等じゃないから346は通らないのでは？

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; }

>348
Cタイプ配列は C++/CLI では array<Type> でラップされるよ。だから、346 は動く
>347 がそれを言ってる

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

VS2008 Beta2 試してみた。コンパイル対象となる .net fx が選べるようになったんだが
2.0, 3.0 を選んだとき、STLCLR.dll は使えなかった
STL/CLR を使いたかったら、3.5 を普及させろと言うことらしい

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

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

>>350
C#のCタイプ配列はCLR配列だが、C++/CLI のCタイプ配列はCLR配列じゃないぞ。
>>346を実際にコンパイルしてみろ、C3285でしっかりコンパイルエラーが出る。 

VC8 SP1で試したけど/clrの有無に関わらずC3285になるね。

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

>352-353
悪禁食らっていたので返答が遅れた
ごめん。漏れが試したのは、VS2008 Beta2 だった。こちらは >346 でコンパイルできるし
動く。また、ecma-372 でも、仕様上 346 で正しいから、VC8 で取りこぼしてた仕様が
いくつかあったやつを VC9 で準拠したんだと思う

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

>>354
349でネイティブでも使えるという報告があるよ。

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

つ ネイティブC++

>>356
WindowsのNTFSファイルシステムドライバは"Ａ"と"ａ"は同じ文字とみなしてるよ？

>>358
あ、ほんとだ。区別されるものと思ってた。

>>356
カーネルの中には比較する関数あるんだけどね・・・
なんでユーザーモードに無いのかは謎

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

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

マネージドなプログラム組むならＣ＋＋なんか使わねっつの！ｗ

＞マネージドなプログラム

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

プラットフォームにVistaが使えるじゃねーか。

いや、Vi$taにあうのはネイティブアプリ。

>>363
自分専用ツールにはクラスライブラリが充実しているので便利。

>>366
それにしては、Win32で出来るものが出来なかったり、中途半端。

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

＞クラスライブラリが充実しているので

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

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

ドトネト君っていろんなスレにいるな。
飽きないの？

＞プラットフォームにVista

つ　ttp://gigazine.net/index.php?/news/comments/20070801_will_not_move_to_vista/

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

そりゃ、CreateFile系のAPI自体がバグでロックしちゃうんだもの。
企業ユーザが使おうとするわけがない。 >> VISTA

>CreateFile系のAPI自体がバグでロックしちゃうんだもの。

kwsk

これか
ttp://d.hatena.ne.jp/NyaRuRu/20070731/p2

Form.hに実装を書かせられるの嫌なんだけど、どうにかならない？
てか、なんでForm.hに実装させるような仕組みにしたんだろう？

Form.cppに実装を移せば？

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

ぶっちゃけVC++8の.NETサポートは「諦めろ」としか言えないよ・・・

VC++9 では何か変わってるの？

そりゃ変わってますよw

VC2008先行して使っている人、
デサイナが生成するコードに何か大きな変化は有りましたか？

試してみたけど変わってないみたいだね。残念だ…

C++/CLI に関してはろくに対応されていないね。STL/CLR なんか作ってる場合じゃないと
思うんだが。結局、ネイティブ・アプリの ClickOnce 対応もしていないし

いや、STL/CLRは「ろくな対応」なんじゃないか？

ネイティブの STL にマネージド・オブジェクトが格納できればいらない対応でしょ
むしろ、2種類のライブラリに混乱しかねない

マネージドなSTLはそれになりに便利だと思う。
標準C++ & boost萌えな俺には、C++/CLIやC#はきついんだが…

>>384
確かに。少なくともクラス定義だけでも、
ネイティブクラスと値クラスに違いがなければいける。

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

C++0x の concept map が C++/CLI に実装されたら、それつかって managed class を STL コンテナにいれられるのでは...

だとしたら、ほんとに STL/CLR は C++0x が確定するまでの繋ぎでしかなくなるな

いや、一応STL/CLRは一度覚えればC#でも使えるんだろ?

STL/CLR は C++/CLI せんよーだってさ
テンプレートで実装してるしね

じゃあ、意味ねーなw

なんかグダグダ

でもまだSTL/CLRのコンテナは、System::CollectionsやSystem::Collections::Genericの
インタフェースを実装しているのが強みと言えるかもしれない。

STLがあればGenerics要らんやん。

C# にも展開してくれれば良かったんだけどなぁ

まぁどっちかっつーと.NET言語の態勢を保ちつつ
コンパイル時のコード生成であるC++テンプレートをサポートするってのが
端から無茶やってるとは思うけどねぇ。

C++/CLIでは
stringstream
に相当するものは用意されているのでしょうか？

.NETのクラスライブラリにはMemoryStreamが似ている存在。
でもstringstreamだって使いたければ使えばいいし。

StringBuilder や StringReader, StringWriter を使ってもいいな

C++/CLIでも派生させるクラスのデストラクタはvirtualにすべき？
勝手になる？

長さの単位が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;
}

>>400

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

>>402
へえ、boost::shared_ptrみたいだな

「リソース管理できてデストラクタに罠がない賢い手段」
目指してるものが同じだからな。

>>402
トンクス！

ハンドル型っていまいち概念がわからん。
マネージドヒープにある実体を指すポインタなんだろうか？

ガベコレの都合から考えたほうが早いかも

ref class だと
デストラクタってDisposeじゃなかった？
だからvirtualにならないとつじつまが合わない気が・・・

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

>>406
ようするにそういうこと。ただしポインタ演算禁止で、演算子多重定義が使える。
ポインタ演算がやりたければinterior_ptr<>。

>>406
> マネージドヒープにある実体を指すポインタ

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

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

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

>>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のどこにも出力されないんですけど。

>>412
%は参照&のマネージド版。

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

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

void plusA(int^ x) {
(*x)++;
}

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

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

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

>>414
Console::ReadLine();などででプログラム止めてる？

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



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

>>414
コンソールプログラムのプロジェクトにしている？
そうしないと、cout, printf, WriteLineの出力先は現れないよ。

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

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

boostみたいにprivateもシリアライズできる
非侵入型のシリアライズはないのでしょうか？

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

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

が発生する。

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

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

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

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

最低限のコードを入れてリビルドして、どうなる？

>>419
stdafx.h
stdafx.cpp
main.cpp
resource.h

だけの状態？

すまんLNK2022だった

アノニマスな構造体があったの？

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

お騒がせｽﾏｿ

>>422
なかった

VC++ expressで
C++/CLIを使うときの制限事項ってどんなのがありますか？

別に何も無いよ

え？そうなの？

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

>>424
http://msdn2.microsoft.com/ja-jp/library/hs24szh9(VS.80).aspx

intからenum（enum classじゃない）に変換したいんだが
普通のC言語のようにただのキャストじゃ変換できない？
どうもできていないような気がするんだが。

>>428
enum classじゃないenumはC++のそのままですよね？
単に使い方がおかしいだけでは。ソースを示してみたらどうです。

DirectXのコードなんだが

D3DFORMAT fmt = (D3DFORMAT)21;

実際のコードでは21の部分は変数になってる。
ユーザの入力。

実体が unsigned long int なんじゃね？

ヘッダではこうなってる
typedef enum _D3DFORMAT
{
（省略）
D3DFMT_A8R8G8B8 = 21,
（省略）
} D3DFORMAT;

直後にブレークポイントつけてウォッチすると
fmtが「未定義の値」になってる。

これで普通に代入できたぞ？

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

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

version違いの*.hがあって、21がない方のをincludeしてるとか。

d3d9types.h なんて前からあるっしょ
これでリリース・ビルドしていたせいで変数がデバッガ上で正常に表示されていなかった
なんてオチだったら指さして笑うが

C++/CLIって実際どのくらい使われてるの？

Dの5倍くらい。

>>438
俺仕事で使ってる
ただのラッパークラスだが

>>440
ネイティブのライブラリをドトネトから使うため？

>>411
前の製品の再利用可能な部分
GUIはC#になっちまった

安価ミス
>>441な

>435
enumは int だし。ってのはCの仕様だっけか。

どうやらint関係なしに
直接D3DFMT_R8G8B8を入れても
<未定義の値>になる。

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

enum は含まれる値を全て表現可能なサイズの型になる。

>445
直接、D3DFORMAT の enum 値を出力してみたら?
TRACE でも cout でも何でもいいけど

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

>>447
ちゃんと21が出たｗ
VC8です

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

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

追記です
VS2005上での話です。

この言語ほんとに流行りそうなの？

.NET が流行れば。
だって既存の C++ のライブラリの
ラッパーとしての存在価値は少なくともあるから。

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

C++/CLI自体が単体で流行ることはないと思う。
あくまでもC++の資産を.NETで利用するためのツール。

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

Objective-C つかったことないや

はいはい死滅死滅

2008になったらC++CLIは何かかわんの？

>>457
STL/CLRとこれまで規格に非準拠だった部分の対応。
例えばC型配列がarrayと同等に扱えるようななった。

がるぽっ

C++0x が確定するまでは、大きな修正は入れてこないだろうね
また、いろいろと言われるから（ｗ

なんか、見た目が変態的なソースコードになるよな・・・

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

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

それをやったのが mc++ で、マネージド・オブジェクトの判別が付かなくなったので
明示的に分離するように変更したんだよ
C++ は既存のままで、CLI を追加構文で、これでようやく見通しが良くなったのさ

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

正直 Managed C++ は「よけいわかりにくいわ！」って
感じだったからな。マネージドな部分とそうでない部分が
明確に分かれている C++/CLI のほうがわかりやすい。
確かに上にあった Objective C の Microsoft 版だという
たとえは的を射ていると思う。

漏れにスキルさえあれば、JVM や Squeek に CLI ラッパをかぶせて、GCC の C++/CLI
実装を作ってみるのになぁ

.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も実行してあるのですが。。。
このあたりの情報(こうすれば動く、実はサポート外など)を
お持ちの方、いましたら教えていただけませんか。
ネットで散々探しましたが、意外とこの話題少ないんです。
よろしくお願い板します。

ごめんなさい。
<add key="HOGE" value="ほげほげ" />
は
<add key="HOGEHOGE" value="ほげほげ" />
の間違いです。

レベル高すぎ

>>465
うちの環境だと正常に読めてる。Vertual PCでWin2k(SP4)。
xx.exe.configの名前はあってる？

>>468
>xx.exe.configの名前はあってる？
それ、ビンゴです！
C#やVBはビルド時に自動でファイル名つけてくれるのに。。。

過疎ってんなー
やっぱりC++/CLIは
流行らないってことでおｋ？

だってマネージ・アンマネージの橋渡し専用言語だもん

GDI+死ぬほどのろいんで、ペイントルーチンをC++/CLIでGDI使って
組めばいいんじゃね
テキスト描画すんのもGDIのが楽なような

>>472
VistaでDDBの速度的有利さは事実上消滅したけどな

DirectDraw（笑）

>>473
.NETがのろくて誰も使ってくれないから全員平等にのろくしたって感じだな

馬鹿?

.NETは最初から馬鹿だよ。

>>475
Direct3DとWPFは仲間はずれ？

>>471
まぁそうなんだろうけど、そういう言語が CLI 上にちゃんと
用意されているところが Java VM とは違うところだよな。
といってドトネトを擁護してみる。

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

それって逆に選択肢がないんじゃ… > シミュ&Win Forms

>>480 そうともいう。
シミュレータ自体はライブラリ化していて、コマンドライン版は
Linuxクラスタで動かしているんだけど、同じライブラリを
リンクしてWindowsで動くGUI版を作れるというのはかなり便利。

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

C#のほうが解析しやすい言語だから

解析なんてしてないだろw

>>483

プリコンパイル済みヘッダーは
C++/CLIで使えるのでしょうか？

使える

プロパチー見ろ

C++で今まで書いてきて
GUIをもっとバリバリやりたくなってきたんですが
かといってMFCは嫌い。
C#は書き直すのがめんどいし
そんな漏れはC++/CLIがいい？

>>488
Win32

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

>>490
どちらでも可能だが、
マネージドのスレッドを使ったほうが取り扱いが楽だと思う。

ネイティブを混ぜるマネージドアプリに何の意味がある。

>>492
C++/CLIスレでそれを言うなよ。/safeにどの程度の意味があるんだ？

>>492
ネイティブってどういう意味で使ってるの?

>>494
マネージドアプリをアンマネージドアプリにする混ぜ物。

むしろ逆だろ
pureでやりたいなら C# で十分じゃん
C++/CLI はそれだけじゃ物足りない人向けだろ

WTLを忘れるな

数値演算をC++にさせて「何の意味がある」って言われるなら、
<funcional>すら駄目ってことになるが…

C#って初期バージョンで完成形だったのに
だんだん拡張されてキモクなってるよな。

全然

C#程度でキモいっつーんならC++とか使えないだろ

>>488
楽したいならC# + C++/CLIとかWPFとか
厳しい道を行きたいなら DirectX Graphics

おまえ、なんかものすごい勘違いしてない？

C#にある delegate の ThreadInvoke メソッドを使った
○ちスレッド処理って、同様のことは C++/CLI では
できないのかな。そもそも delegate がないから無理か。

ThreadInvoke じゃなかった、BeginInvoke だった。
それに、そもそも C++/CLI にも delegate はあるんだった。

なにを言っているんだ

C++/CLIではコンテナクラスライブラリとして STL.NET
なるものを使うべきなんですか？それとも .NET Framework
にはほかにも（言語独立の）コンテナが用意されていて
そちらを使うべきなんですか？

好きな方を使えばいい
C# で慣れてるなら .net の Collections を使えばいいし、違和感がないなら STL.NET で
いい。格納するものがネイティブだったら、既存のライブラリでもいいだろうし

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

一般論だけどDeepCopyの仕様はクラス作成者にしか決められないんじゃないかな。

>509
Primitive型と値型は初期化される

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

自動でディープコピーやったら、循環参照のときコピー終わらなくなっちゃうよ。

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

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

CEDEC2007で
3ds maxは、C++/CLI使ってるようなこと言ってた。
プラグインもC++/CLIだし

コンテナはC++CLIならSTL+Boostがいいのかな？

>>515
ネイティブなクラスのインスタンスを格納するか
マネージドなクラスのインスタンスへのハンドルを格納するかに
よるんじゃね？boost::shared_ptr で格納するなら
また話は発散する。

スタティックライブラリを利用しようとしたところ
（libcmtd.lib等とぶつかる系も回避しました）

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

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

>517
それは C++/CLI なの？

プロジェクトは、C++/CLIです。
stdafx.hに
#include <windows.h>
#pragma comment(lib, "user32.lib")
書いてます

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

>>519
ライブラリは /MDでコンパイルしてます？

　　　　 〜〜〜〜
　　／　　　　　　　　ヽ
　/　　　＞~~~~~~~~/
　|　　∠　 ＼　 ／ |
｜　√　　⌒　 <⌒ |　　　／￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　(6 ≡　　　　　 ＼｜　 　|　　やる前から負けることを
　　 ≡　 ┌ ＿＿「｜ 　＜
　　　＼　　 ＼＿( ｜　　　|　　考えるﾊﾞｶがいるかｺﾉﾔﾛｰ！
　　　 　＼　　　ー ｜　　　|
　　　　　　＼＿＿＿|　　　＼＿＿＿＿＿＿＿＿＿＿＿＿＿

誤爆ｽﾝﾏｿ

ネイティブコード吐かないんなら、C++使う意味無くない？

無くない

ドトネトにはｲﾐﾅｲ

>>520
おおおお
いけました。
ありがとうございます。
ありがとうございます。
ありがとうございます。

修行するぞ。
修行するぞ。
修行するぞ。

C++なのに遅いとか泣けるよな・・・
いや、C++/CLIをC++に含めるのは問題だと、ISOにバッサリ斬られたけど。

ISOがﾀﾀﾞｼｲ

C※にでもすればいいのに。

左を向けば変態的な/CLI
右を向けば変態的な0x
振り返っても変態的なC++

>531
ウホッ！　最高だな（ｗ

変態の俺にピッタリだ。

おまいら、まだまだ子供だな。俺を満足させたかったら、MixedType を持ってこい
CLI もネイティブも多重継承してやるぜ

MixedType ってなに？
boost::any とか？
boost::optional とか？

混合型

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

そうだ、Ｍ＄がマネージドをネイティブに書き換えれば準備完了！

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

人に聞くときゃ、エラーを出せよ

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

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

そういうのは Init みたいな初期化関数を使うってのが C++ の定石だけど、
ちょっとカッコ悪いよね。

うんかっこわるい
Initialize()でないと

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

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

C++xCLI とか CLI++ とか？

C#ってのはどうだろ?

>545
巣に（・∀・）ｶｴﾚ!!

VBってのはどうだろ?

VB から生まれしもの、元いたDLL地獄へ（・∀・）ｶｴﾚ!!

普通に検索できないか？

Googleでは C++/CLI で一単語として認識しているみたいだね。
Googleって形態素解析してないと思ったたんだけど、
いつの間にかリッチな辞書使ってるんだなぁ。

昔はC#とかも検索できんかったけどな

GCは構文のシンメトリーが崩れるから糞

明示的にdeleteすればおｋ

>>552
爆破すれ

>>554
ECMAに通報しました(･∀･)

コナンか

C++/CLIより懐の広い言語って
存在するの？

D言語

>>558
多重継承ができないじゃん。

多重継承いらないし。

>>560 もっと広い心を持てよ。

Mixinは素晴らしい世界

しかし、未だにデザイン以降の仕様の影すらみえない罠

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

pure safeを諦める

＞pure safe

これって、価値ある？

C#やVB.NET並みには

/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
は、使えないんですか？

pure は .net Framework 専用だろ
/clr をつけたら、必要なライブラリは明示的に追加しろや
それか MDX か XNA でも使うんだな

>>568
手順4だけでいいからやれ。
http://www.microsoft.com/japan/msdn/vstudio/express/visualc/usingpsdk/

生成元のクラスから生成したクラスに、自クラスのメソッドを渡し、
生成したクラスから生成元のクラスへコールバックしたいと思ってます。
AsyncDeligateを使えばいいのかと思うんですが、
この関数って実は、自クラス内のメソッドのコールバックにしか使えないの
でしょうか？

ref class MyClass{

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

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

自クラスのインスタンス生成時に親クラスの参照渡しとけばいいんじゃないの？

自クラス→生成するインスタンス
親クラス→生成元インスタンスってことですか？
生成するクラスをDestClassとすると
DestClass destClass(this);
みたいなことでしょうか？

>>571
普通にイベントで実装したらまずい？非同期操作はどの辺でからむのだろ。

C++/クリ

AsyncDelegate って AsyncResult のプロパティだろ？
AsyncResult にサンプルあるじゃん

黒川紀章氏のような一生に憧れるな。
ご冥福をお祈りいたします。

C++は別にJavaのような言語になる必要性を感じない。

C++とjavaとC#の速度の違いを解説してるようなHPとか書籍あったら教えてください

今勉強しるのですが、これ無くならないですよね?

そんな心配がいるほど勉強に時間かかるようなもんかね？

>>581
ドトネトのことを全く知らないと混乱するかも。
あと、古い情報（Managed C++）を見てしまって
混乱していた人がここに約一名。

ManagedDirectX2.0は消えた

MSのC++/CLIがC++委員会に却下されたが、そうすると
次世代WindowsからC＃しかサポートしない、Windows
プログラミングやりたかったらVB.netやC#使え！
と嫌がらせしてくるんじゃないかと不安。

VBやC#が嫌いだから困る。

今はMFC使っているが、今後もMFCは
サポートされるのだろうか？

MFCが駄目ならC++/CLIを使うが、それも
サポートされないとなると。。。

現状は 0x の仕様策定待ちでしょ。だから、ライブラリ拡張しかしてないだけで
MFC のサポートが切れたら、WTLでも使えばいい
RADなくても大丈夫でしょ

委員会氏ね

>>585
こういう事いうからC++基地外は。。。

RADはあった方がいい。

RADは必須だが、MFCのビルダーはカンベン。

MFCのビルダーって何？

RAD で具体的には何を指してるの？
C++/CLI のデザイナのこと？

ま、一般的にはソースと連携するGUIエディタ。
コードジェネレータ以降のもの。

じゃ，コードオナペット機能とかも？

MFCのどこがRODなんだよ

RODって何だよ

ヤンキースの選手だよ

THE PAPER

いや、だからVisual C++/MFCはRADを目指してるように見せかけてた。

しかし、C++のRADができあがると開発者がオプソに流れちゃう。

>>597
それが C++/CLI + フォームデザイナではないのか？
あくまでネイティブにこだわる？

＞あくまでネイティブにこだわる？

これは詭弁。

実体は、Ｍ＄が非ネイティブにこだわる。
gccですんなりコンパイルできちゃったらWinが単なる開発マシンで、
ターゲットマシンが別０＄になっちゃう。

C# で mono とか　tcl/tk とか何かならわかるが、
pure C++ で Win32 アプリがRADで開発できても、
＞gccですんなりコンパイルできちゃったらWinが単なる開発マシンで、
＞ターゲットマシンが別０＄になっちゃう。
ってことにはならないと思うが。

＞ってことにはならないと思うが。

ってことにはならない、じゃなくて、Ｍ＄が阻止する。
売る側からしたら端末みたく膨大な数を売るものだったら１台あたりに０＄代払いたくない。

開発マシンとターゲットマシンと別々なのはふつー。
Winの前の時代なら、UNIXで開発＆Ｍａｋｅして汎用機（ﾒｲﾝﾌﾚﾑ）に転送していた。

＞UNIXで開発＆Ｍａｋｅして汎用機に転送していた。

あ、やっぱ、コンパイルは汎用機でやってたね。

>>601
そういう意味じゃなくてさ、MS の作る Win32 アプリの RAD の出してきたコードを
gccでコンパイルしても、実行できる環境が Linux にある？
Wine がそんなに実用的になってる？

>>603
Windowsヘッダーがgcc環境に移植されてM＄が慌てたのを知らないの？

RADなら製品としては成立しなくて終了したっぽいけど、Delphi / Kylix、 C++ Builder / C++ Builder Linux があるお。

>>603
あ、C++ BuilderにwxWidgetsのプラグインがあってポトペタできる。
wxWidgetsだからLinuxとMacは対応できる。

>>605
MS がクロスプラットフォームな UI フレームワークを採用した RAD を
出すわけないと思うけど。pure C++ になったとしても、Win32 べったりでそ。
次はそれに文句言うの？

それとも Wine があるから
＞gccですんなりコンパイルできちゃったらWinが単なる開発マシンで、
＞ターゲットマシンが別０＄になっちゃう。
だ、って主張？

>>604
漏れも cygwin は使ってるけど、そういうおまいは使ってるのか？
きつい言葉だが、現実見えてる？

じゃ、wxWidgetsだ！

MFCアプリケーションをLinuxに移植する
ttp://www.ibm.com/developerworks/jp/linux/library/l-mfc/

おおい、C++/CLI スレなんだかから、
RAD にかんしては mono で Windows.Form
が使えるかどうかってのがメインの話題にならんの？
そういう俺は Hello world しか試したことがないよ。
mono では。

mono=Hello worldﾂｰﾙ

RHD = Rapid "Hello world" Development

RAD = RApid "Hello world" Development

CLI = Common "Hello World" Language Infrastructure

HAL = HALlo world is typo.

V$ﾄﾞﾄﾈﾄは、ﾄﾞﾄﾈﾄ Framework の機能を最大限に利用することによって、Hello worldの生産性を劇的に向上させます。

質問です。
int sample(int (* func)(void*), void* arg);
というCの関数を呼び出したいのですが、argにマネージオブジェクトを引き渡す手段に悩んでいます。
struct Arg { gcroot<array<int>^> obj; };
と
int on_callback(void* arg) {
   Arg* parg = (Arg*)arg;
   Console::WriteLine(part->obj->Length);
}
を用意して
Arg arg;
arg.obj = gcnew array<int>(4);
sample(on_callback, &arg);
みたいな方法を考え付いて一見問題なく動いているように見えますが、何か問題があったりもっと一般的な方法があったりするんでしょうか。
ていうかon_callbackはなぜ#pragma unmanagedじゃなくても動くんだろう？

>>615
その方法でいいと思うよ。
＞ていうかon_callbackはなぜ#pragma unmanagedじゃなくても動くんだろう？ 
その為の混合モードだから。関数はマネージドとネイティブの両方のエントリーを持っている。
#pragma unmanagedを使うのは DllMainとlongjmpのときくらいじゃなったかな。

>>616
ありがとうございます。
これで実装を進めることにします。

IntPtrで与えられたポインタをマネージ型のByte配列に変換したいのですが、できるのでしょうか？
アンマネージへの変換はMSDNの参照などによりわかったのですが、
マネージへはまだわかっておりません。
アンマネージに変換して使用して配列を扱ってもいいのですが、なるべくマネージ型でまとめたいと思いまして・・・
そもそも無理だとしたらIntPtrのReadByteを使うしかありませんか？
どなたかご教授ください。

>>618
なにがやりたいのかさっぱり和漢ねえ

それへ知ってハッキングでもする気か？

ポインタにするにはちょっとGCさえごまかせば済む話だが、
配列はオブジェクトなので新しく作る必要がある。
C++/CLI使っててポインタを使わない意味はないだろ。

何やりたいかわからんが、Marshal::Copy とかか？

￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣｣
―――――――――――――‐┬┘
　　　　　　　　　　　 　 　 　 　 　 　 |
　　 　 　 ＿＿＿＿.＿＿＿＿ 　　 |
　　　　　|　 　 　 　 | 　 　 　 　|　　 |　 　
　　　　　|　 　 　 　 | ∧＿∧　|　　 | 　　
　　　　　|　 　 　 　 |（　´∀｀）つ ミ | 　　
　　　　　|　 　 　 　 |/ ⊃　 ﾉ　|　　 |
　 　 　 　￣￣￣￣'￣￣￣￣　 　 | 　　 ミ　C++/CLI

懐かしすぎるぞそのAAｗ

配列が三つもあるとかあほすぎ

618への回答にinterior_ptrっていいだろうかｗ？
マネージ型には違いないぞ。

たぶん、IntPtr に格納されたアドレス値をバイト配列に変換したい訳じゃないとは思うんだが（ｗ

c++/cliを使うメリットってなんすか？
C++に中間吐かせるなんて、ﾋﾞｬｰﾈが知ったら泣くぞ

C++ を越えた変態になれる

ま、C++と文法的に相性が悪かったCOMの悪夢の続きを見れるとか。

.netライブラリを使える

ﾄﾞﾄﾈﾄﾗｲﾌﾞﾗﾘはｲﾗﾈ

既存のC/C++ﾗｲﾌﾞﾗﾘを使いたいわけ。

>>632
そういう人がなぜこのスレッドにいるのかわからん。

何ていうか、分からないから見てみる、みたいな。

.NET「本音」相談室
ttp://www.atmarkit.co.jp/fwin2k/dnitpro/honneqa01/honneqa01_01.html

VB.netからとりあえず早さを求めてC++/CLIやり始めたんですが、
//Form1.h
#pragma unmanaged
class hogehoge{};
#pragma managed
Form1を作ったときに自動生成されたやつ
private: System::Void start(System::Object^ sender, System::EventArgs^ e) {
hogehoge test;
}
とやると動くのは分かったんですが、デザイナに

クラス Form1 はデザインできますが、ファイルの最初のクラスではありません。Visual Studio では、デザイナはファイルの最初のクラスを使用する必要があります。クラスがファイルの最初のクラスになるようにクラス コードを移動して、デザイナを再度読み込んでください。
と怒られてしまいます。
いい方法を教えてくださいmm

>>635
IDEが作成したファイルに手を加えるのはあまりよくない。
別のファイルに書こう。

>>635
ええ、絶対間違ってると思ってtest.cppってファイルを作って同じのを書いたのですが、
hogehoge という型指定子が見つかりませんと言われてしまうんです。

//test.cpp
class hogehoge{};
//Form1.h
>>635の#pragma managedより下
って書いてみたんですけど、ヘッダーがコンパイルされたときには
test.cppはまだコンパイルされてないからこういう事になってるんですかね・・・？

>>637
先にCをやってきな

>>639
C++もだろ。

だな。

http://www.asahi-net.or.jp/~yf8k-kbys/newcpp0.html
とりあえずここに書いてることは大体理解出来るんですが、
足がかりになるようなページ教えていただけませんか？

ヘッダと cpp の関係がわかってないのかな？
Form.h が メインの cpp に include されてコンパイルされる前に、hogehoge なるクラスが
定義されていないといけないんだよ
だから、hogehoge をヘッダに定義して、Form1.h で include すればいいんだけど
この説明の意味、わかる？

次はたぶん、混合型はサポートされていません。て、エラーになると予言（ｗ

>>643
ヘッダーを作らないといけないのを全く理解してませんでした。
IDEでクラスを作って見よう見まねでいじったらうまく行きました^^
丁寧にありがとうございましたmm

まぁ、別に cpp を include してもいいんだけどな

いやいや、リンクしたときに定義が衝突するでしょ

それよりおれは>>635の1行目が気になる

それよりおれは>>647の1行目が気になる

C++/CLIって、仕事あるか？

>>647
実は俺も気になってた。

>>649
3ds/maxの会社

CLI穴だらけじゃん(`Д')ノ
じゃあみんなで補完しあおうぜ(=ﾟωﾟ)ﾉ
議論盛り上がりまくり(ﾟдﾟ)ｳﾏｰ
ﾄﾞﾄﾈﾄ対応（･∀･）ｲｲ!

ってのが製作者の狙いということか( ﾟДﾟ)ﾊｯ
いや…なん違うような(；´Д｀)

なすてnullptrなんて作たんだろ、nullで統一してよ

ぬるぽ

>>653
> なすてnullptrなんて作たんだろ、nullで統一してよ
'\0' と混同する人がいないとも限らないからかな…

#define null 0としているプログラムは探せば結構ありそうに思う。
そんなコードでも変更なしに使えるようにという配慮では？

え　C++/CLIはヘッダーに全部実装するのが流儀だろ
cppファイルなんていらんのですよ

実体化しないのかよ
まさか、プリコンパイルヘッダに全部うわなんだおまえやめｒ

>>649
このあいだ、基本は.NETライブラリで、ネイティブ用のI/Fも欲しいって仕事があって
何を使っても良かったし、ずっと自分が面倒みる事になる事は分ってたから
C++/CLI のラッパーで対応したが。

レアケースなのは間違いないな。

＞基本は.NETライブラリで、ネイティブ用のI/Fも欲しいって

これ、何ていうﾄﾞﾄﾈﾄアプリの破滅。

>>え　C++/CLIはヘッダーに全部実装するのが流儀だろ
あ、やはりそうなのか?

こより的には、そのやり方はちょっと…

C#でいう「インターフェイス メンバの明示的実装」をやるにはどうすればいいの?

自己解決
private: virtual Object^ Clone() = ICloneable::Clone { ... }

CLI 部分については C++/CLI って C# よりむしろ VB に近いと思う瞬間の一つだな
raise とか

>>662
マイナー杉

＞raise とか

これ、何てDelphi？

2008入れてみた。
STL/CLI使えるぽ。

.net fx 2.0 指定でも使える？

この言語って、どの程度流行ってんの？

各国で静かなブームですよ

TreeViewとListViewにｘVN_GETDISPINFO相当の機能がなかったので、
Controlから派生させて自作したよ('A`)
（VirtualModeもパフォーマンスがよくなかった・・・）

C#だとAPIや定数の定義が面倒だが、C++/CLIだとWin32ヘッダそのままインクルードして使えるから楽でいい。

だがそんなことするくらいなら最初っから
つMFC

・・・そんな感じだ。

メッセージぐらいならわざわざControl使わんでもどうとでもなるが。
Notify系メッセージならWM_REFLECTION付きで当該コントロールに来るし。

いやWTL最強

>>673
メッセージぐらいではどうにもならんのですよ。
WM_NOTIFY + WM_REFLECTでメッセージ引っ掛けても、先が続かん

Windowsプログラムを組む必要がない場合
CLIを勉強する意味ある？

Windows以外で動く独自のCLIを開発する場合とか。

( ﾟдﾟ )( ﾟдﾟ )( ﾟдﾟ )…

独自にCLRを実装するなら、CLI の勉強は必要だな
C++/CLI は不要だが

Object型の変数の値が、値型Tのボクシングされたオブジェクトであるかどうかを
調べるにはどうすればいいんでしょうか
C#では obj is T とするところです

参照型同様dynamic_cast<T^>(obj)がnullptrになるか否かで判定すればいい。

safe_cast ？

castに失敗した時に、例外が発生したほうがいいならsafe_cast。
nullptrを返してほしいなら、dynamic_cast。
if分の条件でスマートに使いたいなら、T::typeid->IsSubclassOf(obj)もしくはIsInstanceOfType()の組み合わせで。

public ref class A : public Generic::IEnumerable<Object^>
{
public:
virtual Generic::IEnumerator<Object^>^ GetEnumerator();
};
コンパイルエラーになるのだが、こういう実装はだめなの？

エラーメッセージぐらい書（ｒｙ
System::Collections::IEnumerable::GetEnumeratorの方の宣言がない

>>685
public ref class A : Generic::IEnumerable<Object^>
{
public:
virtual Generic::IEnumerator<Object^>^ GetEnumerator();
virtual Collections::IEnumerator^ GetEnumerator();
};
してみたけど、だめでした。

error C2556: 'System::Collections::IEnumerator ^A::GetEnumerator(void)' : overloaded function differs only by return type from 'System::Collections::Generic::IEnumerator<T> ^A::GetEnumerator(void)'
with
[
T=System::Object ^
]

そりゃ返値が違うだけの同名同引数メソッドを宣言できるわけないだろ？
別名定義する必要がある。リファレンスのinterface classの解説見れ

>>687
以下でコンパイル通りました。
public ref class A : Generic::IEnumerable<Object^>
{
public:
virtual Generic::IEnumerator<Object^>^ GetEnumerator() = Generic::IEnumerable<Object^>::GetEnumerator;
virtual Collections::IEnumerator^ GetEnumerator2() = Collections::IEnumerable::GetEnumerator;
};
ありがとうございました。

GetEnumerator2のほうはprivateにしたほうが

>>689
早速private: + sealedにしました。
重ね重ねありがとう

マネージクラスも共変できたらいいのにと思う。

共変ができないのはなんでだろう
CLI 上の制約？

>>691
Genericsは共変/反変をサポートしてるけど
標準クラスライブラリと有名どころの言語がサポートしていないので事実上死に設定

たしかデリゲートもIL上は共変・反変できたような。

C#はデリゲートなら共変反変おｋ

（C/C++スレから誘導されて来ました）
VS2005にてC++/CLI使用中です。

Hoge()というアンマネージドクラスが既にあり、これをマネージ環境で使うことを考えています。
このとき、

Hoge *hoge0 = new Hoge();
Hoge *hoge1 = new Hoge();
Hoge *hoge2 = new Hoge();
　・・・

というのを

Hoge *hoge[10];
hoge[0] = new Hoge();
hoge[1] = new Hoge();
hoge[2] = new Hoge();
　・・・

のよう配列にするにはどうしたらよいでしょう？
（マネージ環境だと　Hoge *hoge[10];　の時点でCLI配列使え！って怒られてしまうんですよね・・・）

普通にできるはずだが？
エラーメッセージとか番号とかちゃんと書けよ

C++/CLIでSTLって使えないんですかね。。。
アンマネージ内で使いたいんですが、#include<list>とか<vector>とかすると
error C2039: 'free' : '`global namespace'' のメンバではありません。　e:\program files\microsoft visual studio 8\vc\include\cstdlib
error C3861: 'free': 識別子が見つかりませんでした e:\program files\microsoft visual studio 8\vc\include\malloc.h
とエラーが出ます。。。

>>697
アンマネージクラスだと普通にできますが、マネージ環境だと
Hoge *hoge[10];　のところで
「error C4368: hoge' をマネージ 'test01:managedClass01' のメンバとして定義できません。混合型はサポートされていません」
といったエラーになります。

このエラーでググると「マネージ環境なんだからarray<>使うべし」といった見つかるのですが、
例文はintの配列とかそんなんばっかりで、今回のような場合はどうすりゃいいのか・・・といった感じです。

よろしくお願いいたします。

>>699
ttp://msdn2.microsoft.com/ja-jp/library/xhfb39es(VS.80).aspx
Hoge *hoge[10]をメンバにしようとしてるんだろ。

>>698
普通に使えるが?
ファイルぶっ壊れてるんじゃね?

>>701
まじですか。。。
再インストールしてみます、ありがとですω

>>>701
再インストールしたところ思いっきり動きました。
５時間悩んでたのが馬鹿らしい。。。
ありがとでした。

>>699
やりたいことと少し違うかも知れんが、
new N[10]で10個のオブジェクトの生成は済んでるから注意な。

class N { }; // native class

ref class M { // managed class
 N *n;
public:
 M() { n = new N[10]; }
 ~M() { delete [] n; } 
 !M() { delete [] n; } 
};

array<IntPtr>^ _ptrs = gcnew array<IntPtr>(10);

_ptrs[0] = IntPtr( new Hoge() );
・・・

でよくね？

Conditional属性は使えないの?
諦めてマクロにするしかない?

>>1
は？お前バカか？
.NET開発のデファクトスタンダードはC#だろ。常識的に考えて
いまさら時代遅れのC++なんて勉強する気しねーよ。
俺はJavaから始めたからよ。

で、ホントはC#よりC++/CLIのほうが未来ありそうなん？

>>707
C++ と C++/CLI の区別が出来ない人は
他の人を馬鹿呼ばわりする資格はありません

>>1の一行目は皮肉みたいなもんだろ
http://www.microsoft.com/japan/msdn/vs05/visualc/VS05Cplus.aspx
たぶんこういうのが元ネタだけどタイトルの割に内容は微妙にネガティブｗ

C++/CLIはC++にどっぷり漬かった俺にはなんか納得できないものがある。

全然チェックしてないけど.NET3.5で言語に手は加わってんの？
マーシャリングライブラリが付くって話は聞いたことがあるけど　あとSTLと
この辺は言語そのものじゃないしな

>>710
C++ がすでに何でもありなところを、さらに C++/CLI でなんでもありになってるので好感もてない？ポインタがふたとおりあるとか。

ポインタじゃないよトラッキングハンドルだよ

C++ のネイティブ・クラスをマネージドに委託できると嬉しいんだよな
普通にクラス作って gcnew したらマネージドになってくれるような機能

BCCで使えるの？

gcc-cil はどうなったん？

なあ、Windowsアプリ作るならC#のほうが楽じゃね？
C++にマネージコードが混ざるとうっとおしい。

つ C++ Builder

おまえらがC#に移行しない理由は何？

いつまで待ってもドトネトが必要とされない。

Managed DirectX が消滅した

というか C++/CLI と C# は使う場所がちがうだろ、常識的に考えて ...

　（　<●><●>） 　　Ｃ丼だけで全部を作れないということは分かってます
　 （Ｕ　　 　　 ）つ 　
　　　 ｕ　　ｕ

C#でC++よりも効率のいいデバイスドライバーって作れるの？

ここC++/CLIスレなんだけど

C#は.NETを必要とする代わりに便利な環境を提供するものだけど
C++/CLIはどうしても.NETが必要な人のためのものだからな

.NETが必要なこと自体に遭遇したことがない

リッチなGUIを簡単に作れるのは魅力的なんだが

.NETは美しいんだよ。
APIのドキュメントと長時間睨めっこしなくて済む

それなんてDelphi/VCL？

某は見苦しさを極めてるからなw

>>724
そもそもC#で作ったデバイスドライバなんてあるの？

マネージド、アンマネージドのクラスや配列の解放について質問があります。

なるべく使い終わったクラスを即時メモリ解放したくて、
delete しているのですが、タスクマネージャで確認しても、解放しているようには見えません。
マネージもアンマネージも、deleteしたタイミングでメモリ解放されるのでしょうか？
それとも、マネージはGCに頼るしかなく、アンマネージはdeleteのあるタイミングでメモリ解放されるのでしょうか？

アンマネージドでも確保したメモリをプールして使いまわしてるだけだから、
deleteしたからといって、即座にメモリがOSに返還されるわけではないよ。

既定の new や malloc から先はどうやってるのか
追いかけたことないけど，「必要なら持っていっても
いいよ」っていうマークでもつけておいて必要に応じて
OS が回収できるようにしているのかな？

newやmallocはHeap系APIに丸投げでねーの?

>>736
ん？システムコールに丸投げ？
もっと，こう，自前でヒープを管理していると思うんだけど．

>>737
ちょいと階層は深いけど最終的にはそうなってるようだね＞VC2005で確認。
そうなると500KB以上は個別にVirtualAlloc/VirtualFreeで、
小さいのは一元管理で縮小せずに再利用だろう。

もしかしてLINKオプションの/HEAPオプションは使われてないかも？

>>737
Win32APIはシステムコールではないよ。
Windowsのシステムコールは非公開でげすよ。

ttp://ja.wikipedia.org/wiki/%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E3%82%B3%E3%83%BC%E3%83%AB

システムコールとは、オペレーティングシステム (OS)
（より明確に言えばOSのカーネル）の機能を呼び出すために使用される機構のこと。
実際のプログラミングにおいては、OSの機能は関数 (API) 呼び出しによって実現されるので、
OSの備える関数 (API) のことを指すこともある

>>739
Windows においてはシステムコールはサブシステムの裏に隠れて
いて直接呼び出すことはできないってこと？
Win32 API って POSIX レイヤと同じレイヤ？

基本的に同じ。ただ、GDI関係は性能の都合でWin32 APIはカーネルのほうまで突っ込んでいたはず。
これをシステムコールというのかはわからないけど、
そういうサブシステムの下に位置するネイティブAPIと呼ばれるがNTDLL.DLLから公開されている。

9xの場合はVxDをDeviceIOControlで呼び出すことがシステムコールに相当するといっていいと思う。

ファイナライザって要らない子？

Disposeし忘れたときに必要

C++/CLIくだすれって消えてる？あるならそちらに誘導してもらえれば嬉しいです(’・ω・)
おとなしくC#いけって話かなぁ。。。

ttp://homepage3.nifty.com/ishidate/vcpp05_6/vcpp05_6.htm

ここを参考にしながらForm1_Paintが呼ばれたときに
DrawlineとかDrawRectangleで描画するプログラム書いてるんですが、
その処理がとても重いので(他の理由もあるのですが)ボタンを押されたときだけ画面を更新するようにしたいんですが、どうしたら良いでしょうか。
(Form1_Paintだとウィンドウの移動などでも更新されてしまうので、それを避けたいということです。)

button1ってボタン作って、button1_Clickに全部書きゃ良いじゃんとか思ったんですが、
引数が(System::Object^ sender, System::EventArgs^ e)なのでe->Graphicsを使えなくて困ってます。

メンバにBitmapとか描画バッファを用意して
button1_Clickで描画、PaintでBitBltが妥当じゃね？

>>745
Form.CreateGraphicsは？
.NET使うならC#は読み書きできるようになった方がいろいろ便利だよ

あけおめです。
>>746-747
レスありがとうございます。
まず>>747のようにbutton1_Clickに
Graphic^ g=CreateGraphics();
としてボタンでの描画は成功したんですが、今度はForm1_Paintが呼ばれたときに描画されたものが消えてしまったので
>>746の方法をとろうとしたんですが、ドキュメント見たりググったりしてもいまいち描画バッファ→画面のBitBltのやり方が
分からなかったので、
http://www.atmarkit.co.jp/fdotnet/dotnettips/458picboxdraw/picboxdraw.html
を見ながらpictureBox1を作って、
private: System::Void button1_Click(System::Object^ sender, System::EventArgs^ e) {
Graphics^ g = Graphics::FromImage(pictureBox1->Image);
drawRandomWalk(g);
pictureBox1->Refresh();
}
こんな感じで解決しました。結果的には>>746の方法に近い？解決策となりました。
C#も勉強してみます(’・ω・)
ありがとうございました。

make_publicの使い方に詳しい方いますか？

ReleaseでDLLをBuildするとリンクエラーが発生します。
>libtest.obj : error LNK2022: metadata operation failed (80131195) : カスタム属性が適合しません: (0x0c00021b)。
>Stdafx.obj : error LNK2022: metadata operation failed (80131195) : カスタム属性が適合しません: (0x0c000261)。

Debugでビルドするとエラーが発生しません。
make_publicはStdafx.h（PreCompileヘッダ）に記述しているのですが、
どう対処すればよいのでしょうか？

ガベージコレクションが走るスレッドっていうのは、どのスレッドかは確定してないんですよね？
ということは、ガベージコレクションが走る際に呼び出すアンマネージリソースの処理は
スレッドセーフにしておかなければならないということかな？

具体的には参照カウントオブジェクトのラッパーをC++/CLIで作って.NETで使おうとしてるんだけど
Release関数をスレッドセーフにしなきゃならんのかなと。
(Interlockedにすればいいだけの話なんで、それ自体はどうってことないのですが)

ファイナライザスレッドは独立したスレッドなのでどのみちスレッドセーフは必要だろう

ファイナライザ中でthisに属するオブジェクトも生存は保証されていないしね
本当に最後の手段なんだから、基本的にはGC任せにしない方がいいよ

値型メンバは確実に生存してるぜ？　その値型が持つ参照型はともかく

>>751-752
ありがとうございます。

明示的にDisposeてことになると思うんですが、
そうなるとDisposeしなければならないインスタンスを持つクラスがデータ構造の奥深くにあると
どんどんDispose呼び出しが感染していって親クラスのとこまで行ってしまいますよね。

面倒くさいなぁと思いつつも、仕方が無いなぁとも感じてるんですが
やっぱりそんなもんですかね…

アンマネージリソースを取り扱う以上、これは仕方ねっス。
頭切り替えるしかねっス。
ちなみにアンマネージリソース絡みでSafeHandleてのもあるんスが、
これの経緯とか調べるとさらに頭痛のタネが増えるのでオススメっす。

C++/CLIのメソッド引数に％をつけることについて質問があります。
マネージ型の配列や構造体をメソッドに渡すとき、”^”をつけますが、 この渡し方で配列や構造体の”ポインタ”が渡されると思っていました。
”^”の引数があるメソッドを持ったクラスライブラリをVBで参照したら “ByVal”となっていました。

ここで質問ですが、”^”でなく”^%”としなければ配列や構造体が 値渡し(配列全体がCopy？)になるのでしょうか？%をつける、 という概念がC++/CLIで現れたため悩んでいます。
できるならば 配列や構造体は値渡しでなく、アドレス渡し、配列渡しをしたいのですが・・・

^は参照型　そのまま渡すと参照をコピー
%はC++の&、C#のref/outに当たる参照渡し
「参照型 参照渡し」で調べればいいよ

>>757
ありがとうございます。調べてみました。参照型の^引数はアドレスをコピー、参照型の^%渡しはアドレスを参照渡しする、ということですね。
ということは参照型の場合、どちらの方法で渡してもパフォーマンスに大きな影響はないということでしょうか。
参照型と参照渡しの違いを理解しないといけないのですね。

.NETで参照渡しはあんまり使わないよ
参照で渡すことが多いんだったら初めから参照型にする

TryParseとかあるじゃん

スレ立ったのが2006年とかC++/CLIは使われてないの？
今からやるならC#のがいいかね？

アンマネージC++もC#も使えるようになった上で、
もしも必要に迫られたときにやっと登場する言語だからね

俺は間違っても＃なんか使わん。意地でCLI

シーナンバー

>>761
そりゃ今からやるならC#だな
それよりVB.NETがいいに決まってるけどｗ
少なくともC++/CLIなんて論外だ
まあ.NETやること自体が間違いかもしれないが・・・

なぜVBを推すのか

ref じゃないクラスで managed なクラスのイベント捕まえようとしてるのだけど
やり方がわからないので教えてください。

ref class hoge {
　event EventHandler ^ev;
};

class hoge_wrapper {
　hoge ^_hoge;
　void OnHogeEv(System::Object ^o, System::EventArgs ^);
　hoge_wrapper(hoge ^_hoge) {
　　this->_hoge = _hoge;
　　_hoge->ev += gcnew System::EventHandler (this, &hoge_wrapper::OnHogeEv);
　}
};

こんなコードを書いているのだけど EventHandler のコンストラクターでC3364のコンパイルエラーがでて怒られます。

>767
そりゃ、混合型は駄目だろ
ネイティブはネイティブ、マネージドはマネージドで扱わないと

あ、hoge_wrapper::_hoge の型は
gcroot<hoge ^> _hoge;
って宣言してました。転記ミスです。

いや、そこもそうだけど、gcnew しているイベント・ハンドラにネイティブの
ポインタ this を渡してるだろ？
マネージドでイベントアダプタみたいな物を作ったら？

MAKE_DELIGATE っていうのを見つけて、試してみたら意図したとおりに動くみたいです。
中身を見てみたら 770 さんの言うとおりの動きなのかな?

とりあえず解決しましたー。ありがとです。

linq は C++/CLI では使えないんでしょうか?

>772
使えない
ttp://www.codeplex.com/linqextensions

LINQ のパフォーマンスから見ると、C++/CLI での価値を感じない

LINQ のパフォーマンス（笑）
C++/CLI での価値を感じない（笑）

言語使用的に無理なのかな．
似たようなことがライブラリで実現できるように見えるが．

ttp://japanese.engadget.com/2008/02/05/linus-os-x-vista/

VistaやLeopardが大々的なマーケティングと共に投入されることを批判して：
「OSは(アプリケーションやユーザーからは)完全に透明であるべきだ」。
「マイクロソフトやアップルにとって、(OSの新バージョンは) 環境をまるごとコントロールして
ユーザーにアプリケーションやハードウェアの買い換えを強いる手段になっている」。

>775
ライブラリで似たようなことができるから、言語でのサポートは不要
これで 0x の auto とかが出てこれば、もう少し CLinq もすっきりと書ける
言語仕様に手を入れると、標準化団体が騒ぐし

>>776
＞「OSは(アプリケーションやユーザーからは)完全に透明であるべきだ」

透明であるべきだ，ってどういう意味なんだろうね．
意識しなくていいものであるべきだってこと？
だったら，Linux ってその逆行ってない？
カーネルのマイナーバージョンが変わっただけでモジュール類
コンパイルし直さないと使えないデバイス続出だったり．
まさしくOS部分が一番の障壁になってるとおもうのだが．
自分でいじる分にはそれが楽しいけど．

たしかに，auto は楽しみだなぁ．
ラムダ式は boost のもいいけど
ちゃんと言語でサポートしてほしいよ．

>>777
Expression Treeサポートって今の言語機能でどうやるの？

＞透明であるべきだ，ってどういう意味なんだろうね．
＞意識しなくていいものであるべきだってこと？

上と下意味違ってるだろ。常考。

>780
何をどうやって書きたいのかを書いてもらいたいな
SQL的に書きたいだけのシンタックス・シュガーの導入が標準化団体に受け入れられる
とは思えない

OSのバージョンアップをいちいちお祭り騒ぎにして
ソフトやハードの売り込み合戦を仕込んで
煽ってんじゃねえよって意味なんじゃないの。

煽るだけならまだしも、ふれーむわーく（笑）ごっそり変えて、
＞LINQ使えない
とかカンベン。

>780
Expression tree ということでギってきた
ttp://blogs.msdn.com/daigoh/archive/2006/06/10/625985.aspx

たとえば、こういったことをやりたいのであれば、C#でのコードと同じものが
演算子オーバーロードで生成できるようにすればいいのでは？
boost::spirit みたいな変態ライブラリになると思うが

確かに早くラムダ式の言語サポートが欲しい

http://d.hatena.ne.jp/NyaRuRu/20051017/p1
こういうアイデアはいいなあと思う。

うん。
この調子なら、数年のうちに LISP が再発明されるな。

ま、コンパイル言語で eval しようという試みでもあるからなぁ

ExpressionはDynamicMethod&ILGeneratorの簡易版としても使えて面白いね

3連休なんてあっという間だな。

C++の場合は、boostでメタプログラミングするか、マネージドで拡張するか微妙なところが出るだろうな
LINQを見ていると明らかに boostにインスパイヤーされているとしか思えない所があるし
boostは、さらに、Haskellにインスパイヤーされていて、C#もLINQそれを意識しての拡張だしね。
違いは、静的にか決定できないか、動的な決定も可能にするか、実行速度的に高速か、コンパイル後にまで及ぶ高い汎用性を取るか……
しかし、C++の場合の一番の的は、templateワカンネー人間かもしれないがwww

C++0x/CLI は可能なのだろうか？

Haskellだけでなく、
関数型プログラミング言語全般の影響だと思うけどね。
ほかはだいたいそうだと思う。

>>792
右辺値追跡参照%%とかできたらすげぇって思うわ。
そのセマンティクスまではよその言語へ持って行けないだろうけど。

>右辺値追跡参照
何やら恐ろしげな用語だなと思ってググッてみたらC++/CLIの機能か
なんですかそれは、噛み砕いて解説してやってください、もうC++/CLIとかは全然追ってないので
今のC++ってギリギリ感が凄すぎなんですが、どうなんですかねー

ようするに追跡参照T%は、ただの参照と違ってGCのついでのメモリ移動にも対応した参照型。
だからgcnewしたオブジェクトやその部分オブジェクトも参照できる。
そのポインタ版は、内部ポインタinterior_ptr<T>やハンドルT^が相当すると言っていいと思う。

右辺値参照はC++0xのやつ。

右辺値参照の右辺値の意味はわかりずらいな
左辺にしない代わりに制約が減ったよ値にしてくれ

template <typename T> ref struct A
{
cli::array<T%>^ m;
};

ってやるとコンパイラが落ちるな

ﾏｼﾞか！
ちょっと帰ってきたら試してみよう

2008EEは落ちないな

帰ってきたら？誰が？

コンパイラさんが

VS2005SP1はアウト
トラッキング参照がダメっぽい

Microsoft(R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.762 for 80x86
.\test.cpp(9) : fatal error C1001: コンパイラで内部エラーが発生しました。
(コンパイラ ファイル 'msc1.cpp'、行 1393)
この問題を回避するには、上記の場所付近のプログラムを単純化するか変更してください。
詳細については、Visual C++ ヘルプ メニューのサポート情報コマンドを
選択してください。またはサポート情報 ヘルプ ファイルを参照してください。
.\test.cpp(10) : コンパイルされたクラスの テンプレート のインスタンス化 'A<T>' の参照を確認してください

C++/CLIってどうなんですかね？
今仕事が谷間なんで新しい言語でも勉強してようかと思うんですけど
仕事とかで使われてます？

>>804
とりあえずC#やってこい．

>>805
何いきなり否定してんだよ

>>804
仕事ではとりあえず見たこと無いな、ガベコレ？なにそれ状態だw。
C++/CLIは、やりすぎだと思うんだな、Dの様な言語を作っておいて、共存可能にした上で徐々にC++側をフェードアウトすべきだと俺は思った。

C++ユーザーはドトネトを無視、
ドトネト厨はC++を無視、
そんな状況を解決する策











となる筈だった。

>>807
無視してないだろ、たとえばLINQなどは思いっきりboostがやってきた事を意識しているのは明白だし。

やっぱり橋渡し専用言語に留まるのかなあ

＞橋渡し専用言語
それ以上の用途は最初から想定してないでしょ。
言語宗教論争への配慮なんて意図は一切なかったと思うんだがなぁ。
STL/CRLは気の迷いだよたぶん。

実際のところ、C++のシンタクスを完全にマージしつつ（完全は言い過ぎか）、
.NETなセマンティクスを生成する偉業はもうちょっと評価されるべきかと。

もちろん構文が似てるからとC++/CLIから.NETに入ろうとしている人には
暴力に訴えてでも全力でC#をオススメするが。

C#って.NETの基礎言語みたいなもんだしな。
俺はそんなものにとっくに飽きてしまって
マクロと抽象インターフェースを通すようにして
C++|C++/CLIに一発で切り替えられるようにしてプログラムしてる。
いつでも.NETから逃げ出せるようにね。

>>806
つ　C#

そんなことより、
C++をヘードアウトさせるなんてとんでもない！

C++/CLIでは、
PropertyGridは、
String以外に指定できんのですか？

Booleanとかintにしてもリードオンリーになる

ColorとかSizeとかenumなどもやりたいお

C++/CLI関係ないからMSDN嫁

MSDNの何処に書いてあるのかさっぱり。
Fontは、できました。
Colorは、できません。
意味不明＞＜

VC2005です。
classは、ここのやつコピペして
http://www.gamedev.net/community/forums/topic.asp?topic_id=450334

public: cParticleDef^ def;
private: System::Void ImageEditor_Load(System::Object^ sender, System::EventArgs^ e)
{
def = gcnew cParticleDef;
this->propertyGrid1->SelectedObject = def;

みたいな子としてます。
EditorAttribute指定とかいるんかしら

MSDNライブラリ内を探すときには、
site:msdn2.microsoft.com付けてググるといいんだよ。

やられました。
見本にしてた
http://www.gamedev.net/community/forums/topic.asp?topic_id=450334
よく読めよって話でした。
失礼しました。

ググりかたのヒント、ありがとうございます。

アルゴリズムにも関わるため、この板で質問していいか悩みましたが、
C++/CLIで作ろうと思っているため、質問させていただきました。


ある16Byteのデータが、
1000個くらいのアンマネージ型の16Byteの配列のどれに当てはまるか
検索することを実装したいと思っています。
1000個の配列間で共通な部分はないです。


最も早い方法というのは何が考えられるでしょうか？
今のところ以下を考えています。

if文でXORまたはmemcmpで検索する
→C++/CLIのXORは高速？

また、C++/CLIのor(||)はショートサーキットが入っているのですか？
VBのOrElseのような。もしも入っていないなら、ショートサーキット
を実現したOrコマンドはあるのでしょうか？

慌ててるのはわかるが、日本語でplz

そこまでタイトならアセンブリで組んだら？
1000個程度ならよほど繰り返し実行しなければ、そこまで真面目にアルゴリズムを
追求する必要があるほどの速度にならないと思うけど

ショートサーキットって、if 文の順番で先に判定外れが発生したら、それ以降は検証
しない奴？　それなら、当たり前にそうなってるけど

日本語がおかしくてすいません・・・あせってまして。
ご返信ありがとうございます。

>そこまでタイトならアセンブリで組んだら？
>1000個程度ならよほど繰り返し実行しなければ、そこまで真面目にアルゴリズムを
>追求する必要があるほどの速度にならないと思うけど
そう聞くと少し安心します。ただ、検索する回数が100回くらいあります。
たいしたことないですかね？

>ショートサーキットって、if 文の順番で先に判定外れが発生したら、それ以降は検証
>しない奴？　それなら、当たり前にそうなってるけど

はい。if(A || B)として、AがtrueでもBを評価することです。
MSDNを見ても書いてないから、ショートサーキットはないと思ってました。

何回も検索するんなら、std::mapとかに入れとけば?

変にアンマネージマネージ行ったり来たりする方が遅そう

>>821
1000個の状態が変わらないなら、がっさりメモリ取っちゃって、その上で検索して
（速度が必要なら分割してmultithreadで）メモリのポジションから当たりのデータを
数えてもいい気がするんだけど

ttp://vene.wankuma.com/ecma372/15_expression.aspx
SS15.9, 15.10

>>823
同意
memcmpはやめたほうがいいな

データが静的なもので検索する回数が多いなら、ソートしちゃって
二分探索でもするのがいいと思うが。

ご返信、ありがとうございます。
memcmpはしない方がいいのですね・・・。マネージクラスのアンマネージ処理は遅くなるのですか。だったら１６バイトの比較はxorを使う
ことが適当でしょうか。

変なことするとILの最適化の妨げになるから、素直に==で比較すべき。

>変なことするとILの最適化の妨げになるから、素直に==で比較すべき。

ありがとうございます。素直==で比較します。ただmemcmpを使わないならば、
自分で比較関数を使った方がいいのでしょうか？
１６バイト比較なので８バイトずつ比較するというような・・・

そんなの実装なんかたいした手間でもないんだから自分でやって計測すれ

アンマネージ型
とわかってるなら
C++で関数作ればいいだけでは？

アンマネージにする意味が分からん。

union で char[16] を double 値２つに突っ込んで、== で比較してもいいわな

できるだけ行ったり来たりしなくて済むようにまとめてアンマネージの範囲でやればいいと思う

>>832
long longでいいよ。

LOGFONT が欲しいんだけど、
void Font.ToLogFont (
Object^ logFont
)
の引数って何渡せばいいの？

Object ^o = gcnew o;
ToLogFont(o);
LOGFONT *lf ・・・？

ググると、自分でLOGFONT構造体を定義してやるC#のサンプルが見付かった。
LOGFONTWが返ってくるらしい。
LOGFONTWを直接渡せればいいのだが、
できないので代わりに配列を送り込んだ。

namespace dr = System::Drawing;

dr::Font^ f = dr::SystemFonts::MessageBoxFont;
array<BYTE>^ a = gcnew array<BYTE>(sizeof (LOGFONTW));
f->ToLogFont(a);
pin_ptr<LOGFONTW> plf = reinterpret_cast<interior_ptr<LOGFONTW> >(&a[0]);
::MessageBoxW(0, plf->lfFaceName, L"", 0);

>>836
ありがとうです！
ばっちりでした。

マクロメディアＦｌａｓｈの
タイムラインみたいなウィンドウ作りたいけど

やっぱり自作しなきゃだめかな
なんか楽そうな方法ありませんか？

クラスライブラリを作ろうとしてます。
C#では///から始まるコメントを書くと、そのクラスライブラリを
参照する方のインテリセンスにコメントに書いた説明が表示されますが
C++/CLIで同様のことはできないのでしょうか?

確か、出た覚えがある

プロジェクトの設定からXMLドキュメントファイルの生成をonにしたらできるようになりました。
けどC#のように///を入力したら自動で整形してくれたり
タグの候補を出してくれたりはしないんですね。

CLIでは無理と認識している。
XML欲しいときは一生懸命書いてるよｗ

ちなみにC#のように楽には書けんよ。圧倒的にタイプ数が増える。

俺はCtrl+spaceキーを多用する癖がついてしまった・・・
あとShiftキーもかなり使う事になる。

C#使ってるとC++でインテリセンスが出ないときに不安になる

>>844
うむ，とりあえず ncb ファイルを削除してみたりとかね．

CLIの入門サイトってありますか？

MFCじゃ駄目なんですか？

他の言語は使えてC++/CLIは初めてなのか，
それともプログラミング自体初心者なのかどっち？
後者ならC++/CLIを選ぶのは間違い

使える言語はC/C++でOffice風のメニュがあるアプリ作りたいからCLIを始めたいのですが・・・・

C# の古い奴を勉強してから仕様書読んだ方が良くね？

C / C++ がわかる人には C# の文法は全然もんだいない

C++/CLI はモンスターだから ...

俺は意地になってCLI使ってる・・・。C#なんか糞喰らえだｗ

たまに羨ましく思うこともあるけど

ILで直接コーディングしてるつわものはいないのか

昔、スクリプトを造ろうとしてやったが、Hello,Worldで力尽きたな（ｗ
ただアセンブリを取得したいのなら、C# を吐き出して、CodeDOM 使った方が楽だという
事実に絶望した

そこでDLRですよ
もはやC++/CLIとは無縁の世界だなw

>>841
こんにちは。

↓このプラグインを使ってみては、どうです？
-CodeProject: XML Comments for Managed C++ Applications. Free source code and programming help
http://www.codeproject.com/KB/macros/MCXDoc.aspx

サンプルはVS2003用ですけど、少し手直しするだけで、VS2005や2008でも動きますよ。
(自分は、 .h だけじゃなくて .cpp でもXMLコメントできるよう1行修正して使ってます)

System::IO::MemoryStreamからアンマネージドなIStreamインターフェース
のポインタを取り出す事ってできるんですか?
ネイティブライブラリ関数の引数に渡したいのですが。

そもそも持ってないので
自前で実装すりゃいいんじゃね？

>>858
そうなんですか。
ComVisibleAttribute属性が付いてるからできるのかなと思ってました。
(ComVisibleAttributeの事はよく分からないけど)

SHCreateMemStreamでIStream作成なんてどう？

実験で
public class Hoge
{
public static void func(ref int a) {}
public static void func(int a) {}
}
というクラスライブラリをC#で書き、C++/CLIから
int a = 〜;
Hoge::func(a);
と呼ぼうとしましたが、どっちを呼べばいいか分からないとコンパイラに怒られました。
C#ならref引数にはrefを付けて呼び出さないといけないので区別することができますが
C++/CLIの場合はどうするのでしょうか?

func(ref int a) -> func(int% a)
で駄目？

delegateを介することで任意のオーバーロードを呼ぶことができました。

delegate void FuncRef(int%);
delegate void Func(int);
(gcnew FuncRef(Hoge::func))(a); // func(ref int a)を呼ぶ
(gcnew Func(Hoge::func))(a); // func(int a)を呼ぶ

>>862
よく意味が分かりません

% は C++/CLI に置ける参照指定

それはわかってるのですが、呼び出し時にどう関係あるのでしょうか?

ん、cast で指定したらってことだけど？
ref に値型を渡すってことは boxing したいってことなんだよね？

castですか?
((void (Hoge::*)(int%))&Hoge::func)(a);
とやってもマネージ型はできないと言われました。

C#でのref引数ってのは、C++/CLIでのトラッキング参照(%)、C++での参照(&)の事だと思うのですが
boxingと関係あるのでしょうか?

関係ないよ。

ref class A {
public:
String^ str;
int* ptr;
};

A^ a = gcnew A();

マネージドなクラスのメンバを初期化しない場合どうなるか見てみたところ
a->str, s->ptrどちらもnullptrでした。
これはたまたまなのか、それとも仕様で決まっているのでしょうか?

仕様のはず
ttp://vene.wankuma.com/ecma372/12_type.aspx#SS.12.3.3

>>870
thx

あるクラスのインスタンスを一気に100個作るメソッドってない？
forでまわすの面倒

gcnew array<AruClass>(100)

↑は忘れて

AruClass a[100];

↑は忘れて

くだすれC++/CLI（初心者用）ってもう無い？

スレ検索して見つからないんなら無いんだろう

.NETのクラスライブラリの使い方に関する質問はC#スレで聞けばいいからなあ
言語仕様の話題だけなら2つもいらん

スタックじゃなくてgcnewで作成する場合はどうすれば・・・

スタックで作っ（たように見せかけ）て、リファレンスで保持するのはできなかったっけ？

>>880
>>873

array<char>^ a = gcnew array<char>(10);
pin_ptr<char> pinned = &a[0];
interior_ptr<char> interior = &a[0];
char* native = pinned;

pinned += 5; // pin_ptrの位置を変える
interior += 5; // interior_ptrの位置を変える

pinned = native; // ネイティブポインタからpin_ptrに
interior = native; // ネイティブポインタからinterior_ptrに


コンパイル・実行共に問題なかったんだけど、コメントのような操作って規格的にOKなの?
つか、pin_ptrやinterior_ptrってデバッガの逆アセンブルで見るとスタックに積まれた
普通のポインタにしか見えないんだけど、どういう仕組みなんだろう…

pin_ptr の方はおっけー。元々、pin_ptr で指されているポインタの先のオブジェクトは GC の
再配置の対象にしないという仕様だから
interior_ptr の方は実体はハンドルらしい
大切なのはGCでオブジェクトの再配置が発生したとき、追随できればいいわけだから普通の
ポインタに見えても不思議はないんじゃない？ GCがアドレスを変更するんだろうし

pin_ptrが指してる先に再配置しないフラグとか付けてる様子無いんだけど
よく分からんが俺の知らない仕組みが働いてるんかな。
まあともかくthx

C++ のコンサバGCだかなんだかと同様に、スタックにあるポインタらしきものが
直接指してる先のものは再配置しないんじゃないの？
そうじゃないとJITコンパイラも効率いいコード吐けないだろうし。

ああなるほど

あなる

class A {
public:
　typedef int(*cbfunc)(void *);
private:
　cbfunc _cb;
　void *_cbarg;

　void somewhen() { _cb(_cbarg); }
public:
　void set(cbfunc cb, void *arg) {
　　_cb = cb; _cbarg = arg;
　}
};

という感じのクラスがDLLの中にすでにあって、
A::set() の arg にマネージドオブジェクトを指定したいのだけど、
どうすればいいですか？ gcroot まではたどり着いたけどなんかちがう

Aを作ってる方の話?
それともAを使う側の話?

使う側ですー。

gcrootをnewしてそれをsetする。
不要になったら、そのgcrootのインスタンスをdeleteするか、
gcrootが中で使っている
System::Runtime::InteropServices::GCHandleを直接使うかというのでどう？

へっだーにusing namespace hoge;を書くと
取り込んだ先でも影響されます。どうしますか？

ヘッダで using しないのは常識。

ウィザードが作ったForm1.hもusingしてるよ。

ウィザードの吐くコードはうんこだから。

こんなもん使うなというメッセージなんだろう

どうしても長くて書きたくない名前空間があるなら別名作っとけ。

よーしマヂレスしちゃうよ

C++/CLIがうんこ

まあMSもあんまり使わせたくないんだろう
フォームのデザインなんてC++/CLI本来の用途から考えたら不要なんだから

class Takenoko
{
public:
　Takenoko();
　~Takenoko();
private:
　 Nazo m_nazo;
};

Nazoのコンストラクタが必ず引数をとる場合エラーがでます。

コンストラクタの中で冷害が起きるとデストラクタは呼ばれるの？

なわけねぇだろ

C#ではできるよ

>>901
ただのC++と同じでコンストラクタ初期化子書け。

C# はマネージド・オブジェクトがスコープ外れて ＧＣ に回収されてるだけだろ
そうじゃなきゃ、コンストラクタの try 構文なんていらねぇよ

using

>>905
渡すものがまだ出来ていない場合はどうすればいいの？

初期化子に書いたものは、コンストラクタ実行前にできあがっていることが保証されてるだろ
そっちで発生した例外はコンストラクタの try catch で捕まえろよ
こんなの、C++の話題だろ。何ここで訊いてやがる。こっち池yo
ttp://pc11.2ch.net/test/read.cgi/tech/1204124447/

ref class Render
{
private:
　PresentParameters pp;
　Device m_device;
}

PresentParametersの本体が自動的に出来ていたとしても
初期化リストでm_device(pp)と渡す時点で中の値は意味をなさないでしょう？

Managed DirectXの話をそこでは出来ません。

最初からコード出せよ。ref もついていないクラスの話かと思ったぜ
それで何が問題なわけ？

Direct3D.Device 型って値型だっけ？　マネージド型のスタック書きってただのシンタックス・シュガー
だから、メンバにするときはハンドルにしておくべきなんじゃね
んで、コンストラクタでPPの値セットしてから gcnew すりゃいいだろうに、何を手を抜いているんだか

解決しました。

C++のライブラリでSTLコンテナの内容が更新されるんですが
コレを刻一刻とデータグリッドに表示させようと思うと
タイマーで定期的に明示的に内容をコピーしまくるしか無いでしょうか？
なんかこうもっとスマートなやり方ってありますか？

もうちょっと話したいことを整理してくれ。

refなクラスはオートポインタ見たいのに入れられますか？

意味がない

要するにmanagedなのにデストラクタ走って欲しいんだろ

MS的に実体宣言でダメなら無理でFA

>>916
msclr::auto_handleとmsclr::auto_gcrootがまさにそれ。
前者がマネージ型（参照型）、後者がネイティブ型。

>>917
マネージクラスHogeはデストラクタ (IDisposable::Dispose実装)を持っているとして、
関数の戻り値としてHoge^を受け取るというときなんかにauto_handleは必要になる、らしい。
Hoge^ f();

void g()
{
//Hoge h = *f(); 普通、参照クラスはコピーコンストラクタがないのでこんなことできない。
msclr::auto_handle<Hoge> h = f();

} //hのデストラクタが中のHogeオブジェクトののデストラクタを呼ぶ。

おまいら、質問者の意味不な一行にエスパーで答えすぎですよ

>>920
いいんじゃね？優しくてｗ
最近おかしいプログラマって多いから・・・例えば

Q．○○するためにはどうしたらいいのですか？

普通・・・□□がいいかも。△△もお勧め。
異常・・・まず、なぜ○○しようと思ったか言え。

普通に答える人って少ないじゃんｗ

その目的を達成するために選んだ経路がそもそも間違ってるケースが多いから仕方ないよ

ほらｗｗｗこんな感じでｗ

そこでエスパー
xxxでできる。けど、もしaaaをやりたくて質問したのならyyyのほうがいいよ。

linq とかはいずれ入って来るのかなあ
C#でしか使ったこと無いけど

LINQはすでに入ってきてるだろ

LINQは要りません。

全ての式をメソッドにして律儀にデリゲートオブジェクト作って
Enumerable::Select(Enumerable::Where(…か

Windows フォームアプリでフォームを二枚開いて
それぞれに別の情報を表示させるにはどうすりゃいいんでしょうか？
_beginthread でスレッドを複数用意して
それぞれのスレッドで System::Windows::Forms::Application::Run
を呼び出すのでしょうか？

_beginthread ・・・ ドトネトぽく無い気もするし、
そもそもフォームを表示させるのに
Application::Run を使うものだと思い込んでる
俺がダメな気もする。知恵をお貸しください。

気のせいだとは思うがC++/CLIの方がC#より速い気がする。
もちろん根拠はない。計ってもいない。

ただ、スタックセマンティクスは大きいよね。これ使えるときは
使った方がいいよね。
少なくともファイナライザーよぶより、デストラクタ呼んだ方が
はやいよね。

>>929
その別の情報ってのがどう意味なのかによると思うけど、
スレッドにする必要はなさそう。
スレッド使うにしても.NETのスレッドの方がプールしてる
らしくてｲｲと聞いたことがあるよ。

>>931
C++ でやってる数値計算があるんですが、
スピードよりわかりやすく見せれ！ってことで
フォームをいくつか開いていろいろ表示させたいなぁ、と。

System::Windows::Forms::Application::Run(gcnew KashikaForm1);
System::Windows::Forms::Application::Run(gcnew KashikaForm2);
System::Windows::Forms::Application::Run(gcnew KashikaForm3);

ためしに適当なフォーム3つ用意して Run 呼んでみたら
当たり前だけど最初の一枚だけ表示されて帰ってコネー！
とじたばたしてました。思わず各行の最後に & つけそうになったよ・・・

3つともインスタンス作ってからそれぞれShow()して
最後にApplication::Run()

　 /＼＿＿_／＼
／　／　　 　ヽ ::: ＼
|　（●）,　、（●）、　|
|　　,,ノ(、_, )ヽ、,, 　 |
|　　　,;‐＝‐ヽ 　 .:::::|
＼　　｀ニニ´　 .:::／　　　　　　NO THANK YOU 　
／｀ー‐--‐‐―´´＼
　 　　　　 .ｎ:n　　　 ｎｎ
　 　 　　nf|｜| 　　　| | |^!n
　 　 　　ｆ|.| | ∩　　∩|..| |.|
　 　 　　|: ::　 ! }　　{！ ::: :|
　 　　　 ヽ　　,イ 　　ヽ　 :イ

>>932
まずその計算てのは大変な計算なんだよね。で、
その計算自体が１つで、それを例えば数値とグラフでみせる。
のかそれとも
独立した計算自体が複数あるのかによっても変わってくるかな。

前者なら、スレッドが計算して、２つのフォームがタイマーで
読んで表示？または、スレッドが２つのフォームにポストか？

後者なら、それぞれのフォームでスレッドを作ればいいかな。
やったことないから嘘かも知れないけど。

>>930
VB.NETやC#よりも、VC++の方が高度な最適化がかかる。
C++とC#のコンパイラの最適化レベルの違い紹介してた記事があったと思うが
ちょっと見つからないな。

>>936
ﾄﾝ。知らなかったよ。

C# 4.0 からは P/Invoke なしで Win32API が使えるようになるそうです。

あれ？C＃にinclude指令と限定Cパーザを足し込む案はボツになって、
System.Win32.[DLLNAME]が追加されたはｚ(ry

938を見てDynamic dispatchが思い浮かんだ。

>>933 >>935 THX
まだ試してませんが、早速 Show しまくってから
Run でイベントループをまわそうと思います。

>>935
計算結果はSTLのコンテナに次々と保持されていて、
そいつをいろんな切り口で見せるパネルを同時に
いくつも開いておきたいです。

クソアメリカへ輸出の日本車に糞付けてやった

クソアメリカのクソ野郎には糞がサイコーだ

世界貿易センタービルから飛び降りて死ね

地面にブチ当たって死ねクソ野郎

クソアメリカの日本車は糞糞糞だらけ〜〜〜

クソアメリカの日本車は糞糞糞だらけ〜〜〜

クソアメリカの日本車は糞糞糞だらけ〜〜〜

クソアメリカへ輸出の日本車に糞付けてやった

クソアメリカのクソ野郎には糞がサイコーだ

世界貿易センタービルから飛び降りて死ね

地面にブチ当たって死ねクソ野郎

クソアメリカの日本車は糞糞糞だらけ〜〜〜

クソアメリカの日本車は糞糞糞だらけ〜〜〜

クソアメリカの日本車は糞糞糞だらけ〜〜〜

クソアメリカへ輸出の日本車に糞付けてやった

クソアメリカのクソ野郎には糞がサイコーだ

世界貿易センタービルから飛び降りて死ね

地面にブチ当たって死ねクソ野郎

クソアメリカの日本車は糞糞糞だらけ〜〜〜

クソアメリカの日本車は糞糞糞だらけ〜〜〜

クソアメリカの日本車は糞糞糞だらけ〜〜〜

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

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

それはそれは

そんなもの作るなよ

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

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

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

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

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

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

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

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

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

それ、何て、要Option Explicit？

文盲現る。

Ｃ丼ダサダサ

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

using System::Drawing;

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

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

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

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

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

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

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

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

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

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

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

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

ゲームとかヤバイ

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

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

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

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

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

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

/clr:pure

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

できるよ

むり

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

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

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

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

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