[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 1001- 2chのread.cgiへ]
Update time : 05/09 17:12 / Filesize : 240 KB / Number-of Response : 1002
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

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



1 名前:デフォルトの名無しさん [2005/09/11(日) 23:54:01 ]
おそらく、.NET開発でデファクトスタンダードに最も近い
であろうC++/CLIについて語ろうぜ!

374 名前:流れを読んでレス mailto:sage [2005/12/11(日) 22:03:40 ]
>>371
初心者スレ行けばw

375 名前:デフォルトの名無しさん mailto:sage [2005/12/11(日) 22:21:02 ]
>>368
FileDialogのカスタマイズ

376 名前:デフォルトの名無しさん mailto:sage [2005/12/12(月) 00:10:36 ]
>>375
初心者スレ行けばw

377 名前:デフォルトの名無しさん mailto:sage [2005/12/12(月) 01:51:23 ]
こう見るとできないことだらけだね。
MSはどうするつもりなんだろう

378 名前:デフォルトの名無しさん mailto:sage [2005/12/12(月) 09:21:36 ]
そのためのC++/CLIじゃないか

379 名前:デフォルトの名無しさん mailto:sage [2005/12/12(月) 23:05:18 ]
>>368
ありふれた業務アプリ程度ならそれほど困ることもないけど、
ちょっとばかしシステムに寄った途端にできないことが増える。

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

>>377
とりあえず使い物になるVer.3を出せと言いたい。

380 名前:デフォルトの名無しさん mailto:sage [2005/12/13(火) 09:00:43 ]
>原因が(専ら機能面とは何の関係もない)くだらない要求だったりして
>余計に萎えるというおまけが付くこともよくある。

あるあるww


381 名前:デフォルトの名無しさん mailto:sage [2005/12/13(火) 15:22:20 ]
ttp://s03.2log.net/home/nsharp/archives/blog404.html

正直賛同できません。


382 名前:デフォルトの名無しさん [2005/12/13(火) 17:15:19 ]
Cに勝る言語はないってことだな



383 名前:デフォルトの名無しさん mailto:sage [2005/12/13(火) 20:46:50 ]
Win32への依存度を下げる必然性がないんだから当たり前でしょ?

384 名前:デフォルトの名無しさん mailto:sage [2005/12/13(火) 21:47:52 ]
Win95が出たときの3.1使いもそう言ってた

385 名前:デフォルトの名無しさん mailto:sage [2005/12/14(水) 17:36:34 ]
Win16→Win32s→Win32のこと?
あれは言語一緒だしね…



386 名前:デフォルトの名無しさん mailto:sage [2005/12/15(木) 05:37:15 ]
技術的な需要もないことはないけど、それよりただ新しいWindowsを
作らないといけないことだけが先行してるのが萎える。市場に対して
新規性を謳うことだけが最重要課題なんだよな。

387 名前:デフォルトの名無しさん mailto:sage [2005/12/15(木) 20:41:33 ]
次は ISO だな
www.ecma-international.org/publications/standards/Ecma-372.htm

388 名前:デフォルトの名無しさん mailto:sage [2005/12/16(金) 00:54:50 ]
ISOは無理。

389 名前:デフォルトの名無しさん mailto:sage [2005/12/16(金) 00:59:57 ]
C#はISOだぞ
C++/CLIだってきっと

390 名前:デフォルトの名無しさん mailto:sage [2005/12/16(金) 08:57:14 ]
CLI は ISO で標準化されてたっけ?

391 名前:デフォルトの名無しさん mailto:sage [2005/12/16(金) 10:32:21 ]
CLI 標準はこれだな
ISO/IEC 23271:2003


392 名前:デフォルトの名無しさん mailto:sage [2005/12/16(金) 10:56:26 ]
このへんね。
www.plumhall.com/ecma/
msdn.microsoft.com/visualc/homepageheadlines/ecma/default.aspx



393 名前:デフォルトの名無しさん mailto:sage [2005/12/19(月) 23:38:22 ]
itpro.nikkeibp.co.jp/article/COLUMN/20051125/225170/?ST=win

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



394 名前:デフォルトの名無しさん mailto:sage [2005/12/20(火) 00:04:06 ]
とりあえずVC++は標準C++への準拠度が高いことに間違いない。

395 名前:デフォルトの名無しさん mailto:sage [2005/12/20(火) 02:58:19 ]
これまでは準拠してなかったということ?

396 名前:デフォルトの名無しさん mailto:sage [2005/12/20(火) 09:38:58 ]
そゆこと

それからC++でドトネトすると飛んでも文法だし、
大体MFCはキショイというのが定説。

397 名前:デフォルトの名無しさん mailto:sage [2005/12/20(火) 13:40:38 ]
へぇ。2005からはキショクはないのか。
VC++(というIDE)を使ってなかった人も使い出したりするんだろか?

398 名前:デフォルトの名無しさん mailto:sage [2005/12/20(火) 20:36:35 ]
IDEがVC6位軽ければみんな使うだろうに

399 名前:デフォルトの名無しさん mailto:sage [2005/12/20(火) 22:31:59 ]
自分の価値観を回りに押し付けないように

400 名前:デフォルトの名無しさん mailto:sage [2005/12/20(火) 23:47:53 ]
ただそこに意見が存在するだけで
押し付けられたとか思い込まないように

401 名前:デフォルトの名無しさん mailto:sage [2005/12/21(水) 14:50:12 ]
ttp://mag.autumn.org/Content.modf?id=20050425162104

C++復権すると思う?

402 名前:デフォルトの名無しさん mailto:sage [2005/12/21(水) 15:45:19 ]
>現状で極めて私的な感想から言えば、>JavaとC#の
>代替プログラム言語になり得る第1候補はVisual Basicです。




403 名前:デフォルトの名無しさん mailto:sage [2005/12/21(水) 20:16:06 ]
>>401
復権もなにも
C++で記述できないプログラムはないんだから・・・

404 名前:デフォルトの名無しさん mailto:sage [2005/12/21(水) 20:22:13 ]
>>403
それは今のCPUがC言語を動かすことを前提としてる面も大きいと思う


405 名前:デフォルトの名無しさん mailto:sage [2005/12/21(水) 20:28:41 ]
CPUがC言語を動かす?

意味不明

406 名前:デフォルトの名無しさん mailto:sage [2005/12/21(水) 20:32:45 ]
0番付近がNULL対策に実メモリを割り当てないようになってたりするじゃん。
他にC言語で簡単に扱えないメモリレイアウトを要求しないとかさ。

407 名前:デフォルトの名無しさん mailto:sage [2005/12/21(水) 21:27:10 ]
>>406
> 0番付近がNULL対策に実メモリを割り当てないようになってたりするじゃん
これはOSの問題という側面のほうが大きいと思う。
別にC/C++ではヌルポインタのビットパターンは0でなくとも良いとなっている。

> 他にC言語で簡単に扱えないメモリレイアウトを要求しないとかさ。
そんなもん誰も要求していない。

408 名前:デフォルトの名無しさん mailto:sage [2005/12/22(木) 07:22:14 ]
>>406
x86のI/Oポートは「C言語」では叩けないよ。

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

言語側から見るだけじゃ、本当の意味では計算機は理解できない。
計算機の基礎から勉強したほうがいい。

409 名前:デフォルトの名無しさん mailto:sage [2005/12/22(木) 08:14:09 ]
x86のI/Oポートをたたく必要がない

410 名前:デフォルトの名無しさん mailto:sage [2005/12/22(木) 10:44:15 ]
>>403
「brainfuck復権すると思う?」
「復権も何も、brainfuckで記述できないプログラムはないんだから……」

411 名前:デフォルトの名無しさん mailto:sage [2005/12/22(木) 10:48:17 ]
>>410
いまだにつかっていますが、なにか?

412 名前:デフォルトの名無しさん mailto:sage [2005/12/23(金) 07:42:22 ]
みんなの大好きなあの言語が.NETの仲間入り。
brainf*ck.NET



413 名前:デフォルトの名無しさん mailto:sage [2005/12/27(火) 11:36:51 ]
>412
ソースコードキボン

414 名前:デフォルトの名無しさん mailto:sage [2005/12/27(火) 21:13:53 ]
C++/CLIの入門サイトってありますか

415 名前:デフォルトの名無しさん mailto:sage [2005/12/28(水) 10:29:47 ]
VB.NET のPGで、構文解析を行う必要が出たときに、
C++/CLI で boost.spirit 使って手軽に構文解析モジュール作成して、
VB.NET から参照設定で呼び出す

ってことが簡単に出来るならすばらしいことだと思うよ。


416 名前:デフォルトの名無しさん mailto:sage [2005/12/28(水) 10:32:23 ]
マルチランゲージは素晴らしい。

現実はJ#は開封もされない事実。
ブビ厨はC貧を嫌い、C貧はブビ厨を嫌う。

M$の理想は宣伝専用。

417 名前:デフォルトの名無しさん mailto:sage [2005/12/29(木) 00:42:11 ]
>415
普通にできるけど?

418 名前:デフォルトの名無しさん mailto:sage [2005/12/29(木) 05:23:34 ]
C#で以下のようなコードを
using (FileStream fs = new FileStream("test.txt", FileMode.Read)) {
}

C++/CLIでうまくかけるんですか?
FileStreamをスタックみたいにして作れると思ったんですが、できないのでしょうか?

419 名前:418 mailto:sage [2005/12/29(木) 05:25:15 ]
すいません。できました。ぜんぜんわかってませんでした。

420 名前:デフォルトの名無しさん mailto:sage [2005/12/29(木) 17:16:57 ]
>414
入門するようなもんじゃねぇだろ?
C# を先に勉強した方がいいぞ

421 名前:デフォルトの名無しさん mailto:sage [2005/12/29(木) 20:22:02 ]
このスレでC#を勧めるのはどうかと思う。

422 名前:デフォルトの名無しさん mailto:sage [2005/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 名前:デフォルトの名無しさん mailto:sage [2005/12/31(土) 08:04:27 ]
>>422の言ってることは確かに理解できるし、俺もほとんど同意だが。
ここはC++/CLIについて語るスレなんだよなw

でもマジレスすると、入門サイトありますか?とか聞くようなレベルなら
さっさとC#かVBで始めたほうがいいと思う。


424 名前:デフォルトの名無しさん mailto:sage [2005/12/31(土) 13:05:55 ]
_asm{} とか書いたらどうなるんだ?って思ってやってみたら、
さすがに main() の中に書いたら怒られた。
関数単位でマネージド、アンマネージドが切り替わるんだね。
_asm{} 入りの関数はネイティブコードとして生成されるみたい。
その呼び出しをうまい具合にやってくれるのがいいね。
いや、C++/CLI で _asm{} 使うような機会があるかどうかは別として。

425 名前:デフォルトの名無しさん mailto:sage [2005/12/31(土) 14:20:04 ]
>424
C++/CLI の拡張構文ではグローバルな関数の存在を認めていない
だから、ただ関数を生成しただけでは、基本的にネイティブとしてコンパイルされる
はずだよ。main はさすがに扱いが違うけど

426 名前:デフォルトの名無しさん mailto:sage [2005/12/31(土) 15:09:22 ]
ふと思ったんだが boost on C++/CLI なんて可能だろうか。
ていうか、だったら素直に .NET Framework にある
便利クラス使えよって気もするが。

427 名前:デフォルトの名無しさん mailto:sage [2005/12/31(土) 16:19:01 ]
アセンブリ内で閉じてるなら平気だろ
CLI 拡張部を使わなければ、標準のC++であることが C++/CLI の設計コンセプトなんだから
できない理由はない。聞く前にやれば?

428 名前:デフォルトの名無しさん [2006/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 名前:デフォルトの名無しさん mailto:sage [2006/01/01(日) 00:46:55 ]
if ( Windows::Forms::DialogResult::OK != openFileDialog1->ShowDialog(this) )
return;

こうしました><

430 名前:デフォルトの名無しさん [2006/01/01(日) 01:19:56 ]
C++/CLIやりたいやつが入門サイトを希望するなんて
ギャグ以外の何者でもないだろ。


431 名前:デフォルトの名無しさん mailto:sage [2006/01/01(日) 12:25:43 ]
CLIマッシーンってどんな環境を目指しているの?
そのうち出るかもしれない3DのUIとか検索ベースのFSまでのつなぎかな??

432 名前:デフォルトの名無しさん mailto:sage [2006/01/01(日) 13:21:49 ]
いつかでるLISPマシンまでの繋ぎです



433 名前:デフォルトの名無しさん [2006/01/01(日) 15:25:53 ]
>C++復権すると思う?

それ以前にC++ってメジャーだったっけ?

434 名前:デフォルトの名無しさん mailto:sage [2006/01/01(日) 19:16:48 ]
>433
どっかの記事では1990年代は優勢とか、書いてあったな。

435 名前:デフォルトの名無しさん mailto:sage [2006/01/01(日) 21:07:00 ]
C++/CLIのライブラリは .NET のライブラリをそのままISO標準にするの??
以前のライブラリを使えるのはいいけど、できればGCで楽したいなー。

436 名前:デフォルトの名無しさん [2006/01/01(日) 21:58:51 ]
1990年代の段階ではC言語の仕事ばっかりやらされていたな。

437 名前:デフォルトの名無しさん mailto:sage [2006/01/01(日) 22:49:23 ]
>>433
Java/C#なんかが出てくる前は優勢だったと言えるだろう。
ただしベターCとしてしか使われなかった割合も大きかっただろうが。

438 名前:デフォルトの名無しさん mailto:sage [2006/01/01(日) 23:37:51 ]
delegateとeventの違いがわかりません。
delegateだけでいいような気がするのですが。。。

eventが存在する理由を教えてほしいです。

439 名前:デフォルトの名無しさん mailto:sage [2006/01/01(日) 23:40:52 ]
delegateを簡単に扱うため

440 名前:デフォルトの名無しさん mailto:sage [2006/01/01(日) 23:46:17 ]
>>439
センセー!簡単になる場面が思いつきません><

441 名前:デフォルトの名無しさん mailto:sage [2006/01/01(日) 23:52:42 ]
event なら delegate の呼び出しが外から出来ないでしょ

442 名前:デフォルトの名無しさん mailto:sage [2006/01/01(日) 23:53:11 ]
>>440
うるせーな。少しは自分で考えろ。
delegateは関数オブジェクトの取り扱いの簡便化ため。
eventはdelegateの呼び出しの簡便化のため



443 名前:デフォルトの名無しさん mailto:sage [2006/01/02(月) 14:27:27 ]
>>438
つか比較すること自体が変だ。
delegateは型、eventはメンバ。class(型)とメンバの違いが分かりませんって
言われたってこっちが説明に困るよ。


444 名前:440 mailto:sage [2006/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 mailto:sage [2006/01/02(月) 23:56:41 ]
あ、上のコード例はC#です。

446 名前:デフォルトの名無しさん mailto:sage [2006/01/03(火) 00:10:51 ]
event がないと AddListner やら RemoveListner を自前で実装せにゃならんのさ

447 名前:デフォルトの名無しさん mailto:sage [2006/01/03(火) 00:38:44 ]
>>444
あー、イベントというものが根本的に分かってないんだろう。
メンバで表現されるものを他の言語と比較すりゃわかると思う。
CLRでのクラスメンバにもてるものはフィールド、メソッド、「プロパティ」、「イベント」なのよ。
後者二つがあることがいわゆるC#が「コンポーネント指向言語」っていわれる理由でも
あり、ただのdelegateフィールドとは「まったく」別のもの。
こうやって特殊化したことによってTypeDescriptorやらで動的にコンポーネント情報を取得できる。

ちなみに 446 も言ってるが、イベントはフィールドとアクセサ(とメタデータ)でなるんだな。

public event EventHandler TextChanged;
と書いたときに生成されるのは
・privateなdelegateフィールド
・publicなadd, removeアクセサメソッド。
・イベントメタデータ
を生成している。

448 名前:440 mailto:sage [2006/01/03(火) 00:42:44 ]
>>446
delegateにも += や -= はあるです。

449 名前:440 mailto:sage [2006/01/03(火) 00:46:05 ]
>>447さんありがとう
即答できないので、調べてみます。

450 名前:デフォルトの名無しさん mailto:sage [2006/01/03(火) 00:57:18 ]
>>448
delegate をそのまま公開しちゃうと呼び出しが外から出来てしまうのが問題なのよ

ここはC++/CLIのスレじゃ?

451 名前:デフォルトの名無しさん [2006/01/03(火) 14:54:46 ]
.NETって使ったことないからよく分からないんだけど、
一度コンパイルしたものを、同じセキュリティーやらなんやらの設定の場合は
キャッシュしておいたコンパイル済みのコードを再利用することって出来ないの?
毎回毎回、プロセス起動のたびにコンパイルしてるのってバカみたいじゃね?

452 名前:デフォルトの名無しさん mailto:sage [2006/01/03(火) 15:02:06 ]
キャッシュされるしngenもあるし



453 名前:デフォルトの名無しさん mailto:sage [2006/01/03(火) 19:56:52 ]
>>451ってバカみたいじゃね?

454 名前:デフォルトの名無しさん mailto:sage [2006/01/04(水) 12:32:46 ]
>>453
何だ、生意気だぞ。 (プンスカプン

455 名前:デフォルトの名無しさん mailto:sage [2006/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 名前:デフォルトの名無しさん mailto:sage [2006/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 mailto:sage [2006/01/07(土) 13:56:25 ]
ごめんこのへん↓参考にして自己解決
ttp://www.microsoft.com/japan/msdn/practices/type/Patterns/enterprise/ImpSingletonInCsharp.asp

458 名前:455 mailto:sage [2006/01/07(土) 14:07:15 ]
>456
今回の場合は、こちらの方法のほうがよさげですね
ありがとうございます

459 名前:デフォルトの名無しさん [2006/01/09(月) 01:03:13 ]
何というか、変態的というか。まぁ、それがC++の良さではあったわけ
だけれど。これではあまりにもコンパイラベンダ泣かせだ…可哀想に。

460 名前:デフォルトの名無しさん mailto:sage [2006/01/09(月) 07:55:52 ]
C++/CLI をフルに実装できるコンパイラベンダって、
MS以外にあるのかね?

とか思ってたら、 g++ が対応したらかなり驚く。
mcs と合体するとか。

461 名前:デフォルトの名無しさん mailto:sage [2006/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 名前:デフォルトの名無しさん mailto:sage [2006/01/09(月) 14:18:44 ]
Cの標準ライブラリlinkしてる?



463 名前:デフォルトの名無しさん mailto:sage [2006/01/09(月) 14:32:49 ]
ECMA-372ってISOになるときに内容が変更される可能性とかある?
ECMAは規格書が公開されるからいいけどISOはショボーンだからさ。

464 名前:デフォルトの名無しさん mailto:sage [2006/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 名前:デフォルトの名無しさん mailto:sage [2006/01/09(月) 17:50:19 ]
libpngをソースから作り直したほうが早いよ。
zlibとlibpngのソースをDLしてdswとかslnとかを開いてビルドするだけ。
やったらWindows フォームアプリのプロジェクトに問題なく使えた。
ml.exeがVCExpressにはないので$(MSVS8)\VC\binにコピーしておくこと。

466 名前:デフォルトの名無しさん mailto:sage [2006/01/09(月) 18:49:06 ]
ありがとうございます!
試してみます。

467 名前:デフォルトの名無しさん mailto:sage [2006/01/09(月) 20:48:36 ]
>463
ECMA から ISO に回された仕様書はただで公開しているよ

468 名前:デフォルトの名無しさん mailto:sage [2006/01/09(月) 21:05:35 ]
>>467
へぇ、ありがとう

469 名前:デフォルトの名無しさん mailto:sage [2006/01/19(木) 07:08:22 ]
value struct B
{
literal System::String^ var = L"abcd";
literal System::String^ var2 = var+L"1212";
};
var2でエラーが出るんだが...だめなのか。(整数型intとかだと大丈夫だったんだけど...)
リテラル データ メンバの初期化子は定数指揮でなければなりません

470 名前:デフォルトの名無しさん [2006/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 mailto:sage [2006/01/19(木) 09:37:44 ]
>>470
literal System::String^ var2 = var;
でもだめみたい。
static ctorでの初期化が許容できるなら
literal -> static initonly に変更するか、マクロにするしかないですね...

msdn2.microsoft.com/en-us/library/5yzft952(en-US,VS.80).aspx


472 名前:デフォルトの名無しさん [2006/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 名前:デフォルトの名無しさん mailto:sage [2006/01/19(木) 12:08:38 ]
C++の計算用DLLをC#から使えばいいだけじゃん

474 名前:デフォルトの名無しさん mailto:sage [2006/01/19(木) 12:12:25 ]
>>472
今までは C++ -> COM経由 -> C#
これからは C++ -> C++/CLI
.NETでは C++/CLI <=>C#








[ 続きを読む ] / [ 携帯版 ]

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<240KB

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef