managed C++ やろうぜ！！

マネージ型の基本事項、制限事項読んできた
('A`)ﾏﾝﾄﾞｸｾ　・・・MC++の存在意義を見失いそうな気分です

>>520
＞MC++の存在意義
既存コードの流用が簡単ってこと以外、MC++に意義なんてあったっけ？

>>518
次のコードで参照渡しはできそうだね。
#include "stdafx.h"
#using <mscorlib.dll>
using namespace System;
public __value struct V
{
int i;
int r;
};
__gc class TestClass
{
public :
static void Test(V& va)
{
va.i = 4;
va.r = 8;
}
};
int _tmain()
{
V v1;
v1.i = 2;
v1.r = 4;
Console::WriteLine(S"v1.i = {0}", v1.i.ToString());
Console::WriteLine(S"v1.r = {0}", v1.r.ToString());
TestClass::Test(v1);
Console::WriteLine(S"v1.i = {0}", v1.i.ToString());
Console::WriteLine(S"v1.r = {0}", v1.r.ToString());
Threading::Thread::Sleep(5000);
return 0;
}

>521
既存コードの流用もCOMにしておいた方が便利だし、あまり利点になってない
既存C++のパワーと.NETライブラリの融合を期待していたのに＿|￣|○

>>504
レス、サンクス！
質問の意味が分からず、総スカン食らったのかと思たよ。

けど、やっぱ、ダメなのね。

これが煩わしいのと、
C#でいうところの param が指定されたメソッドを呼び出すのが煩わしいのがあって、
MC++は、本格的に利用できないね。

さらに次のバージョンではC++ CLIになるし、
個人的に、MC++はボツかなぁ....。

WinFX C++CLI
.NET MC++
ということ？

C#でいいじゃん
なんでC++にそこまで執着するわけ？
もうC++ CLIも要らないよ

C++には夢があるんだよ、夢が。
特にtemplateの夢はC++プログラマなら離れられないものなんだよ・・・。

>>527
いまどきテンプレートだって。
Visio 使えよ Visio！　ﾌﾟ

>528
最近の Visio はすごいんだな（(；ﾟДﾟ)ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ

>526
template に関しては Generic で C# でもサポートされるところがあるから、微妙かな

ただ、やっぱりあるでしょ？ MSに対するそこはかとない不信感が（ｗ
だから、C++ はあくまで限りなく標準のままに .NET との親和性を深めてﾎｽｨ

>>529
信じよされば巣食われる。

> ただ、やっぱりあるでしょ？ MSに対するそこはかとない不信感が（ｗ

だからC#使うんだよ。ECMA標準。もうすぐISO標準。

C++も、MFCによって成長した感があるから、あんまり変わんないや・・・

まぁ、漏れは趣味ではC、仕事ではJavaとCOBOL(過去の遺産ｗ)だけどね。

C++ の template なんか C++ のプログラマの中でも
Visio より知名度が低かったりして。

>533
さすがにそれは・・・、Java も C# も template のありがたみがわかって回帰してるわけだし

C#の標準化ってCILも含めてなの？　それとも言語仕様だけ？

文法だけ。CLI含まず。

>>534
MFC厨だとありえるが・・・

>535
そっか。ごめん漏れにはやっぱりMSは信じ切れないよ（´・ω・｀）
C++ CLI が来るまで待つかぁ

>536
恐ろしい話だ・・・

>>537
C++ CLI出ても、それはMS主導だから一緒でしょ

MFCやCOMですら既に十年以上続いてるわけだが
信用できないとか言ってる奴はアフォか？

まぁ、結局MFCやCOMをバカにしてるのは、
Windowsの動作そのものを理解してないやつばっかり。

>>540
すみません、Windowsの作者ですがMFCやCOMを馬鹿にしてますが何か？

>>541
ああ、あなたがあのブサイクなメガネチビ・・・

カトラー様を侮辱する気か！

CPUの研究者にはフォンノイマン症候群ってものが
あるらしいけど、OS板の香具師はデビッドカトラー
症候群ってものがあるのかな。カトラーだって
MachのアイディアをMSに持ち込んで、そこから設計したって
いうのにね。OSASK。。。

#include <atlbase.h>
するとこんなエラー出るんですけどどうにかならんですか？

error LNK2020: 未解決のトークン (0A00000B) atexit
error LNK2020: 未解決のトークン (0A000012) ??_7type_info@@6B@
error LNK2020: 未解決のトークン (0A00001A) free
fatal error LNK1120: 外部参照 3 が未解決です。

CComPtr とか使いたいのに

>545
>475

ありがと〜（＾ー＾）/
たすかりますた！！
ここはいいインターネットですね。

Win32 Platform SDKと.NET Framework SDKとは共存できないのでしょうか？
前者を入れた後に後者を入れると前者のドキュメントの目次等が表示できなく
なるのです。解決策等ご存知でしたら、ご教示願います。

>>548
漏れもそれなった。PSDK入れた後に.NETSDK1.1を入れたら。
とりあえず不具合はそこだけなので、そのまま放置してます。

素直にVS買えよ

自己レスです。逆順でインストールしたら解決しました。

C++/CLI ってどこかに情報あるの？
Wedbey のところじゃ、__gc が ref になるとかSTLとの親和性が上がるとかの
断片的な情報しかないんだけど、ECMAに仕様を提出して標準化するって書いてあるから
今のうちにMC++との違いを認識しておきたいんだけど

とりあえず、ロードマップの日本語版
ttp://www.microsoft.com/japan/msdn/vstudio/productinfo/roadmap.asp

いちおう、こんなん見つけた

PDFなんで注意
ttp://download.microsoft.com/download/9/9/c/99c65bcd-ac66-482e-8dc1-0e14cd1670cd/C++%20CLI%20Candidate%20Base%20Draft.pdf

>535
このPDF見ると、CLIもECMA,ISO/IECに標準化するのね

っていうか、そこまでしてC++に執着してC++/CLIに移行するメリットあるのかな・・・
素直にC#に行った方が飯食える気がする・・・
っていうか、C++/CLIって出る前から雲行き悪すぎるし、話題にすら殆ど上がって無いあたり。。。

MSは次期OSは.NETで統一するんだし(決定済み)
.NETの為に作成したC#が一番.NETが使いやすいんだし(事実)

こう考えると、C++にいくら自分が残っても、飯食うために使う事は出来ない気がするんだけどなぁ・・・

死滅スレのノリですな

managed C++は既存のC++で組まれたアプリケーションを.NET環境に移行するためのものだね。
（そういう需要があるかとか、移行がスムーズにいくかはさておき）

新規の開発でmanaged C++を選択する必要性や動機はほとんど無いだろね。
>555が書いてるように、C#で開発した方が生産性高い。
C#が選択肢になりえない対象の場合は、managed C++も選択肢にほぼなりえない。

ネイティブコードとマネージドコードの「つなぎ」に使うためのものじゃないのか？＞MC++

つなぎというのが何を指してるのか今市よく分からんが
マネージドコードからアンマネージドなコードを呼ぶだけなら
なおさらMC++である必要はない罠

なんでそこまで CLR 上で C++ が動くことに反発するのかわからんが、MS がこの方向を
覆すことだけはないって

もしも、現状の MSIL と CLR が C++ を載せる能力がないと MS が認めてしまったら
将来、CLR 上でのベースAPIとなる WinFX が C++ に対して親和性がないと言っている
ことになってしまう
Longhorn でのアプリが .Net とネイティブ C++に２局化してしまう。これは CommonLangage
として .Net を位置づけようとしてる MS にとっちゃ問題だろう？
Win32 から WinFx への移行が進まなくなる

既存の VC++ での開発者を WinFX に流すためにも MS が C++ を外すことはないだろう
それが MC++ ではなく、C++/CLI なだけで

反発してるんじゃないんだよ
（本来の）C++や、MC++、C#などを一通りやった上で
ネイティブアプリケーションに比べると、いくらか足枷が出来てしまう
.NETアプリの開発ではC++の生産性の悪さが目に付いてしまうだけ
現状の.NET Frameworkだとネイティブアプリだと普通に出来ることを
実現するのに様々なトリックが必要になったりするからね
あと、MSが一番力入れてるのはC#だろう
MC++については既存の開発者の移行を促すと言う意味では賛成だが
あくまで移行のための言語であって、主力になりえるとは到底思えない

MC++ に関しては移行のためにとりあえずやっつけで作ったものだけど、開発者の
理想としては、従来の VC++ で組んだアプリがそのまま CLR 上に載ることでないの？
それが実現できれば、アンマネージドな軽快さとマネージドの堅牢性があいまって
最強の環境になると思うんだが
とりあえず、MS はその方向へ向かおうと努力しているように見える（と信じたい）

もちろん、.Net の開発環境として最適なのは C# って点には同意するし、漏れも C# は
大好きだ

現状として
> 従来の VC++ で組んだアプリがそのまま CLR 上に載る
ということはないし、実際
> MS はその方向へ向かおうと努力している
ということもないように私は思う。将来的にはWin32の方が
ネイティブではなくなり、エミュレータ上で動くようになって、例え
> Longhorn でのアプリが .Net とネイティブ C++に２局化してしまう。
としても、結局は後者の(高速性等の)メリットはなくなってしまう
であろう。
結果として、managed C++で.Netを学びつつもその扱いにくさを
感じ、その後C#を学んで言語・APIセットともに移行が完了すると
いう順序をMSは目論んでいるのであろう。すなわち、managed C++は
C# & WinFXに向かうための迂回路の1つとして用意されているに
過ぎないと考えられる。

しかし、例えばWin & Macなどクロスプラットフォームで作っている
サードパーティのために、Mac動作の.Net環境をMSが作るかどうか…。

MC++とC++/CLIって別物ですか？

>564
MC++ が移行準備段階で、C++/CLI が移行中な感じ
個人的には WinFX が来るのと同時に、C++/CLI がもう一つ構成が変更されるように思える

MC++ が既存の C++ に マネージド型を扱うためのキーワードを追加してなんとかやりくり
しようとしているのに比べて C++/CLI の方は CLR との相互やりとりのエリアを扱うハンドル
型を追加したりして、Heap Alloc と GC Heap 上のエリアを並立させようとしている模様

詳しくは上の Candidate base でも呼んでちょ

>563
Mac 用の Office とかがあるから、公開するかはともかく CLR は作るんじゃない？
Office は .Net 化するらしいから、ソース管理を考えるとブランチ分けするよりは CLR
を作るかと

>563
Java の失敗から見てもわかるとおり、アンマネージドな部分の要求は決してなくなることは
ないと思う。（私にとってだが）業務用の主となる解析や描画、Design 演算はまずマネージド
にならないだろうし、既存の資産との流用性からアンマネージドな部分を作り、接続する言語は
必要だ

まず、この点は認めてもらえるだろうか？

その上で、マネージドとアンマネージドな領域を自在に行き来できる言語として MC++
（は駄目だけど、その先のC++/CLI）があるのではないかと思う
これは開発者にとって充分に魅力的だと思うんだが、違うかなぁ

なんか昔の PureJava 論議みたいになってきた気がするが（ｗ

マネージドとアンマネージドな領域を「自在に」行き来できるなら
価値あると思うよ
今のはおよそ自在とは言えない代物だからね

MC++は、既存ライブラリを.NET向けにwrapするための
thin wrapperを作るためのもの、にしては
あまりにリッチだと思うぞ。

そこにそんだけリソースを費やせるのはMSぐらいのもんだろうけど。

Javaの失敗というのには同感。JNIははっきり言って拷問。
MC++の自在っぷりは異常。.NET語とC++語とマシンコードを
同時に解釈できるのはなにげにすごいぞ。

議論以前にMC++普及してないじゃん。。。
日本語の参考書籍が１つも無い状況っすよ？
こんなのでは勉強もやりにくいし・・・

もうわざわざC++使う必要もないんじゃないかな・・・
既有技術そのままで実装出来るとは思えないし・・・

VS.NET系のVC本にはMCの解説を入れているものが、私の知る限りで５冊はあるけど。
いったいどんな田舎に住んでるんだろう？

日本語でないと読めない奴はだまってC#とVBで下請けやってればよい

こんなの勉強しなくても普通に使えるだろ。
なにをそんなに慌ててるのかしらんが。

>>571
まぁ、5冊だけどな
資料が少ないってのは事実っしょ。
普及してないってのも事実だし。

正直、C#に行かずにMCにとどまる理由は、移行のためのラッパー書くのみっしょ
それ以上の使い道ないから、移行が完了すると、もう使う事もないでしょうし

JNIがアホすぎたんだよな

Whidbey の Community Technology Preview のコンパイラだが、C++/CLI も
コンパイルできるっぽい

ふつうに Whidbey のプロジェクトから /clr のオプションをつけると /clr:oldSyntax と
なって C++/CLI の構文はエラーになるけど、コマンド・プロンプトで cl /clr とやって
コンパイルを通ると、動いたよん

質問です。
クラスのインスタンスを作る時に
グローバルな領域において置きたいのですが
MC++だと関数の中でしかインスタンスを作れません。

どうすれば各関数から共通のインスタンスを使う方法を実現出来るのでしょうか？

>>577
まずはsageを覚えろ。

>>577
その次にシングルトンを覚えろ。

>>577
出来ない。
設計見直せ。
何のためのnamespaceであり、何のためのクラスか知るべし

どうしても共通のインスタンスが必要ならば

途中で送信してしまった・・・
どうしても必要ならば
と思ったけど、もう>>579で答え出てるか・・・

ここってsage進行なんですか？
よく分からないのでとりあえずsageで・・・

え〜と、質問なのですが
VC++.NETでMC++でコード書いてるのですが
今までSDKでやってたので、.NETではウインドウプロシージャはどうなってるのでしょうか？

と言うのもWinsockのWSAAsyncSelect()を使いたくて、メッセージを受信したいのです。

なんでVC++.NETがあるのにMSDNを読もうとしないんだろう

>>583
とりあえず半日調べての質問です。。。。
すみません、探し方が悪いとは思うんですが、キーワードも適切なのが見当付かずに・・・

>584

void System::Windows::Forms::Control::WndProc(Message* m);

次は、メッセージが定義されてないんですけど、とか訊くなよ

>581
素直に、グローバルな値はアンマネージドクラスで定義した方が早くない？

>> 576
VC++2005 のプロジェクトのプロパティにある、C++ のコマンドラインオプションに、
/clr を追加すれば、警告が出てくるが、/clr:oldSyntax を上書きしてくれる。
それがいやなら、「use managed 〜」のチェックをはずす。

>587
Thx. チェック外して自前でコマンドラインに追加するっす
しかし、>>553 以外の C++/CLI のちゃんとした構文ドキュメントってどっかにないかねぇ

ttp://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1557.pdf
これは何の資料なんだろう。QuakeIIのソースを利用した調査かな

>>588
「Use Managed 〜」のチェックをはずすと、
コマンドラインで取り込んでいるモノがすべて消えるので注意。
メモして自前で記述する。

>590
りょうかいです

プロパティもとはちょっと変わるんだねぇ

ref class R {
private:
　　int size_;

public:
　　property int Size {
　　　　int get() { return size_; }
　　　　void set(int val) { size_ = val; }
　　}
};

>589
これは ISO C++ のワーキング・グループがまとめた C++/CLI の説明らすぃ
今回の Whidbey でどこまで実装されてるかチェックしてみます

C++ compiler M4 feature list
ttp://communities.microsoft.com/newsgroups/previewFrame.asp?ICP=whidbey&sLCID=US&sgroupURL=microsoft.private.whidbey.cplusplus.language&sMessageID=%[email protected]%253E

>593
おおう、おおむねこのリスト通りであることを確認しますた

・ファイナライザ（M4.2) 未実装

・プロパティ
機能を確認

・インデックス・プロパティ(M4.2) 未実装

・ref クラス内でのSTLコンテナの記述
マネージド型と非マネージド型の混在するmapが作れなかった
stdcli はたぶんかなり先

・delete
ref 型に対する機能を確認

・for each(M4.2) 未実装

・marshal_as 未実装

・native 型からの継承　未実装

・static な operator (M4.1) 機能を確認

generic と template はまだ見てないです

ParamArray と 初期化時の new もまだですた

void foo(array<Object^>^arr); // 可変長引数

ref class Foo {
　　std::vector<int> *vec_;

public:
　　Foo() : vec_( new std::vector<int> ) { // 初期化時のnew
　　}
　　~Foo() { delete vec_; }
};

マネージクラスのポインタが作成できない。

ref class C { /* .. */ };

C ^ h = gcnew C;　　　　　// OK
(*h).do_something();　　　 // OK
C * p;　　　　　　　　　　　　// Compile Error
sizeof( *h );　　　　　　　　// Compile Error

orz

独自にネイティブスレッド生成するアンマネージドなC++の
コードをラップするマネージドなクラスを生成して、
マネージドコードなUIプログラムとリンクさせたアプリケーションを
作った場合、アンマネージドなスレッドの動作にGCコレクションを
割り込ませないようにすることは可能でしょうか？
例えばアンマネージドなスレッドを優先的に動かしたい場合
などです。

>598
具体的には何とも言えんが、用はネイティブなスレッドが起動している間はGCが
動いてその親であるマネージド型を回収してほしくないってこと？

__pin しる

__pin はアンマネージドが動いている間、対象となるオブジェクトをGCしないことを
保証してくれる

>596-597
これって、こういうもんだろってスルーしてたけど、マネージド型って C++/CLI では
ハンドル型として規定されて、クラス・インスタンスとは同等ではないから >>597 の
振る舞いで問題はないと思う

アンマネージドなクラスがマネージド型を保持するときだけ、* でのポイントを認められて
いるけど、ネイティブとマネージド型の混在は M4 を通しての課題らしいから、まだ動いて
いないかと

>>599
__pinはメモリを移動しないって意味ですよね？
そうではなく、私が考えているシチュエーションは
1)優先度が高いアンマネージドなスレッドがアクティブな時に
　GCが走り出さない保証があるか？
2)通常優先度のマネージドなコード実行中にGCが走り出した場合、
　そこに優先度が高いアンマネージドなスレッドが割り込むことが
　可能か？
ということです。helpみてるとGC中は(同一プロセス内の？)
全スレッドが中断されるみたいな記述があったようなきがした
のですが、これってアンマネージドなスレッドも含まれのでしょうか？
優先度の高い所だけプロセス分けるって手もあるんでしょうけど…。

>>600
でもなぁ、>>589 のPDF みると、将来的には出来そうなんだよなぁ。
これが出来れば、T がマネージドなクラスかそうでないかをコンパイル時に
判定することも出来そうなので、なるべく早い段階で使えるようにしてほしい。

>601
実行モデルの問題ですね
NativeスレッドとGCのどちらが優先度が高いのか、正直こんなとこで訊いてないで
やってみればいいんでない、とか思わなくもないですが、ざっと調べた限り、CLRと
Nativeの混合状態での実行モデルのようなものは見あたりませんですた

つーことで、試してみました
native スレッドは通常のプライオリティで、ひたすらミリセカンドまで表示し続け
GC側はマネージド型を10000個作って、GC::Collect をかけます

とですね、見事にGCのタイミングで出力される時間が飛んでます。普段は１０ミリ
セカンドですが、GC::Collectのタイミングでだいたい＋３０ミリセカンドぐらいです

もちろん誤差も含んでますし、タイミングもあると思いますが、まぁ、COMでapart
にしたほうがよろしいかと思います

>602
M4終了がいつかってことだよね。WGのタイムテーブルだと、C++/CLIの最終勧告が
２００５年末ぐらいだから、構文とベース機能（nativeとmanagedの併存の実現）は今年
いっぱいぐらいじゃないのかなぁ

年末あたりにベータが出るかもね

>>603
>やってみればいいんでない
おっしゃる通りです。今夜にも同じようにして試してみます。

>とですね、見事にGCのタイミングで出力される時間が飛んでます。普段は１０ミリ
うーん、残念です。ここら辺が保証されれば、私的にはmanaged C++最強！
なわけですが…。っていうか実行モデルの問題か。
まあ、windows上でTimeCriticalなアプリ組むのもどうかってのもあるけど。

わざわざ試して頂いて、ありがとうございました。

http://page4.auctions.yahoo.co.jp/jp/auction/d47227135

VC++.NET2003はC++の.NET環境が整ってきているのですが、デバッグ実行時の起動が超遅いです。
プロジェクトを新規作成して何もコードを書かずにデバッグ実行を開始しても、フォームが出てくるまで３０秒ぐらい待たされます。
デバッグなしの実行ではすぐに出てくるのでデバッガの問題だと思うのですが。
2002の時も「Hello World」がコンソールに出てくるまでやはり３０秒ぐらいかかります。
どなたか解決策をご存じないでしょうか？
ちなみに環境はWinXPPro、AthlonMP2000+Dual、メモリ512MBです。
ノート（WinXPHome、PentiumM1.4GHz、メモリ512MB）や職場のPC（Win2k、Pentium4-2GHz、メモリ256MB）でも同様でした。
よろしくお願いします。

ウチは３秒だなあ
アンチウイルスソフトとかつかってる？

おまえら何時までＣ＋＋　なんか使ってるんだ？
馬鹿だろ？さっさと死ねよ

ウチも遅いです。
なんか大量にモジュールをロードしてる感じ。

ナニカ常駐させれば速くなるのかな？

>610
2002 の時はそうだったが、2003 になってからは感じなくなった
当時も環境の問題だろうと言われて、消えていったんだが、マルチポストのスレ違い
を相手にしないでくれ

いい感じに沈んでたのに

>607 です
自己解決しました。デバッグモードを「自動」ではなく「マネージのみ」にすると早くなりました。デバッグも出来るみたいです。お騒がせしました。

>>612
お礼すんのにあげんなァァァ

private: System::Void button1_Click(System::Object * sender, System::EventArgs * e)
{
　　int a;
　　a=atoi(textBox1->Text);
}

error C2664 'atoi' １番目の引数を'System::String __gc*'から'const char*'に変換できません。

フォーム上のボタン button1 をクリックしたら
textBox1 の text プロパティを数値に変換したいのです
デザイン時 text="10"です

>614
上げないで欲しいんだが・・・

文字列の変換はユーティリティを利用する

#include<vcclr.h>

と宣言して、

wchar_t __pin *pRawString = PtrToStringChars(textBox1->Text);

これで、ワイド文字列になる。あとは、ワイド文字列に対応した wcstol を使って欲しい

よく考えると、この文字列処理ってこのｽﾚに書いたことがなかったなぁ

>615
あーっと、ｽﾏｿ
こっちだ wcstol −＞ _wtoi

>>615-616
遅レス＆age申し訳ないです
今確かめました。修行してきます・・・

MSDN C++マネージ拡張の仕様
7.8　文字への直接アクセス
これ自分には勉強になりました

MSDN に VS2005 TP May 2004 来た。
C++ CLI はどこまで進んでいるんだろう…

>618
こんな感じらしい
ttp://blogs.msdn.com/slippman/

もうしばらくしたら確認してみる

皆さんの目から見るC#に対してのメリットってなんですか?
自分はVC++メインに使っていて､最近やっと．NET触ることになり調べてるんですが､C#も便利そうなんですが､テンプレート使えないので躊躇しています｡
　　　　　　　　　　　
自分なりのメリットデメリットです｡まだ本診ただけなので間違ってるところも多々あると思いますが
ManagedC++
　テンプレートつかえる。stl､boostなどになれたものには何よりも変えられん｡
　アンマネージとの共存がちょっとやりやすそう
　
C#
　記述がC++よりもすっきりする(個人的に)
　デリゲート､イベント使える

追加：C++の多重継承

ハンドルは間違いです．．．

>620

まず、MC++ に対する認識について、マネージドクラスに対してはまだテンプレートは
あまり使えんです
また、マネージド、アンマネージドの混合したクラスも作れんです
だから、単純に言語としてのレベルでは C# の圧勝と言ってもいいと思います
それで、C++/CLI とかで上で騒いでるわけですが

ただ、アンマネージドなプログラムから、マネージドなクラス・ライブラリを摘み食うことが
できるのは、MC++ の唯一最大の特権ではないでしょうか
また、処理速度を必要とする部分を組むのに、アンマネージドで組んでマネージド側に
ラップして機能を提供するという点を考えると、MC++ を避けて通れないと思っています

どこでも継子扱いなんだけどね(´･ω･`)ｼｮﾎﾞｰﾝ

うーんだときついかも知れんです
テンプレートはマネージドに対して少しは使えるんですか?

>623
言い忘れてたけど、できれば sage て

アンマネージド・クラスで gcroot 使ってマネージド・クラスを持てば、アンマネージド・クラスに
ついてはテンプレート使えるけど、現状の CLR 自体が Generics について拡張されるのを
待ってる状態だから

すぐに仕事に使うんじゃなければ >589 でも読んで(*´Д`)ﾊｧﾊｧするがよしかと

>623

マネージド拡張の未サポート説明
ttp://msdn.microsoft.com/library/default.asp?url=/library/en-us/vcmxspec/html/vcManagedExtensionsSpec_25.asp

MSDN日本語ドキュメントにも付いてたはず

>>623
単純なSTLの利用程度だったら gcroot を使う方法がここにある
http://www.codeproject.com/managedcpp/

自分がしたいこと

多重継承
リフレクション
デリゲート
テンプレートorGenerics
ガベコレ
アンマネージとの密接なやり取り

．．．2005年まで待つのか．．．いやほんとに2005年に出るのか?

ごめんなさいまたあげちゃいました．．．

Whidbey May 2004
基本的には M4.1 ベースでバグフィックスを進めたみたい
今回の Whidbey からはプロパティ上で /clr /clr:pure /clr:safe /clr:oldSyntax が設定できる
ようになってた

後は、.Net FW は 2.0 ベースになってた

んで、次のような構文を実行しますた

interface class IOut { String ^Result(void); };

value class SamVal : public IOut {
public:
　　String ^Result(void) override {
　　　　return gcnew String("Sample value");
　　}
};

generic <typename T> where T : IOut
ref class Sample {
public:
　　void out() {
　　　　T t;
　　　　Console::WriteLine("Result : {0}", t->Result());
　　}
};

void _tmain() {
　　Sample<SamVals> ^sam = gcnew Sample<SamVals>;
　　sam->out();
}
Generics も順調そうです

SessionEnding を拾えないでいる・・・・C#で書くとうまくいくのだが・・・？
どっかにサンプルころがってないかな？VC++.netのコード。

>631
CodeProject の C++ WebSrevice あたりで、あるんでない？
この間、WebServices を作ってて、Application や Session にアクセスできることを
今更ながら知って感動していた

いや、漏れが物知らずだったんだけどさ(´･ω･`)ｼｮﾎﾞｰﾝ

結局SessionEnding使わずにWndProcでやり過ごしたわ。あーすっきり

深く沈んでる（ｗ
ベータが出るまで話題がないなぁ

と、保守

VC++2005 Express Beta 入れてみた
相変わらず、ファイナライザはない

相変わらず M4.1 らしい

ぬぅ。

　boost::is_base_and_derived< System::Object, T >

とかかけるようになるのはいったいいつになるのだ。

MC++以外の.NETのプロジェクトに
C++,ATL,MC++で書いたライブラリをDLL化
しないで使うことって可能ですか？

あとからexeとdllを一つにできるのでもいいです。

>637
無理

なあ、managed C++やろうと思っても良い書籍が見つからないんだがオススメある？
やっぱMSDNライブラリしかない？

>639
漏れはこれで勉強した。いい本かどうかは微妙

ttp://www.amazon.co.jp/exec/obidos/ASIN/1893115283/qid=1090330561/sr=1-4/ref=sr_1_10_4/249-9037969-2157104

あげ

>>639
洋書でいいなら"Programming with managed extensions for VISUAL C++ .NET" MS Press
http://www.amazon.com/exec/obidos/tg/detail/-/0735617244/qid=1090702738/sr=8-1/ref=sr_8_xs_ap_i1_xgl14/103-7664091-4927863?v=glance&s=books&n=507846
もあるよ。ぜんぜん初心者向けじゃなく、C++ をMFCなどで使っている人が.NETを使いたい場合に読むって感じの内容。
なので、易しい解説などいらんから、がつーんと要点と詳細が欲しいという人向け。

C# の params キーワードに対応するmanaged C++ での方法は、何を使えばよいのでしょうか？

>643

対応型 __gc[] じゃ駄目？

params char[] だったら wchar_t __gc []

いえ、可変長メソッド引数なので、単なる __gc ではだめです。
何かしらの Attribute だと思うのですが、見つけられていません……。

えっと、 __gc[] で駄目だったの？　__gc[] って array のガベージ型だと思うんだけど

C#
System.Console.WriteLine(string format, params object[] args)

C++
System.Console.WriteLine(String *format, Object* arg __gc[])

ってなってるんだけど

解決しました。
ParamArrayAttribute でした。
MSDNの言語フィルタをVBにしたら気づきました。

>>646
その __gc は、単に managed 配列を表すだけの、省略可能な修飾子ですよ。

[ParamArrayAttribute]
void Func(String *forms, Object * args[])

具体的にはこんな感じになるのでしょうか？

引数に対する属性なので、この位置です。
void Func(String *forms, [ParamArray] Object * args[])

ただ、managed C++ だと、最後の引数以外につけてもエラーにならないんですね。
C# の params だとちゃんと怒られるのに……。

2005βにて。
ジェネリックテンプレート

template <typename Interface>
generic <typename Type> where Type : Interface
public ref class GenericTemplate{
・
・
・
}

こんなのを書いたら怒られた。
コンパイラ君、無理言ってｽﾏﾝｶｯﾀ

>650
・・・そりゃ難かしいでしょう
でも、できたらうれすぃ

>649
Whidbey のサンプルでは、C++/CLI ではこうなるらすぃ

double average( [ParamArray] array<Int32>^ arr );

array は stdcli::language でサポートされるマネージド配列のクラス

double average( [ParamArray] array<Object^>^ arr)

で任意の Object お取得するようになるってことか

ざっと、アプリを作ってみますた。軽く注意するところは

・まず、第一に using namespace stdcli::language;
・配列の受け取りは array<型> ^
・ハンドル型の NULL 初期化は nullptr を使う
・static 変数の初期化は static コンストラクタで行う
・普通のポインタ型を delete し忘れるな
・as の代わりに safe_cast<ハンドル ^>
・foreach はないので、stdcli::for_each を信じて待て

という点でしょうか

感想としては、C# で組んでるのと変わらない気分になったです
速度も、WindowsForm で組む分には C# の方が起動は早いみたい
まぁ、まだこれからだと思いますが

Stringの比較はCompare、CompareToメソッドを使うしかないの？
if (Path::GetExtension(filename) == S".BIN")みたいに書きたいんだけど。

String は結局、CLI の型だから、Equals が用意されてる

if ( Path::GetExtention(filename)->ToUpper()->Equals(S"BIN") )

って書けばいいかと

== もちゃんと動いている気がするけど、念のために

C++/CLIって
ぶっちゃけイケてる？

>>656
逝けてる

>>656
既存のライブラリを使いやすいという意味ではかなりいけてる。

まあ、MC++で Managed ラッパクラス作って、それを C# から使うのがベストな気がするが。

>656
C++ で .Net フレームワークを綺麗に使いたい。でも、__gc とかうっとうしい。という要望に
完全に応えている。ハンドル型とか最初は気になるけど、自動変数の気分で使い捨てる
ことができる

C# くらいに C++ が .Net フレームワークへの親和性を高めたものと感じる
ここまで作りが違わないと、逆に C# でコード組む気がなくなるよ
後は、マネージド、アンマネージドの混在が実現できれば、言うこと無し

標準 C++ で組みたいときはそのまま組めばいいし、ふと、マネージドに繋げたいときは
さっくりソース持ってきて纏め直して、ref つけるだけ
ベータ・レベルのできばえとしては、べた褒めする

まぁ、まだ、ベータだし、ってとこいっぱいあるけど

STL.NET
http://msdn.microsoft.com/library/en-us/dnvs05/html/stl-netprimer.asp
いつだ、いつ追加されるんだぁ。少なくとも Beta1 にはなかった

ところで、匿名デリゲートのやり方がよくわからないんですが、できる？

List<String ^>^ loop_words = gcnew List<String^>;
loop_words->ForEach( ... ここに匿名 delegate を渡したい );

って、やりたい
チェックライト程度の処理をいちいちメソッドにしたくないんです

http://www.msdn.net/library/default.asp?url=/library/en-us/dnvs05/html/TransGuide.asp
こんなのもあったのな

アスペクト指向的に、今までのC++ソースコードは何も書き換えずに
別ファイルからこのクラスは__gcにする、とかいう指定が出来るようになればいいな。

>662
なんか、できそうな気がする

アセンブリに纏めるということを前提に、export するクラスを別ファイルでこのクラスは
ハンドル型で扱えるようにすると指定しておいて、アセンブリにまとめるときに、対応する
インターフェイス名を指定してマッピングし、旧来のソースをマネージド型として扱うという
やり方なら作れるんじゃないかな

C#での
BindingContext[dataSet1,"TableName"].Position++;
はCPPでどう書くの？

>>663
そうすと、Ｃ＃囲い込み戦略byＭ＄が破綻するから、出来ない仕掛け。

>>665
ぜんぜん論理的じゃない。

>664
MSDN に書いてあるじゃねぇか
BindingContext->get_Item( ds, "Customers" )->Position = groupBox1->BindingContext->get_Item( ds, "Customers" )->Position + 1

>665
え？　自作すればいいだろ、これぐらい
ファイルの対応表から、マネージド・ラッパのクラス吐いて、インターフェイスの実装再配置を
使って、アンマネージドなクラスにマッピングすればいいんだと思うが
もしかして、それよりもずっと高度な話を言ってる？

MC++とC++/CLIの違いは記述の違いだけ？
やれることに違いは無いのかな？

違いはいっぱいあるんだが、目に見えるところでは記述の違いだけだな
言語って、そういうものだろ？

>>669
まあそうですけどね。ただ、VJ++とCOMのシームレスな連携と
C++とCOMのあのメンドクささを、ただの記述の違いというには
個人的には違和感を感じます。あれぐらいの違いがあるのかなと。

>670
C++/CLI の最大の焦点は、マネージドとアンマネージドの２層化
MC++ ではCILヒープとヒップの層の分離ができていないために、総てが一緒くたに
new していた。だから、逆に何を削除するか、何をガベージに任せればいいのか
わからなくなっていた

MC++ はその試行錯誤の段階の言語といえる。管理を明確にし、型を分離し、配置位置を
ちゃんと意識しながらコーディングできるようにしたのが C++/CLI
そして、同時に標準 C++ の純粋性を保持しようとしている。また、継承関係でもマネージド
・非マネージド間での相互参照を許可する（予定。笑）設計になってる

これらを考えると、内部的にはかなり違っている。追加された表記は特にオブジェクトの
配置位置を明確にすることと、さりげに、C++ の抽象化への不満を解消するための
キーワードが多い

こんな感じで良い？　まぁ、口で説明受けるより組んでみた方が良い
漏れの意見はちょっとヽ(´ー｀)ノﾏﾝｾｰ意見が過ぎると思う

ECMA 標準化 C++/CLI ドラフト
http://msdn.microsoft.com/visualc/homepageheadlines/ecma/default.aspx

VS2003、.net Framework 1.1を使っています。
自作のアイコンを作成してFormに適用しました。タスクバーにもアイコンが表示されています。

ところがXPにはタスクバーにアイコンが増えるとアイコンをまとめる機能があり、
これが働くとデフォルトのアイコンに戻ってしまいます。
たぶんフォームではなくアプリのアイコンを表示しているのだと思います。
アプリケーションに自作のアイコンを適用するにはどうすればよいのでしょうか？

C#ではプロジェクトのプロパティにビルドという項目があってそこで指定できます。
しかしMC++にはこれがありません。app.icoを自作のアイコンで上書きしたところ、
app.rcの中も自作のアイコンに置き換わりましたが、上記の不具合はなおりませんでした。

解決しました。
app.icoを上書きすればよかったのですね…。
debugビルドでは反映されないので混乱してしまいました。

C#での BindingContext[dataSet1,"TableName"].Position++;
が
BindingContext->get_Item( ds, "Customers" )->Position = groupBox1->BindingContext->get_Item( ds, "Customers" )->Position + 1
に化けるのか。

なんかどこかで見たような....

そうそう。C++Builder で Delphi のクラスを使うときも、こんな感じで記述が増えた。
同じことをやっているんだね...

>674
ただ単に、現状の C++/CLI では、インデックス・プロパティをサポートできていないから
こうなってるだけなんでは？

インデックス・プロパティに対応したら、

BindingContext[ds, L"Customers"]->Position = BindingContext[ds, L"Customers"]->Position + 1;

になるでしょう。もっとも、＋や＋＋をわざわざオーバーロードする気がなさそうなんで
あまりかわんないけど

プロパティのインクリメントに対応するだけでも、
BindingContext->get_Item( ds, "Customers" )->Position++;
こんなにすっきり。

ふと思ったんだが、インクリぐらい対応してるんじゃないのか？

__gc なクラスをシングルトンにするにはどうしたらいいでしょうか？
クラス変数はGCポインタをもてないので。

お願いだから、。NETでSTLやふつ〜の標準C/C++ライブラリ
使う方法教えてくれ。これなしでC++のプログラムをせいと
いうわけじゃなかろ？

>678
Singleton クラスを一つ作って、gcroot でメンバを持たせたら？

>679
C++/CLI が無事完成するのを待て
ふつーのSTLや標準C++ライブラリしか使わないなら、マネージド拡張なしで作れば
いいんでない？
#pragma unmanaged 使ってさ

漏れ、boostをそれで使ってるよ

このスレも C++/CLI やろうぜ！！ で立て直したら？

まだ、M4程度のベータだし、managed C++とｽﾚ分けるまでもないから、このままで
いいと思われ
このペースじゃ2005 Mid のWhidbeyリリースまでに1000逝かんでしょ

C++/CLI のベータだが、気のせいか
Dictionary<String ^, data ^> ^dic = gcnew Dictionary<String ^, data ^>;
で作ったデータで、

String ^keyword = ...
dic->ContainsKey(keyword)
としたとき、データとして含まれているはずなのに引っかからないことがある
（´-｀）.｡oO(なんでだろう？)

interface class を継承したクラスまでインターフェイスになっちまうし。

>>679
Microsoft Visual C++ .Net 2003: Kick Start
http://www.amazon.co.jp/exec/obidos/ASIN/0672326000
を読むと何か参考になるかも。

WonAPI MRIMG32は、Microsoft MSIMG32.DLL と高い互換性を実現しました。

サンプル プログラムで動作を確認できる。

詳しくは、下の「WonAPI MRIMG32 トップページ」で最新情報をご確認を。

WonAPI MRIMG32 トップページ
http://f59.aaa.livedoor.jp/~wonapi/mrimg32/index.html

この程度自前で実装できる上に、このスレと何の関係もない。

__gcを付けたクラスから__gcの無いクラスにコールバック先(デリゲートを使う？)を渡して
__gcの無いクラスからコールバックをするにはどうしたらいいのでしょうか？

・delegateは__gcクラス
・__gcクラスを__nogcクラスで使うときはgcroot<>で囲む
ポイントはこの二つ。コードに起こすとこんな感じ。

#include <gcroot.h>
using namespace System;
public __delegate void DD(String* message);
__nogc class Nogc{
　　gcroot<DD*> my;
public:
　　void SetD( DD* m ){ my = m; }
　　void CallD(){ my->Invoke( "ぬるぽ\n" ); }
};
public __gc class Gc {
public:
　void Func(String* message) { Console::WriteLine(message); }
};

int main(){
　Gc* c = new Gc;
　Nogc i;
　i.SetD( new DD( c, Gc::Func ) );
　i.CallD();
　return 0;
}

>>690
レスありがとーー！
試してみます。報告は後ほど

>>690
ありがとうございました。
解決しそうです。

ちなみに何かいいMC++の書籍ありますか？

つーか
こんなの使ってる奴いるのか？
正気か？

>>693
使わざるえない時もあるってもんさヽ( ｀Д´)ﾉ

>>692
俺はMSDNだけで済ませてる。
あとは過去ログ参照

>>693
俺だってC#とか使いてぇよ…orz
まぁ、デフォのC++よりは幾分ﾏｼ

　　　AAA* aaa[];
public:
　　　__property ????? get_AddressList() { return aaa; }
　　　__property void set_AddressList(????? value) { aaa = value; }

AAAクラスを配列で持ちたいので
こんな感じでプロパティを宣言したいのですが
うまくいきません。?????の所をどうしたらいいのでしょうか？

自己解決(´Д｀;)しました


　　　AAA* aaa[];
public:
　　　__property AAA* get_AAAList()[] { return aaa; }
　　　__property void set_AAAList(AAA* value[]) { aaa = value; }

こうでした。
う〜ん、それにしてもgetの時の[]の位置って普通わからないよなぁ

>>696
AAA* __gc[] だったかな。

>>697
戻り値をAAA*[]にして小一時間程悩むのは誰もが通る道だろうな。

C++/CLIが出るまでの我慢

__だらけで汚い言語ですね

過渡期のものだから。

ANSIで規格化されない限り、ずっとそのまま。

解析処理みたいなのをmc++でストックしとけば、ﾄﾞﾄﾆｰﾄ時代にも対応出来ますよね？

必要になるまでやらんでいいと思うが

C++/CLRが出るまでC#に退避することにしますた。

int をHex表示したいんですがどうやるんですか？

>>707
何に表示したいんだ？
まあ、とりあえず、標準出力なら
Console.Write("{0:x}", num);
string.Format ってのもあり。

・・・sprintf でも使ったら？

C++/CLI だと
(3).ToString("X"); とか

stringstream にマニュピレータ設定するのが C++ スタイルだろ。

ありがとう。返事送れてごめん。

このごろ C++/CLI の解説もかなり充実してきて勉強になる。英語で苦労だけど。

http://www.codeproject.com/managedcpp/
の "C++/CLI" 項目の記事はどれもいい。

S.B.リップマン氏の記事は必読。
前からある有名なやつが、>661 にあるので、
最近の MSDN Magazine の "Hello, C++/CLI" が、
http://msdn.microsoft.com/visualc/default.aspx?pull=/msdnmag/issues/05/02/purec/default.aspx

S.B.リップマン氏の MSDN Magazine "Pure C++"、二本目でた。
"Generic Programming Under .NET"
http://msdn.microsoft.com/msdnmag/issues/05/04/PureC/

>712
日本語資料ならなんかGDNJで晒されてたぞ

>>714 これ?
C++/CLI 言語仕様
http://www.stdblue.net/cgi-bin/vene/wiki/wiki.cgi

Java VMで十分

意味不明

>717
CLR の事と間違えてんじゃねぇの？
まぁ、CodeDOMあるから、C++の実行時解釈もできるけど

Cマガジンの特集記事がうんこなのか俺の頭がうんこなのかわかんないけど
C++/CLIの追加機能の意味(というか用途)がわからんものが多いッス
genericsとtemplateの使い分けはどうするんだとか
interfaceは純粋仮想関数で事足りるんじゃねぇの？とか

俺も今回の Cマガ読んで、　C++/CLI を知ったんですが、機能追加しすぎで混乱しますね。
C++/CLI　というから、C++に最低限の機能を追加したのかと思いきや、もう全然違う言語に感じます。

個人的には、ガベージコレクタだけで十分なんだが。（しかも、もっとシンプルな形で）

あの記事は機能紹介に詰め込みすぎて、C++/CLIの魅力を伝え切れていない気がするね

ポインタとハンドル、ヒープとCLIヒープ、そして、CLI経由での互換性、C++としての旧来の
ライブラリ互換性、コンパイル時展開されるテンプレートと、コンパイル時には生成型と
いう形で一次展開され実行時に正式に型に合わせた形で展開されるジェネリクス

基本的にはC++/CLIはC++に対するCLIのアドオンという位置づけをもっと明確に示して
説明するべきではなかったのかなぁと思われ

ぶっちゃけた話、JVMをJNI経由でC++から直接操作してるようなものだし

>>719
CLIの対応型を純粋仮想関数だけのネイティブ・クラスと混在させないために必要なんだよ
混合型だとC#やVBから呼べなくなるから

>>720
>>714 の８章を読んでみるといいよ。valueクラスのところとか、Javaに対する皮肉や
パフォーマンスに関する苦労がさりげなく感じ取れる（ｗ

つまり.NETFrameWorkの枠組み(他の言語から呼び出せるとか)
への対応が強化された

って理解でいいのかな

ん。C++ユーザーにとって、C#が不要になるくらい親和性が高くなったというとこ

C#見捨てないで・・・

C#、君はいい言語だったが、君のお父上が悪いのだよ

まあ、1からの .NET アプリ開発だとやっぱりC#の方が綺麗だろ。

>>726
私はC++のポリシーの無さが限りなく心地よいのだが、それでも
確かに.netを用いた開発においてはC#の方がC++/CLIよりも開発
効率の点で勝っていることを認めざるを得ない。

Dから(CまたはC++)は利用できますか？
出来るとしたらそのときはmanagedC++使うんですか？

>728
D言語とMC++、C++/CLI には直接的な関係はありません
DからのC/C++関数呼び出しはこちらのｽﾚで聞いてください

D言語 Part 6
http://pc8.2ch.net/test/read.cgi/tech/1109933426/

Beta2 まだかねぇ。結局、for each は採用されるのだろうか
正式な仕様が公表されていないから、実際にどうなっているのかWhidbeyで動かして
見ないとわからんと言うのは問題だな

for each は Beta1 でももう、Visual C++ 2005 Tools Refresh
でアップデートされたときから、サポートされてるよ。
http://www.microsoft.com/downloads/details.aspx?FamilyID=afd04ff1-9d16-439a-9a5e-e13eb0341923&displaylang=en
最初のバージョンとはかなり違って、公表されてる仕様に近くなってるから、
覚悟してアップデートするように。

これ、以前入れたら cl が実行時にセグ落ちするようになっちゃって、もとのBetaを
入れ直した憶えがある
構文が公開仕様に近いなら、試してみたいが・・・うーん

ファイナライザとか実装されてる？

>> 724
C#はもうJIS規格になったよ。見捨てられないね。

フレームワークが標準で着いてくるようになってるけど
まだ9x系使ってる人もいるからな…

さぁ、Beta2が楽しみだ。ファイナライザとインデックスド・プロパティ、混合型が
実現していますように

ところで、正式な仕様はまだ公開されないのかねぇ

Beta2 が出たね。VS2005 のバージョンは、まだ MSDN 会員専用みたいだけど。
Express 版は一般向けに出てきた。
まあ、.NET Framework 2.0 SDK Beta2 さえインストールすれば、
C++/CLI の safe モード機能はすべて使えるはずだから、暇なときに入れとくことにするよ。
STL.NET が付くのはどれなのかな。
http://lab.msdn.microsoft.com/vs2005/downloads/default.aspx

ん。ファイナライザの動作を確認

STL.NET はまだでしょう？

Beta2 にて

・インデックスド・プロパティ：動作
・ファイナライザ：動作
・パラメータ配列：動作
・for each：動作

あとなんかあったっけ？

インスタンス時生成も動いた

コンストラクタでこうするﾔｼ
TestClazz() : _name(gcnew String(L"My Name")) { }

基本的な言語機能は出そろったのかな

ｲｲﾈ

System::StringをLPSTRに変換したいのですが
どうしたらいいでしょうか？

pin_ptr を使う

array<wchar_t>^ arr = stringVal->ToArray();
pin_ptr<wchar_t> pptr = &arr[0];

で pptr を WideCharToMultiByte に wchar_t* として渡せばいい

#include "windows.h"
とライブラリの明示的リンクを忘れないこと

追加。おすすめとしては、基本的にWin32 APIを使う時はユニコードにしておいた方が
大抵のAPIはいちいちMBCSへの変換をかますことなく、pin_ptr を渡せるので
そっちをお勧めする

>>742
stdcli::languageを使うにはどうしたらいいのでしょうか？

using namespace stdcli::languageと書いたのですがダメでした
何を参照すればいいのでしょうか？

えーっと、ごめん。Beta2だよね？
Beta2 では pin_ptr や safe_cast, array<> は stdcli::language 宣言しなくても使えるように
なったよ。だから、逆に宣言してはいけない（はず）

>>745
Beta2とかよくわからないです(´Д｀;)
でも
array<wchar_t>^ arr = stringVal->ToArray();
を書いたら

error C2059: 構文エラー : '^'
error C2065: 'array' : 定義されていない識別子です。

ってエラーが出てしまいます。

それはもしかして、普通に managed C++ でしょうか。VisualStudio は 2005 ではない？
だったら、 >>615 なんだけど

>>747
多分普通のmanaged C++ なのかなぁ
Microsoft Visual Studio .NET 2003を使ってます。

>>615を試した方がいいですかね？
できれば>>615を、もうすこし解説してもらえると助かります。

あ、思いっきり普通の managed C++ ですね。最近、C++/CLIで調子に乗ってたから

managed C++ にはユーティリティ関数がいくつか用意されていて
#include <vcclr.h>
で使えるようになります。

あとは、
PtrToStringChars で System::String __gc * 型を LPCWSTR に変換して、それに
WideCharToMultiByte を実行するって手順になります

これでだいたい判るよね？

>>749
ありがとうございます（＾∀＾ヾ|

なんとか出来そうな感じがしてきました

MC++をデバックすると
ウォッチで中身が確認できないのですが
解決方法ないでしょうか？

＊Microsoft Visual Studio .NET 2003を使ってます。

>>751を知ってる方いないでしょうか？

TRACEするか、System::Diagnostic::Trace 使うしかないんでないかい？

>>753
よくあることなの？
デバッカーが使えないのはなんとも不自由だ(´Д｀;)

がんばります

C++/CLIって正式に出るのはいつなんだ？
今managedC++をやるべきか躊躇している。

ECMA標準化作業は本当は正式勧告は去年末の予定だったらしいが、３月まで延びた
実装はMSしかやっていないわけで、当然、VisualStudio 2005 の出荷待ち

仕事で必要なんだったら、MC++をやる以外に選択肢はないんだが、勉強程度だったら
C++/CLIを押さえておく程度で問題はないんじゃないか

MC++とC++/CLIってどう違うの？

MC++をもちっと使いやすくして
文法を整えたのがC++/CLI

Beta2 の C++/CLI だが、 enum 型の背景型指定が効いていない気がして

public enum class Width : double
{
　　Undefine = 0.0
};

とすると、コンパイル・エラーが出る
　おかしいなと思って調べてみたら、駄目じゃん、int 系の型しか背景型にならないとMSDNに
書いてあったorz

public struct PaperSize
{
　　double Width;
　　double Height;
};

public enum class Paper : PaperSize
{
　　Ax = { 1000.0, 2000.0 }
};

とかできると信じていたのに

さすがにenumは整数型だろうよ...

C++/CLIってC++の文法規則からだいぶ逸脱してるのかい？

既存のc++クラスのコードはそのまま使えるよ
追加分があるだけ

単純にライブラリの追加というよりは、文法にもメスを入れてるのか？

>760
いや、MS から手に入る去年の６月版ドラフトには float, double も可能と書いてある
奴ら実装で手を抜きやがった
あ、いや、信じてるよ。正式リリース時にはちゃんと float や double も背景型に
指定できるって。__int64 まで対応しているから、エリア的には大丈夫なはずだし

>763
そりゃ、基本的な型だけでも参照型と値型の２種類。インターフェイスやデリゲート、属性も
増えてるんだから、文法にも手を入れないとキャストもできないだろ

VS2005にC++/CLIが含まれてるの？

>766
yes
ここで出てる C++/CLI の話は、全部 VS 2005 Beta での話

C++/CLIも中途半端なリリースになっちまうんじゃないか？

ttp://mag.autumn.org/Content.modf?id=20050506023118
こんな事書いてる

確かにその意見には同意するし、C++/CLIへの評価も判る
だが、なぜだろう。疫病神に取り憑かれたような気がするのは（ｗ

ＶＣ＋＋っていう名前がＣ＋＋／ＣＬＩになるのけ？

Jan, 2005 ものを発見
ttp://download.microsoft.com/download/9/9/c/99c65bcd-ac66-482e-8dc1-0e14cd1670cd/C++-CLI%20Standard.pdf

VS2005は
C++のexportには対応してくれてるのかな？

VS2005のスレから来ました。以下、知ってたら教えてください。

VS2005TSβ２、VC8で、共通言語ランタイムを有効にしてビルドした
ものを 実行しようとすると、必要なDLL が無いと怒られました。

手動で.NET Frameworkの該当するフォルダにパスを通せば動く
のですが、手でパス設定しなければならないものでしょうか？
（そんなこと無いと思うのですが）

今までネイティブしかやってないので、勝手がわかりません…
どなたかお願いします。

そのDLLが.NETのアセンブリならパスは不要だが、普通のDLLならパスが必要。
printfなどのc/c++の関数使っているならいくら/CLRでコンパイルしても
呼び出されるDLLはネイティブのものだからパスが必要になる。
具体的にはどのDLLが無いと出たのか書かないと答えられんよ。

>>774
返事ありがとう。
DLLはmsvcr80.dllでした（無記入ｽﾐﾏｾﾝ）
通したパスは
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50215
です。
printfは使っています。

>>774
くだんのプログラムですが、共通言語ランタイムを無効にして
ビルド＆実行したときには特に問題は無いです。

このことは、ネイティブなDLLへのパスは通っているという
解釈になりませんか？

いや

共通言語ランタイム無効で次のオプションでコンパイルしてみ。
実行すると同じエラーが出るはず。
cl /MD xxx.cpp
msvcr80.dllはマルチスレッド対応のランタイムルーチン。シングルスレッドモードの場合は不要。
/CLRの場合常にマルチスレッド対応であることが要求されるため暗黙に/MDが付加される。
VC++6.0用のものは、c:\windows\system32\msvcrt.dll にあるからパスは不要なのだ。
リリース版になったらインストール時にwindows\system32にコピーされるようなるのだと思う。

>>778
元のプログラムがマルチスレッドプログラムなので /MT を使って
ビルドしています。 /MD 使ってビルドして実行したらハングするかも
（共通言語ランタイム無効の場合）

/CLRの時は、コード生成は/MDにしましたが（そうしないとコンパイルエラーが出る）、
それがdllが無いと言われる原因？

ちと混乱してきました。

１・/CLRをつける
２・/MT->/MDにする（共通言語ランタイムでは、MDでマルチスレッド対応なので問題なし）
３・msvcr80.dllが無いといわれる。

という流れですか？　結局回避するにはどうしたらいいのでしょう。

ちなみに、c:\windows\system32 の中には msvcr80d.dllだけありました。
msvcr80.dllを手でコピーしちゃえば問題なくなるのはわかりますが、
要はβ2では、msvcr80.dllを使うプログラムは、自分（VSの使い手）で
何とかせい、ということでしょうか？

_ATL_MIN_CRT

http://www.microsoft.com/japan/msdn/library/default.asp?url=/japan/msdn/library/ja/vccore/html/vcconusing_atl_min_crtinyouratlproject.asp
http://hp.vector.co.jp/authors/VA022575/c/atlmincrt.html
http://home.att.ne.jp/banana/akatsuki/doc/atlwtl/atlwtl08-03/
http://www.hi-ho.ne.jp/babaq/comprog2.html

>780
いや、明示的に printf なんて使ってるからそれじゃ駄目だろう

>779
C ランタイム・ライブラリのBeta版をシステムに入れちゃいかんだろうさ
モジュールの横に置いたら？

>>779
こちらのは前のバージョンなので違うのかもしれないが、
/clr のデフォルトは /MT になってるぞ。/MDは指定可能だが
/MLは不可になってる。/MTじゃエラーになるのかな？
/MT ならモジュールサイズはでかくなるがDLLは不要だ。

>>781
msvcr80d.dll（デバッグ用？）のは知らない間にもう入ってました。

>>782
＞/MTじゃエラーになるのかな？
β2だとコンパイルエラーになります。

VS2005スレで教えてもらったリンクで概要がなんとなくわかりました。
http://pc8.2ch.net/test/read.cgi/tech/1113305966/201-203

>>784
サイドバイサイドか、いよいよWin2000は切捨てかのう。

>>785
XPSP2にVS2005をインストールして試してますが、
2000だとC++/CLIのランタイムはどうなるんでしょうね？

>786
別に変わらんでしょ。COMのサイド×サイドがない振る舞いをするだけで
アセンブリのロードはCLRが管理するから、問題ないんじゃね？

msvcr80.dllはアセンブリじゃないんじゃないの？

>>779
以下、勘違いでした。

＞元のプログラムがマルチスレッドプログラムなので /MT を使って
＞ビルドしています。 /MD 使ってビルドして実行したらハングするかも

/MLと勘違いしてた。 /MTを/MDにしてもハングする訳ないですね。
っていうか、VS2005って、/MLがなくなってるみたい。今気がついた…

スレ違いｽﾐﾏｾﾝ

>788
DLL のロード順て、exe の位置が最優先でしょ
今まで通りサーチは PATH に従うだけで何か問題ある？
mfc の DLL とかと同じ扱いすればいいんじゃねぇの

いいえ

> DLL のロード順て、exe の位置が最優先でしょ

アホか

ん？
MSDN の LoadLibrary には

1.アプリケーションのロード元ディレクトリ。
2.現在のディレクトリ。
3.Windows System ディレクトリ。32->16
4.Windows ディレクトリ。
5.PATH 環境変数にリストされたディレクトリ。

と、書かれているが違うの？

整理するとDLLは３種類ある。
1)普通のDLLは >>793 のとおり、ただしWinXP以降Win32マニフェストで変更可能。
2)ActiveXのDLLはレジストリに登録されたパスからロードされる。Win32マニフェストで変更可能。
3)アセンブリのDLLはCLR管理で、少し端折るがGAC、codebase、exeの位置から相対パスで特定の
ルールで検索。codebaseはアセンブリマニフェストに相対パスで記録される。
（マニフェストも２種類あるのでアセンブリとWin32を接頭語として付けてみた。
マニュアル上の表記ではないがまったく別のものなので区別しないと混乱の元。）
managed c++, C++/CLIはすべてのDLLを使えるため1,2,3を意識しなきゃいかんということ。
msvcr80.dllは (1)なのでWin32マニフェストが機能しないWinXPより前のOSでは
>>793 のリストのどこかに配置しなければならない。
VS2005でコンパイルするとmsvcr80.dllはWin32マニフェストで指定されるため、XP以降は
Win32マニフェストをexeと同じ場所に置くか、Win32リソースとして埋め込むかすればよい。
まあこれじゃユーザーが混乱するのも仕方ないわな。

>794
だから、2kだと変わらんよね？　msvc80.dll はネイティブだから exe の位置に置けば
特に変わらないよと逝っているんだが、なんで漏れが否定されているのかよく分からない(´･ω･`)

>>795
> DLL のロード順て、exe の位置が最優先でしょ
のDLLの部分がmsvc80.dllを指しているのか、DLL一般のことを言ってるのか
区別がつきづらかったのだと思うが、>>792が脳髄反射で反応してるのは確かだ。

.exeの位置最優先じゃないよ
まったくこれだからカスどもは

なんかキレてるｗ

C++/CLIですがref value なクラスは定義部だけでなく実装のコードも含めて
すべて *.h に書くのが普通なのでしょうか？
（そもそも定義部と実装コードは分けられないようですが）
VS2005を使うと*.hにコードがあり、#includeだけの*.cppが生成されます。
全部*.cppに書いても問題ないような気がしますがどうなのでしょうか。

編集んときに楽じゃん
事情がない限りは.hに書いたほうがいいんじゃね？

全部*.cppに書いても問題ない

インライン指定にチェック入れない限り、普通に分離して作成されるけど？

んなことたずねてないと思うけど。

＞ （そもそも定義部と実装コードは分けられないようですが）
の部分は誤りでした。実装コード側に定義部と同じnamespaceをつけるのを忘れて
エラーが出ていました。C++クラスのテンプレートから作成した場合 802さんの
おっしゃるとおりインラインかどうかを選択できました。
普通のC++のクラスでインラインを多用するとロードモジュールのサイズが
肥大化するので心配していたのですが、Managedクラスの場合はそういう問題は
起きないようで、インラインか否かは表記上の問題で生成されるロードモジュール
に違いはでないようです。

C++/CLI めちゃくちゃ違和感ある。

みんななんて呼んでるの？
しーぷらぷらしーえるあい？

しーしり

しぷぷすくり

日本語訳も次々と来てるね

C++: .NET Framework プログラミング最良の言語
http://www.microsoft.com/japan/msdn/vs05/visualc/VS05Cplus.asp

STL.NET 入門
http://www.microsoft.com/japan/msdn/vs05/visualc/stl-netprimer.asp

日本語訳でて来たね。これも重要だ。

変換ガイド: Managed Extensions for C++ から C++/CLI へのプログラムの移行
Stanley B. Lippman
http://www.microsoft.com/japan/msdn/vs05/visualc/TransGuide.asp

>>810
何か後半中部の訳が変じゃない？(前半部と最後は良かったんだが...

>難解で洗練されていない構文を使用すると、開発プロセスにおける危険性が増大します。これは、フロントガラスの汚れや煙が自動車事故の危険性を高めるのと同じです。改訂されたデザインでは、磨き上げられた新品のフロントガラス並みに構文の透明性が向上しています。
ﾜﾛﾀ
>構文糖
>??
>const char* インスタンスに解決されていた解決が、あいまいとしてフラグされるようになりました。
>コンパイル時間ダウンキャスト

＞構文糖
シンタックスシュガー

んなこたわかってるよ

managed C++って業務で使ったことある人いる？
うち何件か企画はあったんだけど検討の結果全部C#になりました。

ライブラリとしてC#への接合部にMC++使ったよ
メインとしてはとても使えないけど、旧来のルーチンをラップするにはベターな選択だ

C++/CLIの方に移るからね。managed C++は消えるでしょ。

名前はmanaged C++のほうがかっこいいよね

C++がCLIになっても、標準ライブラリィとかはどうなんだろう？

ネイティブに対しては変わらない。C++/CLI は特徴として、CLI 拡張を使わない限り
標準C++と変わらない
今までの STL はネイティブに対しては今まで通り使えるし、ref 型とかは STL.NETが
用意される

>>819
Boostは使えるん？

>820
spilit でパーサ使ってるが？

アセンブリという概念が組み込まれてるので、テンプレートはちょっと実用範囲が低下するが
アセンブリ内なら普通に使える
ヘッダ取り込みなんて無様な真似はアセンブリ内で閉じておけと

あ・・・、spilit -> spirit ね

ref クラス内で ::EnumWindows() を使っており、
LPARAM に this ポインタを渡したいのですが、方法がわかりません。

こういうことはできない、またはすべきでなかったりするのでしょうか？

pin_ptr<LPARAM> current = this;
EnumWindows(&func, current);
で駄目なん？

レスありがとうございます。でもコンパイル通らなかったです

ref class A {
　void Enum() {
　　pin_ptr<A^> pinnedThis = &((A^)this);
　　EnumWindows(func, (LPARAM)pinnedThis);
　}
};

これなら通りました、ただちゃんと動いているのかは、まだ見てないのですけど・・・
しかし、

ref class A {
　static BOOL Enum(HWND h, LPARAM lp) {
　　A* a = reinterpret_cast<A*>(lp); // <- 結局これができないので、
　　return 1;
　}
};

どうしたものか、というところです
this を渡しているのは、結局 HWND を自分に渡したいからで、
その辺を LPARAM に頼らない形で作ったほうがいいのかな、とも思っています
と言っても static メンバを使うとかしか思いつかないのですけど、、、

えっと、

A* a = reinterpret_cast<A*>(lp); を

A^ a = interior_ptr<A>(lp);
では？

まぁ、ネイティブのワーククラス作った方が簡単だと思うんだけど

ごめ。間違えた
interior_ptr<A> a = lp;
だね

自己レス、できました

interior_ptr じゃないですけど、

GCHandle gch = GCHandle::Alloc(this);
::EnumWindows(enumProc,
　　reinterpret_cast<LPARAM>(GCHandle::ToIntPtr(gch).ToPointer()));
gch.Free();

コールバック先で

A^ This = safe_cast<A^>(GCHandle::FromIntPtr(IntPtr(lp)).Target);
This->hoge(hWnd);

GCHandle なんてはじめて知りました。

質問です
ref class 内で、windows.h などにある unmanaged の構造体を
メンバにしようとすると、コンパイルエラーになってしまいますが
こういうときは ref なしの class を作ってやるしかないのでしょうか

イベント呼び出しがC#からはうまくいくのにC++からだと失敗するのはなぜ？
こんな感じのユーザコントロール作って、C#からFireEvent()呼ぶと正常。
COMでイベントが発生するとCEvents::OnEvent()が呼ばれる。ここまではOK
で、そこからFireEvent()呼ぶとCOMEvent::OnEvent()呼び出しで
System.ArgumentNullException : 値を Null にすることはできません。
VSでみるとCOMEvent::OnEvent()が<未定義の値>になってる

public __gc class COMEvent:UserControl{
public:
　　__delegate void EventDelegate();
　　__event EventDelegate* OnEvent;
　　void FireEvent(){
　　　　OnEvent();
　　}
};

class CEvents:
　　public IDispatchImpl<IEvents,&IID_Events,&LIBID>,
　　public CComObjectRoot
{
　　BEGIN_COM_MAP(CEvents)
　　　　COM_INTERFACE_ENTRY(IEvents)
　　END_COM_MAP()
public:
　　gcroot<COMEvent*> m_control;

　　void STDMETHODCALLTYPE OnEvent(){
　　　　m_control->FireEvent();
　　}
};

>829
ポインタを使えばいけるんじゃないかな？
C++/CLI使ってないから見当はずれかもしれないけど

だったら答えるなよ

> だったら答えるなよ
> だったら答えるなよ
> だったら答えるなよ
> だったら答えるなよ

>829
その通りです。そういったクラスは混合型と呼ばれ、将来拡張予定の機能です。
それまでは、別に管理クラスを作るか >831 の言う通り、IntPtrに new して
持たせてください

>830
gcroot<COMEvent*> m_control が null 値なんじゃね？
いつ作ってんの？

>>831
>>834
回答ありがとうございます
IntPtr 使って実装することにしました

>830
>835 は間違えた。忘れてくり。
EventDelegate * の OnEvent はどこで生成してるの？

>836
追加ですが、.Net Framework 2.0 では IntPtr に加えてリファレンスカウンタなどの Ptr 型が
増えているので、それらを利用するのも手だと思われます
System::Marshal 周りを探してみてください

>837
このUserControlを使うC#コードで生成してます
inst.OnEvent+=new EventDelegate(hoge);
inst.FireEvent();
と書いてみるとここではちゃんと動くんですよね
その後に発生するCOMイベントから
CEvents::OnEvent()経由でFireEvent()がよばれて、そこだとうまくいかないんです

今ソースないので試せませんが純粋仮想関数でも似た結果だったような

>839
となると、やっぱり、m_control に値が入っていないような気がするんだけど、これって
どの段階で生成されるオブジェクトなの？
gcroot は非マネージド・オブジェクトがマネージド・オブジェクトを保持するエリアだよね
だから、どこかで COMEvent のインスタンスが渡されていないといけないんだけど

出来ました…
たしかにm_controlに値を入れるメソッドを作るのは後回しにしたままでした

m_controlに値が入ってなければm_control->FireEvent();
の時点で失敗するだろうという思い込みが原因でした

ありがとうございました

C++/CLI の STL をいじってるんだけど、
vector<string^>^ a(gcnew vector<string^>^);
微妙な顔文字に見えてきて、微妙。

やめろｗ
そういわれたら顔文字にしか見えなくなってきたじゃないか

Managed C++ってヘッダーに全部実装書くのが普通なの？

C++はメソッドのとかまだなんとついていけたけどC++/CLIとかBoost
入れるとややこしいのが出てくるとついていけない様な感じがして
これから先のC++の印象が…。C#に逃げてしまいそう。
なんかいいH.P.ありませんか？

C#でいいじゃん。
ジェネリクスと無名関数オブジェクトがついた以上
C++をあえて使う意味は無くなったよ。

>あえて使う意味は無くなったよ。

C++よりもマイナーＣ丼にふさわしい形容。

C++/CLI にも無名デリゲートが(　ﾟдﾟ)ﾎｽｨ…

boost::function+boost::bind>>>>>delegate

( ﾟдﾟ) ､ﾍﾟｯ boost::bind
boost::lambda（・∀・）ｲｲ!!

ぁあぁああああぉおぁあああMSﾏﾝｾーーーーーーーー！！！！

>>850
そんな色物いらん

ただのシンタックス・シュガーで充分だから、匿名デリゲートがある方がいい
単純な比較やソートに使うだけだから

Draft 1.14 Aug 2005 が公開されているのを今更ながらに発見
全然追いつけないぉ

ActiveXでmanaged c++使えるの？

主語が逆だぞ

いや、正しいだろ。逆ならみんな答えてる

>>854
実際どうか、試してみないと何とも言えんから、自分でやれ

vs.net2003を買ってC#はある程度かけるようになったのですが
今度C++(学校にある環境はvc++ ver6)を勉強することになりました。

vs.net2003で選べるc++とvc++ ver6のc++って全然別物なのでしょうか？
それとも家でvs.netでc++やっても勉強になるんでしょうか？

>>857
managed じゃなければいっしょ。
vs.net の c++ でも、managed を選ばなければ、vc6といっしょだよ。

＞８５８
やったことないけど、プロジェクトのコンソールアプリでファイル名.cppにしてもWIN32API使えるんですか？
自分では、プロジェクトでコンソールアプリで.cならC言語、.cppならC++、
WIN32アプリやMFCならVCだという頭があったけど。

> コンソールアプリでファイル名.cppにしてもWIN32API使えるんですか

全然使える。
超使ってる。

VC6はC++の準拠度が古いと言うか明らかにおかしいので、細かい差異で苦労しそうではある

c#から、MC++でラップしたdllを使用したいのですが、
managedなdllを作る場合、コンパイルオプションはどのようにつければよいでしょうか？
以下のコードを"cl /clr /LD ***.cpp"というコマンドでコンパイルしても、managedなdllが作成できませんでした。
どなたかご教授お願いします。

class umgd {
public :
umgd() { }
~umgd() { }
show() { printf( "test\n" ); }
}

__gc class mgd {
public :
mgd() { p_umgd = new umgd(); }
~mgd() { delete p_umgd; }
show() { p_umgd->show(); }
private :
umgd *p_umgd;
}

あげ忘れてた・・・age

プロジェクトの段階で選んでおけばいいだけ。

>>862
＞__gc class mgd {
先頭にpublicが抜けてるだけでは。
LNK4243の問題が無ければP/Invokeよりこっちを使いたいよ。

>>864-865
ありがとうございます。早速試してみます。

managed c++ってしょせんC++やってた人と
C#やってた人が同居していちゃいちゃするの

>>864-865
無事dll化することができました。

LNK4243の警告は出ましたが、とりあえずは使えるようなので今はそのまま使っています。
下記に参考になる情報が載っているようなので、もうすこし頑張ってみます。
返答、ありがとうございました。

ttp://support.microsoft.com/?id=814472
ttp://blog.windy.ac/managed_c/

ご教授お願いします
CHOCOAのCCAPIを使って.NETでBOTを作ろうと思っています

MFCの時は登録されていたタイプライブラリからCOleDispatchDriverの派生クラスを自動生成し、
CreateDispatch("CHOCOA.Application");で対応するオブジェクトを得ることができたのですが…

"参照の追加"で生成したdllにInterop::ChocoaLib::CHOCOAというクラスができて、
CHOCOA* chocoa = new CHOCOA();
とすると、このクラスはインタフェイスで生成することはできない、とコンパイルエラーが出ます。

で、隠しクラスっぽいCHOCOAClassというのが入っていたので、
CHOCOA* chocoa = new CHOCOAClass();
とすると、実行時に"DA21EA40-0A85-11D2-901F-00000E7C45FA"というCLSIDは見つからない、と言われました。

regeditでHKEY_CLASSES_ROOT\CHOCOA.Application\を見ると
{F3052B65-0A50-11D2-901F-00000E7C45FA}となっているので、
どうもこの辺が合ってない気がするのですが…

それで、このCLSIDでマネージクラスを生成すればどうにかなるんじゃないかと思うのですが、
どのようにしたら生成できるでしょうか？

すいません、一応ageておきます

>>869
つーかよ、それCOMとして登録されているDLLとInteropに追加したDLLが別もんなんでね？
参照で追加するとき、レジストリに登録されているCOMを指定してやったら？

>>871
えっと、その辺がよく分からんのです。。
正直言ってCOMの仕組みにはあまり自信がないので。。。

HKEY_CLASSES_ROOT\CLSID\{F3052B65-0A50-11D2-901F-00000E7C45FA}\ の下に
InprogHandler32 = ole32.dll
LocalServer32 = CHOCOAの絶対パス
ProgID = CHOCOA.Application
というキーがあったので、chocoa.exeを参照すればいいのかと思ったのですが、参照できませんでした。
他にそれっぽいライブラリ系のファイルは見当たらないです。

今はchocoa.tlbっていうタイプライブラリを使っています。MFCの時も一緒です。
ただMFCの時はCreateDispatchで"CHOCOA.Application"を指定できたものの、
.NETのほうではこれに相当する部分がないなぁ、という感じなのです。

参照の追加をするときにCOMを指定できるっしょ
その時、COMの一覧の中から、CHOCOAを指定してやったらどう？
どうも、そのタイプライブラリと、登録されているGUIDが一致してないようにしか
見えないんだけど

>>873
私も原因はGUIDの不一致だと思います。

で、そこのCOMの一覧にChocoaLibっていうのがあるんですが、
それを選択すると↑で言ったようになってしまうんです。。

「参照の追加・・・」でローカルサーバ（EXEサーバ）は追加できない、っていう問題が
あったような気がするけど気のせいかもしれない。

tlbimp hoge.exe /out:hogeexe.dll とかしてinteropアッセンブリを手動で作ってみては？

>>875
ありがとうございます。ただ、やってみたところエラーでした。

＞TlbImp error: The input file 'C:\Program Files (x86)\Local\CHOCOA\chocoa.exe' is
＞ not a valid type library

今タイプライブラリから生成されたアセンブリを逆アセして
CHOCOAClassのGUIDを書き換えて再アセンブルする
という方法を思いついたのですが、ちょっと怖いな。。

どうやら>>876の方法でできたようです！
何度もご返事くださった方、ありがとうございました。

これはタイプライブラリの生成時がアレだったということなのかなあ。。

VC++.NET2003 でVBなどから参照できるクラスライブラリ作成しております。
基本的には機嫌良く動いているのですが、同じクラスライブラリ内のクラスを
継承した派生クラスでデストラクタを記述しようとするとエラーが出ます。
継承関係のないクラスのデストラクタは成功します。
中身を空にしたりvirtual や　void を付けたり取ったりしても同じです。

また普通にFormのプロジェクト内で作成したクラスの継承では問題ありません。

error LNK2001: 外部シンボル ""void __cdecl __CxxCallUnwindDtor(void
(__thiscall*)(void *),void *)"
(?__CxxCallUnwindDtor@@・・・・)" は未解決です。

クラスライブラリ内で継承したクラスにデストラクタをつけるにはどうしたらいいでしょうか？

放置の模様ですので移動します。

放置というよりは、最近、mc++ を触っていないのでわからないんだよな
簡単なアプリでも起こせるの？

オオー!レスが!
えっと、肝心なことが漏れてたのですが、__gcクラスのデストラクタでエラーが出ます。
__gcをとるとエラーはなくなります。
↓これでエラー再現しました。(クラスライブラリ(.NET)にて)

// test.h
#pragma once
using namespace System;
namespace test
{
public __gc class Class1
{
public:
~Class1(){;}
};

public __gc class Class2 : public Class1
{
public:
~Class2(){;}
};
}

>881
うーん・・・。手元の環境に2003を入れてないので、2005 英語版で試してみたんだけど
/clr:oldSyntax でコンパイル

namespace DestOrth {
public __gc class Class1
{
public:
Class1()
{
}

virtual ~Class1()
{
}
};

public __gc class Class2 : public Class1
{
public:
Class2()
{
}

virtual ~Class2()
{
}
};
}

これちゃんとコンパイルできたよ？
リンク時にトラぶってるのかな

ん？　マネージ拡張でデストラクタ？
http://www.microsoft.com/japan/msdn/library/default.asp?url=/japan/msdn/library/ja/cpguide/html/cpconusingcdestructorsyntax.asp

ﾚｽｻﾝｸｽ。

>>883
こんなのもあったりで、なにがなんやら・・・
http://www.microsoft.com/japan/msdn/library/default.asp?url=/japan/msdn/library/ja/vcmxspec/html/vcmanagedextensionsspec_4_2.asp

それから、新展開がありまして、ｸﾗｽﾗｲﾌﾞﾗﾘ作成時に自動的に作成されるcppﾌｧｲﾙをはずすか、
cppの中の #include "test.h" をはずせば何とかリンクが通るようです。
しかし、cppにｿｰｽ書くなら#include をはずせないし。

実装はすべてヘッダファイルへ、ってことでしょうか。
そういう通例があるというのもどっかで聞いたことがあるような無いような・・

私も気になっています。
VC++では実装はヘッダーファイルに書くことが多いのでしょうか？

クラスライブラリかWindowsフォーム(.NET)か
によっても違うのかもしれませんが。。

実装をヘッダーファイルに書くというイディオムが存在する。
名前は忘れたけど。

うる覚えなんだが、むかーし、mc++ で空の cpp を使っているとトラブった記憶がある
メソッド増やして実装を入れたらコンパイルできるようになった気がする

>VC++では実装はヘッダーファイルに書くことが多いのでしょうか？

STLなんかは全部ヘッダーなんでわ？

>イディオムが存在する。 名前は忘れたけど。

名前があるのは知らなかった。知りたいお。

>>888
＞STLなんかは全部ヘッダーなんでわ？

違うよ。C++用のlibファイルが存在する時点で気づこう。

>>889
iostreamとかlocale関係はたしかにlibファイルが使われているだろうが，
俺が一般的だと思う意味でのSTLの部分はヘッダに全て実装されている。
（コンテナ・アルゴリズム・イテレータ・関数オブジェクトなど）

まぁ、STLっていう言葉自体、規格上の正式な用語ではないからね。

じゃあこうしよう。
WTLは全部ヘッダーだ

っていうかtemplateやるならヘッダーファイルになるんじゃ？

共通実装がlibにはいってるんじゃなかろうか

俺が思うにiostreamはcharとwchar_tで明示的実体化したものがライブラリに入っているのではないかと思う。

>>890
SGIのオリジナルSTLはそうだね。
STLportやgccのlibstdc++のSTL部分は*.cもある。

やっぱ基本は.hだおね。

でも、自分のソースは.hに全部入れると読み難い。

へー。なるほど。

じゃ、ｈファイルに書くかcppファイルに書くかって
どこらへんで判断してるのでしょう。。

簡単には切り分けられない？

だから、クラス宣言以外、つまりクラスの実装部は全部.cppに入れると書きやすいんじゃないの？

言語仕様的には.hに書くのが推奨なんだろうけど。

>>890
本当にそう思うなら、C++のlibとリンクせずにvectorを使ってみてくれ。

890じゃないけど、、、

>>900
C++の文法から逝って論理的に可能。
だからといって、わざわざレスするためにテストしる！というのは如何なものかと。

>>901
結論からいうよ。無理なんだよ。
メモリのアロケーションに関する部分がライブラリ依存なの。
「論理的に可能」とか意味不明なこと書くな。
論理的って何だ？まずは、そこから教えろ。

メモリのアロケーションがlibだからって、
STLがcppも必要だとは如何なものかと。

ライブラリ依存を.hに絶対入れることが出来ないわけじゃないお。

>>899
言語仕様的には.hにすべて書くのが「推奨」なのでしょうか？

>>902
実際に試してみたらたしかにCのライブラリ(libc.lib)が必要だった。
どうやらメモリ関係にスタートアップルーチンと例外処理などがCRTを必要とするようだ。
（メモリ確保だけは自分でAllocatorを書けば済むが）

しかし、たしかにC++のライブラリ(libcp.lib)は不要にできた。
length_errorがstd::stringを使っているのが問題だったがこうして回避した。だめか？
#define _STDEXCEPT_
namespace std
{
    class length_error
    {
    public:
        template<typename T>
        length_error(T)
        {
        }
    };
}
#include <vector>

>>898
libstdc++なんかはかなり恣意的。基準があるとは到底思えない。

自分は全部.hに書く流儀。
別途プロトタイプ宣言書くのが面倒と言うだけの理由。

最初にオリジナルSTLを見たときはかなりビビッた。
あんな大きいクラスライブラリで全部.hなのは始めてみたので。

けど今は心配するのはよして、.hを愛するようになった。

お陰で、プリコンパイルヘッダの有り難みを身に染みて感じるようになった。

C++アンマネージ拡張 ってのがあると聞いたんだが、誰か知ってる人いますか?

>>909
VC++用に書いたclassがMC++から呼び出せる。
具体例はヘルプにすんごく分かりやすいサンプルが載ってるからそれを見るべし。

猫でも〜は辛うじてGDI+のところでC++でないとコンパイルできないプログラムを作っているな。

managed C++ やろうぜ！！ 002
http://pc8.2ch.net/test/read.cgi/tech/1139043535/l50

.Net 2005は出たばっかだから、業務にはちょっと…。
ということで、やっとこさっとこ、.Net2003に移行。いままで、V6だったからなぁ…。
manage C++ に初挑戦ですよ。

>>913
悪いことは言わん、VS2005に上げてC++/CLIに取り組め。

>>914
なんで?　

それって、説得できる情報がないと、みんな動いてくれないんだよね。
出たばかりだと情報も少ない事が分かってるからね。バグもしかり。

納得できる回答を望む。

逆に何故今managed C++なの?

納得できる回答を望む。

>>916

>.Net 2005は出たばっかだから、業務にはちょっと…。

回答は出てるだろ?

>>915
managed C++の欠点。
キーワードが下線ばかりで汚い。
デストラクタの発動がC#と同じGCされるとき。
マネージオブジェクトはnewしないと作れない。
マネージオブジェクトに対して演算子多重定義が使えない。

>>918
つまり、言語仕様が少し古い…と言うことなだけか?　CLIの方が洗練されていると言うだけ?
コード書くだけがプロジェクトじゃないから、そんなことはとても些細なことだな。

そんな答えで、納得できるヤツはバイト君ぐらいなモンだ。
出直せ。

C++/CLIはこれからの言語だけど
Managed C++はいつ切り捨てられるかわからない言語

でも、仕事では金が絡むからな。切り捨てられても、.Net2004を使っていれば問題ない。
つーか、まだVC6が現役なところも変えず多くあるんだぞ?
少なくとも、サービスパックが複数出てからじゃないと C++/CLIには移行できないよ。

枯れる前に摘まれちゃったManaged C++に敢えて行く理由がよくわからないな。
C++/CLIが枯れるまでVC++6.0でいいじゃない。

managed C++は、将来バグフィックスされるかどうかもわからないのに、

> 切り捨てられても、.Net2004を使っていれば問題ない。

なんて良く言えるね。どっちも調査だけで業務はスルーしとけよ。

>>923
.Netはライブラリとして、多機能。

話を誤解してるな。
.Net2004でクオリティをクリアしたアプリをメンテナンスするには.Net2004を使い続ければよい。
ということだ。

バグフィックスされることより、バグを避けられることが重要。
その点、manage C++ は情報がある。

managed C++にバグがあったとしても、できあがった製品のクオリティと運用に問題がなければ、
そのバグは存在しようがしまいが、問題ない。

何この馬鹿?

釣れた！

学生はクソして C++/CLIとかいうヤツに必死になってればぁ?

そもそも.Net 2004とは何？

釣れた！

>>928
池沼は無視

で、manage c++から C# を呼び出すってのはどうやんだ?

>>931
参照設定（#usingやプロジェクトのプロパティから）

マーシャリングの必要もないのか?

いらん

つまり、C#のクラスを manage C++からは参照設定でOK。

んじゃ、unmanage C++からは?

CLRHosting

>>936

めんどくさそうだな?　簡単か?

自分で調べようとしないおまえには無理だろう

何だ、そりゃ?　ブルーワーカーが板についたご回答だな。

しかし、C#側でメモリマネージャから特別扱いしてもらうような、指定は出来ねーのか?

・・・(ﾟДﾟ)ﾊｧ?

unmanage C++から呼ぶには
やっぱCOMでしょ

COMなんてめんどくせーコトしなきゃ、呼べねーのか?

C++とCOMは異常に相性が悪い。

2005は最適化がクソだからなぁ。バグも派手に出てるし。
今はまた、2003が正解。

>>943
それ名言じゃん！

943とCOMは異常に相性が悪い。

市滅したCOMと相性が良い人って誰？

DONBOX

SOAPも DONBOXが絡んでるんだよな…。
おかげで…。Toolkitは最悪だったんじゃないかと想像。

COMって無駄にメモリを消費する希ガス

>>950
何を根拠に？

.NETよりましだろ

.NETはいいものだ
ライブラリはいいぞ

ただのクラスライブラリだろ？

とんでもMFC使わされてたやつとかﾌﾞﾋﾞﾁｭｳが良いものと思うだけで別にふつー。

Gehandhabtes C++

ただ、マーシャリングが非常に面倒。
managedは遅いから極力使わないようにしてるし。

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

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

新手のウィルスか?

クラスライブラリ作成時に、継承関係にあるクラスにデストラクタを
実装するとリンクエラーがでてビルドできない現象がようやく解決しました。

結論から申しますと　msvcrt.lib　をリンクすることで解決しました。

実は、半年近くデストラクタはあきらめた状態でいたのですが、
今度は new や delete でも 未解決シンボル のリンクエラーが出て
再度調べたところ、msvcrt.libにたどり着き、これで、デストラクタも
解決できてしまいました。
ちなみに ヘッダファイルにすべて実装する、というのは見当違いでした。

VC++.NET2003でmanaged をやっています。
とあるプロジェクト内で、サブのForm Classを新規作成したのですが、名前空間を
入れ子にするとデザイナでエラーが出てフォームが表示されなくなります。
（このファイルのデザイナに、デザインできるクラスがないため、デザイナを表示できませんでした)
コンパイル／リンクは問題なく行われ、実行時のエラーも出ずに、作成したFormを表示もできます。
デザイナの問題と思われます。

これを回避できる策に心当たりある方がおられましたら、ご教示願います。

こんな感じ。
namespaceを入れ子にしなければ、名前を変更しても
デザイナで表示もできるのです。

namespace AAA{
namespace BBB{

　　public __gc class Test : public System::Windows::Forms::Form
　　{
　　　　　(略)
　　};
}
}

私は今C#でプログラムをしています。string型の二次元配列使用時、
値が入ってないとき「未定義の値」と表示。値が入って無い場合の
チェック文をそのまま素通りしてしまう。この場合の対処策を
ご教授願います。以下にそのコードの内容を書いておきます。

string[][] st = new string[][];
st = new string[10][];
この後、ﾙｰﾌﾟで各要素にﾒﾓﾘｰを持たせ、値を入れる。
値が入ってないかを見る条件分は以下の通り。
if(st[i][y] != null && st[i][y] != "")

ふみぱいんより。

>>962
＞私は今C#でプログラムをしています。
日本語が不自由な方のようですが、ここはその質問に適当な場所ではありません。他をあたりましょう。

>>963
日本語の不自由な方っぽいけど、誘導先も書いてあげようよ。
C# と Managed C++ は別。C# でスレ検索かけろ、くらいでいいから。

つ　ふらっとC♯（初心者用） Part8

人少ないと思たら、案外みてるんかな。

みんな、CLIに移行したんかなぁ。
CLIがいやでmanagedにこだわってる人っている？
二重下線が汚いという理由をよく聞くけど、 ＾ とか ^>^(顔文字) とか gcnewとかのが俺はいや。
暗黙のbox化なんかも余計なお世話って感じ。(でも、なれたら後戻りできなくなるかも)。
んなとこ変えるくらいなら @"c:\hoge\" + fileName + ".txt" とか装備してほしい（されてんの？）

でも、探してた機能がFrameWork2.0で追加されましたとか最近よく出てきたし、
なんかいいことあるかも、みたいな期待感で、私もC++/CLIに移行する予定です。
ありがとう、managed ！！

gc new

>>966
#define E(s) #s

E(C:\hoge\) + fileName + ".txt"

>>968
単純に"C:\hoge\"　と展開されるので
＞warning C4129: 'h' : エスケープ シーケンスとして正しく認識されませんでした。
が出る。

C++/CLI 今ダウンロードして実行したけど、Stringの＋演算子は使えるみたいですね。
@"..."　もサポートされてないし、>968もうまく動作しないけど。

うわ、ごめん。
\とかもエスケープしてくれるもんだと思っていた。

パスの区切りなら「大抵」スラッシュでもいけるからそっちへ逃げる方向で勘弁して。