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

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

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

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

573:デフォルトの名無しさん
06/02/09 17:47:52
>>571

BOOST.NETって何？そんなんあんの？

574:デフォルトの名無しさん
06/02/09 22:47:44
>>572

その将来性のおかげで、君の部下が次々と止めていくんだがどう責任取るのかね?

575:デフォルトの名無しさん
06/02/10 21:58:53
値型にデフォルトコンストラクタと代入演算子を定義できる
.NET言語ってあるんかな？

576:デフォルトの名無しさん
06/02/10 22:01:31
フレームワーク内のprivateないくつかの構造体を見ると、
デフォルトコンストラクタ使ってるのがいくつかあるな。

Win32関係の構造体で自分のサイズを設定してるんだが。

577:デフォルトの名無しさん
06/02/10 22:20:02
>>575
つIL (ilasm)
まぁぶっちゃけいらないっていうかあってもまずやっちゃいけないしな

578:575
06/02/10 23:53:50
>>576,577
どうも

Reflectorでみてみたら
staticコンストラクタで代用しているのはありました。

こんな感じで試してみようかな...
URLﾘﾝｸ(www.gdncom.jp)

579:575
06/02/11 01:08:41
やってみたけどよくわからんかった。でも
templateの部分特殊化でCLI型が使えるみたいだから、それでcreateすればいいか.

template <typename T> ref struct Type{ T create(); };
template <typename T> ref struct Type<T^>{ T^ create(); };

580:デフォルトの名無しさん
06/02/11 07:51:31
C++ で boost の shared_ptr とか boost::program_options とか
使いまくりんぐのプログラム作ってきたんだけど、
C++/CLI でそのコード流用できるんですかね？
stl::map とか使いまくりんぐノプログラムは
そのままで動くのか、STL.NET みたいなモノをつかうように
移植しなけりゃならないのか、System::Collections を
使うのが C++/CLI 流なのか・・・・・・

何でも出来るから何使えばいいか迷う。

581:デフォルトの名無しさん
06/02/11 09:40:08
C++/CLIは便利だと思うが、棲み分けに失敗した感じがするな。
C#で統合するはずが、C++/CLIで統合されるとは…。
本当は.NET対応はC#だけでよかったんだと思う。

582:デフォルトの名無しさん
06/02/11 10:25:45
>>580
managedなobjectをどう扱いたいかによるだろ?

例えば数値計算してその結果を3Dグラフ表示するような場合、
数値計算の部分は普通にC++使えばいいけど、(例えばboostなど)
画面表示の部分はどうしてもCLIに頼らないといけない。

C++/CLIは基本的にC++の上位互換と考えていいから。
"spaced keyword"なんていうのは非互換だけどね。

583:デフォルトの名無しさん
06/02/11 10:29:11
おまえら、どのエディション使ってるの？

584:デフォルトの名無しさん
06/02/11 10:35:44
>>582 うむ、いっていることは分かる。
まさに数値計算して可視化、ってのは仕事で必要。
しかも膨大な数値計算用のライブラリ(自作+他作)がすでにある。

今一番の問題は、コマンドラインをパーすするために便利な
boost::program_options を C++/CLI コンソールアプリでも
使いたいってことかな(笑

585:デフォルトの名無しさん
06/02/11 11:10:32
C++/CLIは、CLIに頼らなければいけない時だけ、
managedなコードを書かなければいけないC++だろ?

embedded C++みたいに言語の機能抜かれているわけじゃないから。

ライブラリであるSTL .NETは、C#やHaskelからも使えるSTLライブラリとして、
C++特有のところは抜かれているけれど。(特殊化関連など)

586:デフォルトの名無しさん
06/02/11 11:11:09
>>585
> managedなコードを書かなければいけないC++だろ?

managedなコードも書ける、とも言えるし。

587:デフォルトの名無しさん
06/02/11 11:15:34
>>585 ふむ、いわれてみればそうだな。
俺があまりにも boost 依存なコードを書きすぎていただけだと思う。

588:デフォルトの名無しさん
06/02/11 15:56:27
>>581
いろんな言語が使用できるっていうのが.NETのうたい文句のひとつだったから
C#だけって言うのはいただけない

589:デフォルトの名無しさん
06/02/11 16:22:28
馬鹿はスルーしる

590:デフォルトの名無しさん
06/02/11 16:26:50
.NETって実際複数言語で開発してたりすんの？

591:デフォルトの名無しさん
06/02/11 16:48:36
>>590 俺はドトネトは C# しか使ってないけど、
俺が使ってるアセンブリが C++/CLI や VB.NET
で作られているかどうかは知らない。

592:デフォルトの名無しさん
06/02/11 16:53:16
VC++はVC++で作られていますという件はもはや過去のもの？

593:デフォルトの名無しさん
06/02/11 17:26:02
「ドトネト」って言う呼び方はアンチっぽいからやめてくれ

594:デフォルトの名無しさん
06/02/11 17:31:18
エロビデオのネバスペみたいなもんか。

595:デフォルトの名無しさん
06/02/11 17:39:26
Win32APIなどのネイティブ呼び出しをC++/CLIでラップしてあとはC#で開発してる。
windows.h　の関数や定数の定義をそのまま使える上にInteropで呼び出しも高速なので
P/Invokeよりぜんぜんいいよ。

ドトネトよりポチネットのほうが可愛い

596:デフォルトの名無しさん
06/02/11 18:07:08
>>595
狂おしいほどに同意
アセンブリの中にネイティブコードを突っ込めるから
逆コンパイルにも対抗できるし。

597:デフォルトの名無しさん
06/02/11 20:57:49
そんなことしたら64bitでそのまま動かないじゃん

598:デフォルトの名無しさん
06/02/12 03:52:02
>>597
32bitで何か問題でも?

599:デフォルトの名無しさん
06/02/12 16:51:41
C++/CLIがNativeとManagedの混合アプリを作るのに優秀なのは理解できるが、
/clr:safe　なアプリをあえてC++/CLIで作ることに意味があるのだろうか。

600:デフォルトの名無しさん
06/02/12 17:37:42
>>599
特になし。C++/CLIはC++使い慣れてる(C++ライブラリを膨大に抱えてる)人を
.NETに繋ぎとめておくためのもの。

601:デフォルトの名無しさん
06/02/12 21:00:01
2003のWin32APIやMFCを2005ExpressEditionで使おうと
頑張ってみたが無理だった。
Win32APIはコンパイル通るけど警告出るし、
MFCに関しては全くお手上げ。

602:デフォルトの名無しさん
06/02/12 22:31:04
>>601
WinAPIは2003から持ってこなくても最新のPlatform　SDKを入れればいいだろうに。

603:デフォルトの名無しさん
06/02/12 23:14:27
C++/CLIはVB.NETで作ったクラスライブラリを呼び出すことも可能？

604:デフォルトの名無しさん
06/02/12 23:33:15
可

605:デフォルトの名無しさん
06/02/12 23:51:30
>>602
最新のSDK持ってきたら、警告なくなったよ。ありがと。

606:デフォルトの名無しさん
06/02/13 08:02:58
managed C++ みたいに C++/CLI もやっぱやーめたなんてことにはならんだろうな？
前者はなんか標準化団体には出されてたんだっけ？後者はだされてたよな？

607:デフォルトの名無しさん
06/02/13 08:05:18
>>605
感謝は言葉ではなく物で示せ。

608:デフォルトの名無しさん
06/02/13 12:44:28
>606
今、ISO で標準化の審査中

609:デフォルトの名無しさん
06/02/13 13:03:53
>>608 それは C++/CLI だよね？
もう Managed C++ はいらんでそ。

610:デフォルトの名無しさん
06/02/13 14:01:33
(1)for each( int obj in v)
(2)for each( int^ itr in v)
(3)for each( int% r in v)

for each する場合、どれがお勧め？

611:デフォルトの名無しさん
06/02/13 15:26:41
>>609
URLﾘﾝｸ(www.ecma-international.org)
これがISOに提出された。まあISOになる可能性はないと思うけれど。

612:デフォルトの名無しさん
06/02/13 16:55:39
>>611 あれ？ないの？

613:デフォルトの名無しさん
06/02/13 17:22:33
CLI 自体はすでに ISO 標準になってるんだよな。
Java VM も ISO 標準にすればいいのに。
Java 言語とは切り離して。

614:デフォルトの名無しさん
06/02/13 18:06:42
で、ISO 標準て何の役に立つの？

615:デフォルトの名無しさん
06/02/13 18:07:31
ネームバリュー

616:デフォルトの名無しさん
06/02/13 18:10:32
実質を無視したネームバリューなら、
Java >>>>>>（壁）>>>>>> Ｃ丼（I$O）
だね。

617:デフォルトの名無しさん
06/02/13 18:13:08
>>616 実質的なネームバリューだと思うけど。

618:デフォルトの名無しさん
06/02/13 21:22:11
>>616
Java のネームバリューってかなり実質的なものだと思うぞ。

619:デフォルトの名無しさん
06/02/13 23:26:25
>>613
EMCAの時に、J2EEも同時に採用されることにこだわった。
当時は、IBMその他ベンダーが独自ビジネス向けフレームワークの覇権を争っていた。

Javaはまだまだ言語規格の変化が激しいから、10年前なら見送りも妥当だったと思う。
今は、C++みたいにろくにない実装も規格を作るのに抵抗がなくなってきている。
だからJavaも今からISOの提出してもいいと思うけれど、
EMCAのWin系規格みたいに放置されると困るよね。

C#やCLIもそんなことにならないかと心配。

次ページ