06/03/12 16:10:10
managed C++ → C++/CLI
(p)URLﾘﾝｸ(www.microsoft.com)
［特集］ Visual C++ 2005 いままたC++が熱い！「C++/CLI」として大進化したVisual C++ 2005
(p)URLﾘﾝｸ(www.atmarkit.co.jp)
Calling Native Functions from Managed Code
(p)URLﾘﾝｸ(msdn2.microsoft.com)(en-US,VS.80).aspx
C++/Cli Essentials
(p)URLﾘﾝｸ(www.amazon.com)
Shared Source Cli Essentials
(p)URLﾘﾝｸ(www.amazon.co.jp)
C++/CLI設計者のblog
(p)URLﾘﾝｸ(blogs.msdn.com)
(p)URLﾘﾝｸ(blogs.msdn.com)
STL.NET
(p)URLﾘﾝｸ(www.microsoft.com)
(p)URLﾘﾝｸ(www.dinkumware.com)
C++の今後
(p)URLﾘﾝｸ(216.55.183.63)
3:デフォルトの名無しさん
06/03/12 19:15:06
前スレで gcroot と auto_gcroot の存在を教えてもらったんですが、
その後いろいろとググってみたところ、あんまり使われていない
みたいですね。というか、このテンプレートって標準なんだろうか。
なんか裏技でそのうちひっそりと使えなくされてしまうなんて
ことないかちょっと不安。
4:3
06/03/12 19:37:30
ごめん、嘘
auto_gcroot Class
URLﾘﾝｸ(msdn2.microsoft.com)
C++/CLI の規格というわけじゃなくて、VC++ の独自な
テンプレートクラスってことらしい。
逆に ref class の中に std::auto_ptr<NativeClass> みたいに
ネイティブクラスへのポインタを持たせられる？とか期待して
みたけど、それらしいのが見つからなかった。
ref class auto_handle なんてのが見つかったけど、
なんか意味あるんだろうか。普通のハンドルとどこが違うんだろう。
URLﾘﾝｸ(msdn2.microsoft.com)
5:3
06/03/12 19:43:45
Mixing Native and Managed Types in C++
URLﾘﾝｸ(weblogs.asp.net)
標準的なモノはなくて、 std::auto_ptr もどきの
ref struct AutoPtr を自前で作れ、ってことか。
ハッ!? もしかしてぜんぜん追っかけてなかったけど、
STL.NET には含まれてるのか？？
#この程度の話題って、くだスレの方がいい？
#棲み分け具合がまだ把握できてない
6:デフォルトの名無しさん
06/03/12 19:47:50
C#の話は、禁止だから、そのつもりで。
ここは、C++/CLIのスレだからな。
C#を勧める奴は、C#スレにいけ。
7:3
06/03/12 19:56:27
>>6 してないじゃん。gcroot って、C# とは無縁だよ？
そりゃ System::Runtime::InteropServices::GCHandle を
ラップしてるわけだから .NET Framework とは縁があるけど。
なにか過剰反応してるんじゃないですか?
8:デフォルトの名無しさん
06/03/12 19:58:01
>>7
前スレにいたアレなやつだ。
9:デフォルトの名無しさん
06/03/12 21:33:22
>>4
auto_handleはauto_gcrootが参照クラスになった感じのようだ。
URLﾘﾝｸ(msdn2.microsoft.com)(VS.80).aspx
URLﾘﾝｸ(msdn2.microsoft.com)(VS.80).aspx
生のハンドルと違ってスコープを抜けるときにデストラクタが呼ばれると言う利点は存在するようだ。
URLﾘﾝｸ(msdn2.microsoft.com)(VS.80).aspx
自動変数にすることに比べて利点がわからないけど。
10:3
06/03/12 22:15:20
auto_gcroot って #include <msclr/auto_gcroot.h> しないと
使えないんだね。名前空間は msclr::auto_gcroot になってる。
一方 gcroot の方は #include <vcclr.h> で自動的に
#include <gcroot.h> されて使えるようになる。
名前空間はグローバルになってる。
う～む、なんで扱いが違うんだろう。というか、gcroot が
グローバルな名前空間で宣言されているのが気持ち悪いな。
11:3
06/03/12 22:18:24
たぶん gcroot も msclr::gcroot に配置すべきなんだろうな。
gcroot.h のコメントでは次のように書かれているし。
Use this class to declare gc "pointers" that live in the C++ heap.
Example:
struct StringList {
msclr::gcroot<String^> str;
StringList *next;
StringList(); // should have ctors and dtors
~StringList();
};
12:デフォルトの名無しさん
06/03/12 22:39:08
>>10
直接<msclr\gcroot.h>をインクルードすればよい。
<vcclr.h>の中では<gcroot.h>がインクルードされていて、
<gcroot.h>が<msclr\gcroot.h>をインクルードしている。
<msclr\gcroot.h>は<gcroot.h>からインクルードされると名前空間を使わないようにされている。
直接ヘッダを見てみたらそうなっていた。
13:3
06/03/12 22:56:32
>>12 THX
msclr\gcroot.h っていうディレクトリと名前空間 msclr から
考えて C++/CLI の標準仕様には gcroot, auto_gcroot は
入れないつもりなのかな。しかしこれが無いと困る場面も
あるんだけどなぁ。標準に入れてくれ>MSの人
14:デフォルトの名無しさん
06/03/13 00:32:58
>13
言語上の本道は混合型の導入になるから、正式仕様にはならないんじゃないかな
STL/CLIも混合型が使えるようになったら正直いらないし
15:デフォルトの名無しさん
06/03/13 01:35:07
> おそらく、.NET開発でデファクトスタンダードに最も近い
まじかよ
16:デフォルトの名無しさん
06/03/13 02:47:59
混合型もいいけどコンパイラスイッチで、
ぱちっと切り替えられるほうがいいな。
逝ったりきたりすると遅くなりそう...
17:デフォルトの名無しさん
06/03/13 02:54:26
>>15
マジなんだよ。C#とか言うヤツの気がしれんわ。
18:3
06/03/13 04:27:03
>>14
今の ECMA の規格じゃぁ mixed type はダメなんだったっけ。
Mixed type に言及してる文献はあるけど、標準化には入ってこないのかな。
URLﾘﾝｸ(std.dkuug.dk)
URLﾘﾝｸ(www.gotw.ca)
19:デフォルトの名無しさん
06/03/13 05:06:37
----以降 C# は駄目とか C# じゃなきゃ駄目とかいう過激派は発言禁止----
20:デフォルトの名無しさん
06/03/13 05:19:37
し、C♯じゃなきゃだめなんていってないじゃないっ！
あんたのほかにも代わりはいくらだっているんだから！！！
21:デフォルトの名無しさん
06/03/13 08:39:23
>18
だめっつーより、開発予定なんだろうけど
URLﾘﾝｸ(signe.japan.webmatrixhosting.net)
実際のスケジュールはどうなんだろうね。デリゲート・コンストラクタの方が先に実装
されそうだよ
22:デフォルトの名無しさん
06/03/13 08:55:22
混合型のサポートは VC++ 2010 がターゲットだってよ
URLﾘﾝｸ(blogs.msdn.com)
23:デフォルトの名無しさん
06/03/13 09:11:10
CLIをまともなC++言語から使うには2010年までまつ必要があるということ？
24:デフォルトの名無しさん
06/03/13 09:37:42
完全な混合型は、需要もどの程度あるか疑問だし、とりあえず
１）マネージドなオブジェクトへのハンドルを
ネイティブクラスのメンバに
２）ネイティブなオブジェクトへのスマートポインタを
マネージドクラスのメンバに
の相互通行ができれば便利なんじゃないかな。
それは gcroot/auto_gcroot と >>5 の AutoPtr 的な
スマートポインタクラスを使えば VC++ 2005 でも
可能なんだけどできれば何か標準があったほうが安心だよなぁ。
25:デフォルトの名無しさん
06/03/13 09:50:54
何だかプログラミングし難くね？
Winの良さが丸消えじゃん。
26:デフォルトの名無しさん
06/03/13 10:03:56
ネイティブで多重継承して、それをサポートしたいコントロールに継承させたり、friend の
抜け道をネイティブ側に用意して、マネージドを操作したり、本格的に混合型をサポート
してくれれば、使い方に夢が広がるんだけどねSTLだって、ネイティブとしてキャストして
保持させれば、混合型でマネージドを操作できるだろうし
ただ、相互のデータメンバを保持するだけなら、作りで回避できるからあまり混合型の
メリットは感じないなぁ
27:デフォルトの名無しさん
06/03/13 12:54:59
それじゃマネージド終焉じゃん。
28:デフォルトの名無しさん
06/03/13 13:30:46
>>27 どのあたりが？
29:デフォルトの名無しさん
06/03/13 13:57:59
STLをまともに使えないC++に何の意味があるのか。
30:デフォルトの名無しさん
06/03/13 15:12:34
だから、結局C++で。必要なところだけ C++/CLIなんだろな。
31:デフォルトの名無しさん
06/03/13 15:14:55
必要なところって、どこ？
32:デフォルトの名無しさん
06/03/13 15:29:36
.NETFrameworkを利用するところ。
33:デフォルトの名無しさん
06/03/13 15:52:52
結局、C++/CLIはラッパーでしか使えないねぇ。
34:デフォルトの名無しさん
06/03/13 16:12:10
それじゃ、ＣＯＭと変わら（ｒｙ
35:デフォルトの名無しさん
06/03/13 17:13:50
仕方ないじゃん。
TRONとかいろいろ環境はあるわけで、その中でWinだけ C++/CLIだけでは組めないよ。
36:デフォルトの名無しさん
06/03/15 20:32:14
あー、翻訳終わったお～。がんばったよ
37:デフォルトの名無しさん
06/03/15 20:42:36
うぇねの人？
乙
38:デフォルトの名無しさん
06/03/15 20:49:33
thx みゅ。どこぞから抗議されたらチキンのように消すんで、適当に見といてくらさい
39:デフォルトの名無しさん
06/03/15 21:15:38
激しく乙
40:デフォルトの名無しさん
06/03/15 23:27:13
>>38
キチンと消せよ
41:デフォルトの名無しさん
06/03/16 22:50:30
>>38
せめてWeb Archiveに残るまでは消さないで。
42:http://www.vector.co.jp/soft/win95/util/se072729.html
06/03/18 20:53:45
TextSS のWindowsXP(Professional)64bit化おながいします
もしくは64bitにネイティブ対応したテキスト置換ソフトありますか？
43:デフォルトの名無しさん
06/03/24 07:19:40
C++とCLIの統合のまだ道半ばってところなのかね。
44:デフォルトの名無しさん
06/03/24 10:22:50
>>43 道半ばなんじゃね？
でもネイティブなコードとマネージドなコードが
仲良くできるってビジョンを示した点ではC++/CLI
ってのはかなり意味があるんじゃないかな。
さらに Managed C++ から C++/CLI への移行劇を
見せ付けられて、その道程が険しいってこともわかったし。
45:デフォルトの名無しさん
06/03/24 12:17:38
ついでながらC++とCOMの統合も目指してくれ
46:デフォルトの名無しさん
06/03/24 12:30:23
>>45 COM との統合って具体的には？
COM つかうのに言語仕様上の制約ってあったっけ？
47:デフォルトの名無しさん
06/03/24 12:41:13
クライアントとして使うには#importがあるし、
サーバにはATLがあればまあいいやと思うのだが。
48:デフォルトの名無しさん
06/03/25 00:47:41
すまん、XBOXが managed になるそうだ。
49:デフォルトの名無しさん
06/03/25 09:01:08
それは、先代XBOXでしょうか、現行のXBOX360でしょうか？
50:デフォルトの名無しさん
06/03/25 11:57:40
360だ。ネタ元は、
URLﾘﾝｸ(blogs.msdn.com)
それに対するQ&Aのようなコメントは
URLﾘﾝｸ(blogs.msdn.com)
51:デフォルトの名無しさん
06/03/26 01:53:09
>45
URLﾘﾝｸ(msdn2.microsoft.com)(VS.80).aspx
52:デフォルトの名無しさん
06/03/29 07:48:03
C++/CLI（っというかMSC++2005EE） でManaged DirectXって使えないのかな？
検索しても見つからないorz
解説されてそうなところ知ってる方いませんか？
53:デフォルトの名無しさん
06/03/29 07:52:22
SDK入れて参照に追加するだけじゃん
54:デフォルトの名無しさん
06/03/29 08:13:34
>>53
#using <microsoft.dirextx.direct3D.dll>
using namespace microsoft::directx::direct3d;
と入れても
アセンブリ 'microsoft.dirextx.direct3D.dll' がみつかりませんでした:
って言われちゃうんだよねorz何がいけないんだろう・・・
55:デフォルトの名無しさん
06/03/29 08:21:08
リンク時の参照に追加してないだけじゃね？
56:52=54
06/03/29 08:34:10
>>55
すいません。#using <>で大文字小文字の区別ができないだけみたいでした。
ありがとうございました。
57:デフォルトの名無しさん
06/04/07 02:18:21
はどーけん
58:デフォルトの名無しさん
06/04/07 02:35:53
一週間ぶりの書き込みがそれかよ もうちょっと考えろよ
59:デフォルトの名無しさん
06/04/07 02:55:28
普段脳みそ使ってる分の反動ってやつかな…
60:デフォルトの名無しさん
06/04/07 10:58:30
＼ ずどどどーーん
／|[]::::::|_ / ＼/＼＼ ／
.／|￣￣￣￣ //＼ ＼/ ＼ ／/ ＿＿＿
| |:::「「「「「「 / ＼/＼ /＼＼ ／:::/ .／| |＿＿
＿..| |:::LLLLL//＼ ＼/ ＼/＼＼／::::::/ ／ | ロ .|lllllllllllll
／ llllll| |:::「「「「 / ＼/＼怒/＼ .＼/ ./::::::::/ ／ .／ .| |lllllllllllll
＿＿ llllll| |:::LLL.//＼ ＼/涛＼/＼ /::::::::/ | ／ .| ロ .|lllllllllllll
llllll| |:::「「「/ ＼/＼熱 /＼ ＼/ /::::::::/ | ||／ ..| |lllllllllllll
llllll| |:::LL//＼ ＼/ ＼/＼ ./::::::::/ .| ||／ ..|
| |:::「./ .＼/＼ 湯/＼ ＼/ /::::::::/⌒ヽ､ .| ||／ ..|
| |:::l//＼ ＼/ ＼/＼_, -― ､ ''"⌒ヽ,_
(⌒ヽ､_,ノ⌒Ｙ" Y .....⌒) どーーーーーん
(⌒ヽーﾞ ....::（ ..::....... .__人.....::::::::::::::::::::
＿ノ⌒ヽ Y⌒ヽ;;:::::"'::::::::::::::::::::::::::::: ＿＿＿
＿＿_( ﾞ ....:::..... Y" ∧＿∧ ／
／/ ll＿＿ヽ＿::::::::::::::::::::::::::::::ヽ....（ ´Д｀）＜逃げろ逃げろ！
「 ヽＯ≡≡O:::::::::::::::::::::::::::::::::::/ つ _つ ＼＿＿＿＿
ﾞｕ─―ｕ-―-ｕ 人
61:デフォルトの名無しさん
06/04/09 19:51:41
ダブル サンキング
って糞じゃない？
仮想関数使えないじゃん。
62:デフォルトの名無しさん
06/04/10 00:35:31
C++/CLIのバージョン１というのはC++マネージ拡張のことなのかな？
63:デフォルトの名無しさん
06/04/11 10:09:41
>>62 C++/CLI にバージョンってあったのか。
Managed C++ → C++/CLI
くらいしか認識してなかった。
64:デフォルトの名無しさん
06/04/15 12:35:08
Objective-C++/CLI
ﾏﾀﾞｰ?ﾁﾝ､ﾁﾝ｡
//GCCもCLI対応するんだろうか?
65:デフォルトの名無しさん
06/04/15 12:39:11
Objective-C++ はちょっと意味が分からないな
C++ は C++ でそれなりに Objective だからな
66:デフォルトの名無しさん
06/04/15 12:44:48
>>64
Objective-C 言語
+
C++ 言語
||
Objective-C++
67:デフォルトの名無しさん
06/04/15 15:00:18
URLﾘﾝｸ(homepage.mac.com)
ここらを見ると、いろんな苦労が共有できる気がするな
68:デフォルトの名無しさん
06/04/16 15:02:33
Robert Rameyがいらないってんだから要らないんだよ
Sutterも嫌々やってるんですよ
69:デフォルトの名無しさん
06/04/22 01:05:39
すみません。
Visual Studio2005ですが、MFCのプロジェクトで、
Windowsフォームデザイナで貼り付けられるような
コントロールは使用できるのでしょうか？
またWindowsフォームデザイナで開発した場合は、
.NetFrameworkが必要となり、Windows2000では動作できないなどありますか？
70:デフォルトの名無しさん
06/04/22 01:23:13
>>69
1.使用できなくはないかもしれないがそれなら正攻法で使ったほうが多分楽
2..NET Framewokは98でも動く。一部2kで使えて98で使えない機能もあるがそれはたいていSDKに依存する問題。
71:デフォルトの名無しさん
06/04/22 01:23:21
Windows 2000 でも .NET Framework は動くだろ
72:デフォルトの名無しさん
06/04/22 01:25:33
>>69
正攻法とはどのような方法でしょうか？
また、.NETFrameworkがインストールされていないと
動作しないのですよね？
※すみません。.NETFramework初体験です。
73:デフォルトの名無しさん
06/04/22 01:44:20
>>72
>正攻法
SDKを使う方法。
>.NE（ｒ
もちろん動作しない。OSがインストールされていないようなもんだ。
74:デフォルトの名無しさん
06/04/22 01:49:18
>>73
SDKはどのように使えばよいのでしょうか？
お手数ですが、簡単なサンプルとかってありませんか？
もう少し詳細を教えていただけるとたすかります
何しろＭＦＣの標準コントロールは古臭くて。。
75:デフォルトの名無しさん
06/04/22 01:53:10
>>74
Win32API質問箱 Build42
ｽﾚﾘﾝｸ(tech板)
76:デフォルトの名無しさん
06/04/22 08:53:14
>74
CWinFormsControl を使え
URLﾘﾝｸ(msdn2.microsoft.com)(VS.80).aspx
77:デフォルトの名無しさん
06/04/22 08:56:00
というかそもそも何故 MFC なんだろう？
78:デフォルトの名無しさん
06/04/22 10:15:56
既存のアプリの改良に WinForms を使いたいんじゃね？
79:デフォルトの名無しさん
06/04/22 17:27:33
>>78
ご名答！！
そもそもVisualStudioの統合環境のツールバーや
メニューバーはどうやってるんだろうと。。
80:デフォルトの名無しさん
06/04/22 17:34:21
別に何でもかんでもまぜまぜする必要ないじゃん。
混ぜることそのものが目的になってしまってる、みたいな。
81:デフォルトの名無しさん
06/04/22 17:48:48
>>79 それは全部マネージドなんじゃね？
82:デフォルトの名無しさん
06/04/22 18:24:55
漏れも手抜きしたくて CWinFormsControl を既存アプリに組み込んだりしたいけどな
さすがに、ユーザーに .net Framework 2.0 を要求できなくてやってないけど
83:デフォルトの名無しさん
06/04/23 12:49:49
>>79
コントロールは単なるウィンドウを子ウィンドウにしてるだけ。
って言うのは解ってる?
84: ◆GjPgyWFPCM
06/04/23 13:24:21
( ´_ゝ｀)
85:デフォルトの名無しさん
06/04/23 18:16:21
現状のC++ソースをまんまPureCLIに出来ないのが美しくないね。
86:デフォルトの名無しさん
06/04/23 18:53:21
>>85
災いと引き換えの美しさなんぞいらん。
87:デフォルトの名無しさん
06/04/23 19:37:17
>>85
むしろこれからはそれを意識したマクロ定義を心がけるべき？
88:デフォルトの名無しさん
06/04/23 19:46:14
時代に逆行して COM かよ
89:デフォルトの名無しさん
06/04/24 01:40:49
だから、猛烈にISO化に反対されてるだろ。
90:デフォルトの名無しさん
06/04/24 09:08:11
災い＝怒涛熱湯
美＝Ｃ＋＋
91:デフォルトの名無しさん
06/04/24 19:36:55
あの ISO の論議は宗教戦争だよ
C++ だって C とは完全互換性がなくて非互換性の項目作ってるのに、C++/CLI は完全互換じゃ
ないから C++ の名前を使うな、なんて、馬鹿馬鹿しい
92:デフォルトの名無しさん
06/04/24 19:51:22
C++#にするしかないのか
93:86
06/04/24 20:17:12
>>90
逆。
ＣとC++で起きた災いのことだ。
94:デフォルトの名無しさん
06/04/25 01:16:21
>>91
んなーことはない。互換のない箇所があまりにも C++ を越えてるからな。
誰もが、「C++であれは不味いよ」という実装。
C++の名前は使ってもいいが、正直、ISOにはなって欲しくない。
95:デフォルトの名無しさん
06/04/25 05:32:35
そうか？ 文字列互換性なんて C++ の不始末を便利にしたとこを駄目だとか騒いでるぐらいじゃね
MSのサイトの記述にけちつけて、こいつら営利企業に何求めてるんだ、とか思っちゃったけどな
96:デフォルトの名無しさん
06/04/25 08:02:46
論争ってなんのことかよく知らないんだけど、
名前に C++ が入ってるのがまずいダロってことになってんの？
まぁ確かにもう少し検索エンジンフレンドリーな名前でもいいかもって気はする。
97:デフォルトの名無しさん
06/04/25 09:42:19
ま、どっちにせよ、
Windowsのネーミングからはじまり、
J++、J#、managed C++、STL.NETとか、
一般的なものを汚し杉。
98:デフォルトの名無しさん
06/04/25 09:59:29
そんな、汚すだなんて Java の信者じゃないんだから（ｗ
Bjarne Stroustrup のFAQになってるところがﾜﾗﾀ
URLﾘﾝｸ(www.research.att.com)
ISO UK が強硬に反対していて、その下に ECMA からの回答書も公開されている
ECMA じゃ C++/CLI と C++0x にどうやって巻き込まれないようにするかの調査も
始めてるってさ
99:デフォルトの名無しさん
06/04/25 10:06:02
ECMA の回答書の最後に、おまいらががたがた言おうともう ECMA 標準であることに代わりは
ねえんだよ、って答えてるとこが笑える
100:デフォルトの名無しさん
06/04/25 10:43:04
C/C++系を汚すなんて汚杉。
VC++が吐き出すMFCコードからして何語？って感じだった。
ユーザーに変なもん使わせながらM$は別のクラスライブラリ使ってるらしいし。
101:デフォルトの名無しさん
06/04/25 15:28:25
関係ないがアンダーバーつきまくりの変な修飾子はもう見たくないと思った。
102:デフォルトの名無しさん
06/04/25 15:52:08
こうやってC++をぐだぐだにすることで、
C#の地位を着々と上げていく作戦なんだな。
103:デフォルトの名無しさん
06/04/25 17:10:51
何言ってるんだ。 C++/CLI が出てきたせいで、C# がその存在意義を問われてしまったのに
104:デフォルトの名無しさん
06/04/25 17:41:48
でも、現場では「C++/CLI」と「C++」を完全に切り分けないと仕事にならんのも事実。
ISOにする前に、Mac用の C++/CLIでも出してから言ってくれ、という気分だ。
>>100
おまえさん、そんなこと言ったら、COBAとかCOBA真似 IIS C++ソースなんて見たら目がつぶれるぞ。
MFCなんかは、独自仕様として実装されてるからいいよ。アンダーバー定義でその世界だけで収まってるからな。
しかし、今回の C++/CLI での文字列の扱いはそんなレベルじゃないだろ。
C++の延長線上に C++/CLI があるような ISO 化は止めて欲しいってこった。
C#の存在意義なんて、海外では数年前からいわれてんのに、今頃何言ってンのよ。
105:100
06/04/25 19:08:19
>おまえさん、そんなこと言ったら、COBAとかCOBA真似 IIS C++ソースなんて見たら目がつぶれるぞ。
見たい。ＵＲＬ教えれ。
>C++の延長線上に C++/CLI があるような ISO 化は止めて欲しいってこった。
なるほど、ISO化が嫌われてるのね。
>C#の存在意義なんて、海外では数年前からいわれてんのに、今頃何言ってンのよ。
知らなかった。ＫＷＳＫ
106:デフォルトの名無しさん
06/04/25 19:50:18
>>105
>見たい。ＵＲＬ教えれ。
断る。
comのプログラムを探れ。corbaを参考に ActiveX, COM, DCOMをつくり、その開発メンバーがIISに流れた。
後は自分で探せ。
>なるほど、ISO化が嫌われてるのね。
C++という名前を使うな、という気持ちも理解できるが…、ISOにする必要性は全くない。
MS以外誰も望んでいないからな。
>知らなかった。ＫＷＳＫ
C#を初めとして、その他の多くが失敗したから、「ユーザの望むモノを提供していないンだよ、ボケ社員ども」と方針転換した話は有名。
Vistaで乗るバッチプログラムだって、初めは新しい言語だったのにひっこめて全部作り直す。
そのとき、名言。「すみません。Perl風に作り替えます。」
MSは既に梶を切ってるのに、古い方針の独善的な仕様でISO化してどうするよ。
107:100
06/04/25 20:01:59
>>106
おもしろい情報一杯持ってるね。そういう情報好き。
>comのプログラムを探れ。corbaを参考に ActiveX, COM, DCOMをつくり、その開発メンバーがIISに流れた。
こういうの面白い。さらにＣＯＭのトンデモ文法で作ったＭ＄のアプリサーバなんて装飾子があったら爆笑。
>C#を初めとして、その他の多くが失敗したから、「ユーザの望むモノを提供していないンだよ、ボケ社員ども」と方針転換した話は有名。
方向転換したのはゲイツ氏？
Ｌｏｎｇｈｏｒｎ＠マネージド→Ｖｉｓｔａの方向転換のこと？
>Vistaで乗るバッチプログラムだって、初めは新しい言語だったのにひっこめて全部作り直す。
あの、WinFXスレでマンセーされてたシェル言語？スゲ
108:デフォルトの名無しさん
06/04/25 21:23:31
自演乙
109:デフォルトの名無しさん
06/04/26 00:58:33
>>107
だから、corbaを元にしたと言ってるのによ。おかげでIISとC++で組むのは無駄に知識が必要だったりするわけだが。
DON BOXとかsoapに絡んでるから余計に…。
.Netで楽にはなったらしいが。
方向転換したのはゲイツメールじゃない。10年前か!?はゲイツだったけどね。
たしか、そんなに古株じゃないヘッドハンティングされてきた人物だったはず。
方針転換はな、いま口癖のように言ってる Live って奴だ。MSは毎日かかさず Live関連の新機能を発表してるって知ってたか?
まあ、何でもかんでも Live と言ってるって事だけどさ。
とにかく、4/1にエイプリルフールでLiveネタででたジョークでは。shellで ls うつと、存在するファイル名に対応した広告が
ファイル一覧と共に表示される。という奴だった。
マネージド -> Vista なんていう程度の石頭じゃ、これからの10年食っていけないぞ?
110:デフォルトの名無しさん
06/04/26 01:10:43
レイオジーのこと？
俺はなんだかんだ言っても最後は.NETに落ち着くと思うけどな。
エイプリルフールネタはおもしろい。
111:デフォルトの名無しさん
06/04/26 08:49:41
＞俺はなんだかんだ言っても最後は.NETに落ち着くと思うけどな。
いや、Ｍ＄がドトネトに決定するかもしれんが、落ち着いたことは過去一度も無いお。
DDE（Win3.1or3.0 1993)
↓
NET DDE (Win3.1 1994)
↓
埋め込みしたいなぁ．．．
↓
OLE1.0（DDE使用）
↓
OLE2.0=COM ただし目的はインプレースドキュメント。しかしその背景には本質としてバイナリオブジェクト標準あんどオブジェクト通信の思想あり。この辺で名慮or迷著 InsideOLEあんどIsideOLE2。死者多数。
部品としてVB用のVBX (VB2.0からVB4.0 1995あたり)
↓
COMを使ったOCX (1996あたり）結局コンポーネントビジネスはやんなかったな...
ゲイツがインターネットに熱上げあんどJAVA Appletはやる (1995）
↓
COMつかってActiveX(1996)
だんだんオブジェクトはやってくる。 （UMLなど1997）オブジェクトもでるとしてCOMの宣伝開始 DCOMなどCORBAとがっぷり。この辺でMTSではじめ
↓
マーケティングてきなWindowsDNA 。MTS2.0それなりに使えそう。つか使った。DCOM糞。(1999)
↓
COM+ （Win2000､2000）In-MemoryDBどこいったゴラァ
COM Runtimeの情報漏れ始め (2000～)
↓
セキュリティ→ファイアーウォールのためCOM全滅。しばらくしてから.NETとしてCOMじゃないものに．．．
↓
.NET流行らず(～2006)
↓
WinFX完成(2007)
↓
オブジェクトベースプログラミングにより、OSは関数コールに戻る(2008)
WinFX下位互換へ
112:デフォルトの名無しさん
06/04/26 13:23:51
LiveってWinモンリー？
113:デフォルトの名無しさん
06/04/28 11:50:51
CLR_OR_THIS_CALL
114:デフォルトの名無しさん
06/05/11 19:07:00
ネイティブとかマネージとかアンマネージとか値とか参照とか
ややこしいっつーの
115:デフォルトの名無しさん
06/05/11 20:16:13
C#書いてるときに比べてC++/CLI だと IDE が明らかに遅いんだけど。。。
ボタンを設置してダブルクリックして、イベントハンドラのスケルトンができるまでが明らかに遅い。
116:デフォルトの名無しさん
06/05/11 22:07:38
パソコン買い換えろよ。ボロイのいつまで使ってんだよ。
117:デフォルトの名無しさん
06/05/12 22:24:27
買い換えても、遅いモノは遅いぞ。相対的なものだからな。
118:デフォルトの名無しさん
06/05/12 22:45:13
まあ、十分に早くなれば差に意味が無くなるだろう
……ネイティブとCLIの縮図のようだ
119:デフォルトの名無しさん
06/05/15 20:37:12
System::Runtime::InteropServices::PARAMFLAG::Outって何？
System::Runtime::InteropServices::OutAttributeに変えてもいいの？
120:ヽ(ﾟ∀｡)ﾉうぇね ◆xOFicusMP.
06/05/19 23:03:00
ECMAから公開許可をもらったぜ
消す必要はなくなったから、安心してくり
121:デフォルトの名無しさん
06/05/20 07:40:11
>>120
おお、めちゃ乙。
122:デフォルトの名無しさん
06/05/20 11:58:59
ECMAって心が広いんだね
123:デフォルトの名無しさん
06/05/30 14:20:07
ちがうよ、必死なんだヨ。
124:デフォルトの名無しさん
06/06/02 13:29:20
STL.NETどこイっちゃたの？
125:デフォルトの名無しさん
06/06/02 14:05:47
思いつきで適当なもん作ってはお蔵入り
126:デフォルトの名無しさん
06/06/02 14:12:41
今はSTL/CLIだよね。
出てもJavaの新しいcollectionみたいな仕様のクラスライブラリで、
method等の名前がSTL風になっているだけだろうけど。
STLはC++の言語仕様にかなり依存しているから。
なんにしてもそれどころじゃないみたい。
URLﾘﾝｸ(blogs.msdn.com)
127:126
06/06/12 08:21:10
しかし、すげー、過疎スレだなw
128:デフォルトの名無しさん
06/06/18 20:33:44
話題がないのにだらだらだべるなんて苦痛だからね
正直、STL/CLI は C++/CLI にとって不要な要素だと思ってる
作るだけ、無駄。だから、あまり力を入れていないのは正解じゃないかな
129:デフォルトの名無しさん
06/06/18 21:06:52
そうだなあ。
ManagedなobjectをSTLで扱う時のTIPSでいいかな。
130:デフォルトの名無しさん
06/06/18 23:35:16
コンテナ程度の対応をするより、0x への対応をしっかりとやって欲しいのですよ
それらの要素をどう C++/CLI に持ち込むかの方が重要だと思う
131:デフォルトの名無しさん
06/06/19 16:02:04
System.Collections.Generics.Listのイテレータを作ってみたことがあるんだ。
最初はそのイテレータも参照型にしたんだけど、Visual C++付属の<algorithm>の関数は、
デバッグ用か何かの仕掛けがあって、ネイティブ型しか受け付けてくれなかった。
結局そのイテレータに対するネイティブ型のラッパを作ってやったんだ。
逆に言えばマネージ型のイテレータがVC++付属の標準ライブラリで使えれば、
STL/CLIなんてなくても自分たちで勝手にイテレータを作ったりして使うことは容易だと思う。
132:デフォルトの名無しさん
06/06/25 01:03:26
素直に混合型を実現してマネージドとネイティブを継承した型を使えばと・・・
133:デフォルトの名無しさん
06/06/27 10:39:54
それ、ふつーのネイティブ。
134:デフォルトの名無しさん
06/07/03 22:36:31
実践C++/CLI
URLﾘﾝｸ(www.amazon.co.jp)
を買った人いる？ どんな感じ？
135:デフォルトの名無しさん
06/07/04 07:53:18
本屋で立ち読みしてみるのが一番手っ取り早いかと
136:デフォルトの名無しさん
06/07/04 22:51:53
手っ取り早いどころか、立ち読みしてから買わないと危険な香りがするな。
137:デフォルトの名無しさん
06/07/07 00:43:47
立ち読みした。実践じゃなくて、実際だな。内容的には。
本の後半で、Visual Studioのダイアログでの指定方法とか書かれてる。
つーか、最近、ソフトバンククリエイティブの本はタイトル詐欺が多すぎ。
噂の真相うんちゃらかんちゃらも、タイトル買いしたら内容は単なる手記だったしよ。
138:デフォルトの名無しさん
06/07/08 12:51:24
表紙だけ素晴らしくて内容がｳﾝｺなエロ同人誌みたいなもんか
139:デフォルトの名無しさん
06/07/08 13:18:39
買って読んだが、ちと微妙なできだな
C++/CLI に踏み込んだ記述は少なく、既存の VC++ の開発者向けに .net を使うための
チップス集といった感じだった
記述するべき知識が広範囲すぎて、なるべくいろいろ網羅しようとがんばっているのは
感じたが、前提知識があるものと記述されている部分が多くて、これはさらりと書かれている
部分がわからないのでは、と疑問に感じた
140:デフォルトの名無しさん
06/07/08 13:43:06
>>137
> 最近
笑うところ?
141:デフォルトの名無しさん
06/07/09 13:17:19
ページ数が少なすぎるね
142:デフォルトの名無しさん
06/07/23 00:28:01
C++/CLI 気に入ったんだが、リファクタリングできないのがつらいなぁ。
143:デフォルトの名無しさん
06/07/23 02:07:36
デバッグでトレースが重いのが致命的だよ・
144:デフォルトの名無しさん
06/07/24 05:00:40
.NETと無縁の仕事ばかりやってたので思いつきでCLIでもやって
みようと思って買ってみたよ。
ダイヤモンド継承の問題点とかでてきてちょっとなえるが、まあ
もうちょっと読んでみるよ。
Win32と.NETが同時に使えるのはツールとかちょっと作るのには
便利なのかなあくらいに思ってるよ。製品開発に使えるとはまだ
ちょっと思えないけど。。
145:デフォルトの名無しさん
06/07/27 04:12:28
>>144
去年、C#の案件をやったんだが「ああ、あの時C++/CLIが出てればなぁ」とは思う。
146:デフォルトの名無しさん
06/07/31 20:51:05
これ読んだ人いる？
URLﾘﾝｸ(www.amazon.com)
147:デフォルトの名無しさん
06/08/01 10:00:59
>>145
Ｃ＋＋ ＞ （壁） ＞ Ｃ丼
ということ？
148:デフォルトの名無しさん
06/08/01 19:12:10
>>147
ヒント：DllImport
今は逆にC++（ただしネイティブ）の案件やってるが「これがC#だったらもっと楽なのに」と思いながらコード書いてる。
149:デフォルトの名無しさん
06/08/01 20:31:57
BStrWrapper ってどうやって使うんでしょうか？
ググっても、ひっかかりもしねぇっす。
150:デフォルトの名無しさん
06/08/09 16:31:51
こんにちは。質問です。
VC++EE使ってます。
system以下のライブラリを網羅したページってないですか？
C#やVBで解説されててもかまわないのでどこかご存知ありませんか？
151:デフォルトの名無しさん
06/08/09 16:50:50
MSDN
152:デフォルトの名無しさん
06/08/09 17:51:19
検索で引っかからなかったけど、MSDN普通にもぐってったらあった。OTL
なんでMFCなのかわからんけど、見つかってよかった。
URLﾘﾝｸ(msdn2.microsoft.com)
153:デフォルトの名無しさん
06/08/10 00:00:25
>>152
>MSDN ライブラリ > .NET 開発 > .NET Framework SDK > MFC リファレンス
うは、ほんとだｗｗｗ
154:ヽ(ﾟ∀｡)ﾉうぇね ◆xOFicusMP.
06/08/26 23:01:19
あまり使ってる人もいないんだろうけど、ごめん、鯖が消えてた(´･ω･`)
引っ越したので、こちらを参照してください
ECMA-372仕様書
URLﾘﾝｸ(mdjowbnb.sv05.fsdotnet.net)
155:デフォルトの名無しさん
06/08/27 17:51:15
>>154
乙です。お世話になってます。
156:デフォルトの名無しさん
06/09/05 18:17:53
C++/CLI で作ったクラスライブラリって、CLR Profiler 通る？
CLR Profiler いつも落ちるんだけど。
157:デフォルトの名無しさん
06/09/08 00:40:07
/clr:pure 状態でも？
158:デフォルトの名無しさん
06/09/08 11:33:09
/clrでコンパイルしたときにアンマネージコードの生成が
『～～用にネイティブ コードの生成が発生します』
と自動的に適用される場合と、
『この関数はマネージとしてコンパイルできません。#pragma をアンマネージで使用してください』
と明示しなければエラーになる場合があるんだけど、
両者の違いって分る人居ますか？
159:デフォルトの名無しさん
06/09/14 00:40:15
ISOは賢明な判断をしたな
160:デフォルトの名無しさん
06/09/14 01:05:14
>>159
くわしく。
161:デフォルトの名無しさん
06/09/14 08:25:11
これか
URLﾘﾝｸ(blogs.wankuma.com)
162:デフォルトの名無しさん
06/09/14 08:27:22
これかな?
URLﾘﾝｸ(www.iso.org)
163:デフォルトの名無しさん
06/09/14 08:31:29
間違えた orz
URLﾘﾝｸ(www.iso.org)
164:デフォルトの名無しさん
06/09/14 08:52:40
ま、駄目だった物は駄目、ということで
165:デフォルトの名無しさん
06/09/14 09:03:55
まあ駄目で当然という気がする。
仕様が汚すぎる。上位互換じゃないのも(C++を名乗るには)問題。
166:デフォルトの名無しさん
06/09/14 13:57:57
ちょっとホッとした。本当に賢明な判断だ。
167:デフォルトの名無しさん
06/09/15 01:56:05
どっちの味方なんだよ
168:デフォルトの名無しさん
06/09/15 02:18:45
最終的にまともなのになってくれれば過程はどうでもい
169:デフォルトの名無しさん
06/09/15 04:19:04
C++をマネージ拡張するのもいいんだけど、
C#をアンマネージ拡張して欲しいと思うときがある。
まあ、DllImportすればいいんだけど。
170:デフォルトの名無しさん
06/09/16 01:34:15
よくねーよ。
でもMSが持ってるNativeMethods.cs公開してくれたら、それでいい気がする。
171:デフォルトの名無しさん
06/09/16 01:44:50
俺もそれほしい
PInvoke.net が不要になっちゃう
172:デフォルトの名無しさん
06/09/16 02:03:51
結局、/CLIは今のところ使わない方が良いって事だなぁ…。
173:デフォルトの名無しさん
06/11/18 10:46:54
sage
174:デフォルトの名無しさん
06/11/19 03:51:20
C++/CLIって結局微妙ってこと？
＠IT：特集：Visual C++ 2005 いままたC++が熱い！「C++/CLI」として大進化したVisual C++ 2005
URLﾘﾝｸ(www.atmarkit.co.jp)
これとか見ると随分興奮しているけど
175:デフォルトの名無しさん
06/11/19 12:02:38
>>174
ヒント: 川俣 晶
176:デフォルトの名無しさん
06/11/20 16:15:43
海外だと、C++/CLIは凍るほど冷えてる。
177:デフォルトの名無しさん
06/11/20 19:51:22
>>176
そうなんかぁ～？
178:デフォルトの名無しさん
06/12/03 02:17:55
DllImport関係のNativeMethod系以外に結局何が素敵なの？ C++/CLIって
>>145
(言語熟練度はプロジェクト要員の平均レベルでC++/C#ができるものとして）
Manageなコード中に簡単にネイティブっぽいものが書けちゃうと逆にメンテし辛いものにならないのかな。
ところで、C++/CLIってC#3.0みたいな機能って予定されてるの？
179:デフォルトの名無しさん
06/12/03 03:11:41
ネイティブの方が圧倒的に多かったり、
XP用のポーティングをしたり、
いろいろ便利なケースは想定できるでしょ?
どこまで厚くサポートされるかは分からない。
STL.NETみたいに辞めちゃったプロジェクトもあるし、
C++/CLIの人員削減はあり得ることだと思う。
180:デフォルトの名無しさん
06/12/03 08:56:56
STL.NETはやめてはいないだろ。
OrcasのCTPにSTL/CLRが入っている。
どんなもんかまだ俺は試していないけど。
181:デフォルトの名無しさん
06/12/04 15:49:06
void func (String* str1, String* str2, String* str3) {
String* str;
str = System::String::Concat( str, str1 );
str = System::String::Concat( str, '\0' );
str = System::String::Concat( str, str2 );
str = System::String::Concat( str, '\0' );
str = System::String::Concat( str, str3 );
str = System::String::Concat( str, '\0' );
str = System::String::Concat( str, '\0' );
}
func("aaa","bbb","ccc");
上記で、"aaa\0bbb\0ccc\0\0"という値を期待していたのですが、\0が消えて"aaabbbccc"となってしまいます。
助けてください
182:181
06/12/04 15:57:05
void fucn(string a, string b, string c) {
string ret = "";
ret = System.String.Concat( ret, a );
ret = System.String.Concat( ret, '\0' );
ret = System.String.Concat( ret, b );
ret = System.String.Concat( ret, '\0' );
ret = System.String.Concat( ret, c );
ret = System.String.Concat( ret, '\0' );
ret = System.String.Concat( ret, '\0' );
}
func("aaa","bbb","ccc");
あと、C#で上記のようにやった場合は期待通りの値になっているようです。
本当はC#で全部やろうと思ったのですが、C#でWin32APIの呼び出しが解らなくてC++/CLI使ってみました。
そのAPIの引数が、"aaa\0bbb\0ccc\0\0"という形式で指定しろとなっているのですが、
今度は引数が生成できなくて填ってます。
183:デフォルトの名無しさん
06/12/04 16:07:42
>>182
やったこと無いんだが、
見た感じ、strcatと同じ動作に見えるね。
オペレータの＋ってないの？
184:デフォルトの名無しさん
06/12/04 16:18:11
>>183
ret += a;
今、上記のようにやってみたのですが、下記のエラーになってしまいました。。。
error C2297: '+=' : 無効な右オペランドです。
error C2845: '+=' : __gc ポインタ 'System::String __gc *' に対してポインタ演算ができません。
185:デフォルトの名無しさん
06/12/04 16:47:32
CLIは素人なのではずしてたらごめんね。
で、これ通ったよ。
using namespace System;
int main(array<System::String ^> ^args)
{
String^ A="Hello";
String^ B="World";
String^ C="";
C=A+B;
Console::WriteLine(C->ToCharArray());
return 0;
}
と、ここまで書いて見落とし発見・・・。
なんだ、普通のstd::stringか？
ちょっとまってて。
186:181
06/12/04 17:03:45
皆さん、ありがとう。
下記のようにして何とか動きました。
voidfunc(String*str1,String*str2,String*str3){
LPTSTRpArg;
LPTSTRpStr1=(LPTSTR)Marshal::StringToHGlobalAnsi(str1).ToPointer();
LPTSTRpStr2=(LPTSTR)Marshal::StringToHGlobalAnsi(str2).ToPointer();;
LPTSTRpStr3=(LPTSTR)Marshal::StringToHGlobalAnsi(str3).ToPointer();;
intlen=0;
len+=lstrlen(pStr1);
len+=1;
len+=lstrlen(pStr2);
len+=1;
len+=lstrlen(pStr3);
len+=1;
len+=1;
pArg=(LPTSTR)malloc(len);
len=0;
memcpy(&pArg[len],pStr1,lstrlen(pStr1));len+=lstrlen(pStr1);
memcpy(&pArg[len],"\0",1);len+=1;
memcpy(&pArg[len],pStr2,lstrlen(pStr2));len+=lstrlen(pStr2);
memcpy(&pArg[len],"\0",1);len+=1;
memcpy(&pArg[len],pStr3,lstrlen(pStr3));len+=lstrlen(pStr3);
memcpy(&pArg[len],"\0",1);len+=1;
memcpy(&pArg[len],"\0",1);len+=1;
func(pArg);
free(pArg);
}
187:デフォルトの名無しさん
06/12/04 17:04:51
ミスった・・・
voidfunc(String*str1,String*str2,String*str3){
LPTSTR pArg;
LPTSTR pStr1=(LPTSTR)Marshal::StringToHGlobalAnsi(str1).ToPointer();
LPTSTR pStr2=(LPTSTR)Marshal::StringToHGlobalAnsi(str2).ToPointer();;
LPTSTR pStr3=(LPTSTR)Marshal::StringToHGlobalAnsi(str3).ToPointer();;
int len=0;
len+=lstrlen(pStr1);
len+=1;
len+=lstrlen(pStr2);
len+=1;
len+=lstrlen(pStr3);
len+=1;
len+=1;
pArg=(LPTSTR)malloc(len);
len=0;
memcpy(&pArg[len],pStr1,lstrlen(pStr1));len+=lstrlen(pStr1);
memcpy(&pArg[len],"\0",1);len+=1;
memcpy(&pArg[len],pStr2,lstrlen(pStr2));len+=lstrlen(pStr2);
memcpy(&pArg[len],"\0",1);len+=1;
memcpy(&pArg[len],pStr3,lstrlen(pStr3));len+=lstrlen(pStr3);
memcpy(&pArg[len],"\0",1);len+=1;
memcpy(&pArg[len],"\0",1);len+=1;
func(pArg);
free(pArg);
}
188:デフォルトの名無しさん
06/12/04 17:10:58
>>181お前それC++/CLIではなく、マネージドC++だろ。
とりあえず、こうすると.NET 2003の/clrと2005の/clr:OldSyntaxで動く（実行するとaaaしか表示されない）。
#using <mscorlib.dll>
#include <vcclr.h>
#include <windows.h>
#pragma comment(lib, "user32.lib")
void func (System::String* str1, System::String* str2, System::String* str3) {
using System::String;
String* str;
str = String::Concat(str, str1);
str = String::Concat(str, S"\0");
str = String::Concat(str, str2);
str = String::Concat(str, S"\0");
str = String::Concat(str, str3);
str = String::Concat(str, S"\0");
str = String::Concat(str, S"\0");
const wchar_t __pin* p = PtrToStringChars(str);
::MessageBoxW(0, p, L"", MB_OK);
}
int main()
{
func("aaa","bbb","ccc");
}
まあAPIの相手をするならchar配列のほうが楽。
>>187 せめてsprintf使え。あとLPTSTRをマルチバイト文字列に使うな。
189:デフォルトの名無しさん
06/12/04 17:11:03
こらこら、ANSI文字列のポインタをLPTSTRで受けちゃダメだぞ。
190:デフォルトの名無しさん
06/12/04 17:14:53
…なんだか口は悪いけど親切なお兄さんと結婚することになりそうです。
191:188
06/12/04 17:22:28
>>188
動きました！
192:181
06/12/04 17:22:51
名前欄まちがえた
193:デフォルトの名無しさん
06/12/04 17:30:11
あと、Marshal::StringToHGlobalAnsiで確保したメモリを開放していないな。
方法は幾通りもある。あんマネージ文字列への変換はCString （ATL/MFC 7以上）使うのと結構楽。
TCHARも適当にやってくれるし。
#using <mscorlib.dll>
#include <atlstr.h>
#include <windows.h>
#pragma comment(lib, "user32.lib")
void func (System::String* str1, System::String* str2, System::String* str3)
{
using ATL::CString;
CString cs1(str1), cs2(str2), cs3(str3);
CString arg;
arg.Format(TEXT("%s\0%s\0%s\0"), static_cast<PCSTR>(cs1), static_cast<PCSTR>(cs2), static_cast<PCSTR>(cs3));
::MessageBox(0, arg, TEXT(""), MB_OK);
}
194:185
06/12/04 17:37:49
>>186-188
ほかの方法があったか。
色々考え出したら止まらなくって困ってたとこだった。
役に立てなくてすまない。
#include <string>
#include <iostream>
int main(array<System::String ^> ^args)
{
std::string A="BMP",B="Wav";
std::string C="";
C=A+'\0'+B+'\0'+'\0';
std::cout<<C<<std::endl;
//std::cout<<C.c_str()<<std::endl;
return 0;
}
こういう感じの想定してた。＠VC2005EE
195:デフォルトの名無しさん
06/12/04 17:44:41
>>193の方法は短いですけど、>>188の方が見やすそうなので、使わせてもらいました。
色々勉強になりました
196:デフォルトの名無しさん
06/12/04 17:56:57
CLIだが最終的にこんなんなった。
std::string func(String^ str1, String^ str2, String^ str3)
{
IntPtr ptr1 = System::Runtime::InteropServices::Marshal::StringToHGlobalAnsi(str1);
IntPtr ptr2 = System::Runtime::InteropServices::Marshal::StringToHGlobalAnsi(str2);
IntPtr ptr3 = System::Runtime::InteropServices::Marshal::StringToHGlobalAnsi(str3);
std::string result = std::string()
+ reinterpret_cast<const char *>(ptr1.ToPointer()) + '\0'
+ reinterpret_cast<const char *>(ptr2.ToPointer()) + '\0'
+ reinterpret_cast<const char *>(ptr3.ToPointer()) + '\0'
+ '\0';
System::Runtime::InteropServices::Marshal::FreeHGlobal(ptr1);
System::Runtime::InteropServices::Marshal::FreeHGlobal(ptr2);
System::Runtime::InteropServices::Marshal::FreeHGlobal(ptr3);
return result;
}
197:デフォルトの名無しさん
06/12/04 18:23:57
>>195
せめてStringBuilder使え。
198:デフォルトの名無しさん
06/12/04 23:45:05
ふつうに wstring 使った方が早くね？
199:デフォルトの名無しさん
06/12/04 23:49:36
String::Format 使えばいいと思う……
200:デフォルトの名無しさん
06/12/05 00:23:34
>>199
>>193で出たものの、>>195で却下された。
201:デフォルトの名無しさん
06/12/05 11:03:39
個人的には(作成理由から読むに) C# で DLLImport の方法を探した方が遥かに楽だったんじゃないかという気がするけど。
色んな選択肢を使える懐の深さが C++/CLI の一つの魅力なわけだし、
最速/高効率よりも、本人が理解/吸収しやすい手法を取るのが最良だと思う。
202:デフォルトの名無しさん
06/12/05 16:10:02
さすがに、それを最良と言い切るのはおかしいな。
言いたいことはわかるが、言葉の選択を誤ってるね。
203:デフォルトの名無しさん
07/01/03 23:36:10
URLﾘﾝｸ(www.rupan.net)
PASS: CLI
204:デフォルトの名無しさん
07/01/06 00:27:15
>>203
これってなんだったの？
205:デフォルトの名無しさん
07/01/06 00:31:07
仕様書のスキャン画像
206:デフォルトの名無しさん
07/02/24 01:07:33
C++/CLIでWPFの開発できないの？
207:デフォルトの名無しさん
07/02/24 18:54:27
できないほうが不思議
208:デフォルトの名無しさん
07/03/01 04:46:46
IDEのサポートがあるかどうかは別問題だけどね。
209:デフォルトの名無しさん
07/03/01 20:21:14
C++/CLIでのWPF開発ではIDEのサポートは無いの？
210:デフォルトの名無しさん
07/03/01 21:27:14
XAMLPadで十分じゃん
どうせUIはC++じゃなくてXMLで書くんだし
211:デフォルトの名無しさん
07/03/01 21:27:51
Visual Studio 2007(2008?)には標準で入るはず。
212:デフォルトの名無しさん
07/03/03 19:31:33
literalって何のために追加されたの？
constでいいじゃん。
213:デフォルトの名無しさん
07/03/04 16:28:43
>>212
よく知らんが、名前の通りリテラルの為なんじゃないのか？
214:デフォルトの名無しさん
07/03/04 17:59:55
いやだってManaged C++ではstatic constで済んでいただろ。
215:デフォルトの名無しさん
07/03/04 22:20:44
フィールドにCILで言うところのliteral属性をつけるか否かを区別できるようになった
216:デフォルトの名無しさん
07/03/06 23:10:16
Managed C++ではunmanagedなものとの区別があいまいだったから、
出来るだけ違う名前を付けるようにしたとかそんなのじゃないの？
参照周りとかgcnewとか見ててもそういう思想に見えるんだが
217:デフォルトの名無しさん
07/04/09 19:24:28
流れぶった切って申し訳ないですが、質問です。
C++/CLIで、既存のネイティブ関数をラップして、
public ref class Test
{
public :
static void show( System::Int32^ x ) {}
static void show( System::Double^ x ) {}
};
というようなクラスを作って、C#から
static void main()
{
Test.show( 1 );
Test.show( 2.0 );
}
という風にオーバーロードして呼び出たんですが、
次のメソッドまたはプロパティ間で呼び出しが不適切です: 'Test.show(System.ValueType)' と 'Test.show(System.ValueType)'
というエラーがでて、コンパイルできませんでした。
エラーをみると、引数のSystem::Int32とSystem::DoubleがSystem::ValueTypeになってる
っぽいんですが、正しくラップするにはどういう風に書くんでしょうか？
218:デフォルトの名無しさん
07/04/09 19:34:18
＾
219:デフォルトの名無しさん
07/04/09 20:42:10
>>217
そういうこと。値型はハンドルを使わず生の型を使え。
C++/CLIで値型へのハンドルはボックス化の扱い。
IL上の引数・戻り値は、System.ValueType（これ自体は参照型）となる。
URLﾘﾝｸ(vene.wankuma.com)
基の型の情報も記録しているので、IL上は多重定義可能で、
C++/CLIでもコンパイラがそれを認識して多重定義解決を行う。
しかしC#コンパイラはそれを知らないので、
単にSystem.ValueTypeを1つ引数に取るメソッドshowが2つあるとしか認識できない。
220:217
07/04/09 23:01:02
>>218-219
なるほど。
解決しました！ありがとうございます。
221:デフォルトの名無しさん
07/05/09 18:06:56
○コンストラクタ
StreamReader^ FormDataReader = gcnew StreamReader("FormData.txt", System::Text::Encoding::GetEncoding("shift-jis"));
String^ locationX = MainFormDataReader->ReadLine();
String^ locationY = MainFormDataReader->ReadLine();
String^ SizeW = MainFormDataReader->ReadLine();
String^ SizeH = MainFormDataReader->ReadLine();
locationX = locationX->Substring(locationX->IndexOf("=") + 1);
locationY = locationY->Substring(locationY->IndexOf("=") + 1, locationY->IndexOf("}") - locationY->IndexOf("=") - 1);
SizeW = SizeW->Substring(SizeW->IndexOf("=") + 1);
SizeH = SizeH->Substring(SizeH->IndexOf("=") + 1, SizeH->IndexOf("}") - SizeH->IndexOf("=") - 1);
this->SetDesktopBounds(int::Parse(locationX), int::Parse(locationY), int::Parse(SizeW), int::Parse(SizeH));
MainFormDataReader->Close();
//最初の表示位置を記録
this->OnResizeEnd(nullptr);
○デストラクタ
StreamWriter^ FormDataWriter = gcnew StreamWriter("FormData.txt", false, System::Text::Encoding::GetEncoding("shift-jis"));
MainFormDataWriter->WriteLine(this->WindowState);
MainFormDataWriter->WriteLine(LocationString->Replace(",", "\r\n"));
MainFormDataWriter->WriteLine(SizeString->Replace(",", "\r\n"));
MainFormDataWriter->WriteLine(splitContainer1->SplitterDistance);
MainFormDataWriter->WriteLine(splitContainer2->SplitterDistance);
MainFormDataWriter->Close();
222:デフォルトの名無しさん
07/05/09 18:09:35
○初期設定
String^ LocationString;
String^ SizeString;
this->ResizeEnd += gcnew System::EventHandler(this, &MainForm::MainForm_ResizeEnd);
○フォームのサイズと位置を取得する
private: System::Void MainForm_ResizeEnd(System::Object^ sender, System::EventArgs^ e) {
LocationString = "" + this->Location;
SizeString = "" + this->Size;
}
長かったので分割してカキコしました
今日出された課題でフォーム位置を記録するという物があったのですが、どうしても汚くなってしまいます。
もう少し効率の良いフォーム位置の記録方法はありませんか？
223:デフォルトの名無しさん
07/05/09 21:05:32
なんつうかきったねえな、おい。
Hashtableに格納してシリアライズするとか、
シリアライズ可能な構造体を定義してそれを保存するとか、
自前で読み書きするにしても、せめて、生の整数値で保存しろよ。
224:デフォルトの名無しさん
07/05/09 22:03:19
>>223
ご指摘ありがとうございます
>自前で読み書きするにしても、せめて、生の整数値で保存しろよ。
苦肉の策で、無理矢理保存してました（汗
225:デフォルトの名無しさん
07/05/10 08:14:13
String^ a = "a";
String^ b = a;
a = "b";
これでbが"b"にならないのはどういう仕組みなんでしょうか？
いろいろ調べましたが結局わかりません。
226:デフォルトの名無しさん
07/05/10 08:18:49
int n = 1;
int* a = &n;
int* b = a;
int m = 2;
a = &m;
で b が 2 になりません、って言ってるのと同じこと。
227:デフォルトの名無しさん
07/05/10 08:19:26
間違えた。*b が 2 に、だった。
228:デフォルトの名無しさん
07/05/10 08:44:36
>>226
ありがとう。なんかぼけてました。(;´Д｀)
229:デフォルトの名無しさん
07/05/15 21:09:57
（ﾟДﾟ）
230:デフォルトの名無しさん
07/05/17 01:46:32
致命的なエラーです。 (HRESULT からの例外: 0x8000FFFF (E_UNEXPECTED))
という警告がデザイナーで急に頻繁に表示されるようになってしまったのですが、
どなたか解決策をご存じありませんか？
コンパイルはちゃんとできるんですけど...
231:デフォルトの名無しさん
07/05/17 18:01:24
言語伝々自体にドトネトコード自体がお呼びじゃないからな。
232:デフォルトの名無しさん
07/05/17 22:56:54
誤爆け？
233:デフォルトの名無しさん
07/05/18 16:56:09
でんでん？
云々の間違いなんだろうが、どうすればそんな間違いが起こるんだｗ
234:デフォルトの名無しさん
07/05/18 17:16:41
＞伝々
思わずふいてしまた
235:デフォルトの名無しさん
07/05/25 16:01:13
treeViewの再描画を一時停止したいんだけどどうすれば良いの？
236:デフォルトの名無しさん
07/05/25 17:22:17
初めまして、VC++のC++/CLIのフォームアプリケーションについて質問があります。
今、LimeChat 2 の様なアプリを作っていています。
そのアプリのテキストボックスには、カーソルが表示されていません。
どのようにすれば、カーソルを表示させないようにできるのでしょうか？
また、TreeViewの再描画を一時停止させたいのですが、どうすればよいのでしょうか？
237:デフォルトの名無しさん
07/05/26 00:24:49
再描画のハンドラをオーバーロードして
止めたいときだけ無視する。
238:デフォルトの名無しさん
07/05/26 00:28:12
自己解決しました！
>>また、TreeViewの再描画を一時停止させたいのですが、どうすればよいのでしょうか？
treeView->BeginUpdate();
キャレットが出無くなればいいわけです
Win32 APIにHideCaretという関数があるのですが、C++/CLIではどうしても見つけることができませんでしたorz
239:デフォルトの名無しさん
07/05/27 15:49:02
iconv (iconv_t cd, const char* * inbuf, size_t *inbytesleft, char* * outbuf, size_t *outbytesleft);
この関数のinbufにString^を渡したいのですがうまくキャストできません。
pin_ptr<const wchar_t> pIn = PtrToStringChars(in);
pin_ptr<const char> pInPass = pin_ptr<const char>pIn; // error
iconv(cd, &pInPass, &inlength, pOutPass, &outlength) )
どうやってキャストすればいいのでしょうか？
240:デフォルトの名無しさん
07/05/27 20:26:06
pInの段階で既にpinされているのだから、後は普通のC++と同じように
const char* pInPass = reinterpret_cast<const char*>(pIn);でいいと思う。
241:かも
07/05/27 23:33:12
だれか、ニューメリカルレシピインシーっていう本やったことある人いませんか（？？）
242:デフォルトの名無しさん
07/05/28 02:05:15
>>239
URLﾘﾝｸ(msdn2.microsoft.com)(VS.80).aspx
String^からstd::stringにしてc_str()で渡せば。
243:デフォルトの名無しさん
07/05/28 10:20:36
>240
できました。ありがとう。
>242
できればコピーしないでやりたかったので。
244:デフォルトの名無しさん
07/05/29 18:10:26
こんなものC++の標準が改定されたら置いてきぼりになるじゃんか
志ねMS
245:デフォルトの名無しさん
07/05/29 19:22:06
C++/CLIはC++ではないと何度言ったら分かるんだね。
246:デフォルトの名無しさん
07/05/29 19:25:48
C++自体がC99から置いてきぼりになってますが何か？
でもってC++/CLIも世界標準規格のわけだが
247:デフォルトの名無しさん
07/05/29 20:05:06
世界標準言ったって、盲判で有名なECMAだろ？
ちょっとまえにISOに蹴られたばっかじゃん。
248:デフォルトの名無しさん
07/05/29 22:43:18
実装がひとつしかないのに世界標準とかいわれても非常に困る
249:デフォルトの名無しさん
07/05/30 00:09:22
っ Mono
250:デフォルトの名無しさん
07/05/30 00:14:38
>>249
だから一つしかないんだろ？
251:デフォルトの名無しさん
07/05/30 00:14:44
MonoにC++/CLIコンパイラなんてあったの？
252:デフォルトの名無しさん
07/05/30 00:17:41
いずれできる
253:デフォルトの名無しさん
07/05/30 00:20:26
>246
はあ? ISOに蹴られてるだろ? どこが世界標準規格なんだよ。
嘘もいい加減にしろ。
254:デフォルトの名無しさん
07/05/30 00:23:11
URLﾘﾝｸ(www.ecma-international.org)
無知は黙っとけ
おっとお子ちゃまに英語は読めないかなw
255:デフォルトの名無しさん
07/05/30 00:27:19
>>254
あれ？ なにそれ？ なんで普通になんの制限もないPDFがダウンロードできるの？
単にECMA規格がそーゆーもんなの？ それともドラフトかなんか？
256:デフォルトの名無しさん
07/05/30 00:28:47
標準規格に制限かける標準化団体はいね。
257:デフォルトの名無しさん
07/05/30 00:28:48
もう、C++/CLIは死に体。
258:デフォルトの名無しさん
07/05/30 00:29:58
>>256
IEEE
259:デフォルトの名無しさん
07/05/30 01:00:15
CLIもDも
C++0xへの叩き台なので問題ない
260:デフォルトの名無しさん
07/05/30 01:45:36
>>256
ISO も JIS も普通に金取られるぞ
261:デフォルトの名無しさん
07/05/30 02:35:21
ANSIも
262:デフォルトの名無しさん
07/05/30 22:01:33
規格がみんな無料で閲覧できるようになればいいのに
コストはともかくトラフィックで死ねるからやらないんだろうけど
263:デフォルトの名無しさん
07/05/31 00:15:28
いらないものをさも必要があるかのように作って無駄にはやらせようとするM$は死ねばいいのに
264:デフォルトの名無しさん
07/05/31 01:02:17
開発者に対してろくなアプローチをしないところよりはまだマシさ。
265:デフォルトの名無しさん
07/05/31 07:02:19
>>263
禿は「ライブラリで出来るところはライブラリでやれよ。
テンプレートで出来るだろ」という見解だったな。
というわけで、ISOでは蹴られ続けるだろうな。
実際5月のミーティングでも駄目だったし。
266:デフォルトの名無しさん
07/05/31 11:19:11
VC++2005です。
メインフォーム上に置いたコントロールのWndProcをオーバーライド
したいんですが。普通に継承して、メインフォームのコードを書き換えると、
フォームデザイナーがうまく機能しなくなってしまいます。
フォームデザイナをちゃんと動かすためにはいろいろ大変みたいで
できればやりたくないです。もっと簡単にWndProcをオーバーライド
する方法はないでしょうか？
267:デフォルトの名無しさん
07/05/31 11:34:27
結局、C++/CLIとC++でいつでも分離できるように実装するしかないんだよな。
C++/CLI側は「まだ実装するべき機能はあるから、追加しちゃうよ」とかほざいてるし、
標準じゃないのはいらねぇよ。
268:デフォルトの名無しさん
07/05/31 15:51:15
about C# Mono
Mono C# compiler version 1.2.2.1
C# Language Specification ECMA-334
Common Language Infrastructure (CLI) ECMA-335
Home Page: URLﾘﾝｸ(www.mono-project.com)
Download: URLﾘﾝｸ(www.mono-project.com)
269:デフォルトの名無しさん
07/05/31 17:26:09
で？
270:デフォルトの名無しさん
07/05/31 18:51:50
>>268
君さ、何か勘違いしてる気がするよ。
271:デフォルトの名無しさん
07/05/31 20:47:23
C++/CLIで作ると移植性が落ちる。
272:デフォルトの名無しさん
07/05/31 21:16:15
ポートも糞もないだろｗ
273:デフォルトの名無しさん
07/05/31 23:26:57
質問です。
using namespace System;
using namespace System::Collections::Generic;
ref class HogeItem;
generic<typename CItem>
where CItem : HogeItem
ref class HogeList;
public ref class HogeItem abstract {
internal:
HogeList<HogeItem^>^ list;
};
generic<typename CItem>
where CItem : HogeItem
public ref class HogeList abstract : IList<CItem> {
public:
virtual void Insert(int index, CItem item) {
item->list = this; ←ここでエラー
}
};
HogeItem::list の型は HogeList<HogeItem^>^ なんですが、this が HogeList<CItem>^ なので
変換できないって怒られます。
IList<HogeItem^>^ とかにしてもだめでした。
generic の宣言のほうを変更しても良い方法が見つからず、困っています。
item 側にどの List に格納されたのか知らせる手段がほしいのですが、
うまい方法は無いでしょうか？
274:デフォルトの名無しさん
07/06/01 08:39:29
＞271 名前： デフォルトの名無しさん [sage] 投稿日： 2007/05/31(木) 20:47:23
＞C++/CLIで作ると移植性が落ちる。
だから世の中の０＄や重要なソフトはC++なのさ。
275:デフォルトの名無しさん
07/06/01 11:56:46
>>273
item->list = (HogeList<HogeItem^>^) this;
HogeListは事実上HogeItemの派生クラス専用なのだから、
IList<T>の継承じゃなくてListを包含してしまったほうが楽だと思うけどな。
276:デフォルトの名無しさん
07/06/04 00:21:36
ネイティブのクラスがハンドルを持てないのはなぜ？
277:デフォルトの名無しさん
07/06/04 11:19:47
ハンドルはGC管理領域を指すマネージドポインタだから。
278:デフォルトの名無しさん
07/06/04 14:38:46
>>277
それは織り込み済みです。
279:デフォルトの名無しさん
07/06/04 15:13:16
ベンダーはECMAを見るだろうからISOとか関係ないっしょ
280:デフォルトの名無しさん
07/06/04 15:50:03
いや、ベンダーって、誰が実装するのよ？
281:デフォルトの名無しさん
07/06/04 18:39:41
>>276
ネイティブクラスのインスタンスは、マネージヒープ・スタック以外に作られる可能性がある
しかし、CLRのGCは、自身が管理するメモリ以外を見ない
だからネイティブクラスはハンドルを持てない
おとなしくmsclr::gcrootを使いなさいということ
282:デフォルトの名無しさん
07/06/04 18:49:32
>>281
ありがとう。
つまりネイティブヒープ上にあると、ハンドルがGC対象にしていいか追跡
できなくなるって理解しました。
gcrootなんてあったんですね。調べてみます。
283:デフォルトの名無しさん
07/06/04 18:49:50
CreateFileとかCloseHandle呼べばいいんでは？
284:デフォルトの名無しさん
07/06/04 19:00:12
審議中
∧,,∧ ∧,,∧
∧ (´・ω・) (・ω・｀) ∧∧
( ´・ω) Ｕ) ( つと ﾉ(ω・｀ )
｜ Ｕ ( ´・) (・｀ ) と ﾉ
ｕ-ｕ （l ) ( ﾉu-ｕ
`ｕ-ｕ'. `ｕ-u'
285:デフォルトの名無しさん
07/06/04 19:16:51
>>279
つーか、ECMAに最初だけ登録しておいて、
以後のバージョンアップは放置ってのがMSの手法。
で「仕様は公開されてますよ、オープンです」って言う。
286:デフォルトの名無しさん
07/06/04 19:33:12
C++/CLIで作ったら、各部署、それぞれから大ブーイングだぜ。
287:デフォルトの名無しさん
07/06/04 19:37:41
C#はJIS通ったんだが
288:デフォルトの名無しさん
07/06/04 21:02:25
>>286
なんで？
289:デフォルトの名無しさん
07/06/05 01:13:42
>288
ソースが転用できねーじゃねーか。ぼけ、死ね、くたばれ。
って言われる。
290:デフォルトの名無しさん
07/06/05 05:53:23
ネットワークドライブ上のファイル X:\あああああ\いいいいい.txt
があり、ファイル名は日本語とします。
また、ファイル名としてconst char*を受け取るライブラリの関数libfuncがあります。
これは変更不可です。
英語XPでこのlibfuncにパスを渡すいい方法はないでしょうか？
以下のようなコードだとconst char*に変換するとき X:\??????などと
なり、読み込み不可になってしまいます。
String^ filename = L"X:\\あああああ\\いいいいい.txt";
System::IntPtr pp = StringToHGlobalAnsi(filename);
const char* afilename = (const char*)pp.ToPointer();
libfunc(afilename);
FreeHGlobal(pp);
shortpathを使う方法も思いついたのですがGetShortPathNameWで変換しても
X:\ああ~1\ などとなり日本語が残ってしまうためconst char*にうまく変換
できません。
291:デフォルトの名無しさん
07/06/05 05:54:24
続きです。
さらにもし可能なら、英語版windows98でも動くようにしたいです。
292:デフォルトの名無しさん
07/06/05 08:28:02
PtrToStringCharsの戻り値をpinして、
自分でWideCharToMultiByteやその他の手段でマルチバイト文字列へ変換
その際マルチバイト文字列の文字コードにShift_JIS (CP932)を指定
XP (NT)なら、Unicode対応でないプログラムの言語の設定（コントロールパネル→地域と言語のオプション→詳細設定）
で日本語を選んでおけばこれで動くと思う。あるいはAppLocaleで個別指定する手もある
98 (9x)は無理
293:デフォルトの名無しさん
07/06/05 23:56:10
String^ temp;
^って、なんの意味があるんですか？
294:デフォルトの名無しさん
07/06/05 23:58:15
ポインタ
295:デフォルトの名無しさん
07/06/05 23:59:01
ハンドル
296:デフォルトの名無しさん
07/06/06 00:10:54
>>294
ポインタ？
String* temp;
はなくなったんですか？
>>295
すいません、よくわかりません。
297:デフォルトの名無しさん
07/06/06 00:14:05
ハンドルで分からないなら managed なポインタと思っとけばおｋ
298:デフォルトの名無しさん
07/06/06 00:55:44
>>297
有難う御座います。
そのように思っておきます。
299:デフォルトの名無しさん
07/06/06 02:46:37
>>293
C++/CLI の変更点くらい確認しようぜ
ヘルプで C++/CLI Version 2, マネージ拡張 から
変更の概略を見れば出ている
300:デフォルトの名無しさん
07/06/06 10:33:56
でも、ぶっちゃけ、CLIにメモリ管理を任せる意味はあるのか。
301:デフォルトの名無しさん
07/06/06 11:32:38
>>300
DLLをまたいでオブジェクトが行き来しても、
メモリアロケータが違ってあぼんとかしないのはイイよ。
もちろんネイティブC++だってわかっている人が使えば問題ないんだけど。
ヘッダファイルにnew書いててそれがDEBUG_NEWに置換されて死亡とかイヤ過ぎる。
URLﾘﾝｸ(forums.microsoft.com)
302:デフォルトの名無しさん
07/06/06 13:21:26
>301
その為に共有メモリってのがあったわけだが…。
ちょっとコスト対効果のバランスが悪い理由な気がする。
303:デフォルトの名無しさん
07/06/06 13:25:03
>>302
共有メモリはプロセス間でメモリ共有したいときのものだと思うけど。
DLLはもとからメモリ空間共有してるわけだし、
メモリ共有で何を解決するつもりなのかサパリワカラン
304:デフォルトの名無しさん
07/06/06 14:29:10
>>303
DLLのスタティック領域がプロセス間で共有されてたのはWindows 3.1時代の話だぜ
305:290
07/06/06 19:50:35
>>292
ありがとう。
しかし290の例の日本語は他の言語の場合もあり、またはUnicodeでしか
表わせない混合型の場合もあるので、もっと根本的な解決法があれば
いいんですが。
306:デフォルトの名無しさん
07/06/07 00:18:32
根本的な解決があるとすれば、そのライブラリをどうにかするしかない
ハンドルやファイルポインタ・ストリーム辺りが渡せればだいぶましなんだが
307:デフォルトの名無しさん
07/06/13 07:45:40
アンマネージドで格納したバイト配列をcli::array<unsigned char,1>にしたいのですが、
どうすればいいのでしょうか？
int size = 1024;
byte *buf = new byte[size];
cli:array<unsigned char,1> ^arr = gcnew cli:array<unsigned char,1>(size);
System::Runtime::InteropServices::Marshal::Copy((IntPtr)buf, arr, 0, size);
//ここでエラーになる。
308:デフォルトの名無しさん
07/06/13 17:50:08
IntPtrをSystem::IntPtrにしたこと以外はそのままでも問題なさそうだし、
実際試しに動かしてみても問題なかったぞ
309:デフォルトの名無しさん
07/06/14 01:37:21
>>308
ありがとうございます。
すみません。問題は別のところにありました。
実際は*bufは関数でネイティブに渡していて、そこにそのまま渡していたという初歩的なミスです。
void nativefunc(byte **buf_p, size_t *size) {
//--- nativefunc(byte *buf_p, size_t *size) これで宣言していた
*size = bitmap.size;
byte *data = new byte[*size];
memcpy(//--- データ書き込み
*buf_p = &data[0]; //--- cliのbufのアドレス書き換え
}
void clifunc() {
size_t size;
byte *buf;
(new NativeCls)->nativefunc(&buf, &size);
//--- nativefunc(buf, &size); そのまま渡していた
cli:array<unsigned char,1> ^arr = gcnew cli:array<unsigned char,1>(size);
System::Runtime::InteropServices::Marshal::Copy((IntPtr)buf, arr, 0, size);
}
310:デフォルトの名無しさん
07/06/21 00:39:09
String a("A");
これがコンパイルできないのはなぜですか？
error C3149: 'System::String' : トップレベルの '^' なしに、この型をここに使用することはできません
311:デフォルトの名無しさん
07/06/21 00:46:21
トップレベルの '^' なしに、この型をここに使用することはできないから。
312:デフォルトの名無しさん
07/06/21 01:45:46
>>311
その理由を聞いています。
313:デフォルトの名無しさん
07/06/21 07:33:41
仕様だからとしか
314:デフォルトの名無しさん
07/06/21 08:49:15
仕様ですか。しかしObjectやStringBuilderなどは^がなくてもOKなので、
Stringのみ特別な事情があると理解すればいいでしょうか？
315:デフォルトの名無しさん
07/06/21 09:20:15
MSDNには対象外としか書いてないね。
The following reference types are not available for use with stack semantics:
delegate / array / String
予想だけどこれらはIDisposableでないので出来ても意味が少ない。
出来たとしてもハンドルに変換しないと使えない。
String s("A");
String^ x = "abcd" + %s;
String^ x = "abcd" + s.ToString();
316:デフォルトの名無しさん
07/06/21 10:55:52
>>315
ありがとう。
使い道がないということで理解しようと思います。
317:デフォルトの名無しさん
07/06/22 17:45:52
delegateは知らんが、arrayやStringは.NET ILレベルで特別扱いしてるからかもな。
318:デフォルトの名無しさん
07/06/24 09:16:58
VC2005でデバッグしてるとステップ実行で変なところを
さしてしまう場合があってデバッグしづらいんですが
直す方法はありますか？
nop命令があってそこでへんなとへこいきます。
319:デフォルトの名無しさん
07/07/06 05:55:39
GUIなアプリケーションを作るために
C#の「Windowsアプリケーション」プロジェクトでいくか
C++/CLIの「Windowsフォームアプリケーション」プロジェクトで行くか悩む。
アンマネージドなC++クラス（とboost）で書かれたCUI
アプリケーションのGUI版を作ろうとしています。
C# でもアンマネージドな DLL のエントリを呼び出すことできますし。
でもアンマネージドな C++ のクラスを使いまくりたいんだけど
どうしたものか・・・ COM コンポーネントとして作られていれば
容易に扱うことができたのかもしれないけど。
アンマネージドな C++ で書かれたクラスのインスタンスを
生成したい時って、そのクラスのファクトリメソッドを
用意しておいてそれを C# 側から呼び出すということになるんですかね？
C++ 特有の複雑な（引数の型を反映した）関数名とかどうなるんだろう。
extern "C" つかうのか。
320:デフォルトの名無しさん
07/07/06 05:56:10
ごめん、書いてる途中で C# な話題になってしまった。
321:319
07/07/06 06:41:49
それで、肝心のことなんですが、アンマネージドな C++ のクラスを
.NET 環境で使うためには C++/CLI でラッパークラスを書けば
いいのでしょうか？そうするとマーシャリングなども自動で
やってくれるということなのでしょうか？
DLL は C++ にやさしくない、かといって COM コンポーネント
として書いてしまうとプラットフォームに強く依存しすぎるので
一般的な用途のクラスライブラリには向かない、
でもアンマネージドな C++ のクラスを .NET と仲良くさせたい、
という課題をどう解決すればいいのかを教えてください。
322:デフォルトの名無しさん
07/07/06 08:19:58
> そうするとマーシャリングなども自動で
> やってくれるということなのでしょうか？
そういうことになるが、ある意味自分で
マーシャリングコードを書く補助をしていると言ってもいいかもしれない。
アンマネージクラスをC#（やその他.NET言語）から呼び出したければ、
C++/CLIでそのクラスをラップしたマネージクラスを含むマネージドDLLを作って、
他の言語から参照設定して使うのが一番率直な手段。
そもそもC#でアンマネージDLLのC++クラスを操作するなんて不可能だぞ。
（COMインタフェース経由を除く）
323:319
07/07/06 10:57:16
>C++/CLIでそのクラスをラップしたマネージクラスを含むマネージドDLLを作って、
>他の言語から参照設定して使うのが一番率直な手段。
やっぱそうですか、ある意味安心しました。
System.Runtime.Interop 以下にいろいろあるのを眺めてて、
もしかしてマネージドからなんかうまい具合にごにょごにょ
できる方法が用意されてるのかなぁ、などと疑心暗鬼になってました。
324:デフォルトの名無しさん
07/07/07 13:26:04
VC2005でデフォルトのフォームアプリを作成して、
CLRサポートを/clrにして以下のインクルードを追加すると
実行時ヒープエラーみたいなのが出ます。
#include <comdef.h>
#pragma comment(lib, "oleaut32.lib")
どうやって直したらいいのでしょうか？
325:デフォルトの名無しさん
07/07/24 03:07:41
なんで Void って大文字になったの？
326:デフォルトの名無しさん
07/07/24 03:13:36
ヘミvoidが権利を主張するのを避けるため
327:デフォルトの名無しさん
07/07/24 23:16:42
System::Void のこと？
328:デフォルトの名無しさん
07/07/24 23:50:23
当たり前のことなんだろうけどvoid代わりに使えるのが少し不思議に感じる。
#include <cstdlib>
int main()
{
System::Void* pv = std::malloc(256);
std::free(pv);
}
329:デフォルトの名無しさん
07/07/25 02:28:58
自分自身の起動パスを得るにはどうしたらいいの？
330:デフォルトの名無しさん
07/07/25 13:29:14
CRTの__argv[0]やWin32のGetModuleFileName(0,とか
.NETのSystem::Windows::Forms::Application::ExecutablePathなど。
331:デフォルトの名無しさん
07/07/25 22:11:43
Applicationにあったのか！
ありがとう。
ずっとProcessとかを探してたよ
Win32APIのときGetModuleDirectoryとかなんとかだったから
332:デフォルトの名無しさん
07/07/25 22:51:56
>>331
その線も惜しい。
Win32はGetModuleFileNameだったでしょ。
.NETだとモジュール (EXE/DLL)に対応するものはアセンブリだから、
その方向でやるならAssemblyクラスが正解だった。
URLﾘﾝｸ(www.atmarkit.co.jp)
333:デフォルトの名無しさん
07/07/27 12:14:00
Visual Studio 2005 で C++/CLI を使おうとしています。
std::vector<System::String^> のように標準のSTLのコンテナには
ハンドルを格納することはできないのでしょうか？
C++/CLI にはマネージドな世界独自のコンテナクラスライブラリが
用意されているのでしょうか？今の自分は array<String^>
しか使えずさみしい毎日を過ごしています。
std::vector<System::String^>^ lines;
try{
for(;;)
lines->push_back(stream_reader->ReadLine());
} catch
以下略
のようにぶん回してファイルを行単位で全行
読み込みたいだけなのですが・・・
334:デフォルトの名無しさん
07/07/27 12:19:12
>>333
＞C++/CLI にはマネージドな世界独自のコンテナクラスライブラリが
つSystem::Collections::Generic
STL.NET構想はどっかいっちゃったけどな
335:デフォルトの名無しさん
07/07/27 12:26:29
>>334
おお、「コレクション」というのですか。
どうりで C++ CLI コンテナ で検索していても
昔の managed C++ の資料や gcroot でがんばる
という方法しか見つからず難儀していました。
しかも cliext::vector なんかも見つかってしまい、
余計に混乱していました。cliext 名前空間以下の
識別子ってのが STL.NET なんですかね？
336:デフォルトの名無しさん
07/07/27 12:42:30
>335
STL.NET は STL/CLR という名前で VS2008 に同梱
ただ、.net fx 2.0 では動かない
こういう後方互換性がないものを C++/CLI で出してほしくなかった
337:デフォルトの名無しさん
07/07/27 12:47:04
＞後方互換性
上位互換が無いってことか？
338:デフォルトの名無しさん
07/07/27 12:49:22
>>336
それで困るやつはどれだけいるんだ
339:デフォルトの名無しさん
07/07/27 12:51:29
STLってのはC++では最重要なんだが...
340:デフォルトの名無しさん
07/07/27 12:55:13
>>336
それ本当？
.NET Framework 3.0も3.5もCLRのバージョンは2.0のままだろ。
341:デフォルトの名無しさん
07/07/27 13:07:08
.net fx 2.0 で作ってた既存アプリに STL/CLR を使って修正すると、アプリの実行に
3.5 が必要になるのは嫌じゃね？
前のCTPの頃はライブラリだけ持って行けばよかったんだが
342:デフォルトの名無しさん
07/07/27 13:22:05
>340
Beta1 で Microsoft.VisualC.Stlclr.Dll ＋ヘッダ抜き出しで駄目だったという報告があった
とりあえず、Beta2 が来てるんで、入れて試してみる
一応、「Microsoft.VisualC.Stlclr.Dll は .net fx 3.5 の一部ではない」はずなんだが
343:デフォルトの名無しさん
07/07/27 13:47:59
>>341
>.net fx 2.0 で作ってた既存アプリに STL/CLR を使って修正すると、アプリの実行に
>3.5 が必要になるのは嫌じゃね？
>前のCTPの頃はライブラリだけ持って行けばよかったんだが
コンパイルし直すんだろ？
どうせmsvcp90.dllとか増えてるんじゃないの？
VC++のランタイムライブラリに同梱ってのが幸せになる道かねぇ。
まあ3.5のサイズにもよるな。
344:デフォルトの名無しさん
07/07/27 14:43:50
>343
客先に説明するのが面倒なんだよね。でも、STL/CLR は使いたい
できれば、CTP同様に VS2005 + ヘッダ + Microsoft.VisualC.Stlclr.Dll で STL/CLR を
使った開発ができる方がうれしい。SP2 で来ないものかな
345:デフォルトの名無しさん
07/07/27 17:14:22
std::vector<int> v;
：
for each(int i in v)
{}
for eachでbegin(), end()が呼ばれているようですが
ECMA-372にはこの振る舞いの記述が見あたりません。
MSの独自拡張なのでしょうか?
346:デフォルトの名無しさん
07/07/28 00:28:26
>345
これでも行けますね
int vec[] = { 1, 2, 3, 4, 5 };
for each ( int num in vec )
{
std::cout << num <<std::endl;
}
配列アクセスが可能なものは Array のラップを掛けて渡されているのでは
ないでしょうか。Array は IEnumerable ですし
347:デフォルトの名無しさん
07/07/28 00:34:44
>346
ごめん。これはできて当たり前だわ
array<int>^ vec = { 1, 2, 3, 4, 5 };
と同等だもんな
348:デフォルトの名無しさん
07/07/28 07:12:42
>>346
Cタイプ配列とarray<T>は同等じゃないから346は通らないのでは？
349:デフォルトの名無しさん
07/07/28 07:20:17
std::vectorに対するfor each inはネイティブでコンパイルしても使えてるな。
/Zeで拡張構文を抑制するとeachが構文エラーになった。
// cl /EHsc hoge.cpp
#include <iostream>
#include <vector>
int main() {
std::vector<int> v; v.push_back(1); v.push_back(5);
for each (int i in v) std::cout << i << std::endl;
return 0; }
350:デフォルトの名無しさん
07/07/28 18:16:58
>348
Cタイプ配列は C++/CLI では array<Type> でラップされるよ。だから、346 は動く
>347 がそれを言ってる
ヘッダ見たけど、特に ecma-372 で必要とされている IEnumerable の定義も
見あたらないから、CLR・・・で定義されている所に、拡張構文で潜んでるっぽい
351:デフォルトの名無しさん
07/07/28 18:24:10
VS2008 Beta2 試してみた。コンパイル対象となる .net fx が選べるようになったんだが
2.0, 3.0 を選んだとき、STLCLR.dll は使えなかった
STL/CLR を使いたかったら、3.5 を普及させろと言うことらしい
( ﾟдﾟ) Feedback ﾏﾝﾄﾞｸｻ
＿(__つ/￣￣￣/＿
＼/ /
￣￣￣
( ﾟдﾟ )
＿(__つ/￣￣￣/＿
＼/ /
￣￣￣
352:デフォルトの名無しさん
07/07/28 19:47:41
>>350
C#のCタイプ配列はCLR配列だが、C++/CLI のCタイプ配列はCLR配列じゃないぞ。
>>346を実際にコンパイルしてみろ、C3285でしっかりコンパイルエラーが出る。
353:デフォルトの名無しさん
07/07/28 23:12:16
VC8 SP1で試したけど/clrの有無に関わらずC3285になるね。
当たり前だけど、boost::arrayはOK。
どうせならレンジに使えればいいのに、
ってそれなんてBOOST_FOREACHなんだけどね。
354:名無しさん＠そうだ選挙に行こう
07/07/29 14:40:44
>352-353
悪禁食らっていたので返答が遅れた
ごめん。漏れが試したのは、VS2008 Beta2 だった。こちらは >346 でコンパイルできるし
動く。また、ecma-372 でも、仕様上 346 で正しいから、VC8 で取りこぼしてた仕様が
いくつかあったやつを VC9 で準拠したんだと思う
/clr の有無に関わらずって、/clr なくて for each が使えるの？
355:名無しさん＠そうだ選挙に行こう
07/07/29 19:24:33
>>354
349でネイティブでも使えるという報告があるよ。
356:デフォルトの名無しさん
07/07/30 14:40:51
ファイル名をキーとするstd::mapのようなものを作りたく、Generic::Dictionaryのキー型にString^
比較にStringComparer:::CurrentCultureIgnoreCaseを指定してるのですが
全角アルファベットの大文字・小文字も同一視されてしまいます。
要するにNTFSやFATと同じようなファイル名の比較をしたいのですが、どうすればいいんでしょうか?
357:デフォルトの名無しさん
07/07/30 15:16:49
つ ネイティブC++
358:デフォルトの名無しさん
07/07/30 15:50:00
>>356
WindowsのNTFSファイルシステムドライバは"Ａ"と"ａ"は同じ文字とみなしてるよ？
359:デフォルトの名無しさん
07/07/30 16:11:47
>>358
あ、ほんとだ。区別されるものと思ってた。
360:デフォルトの名無しさん
07/07/31 10:22:34
>>356
カーネルの中には比較する関数あるんだけどね・・・
なんでユーザーモードに無いのかは謎
まじめにやると日本語やアルファベット以外の文字（ヨーロッパ圏など）でも
全角半角を問わず大文字小文字を区別しないので
割と面倒だった気がする。
361:デフォルトの名無しさん
07/08/01 04:25:12
Visual Studio 2005 で C++/CLI を使っています。
フォームデザイナの機能で C++/CLI と C# の間に
違いはあるのでしょうか？
つまり C# でのフォームデザイナと、C++/CLi での
フォームデザイナの間に、利用できるコントロールの
種類などで違いがあるのでしょうか？
.NET Framework で用意されている機能なら言語によらず
利用可能だとおもうので差はないと思っているのですが。
362:デフォルトの名無しさん
07/08/01 04:54:48
マネージドなプログラム組むならＣ＋＋なんか使わねっつの！ｗ
363:デフォルトの名無しさん
07/08/01 08:38:47
＞マネージドなプログラム
これってメリットある？
いや、一般論じゃなくて実際のところ。
364:デフォルトの名無しさん
07/08/01 09:07:42
プラットフォームにVistaが使えるじゃねーか。
365:デフォルトの名無しさん
07/08/01 09:14:12
いや、Vi$taにあうのはネイティブアプリ。
366:デフォルトの名無しさん
07/08/01 11:44:46
>>363
自分専用ツールにはクラスライブラリが充実しているので便利。
367:デフォルトの名無しさん
07/08/01 12:01:52
>>366
それにしては、Win32で出来るものが出来なかったり、中途半端。
だったらVCLみたくネイティブクラスライブラリ充実させろよ。
368:デフォルトの名無しさん
07/08/01 12:05:21
＞クラスライブラリが充実しているので
これって、ネイティブ版クラスライブラリを作成すれば完璧だおね。
M$のﾄﾞﾄﾈﾄ囲い込み戦略に嵌められてるだけじゃないの？
ﾄﾞﾄﾈﾄは終焉したわけだし、無視した方が良いよ。
369:デフォルトの名無しさん
07/08/01 12:37:37
ドトネト君っていろんなスレにいるな。
飽きないの？
370:デフォルトの名無しさん
07/08/01 13:00:03
＞プラットフォームにVista
つ URLﾘﾝｸ(gigazine.net)
企業ユーザーの大多数はVistaへの移行を考えていない
371:デフォルトの名無しさん
07/08/01 16:47:45
そりゃ、CreateFile系のAPI自体がバグでロックしちゃうんだもの。
企業ユーザが使おうとするわけがない。 >> VISTA
372:デフォルトの名無しさん
07/08/01 17:10:29
>CreateFile系のAPI自体がバグでロックしちゃうんだもの。
kwsk
373:デフォルトの名無しさん
07/08/01 17:12:17
これか
URLﾘﾝｸ(d.hatena.ne.jp)
374:デフォルトの名無しさん
07/08/01 22:23:38
Form.hに実装を書かせられるの嫌なんだけど、どうにかならない？
てか、なんでForm.hに実装させるような仕組みにしたんだろう？
375:デフォルトの名無しさん
07/08/01 23:02:47
Form.cppに実装を移せば？
376:デフォルトの名無しさん
07/08/01 23:59:06
実装を書かせるといっても、イベント用に開発環境が自動生成したものですよね。
これをcppにということになると、たとえば、フォームデザインの変更を
ちょこちょこやる場合、Formのデザイナとヘッダとcppを行ったり来たりでは
やっぱり大変だよね。
377:デフォルトの名無しさん
07/08/02 00:59:04
ぶっちゃけVC++8の.NETサポートは「諦めろ」としか言えないよ・・・
378:デフォルトの名無しさん
07/08/02 04:03:15
VC++9 では何か変わってるの？
379:デフォルトの名無しさん
07/08/02 09:44:37
そりゃ変わってますよw
380:デフォルトの名無しさん
07/08/02 18:35:26
VC2008先行して使っている人、
デサイナが生成するコードに何か大きな変化は有りましたか？
381:デフォルトの名無しさん
07/08/02 21:36:34
試してみたけど変わってないみたいだね。残念だ…
382:デフォルトの名無しさん
07/08/02 22:27:36
C++/CLI に関してはろくに対応されていないね。STL/CLR なんか作ってる場合じゃないと
思うんだが。結局、ネイティブ・アプリの ClickOnce 対応もしていないし
383:デフォルトの名無しさん
07/08/02 22:53:42
いや、STL/CLRは「ろくな対応」なんじゃないか？
384:デフォルトの名無しさん
07/08/03 01:11:20
ネイティブの STL にマネージド・オブジェクトが格納できればいらない対応でしょ
むしろ、2種類のライブラリに混乱しかねない
385:デフォルトの名無しさん
07/08/03 01:41:52
マネージドなSTLはそれになりに便利だと思う。
標準C++ & boost萌えな俺には、C++/CLIやC#はきついんだが…
386:デフォルトの名無しさん
07/08/03 08:17:10
>>384
確かに。少なくともクラス定義だけでも、
ネイティブクラスと値クラスに違いがなければいける。
前にも書いた気がするけど、ハンドル用のアロケータ書いてみたが、
ネイティブクラスはハンドルを持てないのでだめだった。
387:デフォルトの名無しさん
07/08/03 08:27:31
C++0x の concept map が C++/CLI に実装されたら、それつかって managed class を STL コンテナにいれられるのでは...
388:デフォルトの名無しさん
07/08/03 10:16:37
だとしたら、ほんとに STL/CLR は C++0x が確定するまでの繋ぎでしかなくなるな
389:デフォルトの名無しさん
07/08/03 11:18:52
いや、一応STL/CLRは一度覚えればC#でも使えるんだろ?
390:デフォルトの名無しさん
07/08/03 11:21:41
STL/CLR は C++/CLI せんよーだってさ
テンプレートで実装してるしね
391:デフォルトの名無しさん
07/08/03 11:22:36
じゃあ、意味ねーなw
392:デフォルトの名無しさん
07/08/03 11:33:20
なんかグダグダ
393:デフォルトの名無しさん
07/08/03 16:46:48
でもまだSTL/CLRのコンテナは、System::CollectionsやSystem::Collections::Genericの
インタフェースを実装しているのが強みと言えるかもしれない。
394:デフォルトの名無しさん
07/08/03 16:51:41
STLがあればGenerics要らんやん。
395:デフォルトの名無しさん
07/08/03 17:49:38
C# にも展開してくれれば良かったんだけどなぁ
396:デフォルトの名無しさん
07/08/04 00:58:40
まぁどっちかっつーと.NET言語の態勢を保ちつつ
コンパイル時のコード生成であるC++テンプレートをサポートするってのが
端から無茶やってるとは思うけどねぇ。
397:デフォルトの名無しさん
07/08/04 13:00:12
C++/CLIでは
stringstream
に相当するものは用意されているのでしょうか？
398:デフォルトの名無しさん
07/08/04 13:03:09
.NETのクラスライブラリにはMemoryStreamが似ている存在。
でもstringstreamだって使いたければ使えばいいし。
399:デフォルトの名無しさん
07/08/04 15:31:51
StringBuilder や StringReader, StringWriter を使ってもいいな
400:デフォルトの名無しさん
07/08/04 23:23:24
C++/CLIでも派生させるクラスのデストラクタはvirtualにすべき？
勝手になる？
401:397
07/08/04 23:41:29
長さの単位がString,StringBuilderはInt32でStreamはInt64くさいけど
System::IO::Streamとしても使いたかったんで
MemoryStreamから派生することにした。
順序つきで使える operator >> は面倒だからやめた・・・。
generic <typename T> MyStringStream% operator << (T x)
{
cli::array<unsigned char>^ buffer = System::Text::Encoding::Unicode->GetBytes(x->ToString());
this->Write(buffer,0,buffer->Length);
return *this;
}
402:デフォルトの名無しさん
07/08/05 00:21:56
>>400
ポインタを使った場合だと、virtual 付けないとダメね
ハンドル型だと、virtualなしでもいける
403:デフォルトの名無しさん
07/08/05 00:23:24
>>402
へえ、boost::shared_ptrみたいだな
404:デフォルトの名無しさん
07/08/05 00:26:44
「リソース管理できてデストラクタに罠がない賢い手段」
目指してるものが同じだからな。
405:デフォルトの名無しさん
07/08/05 00:54:52
>>402
トンクス！
406:デフォルトの名無しさん
07/08/05 01:28:41
ハンドル型っていまいち概念がわからん。
マネージドヒープにある実体を指すポインタなんだろうか？
407:デフォルトの名無しさん
07/08/05 01:35:03
ガベコレの都合から考えたほうが早いかも
408:デフォルトの名無しさん
07/08/05 02:07:15
ref class だと
デストラクタってDisposeじゃなかった？
だからvirtualにならないとつじつまが合わない気が・・・
409:デフォルトの名無しさん
07/08/05 05:28:45
>>408
ref classのデストラクタはDispose()ナマじゃなからvirtualかどうかは意味がない。
デストラクタを宣言すると暗黙でDispose(bool)とDispose()とFinalize()が定義されて、
デストラクタはDispose(bool)から間接的に呼ばれるので、
結果、継承ツリーの下位のほうから順にデストラクタが呼ばれる形になる。
410:デフォルトの名無しさん
07/08/05 08:36:27
>>406
ようするにそういうこと。ただしポインタ演算禁止で、演算子多重定義が使える。
ポインタ演算がやりたければinterior_ptr<>。