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はマネージ側で実行されるんでしょ？ だからネイティブとの
大きな差にはならないんじゃないのかと。←こっちより差が小さいから
350:デフォルトの名無しさん
05/12/10 12:59:11
>349
んにゃ。STLはネイティブだよ。ループで代入しているのは、最適化でループ自体が外される
のを防ぐため
しかし、CLRx64 にはもうちょっとがんがってほすぃ
351:310
05/12/10 13:01:25
>>350
>STLはネイティブだよ
ありゃそうなの？ テンプレートっつーくらいだから
マネージとしてコンパイルされてるのかと思った。
352:デフォルトの名無しさん
05/12/10 13:05:46
>351
それはジェネリクスを利用した STL.NET と混同してるんじゃないかな
しかし、+2秒はいったい何をしているのだろう
353:デフォルトの名無しさん
05/12/10 13:18:58
気になったので試してみた
List<int>^ results = gcnew List<int>;
time_t stm = 0;
time(&stm);
for ( unsigned long int i=0; i<100000000; i++ )
{
results->Add(lstrcmp(a, b));
}
time_t etm = 0;
time(&etm);
std::cout << "Result : " << etm - stm << " Size : " << results->Count << std::endl;
CLR Native CLRx64 Nativex64
lstrcmp 13s 11s 12s 9s
なかなか、よい結果です
354:デフォルトの名無しさん
05/12/10 22:23:25
>>346
数学苦手だった人?
355:デフォルトの名無しさん
05/12/10 22:28:52
直線と言っても限りなく水平に近いものから限りなく垂直に近いものまであるわけで。
356:デフォルトの名無しさん
05/12/11 00:48:46
>>353
ｽｹﾞｰな
357:デフォルトの名無しさん
05/12/11 03:32:29
.net2.0SDKにはC++/CLIのコンパイラって付いてくるの？
managedC++は？
358:デフォルトの名無しさん
05/12/11 04:57:42
ついてこない。
359:デフォルトの名無しさん
05/12/11 05:03:06
えええええええええええええ
360:デフォルトの名無しさん
05/12/11 07:55:17
.NET 1.0のmanaged c++の頃にやったテストなのだが、
C#やVB.NETでも使えるP/Invokeに比べて、
importlibで呼び出す場合はかなりパフォーマンスがよかった。
単純なNativeコードのDLLを作り繰り返し交互に呼び出すテストで、
かかった時間はP/Invoke 24, importlib 3
nativeコードからimportlibを使っての呼び出し 1.5 の比率。
DLLを作らずobjのリンクの場合、native-nativeで１、managed-nativeで2.5。
というわけでC++/CLIの存在意義はmix modeにあると思っている。
361:デフォルトの名無しさん
05/12/11 07:58:58
>357
cl /clr
cl /clr:oldSyntax
ってやってみな
362:デフォルトの名無しさん
05/12/11 08:05:27
>>360
つか、今時Win32 APIをコールする必要があるか？？？
363:デフォルトの名無しさん
05/12/11 08:56:21
ある
364:デフォルトの名無しさん
05/12/11 10:14:33
>>362
まだ大いにあるよ。
365:デフォルトの名無しさん
05/12/11 10:49:56
>>362
君にはない。
366:デフォルトの名無しさん
05/12/11 11:11:19
>>362
今時っていうか、今程度の.netじゃ、
まともなWindowsプログラミングやるならWinAPI叩かざるを得ない。
367:デフォルトの名無しさん
05/12/11 12:15:19
激同
368:デフォルトの名無しさん
05/12/11 19:40:02
>>366
そうか～？
.NET Frameworkのクラスライブラリだけですべて作れますけど・・・
369:デフォルトの名無しさん
05/12/11 20:06:45
いまんところ直面した問題
・ＩＭＥ
・Ｃａｒｅｔ
・ScrollWindowEx
370:デフォルトの名無しさん
05/12/11 20:08:00
>>369
初心者スレ行けばｗ
371:デフォルトの名無しさん
05/12/11 20:15:13
>>370
あほか。流れ嫁。API呼ばなきゃいけない問題だ。かす。
372:デフォルトの名無しさん
05/12/11 20:22:17
>>371
初心者スレ行けばｗ
373:デフォルトの名無しさん
05/12/11 20:29:00
>>368
SHFileOperation
VBのMyを使えとか言ったら刺す。
374:流れを読んでレス
05/12/11 22:03:40
>>371
初心者スレ行けばｗ
375:デフォルトの名無しさん
05/12/11 22:21:02
>>368
FileDialogのカスタマイズ
376:デフォルトの名無しさん
05/12/12 00:10:36
>>375
初心者スレ行けばｗ
377:デフォルトの名無しさん
05/12/12 01:51:23
こう見るとできないことだらけだね。
MSはどうするつもりなんだろう
378:デフォルトの名無しさん
05/12/12 09:21:36
そのためのC++/CLIじゃないか
379:デフォルトの名無しさん
05/12/12 23:05:18
>>368
ありふれた業務アプリ程度ならそれほど困ることもないけど、
ちょっとばかしシステムに寄った途端にできないことが増える。
原因が（専ら機能面とは何の関係もない）くだらない要求だったりして
余計に萎えるというおまけが付くこともよくある。
>>377
とりあえず使い物になるVer.3を出せと言いたい。
380:デフォルトの名無しさん
05/12/13 09:00:43
>原因が（専ら機能面とは何の関係もない）くだらない要求だったりして
>余計に萎えるというおまけが付くこともよくある。
あるあるｗｗ
381:デフォルトの名無しさん
05/12/13 15:22:20
URLﾘﾝｸ(s03.2log.net)
正直賛同できません。
382:デフォルトの名無しさん
05/12/13 17:15:19
Cに勝る言語はないってことだな
383:デフォルトの名無しさん
05/12/13 20:46:50
Win32への依存度を下げる必然性がないんだから当たり前でしょ？
384:デフォルトの名無しさん
05/12/13 21:47:52
Win95が出たときの3.1使いもそう言ってた
385:デフォルトの名無しさん
05/12/14 17:36:34
Win16→Win32s→Win32のこと?
あれは言語一緒だしね…
386:デフォルトの名無しさん
05/12/15 05:37:15
技術的な需要もないことはないけど、それよりただ新しいWindowsを
作らないといけないことだけが先行してるのが萎える。市場に対して
新規性を謳うことだけが最重要課題なんだよな。
387:デフォルトの名無しさん
05/12/15 20:41:33
次は ISO だな
URLﾘﾝｸ(www.ecma-international.org)
388:デフォルトの名無しさん
05/12/16 00:54:50
ISOは無理。
389:デフォルトの名無しさん
05/12/16 00:59:57
C#はISOだぞ
C++/CLIだってきっと
390:デフォルトの名無しさん
05/12/16 08:57:14
CLI は ISO で標準化されてたっけ？
391:デフォルトの名無しさん
05/12/16 10:32:21
CLI 標準はこれだな
ISO/IEC 23271:2003
392:デフォルトの名無しさん
05/12/16 10:56:26
このへんね。
URLﾘﾝｸ(www.plumhall.com)
URLﾘﾝｸ(msdn.microsoft.com)
393:デフォルトの名無しさん
05/12/19 23:38:22
URLﾘﾝｸ(itpro.nikkeibp.co.jp)
に「VC++ExpressEditionは標準C++を学習するための優れた教材である 」
てあるけど、そうなの？
.NETのWindowsアプリ作るものかとおもってたよ。
394:デフォルトの名無しさん
05/12/20 00:04:06
とりあえずVC++は標準C++への準拠度が高いことに間違いない。
395:デフォルトの名無しさん
05/12/20 02:58:19
これまでは準拠してなかったということ？
396:デフォルトの名無しさん
05/12/20 09:38:58
そゆこと
それからC++でﾄﾞﾄﾈﾄすると飛んでも文法だし、
大体MFCはキショイというのが定説。
397:デフォルトの名無しさん
05/12/20 13:40:38
へぇ。２００５からはキショクはないのか。
VC++（というIDE）を使ってなかった人も使い出したりするんだろか？
398:デフォルトの名無しさん
05/12/20 20:36:35
IDEがVC6位軽ければみんな使うだろうに
399:デフォルトの名無しさん
05/12/20 22:31:59
自分の価値観を回りに押し付けないように
400:デフォルトの名無しさん
05/12/20 23:47:53
ただそこに意見が存在するだけで
押し付けられたとか思い込まないように
401:デフォルトの名無しさん
05/12/21 14:50:12
URLﾘﾝｸ(mag.autumn.org)
C++復権すると思う？
402:デフォルトの名無しさん
05/12/21 15:45:19
>現状で極めて私的な感想から言えば、>JavaとC#の
>代替プログラム言語になり得る第1候補はVisual Basicです。
403:デフォルトの名無しさん
05/12/21 20:16:06
>>401
復権もなにも
C++で記述できないプログラムはないんだから・・・
404:デフォルトの名無しさん
05/12/21 20:22:13
>>403
それは今のCPUがC言語を動かすことを前提としてる面も大きいと思う
405:デフォルトの名無しさん
05/12/21 20:28:41
CPUがC言語を動かす？
意味不明
406:デフォルトの名無しさん
05/12/21 20:32:45
0番付近がNULL対策に実メモリを割り当てないようになってたりするじゃん。
他にC言語で簡単に扱えないメモリレイアウトを要求しないとかさ。
407:デフォルトの名無しさん
05/12/21 21:27:10
>>406
> 0番付近がNULL対策に実メモリを割り当てないようになってたりするじゃん
これはOSの問題という側面のほうが大きいと思う。
別にC/C++ではヌルポインタのビットパターンは0でなくとも良いとなっている。
> 他にC言語で簡単に扱えないメモリレイアウトを要求しないとかさ。
そんなもん誰も要求していない。
408:デフォルトの名無しさん
05/12/22 07:22:14
>>406
x86のI/Oポートは「C言語」では叩けないよ。
喪前様が言ってるのは、例えるなら、見かけの現象だけで
「太陽は地球を回っている」と言ってるのと同じこと。
言語側から見るだけじゃ、本当の意味では計算機は理解できない。
計算機の基礎から勉強したほうがいい。
409:デフォルトの名無しさん
05/12/22 08:14:09
x86のI/Oポートをたたく必要がない
410:デフォルトの名無しさん
05/12/22 10:44:15
>>403
「brainfuck復権すると思う？」
「復権も何も、brainfuckで記述できないプログラムはないんだから……」
411:デフォルトの名無しさん
05/12/22 10:48:17
>>410
いまだにつかっていますが、なにか？
412:デフォルトの名無しさん
05/12/23 07:42:22
みんなの大好きなあの言語が.NETの仲間入り。
brainf*ck.NET
413:デフォルトの名無しさん
05/12/27 11:36:51
>412
ソースコードｷﾎﾞﾝ
414:デフォルトの名無しさん
05/12/27 21:13:53
C++/CLIの入門サイトってありますか
415:デフォルトの名無しさん
05/12/28 10:29:47
VB.NET のPGで、構文解析を行う必要が出たときに、
C++/CLI で boost.spirit 使って手軽に構文解析モジュール作成して、
VB.NET から参照設定で呼び出す
ってことが簡単に出来るならすばらしいことだと思うよ。
416:デフォルトの名無しさん
05/12/28 10:32:23
マルチランゲージは素晴らしい。
現実はJ#は開封もされない事実。
ﾌﾞﾋﾞ厨はＣ貧を嫌い、Ｃ貧はﾌﾞﾋﾞ厨を嫌う。
Ｍ＄の理想は宣伝専用。
417:デフォルトの名無しさん
05/12/29 00:42:11
>415
普通にできるけど？
418:デフォルトの名無しさん
05/12/29 05:23:34
C#で以下のようなコードを
using (FileStream fs = new FileStream("test.txt", FileMode.Read)) {
}
C++/CLIでうまくかけるんですか？
FileStreamをスタックみたいにして作れると思ったんですが、できないのでしょうか？
419:418
05/12/29 05:25:15
すいません。できました。ぜんぜんわかってませんでした。
420:デフォルトの名無しさん
05/12/29 17:16:57
>414
入門するようなもんじゃねぇだろ？
C# を先に勉強した方がいいぞ
421:デフォルトの名無しさん
05/12/29 20:22:02
このスレでC#を勧めるのはどうかと思う。
422:デフォルトの名無しさん
05/12/30 00:13:58
そうか？ 基本的にC++/CLIのターゲットは、今までC++をやってきた連中が .net
Framework を自由に使えるようにと言うことだろ
表面的な文法なら、ref や generics にプロパティ、delegate ぐらいしか増えないわけで
今までC++をやっていたのであれば、それほど大した変更じゃない
問題なのは、.net Framework を使えるか、それをC++/CLIではどのように融合させたのか
という点だから、それは入門じゃないだろ。C# の入門書見て、C++/CLI の構文での使い方を
知れば、十分なんじゃねえかと思われ
ダイレクトに C++ を知らずに、C++/CLI に手を出すのは、止めた方がいいだろ
423:デフォルトの名無しさん
05/12/31 08:04:27
>>422の言ってることは確かに理解できるし、俺もほとんど同意だが。
ここはC++/CLIについて語るスレなんだよなｗ
でもマジレスすると、入門サイトありますか？とか聞くようなレベルなら
さっさとC#かVBで始めたほうがいいと思う。
424:デフォルトの名無しさん
05/12/31 13:05:55
_asm{} とか書いたらどうなるんだ？って思ってやってみたら、
さすがに main() の中に書いたら怒られた。
関数単位でマネージド、アンマネージドが切り替わるんだね。
_asm{} 入りの関数はネイティブコードとして生成されるみたい。
その呼び出しをうまい具合にやってくれるのがいいね。
いや、C++/CLI で _asm{} 使うような機会があるかどうかは別として。
425:デフォルトの名無しさん
05/12/31 14:20:04
>424
C++/CLI の拡張構文ではグローバルな関数の存在を認めていない
だから、ただ関数を生成しただけでは、基本的にネイティブとしてコンパイルされる
はずだよ。main はさすがに扱いが違うけど
426:デフォルトの名無しさん
05/12/31 15:09:22
ふと思ったんだが boost on C++/CLI なんて可能だろうか。
ていうか、だったら素直に .NET Framework にある
便利クラス使えよって気もするが。
427:デフォルトの名無しさん
05/12/31 16:19:01
アセンブリ内で閉じてるなら平気だろ
CLI 拡張部を使わなければ、標準のC++であることが C++/CLI の設計コンセプトなんだから
できない理由はない。聞く前にやれば？
428:デフォルトの名無しさん
06/01/01 00:43:38
if ( DialogResult::OK != openFileDialog1->ShowDialog(this) )
return;
コンパイルできません＞＜
t:\dev\www\winform\winform\Form1.h(154) : error C2039: 'OK' : 'System::Windows::Forms::Form::DialogResult' のメンバではありません。
t:\dev\www\winform\winform\Form1.h(23) : 'System::Windows::Forms::Form::DialogResult' の宣言を確認してください。
t:\dev\www\winform\winform\Form1.h(154) : error C2065: 'OK' : 定義されていない識別子です。
ビルドログは "file://t:\DEV\WWW\winform\winform\Debug\BuildLog.htm" に保存されました。
winform - エラー 2、警告 0
========== ビルド: 0 正常終了、1 失敗、0 更新、0 スキップ ==========
429:デフォルトの名無しさん
06/01/01 00:46:55
if ( Windows::Forms::DialogResult::OK != openFileDialog1->ShowDialog(this) )
return;
こうしました＞＜
430:デフォルトの名無しさん
06/01/01 01:19:56
Ｃ＋＋／ＣＬＩやりたいやつが入門サイトを希望するなんて
ギャグ以外の何者でもないだろ。
431:デフォルトの名無しさん
06/01/01 12:25:43
CLIマッシーンってどんな環境を目指しているの？
そのうち出るかもしれない3DのUIとか検索ベースのFSまでのつなぎかな？？
432:デフォルトの名無しさん
06/01/01 13:21:49
いつかでるLISPマシンまでの繋ぎです
433:デフォルトの名無しさん
06/01/01 15:25:53
>C++復権すると思う？
それ以前にC++ってメジャーだったっけ？
434:デフォルトの名無しさん
06/01/01 19:16:48
>433
どっかの記事では1990年代は優勢とか、書いてあったな。
435:デフォルトの名無しさん
06/01/01 21:07:00
C++/CLIのライブラリは .NET のライブラリをそのままISO標準にするの？？
以前のライブラリを使えるのはいいけど、できればGCで楽したいなー。
436:デフォルトの名無しさん
06/01/01 21:58:51
1990年代の段階ではC言語の仕事ばっかりやらされていたな。
437:デフォルトの名無しさん
06/01/01 22:49:23
>>433
Java/C#なんかが出てくる前は優勢だったと言えるだろう。
ただしベターCとしてしか使われなかった割合も大きかっただろうが。
438:デフォルトの名無しさん
06/01/01 23:37:51
delegateとeventの違いがわかりません。
delegateだけでいいような気がするのですが。。。
eventが存在する理由を教えてほしいです。
439:デフォルトの名無しさん
06/01/01 23:40:52
delegateを簡単に扱うため
440:デフォルトの名無しさん
06/01/01 23:46:17
＞＞439
センセー！簡単になる場面が思いつきません＞＜
441:デフォルトの名無しさん
06/01/01 23:52:42
event なら delegate の呼び出しが外から出来ないでしょ
442:デフォルトの名無しさん
06/01/01 23:53:11
>>440
うるせーな。少しは自分で考えろ。
delegateは関数オブジェクトの取り扱いの簡便化ため。
eventはdelegateの呼び出しの簡便化のため
443:デフォルトの名無しさん
06/01/02 14:27:27
>>438
つか比較すること自体が変だ。
delegateは型、eventはメンバ。class(型)とメンバの違いが分かりませんって
言われたってこっちが説明に困るよ。
444:440
06/01/02 23:54:45
>>441
そこらへんが答えだと思うんですが、まだよくわかりません。
>>442
＞eventはdelegateの呼び出しの簡便化のため
は
＞delegateはdelegateの呼び出しの簡便化のため
でもいいとおもうんです。eventなど持ち込まなくてもできると思うんです。
>>443
例えば、
public delegate void LogHandler(string message);
public event LogHandler Log;
を
public delegate void LogHandler(string message);
public LogHandler Log;
と書いても動くと思うんです。
まだ.NET初心者なのではずしてるかもしれませんが。
445:440
06/01/02 23:56:41
あ、上のコード例はC#です。
446:デフォルトの名無しさん
06/01/03 00:10:51
event がないと AddListner やら RemoveListner を自前で実装せにゃならんのさ
447:デフォルトの名無しさん
06/01/03 00:38:44
>>444
あー、イベントというものが根本的に分かってないんだろう。
メンバで表現されるものを他の言語と比較すりゃわかると思う。
CLRでのクラスメンバにもてるものはフィールド、メソッド、「プロパティ」、「イベント」なのよ。
後者二つがあることがいわゆるC#が「コンポーネント指向言語」っていわれる理由でも
あり、ただのdelegateフィールドとは「まったく」別のもの。
こうやって特殊化したことによってTypeDescriptorやらで動的にコンポーネント情報を取得できる。
ちなみに 446 も言ってるが、イベントはフィールドとアクセサ(とメタデータ)でなるんだな。
public event EventHandler TextChanged;
と書いたときに生成されるのは
・privateなdelegateフィールド
・publicなadd, removeアクセサメソッド。
・イベントメタデータ
を生成している。
448:440
06/01/03 00:42:44
＞＞４４６
delegateにも += や -= はあるです。
449:440
06/01/03 00:46:05
＞＞４４７さんありがとう
即答できないので、調べてみます。
450:デフォルトの名無しさん
06/01/03 00:57:18
>>448
delegate をそのまま公開しちゃうと呼び出しが外から出来てしまうのが問題なのよ
ここはC++/CLIのスレじゃ？
451:デフォルトの名無しさん
06/01/03 14:54:46
.NETって使ったことないからよく分からないんだけど、
一度コンパイルしたものを、同じセキュリティーやらなんやらの設定の場合は
キャッシュしておいたコンパイル済みのコードを再利用することって出来ないの？
毎回毎回、プロセス起動のたびにコンパイルしてるのってバカみたいじゃね？
452:デフォルトの名無しさん
06/01/03 15:02:06
キャッシュされるしngenもあるし
453:デフォルトの名無しさん
06/01/03 19:56:52
>>451ってバカみたいじゃね？
454:デフォルトの名無しさん
06/01/04 12:32:46
>>453
何だ、生意気だぞ。 (ﾌﾟﾝｽｶﾌﾟﾝ
455:デフォルトの名無しさん
06/01/07 13:19:01
プログラムのあちこちから大量にアクセスする文字列型を、
いちいちUnicode文字の配列からgcnewするのはもったいないと思って
あらかじめ生成しておいたSystem::Stringをグローバルに持つことで解決しようかと思いました。
が、普通にやったらコンパイラに怒られたので試行錯誤の結果以下のようにしてみました。
（StringDataはSystem::Stringを大量に生成して格納するクラス）
StringData^* gpStringData;
int main(array<System::String ^> ^args)
{
StringData^ stringData = gcnew StringData();
gpStringData = &stringData;
（以下メイン処理）
}
もうちょっと行儀のよさげな方法ないですかね？
456:デフォルトの名無しさん
06/01/07 13:55:09
こう？
value struct StringData {
initonly static String^ A = L"AAA";
initonly static String^ B = L"BBB";
initonly static String^ C = L"CCC";
};
int main()
{
String^ a = StringData::A;
String^ b = StringData::B;
return 0;
}
457:455
06/01/07 13:56:25
ごめんこのへん↓参考にして自己解決
URLﾘﾝｸ(www.microsoft.com)
458:455
06/01/07 14:07:15
>456
今回の場合は、こちらの方法のほうがよさげですね
ありがとうございます
459:デフォルトの名無しさん
06/01/09 01:03:13
何というか、変態的というか。まぁ、それがC++の良さではあったわけ
だけれど。これではあまりにもコンパイラベンダ泣かせだ…可哀想に。
460:デフォルトの名無しさん
06/01/09 07:55:52
C++/CLI をフルに実装できるコンパイラベンダって、
MS以外にあるのかね？
とか思ってたら、 g++ が対応したらかなり驚く。
mcs と合体するとか。
461:デフォルトの名無しさん
06/01/09 12:07:26
すいません。質問があります。libpng.libなどを利用した昔のライブラリをC++/CLIで使おうとしたら、
コンパイル時に
libpng.lib(pngerror.obj) : error LNK2019: 未解決の外部シンボル __iob が関数 _png_default_error で参照されました。
libpng.lib(pngrutil.obj) : error LNK2001: 外部シンボル "__iob" は未解決です。
とか言われました。C++/CLIって_iobが使えないんでしょうか？
どなたか解決方法をご存じの方、教えてください。
462:デフォルトの名無しさん
06/01/09 14:18:44
Cの標準ライブラリlinkしてる？
463:デフォルトの名無しさん
06/01/09 14:32:49
ECMA-372ってISOになるときに内容が変更される可能性とかある？
ECMAは規格書が公開されるからいいけどISOはｼｮﾎﾞｰﾝだからさ。
464:デフォルトの名無しさん
06/01/09 14:57:32
一応、mscoree.lib msvcrt.lib msvcrtd.libはリンクしています。
あと、重複とエラーがでるので、libcmt.libはリンク無視しています。
開発環境はVC++ 2005 Express+PlatFormSDKです。
Win32プロジェクトだとlibpng.libを含んでもコンパイルは通るのに、
CLRプロジェクト(C++/CLI)だとうまく行きません・・・
VC++ 2005のstdio.hに_iobが定義されていないのが問題なのでしょうか？
(関係ないかもしれないけど)
465:デフォルトの名無しさん
06/01/09 17:50:19
libpngをソースから作り直したほうが早いよ。
zlibとlibpngのソースをDLしてdswとかslnとかを開いてビルドするだけ。
やったらWindows フォームアプリのプロジェクトに問題なく使えた。
ml.exeがVCExpressにはないので$(MSVS8)\VC\binにコピーしておくこと。
466:デフォルトの名無しさん
06/01/09 18:49:06
ありがとうございます！
試してみます。
467:デフォルトの名無しさん
06/01/09 20:48:36
>463
ECMA から ISO に回された仕様書はただで公開しているよ
468:デフォルトの名無しさん
06/01/09 21:05:35
>>467
へぇ、ありがとう
469:デフォルトの名無しさん
06/01/19 07:08:22
value struct B
{
literal System::String^ var = L"abcd";
literal System::String^ var2 = var+L"1212";
};
var2でエラーが出るんだが...だめなのか。(整数型intとかだと大丈夫だったんだけど...)
リテラル データ メンバの初期化子は定数指揮でなければなりません
470:デフォルトの名無しさん
06/01/19 07:57:19
literal System::String^ var2 = var + "1212";
は確かにエラーになるね。俺も今確かめてみた。
literal System::String^ var2 = "abcd" + "1212";
これでも同じエラーになる。結局は + 演算子を呼んでるからだろうな。
literal System::String^ var2 = "abcd" "1212";
ならエラーにならなかった。
というわけで、マクロ使え。ってことだと思う。
471:469
06/01/19 09:37:44
>>470
literal System::String^ var2 = var;
でもだめみたい。
static ctorでの初期化が許容できるなら
literal -> static initonly に変更するか、マクロにするしかないですね...
URLﾘﾝｸ(msdn2.microsoft.com)(en-US,VS.80).aspx
472:デフォルトの名無しさん
06/01/19 11:48:55
ふむぅ initonly なんてのもあるのか。
ところで、Visual Studio 2005 いじってて思ったんだけど、
C# に比べりゃリファクタリングなんかの点で
C++/CLI は扱いにくいと思うんだよ。
なのでほとんどの部分は C# でかいてるんだけど、
どうしても C++/CLI で書きたい部分もある。
C++/CLI で書いたコードと C# で書いたコードの
相互連携って可能なのかな？
具体的には、技術関連の計算をやるC++の自作ライブラリ、
結構大規模なモノがすでにある。GUI をつけるために
今までは計算結果をバイナリファイルに落として、
それを C# で作った可視化ツールで読み込んでた。
だけどインタラクティブにしたいんで C++/CLI 使えば
いいかなと思ったんだが、今まで C# で作ったGUI部分と
C++で書いた計算部分は C++/CLI で結婚できるのかと。
473:デフォルトの名無しさん
06/01/19 12:08:38
C++の計算用DLLをC#から使えばいいだけじゃん
474:デフォルトの名無しさん
06/01/19 12:12:25
>>472
今までは C++ -> COM経由 -> C#
これからは C++ -> C++/CLI
.NETでは C++/CLI <=>C#
475:デフォルトの名無しさん
06/01/19 12:18:13
>>473 C++な計算ライブラリの方は、クラスへの参照を
受け取って処理結果をその中に返すんですが、それでも
可ですか？ソース提供が基本のライブラリだったんで、
DLL化とかはしてなかったんですが、試してみます。
476:デフォルトの名無しさん
06/01/19 12:26:53
>>475
refタイプでない普通のクラスはrefクラスでラップする必要がある。ダイレクトには渡せない。
477:デフォルトの名無しさん
06/01/19 13:41:47
>クラスへの参照を受け取って処理結果をその中に返す
可能だろ。
478:デフォルトの名無しさん
06/01/22 14:20:10
参照クラスを値クラスに変換する
template等は用意されているのでしょうか？
479:デフォルトの名無しさん
06/01/26 10:52:47
ｷｲﾀ?( ﾟдﾟ)ｵｸｻﾝ(ﾟдﾟ )ｱﾗﾔﾀﾞﾜｧ
480:デフォルトの名無しさん
06/01/29 18:09:11
C++/CLI が次の VS まで生き残ってるか、かなり不安。
とはいえ、C++/CLI を結構使ってるけど。
481:デフォルトの名無しさん
06/01/29 19:45:25
C#→C++への変換ってできんの？
482:デフォルトの名無しさん
06/01/29 19:50:24
そりゃいくら何でも無理だろ。
483:デフォルトの名無しさん
06/01/29 20:27:13
>>481
ｺﾝﾊﾟｲﾙ→.net reflector
484:デフォルトの名無しさん
06/01/29 21:01:45
cli_class<T>::m_member' : 指定されたメンバは初期化できません。
というエラーが出るのですが、m_memberをコピーするにはどうしたらいいのでしょうか？
generic <typename T> ref struct cli_class
{
T m_member;
cli_class(const cli_class% n)
:m_member(n.m_member) //error
{}
};
485:デフォルトの名無しさん
06/01/29 23:25:35
generic <typename T> where T : System::ICloneable ref struct cli_class
{
T m_member;
cli_class(const cli_class% n)
//:m_member(n.m_member) //error
{
if ( n.m_member != nullptr )
m_member = safe_cast<T>(n.m_member->Clone());
}
};
こうかな？自信ないけど。
486:デフォルトの名無しさん
06/01/30 11:48:01
二項演算子で単項で使われていなかったものオンパレードですね
487:デフォルトの名無しさん
06/01/30 13:02:57
cli_class が確定してなくね？
generic <typename T> ref struct cli_class
{
T m_member;
cli_class()
{}
cli_class(cli_class<T>% n)
:m_member(n.m_member) //error
{}
};
const 付けると、型パラメータも影響を受けてキャストできなくなるから
const 外した
488:デフォルトの名無しさん
06/01/31 17:35:17
GCC の仲間に C++/CLI コンパイラが仲間入りする日が
いつかやってくると思う人、いる？
489:デフォルトの名無しさん
06/01/31 17:51:54
ﾉｼ Java もコンパイルできてるんだから、CLI抜きでやっちゃいそうな気がする
490:デフォルトの名無しさん
06/01/31 18:02:27
>>489
おまい、それ普通のgcc。
491:デフォルトの名無しさん
06/01/31 18:09:14
mingwで構造化例外って実装されてるの?
492:484
06/01/31 18:49:53
>>487
なるほどconstはずしたらできました。
ありがとうございました。
493:デフォルトの名無しさん
06/01/31 19:34:10
>490
ああ、実行エンジン無しで作っちゃいそうな気がするってこと
494:デフォルトの名無しさん
06/02/01 00:17:29
CLRのこと?
495:デフォルトの名無しさん
06/02/01 06:59:47
ランタイムはコンパイラコレクションが
提供しなくてもいいんじゃない？
496:デフォルトの名無しさん
06/02/01 08:47:44
GCC で CIL を出力するだけじゃ意味がないから、exe を実行するときバインドするの実行
エンジンはCLR か mono に頼るの？
497:デフォルトの名無しさん
06/02/01 09:02:05
>>496 そうなるだろうなぁ。
mono の mcs の方が C++/CLI コンパイルできるように・・・
ならないだろうな。
mono ではすでに ASP.NET はいい感じで動いてるんだったっけ？
Java の牙城をちょっとは切り崩すことが出来る、のかな？
って、Webアプリケーションは PHP でしか書いたこと無いんだけど。
498:デフォルトの名無しさん
06/02/01 09:55:46
monoって実行ファイル起動時に外部エンジンにアタッチしてやりとりできるいい仕組みって
ある？ Java の JNI で C/C++ から VM 叩くようなヤシ
499:デフォルトの名無しさん
06/02/01 10:32:17
DLL の呼び出しと同じ仕組みが使えた気がする。
以前、コンソールアプリをポータブルに作ろうと思って、
ncurses ライブラリを使って C# コンソールアプリを作った。
ncurses の DLL を C# から呼び出すようにして。
それは Visual Studio .NET 2003 で作成。
で、ncurses の共有ライブラリが入ってる Debian に、
VS でコンパイルした *.exe をそのまま持って行って、
何も考えずに mono で実行したらちゃんと libncurses.so
とかその辺をダイナミックリンクしてくれてあっさり動いた。
500:デフォルトの名無しさん
06/02/01 10:34:03
ｽﾚﾘﾝｸ(tech板:21番)
の兄弟の片割れが漏れなんだが(もう一人は誰か知らん)
その詳細なリポートを書いた mono の前スレが見れん。
501:デフォルトの名無しさん
06/02/01 10:34:53
それはそうと、JNIって「C/C++ から VM 叩くようなヤシ」か？
漏れ JNI は使ったことないんだけど、逆じゃね？
502:デフォルトの名無しさん
06/02/01 10:38:03
つーわけで、CLI からは DLL と同じように so が呼び出せると思う。
かなりオープンというか、なんというか・・・
503:デフォルトの名無しさん
06/02/01 10:59:04
連投ごめん。リンク間違えた。
ｽﾚﾘﾝｸ(tech板:21番) ね。
504:デフォルトの名無しさん
06/02/01 13:05:25
>501
JNI は Java からの C 呼び出しと、C/C++ からの JVM 呼び出しの両方を規定してるお
505:デフォルトの名無しさん
06/02/01 13:14:26
>>501 お、そうか。スマンコ
ネイティブコードからの呼び出しは正直シランコ
506:デフォルトの名無しさん
06/02/03 09:47:25
ええっと、長年Cオンリーでやってきたロートルなんですが、
新しい（？）ポインタの^に関して、詳しく解説した書籍とかありませんでしょうか？
char型の文字列は 文字が１文字ずつ入っていって、最後が\0になっているという、
アセンブラレベルからするととてもわかりやすいものだったのですが、
String^ s = "0123456789" が、メモリ上にどの用に格納されるのか
さらに、この文字列に対して、
char c,*p ;
p=s;
c = *(p+10);
といった、従来のメモリ上のキッタハッタが出来なくなってきているのは、どういう仕組みなのか
を理解したいのですが。
507:デフォルトの名無しさん
06/02/03 10:18:32
managedなだけよ
508:デフォルトの名無しさん
06/02/03 10:43:00
>>506
JavaやLispやCLIの実行環境がどうなっているか調べろ。
509:デフォルトの名無しさん
06/02/03 12:53:41
>>508
それを詳しく解説した書籍とかを訊いてんだよ、ボケが。
510:デフォルトの名無しさん
06/02/03 13:02:48
そんな怒らないでよ(w
これ読みなよ、日本語はいいのがないから。
Shared Source Cli Essentials
URLﾘﾝｸ(www.amazon.co.jp)
511:デフォルトの名無しさん
06/02/03 15:55:01
>>506
C++のclassは理解してますか？
class objectを指すポインタと思えばよいかと。
512:デフォルトの名無しさん
06/02/03 19:54:02
template引数を使おうとしたらエラーが出るのですが、何がいけないのでしょうか？
ref struct F{//FNの引数にしようかなと
int operator()(int a){return a;}
};
generic <typename FN> ref struct Fn{
void test(){
FN fn;
fn.operator ()(100);// : error C2039: '()' : 'System::Object' のメンバではありません。
}
};
513:512
06/02/03 20:13:31
generic -> template
にしたら通りました。
generic の typename は Object前提になるのかな
514:512
06/02/03 20:24:11
Reflectorでみてみたら
generic で宣言した方はパラーメータが残ってた、 class_name<T>
TはObjectを想定してるので、パラメータが残せてるんかな...
templateの方はパラメータが固定されてた -> class_name<int>
515:デフォルトの名無しさん
06/02/03 23:42:54
単に、マネージドとネイティブの混合型になるから駄目なだけ
516:デフォルトの名無しさん
06/02/03 23:44:42
>515 は違った。genericsは背景型が System::Object型であることを前提としており、
コンパイル時では閉じない限り、型が確定しない
そこら辺が、文字列置き換えの template とは性質が違う
517:512
06/02/04 02:33:08
>>516
なるほどなっとくしました。
ありがとうございました。
System::Collections::Generic::IEnumerator<T>
などでcovariant return valueが発生したときはどうしたらいいん...orz
518:デフォルトの名無しさん
06/02/04 02:45:42
つーか、512よ。インターフェイスで拘束されているわけでもない不定の FN 型の fn
のメソッドが呼び出せるわけないだろ？
>517 は具体的な例でしてくれないと状況がわからん
519:512
06/02/04 13:45:57
>>518
すいません。ファンクタのconvariantなケースでなくて、
C++/CLIで一般に遭遇した場合という意味です。
以下のような感じでやってみたのですが、インターフェイスの実装ができませんでした。
他言語だとどうなるのか調べんとだめかな...
//NG
typedef String^ MyType;
typedef System::Collections::Generic::IEnumerator<MyType> MyEnumeratorType;
typedef System::Collections::Generic::IEnumerable<MyType> MyEnumerableType;
//OK
//typedef Object^ MyType;
//typedef System::Collections::IEnumerator MyEnumeratorType;
//typedef System::Collections::IEnumerable MyEnumerableType;
ref struct MyTest :public MyEnumerableType
{
ref struct MyEnumerator : public MyEnumeratorType
{
virtual property MyType Current { MyType get () { return nullptr; } }
virtual bool MoveNext(){ return false; }
virtual void Reset(){}
};
virtual MyEnumeratorType^ GetEnumerator() { return gcnew MyEnumerator();}
};
520:519
06/02/04 15:03:57
private: virtual Object^ System::Collections::IEnumerator::Current { Object^ get() sealed {return nullptr;} }
という風にC#を真似てみたけどだめみたいでした。
以下はC#でのサンプル
class MyTest :System.Collections.Generic.IEnumerable<string>
{
class MyEnumerator :System.Collections.Generic.IEnumerator<string>
{
public virtual string Current { get { return null; } }
public virtual bool MoveNext(){ return false; }
public virtual void Reset(){}
public virtual void Dispose(){}
object System.Collections.IEnumerator.Current { get { return null; } }
};
public virtual System.Collections.Generic.IEnumerator<string> GetEnumerator(){ return new MyEnumerator();}
System.Collections.IEnumerator System.Collections.IEnumerable.GetEnumerator() { return new MyEnumerator(); }
};
521:519
06/02/04 16:15:08
covariant return value の場合、２段階で実装すればなんとか可能でした。
ref struct MyTestBase :public System::Collections::IEnumerable
{
ref struct MyEnumeratorBase :public System::Collections::IEnumerator
{
virtual property Object^ Current { Object^ get () { return nullptr; } }
virtual bool MoveNext(){ return false; }
virtual void Reset(){}
};
virtual System::Collections::IEnumerator^ GetEnumerator() { return gcnew MyEnumeratorBase();}
};
ref struct MyTest :public MyTestBase,System::Collections::Generic::IEnumerable<String^>
{
ref struct MyEnumerator:public MyEnumeratorBase,public System::Collections::Generic::IEnumerator<String^>
{
virtual property String^ Current { String^ get() new {return nullptr;} }
virtual ~MyEnumerator(){}
};
virtual System::Collections::Generic::IEnumerator<String^>^ GetEnumerator() new {return gcnew MyEnumerator();}
};
522:デフォルトの名無しさん
06/02/04 18:01:17
managed C++ やろうぜ！！ 002
ｽﾚﾘﾝｸ(tech板)l50
523:デフォルトの名無しさん
06/02/04 18:07:52
ref classのメソッドでEnumWindowsを使おうとしてます
コールバック関数をクラスのメソッド、LPARAMをこのクラスのポインタとしたいのですが
いい方法はありますでしょうか?
524:519
06/02/04 21:59:53
値型だとインターフェイスからしか派生できないから
521の手法使えないね...orz
値型なら
Type<int,Type<int,int> >と記述できたのに
Type<int,Type<int,int>^ > または Type<int,Type<int,int>^ >^
とするしかないか...orz
525:デフォルトの名無しさん
06/02/04 22:31:14
>>523
P/Invokeの場合にはcallbackにはdelegateを使うんだっけな。
C++/CLIの場合はコールバック用のクラスとメソッドは普通のclassで作って
ref classに包含したほうが楽だ。
526:デフォルトの名無しさん
06/02/04 22:33:29
>523
過去ログにがいしゅつ
527:523
06/02/04 23:47:58
>>525
ありがとうございます
チャレンジしてみます。
528:523
06/02/05 02:31:27
delegateとコールバックで検索したら見つかりました
URLﾘﾝｸ(www.microsoft.com)
529:デフォルトの名無しさん
06/02/05 19:43:18
generic parameterからgcnewできないと思ったら
new制約なんてあったんだね。
C#にあるみたいなんで試してみたらできたよ。
generic <typename T>where T : gcnew()
ref class A
{A(){ T t = gcnew T();}};
530:デフォルトの名無しさん
06/02/05 23:48:54
System.Windows.Forms.ShowDialog()をした時にタスクバーに
Windowが追加されちゃいます
タスクバーに出てこない方法ってりますか?
531:デフォルトの名無しさん
06/02/06 00:31:03
>>530
ShowInTaskbar
532:デフォルトの名無しさん
06/02/06 01:08:43
>>531
さんくす！
533:デフォルトの名無しさん
06/02/06 01:41:27
C++ﾌﾟﾛｸﾞﾗﾏｰには二種類いるわけ。
C++をﾍﾞﾀｰCとして使う人とC++の機能を目一杯使う人。
俺はﾍﾞﾀｰC派なんだな。
C++の機能は必要最小限しか使わない。
特に枯れてない最新技術はまず使わない。
そして必ずGCをかます。
これは俺というよりも会社の方針なんだわ。
実の所、C++を完璧に使いこなせるPGはほとんどいない。
皆、言語の一角に住み着いてﾌﾟﾛｸﾞﾗﾐﾝｸﾞする。
これが大規模な開発になるとﾃﾞｽﾏの原因になるんだな。
ﾃﾞｽﾏを防ぐためにあえて制限を設ける。
俺は会社の方針は正しいと思っている。
534:デフォルトの名無しさん
06/02/06 03:45:59
C++/CLIだと値クラスのプロパティとインデクサををref化できるね。
C#ではやり方が悪いのかできなかった。言語思想が違うためだろうか
これができないとインデクサで変更を扱う値型のコンテナが作れない気がするんだが...
value struct Val{int val;};
value struct Test
{
void test(){ Test test;test[100].myt.val=200;Console::WriteLine(test.myt.val); }
Val myt;
property Val% default[int]{ Val% get(int index){ return myt; } }
};
535:デフォルトの名無しさん
06/02/06 09:34:19
sage
536:デフォルトの名無しさん
06/02/06 12:59:49
Equals を使うな。使う事を推奨するな。
URLﾘﾝｸ(www.ailight.jp) ...
537:デフォルトの名無しさん
06/02/06 15:53:01
>>536
リンク修正
URLﾘﾝｸ(www.ailight.jp)
URLﾘﾝｸ(www.ailight.jp)
538:デフォルトの名無しさん
06/02/06 16:16:06
ようするにさらし上げ?
539:デフォルトの名無しさん
06/02/06 17:05:29
>>534
setするほうのプロパティを作ればよいだけではないのか?
540:534
06/02/06 19:13:17
>>539
それだとプロパティへの代入はできるけど、プロパティを介する変更ができないと思う。
Val%をValに変更してsetをつけても、test[100].val=200;だと変更できない
Val tmp;tmp.val=200; test[100]=tmp; なら変更可能だけど...
問題なさそうで問題あるケース
generic <typename T1,typename T2> value struct M
{T2 myt;
property T2% default[T1]{
T2% get(T1 t1) { return myt; }
void set(T1 t1,T2% val){myt = val;}}
};
T2%だと M<int,M<int,int>> m; int i=100; m[100][100]=i; //と書ける //ただ変数にしないといけない難点が...
T2だと m[100][100]=100;と書けるが変更できない
541:デフォルトの名無しさん
06/02/06 19:53:28
海外の大御所がある雑誌で言った。
「私はもう二度と .Net の記事を書かない。」
マイクロソフトにだまされてる奴ら、お疲れ。
542:デフォルトの名無しさん
06/02/06 20:05:34
>>541
大御所が誰だか教えて
543:デフォルトの名無しさん
06/02/06 20:13:56
プラウガもC++/CLIやってるけどな。
URLﾘﾝｸ(www.dinkumware.com)
やつらはVC++用ライブラリにたずさわっているし、
C++/CLIはEMCAの標準化に関与しているから。
まあC++/CLIはいい言語拡張と思わないけれど、
managed C++の将来のなさには流石に脱帽。
544:デフォルトの名無しさん
06/02/06 20:33:14
将来も何もmanaged C++はC++/CLIまでの暫定版なんだから、
managed C++の将来はC++/CLIじゃないか。
managed C++は OldSyntaxだべさ。
545:デフォルトの名無しさん
06/02/06 20:39:32
どれかひとつ選ばなければならないとしたら不本意ながらC++/CLIを選ぶしかないわな。
546:デフォルトの名無しさん
06/02/06 20:46:22
レヴューリリースだわな、managed C++は。
547:デフォルトの名無しさん
06/02/06 20:49:30
正直、記憶力がおいつかない。
548:デフォルトの名無しさん
06/02/06 20:55:37
でも、サービスパックも出てない VisualStudioを使うほどバカじゃなし。
MS製以外でコンパイル通るヤツってある?
549:デフォルトの名無しさん
06/02/06 23:39:31
>>548
無いよ。バカ
550:デフォルトの名無しさん
06/02/07 00:04:25
バカじゃん
551:デフォルトの名無しさん
06/02/07 01:01:12
おまえら、VS2005マジで使うの? バカじゃん。
すでに、MSはSP出荷を確約してるんだぞ。
552:デフォルトの名無しさん
06/02/07 01:44:04
>>551
じーっと枯れるのまってろこのうすらタコ！
553:デフォルトの名無しさん
06/02/07 02:14:49
>>548
VB6でも使っとけよ wwww
554:デフォルトの名無しさん
06/02/07 02:41:12
>>552
N88 BASIC
555:デフォルトの名無しさん
06/02/07 10:21:32
バカが3匹。
556:デフォルトの名無しさん
06/02/07 10:51:33
Win32コンソールアプリケーションの
int _tmain(int argc, _TCHAR* argv[])
は
int main(int argc, char* argv[])
にしちゃいますけど。いいですよね？引数がアルファとかヌメリックなら。
557:デフォルトの名無しさん
06/02/07 11:32:34
漏れは
int main(const int argc, const char* const argv[])
558:デフォルトの名無しさん
06/02/07 13:00:33
>>557
そこまでいくなら戻り値もconstにしてはどうか？
559:デフォルトの名無しさん
06/02/07 13:21:59
>>558 参照返しじゃないから意味なし。
560:558
06/02/07 13:27:44
>>559
ああ、確かに意味は無いなｗ
でも、argcもconstにしてるけど、これも意味が無いから、
それをさらに徹底させるって意味で返り値もconstにすればいいのにー
っと思っただけ
561:デフォルトの名無しさん
06/02/07 14:04:04
argcの場合、意義はともかくプログラム上の意味が変わる。
562:デフォルトの名無しさん
06/02/07 14:21:19
うっかり書き換えるとコンパイラにゴルァされるとか
563:558
06/02/07 14:26:48
確かに関数内では意味が変わる...か。
関数のオーバーロードでは同一視されるから一緒と思ってたけど、
内部の事は忘れてた。thanks
564:デフォルトの名無しさん
06/02/07 15:01:05
>>558 お前素直な奴だな
565:デフォルトの名無しさん
06/02/08 00:54:04
そこでconst_castの登場だな
566:デフォルトの名無しさん
06/02/08 18:26:06
全部ILで書こうぜ
567:デフォルトの名無しさん
06/02/08 19:24:23
遅いからヤダよ。
568:デフォルトの名無しさん
06/02/09 01:52:44
STL/CLIお蔵入り
569:デフォルトの名無しさん
06/02/09 04:28:08
固定長配列はcli::array以外に用意されてない？
570:デフォルトの名無しさん
06/02/09 11:58:31
>568
STL.NETは別途配布されるんじゃなかったの？
571:デフォルトの名無しさん
06/02/09 12:38:09
BOOST.NETも出たりとか。
正直大混乱。
572:デフォルトの名無しさん
06/02/09 13:44:43
正直いってWinXPのSP2入れたくないからとかいう理由で
SP1を使ってる馬鹿と同レベルの理屈だな
新しいものの方がいいに決まってる。たとえバグ込みでも
長い目で見れば将来性の高いほうを選択する方がよい
573:デフォルトの名無しさん
06/02/09 17:47:52
>>571
BOOST.NETって何？そんなんあんの？
574:デフォルトの名無しさん
06/02/09 22:47:44
>>572
その将来性のおかげで、君の部下が次々と止めていくんだがどう責任取るのかね?
575:デフォルトの名無しさん
06/02/10 21:58:53
値型にデフォルトコンストラクタと代入演算子を定義できる
.NET言語ってあるんかな？
576:デフォルトの名無しさん
06/02/10 22:01:31
フレームワーク内のprivateないくつかの構造体を見ると、
デフォルトコンストラクタ使ってるのがいくつかあるな。
Win32関係の構造体で自分のサイズを設定してるんだが。
577:デフォルトの名無しさん
06/02/10 22:20:02
>>575
つIL (ilasm)
まぁぶっちゃけいらないっていうかあってもまずやっちゃいけないしな
578:575
06/02/10 23:53:50
>>576,577
どうも
Reflectorでみてみたら
staticコンストラクタで代用しているのはありました。
こんな感じで試してみようかな...
URLﾘﾝｸ(www.gdncom.jp)