05/09/11 23:57:10
専用スレが今の時期にいるのか?
3:デフォルトの名無しさん
05/09/11 23:58:57
あくまでも MSの推奨は C#だろ。
4:デフォルトの名無しさん
05/09/12 00:00:42
C#ってプラットホーム呼び出しとか面倒じゃね？
態々DllImportってうぜー
5:デフォルトの名無しさん
05/09/12 00:15:55
C++/CLIって普通にSTLとかBoostとか使えるのかな？
6:デフォルトの名無しさん
05/09/12 01:01:16
2005β2でSTLは使えたぞ
Boostはまだ未検証
7:マイク ◆yrBrqfF1Ew
05/09/12 01:06:04
.netなんてC++を使うまでも無いだろ
8:デフォルトの名無しさん
05/09/12 01:09:22
なにを使えと？
まさかC#？
9:デフォルトの名無しさん
05/09/12 01:12:43
VC++のエディタは支援機能がVC#に比べて弱い
10:デフォルトの名無しさん
05/09/12 01:20:29
エディタなんてIDEのものは普通使わんだろ？
支援機能がないと書けないの？
11:デフォルトの名無しさん
05/09/12 01:27:23
>>10
今時そんなこと言ってる人間はJavaの世界でもいなくなったのに。
12:マイク ◆yrBrqfF1Ew
05/09/12 01:47:57
4年前からまだterapadだな俺
13:デフォルトの名無しさん
05/09/12 07:16:46
>>4
くまぐまDllImport
14:デフォルトの名無しさん
05/09/12 09:50:25
>あくまでも MSの推奨は
推奨は消えるからﾔｳﾞｧｽ。＞NetBUEI、VBX、VB、WinDNA、COM
15:デフォルトの名無しさん
05/09/12 11:51:07
COMは消えない
16:デフォルトの名無しさん
05/09/12 11:58:35
AJAX >>>>>（壁）>>>>> COM
17:デフォルトの名無しさん
05/09/12 12:17:29
>>16
AjaxのXMLコンポーネントは何でできてるかご存知で？
18:デフォルトの名無しさん
05/09/12 12:18:52
COMだと？
19:デフォルトの名無しさん
05/09/12 12:21:09
C++/CLIについて語ろうぜ！
20:デフォルトの名無しさん
05/09/12 12:28:40
重複ｽﾚです
managed C++ やろうぜ！！
ｽﾚﾘﾝｸ(tech板)
21:デフォルトの名無しさん
05/09/12 12:30:34
managed C++ と C++/CLI は異なるものですが・・・
22:デフォルトの名無しさん
05/09/12 13:10:25
C++を複雑化すんなって漢字。
C++/COMもヘッダー巨大＆ワケワカだったし。
23:デフォルトの名無しさん
05/09/12 13:24:30
自分の頭の悪さを言語のせいにするな
24:デフォルトの名無しさん
05/09/12 13:27:45
>21
ｽﾚﾘﾝｸ(tech板:681-682番)
25:とこなつ
05/09/12 20:26:45
いままたC++が熱い！「C++/CLI」として大進化したVisual C++ 2005
URLﾘﾝｸ(www.atmarkit.co.jp)
26:デフォルトの名無しさん
05/09/13 00:34:04
ｈとｃｐｐに分けるの面倒
予期せぬEOFが云々
とかもうぜー
27:デフォルトの名無しさん
05/09/13 00:49:56
>>16
AjaxとCOMを並列に語る発想がすごいよね
28:デフォルトの名無しさん
05/09/13 00:51:38
AjaxとCOMが別物だと思っているしとﾊｹｰﾝｗ
29:デフォルトの名無しさん
05/09/13 01:48:28
VC#のほうが簡単だよ
30:デフォルトの名無しさん
05/09/13 01:50:23
>>28
基地外さらしage
31:デフォルトの名無しさん
05/09/13 01:52:40
C#死亡・・・
たぶんＭＳは、C#をなかったことにするのでないかい？
こんだけ推し進めといて、アッサリ切り捨てるのがＭＳのやり方だーね
32:デフォルトの名無しさん
05/09/13 07:04:48
はいはいネガティブネガティブ
33:デフォルトの名無しさん
05/09/13 07:49:18
> デファクトスタンダードに最も近い
本当かよｗ
34:デフォルトの名無しさん
05/09/13 08:17:41
まぁ近いだろうな。消去法で。
35:デフォルトの名無しさん
05/09/13 09:46:47
>>31
マジレスすると全く正反対。
ヒント：J#
36:デフォルトの名無しさん
05/09/13 09:50:46
Sunとの和解内容は秘密だから分からないけれど、
当然将来J#を選択できる内容になっているんだろうな。
報道ではJ#完全打ち止めだけども…
37:デフォルトの名無しさん
05/09/13 09:55:57
C++/CLI のフリー環境は作れないわけではないと思われ
VMに何を利用するかによるが、じきにGNUあたりで出てくるんでないかね
38:デフォルトの名無しさん
05/09/13 10:46:48
ネイティブ以外興味ないよ
39:デフォルトの名無しさん
05/09/13 10:53:55
GNU/UNIX系は、他環境のコード（例えばWin32）を取り込んでUNIXでコンパイルできるようにする文化だから、
ネイティブコンパイルできるようになるだけっぽい。
40:デフォルトの名無しさん
05/09/13 10:57:52
>>37
まだまだだが、
URLﾘﾝｸ(www.go-mono.com)
URLﾘﾝｸ(open64.sourceforge.net) WHIRL中間コードを利用するgcc
URLﾘﾝｸ(www.math.leidenuniv.nl) WHIRL→CLI
URLﾘﾝｸ(msdn.microsoft.com)
41:デフォルトの名無しさん
05/09/13 10:58:30
>>39
ｱﾌｫ?
42:デフォルトの名無しさん
05/09/13 11:11:57
>>41
いいえ、あなたがアフォです。
43:デフォルトの名無しさん
05/09/13 12:11:59
>>42
やっぱり!
44:デフォルトの名無しさん
05/09/13 12:33:01
>40
ECMA での MC++ （＝C++/CLI）を Mono VM でサポートってことは、SGI と共同で
C++/CLI の MonoVM 環境を作るつもりなんだ。他のコミッティはどうするんだろう
しかし、中間コードから CIL を出力って、これがうまくいけば凄いね。VES 上でC/C++が
動くんかいな
45:デフォルトの名無しさん
05/09/13 12:45:09
いや、SGIが作るのはWHIRLを中間に使うgcc変種。
最終的にはネイティブを出力。
WHIRLは高水準のものから低水準のものまで多段で扱う流儀なので、
高水準のものからなら、CLIへのコンバートはそれほど難しくないと思われ。
whirl2cってのがあるくらいだから。open64のwhirl.pdfの1.3節
46:デフォルトの名無しさん
05/09/13 14:45:49
んーってことは、ただのネイティブ変換なんだ
モジュール起動時にVESにアタッチして、マネージド・オブジェクトとあったこったやったり
しない訳ね。ちょっとそれだと魅力ないなぁ。構文だけ一緒なだけなんだ
まだ、JNI をいじってラップかますほうが C++/CLI っぽいか
47:デフォルトの名無しさん
05/09/13 19:49:32
SGI
URLﾘﾝｸ(www.sgi.org)
48:デフォルトの名無しさん
05/09/13 20:27:44
そうかそうか
49:デフォルトの名無しさん
05/09/13 23:07:52
>>33
まだ出てもいないのにデファクトなわけないだろｗｗｗｗｗｗ
50:デフォルトの名無しさん
05/09/14 00:44:49
>>46
ちょっと勘違いがあるみたいなんだが、open64はCLIと何の関係もない。
RTLを使わないgccの変種を作っている。(WHIRLを使う)
で、その成果を利用すると、CLIへの変換が容易、
あるいはいきなりCLI生成な更なる変種を作るのが容易。
ってな感じの状況が>>40。一つ目のURLのFAQを読んでね。
51:デフォルトの名無しさん
05/09/14 01:04:19
>50
んー、それは理解している。でも、C++/CLI の魅力は IL にして VES 上でのみ動かす事じゃなく、
ネイティブとマネージドが共存するメモリモデルを持っていることだから、C# の亜種なら
要らないでしょ
52:デフォルトの名無しさん
05/09/14 09:12:12
まだその段階にないというだけなんでは?
53:デフォルトの名無しさん
05/09/14 19:39:29
>52
そうだけど、方向性が違うでしょ。実行モジュールから MonoVM をアタッチして、その上に
部分変換した IL を流し込むやり方は、遠いよ
JNI みたくVM上に直接オブジェクトを作るアプローチの方が手っ取り早いと思うんだけどな
54:デフォルトの名無しさん
05/09/16 00:47:53
あげ
55:デフォルトの名無しさん
05/09/17 15:47:46
あげ
56:デフォルトの名無しさん
05/09/19 00:32:42
あｇｔ
57:デフォルトの名無しさん
05/09/19 07:50:33
いつになったらC++/CLI使えるようになるの？
58:デフォルトの名無しさん
05/09/19 10:44:10
今でも使えるよ
59:デフォルトの名無しさん
05/09/19 11:11:11
printfが使えるらしい
60:デフォルトの名無しさん
05/09/19 20:00:34
Visual Studio .Net 2003 で動作していた、
アセンブラ ファイルを含むプロジェクトが
Visual Team Suite 2005 Beta2 では、
error PRJ0003 : 'cmd.exe' の起動中にエラーが発生しました。
とのエラーになる。
どなたか、アセンブラ ファイル（.asm）を含むプロジェクトを
試された方、アドバイスお願いします。
61:デフォルトの名無しさん
05/09/19 21:20:11
asm の部分をコメントアウトしてコンパイルしてみたら？
問題は別のところにあるんじゃねぇ？
62:デフォルトの名無しさん
05/09/19 21:58:39
>61
いや、インラインではないんだ。
別に拡張子.asmのファイルを含んだ
プロジェクトで、例えば、
abc.cpp
abc.asm
この２つのファイルを含んだプロジェクト
をビルドすると、エラーとなるわけ。
abc.asmのカスタム ビルド ステップ指定は
以前のVSN_2003と同様ですがね。
63:デフォルトの名無しさん
05/09/19 22:52:32
cmd.exeってことは起動に失敗してるんだろ
アセンブラがパス通ってないか、無いんじゃねーの
64:デフォルトの名無しさん
05/09/19 22:52:48
2009年のC++の姿でも見ておけ。これでもC++がいいのか。
URLﾘﾝｸ(216.55.183.63)
65:デフォルトの名無しさん
05/09/19 23:01:22
pptってなんだよ
変てこなバイナリつくんなよ
66:デフォルトの名無しさん
05/09/19 23:18:43
>64
良くなるじゃん。ラムダと自動変数と関数子に並列処理やメモリのクリティカルなアクセス保持、
遅延実行、メッセージの言語サポート、非同期実行による処理の委託、スコープによる
処理の実行の同期、アルゴリズムをスレッド化してくれるし、並列化STLとかも来るとなると、
なんか、あれふ、みたいだな
>62
関数呼び出し部をコメントアウトして、asm はあるけど使わないとどうなるの、と訊いた
つもりなんだが
漏れも 63 が正しいと思うカスタム・ビルドで指定してるコマンドが間違ってるんじゃね？
67:デフォルトの名無しさん
05/09/19 23:25:23
ConcurやLinqなんて入るのか?
VC++/CLIだけだろ?
68:デフォルトの名無しさん
05/09/19 23:31:50
>67
これ、C++0x （多分、x==9）の予定だよ。だから、これをサポートしたコンパイラが出てくるのは
５年後から。まぁ、独自拡張でいろいろ試したりするだろうけど
それよりもまず、名前空間を拡張して欲しいなぁ
namespace company.product_name
{
...
}
って書きたいよ
69:デフォルトの名無しさん
05/09/19 23:43:58
>>65
恥さらし乙
70:デフォルトの名無しさん
05/09/19 23:51:48
>>68
C++0xは全部じゃないよ。
Linqなんて言語レベルでやるのが良いのかどうか。
C++は機構だけ提供するのが好きな言語だから。
71:デフォルトの名無しさん
05/09/19 23:53:44
65 名前：デフォルトの名無しさん[] 投稿日：2005/09/19(月) 23:01:22
pptってなんだよ
変てこなバイナリつくんなよ
72:デフォルトの名無しさん
05/09/20 09:49:04
もうこれ以上言語を拡張するのはやめてほしい＞C++0x
これだけ仕様が肥大すると、規格準拠コンパイラが存在しなくなって互換性も糞もなくなるぞ（もうなってるか・・・）
C/C++と親和性の高い言語を新しく設計したほうがマシ。
73:デフォルトの名無しさん
05/09/20 19:01:40
>>72
だめだ。それをやると、D言語の二の舞になって、ユーザーを得られない。
74:デフォルトの名無しさん
05/09/20 20:32:24
D言語はセンス悪いもん。
ConcurやLinqは、高レベル過ぎるから、
新しいのつけるならプリミティブを抽出して欲しいな。
Javaのfor each程度のものならすぐにつけてもいいけれど。
75:デフォルトの名無しさん
05/09/20 20:34:44
諦めてガジェットとして見るべ
便利なとこだけつまみ食いすればいいよ。結局実用外のところは、廃れるだろう
理解しなくても、ツールとしてコードは書けるし、それで充分だと思う
76:デフォルトの名無しさん
05/09/21 19:18:08
今回のVS_2005 C++/CLI は、たぶん
生き残ると思う。
秩序と混沌、
いつの世でも、新たな革新的技術は、
混沌が土壌だったからね。
アセンブラ～C#まで、必要とあらば一望の下に。
77:デフォルトの名無しさん
05/09/21 20:35:36
>>76
生き残るか生き残らないかは、君が決める事ではない。
まだ発売されてもいないのに。ＭＳの社員か？
78:デフォルトの名無しさん
05/09/21 20:43:29
>77
生き残ると、私が今国会で決めたのだ！
小泉君に聞いてみな。
79:デフォルトの名無しさん
05/09/21 20:55:12
>>77
思うというのは予想であって、予想というのは
事の決着に直接関与しない人間でもすることだし、
事が始まるより前にすることだよ。
「神戸新聞杯はやっぱディープインパクトが勝つと思うよ」
「勝つか負けるかは、君が決める事ではない。
まだ発走してもいないのに。厩舎関係者か？」
・・・っていう会話くらい変。
80:デフォルトの名無しさん
05/09/21 20:58:48
>>79
つ[チラシの裏]
81:デフォルトの名無しさん
05/09/21 21:32:48
長年プログラミングをしていると
オブジェクト指向だの何だの、
これらの概念は、すでに独自の手法で
取り込み、我がものとしているハズ。
でなければ、いくら最新最強と言われる、
処理系を手にしようと、扱う人によっては....。
それにしても、C++/CLI は、有望、だと思う。
82:デフォルトの名無しさん
05/09/21 21:33:10
/ | ﾊ ＼ ／／／／ ヽ
! l |l､､＼ ｀ 丶 ､'´＿ ､ 、
! ｌ ∥＼､ ＼_ ＿ /, -｀ヽ }
、 ｌ ∥＿ ＞:=‐ ￣￣「 ｌ| l } ､ ヽ んっ んんっ…
ヽ ､i`─ '´ ___ ｜ ｌl ⌒; j 、 ヽ
＼ヽ r,ﾆ､‐‐'‐' u .ｌ ｌl '_ノ ､ ヽ
｀ ＼"＼):､ ｜ ｌ| ｀､ ヽ ､ ヽ
ヽ ゞ'＾ ! lｌ ｀､ ヽ ､ ヽ
丿 .:::. ｜ l| ＼ ヽ、 ､ ヽ
丶､_ | l|/ｌヽ ｀＞=‐- ミヽ ｀、
｀⌒ヽ_ | ｌ| | ﾊ ／´ ｀ヽ ､
ﾁｭﾊﾟ / /. ｀´| ｌ| | l / 〃 ｀、 ､
ﾁｭﾊﾟ / / | ｌ| | l' 〃
【ゴールデンレス】
このレスを見た人はコピペでもいいので
10分以内に3つのスレへ貼り付けてください。
そうすれば１４日後好きな人から告白されるわ宝くじは当たるわ
出世しまくるわ体の悪い所全部治るわでえらい事です
83:デフォルトの名無しさん
05/09/21 22:50:20
この板アホアンチ多くね？
健全にMSの話題ができん。
84:デフォルトの名無しさん
05/09/21 23:00:17
技術の話ならするよ。
マンセーやアンチは置いといてさ。
85:デフォルトの名無しさん
05/09/22 08:42:24
>>80
いや、独り言じゃないから。
馬鹿をメタクソにやり込めただけだから :-P
86:72
05/09/22 08:57:32
>>73
俺 が 悪 か っ た
でもほんとこれ以上肥大させるのは勘弁して欲しい。
SubversionのFAQだったかな、「svnはなぜC++でなくCで記述されているのですか？」「C++だとポータビリティが低下するからです」。
わざわざ醜い言語仕様にして後方互換性を保ってもこのザマ。
まあそこがC++らしいっちゃらしいんだけどね。
87:デフォルトの名無しさん
05/09/22 12:16:31
C++でもテンプレートを禁止すれば互換性はかなり保てると思う。
けど俺はテンプレートのないC++なんて使いたくないがな。
88:デフォルトの名無しさん
05/09/22 12:29:33
>>86
URLﾘﾝｸ(subversion.tigris.org)
ないぞ。
89:デフォルトの名無しさん
05/09/22 12:34:16
そこでMozilla Portability Guideですよ。
90:デフォルトの名無しさん
05/09/22 12:38:26
URLﾘﾝｸ(subversion.bluegate.org)
91:デフォルトの名無しさん
05/09/25 14:11:17
>>53
GNU.NETのcsccは、Cのコードとミックスできるようだな。
WindowsのVC++ .NETで書けるCとのミックスコードを、コンパイルできるらしい。
(ただしCからWindows固有の機能を使ってはダメ)
92:デフォルトの名無しさん
05/09/25 19:10:44
いみなくね？
93:デフォルトの名無しさん
05/09/26 02:16:25
C++/CLIで書いてもC#で書いてもはたまたVB.NETで買いても
吐き出される中間コードはどれも一緒だよ
94:デフォルトの名無しさん
05/09/26 02:49:26
dotGNU Portable.NETってCLIのクラスライブラリ用いてlibc作ってなかったっけ？
95:デフォルトの名無しさん
05/09/26 06:44:54
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.
96:デフォルトの名無しさん
05/09/26 09:13:12
>93
pure とか mixed とかいろいろあるんだよ
97:デフォルトの名無しさん
05/10/01 10:07:04
「Inside the C++ Object Model」を書いていたStanley B. Lippmanが、
URLﾘﾝｸ(www.amazon.co.jp)
C++/CLIの本書いてるなあ。
C++/Cli Essentials (MICROSOFT .NET DEVELOPMENT)
URLﾘﾝｸ(www.amazon.com)
URLﾘﾝｸ(www.compman.co.uk)
Essential C++の人
URLﾘﾝｸ(www.amazon.com)
98:デフォルトの名無しさん
05/10/03 10:35:22
今までmanaged C++本買い捲って勉強してた人たちはどーなるわけ？
99:デフォルトの名無しさん
05/10/03 11:12:18
>>98
今まで通りでしょ?
C++/CLIへの大きな準備が一つ済んでるだけ。
変換ガイド: Managed Extensions for C++ から C++/CLI へのプログラムの移行
Stanley B. Lippman
Microsoft Corporation
2. マネージ型
URLﾘﾝｸ(www.microsoft.com)
100:デフォルトの名無しさん
05/10/03 11:23:49
今まで通りなら、もうC++/CLI本を買わなくて良いわけね？
101:デフォルトの名無しさん
05/10/03 11:48:23
>>100
そんな事ないな、C++/CLI特有の癖が出るから
こんなコードにしとけってのはある
102:デフォルトの名無しさん
05/10/03 11:49:50
で、mc++系の本はドブに捨てときゃいいわけ？
103:デフォルトの名無しさん
05/10/03 12:50:53
>>99
C++/CLIでManaged C++が捨てられるのだけは確定では？
大きな準備がどうとかほざいてる奴は同様にCOMも死んでないって言うんだろうねえ。
そもそも「移行」ってどんことか知らない奴は気楽に言ってくれる。
104:デフォルトの名無しさん
05/10/03 12:53:26
どうしてMSがらみのマはいつもいつも「移行」に追い立てられなきゃならんのかな。
いつも「移行」だよ。簡単ですからとか、技術の発展ですとか言われてナ。
105:デフォルトの名無しさん
05/10/03 12:58:51
>>104
そうは言っても、いずれは捨てていく物もある訳で
ある程度かき回してくれるおかげでオープンシステムになっていてもニッチ産業以外の所で小さい所が勝負できる
106:デフォルトの名無しさん
05/10/03 13:05:41
>>104
その点COBOLなら変化がなくて安心ですね(^^)
107:デフォルトの名無しさん
05/10/03 13:12:55
>>104 >>105
あおりのつもりかも知れんが、コンピューターの世界はレイヤーで残っていくもんだよ。
Javaで呼び出す部分にCOBOLで作らせたり、いろいろと。
実行環境はふつー継承されるもんで、丸ごと消えるってのはありえない。
108:デフォルトの名無しさん
05/10/03 13:18:07
使われる前に消え去った.NET1.0、2.0、mc++って一体...
109:デフォルトの名無しさん
05/10/03 14:09:06
managedを理解してないと、
C++/CLIでmanagedとunmanagedを混在させたコードを書けないよ。
managedだけでいいって人は、managed C++は捨てていいと思う。
C++/CLIではその辺(__gcとか)を隠してくれるから。
自分は言語が好きだから、managed C++→C++/CLIの以降はいい事だと思うけれど、
現場は大変だよね。(けどmanaged C++で仕事始めているところってあるの?)
110:デフォルトの名無しさん
05/10/03 14:12:08
C、C++のライブラリが使えるのが重要なんであって、そんなんやったらC++の意味無いやん。
111:デフォルトの名無しさん
05/10/03 14:41:10
今110が正解を言った！
まあ、_tmainなんて腐ったもの見たくねーよな、みんな。
112:デフォルトの名無しさん
05/10/03 14:42:02
本当はWinMainもみたくなかったよﾏﾏﾝ
113:デフォルトの名無しさん
05/10/03 14:47:00
>>109
>managedを理解してないと、
>C++/CLIでmanagedとunmanagedを混在させたコードを書けないよ。
>managedだけでいいって人は、managed C++は捨てていいと思う。
すると、C++/CLIが規格通っても、新しく勉強する人はmanaged C++から
勉強しなきゃいけないの？そんなに大変ならJava使いたいよね。
>自分は言語が好きだから、managed C++→C++/CLIの以降はいい事だと思うけれど、
>現場は大変だよね。
学生やら工作員の人は楽でいいよね。現場は大変だよ。
>(けどmanaged C++で仕事始めているところってあるの?)
それはない。.NET自体、ないしな。（ｗ
114:デフォルトの名無しさん
05/10/03 14:53:34
さあ、盛り上がってきます他。
115:デフォルトの名無しさん
05/10/03 14:54:19
>>113
.NETはあるってｗ
VB.NETだけど
116:デフォルトの名無しさん
05/10/03 15:32:46
>>108
.NET2.0ってなくなっちゃったの？
117:デフォルトの名無しさん
05/10/03 15:37:11
C++/CLI、標準になってないのに__propertyをpropertyにしているな。
それからspaced keywordダサ過ぎ…
118:デフォルトの名無しさん
05/10/03 15:37:47
>>116
managed APIはなくなって、単なるライブラリになちゃたお。
じゃ、C++/CLIいらねーじゃん。
URLﾘﾝｸ(pc.watch.impress.co.jp)
マイクロソフトOBでWindows 1.xの時代からWindowsの開発に関わっていた方(2000年に退職)から
コメントをいただいた。引用させていただくと
“私の住むシアトル近辺のマイクロソフトOBの間では、2004年の前半に「Longhornがキャンセルに
なったらしい」という噂がさかんに交わされ、その後次々と「OFSはLonghornとは別」、
「Managed APIは採用しない」とのアナウンスがありました。結局の所、もともと計画していた
Longhorn は出せなくなったけれども、いまさらキャンセルになったとは言えないので、出せるもの
だけかき集めてLonghornと呼ぶことにした、という見方がこちらでは一般的です”
119:デフォルトの名無しさん
05/10/03 16:36:52
>>118
＞managed APIはなくなって、単なるライブラリになちゃたお。
これの意味が分らないんだけどどういうこと？
120:デフォルトの名無しさん
05/10/03 16:42:39
> 同氏のコメントには「Managed APIは採用しない」というものもあるが、
> 確かにWinFXの位置付けも変化してきているように思える。一昨年秋の
> Professional Developers Conferenceでは、WinFXはLonghornの
> ネイティブアプリケーションが利用するManaged CodeベースのハイレベルAPIで、
> 次世代Windowsが実現する機能を新しいクラスライブラリでくるんだものだ
> と話していた。対してWin32を使うのは(WinFX混在も不可能ではないが)
> レガシーアプリケーションのみという話だったように記憶している。
managed APIの意味は分ったお。でも.NET2.0って元々Win32のラッパーじゃなかった？
121:デフォルトの名無しさん
05/10/03 16:55:48
俺も>>118は意味がわからんところが多いな。
実際問題managed objectが存在しなくなるなんて事言っているわけじゃないでしょ?
俺は要らないんだけれど、今更そんな変更出来るわけがないし(w
まあ適当なところでお茶を濁すつもりじゃないかと。
122:デフォルトの名無しさん
05/10/03 17:35:41
まぁようするに
本来のVistaはmanagedプログラミングしか許さない設計で
NativeC++でプログラムすると速度が遅くなるはずだったのが
開発の遅れと.Netが糞なせいでNativeC++とmanagedが対等の関係
もしくは NativeC++ > managed になっちゃった！
って事だろ
123:デフォルトの名無しさん
05/10/03 17:59:22
つまり今と状況は変わらないと。
124:デフォルトの名無しさん
05/10/03 18:28:10
いつものパターン
125:デフォルトの名無しさん
05/10/03 19:13:19
最近になってやたらとXPのCM入れたりしてるのは、Longhornの遅れが響いてるのかな。
126:デフォルトの名無しさん
05/10/03 19:16:26
>>120 >>121
>でも.NET2.0って元々Win32のラッパーじゃなかった？
OS本体がマネージドなWinFXとなって、下位互換のためだけに、その上にWin32APIをエミュレートする予定だったお。
127:デフォルトの名無しさん
05/10/03 22:24:08
急にスレ伸びたなおい。
言語仕様としてスコープの概念が使える（スコープ切れでデストラクタを呼び出させる）のは
やっとｷﾀかって感じだな。
C++使いからみてJava/C#あたりのGC系言語の大きな不満といえば、あとは
constメンバかな。あれはやっぱりCLIに組み込むのは難しいのかなぁ。。。
＃もちろんmodoptに仕込むとかは今でもやってると思うけど、
＃多言語との相互運用とかいろいろ考えるとむりぽかなぁ。。。
128:デフォルトの名無しさん
05/10/03 23:01:16
メモリの配置位置がそもそも移動するから無理ぽ。常時pinするような状況になるわけで
それならヒープに普通に置いた方がめんどくさくなくない？
129:デフォルトの名無しさん
05/10/03 23:09:59
>>127
俺はそれよりもSTLを使いたいがためにC++を使っている。
130:デフォルトの名無しさん
05/10/03 23:11:52
つSTL.NET
131:129
05/10/03 23:22:26
>>130
それは知っている。
こういうのがないから俺もJavaやC#は好きになれんと言いたかった。
132:デフォルトの名無しさん
05/10/03 23:38:13
STL.NET がC#にも対応したら、複雑だな
133:デフォルトの名無しさん
05/10/04 00:12:25
>>126
そもそもそんな事したらIntelが黙って無いだろ
それはCPUは何でも良いって事になるんだぞ
134:デフォルトの名無しさん
05/10/04 08:31:33
別にintelは気にしないだろ。昔から殺伐した仲だし
32bit->64bit移行もあるから、そこらを切り離すのは普通の判断だべ
135:デフォルトの名無しさん
05/10/04 09:40:41
>>126
> OS本体がマネージドなWinFXとなって、下位互換のためだけに、
> その上にWin32APIをエミュレートする予定だったお。
この設計がもう滅茶苦茶バッドセンスなわけだが…それでいて、
>>122
> NativeC++でプログラムすると速度が遅くなるはずだったのが
って、それお前等がそうやっているからやん…
やはり最初はnativeの上にmanagedをwrapしていくことから地道に始めるべきだったかと。
136:デフォルトの名無しさん
05/10/04 09:44:53
>>132
一応、言語依存をなくす方向だよね。> STL.NET
CLI的なgenericにして。
ただこんなこと(言語非依存)やっていると、どんどん実装が遅れる。
ISO C++の時みたいに仕様だけどんどん出来て実装が追い付かない。
まあ流石にHaskell.NETは置いてきぼりだろうが(w
137:デフォルトの名無しさん
05/10/04 10:39:29
>>135
概ね同意。
でも、営業的にはもうWin32APIを切り捨てたいというのがあるんだよな？確か。
その為に移行期間としてエミュレーションで動くようにして、徐々に
減らしていくぞと。この方向は間違ってはいなそう。
営業的見解から言い出したことが、やってみたら
（技術的にか時間的にか環境的にか知らないが）やっぱり難しかった
って結果のような気がする。個人的にはゆっくり移行で良いと思ってるので
この流れで良いかな。
138:デフォルトの名無しさん
05/10/04 12:27:46
VC8には、STL/CLI(STL.NET)が入らない
URLﾘﾝｸ(www.ailight.jp)
残念でした。
139:デフォルトの名無しさん
05/10/04 12:48:22
>>137
> 営業的見解から言い出したことが、
"光の速さの経営"的見解に決まっているでしょ…
>>138
まだ無理。正直C++依存性が残ってる。
早く入れすぎて悪い設計を改変できず負の遺産、
これがMSの技術面の一番悪いところだから、入れないことはいいんじゃないの?
140:デフォルトの名無しさん
05/10/04 13:06:46
>>137
>でも、営業的にはもうWin32APIを切り捨てたいというのがあるんだよな？確か。
>その為に移行期間としてエミュレーションで動くようにして、徐々に
>減らしていくぞと。この方向は間違ってはいなそう。
だから、困るっちゅーに。
ソースコードってのは生き残るもんであって。
141:デフォルトの名無しさん
05/10/04 13:23:19
結局は、
・Win32じゃないNative APIも。
・Win32はNativeの上に互換ライブラリで。(ただし少しは改変必要)
・managedの世界もありまっせー。
になるんじゃまいか?
142:デフォルトの名無しさん
05/10/04 13:25:14
>>117
> それからspaced keywordダサ過ぎ…
いまさらcppの意味まで変えようつーのにはたまげた…
(cpp単体での)互換性切り捨てすぎ…というかアホ? > MS/Lippman
143:デフォルトの名無しさん
05/10/04 17:23:27
もうC++の名を捨てて新しい言語として出直したらいいのに
……そりゃC#か
144:デフォルトの名無しさん
05/10/04 21:29:10
>>138
URLﾘﾝｸ(forums.microsoft.com)
この話だよね。
145:デフォルトの名無しさん
05/10/04 23:43:18
結局C++をなんとかしようとしてどうにもなりませんでしたというわけだ。
Javaはガベージコレクタはありますがcloseメソッドをその都度呼び出せとだましとおす気だ。
closeがdeleteだったらバカは気づいただろう。
C#は誰も理解していないしその存在が不明だ。この言語はいったいなんなのだ。
C++/CLIは超難解なC++言語でがんばって数十メガのVMがロードされるというわけだ。
むくわれない。
あきらめろ。もうC++はboostとがんばれよ。
146:デフォルトの名無しさん
05/10/05 00:21:27
人の邪魔をするな。
俺は俺だ。お前がどう感じようが関係ない。
147:デフォルトの名無しさん
05/10/05 00:42:35
>>145
今時のパソコンで数十メガなんて意味を持たない
148:デフォルトの名無しさん
05/10/05 00:45:18
わざわざ対象のスレにまで来てネガティブキャンペーンをするやつは
結局のところ、自身の不安の裏返しなのだ。
149:デフォルトの名無しさん
05/10/05 01:12:28
せっかくC#おぼえたのにー
150:デフォルトの名無しさん
05/10/05 01:13:10
無駄銭だったねｗ
151:デフォルトの名無しさん
05/10/05 02:00:48
そもそもC++&.NETが間違いだよなぁ。
まあ今更だけど。
152:デフォルトの名無しさん
05/10/05 02:45:38
無駄じゃない！全然無駄じゃない！
153:デフォルトの名無しさん
05/10/05 04:14:57
無駄無駄無駄無駄無駄無駄無駄無駄無駄無駄無駄無駄ァァァ！！！
154:デフォルトの名無しさん
05/10/05 08:39:38
だからぁ、普通のC++ライブラリを混ぜれて、コンパイラオプションでWin32/Win64/ドトネトが切り替わるなら、どんどん使ってやる。
155:デフォルトの名無しさん
05/10/05 10:49:38
>154
C++/CLI はその通りですが何か？
156:デフォルトの名無しさん
05/10/05 10:53:11
STLさえ使えなくて、パチモンのSTLドトネトが要るなんて...
157:デフォルトの名無しさん
05/10/05 11:18:23
>C++/CLIは超難解なC++言語でがんばって数十メガのVMがロードされるというわけだ。
･ﾟ･(つД`)･ﾟ･
>今時のパソコンで数十メガなんて意味を持たない
∧＿∧
（ ´∀｀ ） このゴミ、どこに捨てたらいい？
/⌒ ｀ヽ
/ / ﾉ.＼＿M
( /ヽ |＼＿__E）
＼ / | ／ ＼
（ _ﾉ | / ｳﾜｧｧﾝ ヽ
| / / |ヽ（｀Д´）ﾉ|
| / / ヽ（>>147）ノ
( ) ) ￣￣￣
| | /
| | |.
/ |＼ ＼
∠／
158:デフォルトの名無しさん
05/10/05 11:48:48
>>157
「C++/CLIは」というより、
Longhornは常にCLRが動いていて、その上でサービスを受けるわけでしょ。
C#やVBだって同じ。
159:デフォルトの名無しさん
05/10/05 11:58:04
∧＿∧
（ ´∀｀ ） このゴミ、どこに捨てたらいい？
/⌒ ｀ヽ
/ / ﾉ.＼＿M
( /ヽ |＼＿__E）
＼ / | ／ ＼
（ _ﾉ | / ｳﾜｧｧﾝ ヽ
| / / |ヽ（｀Д´）ﾉ|
| / / ヽ（Longhorn）ノ
( ) ) ￣￣￣
| | /
| | |.
/ |＼ ＼
∠／
160:デフォルトの名無しさん
05/10/05 12:31:44
>>158
LHは1.1じゃなかったっけ？
161:デフォルトの名無しさん
05/10/05 13:47:31
2.0 だろ。WinFX は PlatformSDK のような扱いになるらしいが
>>158
もともとCOMサーバが動いてるんだから、変わらないでしょ
CLR は COM 後継なんだし
162:デフォルトの名無しさん
05/10/05 14:45:51
後継にしては今までのソースが全て吹っ飛んでしまうのは何故？
163:デフォルトの名無しさん
05/10/05 18:45:25
そこでC++/CLIですよ
164:デフォルトの名無しさん
05/10/05 18:55:03
>162
(ﾟДﾟ)ﾊｧ?
165:デフォルトの名無しさん
05/10/06 02:33:02
>>162
レガシー
166:デフォルトの名無しさん
05/10/06 14:27:21
>>165
もうカルディナは必要ありません。
167:デフォルトの名無しさん
05/10/06 14:37:56
Vistaはネッツに吸収されました。
168:デフォルトの名無しさん
05/10/06 15:13:30
アニヲタばっかりだな
169:デフォルトの名無しさん
05/10/06 15:15:10
車なんだけど...
170:デフォルトの名無しさん
05/10/06 15:28:17
>>68
LinqやActive Objectが、C++0xに入るわけないだろ。
この辺が入ったC++/CLIはEMCAで標準化されるだろうけど。
171:デフォルトの名無しさん
05/10/06 15:41:49
そーいえば、Ｃ貪とかいう標準化されたどーでもいーものがあったね。
標準化なんてＣＯＢＯＬでもある。
というか、プログラムの長持ちではＣＯＢＯＬのが先輩だね。
172:デフォルトの名無しさん
05/10/06 16:22:27
168 名前：デフォルトの名無しさん[sage] 投稿日：2005/10/06(木) 15:13:30
アニヲタばっかりだな
169 名前：デフォルトの名無しさん[sage] 投稿日：2005/10/06(木) 15:15:10
車なんだけど...
173:デフォルトの名無しさん
05/10/06 16:53:26
active最高杉
174:デフォルトの名無しさん
05/10/06 18:05:44
168 名前： デフォルトの名無しさん [sage] 投稿日： 2005/10/06(木) 15:13:30
アニヲタばっかりだな
169 名前： デフォルトの名無しさん [sage] 投稿日： 2005/10/06(木) 15:15:10
車なんだけど...
ワロタ
175:デフォルトの名無しさん
05/10/07 00:25:44
よくわからんが、車を元ネタにした名前が出てくるアニメがあるって解釈でいいのか？
176:デフォルトの名無しさん
05/10/07 00:32:14
>>175
レイアースの登場人物の名前は車に由来。
ジョジョの登場人物の名前はミュージシャンに由来。
とCLAMPのアニメを3本見ただけの俺が答える。
177:デフォルトの名無しさん
05/10/07 00:32:53
つまり「アニヲタばっかりだな」が正解？
178:デフォルトの名無しさん
05/10/07 01:28:14
>>177
「アニヲタ馬鹿だな」が正解。
179:デフォルトの名無しさん
05/10/07 14:04:43
アニオタのせいで秋葉原って今ものすごいキモイ町になってる
180:デフォルトの名無しさん
05/10/07 14:41:26
そういや開業直後にTXに乗ってアキバへ行ったが、駅を出たら見知らぬ光景に遭遇して慣れるのに
時間を要した。ちなみにヨドバシカメラにはまだ行っていない。
181:デフォルトの名無しさん
05/10/07 20:32:11
>>179
アニヲタはそれほどでもない。むしろエロゲヲタが酷い。
182:デフォルトの名無しさん
05/10/07 20:52:23
>>181
悪いが区別が付かないのでどうでもいい。
183:デフォルトの名無しさん
05/10/07 20:53:42
>>182
プログラマとSE
184:デフォルトの名無しさん
05/10/07 21:07:08
>>183
悪いが区別が付かないのでどうでもいい。
185:デフォルトの名無しさん
05/10/07 21:15:49
よくテレビや雑誌で晒されてるようなヲタって何ヲタなの？
電車男みたいなやつ
186:デフォルトの名無しさん
05/10/07 21:39:55
ヲタというより、むしろ朝からパチンコ屋に並んだり、競馬場にたむろしてる連中を連想する。
187:デフォルトの名無しさん
05/10/07 22:54:11
パチンコ屋に並ぶのは朝しかねーだろ？
バカかおめー昼夕オープンなんて滅多にないんだぞ
しね
188:デフォルトの名無しさん
05/10/08 00:03:20
とパチンカスが言っております。
189:デフォルトの名無しさん
05/10/08 01:40:45
>>185
プログラマじゃないの？ :-)
190:デフォルトの名無しさん
05/10/08 02:08:49
>>186
社会の底辺にいる人達か。
191:デフォルトの名無しさん
05/10/08 02:13:23
なるほど、プログラマは朝からパチンコ屋にならんで競馬場にたむろしてマルチ萌え～とかセリオたんﾊｧﾊｧって言ってる人たちなのか
モニタの上に変なフィギュア飾ってるし
192:デフォルトの名無しさん
05/10/08 02:15:16
>>191
通常の業務の上にそんなことまでしてたら過労死するな。
193:デフォルトの名無しさん
05/10/08 21:40:48
朝からパチンコ屋にならんでなんいうやつはｱﾌｫ１確
お金をつかって買い物するっていってるような物だぞｗ
194:デフォルトの名無しさん
05/10/08 21:41:33
>>193
おまえは中国人かよｗ
195:デフォルトの名無しさん
05/10/08 21:43:57
デカ顔＆短足＆チビの日本人よりはマシｗ
196:デフォルトの名無しさん
05/10/08 21:44:57
ズボシだったのか
いや、悪気はなかったんだ
ジョークだ許してくれ
197:デフォルトの名無しさん
05/10/08 21:44:59
COME WITH ME
ってｶｯｺｲｲ
198:デフォルトの名無しさん
05/10/08 21:55:29
誰か>>193の言わんとすることをわかりやすく解説してください。
199:デフォルトの名無しさん
05/10/08 21:57:38
おまいら、巣にｶｴﾚ
200:デフォルトの名無しさん
05/10/09 00:56:46
>>198
日雇いのバイトで得た給料を次の日にパチンコでなくすようなやつなんだ。
そっとしといてやれよ。
201:デフォルトの名無しさん
05/10/09 01:00:55
プログラミングヲタよりは（ｒｙ
202:デフォルトの名無しさん
05/10/10 13:13:40
>>200
その日の内にだろ
203:デフォルトの名無しさん
05/10/10 16:34:14
>>202
夜勤の場合はその通りだな。
204:デフォルトの名無しさん
05/10/10 21:48:37
ここにいるひとってやっぱ電車男みたいな人ばっかり？
俺は電車男そのものだけど・・・orz
205:デフォルトの名無しさん
05/10/11 00:50:45
電車男って、アニメオタクでプログラミングなんてしないんじゃ？ （テレビしか見てないけど
206:デフォルトの名無しさん
05/10/11 00:51:50
電車男はあまりオタクじゃないよ
完全に消費者だし
207:デフォルトの名無しさん
05/10/11 01:27:57
もはやC++/CLIはどうでもよくなってる罠
208:デフォルトの名無しさん
05/10/11 01:31:00
>>168逝って良し
209:デフォルトの名無しさん
05/10/11 11:16:33
>207
必死に自作自演してるんだよ。ほっとけ
210:デフォルトの名無しさん
05/10/20 02:58:49
へー、pure Java の CLRなんてあるのか。
逆もあれば、無限に重ねられるな
211:デフォルトの名無しさん
05/11/05 01:08:45
>>210
詳しく
212:デフォルトの名無しさん
05/11/05 13:22:36
C#のほうが気になる
213:デフォルトの名無しさん
05/11/10 01:23:28
>>210
ただでさえ重いCLRをJavaなんかで実装したら使い物にならんだろ
214:デフォルトの名無しさん
05/11/18 01:03:42
C#もっと速かったら使いやすいし、いいんだけだな～
215:デフォルトの名無しさん
05/11/20 01:35:04
釣れなかったみたいだねﾌﾟｹﾞﾗ
216:デフォルトの名無しさん
05/11/22 07:00:04
checked statement なぜ使えないのだろうか...orz
217:デフォルトの名無しさん
05/11/22 08:16:08
C++/CLIをちょっと.NETのライブラリとか使いたい部分だけマネージにして後はほとんどアンマネージにしてる人って居る?
その場合の速度知りたいんですが･･･
C#ちょっともっさりしすぎ。
218:デフォルトの名無しさん
05/11/22 13:42:52
>>217
部分的にでもCLRを呼び出している以上起動時のもっさり感は変わらない。
P/Invokeよりは高速とはいえ、ネイティブ－マネージドの遷移は負荷が高いから
混ぜたいなら呼び出しの単位は大きいほうがいい。
画面まわりをネイティブで書いて、メニューからのイベントをマネージドで
処理するような使い方（またはその逆）は向いているが、
特定のロジックをネイティブにして頻繁にマネージドコードから呼び出すのには向いていない。
219:デフォルトの名無しさん
05/11/22 20:50:52
ホスティングすればいいんじゃないの？＞起動の遅さ
URLﾘﾝｸ(d.hatena.ne.jp)
220:デフォルトの名無しさん
05/11/22 21:33:23
STL.NETはどこからダウソできるん？
221:デフォルトの名無しさん
05/11/24 09:32:05
STL.NETじゃね？
222:デフォルトの名無しさん
05/11/24 11:46:15
> ネイティブ－マネージドの遷移は負荷が高い
え？
223:デフォルトの名無しさん
05/11/25 01:21:05
>>219
だたホスティングしてもmscoree.dll をCOMで呼び出すだけだからあまり変わらない気がするが、
同じプロセス空間に複数のアップドメインを作ってアセンブリを起動するシェルのようなものを作れば、
それなりに起動は速くなるかもしれないですね。
>>222
え？ managed codeからnative codeをオーバーヘッド無しで呼べるといいたいのかな？
224:デフォルトの名無しさん
05/11/25 01:44:09
呼べるでしょ。
データの受け渡しにコストがかかるだけで。
225:デフォルトの名無しさん
05/11/25 01:47:36
>>224
呼べません。
226:デフォルトの名無しさん
05/11/25 01:53:34
一見そのまま呼べるかのように振る舞うだけじゃなかったか
227:デフォルトの名無しさん
05/11/25 02:04:50
オーバーヘッドって具体的にどんな処理してるんだろ。
228:デフォルトの名無しさん
05/11/25 02:08:03
マーシャリングとかじゃね？
229:デフォルトの名無しさん
05/11/25 02:12:24
マネージドとネイティブの世界には分厚い境界線
なるものが存在するんですよ。
その境界線を越えようとするものは某北朝鮮から脱国するがごとく
リスクを負わなければならないのですよ。
230:デフォルトの名無しさん
05/11/25 06:46:32
intしか使わないネイティブを、
SuppressUnmanagedCodeSecurity, LinkDemandすればコストほとんどなしなんじゃないの?
構造体もValueType使えば、ボクシング/アンボクシング行われないしね。
231:デフォルトの名無しさん
05/11/25 09:22:48
>>229
つ Borland(R) Developer Studio 2006 URLﾘﾝｸ(www.borland.co.jp)
マネージドとネイティブをコンパイルで切り替えだお。
232:デフォルトの名無しさん
05/11/25 11:14:41
value class制限大杉
233:デフォルトの名無しさん
05/11/25 21:30:37
ref structとvalue classの違いは？
ref structって値型じゃないの？
ref classとref structの違いって何よ？デフォルトpublicとprivateの違いだけ？
234:デフォルトの名無しさん
05/11/25 22:31:14
ref ←→ 値型
ref class と ref struct の違いは class と struct の違いと同じ
ref 型がCLRに管理されてるクラス。value 型は primary な値を意味するクラス
235:デフォルトの名無しさん
05/11/25 22:44:30
OKありがとう。とてもわかった
236:デフォルトの名無しさん
05/11/25 23:02:55
値型だと
デフォルトコンストラクタ
コピーコンストラクタ
デストラクタ
ファイナライザ
代入演算子
が定義できなかったよ。
デフォルトコンストラクタが定義できないんで引数無しのタグクラス食わせてるんだけど
何かあるんだろうか...
それとデストラクタが定義できないせいで単純にnewすると解放ができない。
237:デフォルトの名無しさん
05/11/25 23:07:16
>>236
C#って知ってる？
238:デフォルトの名無しさん
05/11/25 23:08:24
> newすると解放ができない。
なんか言ってることおかしくない？
解放って？
239:デフォルトの名無しさん
05/11/25 23:12:33
>236
値型は primary な型を作るためのものだから、int とかにデフォルト・コンストラクタや
ファイナライザを定義しないでしょ？
240:デフォルトの名無しさん
05/11/25 23:13:13
>>236
値型は、初期化しによる初期化、代入などで、
memcpyが行われるだけでいいようなオブジェクトに使う。
定義できなかったと言うより、定義しないでいいものに使う。
241:236
05/11/25 23:15:45
>>238
template <typename T,typename TAG>
value struct a
{
T *p;
a(TAG)
{
p = new T();//NativeC++のスマートポインタが使えないのでCLIなスマートポインタが必要ぽい
}
};
242:236
05/11/25 23:21:43
>>239,240
参照型だとコピーコンストラクタいちいち用意するの面倒じゃん。
C++とC++/CLI両対応のソース書きたいので値型にしてる。
243:デフォルトの名無しさん
05/11/25 23:38:57
>>242
.Netでは「クラスは参照型」となっているのだからいつか破綻する。
244:デフォルトの名無しさん
05/11/25 23:40:16
それは思考が逆で、
コピーコンストラクタが必要ないから値型にしているのであって、
面倒だから参照型を使わないんじゃない。
245:デフォルトの名無しさん
05/11/25 23:41:57
値型か参照型かは性能にもろに影響してくるから
適切に選択した方がいいよ
246:デフォルトの名無しさん
05/11/25 23:56:47
普通にクラスを書けばいいんじゃないか？
わざわざ値型で定義しようとするから、苦労しているだけだと思うが
247:デフォルトの名無しさん
05/11/26 08:19:50
>>45
LLVMがgccに入りそうな勢いだなあ。
248:デフォルトの名無しさん
05/11/28 09:42:42
参照を初期化リストで初期化できないのですが、
なぜなのでしょうか？
value struct UseRef
{
explicit UseRef(int& in_i)
:i(in_i)
{}
int& i;
};
ref struct TestRef
{
int i;
UseRef r;
TestRef()
:r(i)
{}
};
249:デフォルトの名無しさん
05/11/28 13:52:01
値型は生成時にデフォルト値を持つ必要がありますが、標準C++ の int 型はデフォルト値を
規定されていません。そのため、生成時に不定となる値の参照を型として保持できないと思われ
250:248
05/11/28 16:40:53
>>249
ありがとうございます。
参照型でも試してみましたが、やはりだめみたいでした。
一度、GC Heapにgcnewしてそこからinterior reference？(int%)を取得することで
参照のように扱うことはできました。
どうも値型のメンバには値型かGcHeap(Cloneされる)しかおけないようです。
また、interior ptr|referenceのときもクラスのメンバにはできないようです。
251:デフォルトの名無しさん
05/11/28 18:05:46
まぁ、仕様書見るとそう書いてありますね
252:デフォルトの名無しさん
05/11/28 22:05:15
俺の勘で。
ref struct TestRef
{
int i;
UseRef r;
TestRef() : i(0), r(i)
{}
};
253:デフォルトの名無しさん
05/11/29 16:38:04
UseRef のデフォルト・コンストラクタが不定値を持つから駄目ぽ
254:デフォルトの名無しさん
05/12/01 17:33:26
組込型だと
普通の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
255:デフォルトの名無しさん
05/12/02 02:00:31
なんだか汚い言語になっちゃいましたね
perlみてー
256:デフォルトの名無しさん
05/12/02 03:41:08
C++が汚いのはもとからだろ
257:デフォルトの名無しさん
05/12/02 07:44:32
>>255
思いつきで拡張してるよね。
C++の世界では有名な人達がやっているんだが…
258:デフォルトの名無しさん
05/12/02 07:49:14
だれだっけ？
259:デフォルトの名無しさん
05/12/02 08:28:53
Stanley Lippman
URLﾘﾝｸ(staff.develop.com)
URLﾘﾝｸ(blogs.msdn.com)
URLﾘﾝｸ(www.microsoft.com)
Herb Sutter
URLﾘﾝｸ(www.gotw.ca)
URLﾘﾝｸ(blogs.msdn.com)
URLﾘﾝｸ(www.microsoft.com)
260:デフォルトの名無しさん
05/12/02 12:51:52
Perlは美しい。C++もああいうの目指すべき。
261:デフォルトの名無しさん
05/12/02 13:27:41
>>260
漏れはあまり詳しくないんだが、そうか？？？本当にそうなのか？？？？？？？
262:デフォルトの名無しさん
05/12/02 15:34:59
そんなあなたに Brainf*ck
263:デフォルトの名無しさん
05/12/03 00:57:17
>>255-257
良くも悪くもC++的っていう気はする。
264:デフォルトの名無しさん
05/12/03 11:30:30
C++は細かいところで汚いなりに、それなりのポリシーがあったが、
C++/CLIに至ってはなんでもありだ。実装の都合としか思えないものもある。
265:デフォルトの名無しさん
05/12/03 19:46:54
C++をぐちゃぐちゃにしC++コミュニティーを崩壊させる。
↓
C++の衰退とC#の反映
266:デフォルトの名無しさん
05/12/03 20:47:05
Ｃ＃はメジャーにならない
断言する
267:デフォルトの名無しさん
05/12/03 21:11:34
名無しで断言されても……
268:デフォルトの名無しさん
05/12/03 22:04:56
>>265
それか！！
269:デフォルトの名無しさん
05/12/04 18:49:26
C++/CLIの設計コンセプトは「拡張機能を使わなければ、既存のC++と変わらないこと」だから
別にC++に変な影響を与えないと思うけど
270:デフォルトの名無しさん
05/12/04 20:03:25
果たしてそうかな
271:デフォルトの名無しさん
05/12/04 20:18:12
>>270
そうだよ。
272:デフォルトの名無しさん
05/12/04 20:56:43
関係ないが、親玉格のC(99)がやらかしてくれてるからなあ。
273:デフォルトの名無しさん
05/12/04 21:15:11
C++はまだ「生きた」言語なんだよ。
まだまだ進化する。
274:デフォルトの名無しさん
05/12/04 21:41:25
ここに書いて良いのかわからんかったんですが。
タスクマネージャーの「CPU使用率の履歴」みたいな動的な(?)グラフを出せるものを書きたいのですが
何から手をつければいいのか、全くわかりません。
アドバイスよろしくお願いします。
275:デフォルトの名無しさん
05/12/04 21:46:55
age
276:デフォルトの名無しさん
05/12/04 22:13:21
>>274
とりあえず↓この本読め。
URLﾘﾝｸ(www.amazon.co.jp)
277:デフォルトの名無しさん
05/12/05 09:58:09
>>272
C99のマズイところでどんなとこ？
得に思い当たらないんだけど
278:デフォルトの名無しさん
05/12/05 11:34:16
エラーのthrow/catchが、cとc++で別になったのは痛い。
MFCとC++、C丼とC++、MC++とC++、C++CLIとC++、それぞれ結局別物と思われてるところも痛いけど。
279:デフォルトの名無しさん
05/12/05 11:43:35
実際別物
280:デフォルトの名無しさん
05/12/05 15:13:07
MFCを持ち出してくるところが痛い。
281:デフォルトの名無しさん
05/12/05 15:30:50
MFCって、mc++とかC++/CLIから使えるんだっけか？
282:デフォルトの名無しさん
05/12/05 18:32:19
C++/CLIやmc++の構文を使ってないコードを /clrでコンパイルしたものを
C++/CLIやmc++のプログラムと読んでいいかどうかによるけど、
そう呼んでいいなら使える。
283:デフォルトの名無しさん
05/12/05 18:41:23
managed と unmanagedの型でデータ交換したいのですが、
COMを使うしかないのでしょうか？
284:デフォルトの名無しさん
05/12/05 19:07:05
>>283
具体例を挙げてわかるように質問してくれ。
285:デフォルトの名無しさん
05/12/05 19:10:17
＞/clrでコンパイルしたものを
どういったオプションでつか？
286:283
05/12/05 19:33:39
>>284
混合クラスにできないだけで、
別クラスにしておいて呼び出しは可能だったのね...
Marshalingできる時はしたほうがいいのかな
URLﾘﾝｸ(msdn2.microsoft.com)(en-US,VS.80).aspx
287:修正
05/12/05 21:25:49
unmanagedからmanagedの呼び出しはできないみたい。
288:デフォルトの名無しさん
05/12/05 22:45:23
CLRホスティング・・・
289:デフォルトの名無しさん
05/12/06 03:01:26
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
290:デフォルトの名無しさん
05/12/06 07:34:09
最強
291:デフォルトの名無しさん
05/12/06 10:52:01
unko
292:デフォルトの名無しさん
05/12/07 23:15:01
C++/CLIの存在意義って？
マネージならC#でよくね？
293:マイク ◆yrBrqfF1Ew
05/12/07 23:19:32
そうだな。
294:デフォルトの名無しさん
05/12/08 00:28:08
やっぱりC#?
C++から移植するのってどれぐらい工数かかるんだろうか・・・・
295:デフォルトの名無しさん
05/12/08 00:32:04
ぶっちゃけ、WindowsアプリならVC++6&MFCが最強では？
あえてC#を覚えようとする気がしない。
VC++6&MFCでつれないWindowsアプリはない。
296:デフォルトの名無しさん
05/12/08 00:39:03
かわいそうな人
297:デフォルトの名無しさん
05/12/08 01:10:46
あえてCを覚えようという気がしない。
機械語で作れないwindowsアプリはない。
298:デフォルトの名無しさん
05/12/08 01:24:49
あえて計算機を覚えようという気がしない。
脳内で計算できない問題はない。
299:デフォルトの名無しさん
05/12/08 06:10:14
切り返すなら同じ性質の物事を書かなきゃ :-P
300:デフォルトの名無しさん
05/12/08 08:16:12
>>297
俺も未だに機械語で書いてるよ
Cだとおせーから嫌だ
301:デフォルトの名無しさん
05/12/08 08:28:05
>>295
なるほど、いろんなWindowsアプリさんたちが釣れるようでつね。
302:デフォルトの名無しさん
05/12/08 11:44:15
>>295はLonghornが出たら干される使い捨てデジドカ
303:デフォルトの名無しさん
05/12/08 20:59:47
OSが記述できてしまう
C++は絶対に廃れないよ
しかも、デバイスドライバを書ける人は絶対に不可欠
C#やJAVAなんてモノが出来ても結局また
新たな言語が出てきて廃れるのは必至
304:デフォルトの名無しさん
05/12/08 21:14:47
つまりCOBOLと似たようなもんだ。
新しい言語の出現で全盛期より減ったとは言え、需要がなくなることはありえない。
305:デフォルトの名無しさん
05/12/08 21:44:19
歩く死体か。
306:デフォルトの名無しさん
05/12/09 02:03:11
Cで必要にして十分な件。
307:デフォルトの名無しさん
05/12/09 11:02:38
既存のプログラムが全部マネージ環境で通るようにライブラリとか
整えて欲しい。
printfやstrcmp使うとネイティブとの混合アプリになっちゃうんでしょ？
標準ライブラリの中も.NETにすりゃあいいのに。
308:デフォルトの名無しさん
05/12/09 11:24:49
混合になってなんかマズイことでもあるのかい？
309:デフォルトの名無しさん
05/12/09 13:12:07
>>307
あなたは根本的にCLIの世界を理解してないです。
310:デフォルトの名無しさん
05/12/09 16:26:18
>>308
混合だとWin以外に持っていけるの？（あるかはしらんけど）
あと、切り替え時に異様に遅い感触。
>>309
根本を教えてくれ
311:デフォルトの名無しさん
05/12/09 16:43:46
感触って君の思い込みのこと?
312:デフォルトの名無しさん
05/12/09 16:53:06
>>311
/clrつけてコンパイルしなおしたプログラムが異様に遅い。
.NETにしてもちょっと遅すぎると思ってね。原因がネイティブ
部分の呼び出し負荷くらいしか思い当たらない。
313:310
05/12/09 17:37:18
簡単なやつで試してみた。環境は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でもインライン展開されるのかな？
314:310
05/12/09 17:42:54
>>313の例ではネイティブへの切り替え以外に負荷になる要素は
無いと思うんだが、識者の意見希望。
315:デフォルトの名無しさん
05/12/09 18:51:09
関数の処理が遅いのか、CLR の起動に手間取っているのかは、ちゃんと分けた？
316:310
05/12/09 19:01:59
>>315
my_stricmpを使ってネイティブと時間の差が無いのだから、
起動時間の問題じゃないと思う。
あと、ループの回数を増減させれば処理時間も比例する。
317:デフォルトの名無しさん
05/12/09 20:03:25
>>313
strcmpは？stricmpだとCLIの方はロケールとかで色々面倒くさい
ことしてそう。
318:デフォルトの名無しさん
05/12/09 20:56:41
>>313
ではlstrcmpはどう？
これなら絶対にインライン展開できない。
319:310
05/12/09 21:15:00
>>318
lstrcmp,これから試してみるけど先に質問。
>>317に関して、
俺、やはり根本が分かって無い模様。strcmpは313に書いた通りなのだが、
stricmpの場合でも、CLIからネイティブと同じルーチンが呼ばれるもんだと
思っていた。
この前提で、中身が一緒なら呼び出してる部分に負荷があるんじゃないかと
思っていたわけだが、ネイティブとCLIで呼び出されるstricmp（に限らず標準
ライブラリ全般）は別物なの？
320:デフォルトの名無しさん
05/12/09 22:17:02
>>319
その試した見たというコードをどこかのアップローダに晒すというのは
どうだい？そうすれば同じ土俵で話ができる。
321:310
05/12/09 22:54:16
>>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;
}
322:デフォルトの名無しさん
05/12/09 22:55:34
アセンブリ（アプリケーション）で閉じてる範囲に置いては、CLIはロードされないんじゃね？
323:310
05/12/09 23:02:41
>>322
意味が分かりませんorz
324:デフォルトの名無しさん
05/12/09 23:06:31
>>321
> つーことはやはり呼び出し負荷でしょう。
それ言うなら、
> もちろんループ回数も同じで測定している。
回数変えてファクターが何か調べないと。面白い奴だな(w
325:310
05/12/09 23:10:53
>>324
回数変えたら実行秒数が比例するけど。
my_stricmpにしてネイティブと差が無いわけだから、違いは
標準ライブラリの呼び出し以外に何か考えられる？
326:デフォルトの名無しさん
05/12/09 23:20:29
y = ax + b の a を比べろと言えば分かりますか?
327:310
05/12/09 23:27:29
>>326
何を言ってるのか分かりませんが、
具体的に他にファクターがあるならあげてみて欲しい。
こちらの比べ方に抜けがあるならそこを指摘してくれまいか。
328:デフォルトの名無しさん
05/12/09 23:31:27
ちょっと、煽りと神経質になってる人もいるみたい
まぁ、とりあえず、時間の出たマシンのスペックを教えてちょ
問題になっているのは、msvcm80.dll 辺りかな
329:デフォルトの名無しさん
05/12/09 23:54:07
回数を2倍にしても実行時間が2倍になるとは限らない。
325に比例するとは書いてあるけど、比例にもいろいろあるだろうに。
330:デフォルトの名無しさん
05/12/10 00:00:17
いや、確認した。これは、なんだろう
比較のサンプルソースを出すね
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を切り替えるだけで、全然速度が違う。なじぇ？
331:デフォルトの名無しさん
05/12/10 00:19:19
ﾜﾗ
332:デフォルトの名無しさん
05/12/10 00:28:24
まるで見当はずれかもしれませんが
int mycomp(,,,) の前に #pragma unmanaged を置いてみるとどうなりますかね？
333:330
05/12/10 00:53:42
ごめん。これは速度が違って当たり前だった。ろくにチェックしていない
before をちゃんとチェックすると、だいたい１６秒でstrcmpと変わらない
むしろ、ネイティブだと一瞬なんで、処理に時間がかかる理由が気になる
334:330
05/12/10 01:08:50
すまん。>>333 は元の関数のコメントアウトをしてなかったorz
mycompにすると一瞬で終わるね。もうちょっと、関数の実装をちゃんとするべきなんだろうけど
ネイティブに記述された関数はネイティブで処理されてる。となると、C標準関数が問題
なのか・・・
335:310
05/12/10 08:50:45
>>329
＞回数を2倍にしても実行時間が2倍になるとは限らない。
それは比例じゃないと思うけど。
言葉どおり比例と受け取って欲しい。
だからループ外のファクターでは無いと思う。
>>334
マシンの速度が分からないけど、200万回のループで１６秒もかかる？
あと、strcmpだとこちらではCLIでもネイティブと同じだった。
stricmp,lstrcmpで、ネイティブとの差が2億回のループで10秒。
差が同じなので、処理内容の問題でも無いと思う。
こちらのマシン速度は>>313です。
336:310
05/12/10 10:00:02
>>329
言葉が足んなかった、すまん。ax+bのbの部分はごく小さいと思って欲しい。
>>332
試してみた。
CLIでmy_stricmpをunmanagedプラグマで囲ったら、少しだけ遅くなった（３秒くらい）。
囲わなかった場合、今朝計り直してみたら１秒未満。
337:デフォルトの名無しさん
05/12/10 10:26:32
「思って欲しい」(w ってんじゃなくて、普通は i<2000000 だけじゃなく、
i<500000、i<1000000、i<2500000も取ってグラフをプロットするわけ。
あと、*cmp("abcdefghijklmnopqrstuvwxyz", "abcdefghijklmnopqrstuvwxyz")と、
*cmp("buffer", "Test")で比較するとかさ。
関数呼び出しのオーバーヘッドをみたいなら、
関数内の処理を軽くしたり重くしたりして違いを見るのが定席だろ?
strcmpとmycompじゃ実装が全然違うわけだから、そのくらいはしないと、
呼び出しがオーバーヘッドになっているかどうか分からない。
一文字目の比較で関数が返るから、関数呼び出しの差を見えると思ったかもしれないが、
ソースのない方はもしかしたらNULLチェックしているかもしれないし、
タコなコーディングかもしれない。
分からないはずなのに安易に結論づけているから、スルーされてる。
表計算ソフト、数式処理ソフト、グラフプロットツールあれば簡単にグラフ化できるよね。
338:デフォルトの名無しさん
05/12/10 10:37:48
・・・2億回で10秒って、別に違いがあって不思議じゃないよな？
339:310
05/12/10 10:56:43
>>338
単純化しただけであって、回数そのものは突飛でもない。
俺が問題にしてるのはCLIで標準関数呼び出しが遅い
ということ。>>337のいうようにちゃんとやることも出来るが、
そこまでやら無くても「CLIで標準関数呼び出しが遅い」のは
今までの例で明白じゃない？
340:デフォルトの名無しさん
05/12/10 11:15:41
最適化の違いだけだったりして
自分で言ってるけど、strcmp でネイティブと違いがないなら「CLIで標準関数呼び出しが遅い」
とは言えないんじゃない？
341:デフォルトの名無しさん
05/12/10 11:28:40
>>339
明白かどうかわかんないから粘着してんじゃないの？
他のファクターを探す手助けにもなるんだから手抜かずにやれば？
342:デフォルトの名無しさん
05/12/10 11:32:24
最適化で思ったんだけど、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;
}
343:342
05/12/10 11:37:56
あ、すまん。濡れ衣だな。パフォーマンスの違いと詰め込み時間を考えれば、妥当か
ちなみに、/clr では同等のソースで11秒だった
344:310
05/12/10 11:38:06
>>340
遅まきながらステップしてみた。
strcmpはCLIでもインライン展開されていた。
stricmpはcallされていて、スタックトレースウインドウに
マネージからネイティブへ以降、と表示される。
345:342
05/12/10 11:48:28
漏れの環境での比較と詰め込みの結果
CLR native
strcmp 11s 8s
stricmp 16s 13s
lstrcmp 20s 17s
なんか、綺麗な結果になった。CLR の起動コストとかで +3s ぐらい
346:310
05/12/10 11:50:27
>>341
1回、1億回、2億回でほぼ直線状に並んでたから比例と書いた。
１回なら起動の時間は気にならないくらい一瞬で終わる。
347:310
05/12/10 11:52:44
>>345
ループ1回で+3sかかりますか？
348:デフォルトの名無しさん
05/12/10 12:39:12
>347
それはなかった。何らかのコストがかかっているのは確かみたい
CLR 側のやつはDateTime とか Console::WriteLine を使っていたので、ソースを完全に
同一にすると、
lstrcmp 19s 17s
になった。1億回のループでこれだから、あとはパフォーマンス・カウンタでも使わないと
細かくはわからない領域だと思う
ちなみにいろいろと切って静かに取ってみたら
CLR Native CLRx64 Nativex64
lstrcmp 16s 14s 15s 12s
なんて結果になった
349:310
05/12/10 12:52:57
>>348
342のソースはSTLの負荷が大きいのと、strcmpはインライン化されて
マネージ、ネイティブの切り替えは見えにくくなってると思う。
だから純粋にネイティブとCLIの差じゃなかろうか。
STLとっぱらってstricmpとかだけにしたらこちらの結果と
相似に近いのが出るんじゃないかな。
STLはマネージ側で実行されるんでしょ？ だからネイティブとの
大きな差にはならないんじゃないのかと。←こっちより差が小さいから
350:デフォルトの名無しさん
05/12/10 12:59:11
>349
んにゃ。STLはネイティブだよ。ループで代入しているのは、最適化でループ自体が外される
のを防ぐため
しかし、CLRx64 にはもうちょっとがんがってほすぃ
351:310
05/12/10 13:01:25
>>350
>STLはネイティブだよ
ありゃそうなの？ テンプレートっつーくらいだから
マネージとしてコンパイルされてるのかと思った。
352:デフォルトの名無しさん
05/12/10 13:05:46
>351
それはジェネリクスを利用した STL.NET と混同してるんじゃないかな
しかし、+2秒はいったい何をしているのだろう
353:デフォルトの名無しさん
05/12/10 13:18:58
気になったので試してみた
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
なかなか、よい結果です
354:デフォルトの名無しさん
05/12/10 22:23:25
>>346
数学苦手だった人?
355:デフォルトの名無しさん
05/12/10 22:28:52
直線と言っても限りなく水平に近いものから限りなく垂直に近いものまであるわけで。
356:デフォルトの名無しさん
05/12/11 00:48:46
>>353
ｽｹﾞｰな
357:デフォルトの名無しさん
05/12/11 03:32:29
.net2.0SDKにはC++/CLIのコンパイラって付いてくるの？
managedC++は？
358:デフォルトの名無しさん
05/12/11 04:57:42
ついてこない。
359:デフォルトの名無しさん
05/12/11 05:03:06
えええええええええええええ
360:デフォルトの名無しさん
05/12/11 07:55:17
.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にあると思っている。
361:デフォルトの名無しさん
05/12/11 07:58:58
>357
cl /clr
cl /clr:oldSyntax
ってやってみな
362:デフォルトの名無しさん
05/12/11 08:05:27
>>360
つか、今時Win32 APIをコールする必要があるか？？？
363:デフォルトの名無しさん
05/12/11 08:56:21
ある
364:デフォルトの名無しさん
05/12/11 10:14:33
>>362
まだ大いにあるよ。
365:デフォルトの名無しさん
05/12/11 10:49:56
>>362
君にはない。
366:デフォルトの名無しさん
05/12/11 11:11:19
>>362
今時っていうか、今程度の.netじゃ、
まともなWindowsプログラミングやるならWinAPI叩かざるを得ない。
367:デフォルトの名無しさん
05/12/11 12:15:19
激同
368:デフォルトの名無しさん
05/12/11 19:40:02
>>366
そうか～？
.NET Frameworkのクラスライブラリだけですべて作れますけど・・・
369:デフォルトの名無しさん
05/12/11 20:06:45
いまんところ直面した問題
・ＩＭＥ
・Ｃａｒｅｔ
・ScrollWindowEx
370:デフォルトの名無しさん
05/12/11 20:08:00
>>369
初心者スレ行けばｗ
371:デフォルトの名無しさん
05/12/11 20:15:13
>>370
あほか。流れ嫁。API呼ばなきゃいけない問題だ。かす。
372:デフォルトの名無しさん
05/12/11 20:22:17
>>371
初心者スレ行けばｗ
373:デフォルトの名無しさん
05/12/11 20:29:00
>>368
SHFileOperation
VBのMyを使えとか言ったら刺す。
374:流れを読んでレス
05/12/11 22:03:40
>>371
初心者スレ行けばｗ
375:デフォルトの名無しさん
05/12/11 22:21:02
>>368
FileDialogのカスタマイズ
376:デフォルトの名無しさん
05/12/12 00:10:36
>>375
初心者スレ行けばｗ
377:デフォルトの名無しさん
05/12/12 01:51:23
こう見るとできないことだらけだね。
MSはどうするつもりなんだろう
378:デフォルトの名無しさん
05/12/12 09:21:36
そのためのC++/CLIじゃないか
379:デフォルトの名無しさん
05/12/12 23:05:18
>>368
ありふれた業務アプリ程度ならそれほど困ることもないけど、
ちょっとばかしシステムに寄った途端にできないことが増える。
原因が（専ら機能面とは何の関係もない）くだらない要求だったりして
余計に萎えるというおまけが付くこともよくある。
>>377
とりあえず使い物になるVer.3を出せと言いたい。
380:デフォルトの名無しさん
05/12/13 09:00:43
>原因が（専ら機能面とは何の関係もない）くだらない要求だったりして
>余計に萎えるというおまけが付くこともよくある。
あるあるｗｗ
381:デフォルトの名無しさん
05/12/13 15:22:20
URLﾘﾝｸ(s03.2log.net)
正直賛同できません。
382:デフォルトの名無しさん
05/12/13 17:15:19
Cに勝る言語はないってことだな
383:デフォルトの名無しさん
05/12/13 20:46:50
Win32への依存度を下げる必然性がないんだから当たり前でしょ？
384:デフォルトの名無しさん
05/12/13 21:47:52
Win95が出たときの3.1使いもそう言ってた
385:デフォルトの名無しさん
05/12/14 17:36:34
Win16→Win32s→Win32のこと?
あれは言語一緒だしね…
386:デフォルトの名無しさん
05/12/15 05:37:15
技術的な需要もないことはないけど、それよりただ新しいWindowsを
作らないといけないことだけが先行してるのが萎える。市場に対して
新規性を謳うことだけが最重要課題なんだよな。
387:デフォルトの名無しさん
05/12/15 20:41:33
次は ISO だな
URLﾘﾝｸ(www.ecma-international.org)
388:デフォルトの名無しさん
05/12/16 00:54:50
ISOは無理。
389:デフォルトの名無しさん
05/12/16 00:59:57
C#はISOだぞ
C++/CLIだってきっと
390:デフォルトの名無しさん
05/12/16 08:57:14
CLI は ISO で標準化されてたっけ？
391:デフォルトの名無しさん
05/12/16 10:32:21
CLI 標準はこれだな
ISO/IEC 23271:2003
392:デフォルトの名無しさん
05/12/16 10:56:26
このへんね。
URLﾘﾝｸ(www.plumhall.com)
URLﾘﾝｸ(msdn.microsoft.com)
393:デフォルトの名無しさん
05/12/19 23:38:22
URLﾘﾝｸ(itpro.nikkeibp.co.jp)
に「VC++ExpressEditionは標準C++を学習するための優れた教材である 」
てあるけど、そうなの？
.NETのWindowsアプリ作るものかとおもってたよ。
394:デフォルトの名無しさん
05/12/20 00:04:06
とりあえずVC++は標準C++への準拠度が高いことに間違いない。
395:デフォルトの名無しさん
05/12/20 02:58:19
これまでは準拠してなかったということ？
396:デフォルトの名無しさん
05/12/20 09:38:58
そゆこと
それからC++でﾄﾞﾄﾈﾄすると飛んでも文法だし、
大体MFCはキショイというのが定説。
397:デフォルトの名無しさん
05/12/20 13:40:38
へぇ。２００５からはキショクはないのか。
VC++（というIDE）を使ってなかった人も使い出したりするんだろか？
398:デフォルトの名無しさん
05/12/20 20:36:35
IDEがVC6位軽ければみんな使うだろうに
399:デフォルトの名無しさん
05/12/20 22:31:59
自分の価値観を回りに押し付けないように
400:デフォルトの名無しさん
05/12/20 23:47:53
ただそこに意見が存在するだけで
押し付けられたとか思い込まないように
401:デフォルトの名無しさん
05/12/21 14:50:12
URLﾘﾝｸ(mag.autumn.org)
C++復権すると思う？
402:デフォルトの名無しさん
05/12/21 15:45:19
>現状で極めて私的な感想から言えば、>JavaとC#の
>代替プログラム言語になり得る第1候補はVisual Basicです。
403:デフォルトの名無しさん
05/12/21 20:16:06
>>401
復権もなにも
C++で記述できないプログラムはないんだから・・・
404:デフォルトの名無しさん
05/12/21 20:22:13
>>403
それは今のCPUがC言語を動かすことを前提としてる面も大きいと思う
405:デフォルトの名無しさん
05/12/21 20:28:41
CPUがC言語を動かす？
意味不明
406:デフォルトの名無しさん
05/12/21 20:32:45
0番付近がNULL対策に実メモリを割り当てないようになってたりするじゃん。
他にC言語で簡単に扱えないメモリレイアウトを要求しないとかさ。
407:デフォルトの名無しさん
05/12/21 21:27:10
>>406
> 0番付近がNULL対策に実メモリを割り当てないようになってたりするじゃん
これはOSの問題という側面のほうが大きいと思う。
別にC/C++ではヌルポインタのビットパターンは0でなくとも良いとなっている。
> 他にC言語で簡単に扱えないメモリレイアウトを要求しないとかさ。
そんなもん誰も要求していない。
408:デフォルトの名無しさん
05/12/22 07:22:14
>>406
x86のI/Oポートは「C言語」では叩けないよ。
喪前様が言ってるのは、例えるなら、見かけの現象だけで
「太陽は地球を回っている」と言ってるのと同じこと。
言語側から見るだけじゃ、本当の意味では計算機は理解できない。
計算機の基礎から勉強したほうがいい。
409:デフォルトの名無しさん
05/12/22 08:14:09
x86のI/Oポートをたたく必要がない
410:デフォルトの名無しさん
05/12/22 10:44:15
>>403
「brainfuck復権すると思う？」
「復権も何も、brainfuckで記述できないプログラムはないんだから……」
411:デフォルトの名無しさん
05/12/22 10:48:17
>>410
いまだにつかっていますが、なにか？
412:デフォルトの名無しさん
05/12/23 07:42:22
みんなの大好きなあの言語が.NETの仲間入り。
brainf*ck.NET
413:デフォルトの名無しさん
05/12/27 11:36:51
>412
ソースコードｷﾎﾞﾝ
414:デフォルトの名無しさん
05/12/27 21:13:53
C++/CLIの入門サイトってありますか
415:デフォルトの名無しさん
05/12/28 10:29:47
VB.NET のPGで、構文解析を行う必要が出たときに、
C++/CLI で boost.spirit 使って手軽に構文解析モジュール作成して、
VB.NET から参照設定で呼び出す
ってことが簡単に出来るならすばらしいことだと思うよ。
416:デフォルトの名無しさん
05/12/28 10:32:23
マルチランゲージは素晴らしい。
現実はJ#は開封もされない事実。
ﾌﾞﾋﾞ厨はＣ貧を嫌い、Ｃ貧はﾌﾞﾋﾞ厨を嫌う。
Ｍ＄の理想は宣伝専用。
417:デフォルトの名無しさん
05/12/29 00:42:11
>415
普通にできるけど？
418:デフォルトの名無しさん
05/12/29 05:23:34
C#で以下のようなコードを
using (FileStream fs = new FileStream("test.txt", FileMode.Read)) {
}
C++/CLIでうまくかけるんですか？
FileStreamをスタックみたいにして作れると思ったんですが、できないのでしょうか？
419:418
05/12/29 05:25:15
すいません。できました。ぜんぜんわかってませんでした。
420:デフォルトの名無しさん
05/12/29 17:16:57
>414
入門するようなもんじゃねぇだろ？
C# を先に勉強した方がいいぞ
421:デフォルトの名無しさん
05/12/29 20:22:02
このスレでC#を勧めるのはどうかと思う。
422:デフォルトの名無しさん
05/12/30 00:13:58
そうか？ 基本的にC++/CLIのターゲットは、今までC++をやってきた連中が .net
Framework を自由に使えるようにと言うことだろ
表面的な文法なら、ref や generics にプロパティ、delegate ぐらいしか増えないわけで
今までC++をやっていたのであれば、それほど大した変更じゃない
問題なのは、.net Framework を使えるか、それをC++/CLIではどのように融合させたのか
という点だから、それは入門じゃないだろ。C# の入門書見て、C++/CLI の構文での使い方を
知れば、十分なんじゃねえかと思われ
ダイレクトに C++ を知らずに、C++/CLI に手を出すのは、止めた方がいいだろ
423:デフォルトの名無しさん
05/12/31 08:04:27
>>422の言ってることは確かに理解できるし、俺もほとんど同意だが。
ここはC++/CLIについて語るスレなんだよなｗ
でもマジレスすると、入門サイトありますか？とか聞くようなレベルなら
さっさとC#かVBで始めたほうがいいと思う。
424:デフォルトの名無しさん
05/12/31 13:05:55
_asm{} とか書いたらどうなるんだ？って思ってやってみたら、
さすがに main() の中に書いたら怒られた。
関数単位でマネージド、アンマネージドが切り替わるんだね。
_asm{} 入りの関数はネイティブコードとして生成されるみたい。
その呼び出しをうまい具合にやってくれるのがいいね。
いや、C++/CLI で _asm{} 使うような機会があるかどうかは別として。
425:デフォルトの名無しさん
05/12/31 14:20:04
>424
C++/CLI の拡張構文ではグローバルな関数の存在を認めていない
だから、ただ関数を生成しただけでは、基本的にネイティブとしてコンパイルされる
はずだよ。main はさすがに扱いが違うけど
426:デフォルトの名無しさん
05/12/31 15:09:22
ふと思ったんだが boost on C++/CLI なんて可能だろうか。
ていうか、だったら素直に .NET Framework にある
便利クラス使えよって気もするが。
427:デフォルトの名無しさん
05/12/31 16:19:01
アセンブリ内で閉じてるなら平気だろ
CLI 拡張部を使わなければ、標準のC++であることが C++/CLI の設計コンセプトなんだから
できない理由はない。聞く前にやれば？
428:デフォルトの名無しさん
06/01/01 00:43:38
if ( DialogResult::OK != openFileDialog1->ShowDialog(this) )
return;
コンパイルできません＞＜
t:\dev\www\winform\winform\Form1.h(154) : error C2039: 'OK' : 'System::Windows::Forms::Form::DialogResult' のメンバではありません。
t:\dev\www\winform\winform\Form1.h(23) : 'System::Windows::Forms::Form::DialogResult' の宣言を確認してください。
t:\dev\www\winform\winform\Form1.h(154) : error C2065: 'OK' : 定義されていない識別子です。
ビルドログは "file://t:\DEV\WWW\winform\winform\Debug\BuildLog.htm" に保存されました。
winform - エラー 2、警告 0
========== ビルド: 0 正常終了、1 失敗、0 更新、0 スキップ ==========
429:デフォルトの名無しさん
06/01/01 00:46:55
if ( Windows::Forms::DialogResult::OK != openFileDialog1->ShowDialog(this) )
return;
こうしました＞＜
430:デフォルトの名無しさん
06/01/01 01:19:56
Ｃ＋＋／ＣＬＩやりたいやつが入門サイトを希望するなんて
ギャグ以外の何者でもないだろ。
431:デフォルトの名無しさん
06/01/01 12:25:43
CLIマッシーンってどんな環境を目指しているの？
そのうち出るかもしれない3DのUIとか検索ベースのFSまでのつなぎかな？？
432:デフォルトの名無しさん
06/01/01 13:21:49
いつかでるLISPマシンまでの繋ぎです
433:デフォルトの名無しさん
06/01/01 15:25:53
>C++復権すると思う？
それ以前にC++ってメジャーだったっけ？
434:デフォルトの名無しさん
06/01/01 19:16:48
>433
どっかの記事では1990年代は優勢とか、書いてあったな。
435:デフォルトの名無しさん
06/01/01 21:07:00
C++/CLIのライブラリは .NET のライブラリをそのままISO標準にするの？？
以前のライブラリを使えるのはいいけど、できればGCで楽したいなー。
436:デフォルトの名無しさん
06/01/01 21:58:51
1990年代の段階ではC言語の仕事ばっかりやらされていたな。
437:デフォルトの名無しさん
06/01/01 22:49:23
>>433
Java/C#なんかが出てくる前は優勢だったと言えるだろう。
ただしベターCとしてしか使われなかった割合も大きかっただろうが。
438:デフォルトの名無しさん
06/01/01 23:37:51
delegateとeventの違いがわかりません。
delegateだけでいいような気がするのですが。。。
eventが存在する理由を教えてほしいです。
439:デフォルトの名無しさん
06/01/01 23:40:52
delegateを簡単に扱うため
440:デフォルトの名無しさん
06/01/01 23:46:17
＞＞439
センセー！簡単になる場面が思いつきません＞＜
441:デフォルトの名無しさん
06/01/01 23:52:42
event なら delegate の呼び出しが外から出来ないでしょ
442:デフォルトの名無しさん
06/01/01 23:53:11
>>440
うるせーな。少しは自分で考えろ。
delegateは関数オブジェクトの取り扱いの簡便化ため。
eventはdelegateの呼び出しの簡便化のため
443:デフォルトの名無しさん
06/01/02 14:27:27
>>438
つか比較すること自体が変だ。
delegateは型、eventはメンバ。class(型)とメンバの違いが分かりませんって
言われたってこっちが説明に困るよ。
444:440
06/01/02 23:54:45
>>441
そこらへんが答えだと思うんですが、まだよくわかりません。
>>442
＞eventはdelegateの呼び出しの簡便化のため
は
＞delegateはdelegateの呼び出しの簡便化のため
でもいいとおもうんです。eventなど持ち込まなくてもできると思うんです。
>>443
例えば、
public delegate void LogHandler(string message);
public event LogHandler Log;
を
public delegate void LogHandler(string message);
public LogHandler Log;
と書いても動くと思うんです。
まだ.NET初心者なのではずしてるかもしれませんが。
445:440
06/01/02 23:56:41
あ、上のコード例はC#です。
446:デフォルトの名無しさん
06/01/03 00:10:51
event がないと AddListner やら RemoveListner を自前で実装せにゃならんのさ
447:デフォルトの名無しさん
06/01/03 00:38:44
>>444
あー、イベントというものが根本的に分かってないんだろう。
メンバで表現されるものを他の言語と比較すりゃわかると思う。
CLRでのクラスメンバにもてるものはフィールド、メソッド、「プロパティ」、「イベント」なのよ。
後者二つがあることがいわゆるC#が「コンポーネント指向言語」っていわれる理由でも
あり、ただのdelegateフィールドとは「まったく」別のもの。
こうやって特殊化したことによってTypeDescriptorやらで動的にコンポーネント情報を取得できる。
ちなみに 446 も言ってるが、イベントはフィールドとアクセサ(とメタデータ)でなるんだな。
public event EventHandler TextChanged;
と書いたときに生成されるのは
・privateなdelegateフィールド
・publicなadd, removeアクセサメソッド。
・イベントメタデータ
を生成している。
448:440
06/01/03 00:42:44
＞＞４４６
delegateにも += や -= はあるです。
449:440
06/01/03 00:46:05
＞＞４４７さんありがとう
即答できないので、調べてみます。
450:デフォルトの名無しさん
06/01/03 00:57:18
>>448
delegate をそのまま公開しちゃうと呼び出しが外から出来てしまうのが問題なのよ
ここはC++/CLIのスレじゃ？
451:デフォルトの名無しさん
06/01/03 14:54:46
.NETって使ったことないからよく分からないんだけど、
一度コンパイルしたものを、同じセキュリティーやらなんやらの設定の場合は
キャッシュしておいたコンパイル済みのコードを再利用することって出来ないの？
毎回毎回、プロセス起動のたびにコンパイルしてるのってバカみたいじゃね？
452:デフォルトの名無しさん
06/01/03 15:02:06
キャッシュされるしngenもあるし
453:デフォルトの名無しさん
06/01/03 19:56:52
>>451ってバカみたいじゃね？
454:デフォルトの名無しさん
06/01/04 12:32:46
>>453
何だ、生意気だぞ。 (ﾌﾟﾝｽｶﾌﾟﾝ
455:デフォルトの名無しさん
06/01/07 13:19:01
プログラムのあちこちから大量にアクセスする文字列型を、
いちいちUnicode文字の配列からgcnewするのはもったいないと思って
あらかじめ生成しておいたSystem::Stringをグローバルに持つことで解決しようかと思いました。
が、普通にやったらコンパイラに怒られたので試行錯誤の結果以下のようにしてみました。
（StringDataはSystem::Stringを大量に生成して格納するクラス）
StringData^* gpStringData;
int main(array<System::String ^> ^args)
{
StringData^ stringData = gcnew StringData();
gpStringData = &stringData;
（以下メイン処理）
}
もうちょっと行儀のよさげな方法ないですかね？
456:デフォルトの名無しさん
06/01/07 13:55:09
こう？
value struct StringData {
initonly static String^ A = L"AAA";
initonly static String^ B = L"BBB";
initonly static String^ C = L"CCC";
};
int main()
{
String^ a = StringData::A;
String^ b = StringData::B;
return 0;
}
457:455
06/01/07 13:56:25
ごめんこのへん↓参考にして自己解決
URLﾘﾝｸ(www.microsoft.com)
458:455
06/01/07 14:07:15
>456
今回の場合は、こちらの方法のほうがよさげですね
ありがとうございます
459:デフォルトの名無しさん
06/01/09 01:03:13
何というか、変態的というか。まぁ、それがC++の良さではあったわけ
だけれど。これではあまりにもコンパイラベンダ泣かせだ…可哀想に。
460:デフォルトの名無しさん
06/01/09 07:55:52
C++/CLI をフルに実装できるコンパイラベンダって、
MS以外にあるのかね？
とか思ってたら、 g++ が対応したらかなり驚く。
mcs と合体するとか。
461:デフォルトの名無しさん
06/01/09 12:07:26
すいません。質問があります。libpng.libなどを利用した昔のライブラリをC++/CLIで使おうとしたら、
コンパイル時に
libpng.lib(pngerror.obj) : error LNK2019: 未解決の外部シンボル __iob が関数 _png_default_error で参照されました。
libpng.lib(pngrutil.obj) : error LNK2001: 外部シンボル "__iob" は未解決です。
とか言われました。C++/CLIって_iobが使えないんでしょうか？
どなたか解決方法をご存じの方、教えてください。
462:デフォルトの名無しさん
06/01/09 14:18:44
Cの標準ライブラリlinkしてる？
463:デフォルトの名無しさん
06/01/09 14:32:49
ECMA-372ってISOになるときに内容が変更される可能性とかある？
ECMAは規格書が公開されるからいいけどISOはｼｮﾎﾞｰﾝだからさ。
464:デフォルトの名無しさん
06/01/09 14:57:32
一応、mscoree.lib msvcrt.lib msvcrtd.libはリンクしています。
あと、重複とエラーがでるので、libcmt.libはリンク無視しています。
開発環境はVC++ 2005 Express+PlatFormSDKです。
Win32プロジェクトだとlibpng.libを含んでもコンパイルは通るのに、
CLRプロジェクト(C++/CLI)だとうまく行きません・・・
VC++ 2005のstdio.hに_iobが定義されていないのが問題なのでしょうか？
(関係ないかもしれないけど)
465:デフォルトの名無しさん
06/01/09 17:50:19
libpngをソースから作り直したほうが早いよ。
zlibとlibpngのソースをDLしてdswとかslnとかを開いてビルドするだけ。
やったらWindows フォームアプリのプロジェクトに問題なく使えた。
ml.exeがVCExpressにはないので$(MSVS8)\VC\binにコピーしておくこと。
466:デフォルトの名無しさん
06/01/09 18:49:06
ありがとうございます！
試してみます。
467:デフォルトの名無しさん
06/01/09 20:48:36
>463
ECMA から ISO に回された仕様書はただで公開しているよ
468:デフォルトの名無しさん
06/01/09 21:05:35
>>467
へぇ、ありがとう
469:デフォルトの名無しさん
06/01/19 07:08:22
value struct B
{
literal System::String^ var = L"abcd";
literal System::String^ var2 = var+L"1212";
};
var2でエラーが出るんだが...だめなのか。(整数型intとかだと大丈夫だったんだけど...)
リテラル データ メンバの初期化子は定数指揮でなければなりません
470:デフォルトの名無しさん
06/01/19 07:57:19
literal System::String^ var2 = var + "1212";
は確かにエラーになるね。俺も今確かめてみた。
literal System::String^ var2 = "abcd" + "1212";
これでも同じエラーになる。結局は + 演算子を呼んでるからだろうな。
literal System::String^ var2 = "abcd" "1212";
ならエラーにならなかった。
というわけで、マクロ使え。ってことだと思う。
471:469
06/01/19 09:37:44
>>470
literal System::String^ var2 = var;
でもだめみたい。
static ctorでの初期化が許容できるなら
literal -> static initonly に変更するか、マクロにするしかないですね...
URLﾘﾝｸ(msdn2.microsoft.com)(en-US,VS.80).aspx
472:デフォルトの名無しさん
06/01/19 11:48:55
ふむぅ initonly なんてのもあるのか。
ところで、Visual Studio 2005 いじってて思ったんだけど、
C# に比べりゃリファクタリングなんかの点で
C++/CLI は扱いにくいと思うんだよ。
なのでほとんどの部分は C# でかいてるんだけど、
どうしても C++/CLI で書きたい部分もある。
C++/CLI で書いたコードと C# で書いたコードの
相互連携って可能なのかな？
具体的には、技術関連の計算をやるC++の自作ライブラリ、
結構大規模なモノがすでにある。GUI をつけるために
今までは計算結果をバイナリファイルに落として、
それを C# で作った可視化ツールで読み込んでた。
だけどインタラクティブにしたいんで C++/CLI 使えば
いいかなと思ったんだが、今まで C# で作ったGUI部分と
C++で書いた計算部分は C++/CLI で結婚できるのかと。
473:デフォルトの名無しさん
06/01/19 12:08:38
C++の計算用DLLをC#から使えばいいだけじゃん
474:デフォルトの名無しさん
06/01/19 12:12:25
>>472
今までは C++ -> COM経由 -> C#
これからは C++ -> C++/CLI
.NETでは C++/CLI <=>C#
475:デフォルトの名無しさん
06/01/19 12:18:13
>>473 C++な計算ライブラリの方は、クラスへの参照を
受け取って処理結果をその中に返すんですが、それでも
可ですか？ソース提供が基本のライブラリだったんで、
DLL化とかはしてなかったんですが、試してみます。