【.NET】 C++/CLI に� ..
2:デフォルトの名無しさん
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 型はデフォルト値を
規定されていません。そのため、生成時に不定となる値の参照を型として保持できないと思われ
次ページ最新レス表示スレッドの検索類似スレ一覧話題のニュースおまかせリスト▼オプションを表示暇つぶし2ch
5371日前に更新/240 KB
担当:undef