COM の世界を斬る！
■ このスレッドは過去ログ倉庫に格納されています
0001IUnknown
NGNG0312デフォルトの名無しさん
NGNGじゃぁ、今使っているCOMの機能をすべてsocketで実装してください。
まぁ君が今使っている機能ぐらいなら作れるだろうな、
どうせ関数呼び出し程度しか使ってないだろうから。
それに、バイト君は暇だからいいけど、プログラマはそんな
低レベルな実装を時間をかけてわざわざやらないのだよ。
0313デフォルトの名無しさん
NGNGsocketでは無くCOMにして良かった例
・COMならsocketで書かなくてならない面倒くさい処理を書かなくてすむ
socketで出来ない処理があるかって言うとそれを探すのは難しい。
しかし、問題はそこじゃないんだよ。
問題は今作っているものにどっちがふさわしいかってこと。
C++でやれることは全てアセンブラでも実現可能だろ。
しかしアセンブラを使用することは少ない。その理由と同じさ。
0314デフォルトの名無しさん
NGNGもしかして、COMを使わないで似たようなことやるには
自前でプロセス間通信して〜って話ですか？
0315デフォルトの名無しさん
NGNG涙が出ます
0316デフォルトの名無しさん
NGNG上げてくれる方法が、いまやいろいろ（COM/CORBA/RMIなど）あるっつうのに、
未だにsocketでなんでもやろうとする奴は、究極の車輪再発明野郎だとおもう。
しかもそういう奴は、どういうわけかそのことにプライドを持っている。なんでだ？
0317デフォルトの名無しさん
NGNGネットワーク層やデータリンク層に手を入れられるからでしょ。
0318デフォルトの名無しさん
NGNGCOMじゃなくてDCOMだろ
0319デフォルトの名無しさん
NGNG総称っつーことで
0320デフォルトの名無しさん
NGNG0321デフォルトの名無しさん
NGNGそんな必要があることは、あまりないと思うが…
セキュリティ関係でプレゼンテーション層を変更する必要があることは
多いけど、こういった機構を使っていても、それは可能だしね。
0322デフォルトの名無しさん
NGNG環境変数よりはマシだと思う。っていうかCLASSPATH逝ってよし。
0324デフォルトの名無しさん
NGNGはぁ？
GUIDはむしろ歓迎だろ。
本当にUniversal Uniqueだとしたら
0325デフォルトの名無しさん
NGNG0326鯛焼きクン
NGNG合意がなければ何も作れない。その決め事をフレームワークって
いうかどうかは別としても、おれはその意味をそう捉えている。
COMを使いましょうって決まったのなら、可能な限りその範囲内で
問題を解決しようっていうことだから、もしSocketで十分なものだと
判明しても、間違っているのは最初の合意（COMの採用）であって
COM自体の優劣の話じゃない。
0327デフォルトの名無しさん
NGNGソケットでやっても、COMでやってもかかる時間はそんな変わらんよ。
>しかしアセンブラを使用することは少ない。その理由と同じさ。
ネタ？(w
COMの位置付けが全然わかってないようで・・・・
COMとソケットの関係が,C++とアセンブラだってさ（ｗ
>未だにsocketでなんでもやろうとする奴は、究極の車輪再発明野郎だとおもう。
なぜ？
俺はソケットの方が､短時間でできる例しか知らないから、
ソケットでやった方が優れていると主張してんだけど。
車輪の再発明とかほざく奴は、どういうわけかそのことにコンプレックスを持っている。なんでだ？
>上げてくれる方法が、いまやいろいろ（COM/CORBA/RMIなど）あるっつうのに、
そういう奴に限ってXMLは重いと言う罠
まあJavaだけ使うなら、RMI便利だけどね。
どーせ、おまえらIDLすらよくわかってないんだろ。
で､結局COM使って良かった例は
・ASPしか使えない奴がプログラマーと名乗ってる組織で仕事する時
だけなんだね。
0328デフォルトの名無しさん
NGNG> ソケットでやっても、COMでやってもかかる時間はそんな変わらんよ。
どんなことをやっているのか教えてください。
0329デフォルトの名無しさん
NGNG> ソケットでやっても、COMでやってもかかる時間はそんな変わらんよ。
「時間は変わらん」というだけなら誰でもできるよ。たとえそれがウソでも。
実例をあげなさい。
> COMの位置付けが全然わかってないようで・・・・
> COMとソケットの関係が,C++とアセンブラだってさ（ｗ
あなたの意見は？ COMの位置付けを説明してよ。 笑うだけなら誰でもできるからさ。
> 俺はソケットの方が､短時間でできる例しか知らないから、
> ソケットでやった方が優れていると主張してんだけど。
そりゃソケットの方が短時間でできるならソケットを使うよ。
じゃぁソケットで時間がかかるときはどうするの？
ソケットの方が､短時間でできる例しか知らないのね。
> 車輪の再発明とかほざく奴は、どういうわけかそのことにコンプレックスを持っている。なんでだ？
「そのこと」ってどこにかかっているの？
> そういう奴に限ってXMLは重いと言う罠
なんでいきなりXMLが出てくるの。だれもそんなこと言ってないでしょ。反論になってないよ。
> で､結局COM使って良かった例は
> ・ASPしか使えない奴がプログラマーと名乗ってる組織で仕事する時
なんでASPなの？ ウソならだれでも言えるからさ、根拠を言いなって。
的外れな意見ばかりだね。もう少し日本語勉強して出直してきなさい。
0330デフォルトの名無しさん
NGNGそういうことだから､教えてくれって言ってるんだよ。
で、短時間でできる例がわかってると認識されてるわけだから、
実例挙げなくてもいいのか？
>なんでいきなりXMLが出てくるの。
逝ってよし
329はえらそうな事言ってる割には、知識乏しいみたいだね（ｗ
実例挙げろ､とか根拠とかさ
結局おまえ何もわかってないだろ。
ASPとVBに訂正して欲しいか？
>的外れな意見ばかりだね。もう少し日本語勉強して出直してきなさい
ストレートに書かなきゃわからん奴は、
´_ゝ｀<<ひっこんでろ！！
0331デフォルトの名無しさん
NGNGどうやって広告するんだよ。
固定か？/etc/serviceか？ロケータサービスか？
いずれにしてもおめでてーな。
0332デフォルトの名無しさん
NGNGCOMだってそこらへんはしょぼいじゃん(w
0333デフォルトの名無しさん
NGNG0334デフォルトの名無しさん
NGNG君の話を聞いていると、Inner-Networkなのばっかりやん。
COMのInner-Process, Inner-Machineな部分は無視ですか(w
0335デフォルトの名無しさん
NGNG0336デフォルトの名無しさん
NGNGSOAPでやりとりするデータ形式という認識であってる？
結局ここで話しているのはsocket vs COMじゃなくSOAP vs COMなわけ？
SOAPよく知らないから変なこと言ってたらすまん。
0337デフォルトの名無しさん
NGNGあってない。SOAPとCOMは関係ない。この文脈のXMLってのは単にｱﾌｫが
勘違いしてるだけ。
0339デフォルトの名無しさん
NGNGXML InfoSetについて調べてみよう。SOAPは＜＞じゃないよ。
0340デフォルトの名無しさん
NGNGよくわからんが、分かった。XMLとSOAPについて調べる。ありがと。
0341デフォルトの名無しさん
NGNGごめん無視してた。
開発者側から見て､というつもりだったので
>>337
比喩がわからんおまえがアフォ
つーか､COMのリスクが分かってないのか？
0342デフォルトの名無しさん
NGNGおまえ、>327じゃねーの？どこが比ゆなんだ？比ゆってなんだかわかってないだろ？
0343DCOM使っている人いるの?
NGNGオブジェクトの参照カウントってどうなるんだ？
ちゃんとIUnknown::Release()されるの？
Releaseされないで放っておかれると、
オブジェクトユーザが死ぬたびにオブジェクトが
放置されるから、ちゃんとReleaseされるんだよね。(たぶん)
0344デフォルトの名無しさん
NGNGReleaseされる。DCOMは分散GC実装してるから。
0345デフォルトの名無しさん
NGNGたぶん、GCできるかどうかどうやって判断するんだ？
ってことだと思うが
0346デフォルトの名無しさん
NGNGPing。
0347デフォルトの名無しさん
NGNG嘘だろ？いくらマイクロソフトだからってそんなことは・・・
0348デフォルトの名無しさん
NGNG0349DCOM使っている人いるの?
NGNGそうそうおもいだした。
MSKBのQ171414にこれのメカニズムと停止方法が書いてある。
PINGを使って生存確認している。当然、誰がどのオブジェクトの
ポインタを持っているのか、AddRefしているかを管理しているわけだ(はずだ)
でオブジェクトユーザが異常死亡すると
その人がAddrefした分、Releaseされるわけだ。で合っているよね。
ということは
IConnectionPoint::Adviseしたオブジェクトが死んだ場合も
IConnectionPoint::Unadviseされるんだよね。
ほかにもIOleObject::AdviseやIDataObject::DAdviseもそうだよね。
それともAdviseしているオブジェクトのメソッドを呼んで
RPC_E_FAULTにでもなったら自分でUnadviseしなければならないの？
0350デフォルトの名無しさん
NGNGが生きているかどうか調べているんじゃなかったでしたけ？
あと、Proxy/StubでAddRefやReleaseも最初と最後しかネットワークに
送信しない様に最適化してるって話も聞いた事がある。
システムでウマーくやってくれてるんじゃないでしょか？
0351DCOM使っている人いるの?
NGNGQueryInterfaceの非効率さに気がついて、
MULTI_QI構造体を用意したくらいだから
0352デフォルトの名無しさん
NGNG0353デフォルトの名無しさん
NGNGそうですね。そっちの方が詳しく書いてある。
で、Adviseの件はどうなんでしょう？
だれか教えてください。自動的にUnadviseされるなんてやっぱり甘い?
自動的でなければ、せめて、死んだことが死んだ時点か
それに近いタイミングで通知されるような仕組みがあると楽なんだけど。
0354デフォルトの名無しさん
NGNG0355デフォルトの名無しさん
NGNG0356デフォルトの名無しさん
NGNG0357デフォルトの名無しさん
NGNG0358デフォルトの名無しさん
NGNGコンストラクタ／デストラクタ持ってる言語でも
うまく破棄されない場合があった気がする。
0359John ◆0z.4Is5E
NGNG酸
0360デフォルトの名無しさん
NGNG0361デフォルトの名無しさん
NGNGそれじゃ話が終わっちゃうじゃん
0362デフォルトの名無しさん
NGNG禿同
0363デフォルトの名無しさん
NGNG0364デフォルトの名無しさん
NGNG禿同
0365デフォルトの名無しさん
NGNGバグとも言い切れない
0366デフォルトの名無しさん
NGNG確保できた資源が、解放時にエラーになる？
それはどのシステムのどんな資源でしょうか？
0367デフォルトの名無しさん
NGNG禿同
0368デフォルトの名無しさん
NGNG参照カウンター
0369デフォルトの名無しさん
NGNG0370デフォルトの名無しさん
NGNGまぁた路線変更に迫られるのですが？
0371デフォルトの名無しさん
NGNG0372デフォルトの名無しさん
NGNG0373うぴゅ
NGNG0374デフォルトの名無しさん
NGNGMozillaのソース見たことないのか...
0375デフォルトの名無しさん
NGNG0376デフォルトの名無しさん
NGNGinner-processだけだし
http://www-106.ibm.com/developerworks/webservices/library/co-xpcom.html
0377デフォルトの名無しさん
NGNG0378デフォルトの名無しさん
NGNGヒープが壊れたときとか。
0379デフォルトの名無しさん
NGNGUnadviseされるわけがない。
理由：Proxy/Stubがそこまで考慮していないから。
0380デフォルトの名無しさん
NGNG＞だれか教えてください。自動的にUnadviseされるなんてやっぱり甘い?
カメレスで済まないけど、Adviceつーても、
単に内部で参照カウントとインターフェースのポインタ
持ってるだけだということを考えませう。
クライアントが落ちてもサーバーが落ちても、
DCOMがRelease( )してくれるのなら
メモリリークはとりあえず発生しない。
0381380
NGNGUnadviceはもちろんやってくれないので、
接続のはがれたインターフェースポインタがいつまでも居座ることにはなる。
DCOMがどんな風にRelease( )するかによるけど、安全性の観点から見て、
多分落ちることはないのではないかと思う。
（使うと常にエラーを返すようになると思うが）
ほんとは、そのあたりでエラーを検出したらインターフェースを取り外すように
Proxy/Stubを吐いてくれると無駄が無くていいのだけど。
そこまではしてくれていない。
VC++のウィザードが作るコードは、大雑把にはvectorでインターフェースを複数
保持して、それらをお構いなしにコールしているだけだと思った。
（エラーが返るからまあいいじゃねーか、という考えなのかな？）
0382デフォルトの名無しさん
NGNGATLのIConnectionPointの実装だと(純粋なCOMというスレの趣旨だがサンプルということで)
Adviseしたオブジェクトのシンクインタフェースへのポインタを固定長の配列で保持している。
だからUnadviseし忘れたオブジェクトがいくつもあってもそのうち、保持しきれなくなる。
あとからAdviseしてきてもCONNECT_E_CANNOTCONNECTと返すほか無くなる。
人によってはIConnectionPointの実装を可変長配列やリストで管理していたりする。
そうなるとおそらくヒープにとるので、Unadviseされないとメモリリークになる。
よくありがちなのが、クライアントが死んでものだからしょうがなく再起動するを繰り返したりする場面。
クライアントが異常終了から再起動するたびに、どんどんメモリリークするかAdvise可能な回数が減る。
DCOMをつかってサーバーから接続しているクライアントに一斉にイベントを投げるようなシステムは気をつけたほうがいい。
こんな状況でもAdviseを受け付けられるようにメモリリーク覚悟でヒープからとるか
固定長の配列で、あふれるようなら拒否するかどっちが良いか悪いかわからんが問題があることは確かだ。
(俺としてはAdvise可能な回数は制限したほうがいいと思うけど)
というわけでイベント送出時にRPC_E_なんとかとなったら自分でUnadviseするのが無難だろ。
VBは自分でUnadviseなんかできないな。
VB屋さんが、DCOMで簡単にサーバークライアントシステムが組めるや、
ちょちょいのちょい。なんて調子で安易にDCOMを使って、
しまいにはどうしたらいいかわからなくなる。
これでもWindowsDNA(死語)の基幹テクノロジーなんだがね。
0383デフォルトの名無しさん
NGNG0384デフォルトの名無しさん
NGNG0385デフォルトの名無しさん
NGNGおいおい、リモート・ローカル等価性はどうなったんだ？
IConnectionPointはリモートで使ってはいけないから
リモートとローカルで等価ではないってことだな。
実はリモートに限らずローカルサーバーもやばいんじゃないか？ということで等価か。
とIConnectionPointひとつを重箱の隅を突くように取り上げて煽ってもしょうがないが
現実問題として、IConnectionPointに限らず、リモートオブジェクトから
インタフェースを渡されるような場面は気をつけたほうがいい。
渡してきた相手がこそっり死んでいるようなこともあるんで。
0386デフォルトの名無しさん
NGNGVBはUnadviseを勝手にやってくれたりはしないのかな？
0387デフォルトの名無しさん
NGNGそうではない。ここで問題になっている程度の、それなりにそれなりが要求される環境で、
しかもDCOMを使っている場合ってこと。
>>385
Effective COM読んでね。
9. Avoid connection points
0388デフォルトの名無しさん
NGNG0389デフォルトの名無しさん
NGNGVCでCOMつくってVBScriptから使おうと思ったんですが、
VBScriptに2つ以上の返り値を戻す方法がわかりません。
つまるところ、
Set Hoge = CreateObject("Hoge.Hoge")
Status = Hoge.Func(InVal, OutVal, OutVal2)
IF OutVal = "aaa" And OutVal2 = "bbb" Then
みたいな設計はできないんでしょうか？
0390デフォルトの名無しさん
NGNGできません。VBScriptの制限事項です。
0391389
NGNGがっくし。SAFEARRAYとVARRANTつかって配列で受け渡しするしかないか・・・
0392デフォルトの名無しさん
NGNGCOM側(VC):
[propget, id(10), helpstring("ﾌﾟﾛﾊﾟﾃｨ RemoteHost")] HRESULT RemoteHost([out, retval] BSTR *pVal);
[propput, id(10), helpstring("ﾌﾟﾛﾊﾟﾃｨ RemoteHost")] HRESULT RemoteHost([in] BSTR newVal);
クライアント側(VBscript):
Hoge.RemoteHost = "myhost"
みたいな。
でこの場合、getやputでエラーとなった場合の処理ってどう実装すればいいんでしょうか？
とくにputの場合エラーとなってもクライアントは判定できないです。
0393デフォルトの名無しさん
NGNG0394デフォルトの名無しさん
NGNG0395393
NGNGVBSならON ERRORで処理するんちゃうんか？
それともVBSはput時のエラーは無視する仕様なの？
0396ななし
NGNGVBからオートメーションでExcelを操作するのに、事前バインドと実行時バインドでどのくらい
レスポンス差があるのか気になって、
(1) 事前バインドで Dim .... As New Excel.Application
(2) 事前バインドで Dim .... As Excel.Application → Set .... = New ... でインスタンシング
(3) 事前バインドで Dim .... As Excel.Application → Set .... = CreateObject ... でインスタンシング
(4) Dim .... As Object → Set .... = CreateObject ... で実行時バインド
の4通りを比較してみたところ、(4)が一番速いという、予想外（常識はずれ）の結果となってしまい
ました。（ベンチマークの内容は、DAOのRecordsetをExcelに出力する、というもの）
COMの解説書には、事前バインドの方が高速と書いてありますが、どうして期待した結果にならないの
でしょうか？
ちなみに、インプロセスサーバを参照してコンパイルしたEXEを該当するコンポーネントがレジスト
されていない端末で起動するとプロセスが起動せずにクラッシュしますが、上記(1)〜(3)のEXEを
Excelがインストールされていない端末で起動しても、エラーにならずに正常に起動してしまいます。（無論、オートメーション機能は動きませんが）
インプロセスコンポーネントと、アウトプロセスコンポーネントでは、バインドの仕組みが違うの
でしょうか？
ご存知の方、コメントお願いします。m(_ _)m
0397ななし
NGNG環境は、VB6.0 SP5 + Excel8.0 SR-2 です。
Windows 98 / NT4.0 ws SP6
のどちらでも、
> (4) Dim .... As Object → Set .... = CreateObject ... で実行時バインド
が最速でした。
0398デフォルトの名無しさん
NGNG0399ななし
NGNG>>398
ソースが現在手元に残ってないのでアレですが、50000件のレコード(DAO.Recordset)を
セルに出力する時間を計測しました。
インスタンス化 → Nothing までの時間です。
無論、現実的には、二次元配列を使うなり、CopyFromRecordsetメソッドを使えば一発の
処理なのですが、メソッドやプロパティの参照回数を増やさないと明確な差が検出でき
ない？と考えたので、1件ずつループしてます。
0400デフォルトの名無しさん
NGNGケース毎にプログラム終了した？
exeにコンパイルして試した？
ケース毎にマシン再起動した？
0401デフォルトの名無しさん
NGNG(総時間) = (一件当たりの時間) * (件数) + (定数)
になるから
件数を変化させたときの時間の変化を見れば、
もう少し分かったと思うんだがなあ・・・
ソースコードがないんじゃあもう無理か。
ちなみにそれぞれの時間を覚えてない？
0402ななし
NGNG当然、IDEではなく、EXEでテストしてますし、プログラムも1回毎に立ち上げ
直しました。マシンのリブートまではしてませんが。（やるべきでした？）
それと、レスポンスの計測にTimer関数を使用したので、測定誤差はあるかも
しれません。でも、誤差が出るのは、(1)〜(4)までおなじ条件なので、(4)に
だけ有利に働くなんてことはないですよね？
0403ななし
NGNGソースがないのは、今、実家に帰ってるから(^-^;で、自分とこのマシンにはちゃんと
あります。（件数をもう少し増やせば、というのはちらっと思いました）
ちなみに、このベンチマークをやったのは、昨年の9月頃です。
実行時バインドの方が高速だなんて、気でも違ったかと思われそうで、技術系のMLやBBS
に上げるのを躊躇してました・・・。
0404デフォルトの名無しさん
NGNG＞ちなみに、インプロセスサーバを参照してコンパイルしたEXEを該当するコンポーネントがレジスト
＞されていない端末で起動するとプロセスが起動せずにクラッシュしますが、上記(1)〜(3)のEXEを
CreateObjectでコケてるんですな。
＞Excelがインストールされていない端末で起動しても、エラーにならずに正常に起動してしまいます。（無論、オートメーション機能は動きませんが）
こっちは、めそっど、ぷろぱてぃの情報がコンパイル時に解決されますね。
0405デフォルトの名無しさん
NGNG厳密に言うなら、ディスクキャッシュなどの影響をなくすために、
同じテストを３回以上繰り返すべき。(1なら1を3回実行する)
これで生の処理時間に近づけるはず。
あと、プロパティやメソッドの実行レスポンスを調べたいのであれば、
計測開始時刻と計測終了時刻 を ループ開始直前とループ終了直後 に
置いたほうがいいね。
4にだけ有利に働く可能性としては
a:単に最後に実行して、全部のデータがディスクキャッシュに乗っていた
b:4のみ >>401 のいう定数部分が小さい(あるいは1〜3は定数部分が大きい)
などがあると思う。
ベンチマーク(理科でいうところの対照実験)の基本なので、
このへんを押えてないと厨房扱いされちゃうよ。
0406デフォルトの名無しさん
NGNGエクセルを操作するのでアウトプロセスでしかもDispatchインターフェイスのみ
でしょう。
どの方法でも測定誤差程度しか違わないのではないでしょうか。
0407ななし
NGNGありがとうございます。
> b:4のみ >>401 のいう定数部分が小さい(あるいは1〜3は定数部分が大きい)
> などがあると思う。
その可能性はありそうですが、Excelの場合、行数に65536という制限があるので、
ベンチマーク方法をもう少し工夫した方がいいのかもしれません。
私的に気になっているのは、メモリ上の操作ではなく、ファイル出力の
レスポンステストなので、複数回実行すると環境が汚れることによる影響
があるんじゃないかと・・・？
0408ななし
NGNGありがとうございます。
> エクセルを操作するのでアウトプロセスでしかもDispatchインターフェイスのみ
> でしょう。
インプロセスとアウトプロセスではバインド方法が違う、という理解でよろしいの
でしょうか？
使っている言語がVBオンリーな上、COMのメカニズムもあまり理解していないので、
このスレの話題についてくのはしんどいです・・・。(T_T)
0409デフォルトの名無しさん
NGNG0410409
NGNG対象のプロセスとインターフェースの型と、インターフェースへのポインタだけです。
CoCreateInstance()などで取得できるものではありません。
0411409
NGNG0412デフォルトの名無しさん
NGNG■ このスレッドは過去ログ倉庫に格納されています