- PR -

Managed C++ != C++

投稿者投稿内容
DaigoH [MSFT]
会議室デビュー日: 2002/07/31
投稿数: 3
投稿日時: 2002-07-31 08:29
はじめまして

Managed C++を使っていただき、ありがとうごさいます。
あまりこのスレッドと関係ないかもしれませんが、めったにManaged C++
についての質問を見ないのでついでに投稿させていただきます。

以下のリンクにManaged C++とTemplateを使ったサンプルがありますので、
よかったら読まれてください。
http://msdn.microsoft.com/msdnmag/issues/02/02/ManagedC/ManagedC.asp

下の二つのリンクはもう少しManagedC++の一般的なことについて
書いてあります。
http://msdn.microsoft.com/msdnmag/issues/02/02/ModernC/ModernC.asp
http://msdn.microsoft.com/msdnmag/issues/01/07/vsnet/vsnet.asp

なぜManaged C++が作られたのか?"なぜ"、"どこに"Managed C++使うのか?
などについて書きたいのですが、今回はあまり時間がないので、
またの機会にさせていただきます。

最後に、これからもフィードバックをよろしくお願いいたします。

DaigoH [MSFT]
_________________
This posting is provided "AS IS" with no warranties, and confers no rights.

この投稿は現状のまま何の保証もなく掲載しているものであり、何らかの権利を許諾するものでもありません。
NothingButXMLInfoSet
大ベテラン
会議室デビュー日: 2002/07/16
投稿数: 116
投稿日時: 2002-07-31 11:12
すみません、遅くなりました。

引用:

Jittaさんの書き込み (2002-07-23 09:02) より:
とすると、実行時にDBAccessのデストラクタでconnectの実態がないというエラーになります。おかしいなぁ??今までこういう書き方でいけてたのになぁ、と3時間ほど悩んで、「デストラクタは別のスレッドで実行される」ことを思い出しました。ということは、DBAccessのインスタンスより、それが持っているOleDbConnectionのインスタンスが先に解放されてしまっている(可能性がある)ということですか?!


この件ですが、USのMSの方にバグであることを確認してもらいました。OleDbConnectionのバグですので、ひとまずFinalizeとマルチスレッドの問題とは関係ない、ということで。

引用:

Jittaさんの書き込み (2002-07-24 08:25) より:
...(略)というクラスを作りました。「delete a;」がエラーになったので「a->Finalize();」とやると、通るんです。String::Finalize()はProtectedメンバーですよね。それならば、class Aからは呼べないはずですよね?


確かに。少し調べてみたところ、次のことがわかりました。
1) System::Objectから直接派生し、しかもFinalizeを実装していないクラスに対しては、Finalizeへの呼び出しがコンパイルも通り、実行も可能。System::Stringはこれに該当します。
2) 自分ではFinalizeを実装していないが、自分の基底クラス(System::Object以外)が実装しているクラスに対しては、Finalizeへの呼び出しがコンパイルは通るものの、実行時例外(MethodAccessException)になる。System::Drawing::Bitmapなどがこれに該当します。
3) 自分でFinalizeを実装しているクラスに対しては、Finalizeへの呼び出しがコンパイルエラー(C2248)になります。
こちらも投げてみましたが、まだ確かな回答は得られていません。

引用:

yaさんの書き込み (2002-07-25 19:27) より:
結局、たぶんこれは、C#のプログラミングスタイルからすると異質なものなんでしょう。だから論点がずれたような。飛躍してすいませんが、この問題は根本的には、デストラクタがない、ということに集約されると思います。そのことをクラスの設計段階から考えた上でプログラムすれば、この問題にはほとんどあたりそうにないですね。


納得しました。 つまり、他のオブジェクトの寿命を自分の寿命と一致させようとしているにもかかわらず、そのオブジェクトの管理を他者(staticなコレクション)にやらせているためにこういうことが起きるのですね。staticは一見自分の一部のような気がしてしまいますが、その実yaさんのご指摘どおり、ロード後はいつまでも存在する他のオブジェクトですから。

引用:

ただ、リスト操作をファイナライザで行う事はないっていうのは私はどうも断言できないんで、ファイナライザの動作を頭の隅に置いておきます。少し冗談が入っていますが、このようなものとか。
class Foo
{
~Foo(){ Log.Add(ToString() + " is Finalized"); }
}


これまた納得しました。 ただしこの場合、Logが自分のインスタンスフィールドだった場合は、問題になります。自分のインスタンスフィールドは自分より先にFinalizeされる可能性があり、Finalizeの中で触ろうとすると例外になる可能性があるから(だそう)です。一方、何らかのstaticフィールドである場合も問題です。Log.Addの実装が、回りまわってFinalize済みオブジェクトに触る可能性があるから(だそう)です。もちろんLogが自分で実装したものであればそのような心配はせずに済みそうですが。「だそうです」というのは、私の観察結果ではなく、これにそう書いてあったからです。

ちなみに、
引用:

yaさんの書き込み (2002-07-22 04:04) より:
ちなみにマルチスレッドなんですが、lockとかありますし、完全に考えから駆逐するのは、無理のような気もします。C#はとても扱いやすくなっているので問題にはならないとは思いますが。


という話なんですが、こういう研究をしている人たちもいます。今日の無理は明日の常識かもしれないということで、一応。
Jitta
ぬし
会議室デビュー日: 2002/07/05
投稿数: 6267
お住まい・勤務地: 兵庫県・海手
投稿日時: 2002-07-31 13:13
こんにちは。
●OleDbConnectionの件
●Finalizeの件
 わざわざありがとうございます。・・・ しかし、なんといいますか、「完璧なもの」なんてないのですが、「仕様」と「バグ」のあやふやなところが、こう、使う意欲をなくすというか・・・

 とにかく、「VS.NETを使って」ということで3ヶ月ほど進んできたProj.ですが、「プラットフォームから見直す」ということになりました。 内作ツールなのでこんなことできるんですけど・・・だつりょく・・・

スキルアップ/キャリアアップ(JOB@IT)