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

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

managed C++ やろうぜ!!

1 :デフォルトの名無しさん:02/02/24 02:47
C#関連のスレは山ほどあるが
managedC++のスレが無いじゃないか。
折角.NETに生き残ったC++、みんなで語ろうぜ。

2 :デフォルトの名無しさん:02/02/24 02:47
おお、
語ろう


3 :デフォルトの名無しさん:02/02/24 02:48
>1=>2

4 :デフォルトの名無しさん:02/02/24 02:49
1-2=3

5 :デフォルトの名無しさん:02/02/24 02:49
名スレの予感

6 :デフォルトの名無しさん:02/02/24 02:50
1-2+3=4

7 :デフォルトの名無しさん:02/02/24 02:50
1==2==3

8 :デフォルトの名無しさん:02/02/24 02:51
1^2^3^4^5^6=7

9 :デフォルトの名無しさん:02/02/24 02:53
v(^・^)v(^・^)v(^・^)v(^・^)v=1*3

10 :デフォルトの名無しさん:02/02/24 02:57
if(1から9まで同一人物だったら)
{
System.out.println("○○○");
}
の「1から9まで同一人物だったら」
の部分って
1==2&&1==3&&....
って書くのは長ったらしいので
何かいい方法ありますか?

11 :デフォルトの名無しさん:02/02/24 02:59
ポインタ、template、が生き残っただけでも凄い嬉しい。
と言う事はSTLもとおると言う事か・・・?
素晴らしい!!

12 :デフォルトの名無しさん:02/02/24 03:17
結局、
class CA{
public:
template<typename T>void func(T t);
};
template<typename T>void CA::func(T t){.......}
がエラーになるのは解決されたのだろうか??

13 :デフォルトの名無しさん:02/02/24 03:21
をを・・・解決されているみたいですな。
今試したら、ちゃんと動きましたよ。


14 :デフォルトの名無しさん:02/02/24 04:41
何てこった・・・.NET SDKには<iostream.h>が入ってない。
さようなら、cout・・・・

15 :デフォルトの名無しさん:02/02/24 04:49
マナゲドって何よ?

16 :デフォルトの名無しさん:02/02/24 04:53
>>14
普通のSDKと.NETのSDKは
C++の扱いは違うの?
.NETのC++はあくまでmanagedコードを
書くためのものなのかな?

17 :デフォルトの名無しさん:02/02/24 04:54
man=男
aged=ageの過去形

18 :デフォルトの名無しさん:02/02/24 04:54
>15
ネタだよな・・・?

19 :デフォルトの名無しさん:02/02/24 05:03
>>15
マグドナルドの経営する中華風ファーストフード店の名称です。

20 :デフォルトの名無しさん:02/02/24 07:57
どうせなら「相談室」スレにしたら良かったのに。

21 :デフォルトの名無しさん:02/02/24 09:13
Ruby >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> managed C++

22 :デフォルトの名無しさん:02/02/24 09:41
>>14
本当だ......。よくみるとVS.NETのほうにしかiostrem.hはないですね。
まあ私はVS.NET買うつもりなので関係ないけど。

23 :デフォルトの名無しさん:02/02/24 09:44
ってか、iostream.hなんていいかげん捨てろよ。
それにマトモなSTL入れておけば問題ないだろ。

24 :デフォルトの名無しさん:02/02/24 09:46
>iostream.hなんていいかげん捨てろよ
どゆいみ?

25 :デフォルトの名無しさん:02/02/24 09:47
iostream

26 :デフォルトの名無しさん:02/02/24 10:12
ファイル名から .h が取り除かれたのが今の標準ってこと知らんのか?

27 :デフォルトの名無しさん:02/02/24 10:47
Ruby!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

28 :デフォルトの名無しさん:02/02/24 11:40
>>10
 !(a^b || a^c || ... )
がベストに近いかな?
少なくとも&&使うよりは良いと思われ。

29 :22:02/02/24 12:02
よく考えてみれば、自分の環境はいきなりVS.NETベータ2をいれたので
純粋に.net SDKを入れただけで本当にiostream.hがインストール
されるかどうかはわからなかったです。
ちなみにC:\Program Files\Microsoft.NET\FrameworkSDK\includeには
なかったです.......。


30 :デフォルトの名無しさん:02/02/24 12:11
>>10
適当なコンテナに突っ込んでfor_eachで比較

31 :デフォルトの名無しさん:02/02/24 12:17
>>30
for_each()じゃなくて、find_if()だろ

32 :デフォルトの名無しさん:02/02/24 18:46
__gc class CA{.....};
とすれば、

mann(){
CA* pca=new CA;
}
delete pca;を書かなくても、
ガベージコレクションがオブジェクトを壊してくれる。
便利になったなぁ・・・。

33 :デフォルトの名無しさん:02/02/24 18:56
>>32
mann()ってなに?ネタだよな・・・?

34 :デフォルトの名無しさん:02/02/24 22:10
>>16
.NETでも今までと同じC++が書けます。
managedコードを吐かせたくなければ、コマンドのcl/CLR
からCLRを外して、ソースからmanagedC++固有の書式を除けば
可能です。多分。

35 :ぎゃあああああ:02/02/24 22:41
managed C++でCOMオブジェクトは作れないの?


36 :デフォルトの名無しさん:02/02/24 22:56
>>35
AttributeとATLで作った方が楽だぞ。

37 :ぎゃあああああ:02/02/24 23:14
>>36
.NET frameworkを使えるATLの環境がほしい…。


38 :デフォルトの名無しさん:02/02/24 23:49
MFCは今後まともなサポートは期待
出来ないんだろうなぁ。

39 :デフォルトの名無しさん:02/02/25 00:37
>>38
移植です。それしかありません。

40 :デフォルトの名無しさん:02/02/26 00:44
アセンブリへのパスが通らん。何故だ?
ベータ2ってインストール時にパスを通すとか言ってなかったか?

41 :デフォルトの名無しさん:02/02/26 00:55
いいや、ここはダレも通さん。

42 :デフォルトの名無しさん:02/02/26 01:23
>>40
練習あるべし。


43 :デフォルトの名無しさん:02/02/26 01:36
ディフェンスの宮本にパスカットされた。

44 :デフォルトの名無しさん:02/02/26 01:56
アセンブリは「パス」は関係ないっす。アプリと同じディレクトリにおいてみるべし。

45 :デフォルトの名無しさん:02/02/26 20:41
>44
そうなんですか?
fatal error C1107: アセンブリ 'System.WinForms.dll' がみつかりませ
んでした : /AI または LIBPATH 環境変数を使用してアセンブリ検索パスを指定してくだ
さい。
と、出るんですが。'System.WinForms.dll' ってassemblyと言うフォルダの中に
あるんですけど・・・。

46 :デフォルトの名無しさん:02/02/26 21:00
根性が足りん


47 :デフォルトの名無しさん:02/02/26 21:15
根性かよ!?
・・・頑張ってみるよ

48 :デフォルトの名無しさん:02/02/26 21:17
>>45
'System.WinForms.dll' ということは、相当古いバージョンだね。


49 :デフォルトの名無しさん:02/02/26 21:31
>>45
System.WinForms.dllはBeta2でSystem.Windows.Forms.dllに変わりました。


50 :デフォルトの名無しさん:02/02/26 21:45
おお、成る程。
そのDLLはありました。assemblyフォルダじゃなくて.NETの方に。

Microsoft.Win32.Interop.dllも名前が変わっているのですか??

51 :名無しさん♯:02/02/26 21:53
>>50
> Microsoft.Win32.Interop.dll

そのDLLはβ2以降なくなったよん。

52 :デフォルトの名無しさん:02/02/26 22:22
無くなった・・・?
もう根性でもどうにもできないな。

53 :デフォルトの名無しさん:02/02/26 22:47
お前の環境はどうなんてっだと、小一時間問詰めたい。

54 :デフォルトの名無しさん:02/02/26 22:51
OSのクリーンインストールからだな。


55 :デフォルトの名無しさん:02/02/26 22:51
.NETベータ2、VC6.0、JAVA2しか入っていません。

56 :デフォルトの名無しさん:02/02/26 23:00
うちもVS.NETβ2とVS6.0は入ってるけど別に問題無いよ。
てことはJAVAかな?

57 :デフォルトの名無しさん:02/02/26 23:01
んなわけない。
旧バージョンをアンインストールせずに新しいやつ入れたんでしょ。

58 :デフォルトの名無しさん:02/02/26 23:08
お前本当に古いバージョンを消したのかと、トイレに連れ込んでボコボコにしながら問詰めたい。

59 :56:02/02/26 23:10
あ、要るDLLが無いんじゃなくて、要らないDLLが在るのか(藁
スマソ

60 :デフォルトの名無しさん:02/02/26 23:11
アンインストはかけましたよ?
但し、インストールとアンインストールを計6回ぐらいしましたが・・・

61 :デフォルトの名無しさん:02/02/26 23:36
その環境は捨てろ。
OSから再インストールしやがれ。

62 :デフォルトの名無しさん:02/02/26 23:44
β2でFormを使ったHello Wolrdをどなたかお示しください。
日本語ページでは見付かりません。
(managed C++の情報って何処にあるんだ? )

63 :デフォルトの名無しさん:02/02/26 23:59
こんなんでどうでしょう?RTMでしか試してませんが。

#using <mscorlib.dll>
#using <System.dll>
#using <System.Windows.Forms.dll>
using namespace System;
using namespace System::Windows::Forms;

__gc public class Form1 : public Form {
protected:
 Label *label1;
public:
 Form1() {
  label1 = new Label();
  label1->Text = S"Hello World!";
  this->Controls->Add(label1);
 };
};

int main() {
 Application::Run(new Form1());
}

% cl /clr form1.cpp

64 :デフォルトの名無しさん:02/02/27 00:09
をを・・・出来ましたよ。
ありがとうございます!!
(やっと、GUIの門の前に立った♪)

65 :仕様書無しさん:02/02/27 00:43
おおっ、いつの間にこんなスレが!
昔、managed C++とC#の比較のセミナー見たことあるけど、
managed C++は味があっていい感じ。


66 :デフォルトの名無しさん:02/02/27 00:46
C#とmanaged C++ってどう違うんですか?

67 :デフォルトの名無しさん:02/02/27 01:11
文法が違います。
JAVAとC++と同じぐらい違います。

68 :デフォルトの名無しさん:02/02/27 01:16
>>63を見る限りは文法がそんなに違うとも思えないんですが…

69 :デフォルトの名無しさん:02/02/27 01:22
VCをメインに使ってきた私にはC#もJAVAもほとんど一緒に見えるのです。
だからmanaged C++は私には絶好の言語なのです。ガベコレがあるなんて
最高としか思えない。

70 :デフォルトの名無しさん:02/02/27 01:50
ガベージコレクションってnewしたヤツだけ消してくれるの? GetDCしてReleaseDCしなくてもよくなるとかってことは?

71 :デフォルトの名無しさん:02/02/27 02:00
誰かmanaged C++の分かり易い解説ページ知らない?
本とか全然ないしさ、みんなどうやって勉強してるの?

72 :デフォルトの名無しさん:02/02/27 02:11
>>70
ない。GC対象になるのは__gcなクラスだけ。

>>71
RTMのドキュメント。


73 :デフォルトの名無しさん:02/02/27 18:57
managed C++ってSTL使えるの?
使えるなら、managed C++に乗り換えるけど。

74 :デフォルトの名無しさん:02/02/27 21:24
C#とくらべて少しは速いの?>>実行速度

75 :デフォルトの名無しさん:02/02/27 21:25
>>37
gcroot

76 :デフォルトの名無しさん:02/02/27 21:28
>>73
You can use it

77 :デフォルトの名無しさん:02/02/27 21:31
managedC++ってネィティブコンパイラ?

78 :デフォルトの名無しさん:02/02/28 17:33
C#とコレが使えれば、とりあえず
10年は喰えそうな気がするのだが、
俺の気のせいだろうか・・・・?

79 :デフォルトの名無しさん:02/02/28 17:36
正解。

80 :デフォルトの名無しさん:02/02/28 17:37
>>77
っていうか、cl.exeはネイティブコードもILも両方吐けます。

81 :デフォルトの名無しさん:02/02/28 20:50
クライアント領域が出ねぇーーーー!!
何故だぁ!!

82 :デフォルトの名無しさん:02/02/28 20:59
>>80
ネイティブっつーても、
.NET frameworkは必要。
誤解する人も出るので
言い方改めた方がよい。

83 :デフォルトの名無しさん:02/02/28 21:36
>>82
それを言ったら、いまのプログラムも Win32 API は必要だし。(GDI32.DLL とかさ)

84 :デフォルトの名無しさん:02/02/28 21:41
ATLってどうなるの?

85 :デフォルトの名無しさん:02/02/28 22:16
>>84
死滅しました

86 :デフォルトの名無しさん:02/02/28 22:22
COMの時代も終わりか・・・


87 :デフォルトの名無しさん:02/02/28 22:31
>>85
.net でもヘッダファイルには残ってるが。従来の WTL の機能も一部取り込んで、
発展はしてる。(メインストリームではないと思うが)

88 :デフォルトの名無しさん:02/03/01 11:18
>>82
はぁ。誤解しているのはあんたです。cl.exeはx86ネイティブ吐けます。ILを吐くのは/clrのときだけ。

>>85-87
ATL7使ってみなって。ある意味C++/ATLユーザーは.NET Frameworkなんかいらないってことがわかるから。
ATLはまだまだメインストリーム。


89 :デフォルトの名無しさん:02/03/01 11:22
age

90 :デフォルトの名無しさん:02/03/01 11:49
マネジドやるならC#かJavaでええやん。

91 :デフォルトの名無しさん:02/03/01 12:09
C++でもええやん

92 :デフォルトの名無しさん:02/03/01 16:22
>88
82じゃないけどおれも誤解してたかも。
managed C++はCLR(.NET)を使うために作られたものだと思ってたけど、
CLRと全く関係無しに managed C++を使うものなの?

93 :デフォルトの名無しさん:02/03/01 16:35
>>92
managed extension for C++はC++の構文で、CLR向けのコードを書くための拡張機能。

Visual C++ .NETは、通常のC++以外に、managed extension*も*サポートするC++コンパイラ。

>CLRと全く関係無しに managed C++を使うものなの?
CLRと関係なしに「C++を」使うことができる。
CLRと関係しまくりの「managed extensionをC++とともに」使うこともできる。
OK?

94 :92:02/03/01 17:02
>93
>>CLRと全く関係無しに managed C++を使うものなの?
>CLRと関係なしに「C++を」使うことができる。
>CLRと関係しまくりの「managed extensionをC++とともに」使うこともできる。
CLRを使わずに、「managed extensionをC++とともに」使うことはありえないですよね?

いや、83さんがx86ネイティブを非/clr時に吐けると書いているけど、
ここはmanaged C++スレなので、managedをCLR非利用時に使うことが
ありえるのか?と疑問に感じましたので。

95 :デフォルトの名無しさん:02/03/01 17:14
つーかな、ファイル名そのものがある種のポインタなわけよ。
だから、94は、ポインタとポインタのポインタの説明って事さ。

96 :95:02/03/01 17:27
誤爆スマソ。

97 :デフォルトの名無しさん:02/03/01 17:39
>>94
なるほど。僕としては、
「managedをCLR非利用時に使うことがありえるのか?」
っていう文章が文章として成り立っていない(managedっていう言葉はCLRと同義語だから)ので、??と思ったのでした。

あ、ちなみに83==93==thisってことで。

98 :デフォルトの名無しさん:02/03/01 17:40
ちがーう。88==93==97。

99 :デフォルトの名無しさん:02/03/02 00:38
templateが使えて、GCもあればC#いらん。
C++プログラマーの長年の夢は叶えられた。

100 :100!:02/03/02 00:42
今だ100ゲット!

101 :デフォルトの名無しさん:02/03/02 00:43
>99
ならD使え

102 :デフォルトの名無しさん:02/03/02 00:48
しかし101は無視された!
しかし101は無視された!
しかし101は無視された!


103 :99:02/03/02 00:51
D言語ってDigital Marsのところのヤツか?
確かにC++に最も近いだろうが、「何処でも動く」
わけじゃないからなぁ。

104 :デフォルトの名無しさん:02/03/02 00:55
>「何処でも動く」
managedとか言ってる時点で駄目だろ

105 :デフォルトの名無しさん:02/03/02 01:47
んなこたぁない。実際に「何処でも動く」ようにしてあるんだから。
言葉の定義はどうでもよくて実際が大事。

106 :デフォルトの名無しさん:02/03/02 01:49
managedが動く「何処でも」って何処のこと?

107 :デフォルトの名無しさん:02/03/02 01:50
>103-105
微妙なずれを感知。

108 :デフォルトの名無しさん:02/03/02 02:05
どこでも=MSか地味案が気にかけてくれた所&ユーザがCLR作っちゃうくらい
やるきのあるコミュニティのある所。

109 :デフォルトの名無しさん:02/03/02 07:32
>>99
君は、何屋さんかな?
C++プログラマは要らないと思ってるんだよ。
今まで、ずっとJavaにコンプレックス持ってて、
「でもこっちにはテンプレートがあるんだい」とか言って田?


110 :デフォルトの名無しさん:02/03/02 20:51
C++プログラマは要らないと・・・
ガ━━(゚Д゚;)━━ン!


111 :デフォルトの名無しさん:02/03/02 20:56
>109-110
明らかなズレを感知。

112 :デフォルトの名無しさん:02/03/02 21:24
>109
その通りです。
JAVAのバカヤロー!!

113 :109:02/03/02 21:36
ごめん。
誤:C++プログラマは要らないと思ってるんだよ。
正:C++プログラマはGCなんか要らないと思ってるんだよ。何にしても、煽り入ってたね。ごめーん。

114 :デフォルトの名無しさん:02/03/02 21:38
許さーん。

115 :デフォルトの名無しさん:02/03/02 22:43
確かにC++にガベージコレクションはいらないかも。
ろくにメモリの管理もできないような厨房大量発生の予感。


116 :デフォルトの名無しさん:02/03/02 22:45
いらないというか付けて欲しくないね。
もし付いたらパフォーマンス最優先なOOPLがなくなってしまう。

117 :デフォルトの名無しさん:02/03/02 22:45
auto_ptrで十分…

118 :デフォルトの名無しさん:02/03/02 22:50
BoehmGCだっけ?あれはどーなの?

119 :デフォルトの名無しさん:02/03/02 22:52
Bjarne Stroustrup >
>>The best garbage collecting language that I know of is C++ with a garbage collector.


120 :デフォルトの名無しさん:02/03/02 22:53
The best garbage collecting language that I know of is Ruby!

121 :デフォルトの名無しさん:02/03/02 22:53
>>116
クラス単位で選択可能にすれば良いだけだと思うが。

122 :デフォルトの名無しさん:02/03/02 23:34
>121
なにがいいんだ?
それでGCが走るタイミングを制御できんのか?

123 :デフォルトの名無しさん:02/03/03 00:32
GC なら Lisp に一日の長あり。

124 :デフォルトの名無しさん:02/03/03 06:23
>>119
おお・・・Stroustrupがそんなことを言っていたなんて(福音)
その下のは何?宗教の勧誘か??

125 :デフォルトの名無しさん:02/03/03 09:25
>>119
「GC付きのもっともよい言語は、私の知る限り、GC付きのC++です」
意味わかりません。これマネジドのこと?そんなこと教祖が言ったの?
信じらんない。ソース希望。

126 :デフォルトの名無しさん:02/03/03 09:34
そうだよねー、
GC の制御を細かく出来ないと 速度がクリティカルな環境じゃ使えない。

なんとかならないのかな? .NET の GC は。

127 :デフォルトの名無しさん:02/03/03 10:18
>>126
クリティカルな部分は自分で管理するとかして、
gcの起動を抑制すればいいんじゃない?


128 :デフォルトの名無しさん:02/03/03 11:39
>>125
訳さんでもいいわい。
ttp://www.csl.mtu.edu/cs5311/www/quote.html

129 :デフォルトの名無しさん:02/03/03 11:42
こんなのもあるぞ。
http://pc.2ch.net/test/read.cgi/tech/1010852722/620

130 :デフォルトの名無しさん:02/03/03 12:12
StroustrupはC++のことしかいってないなぁ(w
>Pablo Picasso
>Computers are useless. They can only give you answers.
が(・∀・)カコイイ!!

131 :デフォルトの名無しさん:02/03/04 01:16
マジな話、GCの制御できないのか?(文法レベルで)
VS.NETにはオプションでありそうな気がするんだが。

132 :デフォルトの名無しさん:02/03/04 10:29
なにを制御したいのかな?呼びたいときに呼ぶってなら、System.GCクラスでできるけど。
あとGCが起動するスレッドをどれにするかとか、制御できるよ。

でも、VS.NETのオプションとかいってるところを見ると、アンタGCわかってないね。
開発環境と関係あるわけがない。

133 :興味本位:02/03/04 11:18
ベタな質問でスマソ。
managed C++ソースコードの標準的な拡張子って.cppのままなんですか?

managed G++が出ないかなあ…(CLRが先か)

134 :デフォルトの名無しさん:02/03/04 11:57
>133
そう。

135 :興味本位:02/03/04 13:24
thx
構文的にはC++にCLRを使うための機能を追加しただけだから.cppでいいのか。

136 : :02/03/04 19:22
機能追加なら、C++++で.cp4か?

137 :デフォルトの名無しさん:02/03/05 17:37
++c++ではどうか。

138 :デフォルトの名無しさん:02/03/05 20:28
++++++++c++++++++

139 :デフォルトの名無しさん:02/03/05 20:38
それじゃBrainF**kだよ(w

140 :デフォルトの名無しさん:02/03/05 20:55
Visual BrainF**k

141 :デフォルトの名無しさん:02/03/06 23:49
age

142 :デフォルトの名無しさん:02/03/07 00:00
類似スレが立ったようだが、いきなり荒らされてるな。

143 :デフォルトの名無しさん:02/03/07 00:47
c=1;
++c++;

c==3ですか?

144 :デフォルトの名無しさん:02/03/11 23:10
ttp://msdn.microsoft.com/msdnmag/issues/02/02/ManagedC/ManagedC.asp

145 :デフォルトの名無しさん:02/03/16 16:42
全てがオブジェクトである

146 :デフォルトの名無しさん:02/03/16 17:08
int c = 1, x;

x = ++c++;

cout << "x = " << x << " : c = " << c <<endl;
// x = 2 : c = 3 かな

147 :デフォルトの名無しさん:02/03/16 17:26
で、みんな本気で手を出すつもりかい? まなげどC++


148 :デフォルトの名無しさん:02/03/16 20:19
unmanagedコードが気軽に呼べる環境として注目してる。
.NET的なクラス/インスタンス管理を自動でやってもらえるのは嬉しい。

MC++のコードでmanagedな部分がメインになることは少ないと思うなあ・・


149 :デフォルトの名無しさん:02/03/16 23:04
現在、β2使ってるけど
「古い形式で書かれていますがビルドしますか?」
みたいな内容のダイアログが出てくる時点で
プチ・リストラ気分>VC++ユーザーの俺

150 :デフォルトの名無しさん:02/03/21 21:18
明日本番age


151 :デフォルトの名無しさん:02/03/21 21:19
「ai-indigo.6151@docomo.ne.jp」からウィルスが添付されてきた・・・
よって晒し!

152 :デフォルトの名無しさん:02/03/21 21:20
managed C++ってRubyコンパイラ並みに無意味なような。

153 :デフォルトの名無しさん:02/03/21 21:23
C++ >>>>>>>>>>>>>>>>>>>>>>>>>> Ruby == managed C++
ですか?

154 :デフォルトの名無しさん:02/03/22 13:13
入手!!

155 :デフォルトの名無しさん:02/03/22 13:36
>>153
ちょい違う。
if( (C++ * 10) > ( ( Ruby * 8 ) || ( Managed C++ << 3 ) ) )
printf( "MS イッテヨシ" );

156 :155:02/03/22 13:38
あ、条件文間違えた。

157 :デフォルトの名無しさん:02/03/22 20:17
C++ マネージ拡張

158 :デフォルトの名無しさん:02/03/23 14:31
VS.NET発売age

159 :とあるフリーソフトウェア作家:02/03/23 16:00
しつもーん。
managed C++ のランタイムを配布するときって、
何と何を一緒に配布すりゃいいんでしょ。はたまたそのサイズはいかほど?
あるいは、MSのどこにリンク張っとけばいいんでしょ。

.NET 買うかどうか悩んでるとこなんですが。

160 :デフォルトの名無しさん:02/03/24 02:07
このスレタイトルの
managedてなんですか?

161 :デフォルトの名無しさん:02/03/24 02:11
>>160
.NET上で動くC++か
今までのC++かってことじゃに
managedC++なコードは.NET上でないと動かないよん

162 :デフォルトの名無しさん:02/03/24 02:42
>>159
dotnetfx.exe(21.6MB)

163 :159:02/03/24 05:19
で、デケェ・・・。
そんなもん、フリーソフトウェアにはつけることはできん。
やっぱふつーにC++使いますわ。

会社で作るときに検討しよう・・・・。

164 :デフォルトの名無しさん:02/03/24 11:27
>>163
どうせすぐにサービスパックに含まれるって。


165 :デフォルトの名無しさん:02/03/24 11:33
>>162
それさぁ、Win95で動かすことはできないんかな?
Win95 で CLR / .net しなきゃならないんだけど。


166 :デフォルトの名無しさん:02/03/28 17:00
> Win95 で CLR / .net しなきゃならないんだけど。
何それ?
Win95はもうMicrosoftがサポート止めてるのにいまさら出るわけないと思われ

167 :デフォルトの名無しさん :02/04/07 19:23
http://hp.vector.co.jp/authors/VA000092/jokes/strup.html
感動した。

168 :デフォルトの名無しさん:02/04/07 19:47
何てことだ・・・何てことだ!!

169 :デフォルトの名無しさん:02/04/08 02:06
>>167
ああああああああぁぁぁぁぁぁ

優秀なCプログラマが書いたソースなら、C++のクラスに勝る気がしていたのは
気のせいじゃなかったのか・・・・

170 :デフォルトの名無しさん:02/04/08 08:02
"jokes" ?


171 :C++歌劇派:02/04/08 08:32
managed C++なんてC++じゃないだろ。
だたらJavaやれ。

>優秀なCプログラマが書いたソースなら、C++のクラスに勝る気がしていたのは
それは君がパーなだけ。それに、最近は、じじいのCプログラマばっかりで、
優秀なのもいない。

172 :デフォルトの名無しさん:02/04/08 09:02
マジレスはあれでしょう。

173 :デフォルトの名無しさん:02/04/08 21:40
おいおい、この反応は全部ネタだよな?

174 :デフォルトの名無しさん :02/04/08 23:12
>>167
マジな話C++は終わったのか?
ネタだと信じたい。
もし、ビル・ゲイツが10年ぐらいたってC#は実はジョークでしたとか言ったら泣くよ・・・。

175 :デフォルトの名無しさん:02/04/08 23:23
誰もまなげどC++やってないらしい罠


176 :デフォルトの名無しさん:02/04/09 00:12
よっぽど理由がない限りやらないよ

177 :デフォルトの名無しさん:02/04/09 02:34
いや、MC++まんせー!ってひとがMSのnewsにいたよ。

178 :デフォルトの名無しさん:02/04/09 03:30
    冫─'  ~  ̄´^-、
    /           丶
    /             ノ、
   /  /ヽ丿彡彡彡彡彡ヽヽ
   |  丿           ミ
   | 彡 ____  ____  ミ/
   ゝ_//|    |⌒|    |ヽゞ
   |tゝ  \__/_  \__/ | |    ________________
   ヽノ    /\_/\   |ノ  /
    ゝ   /ヽ───‐ヽ /  /   C#は実はジョークでした
     /|ヽ   ヽ──'   / <     次はC♭出すので買ってね
    / |  \    ̄  /   \
   / ヽ    ‐-            ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄


179 :デフォルトの名無しさん:02/04/10 11:20
まなげどマンセーage

180 :デフォルトの名無しさん:02/04/10 11:36
VS6でmanagedC++やってる人いる?
どうもコマンドラインからだとコンパイル成功するのに
エディタからだとdllがらみのエラーが出る。

181 :デフォルトの名無しさん:02/04/10 11:37
↑リンクエラーのことね

182 :デフォルトの名無しさん:02/04/10 14:20
>>176
C++をmanagedでやる理由もなけりゃmanagedをC++でやる理由も無いからな。
つかC++はキーワードが汚すぎ。

183 :デフォルトの名無しさん:02/04/10 17:56
C++から.NETを使いたい。ってそんなにマイナーなニーズ?
MFCだってあとは現状維持程度で、新しいことがしたければ.NETへ逝け!でしょ?

おれは今のところWindowsは開発対象でないので様子見。

184 :180:02/04/10 18:37
原因はこれです
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore/html/vcerrLinkerErrorLNK2023.asp
だけど解決方法が分かりません。Link.exeに正しく
E:\Program Files\Microsoft Visual Studio .NET\Common7\IDE\msobj10.dll
を読み込ませる方法はないでしょうか?

185 :180:02/04/10 18:59
自己レス。
E:\Program Files\Microsoft Visual Studio\Common\MSDev98\Bin\msobj10.dll
を上の.netSDKのDLLで上書きしたらLNK2023は出なくなりました!

という訳でVS6、.netSDK、PlathomeSDKの三つを上手く組み合わせれば
まだまだ開発はできそうです。

186 :デフォルトの名無しさん:02/04/10 20:55
をいをい、%LIB%直せよ。。

187 :デフォルトの名無しさん:02/04/10 21:20
VC.NETはlokiをコンパイルできるのですか?
というかtemplateの制限はどれくらい解けてます?

188 :デフォルトの名無しさん:02/04/10 21:42
VC.NETはloliをコンパイルできるのですか?

189 :デフォルトの名無しさん:02/04/10 21:47
>>187
それなりに解けてる

190 :180:02/04/10 22:49
>>186
%LIB%にパスを設定したけどダメなんですよ。なんでですかね?

191 :デフォルトの名無しさん:02/04/22 01:27
C#ってVBの関数使えるらしいけど、managed C++は使えるの?

192 :デフォルトの名無しさん:02/04/24 21:04
.NETの関数、という意味ならどの言語だろうが同じなのでは。

193 :デフォルトの名無しさん:02/05/06 03:38
>>192
ほう・・・VBが使えるVC・・・訳わからんな。

194 :デフォルトの名無しさん:02/05/06 03:46
>>192
だよな。
カーネル内の関数をVC++で作成したものだろうがVBで作成したものだろうが呼び出せるのと同じだよな。

195 :194:02/05/06 03:50
カーネルじゃなくてDLLの方がいいか。

196 :デフォルトの名無しさん:02/05/08 16:24
managed C++まじで分らん。誰か助けて!

197 :デフォルトの名無しさん:02/05/08 16:44
>>196
やだ

198 :デフォルトの名無しさん:02/05/08 17:23
>>196
C#やれ

199 :デフォルトの名無しさん:02/05/08 17:50
>>196
質問書けよ。助けて!じゃわからん。

200 :デフォルトの名無しさん:02/05/08 17:54
managed C++でやれることは
unsafeキーワード使うことで
全てC#でできるんですか?

201 :デフォルトの名無しさん :02/05/08 18:04
unsageって前はマネージドコードってことになってなかったっけ?

202 :デフォルトの名無しさん:02/05/08 18:05
多重継承とかは?

203 :デフォルトの名無しさん:02/05/08 18:06
>>202
それはそもそもmanaged c++にはない

204 :デフォルトの名無しさん:02/05/08 18:10
ms-help://MS.NETFrameworkSDK.JA/vcmxspec/html/vcManagedExtensionsSpec_1.htm

205 :デフォルトの名無しさん:02/05/08 18:14
>>201
unsage = age

206 :デフォルトの名無しさん:02/05/08 18:22
・アクセスと制御。
マネージ コードとアンマネージ コードを混在できるため、
下位レベルのアンマネージ API などに直接アクセスできます。
Visual C++ とマネージ拡張を使用して、最大パフォーマンスの
マネージ API を記述できます。

この辺りしかmanaged C++を使う理由はないな。
C#でも十分パフォーマンスをあげるコーディングの仕方が
用意されてるみたいだし。またx86ネイティブなコードを
書く機会もWindowws上じゃ減るんだろうなぁ。

207 :デフォルトの名無しさん:02/05/08 18:30
>>206
MC++のメリットって、APIの構造体(またはクラス)を直接使えることぐらいじゃないかな。
APIの引数の型が単純だったら、C#とかでも難なく使えるし。

208 :デフォルトの名無しさん:02/05/08 18:31
>>200
いいえ。C#は何でもできる言語ではありません。VB.NETでできるのにC#では
できないこともあります。MC++でならできるけど、C#やVB.NETではできない(または限定的)と
いうこともあります。

>>206さんの言うことは一部真だと思いますが、C++ユーザーがC#に進んで混乱するくらいなら
MC++のほうがいいという選択もありえると思います。

209 :デフォルトの名無しさん:02/05/08 18:32
>>207
ちなみにMC++のアンマネージコードの呼び出しはP/Invokeではありません。
P/Invokeよりも数十倍高速な仕組みを利用します。

210 :207:02/05/08 18:35
>>209
ああ、そういやそんな話があったね。IJWって言うんだっけ?

211 :デフォルトの名無しさん:02/05/08 19:12
ms-help://MS.NETFrameworkSDK.JA/vcmxspec/html/vcmg_PlatformInvocationServices.htm
この辺りかな?
とにかく高速なラッパーという用途だけはC++に残っているわけね。

212 :デフォルトの名無しさん:02/05/08 19:31
unsage!

213 :デフォルトの名無しさん :02/05/08 19:51
unsage!

214 :デフォルトの名無しさん:02/05/09 18:37
既存のアプリケーションをマネージドに移行するのに注意する点なんてありますか?

215 :デフォルトの名無しさん:02/05/09 18:41
関係ないですが、"managed C++"を日本語でGoogleから検索すると
かなり上位に出てきます。

216 :デフォルトの名無しさん:02/05/09 19:08
>>214
unmanagedコードを使わないようにがんばろう。

217 :デフォルトの名無しさん:02/05/09 19:48
MFCとかATLをmanagedコードにすることは可能なの?

218 :デフォルトの名無しさん:02/05/09 19:51
ムリ!

219 :デフォルトの名無しさん:02/05/09 19:55
ナンデ!!

220 :デフォルトの名無しさん:02/05/09 19:57
>>217
/clr つければできるよ。一緒に使えないオプションが多くて面倒だけど。

221 :デフォルトの名無しさん :02/05/09 20:06
MC++ってごちゃごちゃしててまじでワケワカラン

222 :デフォルトの名無しさん:02/05/09 21:05
とりあえず、新規のプロジェクトでMC++を使うことはないって言うのが
よく分かったよ。

223 :デフォルトの名無しさん:02/05/09 21:20
C++死滅スレでも作る?

224 :デフォルトの名無しさん:02/05/09 23:29
MC++死滅スレなら。

225 :デフォルトの名無しさん:02/05/10 00:06
>>224
VC++に関していえば、
過去の資産を引き継ぐという意味じゃ、
互換性を切り捨てたVBとは役割は全然違う。
10年はなくならない。
それにMC++は多分内部的にかなりC#とコードを
共有してるような気もするから、なくなることは
ないと思う。

あくまで希望的観測だけどどうでしょう?

226 :デフォルトの名無しさん:02/05/10 00:10
>>225
MC++ -> MSIL -> C#
いいデコンパイラが出れば良い線行くかも。
MC++ -> MSILとC# -> MSILが似ていれば。

227 :デフォルトの名無しさん:02/05/10 07:05
既存のアプリケーションをコンパイルして気が付いたけど、
FILETIME(WinBase.h)とSystem::Runtime::InteropServices::FILETIME
みたいに名前がかぶっちゃうようか場合はどうしてる? 

228 :デフォルトの名無しさん:02/05/10 07:27
ms-help://MS.NETFrameworkSDK.JA/vcmxspec/html/vcmg_AmbiguousReferences.htm

229 :デフォルトの名無しさん:02/05/10 07:49
>>228
解決しました。どうもです。

230 :デフォルトの名無しさん:02/05/10 08:43
ところで普通のアプリに
・使用するDLLを#pragma comment(lib, "XXX.lib")と指定する。
・使用する.net frameworkのDLLをusing <XXX.dll>と指定する。
とこれだけでいいんでしょうか?

しかもやってて思ったのは::MessageBox関数みたいに#define
切られてるのはどうしようもないような気がしてきました。
System::Windows::Forms::MessageBoxWはありませんとか言われて・・・

231 :デフォルトの名無しさん:02/05/10 08:47
>>230
dllなのに拡張子libとは?

232 :デフォルトの名無しさん:02/05/10 08:57
>>231
LINK : fatal error LNK1104: コンパイラは、ファイル 'kernel32.dll' を開くことができません
こうなっちゃうんですよ。

ところでこうやってコンパイルしたプログラムはmanagedってことに
なるんですかねぇ?もちろん全て__nogcという意味でいいのですが。
なんかMC++ってなんなのかよく分りません。
ildasm.exeでもちゃんと見れるからどうなってるのかさっぱりです。

233 :デフォルトの名無しさん:02/05/10 09:04
>>231
#pragma comment(lib, "kernel32")
これでOKでした。拡張子は入りません。

234 :デフォルトの名無しさん:02/05/10 09:08
それにしても盛り上がらないですねー。
既存のプログラムをC#で書き直すぐらいなら
MC++を活用した方が全然いいと思うのですが、、、

これでDLLを作ればC#なんかからusing MyLib;
なんて出来ていいと思うのですが。

235 :デフォルトの名無しさん:02/05/10 09:12
>>234
ライブラリの移植用としては上の方で語られているね。
すくなくとも.NET用に開発されたC#がもっとも.NETとの親和性が高い。

236 :デフォルトの名無しさん:02/05/10 09:17
>>235
個人的にはSun派とMS派のどっちでもないけど、
.netが過去との互換性を重視してる点がいいと思うんですよ。
MC++あっての.net(w

237 :デフォルトの名無しさん:02/05/10 09:19
>>236
俺は心機一転派なのでC#のパイオニアを目指すw


238 :デフォルトの名無しさん:02/05/10 09:19
そういう意味じゃg++が.net対応して保水

239 :デフォルトの名無しさん:02/05/10 09:21
>>238
最強だね。それ。

240 :デフォルトの名無しさん:02/05/10 09:34
今あるWindowsの.net frameworkと同等のmonoを作るだけで
最低でも10年はかかるんだろうなぁ。opensource is always late
なんてAlan Coxさんが言ってたけどまさにそんな感じか、、

241 :デフォルトの名無しさん:02/05/10 11:59
MC++やろうぜ!

242 :デフォルトの名無しさん :02/05/10 12:25
だれも盛り上げないから独り黙々と情報提供

【Essential Guide To Managed Extensions For C++】
http://www.amazon.com/exec/obidos/ASIN/1893115283/

【Managed C++ and .NET Development】
http://www.amazon.com/exec/obidos/ASIN/1590590333/

【Visual C++(r).NET Developer's Guide】
http://www.amazon.com/exec/obidos/ASIN/0072132817/

【Programming with Microsoft Visual C++ .NET, Sixth Edition (Core Reference)】
http://www.amazon.com/exec/obidos/ASIN/0735615497/

GotDotNetのMC++
http://www.gotdotnet.com/team/cplusplus/
http://www.gotdotnet.com/team/upgrade/c++.aspx



243 :デフォルトの名無しさん:02/05/10 12:35
一冊漏れてた
【Microsoft Visual C++ .NET Step by Step】
http://www.amazon.com/exec/obidos/ASIN/0735615675/

COMとの相互運用に関して特化した本
【.NET and COM: The Complete Interoperability Guide】
http://www.amazon.com/exec/obidos/ASIN/067232170X/

C++プログラマたるもの、内部について無知は許されない!
【Inside Microsoft .NET IL Assembler】
http://www.amazon.com/exec/obidos/ASIN/0735615470/

【Compiling for the .NET Common Language Runtime】
http://www.amazon.com/exec/obidos/ASIN/0130622966/

【Essential .NET: The Common Language Runtime (Volume 1)】
http://www.amazon.com/exec/obidos/ASIN/0201734117/

発売してないものも含まれているので注意してください。

それにしても思ったより少ない気もする・・・

244 :デフォルトの名無しさん:02/05/10 12:47
>>243
これからでそ

245 :デフォルトの名無しさん:02/05/10 12:58
managed C++でILを吐かせることはできるんですか?

246 :デフォルトの名無しさん:02/05/10 13:00
>>245
もちろん。そのための「M」ですから。

247 :デフォルトの名無しさん:02/05/10 13:10
>>245
/CLRオプションを付けたときはデフォルトでmanagedコードに
なるみたいですが、managedコード=ILという訳ではないんですよね?
どうもGCとmanagedとILの関係が分らんのです。

x86バイナリにコンパイルされたC++managedコードにGCの機能が含まれて
いるっていう組み合わせもありえるんですよね?

248 :デフォルトの名無しさん:02/05/10 13:12
PreJITと実行時ILコンパイルに質的に差がないのは理解してます。

C#に負けるな、あげ!

249 :デフォルトの名無しさん:02/05/10 13:26
>>247
/clrでmanaged codeを吐くよ。managed codeって目に見えるものじゃなくて
概念的なものだと思う。ILであることもmanaged codeの一側面ではあるけど。

__gcのクラスはmanaged dataになる。managed dataとmanaged codeの違いは
意外にみんな理解していないようだ。

x86バイナリのlibをリンクしても、それがmanagedになるわけじゃないよ。
CLRはunmanaged codeを実行することもできるんだよね、これも意外に
知られていないが。

250 :デフォルトの名無しさん:02/05/10 13:30
>>249
難しいです。なにかよいドキュメントがあればぜひお願いします。

251 :デフォルトの名無しさん:02/05/10 14:10
ドキュメントから抜いてきました。

managed data 【マネージ データ】
共通言語ランタイムによって有効期間が管理されるオブジェクト。
共通言語ランタイムはオブジェクトのレイアウトを自動的に処理し、
それらのオブジェクトへの参照を管理し、不要になったオブジェクトを解放します。

managed code 【マネージ コード】
共通言語ランタイムとの "連携のコントラクト" に従って実行されるコード。
マネージ コードは、ランタイムがメモリ管理、言語間の統合、
コード アクセス セキュリティ、オブジェクトの有効期間の自動管理などの
サービスを提供するために必要とするメタデータを提供する必要があります。
Microsoft Intermediate Language (MSIL) に基づくコードはすべて、
マネージ コードとして実行されます。

unmanaged code 【アンマネージ コード】
共通言語ランタイムの規則および要件に関係なく作成されたコード。
アンマネージ コードが共通言語ランタイム環境で実行される場合は、
最小限のサービスで実行されます。たとえば、ガベージ コレクションは
実行されず、デバッグ機能も限定されます。


これから考えると、いわゆるmanaged C++っていわれてるプログラムは
managed dataとmanaged codeの規約を満たしているっていうわけですね。
ILかx86バイナリかどうかに関係ないく。GC云々の話は規約を満たしている
managed codeが生成したmanaged dataにおいて可能ということですか。
そして規約外のコードが全てunmanaged code。

となると、既存のC++プログラムを/CLRオプションでコンパイルした場合は、
例えそこからunmanaged codeを呼び出していたとしてもmanagedになる、
ってことですね。


もっと勉強しないと。。。

252 :デフォルトの名無しさん:02/05/10 14:27
ms-help://MS.NETFrameworkSDK.JA/csref/html/vclrfunsafe.htm
ところがどっこい、C#ではポインタを使うためにunsafeキーワードを
使うと、アンマネージドになってしまうらしい。

C#ではポインタの使えるマネージドコードというのは記述できないのかな?
それとも上のドキュメントの記述が紛らわしいだけなのか、、

253 :デフォルトの名無しさん:02/05/10 14:44
>>252
綺麗に線引きするには内部の動作を把握してないと無理。
だからみなあいまいな説明しかできない。

254 :デフォルトの名無しさん:02/05/10 17:31
>>252
アンセーフとアンマネージは違う。アンセーフはマネージコードです。
CLRはマネージコードを実行します。アンマネージコードも一部実行できます。
アンセーフはマネージですから完全にCLRの傘下で実行されます。

255 :デフォルトの名無しさん:02/05/10 18:59
>>230
マクロを #undef するよろし。

256 :デフォルトの名無しさん:02/05/10 20:41
MC++とJava(JNI)で連携できた。(・∀・)イイ!

257 :デフォルトの名無しさん:02/05/11 00:57
.NETとJavaとネイティブコードを混ぜられるのはC++だけ。C++最強!

258 :デフォルトの名無しさん:02/05/11 03:01
MC++で COMって書けるの?
厨でrjc

259 :デフォルトの名無しさん:02/05/11 03:41
>>258
ATLで /clr をつければできると思う。

260 :デフォルトの名無しさん:02/05/11 08:15
>>255
それしかないんだけど、なんかきたないね

261 :デフォルトの名無しさん:02/05/12 22:26
MC++やろうぜ!

1はどこいった?(ワラ

262 :デフォルトの名無しさん:02/05/13 17:07
↓で new Size のところ、フルネームにしないとコンパイルエラーに
なるんだけどなんでだろ・・・?

using namespace System;
using namespace System::Drawing;
using namespace System::Windows::Forms;

__gc class Form1 : public Form
{
public:
  Form1()
  {
//   this->Size = *__nogc new Size(400, 300);
    this->Size = *__nogc new System::Drawing::Size(400, 300);
  }
};

[ STAThread ]
int __stdcall WinMain(void)
{
  Application::Run(new Form1);
  return 0;
}

/*
cl /CLR /FU mscorlib.dll /FU System.dll /FU System.Drawing.dll
/FU System.Windows.Forms.dll Form1.cpp
*/

263 :262:02/05/13 17:17
IL的に面倒なことになってるのでちょっと修正。

  Form1()
  {
//   Size s(400, 300);
    System::Drawing::Size s(400, 300);

    this->Size = s;
  }

264 :デフォルトの名無しさん:02/05/13 17:22
>>263
FormにSizeプロパティがあるのと関係?

265 :262:02/05/13 17:30
>>264
あ〜、そういうことですか。Fontクラスもだめでした。
this->Size と System::Drawing::Size の判断ができないのか・・・。萎え。ヽ(´Д`)ノ
それはともかく、ありがとうございます。

266 :デフォルトの名無しさん:02/05/17 14:19
MC++やろうぜ!
http://www.codeproject.com/managedcpp/

267 :デフォルトの名無しさん:02/06/06 15:55
age

268 :デフォルトの名無しさん:02/06/06 16:14
wingdi.hに定義されているGetObjectと
System::Resources::ResourceManagerのGetObject
が、重なってしまいます。


ms-help://MS.NETFrameworkSDK.JA/vcmxspec/html/vcmg_AmbiguousReferences.htm
を見て完全限定名を使ってみたりしてるんですがwingdi.hの方で

#ifdef UNICODE
#define GetObject GetObjectW
#else
#define GetObject GetObjectA
#endif // !UNICODE

というようにdefineされてしまってResourceManagerのGetObjectがうまく使えません。
この場合は、どうしたらいいんでしょう?

System::Resources::ResourceManager *rm=
(new System::Resources::ResourceManager(S"testForm",Assembly::GetExecutingAssembly()));
this->set_Icon(dynamic_cast<System::Drawing::Icon *>(rm->GetObject(S"MainIcon")));



269 :デフォルトの名無しさん:02/06/06 16:28
>>268
ms-help://MS.VSCC/MS.MSDNVS.1041/vcmxspec/html/vcmg_MacrosandthePreprocessor.htm

270 :デフォルトの名無しさん:02/07/01 05:09
あげ

271 :デフォルトの名無しさん:02/07/02 19:17
manageC++でダイアログボックスとか使うときは自分でコード書かないといけないのですか?
リソースからボタン貼り付けてボタンダブルクリックするとMFCクラスウィザードとか出てきますが
MFCでしかウィザードは使用できないのですか?
manageC++ではひたすらコード書き込みですか


272 :デフォルトの名無しさん:02/07/02 22:42
マネドC++使っている人いますか?

273 :デフォルトの名無しさん:02/07/02 22:44
>>272
お前のすぐ上

274 :login:Penguin:02/07/02 22:52
普通に使ってますがなにか?

っていいたいところなんだけど、
C#の方が便利だし綺麗だ。
これが現実。

275 :_:02/07/14 01:56
ちょっとややこしいよね。そこまでC++に愛着ないし・・・

276 :デフォルトの名無しさん:02/07/14 14:36
さらしあげ
http://www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?topic=1638&forum=7

277 :_:02/07/14 15:16
なんかDOS→NTの時の3.1, 95みたいな香りがする。。。

278 :デフォルトの名無しさん:02/07/14 16:06
>>276
何だかなあ...

279 :コギャル&中高生:02/07/14 16:11
男性にはまだ余り知られて
ませんので逆アポ率も激増
H好きな女子中高生が待ってます
(i/j/eza対応)

コギャルとH出来るサイトはここ
ヌキヌキ部屋へ直行便

http://kado7.ug.to/wowo/

H必ず出来る何度も挑戦
中高生感度良好
ロリ−タ好き

http://fry.to/zzz.hi258.2tyann


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

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

read.cgi ver 05.04.02 2018/11/22 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)