トップページ⇒tech
1001コメント304KB

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

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん2005/09/11(日) 23:54:01
おそらく、.NET開発でデファクトスタンダードに最も近い
であろうC++/CLIについて語ろうぜ！
0322デフォルトの名無しさん2005/12/09(金) 22:55:34
アセンブリ（アプリケーション）で閉じてる範囲に置いては、CLIはロードされないんじゃね？
03233102005/12/09(金) 23:02:41
>>322
意味が分かりませんorz
0324デフォルトの名無しさん2005/12/09(金) 23:06:31
>>321
> つーことはやはり呼び出し負荷でしょう。

それ言うなら、

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

回数変えてファクターが何か調べないと。面白い奴だな(w
03253102005/12/09(金) 23:10:53
>>324
回数変えたら実行秒数が比例するけど。

my_stricmpにしてネイティブと差が無いわけだから、違いは
標準ライブラリの呼び出し以外に何か考えられる？
0326デフォルトの名無しさん2005/12/09(金) 23:20:29
y = ax + b の a を比べろと言えば分かりますか?
03273102005/12/09(金) 23:27:29
>>326
何を言ってるのか分かりませんが、
具体的に他にファクターがあるならあげてみて欲しい。

こちらの比べ方に抜けがあるならそこを指摘してくれまいか。
0328デフォルトの名無しさん2005/12/09(金) 23:31:27
ちょっと、煽りと神経質になってる人もいるみたい
まぁ、とりあえず、時間の出たマシンのスペックを教えてちょ
問題になっているのは、msvcm80.dll 辺りかな
0329デフォルトの名無しさん2005/12/09(金) 23:54:07
回数を2倍にしても実行時間が2倍になるとは限らない。
325に比例するとは書いてあるけど、比例にもいろいろあるだろうに。
0330デフォルトの名無しさん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を切り替えるだけで、全然速度が違う。なじぇ？
0331デフォルトの名無しさん2005/12/10(土) 00:19:19
ﾜﾗ
0332デフォルトの名無しさん2005/12/10(土) 00:28:24
まるで見当はずれかもしれませんが
int mycomp(,,,) の前に #pragma unmanaged を置いてみるとどうなりますかね？
03333302005/12/10(土) 00:53:42
ごめん。これは速度が違って当たり前だった。ろくにチェックしていない
before をちゃんとチェックすると、だいたい１６秒でstrcmpと変わらない
むしろ、ネイティブだと一瞬なんで、処理に時間がかかる理由が気になる
03343302005/12/10(土) 01:08:50
すまん。>>333 は元の関数のコメントアウトをしてなかったorz
mycompにすると一瞬で終わるね。もうちょっと、関数の実装をちゃんとするべきなんだろうけど
ネイティブに記述された関数はネイティブで処理されてる。となると、C標準関数が問題
なのか・・・
03353102005/12/10(土) 08:50:45
>>329
＞回数を2倍にしても実行時間が2倍になるとは限らない。
それは比例じゃないと思うけど。
言葉どおり比例と受け取って欲しい。

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

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

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

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

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

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

>>332
試してみた。
CLIでmy_stricmpをunmanagedプラグマで囲ったら、少しだけ遅くなった（３秒くらい）。
囲わなかった場合、今朝計り直してみたら１秒未満。
0337デフォルトの名無しさん2005/12/10(土) 10:26:32
「思って欲しい」(w ってんじゃなくて、普通は i<2000000 だけじゃなく、
i<500000、i<1000000、i<2500000も取ってグラフをプロットするわけ。

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

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

表計算ソフト、数式処理ソフト、グラフプロットツールあれば簡単にグラフ化できるよね。
0338デフォルトの名無しさん2005/12/10(土) 10:37:48
・・・2億回で10秒って、別に違いがあって不思議じゃないよな？
03393102005/12/10(土) 10:56:43
>>338
単純化しただけであって、回数そのものは突飛でもない。

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

0340デフォルトの名無しさん2005/12/10(土) 11:15:41
最適化の違いだけだったりして
自分で言ってるけど、strcmp でネイティブと違いがないなら「CLIで標準関数呼び出しが遅い」
とは言えないんじゃない？
0341デフォルトの名無しさん2005/12/10(土) 11:28:40
>>339
明白かどうかわかんないから粘着してんじゃないの？
他のファクターを探す手助けにもなるんだから手抜かずにやれば？
0342デフォルトの名無しさん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;
}
03433422005/12/10(土) 11:37:56
あ、すまん。濡れ衣だな。パフォーマンスの違いと詰め込み時間を考えれば、妥当か
ちなみに、/clr では同等のソースで11秒だった
03443102005/12/10(土) 11:38:06
>>340
遅まきながらステップしてみた。
strcmpはCLIでもインライン展開されていた。
stricmpはcallされていて、スタックトレースウインドウに
マネージからネイティブへ以降、と表示される。

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

なんか、綺麗な結果になった。CLR の起動コストとかで +3s ぐらい
03463102005/12/10(土) 11:50:27
>>341
1回、1億回、2億回でほぼ直線状に並んでたから比例と書いた。
１回なら起動の時間は気にならないくらい一瞬で終わる。
03473102005/12/10(土) 11:52:44
>>345
ループ1回で+3sかかりますか？
0348デフォルトの名無しさん2005/12/10(土) 12:39:12
>347
それはなかった。何らかのコストがかかっているのは確かみたい
CLR 側のやつはDateTime とか Console::WriteLine を使っていたので、ソースを完全に
同一にすると、
lstrcmp　19s　17s
になった。1億回のループでこれだから、あとはパフォーマンス・カウンタでも使わないと
細かくはわからない領域だと思う
ちなみにいろいろと切って静かに取ってみたら

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

なんて結果になった
03493102005/12/10(土) 12:52:57
>>348

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

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

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

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

0350デフォルトの名無しさん2005/12/10(土) 12:59:11
>349
んにゃ。STLはネイティブだよ。ループで代入しているのは、最適化でループ自体が外される
のを防ぐため

しかし、CLRx64 にはもうちょっとがんがってほすぃ
03513102005/12/10(土) 13:01:25
>>350
>STLはネイティブだよ
ありゃそうなの？　テンプレートっつーくらいだから
マネージとしてコンパイルされてるのかと思った。
0352デフォルトの名無しさん2005/12/10(土) 13:05:46
>351
それはジェネリクスを利用した STL.NET と混同してるんじゃないかな
しかし、+2秒はいったい何をしているのだろう
0353デフォルトの名無しさん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

なかなか、よい結果です
0354デフォルトの名無しさん2005/12/10(土) 22:23:25
>>346
数学苦手だった人?
0355デフォルトの名無しさん2005/12/10(土) 22:28:52
直線と言っても限りなく水平に近いものから限りなく垂直に近いものまであるわけで。
0356デフォルトの名無しさん2005/12/11(日) 00:48:46
>>353
ｽｹﾞｰな
0357デフォルトの名無しさん2005/12/11(日) 03:32:29
.net2.0SDKにはC++/CLIのコンパイラって付いてくるの？
managedC++は？
0358デフォルトの名無しさん2005/12/11(日) 04:57:42
ついてこない。
0359デフォルトの名無しさん2005/12/11(日) 05:03:06
えええええええええええええ
0360デフォルトの名無しさん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にあると思っている。
0361デフォルトの名無しさん2005/12/11(日) 07:58:58
>357
cl /clr
cl /clr:oldSyntax
ってやってみな
0362デフォルトの名無しさん2005/12/11(日) 08:05:27
>>360
つか、今時Win32 APIをコールする必要があるか？？？
0363デフォルトの名無しさん2005/12/11(日) 08:56:21
ある
0364デフォルトの名無しさん2005/12/11(日) 10:14:33
>>362
まだ大いにあるよ。
0365デフォルトの名無しさん2005/12/11(日) 10:49:56
>>362
君にはない。
0366デフォルトの名無しさん2005/12/11(日) 11:11:19
>>362
今時っていうか、今程度の.netじゃ、
まともなWindowsプログラミングやるならWinAPI叩かざるを得ない。
0367デフォルトの名無しさん2005/12/11(日) 12:15:19
激同
0368デフォルトの名無しさん2005/12/11(日) 19:40:02
>>366
そうか〜？
.NET Frameworkのクラスライブラリだけですべて作れますけど・・・
0369デフォルトの名無しさん2005/12/11(日) 20:06:45
いまんところ直面した問題
・ＩＭＥ
・Ｃａｒｅｔ
・ScrollWindowEx
0370デフォルトの名無しさん2005/12/11(日) 20:08:00
>>369
初心者スレ行けばｗ
0371デフォルトの名無しさん2005/12/11(日) 20:15:13
>>370
あほか。流れ嫁。API呼ばなきゃいけない問題だ。かす。
0372デフォルトの名無しさん2005/12/11(日) 20:22:17
>>371
初心者スレ行けばｗ
0373デフォルトの名無しさん2005/12/11(日) 20:29:00
>>368
SHFileOperation

VBのMyを使えとか言ったら刺す。
0374流れを読んでレス2005/12/11(日) 22:03:40
>>371
初心者スレ行けばｗ
0375デフォルトの名無しさん2005/12/11(日) 22:21:02
>>368
FileDialogのカスタマイズ
0376デフォルトの名無しさん2005/12/12(月) 00:10:36
>>375
初心者スレ行けばｗ
0377デフォルトの名無しさん2005/12/12(月) 01:51:23
こう見るとできないことだらけだね。
MSはどうするつもりなんだろう
0378デフォルトの名無しさん2005/12/12(月) 09:21:36
そのためのC++/CLIじゃないか
0379デフォルトの名無しさん2005/12/12(月) 23:05:18
>>368
ありふれた業務アプリ程度ならそれほど困ることもないけど、
ちょっとばかしシステムに寄った途端にできないことが増える。

原因が（専ら機能面とは何の関係もない）くだらない要求だったりして
余計に萎えるというおまけが付くこともよくある。

>>377
とりあえず使い物になるVer.3を出せと言いたい。
0380デフォルトの名無しさん2005/12/13(火) 09:00:43
>原因が（専ら機能面とは何の関係もない）くだらない要求だったりして
>余計に萎えるというおまけが付くこともよくある。

あるあるｗｗ
0381デフォルトの名無しさん2005/12/13(火) 15:22:20
ttp://s03.2log.net/home/nsharp/archives/blog404.html

正直賛同できません。
0382デフォルトの名無しさん2005/12/13(火) 17:15:19
Cに勝る言語はないってことだな
0383デフォルトの名無しさん2005/12/13(火) 20:46:50
Win32への依存度を下げる必然性がないんだから当たり前でしょ？
0384デフォルトの名無しさん2005/12/13(火) 21:47:52
Win95が出たときの3.1使いもそう言ってた
0385デフォルトの名無しさん2005/12/14(水) 17:36:34
Win16→Win32s→Win32のこと?
あれは言語一緒だしね…

0386デフォルトの名無しさん2005/12/15(木) 05:37:15
技術的な需要もないことはないけど、それよりただ新しいWindowsを
作らないといけないことだけが先行してるのが萎える。市場に対して
新規性を謳うことだけが最重要課題なんだよな。
0387デフォルトの名無しさん2005/12/15(木) 20:41:33
次は ISO だな
http://www.ecma-international.org/publications/standards/Ecma-372.htm
0388デフォルトの名無しさん2005/12/16(金) 00:54:50
ISOは無理。
0389デフォルトの名無しさん2005/12/16(金) 00:59:57
C#はISOだぞ
C++/CLIだってきっと
0390デフォルトの名無しさん2005/12/16(金) 08:57:14
CLI は ISO で標準化されてたっけ？
0391デフォルトの名無しさん2005/12/16(金) 10:32:21
CLI 標準はこれだな
ISO/IEC 23271:2003
0392デフォルトの名無しさん2005/12/16(金) 10:56:26
このへんね。
http://www.plumhall.com/ecma/
http://msdn.microsoft.com/visualc/homepageheadlines/ecma/default.aspx
0393デフォルトの名無しさん2005/12/19(月) 23:38:22
http://itpro.nikkeibp.co.jp/article/COLUMN/20051125/225170/?ST=win

に「VC++ExpressEditionは標準C++を学習するための優れた教材である 」
てあるけど、そうなの？
.NETのWindowsアプリ作るものかとおもってたよ。

0394デフォルトの名無しさん2005/12/20(火) 00:04:06
とりあえずVC++は標準C++への準拠度が高いことに間違いない。
0395デフォルトの名無しさん2005/12/20(火) 02:58:19
これまでは準拠してなかったということ？
0396デフォルトの名無しさん2005/12/20(火) 09:38:58
そゆこと

それからC++でﾄﾞﾄﾈﾄすると飛んでも文法だし、
大体MFCはキショイというのが定説。
0397デフォルトの名無しさん2005/12/20(火) 13:40:38
へぇ。２００５からはキショクはないのか。
VC++（というIDE）を使ってなかった人も使い出したりするんだろか？
0398デフォルトの名無しさん2005/12/20(火) 20:36:35
IDEがVC6位軽ければみんな使うだろうに
0399デフォルトの名無しさん2005/12/20(火) 22:31:59
自分の価値観を回りに押し付けないように
0400デフォルトの名無しさん2005/12/20(火) 23:47:53
ただそこに意見が存在するだけで
押し付けられたとか思い込まないように
0401デフォルトの名無しさん2005/12/21(水) 14:50:12
ttp://mag.autumn.org/Content.modf?id=20050425162104

C++復権すると思う？
0402デフォルトの名無しさん2005/12/21(水) 15:45:19
>現状で極めて私的な感想から言えば、>JavaとC#の
>代替プログラム言語になり得る第1候補はVisual Basicです。
0403デフォルトの名無しさん2005/12/21(水) 20:16:06
>>401
復権もなにも
C++で記述できないプログラムはないんだから・・・
0404デフォルトの名無しさん2005/12/21(水) 20:22:13
>>403
それは今のCPUがC言語を動かすことを前提としてる面も大きいと思う
0405デフォルトの名無しさん2005/12/21(水) 20:28:41
CPUがC言語を動かす？

意味不明
0406デフォルトの名無しさん2005/12/21(水) 20:32:45
0番付近がNULL対策に実メモリを割り当てないようになってたりするじゃん。
他にC言語で簡単に扱えないメモリレイアウトを要求しないとかさ。
0407デフォルトの名無しさん2005/12/21(水) 21:27:10
>>406
> 0番付近がNULL対策に実メモリを割り当てないようになってたりするじゃん
これはOSの問題という側面のほうが大きいと思う。
別にC/C++ではヌルポインタのビットパターンは0でなくとも良いとなっている。

> 他にC言語で簡単に扱えないメモリレイアウトを要求しないとかさ。
そんなもん誰も要求していない。
0408デフォルトの名無しさん2005/12/22(木) 07:22:14
>>406
x86のI/Oポートは「C言語」では叩けないよ。

喪前様が言ってるのは、例えるなら、見かけの現象だけで
「太陽は地球を回っている」と言ってるのと同じこと。

言語側から見るだけじゃ、本当の意味では計算機は理解できない。
計算機の基礎から勉強したほうがいい。
0409デフォルトの名無しさん2005/12/22(木) 08:14:09
x86のI/Oポートをたたく必要がない
0410デフォルトの名無しさん2005/12/22(木) 10:44:15
>>403
「brainfuck復権すると思う？」
「復権も何も、brainfuckで記述できないプログラムはないんだから……」
0411デフォルトの名無しさん2005/12/22(木) 10:48:17
>>410
いまだにつかっていますが、なにか？
0412デフォルトの名無しさん2005/12/23(金) 07:42:22
みんなの大好きなあの言語が.NETの仲間入り。
brainf*ck.NET
0413デフォルトの名無しさん2005/12/27(火) 11:36:51
>412
ソースコードｷﾎﾞﾝ
0414デフォルトの名無しさん2005/12/27(火) 21:13:53
C++/CLIの入門サイトってありますか
0415デフォルトの名無しさん2005/12/28(水) 10:29:47
VB.NET のPGで、構文解析を行う必要が出たときに、
C++/CLI で boost.spirit 使って手軽に構文解析モジュール作成して、
VB.NET から参照設定で呼び出す

ってことが簡単に出来るならすばらしいことだと思うよ。
0416デフォルトの名無しさん2005/12/28(水) 10:32:23
マルチランゲージは素晴らしい。

現実はJ#は開封もされない事実。
ﾌﾞﾋﾞ厨はＣ貧を嫌い、Ｃ貧はﾌﾞﾋﾞ厨を嫌う。

Ｍ＄の理想は宣伝専用。
0417デフォルトの名無しさん2005/12/29(木) 00:42:11
>415
普通にできるけど？
0418デフォルトの名無しさん2005/12/29(木) 05:23:34
C#で以下のようなコードを
using (FileStream fs = new FileStream("test.txt", FileMode.Read)) {
}

C++/CLIでうまくかけるんですか？
FileStreamをスタックみたいにして作れると思ったんですが、できないのでしょうか？
04194182005/12/29(木) 05:25:15
すいません。できました。ぜんぜんわかってませんでした。
0420デフォルトの名無しさん2005/12/29(木) 17:16:57
>414
入門するようなもんじゃねぇだろ？
C# を先に勉強した方がいいぞ
0421デフォルトの名無しさん2005/12/29(木) 20:22:02
このスレでC#を勧めるのはどうかと思う。
■ このスレッドは過去ログ倉庫に格納されています