[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 1001- 2chのread.cgiへ]
Update time : 06/26 21:14 / Filesize : 216 KB / Number-of Response : 1002
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

【Whidbey】Visual Studio 2005スレ Part2



1 名前:デフォルトの名無しさん mailto:sage [2005/04/12(火) 20:39:26 ]
前スレ
【Whidbey】Visual Studio 2005スレ【.NET 2.0】
pc8.2ch.net/test/read.cgi/tech/1080916113/

585 名前:デフォルトの名無しさん mailto:sage [2005/08/07(日) 23:57:19 ]
>>584
.NETのランタイムも使いつつ、今までのC/C++のコード資産も併用できるコード。
CLRとネイティブの橋渡し的に使える罠。

586 名前:デフォルトの名無しさん mailto:sage [2005/08/07(日) 23:59:55 ]
間違ってはいないが、マネージドコードの説明としてはおかしいだろ。

587 名前:デフォルトの名無しさん mailto:sage [2005/08/08(月) 00:19:10 ]
すまん、オブジェクトの管理をCLRに委ねるコードのことね。

588 名前:デフォルトの名無しさん mailto:sage [2005/08/08(月) 00:46:25 ]
Javaと対比させるとわかりやすいか?

   .NET            Java
マネージドコード    → バイトコード
アンマネージドコード → ネイティブメソッド

589 名前:デフォルトの名無しさん mailto:sage [2005/08/08(月) 08:48:38 ]
バイトコードに対応するのはMSILでね?

590 名前:デフォルトの名無しさん [2005/08/08(月) 12:04:16 ]
でも、2.0フレームは、1.1より結構速度上がった希ガス。
仮想のアセンブリ使ってるわけだから、CPUのパイプラインでデコードを2層にして対応するとすれば、
直線コースでは、ネイティブのアセンブリと処理速度変わらなくなる可能性あるよね。
分岐予想も、2層にすることではずれやすくなるとは思えないし。 多くはネイティブと1対1対応だろうから。

591 名前:デフォルトの名無しさん mailto:sage [2005/08/08(月) 12:09:45 ]
そのうち、仮想マシンコード要ワイヤード・コンパイラ・(コ)プロセッサとか、CPUの標準構成になるんだろうか。
クルーソーみたいにソフトウェアでカスタマイズしだしたら、Javaも.NETもネイティブとほとんど同じ速度で動くのにね。


592 名前:デフォルトの名無しさん mailto:sage [2005/08/08(月) 12:16:06 ]
>>587
単なる疑似コードの実行マシンとしてのVMでなく、
オブジェクトの管理までやってくれるっていうのは、
そもそもガベコレが目的だったんだろうけど、
オブジェクト指向言語の拡張に一躍買ってるよね。
レイトバインディングとか、動的型情報とか。

従来の言語でも実装はできたけど、IUnknownインタフェースとか、
クラス毎に実装してやらなきゃなんなかった。

今は、コンパイラが実行ファイルへ型情報を書き出しておいてくれて、
VMがそれを読んでインタフェースを提供してくれてるみたいだし。


593 名前:デフォルトの名無しさん mailto:sage [2005/08/08(月) 15:24:11 ]
>>585-592
この中で的確にマネージドコードを説明したレスはあるのか?
それすらわからん。



594 名前:デフォルトの名無しさん mailto:sage [2005/08/08(月) 16:34:56 ]
588でいいと思う

595 名前:デフォルトの名無しさん mailto:sage [2005/08/08(月) 21:15:22 ]
いや、だから、マネージドコードってなんだよ?
CLR上で動いてるMSILの事なのか、それに対応した各言語のソースのことなのか

596 名前:デフォルトの名無しさん mailto:sage [2005/08/08(月) 21:33:30 ]
そのくらいも調べられないのか?
ttp://e-words.jp/w/E3839EE3838DE383BCE382B8E38389E382B3E383BCE38389.html

597 名前:デフォルトの名無しさん mailto:sage [2005/08/08(月) 21:43:15 ]
>596
煽りはいいから。マネージド・オブジェクトならわかる。オブジェクトの管理をCLRに委託した
オブジェクトのことだわな。でも、マネージド・コードって言われても、CLR上の中間コードの
つもりなのか、なんなのかいなって聞いてるわけさ

598 名前:デフォルトの名無しさん [2005/08/09(火) 12:22:38 ]
>>597
MSにでも聞けば?

599 名前:デフォルトの名無しさん mailto:sage [2005/08/09(火) 14:47:52 ]
M$の回答は、マネージドAPIはベーパーAPI。
なら、ベーパーAPIをコールするマネージド・コードは、、、

ttp://pc.watch.impress.co.jp/docs/2005/0804/mobile301.htm
          
マイクロソフトOBでWindows 1.xの時代からWindowsの開発に関わっていた方(2000年に退職)から
コメントをいただいた。引用させていただくと

“私の住むシアトル近辺のマイクロソフトOBの間では、2004年の前半に「Longhornがキャンセルに
なったらしい」という噂がさかんに交わされ、その後次々と「OFSはLonghornとは別」、
「Managed APIは採用しない」とのアナウンスがありました。結局の所、もともと計画していた
Longhorn は出せなくなったけれども、いまさらキャンセルになったとは言えないので、出せるもの
だけかき集めてLonghornと呼ぶことにした、という見方がこちらでは一般的です”

600 名前:デフォルトの名無しさん mailto:sage [2005/08/09(火) 14:50:02 ]
Win32APIの上にマネージド・ライブラリであるWinFXが乗っかるということは、
ま、









新たなVBランタイムということさ。

601 名前:デフォルトの名無しさん mailto:sage [2005/08/09(火) 15:28:52 ]
えーと、.netは……

602 名前:デフォルトの名無しさん mailto:sage [2005/08/09(火) 15:43:37 ]
つーかMSはころころ名前変えるから
何がやりたいのか和姦ね
WinFXって.NETなの?
でも.NETってOS非依存じゃなかったっけ?

603 名前:デフォルトの名無しさん mailto:sage [2005/08/09(火) 16:18:38 ]
..NET Framework ライクなクラスライブラリを備えた
Win32API の代わりになる新APIセットが WinFX じゃなかった?



604 名前:デフォルトの名無しさん mailto:sage [2005/08/09(火) 16:32:56 ]
> ネガティブカキコしながら、反論情報からドトネトのアドバンテージを調査してんだから。

605 名前:デフォルトの名無しさん mailto:sage [2005/08/09(火) 16:41:24 ]
てことは、







Whidbey終焉?

606 名前:デフォルトの名無しさん mailto:sage [2005/08/09(火) 20:05:44 ]
最初にマネージドコードを聞いた>>584こと俺だが、
>>595は俺じゃないけどなんだか難しい事を聞いてしまったようだ。

なんとなくわかったよ。
マネージドコードってのは俺には理解不能だって事がさ。

607 名前:デフォルトの名無しさん mailto:sage [2005/08/09(火) 20:11:44 ]
アンチは放置。わざと釣られてるのか?

608 名前:デフォルトの名無しさん mailto:sage [2005/08/09(火) 21:38:34 ]
>>597
マネージド・オブジェクトなんてあまり使わない。
マネージド・コードはよく使われる。

609 名前:デフォルトの名無しさん mailto:sage [2005/08/09(火) 21:57:14 ]
managed code 【マネージ コード】
オペレーティング システムによって直接実行されるのではなく、
共通言語ランタイムによって実行されるコード。マネージ コード
アプリケーションでは、自動ガベージ コレクション、実行時型チェック、
セキュリティ サポートなどの共通言語ランタイム サービスを利用できます。
これらのサービスは、プラットフォームや言語に依存せずに、マネージ
コードを実行できるようにします。

610 名前:デフォルトの名無しさん mailto:sage [2005/08/09(火) 21:57:16 ]
単純にネイティブコードの反対がマネージドコード

611 名前:デフォルトの名無しさん mailto:sage [2005/08/09(火) 22:39:47 ]
てゆーか、「ネイティブの反対はマネージド」とでっちあげただけだから、
609のようにコアの無い説明になっちゃうわけじゃん。

一つ一つの要素はありふれたものだし、必須はどの要素というのが決まってないし。
この内容じゃ、汎用機COBOLでさえmanaged codeになっちゃうよ。
汎用機COBOLも記述性悪いけどHOSTを落とさないという役割だから、目指すとこ一緒だから良いのか。

612 名前:デフォルトの名無しさん mailto:sage [2005/08/09(火) 22:41:43 ]
汎用機COBOL 【はんようきコボル】
オペレーティング システムによって直接実行されるのではなく、
共通言語ランタイムによって実行されるコード。マネージ コード
アプリケーションでは、自動ガベージ コレクション、実行時型チェック、
セキュリティ サポートなどの共通言語ランタイム サービスを利用できます。
これらのサービスは、プラットフォームや言語に依存せずに、マネージ
コードを実行できるようにします。

613 名前:デフォルトの名無しさん mailto:sage [2005/08/09(火) 22:50:00 ]
COBOL unmanaged code
COBOL.NET managed code



614 名前:相手にするな mailto:sage [2005/08/09(火) 23:02:14 ]
> ネガティブカキコしながら、反論情報からドトネトのアドバンテージを調査してんだから。

615 名前:デフォルトの名無しさん mailto:sage [2005/08/09(火) 23:39:03 ]
>>611
バカ?
CLR上で動作するコードをマネージドコードとマイクロソフトが「名づけた」だけだが。
別に業界標準用語でもなんでもない。

616 名前:デフォルトの名無しさん mailto:sage [2005/08/10(水) 01:07:18 ]
CLR Ver1.0=.NET
CLR Ver2.0=WinFX
CLR Ver3.0=?

617 名前:デフォルトの名無しさん mailto:sage [2005/08/10(水) 01:10:00 ]
SunとMSが和解した時点で、JavaVMと別のランタイム環境を擁する必然性は薄れたな。
まぁSwingなんか叩きたかないが。

618 名前:デフォルトの名無しさん mailto:sage [2005/08/10(水) 01:25:02 ]
>>617
?そもそもJavaと.NETじゃILの表現力が違うでしょ。
目的も用途も違うのに比較する意味がない

619 名前:デフォルトの名無しさん mailto:sage [2005/08/10(水) 01:38:37 ]
そもそも.NETの出所が、あの裁判沙汰になったMSの独自拡張Javaと、WFCでしょ。
JavaVMだって他の「Java言語」以外の言語をサポートしようとしてやれないことはないはず。
まぁネイティブ叩くのは.NETのほうが多少楽だろうが。

620 名前:デフォルトの名無しさん mailto:sage [2005/08/10(水) 09:02:43 ]
いや、V$は必死でネイティブ切ってるから全然楽じゃない。
少しでもネイティブ叩いたらリッチクライアントという範疇から外れちゃうからかな。

621 名前:デフォルトの名無しさん mailto:sage [2005/08/10(水) 10:41:34 ]
>>619
やれないことはないけどやらないんじゃない?
だからMS独自拡張Javaも許容しなかったしGenerics入れるときも
VMは拡張しなかった。
中間言語システムはSunにとっては仮想マシンで
MSにとっては言語中立共通メタデータバイナリイメージなんでしょう。

>>620
ハァ?COM/Interop、P/Invoke、CLR Hosting、C++/CLIまで用意しといて
なにが楽じゃないのよ?C++/CLIにいたっては今までのコードそのまま使えるぞ?

622 名前:デフォルトの名無しさん mailto:sage [2005/08/10(水) 10:49:23 ]
ところで、マネージドコードの利点ってなんですか?
移植性に優れるようにするならば、
なぜ、ネイティブを呼び出せるような仕組みがあるのか疑問です。


623 名前:デフォルトの名無しさん mailto:sage [2005/08/10(水) 11:03:09 ]
>C++/CLIにいたっては今までのコードそのまま使えるぞ?

mc++スレでは、
>今までの STL はネイティブに対しては今まで通り使えるし、
>ref 型とかは STL.NETが用意される
となってるが、C++/CLIだとSTL入りの既存コードはコンパイルできないわけでしょ?



624 名前:デフォルトの名無しさん mailto:sage [2005/08/10(水) 11:16:59 ]
>>622
はっきりいって広範囲に及ぶので一つ一つ解説すると
掲示板じゃむりぽになるんだが・・・
LonghornででたAvalon(これは微妙だが)、Indigo、WinFS、Nomad、
等々すべてマネージコードを必要とする、なければならないものだっていったら
重要性わかります?移植性だけじゃないんですよ。というか移植性、
MSはあんまり重要視してないような希ガス
あぁセキュリティシステム利用ならClickOnceもそうだなー

>>623
だからその中で「そのまま使える」といってるだろ?どうよんだのよ
C++/CLIではマネージ型とネイティブ型が一つのソースで共存できるっていうか
ぶっちゃけ今までのC++にマネージ型用構文が追加されただけなの。
だから既存コードもコンパイルできる。マネージ型としての利用は出来ないけどな。

625 名前:デフォルトの名無しさん mailto:sage [2005/08/10(水) 11:36:24 ]
>MSはあんまり重要視してないような希ガス

ならMS推奨を避けてネイティブしとけば無傷じゃないかな。
WindowsDNAなんて今じゃマボロシだし、AJAXもあることだし。

626 名前:622 mailto:sage [2005/08/10(水) 11:56:41 ]
>>624
Windowsの新機能はマネージドからじゃないと使えないということですか?

627 名前:デフォルトの名無しさん [2005/08/10(水) 12:42:15 ]
>>626

新機能がどっちかによる。

628 名前:627 [2005/08/10(水) 12:43:19 ]
>>626

んなことたぁーない。

629 名前:デフォルトの名無しさん mailto:sage [2005/08/10(水) 12:59:07 ]
じゃぁ、ネイティブから新機能使うのがベスト。

630 名前:デフォルトの名無しさん mailto:sage [2005/08/10(水) 13:24:40 ]
当然、.net2.0 + C# のコードを、
WinFXライブラリ + C#でコンパイルできるんだよな?

631 名前:デフォルトの名無しさん mailto:sage [2005/08/10(水) 14:15:27 ]
何でこういうのを相手にするのかなあ

632 名前:デフォルトの名無しさん mailto:sage [2005/08/11(木) 01:24:48 ]
>>629
ネイティブ版のインタフェースはCOMだろうけど、
64か32でバイナリ違ってくるし、
新APIがDataSetを戻すタイプだったら激しく不幸になれる。

633 名前:デフォルトの名無しさん mailto:sage [2005/08/11(木) 01:27:39 ]
>>630
WinFXでは、SQLServerのXML型の拡張型が使われると予想。



634 名前:デフォルトの名無しさん mailto:sage [2005/08/11(木) 01:55:13 ]
>>625
お前WinFXスレにもかいたアホだろ?Ajaxとかいってるし
単純な話でMSの責任じゃないだけ。標準化や技術公開は
積極的にやってるし、そこまで果たせば十分だしやるべきでない
Monoとかに任せるのが重要なわけでMSがやりゃまた叩かれること
うけあい。

>>632
CLR Hostingでも使うのかと思ったけど。
まぁ静的言語に徹しているC++の限界だな


635 名前:デフォルトの名無しさん mailto:sage [2005/08/11(木) 07:37:41 ]
いや、Win32 APIが拡張されるんだからある程度はそこから使えるようになるでしょ?

636 名前:デフォルトの名無しさん mailto:sage [2005/08/11(木) 08:49:04 ]
>標準化や技術公開は
MSの技術公開って何だろう?
イソターネットなら基礎技術から応用までMSと無関係だけど。

637 名前:デフォルトの名無しさん mailto:sage [2005/08/11(木) 08:53:50 ]
ttp://hotwired.goo.ne.jp/news/technology/story/20050809301.html
Vistaから本格的にAJAXに向かうらしい。
Avalonは名称からして破棄。

638 名前:デフォルトの名無しさん mailto:sage [2005/08/11(木) 09:18:30 ]
>>634
アホが調子付くから放置しる!

639 名前:デフォルトの名無しさん mailto:sage [2005/08/11(木) 09:24:35 ]
>>632
>ネイティブ版のインタフェースはCOMだろうけど、
>64か32でバイナリ違ってくるし、
>新APIがDataSetを戻すタイプだったら激しく不幸になれる。
>>632
>CLR Hostingでも使うのかと思ったけど。
>まぁ静的言語に徹しているC++の限界だな

大きく勘違いしてるようだが、
MS的にはWin32/64は繁殖、COMは終息、みたいだよ。
.NETも縮小方向というか市場が広がってない。

640 名前:デフォルトの名無しさん mailto:sage [2005/08/11(木) 09:47:45 ]
ttp://itpro.nikkeibp.co.jp/free/ITPro/OPINION/20050517/160986/
Win64 との対決でドトネト劣勢

641 名前:デフォルトの名無しさん mailto:sage [2005/08/11(木) 10:08:41 ]
先ずは64bit環境用NET Frameworkの正式版を出してもらわないと
あとExecutionEngineExceptionの発生頻度をもう少し下げてもらえれば使えなくも無い

642 名前:デフォルトの名無しさん mailto:sage [2005/08/11(木) 12:34:50 ]
>>639
COM終息? Windows最大の基幹技術なのに?
COMが無くなるんなら代わりの技術が必要だよ。
.Netがそれだと思うんだけど。
.Netはクラスが全部COMみたいなもんだし。

でないと、MSはどうやってOSのバグ直すのよ。

643 名前:デフォルトの名無しさん mailto:sage [2005/08/11(木) 12:39:51 ]
COMのなくなったWindowsなど、現時点では想像できないのだが



644 名前:デフォルトの名無しさん mailto:sage [2005/08/11(木) 12:44:08 ]
WindowsDNA!

645 名前:デフォルトの名無しさん mailto:sage [2005/08/11(木) 14:35:43 ]
Delphi/VCLなんかだとCOMスルーだったし、
それを取り入れたのが.NETライブラリだからCOMイランしょ。

>その一方で,.NET作戦にとっては衝撃的な宣言が飛び出した。
>Gates会長は「次世代プラットフォーム」を「Win32 and WinFX」と表現したのである。

次世代にCOMが無いのに、COMが要るといって芸氏に歯向かうスレはここでつか?

646 名前:デフォルトの名無しさん mailto:sage [2005/08/11(木) 15:33:20 ]
えーw COMだらけだよw

647 名前:デフォルトの名無しさん mailto:sage [2005/08/11(木) 15:45:40 ]
ここはCOM用のVB6がなぜ破棄されたのか知らないインターネッツでつね。

COMを使わされた人カワイソス

648 名前:デフォルトの名無しさん mailto:sage [2005/08/11(木) 18:38:01 ]
>>645=647
でつでつ、ウザw
DirectShowとかみてみれ、アフォw

649 名前:デフォルトの名無しさん mailto:sage [2005/08/11(木) 20:16:39 ]
COMは今後も残り続けるよ。
Vistaにも新しいCOMインターフェイスが追加されてるし、
.NET 2.0にも新しいCOMインターフェイスが追加された。
Office 12もCOMベースのままだ。

650 名前:デフォルトの名無しさん mailto:sage [2005/08/11(木) 20:17:44 ]
MSは

パフォーマンスが必要な領域(OSに比較的近い所)=COM
開発効率が必要な領域=.NET

の二刀流でいくと思われる。

651 名前:デフォルトの名無しさん mailto:sage [2005/08/11(木) 21:29:40 ]
というか.NETは便利なライブラリ集と思っていて委員ジャマイカ?

652 名前:デフォルトの名無しさん mailto:sage [2005/08/11(木) 21:49:55 ]
それでいいと思う

653 名前:デフォルトの名無しさん mailto:sage [2005/08/11(木) 22:01:40 ]
DirectXはコーポネントが新しくなればなるほど
COMの規則を守らなくなっている件について。



654 名前:デフォルトの名無しさん mailto:sage [2005/08/12(金) 02:01:36 ]
>>647
VBはOCXだと言ってみるテスト

655 名前:デフォルトの名無しさん mailto:sage [2005/08/12(金) 02:05:51 ]
>>650
だろうね。

>653
そうなの?

COMって、極論IUnknownインタフェースのことで、言い換えるとDLLのフォーマットだろ?
だから、高速化という目的では、DLL互換性を保つ条件で最大のパフォを期待できる。
で、
残りの2つのインタフェースが無くなってるの?


656 名前:デフォルトの名無しさん mailto:sage [2005/08/12(金) 02:08:20 ]
>>653
あ、レイトバインディングが無くなってきてるとかいうこと?
サイド・バイ・サイドが出たから、それは仕方ない事じゃなくて?

657 名前:デフォルトの名無しさん mailto:sage [2005/08/12(金) 02:12:51 ]
>>655
フォーマットというか、エントリポイントが絶対配置でなく、問い合わせられる仕様ね。

658 名前:デフォルトの名無しさん mailto:sage [2005/08/12(金) 07:27:15 ]
> ExecutionEngineException
こんなの見たことない

659 名前:デフォルトの名無しさん mailto:sage [2005/08/12(金) 08:41:22 ]
>>650
>パフォーマンスが必要な領域(OSに比較的近い所)=COM
>開発効率が必要な領域=.NET
>の二刀流でいくと思われる。

この二刀流って物凄く損な開発だね。

>Gates会長は「次世代プラットフォーム」を「Win32 and WinFX」と表現したのである。

Delphi/VCLだとWin32をラップしたクラスライブラリだからパフォーマンスは落ちないし、
クラス派生出来る。
つまり、ふつーに開発すればWin32とWinFX間にCOMは不要。
COMが介在した途端にクラス派生アボーン。

Delphi/VCL.netなんて不要なものもあるけど、「次世代プラットフォーム」には素直に合致してる。

660 名前:デフォルトの名無しさん mailto:sage [2005/08/12(金) 08:48:33 ]
>>649
COMが残るということと、COMをツカマされて損するのとは違うじゃん。

>Office 12もCOMベースのままだ。

VBAが丸ごとC丼ベースになることはケテーイなんでそ?
COM使うだけやヴぁいじゃん。
下位互換だからってVBA以前のExcelマクロを使わないように。


661 名前:デフォルトの名無しさん mailto:sage [2005/08/12(金) 08:54:50 ]
>の二刀流でいくと思われる。

開発者にWindowsDNA=VB-COM-VC++の二刀流をやめさせるため、
VBが亡くなってWinFXになるんだよ?
この状況でCOMを残したら、Win32-WinFX-COMの三刀流になっちゃう。

M$がVBを消す直前にアナウンスしたのは、
「COMではオブジェクト指向の海を渡ることができない」というM$DN文書。
内容はCOMは派生が使えない等と機能が足りない点を述べていた。
その前までは、「派生はOOPの本質ではない」といい続けてたがそれをひっくり返した。

だから、COMに拘ると、M$の勧めるクラスベースOOP、つまり.NETを否定することになる。

クラスベースOOPは枯れ切ってて、オブジェクトベースOOPが研究されてる時代なんだから。。

662 名前:デフォルトの名無しさん mailto:sage [2005/08/12(金) 09:41:57 ]
何故V$の中の言語からライブラリまで変わり続けるのか、
本当の理由を読み取れるかどうかは開発のセンスだと思う。
正しくない技術は消えて逝く。

663 名前:デフォルトの名無しさん mailto:sage [2005/08/12(金) 11:14:48 ]
そこでWindowsDNAですよ。

>  正しくない技術は消えて逝く。
正しいか正しくないかは関係ないような?



664 名前:デフォルトの名無しさん mailto:sage [2005/08/12(金) 11:30:08 ]
WindowsDNAセミナーで必ず出てたVBが終息でつよ?

665 名前:デフォルトの名無しさん [2005/08/12(金) 11:41:17 ]
なにをもって正しい技術なのかを証明するのは難しいと思われ
後から結果に対して正しいとかダメポだっだとか言うくらいのつまらない代物

VBは。NETになってからまるで別物になってしまったからなぁ・・
おかげでC#使えるようになったからいいけどVBAとかが今後どうなってくのかは気になる

。NET フレムワクは窓以外でも出て
他のOSでも動くアプリが作れるんだと勝手に妄想しながら当時は歓喜してたけど
ふたを開けてみると他のOSでフレームワーク出すって話はぜんぜん聞かない
マイコゥはどうする気なんだろうか

666 名前:デフォルトの名無しさん mailto:sage [2005/08/12(金) 11:58:33 ]
>なにをもって正しい技術なのかを証明するのは難しいと思われ

その通りですた。
「正しい技術」というより、「正しい技術の進化」の方が考えやすいね。
レイヤーとして古いものものと新しいものがスタックで被さるように。

>後から結果に対して正しいとかダメポだっだとか言うくらいのつまらない代物

これってソースコードの生死に関わるから超重要では。
OSのAPIがあって、その上にクラスライブラリが被さってというレイヤーだと非常に開発しやすく、
クラスライブラリはそこそこ性能もある。

が、OSの上にCOMが被さるとVBでのCOM拡張バージョンは消えるわ、C++とは相性悪いわで散々だった。

WinFXなんかもOSがクラスライブラリAPIになるのはスタックの領域侵犯では?と思ってたら、案の定Win32は残ることに。

じゃぁ、Win32とWinFX、および、他のクラスライブラリがあるところにCOMが要るかというと、イラネー

667 名前:デフォルトの名無しさん mailto:sage [2005/08/12(金) 12:24:03 ]
おまいら勘違いしてる。
 ・OSのクリチカルな処理をやるP/Cの優れた手段と、
 ・インターネットに耐えるよりオブジェクティブな手段と
の2つがあって、DNAは前者で使われてたCOMを拡張して
後者にも適用しようっていう、XMLの無く、ネットもそれほど普及してなかった時代
の発想だ。

 だから後者は、XMLを用いたSOAPを使うWebService(.Netの一手段)へと計画変更され、
VBもVB.Netと世代交代した。
 しかし、前者は相変わらずCOMベース。
SOAPのWebServiceでOSのクリチカルな処理を張り合わせるのは牛刀すぎる。
しかしCOMが使うレジストリは拡張されて、ActiveDirectoryに吸収される方向へ変化していく
だろう。いずれ完全なXMLベースになってな。

 ここで、持論。
そのときにVCLもとい、.Netパッケージの非WebServiceクラスで、OSよりの処理をやるもの同士を
どうやって貼り合わせるか?ディレクトリ構造をフルパスで示したり、一つの場所に集める
だけだとCOMの二の舞。それならサイド・バイ・サイドを導入して…
 そこまでやるなら、今のCOMと本質に変わらないことになるから、結局、COMが完全な
XMLベースになるときにCOMと纏めてパッケージ管理。
 つまり、イントラはActiveDirectory、インターはUDDIがコンポネントを管理するようになる。

最後に、Win32はオブジェクト指向してない時代遅れだから、主力には持って来たくない。
だいたい、NT上ではWin32はサブシステム扱いだし。レガシー以外の何者でもない。
でも、CEとの互換性で切るに切れない面もある。


668 名前:デフォルトの名無しさん mailto:sage [2005/08/12(金) 12:43:21 ]
三刀流カコイイ!

669 名前:デフォルトの名無しさん mailto:sage [2005/08/12(金) 12:47:52 ]
>>666
そりゃ、バラパラのコンポネントより、整然とまとめたクラスライブラリの方が使いやすいさ。
M$はクラスライブラリひとまとめで、一つのコンポネントっていう見方をしてるのかもしれんな。
ネットも高速化されたし、ODBCやMAPIなど、ある程度出そろった気がするし。

だから、互換クラスライブラリを作られると、OSをやってる旨みが、インタフェースを
支配しているという利点が無くなるからやらないのかもね。




670 名前:デフォルトの名無しさん mailto:sage [2005/08/12(金) 13:10:06 ]
>>667
>COMマンセー、Win32レガシー

ここまで読んだ。

しかし、MSはローカルでは「Win32 and WinFX」、インターネットでは「AJAX」とするみたい。
ttp://hotwired.goo.ne.jp/news/technology/story/20050809301.html

Win64も優勢。 ttp://itpro.nikkeibp.co.jp/free/ITPro/OPINION/20050517/160986/

で、実際のところも、ローカルではWin32上ではDelphi/VCL最強といわれたし、
インターネットではググルもAJAX。

671 名前:デフォルトの名無しさん mailto:sage [2005/08/12(金) 13:18:42 ]
必要とされてないCOMをローカルやイソターネットに無理に入れても嫌がられるだけじゃないだろうか。

ユーザーはCOMが使われてるかどうか知らないよ、ということなら良いが、
ローカルアプリだとCOMのエラーは多いし、COMベースの画面ツールであるVBやMFCはショボイ。
また、インターネットでは認証ベースでダウンロードに時間がかかるので劣る。

672 名前:デフォルトの名無しさん mailto:sage [2005/08/12(金) 13:22:10 ]
スレタイよく読めアホ

673 名前:デフォルトの名無しさん mailto:sage [2005/08/12(金) 13:24:52 ]
アホアンチの書き込みは相手にするだけ無駄です。徹底放置してください。

> ネガティブカキコしながら、反論情報からドトネトのアドバンテージを調査してんだから。
> だって広告じゃあてにならん。
> さらにM$広告は派生はOOPの本質じゃない、
> と言い続けた後クラスベースC丼を出してVBユーザーのを騙まし討ちを行った。



674 名前:デフォルトの名無しさん mailto:sage [2005/08/12(金) 13:27:11 ]
VS2005で「Win32 and WinFX」「AJAX」しる!

675 名前:デフォルトの名無しさん mailto:sage [2005/08/12(金) 13:27:52 ]

   〃∩ ∧_∧
   ⊂⌒(  ・ω・)  はいはいわろすわろす
     `ヽ_っ⌒/⌒c
        ⌒ ⌒


676 名前:デフォルトの名無しさん mailto:sage [2005/08/12(金) 13:28:51 ]

> ネガティブカキコしながら、反論情報からドトネトのアドバンテージを調査してんだから。


677 名前:デフォルトの名無しさん mailto:sage [2005/08/12(金) 13:30:03 ]
>騙まし討ちを行った。

これって本当?

678 名前:デフォルトの名無しさん mailto:sage [2005/08/12(金) 13:32:41 ]

     ((⌒⌒))    ドトネトなんか誰も使ってないニダ!!
ファビョ━ l|l l|l ━ン!
(⌒;;..  ∧_,,∧     貴様はM$に騙されてるニダ!!!
(⌒.⊂,ヽ#`Д´>
(⌒)人ヽ   ヽ、从 お前ら!!ウリの話を聞けニダ!!!
  从ノ.:(,,フ .ノゝ⊃
人从;;;;... レ' ノ;;;从人
   〃∩ ∧_∧
   ⊂⌒(  ・ω・)  はいはいわろすわろす
     `ヽ_っ⌒/⌒c
        ⌒ ⌒


679 名前:デフォルトの名無しさん mailto:sage [2005/08/12(金) 13:45:06 ]
COMどうするか決着しる。

680 名前:デフォルトの名無しさん mailto:sage [2005/08/12(金) 13:46:00 ]
COMは例えばC++BOOSTのlambdaのように
言語の持つ能力以上のことをクラスライブラリでやらせているような
無理がある技術。


681 名前:デフォルトの名無しさん mailto:sage [2005/08/12(金) 13:50:25 ]
相手にするも何も、お前らよくあんな支離滅裂な日本語理解できるな。

682 名前:デフォルトの名無しさん mailto:sage [2005/08/12(金) 13:57:57 ]
盛り上がってきますた。



683 名前:デフォルトの名無しさん mailto:sage [2005/08/12(金) 14:24:12 ]
COMは便利>>>FLASH、PDF、etc.



684 名前:デフォルトの名無しさん mailto:sage [2005/08/12(金) 14:27:44 ]
マルCOM・Xです。
アメリカから来ました。

685 名前:デフォルトの名無しさん mailto:sage [2005/08/12(金) 14:57:49 ]
COMとOLEを間違えているスレ






[ 続きを読む ] / [ 携帯版 ]

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<216KB

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef