どうしてCOMは即死したのか

オブジェクト指向の話でよく車輪の再発明ってのが上がってくるが...

実は、車輪と呼べるものが発明されていないんだったりしてな...

単に、C++と相性が悪かったから滅びた。

レジストリに原因があると言ってくれと言っているようなもんだな

いやC++/ATL以上にCOMと相性のよい言語なんか無いが。

#importもかなり便利

くやしい…！　　でも…感じちゃう！（ﾋﾞｸｯﾋﾞｸｯ

・COMオブジェクトの参照カウンタが０になったときに、
　そのオブジェクトが消え去る

・あるDLLに属しているCOMオブジェクトの生存数が０
　になったときにそのDLLをアンロードしてほしい

この二つは全く別の話。

>>133に亀で感動。

COMプログラミングってCだよね

Cで書けばCのプログラムになるね。

ATL基本

もともとはCだね

実はXMLでも書けるんじゃないかと

>COMプログラマの解説書
>Crispin Goswell
>Microsoft Office Product Unit
>1995年 春
>1995年9月13日改訂
http://msdn.microsoft.com/library/ja/default.asp?url=/library/ja/jpdncomp/htm/com_co.asp
>抄録
>この解説書は、
>Microsoft(r) OLE Component Object Model（COM）オブジェクトを作成し、
>効果的に使用する方法を説明しています。
>例文はほとんどCで書かれていますので、実際に何が行われているかが、大変分かりやすく示されています。
>プログラマの中には、オブジェクトを実行するためにC++を好んで使用する人もいるでしょう。
>C++プログラマの観点からCOMの概念および基本的な使用法を論じているのは
>Kraig Brockschmidt著のInside OLE （第2版）（MSDN Library（Books））です。
>COMとは何か、またその設計や哲学の後ろにある動機付けをより理解する事に興味がある読者なら、
>Component Object Model Specification（MSDN Library（Specifications））の最初の2章を読んでください。
>第1章には簡単なイントロダクションを、第2章では徹底的に概要を解説してあります。
>この解説書ではInside OLEとCOM Specificationにある情報を、
>COMオブジェクトを実装する良い方法をいくつか示しながら解説するようにしてあります。

comモデルまんせー

agennnahage

AcadVBA→MFC+COMのコードに移植したいんですけど、
簡単に変換できるソフトとかありませんか？
VARIANTI型とかいちいち宣言追加したりしないといけないし、とても時間かかるんです。＞＜

絶対無いと思う

MFC+COMが簡単になるわけはないし、
COMってC++で扱いにく杉。


つ Delphi

つ ATL

いまだに、OCXのメンテナンスをしている俺って。

>韓国ではFirefox 3が使い物にならない理由
>ttp://pc.nikkeibp.co.jp/article/column/20080724/1006299/
マイクロソフトさえもセキュリティの問題からActiveXを縮小しようとしているのに、韓国では依然とWebの標準技術でもなく、マイクロソフトの技術であるActiveXに固執している。

韓国はVista/IE7が出たときもActiveXのせいで移れないって話が盛んだった気がする。

ActiveX天国（地獄）か、一度観てみたいな

ActiveXやめてもほかの技術に依存したら同じなのにね

NetscapeのPluginだったらマシだったはず。オープンソースだし。

どうましだったのか具体的にいえますか？ｗｗ

マイクロソフトじゃないからまし。

でたｗｗｗｗｗｗｗｗｗ
そうやって第二のMSが生み出され続ける

いや、そういう問題じゃなく、
ActiveXってクライアントＰＣでExe並になんでもできちゃうわけ。

ActiveXは署名技術でがんじがらめにするしかなかった。
よほどよく知られた会社のよく知られたアプリ以外に署名を受け入れるようなユーザーはそういない。
結局、名の知れたプラグインを配布する技術として残った。

△　結局、名の知れたプラグインを配布する技術として残った。
○　結局、アドビのPDFとマクロメディアのFLASHのプラグインを配布する技術として残った。

セキュリティソフト系の会社のネットスキャンも結構受け入れられてね？

セキュリティソフトと見せかけたスパイウェアですね、わかります。

>>208
結局、アドビの為だけの技術ってことかw

アドビは行儀が悪く、しかもウザイので入れない。

はいはい

そもそもCOMなんていらない。
いや、あってもいいが、Windowsの標準的な機構に取り入れすぎた。
COMの力を本当に借りなければいけないシーンがいったいどれだけあるのか。
クライアントPC内でほとんどプロセス内サーバで十分なら従来のDLLで関数をエクスポートする方法でいい。
クラスをエクスポートする必要など無い。
エクスポートするべき関数セットを定義してさえあればそれでよいじゃないか。
第一ベンダーも異なるソフトウエア同士が強調して動作するシーンならほかにもある。
ドライバーだ。あれはCOMじゃないぞ？
COMなんか使わなければアプリケーションはもっと素早く連係動作できるし実装だって楽だ。
VBとかjavaから使いたいなら、それらのエクスポートされた関数をラップするCOMでも用意すれば良かったんだ。
そもそもVBなんて小汚い文法の言語はさっさと捨てるべきなんだよ。

てす

>関数をラップするCOMでも用意すれば良かったんだ。 

結局comは必要なわけねｗ

>>163
これは単にThreadingModelが合ってないだけでは？
fctest10.cpp
CoInitialize(NULL);
FcTest1.h
threading(free),
この組み合わせではマーシャリングが発生してしまう。

Side-by-sideの場合のThreadingModelがどうなるのか分からんけど。
未指定ならThreadingModel=none相当になって、primary STAにインスタンスが作られるから、
マーシャリングが発生しなくて早くなると。

>>214
JScriptからもCOMを使いたいのだす

いろんなところが同じようなことを目指したが、まともに実装/実践したのはMicrosoftだけ。
今は、もっと不効率な方法でも実用に耐えるようになったけど。

＞まともに実装/実践したのは

M$DNセミナーで、COMはBSD UNIX対応すると、何度もアナウンスして実現できなかったわけだが。

同時期、ローカルのＲＤＢ用ＣＯＭコンポーネント（ローカルでＳＱＬいくつも実行してサーバーにそれを纏めて送る）とか、
ＶＪ＋＋脂肪とか、ドトネトパスポートもシパーイと頓挫続きだった。

x　できなかった
o　できるのにしなかった

いや、BSD UNIX対応は年を越えてアナウンスしてたが、実現できなかったんだよ。

UNIXでCOMが動いていれば、COMが消えるどころか標準規格に昇格してるだろｗ

COM/DCOMの独自性があるとすれば、インプロセス、アウトプロセス、ネットワークを
全部プロキシで統合してることかな？

ネットワーク分散オブジェクトならCORBAが標準だし
インプロセスではMozillaのパチモンNSCOMとかあるよね

インプロセスCOMの存在意義は、つきつめればC++のABIの問題回避という面が
大きかったのではないかと俺は思う
C++でまともに（ただの関数インタフェースではない）DLL組もうとすると、
レジストリによってファクトリーを統合するなんて仕掛けは作らないにしても、
結局COMに非常に似たものが出来上がる、というかそうせざるを得ない

CORBAの実装が遅すぎ。

なんでCOMって最強なんでしょうか