5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

C++/CLI について語ろうぜ Part2

1 :デフォルトの名無しさん:2006/03/12(日) 16:08:39
おそらく、.NET開発でデファクトスタンダードに最も近い
であろうC++/CLIについて語ろうぜ!

このスレはC++および.NET Frameworkについて一定以上の知識を持っている人が対象となります。
.NETのクラスライブラリの使い方といった質問は姉妹スレ「くだすれC++/CLI(初心者用)」に
お願いします。

前スレッドはこちら
(p)http://pc8.2ch.net/test/read.cgi/tech/1126450441/l50

姉妹スレ
くだすれC++/CLI(初心者用)
(p)http://pc8.2ch.net/test/read.cgi/tech/1142144110/l50
managed C++ やろうぜ!! 002
(p)http://pc8.2ch.net/test/read.cgi/tech/1139043535/l50


2 :1:2006/03/12(日) 16:10:10

managed C++ → C++/CLI
(p)http://www.microsoft.com/japan/msdn/vs05/visualc/TransGuide.asp#transguide_topic
[特集] Visual C++ 2005 いままたC++が熱い!「C++/CLI」として大進化したVisual C++ 2005
(p)http://www.atmarkit.co.jp/fdotnet/special/cppcli/cppcli_01.html
Calling Native Functions from Managed Code
(p)http://msdn2.microsoft.com/library/ms235282(en-US,VS.80).aspx

C++/Cli Essentials
(p)http://www.amazon.com/exec/obidos/tg/detail/-/0321174054/
Shared Source Cli Essentials
(p)http://www.amazon.co.jp/exec/obidos/ASIN/059600351X

C++/CLI設計者のblog
(p)http://blogs.msdn.com/hsutter/
(p)http://blogs.msdn.com/slippman/

STL.NET
(p)http://www.microsoft.com/japan/msdn/vs05/visualc/stl-netprimer.asp
(p)http://www.dinkumware.com/

C++の今後
(p)http://216.55.183.63/pdc2005/slides/TLN309_Sutter.ppt

3 :デフォルトの名無しさん:2006/03/12(日) 19:15:06
前スレで gcroot と auto_gcroot の存在を教えてもらったんですが、
その後いろいろとググってみたところ、あんまり使われていない
みたいですね。というか、このテンプレートって標準なんだろうか。
なんか裏技でそのうちひっそりと使えなくされてしまうなんて
ことないかちょっと不安。

4 :3:2006/03/12(日) 19:37:30
ごめん、嘘
auto_gcroot Class
http://msdn2.microsoft.com/en-us/library/ms177048.aspx

C++/CLI の規格というわけじゃなくて、VC++ の独自な
テンプレートクラスってことらしい。

逆に ref class の中に std::auto_ptr<NativeClass> みたいに
ネイティブクラスへのポインタを持たせられる?とか期待して
みたけど、それらしいのが見つからなかった。

ref class auto_handle なんてのが見つかったけど、
なんか意味あるんだろうか。普通のハンドルとどこが違うんだろう。
http://msdn2.microsoft.com/en-us/library/ms177066.aspx

5 :3:2006/03/12(日) 19:43:45
Mixing Native and Managed Types in C++
http://weblogs.asp.net/kennykerr/archive/2005/07/12/419102.aspx
標準的なモノはなくて、 std::auto_ptr もどきの
ref struct AutoPtr を自前で作れ、ってことか。

ハッ!? もしかしてぜんぜん追っかけてなかったけど、
STL.NET には含まれてるのか??

#この程度の話題って、くだスレの方がいい?
#棲み分け具合がまだ把握できてない

6 :デフォルトの名無しさん:2006/03/12(日) 19:47:50
C#の話は、禁止だから、そのつもりで。

ここは、C++/CLIのスレだからな。

C#を勧める奴は、C#スレにいけ。


7 :3:2006/03/12(日) 19:56:27
>>6 してないじゃん。gcroot って、C# とは無縁だよ?
そりゃ System::Runtime::InteropServices::GCHandle を
ラップしてるわけだから .NET Framework とは縁があるけど。
なにか過剰反応してるんじゃないですか?

8 :デフォルトの名無しさん:2006/03/12(日) 19:58:01
>>7
前スレにいたアレなやつだ。

9 :デフォルトの名無しさん:2006/03/12(日) 21:33:22
>>4
auto_handleはauto_gcrootが参照クラスになった感じのようだ。
http://msdn2.microsoft.com/ja-jp/library/ms177069(VS.80).aspx
http://msdn2.microsoft.com/ja-jp/library/ms177046(VS.80).aspx
生のハンドルと違ってスコープを抜けるときにデストラクタが呼ばれると言う利点は存在するようだ。
http://msdn2.microsoft.com/ja-jp/library/ms177068(VS.80).aspx
自動変数にすることに比べて利点がわからないけど。

10 :3:2006/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:2006/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 :デフォルトの名無しさん:2006/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:2006/03/12(日) 22:56:32
>>12 THX
msclr\gcroot.h っていうディレクトリと名前空間 msclr から
考えて C++/CLI の標準仕様には gcroot, auto_gcroot は
入れないつもりなのかな。しかしこれが無いと困る場面も
あるんだけどなぁ。標準に入れてくれ>MSの人

14 :デフォルトの名無しさん:2006/03/13(月) 00:32:58
>13
言語上の本道は混合型の導入になるから、正式仕様にはならないんじゃないかな
STL/CLIも混合型が使えるようになったら正直いらないし


15 :デフォルトの名無しさん:2006/03/13(月) 01:35:07
> おそらく、.NET開発でデファクトスタンダードに最も近い
まじかよ

16 :デフォルトの名無しさん:2006/03/13(月) 02:47:59
混合型もいいけどコンパイラスイッチで、
ぱちっと切り替えられるほうがいいな。
逝ったりきたりすると遅くなりそう...



17 :デフォルトの名無しさん:2006/03/13(月) 02:54:26
>>15
マジなんだよ。C#とか言うヤツの気がしれんわ。


18 :3:2006/03/13(月) 04:27:03
>>14
今の ECMA の規格じゃぁ mixed type はダメなんだったっけ。
Mixed type に言及してる文献はあるけど、標準化には入ってこないのかな。
http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1557.pdf
http://www.gotw.ca/publications/C++CLIRationale.pdf

19 :デフォルトの名無しさん:2006/03/13(月) 05:06:37
----以降 C# は駄目とか C# じゃなきゃ駄目とかいう過激派は発言禁止----

20 :デフォルトの名無しさん:2006/03/13(月) 05:19:37
し、C♯じゃなきゃだめなんていってないじゃないっ!
あんたのほかにも代わりはいくらだっているんだから!!!

21 :デフォルトの名無しさん:2006/03/13(月) 08:39:23
>18
だめっつーより、開発予定なんだろうけど

ttp://signe.japan.webmatrixhosting.net/ecma372/23_mixed_type.aspx

実際のスケジュールはどうなんだろうね。デリゲート・コンストラクタの方が先に実装
されそうだよ

22 :デフォルトの名無しさん:2006/03/13(月) 08:55:22
混合型のサポートは VC++ 2010 がターゲットだってよ
ttp://blogs.msdn.com/branbray/archive/2005/07/20/441099.aspx


23 :デフォルトの名無しさん:2006/03/13(月) 09:11:10
CLIをまともなC++言語から使うには2010年までまつ必要があるということ?

24 :デフォルトの名無しさん:2006/03/13(月) 09:37:42
完全な混合型は、需要もどの程度あるか疑問だし、とりあえず

1)マネージドなオブジェクトへのハンドルを
  ネイティブクラスのメンバに

2)ネイティブなオブジェクトへのスマートポインタを
  マネージドクラスのメンバに

の相互通行ができれば便利なんじゃないかな。
それは gcroot/auto_gcroot と >>5 の AutoPtr 的な
スマートポインタクラスを使えば VC++ 2005 でも
可能なんだけどできれば何か標準があったほうが安心だよなぁ。

25 :デフォルトの名無しさん:2006/03/13(月) 09:50:54
何だかプログラミングし難くね?
Winの良さが丸消えじゃん。

26 :デフォルトの名無しさん:2006/03/13(月) 10:03:56
ネイティブで多重継承して、それをサポートしたいコントロールに継承させたり、friend の
抜け道をネイティブ側に用意して、マネージドを操作したり、本格的に混合型をサポート
してくれれば、使い方に夢が広がるんだけどねSTLだって、ネイティブとしてキャストして
保持させれば、混合型でマネージドを操作できるだろうし

ただ、相互のデータメンバを保持するだけなら、作りで回避できるからあまり混合型の
メリットは感じないなぁ


27 :デフォルトの名無しさん:2006/03/13(月) 12:54:59
それじゃマネージド終焉じゃん。

28 :デフォルトの名無しさん:2006/03/13(月) 13:30:46
>>27 どのあたりが?

29 :デフォルトの名無しさん:2006/03/13(月) 13:57:59
STLをまともに使えないC++に何の意味があるのか。

30 :デフォルトの名無しさん:2006/03/13(月) 15:12:34
だから、結局C++で。必要なところだけ C++/CLIなんだろな。


31 :デフォルトの名無しさん:2006/03/13(月) 15:14:55
必要なところって、どこ?

32 :デフォルトの名無しさん:2006/03/13(月) 15:29:36
.NETFrameworkを利用するところ。

33 :デフォルトの名無しさん:2006/03/13(月) 15:52:52
結局、C++/CLIはラッパーでしか使えないねぇ。

34 :デフォルトの名無しさん:2006/03/13(月) 16:12:10
それじゃ、COMと変わら(ry

35 :デフォルトの名無しさん:2006/03/13(月) 17:13:50
仕方ないじゃん。
TRONとかいろいろ環境はあるわけで、その中でWinだけ C++/CLIだけでは組めないよ。


36 :デフォルトの名無しさん:2006/03/15(水) 20:32:14
あー、翻訳終わったお〜。がんばったよ


37 :デフォルトの名無しさん:2006/03/15(水) 20:42:36
うぇねの人?



38 :デフォルトの名無しさん:2006/03/15(水) 20:49:33
thx みゅ。どこぞから抗議されたらチキンのように消すんで、適当に見といてくらさい

39 :デフォルトの名無しさん:2006/03/15(水) 21:15:38
激しく乙

40 :デフォルトの名無しさん:2006/03/15(水) 23:27:13
>>38
キチンと消せよ

41 :デフォルトの名無しさん:2006/03/16(木) 22:50:30
>>38
せめてWeb Archiveに残るまでは消さないで。

42 :http://www.vector.co.jp/soft/win95/util/se072729.html:2006/03/18(土) 20:53:45
TextSS のWindowsXP(Professional)64bit化おながいします

もしくは64bitにネイティブ対応したテキスト置換ソフトありますか?

43 :デフォルトの名無しさん:2006/03/24(金) 07:19:40
C++とCLIの統合のまだ道半ばってところなのかね。

44 :デフォルトの名無しさん:2006/03/24(金) 10:22:50
>>43 道半ばなんじゃね?
でもネイティブなコードとマネージドなコードが
仲良くできるってビジョンを示した点ではC++/CLI
ってのはかなり意味があるんじゃないかな。

さらに Managed C++ から C++/CLI への移行劇を
見せ付けられて、その道程が険しいってこともわかったし。

45 :デフォルトの名無しさん:2006/03/24(金) 12:17:38
ついでながらC++とCOMの統合も目指してくれ

46 :デフォルトの名無しさん:2006/03/24(金) 12:30:23
>>45 COM との統合って具体的には?
COM つかうのに言語仕様上の制約ってあったっけ?

47 :デフォルトの名無しさん:2006/03/24(金) 12:41:13
クライアントとして使うには#importがあるし、
サーバにはATLがあればまあいいやと思うのだが。

48 :デフォルトの名無しさん:2006/03/25(土) 00:47:41
すまん、XBOXが managed になるそうだ。


49 :デフォルトの名無しさん:2006/03/25(土) 09:01:08
それは、先代XBOXでしょうか、現行のXBOX360でしょうか?

50 :デフォルトの名無しさん:2006/03/25(土) 11:57:40
360だ。ネタ元は、
http://blogs.msdn.com/mswanson/archive/2006/03/23/559456.aspx

それに対するQ&Aのようなコメントは
http://blogs.msdn.com/briankel/archive/2006/03/20/555488.aspx



51 :デフォルトの名無しさん:2006/03/26(日) 01:53:09
>45
http://msdn2.microsoft.com/ja-JP/library/ms177101(VS.80).aspx

52 :デフォルトの名無しさん:2006/03/29(水) 07:48:03
C++/CLI(っというかMSC++2005EE) でManaged DirectXって使えないのかな?
検索しても見つからないorz
解説されてそうなところ知ってる方いませんか?

53 :デフォルトの名無しさん:2006/03/29(水) 07:52:22
SDK入れて参照に追加するだけじゃん

54 :デフォルトの名無しさん:2006/03/29(水) 08:13:34
>>53
 #using <microsoft.dirextx.direct3D.dll>
 using namespace microsoft::directx::direct3d;
と入れても
 アセンブリ 'microsoft.dirextx.direct3D.dll' がみつかりませんでした:
って言われちゃうんだよねorz何がいけないんだろう・・・

55 :デフォルトの名無しさん:2006/03/29(水) 08:21:08
リンク時の参照に追加してないだけじゃね?

56 :52=54:2006/03/29(水) 08:34:10
>>55
すいません。#using <>で大文字小文字の区別ができないだけみたいでした。
ありがとうございました。

57 :デフォルトの名無しさん:2006/04/07(金) 02:18:21
はどーけん

58 :デフォルトの名無しさん:2006/04/07(金) 02:35:53
一週間ぶりの書き込みがそれかよ もうちょっと考えろよ

59 :デフォルトの名無しさん:2006/04/07(金) 02:55:28
普段脳みそ使ってる分の反動ってやつかな…

60 :デフォルトの名無しさん:2006/04/07(金) 10:58:30
     \ ずどどどーーん
            /|[]::::::|_ / \/\\          /
           ./| ̄ ̄ ̄ ̄ //\ \/  \      //    ___
         |  |:::「「「「「「 / \/\  /\\   /:::/   ./|    |__
       _..|  |:::LLLLL//\ \/  \/\\/::::::/  /  | ロ  .|lllllllllllll
      / llllll|  |:::「「「「 / \/\怒/\ .\/ ./::::::::/  / ./ .|    |lllllllllllll
__     llllll|  |:::LLL.//\ \/涛\/\  /::::::::/   | /  .| ロ  .|lllllllllllll
        llllll|  |:::「「「/ \/\熱 /\ \/ /::::::::/   | ||/ ..|    |lllllllllllll
         llllll|  |:::LL//\ \/  \/\ ./::::::::/    .| ||/ ..|
         |  |:::「./ .\/\ 湯/\ \/ /::::::::/⌒ヽ、 .| ||/ ..|
         |  |:::l//\ \/  \/\_, -― 、  ''"⌒ヽ,_
                (⌒ヽ、_,ノ⌒Y"    Y     .....⌒) どーーーーーん
            (⌒ヽー゙ ....::(   ..::.......  .__人.....::::::::::::::::::::
         _ノ⌒ヽ  Y⌒ヽ;;:::::"'::::::::::::::::::::::::::::: ___
     ___(   ゙   ....:::.....  Y"  ∧_∧   /
   // ll__ヽ_::::::::::::::::::::::::::::::ヽ....(  ´Д`)<逃げろ逃げろ!
  「    ヽO≡≡O:::::::::::::::::::::::::::::::::::/ つ  _つ  \____
  ゙u─―u-――-u         人



61 :デフォルトの名無しさん:2006/04/09(日) 19:51:41
ダブル サンキング
って糞じゃない?
仮想関数使えないじゃん。



62 :デフォルトの名無しさん:2006/04/10(月) 00:35:31
C++/CLIのバージョン1というのはC++マネージ拡張のことなのかな?

63 :デフォルトの名無しさん:2006/04/11(火) 10:09:41
>>62 C++/CLI にバージョンってあったのか。
Managed C++ → C++/CLI
くらいしか認識してなかった。

64 :デフォルトの名無しさん:2006/04/15(土) 12:35:08
Objective-C++/CLI
マダー?チン、チン。
//GCCもCLI対応するんだろうか?

65 :デフォルトの名無しさん:2006/04/15(土) 12:39:11
Objective-C++ はちょっと意味が分からないな
C++ は C++ でそれなりに Objective だからな

66 :デフォルトの名無しさん:2006/04/15(土) 12:44:48
>>64
Objective-C 言語
   +
  C++ 言語
   ||
Objective-C++

67 :デフォルトの名無しさん:2006/04/15(土) 15:00:18
ttp://homepage.mac.com/mkino2/spec/objectiveC++/objectiveC++.html

ここらを見ると、いろんな苦労が共有できる気がするな

68 :デフォルトの名無しさん:2006/04/16(日) 15:02:33
Robert Rameyがいらないってんだから要らないんだよ
Sutterも嫌々やってるんですよ

69 :デフォルトの名無しさん:2006/04/22(土) 01:05:39
すみません。

Visual Studio2005ですが、MFCのプロジェクトで、
Windowsフォームデザイナで貼り付けられるような
コントロールは使用できるのでしょうか?

またWindowsフォームデザイナで開発した場合は、
.NetFrameworkが必要となり、Windows2000では動作できないなどありますか?


70 :デフォルトの名無しさん:2006/04/22(土) 01:23:13
>>69
1.使用できなくはないかもしれないがそれなら正攻法で使ったほうが多分楽
2..NET Framewokは98でも動く。一部2kで使えて98で使えない機能もあるがそれはたいていSDKに依存する問題。

71 :デフォルトの名無しさん:2006/04/22(土) 01:23:21
Windows 2000 でも .NET Framework は動くだろ

72 :デフォルトの名無しさん:2006/04/22(土) 01:25:33
>>69

正攻法とはどのような方法でしょうか?

また、.NETFrameworkがインストールされていないと
動作しないのですよね?

※すみません。.NETFramework初体験です。


73 :デフォルトの名無しさん:2006/04/22(土) 01:44:20
>>72
>正攻法
SDKを使う方法。

>.NE(r
もちろん動作しない。OSがインストールされていないようなもんだ。

74 :デフォルトの名無しさん:2006/04/22(土) 01:49:18
>>73
SDKはどのように使えばよいのでしょうか?
お手数ですが、簡単なサンプルとかってありませんか?
もう少し詳細を教えていただけるとたすかります
何しろMFCの標準コントロールは古臭くて。。


75 :デフォルトの名無しさん:2006/04/22(土) 01:53:10
>>74
Win32API質問箱 Build42
http://pc8.2ch.net/test/read.cgi/tech/1144962549/

76 :デフォルトの名無しさん:2006/04/22(土) 08:53:14
>74
CWinFormsControl を使え
ttp://msdn2.microsoft.com/ja-jp/library/8z4d86s2(VS.80).aspx

77 :デフォルトの名無しさん:2006/04/22(土) 08:56:00
というかそもそも何故 MFC なんだろう?

78 :デフォルトの名無しさん:2006/04/22(土) 10:15:56
既存のアプリの改良に WinForms を使いたいんじゃね?

79 :デフォルトの名無しさん:2006/04/22(土) 17:27:33
>>78

ご名答!!
そもそもVisualStudioの統合環境のツールバーや
メニューバーはどうやってるんだろうと。。



80 :デフォルトの名無しさん:2006/04/22(土) 17:34:21
別に何でもかんでもまぜまぜする必要ないじゃん。
混ぜることそのものが目的になってしまってる、みたいな。

81 :デフォルトの名無しさん:2006/04/22(土) 17:48:48
>>79 それは全部マネージドなんじゃね?

82 :デフォルトの名無しさん:2006/04/22(土) 18:24:55
漏れも手抜きしたくて CWinFormsControl を既存アプリに組み込んだりしたいけどな
さすがに、ユーザーに .net Framework 2.0 を要求できなくてやってないけど

83 :デフォルトの名無しさん:2006/04/23(日) 12:49:49
>>79
コントロールは単なるウィンドウを子ウィンドウにしてるだけ。
って言うのは解ってる?

84 : ◆GjPgyWFPCM :2006/04/23(日) 13:24:21
( ´_ゝ`)

85 :デフォルトの名無しさん:2006/04/23(日) 18:16:21
現状のC++ソースをまんまPureCLIに出来ないのが美しくないね。


86 :デフォルトの名無しさん:2006/04/23(日) 18:53:21
>>85
災いと引き換えの美しさなんぞいらん。

87 :デフォルトの名無しさん:2006/04/23(日) 19:37:17
>>85
むしろこれからはそれを意識したマクロ定義を心がけるべき?

88 :デフォルトの名無しさん:2006/04/23(日) 19:46:14
時代に逆行して COM かよ


89 :デフォルトの名無しさん:2006/04/24(月) 01:40:49
だから、猛烈にISO化に反対されてるだろ。

90 :デフォルトの名無しさん:2006/04/24(月) 09:08:11
災い=怒涛熱湯
美=C++

91 :デフォルトの名無しさん:2006/04/24(月) 19:36:55
あの ISO の論議は宗教戦争だよ
C++ だって C とは完全互換性がなくて非互換性の項目作ってるのに、C++/CLI は完全互換じゃ
ないから C++ の名前を使うな、なんて、馬鹿馬鹿しい

92 :デフォルトの名無しさん:2006/04/24(月) 19:51:22
C++#にするしかないのか

93 :86:2006/04/24(月) 20:17:12
>>90
逆。
CとC++で起きた災いのことだ。

94 :デフォルトの名無しさん:2006/04/25(火) 01:16:21
>>91

んなーことはない。互換のない箇所があまりにも C++ を越えてるからな。
誰もが、「C++であれは不味いよ」という実装。

C++の名前は使ってもいいが、正直、ISOにはなって欲しくない。

95 :デフォルトの名無しさん:2006/04/25(火) 05:32:35
そうか? 文字列互換性なんて C++ の不始末を便利にしたとこを駄目だとか騒いでるぐらいじゃね
MSのサイトの記述にけちつけて、こいつら営利企業に何求めてるんだ、とか思っちゃったけどな


96 :デフォルトの名無しさん:2006/04/25(火) 08:02:46
論争ってなんのことかよく知らないんだけど、
名前に C++ が入ってるのがまずいダロってことになってんの?
まぁ確かにもう少し検索エンジンフレンドリーな名前でもいいかもって気はする。



97 :デフォルトの名無しさん:2006/04/25(火) 09:42:19
ま、どっちにせよ、

Windowsのネーミングからはじまり、
J++、J#、managed C++、STL.NETとか、
一般的なものを汚し杉。

98 :デフォルトの名無しさん:2006/04/25(火) 09:59:29
そんな、汚すだなんて Java の信者じゃないんだから(w

Bjarne Stroustrup のFAQになってるところがワラタ
ttp://www.research.att.com/~bs/bs_faq.html#CppCLI

ISO UK が強硬に反対していて、その下に ECMA からの回答書も公開されている
ECMA じゃ C++/CLI と C++0x にどうやって巻き込まれないようにするかの調査も
始めてるってさ

99 :デフォルトの名無しさん:2006/04/25(火) 10:06:02
ECMA の回答書の最後に、おまいらががたがた言おうともう ECMA 標準であることに代わりは
ねえんだよ、って答えてるとこが笑える

100 :デフォルトの名無しさん:2006/04/25(火) 10:43:04
C/C++系を汚すなんて汚杉。
VC++が吐き出すMFCコードからして何語?って感じだった。
ユーザーに変なもん使わせながらM$は別のクラスライブラリ使ってるらしいし。

101 :デフォルトの名無しさん:2006/04/25(火) 15:28:25
関係ないがアンダーバーつきまくりの変な修飾子はもう見たくないと思った。

102 :デフォルトの名無しさん:2006/04/25(火) 15:52:08
こうやってC++をぐだぐだにすることで、
C#の地位を着々と上げていく作戦なんだな。

103 :デフォルトの名無しさん:2006/04/25(火) 17:10:51
何言ってるんだ。 C++/CLI が出てきたせいで、C# がその存在意義を問われてしまったのに

104 :デフォルトの名無しさん:2006/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:2006/04/25(火) 19:08:19
>おまえさん、そんなこと言ったら、COBAとかCOBA真似 IIS C++ソースなんて見たら目がつぶれるぞ。

見たい。URL教えれ。


>C++の延長線上に C++/CLI があるような ISO 化は止めて欲しいってこった。

なるほど、ISO化が嫌われてるのね。


>C#の存在意義なんて、海外では数年前からいわれてんのに、今頃何言ってンのよ。

知らなかった。KWSK

106 :デフォルトの名無しさん:2006/04/25(火) 19:50:18
>>105
>見たい。URL教えれ。
断る。
comのプログラムを探れ。corbaを参考に ActiveX, COM, DCOMをつくり、その開発メンバーがIISに流れた。
後は自分で探せ。

>なるほど、ISO化が嫌われてるのね。
C++という名前を使うな、という気持ちも理解できるが…、ISOにする必要性は全くない。
MS以外誰も望んでいないからな。

>知らなかった。KWSK
C#を初めとして、その他の多くが失敗したから、「ユーザの望むモノを提供していないンだよ、ボケ社員ども」と方針転換した話は有名。
Vistaで乗るバッチプログラムだって、初めは新しい言語だったのにひっこめて全部作り直す。

そのとき、名言。「すみません。Perl風に作り替えます。」 

MSは既に梶を切ってるのに、古い方針の独善的な仕様でISO化してどうするよ。

107 :100:2006/04/25(火) 20:01:59
>>106
おもしろい情報一杯持ってるね。そういう情報好き。

>comのプログラムを探れ。corbaを参考に ActiveX, COM, DCOMをつくり、その開発メンバーがIISに流れた。

こういうの面白い。さらにCOMのトンデモ文法で作ったM$のアプリサーバなんて装飾子があったら爆笑。

>C#を初めとして、その他の多くが失敗したから、「ユーザの望むモノを提供していないンだよ、ボケ社員ども」と方針転換した話は有名。

方向転換したのはゲイツ氏?

Longhorn@マネージド→Vistaの方向転換のこと?

>Vistaで乗るバッチプログラムだって、初めは新しい言語だったのにひっこめて全部作り直す。

あの、WinFXスレでマンセーされてたシェル言語?スゲ


108 :デフォルトの名無しさん:2006/04/25(火) 21:23:31
自演乙

109 :デフォルトの名無しさん:2006/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 :デフォルトの名無しさん:2006/04/26(水) 01:10:43
レイオジーのこと?

俺はなんだかんだ言っても最後は.NETに落ち着くと思うけどな。
エイプリルフールネタはおもしろい。

111 :デフォルトの名無しさん:2006/04/26(水) 08:49:41
>俺はなんだかんだ言っても最後は.NETに落ち着くと思うけどな。
いや、M$がドトネトに決定するかもしれんが、落ち着いたことは過去一度も無いお。
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 :デフォルトの名無しさん:2006/04/26(水) 13:23:51
LiveってWinモンリー?

113 :デフォルトの名無しさん:2006/04/28(金) 11:50:51
CLR_OR_THIS_CALL


114 :デフォルトの名無しさん:2006/05/11(木) 19:07:00
ネイティブとかマネージとかアンマネージとか値とか参照とか
ややこしいっつーの

115 :デフォルトの名無しさん:2006/05/11(木) 20:16:13
C#書いてるときに比べてC++/CLI だと IDE が明らかに遅いんだけど。。。
ボタンを設置してダブルクリックして、イベントハンドラのスケルトンができるまでが明らかに遅い。

116 :デフォルトの名無しさん:2006/05/11(木) 22:07:38
パソコン買い換えろよ。ボロイのいつまで使ってんだよ。

117 :デフォルトの名無しさん:2006/05/12(金) 22:24:27
買い換えても、遅いモノは遅いぞ。相対的なものだからな。

118 :デフォルトの名無しさん:2006/05/12(金) 22:45:13
まあ、十分に早くなれば差に意味が無くなるだろう
……ネイティブとCLIの縮図のようだ

119 :デフォルトの名無しさん:2006/05/15(月) 20:37:12
System::Runtime::InteropServices::PARAMFLAG::Outって何?
System::Runtime::InteropServices::OutAttributeに変えてもいいの?

120 :ヽ(゚∀。)ノうぇね ◆xOFicusMP. :2006/05/19(金) 23:03:00
ECMAから公開許可をもらったぜ
消す必要はなくなったから、安心してくり

121 :デフォルトの名無しさん:2006/05/20(土) 07:40:11
>>120
おお、めちゃ乙。

122 :デフォルトの名無しさん:2006/05/20(土) 11:58:59
ECMAって心が広いんだね

123 :デフォルトの名無しさん:2006/05/30(火) 14:20:07
ちがうよ、必死なんだヨ。

124 :デフォルトの名無しさん:2006/06/02(金) 13:29:20
STL.NETどこイっちゃたの?


125 :デフォルトの名無しさん:2006/06/02(金) 14:05:47
思いつきで適当なもん作ってはお蔵入り

126 :デフォルトの名無しさん:2006/06/02(金) 14:12:41
今はSTL/CLIだよね。

出てもJavaの新しいcollectionみたいな仕様のクラスライブラリで、
method等の名前がSTL風になっているだけだろうけど。
STLはC++の言語仕様にかなり依存しているから。

なんにしてもそれどころじゃないみたい。
http://blogs.msdn.com/nikolad/archive/2006/02/07/527193.aspx



127 :126:2006/06/12(月) 08:21:10
しかし、すげー、過疎スレだなw

128 :デフォルトの名無しさん:2006/06/18(日) 20:33:44
話題がないのにだらだらだべるなんて苦痛だからね
正直、STL/CLI は C++/CLI にとって不要な要素だと思ってる
作るだけ、無駄。だから、あまり力を入れていないのは正解じゃないかな

129 :デフォルトの名無しさん:2006/06/18(日) 21:06:52
そうだなあ。
ManagedなobjectをSTLで扱う時のTIPSでいいかな。

130 :デフォルトの名無しさん:2006/06/18(日) 23:35:16
コンテナ程度の対応をするより、0x への対応をしっかりとやって欲しいのですよ
それらの要素をどう C++/CLI に持ち込むかの方が重要だと思う

131 :デフォルトの名無しさん:2006/06/19(月) 16:02:04
System.Collections.Generics.Listのイテレータを作ってみたことがあるんだ。
最初はそのイテレータも参照型にしたんだけど、Visual C++付属の<algorithm>の関数は、
デバッグ用か何かの仕掛けがあって、ネイティブ型しか受け付けてくれなかった。
結局そのイテレータに対するネイティブ型のラッパを作ってやったんだ。

逆に言えばマネージ型のイテレータがVC++付属の標準ライブラリで使えれば、
STL/CLIなんてなくても自分たちで勝手にイテレータを作ったりして使うことは容易だと思う。

132 :デフォルトの名無しさん:2006/06/25(日) 01:03:26
素直に混合型を実現してマネージドとネイティブを継承した型を使えばと・・・

133 :デフォルトの名無しさん:2006/06/27(火) 10:39:54
それ、ふつーのネイティブ。

134 :デフォルトの名無しさん:2006/07/03(月) 22:36:31
実践C++/CLI
ttp://www.amazon.co.jp/gp/product/4797336277/249-7078532-9380326?v=glance&n=465392

を買った人いる? どんな感じ?

135 :デフォルトの名無しさん:2006/07/04(火) 07:53:18
本屋で立ち読みしてみるのが一番手っ取り早いかと

136 :デフォルトの名無しさん:2006/07/04(火) 22:51:53
手っ取り早いどころか、立ち読みしてから買わないと危険な香りがするな。


137 :デフォルトの名無しさん:2006/07/07(金) 00:43:47
立ち読みした。実践じゃなくて、実際だな。内容的には。
本の後半で、Visual Studioのダイアログでの指定方法とか書かれてる。

つーか、最近、ソフトバンククリエイティブの本はタイトル詐欺が多すぎ。
噂の真相うんちゃらかんちゃらも、タイトル買いしたら内容は単なる手記だったしよ。


138 :デフォルトの名無しさん:2006/07/08(土) 12:51:24
表紙だけ素晴らしくて内容がウンコなエロ同人誌みたいなもんか

139 :デフォルトの名無しさん:2006/07/08(土) 13:18:39
買って読んだが、ちと微妙なできだな
C++/CLI に踏み込んだ記述は少なく、既存の VC++ の開発者向けに .net を使うための
チップス集といった感じだった
記述するべき知識が広範囲すぎて、なるべくいろいろ網羅しようとがんばっているのは
感じたが、前提知識があるものと記述されている部分が多くて、これはさらりと書かれている
部分がわからないのでは、と疑問に感じた

140 :デフォルトの名無しさん:2006/07/08(土) 13:43:06
>>137
> 最近

笑うところ?

141 :デフォルトの名無しさん:2006/07/09(日) 13:17:19
ページ数が少なすぎるね

142 :デフォルトの名無しさん:2006/07/23(日) 00:28:01
C++/CLI 気に入ったんだが、リファクタリングできないのがつらいなぁ。

143 :デフォルトの名無しさん:2006/07/23(日) 02:07:36
デバッグでトレースが重いのが致命的だよ・

144 :デフォルトの名無しさん:2006/07/24(月) 05:00:40
.NETと無縁の仕事ばかりやってたので思いつきでCLIでもやって
みようと思って買ってみたよ。
ダイヤモンド継承の問題点とかでてきてちょっとなえるが、まあ
もうちょっと読んでみるよ。
Win32と.NETが同時に使えるのはツールとかちょっと作るのには
便利なのかなあくらいに思ってるよ。製品開発に使えるとはまだ
ちょっと思えないけど。。

145 :デフォルトの名無しさん:2006/07/27(木) 04:12:28
>>144
去年、C#の案件をやったんだが「ああ、あの時C++/CLIが出てればなぁ」とは思う。

146 :デフォルトの名無しさん:2006/07/31(月) 20:51:05
これ読んだ人いる?
ttp://www.amazon.com/gp/product/1590596404/ref=sr_11_1/104-8510614-7138345?ie=UTF8

147 :デフォルトの名無しさん:2006/08/01(火) 10:00:59
>>145
C++ > (壁) > C丼
ということ?

148 :デフォルトの名無しさん:2006/08/01(火) 19:12:10
>>147
ヒント:DllImport

今は逆にC++(ただしネイティブ)の案件やってるが「これがC#だったらもっと楽なのに」と思いながらコード書いてる。

149 :デフォルトの名無しさん:2006/08/01(火) 20:31:57
BStrWrapper ってどうやって使うんでしょうか?
ググっても、ひっかかりもしねぇっす。

150 :デフォルトの名無しさん:2006/08/09(水) 16:31:51
こんにちは。質問です。

VC++EE使ってます。
system以下のライブラリを網羅したページってないですか?
C#やVBで解説されててもかまわないのでどこかご存知ありませんか?

151 :デフォルトの名無しさん:2006/08/09(水) 16:50:50
MSDN

152 :デフォルトの名無しさん:2006/08/09(水) 17:51:19
検索で引っかからなかったけど、MSDN普通にもぐってったらあった。OTL
なんでMFCなのかわからんけど、見つかってよかった。

ttp://msdn2.microsoft.com/ja-jp/library/ms306608.aspx

153 :デフォルトの名無しさん:2006/08/10(木) 00:00:25
>>152
>MSDN ライブラリ > .NET 開発 > .NET Framework SDK > MFC リファレンス
うは、ほんとだwww

154 :ヽ(゚∀。)ノうぇね ◆xOFicusMP. :2006/08/26(土) 23:01:19
あまり使ってる人もいないんだろうけど、ごめん、鯖が消えてた(´・ω・`)
引っ越したので、こちらを参照してください

ECMA-372仕様書
ttp://mdjowbnb.sv05.fsdotnet.net/ecma372/StartingState.aspx


155 :デフォルトの名無しさん:2006/08/27(日) 17:51:15
>>154
乙です。お世話になってます。

156 :デフォルトの名無しさん:2006/09/05(火) 18:17:53
C++/CLI で作ったクラスライブラリって、CLR Profiler 通る?
CLR Profiler いつも落ちるんだけど。

157 :デフォルトの名無しさん:2006/09/08(金) 00:40:07
/clr:pure 状態でも?

158 :デフォルトの名無しさん:2006/09/08(金) 11:33:09
/clrでコンパイルしたときにアンマネージコードの生成が

『〜〜用にネイティブ コードの生成が発生します』
と自動的に適用される場合と、

『この関数はマネージとしてコンパイルできません。#pragma をアンマネージで使用してください』
と明示しなければエラーになる場合があるんだけど、

両者の違いって分る人居ますか?

159 :デフォルトの名無しさん:2006/09/14(木) 00:40:15
ISOは賢明な判断をしたな

160 :デフォルトの名無しさん:2006/09/14(木) 01:05:14
>>159

くわしく。

161 :デフォルトの名無しさん:2006/09/14(木) 08:25:11
これか
ttp://blogs.wankuma.com/episteme/archive/2006/09/12/38394.aspx

162 :デフォルトの名無しさん:2006/09/14(木) 08:27:22
これかな?
http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=42926

163 :デフォルトの名無しさん:2006/09/14(木) 08:31:29
間違えた orz
http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=43913&scopelist=PROGRAMME

164 :デフォルトの名無しさん:2006/09/14(木) 08:52:40
ま、駄目だった物は駄目、ということで

165 :デフォルトの名無しさん:2006/09/14(木) 09:03:55
まあ駄目で当然という気がする。
仕様が汚すぎる。上位互換じゃないのも(C++を名乗るには)問題。

166 :デフォルトの名無しさん:2006/09/14(木) 13:57:57
ちょっとホッとした。本当に賢明な判断だ。


167 :デフォルトの名無しさん:2006/09/15(金) 01:56:05
どっちの味方なんだよ

168 :デフォルトの名無しさん:2006/09/15(金) 02:18:45
最終的にまともなのになってくれれば過程はどうでもい

169 :デフォルトの名無しさん:2006/09/15(金) 04:19:04
C++をマネージ拡張するのもいいんだけど、
C#をアンマネージ拡張して欲しいと思うときがある。
まあ、DllImportすればいいんだけど。

170 :デフォルトの名無しさん:2006/09/16(土) 01:34:15
よくねーよ。
でもMSが持ってるNativeMethods.cs公開してくれたら、それでいい気がする。

171 :デフォルトの名無しさん:2006/09/16(土) 01:44:50
俺もそれほしい
PInvoke.net が不要になっちゃう

172 :デフォルトの名無しさん:2006/09/16(土) 02:03:51
結局、/CLIは今のところ使わない方が良いって事だなぁ…。


173 :デフォルトの名無しさん:2006/11/18(土) 10:46:54
sage

174 :デフォルトの名無しさん:2006/11/19(日) 03:51:20
C++/CLIって結局微妙ってこと?
@IT:特集:Visual C++ 2005 いままたC++が熱い!「C++/CLI」として大進化したVisual C++ 2005
http://www.atmarkit.co.jp/fdotnet/special/cppcli/cppcli_01.html
これとか見ると随分興奮しているけど

175 :デフォルトの名無しさん:2006/11/19(日) 12:02:38
>>174
ヒント: 川俣 晶

176 :デフォルトの名無しさん:2006/11/20(月) 16:15:43
海外だと、C++/CLIは凍るほど冷えてる。


177 :デフォルトの名無しさん:2006/11/20(月) 19:51:22
>>176
そうなんかぁ〜?

178 :デフォルトの名無しさん:2006/12/03(日) 02:17:55
DllImport関係のNativeMethod系以外に結局何が素敵なの? C++/CLIって
>>145
(言語熟練度はプロジェクト要員の平均レベルでC++/C#ができるものとして)
Manageなコード中に簡単にネイティブっぽいものが書けちゃうと逆にメンテし辛いものにならないのかな。

ところで、C++/CLIってC#3.0みたいな機能って予定されてるの?

179 :デフォルトの名無しさん:2006/12/03(日) 03:11:41
ネイティブの方が圧倒的に多かったり、
XP用のポーティングをしたり、
いろいろ便利なケースは想定できるでしょ?

どこまで厚くサポートされるかは分からない。
STL.NETみたいに辞めちゃったプロジェクトもあるし、
C++/CLIの人員削減はあり得ることだと思う。

180 :デフォルトの名無しさん:2006/12/03(日) 08:56:56
STL.NETはやめてはいないだろ。
OrcasのCTPにSTL/CLRが入っている。
どんなもんかまだ俺は試していないけど。

181 :デフォルトの名無しさん:2006/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:2006/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 :デフォルトの名無しさん:2006/12/04(月) 16:07:42
>>182
やったこと無いんだが、
見た感じ、strcatと同じ動作に見えるね。

オペレータの+ってないの?

184 :デフォルトの名無しさん:2006/12/04(月) 16:18:11
>>183
ret += a;
今、上記のようにやってみたのですが、下記のエラーになってしまいました。。。

error C2297: '+=' : 無効な右オペランドです。
error C2845: '+=' : __gc ポインタ 'System::String __gc *' に対してポインタ演算ができません。


185 :デフォルトの名無しさん:2006/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:2006/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 :デフォルトの名無しさん:2006/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 :デフォルトの名無しさん:2006/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 :デフォルトの名無しさん:2006/12/04(月) 17:11:03
こらこら、ANSI文字列のポインタをLPTSTRで受けちゃダメだぞ。

190 :デフォルトの名無しさん:2006/12/04(月) 17:14:53
…なんだか口は悪いけど親切なお兄さんと結婚することになりそうです。

191 :188:2006/12/04(月) 17:22:28
>>188
動きました!

192 :181:2006/12/04(月) 17:22:51
名前欄まちがえた

193 :デフォルトの名無しさん:2006/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:2006/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 :デフォルトの名無しさん:2006/12/04(月) 17:44:41
>>193の方法は短いですけど、>>188の方が見やすそうなので、使わせてもらいました。
色々勉強になりました

196 :デフォルトの名無しさん:2006/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 :デフォルトの名無しさん:2006/12/04(月) 18:23:57
>>195
せめてStringBuilder使え。

198 :デフォルトの名無しさん:2006/12/04(月) 23:45:05
ふつうに wstring 使った方が早くね?

199 :デフォルトの名無しさん:2006/12/04(月) 23:49:36
String::Format 使えばいいと思う……

200 :デフォルトの名無しさん:2006/12/05(火) 00:23:34
>>199
>>193で出たものの、>>195で却下された。

201 :デフォルトの名無しさん:2006/12/05(火) 11:03:39
個人的には(作成理由から読むに) C# で DLLImport の方法を探した方が遥かに楽だったんじゃないかという気がするけど。

色んな選択肢を使える懐の深さが C++/CLI の一つの魅力なわけだし、
最速/高効率よりも、本人が理解/吸収しやすい手法を取るのが最良だと思う。

202 :デフォルトの名無しさん:2006/12/05(火) 16:10:02
さすがに、それを最良と言い切るのはおかしいな。
言いたいことはわかるが、言葉の選択を誤ってるね。


203 :デフォルトの名無しさん:2007/01/03(水) 23:36:10
http://www.rupan.net/uploader/download/1167834884.zip
PASS: CLI

204 :デフォルトの名無しさん:2007/01/06(土) 00:27:15
>>203
これってなんだったの?

205 :デフォルトの名無しさん:2007/01/06(土) 00:31:07
仕様書のスキャン画像

206 :デフォルトの名無しさん:2007/02/24(土) 01:07:33
C++/CLIでWPFの開発できないの?

207 :デフォルトの名無しさん:2007/02/24(土) 18:54:27
できないほうが不思議

54 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)