【.NET】 C++/CLI に� ..
[2ch|▼Menu]
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
へぇ、ありがとう

次ページ
最新レス表示
スレッドの検索
類似スレ一覧
話題のニュース
おまかせリスト
▼オプションを表示
暇つぶし2ch
5371日前に更新/240 KB
担当:undef