- 1 名前：デフォルトの名無しさん [2005/09/11(日) 23:54:01 ]
- おそらく、.NET開発でデファクトスタンダードに最も近い
であろうC++/CLIについて語ろうぜ！
- 272 名前：デフォルトの名無しさん mailto:sage [2005/12/04(日) 20:56:43 ]
- 関係ないが、親玉格のC(99)がやらかしてくれてるからなあ。
- 273 名前：デフォルトの名無しさん mailto:sage [2005/12/04(日) 21:15:11 ]
- C++はまだ「生きた」言語なんだよ。
まだまだ進化する。
- 274 名前：デフォルトの名無しさん mailto:sage [2005/12/04(日) 21:41:25 ]
- ここに書いて良いのかわからんかったんですが。
タスクマネージャーの「CPU使用率の履歴」みたいな動的な(?)グラフを出せるものを書きたいのですが
何から手をつければいいのか、全くわかりません。
アドバイスよろしくお願いします。
- 275 名前：デフォルトの名無しさん [2005/12/04(日) 21:46:55 ]
- age
- 276 名前：デフォルトの名無しさん mailto:sage [2005/12/04(日) 22:13:21 ]
- >>274
とりあえず↓この本読め。
www.amazon.co.jp/exec/obidos/ASIN/4872331265/qid=1133701895/sr=1-1/ref=sr_1_10_1/249-6035794-3226728
- 277 名前：デフォルトの名無しさん [2005/12/05(月) 09:58:09 ]
- >>272
C99のマズイところでどんなとこ？
得に思い当たらないんだけど
- 278 名前：デフォルトの名無しさん mailto:sage [2005/12/05(月) 11:34:16 ]
- エラーのthrow/catchが、cとc++で別になったのは痛い。
MFCとC++、C丼とC++、MC++とC++、C++CLIとC++、それぞれ結局別物と思われてるところも痛いけど。
- 279 名前：デフォルトの名無しさん mailto:sage [2005/12/05(月) 11:43:35 ]
- 実際別物
- 280 名前：デフォルトの名無しさん mailto:sage [2005/12/05(月) 15:13:07 ]
- MFCを持ち出してくるところが痛い。
- 281 名前：デフォルトの名無しさん mailto:sage [2005/12/05(月) 15:30:50 ]
- MFCって、mc++とかC++/CLIから使えるんだっけか？
- 282 名前：デフォルトの名無しさん mailto:sage [2005/12/05(月) 18:32:19 ]
- C++/CLIやmc++の構文を使ってないコードを /clrでコンパイルしたものを
C++/CLIやmc++のプログラムと読んでいいかどうかによるけど、
そう呼んでいいなら使える。
- 283 名前：デフォルトの名無しさん mailto:sage [2005/12/05(月) 18:41:23 ]
- managed と unmanagedの型でデータ交換したいのですが、
COMを使うしかないのでしょうか？
- 284 名前：デフォルトの名無しさん mailto:sage [2005/12/05(月) 19:07:05 ]
- >>283
具体例を挙げてわかるように質問してくれ。
- 285 名前：デフォルトの名無しさん mailto:sage [2005/12/05(月) 19:10:17 ]
- ＞/clrでコンパイルしたものを
どういったオプションでつか？
- 286 名前：283 mailto:sage [2005/12/05(月) 19:33:39 ]
- >>284
混合クラスにできないだけで、
別クラスにしておいて呼び出しは可能だったのね...
Marshalingできる時はしたほうがいいのかな
ttp://msdn2.microsoft.com/library/ms235282(en-US,VS.80).aspx
- 287 名前：修正 mailto:sage [2005/12/05(月) 21:25:49 ]
- unmanagedからmanagedの呼び出しはできないみたい。
- 288 名前：デフォルトの名無しさん mailto:sage [2005/12/05(月) 22:45:23 ]
- CLRホスティング・・・
- 289 名前：デフォルトの名無しさん mailto:sage [2005/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 名前：デフォルトの名無しさん mailto:sage [2005/12/06(火) 07:34:09 ]
- 最強
- 291 名前：デフォルトの名無しさん mailto:sage [2005/12/06(火) 10:52:01 ]
- unko
- 292 名前：デフォルトの名無しさん [2005/12/07(水) 23:15:01 ]
- C++/CLIの存在意義って？
マネージならC#でよくね？
- 293 名前：マイク ◆yrBrqfF1Ew mailto:sage [2005/12/07(水) 23:19:32 ]
- そうだな。
- 294 名前：デフォルトの名無しさん mailto:sage [2005/12/08(木) 00:28:08 ]
- やっぱりC#?
C++から移植するのってどれぐらい工数かかるんだろうか・・・・
- 295 名前：デフォルトの名無しさん [2005/12/08(木) 00:32:04 ]
- ぶっちゃけ、WindowsアプリならVC++6&MFCが最強では？
あえてC#を覚えようとする気がしない。
VC++6&MFCでつれないWindowsアプリはない。
- 296 名前：デフォルトの名無しさん mailto:sage [2005/12/08(木) 00:39:03 ]
- かわいそうな人
- 297 名前：デフォルトの名無しさん mailto:sage [2005/12/08(木) 01:10:46 ]
- あえてCを覚えようという気がしない。
機械語で作れないwindowsアプリはない。
- 298 名前：デフォルトの名無しさん mailto:sage [2005/12/08(木) 01:24:49 ]
- あえて計算機を覚えようという気がしない。
脳内で計算できない問題はない。
- 299 名前：デフォルトの名無しさん mailto:sage [2005/12/08(木) 06:10:14 ]
- 切り返すなら同じ性質の物事を書かなきゃ :-P
- 300 名前：デフォルトの名無しさん [2005/12/08(木) 08:16:12 ]
- >>297
俺も未だに機械語で書いてるよ
Cだとおせーから嫌だ
- 301 名前：デフォルトの名無しさん mailto:sage [2005/12/08(木) 08:28:05 ]
- >>295
なるほど、いろんなWindowsアプリさんたちが釣れるようでつね。
- 302 名前：デフォルトの名無しさん mailto:sage [2005/12/08(木) 11:44:15 ]
- >>295はLonghornが出たら干される使い捨てデジドカ
- 303 名前：デフォルトの名無しさん [2005/12/08(木) 20:59:47 ]
- OSが記述できてしまう
C++は絶対に廃れないよ
しかも、デバイスドライバを書ける人は絶対に不可欠
C#やJAVAなんてモノが出来ても結局また
新たな言語が出てきて廃れるのは必至
- 304 名前：デフォルトの名無しさん mailto:sage [2005/12/08(木) 21:14:47 ]
- つまりCOBOLと似たようなもんだ。
新しい言語の出現で全盛期より減ったとは言え、需要がなくなることはありえない。
- 305 名前：デフォルトの名無しさん mailto:sage [2005/12/08(木) 21:44:19 ]
- 歩く死体か。
- 306 名前：デフォルトの名無しさん mailto:sage [2005/12/09(金) 02:03:11 ]
- Cで必要にして十分な件。
- 307 名前：デフォルトの名無しさん mailto:sage [2005/12/09(金) 11:02:38 ]
- 既存のプログラムが全部マネージ環境で通るようにライブラリとか
整えて欲しい。
printfやstrcmp使うとネイティブとの混合アプリになっちゃうんでしょ？
標準ライブラリの中も.NETにすりゃあいいのに。
- 308 名前：デフォルトの名無しさん mailto:sage [2005/12/09(金) 11:24:49 ]
- 混合になってなんかマズイことでもあるのかい？
- 309 名前：デフォルトの名無しさん mailto:sage [2005/12/09(金) 13:12:07 ]
- >>307
あなたは根本的にCLIの世界を理解してないです。
- 310 名前：デフォルトの名無しさん mailto:sage [2005/12/09(金) 16:26:18 ]
- >>308
混合だとWin以外に持っていけるの？（あるかはしらんけど）
あと、切り替え時に異様に遅い感触。
>>309
根本を教えてくれ
- 311 名前：デフォルトの名無しさん mailto:sage [2005/12/09(金) 16:43:46 ]
- 感触って君の思い込みのこと?
- 312 名前：デフォルトの名無しさん mailto:sage [2005/12/09(金) 16:53:06 ]
- >>311
/clrつけてコンパイルしなおしたプログラムが異様に遅い。
.NETにしてもちょっと遅すぎると思ってね。原因がネイティブ
部分の呼び出し負荷くらいしか思い当たらない。
- 313 名前：310 mailto:sage [2005/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 mailto:sage [2005/12/09(金) 17:42:54 ]
- >>313の例ではネイティブへの切り替え以外に負荷になる要素は
無いと思うんだが、識者の意見希望。
- 315 名前：デフォルトの名無しさん mailto:sage [2005/12/09(金) 18:51:09 ]
- 関数の処理が遅いのか、CLR の起動に手間取っているのかは、ちゃんと分けた？
- 316 名前：310 mailto:sage [2005/12/09(金) 19:01:59 ]
- >>315
my_stricmpを使ってネイティブと時間の差が無いのだから、
起動時間の問題じゃないと思う。
あと、ループの回数を増減させれば処理時間も比例する。
- 317 名前：デフォルトの名無しさん mailto:sage [2005/12/09(金) 20:03:25 ]
- >>313
strcmpは？stricmpだとCLIの方はロケールとかで色々面倒くさい
ことしてそう。
- 318 名前：デフォルトの名無しさん mailto:sage [2005/12/09(金) 20:56:41 ]
- >>313
ではlstrcmpはどう？
これなら絶対にインライン展開できない。
- 319 名前：310 mailto:sage [2005/12/09(金) 21:15:00 ]
- >>318
lstrcmp,これから試してみるけど先に質問。
>>317に関して、
俺、やはり根本が分かって無い模様。strcmpは313に書いた通りなのだが、
stricmpの場合でも、CLIからネイティブと同じルーチンが呼ばれるもんだと
思っていた。
この前提で、中身が一緒なら呼び出してる部分に負荷があるんじゃないかと
思っていたわけだが、ネイティブとCLIで呼び出されるstricmp（に限らず標準
ライブラリ全般）は別物なの？
- 320 名前：デフォルトの名無しさん mailto:sage [2005/12/09(金) 22:17:02 ]
- >>319
その試した見たというコードをどこかのアップローダに晒すというのは
どうだい？そうすれば同じ土俵で話ができる。
- 321 名前：310 mailto:sage [2005/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 名前：デフォルトの名無しさん mailto:sage [2005/12/09(金) 22:55:34 ]
- アセンブリ（アプリケーション）で閉じてる範囲に置いては、CLIはロードされないんじゃね？
- 323 名前：310 mailto:sage [2005/12/09(金) 23:02:41 ]
- >>322
意味が分かりませんorz
- 324 名前：デフォルトの名無しさん mailto:sage [2005/12/09(金) 23:06:31 ]
- >>321
> つーことはやはり呼び出し負荷でしょう。
それ言うなら、
> もちろんループ回数も同じで測定している。
回数変えてファクターが何か調べないと。面白い奴だな(w
- 325 名前：310 mailto:sage [2005/12/09(金) 23:10:53 ]
- >>324
回数変えたら実行秒数が比例するけど。
my_stricmpにしてネイティブと差が無いわけだから、違いは
標準ライブラリの呼び出し以外に何か考えられる？
- 326 名前：デフォルトの名無しさん mailto:sage [2005/12/09(金) 23:20:29 ]
- y = ax + b の a を比べろと言えば分かりますか?
- 327 名前：310 mailto:sage [2005/12/09(金) 23:27:29 ]
- >>326
何を言ってるのか分かりませんが、
具体的に他にファクターがあるならあげてみて欲しい。
こちらの比べ方に抜けがあるならそこを指摘してくれまいか。
- 328 名前：デフォルトの名無しさん mailto:sage [2005/12/09(金) 23:31:27 ]
- ちょっと、煽りと神経質になってる人もいるみたい
まぁ、とりあえず、時間の出たマシンのスペックを教えてちょ
問題になっているのは、msvcm80.dll 辺りかな
- 329 名前：デフォルトの名無しさん mailto:sage [2005/12/09(金) 23:54:07 ]
- 回数を2倍にしても実行時間が2倍になるとは限らない。
325に比例するとは書いてあるけど、比例にもいろいろあるだろうに。
- 330 名前：デフォルトの名無しさん mailto:sage [2005/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 名前：デフォルトの名無しさん mailto:sage [2005/12/10(土) 00:19:19 ]
- ﾜﾗ
- 332 名前：デフォルトの名無しさん mailto:sage [2005/12/10(土) 00:28:24 ]
- まるで見当はずれかもしれませんが
int mycomp(,,,) の前に #pragma unmanaged を置いてみるとどうなりますかね？
- 333 名前：330 mailto:sage [2005/12/10(土) 00:53:42 ]
- ごめん。これは速度が違って当たり前だった。ろくにチェックしていない
before をちゃんとチェックすると、だいたい１６秒でstrcmpと変わらない
むしろ、ネイティブだと一瞬なんで、処理に時間がかかる理由が気になる
- 334 名前：330 mailto:sage [2005/12/10(土) 01:08:50 ]
- すまん。>>333 は元の関数のコメントアウトをしてなかったorz
mycompにすると一瞬で終わるね。もうちょっと、関数の実装をちゃんとするべきなんだろうけど
ネイティブに記述された関数はネイティブで処理されてる。となると、C標準関数が問題
なのか・・・
- 335 名前：310 mailto:sage [2005/12/10(土) 08:50:45 ]
- >>329
＞回数を2倍にしても実行時間が2倍になるとは限らない。
それは比例じゃないと思うけど。
言葉どおり比例と受け取って欲しい。
だからループ外のファクターでは無いと思う。
>>334
マシンの速度が分からないけど、200万回のループで１６秒もかかる？
あと、strcmpだとこちらではCLIでもネイティブと同じだった。
stricmp,lstrcmpで、ネイティブとの差が2億回のループで10秒。
差が同じなので、処理内容の問題でも無いと思う。
こちらのマシン速度は>>313です。
- 336 名前：310 mailto:sage [2005/12/10(土) 10:00:02 ]
- >>329
言葉が足んなかった、すまん。ax+bのbの部分はごく小さいと思って欲しい。
>>332
試してみた。
CLIでmy_stricmpをunmanagedプラグマで囲ったら、少しだけ遅くなった（３秒くらい）。
囲わなかった場合、今朝計り直してみたら１秒未満。
- 337 名前：デフォルトの名無しさん mailto:sage [2005/12/10(土) 10:26:32 ]
- 「思って欲しい」(w ってんじゃなくて、普通は i<2000000 だけじゃなく、
i<500000、i<1000000、i<2500000も取ってグラフをプロットするわけ。
あと、*cmp("abcdefghijklmnopqrstuvwxyz", "abcdefghijklmnopqrstuvwxyz")と、
*cmp("buffer", "Test")で比較するとかさ。
関数呼び出しのオーバーヘッドをみたいなら、
関数内の処理を軽くしたり重くしたりして違いを見るのが定席だろ?
strcmpとmycompじゃ実装が全然違うわけだから、そのくらいはしないと、
呼び出しがオーバーヘッドになっているかどうか分からない。
一文字目の比較で関数が返るから、関数呼び出しの差を見えると思ったかもしれないが、
ソースのない方はもしかしたらNULLチェックしているかもしれないし、
タコなコーディングかもしれない。
分からないはずなのに安易に結論づけているから、スルーされてる。
表計算ソフト、数式処理ソフト、グラフプロットツールあれば簡単にグラフ化できるよね。
- 338 名前：デフォルトの名無しさん mailto:sage [2005/12/10(土) 10:37:48 ]
- ・・・2億回で10秒って、別に違いがあって不思議じゃないよな？
- 339 名前：310 mailto:sage [2005/12/10(土) 10:56:43 ]
- >>338
単純化しただけであって、回数そのものは突飛でもない。
俺が問題にしてるのはCLIで標準関数呼び出しが遅い
ということ。>>337のいうようにちゃんとやることも出来るが、
そこまでやら無くても「CLIで標準関数呼び出しが遅い」のは
今までの例で明白じゃない？
- 340 名前：デフォルトの名無しさん mailto:sage [2005/12/10(土) 11:15:41 ]
- 最適化の違いだけだったりして
自分で言ってるけど、strcmp でネイティブと違いがないなら「CLIで標準関数呼び出しが遅い」
とは言えないんじゃない？
- 341 名前：デフォルトの名無しさん mailto:sage [2005/12/10(土) 11:28:40 ]
- >>339
明白かどうかわかんないから粘着してんじゃないの？
他のファクターを探す手助けにもなるんだから手抜かずにやれば？
- 342 名前：デフォルトの名無しさん mailto:sage [2005/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 mailto:sage [2005/12/10(土) 11:37:56 ]
- あ、すまん。濡れ衣だな。パフォーマンスの違いと詰め込み時間を考えれば、妥当か
ちなみに、/clr では同等のソースで11秒だった
- 344 名前：310 mailto:sage [2005/12/10(土) 11:38:06 ]
- >>340
遅まきながらステップしてみた。
strcmpはCLIでもインライン展開されていた。
stricmpはcallされていて、スタックトレースウインドウに
マネージからネイティブへ以降、と表示される。
- 345 名前：342 mailto:sage [2005/12/10(土) 11:48:28 ]
- 漏れの環境での比較と詰め込みの結果
CLR native
strcmp 11s 8s
stricmp 16s 13s
lstrcmp 20s 17s
なんか、綺麗な結果になった。CLR の起動コストとかで +3s ぐらい
- 346 名前：310 mailto:sage [2005/12/10(土) 11:50:27 ]
- >>341
1回、1億回、2億回でほぼ直線状に並んでたから比例と書いた。
１回なら起動の時間は気にならないくらい一瞬で終わる。
- 347 名前：310 mailto:sage [2005/12/10(土) 11:52:44 ]
- >>345
ループ1回で+3sかかりますか？
- 348 名前：デフォルトの名無しさん mailto:sage [2005/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 mailto:sage [2005/12/10(土) 12:52:57 ]
- >>348
342のソースはSTLの負荷が大きいのと、strcmpはインライン化されて
マネージ、ネイティブの切り替えは見えにくくなってると思う。
だから純粋にネイティブとCLIの差じゃなかろうか。
STLとっぱらってstricmpとかだけにしたらこちらの結果と
相似に近いのが出るんじゃないかな。
STLはマネージ側で実行されるんでしょ？ だからネイティブとの
大きな差にはならないんじゃないのかと。←こっちより差が小さいから
- 350 名前：デフォルトの名無しさん mailto:sage [2005/12/10(土) 12:59:11 ]
- >349
んにゃ。STLはネイティブだよ。ループで代入しているのは、最適化でループ自体が外される
のを防ぐため
しかし、CLRx64 にはもうちょっとがんがってほすぃ
- 351 名前：310 mailto:sage [2005/12/10(土) 13:01:25 ]
- >>350
>STLはネイティブだよ
ありゃそうなの？ テンプレートっつーくらいだから
マネージとしてコンパイルされてるのかと思った。
- 352 名前：デフォルトの名無しさん mailto:sage [2005/12/10(土) 13:05:46 ]
- >351
それはジェネリクスを利用した STL.NET と混同してるんじゃないかな
しかし、+2秒はいったい何をしているのだろう
- 353 名前：デフォルトの名無しさん mailto:sage [2005/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 名前：デフォルトの名無しさん mailto:sage [2005/12/10(土) 22:23:25 ]
- >>346
数学苦手だった人?
- 355 名前：デフォルトの名無しさん mailto:sage [2005/12/10(土) 22:28:52 ]
- 直線と言っても限りなく水平に近いものから限りなく垂直に近いものまであるわけで。
- 356 名前：デフォルトの名無しさん mailto:sage [2005/12/11(日) 00:48:46 ]
- >>353
ｽｹﾞｰな
- 357 名前：デフォルトの名無しさん [2005/12/11(日) 03:32:29 ]
- .net2.0SDKにはC++/CLIのコンパイラって付いてくるの？
managedC++は？
- 358 名前：デフォルトの名無しさん mailto:sage [2005/12/11(日) 04:57:42 ]
- ついてこない。
- 359 名前：デフォルトの名無しさん mailto:sage [2005/12/11(日) 05:03:06 ]
- えええええええええええええ
- 360 名前：デフォルトの名無しさん [2005/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 名前：デフォルトの名無しさん mailto:sage [2005/12/11(日) 07:58:58 ]
- >357
cl /clr
cl /clr:oldSyntax
ってやってみな
- 362 名前：デフォルトの名無しさん [2005/12/11(日) 08:05:27 ]
- >>360
つか、今時Win32 APIをコールする必要があるか？？？
- 363 名前：デフォルトの名無しさん mailto:sage [2005/12/11(日) 08:56:21 ]
- ある
- 364 名前：デフォルトの名無しさん mailto:sage [2005/12/11(日) 10:14:33 ]
- >>362
まだ大いにあるよ。
- 365 名前：デフォルトの名無しさん mailto:sage [2005/12/11(日) 10:49:56 ]
- >>362
君にはない。
- 366 名前：デフォルトの名無しさん mailto:sage [2005/12/11(日) 11:11:19 ]
- >>362
今時っていうか、今程度の.netじゃ、
まともなWindowsプログラミングやるならWinAPI叩かざるを得ない。
- 367 名前：デフォルトの名無しさん mailto:sage [2005/12/11(日) 12:15:19 ]
- 激同
- 368 名前：デフォルトの名無しさん [2005/12/11(日) 19:40:02 ]
- >>366
そうか〜？
.NET Frameworkのクラスライブラリだけですべて作れますけど・・・
- 369 名前：デフォルトの名無しさん mailto:sage [2005/12/11(日) 20:06:45 ]
- いまんところ直面した問題
・ＩＭＥ
・Ｃａｒｅｔ
・ScrollWindowEx
- 370 名前：デフォルトの名無しさん mailto:sage [2005/12/11(日) 20:08:00 ]
- >>369
初心者スレ行けばｗ
- 371 名前：デフォルトの名無しさん mailto:sage [2005/12/11(日) 20:15:13 ]
- >>370
あほか。流れ嫁。API呼ばなきゃいけない問題だ。かす。
- 372 名前：デフォルトの名無しさん mailto:sage [2005/12/11(日) 20:22:17 ]
- >>371
初心者スレ行けばｗ
|
 |
