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

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

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん2005/09/11(日) 23:54:01
おそらく、.NET開発でデファクトスタンダードに最も近い
であろうC++/CLIについて語ろうぜ！
0237デフォルトの名無しさん2005/11/25(金) 23:07:16
>>236
C#って知ってる？
0238デフォルトの名無しさん2005/11/25(金) 23:08:24
> newすると解放ができない。

なんか言ってることおかしくない？
解放って？
0239デフォルトの名無しさん2005/11/25(金) 23:12:33
>236
値型は primary な型を作るためのものだから、int とかにデフォルト・コンストラクタや
ファイナライザを定義しないでしょ？
0240デフォルトの名無しさん2005/11/25(金) 23:13:13
>>236
値型は、初期化しによる初期化、代入などで、
memcpyが行われるだけでいいようなオブジェクトに使う。
定義できなかったと言うより、定義しないでいいものに使う。
02412362005/11/25(金) 23:15:45
>>238
template <typename T,typename TAG>
value struct a
{
T *p;
a(TAG)
{
p = new T();//NativeC++のスマートポインタが使えないのでCLIなスマートポインタが必要ぽい
}
};
02422362005/11/25(金) 23:21:43
>>239,240
参照型だとコピーコンストラクタいちいち用意するの面倒じゃん。
C++とC++/CLI両対応のソース書きたいので値型にしてる。
0243デフォルトの名無しさん2005/11/25(金) 23:38:57
>>242
.Netでは「クラスは参照型」となっているのだからいつか破綻する。
0244デフォルトの名無しさん2005/11/25(金) 23:40:16
それは思考が逆で、
コピーコンストラクタが必要ないから値型にしているのであって、
面倒だから参照型を使わないんじゃない。
0245デフォルトの名無しさん2005/11/25(金) 23:41:57
値型か参照型かは性能にもろに影響してくるから
適切に選択した方がいいよ
0246デフォルトの名無しさん2005/11/25(金) 23:56:47
普通にクラスを書けばいいんじゃないか？
わざわざ値型で定義しようとするから、苦労しているだけだと思うが
0247デフォルトの名無しさん2005/11/26(土) 08:19:50
>>45
LLVMがgccに入りそうな勢いだなあ。
0248デフォルトの名無しさん2005/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)
{}
};
0249デフォルトの名無しさん2005/11/28(月) 13:52:01
値型は生成時にデフォルト値を持つ必要がありますが、標準C++ の int 型はデフォルト値を
規定されていません。そのため、生成時に不定となる値の参照を型として保持できないと思われ
02502482005/11/28(月) 16:40:53
>>249
ありがとうございます。
参照型でも試してみましたが、やはりだめみたいでした。
一度、GC Heapにgcnewしてそこからinterior reference？(int%)を取得することで
参照のように扱うことはできました。
どうも値型のメンバには値型かGcHeap(Cloneされる)しかおけないようです。
また、interior ptr|referenceのときもクラスのメンバにはできないようです。
0251デフォルトの名無しさん2005/11/28(月) 18:05:46
まぁ、仕様書見るとそう書いてありますね
0252デフォルトの名無しさん2005/11/28(月) 22:05:15
俺の勘で。
ref struct TestRef
{
  int i;
  UseRef r;
  TestRef() : i(0), r(i)
  {}
};
0253デフォルトの名無しさん2005/11/29(火) 16:38:04
UseRef のデフォルト・コンストラクタが不定値を持つから駄目ぽ
0254デフォルトの名無しさん2005/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
0255デフォルトの名無しさん2005/12/02(金) 02:00:31
なんだか汚い言語になっちゃいましたね

perlみてー
0256デフォルトの名無しさん2005/12/02(金) 03:41:08
C++が汚いのはもとからだろ
0257デフォルトの名無しさん2005/12/02(金) 07:44:32
>>255
思いつきで拡張してるよね。
C++の世界では有名な人達がやっているんだが…
0258デフォルトの名無しさん2005/12/02(金) 07:49:14
だれだっけ？
0259デフォルトの名無しさん2005/12/02(金) 08:28:53
Stanley Lippman
http://staff.develop.com/slip/
http://blogs.msdn.com/slippman/
http://www.microsoft.com/presspass/press/2001/oct01/10-19lippmanpr.mspx

Herb Sutter
http://www.gotw.ca/
http://blogs.msdn.com/hsutter/
http://www.microsoft.com/presspass/press/2002/Mar02/03-13SutterPR.mspx
0260デフォルトの名無しさん2005/12/02(金) 12:51:52
Perlは美しい。C++もああいうの目指すべき。
0261デフォルトの名無しさん2005/12/02(金) 13:27:41
>>260
漏れはあまり詳しくないんだが、そうか？？？本当にそうなのか？？？？？？？
0262デフォルトの名無しさん2005/12/02(金) 15:34:59
そんなあなたに Brainf*ck
0263デフォルトの名無しさん2005/12/03(土) 00:57:17
>>255-257
良くも悪くもC++的っていう気はする。
0264デフォルトの名無しさん2005/12/03(土) 11:30:30
C++は細かいところで汚いなりに、それなりのポリシーがあったが、
C++/CLIに至ってはなんでもありだ。実装の都合としか思えないものもある。
0265デフォルトの名無しさん2005/12/03(土) 19:46:54
C++をぐちゃぐちゃにしC++コミュニティーを崩壊させる。

↓

C++の衰退とC#の反映
0266デフォルトの名無しさん2005/12/03(土) 20:47:05
Ｃ＃はメジャーにならない
断言する
0267デフォルトの名無しさん2005/12/03(土) 21:11:34
名無しで断言されても……
0268デフォルトの名無しさん2005/12/03(土) 22:04:56
>>265
それか！！
0269デフォルトの名無しさん2005/12/04(日) 18:49:26
C++/CLIの設計コンセプトは「拡張機能を使わなければ、既存のC++と変わらないこと」だから
別にC++に変な影響を与えないと思うけど
0270デフォルトの名無しさん2005/12/04(日) 20:03:25
果たしてそうかな
0271デフォルトの名無しさん2005/12/04(日) 20:18:12
>>270
そうだよ。
0272デフォルトの名無しさん2005/12/04(日) 20:56:43
関係ないが、親玉格のC(99)がやらかしてくれてるからなあ。
0273デフォルトの名無しさん2005/12/04(日) 21:15:11
C++はまだ「生きた」言語なんだよ。
まだまだ進化する。
0274デフォルトの名無しさん2005/12/04(日) 21:41:25
ここに書いて良いのかわからんかったんですが。
タスクマネージャーの「CPU使用率の履歴」みたいな動的な(?)グラフを出せるものを書きたいのですが
何から手をつければいいのか、全くわかりません。
アドバイスよろしくお願いします。
0275デフォルトの名無しさん2005/12/04(日) 21:46:55
age
0276デフォルトの名無しさん2005/12/04(日) 22:13:21
>>274
とりあえず↓この本読め。
http://www.amazon.co.jp/exec/obidos/ASIN/4872331265/qid=1133701895/sr=1-1/ref=sr_1_10_1/249-6035794-3226728
0277デフォルトの名無しさん2005/12/05(月) 09:58:09
>>272
C99のマズイところでどんなとこ？
得に思い当たらないんだけど
0278デフォルトの名無しさん2005/12/05(月) 11:34:16
エラーのthrow/catchが、cとc++で別になったのは痛い。

MFCとC++、C丼とC++、MC++とC++、C++CLIとC++、それぞれ結局別物と思われてるところも痛いけど。
0279デフォルトの名無しさん2005/12/05(月) 11:43:35
実際別物
0280デフォルトの名無しさん2005/12/05(月) 15:13:07
MFCを持ち出してくるところが痛い。
0281デフォルトの名無しさん2005/12/05(月) 15:30:50
MFCって、mc++とかC++/CLIから使えるんだっけか？
0282デフォルトの名無しさん2005/12/05(月) 18:32:19
C++/CLIやmc++の構文を使ってないコードを /clrでコンパイルしたものを
C++/CLIやmc++のプログラムと読んでいいかどうかによるけど、
そう呼んでいいなら使える。
0283デフォルトの名無しさん2005/12/05(月) 18:41:23
managed と unmanagedの型でデータ交換したいのですが、
COMを使うしかないのでしょうか？

0284デフォルトの名無しさん2005/12/05(月) 19:07:05
>>283
具体例を挙げてわかるように質問してくれ。
0285デフォルトの名無しさん2005/12/05(月) 19:10:17
＞/clrでコンパイルしたものを
どういったオプションでつか？
02862832005/12/05(月) 19:33:39
>>284
混合クラスにできないだけで、
別クラスにしておいて呼び出しは可能だったのね...

Marshalingできる時はしたほうがいいのかな
ttp://msdn2.microsoft.com/library/ms235282(en-US,VS.80).aspx
0287修正2005/12/05(月) 21:25:49
unmanagedからmanagedの呼び出しはできないみたい。

0288デフォルトの名無しさん2005/12/05(月) 22:45:23
CLRホスティング・・・
0289デフォルトの名無しさん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

0290デフォルトの名無しさん2005/12/06(火) 07:34:09
最強
0291デフォルトの名無しさん2005/12/06(火) 10:52:01
unko
0292デフォルトの名無しさん2005/12/07(水) 23:15:01
C++/CLIの存在意義って？

マネージならC#でよくね？
0293マイク ◆yrBrqfF1Ew 2005/12/07(水) 23:19:32
そうだな。
0294デフォルトの名無しさん2005/12/08(木) 00:28:08
やっぱりC#?
C++から移植するのってどれぐらい工数かかるんだろうか・・・・
0295デフォルトの名無しさん2005/12/08(木) 00:32:04
ぶっちゃけ、WindowsアプリならVC++6&MFCが最強では？
あえてC#を覚えようとする気がしない。
VC++6&MFCでつれないWindowsアプリはない。
0296デフォルトの名無しさん2005/12/08(木) 00:39:03
かわいそうな人
0297デフォルトの名無しさん2005/12/08(木) 01:10:46
あえてCを覚えようという気がしない。
機械語で作れないwindowsアプリはない。
0298デフォルトの名無しさん2005/12/08(木) 01:24:49
あえて計算機を覚えようという気がしない。
脳内で計算できない問題はない。
0299デフォルトの名無しさん2005/12/08(木) 06:10:14
切り返すなら同じ性質の物事を書かなきゃ :-P
0300デフォルトの名無しさん2005/12/08(木) 08:16:12
>>297
俺も未だに機械語で書いてるよ
Cだとおせーから嫌だ
0301デフォルトの名無しさん2005/12/08(木) 08:28:05
>>295
なるほど、いろんなWindowsアプリさんたちが釣れるようでつね。
0302デフォルトの名無しさん2005/12/08(木) 11:44:15
>>295はLonghornが出たら干される使い捨てデジドカ
0303デフォルトの名無しさん2005/12/08(木) 20:59:47
OSが記述できてしまう
C++は絶対に廃れないよ
しかも、デバイスドライバを書ける人は絶対に不可欠
C#やJAVAなんてモノが出来ても結局また
新たな言語が出てきて廃れるのは必至
0304デフォルトの名無しさん2005/12/08(木) 21:14:47
つまりCOBOLと似たようなもんだ。
新しい言語の出現で全盛期より減ったとは言え、需要がなくなることはありえない。
0305デフォルトの名無しさん2005/12/08(木) 21:44:19
歩く死体か。
0306デフォルトの名無しさん2005/12/09(金) 02:03:11
Cで必要にして十分な件。
0307デフォルトの名無しさん2005/12/09(金) 11:02:38
既存のプログラムが全部マネージ環境で通るようにライブラリとか
整えて欲しい。

printfやstrcmp使うとネイティブとの混合アプリになっちゃうんでしょ？
標準ライブラリの中も.NETにすりゃあいいのに。
0308デフォルトの名無しさん2005/12/09(金) 11:24:49
混合になってなんかマズイことでもあるのかい？
0309デフォルトの名無しさん2005/12/09(金) 13:12:07
>>307
あなたは根本的にCLIの世界を理解してないです。
0310デフォルトの名無しさん2005/12/09(金) 16:26:18
>>308
混合だとWin以外に持っていけるの？（あるかはしらんけど）
あと、切り替え時に異様に遅い感触。

>>309
根本を教えてくれ
0311デフォルトの名無しさん2005/12/09(金) 16:43:46
感触って君の思い込みのこと?
0312デフォルトの名無しさん2005/12/09(金) 16:53:06
>>311
/clrつけてコンパイルしなおしたプログラムが異様に遅い。
.NETにしてもちょっと遅すぎると思ってね。原因がネイティブ
部分の呼び出し負荷くらいしか思い当たらない。
03133102005/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でもインライン展開されるのかな？
03143102005/12/09(金) 17:42:54
>>313の例ではネイティブへの切り替え以外に負荷になる要素は
無いと思うんだが、識者の意見希望。
0315デフォルトの名無しさん2005/12/09(金) 18:51:09
関数の処理が遅いのか、CLR の起動に手間取っているのかは、ちゃんと分けた？
03163102005/12/09(金) 19:01:59
>>315
my_stricmpを使ってネイティブと時間の差が無いのだから、
起動時間の問題じゃないと思う。

あと、ループの回数を増減させれば処理時間も比例する。
0317デフォルトの名無しさん2005/12/09(金) 20:03:25
>>313
strcmpは？stricmpだとCLIの方はロケールとかで色々面倒くさい
ことしてそう。
0318デフォルトの名無しさん2005/12/09(金) 20:56:41
>>313
ではlstrcmpはどう？
これなら絶対にインライン展開できない。
03193102005/12/09(金) 21:15:00
>>318
lstrcmp,これから試してみるけど先に質問。

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

この前提で、中身が一緒なら呼び出してる部分に負荷があるんじゃないかと
思っていたわけだが、ネイティブとCLIで呼び出されるstricmp（に限らず標準
ライブラリ全般）は別物なの？
0320デフォルトの名無しさん2005/12/09(金) 22:17:02
>>319
その試した見たというコードをどこかのアップローダに晒すというのは
どうだい？そうすれば同じ土俵で話ができる。
03213102005/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;
}


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プラグマで囲ったら、少しだけ遅くなった（３秒くらい）。
囲わなかった場合、今朝計り直してみたら１秒未満。
■ このスレッドは過去ログ倉庫に格納されています