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

おそらく、.NET開発でデファクトスタンダードに最も近い
であろうC++/CLIについて語ろうぜ！

専用スレが今の時期にいるのか?

あくまでも MSの推奨は　C#だろ。

C#ってプラットホーム呼び出しとか面倒じゃね？
態々DllImportってうぜー

C++/CLIって普通にSTLとかBoostとか使えるのかな？

2005β2でSTLは使えたぞ
Boostはまだ未検証

.netなんてC++を使うまでも無いだろ

なにを使えと？
まさかC#？

VC++のエディタは支援機能がVC#に比べて弱い

エディタなんてIDEのものは普通使わんだろ？
支援機能がないと書けないの？

>>10
今時そんなこと言ってる人間はJavaの世界でもいなくなったのに。

4年前からまだterapadだな俺

>>4
くまぐまDllImport

>あくまでも MSの推奨は

推奨は消えるからﾔｳﾞｧｽ。＞NetBUEI、VBX、VB、WinDNA、COM

COMは消えない

AJAX >>>>>（壁）>>>>> COM

>>16
AjaxのXMLコンポーネントは何でできてるかご存知で？

COMだと？

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

重複ｽﾚです

managed C++ やろうぜ！！
http://pc8.2ch.net/test/read.cgi/tech/1014486422/

managed C++ と C++/CLI は異なるものですが・・・

C++を複雑化すんなって漢字。

C++/COMもヘッダー巨大＆ワケワカだったし。

自分の頭の悪さを言語のせいにするな

>21
http://pc8.2ch.net/test/read.cgi/tech/1014486422/681-682

いままたC++が熱い！「C++/CLI」として大進化したVisual C++ 2005
http://www.atmarkit.co.jp/fdotnet/special/cppcli/cppcli_01.html

ｈとｃｐｐに分けるの面倒
予期せぬEOFが云々
とかもうぜー

>>16
AjaxとCOMを並列に語る発想がすごいよね

AjaxとCOMが別物だと思っているしとﾊｹｰﾝｗ

VC#のほうが簡単だよ

>>28
基地外さらしage

C#死亡・・・
たぶんＭＳは、C#をなかったことにするのでないかい？
こんだけ推し進めといて、アッサリ切り捨てるのがＭＳのやり方だーね

はいはいネガティブネガティブ

>　デファクトスタンダードに最も近い
本当かよｗ

まぁ近いだろうな。消去法で。

>>31
マジレスすると全く正反対。
ヒント：J#

Sunとの和解内容は秘密だから分からないけれど、
当然将来J#を選択できる内容になっているんだろうな。
報道ではJ#完全打ち止めだけども…

C++/CLI のフリー環境は作れないわけではないと思われ
VMに何を利用するかによるが、じきにGNUあたりで出てくるんでないかね

ネイティブ以外興味ないよ

GNU/UNIX系は、他環境のコード（例えばWin32）を取り込んでUNIXでコンパイルできるようにする文化だから、
ネイティブコンパイルできるようになるだけっぽい。

>>37
まだまだだが、
http://www.go-mono.com/faq.html#gcc
http://open64.sourceforge.net/documentation.html WHIRL中間コードを利用するgcc
http://www.math.leidenuniv.nl/~kris/whirl2il/ WHIRL→CLI
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vcmex/html/vcgrfconvertingmanagedextensionsforcprojectsfrommixed-modetopureil.asp

>>39
ｱﾌｫ?

>>41
いいえ、あなたがアフォです。

>>42
やっぱり!

>40
ECMA での MC++ （＝C++/CLI）を Mono VM でサポートってことは、SGI と共同で
C++/CLI の MonoVM 環境を作るつもりなんだ。他のコミッティはどうするんだろう
しかし、中間コードから CIL を出力って、これがうまくいけば凄いね。VES 上でC/C++が
動くんかいな

いや、SGIが作るのはWHIRLを中間に使うgcc変種。
最終的にはネイティブを出力。

WHIRLは高水準のものから低水準のものまで多段で扱う流儀なので、
高水準のものからなら、CLIへのコンバートはそれほど難しくないと思われ。
whirl2cってのがあるくらいだから。open64のwhirl.pdfの1.3節

んーってことは、ただのネイティブ変換なんだ
モジュール起動時にVESにアタッチして、マネージド・オブジェクトとあったこったやったり
しない訳ね。ちょっとそれだと魅力ないなぁ。構文だけ一緒なだけなんだ
まだ、JNI をいじってラップかますほうが C++/CLI っぽいか

SGI
http://www.sgi.org/

そうかそうか

>>33
まだ出てもいないのにデファクトなわけないだろｗｗｗｗｗｗ

>>46
ちょっと勘違いがあるみたいなんだが、open64はCLIと何の関係もない。
RTLを使わないgccの変種を作っている。(WHIRLを使う)

で、その成果を利用すると、CLIへの変換が容易、
あるいはいきなりCLI生成な更なる変種を作るのが容易。
ってな感じの状況が>>40。一つ目のURLのFAQを読んでね。

>50
んー、それは理解している。でも、C++/CLI の魅力は IL にして VES 上でのみ動かす事じゃなく、
ネイティブとマネージドが共存するメモリモデルを持っていることだから、C# の亜種なら
要らないでしょ

まだその段階にないというだけなんでは?

>52
そうだけど、方向性が違うでしょ。実行モジュールから MonoVM をアタッチして、その上に
部分変換した IL を流し込むやり方は、遠いよ
JNI みたくVM上に直接オブジェクトを作るアプローチの方が手っ取り早いと思うんだけどな

あげ

あげ

あｇｔ

いつになったらC++/CLI使えるようになるの？

今でも使えるよ

printfが使えるらしい

Visual Studio .Net 2003 で動作していた、
アセンブラ ファイルを含むプロジェクトが
Visual Team Suite 2005 Beta2 では、
error PRJ0003 : 'cmd.exe' の起動中にエラーが発生しました。
とのエラーになる。

どなたか、アセンブラ ファイル（.asm）を含むプロジェクトを
試された方、アドバイスお願いします。

asm の部分をコメントアウトしてコンパイルしてみたら？
問題は別のところにあるんじゃねぇ？

>61
いや、インラインではないんだ。
別に拡張子.asmのファイルを含んだ
プロジェクトで、例えば、
abc.cpp
abc.asm
この２つのファイルを含んだプロジェクト
をビルドすると、エラーとなるわけ。
abc.asmのカスタム ビルド ステップ指定は
以前のVSN_2003と同様ですがね。

cmd.exeってことは起動に失敗してるんだろ
アセンブラがパス通ってないか、無いんじゃねーの

2009年のC++の姿でも見ておけ。これでもC++がいいのか。
ttp://216.55.183.63/pdc2005/slides/TLN309_Sutter.ppt

pptってなんだよ
変てこなバイナリつくんなよ

>64
良くなるじゃん。ラムダと自動変数と関数子に並列処理やメモリのクリティカルなアクセス保持、
遅延実行、メッセージの言語サポート、非同期実行による処理の委託、スコープによる
処理の実行の同期、アルゴリズムをスレッド化してくれるし、並列化STLとかも来るとなると、
なんか、あれふ、みたいだな

>62
関数呼び出し部をコメントアウトして、asm はあるけど使わないとどうなるの、と訊いた
つもりなんだが
漏れも 63 が正しいと思うカスタム・ビルドで指定してるコマンドが間違ってるんじゃね？

ConcurやLinqなんて入るのか?
VC++/CLIだけだろ?

>67
これ、C++0x （多分、x==9）の予定だよ。だから、これをサポートしたコンパイラが出てくるのは
５年後から。まぁ、独自拡張でいろいろ試したりするだろうけど

それよりもまず、名前空間を拡張して欲しいなぁ
namespace company.product_name
{
...
}
って書きたいよ

>>65
恥さらし乙

>>68
C++0xは全部じゃないよ。
Linqなんて言語レベルでやるのが良いのかどうか。
C++は機構だけ提供するのが好きな言語だから。

65 名前：デフォルトの名無しさん[] 投稿日：2005/09/19(月) 23:01:22
　　pptってなんだよ
　　変てこなバイナリつくんなよ

もうこれ以上言語を拡張するのはやめてほしい＞C++0x
これだけ仕様が肥大すると、規格準拠コンパイラが存在しなくなって互換性も糞もなくなるぞ（もうなってるか・・・）

C/C++と親和性の高い言語を新しく設計したほうがマシ。

>>72
だめだ。それをやると、D言語の二の舞になって、ユーザーを得られない。

D言語はセンス悪いもん。

ConcurやLinqは、高レベル過ぎるから、
新しいのつけるならプリミティブを抽出して欲しいな。

Javaのfor each程度のものならすぐにつけてもいいけれど。

諦めてガジェットとして見るべ
便利なとこだけつまみ食いすればいいよ。結局実用外のところは、廃れるだろう
理解しなくても、ツールとしてコードは書けるし、それで充分だと思う

今回のVS_2005 C++/CLI は、たぶん
生き残ると思う。

秩序と混沌、
いつの世でも、新たな革新的技術は、
混沌が土壌だったからね。

アセンブラ〜C#まで、必要とあらば一望の下に。

>>76
生き残るか生き残らないかは、君が決める事ではない。
まだ発売されてもいないのに。ＭＳの社員か？

>77
生き残ると、私が今国会で決めたのだ！
小泉君に聞いてみな。

>>77
思うというのは予想であって、予想というのは
事の決着に直接関与しない人間でもすることだし、
事が始まるより前にすることだよ。

「神戸新聞杯はやっぱディープインパクトが勝つと思うよ」
「勝つか負けるかは、君が決める事ではない。
まだ発走してもいないのに。厩舎関係者か？」

・・・っていう会話くらい変。

>>79
つ[チラシの裏]

長年プログラミングをしていると
オブジェクト指向だの何だの、
これらの概念は、すでに独自の手法で
取り込み、我がものとしているハズ。

でなければ、いくら最新最強と言われる、
処理系を手にしようと、扱う人によっては....。

それにしても、C++/CLI は、有望、だと思う。

/ | ﾊ　　　　＼　／／／／　　　　ヽ
!　l　|l､､＼　　　　 ｀ 丶 ､'´＿ ､　　　　 、
!　ｌ ‖＼､ ＼_　　　　 ＿ /, -｀ヽ　　　　}
、 ｌ ‖＿ ＞:=‐ ￣￣「　ｌ| l　 　 } ､　　ヽ 　　んっ　んんっ…
ヽ　､i`─ '´　___　　　｜ ｌl　⌒;　j　 、 　 ヽ
　＼ヽ　r,ﾆ､‐‐'‐'　u　.ｌ　ｌl 　 '_ノ　　 ､　 　 ヽ　
　　 ｀ ＼"＼):､　　　 ｜ ｌ|　　｀､　ヽ　 ､　　　ヽ
　　　 　 ヽ　 ゞ'＾ 　 　 !　lｌ　　　｀､　ヽ　　､　 　 ヽ
　　　　　丿　 　.:::.　　｜ l|　　　　 ＼　ヽ、　､　　 ヽ
　　　　 丶､_　 　 　 　 |　l|/ｌヽ　　　｀＞=‐- ミヽ 　 ｀、
　 　 　 　 　 ｀⌒ヽ_　　|　ｌ| |　ﾊ　 ／´　　　　 ｀ヽ　　 ､
　　ﾁｭﾊﾟ　　/　　/.　｀´|　ｌ| | l / 〃　　　　　　　　｀、　 ､
　ﾁｭﾊﾟ　　/ 　　/ 　 　 |　ｌ| | l' 〃　　　　 　 　 　 　


　　　　　　　　　　　　　　　　　　　　　　　　　　　　　【ゴールデンレス】

このレスを見た人はコピペでもいいので
10分以内に3つのスレへ貼り付けてください。
そうすれば１４日後好きな人から告白されるわ宝くじは当たるわ
出世しまくるわ体の悪い所全部治るわでえらい事です

この板アホアンチ多くね？
健全にMSの話題ができん。

技術の話ならするよ。
マンセーやアンチは置いといてさ。

>>80
いや、独り言じゃないから。
馬鹿をメタクソにやり込めただけだから :-P

>>73
　俺　が　悪　か　っ　た

でもほんとこれ以上肥大させるのは勘弁して欲しい。
SubversionのFAQだったかな、「svnはなぜC++でなくCで記述されているのですか？」「C++だとポータビリティが低下するからです」。
わざわざ醜い言語仕様にして後方互換性を保ってもこのザマ。
まあそこがC++らしいっちゃらしいんだけどね。

C++でもテンプレートを禁止すれば互換性はかなり保てると思う。

けど俺はテンプレートのないC++なんて使いたくないがな。

>>86
http://subversion.tigris.org/faq.html
ないぞ。

そこでMozilla Portability Guideですよ。

http://subversion.bluegate.org/svn-anti-fud-ja.html

>>53
GNU.NETのcsccは、Cのコードとミックスできるようだな。
WindowsのVC++ .NETで書けるCとのミックスコードを、コンパイルできるらしい。
(ただしCからWindows固有の機能を使ってはダメ)

いみなくね？

C++/CLIで書いてもC#で書いてもはたまたVB.NETで買いても
吐き出される中間コードはどれも一緒だよ

dotGNU Portable.NETってCLIのクラスライブラリ用いてlibc作ってなかったっけ？

pnet-ctools - Development tools for compiling C to IL bytecode

This package provides the tools & links to the toolchain for compiling programs written in C to IL bytecode.

>93
pure とか mixed とかいろいろあるんだよ

「Inside the C++ Object Model」を書いていたStanley B. Lippmanが、
http://www.amazon.co.jp/exec/obidos/ASIN/0201834545/
C++/CLIの本書いてるなあ。

C++/Cli Essentials (MICROSOFT .NET DEVELOPMENT)
http://www.amazon.com/exec/obidos/tg/detail/-/0321174054/
http://www.compman.co.uk/htmlcat/0321174054_CplusplusCLI_Essentials.asp

Essential C++の人
http://www.amazon.com/exec/obidos/tg/detail/-/0201485184/

今までmanaged C++本買い捲って勉強してた人たちはどーなるわけ？

>>98
今まで通りでしょ?
C++/CLIへの大きな準備が一つ済んでるだけ。

変換ガイド: Managed Extensions for C++ から C++/CLI へのプログラムの移行
Stanley B. Lippman
Microsoft Corporation
2. マネージ型
http://www.microsoft.com/japan/msdn/vs05/visualc/TransGuide.asp#transguide_topic3

今まで通りなら、もうC++/CLI本を買わなくて良いわけね？

>>100
そんな事ないな、C++/CLI特有の癖が出るから
こんなコードにしとけってのはある

で、mc++系の本はドブに捨てときゃいいわけ？

>>99
C++/CLIでManaged C++が捨てられるのだけは確定では？
大きな準備がどうとかほざいてる奴は同様にCOMも死んでないって言うんだろうねえ。
そもそも「移行」ってどんことか知らない奴は気楽に言ってくれる。

どうしてMSがらみのマはいつもいつも「移行」に追い立てられなきゃならんのかな。
いつも「移行」だよ。簡単ですからとか、技術の発展ですとか言われてナ。

>>104
そうは言っても、いずれは捨てていく物もある訳で
ある程度かき回してくれるおかげでオープンシステムになっていてもニッチ産業以外の所で小さい所が勝負できる

>>104
その点COBOLなら変化がなくて安心ですね(^^)

>>104 >>105
あおりのつもりかも知れんが、コンピューターの世界はレイヤーで残っていくもんだよ。

Javaで呼び出す部分にCOBOLで作らせたり、いろいろと。

実行環境はふつー継承されるもんで、丸ごと消えるってのはありえない。

使われる前に消え去った.NET1.0、2.0、mc++って一体...

managedを理解してないと、
C++/CLIでmanagedとunmanagedを混在させたコードを書けないよ。
managedだけでいいって人は、managed C++は捨てていいと思う。
C++/CLIではその辺(__gcとか)を隠してくれるから。

自分は言語が好きだから、managed C++→C++/CLIの以降はいい事だと思うけれど、
現場は大変だよね。(けどmanaged C++で仕事始めているところってあるの?)

C、C++のライブラリが使えるのが重要なんであって、そんなんやったらC++の意味無いやん。

今110が正解を言った！
まあ、_tmainなんて腐ったもの見たくねーよな、みんな。

本当はWinMainもみたくなかったよﾏﾏﾝ

>>109
>managedを理解してないと、
>C++/CLIでmanagedとunmanagedを混在させたコードを書けないよ。
>managedだけでいいって人は、managed C++は捨てていいと思う。
すると、C++/CLIが規格通っても、新しく勉強する人はmanaged C++から
勉強しなきゃいけないの？そんなに大変ならJava使いたいよね。

>自分は言語が好きだから、managed C++→C++/CLIの以降はいい事だと思うけれど、
>現場は大変だよね。
学生やら工作員の人は楽でいいよね。現場は大変だよ。

>(けどmanaged C++で仕事始めているところってあるの?)
それはない。.NET自体、ないしな。（ｗ

さあ、盛り上がってきます他。

>>113
.NETはあるってｗ
VB.NETだけど

>>108
.NET2.0ってなくなっちゃったの？

C++/CLI、標準になってないのに__propertyをpropertyにしているな。
それからspaced keywordダサ過ぎ…

>>116
managed APIはなくなって、単なるライブラリになちゃたお。

じゃ、C++/CLIいらねーじゃん。

ttp://pc.watch.impress.co.jp/docs/2005/0804/mobile301.htm
　　　　　　　　　　
マイクロソフトOBでWindows 1.xの時代からWindowsの開発に関わっていた方(2000年に退職)から
コメントをいただいた。引用させていただくと

“私の住むシアトル近辺のマイクロソフトOBの間では、2004年の前半に「Longhornがキャンセルに
なったらしい」という噂がさかんに交わされ、その後次々と「OFSはLonghornとは別」、
「Managed APIは採用しない」とのアナウンスがありました。結局の所、もともと計画していた
Longhorn は出せなくなったけれども、いまさらキャンセルになったとは言えないので、出せるもの
だけかき集めてLonghornと呼ぶことにした、という見方がこちらでは一般的です”

>>118
＞managed APIはなくなって、単なるライブラリになちゃたお。

これの意味が分らないんだけどどういうこと？

> 同氏のコメントには「Managed APIは採用しない」というものもあるが、
> 確かにWinFXの位置付けも変化してきているように思える。一昨年秋の
> Professional Developers Conferenceでは、WinFXはLonghornの
> ネイティブアプリケーションが利用するManaged CodeベースのハイレベルAPIで、
> 次世代Windowsが実現する機能を新しいクラスライブラリでくるんだものだ
> と話していた。対してWin32を使うのは(WinFX混在も不可能ではないが)
> レガシーアプリケーションのみという話だったように記憶している。

managed APIの意味は分ったお。でも.NET2.0って元々Win32のラッパーじゃなかった？

俺も>>118は意味がわからんところが多いな。
実際問題managed objectが存在しなくなるなんて事言っているわけじゃないでしょ?
俺は要らないんだけれど、今更そんな変更出来るわけがないし(w
まあ適当なところでお茶を濁すつもりじゃないかと。

まぁようするに
本来のVistaはmanagedプログラミングしか許さない設計で
NativeC++でプログラムすると速度が遅くなるはずだったのが
開発の遅れと.Netが糞なせいでNativeC++とmanagedが対等の関係
もしくは　NativeC++ >　managed になっちゃった！
って事だろ

つまり今と状況は変わらないと。

いつものパターン

最近になってやたらとXPのCM入れたりしてるのは、Longhornの遅れが響いてるのかな。

>>120 >>121

>でも.NET2.0って元々Win32のラッパーじゃなかった？

OS本体がマネージドなWinFXとなって、下位互換のためだけに、その上にWin32APIをエミュレートする予定だったお。

急にスレ伸びたなおい。

言語仕様としてスコープの概念が使える（スコープ切れでデストラクタを呼び出させる）のは
やっとｷﾀかって感じだな。

C++使いからみてJava/C#あたりのGC系言語の大きな不満といえば、あとは
constメンバかな。あれはやっぱりCLIに組み込むのは難しいのかなぁ。。。

＃もちろんmodoptに仕込むとかは今でもやってると思うけど、
＃多言語との相互運用とかいろいろ考えるとむりぽかなぁ。。。

メモリの配置位置がそもそも移動するから無理ぽ。常時pinするような状況になるわけで
それならヒープに普通に置いた方がめんどくさくなくない？

>>127
俺はそれよりもSTLを使いたいがためにC++を使っている。

つSTL.NET

>>130
それは知っている。
こういうのがないから俺もJavaやC#は好きになれんと言いたかった。

STL.NET がC#にも対応したら、複雑だな

>>126
そもそもそんな事したらIntelが黙って無いだろ
それはCPUは何でも良いって事になるんだぞ

別にintelは気にしないだろ。昔から殺伐した仲だし
32bit->64bit移行もあるから、そこらを切り離すのは普通の判断だべ

>>126
> OS本体がマネージドなWinFXとなって、下位互換のためだけに、
> その上にWin32APIをエミュレートする予定だったお。

この設計がもう滅茶苦茶バッドセンスなわけだが…それでいて、

>>122
> NativeC++でプログラムすると速度が遅くなるはずだったのが

って、それお前等がそうやっているからやん…

やはり最初はnativeの上にmanagedをwrapしていくことから地道に始めるべきだったかと。

>>132
一応、言語依存をなくす方向だよね。> STL.NET
CLI的なgenericにして。

ただこんなこと(言語非依存)やっていると、どんどん実装が遅れる。
ISO C++の時みたいに仕様だけどんどん出来て実装が追い付かない。

まあ流石にHaskell.NETは置いてきぼりだろうが(w

>>135
概ね同意。
でも、営業的にはもうWin32APIを切り捨てたいというのがあるんだよな？確か。
その為に移行期間としてエミュレーションで動くようにして、徐々に
減らしていくぞと。この方向は間違ってはいなそう。

営業的見解から言い出したことが、やってみたら
（技術的にか時間的にか環境的にか知らないが）やっぱり難しかった
って結果のような気がする。個人的にはゆっくり移行で良いと思ってるので
この流れで良いかな。

VC8には、STL/CLI(STL.NET)が入らない
http://www.ailight.jp/blog/sha256/archive/2005/10/04/9826.aspx

残念でした。

>>137
> 営業的見解から言い出したことが、

"光の速さの経営"的見解に決まっているでしょ…

>>138
まだ無理。正直C++依存性が残ってる。
早く入れすぎて悪い設計を改変できず負の遺産、
これがMSの技術面の一番悪いところだから、入れないことはいいんじゃないの?

>>137
>でも、営業的にはもうWin32APIを切り捨てたいというのがあるんだよな？確か。
>その為に移行期間としてエミュレーションで動くようにして、徐々に
>減らしていくぞと。この方向は間違ってはいなそう。

だから、困るっちゅーに。
ソースコードってのは生き残るもんであって。

結局は、
・Win32じゃないNative APIも。
・Win32はNativeの上に互換ライブラリで。(ただし少しは改変必要)
・managedの世界もありまっせー。
になるんじゃまいか?

>>117
> それからspaced keywordダサ過ぎ…

いまさらcppの意味まで変えようつーのにはたまげた…
(cpp単体での)互換性切り捨てすぎ…というかアホ? > MS/Lippman

もうC++の名を捨てて新しい言語として出直したらいいのに


……そりゃC#か

>>138

http://forums.microsoft.com/msdn/ShowPost.aspx?PostID=14599

この話だよね。

結局C++をなんとかしようとしてどうにもなりませんでしたというわけだ。
Javaはガベージコレクタはありますがcloseメソッドをその都度呼び出せとだましとおす気だ。
closeがdeleteだったらバカは気づいただろう。
C#は誰も理解していないしその存在が不明だ。この言語はいったいなんなのだ。
C++/CLIは超難解なC++言語でがんばって数十メガのVMがロードされるというわけだ。
むくわれない。

あきらめろ。もうC++はboostとがんばれよ。

人の邪魔をするな。
俺は俺だ。お前がどう感じようが関係ない。

>>145
今時のパソコンで数十メガなんて意味を持たない

わざわざ対象のスレにまで来てネガティブキャンペーンをするやつは
結局のところ、自身の不安の裏返しなのだ。

せっかくC#おぼえたのにー

無駄銭だったねｗ

そもそもC++&.NETが間違いだよなぁ。
まあ今更だけど。

無駄じゃない！全然無駄じゃない！

無駄無駄無駄無駄無駄無駄無駄無駄無駄無駄無駄無駄ァァァ！！！

だからぁ、普通のC++ライブラリを混ぜれて、コンパイラオプションでWin32/Win64/ドトネトが切り替わるなら、どんどん使ってやる。

>154
C++/CLI はその通りですが何か？

STLさえ使えなくて、パチモンのSTLドトネトが要るなんて...

>C++/CLIは超難解なC++言語でがんばって数十メガのVMがロードされるというわけだ。
･ﾟ･(つД`)･ﾟ･

>今時のパソコンで数十メガなんて意味を持たない
　　　　 ∧＿∧
　　　　　（ ´∀｀ ） 　このゴミ、どこに捨てたらいい？
　　　　 /⌒　　 ｀ヽ
　　　　/　/　　　 ﾉ.＼＿M
　　　 (　/ヽ　　　|＼＿__E）
　　　　＼ /　　　|　　 ／　 ＼
　　　 　 （　　 _ﾉ |　 / ｳﾜｧｧﾝ ヽ
　　　　　 | 　 /　/　 |ヽ（｀Д´）ﾉ|
　　　 　　|　 /　/　　ヽ（>>147）ノ
　　　　 　(　 )　) 　　　￣￣￣
　　　　　 |　|　/
　　　　　 |　|　|.
　　　　　/　|＼ ＼
　　 　 ∠／

>>157
「C++/CLIは」というより、
Longhornは常にCLRが動いていて、その上でサービスを受けるわけでしょ。
C#やVBだって同じ。

　　　　　 ∧＿∧
　　　　　（ ´∀｀ ） 　このゴミ、どこに捨てたらいい？
　　　　 /⌒　　 ｀ヽ
　　　　/　/　　　 ﾉ.＼＿M
　　　 (　/ヽ　　　|＼＿__E）
　　　　＼ /　　　|　　 ／　 ＼
　　　 　 （　　 _ﾉ |　 / ｳﾜｧｧﾝ ヽ
　　　　　 | 　 /　/　 |ヽ（｀Д´）ﾉ|
　　　 　　|　 /　/　　ヽ（Longhorn）ノ
　　　　 　(　 )　) 　　　￣￣￣
　　　　　 |　|　/
　　　　　 |　|　|.
　　　　　/　|＼ ＼
　　 　 ∠／

>>158
LHは1.1じゃなかったっけ？

2.0 だろ。WinFX は PlatformSDK のような扱いになるらしいが
>>158
もともとCOMサーバが動いてるんだから、変わらないでしょ
CLR は COM 後継なんだし

後継にしては今までのソースが全て吹っ飛んでしまうのは何故？

そこでC++/CLIですよ

>162
(ﾟДﾟ)ﾊｧ?

>>162
レガシー

>>165
もうカルディナは必要ありません。

Vistaはネッツに吸収されました。

アニヲタばっかりだな

車なんだけど...

>>68
LinqやActive Objectが、C++0xに入るわけないだろ。

この辺が入ったC++/CLIはEMCAで標準化されるだろうけど。

そーいえば、Ｃ貪とかいう標準化されたどーでもいーものがあったね。

標準化なんてＣＯＢＯＬでもある。
というか、プログラムの長持ちではＣＯＢＯＬのが先輩だね。

168 名前：デフォルトの名無しさん[sage] 投稿日：2005/10/06(木) 15:13:30
　　アニヲタばっかりだな

169 名前：デフォルトの名無しさん[sage] 投稿日：2005/10/06(木) 15:15:10
　　車なんだけど...

active最高杉

168 名前： デフォルトの名無しさん [sage] 投稿日： 2005/10/06(木) 15:13:30
アニヲタばっかりだな
169 名前： デフォルトの名無しさん [sage] 投稿日： 2005/10/06(木) 15:15:10
車なんだけど...

ワロタ

よくわからんが、車を元ネタにした名前が出てくるアニメがあるって解釈でいいのか？

>>175
レイアースの登場人物の名前は車に由来。
ジョジョの登場人物の名前はミュージシャンに由来。

とCLAMPのアニメを3本見ただけの俺が答える。

つまり「アニヲタばっかりだな」が正解？

>>177
「アニヲタ馬鹿だな」が正解。

アニオタのせいで秋葉原って今ものすごいキモイ町になってる

そういや開業直後にTXに乗ってアキバへ行ったが、駅を出たら見知らぬ光景に遭遇して慣れるのに
時間を要した。ちなみにヨドバシカメラにはまだ行っていない。

>>179
アニヲタはそれほどでもない。むしろエロゲヲタが酷い。

>>181
悪いが区別が付かないのでどうでもいい。

>>182
プログラマとSE

>>183
悪いが区別が付かないのでどうでもいい。

よくテレビや雑誌で晒されてるようなヲタって何ヲタなの？
電車男みたいなやつ

ヲタというより、むしろ朝からパチンコ屋に並んだり、競馬場にたむろしてる連中を連想する。

パチンコ屋に並ぶのは朝しかねーだろ？
バカかおめー昼夕オープンなんて滅多にないんだぞ
しね

とパチンカスが言っております。

>>185
プログラマじゃないの？ :-)

>>186
社会の底辺にいる人達か。

なるほど、プログラマは朝からパチンコ屋にならんで競馬場にたむろしてマルチ萌え〜とかセリオたんﾊｧﾊｧって言ってる人たちなのか
モニタの上に変なフィギュア飾ってるし

>>191
通常の業務の上にそんなことまでしてたら過労死するな。

朝からパチンコ屋にならんでなんいうやつはｱﾌｫ１確
お金をつかって買い物するっていってるような物だぞｗ

>>193
おまえは中国人かよｗ

デカ顔＆短足＆チビの日本人よりはマシｗ

ズボシだったのか
いや、悪気はなかったんだ
ジョークだ許してくれ

COME WITH ME
ってｶｯｺｲｲ

誰か>>193の言わんとすることをわかりやすく解説してください。

おまいら、巣にｶｴﾚ

>>198
日雇いのバイトで得た給料を次の日にパチンコでなくすようなやつなんだ。
そっとしといてやれよ。

プログラミングヲタよりは（ｒｙ

>>200
その日の内にだろ

>>202
夜勤の場合はその通りだな。

ここにいるひとってやっぱ電車男みたいな人ばっかり？
俺は電車男そのものだけど・・・orz

電車男って、アニメオタクでプログラミングなんてしないんじゃ？　（テレビしか見てないけど

電車男はあまりオタクじゃないよ
完全に消費者だし

もはやC++/CLIはどうでもよくなってる罠

>>168逝って良し

>207
必死に自作自演してるんだよ。ほっとけ

へー、pure Java の CLRなんてあるのか。
逆もあれば、無限に重ねられるな

>>210
詳しく

C#のほうが気になる

>>210
ただでさえ重いCLRをJavaなんかで実装したら使い物にならんだろ

C#もっと速かったら使いやすいし、いいんだけだな〜

釣れなかったみたいだねﾌﾟｹﾞﾗ

checked statement なぜ使えないのだろうか...orz

C++/CLIをちょっと.NETのライブラリとか使いたい部分だけマネージにして後はほとんどアンマネージにしてる人って居る?
その場合の速度知りたいんですが･･･
C#ちょっともっさりしすぎ。

>>217
部分的にでもCLRを呼び出している以上起動時のもっさり感は変わらない。
P/Invokeよりは高速とはいえ、ネイティブ−マネージドの遷移は負荷が高いから
混ぜたいなら呼び出しの単位は大きいほうがいい。
画面まわりをネイティブで書いて、メニューからのイベントをマネージドで
処理するような使い方（またはその逆）は向いているが、
特定のロジックをネイティブにして頻繁にマネージドコードから呼び出すのには向いていない。

ホスティングすればいいんじゃないの？＞起動の遅さ
ttp://d.hatena.ne.jp/akiramei/20051108

STL.NETはどこからダウソできるん？

STL.NETじゃね？

> ネイティブ−マネージドの遷移は負荷が高い

え？

>>219
だたホスティングしてもmscoree.dll をCOMで呼び出すだけだからあまり変わらない気がするが、
同じプロセス空間に複数のアップドメインを作ってアセンブリを起動するシェルのようなものを作れば、
それなりに起動は速くなるかもしれないですね。

>>222
え？　managed codeからnative codeをオーバーヘッド無しで呼べるといいたいのかな？

呼べるでしょ。
データの受け渡しにコストがかかるだけで。

>>224
呼べません。

一見そのまま呼べるかのように振る舞うだけじゃなかったか

オーバーヘッドって具体的にどんな処理してるんだろ。

マーシャリングとかじゃね？

マネージドとネイティブの世界には分厚い境界線
なるものが存在するんですよ。
その境界線を越えようとするものは某北朝鮮から脱国するがごとく
リスクを負わなければならないのですよ。

intしか使わないネイティブを、
SuppressUnmanagedCodeSecurity, LinkDemandすればコストほとんどなしなんじゃないの?

構造体もValueType使えば、ボクシング/アンボクシング行われないしね。

>>229

つ Borland(R) Developer Studio 2006 ttp://www.borland.co.jp/news/20051124_bds2006.html

マネージドとネイティブをコンパイルで切り替えだお。

value class制限大杉

ref structとvalue classの違いは？

ref structって値型じゃないの？

ref classとref structの違いって何よ？デフォルトpublicとprivateの違いだけ？

ref　←→ 値型

ref class と ref struct の違いは class と struct の違いと同じ
ref 型がCLRに管理されてるクラス。value 型は primary な値を意味するクラス

OKありがとう。とてもわかった

値型だと
デフォルトコンストラクタ
コピーコンストラクタ
デストラクタ
ファイナライザ
代入演算子
が定義できなかったよ。

デフォルトコンストラクタが定義できないんで引数無しのタグクラス食わせてるんだけど
何かあるんだろうか...
それとデストラクタが定義できないせいで単純にnewすると解放ができない。

>>236
C#って知ってる？

> newすると解放ができない。

なんか言ってることおかしくない？
解放って？

>236
値型は primary な型を作るためのものだから、int とかにデフォルト・コンストラクタや
ファイナライザを定義しないでしょ？

>>236
値型は、初期化しによる初期化、代入などで、
memcpyが行われるだけでいいようなオブジェクトに使う。
定義できなかったと言うより、定義しないでいいものに使う。

>>238
template <typename T,typename TAG>
value struct a
{
T *p;
a(TAG)
{
p = new T();//NativeC++のスマートポインタが使えないのでCLIなスマートポインタが必要ぽい
}
};

>>239,240
参照型だとコピーコンストラクタいちいち用意するの面倒じゃん。
C++とC++/CLI両対応のソース書きたいので値型にしてる。

>>242
.Netでは「クラスは参照型」となっているのだからいつか破綻する。

それは思考が逆で、
コピーコンストラクタが必要ないから値型にしているのであって、
面倒だから参照型を使わないんじゃない。

値型か参照型かは性能にもろに影響してくるから
適切に選択した方がいいよ

普通にクラスを書けばいいんじゃないか？
わざわざ値型で定義しようとするから、苦労しているだけだと思うが

>>45
LLVMがgccに入りそうな勢いだなあ。

参照を初期化リストで初期化できないのですが、
なぜなのでしょうか？
value struct UseRef
{
explicit UseRef(int& in_i)
:i(in_i)
{}
int& i;
};
ref struct TestRef
{
int i;
UseRef r;
TestRef()
:r(i)
{}
};

値型は生成時にデフォルト値を持つ必要がありますが、標準C++ の int 型はデフォルト値を
規定されていません。そのため、生成時に不定となる値の参照を型として保持できないと思われ

>>249
ありがとうございます。
参照型でも試してみましたが、やはりだめみたいでした。
一度、GC Heapにgcnewしてそこからinterior reference？(int%)を取得することで
参照のように扱うことはできました。
どうも値型のメンバには値型かGcHeap(Cloneされる)しかおけないようです。
また、interior ptr|referenceのときもクラスのメンバにはできないようです。

まぁ、仕様書見るとそう書いてありますね

俺の勘で。
ref struct TestRef
{
  int i;
  UseRef r;
  TestRef() : i(0), r(i)
  {}
};

UseRef のデフォルト・コンストラクタが不定値を持つから駄目ぽ

組込型だと
普通のref class とvalue classで通るコードでエラーがでるんだけど
属性とかでなくコンパイラにはじかれてるのかな？

Int32 o_int(0);
Int32^ g_int = gcnew Int32(0);
Int32% r_int = *g_int;
//Int32^ rg_int = %r_int;//NG

//String o_str;//NG
String^ g_str = gcnew String("");
//String% r_str = *g_str;//NG
//String^ rg_str = %r_str;//NG

なんだか汚い言語になっちゃいましたね

perlみてー

C++が汚いのはもとからだろ

>>255
思いつきで拡張してるよね。
C++の世界では有名な人達がやっているんだが…

だれだっけ？

Stanley Lippman
http://staff.develop.com/slip/
http://blogs.msdn.com/slippman/
http://www.microsoft.com/presspass/press/2001/oct01/10-19lippmanpr.mspx

Herb Sutter
http://www.gotw.ca/
http://blogs.msdn.com/hsutter/
http://www.microsoft.com/presspass/press/2002/Mar02/03-13SutterPR.mspx

Perlは美しい。C++もああいうの目指すべき。

>>260
漏れはあまり詳しくないんだが、そうか？？？本当にそうなのか？？？？？？？

そんなあなたに Brainf*ck

>>255-257
良くも悪くもC++的っていう気はする。

C++は細かいところで汚いなりに、それなりのポリシーがあったが、
C++/CLIに至ってはなんでもありだ。実装の都合としか思えないものもある。

C++をぐちゃぐちゃにしC++コミュニティーを崩壊させる。

↓

C++の衰退とC#の反映

Ｃ＃はメジャーにならない
断言する

名無しで断言されても……

>>265
それか！！

C++/CLIの設計コンセプトは「拡張機能を使わなければ、既存のC++と変わらないこと」だから
別にC++に変な影響を与えないと思うけど

果たしてそうかな

>>270
そうだよ。

関係ないが、親玉格のC(99)がやらかしてくれてるからなあ。

C++はまだ「生きた」言語なんだよ。
まだまだ進化する。

ここに書いて良いのかわからんかったんですが。
タスクマネージャーの「CPU使用率の履歴」みたいな動的な(?)グラフを出せるものを書きたいのですが
何から手をつければいいのか、全くわかりません。
アドバイスよろしくお願いします。

age

>>274
とりあえず↓この本読め。
http://www.amazon.co.jp/exec/obidos/ASIN/4872331265/qid=1133701895/sr=1-1/ref=sr_1_10_1/249-6035794-3226728

>>272
C99のマズイところでどんなとこ？
得に思い当たらないんだけど

エラーのthrow/catchが、cとc++で別になったのは痛い。

MFCとC++、C丼とC++、MC++とC++、C++CLIとC++、それぞれ結局別物と思われてるところも痛いけど。

実際別物

MFCを持ち出してくるところが痛い。

MFCって、mc++とかC++/CLIから使えるんだっけか？

C++/CLIやmc++の構文を使ってないコードを /clrでコンパイルしたものを
C++/CLIやmc++のプログラムと読んでいいかどうかによるけど、
そう呼んでいいなら使える。

managed と unmanagedの型でデータ交換したいのですが、
COMを使うしかないのでしょうか？

>>283
具体例を挙げてわかるように質問してくれ。

＞/clrでコンパイルしたものを
どういったオプションでつか？

>>284
混合クラスにできないだけで、
別クラスにしておいて呼び出しは可能だったのね...

Marshalingできる時はしたほうがいいのかな
ttp://msdn2.microsoft.com/library/ms235282(en-US,VS.80).aspx

unmanagedからmanagedの呼び出しはできないみたい。

CLRホスティング・・・

managed c++, c++/CLI なら
managed から nativeのモジュールを呼び出すことも
cl /MT /c submod.cpp
cl /clr mainmod.cpp submod.obj
native から managedのモジュールを呼び出すこともできる。
cl /clr /c submod.cpp
cl /MT mainmod.cpp submod.obj

最強

unko

C++/CLIの存在意義って？

マネージならC#でよくね？

そうだな。

やっぱりC#?
C++から移植するのってどれぐらい工数かかるんだろうか・・・・

ぶっちゃけ、WindowsアプリならVC++6&MFCが最強では？
あえてC#を覚えようとする気がしない。
VC++6&MFCでつれないWindowsアプリはない。

かわいそうな人

あえてCを覚えようという気がしない。
機械語で作れないwindowsアプリはない。

あえて計算機を覚えようという気がしない。
脳内で計算できない問題はない。

切り返すなら同じ性質の物事を書かなきゃ :-P

>>297
俺も未だに機械語で書いてるよ
Cだとおせーから嫌だ

>>295
なるほど、いろんなWindowsアプリさんたちが釣れるようでつね。

>>295はLonghornが出たら干される使い捨てデジドカ

OSが記述できてしまう
C++は絶対に廃れないよ
しかも、デバイスドライバを書ける人は絶対に不可欠
C#やJAVAなんてモノが出来ても結局また
新たな言語が出てきて廃れるのは必至

つまりCOBOLと似たようなもんだ。
新しい言語の出現で全盛期より減ったとは言え、需要がなくなることはありえない。

歩く死体か。

Cで必要にして十分な件。

既存のプログラムが全部マネージ環境で通るようにライブラリとか
整えて欲しい。

printfやstrcmp使うとネイティブとの混合アプリになっちゃうんでしょ？
標準ライブラリの中も.NETにすりゃあいいのに。

混合になってなんかマズイことでもあるのかい？

>>307
あなたは根本的にCLIの世界を理解してないです。

>>308
混合だとWin以外に持っていけるの？（あるかはしらんけど）
あと、切り替え時に異様に遅い感触。

>>309
根本を教えてくれ

感触って君の思い込みのこと?

>>311
/clrつけてコンパイルしなおしたプログラムが異様に遅い。
.NETにしてもちょっと遅すぎると思ってね。原因がネイティブ
部分の呼び出し負荷くらいしか思い当たらない。

簡単なやつで試してみた。環境はPen4-3GHz

int a=0;
while(a++<200000000){
stricmp("abc","123");
}

ネイティブアプリだと１、２秒、CLIだと１２秒くらいかかる。

stricmpをmy_stricmpに変えて、以下のように適当に定義してみると、
ネイティブでもCLIでも１、２秒で終わる。（my_stricmpは適当。要は
標準ランタイムを呼ばなければ良い）

int my_stricmp(const char*a,const char*b){
while(*a++==*b++){
if(a[0] == 0)
return 0;
}
return -1;
}

ちなみに、strcmpだとCLIでも１、２秒で終わるのだが、良く分からん。
strcmpだとCLIでもインライン展開されるのかな？

>>313の例ではネイティブへの切り替え以外に負荷になる要素は
無いと思うんだが、識者の意見希望。

関数の処理が遅いのか、CLR の起動に手間取っているのかは、ちゃんと分けた？

>>315
my_stricmpを使ってネイティブと時間の差が無いのだから、
起動時間の問題じゃないと思う。

あと、ループの回数を増減させれば処理時間も比例する。

>>313
strcmpは？stricmpだとCLIの方はロケールとかで色々面倒くさい
ことしてそう。

>>313
ではlstrcmpはどう？
これなら絶対にインライン展開できない。

>>318
lstrcmp,これから試してみるけど先に質問。

>>317に関して、
俺、やはり根本が分かって無い模様。strcmpは313に書いた通りなのだが、
stricmpの場合でも、CLIからネイティブと同じルーチンが呼ばれるもんだと
思っていた。

この前提で、中身が一緒なら呼び出してる部分に負荷があるんじゃないかと
思っていたわけだが、ネイティブとCLIで呼び出されるstricmp（に限らず標準
ライブラリ全般）は別物なの？

>>319
その試した見たというコードをどこかのアップローダに晒すというのは
どうだい？そうすれば同じ土俵で話ができる。

>>318
試してみた。lstrcmpの場合、ネイティブ３７秒、CLI４７秒だった。
lstrcmpこんなに重いのかというのはともかく、差がstricmpと
同じ。つーことはやはり呼び出し負荷でしょう。もちろんループ
回数も同じで測定している。

>>320
＞その試した見たというコード
今までの数字は全部313のサンプルコードでの話。
mainかWinMainで囲ってちょうだい。

INT WINAPI WinMain( HINSTANCE, HINSTANCE, LPSTR, INT)
{
{
int a=0;
while(a++<200000000){
stricmp("abc","123");
}
}
return 0;
}

アセンブリ（アプリケーション）で閉じてる範囲に置いては、CLIはロードされないんじゃね？

>>322
意味が分かりませんorz

>>321
> つーことはやはり呼び出し負荷でしょう。

それ言うなら、

> もちろんループ回数も同じで測定している。

回数変えてファクターが何か調べないと。面白い奴だな(w

>>324
回数変えたら実行秒数が比例するけど。

my_stricmpにしてネイティブと差が無いわけだから、違いは
標準ライブラリの呼び出し以外に何か考えられる？

y = ax + b の a を比べろと言えば分かりますか?

>>326
何を言ってるのか分かりませんが、
具体的に他にファクターがあるならあげてみて欲しい。

こちらの比べ方に抜けがあるならそこを指摘してくれまいか。

ちょっと、煽りと神経質になってる人もいるみたい
まぁ、とりあえず、時間の出たマシンのスペックを教えてちょ
問題になっているのは、msvcm80.dll 辺りかな

回数を2倍にしても実行時間が2倍になるとは限らない。
325に比例するとは書いてあるけど、比例にもいろいろあるだろうに。

いや、確認した。これは、なんだろう

比較のサンプルソースを出すね

C++/CLI
int main(array<System::String ^> ^args)
{
　　const char *buff = "buffer";
　　const char *check = "Test";

　　DateTime dt = DateTime::Now;
　　for ( int i=0; i<2000000; i++ )
　　{
　　　　//strcmp(buff,check);
　　　　mycomp(buff, check);
　　}
　　DateTime endTm = DateTime::Now;
　　Console::WriteLine("Time : {0}", endTm - dt);
　　return 0;
}

int mycomp(const char* before, const char* after)
{
　　while(*before++==*after++) if(before[0] == 0) return 0;
　　return -1;
}

これで、strcmp とmycompを切り替えるだけで、全然速度が違う。なじぇ？

ﾜﾗ

まるで見当はずれかもしれませんが
int mycomp(,,,) の前に #pragma unmanaged を置いてみるとどうなりますかね？

ごめん。これは速度が違って当たり前だった。ろくにチェックしていない
before をちゃんとチェックすると、だいたい１６秒でstrcmpと変わらない
むしろ、ネイティブだと一瞬なんで、処理に時間がかかる理由が気になる

すまん。>>333 は元の関数のコメントアウトをしてなかったorz
mycompにすると一瞬で終わるね。もうちょっと、関数の実装をちゃんとするべきなんだろうけど
ネイティブに記述された関数はネイティブで処理されてる。となると、C標準関数が問題
なのか・・・

>>329
＞回数を2倍にしても実行時間が2倍になるとは限らない。
それは比例じゃないと思うけど。
言葉どおり比例と受け取って欲しい。

だからループ外のファクターでは無いと思う。

>>334
マシンの速度が分からないけど、200万回のループで１６秒もかかる？

あと、strcmpだとこちらではCLIでもネイティブと同じだった。

stricmp,lstrcmpで、ネイティブとの差が2億回のループで10秒。

差が同じなので、処理内容の問題でも無いと思う。
こちらのマシン速度は>>313です。

>>329
言葉が足んなかった、すまん。ax+bのbの部分はごく小さいと思って欲しい。

>>332
試してみた。
CLIでmy_stricmpをunmanagedプラグマで囲ったら、少しだけ遅くなった（３秒くらい）。
囲わなかった場合、今朝計り直してみたら１秒未満。

「思って欲しい」(w ってんじゃなくて、普通は i<2000000 だけじゃなく、
i<500000、i<1000000、i<2500000も取ってグラフをプロットするわけ。

あと、*cmp("abcdefghijklmnopqrstuvwxyz", "abcdefghijklmnopqrstuvwxyz")と、
*cmp("buffer", "Test")で比較するとかさ。
関数呼び出しのオーバーヘッドをみたいなら、
関数内の処理を軽くしたり重くしたりして違いを見るのが定席だろ?

strcmpとmycompじゃ実装が全然違うわけだから、そのくらいはしないと、
呼び出しがオーバーヘッドになっているかどうか分からない。
一文字目の比較で関数が返るから、関数呼び出しの差を見えると思ったかもしれないが、
ソースのない方はもしかしたらNULLチェックしているかもしれないし、
タコなコーディングかもしれない。
分からないはずなのに安易に結論づけているから、スルーされてる。

表計算ソフト、数式処理ソフト、グラフプロットツールあれば簡単にグラフ化できるよね。

・・・2億回で10秒って、別に違いがあって不思議じゃないよな？

>>338
単純化しただけであって、回数そのものは突飛でもない。

俺が問題にしてるのはCLIで標準関数呼び出しが遅い
ということ。>>337のいうようにちゃんとやることも出来るが、
そこまでやら無くても「CLIで標準関数呼び出しが遅い」のは
今までの例で明白じゃない？

最適化の違いだけだったりして
自分で言ってるけど、strcmp でネイティブと違いがないなら「CLIで標準関数呼び出しが遅い」
とは言えないんじゃない？

>>339
明白かどうかわかんないから粘着してんじゃないの？
他のファクターを探す手助けにもなるんだから手抜かずにやれば？

最適化で思ったんだけど、310 のネイティブの結果って速過ぎない？
漏れ、turion M37 2000 相当で以下のソースで1億回廻したけど、8秒ほどかかった
メモリも800MBほど食べた

int _tmain(int argc, _TCHAR* argv[])
{
　　const char *a = "sample text a";
　　const char *b = "sample text b";
　　std::vector<int> results;
　　time_t stm = 0;
　　time(&stm);
　　for ( unsigned long int i=0; i<100000000; i++ )
　　{
　　　　results.push_back(strcmp(a, b));
　　}
　　time_t etm = 0;
　　time(&etm);
　　std::cout << "Result : " << etm - stm << " Size : " << results.size() << std::endl;
　　return 0;
}

あ、すまん。濡れ衣だな。パフォーマンスの違いと詰め込み時間を考えれば、妥当か
ちなみに、/clr では同等のソースで11秒だった

>>340
遅まきながらステップしてみた。
strcmpはCLIでもインライン展開されていた。
stricmpはcallされていて、スタックトレースウインドウに
マネージからネイティブへ以降、と表示される。

漏れの環境での比較と詰め込みの結果
　　　　　CLR　native
strcmp　11s　8s
stricmp　16s　13s
lstrcmp　20s　17s

なんか、綺麗な結果になった。CLR の起動コストとかで +3s ぐらい

>>341
1回、1億回、2億回でほぼ直線状に並んでたから比例と書いた。
１回なら起動の時間は気にならないくらい一瞬で終わる。

>>345
ループ1回で+3sかかりますか？

>347
それはなかった。何らかのコストがかかっているのは確かみたい
CLR 側のやつはDateTime とか Console::WriteLine を使っていたので、ソースを完全に
同一にすると、
lstrcmp　19s　17s
になった。1億回のループでこれだから、あとはパフォーマンス・カウンタでも使わないと
細かくはわからない領域だと思う
ちなみにいろいろと切って静かに取ってみたら

　　　　　　CLR　Native　CLRx64　Nativex64
lstrcmp　　16s　　14s　　　15s　　　12s

なんて結果になった

>>348

342のソースはSTLの負荷が大きいのと、strcmpはインライン化されて
マネージ、ネイティブの切り替えは見えにくくなってると思う。

だから純粋にネイティブとCLIの差じゃなかろうか。

STLとっぱらってstricmpとかだけにしたらこちらの結果と
相似に近いのが出るんじゃないかな。

STLはマネージ側で実行されるんでしょ？　だからネイティブとの
大きな差にはならないんじゃないのかと。←こっちより差が小さいから

>349
んにゃ。STLはネイティブだよ。ループで代入しているのは、最適化でループ自体が外される
のを防ぐため

しかし、CLRx64 にはもうちょっとがんがってほすぃ

>>350
>STLはネイティブだよ
ありゃそうなの？　テンプレートっつーくらいだから
マネージとしてコンパイルされてるのかと思った。

>351
それはジェネリクスを利用した STL.NET と混同してるんじゃないかな
しかし、+2秒はいったい何をしているのだろう

気になったので試してみた

　　List<int>^ results = gcnew List<int>;
　　time_t stm = 0;
　　time(&stm);
　　for ( unsigned long int i=0; i<100000000; i++ )
　　{
　　　　results->Add(lstrcmp(a, b));
　　}
　　time_t etm = 0;
　　time(&etm);
　　std::cout << "Result : " << etm - stm << " Size : " << results->Count << std::endl;

　　　　　　CLR　Native　CLRx64　Nativex64
lstrcmp　　13s　　11s　　　12s　　　9s

なかなか、よい結果です

>>346
数学苦手だった人?

直線と言っても限りなく水平に近いものから限りなく垂直に近いものまであるわけで。

>>353
ｽｹﾞｰな

.net2.0SDKにはC++/CLIのコンパイラって付いてくるの？
managedC++は？

ついてこない。

えええええええええええええ

.NET 1.0のmanaged c++の頃にやったテストなのだが、
C#やVB.NETでも使えるP/Invokeに比べて、
importlibで呼び出す場合はかなりパフォーマンスがよかった。
単純なNativeコードのDLLを作り繰り返し交互に呼び出すテストで、
かかった時間はP/Invoke 24, importlib 3
nativeコードからimportlibを使っての呼び出し 1.5 の比率。
DLLを作らずobjのリンクの場合、native-nativeで１、managed-nativeで2.5。
というわけでC++/CLIの存在意義はmix modeにあると思っている。

>357
cl /clr
cl /clr:oldSyntax
ってやってみな

>>360
つか、今時Win32 APIをコールする必要があるか？？？

ある

>>362
まだ大いにあるよ。

>>362
君にはない。

>>362
今時っていうか、今程度の.netじゃ、
まともなWindowsプログラミングやるならWinAPI叩かざるを得ない。

激同

>>366
そうか〜？
.NET Frameworkのクラスライブラリだけですべて作れますけど・・・

いまんところ直面した問題
・ＩＭＥ
・Ｃａｒｅｔ
・ScrollWindowEx

>>369
初心者スレ行けばｗ

>>370
あほか。流れ嫁。API呼ばなきゃいけない問題だ。かす。

>>371
初心者スレ行けばｗ

>>368
SHFileOperation

VBのMyを使えとか言ったら刺す。

>>371
初心者スレ行けばｗ

>>368
FileDialogのカスタマイズ

>>375
初心者スレ行けばｗ

こう見るとできないことだらけだね。
MSはどうするつもりなんだろう

そのためのC++/CLIじゃないか

>>368
ありふれた業務アプリ程度ならそれほど困ることもないけど、
ちょっとばかしシステムに寄った途端にできないことが増える。

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

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

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

あるあるｗｗ

ttp://s03.2log.net/home/nsharp/archives/blog404.html

正直賛同できません。

Cに勝る言語はないってことだな

Win32への依存度を下げる必然性がないんだから当たり前でしょ？

Win95が出たときの3.1使いもそう言ってた

Win16→Win32s→Win32のこと?
あれは言語一緒だしね…

技術的な需要もないことはないけど、それよりただ新しいWindowsを
作らないといけないことだけが先行してるのが萎える。市場に対して
新規性を謳うことだけが最重要課題なんだよな。

次は ISO だな
http://www.ecma-international.org/publications/standards/Ecma-372.htm

ISOは無理。

C#はISOだぞ
C++/CLIだってきっと

CLI は ISO で標準化されてたっけ？

CLI 標準はこれだな
ISO/IEC 23271:2003

このへんね。
http://www.plumhall.com/ecma/
http://msdn.microsoft.com/visualc/homepageheadlines/ecma/default.aspx

http://itpro.nikkeibp.co.jp/article/COLUMN/20051125/225170/?ST=win

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

とりあえずVC++は標準C++への準拠度が高いことに間違いない。

これまでは準拠してなかったということ？

そゆこと

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

へぇ。２００５からはキショクはないのか。
VC++（というIDE）を使ってなかった人も使い出したりするんだろか？

IDEがVC6位軽ければみんな使うだろうに

自分の価値観を回りに押し付けないように

ただそこに意見が存在するだけで
押し付けられたとか思い込まないように

ttp://mag.autumn.org/Content.modf?id=20050425162104

C++復権すると思う？

>現状で極めて私的な感想から言えば、>JavaとC#の
>代替プログラム言語になり得る第1候補はVisual Basicです。

>>401
復権もなにも
C++で記述できないプログラムはないんだから・・・

>>403
それは今のCPUがC言語を動かすことを前提としてる面も大きいと思う

CPUがC言語を動かす？

意味不明

0番付近がNULL対策に実メモリを割り当てないようになってたりするじゃん。
他にC言語で簡単に扱えないメモリレイアウトを要求しないとかさ。

>>406
> 0番付近がNULL対策に実メモリを割り当てないようになってたりするじゃん
これはOSの問題という側面のほうが大きいと思う。
別にC/C++ではヌルポインタのビットパターンは0でなくとも良いとなっている。

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

>>406
x86のI/Oポートは「C言語」では叩けないよ。

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

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

x86のI/Oポートをたたく必要がない

>>403
「brainfuck復権すると思う？」
「復権も何も、brainfuckで記述できないプログラムはないんだから……」

>>410
いまだにつかっていますが、なにか？

みんなの大好きなあの言語が.NETの仲間入り。
brainf*ck.NET

>412
ソースコードｷﾎﾞﾝ

C++/CLIの入門サイトってありますか

VB.NET のPGで、構文解析を行う必要が出たときに、
C++/CLI で boost.spirit 使って手軽に構文解析モジュール作成して、
VB.NET から参照設定で呼び出す

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

マルチランゲージは素晴らしい。

現実はJ#は開封もされない事実。
ﾌﾞﾋﾞ厨はＣ貧を嫌い、Ｃ貧はﾌﾞﾋﾞ厨を嫌う。

Ｍ＄の理想は宣伝専用。

>415
普通にできるけど？

C#で以下のようなコードを
using (FileStream fs = new FileStream("test.txt", FileMode.Read)) {
}

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

すいません。できました。ぜんぜんわかってませんでした。

>414
入門するようなもんじゃねぇだろ？
C# を先に勉強した方がいいぞ

このスレでC#を勧めるのはどうかと思う。

そうか？　基本的にC++/CLIのターゲットは、今までC++をやってきた連中が .net
Framework を自由に使えるようにと言うことだろ
表面的な文法なら、ref や generics にプロパティ、delegate ぐらいしか増えないわけで
今までC++をやっていたのであれば、それほど大した変更じゃない
問題なのは、.net Framework を使えるか、それをC++/CLIではどのように融合させたのか
という点だから、それは入門じゃないだろ。C# の入門書見て、C++/CLI の構文での使い方を
知れば、十分なんじゃねえかと思われ

ダイレクトに C++ を知らずに、C++/CLI に手を出すのは、止めた方がいいだろ

>>422の言ってることは確かに理解できるし、俺もほとんど同意だが。
ここはC++/CLIについて語るスレなんだよなｗ

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

_asm{} とか書いたらどうなるんだ？って思ってやってみたら、
さすがに main() の中に書いたら怒られた。
関数単位でマネージド、アンマネージドが切り替わるんだね。
_asm{} 入りの関数はネイティブコードとして生成されるみたい。
その呼び出しをうまい具合にやってくれるのがいいね。
いや、C++/CLI で _asm{} 使うような機会があるかどうかは別として。

>424
C++/CLI の拡張構文ではグローバルな関数の存在を認めていない
だから、ただ関数を生成しただけでは、基本的にネイティブとしてコンパイルされる
はずだよ。main はさすがに扱いが違うけど

ふと思ったんだが boost on C++/CLI なんて可能だろうか。
ていうか、だったら素直に .NET Framework にある
便利クラス使えよって気もするが。

アセンブリ内で閉じてるなら平気だろ
CLI 拡張部を使わなければ、標準のC++であることが C++/CLI の設計コンセプトなんだから
できない理由はない。聞く前にやれば？

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 スキップ ==========

if ( Windows::Forms::DialogResult::OK != openFileDialog1->ShowDialog(this) )
return;

こうしました＞＜

Ｃ＋＋／ＣＬＩやりたいやつが入門サイトを希望するなんて
ギャグ以外の何者でもないだろ。

CLIマッシーンってどんな環境を目指しているの？
そのうち出るかもしれない3DのUIとか検索ベースのFSまでのつなぎかな？？

いつかでるLISPマシンまでの繋ぎです

>C++復権すると思う？

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

>433
どっかの記事では1990年代は優勢とか、書いてあったな。

C++/CLIのライブラリは　.NET　のライブラリをそのままISO標準にするの？？
以前のライブラリを使えるのはいいけど、できればGCで楽したいなー。

1990年代の段階ではC言語の仕事ばっかりやらされていたな。

>>433
Java/C#なんかが出てくる前は優勢だったと言えるだろう。
ただしベターCとしてしか使われなかった割合も大きかっただろうが。

delegateとeventの違いがわかりません。
delegateだけでいいような気がするのですが。。。

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

delegateを簡単に扱うため

＞＞439
センセー！簡単になる場面が思いつきません＞＜

event なら delegate の呼び出しが外から出来ないでしょ

>>440
うるせーな。少しは自分で考えろ。
delegateは関数オブジェクトの取り扱いの簡便化ため。
eventはdelegateの呼び出しの簡便化のため

>>438
つか比較すること自体が変だ。
delegateは型、eventはメンバ。class(型)とメンバの違いが分かりませんって
言われたってこっちが説明に困るよ。

>>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初心者なのではずしてるかもしれませんが。

あ、上のコード例はC#です。

event がないと AddListner やら RemoveListner を自前で実装せにゃならんのさ

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

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

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

＞＞４４６
delegateにも += や -= はあるです。

＞＞４４７さんありがとう
即答できないので、調べてみます。

>>448
delegate をそのまま公開しちゃうと呼び出しが外から出来てしまうのが問題なのよ

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

.NETって使ったことないからよく分からないんだけど、
一度コンパイルしたものを、同じセキュリティーやらなんやらの設定の場合は
キャッシュしておいたコンパイル済みのコードを再利用することって出来ないの？
毎回毎回、プロセス起動のたびにコンパイルしてるのってバカみたいじゃね？

キャッシュされるしngenもあるし

>>451ってバカみたいじゃね？

>>453
何だ、生意気だぞ。 (ﾌﾟﾝｽｶﾌﾟﾝ

プログラムのあちこちから大量にアクセスする文字列型を、
いちいちUnicode文字の配列からgcnewするのはもったいないと思って
あらかじめ生成しておいたSystem::Stringをグローバルに持つことで解決しようかと思いました。

が、普通にやったらコンパイラに怒られたので試行錯誤の結果以下のようにしてみました。
（StringDataはSystem::Stringを大量に生成して格納するクラス）


StringData^* gpStringData;

int main(array<System::String ^> ^args)
{
　StringData^ stringData = gcnew StringData();
　gpStringData = &stringData;
（以下メイン処理）
}


もうちょっと行儀のよさげな方法ないですかね？

こう？

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;
}

ごめんこのへん↓参考にして自己解決
ttp://www.microsoft.com/japan/msdn/practices/type/Patterns/enterprise/ImpSingletonInCsharp.asp

>456
今回の場合は、こちらの方法のほうがよさげですね
ありがとうございます

何というか、変態的というか。まぁ、それがC++の良さではあったわけ
だけれど。これではあまりにもコンパイラベンダ泣かせだ…可哀想に。

C++/CLI をフルに実装できるコンパイラベンダって、
MS以外にあるのかね？

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

すいません。質問があります。libpng.libなどを利用した昔のライブラリをC++/CLIで使おうとしたら、
コンパイル時に

libpng.lib(pngerror.obj) : error LNK2019: 未解決の外部シンボル __iob が関数 _png_default_error で参照されました。
libpng.lib(pngrutil.obj) : error LNK2001: 外部シンボル "__iob" は未解決です。

とか言われました。C++/CLIって_iobが使えないんでしょうか？
どなたか解決方法をご存じの方、教えてください。

Cの標準ライブラリlinkしてる？

ECMA-372ってISOになるときに内容が変更される可能性とかある？
ECMAは規格書が公開されるからいいけどISOはｼｮﾎﾞｰﾝだからさ。

一応、mscoree.lib msvcrt.lib msvcrtd.libはリンクしています。
あと、重複とエラーがでるので、libcmt.libはリンク無視しています。

開発環境はVC++ 2005 Express+PlatFormSDKです。
Win32プロジェクトだとlibpng.libを含んでもコンパイルは通るのに、
CLRプロジェクト(C++/CLI)だとうまく行きません・・・

VC++ 2005のstdio.hに_iobが定義されていないのが問題なのでしょうか？
(関係ないかもしれないけど)

libpngをソースから作り直したほうが早いよ。
zlibとlibpngのソースをDLしてdswとかslnとかを開いてビルドするだけ。
やったらWindows フォームアプリのプロジェクトに問題なく使えた。
ml.exeがVCExpressにはないので$(MSVS8)\VC\binにコピーしておくこと。

ありがとうございます！
試してみます。

>463
ECMA から ISO に回された仕様書はただで公開しているよ

>>467
へぇ、ありがとう

value struct B
{
literal System::String^ var = L"abcd";
literal System::String^ var2 = var+L"1212";
};
var2でエラーが出るんだが...だめなのか。(整数型intとかだと大丈夫だったんだけど...)
リテラル データ メンバの初期化子は定数指揮でなければなりません

literal System::String^ var2 = var + "1212";
は確かにエラーになるね。俺も今確かめてみた。
literal System::String^ var2 = "abcd" + "1212";
これでも同じエラーになる。結局は + 演算子を呼んでるからだろうな。
literal System::String^ var2 = "abcd" "1212";
ならエラーにならなかった。
というわけで、マクロ使え。ってことだと思う。

>>470
literal System::String^ var2 = var;
でもだめみたい。
static ctorでの初期化が許容できるなら
literal -> static initonly に変更するか、マクロにするしかないですね...

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

ふむぅ initonly なんてのもあるのか。

ところで、Visual Studio 2005 いじってて思ったんだけど、
C# に比べりゃリファクタリングなんかの点で
C++/CLI は扱いにくいと思うんだよ。
なのでほとんどの部分は C# でかいてるんだけど、
どうしても C++/CLI で書きたい部分もある。
C++/CLI で書いたコードと C# で書いたコードの
相互連携って可能なのかな？

具体的には、技術関連の計算をやるC++の自作ライブラリ、
結構大規模なモノがすでにある。GUI をつけるために
今までは計算結果をバイナリファイルに落として、
それを C# で作った可視化ツールで読み込んでた。
だけどインタラクティブにしたいんで C++/CLI 使えば
いいかなと思ったんだが、今まで C# で作ったGUI部分と
C++で書いた計算部分は C++/CLI で結婚できるのかと。

C++の計算用DLLをC#から使えばいいだけじゃん

>>472
今までは C++ -> COM経由 -> C#
これからは C++ -> C++/CLI
.NETでは C++/CLI <=>C#

>>473 C++な計算ライブラリの方は、クラスへの参照を
受け取って処理結果をその中に返すんですが、それでも
可ですか？ソース提供が基本のライブラリだったんで、
DLL化とかはしてなかったんですが、試してみます。

>>475
refタイプでない普通のクラスはrefクラスでラップする必要がある。ダイレクトには渡せない。

>クラスへの参照を受け取って処理結果をその中に返す

可能だろ。

参照クラスを値クラスに変換する
template等は用意されているのでしょうか？

ｷｲﾀ?( ﾟдﾟ)ｵｸｻﾝ(ﾟдﾟ )ｱﾗﾔﾀﾞﾜｧ

C++/CLI が次の VS まで生き残ってるか、かなり不安。
とはいえ、C++/CLI を結構使ってるけど。

C#→C++への変換ってできんの？

そりゃいくら何でも無理だろ。

>>481
ｺﾝﾊﾟｲﾙ→.net reflector

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
{}
};

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());
}
};

こうかな？自信ないけど。

二項演算子で単項で使われていなかったものオンパレードですね

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 外した

GCC の仲間に C++/CLI コンパイラが仲間入りする日が
いつかやってくると思う人、いる？

ﾉｼ Java もコンパイルできてるんだから、CLI抜きでやっちゃいそうな気がする

>>489
おまい、それ普通のgcc。

mingwで構造化例外って実装されてるの?

>>487
なるほどconstはずしたらできました。
ありがとうございました。

>490
ああ、実行エンジン無しで作っちゃいそうな気がするってこと

CLRのこと?

ランタイムはコンパイラコレクションが
提供しなくてもいいんじゃない？

GCC で CIL を出力するだけじゃ意味がないから、exe を実行するときバインドするの実行
エンジンはCLR か mono に頼るの？

>>496 そうなるだろうなぁ。
mono の mcs の方が C++/CLI コンパイルできるように・・・
ならないだろうな。

mono ではすでに ASP.NET はいい感じで動いてるんだったっけ？
Java の牙城をちょっとは切り崩すことが出来る、のかな？
って、Webアプリケーションは PHP でしか書いたこと無いんだけど。

monoって実行ファイル起動時に外部エンジンにアタッチしてやりとりできるいい仕組みって
ある？　Java の JNI で C/C++ から VM 叩くようなヤシ

DLL の呼び出しと同じ仕組みが使えた気がする。

以前、コンソールアプリをポータブルに作ろうと思って、
ncurses ライブラリを使って C# コンソールアプリを作った。
ncurses の DLL を C# から呼び出すようにして。
それは Visual Studio .NET 2003 で作成。

で、ncurses の共有ライブラリが入ってる Debian に、
VS でコンパイルした *.exe をそのまま持って行って、
何も考えずに mono で実行したらちゃんと libncurses.so
とかその辺をダイナミックリンクしてくれてあっさり動いた。

http://pc5.2ch.net/test/read.cgi/tech/1020215602/21
の兄弟の片割れが漏れなんだが(もう一人は誰か知らん)
その詳細なリポートを書いた mono の前スレが見れん。

それはそうと、JNIって「C/C++ から VM 叩くようなヤシ」か？
漏れ JNI は使ったことないんだけど、逆じゃね？

つーわけで、CLI からは DLL と同じように so が呼び出せると思う。
かなりオープンというか、なんというか・・・

連投ごめん。リンク間違えた。
http://pc8.2ch.net/test/read.cgi/tech/1100616350/21 ね。

>501
JNI は Java からの C 呼び出しと、C/C++ からの JVM 呼び出しの両方を規定してるお

>>501 お、そうか。スマンコ
ネイティブコードからの呼び出しは正直シランコ

ええっと、長年Cオンリーでやってきたロートルなんですが、
新しい（？）ポインタの^に関して、詳しく解説した書籍とかありませんでしょうか？

char型の文字列は 文字が１文字ずつ入っていって、最後が\0になっているという、
アセンブラレベルからするととてもわかりやすいものだったのですが、

String^ s = "0123456789" が、メモリ上にどの用に格納されるのか
さらに、この文字列に対して、
char c,*p ;
p=s;
c = *(p+10);
といった、従来のメモリ上のキッタハッタが出来なくなってきているのは、どういう仕組みなのか
を理解したいのですが。

managedなだけよ

>>506
JavaやLispやCLIの実行環境がどうなっているか調べろ。

>>508
それを詳しく解説した書籍とかを訊いてんだよ、ボケが。

そんな怒らないでよ(w
これ読みなよ、日本語はいいのがないから。

Shared Source Cli Essentials
http://www.amazon.co.jp/exec/obidos/ASIN/059600351X/

>>506
C++のclassは理解してますか？
class objectを指すポインタと思えばよいかと。

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' のメンバではありません。
}
};

generic -> template
にしたら通りました。
generic の typename は Object前提になるのかな

Reflectorでみてみたら
generic で宣言した方はパラーメータが残ってた、 class_name<T>
TはObjectを想定してるので、パラメータが残せてるんかな...
templateの方はパラメータが固定されてた -> class_name<int>

単に、マネージドとネイティブの混合型になるから駄目なだけ

>515 は違った。genericsは背景型が System::Object型であることを前提としており、
コンパイル時では閉じない限り、型が確定しない
そこら辺が、文字列置き換えの template とは性質が違う

>>516
なるほどなっとくしました。
ありがとうございました。

System::Collections::Generic::IEnumerator<T>
などでcovariant return valueが発生したときはどうしたらいいん...orz

つーか、512よ。インターフェイスで拘束されているわけでもない不定の FN 型の fn
のメソッドが呼び出せるわけないだろ？

>517 は具体的な例でしてくれないと状況がわからん

>>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();}
};

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(); }
};

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();}
};

managed C++ やろうぜ！！ 002
ttp://pc8.2ch.net/test/read.cgi/tech/1139043535/l50

ref classのメソッドでEnumWindowsを使おうとしてます
コールバック関数をクラスのメソッド、LPARAMをこのクラスのポインタとしたいのですが
いい方法はありますでしょうか?

値型だとインターフェイスからしか派生できないから
521の手法使えないね...orz

値型なら
Type<int,Type<int,int> >と記述できたのに
Type<int,Type<int,int>^ > または Type<int,Type<int,int>^ >^
とするしかないか...orz

>>523
P/Invokeの場合にはcallbackにはdelegateを使うんだっけな。
C++/CLIの場合はコールバック用のクラスとメソッドは普通のclassで作って
ref classに包含したほうが楽だ。

>523
過去ログにがいしゅつ

>>525
ありがとうございます
チャレンジしてみます。

delegateとコールバックで検索したら見つかりました
http://www.microsoft.com/japan/msdn/library/default.asp?url=/japan/msdn/library/ja/cpguide/html/cpconusingcallbackfunctions.asp

generic parameterからgcnewできないと思ったら
new制約なんてあったんだね。
C#にあるみたいなんで試してみたらできたよ。

generic <typename T>where T : gcnew()
ref class A
{A(){ T t = gcnew T();}};

System.Windows.Forms.ShowDialog()をした時にタスクバーに
Windowが追加されちゃいます
タスクバーに出てこない方法ってりますか?

>>530
ShowInTaskbar

>>531
さんくす！

C++ﾌﾟﾛｸﾞﾗﾏｰには二種類いるわけ。
C++をﾍﾞﾀｰCとして使う人とC++の機能を目一杯使う人。
俺はﾍﾞﾀｰC派なんだな。
C++の機能は必要最小限しか使わない。
特に枯れてない最新技術はまず使わない。
そして必ずGCをかます。
これは俺というよりも会社の方針なんだわ。
実の所、C++を完璧に使いこなせるPGはほとんどいない。
皆、言語の一角に住み着いてﾌﾟﾛｸﾞﾗﾐﾝｸﾞする。
これが大規模な開発になるとﾃﾞｽﾏの原因になるんだな。
ﾃﾞｽﾏを防ぐためにあえて制限を設ける。
俺は会社の方針は正しいと思っている。

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; } }
};

sage

Equals を使うな。使う事を推奨するな。
http://www.ailight.jp/blog/kazuk/archive/2006/01/31/11043.as ...

>>536
リンク修正
http://www.ailight.jp/blog/kazuk/archive/2006/01/31/11043.aspx
http://www.ailight.jp/blog/kazuk/archive/2006/02/01.aspx

ようするにさらし上げ?

>>534
setするほうのプロパティを作ればよいだけではないのか?

>>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;と書けるが変更できない

海外の大御所がある雑誌で言った。

「私はもう二度と .Net の記事を書かない。」

マイクロソフトにだまされてる奴ら、お疲れ。

>>541
大御所が誰だか教えて

プラウガもC++/CLIやってるけどな。
http://www.dinkumware.com/

やつらはVC++用ライブラリにたずさわっているし、
C++/CLIはEMCAの標準化に関与しているから。

まあC++/CLIはいい言語拡張と思わないけれど、
managed C++の将来のなさには流石に脱帽。

将来も何もmanaged C++はC++/CLIまでの暫定版なんだから、
managed C++の将来はC++/CLIじゃないか。
managed C++は OldSyntaxだべさ。

どれかひとつ選ばなければならないとしたら不本意ながらC++/CLIを選ぶしかないわな。

レヴューリリースだわな、managed C++は。

正直、記憶力がおいつかない。

でも、サービスパックも出てない VisualStudioを使うほどバカじゃなし。
MS製以外でコンパイル通るヤツってある?

>>548
無いよ。バカ

バカじゃん

おまえら、VS2005マジで使うの?　バカじゃん。
すでに、MSはSP出荷を確約してるんだぞ。

>>551
じーっと枯れるのまってろこのうすらタコ！

>>548
VB6でも使っとけよ wwww

>>552
N88 BASIC

バカが3匹。

Win32コンソールアプリケーションの

int _tmain(int argc, _TCHAR* argv[])
は
int main(int argc, char* argv[])
にしちゃいますけど。いいですよね？引数がアルファとかヌメリックなら。

漏れは
int main(const int argc, const char* const argv[])

>>557
そこまでいくなら戻り値もconstにしてはどうか？

>>558 参照返しじゃないから意味なし。

>>559
ああ、確かに意味は無いなｗ

でも、argcもconstにしてるけど、これも意味が無いから、
それをさらに徹底させるって意味で返り値もconstにすればいいのにー
っと思っただけ

argcの場合、意義はともかくプログラム上の意味が変わる。

うっかり書き換えるとコンパイラにゴルァされるとか

確かに関数内では意味が変わる...か。
関数のオーバーロードでは同一視されるから一緒と思ってたけど、
内部の事は忘れてた。thanks

>>558 お前素直な奴だな

そこでconst_castの登場だな

全部ILで書こうぜ

遅いからヤダよ。

STL/CLIお蔵入り

固定長配列はcli::array以外に用意されてない？

>568

STL.NETは別途配布されるんじゃなかったの？

BOOST.NETも出たりとか。
正直大混乱。

正直いってWinXPのSP2入れたくないからとかいう理由で
SP1を使ってる馬鹿と同レベルの理屈だな

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

>>571

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

>>572

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

値型にデフォルトコンストラクタと代入演算子を定義できる
.NET言語ってあるんかな？

フレームワーク内のprivateないくつかの構造体を見ると、
デフォルトコンストラクタ使ってるのがいくつかあるな。

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

>>575
つIL (ilasm)
まぁぶっちゃけいらないっていうかあってもまずやっちゃいけないしな

>>576,577
どうも

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

こんな感じで試してみようかな...
ttp://www.gdncom.jp/general/bbs/ShowPost.aspx?PostID=40822

やってみたけどよくわからんかった。でも
templateの部分特殊化でCLI型が使えるみたいだから、それでcreateすればいいか.

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

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

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

C++/CLIは便利だと思うが、棲み分けに失敗した感じがするな。
C#で統合するはずが、C++/CLIで統合されるとは…。
本当は.NET対応はC#だけでよかったんだと思う。

>>580
managedなobjectをどう扱いたいかによるだろ?

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

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

おまえら、どのエディション使ってるの？

>>582 うむ、いっていることは分かる。
まさに数値計算して可視化、ってのは仕事で必要。
しかも膨大な数値計算用のライブラリ(自作+他作)がすでにある。

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

C++/CLIは、CLIに頼らなければいけない時だけ、
managedなコードを書かなければいけないC++だろ?

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

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

>>585
> managedなコードを書かなければいけないC++だろ?

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

>>585 ふむ、いわれてみればそうだな。
俺があまりにも boost 依存なコードを書きすぎていただけだと思う。

>>581
いろんな言語が使用できるっていうのが.NETのうたい文句のひとつだったから
C#だけって言うのはいただけない

馬鹿はスルーしる

.NETって実際複数言語で開発してたりすんの？

>>590 俺はドトネトは C# しか使ってないけど、
俺が使ってるアセンブリが C++/CLI や VB.NET
で作られているかどうかは知らない。

VC++はVC++で作られていますという件はもはや過去のもの？

「ドトネト」って言う呼び方はアンチっぽいからやめてくれ

エロビデオのネバスペみたいなもんか。

Win32APIなどのネイティブ呼び出しをC++/CLIでラップしてあとはC#で開発してる。
windows.h の関数や定数の定義をそのまま使える上にInteropで呼び出しも高速なので
P/Invokeよりぜんぜんいいよ。

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

>>595
狂おしいほどに同意
アセンブリの中にネイティブコードを突っ込めるから
逆コンパイルにも対抗できるし。

そんなことしたら64bitでそのまま動かないじゃん

>>597
32bitで何か問題でも?

C++/CLIがNativeとManagedの混合アプリを作るのに優秀なのは理解できるが、
/clr:safe なアプリをあえてC++/CLIで作ることに意味があるのだろうか。

>>599
特になし。C++/CLIはC++使い慣れてる(C++ライブラリを膨大に抱えてる)人を
.NETに繋ぎとめておくためのもの。

2003のWin32APIやMFCを2005ExpressEditionで使おうと
頑張ってみたが無理だった。
Win32APIはコンパイル通るけど警告出るし、
MFCに関しては全くお手上げ。

>>601
WinAPIは2003から持ってこなくても最新のPlatform SDKを入れればいいだろうに。

C++/CLIはVB.NETで作ったクラスライブラリを呼び出すことも可能？

可

>>602
最新のSDK持ってきたら、警告なくなったよ。ありがと。

managed C++ みたいに C++/CLI もやっぱやーめたなんてことにはならんだろうな？
前者はなんか標準化団体には出されてたんだっけ？後者はだされてたよな？

>>605
感謝は言葉ではなく物で示せ。

>606
今、ISO で標準化の審査中

>>608 それは C++/CLI だよね？
もう Managed C++ はいらんでそ。

(1)for each( int obj in v)
(2)for each( int^ itr in v)
(3)for each( int% r in v)

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

>>609
http://www.ecma-international.org/publications/standards/Ecma-372.htm
これがISOに提出された。まあISOになる可能性はないと思うけれど。

>>611 あれ？ないの？

CLI 自体はすでに ISO 標準になってるんだよな。
Java VM も ISO 標準にすればいいのに。
Java 言語とは切り離して。

で、ISO 標準て何の役に立つの？

ネームバリュー

実質を無視したネームバリューなら、
Java >>>>>>（壁）>>>>>> Ｃ丼（I$O）
だね。

>>616 実質的なネームバリューだと思うけど。

>>616
Java のネームバリューってかなり実質的なものだと思うぞ。

>>613
EMCAの時に、J2EEも同時に採用されることにこだわった。
当時は、IBMその他ベンダーが独自ビジネス向けフレームワークの覇権を争っていた。

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

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

>>618
確かにJavaはネームバリューだけだな

ドトネッツは実質ＮＯ．１










（ベーパーウェア部門）

>610
vの中身を書き換えたいときは、必然的に(3)
(1)と(2)でコンパイル結果に差が出るかは知らんが、同じなら(2)の方が他の参照型などと統一性が採れると思う

int^ だとボックス化のコストが高くない？

>>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
}
};

>624
何を悩んでいるのかよくわからん
列挙する型に合わせれば良いんじゃないか？
適材適所だろ

^うざ

よーく見ると、顔に見えてくる。

VS 2005 C++だす
×　String str = "Hello";
○　String ^str = "Hello";
いちち^付けないといけないみたいですね、
^ってどういう意味ﾃﾞﾂｶ

>>628
C++/CLIに於けるポインタ

そっか、それで
*を^に変えろって困憊羅が言ってるの、見たような希ガスル
しかしなぁー、なぜ換える必要があるのかと、悩む事小10分
*アスタリスクはなんか他の用途でつかってるのかなぁ？？

こう覚えた方が早い
* を使っているのは C++
^ を使っているのは CLI 拡張

>>630
*のポインタ型同士はポインタ演算があるから演算子多重定義ができない。
^の追跡ハンドルならそのようなことがないから演算子多重定義ができる。

>>631
>>632サンクスです
GUIが使えるWin32でアプリケーションを作りたくて、NETや本を読んで
今学習しているところなんです、Visual Studio 2005 C++の
Win32コンソールアプリケーションを開いてボタンを押したら、
テキストボックスにメッセージを表示させたりとかして
動かしているのですけど訳も分からずに、CLIを使っていたんですね（；^ω^）
VS2005C++な環境でネイテイブなC++でコンソールアプリケーションは
作れないのでしょうか？MFCも挑戦しようと思いましたが、又別物のようですし
初心者的にはどの方向で進んだら良いでしょう、小一週間悶々としています

ｽﾏｿ
×　GUIが使えるWin32でアプリケーションを作りたくて
○　GUIで動作するWindowsアプリケーションを作りたくて

初心者ならC#へ行ってみてはどうかと惑わしてみる。
VS2005C++使った事無いけど、アンマネージド(ネイティブ)は作れるはずだ。

2005は普通に「Win32コンソールアプリケーション」でネイティブを作れるはずだが…
Expressだと違うのか？

>628
GUI でモノを作りたければ、素直に MFC に進んだ方がいいと思われ
C++/CLI はちと初心者にはお勧めできない。普通の方法では満足できなくなった玄人向け
だから
あとは、635 の進めるとおり、C# でモノを作ってみて満足できなくなったら、またこちらに
出戻ってくると言うのもいい

>>633
コンソールアプリケーションとテキストボックスのつながりがわからん

すんません、又間違えていました
CLRからWindowsフォームアプリケーション作成でした

他スレから誘導されてきました。

C++/CLIを使っているんですが、
自分のクラスライブラリのシングルトンのクラスにあるSystem::Drawing::Size型のプロパティを変更しようとしたら
p->Size = System::Drawing::Size(64, 64);
と設定はできるのですが、
p->Size.Width = 64;
のように個別に設定しようとしたら必ず0になってしまいます。

どうすれば個別に設定できるようになりますか。

投稿して気付いたのですが、Sizeの部分をハンドルにしたら設定出来るようになりました。
何故かがわからないですが・・・。

スレ汚しすいませんでした。

>>641
System.Drawing.Sizeは型値だから扱いが面倒だのう。

>>633
スレ違い
http://pc8.2ch.net/test/read.cgi/tech/1131590396/

>>641
というかそれはあまりよろしくない。たぶん。

p->Size = Size(64, p->Sizte.Width);

としなさい(こういうCLRの常識みたいなのもいるから
また複雑なんだよな>C++/CLI)。

にゃー、コード間違いすぎ

p->Size = Size(64, p->Size.Height);

こう。

そんなんわからん奴はC#やJavaも微妙だろ。

>>646
…まぁな。実体の追跡もできないレベルだし。
C#はまだ動かないだけで安全だけど、こういうやつには特にC++は使わせたくない。
メモリ関係のバグ大量コードを書く。しかもそういう場合デバッグビルドだと動いたり
することもあるから性質が悪い…。

Visual C++ 2005 Express Edition の環境で、はまってしまい、皆さんのお知恵を拝借したいです。

Webのダウンロードなのですが、
方法1
　　WebClient^ wc = gcnew WebClient();
　　Stream^ st = wc->OpenRead("http://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("http://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
　　　　]
　　　　この変換を実行可能なユーザー定義変換演算子がないか、または演算子を呼び出せません。

とあります。
バイト配列に入れたいだけなのに。

>>648
WebClient::DownloadData()の戻り値の型はcli::array<unsigned char>^。
Encoding::GetString()の引数もcli::array<unsigned char>^。

^　←なんかコレうざい。よくわからないけど腹立たしい。

(^^:

^<T>^

>>649
Byte を cli::array<Byte> にしたところ、できました。

cli::array<Byte> ^ myDataBuffer = wc->DownloadData("http://www.yahoo.co.jp/");
Encoding^ enc = Encoding::GetEncoding("euc-jp");
String^ out = enc->GetString(myDataBuffer);

ばっちりです。これで先に進めます。

つい最近まで C++ Builder 使いだったので、いろいろと戸惑ってます。
ポインタは使えず、^ というものが必要だとわかるまで、延べ1日くらいかかってます。
勉強がてら少しずつ移植していきます。

どうもありがとうございました。

>>650
呼んだ?

>>650
あなたの心が汚れてるからですよ(^^;;;

そんなばかな^^;

>>650-652
ヤベ、ツボにはまったｗ

>>422-423
＞ダイレクトに C++ を知らずに、C++/CLI に手を出すのは、止めた方がいいだろ
＞さっさとC#かVBで始めたほうがいいと思う。

とりあえずＣ＃で始めようと思った矢先、C++/CLI とかいうのが目に入って、
「ファイナライザいいな」とか思ってしまったんですが、
やっぱりＣ＃から始めることにします。

>>424
関数単位ですか。
つまり、関数呼び出しを共通化することで様々な実行環境にあるコードを一つのプログラムにまとめることができたと言うことでしょうかね。

>>658
ああ、C#にしたのか。まぁそうしとけ。C++/CLIはネイティブの知識(C++)とCLRの
知識(C#)が両方要求されるひどい言語だ。最低限どっちかぐらい自由に使える
ようになってからおいで。…両方自由に使えるぐらいじゃないと使える言語でも
ないかもしれないが。

ファイナライザ？C#にもあるぞ。というかCLR用語だそれ。
まぁDisposeがスタックオブジェクトのように書けることをいいたかったんだろうけど。
川俣とかが取り上げているほど、たいしたものじゃない。あの人は大げさに書く文体
が売りだからな。いい悪いは別にして。

通のお勧めは関数のオーバーライド
ディスポーズ・パターンの変形に目が眩んでちゃ、まだまだ

>>660 ポリモにならんじゃん

>>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されるわけではない。

!hogeなんてあったんだ

>>662
いや、えーと、このスレにいる以上知っている。
ildasmでも確認したしな。ああ、そうか、それをC++/CLI用語でFinalizerというのか。

>661
おまいはC++/CLIにおける関数上書きの奥の深さに気付いていない

ここに IEnumerable を継承したインターフェイス IEA と IEB がある
その双方を実装した ref クラス RAB は明示的オーバーライドによって列挙の方式を
IEA と IEB によって変更できる
つまり、RAB から取得したインターフェイスによって、for each のオーダーを自由に
選択できるわけだ

MSがC++/CLIを捨てるのは何年後くらいですか？

MFCの如くこの劣悪貧を１０年使うかも。
C++ってだけでもSTLやBoostが混ざってくると複雑なのに、正直CLIはカンベンて感じだおね。

>>667
駄菓子菓子、これがないとネイティブとかからCLRが非常に使いにくい。
ほら、次でWPFとかなんかたくさんあるし。

マイクロソフトがもうｲﾗﾈと思ったら容赦なく捨てにくるさ。

>>669

そりゃ日本だけ。海外ではVBerが反乱おこして、msも今では Love VB, Love C#だとよ。

C#は、VC++とVBの中間を行くような言語だから、
どっちからも反発が強いだろうね。

反発はしないけど、C++で出来るなら C++ Nativeでやっちゃうよ。
必要なとこだけ CLIで .Netなんてライブラリ感覚で使えばいい。

/clrでNativeコンパイルすると遅くなる？

>673
>348

>>669
要るだろ。

だって、C++市場をCLIで混乱させることにより、
開発者をWin＠ﾌﾞﾋﾞ or Win＠Ｃ丼で留めておける。

>>674

遅くなるのは事実としても、何で遅くなるんだろ?
異なるライブラリがリンクされるからか?　lstrcmp自体の実装が異なるのか?

それとも呼び出し時にスタックチェックでも入ってるのかね…。

>676
単純なループでは簡単に結論が出ない問題かもしれない
ちなみに漏れの環境では
CLR 6 - 7 sec.
Native 8 sec.
となった。意外だがCLRの方が早い
Win のほうは -02 -0t を付けた状態で、CLRの方はデフォルトのリリースモジュールだ

>>670
そんな話しきいたことネ

誰か、C++/CLI で吐いた実行ファイル、
mono で動かした奴いる？？

以前 VS.NET 2003 の C# で書いたコンソールアプリなら
mono で動かしたことあるんだけど。

mono がそもそも .net framework 2.0 に対応してたか？
してるなら、/clr:pure で動くだろう

nullptr

ｶﾞｯ^

>>678

http://blogs.msdn.com/hiroyask/archive/2006/02/13/530769.aspx

ケツの穴が広がるぐらい、ハードに読めや。

>>683
良く読んだよ

>表の顔の日記　

> 裏の顔の日記
> さっさと消えてくんないかな。 うざいんだけど、 まじで。

という電波でも飛んでるのか?

また教えてください。

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型の配列の定義がしたいのですが、マネージ環境では、どのようなやり方があるでしょうか?

typedef struct → typedef value struct
では？

>>687
そうです。コピペ間違いました。

value struct HOGE{
　　int x;
　　int y[4];
};

と記述してます。

・・・value型使わず、ネイティブ型で定義すれば？

あとは ref にして array<long>^ y で宣言して、コンストラクタで初期化するか

value struct HOGE
{
　　int x;
　　array<long>^ y;
};
はコンパイルが通るが、仕様上これでいいのか？

ok
ハンドルは nullptr で初期化される

皆さん、早速のレス、ありがとうございます。

>>689

ネイティブで定義すればできることは確認してます。
ただそうすると少し複雑なソフトを組んだ場合、きちんとメモリの後処理をしないと
メモリリークが発生するので、マネージにすればメモリガベージの効用であまり複雑に
考えなくともよいかな、と思っているのです。

>>691

そのやり方もわかります。

各関数で、
void func1(void)
{
　　HOGE wk1;
　　wk2.y[2] = 123;
}

void func2(void)
{
　　HOGE wk2;
　　wk2.y[2] = 456;
}

というようなことをしたいのです。

2〜3日あがいてみて自分ではできなそうだったら、ネイティブで定義してやっていきます。
マネージ環境に慣れていけば、そのうち、何か気づきがあると信じて進むしかありません。

2〜3日あがくなら2〜3日かけてマニュアル読んだほうがいいような気がする

>>693
値型にGCを求める必要がある？

C++/CLIのスレ見てると無意味にvalueを使いたがる人が多い気がするな。
valueは動作に癖があるから基本refで作ったほうがいいと思う。

value使ったほうが処理速度が速いとでも思い込んでいるんじゃ？
クセがあるには同意。

いろいろとサイトをまわりまして、以下のようにしたところ動いているように見えます。
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]);
　　}
}

検討違いのコードでなければよいですが。

みなさん、いろいろとレスありがとう。

>>698
これでも平気。
void func()
{
    HOGE abc;
    abc.x = 10;
    abc.y[2] = 20;
    for (int i = 0; i < 4; i++) {
        Debug::WriteLine(abc->y[i]);
    }
}

C++は真のローカル変数を使える言語なんだから、（ユーザー定義オブジェクト
がスタック上に配置できる）GCが必要な場合ってのはそんなに多くはならない
ってビョーン先生が言ってた。

>>700
それはわかるけれど、C++/CLIはCLIの世界にあわせないといけないからさ。

C++/CLIは二つの言語が同居しているようなものだからな。
C++の拡張というより建て増し。

>699
それだと、配列のサイズが3で固定されちゃわない？

>>702
二世帯住宅

ビョーン先生が取り扱っている案件はそうかもしれんけどな。
動的にオブジェクトが増えたり減ったりする案件のほうが多い。

>>700
しかしビョーン先生はGCをそんなに否定していない。
既存のC/C++のコードと互換性を保ったまま導入できるのなら、
C++に入れてもいいというようなことをD&Eで書いている。

>>705
vector使えばええやん。メンバかローカルにしておけばdeleteいらん。

>>707
グローバルでもdeleteいらんぞ

別に GC なんて C++/CLI の利点じゃないだろ
単に .net framework を既存の C++ と混同することなく使えるってとこが一番重要さ

C++/Smalltalk とか C++/Squeak とか出てこないかな

【初心者歓迎】C/C++室 Ver.25【環境依存OK】から誘導されてきました( ｀・ω・´)ﾉﾖﾛｼｸｰ
VC8でopenFileDialogを使いたくて
MSDNのソースを試してみようと
ttp://msdn2.microsoft.com/ja-jp/library/system.windows.forms.openfiledialog.aspx
説明を読み
フォームに 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' : 定義されていない識別子です。

>>710
System::Windows::Forms::DialogResult::OK とフルで書く。

>>711
最後まで仕様が揺れた所かも知れないね。

この状況って System::Windows::Forms まで using で指定しているから、単純にグローバル
スコープ指定していることが問題なんじゃね？
12行目の ::DialogResult を意味なく、:: で始めるな、と

>>713
ところがどっこい
DialogResult::OK　と書くと今度は
System::Windows::Forms::Form::DialogResultが無いというエラーになる。
using namespace は探しに行ってくれないらしい。

ん、サンプルだと :: で始めてるな
っていうか、>710 って名前空間 System しか宣言してないって言ってるが
using namespace System::Windows::Forms が宣言されている環境では
::DialogResult::OK でエラーなくコンパイルできるな

先頭 :: の名前検索ルールって、グローバル指定じゃないんだ・・・

>>714
using namespace System::Windows::Forms;
してあるということ? その"Form"は何よ?

>>715
namespace N { int x; };
using namespace N;
int x;
int f(void) { return x; } ←このxはambiguousになる。それで正しい。

まず、 >710 の問題は、単に System::Windows::Forms が using 指定していないから
using namespace System::Windows::Form;
を付ければおっけー

>716
::DialogResult ってなっているから、先頭に :: を付ける場合ってグローバル名前空間の
名前空間指定だと思ってた。カレント解決してくれるんだ

>>717
いや、「正しい」はグローバル参照の方。

> using namespace System::Windows::Form;
> を付ければおっけー

Forms

ということは、MSの実装はバグかMS独自仕様か、微妙なとこだな

皆さんどうもありがとう、遅くなってすみません
今帰宅しました

ヘッダー部分ですが
#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' : 属性が見つかりません。
とこんな感じで、
ﾜｹ 川・∀・川 ﾜｶﾒです

>>720
その一
using namespace ...
using namespace ...
namespace hoge {
と順番を変えたら ::DialogResult::OK でコンパイルが通る。

その二
hoge::DialogResult::OK　 でコンパイルが通る。
恐らく下のも通るはず。
[hoge::STAThreadAttribute]

その三
namespace hoge {　を使わずすべてGlobalに書く

これが仕様なのかバグなのかは俺にもわかんね〜

気になって少々試してみたが、関数内で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)

ほとんど素のC++の話題になってるけど、まあいいか。
なんでDialogResultが重なってんだろ?

using ::System::Windows::Forms::DialogResult;
if (ofd.ShowDialog() == OK)
か
using ::System::Windows::Forms;
if (ofd.ShowDialog() == DialogResult::OK)
ならわかるけど。

>>723
C++/CLIの列挙子は列挙型の中のスコープにある。

>>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) 

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;も問題ない。

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にしても同じ。

>>727
CLRタイプのenum class と Cタイプのenumの２種類あって、
後者の話ならそのとおり。

皆さんのおかげで、openFileDialogを動かす事ができたのですが
肝心な事を忘れていました、ファイルを選択してボタンを押しても
実際にファイルが開かないんですよね（；^ω^）
// Insert code to read the stream here.
ってコメントアウトしてある部分が気になるけど、ここに何か
書かないといけないのかな？

教えてクンマンセー！

コメントが何のために有るのかわかってるのか？
っていうか読めよ。

>>731
英語読めません(´･ω･`)

>>732
んじゃ、英語の勉強から。英語書けないならともかく、読めないんじゃ
プログラミングなんてやってられない。

翻訳サイトも使えないようなヤツはプログラミングやめれ

ていうか、732は710の偽なんですが

俺は嘘つきだから俺の言うことは嘘ばっかりさ。さてこの嘘はホントかわかるかねｗｗｗ

そんなおもしろくないよ?

>>733
ひまわりが専門なので関係ないでしょ

ﾟ･*:.｡..｡.:*･゜ヽ( ´∀｀)人(´∀｀ )ノ･゜ﾟ･*:.｡..｡.:*
できた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();
}

C++/CLI の場合でも .NET Framework のサンプルがほしければ
C#やVBのをそのまま使えるってのに

|∀・).｡oO(・・・)
そうなのか？

ｶﾞﾝｶﾞﾚ

ﾑﾘｯﾎﾟ

>>740 うむ。
ちょっと間接参照の記述が違うくらいで、
流れは C# のコードのままでいいな。
まぁそれが C++/CLI の真骨頂でもある。

>>739
C++/CLIなんだからいちいちgcnewする必要はないと思う。

>>739
つかCloseもfinally句に書いてないし。
C#ならusing、C++/CLIならスタックオブジェクトにしろよなほんと。

で、STLはどうしてるんだ、おまえら?

C++/CLI でGUIなアプリつくるべ、と、フォームをデザインして
遊んでます。で、みなさん、アプリで必要となる大量の
変数たちは、class Form1 のメンバとしてずらずら宣言してしまって
構わないんでしょうか？

今までは UNIX 系でのコンソールアプリ主体で、自前の
アプリケーションクラスを用意して main() の中から
そいつをインスタンス化して、という感じでやってました。

Windows でのグラフィカルなアプリでの作法では、
自動生成された class Form1 にどんどんメンバを
追加しちゃっていいんですか？

当然イベントハンドラなどはデザイナで追加されていくわけで、
手動で追加したメンバのためにフォームデザイナが混乱して
しまわないかすごく不安です。

STLが無い、C++なんて。

クソ。

>>749 え？C++/CLI で STL つかえないの？

>>750
ネイティブ型に対しては使える。

そしてマネージ型対応のSTL/CLI(旧称STL.Net）がVC++ 2005と同時に公開されるはずだったのだが、
伸びに伸びて未だ公開されていない。

http://www.microsoft.com/japan/msdn/vs05/visualc/stl-netprimer.asp

いっそのこと俺たちで作るかｗ。

>>751 あ〜びっくりした。
そうだよな、ネイティブ型に対しては使えるよな？

C++ で書きためてきた std::vector 使ってる
数値計算用のライブラリがあって、どうしても
それから逃れられない + DirectX で可視化したい、
という要求があって、それ満たすには C++/CLI しか
ないだろ、ってことでこれから使おうと思ってたんで、
ちょっと焦った。

>>752
いやいやいや、お前DirectXをなんと心得る？

>>753 まだ、OpenGL のかわりみたいなもん、
くらいの認識です。頂点データの扱いとか
ぜんぜんちがうんですかね？
その話題はスレ違いですが。

目的は動き回る多数の分子模型の
ようなものなんですが。

DirectXはまだネイティブがメインなのにどうしてSTLの無いC++/CLIを無理に使おうとするのか

com::ptr 型がそこにあるから

OpenGLでもいいし。

>>755 いや、それすらまだ知らないんですよ。
普通に次元の可視化するときに、
フォームにぺたぺたとやってえらく簡単に
できたもんで、この勢いで 3D もいける？
とか思ったわけです。

>>757 いわれていれば、そうかも

>>758
そのノリでやりたいんなら(ビジネスっていうかグラフ化とかな)、
確かにマネージのAvalonが向いてる。けどもまだない。残念。

DirectXとOpenGLは例えばDirectXはCOMだったりとか細かくは違う。
けど理論はあんまり違わんので好きなほうでどうぞ。
一般的には凝ったことしなければOpenGLのほうが簡単。

スレ違いなんだが、VTKとかいろいろあるじゃん?

> フォームにぺたぺたとやってえらく簡単に
> できたもんで、この勢いで 3D もいける？

そんな子どもっぽい理由じゃなくて、(発端じゃなくて直線的な選択の事ね)
道具くらいちゃんと自分で選べるようになろうよ。
http://sal.linet.gr.jp/E/1/index.shtml でも漁れ。多くがWindowsもOK。
OpenGLやDirectXを直接叩くなんて馬鹿らしいよ。

>>760 THX

論文に貼る図だと、動画じゃないので普通に
gnuplot で作ってるんですが、プレゼンだと
やっぱ動かなきゃな、ってことで取り組んでます。
色々あるんですね、こりゃ楽しそうだ。

今晩も盛り下がっていますね皆さん( ノﾟДﾟ)こんばんわ
>>744間接参照の仕方を巧く解説してるサイトってない？
>>745newでは困憊羅君が、言うこと聞いてくれませんでした
>>746スタックオブジェクトって、なに？グラフや絵を描くメソッドのことかな？と聞いてみる
夕べ
ttp://www.athomejp.com/goldfish/vcs/openfiledialogreader.asp
ここのソースを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();
　}

>>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();
}
（続く）

これをスローカル変数を使うようにして、
個人的に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);
}

>>764
Debug.WriteLine に nullptr 渡すのってありだっけ。
}

>>765
どうみてもまずいですね。
本当にありがとうございました。

そう書こうと思ったけど、その前に試してみた。
System::Diagnostics::Debug::WriteLine(static_cast<String^>(nullptr));
全く問題なかった。

ついでに言うとそれ::にするの忘れてた。すまん。
結局こうすればよかったな。
while (System::String^ str = streamR->ReadLine())
{
    // デバッグ出力
    System::Diagnostics::Debug::WriteLine(str);
}

盛り上がってるところ済みません。
どなたか >>748 に答えてくださるかた
おられませんでしょうか・・・

>>763
解説Thanks ☆☆** v(￣ー￣)v**☆☆ Thanks

>>762
スタックオブジェクト＝auto変数

C++/CLIで

char *ptr;

ptr=(char *)malloc(sizeof(hoge));
free(ptr);

が使えるのに感動した！

>>767
シングルウィンドウのアプリケーションならそれでいいと思う。

質問させてください。
System::Collections::Generic::ListかSystem::Collections::ArrayListで
要素へのinterior_ptrを得る方法はないでしょうか。
ToArray()はコピーを返すのでだめでした。

>>772
ArrayList や　List では無理、固定サイズの配列ならいける。
array<int>^ x = { 10, 20, 30, 40, 50 };
interior_ptr<int> r =  &(x[3]);

VS2003のC++で書いた
int __pin* px = &pX -> x;
こういう、書き方はVC8では通らないようですね？

>>774
cli::pin_ptr<int> px = &pX->x;

>774
/clr:oldSyntax

おっすオラ悟空

C++/CLI コンソールアプリの main では
コマンドライン引数として String^ の array への ^ が
渡されるんだけど、今まで使ってたコマンドライン処理
ルーチンに int argc, char** argv って感じの
おなじみのアンマネージドな形式で渡したい。
簡単な方法無い？？？？？

>777
普通に int main(int argc, char**argv) で宣言すれば？
C++/CLI は CLI 拡張であって、旧来の機能がなくなった訳じゃない

おっす、オラ悟空
>>778 うまくいったぞ
これで boost::program_options がつかえそうだぞ

ところで boost のライブラリのうち /clr でビルドに
しっぱいするのは graph, test, wave みたいだぞ。
ほとんどは *.hpp だからビルド不要だけど.

おっすオラ悟空
もしかして C++/CLI ってすげぇ戦闘能力じゃねぇか？
スカウターが壊れちまったぜ

ゴクウがスカウターつけんなよ

じゃ、お前にやる

>>781
すげーﾜﾗﾀ

STL.Netが待ちきれなくて、System::Collections::Generic::ListのラッパをVectorという名で作ってみようとしたが、難しい。
クラスライブラリ化して他言語からも使えるようにとか考え出したら駄目だこりゃ。

CLIだとメンバにref object(ref ptrは可)
おけないからSTL.NETは
ptr_contenaみたいになるよね？

何処で聞こうかと迷いましたがここでお願いします
.NET Framework クラス ライブラリで
メール送信するSystem.Net.Mailというクラスがあるのですが
受信するクラスはどれですか？

Socket で imap か pop のポートに繋げてプロトコルながしゃいいんでない？

追加
ttp://mobiquitous.com/programming/apop-imap.html
ま、ライブラリとかもぐぐりゃ出てくるんだが

void func(const std::string & s); ってのは書けるけど
void func(const String ^ s); ってなふうにはかけないのね。

ハンドルは追跡ポインタだから const したら追跡できないだろ

>>790 ポイント先のオブジェクトを変更したくないよ
ってのを明示したかった。const な String へのハンドル、
って書きたかったんだ。

意味はわかるが、const の意味を拡張しない限りできんだろ
const や volatile は GCヒープには使えないと思わないとな

う〜む、渡された側で不用意に変更して
しまわないようにしたかったんだけどな。
マネージドなオブジェクトに対しては無理なのか。

普通にconst指定出来たが、何をもって書けないと言っているんだ？

>>794
「const System::String ^
　この型での const/volatile 修飾子はサポートされていません」

って、コンパイラが優しくおこってくれた。

コンソールアプリで確認したけど、エラーなんて出なかったが。

#include "stdafx.h"

using namespace System;
void func(const String^ s)
{
Console::WriteLine((String^)s);
}

int main(array<System::String ^> ^args)
{
func(L"Hello World");
return 0;
}

>>796 いいなぁ。
うちのコンパイラは出るんだ。
なんかスイッチの関係かな。
もうちょっと調べてみるよ。

それ、コンパイル警告C4400で、警告レベルは4。
どうやら漏れが警告レベルを一番高くしてるから表示されてるみたいだ。

const (C++) 修飾子および volatile (C++) 修飾子は、
共通言語ランタイムの型の変数では使用できません。
次の例では C4400 エラーが生成されます。
// C4400.cpp
// compile with: /clr /W4
// C4401 expected
using namespace System;
#pragma warning (disable : 4101)
int main() {
   const String^ str;   // C4400
   volatile String^ str2;   // C4400
}

いいなぁって、駄目だろ。const 指定できちゃ（ｗ

String^ hello = "Hello, World";
func(hello);

だとエラーだったりして

.NETの共通として通用しないだけで、
C++/CLI上では値を変更しようとするとエラーになるし、
特に問題はないと思うけど。

ちなみに>>800のも通った。

>>800
これが通るんだからそれが通らないわけが無いだろ。
void func(const std::string& s);

std::string hello = "Hello, World";
func(hello);

まぁそれ以前にあれだ、System::StringはImmutableなオブジェクトだ。
どっちにしろ変更できん…わけでもないけど裏技

private: System::Void button1_Click(System::Object^ sender, System::EventArgs^ e) {
　　pin_ptr<const wchar_t> text = PtrToStringChars(textBox1->Text);
　　//16進数に変換
　　wchar_t* pEnd;
　　unsigned long hoge = std::wcstoul(text, &pEnd, 16);
　　//入力されたデータの判定（省略）
　　wchar_t* foo;
　　foo=NULL;
　　//unsigned long 型の整数を文字列に変換
　　_ultow_s (hoge,foo,32,16);
　　String ^tmp=Convert::ToString(*foo);
　　textBox2->Text=tmp;
}

ボタンを押したらtextBox1に、入力した文字を16進数に変換し、データの判定を行い
再び文字変数に変換し、textBox2に表示させるという、プログラムです、
foo=NULL;を入れないと、: warning C4700: 初期化されていないローカル変数 'foo' が使用されますと、警告され
foo=NULL;としたらエラーは出ないのですが
いづれの場合でも、実行すると
Debug Assertion Failed!

Expression:buf!=NULL
とお叱りを受けます、どうしたらよいでしょうか？
ｵﾅｶﾞｲｼﾏｽ。

漏れには foo に割り当てられているはずの 16 wchar_t が見えないんだがどこにあるんだ？
MSDN で _ultow_s が領域確保してくれるのかどうかぐらい確かめろ

pin_ptr<Char> text = textBox1->Text->ToCharArray();

wchar_t* pEnd = 0;
unsigned long hoge = std::wcstoul(text, &pEnd, 16);

wchar_t foo[16];
memset(foo, 0, 16*sizeof(wchar_t));

_ultow_s (hoge,foo,32,16);
String ^tmp = gcnew String(foo);
textBox2->Text = tmp;

MSDN を読んで出直してこい

>>805ありがとう
出直す前に、ｽﾏｿ
unsigned longって32bitですよね、多分そのせいだと思うけど
9桁以上入力すると、結果がオーバーフローしちゃってffffffffに
なっちゃいます、予期せぬ結果です
wchar_tが16ビットのせいだと思うのですが、こんなときはどうしたら
いいのでしょうか、教えて君で申し訳ないですが御教授お願いします。

>>806
（VC++の）unsigned longは32ビットで0〜0xffffffffの数値を格納できる。
だから十六進法で8桁までだ。wchar_tに非は無い。
たとえばunsigned long longなら64ビットあるから十六進法で倍の16桁までいける。

>>806ありがとう
unsigned long
↓
unsigned long longにしてみたら
: warning C4244: '引数' : 'unsigned __int64' から 'unsigned long' への変換です。データが失われる可能性があります。
警告が出てしまい、実行するとやはり9桁でオーバーフローしてしまいました
手のほどこし方はもう無さそうですね、(´・ω・｀)

UInt32::Parseじゃいかんの？

>>808
32ビットしか返さない関数使ってるんだから当たり前だな

>808
だから、自分の使っている関数の方とかをチェックしてこいといってるだろうに
受け取り側を unsigned long long にしても、変換関数が対応していなけりゃ駄目だろ
おまいさんは文字列を 64 ビット長の整数値に変換したいんだから、それに対応した
変換関数を探してこい
>809 がいいヒントをくれているじゃないか
.net framework で 64ビット長符号なし整数値の型を探してそのメソッドを調べろよ

>>811どうもありがとう
>>806です
ttp://msdn2.microsoft.com/ja-jp/library/system.convert.touint64.aspx
Convert.ToUInt64 (Int32)
これでいいのかな？

・・・おまいさん、文字列を UInt64 に変換したいんだろう？
だったら使うべき変換関数は Convert.ToUInt64(String^) じゃないのかい
これなら、いちいち配列変換しなくてもいいわけだし
UInt64::Parse(String^) だってあるだろうに
もちろん、UInt64.ToString() とすれば、文字列への変換もできるぞ

C++/CLI は (3.14).ToString() ってやって文字列を取得することだってできるんだから

std::wcstoul を愛しているんだろうから、そっとしておいてやれよ

(´ε｀；)ｳｰﾝ…

unsigned long long hoge;
にすると
_ultow_s (hoge,foo,16,16);
ここで、
: warning C4244: '引数' : 'unsigned __int64' から 'unsigned long' への変換です。データが失われる可能性があります。
String ^tmp = Convert::ToUInt64(*foo);
とすると
: error C2440: '初期化中' : 'unsigned __int64' から 'System::String ^' に変換できません。
使用可能なユーザー定義された変換演算子がない、または
演算型のボックス化された形式からターゲット型への標準変換は存在しません
なんですよね、全くなにやってんだか・・・・

>>815
Convert::ToUInt64は文字列をUInt64(unsigned long long)に変換するほうだ。

がー！　だから、型と関数を考えて、ちゃんとメソッドを構成する英語を嫁と
UInt64 hoge = 0LL;

if ( UInt64::TryParse(textBox->Text) )
　　hoge = UInt64::Parse(textBox1->Text);

String^ tmp = hoge.ToString();

でいいんだって

なんでわざわざ wchar_t の配列に変換するのかな
ちゃんと、キーワードでぐぐるかMSDN見てる？

文字列を数値にするのには次のものがある。

Cのato〜とstrto〜。そしてそれぞれワイド文字版の_wto〜（非標準）とwcsto〜がある。sscanf/swscanf類もある。
C++のistringstream類。
.Net FrameworkのConvert::To〜と〜::Parce。

数値を文字列にするのには次のものがある。
Cの_〜toa、_〜tow（非標準）。sprintf/swprintf。この行のは全てVC8の_s版（全て非標準）もある。
C++のostringstream類。
.Net FrameworkのConvert::ToStringとObject::ToString。

ちなみにそれぞれ対称性がある。

C++のstream以外は全て数値の型により関数名などが異なっている。
だからunsigned longを使うかunsigned long longを使うかで違いが出てくる。

というか、unsigned long long int って型はまだ標準じゃないよな

>>819
C++にはまだないが、C++/CLIには存在する。
http://signe.japan.webmatrixhosting.net/ecma372/12_type.aspx

>820
それは知ってるが、標準関数が対応してないってこと
ってそこ直リンすんなよ

>>821
だからC/C++のunsigned long longが関係するところは全て非標準だな。

そだな。非標準の型は全部 CLI 型表記にした方がわかりやすいと思うんだが
変に今までと一緒なもんだから、間違えやすいんじゃないかな

それよりも混乱する原因はC、C++、.Net Frameworkのクラス・関数が入り乱れているからのほうが大きいと思う。
答えているほうだって、あれ使え、いやこれ使えって具合だし。

そもそも一旦十六進法の文字列へ変換するまではともかく、その後文字列へ変換する必要性がわからない。
そのままtextBox2->Text = textBox1->Text;でいいと思うのだが。
大文字小文字を揃えたいだけならtextBox1->Text->ToUpper()で十分だし。

>>817さん
どうもです
>>なんでわざわざ wchar_t の配列に変換するのかな
>>814さんの書いたとおり
std::wcstoulと_ultow_sの呪縛に囚われていました
こうやって見ましたが

private: System::Void button1_Click(System::Object^ sender, System::EventArgs^ e)
　　{
　　　　UInt64 hoge = 0LL;
　　　　if ( UInt64::TryParse(textBox1->Text))
　　　　　　hoge = UInt64::Parse(textBox2->Text);
　　　　String^ tmp = hoge.ToString();
　　}

if ( UInt64::TryParse(textBox1->Text))ここで
: error C2661: 'System::UInt64::TryParse' : 1 個の引数を伴うオーバーロードされた関数はありません。
こうなるのですが・・・

>>825
MSDN見ろ。
TryParseは2つ目に結果を格納する引数がある。

>>826さんどうもです
private: System::Void button1_Click(System::Object^ sender, System::EventArgs^ e) {

UInt64 hoge = 0LL;
　　if ( UInt64::Parse(textBox1->Text))
　　　　hoge = UInt64::Parse(textBox2->Text);
　　else
　　　　String^ tmp = hoge.ToString();
　　}
こうしたら、できましたが、実行すると
アプリケーションのコンポーネントで、ハンドルされていない例外が発生しまし。
中略
入力文字列の形式が正しくありません。

ust-In-Time (JIT) デバッグを呼び出すための詳細については、
ダイアログ ボックスではなく、このメッセージの最後を参照してください。
中略
************** JIT デバッグ **************
Just-In-Time (JIT) デバッグを有効にするには、このアプリケーション、
またはコンピュータ (machine.config) の構成ファイルの jitDebugging
値を system.windows.forms セクションで設定しなければなりません。
アプリケーションはまた、デバッグを有効にしてコンパイルされなければ
なりません。

>825
勘違いしたんじゃ、ないぞ。MSDNを見るようわざと間違えたんだからな
決して、名前だけで bool 値を返すんだろとか考えて適当に書いた訳じゃ、ないんだからな

>>827
MSDN見ろ。1つめの引数の文字列の書式が書いてある。UInt64::Parseは十進法しか受け付けない。
Convert::ToUInt64なら基数が指定できるけど、Try版がないから例外を受けるしかないと思う。

ｽﾏｿ
Try外していました
しかし、TryParseの問題を解決しても
例外エラーは出そうな感じがするんだが

>827
だから、MSDN で UInt64 のメソッドぐらいチェックしろと

そろそろ何をしたいのかがわからんのだが。自分が書いているコードの意味がわかってる？

textBox2 に textBox1 の内容をコピーしたいのなら >824 が言ってるとおり
textBox2->Text = textBox1->Text;
だけでいいはずだし、いったん、数字にしてなんかの検証をしたいのなら
なぜ、いきなり textBox2->Text から数値を取ってるんだ？

マジに書くと
if ( !String::IsNullOrEmpty() )
{
　　try
　　{
　　　　UInt64 hoge = UInt64::Parse(textBox1->Text);
　　　　textBox2->Text = hoge.ToString();
　　}
　　catch( ... )
　　{
　　}
}
まぁ、例外処理は除いたが、いったん数値にして、別のテキスト・ボックッスに文字列として
代入するならこんな感じだろ

あ、
if ( !String::IsNullOrEmpty() ) →if ( !String::IsNullOrEmpty(textBox1->Text) )
だったorz

そもそも、目的はbutton1を押すとtextBox1に入力した
16進数の入力判定を行い、（条件として、空でないこと、16進数16桁であること）
button2を押したら、openFileDialogを呼び出しファイルを選択してOKを押したら
textBox2に選択したファイルを読み込ませ（ここは既に実装できています）
最後にbutton3を押したらtextBox1とtextBox2を結合し、saveFileDialogで
名前を付けて保存するという、単純なものなのですが16進数変換と入力判定の所で
どつぼにはまってしまいました。

文字入力
↓
16進数変換＆入力チェック
↓
外部ファイル読み込み
↓
16進数＋外部ファイル結合
↓
名前を付けて保存

とりあえず判定は829のように例外が投げられるかどうか調べるしかないと思う。

ちょっと理解できてきたみたいです
//16進数を受け付ける
UInt64 hoge =Convert::ToUInt64(textBox1->Text,16);
//10進数を受け付ける
UInt64 hoge = UInt64::Parse(textBox1->Text);
textBox2->Text = hoge.ToString();
やっと16進数の入力を考えれるようになりましたが
UInt64 hoge =Convert::ToUInt64(textBox1->Text,16);
textBox2->Text = hoge.ToString();
で出力すると、ご丁寧にも16進数から10進数に変換されています
ヮ(ﾟдﾟ)ォ!

16進で出力すればいいじゃん。
何言ってんだ？

やっとできました、どうも皆さん
ｱﾘｶﾞﾀﾏｷﾝ ( ´∀｀)ﾉ⌒ω)Д`)ﾌﾞﾆｭ
UInt64 hoge =Convert::ToUInt64(textBox1->Text,16);
wchar_t foo[16];
memset(foo, 0, 16*sizeof(wchar_t));
_i64tow_s (hoge,foo,16,16);
String ^tmp = gcnew String(foo);
textBox2->Text = tmp;
しかし、例外処理が超難関だな(;´д｀)ﾄﾎﾎ…
try {}catch( )の構文前からスマートでかっこいいと思っていたので
覚えたいと思っていたんだがな、ムズそうだな・・・・
今更泥臭くMessageBoxで条件判定するのも、なんだかなぁー

学生さん？

>>837
textBox2->Text = Convert::ToUInt64(textBox1->Text, 16).ToString("x");

ちゅうかうざい。

ToString が書式指定できることを知らんと言うのもありがちで、MSDNを見れば・・・

だが、Express の配布で C++/CLI を使う初心者がこんな感じに騒いだらこの先恐ろしいな

L"..."を
template引数で使うとconst wchar_t*にならない？
(generic,overloadだとStringになった)

void call_overload(String^ s){Console::WriteLine("String");}
void call_overload(const wchar_t* w){Console::WriteLine(L"const wchar_t*");}
template <typename T> void call_template(T t){Console::WriteLine( (T::typeid)->Name );}
generic <typename T> void call_generic(T t){Console::WriteLine( (T::typeid)->Name );}

call_overload(L"123");//String
call_template(L"123");//Char*
call_generic(L"123"); //String

仕様にそう書いてあった
template では const char* や const wchar_t* が渡されたら、char や wchar_t の配列として
扱い、ジェネリック関数は型引数で const char* や const wchar_t* が渡された場合には
String として型推論するというルールだって

call_template(gcnew String("123"));
とやると、String としてちゃんと帰ってきた

MFCはどうなるんでつか？

STL.CLIみたく、MFC.CLIが出るんでつか？

つ CWinFormsControl

Microsoft .NET Framework の Windows フォームを使用したペインティング テクニック
http://www.gotdotnet.com/japan/team/windowsforms/windowsformspainting.aspx
これを参考に、C++/CLI からのグラフィックスの基礎を勉強しています。

最後の TextClipping というアプリケーションの例で、
protected override void OnPaintBackground(PaintEventArgs e)
という C# における記述が出てくるのですが、
同様の記述を C++/CLI でやってみたところ、
override 仕様にも基本クラスで OnPaintBackground は
virtual じゃないよ、って言われます。

.NET Framework 2.0 で何か変更になったのでしょうか？

自分のメソッドの宣言で virtual は書いたけど override 指定していない方に つ�I

汚い文法だなぁ

>>864 OnPaintBackground つーのは、規定クラス
System::Windows::Forms で virtual で宣言
されている「はず」だったんですが・・・
んじゃ、OnPaint とかを乗っ取る事はできないのかなぁ。

ｆつべｖうぇ４５ｗｖｗ３４

>848
まぁ、漏れあてなんだろうけど、C++/CLI では暗黙のオーバーライドは禁止されている
ちゃんと
virtual void OnPaintBackGround(...) override ←これ
{
...
}
と記述してる？　これ書いても上書きできていないの？

>>850 忘れてました orz

>>100 本買ってまで勉強する必要はないんじゃない？

private:
　　void button1_Click( Object^ /*sender*/, System::EventArgs^ /*e*/ ){
　　hoge = "";
　　〜
}

private:
内で定義した変数って、よそのプロシージャーでは当然使えませんよね
グローバル変数で定義すれば、いいのだろうけど
NETで
※どんなアルゴリズムでも、グローバル変数なしで
記述できることが証明されています。
グローバル変数は後述するように、非常に強力な反面、
大きな危険性を秘めています。
とはいえ、絶対に知っておくべき事柄です。
らしい、button1で発生した変数を、button2のイベントが起きたときに
継承させる方法を
、グローバル変数無しで実現できるの？

>>853 まずもってプロシージャってのが C++ にあるか
ってのは置いといて、そのフォームのメンバ変数は
button1_Click() からでも button2_Click() からでも
アクセスできるじゃん。

そんなことはないやろ、
private:
　　void button1_Click( Object^ /*sender*/, System::EventArgs^ /*e*/ ){
　　hoge = "";
　　〜



} private:
　　void button2_Click( Object^ /*sender*/, System::EventArgs^ /*e*/ ){
　　textBox2->Text=hoge;
　　〜
}

: error C2065: 'temp' : 定義されていない識別子です。

>>855
それ別の位置でコンパイルエラー出てるだけじゃないか？
そのコードの中にtempなんて識別子は出てないのだが

>856
この人が言ってるの、auto 変数のことじゃない？
メソッド内部で宣言したローカル変数にアクセスしたがってるんだよ

>>857 そんなもん、VB でもできんわ・・・
プロシージャとかいってるからたぶん
VB使いかな？とか思った。

やっぱり、無理やな

>>853 の頭の中には、ローカル変数とグローバル変数しか内のだろうか。

プロシージャが WinProc のことなら、Form 間でのアクセスのことかも
何にしても、そんな状態でC++/CLIに手を出すのはやめた方がいいと思う

そもそもC++/CLIでなくてもC#でもなんでもやめたほうがいいな。

>>862も人生をやめたほうがいいな。

C++/CLI がこんなにも複雑なのがいけないと思います！

まぁ何でもあり(？)なのが C++/CLI だしなぁ。
複雑さを避けたいなら、C#だよな。
あ、VB.NET って手もあるか。

>>865
> まぁ何でもあり(？)なのが C++/CLI だしなぁ。
まさにC++から派生した、って感じだな

言語仕様を拡張せずに .NET 対応は出来なったのかなぁ。
managed_ptr<Object> obj = managed_new<Object>();
みたいな。

>>867 managed C++ であんまりうまくいかなかったから、
結局言語使用の拡張に踏み切ったんだろ。

>867
逆に、どこまでが既存の C++ でどこからが CLI 拡張かわかりやすくていいと思うよ
mc++ の混乱ぷりから考えるに、MSが出した仕様にしてはさっぱりしすぎて不思議
時代が変わっても、フレームワークをさくっと切り替えるだけで対応できるし、VES も
簡単に交換可能なところが夢があると思われ
また、C++ 自体の拡張の邪魔にならないところとかもいい
Sun も JNI の仕様をこれにしないかな。そしたら、JVM も使う気になるのに

Java をネイティブ拡張したものがが仮にあったとして、
C++/CLI とどっちを使う？？

その仮とやらの質による。存在しないものと比較しても仕方がない

おい！！！！
だれだよ、俺のプロジェクトで勝手に /clr:pure にした奴は！
おかげで全部 __clrcall になっててリンクできずに
一晩悩んだじゃないか！

さて、そろそろ帰るか。

>>870
Javaをネイティブ拡張したもの≒C#

Java = C++--
C# = Java++ = C++--++

>>873
ネイティブじゃナインじゃん

String^ arg_1 = abc;
String^ arg_2 = def;
textBox1->Text = arg_1 + arg_2;
としたら
abcdef
と出力出来ますが
textBox1->Text = arg_1 + endl + arg_2;
: error C2679: 二項演算子 '+' : 型 'overloaded-function' の右オペランドを扱う演算子が見つかりません (または変換できません)。
となり、期待していた
abc
def
が出来ません
誰かrg_1とarg_2の間に改行を入れて
abc
def
となる様にしてください。
ｵﾅｶﾞｲｼﾏｽ

System::Environment::NewLine

textBox1->Text = arg_1 + endl + arg_2;
じゃなくて
textBox1->Text = arg_1 + "\n" + arg_2;
でいいじゃん。

std::endl はマニピュレータで、、
マネージド型である String に対して
+ 演算子がオーバーロードされているなんてことはまずない。

"\r\n"にしないとだめではないか？

変だな？
textBox1->Text = arg_1 + "\n" + arg_2;
としたら
コンパイルも通ったんだけど
textBox1に表れた文字が
abc・def
全角文字の・に似た記号が出ます（多分全角の・とは違う気がするが、定かではない）
秀丸に貼り付けると
abc
def
と改行されてるんだが、なぜ？

>>880
サンクスできましたが、解説もｵﾅｶﾞｲｼﾏｽ
なんで
"\n"では駄目で"\r\n"なの？

Windowsの改行コードは"\r\n"だから。
UNIXとかのコンソールプログラムでは\nで
Macは"\r"

そしてC/C++は\nを使い、テキストモードでの入出力時には環境固有の改行コードと\nとで変換をしている。

ウィンドウズはそういうもん。
Unix : 円 n
Windows : 円 r 円 n
旧 mac : 円 r

コンソールアプリは透過的に 円 n ⇔ 円 r 円 n やってくれるが
テキストボックスとかはやってくれない。
秀丸じゃなくってノートパッドならやっぱりナカテンが出ると思う。

みんなでケコーン

OS X は ¥n になったよ ... 関係ないですが。

>>882->>885
>>881です
ご丁寧にありがとうございました、よく理解できました
しかし皆さん本当に良く知ってますね

>>884
どっちかと言うと円記号よりもバックスラッシュ。

完璧な回答を出しているのにスルーされてる>>877がｶﾅｼｽ

>>887さん
ありがとう
ｽﾏｿ、やっぱりC++/CLIならこうですよね
(ﾟдﾟ)(｡_｡)(ﾟдﾟ)(｡_｡) ｳﾝｳﾝ
msdnでよく調べます

String型の変数arg_1を書き込みたいのですが、
下記のコードでコンパイルも通りるのですがアプリケーションのコンポーネントで、
ハンドルされていない例外が発生しました〜後略
別のプロセスで使用されているため、プロセスはファイル'C*\hoge.txt'に
アクセスできません。
となってしまいます、どこがおかしいのでしょうか？

protected:
void button3_Click(Object^ /*sender*/, System::EventArgs^ /*e*/){
　　using ::System::Windows::Forms::DialogResult;
　　Stream^ myStream ;
　　SaveFileDialog^ saveFileDialog1 = gcnew SaveFileDialog();
　　saveFileDialog1->Filter = "txt files (*.txt)|*.txt|All files (*.*)|*.*" ;　　　saveFileDialog1->FilterIndex = 2 ;
　　saveFileDialog1->RestoreDirectory = true ;
　　if(saveFileDialog1->ShowDialog() == DialogResult::OK)
　　{
　　　　if((myStream = saveFileDialog1->OpenFile()) != nullptr)
　　　　{
　　　　// Code to write the stream goes here.
　　　　System::IO::StreamWriter^ sw = gcnew
　　　　System::IO::StreamWriter(saveFileDialog1->FileName);
　　　　sw->Write(arg_1);
　　　　sw->Close();
　　　　myStream->Close();
　　　　}
　　}
}

なんでSaveFileDialog->OpenFileで開いてるのにさらにStreamWriterで開き直す？
すでに開いているストリームに対してStreamWriterを使うのならStream^を渡す。

最近よう、気のせいか初心者歓迎スレに変わってきてないか？
なんか、聞けばいいと思っている輩が増えてきた気がするんだが

>>891
SaveFileDialog->OpenFileに書き込むには
どうしたらいいですか？

System::IO::StreamWriter^ sw = gcnew System::IO::StreamWriter(myStream);

初心者はC#かVBからはじめるのがいいよ。MSDNの見方くらい覚えような。

>>894
ありが�d

C++/CLI みたいなマニアな言語を使おうとする奴が
なぜこんなところで教えてくんしてるのか判らん。
(マニア、というのは、それでないと書けないほどのアプリを
書かないといけないはめになっていないと使わないだろう、
ぐらいの意味。)
MSDN 読めるぐらいでないと C++/CLI 手を出さないと思うんだが、
どうなってんだろう？

しらんがな。

>>896
少しはC++をやっていて、新しい言語に手を付けずに.Netが使えるぞと思っているんだよ、きっと。
実際はC++とC++/CLIとは別物だということを知らず。

つーか、自然な流れだと思うぞ。

一般的にC++が普及してた。
ライブラリはMFCやらWin32APIやらATLを使ってたであろう。
そして、MSの次期スタンダードなライブラリが、.NETになった。
じゃあ、C++から.NETを使おうか。

こんな感じでしょ。
間違いだとも思わない。

ええっと、言語間の違いよりも、
ライブラリ間の違いのほうが余程大きいと思うんですが...

一般的に旧VBが普及してた。
PC以外で死滅気味だった言語が台頭。サーバーサイドJavaや組み込みC++。
サーバーサイドや組み込みに足を踏み入れるドトネトとＣ丼を強制。
ﾌﾞﾋﾞ厨氏滅＆ドトネト氏産。
ｵﾈｶﾞｲC++からドトネト使ってトンでも言語mc++ → C++/STL.CLI

>>901
日本語でおｋ

899=線能されてる

C++の文法複雑＋マネージドの理解＋旧ＣＯＭの理解を要するなんてサイアクじゃん。
で、C++のBoostなんかは使えないという利点が無いオマケ月。

>>903 ネイティブな領域では普通に Boost 使えてるけど？
たとえば Boost.Serialization で既存のデータを読み込んで、
Windows Forms で表示したり ADO.NET で DB に投入したりできる。

>>904
書いてて自分の文章の複雑さに気付かない？

http://pc8.2ch.net/test/read.cgi/tech/1139313234/115
こういうこともあるみたいだけど。

>>904 ネイティブな領域では普通に Boost 使えてるけど？

なんだ、丸々大ウソか。
さすが線能されてるだけある。

M$もCOMでC++を汚しきったが、mc++で文法破壊、CLIでライブラリ破壊だね。

>>906 それ書いたの俺。で、そのオチが >>872

>>908
>だれだよ、俺のプロジェクトで勝手に /clr:pure にした奴は！

PUREでない混合だと激遅になるドトネトに何の意味があるのかと小一時間。

>>909 pure でやるなら、既存のライブラリの多くを
あきらめるってことなので、俺なら C# を選択する。

>あきらめるってことなので、俺なら C# を選択する。

ソースコードの価値ってのは既存コードだったり、
環境変わってもコンパイルしたりすると動くことだったりするのに、
馬の骨Ｃ丼に何の価値があるのかと。

ttp://pc8.2ch.net/test/read.cgi/tech/1141828033/1
　　　　　　　　 ,. -‐'''''""¨¨¨ヽ
　　　　 　 　 (.＿＿_,,,... -ｧァﾌ|　　　　　　　　　　あ…ありのまま　今　起こった事を話すぜ！
　 　 　 　 　 |i i|　 　 }!　}} /／|
　　　　 　 　 |l､{　 　j}　/,,ｨ//｜　　　　　　　『.NET framework 2.0を入れたと思ったら
　　　　　　　 i|:!ヾ､_ﾉ／ u {:}//ﾍ　　　　　　　　何故かノータッチデプロイメントがぶっ壊れた』
　　　　　　　 |ﾘ u' }　 ,ﾉ　_,!V,ﾊ |
　　 　 　 ／´fト､_{ﾙ{,ィ'ｅﾗ　, ﾀ人　　　　　　　　な…　何を言ってるのか　わからねーと思うが
　　　　 /' 　 ヾ|宀| {´,)⌒`/ |<ヽﾄiゝ　　　　　　　　おれも　何をされたのか　わからなかった…
　　　　,ﾞ　 ／ )ヽ iLﾚ 　u' |　| ヾｌﾄﾊ〉
　　 　 |／_／　 ﾊ !ニ⊇　'／:} 　V:::::ヽ　　　　　　　　頭がどうにかなりそうだった…
　　　 /／ 二二二7'T'' ／u'　__ /:::::::/｀ヽ
　　　/'´r　-―一ｧ‐ﾞＴ´　'"´ ／::::／-‐ 　＼　　　移植や修正が必要だとか
　　 / // 　 广¨´ 　/'　　 ／:::::／´￣｀ヽ ⌒ヽ　　　　そんなチャチなもんじゃあ　断じてねえ
　　ﾉ ' /　 ノ:::::`ー-､___／:::::／/ 　 　 　 ヽ　　}
_／｀丶　/::::::::::::::::::::::::::￣`ー-{:::...　　　 　　　ｲ　 もっと恐ろしいものの　片鱗を味わったぜ…

>>911 だから今俺は C++/CLI 使ってるんだってば。

>>913
で、C++/CLI複雑じゃない？それだけ価値あるということ？

>>914 使わざるを得ない場面があるということ。
あと、マゾにはたまらないって言うこと。

自分で判断できないような人はC#やっといた方がいい。
C++/CLIは必要があって使うもの。

既存のライブラリの多くを諦める事になるからC♯って意味分からん。
C♯だったら、多くを諦めるどころか、全部諦めにゃならんだろｗ
ヤケクソやってんのか？ｗ

>917 そんなこといってないじゃん。
既存のライブラリを使いたいから /clr:pure あきらめて
C++/CLI つかってます、って書いてんのに。

ヒント；Ｍ＄ジレンマ

>>918
君は正しい。ただあんまり一生懸命レスすること無い。疲れるだけだから。

昔：VB-VC-Windwos
今：.NET Framework-C++/CLI-Windows

伸びてると思ったら不毛な議論が続いてたようだな。
アンチが何したいのかわからんがこんなところで騒いでも無駄ですよ

皆さんはやっぱり、C++/CLIでもファイルの入出力とか自作のライブラリー等
作成されてるのですか？Stream オブジェクトとか、MSDN見る限り、素人目には
既に完成されていると思うのですが、個人的にパラメータを渡して読み込み、書き込み
モードで開いたりとかテキストモードで開いたり、バイナリモードで開いたりとか、やったほうがもっと楽でミスも少なくて、いいのかなぁーと思ったりするのですが、
いかがなものでしょう？

逆に聞くが>>923は今まで入出力に自作のライブラリを使っていたのか？

>>923 C++/CLI でも、っていうか、マネージドの領域では
.NET Framework べったりのプログラミングしてます。

C++/CLI 使うメリットはネイティブとの橋渡しができる
ことだと思ってるんで、ネイティブの領域では
従来通りの自作のライブラリーを多用しています。

>>923
何言っているんだかわからん。
Streamのどこが気に入らなくて、どういうことをやっているわけ?

>>926 抽象化されていないもっとファイルシステムべったりの
いじり方をしたいのでは、と推測するけど、まぁそういうことが
したけりゃ Windows API 叩くのも C の標準ライブラリ
叩くのも低レベルファイルアクセス関数群叩くのも
C++ の標準 I/O ストリーム使うのも自由、としか言いようがないな。