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

【.NET】 C++/CLI に� ..

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を使ってる馬鹿と同レベルの理屈だな

新しいものの方がいいに決まってる。たとえバグ込みでも
長い目で見れば将来性の高いほうを選択する方がよい

次ページ