【.NET】 C++/CLI に� ..

---

[2ch|▼Menu]

116:デフォルトの名無しさん
05/10/03 15:32:46
>>108
.NET2.0ってなくなっちゃったの？

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

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

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

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

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

119:デフォルトの名無しさん
05/10/03 16:36:52
>>118
＞managed APIはなくなって、単なるライブラリになちゃたお。

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

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


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

123:デフォルトの名無しさん
05/10/03 17:59:22
つまり今と状況は変わらないと。

124:デフォルトの名無しさん
05/10/03 18:28:10
いつものパターン

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

126:デフォルトの名無しさん
05/10/03 19:16:26
>>120 >>121

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

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

127:デフォルトの名無しさん
05/10/03 22:24:08
急にスレ伸びたなおい。

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

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

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

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

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

130:デフォルトの名無しさん
05/10/03 23:11:52
つSTL.NET

131:129
05/10/03 23:22:26
>>130
それは知っている。
こういうのがないから俺もJavaやC#は好きになれんと言いたかった。

132:デフォルトの名無しさん
05/10/03 23:38:13
STL.NET がC#にも対応したら、複雑だな

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

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

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

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

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

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

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


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

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

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

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

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

138:デフォルトの名無しさん
05/10/04 12:27:46
VC8には、STL/CLI(STL.NET)が入らない
URLﾘﾝｸ(www.ailight.jp)

残念でした。

139:デフォルトの名無しさん
05/10/04 12:48:22
>>137
> 営業的見解から言い出したことが、

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

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

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

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


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

142:デフォルトの名無しさん
05/10/04 13:25:14
>>117
> それからspaced keywordダサ過ぎ…

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

143:デフォルトの名無しさん
05/10/04 17:23:27
もうC++の名を捨てて新しい言語として出直したらいいのに


……そりゃC#か

144:デフォルトの名無しさん
05/10/04 21:29:10
>>138

URLﾘﾝｸ(forums.microsoft.com)

この話だよね。


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

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

146:デフォルトの名無しさん
05/10/05 00:21:27
人の邪魔をするな。
俺は俺だ。お前がどう感じようが関係ない。

147:デフォルトの名無しさん
05/10/05 00:42:35
>>145
今時のパソコンで数十メガなんて意味を持たない

148:デフォルトの名無しさん
05/10/05 00:45:18
わざわざ対象のスレにまで来てネガティブキャンペーンをするやつは
結局のところ、自身の不安の裏返しなのだ。

149:デフォルトの名無しさん
05/10/05 01:12:28
せっかくC#おぼえたのにー

150:デフォルトの名無しさん
05/10/05 01:13:10
無駄銭だったねｗ

151:デフォルトの名無しさん
05/10/05 02:00:48
そもそもC++&.NETが間違いだよなぁ。
まあ今更だけど。

152:デフォルトの名無しさん
05/10/05 02:45:38
無駄じゃない！全然無駄じゃない！

153:デフォルトの名無しさん
05/10/05 04:14:57
無駄無駄無駄無駄無駄無駄無駄無駄無駄無駄無駄無駄ァァァ！！！

154:デフォルトの名無しさん
05/10/05 08:39:38
だからぁ、普通のC++ライブラリを混ぜれて、コンパイラオプションでWin32/Win64/ドトネトが切り替わるなら、どんどん使ってやる。

155:デフォルトの名無しさん
05/10/05 10:49:38
>154
C++/CLI はその通りですが何か？

156:デフォルトの名無しさん
05/10/05 10:53:11
STLさえ使えなくて、パチモンのSTLドトネトが要るなんて...

157:デフォルトの名無しさん
05/10/05 11:18:23
>C++/CLIは超難解なC++言語でがんばって数十メガのVMがロードされるというわけだ。
･ﾟ･(つД`)･ﾟ･

>今時のパソコンで数十メガなんて意味を持たない
　　　　 ∧＿∧
　　　　　（ ´∀｀ ） 　このゴミ、どこに捨てたらいい？
　　　　 /⌒　　 ｀ヽ
　　　　/　/　　　 ﾉ.＼＿M
　　　 (　/ヽ　　　|＼＿__E）
　　　　＼ /　　　|　　 ／　 ＼
　　　 　 （　　 _ﾉ |　 / ｳﾜｧｧﾝ ヽ
　　　　　 | 　 /　/　 |ヽ（｀Д´）ﾉ|
　　　 　　|　 /　/　　ヽ（>>147）ノ
　　　　 　(　 )　) 　　　￣￣￣
　　　　　 |　|　/
　　　　　 |　|　|.
　　　　　/　|＼ ＼
　　 　 ∠／



158:デフォルトの名無しさん
05/10/05 11:48:48
>>157
「C++/CLIは」というより、
Longhornは常にCLRが動いていて、その上でサービスを受けるわけでしょ。
C#やVBだって同じ。

159:デフォルトの名無しさん
05/10/05 11:58:04
　　　　　 ∧＿∧
　　　　　（ ´∀｀ ） 　このゴミ、どこに捨てたらいい？
　　　　 /⌒　　 ｀ヽ
　　　　/　/　　　 ﾉ.＼＿M
　　　 (　/ヽ　　　|＼＿__E）
　　　　＼ /　　　|　　 ／　 ＼
　　　 　 （　　 _ﾉ |　 / ｳﾜｧｧﾝ ヽ
　　　　　 | 　 /　/　 |ヽ（｀Д´）ﾉ|
　　　 　　|　 /　/　　ヽ（Longhorn）ノ
　　　　 　(　 )　) 　　　￣￣￣
　　　　　 |　|　/
　　　　　 |　|　|.
　　　　　/　|＼ ＼
　　 　 ∠／


160:デフォルトの名無しさん
05/10/05 12:31:44
>>158
LHは1.1じゃなかったっけ？

161:デフォルトの名無しさん
05/10/05 13:47:31
2.0 だろ。WinFX は PlatformSDK のような扱いになるらしいが
>>158
もともとCOMサーバが動いてるんだから、変わらないでしょ
CLR は COM 後継なんだし

162:デフォルトの名無しさん
05/10/05 14:45:51
後継にしては今までのソースが全て吹っ飛んでしまうのは何故？

163:デフォルトの名無しさん
05/10/05 18:45:25
そこでC++/CLIですよ

164:デフォルトの名無しさん
05/10/05 18:55:03
>162
(ﾟДﾟ)ﾊｧ?

165:デフォルトの名無しさん
05/10/06 02:33:02
>>162
レガシー

166:デフォルトの名無しさん
05/10/06 14:27:21
>>165
もうカルディナは必要ありません。

167:デフォルトの名無しさん
05/10/06 14:37:56
Vistaはネッツに吸収されました。

168:デフォルトの名無しさん
05/10/06 15:13:30
アニヲタばっかりだな

169:デフォルトの名無しさん
05/10/06 15:15:10
車なんだけど...

170:デフォルトの名無しさん
05/10/06 15:28:17
>>68
LinqやActive Objectが、C++0xに入るわけないだろ。

この辺が入ったC++/CLIはEMCAで標準化されるだろうけど。

171:デフォルトの名無しさん
05/10/06 15:41:49
そーいえば、Ｃ貪とかいう標準化されたどーでもいーものがあったね。

標準化なんてＣＯＢＯＬでもある。
というか、プログラムの長持ちではＣＯＢＯＬのが先輩だね。

172:デフォルトの名無しさん
05/10/06 16:22:27
168 名前：デフォルトの名無しさん[sage] 投稿日：2005/10/06(木) 15:13:30
　　アニヲタばっかりだな

169 名前：デフォルトの名無しさん[sage] 投稿日：2005/10/06(木) 15:15:10
　　車なんだけど...

173:デフォルトの名無しさん
05/10/06 16:53:26
active最高杉



174:デフォルトの名無しさん
05/10/06 18:05:44
168 名前： デフォルトの名無しさん [sage] 投稿日： 2005/10/06(木) 15:13:30
アニヲタばっかりだな
169 名前： デフォルトの名無しさん [sage] 投稿日： 2005/10/06(木) 15:15:10
車なんだけど...

ワロタ

175:デフォルトの名無しさん
05/10/07 00:25:44
よくわからんが、車を元ネタにした名前が出てくるアニメがあるって解釈でいいのか？

176:デフォルトの名無しさん
05/10/07 00:32:14
>>175
レイアースの登場人物の名前は車に由来。
ジョジョの登場人物の名前はミュージシャンに由来。

とCLAMPのアニメを3本見ただけの俺が答える。

177:デフォルトの名無しさん
05/10/07 00:32:53
つまり「アニヲタばっかりだな」が正解？

178:デフォルトの名無しさん
05/10/07 01:28:14
>>177
「アニヲタ馬鹿だな」が正解。

179:デフォルトの名無しさん
05/10/07 14:04:43
アニオタのせいで秋葉原って今ものすごいキモイ町になってる

180:デフォルトの名無しさん
05/10/07 14:41:26
そういや開業直後にTXに乗ってアキバへ行ったが、駅を出たら見知らぬ光景に遭遇して慣れるのに
時間を要した。ちなみにヨドバシカメラにはまだ行っていない。

181:デフォルトの名無しさん
05/10/07 20:32:11
>>179
アニヲタはそれほどでもない。むしろエロゲヲタが酷い。

182:デフォルトの名無しさん
05/10/07 20:52:23
>>181
悪いが区別が付かないのでどうでもいい。

183:デフォルトの名無しさん
05/10/07 20:53:42
>>182
プログラマとSE

184:デフォルトの名無しさん
05/10/07 21:07:08
>>183
悪いが区別が付かないのでどうでもいい。

185:デフォルトの名無しさん
05/10/07 21:15:49
よくテレビや雑誌で晒されてるようなヲタって何ヲタなの？
電車男みたいなやつ

186:デフォルトの名無しさん
05/10/07 21:39:55
ヲタというより、むしろ朝からパチンコ屋に並んだり、競馬場にたむろしてる連中を連想する。

187:デフォルトの名無しさん
05/10/07 22:54:11
パチンコ屋に並ぶのは朝しかねーだろ？
バカかおめー昼夕オープンなんて滅多にないんだぞ
しね

188:デフォルトの名無しさん
05/10/08 00:03:20
とパチンカスが言っております。

189:デフォルトの名無しさん
05/10/08 01:40:45
>>185
プログラマじゃないの？ :-)

190:デフォルトの名無しさん
05/10/08 02:08:49
>>186
社会の底辺にいる人達か。

191:デフォルトの名無しさん
05/10/08 02:13:23
なるほど、プログラマは朝からパチンコ屋にならんで競馬場にたむろしてマルチ萌え〜とかセリオたんﾊｧﾊｧって言ってる人たちなのか
モニタの上に変なフィギュア飾ってるし

192:デフォルトの名無しさん
05/10/08 02:15:16
>>191
通常の業務の上にそんなことまでしてたら過労死するな。

193:デフォルトの名無しさん
05/10/08 21:40:48
朝からパチンコ屋にならんでなんいうやつはｱﾌｫ１確
お金をつかって買い物するっていってるような物だぞｗ

194:デフォルトの名無しさん
05/10/08 21:41:33
>>193
おまえは中国人かよｗ

195:デフォルトの名無しさん
05/10/08 21:43:57
デカ顔＆短足＆チビの日本人よりはマシｗ

196:デフォルトの名無しさん
05/10/08 21:44:57
ズボシだったのか
いや、悪気はなかったんだ
ジョークだ許してくれ

197:デフォルトの名無しさん
05/10/08 21:44:59
COME WITH ME
ってｶｯｺｲｲ


198:デフォルトの名無しさん
05/10/08 21:55:29
誰か>>193の言わんとすることをわかりやすく解説してください。

199:デフォルトの名無しさん
05/10/08 21:57:38
おまいら、巣にｶｴﾚ

200:デフォルトの名無しさん
05/10/09 00:56:46
>>198
日雇いのバイトで得た給料を次の日にパチンコでなくすようなやつなんだ。
そっとしといてやれよ。

201:デフォルトの名無しさん
05/10/09 01:00:55
プログラミングヲタよりは（ｒｙ


202:デフォルトの名無しさん
05/10/10 13:13:40
>>200
その日の内にだろ

203:デフォルトの名無しさん
05/10/10 16:34:14
>>202
夜勤の場合はその通りだな。

204:デフォルトの名無しさん
05/10/10 21:48:37
ここにいるひとってやっぱ電車男みたいな人ばっかり？
俺は電車男そのものだけど・・・orz

205:デフォルトの名無しさん
05/10/11 00:50:45
電車男って、アニメオタクでプログラミングなんてしないんじゃ？　（テレビしか見てないけど

206:デフォルトの名無しさん
05/10/11 00:51:50
電車男はあまりオタクじゃないよ
完全に消費者だし

207:デフォルトの名無しさん
05/10/11 01:27:57
もはやC++/CLIはどうでもよくなってる罠

208:デフォルトの名無しさん
05/10/11 01:31:00
>>168逝って良し

209:デフォルトの名無しさん
05/10/11 11:16:33
>207
必死に自作自演してるんだよ。ほっとけ

210:デフォルトの名無しさん
05/10/20 02:58:49
へー、pure Java の CLRなんてあるのか。
逆もあれば、無限に重ねられるな

211:デフォルトの名無しさん
05/11/05 01:08:45
>>210
詳しく

212:デフォルトの名無しさん
05/11/05 13:22:36
C#のほうが気になる

213:デフォルトの名無しさん
05/11/10 01:23:28
>>210
ただでさえ重いCLRをJavaなんかで実装したら使い物にならんだろ

214:デフォルトの名無しさん
05/11/18 01:03:42
C#もっと速かったら使いやすいし、いいんだけだな〜

215:デフォルトの名無しさん
05/11/20 01:35:04
釣れなかったみたいだねﾌﾟｹﾞﾗ

216:デフォルトの名無しさん
05/11/22 07:00:04
checked statement なぜ使えないのだろうか...orz


217:デフォルトの名無しさん
05/11/22 08:16:08
C++/CLIをちょっと.NETのライブラリとか使いたい部分だけマネージにして後はほとんどアンマネージにしてる人って居る?
その場合の速度知りたいんですが･･･
C#ちょっともっさりしすぎ。

218:デフォルトの名無しさん
05/11/22 13:42:52
>>217
部分的にでもCLRを呼び出している以上起動時のもっさり感は変わらない。
P/Invokeよりは高速とはいえ、ネイティブ−マネージドの遷移は負荷が高いから
混ぜたいなら呼び出しの単位は大きいほうがいい。
画面まわりをネイティブで書いて、メニューからのイベントをマネージドで
処理するような使い方（またはその逆）は向いているが、
特定のロジックをネイティブにして頻繁にマネージドコードから呼び出すのには向いていない。

219:デフォルトの名無しさん
05/11/22 20:50:52
ホスティングすればいいんじゃないの？＞起動の遅さ
URLﾘﾝｸ(d.hatena.ne.jp)

220:デフォルトの名無しさん
05/11/22 21:33:23
STL.NETはどこからダウソできるん？


221:デフォルトの名無しさん
05/11/24 09:32:05
STL.NETじゃね？


222:デフォルトの名無しさん
05/11/24 11:46:15
> ネイティブ−マネージドの遷移は負荷が高い

え？

223:デフォルトの名無しさん
05/11/25 01:21:05
>>219
だたホスティングしてもmscoree.dll をCOMで呼び出すだけだからあまり変わらない気がするが、
同じプロセス空間に複数のアップドメインを作ってアセンブリを起動するシェルのようなものを作れば、
それなりに起動は速くなるかもしれないですね。

>>222
え？　managed codeからnative codeをオーバーヘッド無しで呼べるといいたいのかな？

224:デフォルトの名無しさん
05/11/25 01:44:09
呼べるでしょ。
データの受け渡しにコストがかかるだけで。

225:デフォルトの名無しさん
05/11/25 01:47:36
>>224
呼べません。

226:デフォルトの名無しさん
05/11/25 01:53:34
一見そのまま呼べるかのように振る舞うだけじゃなかったか

227:デフォルトの名無しさん
05/11/25 02:04:50
オーバーヘッドって具体的にどんな処理してるんだろ。

228:デフォルトの名無しさん
05/11/25 02:08:03
マーシャリングとかじゃね？

229:デフォルトの名無しさん
05/11/25 02:12:24
マネージドとネイティブの世界には分厚い境界線
なるものが存在するんですよ。
その境界線を越えようとするものは某北朝鮮から脱国するがごとく
リスクを負わなければならないのですよ。

230:デフォルトの名無しさん
05/11/25 06:46:32
intしか使わないネイティブを、
SuppressUnmanagedCodeSecurity, LinkDemandすればコストほとんどなしなんじゃないの?

構造体もValueType使えば、ボクシング/アンボクシング行われないしね。

231:デフォルトの名無しさん
05/11/25 09:22:48
>>229

つ Borland(R) Developer Studio 2006 URLﾘﾝｸ(www.borland.co.jp)

マネージドとネイティブをコンパイルで切り替えだお。

232:デフォルトの名無しさん
05/11/25 11:14:41
value class制限大杉



233:デフォルトの名無しさん
05/11/25 21:30:37
ref structとvalue classの違いは？

ref structって値型じゃないの？

ref classとref structの違いって何よ？デフォルトpublicとprivateの違いだけ？

234:デフォルトの名無しさん
05/11/25 22:31:14
ref　←→ 値型

ref class と ref struct の違いは class と struct の違いと同じ
ref 型がCLRに管理されてるクラス。value 型は primary な値を意味するクラス

235:デフォルトの名無しさん
05/11/25 22:44:30
OKありがとう。とてもわかった

236:デフォルトの名無しさん
05/11/25 23:02:55
値型だと
デフォルトコンストラクタ
コピーコンストラクタ
デストラクタ
ファイナライザ
代入演算子
が定義できなかったよ。

デフォルトコンストラクタが定義できないんで引数無しのタグクラス食わせてるんだけど
何かあるんだろうか...
それとデストラクタが定義できないせいで単純にnewすると解放ができない。


237:デフォルトの名無しさん
05/11/25 23:07:16
>>236
C#って知ってる？

238:デフォルトの名無しさん
05/11/25 23:08:24
> newすると解放ができない。

なんか言ってることおかしくない？
解放って？

239:デフォルトの名無しさん
05/11/25 23:12:33
>236
値型は primary な型を作るためのものだから、int とかにデフォルト・コンストラクタや
ファイナライザを定義しないでしょ？

240:デフォルトの名無しさん
05/11/25 23:13:13
>>236
値型は、初期化しによる初期化、代入などで、
memcpyが行われるだけでいいようなオブジェクトに使う。
定義できなかったと言うより、定義しないでいいものに使う。

241:236
05/11/25 23:15:45
>>238
template <typename T,typename TAG>
value struct a
{
T *p;
a(TAG)
{
p = new T();//NativeC++のスマートポインタが使えないのでCLIなスマートポインタが必要ぽい
}
};


242:236
05/11/25 23:21:43
>>239,240
参照型だとコピーコンストラクタいちいち用意するの面倒じゃん。
C++とC++/CLI両対応のソース書きたいので値型にしてる。


243:デフォルトの名無しさん
05/11/25 23:38:57
>>242
.Netでは「クラスは参照型」となっているのだからいつか破綻する。

244:デフォルトの名無しさん
05/11/25 23:40:16
それは思考が逆で、
コピーコンストラクタが必要ないから値型にしているのであって、
面倒だから参照型を使わないんじゃない。


245:デフォルトの名無しさん
05/11/25 23:41:57
値型か参照型かは性能にもろに影響してくるから
適切に選択した方がいいよ

246:デフォルトの名無しさん
05/11/25 23:56:47
普通にクラスを書けばいいんじゃないか？
わざわざ値型で定義しようとするから、苦労しているだけだと思うが

247:デフォルトの名無しさん
05/11/26 08:19:50
>>45
LLVMがgccに入りそうな勢いだなあ。

248:デフォルトの名無しさん
05/11/28 09:42:42
参照を初期化リストで初期化できないのですが、
なぜなのでしょうか？
value struct UseRef
{
explicit UseRef(int& in_i)
:i(in_i)
{}
int& i;
};
ref struct TestRef
{
int i;
UseRef r;
TestRef()
:r(i)
{}
};

249:デフォルトの名無しさん
05/11/28 13:52:01
値型は生成時にデフォルト値を持つ必要がありますが、標準C++ の int 型はデフォルト値を
規定されていません。そのため、生成時に不定となる値の参照を型として保持できないと思われ

250:248
05/11/28 16:40:53
>>249
ありがとうございます。
参照型でも試してみましたが、やはりだめみたいでした。
一度、GC Heapにgcnewしてそこからinterior reference？(int%)を取得することで
参照のように扱うことはできました。
どうも値型のメンバには値型かGcHeap(Cloneされる)しかおけないようです。
また、interior ptr|referenceのときもクラスのメンバにはできないようです。

251:デフォルトの名無しさん
05/11/28 18:05:46
まぁ、仕様書見るとそう書いてありますね


252:デフォルトの名無しさん
05/11/28 22:05:15
俺の勘で。
ref　struct　TestRef
{
　　int　i;
　　UseRef　r;
　　TestRef()　:　i(0),　r(i)
　　{}
};

253:デフォルトの名無しさん
05/11/29 16:38:04
UseRef のデフォルト・コンストラクタが不定値を持つから駄目ぽ

254:デフォルトの名無しさん
05/12/01 17:33:26
組込型だと
普通のref class とvalue classで通るコードでエラーがでるんだけど
属性とかでなくコンパイラにはじかれてるのかな？

Int32 o_int(0);
Int32^ g_int = gcnew Int32(0);
Int32% r_int = *g_int;
//Int32^ rg_int = %r_int;//NG

//String o_str;//NG
String^ g_str = gcnew String("");
//String% r_str = *g_str;//NG
//String^ rg_str = %r_str;//NG

255:デフォルトの名無しさん
05/12/02 02:00:31
なんだか汚い言語になっちゃいましたね

perlみてー

256:デフォルトの名無しさん
05/12/02 03:41:08
C++が汚いのはもとからだろ

257:デフォルトの名無しさん
05/12/02 07:44:32
>>255
思いつきで拡張してるよね。
C++の世界では有名な人達がやっているんだが…

258:デフォルトの名無しさん
05/12/02 07:49:14
だれだっけ？

259:デフォルトの名無しさん
05/12/02 08:28:53
Stanley Lippman
URLﾘﾝｸ(staff.develop.com)
URLﾘﾝｸ(blogs.msdn.com)
URLﾘﾝｸ(www.microsoft.com)

Herb Sutter
URLﾘﾝｸ(www.gotw.ca)
URLﾘﾝｸ(blogs.msdn.com)
URLﾘﾝｸ(www.microsoft.com)

260:デフォルトの名無しさん
05/12/02 12:51:52
Perlは美しい。C++もああいうの目指すべき。

261:デフォルトの名無しさん
05/12/02 13:27:41
>>260
漏れはあまり詳しくないんだが、そうか？？？本当にそうなのか？？？？？？？

262:デフォルトの名無しさん
05/12/02 15:34:59
そんなあなたに Brainf*ck

263:デフォルトの名無しさん
05/12/03 00:57:17
>>255-257
良くも悪くもC++的っていう気はする。

264:デフォルトの名無しさん
05/12/03 11:30:30
C++は細かいところで汚いなりに、それなりのポリシーがあったが、
C++/CLIに至ってはなんでもありだ。実装の都合としか思えないものもある。

265:デフォルトの名無しさん
05/12/03 19:46:54
C++をぐちゃぐちゃにしC++コミュニティーを崩壊させる。

↓

C++の衰退とC#の反映

266:デフォルトの名無しさん
05/12/03 20:47:05
Ｃ＃はメジャーにならない
断言する

267:デフォルトの名無しさん
05/12/03 21:11:34
名無しで断言されても……

268:デフォルトの名無しさん
05/12/03 22:04:56
>>265
それか！！

269:デフォルトの名無しさん
05/12/04 18:49:26
C++/CLIの設計コンセプトは「拡張機能を使わなければ、既存のC++と変わらないこと」だから
別にC++に変な影響を与えないと思うけど

270:デフォルトの名無しさん
05/12/04 20:03:25
果たしてそうかな

271:デフォルトの名無しさん
05/12/04 20:18:12
>>270
そうだよ。

272:デフォルトの名無しさん
05/12/04 20:56:43
関係ないが、親玉格のC(99)がやらかしてくれてるからなあ。

273:デフォルトの名無しさん
05/12/04 21:15:11
C++はまだ「生きた」言語なんだよ。
まだまだ進化する。

274:デフォルトの名無しさん
05/12/04 21:41:25
ここに書いて良いのかわからんかったんですが。
タスクマネージャーの「CPU使用率の履歴」みたいな動的な(?)グラフを出せるものを書きたいのですが
何から手をつければいいのか、全くわかりません。
アドバイスよろしくお願いします。

275:デフォルトの名無しさん
05/12/04 21:46:55
age

276:デフォルトの名無しさん
05/12/04 22:13:21
>>274
とりあえず↓この本読め。
URLﾘﾝｸ(www.amazon.co.jp)

277:デフォルトの名無しさん
05/12/05 09:58:09
>>272
C99のマズイところでどんなとこ？
得に思い当たらないんだけど

278:デフォルトの名無しさん
05/12/05 11:34:16
エラーのthrow/catchが、cとc++で別になったのは痛い。

MFCとC++、C丼とC++、MC++とC++、C++CLIとC++、それぞれ結局別物と思われてるところも痛いけど。

279:デフォルトの名無しさん
05/12/05 11:43:35
実際別物

280:デフォルトの名無しさん
05/12/05 15:13:07
MFCを持ち出してくるところが痛い。

281:デフォルトの名無しさん
05/12/05 15:30:50
MFCって、mc++とかC++/CLIから使えるんだっけか？

282:デフォルトの名無しさん
05/12/05 18:32:19
C++/CLIやmc++の構文を使ってないコードを /clrでコンパイルしたものを
C++/CLIやmc++のプログラムと読んでいいかどうかによるけど、
そう呼んでいいなら使える。

283:デフォルトの名無しさん
05/12/05 18:41:23
managed と unmanagedの型でデータ交換したいのですが、
COMを使うしかないのでしょうか？



284:デフォルトの名無しさん
05/12/05 19:07:05
>>283
具体例を挙げてわかるように質問してくれ。

285:デフォルトの名無しさん
05/12/05 19:10:17
＞/clrでコンパイルしたものを
どういったオプションでつか？

286:283
05/12/05 19:33:39
>>284
混合クラスにできないだけで、
別クラスにしておいて呼び出しは可能だったのね...

Marshalingできる時はしたほうがいいのかな
URLﾘﾝｸ(msdn2.microsoft.com)(en-US,VS.80).aspx


287:修正
05/12/05 21:25:49
unmanagedからmanagedの呼び出しはできないみたい。



288:デフォルトの名無しさん
05/12/05 22:45:23
CLRホスティング・・・

289:デフォルトの名無しさん
05/12/06 03:01:26
managed c++, c++/CLI なら
managed から nativeのモジュールを呼び出すことも
cl /MT /c submod.cpp
cl /clr mainmod.cpp submod.obj
native から managedのモジュールを呼び出すこともできる。
cl /clr /c submod.cpp
cl /MT mainmod.cpp submod.obj



290:デフォルトの名無しさん
05/12/06 07:34:09
最強

291:デフォルトの名無しさん
05/12/06 10:52:01
unko

292:デフォルトの名無しさん
05/12/07 23:15:01
C++/CLIの存在意義って？

マネージならC#でよくね？

293:マイク ◆yrBrqfF1Ew
05/12/07 23:19:32
そうだな。

294:デフォルトの名無しさん
05/12/08 00:28:08
やっぱりC#?
C++から移植するのってどれぐらい工数かかるんだろうか・・・・

295:デフォルトの名無しさん
05/12/08 00:32:04
ぶっちゃけ、WindowsアプリならVC++6&MFCが最強では？
あえてC#を覚えようとする気がしない。
VC++6&MFCでつれないWindowsアプリはない。

296:デフォルトの名無しさん
05/12/08 00:39:03
かわいそうな人

297:デフォルトの名無しさん
05/12/08 01:10:46
あえてCを覚えようという気がしない。
機械語で作れないwindowsアプリはない。

298:デフォルトの名無しさん
05/12/08 01:24:49
あえて計算機を覚えようという気がしない。
脳内で計算できない問題はない。

299:デフォルトの名無しさん
05/12/08 06:10:14
切り返すなら同じ性質の物事を書かなきゃ :-P

300:デフォルトの名無しさん
05/12/08 08:16:12
>>297
俺も未だに機械語で書いてるよ
Cだとおせーから嫌だ

301:デフォルトの名無しさん
05/12/08 08:28:05
>>295
なるほど、いろんなWindowsアプリさんたちが釣れるようでつね。

302:デフォルトの名無しさん
05/12/08 11:44:15
>>295はLonghornが出たら干される使い捨てデジドカ

303:デフォルトの名無しさん
05/12/08 20:59:47
OSが記述できてしまう
C++は絶対に廃れないよ
しかも、デバイスドライバを書ける人は絶対に不可欠
C#やJAVAなんてモノが出来ても結局また
新たな言語が出てきて廃れるのは必至

304:デフォルトの名無しさん
05/12/08 21:14:47
つまりCOBOLと似たようなもんだ。
新しい言語の出現で全盛期より減ったとは言え、需要がなくなることはありえない。

305:デフォルトの名無しさん
05/12/08 21:44:19
歩く死体か。

306:デフォルトの名無しさん
05/12/09 02:03:11
Cで必要にして十分な件。

307:デフォルトの名無しさん
05/12/09 11:02:38
既存のプログラムが全部マネージ環境で通るようにライブラリとか
整えて欲しい。

printfやstrcmp使うとネイティブとの混合アプリになっちゃうんでしょ？
標準ライブラリの中も.NETにすりゃあいいのに。


308:デフォルトの名無しさん
05/12/09 11:24:49
混合になってなんかマズイことでもあるのかい？

309:デフォルトの名無しさん
05/12/09 13:12:07
>>307
あなたは根本的にCLIの世界を理解してないです。


310:デフォルトの名無しさん
05/12/09 16:26:18
>>308
混合だとWin以外に持っていけるの？（あるかはしらんけど）
あと、切り替え時に異様に遅い感触。

>>309
根本を教えてくれ


311:デフォルトの名無しさん
05/12/09 16:43:46
感触って君の思い込みのこと?

312:デフォルトの名無しさん
05/12/09 16:53:06
>>311
/clrつけてコンパイルしなおしたプログラムが異様に遅い。
.NETにしてもちょっと遅すぎると思ってね。原因がネイティブ
部分の呼び出し負荷くらいしか思い当たらない。


313:310
05/12/09 17:37:18
簡単なやつで試してみた。環境はPen4-3GHz

int a=0;
while(a++<200000000){
stricmp("abc","123");
}

ネイティブアプリだと１、２秒、CLIだと１２秒くらいかかる。

stricmpをmy_stricmpに変えて、以下のように適当に定義してみると、
ネイティブでもCLIでも１、２秒で終わる。（my_stricmpは適当。要は
標準ランタイムを呼ばなければ良い）

int my_stricmp(const char*a,const char*b){
while(*a++==*b++){
if(a[0] == 0)
return 0;
}
return -1;
}

ちなみに、strcmpだとCLIでも１、２秒で終わるのだが、良く分からん。
strcmpだとCLIでもインライン展開されるのかな？


314:310
05/12/09 17:42:54
>>313の例ではネイティブへの切り替え以外に負荷になる要素は
無いと思うんだが、識者の意見希望。

315:デフォルトの名無しさん
05/12/09 18:51:09
関数の処理が遅いのか、CLR の起動に手間取っているのかは、ちゃんと分けた？

316:310
05/12/09 19:01:59
>>315
my_stricmpを使ってネイティブと時間の差が無いのだから、
起動時間の問題じゃないと思う。

あと、ループの回数を増減させれば処理時間も比例する。


317:デフォルトの名無しさん
05/12/09 20:03:25
>>313
strcmpは？stricmpだとCLIの方はロケールとかで色々面倒くさい
ことしてそう。

318:デフォルトの名無しさん
05/12/09 20:56:41
>>313
ではlstrcmpはどう？
これなら絶対にインライン展開できない。

319:310
05/12/09 21:15:00
>>318
lstrcmp,これから試してみるけど先に質問。

>>317に関して、
俺、やはり根本が分かって無い模様。strcmpは313に書いた通りなのだが、
stricmpの場合でも、CLIからネイティブと同じルーチンが呼ばれるもんだと
思っていた。

この前提で、中身が一緒なら呼び出してる部分に負荷があるんじゃないかと
思っていたわけだが、ネイティブとCLIで呼び出されるstricmp（に限らず標準
ライブラリ全般）は別物なの？

320:デフォルトの名無しさん
05/12/09 22:17:02
>>319
その試した見たというコードをどこかのアップローダに晒すというのは
どうだい？そうすれば同じ土俵で話ができる。

321:310
05/12/09 22:54:16
>>318
試してみた。lstrcmpの場合、ネイティブ３７秒、CLI４７秒だった。
lstrcmpこんなに重いのかというのはともかく、差がstricmpと
同じ。つーことはやはり呼び出し負荷でしょう。もちろんループ
回数も同じで測定している。

>>320
＞その試した見たというコード
今までの数字は全部313のサンプルコードでの話。
mainかWinMainで囲ってちょうだい。

INT WINAPI WinMain( HINSTANCE, HINSTANCE, LPSTR, INT)
{
{
int a=0;
while(a++<200000000){
stricmp("abc","123");
}
}
return 0;
}




322:デフォルトの名無しさん
05/12/09 22:55:34
アセンブリ（アプリケーション）で閉じてる範囲に置いては、CLIはロードされないんじゃね？

323:310
05/12/09 23:02:41
>>322
意味が分かりませんorz

324:デフォルトの名無しさん
05/12/09 23:06:31
>>321
> つーことはやはり呼び出し負荷でしょう。

それ言うなら、

> もちろんループ回数も同じで測定している。

回数変えてファクターが何か調べないと。面白い奴だな(w


325:310
05/12/09 23:10:53
>>324
回数変えたら実行秒数が比例するけど。

my_stricmpにしてネイティブと差が無いわけだから、違いは
標準ライブラリの呼び出し以外に何か考えられる？


326:デフォルトの名無しさん
05/12/09 23:20:29
y = ax + b の a を比べろと言えば分かりますか?

327:310
05/12/09 23:27:29
>>326
何を言ってるのか分かりませんが、
具体的に他にファクターがあるならあげてみて欲しい。

こちらの比べ方に抜けがあるならそこを指摘してくれまいか。


328:デフォルトの名無しさん
05/12/09 23:31:27
ちょっと、煽りと神経質になってる人もいるみたい
まぁ、とりあえず、時間の出たマシンのスペックを教えてちょ
問題になっているのは、msvcm80.dll 辺りかな

329:デフォルトの名無しさん
05/12/09 23:54:07
回数を2倍にしても実行時間が2倍になるとは限らない。
325に比例するとは書いてあるけど、比例にもいろいろあるだろうに。

330:デフォルトの名無しさん
05/12/10 00:00:17
いや、確認した。これは、なんだろう

比較のサンプルソースを出すね

C++/CLI
int main(array<System::String ^> ^args)
{
　　const char *buff = "buffer";
　　const char *check = "Test";

　　DateTime dt = DateTime::Now;
　　for ( int i=0; i<2000000; i++ )
　　{
　　　　//strcmp(buff,check);
　　　　mycomp(buff, check);
　　}
　　DateTime endTm = DateTime::Now;
　　Console::WriteLine("Time : {0}", endTm - dt);
　　return 0;
}

int mycomp(const char* before, const char* after)
{
　　while(*before++==*after++) if(before[0] == 0) return 0;
　　return -1;
}

これで、strcmp とmycompを切り替えるだけで、全然速度が違う。なじぇ？

331:デフォルトの名無しさん
05/12/10 00:19:19
ﾜﾗ

332:デフォルトの名無しさん
05/12/10 00:28:24
まるで見当はずれかもしれませんが
int mycomp(,,,) の前に #pragma unmanaged を置いてみるとどうなりますかね？

333:330
05/12/10 00:53:42
ごめん。これは速度が違って当たり前だった。ろくにチェックしていない
before をちゃんとチェックすると、だいたい１６秒でstrcmpと変わらない
むしろ、ネイティブだと一瞬なんで、処理に時間がかかる理由が気になる

334:330
05/12/10 01:08:50
すまん。>>333 は元の関数のコメントアウトをしてなかったorz
mycompにすると一瞬で終わるね。もうちょっと、関数の実装をちゃんとするべきなんだろうけど
ネイティブに記述された関数はネイティブで処理されてる。となると、C標準関数が問題
なのか・・・

335:310
05/12/10 08:50:45
>>329
＞回数を2倍にしても実行時間が2倍になるとは限らない。
それは比例じゃないと思うけど。
言葉どおり比例と受け取って欲しい。

だからループ外のファクターでは無いと思う。

>>334
マシンの速度が分からないけど、200万回のループで１６秒もかかる？

あと、strcmpだとこちらではCLIでもネイティブと同じだった。

stricmp,lstrcmpで、ネイティブとの差が2億回のループで10秒。

差が同じなので、処理内容の問題でも無いと思う。
こちらのマシン速度は>>313です。



336:310
05/12/10 10:00:02
>>329
言葉が足んなかった、すまん。ax+bのbの部分はごく小さいと思って欲しい。

>>332
試してみた。
CLIでmy_stricmpをunmanagedプラグマで囲ったら、少しだけ遅くなった（３秒くらい）。
囲わなかった場合、今朝計り直してみたら１秒未満。


337:デフォルトの名無しさん
05/12/10 10:26:32
「思って欲しい」(w ってんじゃなくて、普通は i<2000000 だけじゃなく、
i<500000、i<1000000、i<2500000も取ってグラフをプロットするわけ。

あと、*cmp("abcdefghijklmnopqrstuvwxyz", "abcdefghijklmnopqrstuvwxyz")と、
*cmp("buffer", "Test")で比較するとかさ。
関数呼び出しのオーバーヘッドをみたいなら、
関数内の処理を軽くしたり重くしたりして違いを見るのが定席だろ?

strcmpとmycompじゃ実装が全然違うわけだから、そのくらいはしないと、
呼び出しがオーバーヘッドになっているかどうか分からない。
一文字目の比較で関数が返るから、関数呼び出しの差を見えると思ったかもしれないが、
ソースのない方はもしかしたらNULLチェックしているかもしれないし、
タコなコーディングかもしれない。
分からないはずなのに安易に結論づけているから、スルーされてる。

表計算ソフト、数式処理ソフト、グラフプロットツールあれば簡単にグラフ化できるよね。


338:デフォルトの名無しさん
05/12/10 10:37:48
・・・2億回で10秒って、別に違いがあって不思議じゃないよな？

339:310
05/12/10 10:56:43
>>338
単純化しただけであって、回数そのものは突飛でもない。

俺が問題にしてるのはCLIで標準関数呼び出しが遅い
ということ。>>337のいうようにちゃんとやることも出来るが、
そこまでやら無くても「CLIで標準関数呼び出しが遅い」のは
今までの例で明白じゃない？



340:デフォルトの名無しさん
05/12/10 11:15:41
最適化の違いだけだったりして
自分で言ってるけど、strcmp でネイティブと違いがないなら「CLIで標準関数呼び出しが遅い」
とは言えないんじゃない？

341:デフォルトの名無しさん
05/12/10 11:28:40
>>339
明白かどうかわかんないから粘着してんじゃないの？
他のファクターを探す手助けにもなるんだから手抜かずにやれば？

342:デフォルトの名無しさん
05/12/10 11:32:24
最適化で思ったんだけど、310 のネイティブの結果って速過ぎない？
漏れ、turion M37 2000 相当で以下のソースで1億回廻したけど、8秒ほどかかった
メモリも800MBほど食べた

int _tmain(int argc, _TCHAR* argv[])
{
　　const char *a = "sample text a";
　　const char *b = "sample text b";
　　std::vector<int> results;
　　time_t stm = 0;
　　time(&stm);
　　for ( unsigned long int i=0; i<100000000; i++ )
　　{
　　　　results.push_back(strcmp(a, b));
　　}
　　time_t etm = 0;
　　time(&etm);
　　std::cout << "Result : " << etm - stm << " Size : " << results.size() << std::endl;
　　return 0;
}

343:342
05/12/10 11:37:56
あ、すまん。濡れ衣だな。パフォーマンスの違いと詰め込み時間を考えれば、妥当か
ちなみに、/clr では同等のソースで11秒だった

344:310
05/12/10 11:38:06
>>340
遅まきながらステップしてみた。
strcmpはCLIでもインライン展開されていた。
stricmpはcallされていて、スタックトレースウインドウに
マネージからネイティブへ以降、と表示される。



345:342
05/12/10 11:48:28
漏れの環境での比較と詰め込みの結果
　　　　　CLR　native
strcmp　11s　8s
stricmp　16s　13s
lstrcmp　20s　17s

なんか、綺麗な結果になった。CLR の起動コストとかで +3s ぐらい

346:310
05/12/10 11:50:27
>>341
1回、1億回、2億回でほぼ直線状に並んでたから比例と書いた。
１回なら起動の時間は気にならないくらい一瞬で終わる。


347:310
05/12/10 11:52:44
>>345
ループ1回で+3sかかりますか？


348:デフォルトの名無しさん
05/12/10 12:39:12
>347
それはなかった。何らかのコストがかかっているのは確かみたい
CLR 側のやつはDateTime とか Console::WriteLine を使っていたので、ソースを完全に
同一にすると、
lstrcmp　19s　17s
になった。1億回のループでこれだから、あとはパフォーマンス・カウンタでも使わないと
細かくはわからない領域だと思う
ちなみにいろいろと切って静かに取ってみたら

　　　　　　CLR　Native　CLRx64　Nativex64
lstrcmp　　16s　　14s　　　15s　　　12s

なんて結果になった

349:310
05/12/10 12:52:57
>>348

342のソースはSTLの負荷が大きいのと、strcmpはインライン化されて
マネージ、ネイティブの切り替えは見えにくくなってると思う。

だから純粋にネイティブとCLIの差じゃなかろうか。

STLとっぱらってstricmpとかだけにしたらこちらの結果と
相似に近いのが出るんじゃないかな。

STLはマネージ側で実行されるんでしょ？　だからネイティブとの
大きな差にはならないんじゃないのかと。←こっちより差が小さいから

---

次ページ

最新レス表示

スレッドの検索

類似スレ一覧

話題のニュース

おまかせリスト

▼オプションを表示

レスジャンプ

mixiチェック！

Twitterに投稿

オプション

しおりを挟む

スレッドに書込

スレッドの一覧

暇つぶし2ch

---

5371日前に更新/240 KB
担当:undef