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を使ってる馬鹿と同レベルの理屈だな
新しいものの方がいいに決まってる。たとえバグ込みでも
長い目で見れば将来性の高いほうを選択する方がよい
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もそんなことにならないかと心配。
620:デフォルトの名無しさん
06/02/14 04:09:12
>>618
確かにJavaはネームバリューだけだな
621:デフォルトの名無しさん
06/02/14 09:09:07
ドトネッツは実質ＮＯ．１
（ベーパーウェア部門）
622:デフォルトの名無しさん
06/02/14 13:57:47
>610
vの中身を書き換えたいときは、必然的に(3)
(1)と(2)でコンパイル結果に差が出るかは知らんが、同じなら(2)の方が他の参照型などと統一性が採れると思う
623:デフォルトの名無しさん
06/02/14 22:40:58
int^ だとボックス化のコストが高くない？
624:610
06/02/15 09:08:44
>>622,623
値型の場合、(1)が無難な気がしてきた。(2)はテンポラリGCポインタなのか...(3)はなんか怪しい...
参照型の場合、(2)しか選択もうない気が、第４の選択肢は危険ぽいし...
ref struct Test{
Test(){}int x;Test(int in_x) :x(in_x){}
static void test(){
System::Collections::Generic::List<int> v;v.Add(1);v.Add(2);v.Add(3); //case1
//cli::array<int>^ v = {1,2,3}; //case2
#define SHOW for each(int i in v){Console::WriteLine(i);}
for each(int i in v){i *= 2;}SHOW;//result->{1,2,3}
for each(int^ p in v){(*p) *= 2;}SHOW;//result->{1,2,3}
//for each(int^% p in v){(*p) *= 2;}SHOW;//danger
for each(int% r in v){r *= 2;}SHOW; //case1->{1,2,3},case2->{2,4,6} -> unsafe code
}
static void test2(){
System::Collections::Generic::List<Test^> v;v.Add(%Test(1));v.Add(%Test(2));v.Add(%Test(3));
//cli::array<Test^>^ v ={ %Test(1),%Test(2),%Test(3) };
#define SHOW2 for each(Test^ t in v){Console::WriteLine(t->x);}
for each(Test^ p in v){(*p).x *= 2;}SHOW2;//result->{2,4,6}
for each(Test^% r in v){(*r).x *= 2;}SHOW2;//result->{4,8,12},case2->{2,4,6} -> unsafe code
}
};
625:デフォルトの名無しさん
06/02/15 12:54:23
>624
何を悩んでいるのかよくわからん
列挙する型に合わせれば良いんじゃないか？
適材適所だろ
626:デフォルトの名無しさん
06/02/15 16:25:30
^うざ
627:デフォルトの名無しさん
06/02/15 19:45:53
よーく見ると、顔に見えてくる。
628:デフォルトの名無しさん
06/02/18 14:49:04
VS 2005 C++だす
× String str = "Hello";
○ String ^str = "Hello";
いちち^付けないといけないみたいですね、
^ってどういう意味ﾃﾞﾂｶ
629:デフォルトの名無しさん
06/02/18 15:09:39
>>628
C++/CLIに於けるポインタ
630:デフォルトの名無しさん
06/02/18 15:17:47
そっか、それで
*を^に変えろって困憊羅が言ってるの、見たような希ガスル
しかしなぁー、なぜ換える必要があるのかと、悩む事小10分
*アスタリスクはなんか他の用途でつかってるのかなぁ？？
631:デフォルトの名無しさん
06/02/18 15:30:01
こう覚えた方が早い
* を使っているのは C++
^ を使っているのは CLI 拡張
632:デフォルトの名無しさん
06/02/18 15:44:42
>>630
*のポインタ型同士はポインタ演算があるから演算子多重定義ができない。
^の追跡ハンドルならそのようなことがないから演算子多重定義ができる。
633:628
06/02/18 16:29:22
>>631
>>632サンクスです
GUIが使えるWin32でアプリケーションを作りたくて、NETや本を読んで
今学習しているところなんです、Visual Studio 2005 C++の
Win32コンソールアプリケーションを開いてボタンを押したら、
テキストボックスにメッセージを表示させたりとかして
動かしているのですけど訳も分からずに、CLIを使っていたんですね（；^ω^）
VS2005C++な環境でネイテイブなC++でコンソールアプリケーションは
作れないのでしょうか？MFCも挑戦しようと思いましたが、又別物のようですし
初心者的にはどの方向で進んだら良いでしょう、小一週間悶々としています
634:628
06/02/18 16:32:13
ｽﾏｿ
× GUIが使えるWin32でアプリケーションを作りたくて
○ GUIで動作するWindowsアプリケーションを作りたくて
635:デフォルトの名無しさん
06/02/18 16:45:58
初心者ならC#へ行ってみてはどうかと惑わしてみる。
VS2005C++使った事無いけど、アンマネージド(ネイティブ)は作れるはずだ。
636:デフォルトの名無しさん
06/02/18 16:55:38
2005は普通に「Win32コンソールアプリケーション」でネイティブを作れるはずだが…
Expressだと違うのか？
637:デフォルトの名無しさん
06/02/18 17:01:58
>628
GUI でモノを作りたければ、素直に MFC に進んだ方がいいと思われ
C++/CLI はちと初心者にはお勧めできない。普通の方法では満足できなくなった玄人向け
だから
あとは、635 の進めるとおり、C# でモノを作ってみて満足できなくなったら、またこちらに
出戻ってくると言うのもいい
638:デフォルトの名無しさん
06/02/18 17:15:12
>>633
コンソールアプリケーションとテキストボックスのつながりがわからん
639:デフォルトの名無しさん
06/02/18 17:36:48
すんません、又間違えていました
CLRからWindowsフォームアプリケーション作成でした
640:デフォルトの名無しさん
06/02/18 21:12:37
他スレから誘導されてきました。
C++/CLIを使っているんですが、
自分のクラスライブラリのシングルトンのクラスにあるSystem::Drawing::Size型のプロパティを変更しようとしたら
p->Size = System::Drawing::Size(64, 64);
と設定はできるのですが、
p->Size.Width = 64;
のように個別に設定しようとしたら必ず0になってしまいます。
どうすれば個別に設定できるようになりますか。
641:640
06/02/18 21:26:55
投稿して気付いたのですが、Sizeの部分をハンドルにしたら設定出来るようになりました。
何故かがわからないですが・・・。
スレ汚しすいませんでした。
642:デフォルトの名無しさん
06/02/18 21:48:34
>>641
System.Drawing.Sizeは型値だから扱いが面倒だのう。
643:デフォルトの名無しさん
06/02/19 06:34:22
>>633
スレ違い
ｽﾚﾘﾝｸ(tech板)
644:デフォルトの名無しさん
06/02/19 14:36:44
>>641
というかそれはあまりよろしくない。たぶん。
p->Size = Size(64, p->Sizte.Width);
としなさい(こういうCLRの常識みたいなのもいるから
また複雑なんだよな>C++/CLI)。
645:644
06/02/19 14:43:34
にゃー、コード間違いすぎ
p->Size = Size(64, p->Size.Height);
こう。
646:デフォルトの名無しさん
06/02/19 15:20:04
そんなんわからん奴はC#やJavaも微妙だろ。
647:デフォルトの名無しさん
06/02/19 15:28:54
>>646
…まぁな。実体の追跡もできないレベルだし。
C#はまだ動かないだけで安全だけど、こういうやつには特にC++は使わせたくない。
メモリ関係のバグ大量コードを書く。しかもそういう場合デバッグビルドだと動いたり
することもあるから性質が悪い…。
648:デフォルトの名無しさん
06/02/19 20:48:42
Visual C++ 2005 Express Edition の環境で、はまってしまい、皆さんのお知恵を拝借したいです。
Webのダウンロードなのですが、
方法1
WebClient^ wc = gcnew WebClient();
Stream^ st = wc->OpenRead("URLﾘﾝｸ(www.yahoo.co.jp)");
Encoding^ enc = Encoding::GetEncoding("euc-jp");
StreamReader^ sr = gcnew StreamReader(st, enc);
String^ out = sr->ReadToEnd();
Debug::WriteLine(out);
これはうまくいきWebデータの取得ができます。
方法2
WebClient^ wc = gcnew WebClient();
Byte ^ myDataBuffer = wc->DownloadData("URLﾘﾝｸ(www.google.co.jp)");
Encoding^ enc = Encoding::GetEncoding("euc-jp");
String^ out = enc->GetString(data);
このコードだとコンパイルエラーです。
エラーメッセージは、
.\MainForm.cpp(50) : error C2440: '初期化中' : 'cli::array<Type,dimension> ^' から 'System::Byte ^' に変換できません。
with
[
Type=unsigned char,
dimension=1
]
この変換を実行可能なユーザー定義変換演算子がないか、または演算子を呼び出せません。
とあります。
バイト配列に入れたいだけなのに。
649:デフォルトの名無しさん
06/02/19 21:05:11
>>648
WebClient::DownloadData()の戻り値の型はcli::array<unsigned char>^。
Encoding::GetString()の引数もcli::array<unsigned char>^。
650:デフォルトの名無しさん
06/02/19 21:12:35
^ ←なんかコレうざい。よくわからないけど腹立たしい。
651:デフォルトの名無しさん
06/02/19 21:18:36
(^^:
652:デフォルトの名無しさん
06/02/19 21:20:18
^<T>^
653:648
06/02/19 21:44:16
>>649
Byte を cli::array<Byte> にしたところ、できました。
cli::array<Byte> ^ myDataBuffer = wc->DownloadData("URLﾘﾝｸ(www.yahoo.co.jp)");
Encoding^ enc = Encoding::GetEncoding("euc-jp");
String^ out = enc->GetString(myDataBuffer);
ばっちりです。これで先に進めます。
つい最近まで C++ Builder 使いだったので、いろいろと戸惑ってます。
ポインタは使えず、^ というものが必要だとわかるまで、延べ1日くらいかかってます。
勉強がてら少しずつ移植していきます。
どうもありがとうございました。
654:Pascal
06/02/19 23:09:23
>>650
呼んだ?
655:デフォルトの名無しさん
06/02/20 00:22:49
>>650
あなたの心が汚れてるからですよ(^^;;;
656:デフォルトの名無しさん
06/02/20 00:30:26
そんなばかな^^;
657:デフォルトの名無しさん
06/02/20 01:26:15
>>650-652
ヤベ、ツボにはまったｗ
658:デフォルトの名無しさん
06/02/21 10:07:18
>>422-423
＞ダイレクトに C++ を知らずに、C++/CLI に手を出すのは、止めた方がいいだろ
＞さっさとC#かVBで始めたほうがいいと思う。
とりあえずＣ＃で始めようと思った矢先、C++/CLI とかいうのが目に入って、
「ファイナライザいいな」とか思ってしまったんですが、
やっぱりＣ＃から始めることにします。
>>424
関数単位ですか。
つまり、関数呼び出しを共通化することで様々な実行環境にあるコードを一つのプログラムにまとめることができたと言うことでしょうかね。
659:デフォルトの名無しさん
06/02/21 11:10:22
>>658
ああ、C#にしたのか。まぁそうしとけ。C++/CLIはネイティブの知識(C++)とCLRの
知識(C#)が両方要求されるひどい言語だ。最低限どっちかぐらい自由に使える
ようになってからおいで。…両方自由に使えるぐらいじゃないと使える言語でも
ないかもしれないが。
ファイナライザ？C#にもあるぞ。というかCLR用語だそれ。
まぁDisposeがスタックオブジェクトのように書けることをいいたかったんだろうけど。
川俣とかが取り上げているほど、たいしたものじゃない。あの人は大げさに書く文体
が売りだからな。いい悪いは別にして。
660:デフォルトの名無しさん
06/02/21 21:17:52
通のお勧めは関数のオーバーライド
ディスポーズ・パターンの変形に目が眩んでちゃ、まだまだ
661:デフォルトの名無しさん
06/02/21 21:25:46
>>660 ポリモにならんじゃん
662:デフォルトの名無しさん
06/02/21 21:32:20
>>658
~hogeか!hogeが使われている場合に下のようなコードを自動生成してくれる。
GC.SuppressFinalize(this)がむき出しにならないだけスマートだね。VB.NETにもほしい機能だと思う。
void Dispose(bool disposing) { if (disposing) ~hoge(); else !hoge() }
void Dispose() { Dispose(true); GC::SuppressFinalize(this); };
void Finalize() { Dispose(false); }
deleteしたり { ClassA a(); ...; } でスコープから離れた場合は
Dispose()が呼び出されるだけでその場でGCされるわけではない。
663:デフォルトの名無しさん
06/02/22 00:50:01
!hogeなんてあったんだ
664:デフォルトの名無しさん
06/02/22 07:21:27
>>662
いや、えーと、このスレにいる以上知っている。
ildasmでも確認したしな。ああ、そうか、それをC++/CLI用語でFinalizerというのか。
665:デフォルトの名無しさん
06/02/22 12:42:51
>661
おまいはC++/CLIにおける関数上書きの奥の深さに気付いていない
ここに IEnumerable を継承したインターフェイス IEA と IEB がある
その双方を実装した ref クラス RAB は明示的オーバーライドによって列挙の方式を
IEA と IEB によって変更できる
つまり、RAB から取得したインターフェイスによって、for each のオーダーを自由に
選択できるわけだ
666:デフォルトの名無しさん
06/02/22 16:05:53
MSがC++/CLIを捨てるのは何年後くらいですか？
667:デフォルトの名無しさん
06/02/22 16:13:12
MFCの如くこの劣悪貧を１０年使うかも。
C++ってだけでもSTLやBoostが混ざってくると複雑なのに、正直CLIはカンベンて感じだおね。
668:デフォルトの名無しさん
06/02/22 17:22:04
>>667
駄菓子菓子、これがないとネイティブとかからCLRが非常に使いにくい。
ほら、次でWPFとかなんかたくさんあるし。
669:デフォルトの名無しさん
06/02/22 23:36:01
マイクロソフトがもうｲﾗﾈと思ったら容赦なく捨てにくるさ。
670:デフォルトの名無しさん
06/02/23 02:00:23
>>669
そりゃ日本だけ。海外ではVBerが反乱おこして、msも今では Love VB, Love C#だとよ。
671:デフォルトの名無しさん
06/02/23 02:53:32
C#は、VC++とVBの中間を行くような言語だから、
どっちからも反発が強いだろうね。
672:デフォルトの名無しさん
06/02/23 03:03:54
反発はしないけど、C++で出来るなら C++ Nativeでやっちゃうよ。
必要なとこだけ CLIで .Netなんてライブラリ感覚で使えばいい。
673:デフォルトの名無しさん
06/02/23 03:20:44
/clrでNativeコンパイルすると遅くなる？
674:デフォルトの名無しさん
06/02/23 08:50:40
>673
>348
675:デフォルトの名無しさん
06/02/23 09:37:51
>>669
要るだろ。
だって、C++市場をCLIで混乱させることにより、
開発者をWin＠ﾌﾞﾋﾞ or Win＠Ｃ丼で留めておける。
676:デフォルトの名無しさん
06/02/23 10:00:24
>>674
遅くなるのは事実としても、何で遅くなるんだろ?
異なるライブラリがリンクされるからか? lstrcmp自体の実装が異なるのか?
それとも呼び出し時にスタックチェックでも入ってるのかね…。
677:デフォルトの名無しさん
06/02/23 14:21:46
>676
単純なループでは簡単に結論が出ない問題かもしれない
ちなみに漏れの環境では
CLR 6 - 7 sec.
Native 8 sec.
となった。意外だがCLRの方が早い
Win のほうは -02 -0t を付けた状態で、CLRの方はデフォルトのリリースモジュールだ
678:
06/02/23 22:30:11
>>670
そんな話しきいたことネ
679:デフォルトの名無しさん
06/02/23 22:47:11
誰か、C++/CLI で吐いた実行ファイル、
mono で動かした奴いる？？
以前 VS.NET 2003 の C# で書いたコンソールアプリなら
mono で動かしたことあるんだけど。
680:デフォルトの名無しさん
06/02/23 23:22:55
mono がそもそも .net framework 2.0 に対応してたか？
してるなら、/clr:pure で動くだろう
681:デフォルトの名無しさん
06/02/24 08:17:28
nullptr
682:デフォルトの名無しさん
06/02/24 11:48:08
ｶﾞｯ^
683:デフォルトの名無しさん
06/02/24 17:24:15
>>678
URLﾘﾝｸ(blogs.msdn.com)
ケツの穴が広がるぐらい、ハードに読めや。
684:デフォルトの名無しさん
06/02/24 21:07:35
>>683
良く読んだよ
>表の顔の日記
> 裏の顔の日記
> さっさと消えてくんないかな。 うざいんだけど、 まじで。
685:デフォルトの名無しさん
06/02/25 04:29:20
という電波でも飛んでるのか?
686:648
06/02/25 11:39:03
また教えてください。
C++での構造体の以下の宣言
typedef struct tagHOGE{
int x;
long y[4];
}HOGE;
これをマネージ環境にしようとした場合
typedef struct tagHOGE{
int x;
long y[4]; ← ここが混合型らしい
}HOGE;
.\MainForm.cpp(26) : error C4368: 'y' をマネージ 'HOGE' のメンバとして定義できません。混合型はサポートされていません
というエラーが出ます。
単に4つのlong型の配列の定義がしたいのですが、マネージ環境では、どのようなやり方があるでしょうか?
687:デフォルトの名無しさん
06/02/25 11:43:26
typedef struct → typedef value struct
では？
688:648
06/02/25 12:05:23
>>687
そうです。コピペ間違いました。
value struct HOGE{
int x;
int y[4];
};
と記述してます。
689:デフォルトの名無しさん
06/02/25 12:17:18
・・・value型使わず、ネイティブ型で定義すれば？
690:デフォルトの名無しさん
06/02/25 12:20:37
あとは ref にして array<long>^ y で宣言して、コンストラクタで初期化するか
691:デフォルトの名無しさん
06/02/25 12:23:04
value struct HOGE
{
int x;
array<long>^ y;
};
はコンパイルが通るが、仕様上これでいいのか？
692:デフォルトの名無しさん
06/02/25 12:38:17
ok
ハンドルは nullptr で初期化される
693:648
06/02/25 12:58:50
皆さん、早速のレス、ありがとうございます。
>>689
ネイティブで定義すればできることは確認してます。
ただそうすると少し複雑なソフトを組んだ場合、きちんとメモリの後処理をしないと
メモリリークが発生するので、マネージにすればメモリガベージの効用であまり複雑に
考えなくともよいかな、と思っているのです。
>>691
そのやり方もわかります。
各関数で、
void func1(void)
{
HOGE wk1;
wk2.y[2] = 123;
}
void func2(void)
{
HOGE wk2;
wk2.y[2] = 456;
}
というようなことをしたいのです。
2～3日あがいてみて自分ではできなそうだったら、ネイティブで定義してやっていきます。
マネージ環境に慣れていけば、そのうち、何か気づきがあると信じて進むしかありません。
694:デフォルトの名無しさん
06/02/25 13:05:44
2～3日あがくなら2～3日かけてマニュアル読んだほうがいいような気がする
695:デフォルトの名無しさん
06/02/25 13:45:46
>>693
値型にGCを求める必要がある？
696:デフォルトの名無しさん
06/02/25 14:23:50
C++/CLIのスレ見てると無意味にvalueを使いたがる人が多い気がするな。
valueは動作に癖があるから基本refで作ったほうがいいと思う。
697:デフォルトの名無しさん
06/02/25 16:22:08
value使ったほうが処理速度が速いとでも思い込んでいるんじゃ？
クセがあるには同意。
698:648
06/02/25 17:38:04
いろいろとサイトをまわりまして、以下のようにしたところ動いているように見えます。
public ref struct HOGE {
int x;
array<long>^ y;
HOGE() {
y = gcnew array<long>(4);
}
};
void func(void)
{
HOGE^ abc = gcnew HOGE;
abc->x = 10;
abc->y[2] = 20;
for(int i=0; i<4; i++){
Debug::WriteLine(abc->y[i]);
}
}
検討違いのコードでなければよいですが。
みなさん、いろいろとレスありがとう。
699:デフォルトの名無しさん
06/02/25 20:55:45
>>698
これでも平気。
void func()
{
HOGE abc;
abc.x = 10;
abc.y[2] = 20;
for (int i = 0; i < 4; i++) {
Debug::WriteLine(abc->y[i]);
}
}
700:デフォルトの名無しさん
06/02/25 22:33:45
C++は真のローカル変数を使える言語なんだから、（ユーザー定義オブジェクト
がスタック上に配置できる）GCが必要な場合ってのはそんなに多くはならない
ってビョーン先生が言ってた。
701:デフォルトの名無しさん
06/02/25 23:11:17
>>700
それはわかるけれど、C++/CLIはCLIの世界にあわせないといけないからさ。
702:デフォルトの名無しさん
06/02/25 23:42:48
C++/CLIは二つの言語が同居しているようなものだからな。
C++の拡張というより建て増し。
703:デフォルトの名無しさん
06/02/25 23:49:05
>699
それだと、配列のサイズが3で固定されちゃわない？
704:デフォルトの名無しさん
06/02/26 00:22:20
>>702
二世帯住宅
705:デフォルトの名無しさん
06/02/26 00:49:18
ビョーン先生が取り扱っている案件はそうかもしれんけどな。
動的にオブジェクトが増えたり減ったりする案件のほうが多い。
706:デフォルトの名無しさん
06/02/26 00:56:47
>>700
しかしビョーン先生はGCをそんなに否定していない。
既存のC/C++のコードと互換性を保ったまま導入できるのなら、
C++に入れてもいいというようなことをD&Eで書いている。
707:デフォルトの名無しさん
06/02/26 20:57:17
>>705
vector使えばええやん。メンバかローカルにしておけばdeleteいらん。
708:デフォルトの名無しさん
06/02/26 21:08:56
>>707
グローバルでもdeleteいらんぞ
709:デフォルトの名無しさん
06/02/26 21:14:38
別に GC なんて C++/CLI の利点じゃないだろ
単に .net framework を既存の C++ と混同することなく使えるってとこが一番重要さ
C++/Smalltalk とか C++/Squeak とか出てこないかな
710:デフォルトの名無しさん
06/02/27 01:56:21
【初心者歓迎】C/C++室 Ver.25【環境依存OK】から誘導されてきました( ｀・ω・´)ﾉﾖﾛｼｸｰ
VC8でopenFileDialogを使いたくて
MSDNのソースを試してみようと
URLﾘﾝｸ(msdn2.microsoft.com)
説明を読み
フォームに Button を配置して
using namespace System;を宣言して、
下記のコードを試したのですがエラーが出ます、何か読み込んでいないファイルがあるか設定のミスだと思うのですが、原因が分かりませんよろしくお願いします。
private:
voidbutton1_Click(Object^/*sender*/,System::EventArgs^/*e*/)
{
Stream^myStream;
OpenFileDialog^openFileDialog1=gcnewOpenFileDialog;
openFileDialog1->InitialDirectory="c:\\";
openFileDialog1->Filter="txtfiles(*.txt)|*.txt|Allfiles(*.*)|*.*";
openFileDialog1->FilterIndex=2;
openFileDialog1->RestoreDirectory=true;
if(openFileDialog1->ShowDialog()==::DialogResult::OK)
{
if((myStream=openFileDialog1->OpenFile())!=nullptr)
{
//Insertcodetoreadthestreamhere.
myStream->Close();
}
}
}
error C3083: 'DialogResult': '::' の左側のシンボルには、型を指定しなければなりません
error C2039: 'OK' : '`global namespace'' のメンバではありません。
error C2065: 'OK' : 定義されていない識別子です。
711:デフォルトの名無しさん
06/02/27 07:06:19
>>710
System::Windows::Forms::DialogResult::OK とフルで書く。
712:デフォルトの名無しさん
06/02/27 07:26:28
>>711
最後まで仕様が揺れた所かも知れないね。
713:デフォルトの名無しさん
06/02/27 10:47:00
この状況って System::Windows::Forms まで using で指定しているから、単純にグローバル
スコープ指定していることが問題なんじゃね？
12行目の ::DialogResult を意味なく、:: で始めるな、と
714:デフォルトの名無しさん
06/02/27 11:06:47
>>713
ところがどっこい
DialogResult::OK と書くと今度は
System::Windows::Forms::Form::DialogResultが無いというエラーになる。
using namespace は探しに行ってくれないらしい。
715:デフォルトの名無しさん
06/02/27 11:38:26
ん、サンプルだと :: で始めてるな
っていうか、>710 って名前空間 System しか宣言してないって言ってるが
using namespace System::Windows::Forms が宣言されている環境では
::DialogResult::OK でエラーなくコンパイルできるな
先頭 :: の名前検索ルールって、グローバル指定じゃないんだ・・・
716:デフォルトの名無しさん
06/02/27 13:38:23
>>714
using namespace System::Windows::Forms;
してあるということ? その"Form"は何よ?
>>715
namespace N { int x; };
using namespace N;
int x;
int f(void) { return x; } ←このxはambiguousになる。それで正しい。
717:715
06/02/27 13:45:08
まず、 >710 の問題は、単に System::Windows::Forms が using 指定していないから
using namespace System::Windows::Form;
を付ければおっけー
>716
::DialogResult ってなっているから、先頭に :: を付ける場合ってグローバル名前空間の
名前空間指定だと思ってた。カレント解決してくれるんだ
718:716
06/02/27 13:55:54
>>717
いや、「正しい」はグローバル参照の方。
> using namespace System::Windows::Form;
> を付ければおっけー
Forms
719:715
06/02/27 18:46:14
ということは、MSの実装はバグかMS独自仕様か、微妙なとこだな
720:710
06/02/27 19:46:54
皆さんどうもありがとう、遅くなってすみません
今帰宅しました
ヘッダー部分ですが
#pragma once
#include <fstream>
#include <vcclr.h>
#include <stdlib.h>
namespace hoge {
using namespace System;
using namespace System::IO;
using namespace System::ComponentModel;
using namespace System::Collections;
using namespace System::Windows::Forms;
using namespace System::Data;
using namespace System::Drawing;
using namespace std;
と宣言しているのですが
皆さんの、ご指導通りやってみましたが、
error C3083: 'DialogResult': '::' の左側のシンボルには、型を指定しなければなりません
error C2039: 'OK' : '`global namespace'' のメンバではありません。
error C2065: 'OK' : 定義されていない識別子です。
.\hoge(8) : error C2337: 'STAThreadAttribute' : 属性が見つかりません。
とこんな感じで、
ﾜｹ 川・∀・川 ﾜｶﾒです
721:デフォルトの名無しさん
06/02/27 20:17:53
>>720
その一
using namespace ...
using namespace ...
namespace hoge {
と順番を変えたら ::DialogResult::OK でコンパイルが通る。
その二
hoge::DialogResult::OK でコンパイルが通る。
恐らく下のも通るはず。
[hoge::STAThreadAttribute]
その三
namespace hoge { を使わずすべてGlobalに書く
これが仕様なのかバグなのかは俺にもわかんね～
722:デフォルトの名無しさん
06/02/27 20:17:53
気になって少々試してみたが、関数内でusingすればDialogResult::OKと書いてもエラーにならなかった。
void button1_Click(System::Object^ sender, System::EventArgs^ e)
{
using ::System::Windows::Forms::DialogResult;
OpenFileDialog ofd;
ofd.InitialDirectory = "c:\\";
ofd.Filter = "txtfiles(*.txt)|*.txt|Allfiles(*.*)|*.*";
ofd.FilterIndex = 2;
ofd.RestoreDirectory = true;
if (ofd.ShowDialog() == DialogResult::OK)
723:デフォルトの名無しさん
06/02/27 20:39:09
ほとんど素のC++の話題になってるけど、まあいいか。
なんでDialogResultが重なってんだろ?
using ::System::Windows::Forms::DialogResult;
if (ofd.ShowDialog() == OK)
か
using ::System::Windows::Forms;
if (ofd.ShowDialog() == DialogResult::OK)
ならわかるけど。
724:デフォルトの名無しさん
06/02/27 20:45:59
>>723
C++/CLIの列挙子は列挙型の中のスコープにある。
725:デフォルトの名無しさん
06/02/27 23:10:50
>>721
*.h でこれをやると using が include 先に伝播してしまうので思わぬ名前の重複が起きてしまう。
＞using namespace ...
＞using namespace ...
＞namespace hoge {
妥協案としては、メンバー関数の実態を *.c に分離してから::DialogResult::OKと指定する。
using namespace hoge;
namespace hoge {
void hoge::button1_Click(System::Object^ sender, System::EventArgs^ e)
{
if (ofd.ShowDialog() == ::DialogResult::OK)
726:デフォルトの名無しさん
06/02/28 00:29:25
ISO C++だとusingディレクティブは名前を可視にするだけで、
usingディレクティブが書かれた名前空間へ名前を持ってくるものではなかったはず。
namespace foo {int x;}
namespace bar {int y;}
using namespace foo;
using bar::y;
::x = 10; //NG. x = 0;或いはfoo::x = 0;としなければならない。
::y = 20; //OK. もちろんy = 0;或いはfoo::y = 0;も問題ない。
727:デフォルトの名無しさん
06/02/28 00:59:11
namespace N { namespace M { enum E { zero = 0 }; }; };
using namespace N;
int f(void) { return M::zero; }
あるいは、
namespace N { namespace M { enum E { zero = 0 }; }; };
using namespace N::M;
int f(void) { return zero; }
なんじゃないのか?
// Eのenum名指定なしでanonymous enumにしても同じ。
728:デフォルトの名無しさん
06/02/28 01:38:12
>>727
CLRタイプのenum class と Cタイプのenumの２種類あって、
後者の話ならそのとおり。
729:710
06/02/28 21:38:39
皆さんのおかげで、openFileDialogを動かす事ができたのですが
肝心な事を忘れていました、ファイルを選択してボタンを押しても
実際にファイルが開かないんですよね（；^ω^）
// Insert code to read the stream here.
ってコメントアウトしてある部分が気になるけど、ここに何か
書かないといけないのかな？
730:デフォルトの名無しさん
06/02/28 21:43:05
教えてクンマンセー！
731:デフォルトの名無しさん
06/02/28 21:53:32
コメントが何のために有るのかわかってるのか？
っていうか読めよ。
732:710
06/02/28 21:54:54
>>731
英語読めません(´･ω･`)
733:デフォルトの名無しさん
06/02/28 21:57:00
>>732
んじゃ、英語の勉強から。英語書けないならともかく、読めないんじゃ
プログラミングなんてやってられない。
734:デフォルトの名無しさん
06/02/28 22:35:55
翻訳サイトも使えないようなヤツはプログラミングやめれ
735:デフォルトの名無しさん
06/02/28 22:40:27
ていうか、732は710の偽なんですが
736:732
06/03/01 00:45:52
俺は嘘つきだから俺の言うことは嘘ばっかりさ。さてこの嘘はホントかわかるかねｗｗｗ
737:デフォルトの名無しさん
06/03/01 01:08:24
そんなおもしろくないよ?
738:デフォルトの名無しさん
06/03/01 01:32:16
>>733
ひまわりが専門なので関係ないでしょ
739:710
06/03/01 02:21:51
ﾟ･*:.｡..｡.:*･゜ヽ( ´∀｀)人(´∀｀ )ノ･゜ﾟ･*:.｡..｡.:*
できたYO!
英語のサイトで(・∀・)ｲｲ!!ヒント見つけて
多少漏れのセンスでアレンジしましたがなにか
つーかさー"StreamReader c++ textBox"で具具っても
C#のサンプルや話題が多くて、参考にならなかったんで
英語でぐぐったら
ｷﾀｷﾀｷﾀｷﾀ━━(ﾟ∀ﾟ≡(ﾟ∀ﾟ≡ﾟ∀ﾟ)≡ﾟ∀ﾟ)━━!!
やっぱり本場はいいサンプルが多いな、でもそのものズバリはなかったが
{
// Insert code to read the stream here.
System::IO::StreamReader ^ sr = gcnew
System::IO::StreamReader(openFileDialog1->FileName);
String ^temp = sr->ReadToEnd();
textBox2->Text=temp;
//MessageBox::Show(sr->ReadToEnd());
sr->Close();
myStream->Close();
}
740:デフォルトの名無しさん
06/03/01 02:32:10
C++/CLI の場合でも .NET Framework のサンプルがほしければ
C#やVBのをそのまま使えるってのに
741:710
06/03/01 02:37:58
|∀・).｡oO(・・・)
そうなのか？
742:デフォルトの名無しさん
06/03/01 02:38:23
ｶﾞﾝｶﾞﾚ
743:710
06/03/01 02:43:27
ﾑﾘｯﾎﾟ
744:デフォルトの名無しさん
06/03/01 07:19:26
>>740 うむ。
ちょっと間接参照の記述が違うくらいで、
流れは C# のコードのままでいいな。
まぁそれが C++/CLI の真骨頂でもある。
745:デフォルトの名無しさん
06/03/01 14:15:46
>>739
C++/CLIなんだからいちいちgcnewする必要はないと思う。
746:デフォルトの名無しさん
06/03/01 14:50:01
>>739
つかCloseもfinally句に書いてないし。
C#ならusing、C++/CLIならスタックオブジェクトにしろよなほんと。
747:デフォルトの名無しさん
06/03/01 16:30:41
で、STLはどうしてるんだ、おまえら?
748:デフォルトの名無しさん
06/03/01 16:49:26
C++/CLI でGUIなアプリつくるべ、と、フォームをデザインして
遊んでます。で、みなさん、アプリで必要となる大量の
変数たちは、class Form1 のメンバとしてずらずら宣言してしまって
構わないんでしょうか？
今までは UNIX 系でのコンソールアプリ主体で、自前の
アプリケーションクラスを用意して main() の中から
そいつをインスタンス化して、という感じでやってました。
Windows でのグラフィカルなアプリでの作法では、
自動生成された class Form1 にどんどんメンバを
追加しちゃっていいんですか？
当然イベントハンドラなどはデザイナで追加されていくわけで、
手動で追加したメンバのためにフォームデザイナが混乱して
しまわないかすごく不安です。
749:デフォルトの名無しさん
06/03/01 16:54:58
STLが無い、C++なんて。
クソ。
750:デフォルトの名無しさん
06/03/01 16:57:44
>>749 え？C++/CLI で STL つかえないの？
751:デフォルトの名無しさん
06/03/01 17:06:05
>>750
ネイティブ型に対しては使える。
そしてマネージ型対応のSTL/CLI(旧称STL.Net）がVC++ 2005と同時に公開されるはずだったのだが、
伸びに伸びて未だ公開されていない。
URLﾘﾝｸ(www.microsoft.com)
いっそのこと俺たちで作るかｗ。
752:デフォルトの名無しさん
06/03/01 17:18:06
>>751 あ～びっくりした。
そうだよな、ネイティブ型に対しては使えるよな？
C++ で書きためてきた std::vector 使ってる
数値計算用のライブラリがあって、どうしても
それから逃れられない + DirectX で可視化したい、
という要求があって、それ満たすには C++/CLI しか
ないだろ、ってことでこれから使おうと思ってたんで、
ちょっと焦った。
753:デフォルトの名無しさん
06/03/01 18:24:32
>>752
いやいやいや、お前DirectXをなんと心得る？
754:デフォルトの名無しさん
06/03/01 19:09:05
>>753 まだ、OpenGL のかわりみたいなもん、
くらいの認識です。頂点データの扱いとか
ぜんぜんちがうんですかね？
その話題はスレ違いですが。
目的は動き回る多数の分子模型の
ようなものなんですが。
755:デフォルトの名無しさん
06/03/01 19:16:26
DirectXはまだネイティブがメインなのにどうしてSTLの無いC++/CLIを無理に使おうとするのか
756:デフォルトの名無しさん
06/03/01 19:28:40
com::ptr 型がそこにあるから
757:デフォルトの名無しさん
06/03/01 19:29:40
OpenGLでもいいし。
758:デフォルトの名無しさん
06/03/01 19:40:32
>>755 いや、それすらまだ知らないんですよ。
普通に次元の可視化するときに、
フォームにぺたぺたとやってえらく簡単に
できたもんで、この勢いで 3D もいける？
とか思ったわけです。
>>757 いわれていれば、そうかも
759:デフォルトの名無しさん
06/03/01 20:01:27
>>758
そのノリでやりたいんなら(ビジネスっていうかグラフ化とかな)、
確かにマネージのAvalonが向いてる。けどもまだない。残念。
DirectXとOpenGLは例えばDirectXはCOMだったりとか細かくは違う。
けど理論はあんまり違わんので好きなほうでどうぞ。
一般的には凝ったことしなければOpenGLのほうが簡単。
760:デフォルトの名無しさん
06/03/01 20:11:40
スレ違いなんだが、VTKとかいろいろあるじゃん?
> フォームにぺたぺたとやってえらく簡単に
> できたもんで、この勢いで 3D もいける？
そんな子どもっぽい理由じゃなくて、(発端じゃなくて直線的な選択の事ね)
道具くらいちゃんと自分で選べるようになろうよ。
URLﾘﾝｸ(sal.linet.gr.jp) でも漁れ。多くがWindowsもOK。
OpenGLやDirectXを直接叩くなんて馬鹿らしいよ。
761:デフォルトの名無しさん
06/03/01 20:27:15
>>760 THX
論文に貼る図だと、動画じゃないので普通に
gnuplot で作ってるんですが、プレゼンだと
やっぱ動かなきゃな、ってことで取り組んでます。
色々あるんですね、こりゃ楽しそうだ。
762:710
06/03/01 21:11:31
今晩も盛り下がっていますね皆さん( ノﾟДﾟ)こんばんわ
>>744間接参照の仕方を巧く解説してるサイトってない？
>>745newでは困憊羅君が、言うこと聞いてくれませんでした
>>746スタックオブジェクトって、なに？グラフや絵を描くメソッドのことかな？と聞いてみる
夕べ
URLﾘﾝｸ(www.athomejp.com)
ここのソースをC++に書き換えたらどんな風になるのかな？
C#の.の使い方がポイントだと思うが、もう少し理解できない
多分>>744の言っていた、間接参照の仕方の事だと思うのだが
C++の場合漏れは、::が出てきたら
何々の何々と読んでいるのだが、C#の.の読み方（解釈）教えてください
//ファイルを指定させる
DialogResultresult=openFileDialog1.ShowDialog();
if(result==DialogResult.OK)
{
//指定されたファイルを読み取る
System.IO.Streamstream=openFileDialog1.OpenFile();
System.IO.StreamReaderstreamR=
newSystem.IO.StreamReader(stream,
System.Text.Encoding.Default);
stringstr=streamR.ReadLine();
//ファイルを読み取り
while(str!=null)
{
//デバッグ出力
Debug.WriteLine(str);
str=streamR.ReadLine();
}
//StreamReaderをクローズ
streamR.Close();
}
763:デフォルトの名無しさん
06/03/01 21:42:20
>>762
C#の . はC++(/CLI)だと、 . -> ::のどれか。
. 値（ポインタ・ハンドルでないもの）と参照（ネイティブのT&とマネージドのT%）
-> ポインタ・ハンドル
:: 静的メンバやその他（クラス内で親クラスを参照するときなど）
なるべく同じようにC++/CLIへ写すとこうなる。
//ファイルを指定させる
DialogResult result = openFileDialog1.ShowDialog();
if (result == DialogResult::OK)
{
// 指定されたファイルを読み取る
System::IO::Stream^ stream = openFileDialog1.OpenFile();
System::IO::StreamReader^ streamR =
gcnew System::IO::StreamReader(stream, System::Text::Encoding::Default);
System::String^ str = streamR->ReadLine();
// ファイルを読み取り
while (str != nullptr)
{
// デバッグ出力
Debug.WriteLine(str);
str = streamR->ReadLine();
}
streamR->Close();
}
（続く）
764:デフォルトの名無しさん
06/03/01 21:43:14
これをスローカル変数を使うようにして、
個人的にReadLineが2度もソース上に現れるのが気になったのでそれを修正したもの。
//ファイルを指定させる
DialogResult result = openFileDialog1.ShowDialog();
if (result == DialogResult::OK)
{
// 指定されたファイルを読み取る
System::IO::Stream^ stream = openFileDialog1.OpenFile();
System::IO::StreamReader streamR(stream, System::Text::Encoding::Default);
System::String^ str;
// ファイルを読み取り
do
{
str = streamR.ReadLine();
// デバッグ出力
Debug.WriteLine(str);
}
while (str != nullptr);
}
765:デフォルトの名無しさん
06/03/01 21:48:12
>>764
Debug.WriteLine に nullptr 渡すのってありだっけ。
}
766:デフォルトの名無しさん
06/03/01 22:15:08
>>765
どうみてもまずいですね。
本当にありがとうございました。
そう書こうと思ったけど、その前に試してみた。
System::Diagnostics::Debug::WriteLine(static_cast<String^>(nullptr));
全く問題なかった。
ついでに言うとそれ::にするの忘れてた。すまん。
結局こうすればよかったな。
while (System::String^ str = streamR->ReadLine())
{
// デバッグ出力
System::Diagnostics::Debug::WriteLine(str);
}
767:748
06/03/02 04:01:28
盛り上がってるところ済みません。
どなたか >>748 に答えてくださるかた
おられませんでしょうか・・・
768:デフォルトの名無しさん
06/03/02 05:10:09
>>763
解説Thanks ☆☆** v(￣ー￣)v**☆☆ Thanks
769:デフォルトの名無しさん
06/03/02 06:39:27
>>762
スタックオブジェクト＝auto変数
770:デフォルトの名無しさん
06/03/02 07:16:31
C++/CLIで
char *ptr;
ptr=(char *)malloc(sizeof(hoge));
free(ptr);
が使えるのに感動した！
771:デフォルトの名無しさん
06/03/02 07:41:26
>>767
シングルウィンドウのアプリケーションならそれでいいと思う。
772:デフォルトの名無しさん
06/03/02 09:47:47
質問させてください。
System::Collections::Generic::ListかSystem::Collections::ArrayListで
要素へのinterior_ptrを得る方法はないでしょうか。
ToArray()はコピーを返すのでだめでした。
773:デフォルトの名無しさん
06/03/02 19:35:49
>>772
ArrayList や List では無理、固定サイズの配列ならいける。
array<int>^ x = { 10, 20, 30, 40, 50 };
interior_ptr<int> r = &(x[3]);
774:デフォルトの名無しさん
06/03/02 23:43:37
VS2003のC++で書いた
int __pin* px = &pX -> x;
こういう、書き方はVC8では通らないようですね？
775:デフォルトの名無しさん
06/03/02 23:50:15
>>774
cli::pin_ptr<int> px = &pX->x;
776:デフォルトの名無しさん
06/03/03 08:25:28
>774
/clr:oldSyntax
777:デフォルトの名無しさん
06/03/03 20:40:09
おっすオラ悟空
C++/CLI コンソールアプリの main では
コマンドライン引数として String^ の array への ^ が
渡されるんだけど、今まで使ってたコマンドライン処理
ルーチンに int argc, char** argv って感じの
おなじみのアンマネージドな形式で渡したい。
簡単な方法無い？？？？？
778:デフォルトの名無しさん
06/03/03 20:49:34
>777
普通に int main(int argc, char**argv) で宣言すれば？
C++/CLI は CLI 拡張であって、旧来の機能がなくなった訳じゃない