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


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

【.NET】 C++/CLI について語ろうぜ 【最適】



1 名前:デフォルトの名無しさん [2005/09/11(日) 23:54:01 ]
おそらく、.NET開発でデファクトスタンダードに最も近い
であろうC++/CLIについて語ろうぜ!

45 名前:デフォルトの名無しさん mailto:sage [2005/09/13(火) 12:45:09 ]
いや、SGIが作るのはWHIRLを中間に使うgcc変種。
最終的にはネイティブを出力。

WHIRLは高水準のものから低水準のものまで多段で扱う流儀なので、
高水準のものからなら、CLIへのコンバートはそれほど難しくないと思われ。
whirl2cってのがあるくらいだから。open64のwhirl.pdfの1.3節

46 名前:デフォルトの名無しさん mailto:sage [2005/09/13(火) 14:45:49 ]
んーってことは、ただのネイティブ変換なんだ
モジュール起動時にVESにアタッチして、マネージド・オブジェクトとあったこったやったり
しない訳ね。ちょっとそれだと魅力ないなぁ。構文だけ一緒なだけなんだ
まだ、JNI をいじってラップかますほうが C++/CLI っぽいか

47 名前:デフォルトの名無しさん mailto:sage [2005/09/13(火) 19:49:32 ]
SGI
www.sgi.org/

48 名前:デフォルトの名無しさん mailto:sage [2005/09/13(火) 20:27:44 ]
そうかそうか

49 名前:デフォルトの名無しさん mailto:sage [2005/09/13(火) 23:07:52 ]
>>33
まだ出てもいないのにデファクトなわけないだろwwwwww

50 名前:デフォルトの名無しさん mailto:sage [2005/09/14(水) 00:44:49 ]
>>46
ちょっと勘違いがあるみたいなんだが、open64はCLIと何の関係もない。
RTLを使わないgccの変種を作っている。(WHIRLを使う)

で、その成果を利用すると、CLIへの変換が容易、
あるいはいきなりCLI生成な更なる変種を作るのが容易。
ってな感じの状況が>>40。一つ目のURLのFAQを読んでね。


51 名前:デフォルトの名無しさん mailto:sage [2005/09/14(水) 01:04:19 ]
>50
んー、それは理解している。でも、C++/CLI の魅力は IL にして VES 上でのみ動かす事じゃなく、
ネイティブとマネージドが共存するメモリモデルを持っていることだから、C# の亜種なら
要らないでしょ

52 名前:デフォルトの名無しさん mailto:sage [2005/09/14(水) 09:12:12 ]
まだその段階にないというだけなんでは?

53 名前:デフォルトの名無しさん mailto:sage [2005/09/14(水) 19:39:29 ]
>52
そうだけど、方向性が違うでしょ。実行モジュールから MonoVM をアタッチして、その上に
部分変換した IL を流し込むやり方は、遠いよ
JNI みたくVM上に直接オブジェクトを作るアプローチの方が手っ取り早いと思うんだけどな



54 名前:デフォルトの名無しさん [2005/09/16(金) 00:47:53 ]
あげ

55 名前:デフォルトの名無しさん [2005/09/17(土) 15:47:46 ]
あげ

56 名前:デフォルトの名無しさん [2005/09/19(月) 00:32:42 ]
あgt

57 名前:デフォルトの名無しさん mailto:sage [2005/09/19(月) 07:50:33 ]
いつになったらC++/CLI使えるようになるの?


58 名前:デフォルトの名無しさん mailto:sage [2005/09/19(月) 10:44:10 ]
今でも使えるよ

59 名前:デフォルトの名無しさん mailto:sage [2005/09/19(月) 11:11:11 ]
printfが使えるらしい

60 名前:デフォルトの名無しさん [2005/09/19(月) 20:00:34 ]
Visual Studio .Net 2003 で動作していた、
アセンブラ ファイルを含むプロジェクトが
Visual Team Suite 2005 Beta2 では、
error PRJ0003 : 'cmd.exe' の起動中にエラーが発生しました。
とのエラーになる。

どなたか、アセンブラ ファイル(.asm)を含むプロジェクトを
試された方、アドバイスお願いします。

61 名前:デフォルトの名無しさん mailto:sage [2005/09/19(月) 21:20:11 ]
asm の部分をコメントアウトしてコンパイルしてみたら?
問題は別のところにあるんじゃねぇ?

62 名前:デフォルトの名無しさん [2005/09/19(月) 21:58:39 ]
>61
いや、インラインではないんだ。
別に拡張子.asmのファイルを含んだ
プロジェクトで、例えば、
abc.cpp
abc.asm
この2つのファイルを含んだプロジェクト
をビルドすると、エラーとなるわけ。
abc.asmのカスタム ビルド ステップ指定は
以前のVSN_2003と同様ですがね。


63 名前:デフォルトの名無しさん mailto:sage [2005/09/19(月) 22:52:32 ]
cmd.exeってことは起動に失敗してるんだろ
アセンブラがパス通ってないか、無いんじゃねーの



64 名前:デフォルトの名無しさん mailto:sage [2005/09/19(月) 22:52:48 ]
2009年のC++の姿でも見ておけ。これでもC++がいいのか。
ttp://216.55.183.63/pdc2005/slides/TLN309_Sutter.ppt

65 名前:デフォルトの名無しさん [2005/09/19(月) 23:01:22 ]
pptってなんだよ
変てこなバイナリつくんなよ

66 名前:デフォルトの名無しさん mailto:sage [2005/09/19(月) 23:18:43 ]
>64
良くなるじゃん。ラムダと自動変数と関数子に並列処理やメモリのクリティカルなアクセス保持、
遅延実行、メッセージの言語サポート、非同期実行による処理の委託、スコープによる
処理の実行の同期、アルゴリズムをスレッド化してくれるし、並列化STLとかも来るとなると、
なんか、あれふ、みたいだな

>62
関数呼び出し部をコメントアウトして、asm はあるけど使わないとどうなるの、と訊いた
つもりなんだが
漏れも 63 が正しいと思うカスタム・ビルドで指定してるコマンドが間違ってるんじゃね?

67 名前:デフォルトの名無しさん mailto:sage [2005/09/19(月) 23:25:23 ]
ConcurやLinqなんて入るのか?
VC++/CLIだけだろ?

68 名前:デフォルトの名無しさん mailto:sage [2005/09/19(月) 23:31:50 ]
>67
これ、C++0x (多分、x==9)の予定だよ。だから、これをサポートしたコンパイラが出てくるのは
5年後から。まぁ、独自拡張でいろいろ試したりするだろうけど

それよりもまず、名前空間を拡張して欲しいなぁ
namespace company.product_name
{
...
}
って書きたいよ

69 名前:デフォルトの名無しさん mailto:sage [2005/09/19(月) 23:43:58 ]
>>65
恥さらし乙

70 名前:デフォルトの名無しさん mailto:sage [2005/09/19(月) 23:51:48 ]
>>68
C++0xは全部じゃないよ。
Linqなんて言語レベルでやるのが良いのかどうか。
C++は機構だけ提供するのが好きな言語だから。

71 名前:デフォルトの名無しさん mailto:sage [2005/09/19(月) 23:53:44 ]
65 名前:デフォルトの名無しさん[] 投稿日:2005/09/19(月) 23:01:22
  pptってなんだよ
  変てこなバイナリつくんなよ

72 名前:デフォルトの名無しさん mailto:sage [2005/09/20(火) 09:49:04 ]
もうこれ以上言語を拡張するのはやめてほしい>C++0x
これだけ仕様が肥大すると、規格準拠コンパイラが存在しなくなって互換性も糞もなくなるぞ(もうなってるか・・・)

C/C++と親和性の高い言語を新しく設計したほうがマシ。


73 名前:デフォルトの名無しさん mailto:sage [2005/09/20(火) 19:01:40 ]
>>72
だめだ。それをやると、D言語の二の舞になって、ユーザーを得られない。



74 名前:デフォルトの名無しさん mailto:sage [2005/09/20(火) 20:32:24 ]
D言語はセンス悪いもん。

ConcurやLinqは、高レベル過ぎるから、
新しいのつけるならプリミティブを抽出して欲しいな。

Javaのfor each程度のものならすぐにつけてもいいけれど。

75 名前:デフォルトの名無しさん mailto:sage [2005/09/20(火) 20:34:44 ]
諦めてガジェットとして見るべ
便利なとこだけつまみ食いすればいいよ。結局実用外のところは、廃れるだろう
理解しなくても、ツールとしてコードは書けるし、それで充分だと思う

76 名前:デフォルトの名無しさん [2005/09/21(水) 19:18:08 ]
今回のVS_2005 C++/CLI は、たぶん
生き残ると思う。

秩序と混沌、
いつの世でも、新たな革新的技術は、
混沌が土壌だったからね。

アセンブラ〜C#まで、必要とあらば一望の下に。

77 名前:デフォルトの名無しさん mailto:sage [2005/09/21(水) 20:35:36 ]
>>76
生き残るか生き残らないかは、君が決める事ではない。
まだ発売されてもいないのに。MSの社員か?

78 名前:デフォルトの名無しさん [2005/09/21(水) 20:43:29 ]
>77
生き残ると、私が今国会で決めたのだ!
小泉君に聞いてみな。

79 名前:デフォルトの名無しさん [2005/09/21(水) 20:55:12 ]
>>77
思うというのは予想であって、予想というのは
事の決着に直接関与しない人間でもすることだし、
事が始まるより前にすることだよ。

「神戸新聞杯はやっぱディープインパクトが勝つと思うよ」
「勝つか負けるかは、君が決める事ではない。
まだ発走してもいないのに。厩舎関係者か?」

・・・っていう会話くらい変。

80 名前:デフォルトの名無しさん mailto:sage [2005/09/21(水) 20:58:48 ]
>>79
つ[チラシの裏]

81 名前:デフォルトの名無しさん [2005/09/21(水) 21:32:48 ]
長年プログラミングをしていると
オブジェクト指向だの何だの、
これらの概念は、すでに独自の手法で
取り込み、我がものとしているハズ。

でなければ、いくら最新最強と言われる、
処理系を手にしようと、扱う人によっては....。

それにしても、C++/CLI は、有望、だと思う。

82 名前:デフォルトの名無しさん mailto:sage [2005/09/21(水) 21:33:10 ]
/ | ハ    \ ////    ヽ
! l |l、、\     ` 丶 、'´_ 、     、
! l ‖\、 \_     _ /, -`ヽ    }
、 l ‖_ >:=‐  ̄ ̄「 l| l    } 、  ヽ   んっ んんっ…
ヽ 、i`─ '´ ___   | ll ⌒; j  、   ヽ
 \ヽ r,ニ、‐‐'‐' u .l ll   '_ノ   、    ヽ 
   ` \"\):、    | l|  `、 ヽ  、   ヽ
      ヽ  ゞ'^     ! ll   `、 ヽ  、    ヽ
     丿   .:::.  | l|     \ ヽ、 、   ヽ
     丶、_        | l|/lヽ   `>=‐- ミヽ   `、
          `⌒ヽ_  | l| | ハ  /´     `ヽ   、
  チュパ  /  /. `´| l| | l / 〃        `、  、
 チュパ  /   /     | l| | l' 〃            


                             【ゴールデンレス】

このレスを見た人はコピペでもいいので
10分以内に3つのスレへ貼り付けてください。
そうすれば14日後好きな人から告白されるわ宝くじは当たるわ
出世しまくるわ体の悪い所全部治るわでえらい事です


83 名前:デフォルトの名無しさん mailto:sage [2005/09/21(水) 22:50:20 ]
この板アホアンチ多くね?
健全にMSの話題ができん。



84 名前:デフォルトの名無しさん mailto:sage [2005/09/21(水) 23:00:17 ]
技術の話ならするよ。
マンセーやアンチは置いといてさ。

85 名前:デフォルトの名無しさん mailto:sage [2005/09/22(木) 08:42:24 ]
>>80
いや、独り言じゃないから。
馬鹿をメタクソにやり込めただけだから :-P

86 名前:72 mailto:sage [2005/09/22(木) 08:57:32 ]
>>73
 俺 が 悪 か っ た

でもほんとこれ以上肥大させるのは勘弁して欲しい。
SubversionのFAQだったかな、「svnはなぜC++でなくCで記述されているのですか?」「C++だとポータビリティが低下するからです」。
わざわざ醜い言語仕様にして後方互換性を保ってもこのザマ。
まあそこがC++らしいっちゃらしいんだけどね。

87 名前:デフォルトの名無しさん mailto:sage [2005/09/22(木) 12:16:31 ]
C++でもテンプレートを禁止すれば互換性はかなり保てると思う。

けど俺はテンプレートのないC++なんて使いたくないがな。

88 名前:デフォルトの名無しさん mailto:sage [2005/09/22(木) 12:29:33 ]
>>86
subversion.tigris.org/faq.html
ないぞ。

89 名前:デフォルトの名無しさん mailto:sage [2005/09/22(木) 12:34:16 ]
そこでMozilla Portability Guideですよ。

90 名前:デフォルトの名無しさん mailto:sage [2005/09/22(木) 12:38:26 ]
subversion.bluegate.org/svn-anti-fud-ja.html

91 名前:デフォルトの名無しさん mailto:sage [2005/09/25(日) 14:11:17 ]
>>53
GNU.NETのcsccは、Cのコードとミックスできるようだな。
WindowsのVC++ .NETで書けるCとのミックスコードを、コンパイルできるらしい。
(ただしCからWindows固有の機能を使ってはダメ)

92 名前:デフォルトの名無しさん mailto:sage [2005/09/25(日) 19:10:44 ]
いみなくね?

93 名前:デフォルトの名無しさん [2005/09/26(月) 02:16:25 ]
C++/CLIで書いてもC#で書いてもはたまたVB.NETで買いても
吐き出される中間コードはどれも一緒だよ



94 名前:デフォルトの名無しさん mailto:sage [2005/09/26(月) 02:49:26 ]
dotGNU Portable.NETってCLIのクラスライブラリ用いてlibc作ってなかったっけ?

95 名前:デフォルトの名無しさん mailto:sage [2005/09/26(月) 06:44:54 ]
pnet-ctools - Development tools for compiling C to IL bytecode

This package provides the tools & links to the toolchain for compiling programs written in C to IL bytecode.

96 名前:デフォルトの名無しさん mailto:sage [2005/09/26(月) 09:13:12 ]
>93
pure とか mixed とかいろいろあるんだよ

97 名前:デフォルトの名無しさん mailto:sage [2005/10/01(土) 10:07:04 ]
「Inside the C++ Object Model」を書いていたStanley B. Lippmanが、
www.amazon.co.jp/exec/obidos/ASIN/0201834545/
C++/CLIの本書いてるなあ。

C++/Cli Essentials (MICROSOFT .NET DEVELOPMENT)
www.amazon.com/exec/obidos/tg/detail/-/0321174054/
www.compman.co.uk/htmlcat/0321174054_CplusplusCLI_Essentials.asp

Essential C++の人
www.amazon.com/exec/obidos/tg/detail/-/0201485184/

98 名前:デフォルトの名無しさん mailto:sage [2005/10/03(月) 10:35:22 ]
今までmanaged C++本買い捲って勉強してた人たちはどーなるわけ?

99 名前:デフォルトの名無しさん mailto:sage [2005/10/03(月) 11:12:18 ]
>>98
今まで通りでしょ?
C++/CLIへの大きな準備が一つ済んでるだけ。

変換ガイド: Managed Extensions for C++ から C++/CLI へのプログラムの移行
Stanley B. Lippman
Microsoft Corporation
2. マネージ型
www.microsoft.com/japan/msdn/vs05/visualc/TransGuide.asp#transguide_topic3

100 名前:デフォルトの名無しさん [2005/10/03(月) 11:23:49 ]
今まで通りなら、もうC++/CLI本を買わなくて良いわけね?

101 名前:デフォルトの名無しさん [2005/10/03(月) 11:48:23 ]
>>100
そんな事ないな、C++/CLI特有の癖が出るから
こんなコードにしとけってのはある

102 名前:デフォルトの名無しさん mailto:sage [2005/10/03(月) 11:49:50 ]
で、mc++系の本はドブに捨てときゃいいわけ?

103 名前:デフォルトの名無しさん [2005/10/03(月) 12:50:53 ]
>>99
C++/CLIでManaged C++が捨てられるのだけは確定では?
大きな準備がどうとかほざいてる奴は同様にCOMも死んでないって言うんだろうねえ。
そもそも「移行」ってどんことか知らない奴は気楽に言ってくれる。



104 名前:デフォルトの名無しさん mailto:sage [2005/10/03(月) 12:53:26 ]
どうしてMSがらみのマはいつもいつも「移行」に追い立てられなきゃならんのかな。
いつも「移行」だよ。簡単ですからとか、技術の発展ですとか言われてナ。

105 名前:デフォルトの名無しさん [2005/10/03(月) 12:58:51 ]
>>104
そうは言っても、いずれは捨てていく物もある訳で
ある程度かき回してくれるおかげでオープンシステムになっていてもニッチ産業以外の所で小さい所が勝負できる

106 名前:デフォルトの名無しさん mailto:sage [2005/10/03(月) 13:05:41 ]
>>104
その点COBOLなら変化がなくて安心ですね(^^)

107 名前:デフォルトの名無しさん [2005/10/03(月) 13:12:55 ]
>>104 >>105
あおりのつもりかも知れんが、コンピューターの世界はレイヤーで残っていくもんだよ。

Javaで呼び出す部分にCOBOLで作らせたり、いろいろと。

実行環境はふつー継承されるもんで、丸ごと消えるってのはありえない。

108 名前:デフォルトの名無しさん [2005/10/03(月) 13:18:07 ]
使われる前に消え去った.NET1.0、2.0、mc++って一体...

109 名前:デフォルトの名無しさん mailto:sage [2005/10/03(月) 14:09:06 ]
managedを理解してないと、
C++/CLIでmanagedとunmanagedを混在させたコードを書けないよ。
managedだけでいいって人は、managed C++は捨てていいと思う。
C++/CLIではその辺(__gcとか)を隠してくれるから。

自分は言語が好きだから、managed C++→C++/CLIの以降はいい事だと思うけれど、
現場は大変だよね。(けどmanaged C++で仕事始めているところってあるの?)

110 名前:デフォルトの名無しさん mailto:sage [2005/10/03(月) 14:12:08 ]
C、C++のライブラリが使えるのが重要なんであって、そんなんやったらC++の意味無いやん。


111 名前:デフォルトの名無しさん mailto:sage [2005/10/03(月) 14:41:10 ]
今110が正解を言った!
まあ、_tmainなんて腐ったもの見たくねーよな、みんな。

112 名前:デフォルトの名無しさん mailto:sage [2005/10/03(月) 14:42:02 ]
本当はWinMainもみたくなかったよママン

113 名前:デフォルトの名無しさん mailto:sage [2005/10/03(月) 14:47:00 ]
>>109
>managedを理解してないと、
>C++/CLIでmanagedとunmanagedを混在させたコードを書けないよ。
>managedだけでいいって人は、managed C++は捨てていいと思う。
すると、C++/CLIが規格通っても、新しく勉強する人はmanaged C++から
勉強しなきゃいけないの?そんなに大変ならJava使いたいよね。

>自分は言語が好きだから、managed C++→C++/CLIの以降はいい事だと思うけれど、
>現場は大変だよね。
学生やら工作員の人は楽でいいよね。現場は大変だよ。

>(けどmanaged C++で仕事始めているところってあるの?)
それはない。.NET自体、ないしな。(w



114 名前:デフォルトの名無しさん [2005/10/03(月) 14:53:34 ]
さあ、盛り上がってきます他。

115 名前:デフォルトの名無しさん [2005/10/03(月) 14:54:19 ]
>>113
.NETはあるってw
VB.NETだけど

116 名前:デフォルトの名無しさん [2005/10/03(月) 15:32:46 ]
>>108
.NET2.0ってなくなっちゃったの?

117 名前:デフォルトの名無しさん mailto:sage [2005/10/03(月) 15:37:11 ]
C++/CLI、標準になってないのに__propertyをpropertyにしているな。
それからspaced keywordダサ過ぎ…

118 名前:デフォルトの名無しさん mailto:sage [2005/10/03(月) 15:37:47 ]
>>116
managed APIはなくなって、単なるライブラリになちゃたお。

じゃ、C++/CLIいらねーじゃん。

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と呼ぶことにした、という見方がこちらでは一般的です”

119 名前:デフォルトの名無しさん mailto:sage [2005/10/03(月) 16:36:52 ]
>>118
>managed APIはなくなって、単なるライブラリになちゃたお。

これの意味が分らないんだけどどういうこと?

120 名前:デフォルトの名無しさん mailto:sage [2005/10/03(月) 16:42:39 ]
> 同氏のコメントには「Managed APIは採用しない」というものもあるが、
> 確かにWinFXの位置付けも変化してきているように思える。一昨年秋の
> Professional Developers Conferenceでは、WinFXはLonghornの
> ネイティブアプリケーションが利用するManaged CodeベースのハイレベルAPIで、
> 次世代Windowsが実現する機能を新しいクラスライブラリでくるんだものだ
> と話していた。対してWin32を使うのは(WinFX混在も不可能ではないが)
> レガシーアプリケーションのみという話だったように記憶している。

managed APIの意味は分ったお。でも.NET2.0って元々Win32のラッパーじゃなかった?

121 名前:デフォルトの名無しさん mailto:sage [2005/10/03(月) 16:55:48 ]
俺も>>118は意味がわからんところが多いな。
実際問題managed objectが存在しなくなるなんて事言っているわけじゃないでしょ?
俺は要らないんだけれど、今更そんな変更出来るわけがないし(w
まあ適当なところでお茶を濁すつもりじゃないかと。


122 名前:デフォルトの名無しさん [2005/10/03(月) 17:35:41 ]
まぁようするに
本来のVistaはmanagedプログラミングしか許さない設計で
NativeC++でプログラムすると速度が遅くなるはずだったのが
開発の遅れと.Netが糞なせいでNativeC++とmanagedが対等の関係
もしくは NativeC++ > managed になっちゃった!
って事だろ

123 名前:デフォルトの名無しさん mailto:sage [2005/10/03(月) 17:59:22 ]
つまり今と状況は変わらないと。



124 名前:デフォルトの名無しさん mailto:sage [2005/10/03(月) 18:28:10 ]
いつものパターン

125 名前:デフォルトの名無しさん mailto:sage [2005/10/03(月) 19:13:19 ]
最近になってやたらとXPのCM入れたりしてるのは、Longhornの遅れが響いてるのかな。

126 名前:デフォルトの名無しさん [2005/10/03(月) 19:16:26 ]
>>120 >>121

>でも.NET2.0って元々Win32のラッパーじゃなかった?

OS本体がマネージドなWinFXとなって、下位互換のためだけに、その上にWin32APIをエミュレートする予定だったお。

127 名前:デフォルトの名無しさん mailto:sage [2005/10/03(月) 22:24:08 ]
急にスレ伸びたなおい。

言語仕様としてスコープの概念が使える(スコープ切れでデストラクタを呼び出させる)のは
やっとキタかって感じだな。

C++使いからみてJava/C#あたりのGC系言語の大きな不満といえば、あとは
constメンバかな。あれはやっぱりCLIに組み込むのは難しいのかなぁ。。。

#もちろんmodoptに仕込むとかは今でもやってると思うけど、
#多言語との相互運用とかいろいろ考えるとむりぽかなぁ。。。

128 名前:デフォルトの名無しさん mailto:sage [2005/10/03(月) 23:01:16 ]
メモリの配置位置がそもそも移動するから無理ぽ。常時pinするような状況になるわけで
それならヒープに普通に置いた方がめんどくさくなくない?

129 名前:デフォルトの名無しさん mailto:sage [2005/10/03(月) 23:09:59 ]
>>127
俺はそれよりもSTLを使いたいがためにC++を使っている。

130 名前:デフォルトの名無しさん mailto:sage [2005/10/03(月) 23:11:52 ]
つSTL.NET

131 名前:129 mailto:sage [2005/10/03(月) 23:22:26 ]
>>130
それは知っている。
こういうのがないから俺もJavaやC#は好きになれんと言いたかった。

132 名前:デフォルトの名無しさん mailto:sage [2005/10/03(月) 23:38:13 ]
STL.NET がC#にも対応したら、複雑だな

133 名前:デフォルトの名無しさん mailto:sage [2005/10/04(火) 00:12:25 ]
>>126
そもそもそんな事したらIntelが黙って無いだろ
それはCPUは何でも良いって事になるんだぞ



134 名前:デフォルトの名無しさん mailto:sage [2005/10/04(火) 08:31:33 ]
別にintelは気にしないだろ。昔から殺伐した仲だし
32bit->64bit移行もあるから、そこらを切り離すのは普通の判断だべ

135 名前:デフォルトの名無しさん mailto:sage [2005/10/04(火) 09:40:41 ]
>>126
> OS本体がマネージドなWinFXとなって、下位互換のためだけに、
> その上にWin32APIをエミュレートする予定だったお。

この設計がもう滅茶苦茶バッドセンスなわけだが…それでいて、

>>122
> NativeC++でプログラムすると速度が遅くなるはずだったのが

って、それお前等がそうやっているからやん…

やはり最初はnativeの上にmanagedをwrapしていくことから地道に始めるべきだったかと。


136 名前:デフォルトの名無しさん mailto:sage [2005/10/04(火) 09:44:53 ]
>>132
一応、言語依存をなくす方向だよね。> STL.NET
CLI的なgenericにして。

ただこんなこと(言語非依存)やっていると、どんどん実装が遅れる。
ISO C++の時みたいに仕様だけどんどん出来て実装が追い付かない。

まあ流石にHaskell.NETは置いてきぼりだろうが(w

137 名前:デフォルトの名無しさん mailto:sage [2005/10/04(火) 10:39:29 ]
>>135
概ね同意。
でも、営業的にはもうWin32APIを切り捨てたいというのがあるんだよな?確か。
その為に移行期間としてエミュレーションで動くようにして、徐々に
減らしていくぞと。この方向は間違ってはいなそう。

営業的見解から言い出したことが、やってみたら
(技術的にか時間的にか環境的にか知らないが)やっぱり難しかった
って結果のような気がする。個人的にはゆっくり移行で良いと思ってるので
この流れで良いかな。

138 名前:デフォルトの名無しさん mailto:sage [2005/10/04(火) 12:27:46 ]
VC8には、STL/CLI(STL.NET)が入らない
www.ailight.jp/blog/sha256/archive/2005/10/04/9826.aspx

残念でした。

139 名前:デフォルトの名無しさん mailto:sage [2005/10/04(火) 12:48:22 ]
>>137
> 営業的見解から言い出したことが、

"光の速さの経営"的見解に決まっているでしょ…

>>138
まだ無理。正直C++依存性が残ってる。
早く入れすぎて悪い設計を改変できず負の遺産、
これがMSの技術面の一番悪いところだから、入れないことはいいんじゃないの?

140 名前:デフォルトの名無しさん mailto:sage [2005/10/04(火) 13:06:46 ]
>>137
>でも、営業的にはもうWin32APIを切り捨てたいというのがあるんだよな?確か。
>その為に移行期間としてエミュレーションで動くようにして、徐々に
>減らしていくぞと。この方向は間違ってはいなそう。

だから、困るっちゅーに。
ソースコードってのは生き残るもんであって。


141 名前:デフォルトの名無しさん mailto:sage [2005/10/04(火) 13:23:19 ]
結局は、
・Win32じゃないNative APIも。
・Win32はNativeの上に互換ライブラリで。(ただし少しは改変必要)
・managedの世界もありまっせー。
になるんじゃまいか?

142 名前:デフォルトの名無しさん mailto:sage [2005/10/04(火) 13:25:14 ]
>>117
> それからspaced keywordダサ過ぎ…

いまさらcppの意味まで変えようつーのにはたまげた…
(cpp単体での)互換性切り捨てすぎ…というかアホ? > MS/Lippman

143 名前:デフォルトの名無しさん mailto:sage [2005/10/04(火) 17:23:27 ]
もうC++の名を捨てて新しい言語として出直したらいいのに


……そりゃC#か



144 名前:デフォルトの名無しさん mailto:sage [2005/10/04(火) 21:29:10 ]
>>138

forums.microsoft.com/msdn/ShowPost.aspx?PostID=14599

この話だよね。


145 名前:デフォルトの名無しさん mailto:sage [2005/10/04(火) 23:43:18 ]
結局C++をなんとかしようとしてどうにもなりませんでしたというわけだ。
Javaはガベージコレクタはありますがcloseメソッドをその都度呼び出せとだましとおす気だ。
closeがdeleteだったらバカは気づいただろう。
C#は誰も理解していないしその存在が不明だ。この言語はいったいなんなのだ。
C++/CLIは超難解なC++言語でがんばって数十メガのVMがロードされるというわけだ。
むくわれない。

あきらめろ。もうC++はboostとがんばれよ。






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

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

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