【Whidbey】Visual St ..
511:デフォルトの名無しさん
05/07/20 22:26:57
むしろそれならほいどびーの方が分が悪くねーか？
512:デフォルトの名無しさん
05/07/20 22:35:43
>>511
/hwidbi:/→ホイドビー
そのままやん
上に出てるwheelやwhistleが日本語に取り入れられたとき
ホイッスルとかホイールになったのと同じこと
whという綴りは/hw/という発音が正しいからhもwも含めるようにカナで書く
実際にはhが消えたりするけどそれは「たいいく」を「たいく」と読むようなもの
513:デフォルトの名無しさん
05/07/20 22:50:34
ホイドビーがかっこ悪かったらホイッドビーでも構わない
ホイスラーもホイッスラーでも構わない
これは閉音節は拗音で表記するという音声学的な根拠があるわけで
耳でそう聞こえるからとかじゃないよ
514:デフォルトの名無しさん
05/07/20 22:52:17
おれが うぃ って読んだのは多分ウイスキーが頭にあったからだと思う
ｈが省略されたときの発音が日本語読み化してる例もあるよ〜ってことで
515:デフォルトの名無しさん
05/07/20 22:59:39
>>514
ウイスキーは純粋な英語ではないという特殊事情があるからだよ。
辞書見るとゲール語って書いてあるはず。
あとカタカナはウイスキーであってウィスキーではない。
516:デフォルトの名無しさん
05/07/20 23:09:40
博識だな。ゲール語なんて書いて無いよorz
517:デフォルトの名無しさん
05/07/20 23:16:30
>>516
大学行ったらすげーマニアックな先生とかいてむちゃくちゃ辞書引かされるもんだYO!
URLﾘﾝｸ(www.m-w.com)
Etymology: Irish uisce beathadh & Scottish Gaelic uisge beatha, literally, water of life
Gaelicというのがゲール語
uisgeがそれだけど見ての通りhはない
518:デフォルトの名無しさん
05/07/20 23:22:36
whで始まる語の発音記号はみんな(h)wってなってた、俺の辞書では。
519:デフォルトの名無しさん
05/07/20 23:29:29
>>518
実際はどっちでも通じるけど、h付ける方が正しいとされてるってだけ。
「きたない」でも「きたねー」でもどっちも通じるようなもの。
520:デフォルトの名無しさん
05/07/20 23:32:14
なんか話がそれてきたから発音の話はこれくらいにするね。
もっと英語の勉強がしたければ学校の先生にでも聞いた方が手っ取り早い。
若くて美人の先生とかいるんじゃない？ｗ
521:デフォルトの名無しさん
05/07/21 01:25:05
>>520
センセー！乳もでかいでつか？
522:デフォルトの名無しさん
05/07/21 04:10:56
β2ってバグが多いけど、アップデートあったらいいな。
製品版が出るまで我慢するのはつらいな・・・
523:デフォルトの名無しさん
05/07/21 08:34:46
ﾎﾜｲﾄﾍﾞﾘｰ
524:デフォルトの名無しさん
05/07/21 09:13:38
>>509
> そんなことしてたら日本人はLとRすら聞き分けられないだろ？
右から聞こえてくるのがR、左から聞こえてくるのがLらしいよ！！
525:デフォルトの名無しさん
05/07/21 11:26:39
>>523
ちょっといいな
526:デフォルトの名無しさん
05/07/21 20:58:12
AssemblyInfo.cs 内にある
[assembly: Guid("")]って何？
なんか不気味だが…
527:デフォルトの名無しさん
05/07/22 17:33:29
>>526
GUIDでググれ。
128ビットのランダムな数によって決まり、理論上コリジョンが起きないとされる。
漏れはVC++で多重起動抑止のためにウィンドウクラス名に使っている。
528:デフォルトの名無しさん
05/07/22 18:11:42
IDとかにも使うお
529:デフォルトの名無しさん
05/07/22 22:53:35
>>528はVIPPER
530:デフォルトの名無しさん
05/07/23 04:36:07
半年スルーすればOrcasが出るってのに、このスレは賑やかだなぁ・・・・
531:デフォルトの名無しさん
05/07/23 06:01:10
VSなんて買うもんじゃなく購読するものだし・・・・
532:デフォルトの名無しさん
05/07/23 10:27:55
購読料ﾀｶｽ
533:デフォルトの名無しさん
05/07/23 14:54:52
VS.net theSpokeを購入しましたが、
C言語やC++の関数リファレンスはどこをたどればありますか？
ヘルプ内ではVB VC# VC++のものしか見つけられませんでした。。
534:デフォルトの名無しさん
05/07/23 15:25:43
>>533
言語は知ってることが前提じゃない? C/C++の書籍は
あふれてるよ
それともWin32APIが知りたいの？ MSDNオンラインとか
行ってみればいい
535:デフォルトの名無しさん
05/07/23 20:00:54
とりあえず怒涛熱湯でもいいからチュートリアルでも見ながらテキトーにプログラムを作ってみるところからはじめるといいと思う。
細かいところに拘ると先に進まない。トップダウン的思考で作れて、あとから掘り下げていくほうがいい気がする。
漏れは2chでMFCは糞と聞いてたから無理してWTLから入った。
めちゃくちゃ苦労したがそれなりに実力ついた。
536:デフォルトの名無しさん
05/07/23 22:38:57
2005ってDirectXSDKどれから使用可能になってます？
ウチのOSWin2000だから、2004Decemberで動かないかと試してみたけど
Sample Browser からEmptyProjectインストールしてビルドしても
CVTRES : fatal error CVT1100: 重複するリソースです。type:MANIFEST, name:1, language:0x0409
LINK : fatal error LNK1123: COFF への変換中に障害が発生しました: ファイルが無効であるか､ または壊れています。
こんなエラー。
2005用のソリューションファイル吐くやつじゃないと無理なのかな？
537:デフォルトの名無しさん
05/07/24 08:52:34
文字通りマニフェストリソースが重複しているだけ。
rcファイルを修正すべし
538:デフォルトの名無しさん
05/07/24 10:34:41
少なくともDirectX７は大丈夫
539:デフォルトの名無しさん
05/07/31 09:35:26
質問。 クラスレベルでのデバッグ機能って、Expressにはついてないの？
あの機能に多少期待してて、評価したいんだけど。
540:デフォルトの名無しさん
05/07/31 10:14:53
>>533
好きなだけもって池
URLﾘﾝｸ(www.microsoft.com)
541:デフォルトの名無しさん
05/08/02 02:53:58
C#expressインスコできない…
環境が悪いのかな…
542:チラシの裏
05/08/02 03:49:23
System.Net 名前空間にアクセスできなかった。
.NET Framework には System.Net 名前空間が無いのかとも思った。
でも、ぐぐるとどうもあるようだし。
using System;
はいけた。しかし、
using System.Net;
はコンパイラから怒られた。
参照設定に System.Net を加えようとしたが System.Net.dll は見つからなかった。
時間ばかりがたつ。夜も眠れず、昼には起きていられず、とうとう夢にまで見た。
・・・ふと参照設定に System を加えてみた。
ｷﾀ━━(ﾟ∀ﾟ)━━ｯ!!
以上、空のソリューションに空のプロジェクトを追加した一人の馬鹿の事例。
543:デフォルトの名無しさん
05/08/02 07:15:40
ぬるぽ
544:デフォルトの名無しさん
05/08/02 07:23:27
>>542
> 空のソリューションに空のプロジェクトを追加
いや、俺もそれよくやってるけど･･･。
項目の追加で何を選んでるかによるんじゃないかな。
「クラス」を選んでればアセンブリの参照設定は入ってるはず。
「コードファイル」かなんかだと参照設定が入らなかったと思う。
545:デフォルトの名無しさん
05/08/02 09:08:45
> 夜も眠れず、昼には起きていられず
この時点でダメだろ。
546:デフォルトの名無しさん
05/08/03 18:57:47
俺に一言言わせてくれ。
Whidbeyの読みはウィドゥビー。
ホイドビーなんてかっこ悪すぎ！！
だからウィドゥビーって呼ぼうよ。
547:デフォルトの名無しさん
05/08/03 18:59:21
URLﾘﾝｸ(www.itmedia.co.jp)
> 現在のインターネット（.NETプラットフォーム）では、
現在のインターネット = .NETプラットフォームｗｗｗｗｗうはｗｗｗｗｗｗｗｗ
548:デフォルトの名無しさん
05/08/03 19:43:36
で、いくらになるのか。
VC++単品は出るのか。
出るとしたらエディションは？機能は？
549:デフォルトの名無しさん
05/08/03 21:13:11
製品ラインナップと予定価格は既に発表されてたと思ったが。
550:デフォルトの名無しさん
05/08/03 21:41:05
System.Collections.Generic.Collection ってのがBeta1で使えたんだけど、
Beta2ではなくなってる。.net 2.0の仕様変更？それともバグ？
551:デフォルトの名無しさん
05/08/03 22:22:25
>>550
namespaceの移動
552:デフォルトの名無しさん
05/08/04 00:51:47
ファイル パッケージのダウンロードで
Visual C++ 2005 Express Edition Beta 2 を何度落としても
CRCがFFFFFFFFとなるんだが何故？
553:デフォルトの名無しさん
05/08/04 01:16:54
正直、おまえらにとって、
フレームワークのバージョンが上がるのと、実行時にコードが変えられる以外の実質的なメリットはなに？
554:デフォルトの名無しさん
05/08/04 02:55:04
ﾊｧ?
555:デフォルトの名無しさん
05/08/04 09:20:20
フレームワークのバージョンが上がるのがいいんです!
556:デフォルトの名無しさん
05/08/04 13:27:28
>553
フレームワークのバージョンが上がることより
上がったバージョンのフレームワークが
おそらくビスタでは標準で入ってるってことのほうが大きい
557:デフォルトの名無しさん
05/08/04 13:30:53
あと２００３のときから気になってたんだが
＃regionを全部閉じる機能とかないの？
558:デフォルトの名無しさん
05/08/04 14:05:22
CollapseToDefinitions : CTRL-M, CTRL-O
ToggleAllOutlining : CTRL-M, CTRL-L
ToggleOutliningExpansion:CTRL-M, CTRL-M
この辺りのショートカットキー使えばいいんじゃね？
559:デフォルトの名無しさん
05/08/04 16:00:11
>>549
詳しく
560:デフォルトの名無しさん
05/08/04 19:15:11
VisualStudioを買う予定ですが、Visual Studio2005っていつ頃でますか？今年中に出るなら待って買ったほうがいいかなと思ったのですが。具体的にいつってまだ分かってないんでしょうか？
561:デフォルトの名無しさん
05/08/04 19:20:00
このｽﾚくらい読みましょうね
562:デフォルトの名無しさん
05/08/04 21:16:07
>558
詳しく
563:デフォルトの名無しさん
05/08/04 23:18:44
>>560
11月17日
564:デフォルトの名無しさん
05/08/04 23:23:45
>>563
日本語版って一ヵ月後くらいっしょ？
2003って同時に出たんだっけ？
565:デフォルトの名無しさん
05/08/04 23:39:40
Q) Visual Studio 2005のリリースはいつですか？
A) 英語版は11月7日
日本語版は11月17日
566:デフォルトの名無しさん
05/08/05 03:58:25
System.IOのFileInfoやDirectoryInfoの動作がおかしいね。
フルパスを引数にコンストラクタ読んでも、アプリの起動ディレクトリが入ってくる。
567:デフォルトの名無しさん
05/08/05 08:52:09
Visual Studio2005スタンダードって最適化付いてるの？
568:デフォルトの名無しさん
05/08/06 02:39:33
>>560
今年中には出るんじゃない？
遅くとも今年度中には出るだろうし。
>>565
日本語版は11/17に発表の間違い。リリース日は未定。
569:デフォルトの名無しさん
05/08/06 02:50:32
>>567
/O2や/Oiくらいまでなら対応してる希ガス。Expressですら使えたし。
/Ogは微妙
570:デフォルトの名無しさん
05/08/06 23:53:01
>>569
＞Expressですら使えたし。
beta2の事？
今までStandardは最適化が無い運命だったから今まで通り最適化無しな希ガス。
571:デフォルトの名無しさん
05/08/07 00:04:33
>>570
ExpresssはStandardより下位に位置づけられてる。
TKでProfessional同等のコンパイラついてきたから、投売りだと思う。
Professional以上ではPGOっていう、高度な最適化が使えるようになってるからそれで差別化すると思う。
572:デフォルトの名無しさん
05/08/07 00:26:35
>>571
＞Professional以上ではPGOっていう、高度な最適化が使えるようになってるからそれで差別化すると思う。
なるほど。
凄く納得。
Expressエディションが加わった事によって、それぞれのエディションが底上げされた感じだね。
573:デフォルトの名無しさん
05/08/07 01:20:04
今は64bit OS上で32bitで動いてるのが64bitになるのもメリット多い
574:デフォルトの名無しさん
05/08/07 01:23:23
>>573誤爆？
そういえば64ビット対応バイナリがビルドできるのもPro以上らしい。
575:デフォルトの名無しさん
05/08/07 09:27:28
…ん？.Netも64bitと32bitでバイナリ別なの？
576:デフォルトの名無しさん
05/08/07 09:38:21
マネージドアプリはCLRさえ提供されていればCPUさえ問わない。
Win64/x86-64ネイティブのコードがかけるかどうかって重要でしょ。
ドライバまわりとか、パフォーマンスの求められるアプリとかは、ネイティブが必要なわけで。
GUI叩くだけ使うならCLRで十分。
でもそれじゃC/C++使う意味ないからね
577:デフォルトの名無しさん
05/08/07 09:42:17
>>575
別バイナリと、共通バイナリを指定できる。
578:デフォルトの名無しさん
05/08/07 09:51:47
VS.NETを普通のVC++として使えますか？
579:デフォルトの名無しさん
05/08/07 11:50:17
言ってる意味がわからないしスレ違い
580:デフォルトの名無しさん
05/08/07 13:46:09
2003とどの程度の差があるんですか？
581:デフォルトの名無しさん
05/08/07 13:47:24
ところで、
これからのプログラムは全部マネージドになるの？
ネイティブとWin32APIは互換性のためだけに残されるようになるの？
582:デフォルトの名無しさん
05/08/07 13:49:58
MS製品は今後もネイティブだよ。次世代Officeとか次々世代Officeとか
583:デフォルトの名無しさん
05/08/07 14:25:57
>581
両方。MSはあまり極端に走らない
こけても良いように逃げ道は残しておく
584:デフォルトの名無しさん
05/08/07 23:52:59
なんだそのマネージドコードってのは。
誰か分かりやすく説明してよ。
585:デフォルトの名無しさん
05/08/07 23:57:19
>>584
.NETのランタイムも使いつつ、今までのC/C++のコード資産も併用できるコード。
CLRとネイティブの橋渡し的に使える罠。
586:デフォルトの名無しさん
05/08/07 23:59:55
間違ってはいないが、マネージドコードの説明としてはおかしいだろ。
587:デフォルトの名無しさん
05/08/08 00:19:10
すまん、オブジェクトの管理をCLRに委ねるコードのことね。
588:デフォルトの名無しさん
05/08/08 00:46:25
Javaと対比させるとわかりやすいか？
.NET Java
マネージドコード → バイトコード
アンマネージドコード → ネイティブメソッド
589:デフォルトの名無しさん
05/08/08 08:48:38
バイトコードに対応するのはMSILでね？
590:デフォルトの名無しさん
05/08/08 12:04:16
でも、2.0フレームは、1.1より結構速度上がった希ガス。
仮想のアセンブリ使ってるわけだから、CPUのパイプラインでデコードを２層にして対応するとすれば、
直線コースでは、ネイティブのアセンブリと処理速度変わらなくなる可能性あるよね。
分岐予想も、２層にすることではずれやすくなるとは思えないし。 多くはネイティブと１対１対応だろうから。
591:デフォルトの名無しさん
05/08/08 12:09:45
そのうち、仮想マシンコード要ワイヤード・コンパイラ・（コ）プロセッサとか、CPUの標準構成になるんだろうか。
クルーソーみたいにソフトウェアでカスタマイズしだしたら、Javaも.NETもネイティブとほとんど同じ速度で動くのにね。
592:デフォルトの名無しさん
05/08/08 12:16:06
>>587
単なる疑似コードの実行マシンとしてのVMでなく、
オブジェクトの管理までやってくれるっていうのは、
そもそもガベコレが目的だったんだろうけど、
オブジェクト指向言語の拡張に一躍買ってるよね。
レイトバインディングとか、動的型情報とか。
従来の言語でも実装はできたけど、IUnknownインタフェースとか、
クラス毎に実装してやらなきゃなんなかった。
今は、コンパイラが実行ファイルへ型情報を書き出しておいてくれて、
VMがそれを読んでインタフェースを提供してくれてるみたいだし。
593:デフォルトの名無しさん
05/08/08 15:24:11
>>585-592
この中で的確にマネージドコードを説明したレスはあるのか？
それすらわからん。
594:デフォルトの名無しさん
05/08/08 16:34:56
588でいいと思う
595:デフォルトの名無しさん
05/08/08 21:15:22
いや、だから、マネージドコードってなんだよ？
CLR上で動いてるMSILの事なのか、それに対応した各言語のソースのことなのか
596:デフォルトの名無しさん
05/08/08 21:33:30
そのくらいも調べられないのか？
URLﾘﾝｸ(e-words.jp)
597:デフォルトの名無しさん
05/08/08 21:43:15
>596
煽りはいいから。マネージド・オブジェクトならわかる。オブジェクトの管理をCLRに委託した
オブジェクトのことだわな。でも、マネージド・コードって言われても、CLR上の中間コードの
つもりなのか、なんなのかいなって聞いてるわけさ
598:デフォルトの名無しさん
05/08/09 12:22:38
>>597
MSにでも聞けば？
599:デフォルトの名無しさん
05/08/09 14:47:52
M$の回答は、マネージドAPIはベーパーAPI。
なら、ベーパーAPIをコールするマネージド・コードは、、、
URLﾘﾝｸ(pc.watch.impress.co.jp)
マイクロソフトOBでWindows 1.xの時代からWindowsの開発に関わっていた方(2000年に退職)から
コメントをいただいた。引用させていただくと
“私の住むシアトル近辺のマイクロソフトOBの間では、2004年の前半に「Longhornがキャンセルに
なったらしい」という噂がさかんに交わされ、その後次々と「OFSはLonghornとは別」、
「Managed APIは採用しない」とのアナウンスがありました。結局の所、もともと計画していた
Longhorn は出せなくなったけれども、いまさらキャンセルになったとは言えないので、出せるもの
だけかき集めてLonghornと呼ぶことにした、という見方がこちらでは一般的です”
600:デフォルトの名無しさん
05/08/09 14:50:02
Win32APIの上にマネージド・ライブラリであるWinFXが乗っかるということは、
ま、
新たなVBランタイムということさ。
601:デフォルトの名無しさん
05/08/09 15:28:52
えーと、.netは……
602:デフォルトの名無しさん
05/08/09 15:43:37
つーかMSはころころ名前変えるから
何がやりたいのか和姦ね
WinFXって.NETなの？
でも.NETってOS非依存じゃなかったっけ？
603:デフォルトの名無しさん
05/08/09 16:18:38
..NET Framework ライクなクラスライブラリを備えた
Win32API の代わりになる新APIセットが WinFX じゃなかった？
604:デフォルトの名無しさん
05/08/09 16:32:56
> ネガティブｶｷｺしながら、反論情報からﾄﾞﾄﾈﾄのアドバンテージを調査してんだから。
605:デフォルトの名無しさん
05/08/09 16:41:24
てことは、
Whidbey終焉？
606:デフォルトの名無しさん
05/08/09 20:05:44
最初にマネージドコードを聞いた>>584こと俺だが、
>>595は俺じゃないけどなんだか難しい事を聞いてしまったようだ。
なんとなくわかったよ。
マネージドコードってのは俺には理解不能だって事がさ。
607:デフォルトの名無しさん
05/08/09 20:11:44
アンチは放置。わざと釣られてるのか？
608:デフォルトの名無しさん
05/08/09 21:38:34
>>597
マネージド・オブジェクトなんてあまり使わない。
マネージド・コードはよく使われる。
609:デフォルトの名無しさん
05/08/09 21:57:14
managed code 【マネージ コード】
オペレーティング システムによって直接実行されるのではなく、
共通言語ランタイムによって実行されるコード。マネージ コード
アプリケーションでは、自動ガベージ コレクション、実行時型チェック、
セキュリティ サポートなどの共通言語ランタイム サービスを利用できます。
これらのサービスは、プラットフォームや言語に依存せずに、マネージ
コードを実行できるようにします。
610:デフォルトの名無しさん
05/08/09 21:57:16
単純にネイティブコードの反対がマネージドコード
611:デフォルトの名無しさん
05/08/09 22:39:47
てゆーか、「ネイティブの反対はマネージド」とでっちあげただけだから、
609のようにコアの無い説明になっちゃうわけじゃん。
一つ一つの要素はありふれたものだし、必須はどの要素というのが決まってないし。
この内容じゃ、汎用機COBOLでさえmanaged codeになっちゃうよ。
汎用機COBOLも記述性悪いけどHOSTを落とさないという役割だから、目指すとこ一緒だから良いのか。
612:デフォルトの名無しさん
05/08/09 22:41:43
汎用機COBOL 【はんようきコボル】
オペレーティング システムによって直接実行されるのではなく、
共通言語ランタイムによって実行されるコード。マネージ コード
アプリケーションでは、自動ガベージ コレクション、実行時型チェック、
セキュリティ サポートなどの共通言語ランタイム サービスを利用できます。
これらのサービスは、プラットフォームや言語に依存せずに、マネージ
コードを実行できるようにします。
613:デフォルトの名無しさん
05/08/09 22:50:00
COBOL unmanaged code
COBOL.NET managed code
614:相手にするな
05/08/09 23:02:14
> ネガティブｶｷｺしながら、反論情報からﾄﾞﾄﾈﾄのアドバンテージを調査してんだから。
615:デフォルトの名無しさん
05/08/09 23:39:03
>>611
バカ？
CLR上で動作するコードをマネージドコードとマイクロソフトが「名づけた」だけだが。
別に業界標準用語でもなんでもない。
616:デフォルトの名無しさん
05/08/10 01:07:18
CLR Ver1.0=.NET
CLR Ver2.0=WinFX
CLR Ver3.0=?
617:デフォルトの名無しさん
05/08/10 01:10:00
SunとMSが和解した時点で、JavaVMと別のランタイム環境を擁する必然性は薄れたな。
まぁSwingなんか叩きたかないが。
618:デフォルトの名無しさん
05/08/10 01:25:02
>>617
？そもそもJavaと.NETじゃILの表現力が違うでしょ。
目的も用途も違うのに比較する意味がない
619:デフォルトの名無しさん
05/08/10 01:38:37
そもそも.NETの出所が、あの裁判沙汰になったMSの独自拡張Javaと、WFCでしょ。
JavaVMだって他の「Java言語」以外の言語をサポートしようとしてやれないことはないはず。
まぁネイティブ叩くのは.NETのほうが多少楽だろうが。
620:デフォルトの名無しさん
05/08/10 09:02:43
いや、V$は必死でネイティブ切ってるから全然楽じゃない。
少しでもネイティブ叩いたらリッチクライアントという範疇から外れちゃうからかな。
621:デフォルトの名無しさん
05/08/10 10:41:34
>>619
やれないことはないけどやらないんじゃない？
だからMS独自拡張Javaも許容しなかったしGenerics入れるときも
VMは拡張しなかった。
中間言語システムはSunにとっては仮想マシンで
MSにとっては言語中立共通メタデータバイナリイメージなんでしょう。
>>620
ハァ？COM/Interop、P/Invoke、CLR Hosting、C++/CLIまで用意しといて
なにが楽じゃないのよ？C++/CLIにいたっては今までのコードそのまま使えるぞ？
622:デフォルトの名無しさん
05/08/10 10:49:23
ところで、マネージドコードの利点ってなんですか？
移植性に優れるようにするならば、
なぜ、ネイティブを呼び出せるような仕組みがあるのか疑問です。
623:デフォルトの名無しさん
05/08/10 11:03:09
>C++/CLIにいたっては今までのコードそのまま使えるぞ？
mc++スレでは、
>今までの STL はネイティブに対しては今まで通り使えるし、
>ref 型とかは STL.NETが用意される
となってるが、C++/CLIだとSTL入りの既存コードはコンパイルできないわけでしょ？
624:デフォルトの名無しさん
05/08/10 11:16:59
>>622
はっきりいって広範囲に及ぶので一つ一つ解説すると
掲示板じゃむりぽになるんだが・・・
LonghornででたAvalon(これは微妙だが)、Indigo、WinFS、Nomad、
等々すべてマネージコードを必要とする、なければならないものだっていったら
重要性わかります？移植性だけじゃないんですよ。というか移植性、
MSはあんまり重要視してないような希ガス
あぁセキュリティシステム利用ならClickOnceもそうだなー
>>623
だからその中で「そのまま使える」といってるだろ？どうよんだのよ
C++/CLIではマネージ型とネイティブ型が一つのソースで共存できるっていうか
ぶっちゃけ今までのC++にマネージ型用構文が追加されただけなの。
だから既存コードもコンパイルできる。マネージ型としての利用は出来ないけどな。
625:デフォルトの名無しさん
05/08/10 11:36:24
>MSはあんまり重要視してないような希ガス
ならMS推奨を避けてネイティブしとけば無傷じゃないかな。
WindowsDNAなんて今じゃマボロシだし、AJAXもあることだし。
626:622
05/08/10 11:56:41
>>624
Windowsの新機能はマネージドからじゃないと使えないということですか？
627:デフォルトの名無しさん
05/08/10 12:42:15
>>626
新機能がどっちかによる。
628:627
05/08/10 12:43:19
>>626
んなことたぁーない。
629:デフォルトの名無しさん
05/08/10 12:59:07
じゃぁ、ネイティブから新機能使うのがベスト。
630:デフォルトの名無しさん
05/08/10 13:24:40
当然、.net2.0 + C# のコードを、
WinFXライブラリ + C#でコンパイルできるんだよな？
631:デフォルトの名無しさん
05/08/10 14:15:27
何でこういうのを相手にするのかなあ
632:デフォルトの名無しさん
05/08/11 01:24:48
>>629
ネイティブ版のインタフェースはCOMだろうけど、
64か32でバイナリ違ってくるし、
新APIがDataSetを戻すタイプだったら激しく不幸になれる。
633:デフォルトの名無しさん
05/08/11 01:27:39
>>630
WinFXでは、SQLServerのXML型の拡張型が使われると予想。
634:デフォルトの名無しさん
05/08/11 01:55:13
>>625
お前WinFXスレにもかいたアホだろ？Ajaxとかいってるし
単純な話でMSの責任じゃないだけ。標準化や技術公開は
積極的にやってるし、そこまで果たせば十分だしやるべきでない
Monoとかに任せるのが重要なわけでMSがやりゃまた叩かれること
うけあい。
>>632
CLR Hostingでも使うのかと思ったけど。
まぁ静的言語に徹しているC++の限界だな
635:デフォルトの名無しさん
05/08/11 07:37:41
いや、Win32 APIが拡張されるんだからある程度はそこから使えるようになるでしょ？
636:デフォルトの名無しさん
05/08/11 08:49:04
>標準化や技術公開は
MSの技術公開って何だろう？
イソターネットなら基礎技術から応用までMSと無関係だけど。
637:デフォルトの名無しさん
05/08/11 08:53:50
URLﾘﾝｸ(hotwired.goo.ne.jp)
Vistaから本格的にAJAXに向かうらしい。
Avalonは名称からして破棄。
638:デフォルトの名無しさん
05/08/11 09:18:30
>>634
アホが調子付くから放置しる！
639:デフォルトの名無しさん
05/08/11 09:24:35
>>632
>ネイティブ版のインタフェースはCOMだろうけど、
>64か32でバイナリ違ってくるし、
>新APIがDataSetを戻すタイプだったら激しく不幸になれる。
>>632
>CLR Hostingでも使うのかと思ったけど。
>まぁ静的言語に徹しているC++の限界だな
大きく勘違いしてるようだが、
ＭＳ的にはWin32/64は繁殖、COMは終息、みたいだよ。
.NETも縮小方向というか市場が広がってない。
640:デフォルトの名無しさん
05/08/11 09:47:45
URLﾘﾝｸ(itpro.nikkeibp.co.jp)
Win64 との対決でﾄﾞﾄﾈﾄ劣勢
641:デフォルトの名無しさん
05/08/11 10:08:41
先ずは64bit環境用NET Frameworkの正式版を出してもらわないと
あとExecutionEngineExceptionの発生頻度をもう少し下げてもらえれば使えなくも無い
642:デフォルトの名無しさん
05/08/11 12:34:50
>>639
COM終息？ Windows最大の基幹技術なのに？
COMが無くなるんなら代わりの技術が必要だよ。
.Netがそれだと思うんだけど。
.Netはクラスが全部COMみたいなもんだし。
でないと、MSはどうやってOSのバグ直すのよ。
643:デフォルトの名無しさん
05/08/11 12:39:51
COMのなくなったWindowsなど、現時点では想像できないのだが
644:デフォルトの名無しさん
05/08/11 12:44:08
WindowsDNA!
645:デフォルトの名無しさん
05/08/11 14:35:43
Delphi/VCLなんかだとCOMスルーだったし、
それを取り入れたのが.NETライブラリだからCOMイランしょ。
>その一方で，.NET作戦にとっては衝撃的な宣言が飛び出した。
>Gates会長は「次世代プラットフォーム」を「Win32 and WinFX」と表現したのである。
次世代にCOMが無いのに、COMが要るといって芸氏に歯向かうスレはここでつか？
646:デフォルトの名無しさん
05/08/11 15:33:20
えーｗ COMだらけだよｗ
647:デフォルトの名無しさん
05/08/11 15:45:40
ここはCOM用のVB6がなぜ破棄されたのか知らないインターネッツでつね。
COMを使わされた人ｶﾜｲｿｽ
648:デフォルトの名無しさん
05/08/11 18:38:01
>>645=647
でつでつ、ｳｻﾞｗ
DirectShowとかみてみれ、ｱﾌｫｗ
649:デフォルトの名無しさん
05/08/11 20:16:39
COMは今後も残り続けるよ。
Vistaにも新しいCOMインターフェイスが追加されてるし、
.NET 2.0にも新しいCOMインターフェイスが追加された。
Office 12もCOMベースのままだ。
650:デフォルトの名無しさん
05/08/11 20:17:44
MSは
パフォーマンスが必要な領域(OSに比較的近い所)=COM
開発効率が必要な領域=.NET
の二刀流でいくと思われる。
651:デフォルトの名無しさん
05/08/11 21:29:40
というか.NETは便利なライブラリ集と思っていて委員ジャマイカ?
652:デフォルトの名無しさん
05/08/11 21:49:55
それでいいと思う
653:デフォルトの名無しさん
05/08/11 22:01:40
DirectXはコーポネントが新しくなればなるほど
COMの規則を守らなくなっている件について。
654:デフォルトの名無しさん
05/08/12 02:01:36
>>647
ＶＢはＯＣＸだと言ってみるﾃｽﾄ
655:デフォルトの名無しさん
05/08/12 02:05:51
>>650
だろうね。
>653
そうなの？
COMって、極論IUnknownインタフェースのことで、言い換えるとDLLのフォーマットだろ？
だから、高速化という目的では、DLL互換性を保つ条件で最大のパフォを期待できる。
で、
残りの２つのインタフェースが無くなってるの？
656:デフォルトの名無しさん
05/08/12 02:08:20
>>653
あ、レイトバインディングが無くなってきてるとかいうこと？
サイド・バイ・サイドが出たから、それは仕方ない事じゃなくて？
657:デフォルトの名無しさん
05/08/12 02:12:51
>>655
フォーマットというか、エントリポイントが絶対配置でなく、問い合わせられる仕様ね。
658:デフォルトの名無しさん
05/08/12 07:27:15
> ExecutionEngineException
こんなの見たことない
659:デフォルトの名無しさん
05/08/12 08:41:22
>>650
>パフォーマンスが必要な領域(OSに比較的近い所)=COM
>開発効率が必要な領域=.NET
>の二刀流でいくと思われる。
この二刀流って物凄く損な開発だね。
>Gates会長は「次世代プラットフォーム」を「Win32 and WinFX」と表現したのである。
Delphi/VCLだとWin32をラップしたクラスライブラリだからパフォーマンスは落ちないし、
クラス派生出来る。
つまり、ふつーに開発すればWin32とWinFX間にCOMは不要。
COMが介在した途端にクラス派生アボーン。
Delphi/VCL.netなんて不要なものもあるけど、「次世代プラットフォーム」には素直に合致してる。
660:デフォルトの名無しさん
05/08/12 08:48:33
>>649
COMが残るということと、COMをツカマされて損するのとは違うじゃん。
>Office 12もCOMベースのままだ。
VBAが丸ごとＣ丼ベースになることはケテーイなんでそ？
COM使うだけやヴぁいじゃん。
下位互換だからってVBA以前のExcelマクロを使わないように。
661:デフォルトの名無しさん
05/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:デフォルトの名無しさん
05/08/12 09:41:57
何故V$の中の言語からライブラリまで変わり続けるのか、
本当の理由を読み取れるかどうかは開発のセンスだと思う。
正しくない技術は消えて逝く。
663:デフォルトの名無しさん
05/08/12 11:14:48
そこでWindowsDNAですよ。
> 正しくない技術は消えて逝く。
正しいか正しくないかは関係ないような？
664:デフォルトの名無しさん
05/08/12 11:30:08
WindowsDNAセミナーで必ず出てたVBが終息でつよ？
665:デフォルトの名無しさん
05/08/12 11:41:17
なにをもって正しい技術なのかを証明するのは難しいと思われ
後から結果に対して正しいとかダメポだっだとか言うくらいのつまらない代物
ＶＢは。ＮＥＴになってからまるで別物になってしまったからなぁ・・
おかげでＣ＃使えるようになったからいいけどＶＢＡとかが今後どうなってくのかは気になる
。ＮＥＴ フレムワクは窓以外でも出て
他のＯＳでも動くアプリが作れるんだと勝手に妄想しながら当時は歓喜してたけど
ふたを開けてみると他のＯＳでフレームワーク出すって話はぜんぜん聞かない
マイコゥはどうする気なんだろうか
666:デフォルトの名無しさん
05/08/12 11:58:33
>なにをもって正しい技術なのかを証明するのは難しいと思われ
その通りですた。
「正しい技術」というより、「正しい技術の進化」の方が考えやすいね。
レイヤーとして古いものものと新しいものがスタックで被さるように。
>後から結果に対して正しいとかダメポだっだとか言うくらいのつまらない代物
これってソースコードの生死に関わるから超重要では。
OSのAPIがあって、その上にクラスライブラリが被さってというレイヤーだと非常に開発しやすく、
クラスライブラリはそこそこ性能もある。
が、OSの上にCOMが被さるとVBでのCOM拡張バージョンは消えるわ、C++とは相性悪いわで散々だった。
WinFXなんかもOSがクラスライブラリAPIになるのはスタックの領域侵犯では？と思ってたら、案の定Win32は残ることに。
じゃぁ、Win32とWinFX、および、他のクラスライブラリがあるところにCOMが要るかというと、イラネー
667:デフォルトの名無しさん
05/08/12 12:24:03
おまいら勘違いしてる。
・OSのクリチカルな処理をやるＰ／Ｃの優れた手段と、
・インターネットに耐えるよりオブジェクティブな手段と
の２つがあって、DNAは前者で使われてたCOMを拡張して
後者にも適用しようっていう、ＸＭＬの無く、ネットもそれほど普及してなかった時代
の発想だ。
だから後者は、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はサブシステム扱いだし。レガシー以外の何者でもない。
でも、ＣＥとの互換性で切るに切れない面もある。
668:デフォルトの名無しさん
05/08/12 12:43:21
三刀流カコイイ！
669:デフォルトの名無しさん
05/08/12 12:47:52
>>666
そりゃ、バラパラのコンポネントより、整然とまとめたクラスライブラリの方が使いやすいさ。
Ｍ＄はクラスライブラリひとまとめで、一つのコンポネントっていう見方をしてるのかもしれんな。
ネットも高速化されたし、ODBCやMAPIなど、ある程度出そろった気がするし。
だから、互換クラスライブラリを作られると、ＯＳをやってる旨みが、インタフェースを
支配しているという利点が無くなるからやらないのかもね。
670:デフォルトの名無しさん
05/08/12 13:10:06
>>667
>COMﾏﾝｾｰ、Win32レガシー
ここまで読んだ。
しかし、MSはローカルでは「Win32 and WinFX」、インターネットでは「AJAX」とするみたい。
URLﾘﾝｸ(hotwired.goo.ne.jp)
Win64も優勢。 URLﾘﾝｸ(itpro.nikkeibp.co.jp)
で、実際のところも、ローカルではWin32上ではDelphi/VCL最強といわれたし、
インターネットではググルもAJAX。
671:デフォルトの名無しさん
05/08/12 13:18:42
必要とされてないCOMをローカルやイソターネットに無理に入れても嫌がられるだけじゃないだろうか。
ユーザーはCOMが使われてるかどうか知らないよ、ということなら良いが、
ローカルアプリだとCOMのエラーは多いし、COMベースの画面ツールであるVBやMFCはショボイ。
また、インターネットでは認証ベースでダウンロードに時間がかかるので劣る。
672:デフォルトの名無しさん
05/08/12 13:22:10
スレタイよく読めアホ
673:デフォルトの名無しさん
05/08/12 13:24:52
アホアンチの書き込みは相手にするだけ無駄です。徹底放置してください。
> ネガティブｶｷｺしながら、反論情報からﾄﾞﾄﾈﾄのアドバンテージを調査してんだから。
> だって広告じゃあてにならん。
> さらにM$広告は派生はOOPの本質じゃない、
> と言い続けた後クラスベースC丼を出してVBユーザーのを騙まし討ちを行った。
674:デフォルトの名無しさん
05/08/12 13:27:11
VS2005で「Win32 and WinFX」「AJAX」しる！
675:デフォルトの名無しさん
05/08/12 13:27:52
〃∩ ∧＿∧
⊂⌒（ ・ω・） はいはいわろすわろす
｀ヽ_っ⌒/⌒ｃ
⌒ ⌒
676:デフォルトの名無しさん
05/08/12 13:28:51
> ネガティブｶｷｺしながら、反論情報からﾄﾞﾄﾈﾄのアドバンテージを調査してんだから。
677:デフォルトの名無しさん
05/08/12 13:30:03
>騙まし討ちを行った。
これって本当？
678:デフォルトの名無しさん
05/08/12 13:32:41
((⌒⌒)) ﾄﾞﾄﾈﾄなんか誰も使ってないニダ！！
ﾌｧﾋﾞｮ━ l|l l|l ━ﾝ！
（⌒;;.. ∧_,,∧ 貴様はM$に騙されてるニダ！！！
(⌒.⊂,ヽ#｀Д´>
（⌒)人ヽ ヽ、从 お前ら！！ウリの話を聞けニダ！！！
从ﾉ.:(,,フ .ﾉゝ⊃
人从;;;;... レ' ﾉ;;;从人
〃∩ ∧＿∧
⊂⌒（ ・ω・） はいはいわろすわろす
｀ヽ_っ⌒/⌒ｃ
⌒ ⌒
679:デフォルトの名無しさん
05/08/12 13:45:06
COMどうするか決着しる。
680:デフォルトの名無しさん
05/08/12 13:46:00
COMは例えばC++BOOSTのlambdaのように
言語の持つ能力以上のことをクラスライブラリでやらせているような
無理がある技術。
681:デフォルトの名無しさん
05/08/12 13:50:25
相手にするも何も、お前らよくあんな支離滅裂な日本語理解できるな。
682:デフォルトの名無しさん
05/08/12 13:57:57
盛り上がってきますた。
683:デフォルトの名無しさん
05/08/12 14:24:12
COMは便利＞＞＞FLASH、PDF、etc.
684:デフォルトの名無しさん
05/08/12 14:27:44
マルＣＯＭ・Ｘです。
アメリカから来ました。
685:デフォルトの名無しさん
05/08/12 14:57:49
COMとOLEを間違えているスレ
686:デフォルトの名無しさん
05/08/12 17:00:49
>>679
COMは残る。デバドラ書くのに絶対必要。
687:デフォルトの名無しさん
05/08/12 17:08:57
>>674
なんでCOMやらマネージドオブジェクトの話してるときに、AJAXが出てくるねん。
Win32は、レガシーやからしばらく残るけど、MacみたいにDirectXが標準になったら
益々いらんなー。算術ライブラリなんかは必要だけど、もう、NTネイティブAPI呼んだら
ええんちゃうのん？
688:デフォルトの名無しさん
05/08/12 17:11:55
確かにCOMとOLEをごっちゃにしてた。
便利DLLマシーンとしてCOMが生き残ることはわかった。
ではOLEはこの先生きのこるのか？
689:デフォルトの名無しさん
05/08/12 17:27:38
だからなあ、スレタイよく読めよ
690:デフォルトの名無しさん
05/08/12 17:31:17
擦れたいは、ええとぉ、
VS2005を使うときにCOMは是か非か、
だっけ？
691:デフォルトの名無しさん
05/08/12 17:33:02
ｲﾐﾌﾒ>>686
それはシリアルポートのCOMかよ。
DDKとCOMはﾑｶﾝｹ
692:デフォルトの名無しさん
05/08/12 17:34:02
> ネガティブｶｷｺしながら、反論情報からﾄﾞﾄﾈﾄのアドバンテージを調査してんだから。
693:デフォルトの名無しさん
05/08/12 17:34:26
( ´д)ﾋｿ(´д｀)ﾋｿ(д｀ )
694:デフォルトの名無しさん
05/08/12 17:35:03
>>690
おおよ。じゃあ、VS 2005でのCOM関連の新機能を挙げてみろ。
695:デフォルトの名無しさん
05/08/12 17:38:29
〃∩ ∧＿∧
⊂⌒（ ・ω・） はいはいわろすわろす
｀ヽ_っ⌒/⌒ｃ
⌒ ⌒
696:デフォルトの名無しさん
05/08/12 17:42:59
日本語版July CTPはまだですか？
697:824
05/08/12 17:46:09
〃∩ ∧＿∧
⊂⌒< ・ω・> はいはいわろすわろす
｀ヽ_っ⌒/⌒ｃ
⌒ ⌒
698:デフォルトの名無しさん
05/08/12 17:49:09
>>696
順調に遅れてる。
それよりも英語版のAugust CTPがもうすぐ出る。こっちの方が重要。
699:デフォルトの名無しさん
05/08/12 17:54:43
例のNullableの変更が入るやつか
700:デフォルトの名無しさん
05/08/12 18:14:50
>>699
詳しく。
701:デフォルトの名無しさん
05/08/12 18:22:13
>>700
URLﾘﾝｸ(blogs.msdn.com)
702:デフォルトの名無しさん
05/08/12 18:29:12
>>700
int? n = null;
Console.WriteLine(n == null);
object o = n;
Console.WriteLine(o == null);
現状、↑の結果はtrue、falseになる。
それをランタイムに仕様変更を入れてきちんとtrue、trueになるようにするらしい。
703:794
05/08/12 20:13:27
〃∩ ∧＿∧
⊂⌒< ・ω・> はいはいわろすわろす
｀ヽ_っ⌒/⌒ｃ
⌒ ⌒
704:デフォルトの名無しさん
05/08/12 20:13:54
意味もわからず「Ajax！」とか叫んでるやつが哀れでウケるｗｗ
>>702
そんなのいろんなところで散々既出だろ
705:デフォルトの名無しさん
05/08/12 20:19:36
>VBAが丸ごとＣ丼ベースになることはケテーイ
マジですか。
706:デフォルトの名無しさん
05/08/12 20:25:31
>>704
いや、だから「例の」って言ってるじゃん。
707:デフォルトの名無しさん
05/08/12 20:27:35
C#じゃなくて、それをいうならCLRだろ。
708:デフォルトの名無しさん
05/08/12 20:36:23
>>707
ﾊｧ?
どこに「C#の変更」なんて書いてある？
709:デフォルトの名無しさん
05/08/12 20:41:29
もし構文がC#ライクになるというならそれはVBAじゃなくてC#Aでしょ。
スクリプトエンジンの本体がCLRで書かれるという意味で解しても、「C#ベース」とは言わないだろ。
710:デフォルトの名無しさん
05/08/12 20:43:03
>>709はどこに対するレスだ？
お前ら言ってることがさっぱり理解できんぞ。
711:デフォルトの名無しさん
05/08/12 20:43:52
>VBAが丸ごとＣ丼ベースになることはケテーイ
712:デフォルトの名無しさん
05/08/12 20:45:36
> VBAが丸ごとＣ丼ベースになることはケテーイ
そんなニュース聞いたこともない。リンク出してみろ。
それとVSAがマネージドコードベースなのはVS 2002の頃から。
713:デフォルトの名無しさん
05/08/12 20:47:17
> VS 2005でのCOM関連の新機能を挙げてみろ。
714:デフォルトの名無しさん
05/08/12 20:52:59
とっくにfeature completeしたWhidbeyネタで何を憶測でモノ言ってるんだか･･･。
715:デフォルトの名無しさん
05/08/12 20:58:49
禿同
716:デフォルトの名無しさん
05/08/12 21:02:21
だから、無知なアホは相手にするなと何度言えば
717:デフォルトの名無しさん
05/08/12 21:46:45
VBA持たしかにとっととManagedに移行してもらいたいが、相当先のことだろうな。
しかたなくVSTO使うのさ。
718:デフォルトの名無しさん
05/08/12 21:53:25
--- ここまでスクロールした ---
719:デフォルトの名無しさん
05/08/12 21:58:17
>>691
計測機器のポーリングやるのに、ガベコレ使うわけにいかんやろ。
ハードリアルタイムを保証しようと思ったらCOMしか残ってないやん。
組込ＸＰのデジタルオシロとか想像してみてよ。
それでも要らんと思う？
720:デフォルトの名無しさん
05/08/12 22:21:05
そろそろCOMポートはなくなるな
721:デフォルトの名無しさん
05/08/12 22:35:20
>>719
ＧＣにも様々な種類がある。
すべてのＧＣがハードリアルタイムなモノに利用できないというわけではない。
722:デフォルトの名無しさん
05/08/12 23:01:07
>>721
なるほど。だから、計測機器のドライバをマネージドコードで書く訳か。
723:デフォルトの名無しさん
05/08/12 23:01:50
マネージコードじゃなくてネイティブコードだろ
724:デフォルトの名無しさん
05/08/12 23:03:46
すまん微妙に誤爆
しかしぶっちゃけ、メモリの開放のし忘れよりは、パフォーマンスの低下のほうが心配なんだが
725:デフォルトの名無しさん
05/08/12 23:12:57
そんなのC++でかけばいいじゃん
726:デフォルトの名無しさん
05/08/12 23:13:37
>>724
まーそうだね。
ハードリアルタイムなGCを実現しようとすると、
全ての実行時間におけるガベコレ実行時間の割合が増えるからイクナイ。
そういうわけで、ほとんどのところでは使われないのかもね。
実行効率の良いハードリアルタイムＧＣが発見されることを祈ろう．．．
727:デフォルトの名無しさん
05/08/12 23:43:12
>>726
そもそもさ、ＧＣってメモリ管理の最後の手段でしょ？
最後の手段をイキナリ持ち出してくるって、掟破りなんじゃないの？
しかも組込で。
728:デフォルトの名無しさん
05/08/13 00:38:51
>>727
拒絶反応出ました？
組込みの人だとオブジェクト指向はおろか、
ＧＣアルゴリズムなんてとてもじゃないが知らんと思う。
だから、ＧＣという言葉を聞くだけで、拒絶反応が出てくるのじゃないかと。
実際に、組込みで安心してＧＣを使うには、適切なＧＣを利用し、
利用されているＧＣアルゴリズムを意識したプログラム作成が求められると思う。
とゆーわけで？ＧＣを勉強して有効活用してみないか？とか逝ってみる。
729:デフォルトの名無しさん
05/08/13 00:43:17
GCって勉強しないと使えないものなのか。
いずれにしても組み込みにはランタイム環境ははでかすぎ。
だから多少ロイヤリティがかかっても携帯アプリはJavaよりBREWのほうがマンセーされたりもする。
730:デフォルトの名無しさん
05/08/13 03:03:19
>>728
っていうかさ、そもそも「環境的にC++がまともに使えるかもわからん」よ、組み込み。
それに、C++つかえるならstd::auto_ptr、boost::shared_ptr以外の選択肢があるのか？
ランタイムみたいなぱーぺきなGC(=走査型GC)はどうかと思うのだが。いや、実行タイ
ミングさえコントロールできれば何とかなる場合もあるが、メモリとの戦いもあるしなぁ
Win内でやるとすると…まぁ絶対は無理なのでだましだまし&環境限定になるなぁ
なんかのボードかませてそこでリアルリアルしたほうが安心できるような希ガス
次ページ最新レス表示スレッドの検索類似スレ一覧話題のニュースおまかせリスト▼オプションを表示暇つぶし2ch
4353日前に更新/216 KB
担当:undef