【.NET】 C++/CLI に� ..

---

[2ch|▼Menu]

796:デフォルトの名無しさん
06/03/04 21:46:00
コンソールアプリで確認したけど、エラーなんて出なかったが。

#include "stdafx.h"

using namespace System;
void func(const String^ s)
{
Console::WriteLine((String^)s);
}

int main(array<System::String ^> ^args)
{
func(L"Hello World");
return 0;
}


797:デフォルトの名無しさん
06/03/04 21:58:02
>>796 いいなぁ。
うちのコンパイラは出るんだ。
なんかスイッチの関係かな。
もうちょっと調べてみるよ。

798:デフォルトの名無しさん
06/03/04 22:02:33
それ、コンパイル警告C4400で、警告レベルは4。
どうやら漏れが警告レベルを一番高くしてるから表示されてるみたいだ。

799:MSDN Libraryによると
06/03/04 22:04:20
const (C++) 修飾子および volatile (C++) 修飾子は、
共通言語ランタイムの型の変数では使用できません。
次の例では C4400 エラーが生成されます。
// C4400.cpp
// compile with: /clr /W4
// C4401 expected
using namespace System;
#pragma warning (disable : 4101)
int main() {
　 　const String^ str;　 　// C4400
　 　volatile String^ str2;　 　// C4400
}

800:デフォルトの名無しさん
06/03/04 22:04:21
いいなぁって、駄目だろ。const 指定できちゃ（ｗ

String^ hello = "Hello, World";
func(hello);

だとエラーだったりして

801:デフォルトの名無しさん
06/03/04 22:15:41
.NETの共通として通用しないだけで、
C++/CLI上では値を変更しようとするとエラーになるし、
特に問題はないと思うけど。

ちなみに>>800のも通った。

802:デフォルトの名無しさん
06/03/04 23:24:16
>>800
これが通るんだからそれが通らないわけが無いだろ。
void　func(const　std::string&　s);

std::string　hello　=　"Hello,　World";
func(hello);

803:デフォルトの名無しさん
06/03/04 23:31:02
まぁそれ以前にあれだ、System::StringはImmutableなオブジェクトだ。
どっちにしろ変更できん…わけでもないけど裏技

804:デフォルトの名無しさん
06/03/05 13:02:40
private: System::Void button1_Click(System::Object^ sender, System::EventArgs^ e) {
　　pin_ptr<const wchar_t> text = PtrToStringChars(textBox1->Text);
　　//16進数に変換
　　wchar_t* pEnd;
　　unsigned long hoge = std::wcstoul(text, &pEnd, 16);
　　//入力されたデータの判定（省略）
　　wchar_t* foo;
　　foo=NULL;
　　//unsigned long 型の整数を文字列に変換
　　_ultow_s (hoge,foo,32,16);
　　String ^tmp=Convert::ToString(*foo);
　　textBox2->Text=tmp;
}

ボタンを押したらtextBox1に、入力した文字を16進数に変換し、データの判定を行い
再び文字変数に変換し、textBox2に表示させるという、プログラムです、
foo=NULL;を入れないと、: warning C4700: 初期化されていないローカル変数 'foo' が使用されますと、警告され
foo=NULL;としたらエラーは出ないのですが
いづれの場合でも、実行すると
Debug Assertion Failed!

Expression:buf!=NULL
とお叱りを受けます、どうしたらよいでしょうか？
ｵﾅｶﾞｲｼﾏｽ。


805:デフォルトの名無しさん
06/03/05 16:21:54
漏れには foo に割り当てられているはずの 16 wchar_t が見えないんだがどこにあるんだ？
MSDN で _ultow_s が領域確保してくれるのかどうかぐらい確かめろ

pin_ptr<Char> text = textBox1->Text->ToCharArray();

wchar_t* pEnd = 0;
unsigned long hoge = std::wcstoul(text, &pEnd, 16);

wchar_t foo[16];
memset(foo, 0, 16*sizeof(wchar_t));

_ultow_s (hoge,foo,32,16);
String ^tmp = gcnew String(foo);
textBox2->Text = tmp;

MSDN を読んで出直してこい

806:デフォルトの名無しさん
06/03/05 17:22:58
>>805ありがとう
出直す前に、ｽﾏｿ
unsigned longって32bitですよね、多分そのせいだと思うけど
9桁以上入力すると、結果がオーバーフローしちゃってffffffffに
なっちゃいます、予期せぬ結果です
wchar_tが16ビットのせいだと思うのですが、こんなときはどうしたら
いいのでしょうか、教えて君で申し訳ないですが御教授お願いします。


807:デフォルトの名無しさん
06/03/05 17:30:43
>>806
（VC++の）unsigned　longは32ビットで0〜0xffffffffの数値を格納できる。
だから十六進法で8桁までだ。wchar_tに非は無い。
たとえばunsigned　long　longなら64ビットあるから十六進法で倍の16桁までいける。

808:デフォルトの名無しさん
06/03/05 17:44:29
>>806ありがとう
unsigned long
↓
unsigned long longにしてみたら
: warning C4244: '引数' : 'unsigned __int64' から 'unsigned long' への変換です。データが失われる可能性があります。
警告が出てしまい、実行するとやはり9桁でオーバーフローしてしまいました
手のほどこし方はもう無さそうですね、(´・ω・｀)

809:デフォルトの名無しさん
06/03/05 17:44:57
UInt32::Parseじゃいかんの？


810:デフォルトの名無しさん
06/03/05 18:16:11
>>808
32ビットしか返さない関数使ってるんだから当たり前だな

811:デフォルトの名無しさん
06/03/05 18:18:02
>808
だから、自分の使っている関数の方とかをチェックしてこいといってるだろうに
受け取り側を unsigned long long にしても、変換関数が対応していなけりゃ駄目だろ
おまいさんは文字列を 64 ビット長の整数値に変換したいんだから、それに対応した
変換関数を探してこい
>809 がいいヒントをくれているじゃないか
.net framework で 64ビット長符号なし整数値の型を探してそのメソッドを調べろよ

812:デフォルトの名無しさん
06/03/05 19:01:42
>>811どうもありがとう
>>806です
URLﾘﾝｸ(msdn2.microsoft.com)
Convert.ToUInt64 (Int32)
これでいいのかな？


813:デフォルトの名無しさん
06/03/05 19:09:18
・・・おまいさん、文字列を UInt64 に変換したいんだろう？
だったら使うべき変換関数は Convert.ToUInt64(String^) じゃないのかい
これなら、いちいち配列変換しなくてもいいわけだし
UInt64::Parse(String^) だってあるだろうに
もちろん、UInt64.ToString() とすれば、文字列への変換もできるぞ

C++/CLI は (3.14).ToString() ってやって文字列を取得することだってできるんだから

814:デフォルトの名無しさん
06/03/05 20:42:17
std::wcstoul を愛しているんだろうから、そっとしておいてやれよ

815:デフォルトの名無しさん
06/03/05 21:01:33
(´ε｀；)ｳｰﾝ…

unsigned long long hoge;
にすると
_ultow_s (hoge,foo,16,16);
ここで、
: warning C4244: '引数' : 'unsigned __int64' から 'unsigned long' への変換です。データが失われる可能性があります。
String ^tmp = Convert::ToUInt64(*foo);
とすると
: error C2440: '初期化中' : 'unsigned __int64' から 'System::String ^' に変換できません。
使用可能なユーザー定義された変換演算子がない、または
演算型のボックス化された形式からターゲット型への標準変換は存在しません
なんですよね、全くなにやってんだか・・・・



816:デフォルトの名無しさん
06/03/05 21:11:47
>>815
Convert::ToUInt64は文字列をUInt64(unsigned　long　long)に変換するほうだ。

817:デフォルトの名無しさん
06/03/05 21:14:03
がー！　だから、型と関数を考えて、ちゃんとメソッドを構成する英語を嫁と
UInt64 hoge = 0LL;

if ( UInt64::TryParse(textBox->Text) )
　　hoge = UInt64::Parse(textBox1->Text);

String^ tmp = hoge.ToString();

でいいんだって

なんでわざわざ wchar_t の配列に変換するのかな
ちゃんと、キーワードでぐぐるかMSDN見てる？

818:デフォルトの名無しさん
06/03/05 21:25:28
文字列を数値にするのには次のものがある。

Cのato〜とstrto〜。そしてそれぞれワイド文字版の_wto〜（非標準）とwcsto〜がある。sscanf/swscanf類もある。
C++のistringstream類。
.Net　FrameworkのConvert::To〜と〜::Parce。

数値を文字列にするのには次のものがある。
Cの_〜toa、_〜tow（非標準）。sprintf/swprintf。この行のは全てVC8の_s版（全て非標準）もある。
C++のostringstream類。
.Net　FrameworkのConvert::ToStringとObject::ToString。

ちなみにそれぞれ対称性がある。

C++のstream以外は全て数値の型により関数名などが異なっている。
だからunsigned　longを使うかunsigned　long　longを使うかで違いが出てくる。

819:デフォルトの名無しさん
06/03/05 21:28:41
というか、unsigned long long int って型はまだ標準じゃないよな

820:デフォルトの名無しさん
06/03/05 21:31:17
>>819
C++にはまだないが、C++/CLIには存在する。
URLﾘﾝｸ(signe.japan.webmatrixhosting.net)

821:デフォルトの名無しさん
06/03/05 21:44:23
>820
それは知ってるが、標準関数が対応してないってこと
ってそこ直リンすんなよ

822:デフォルトの名無しさん
06/03/05 21:46:10
>>821
だからC/C++のunsigned　long　longが関係するところは全て非標準だな。

823:デフォルトの名無しさん
06/03/05 21:49:23
そだな。非標準の型は全部 CLI 型表記にした方がわかりやすいと思うんだが
変に今までと一緒なもんだから、間違えやすいんじゃないかな

824:デフォルトの名無しさん
06/03/05 22:01:51
それよりも混乱する原因はC、C++、.Net　Frameworkのクラス・関数が入り乱れているからのほうが大きいと思う。
答えているほうだって、あれ使え、いやこれ使えって具合だし。

そもそも一旦十六進法の文字列へ変換するまではともかく、その後文字列へ変換する必要性がわからない。
そのままtextBox2->Text　=　textBox1->Text;でいいと思うのだが。
大文字小文字を揃えたいだけならtextBox1->Text->ToUpper()で十分だし。

825:デフォルトの名無しさん
06/03/05 22:01:55
>>817さん
どうもです
>>なんでわざわざ wchar_t の配列に変換するのかな
>>814さんの書いたとおり
std::wcstoulと_ultow_sの呪縛に囚われていました
こうやって見ましたが

private: System::Void button1_Click(System::Object^ sender, System::EventArgs^ e)
　　{
　　　　UInt64 hoge = 0LL;
　　　　if ( UInt64::TryParse(textBox1->Text))
　　　　　　hoge = UInt64::Parse(textBox2->Text);
　　　　String^ tmp = hoge.ToString();
　　}

if ( UInt64::TryParse(textBox1->Text))ここで
: error C2661: 'System::UInt64::TryParse' : 1 個の引数を伴うオーバーロードされた関数はありません。
こうなるのですが・・・


826:デフォルトの名無しさん
06/03/05 22:04:35
>>825
MSDN見ろ。
TryParseは2つ目に結果を格納する引数がある。

827:デフォルトの名無しさん
06/03/05 22:26:47
>>826さんどうもです
private: System::Void button1_Click(System::Object^ sender, System::EventArgs^ e) {

UInt64 hoge = 0LL;
　　if ( UInt64::Parse(textBox1->Text))
　　　　hoge = UInt64::Parse(textBox2->Text);
　　else
　　　　String^ tmp = hoge.ToString();
　　}
こうしたら、できましたが、実行すると
アプリケーションのコンポーネントで、ハンドルされていない例外が発生しまし。
中略
入力文字列の形式が正しくありません。

ust-In-Time (JIT) デバッグを呼び出すための詳細については、
ダイアログ ボックスではなく、このメッセージの最後を参照してください。
中略
************** JIT デバッグ **************
Just-In-Time (JIT) デバッグを有効にするには、このアプリケーション、
またはコンピュータ (machine.config) の構成ファイルの jitDebugging
値を system.windows.forms セクションで設定しなければなりません。
アプリケーションはまた、デバッグを有効にしてコンパイルされなければ
なりません。



828:デフォルトの名無しさん
06/03/05 22:28:57
>825
勘違いしたんじゃ、ないぞ。MSDNを見るようわざと間違えたんだからな
決して、名前だけで bool 値を返すんだろとか考えて適当に書いた訳じゃ、ないんだからな

829:デフォルトの名無しさん
06/03/05 22:30:52
>>827
MSDN見ろ。1つめの引数の文字列の書式が書いてある。UInt64::Parseは十進法しか受け付けない。
Convert::ToUInt64なら基数が指定できるけど、Try版がないから例外を受けるしかないと思う。

830:デフォルトの名無しさん
06/03/05 22:30:54
ｽﾏｿ
Try外していました
しかし、TryParseの問題を解決しても
例外エラーは出そうな感じがするんだが

831:デフォルトの名無しさん
06/03/05 22:39:02
>827
だから、MSDN で UInt64 のメソッドぐらいチェックしろと

そろそろ何をしたいのかがわからんのだが。自分が書いているコードの意味がわかってる？

textBox2 に textBox1 の内容をコピーしたいのなら >824 が言ってるとおり
textBox2->Text = textBox1->Text;
だけでいいはずだし、いったん、数字にしてなんかの検証をしたいのなら
なぜ、いきなり textBox2->Text から数値を取ってるんだ？

マジに書くと
if ( !String::IsNullOrEmpty() )
{
　　try
　　{
　　　　UInt64 hoge = UInt64::Parse(textBox1->Text);
　　　　textBox2->Text = hoge.ToString();
　　}
　　catch( ... )
　　{
　　}
}
まぁ、例外処理は除いたが、いったん数値にして、別のテキスト・ボックッスに文字列として
代入するならこんな感じだろ

832:デフォルトの名無しさん
06/03/05 22:40:02
あ、
if ( !String::IsNullOrEmpty() ) →if ( !String::IsNullOrEmpty(textBox1->Text) )
だったorz

833:デフォルトの名無しさん
06/03/05 23:06:15
そもそも、目的はbutton1を押すとtextBox1に入力した
16進数の入力判定を行い、（条件として、空でないこと、16進数16桁であること）
button2を押したら、openFileDialogを呼び出しファイルを選択してOKを押したら
textBox2に選択したファイルを読み込ませ（ここは既に実装できています）
最後にbutton3を押したらtextBox1とtextBox2を結合し、saveFileDialogで
名前を付けて保存するという、単純なものなのですが16進数変換と入力判定の所で
どつぼにはまってしまいました。

文字入力
↓
16進数変換＆入力チェック
↓
外部ファイル読み込み
↓
16進数＋外部ファイル結合
↓
名前を付けて保存


834:デフォルトの名無しさん
06/03/05 23:24:16
とりあえず判定は829のように例外が投げられるかどうか調べるしかないと思う。

835:デフォルトの名無しさん
06/03/06 00:26:19
ちょっと理解できてきたみたいです
//16進数を受け付ける
UInt64 hoge =Convert::ToUInt64(textBox1->Text,16);
//10進数を受け付ける
UInt64 hoge = UInt64::Parse(textBox1->Text);
textBox2->Text = hoge.ToString();
やっと16進数の入力を考えれるようになりましたが
UInt64 hoge =Convert::ToUInt64(textBox1->Text,16);
textBox2->Text = hoge.ToString();
で出力すると、ご丁寧にも16進数から10進数に変換されています
ヮ(ﾟдﾟ)ォ!



836:デフォルトの名無しさん
06/03/06 00:28:58
16進で出力すればいいじゃん。
何言ってんだ？

837:デフォルトの名無しさん
06/03/06 01:07:29
やっとできました、どうも皆さん
ｱﾘｶﾞﾀﾏｷﾝ ( ´∀｀)ﾉ⌒ω)Д`)ﾌﾞﾆｭ
UInt64 hoge =Convert::ToUInt64(textBox1->Text,16);
wchar_t foo[16];
memset(foo, 0, 16*sizeof(wchar_t));
_i64tow_s (hoge,foo,16,16);
String ^tmp = gcnew String(foo);
textBox2->Text = tmp;
しかし、例外処理が超難関だな(;´д｀)ﾄﾎﾎ…
try {}catch( )の構文前からスマートでかっこいいと思っていたので
覚えたいと思っていたんだがな、ムズそうだな・・・・
今更泥臭くMessageBoxで条件判定するのも、なんだかなぁー


838:デフォルトの名無しさん
06/03/06 01:19:03
学生さん？

839:デフォルトの名無しさん
06/03/06 04:30:32
>>837
textBox2->Text = Convert::ToUInt64(textBox1->Text, 16).ToString("x");

ちゅうかうざい。

840:デフォルトの名無しさん
06/03/06 07:57:43
ToString が書式指定できることを知らんと言うのもありがちで、MSDNを見れば・・・

だが、Express の配布で C++/CLI を使う初心者がこんな感じに騒いだらこの先恐ろしいな


841:デフォルトの名無しさん
06/03/06 08:43:29
L"..."を
template引数で使うとconst wchar_t*にならない？
(generic,overloadだとStringになった)

void call_overload(String^ s){Console::WriteLine("String");}
void call_overload(const wchar_t* w){Console::WriteLine(L"const wchar_t*");}
template <typename T> void call_template(T t){Console::WriteLine( (T::typeid)->Name );}
generic <typename T> void call_generic(T t){Console::WriteLine( (T::typeid)->Name );}

call_overload(L"123");//String
call_template(L"123");//Char*
call_generic(L"123"); //String


842:デフォルトの名無しさん
06/03/06 11:11:27
仕様にそう書いてあった
template では const char* や const wchar_t* が渡されたら、char や wchar_t の配列として
扱い、ジェネリック関数は型引数で const char* や const wchar_t* が渡された場合には
String として型推論するというルールだって

call_template(gcnew String("123"));
とやると、String としてちゃんと帰ってきた


843:デフォルトの名無しさん
06/03/06 13:16:33
MFCはどうなるんでつか？

STL.CLIみたく、MFC.CLIが出るんでつか？

844:デフォルトの名無しさん
06/03/06 13:20:15
つ CWinFormsControl

845:デフォルトの名無しさん
06/03/06 13:27:29
Microsoft .NET Framework の Windows フォームを使用したペインティング テクニック
URLﾘﾝｸ(www.gotdotnet.com)
これを参考に、C++/CLI からのグラフィックスの基礎を勉強しています。

最後の TextClipping というアプリケーションの例で、
protected override void OnPaintBackground(PaintEventArgs e)
という C# における記述が出てくるのですが、
同様の記述を C++/CLI でやってみたところ、
override 仕様にも基本クラスで OnPaintBackground は
virtual じゃないよ、って言われます。

.NET Framework 2.0 で何か変更になったのでしょうか？

846:デフォルトの名無しさん
06/03/06 14:19:42
自分のメソッドの宣言で virtual は書いたけど override 指定していない方に つ�I

847:デフォルトの名無しさん
06/03/06 14:49:30
汚い文法だなぁ

848:デフォルトの名無しさん
06/03/06 15:17:51
>>864 OnPaintBackground つーのは、規定クラス
System::Windows::Forms で virtual で宣言
されている「はず」だったんですが・・・
んじゃ、OnPaint とかを乗っ取る事はできないのかなぁ。

849:デフォルトの名無しさん
06/03/06 15:28:57
ｆつべｖうぇ４５ｗｖｗ３４

850:デフォルトの名無しさん
06/03/06 15:57:19
>848
まぁ、漏れあてなんだろうけど、C++/CLI では暗黙のオーバーライドは禁止されている
ちゃんと
virtual void OnPaintBackGround(...) override ←これ
{
...
}
と記述してる？　これ書いても上書きできていないの？

851:デフォルトの名無しさん
06/03/06 17:32:02
>>850 忘れてました orz

852:デフォルトの名無しさん
06/03/06 21:01:39
>>100 本買ってまで勉強する必要はないんじゃない？

853:デフォルトの名無しさん
06/03/07 18:46:38
private:
　　void button1_Click( Object^ /*sender*/, System::EventArgs^ /*e*/ ){
　　hoge = "";
　　〜
}

private:
内で定義した変数って、よそのプロシージャーでは当然使えませんよね
グローバル変数で定義すれば、いいのだろうけど
NETで
※どんなアルゴリズムでも、グローバル変数なしで
記述できることが証明されています。
グローバル変数は後述するように、非常に強力な反面、
大きな危険性を秘めています。
とはいえ、絶対に知っておくべき事柄です。
らしい、button1で発生した変数を、button2のイベントが起きたときに
継承させる方法を
、グローバル変数無しで実現できるの？


854:デフォルトの名無しさん
06/03/07 19:41:37
>>853 まずもってプロシージャってのが C++ にあるか
ってのは置いといて、そのフォームのメンバ変数は
button1_Click() からでも button2_Click() からでも
アクセスできるじゃん。

855:デフォルトの名無しさん
06/03/07 20:40:47
そんなことはないやろ、
private:
　　void button1_Click( Object^ /*sender*/, System::EventArgs^ /*e*/ ){
　　hoge = "";
　　〜



} private:
　　void button2_Click( Object^ /*sender*/, System::EventArgs^ /*e*/ ){
　　textBox2->Text=hoge;
　　〜
}

: error C2065: 'temp' : 定義されていない識別子です。

856:デフォルトの名無しさん
06/03/07 20:57:37
>>855
それ別の位置でコンパイルエラー出てるだけじゃないか？
そのコードの中にtempなんて識別子は出てないのだが

857:デフォルトの名無しさん
06/03/07 21:14:41
>856
この人が言ってるの、auto 変数のことじゃない？
メソッド内部で宣言したローカル変数にアクセスしたがってるんだよ

858:デフォルトの名無しさん
06/03/07 21:20:23
>>857 そんなもん、VB でもできんわ・・・
プロシージャとかいってるからたぶん
VB使いかな？とか思った。

859:デフォルトの名無しさん
06/03/07 21:53:50
やっぱり、無理やな

860:デフォルトの名無しさん
06/03/07 21:55:54
>>853 の頭の中には、ローカル変数とグローバル変数しか内のだろうか。

861:デフォルトの名無しさん
06/03/07 21:56:09
プロシージャが WinProc のことなら、Form 間でのアクセスのことかも
何にしても、そんな状態でC++/CLIに手を出すのはやめた方がいいと思う

862:デフォルトの名無しさん
06/03/07 22:24:46
そもそもC++/CLIでなくてもC#でもなんでもやめたほうがいいな。

863:デフォルトの名無しさん
06/03/07 22:51:56
>>862も人生をやめたほうがいいな。

864:デフォルトの名無しさん
06/03/08 02:13:35
C++/CLI がこんなにも複雑なのがいけないと思います！

865:デフォルトの名無しさん
06/03/08 02:40:33
まぁ何でもあり(？)なのが C++/CLI だしなぁ。
複雑さを避けたいなら、C#だよな。
あ、VB.NET って手もあるか。

866:デフォルトの名無しさん
06/03/08 02:58:40
>>865
> まぁ何でもあり(？)なのが C++/CLI だしなぁ。
まさにC++から派生した、って感じだな

867:デフォルトの名無しさん
06/03/08 07:35:51
言語仕様を拡張せずに .NET 対応は出来なったのかなぁ。
managed_ptr<Object> obj = managed_new<Object>();
みたいな。

868:デフォルトの名無しさん
06/03/08 07:39:15
>>867 managed C++ であんまりうまくいかなかったから、
結局言語使用の拡張に踏み切ったんだろ。

869:デフォルトの名無しさん
06/03/08 08:18:59
>867
逆に、どこまでが既存の C++ でどこからが CLI 拡張かわかりやすくていいと思うよ
mc++ の混乱ぷりから考えるに、MSが出した仕様にしてはさっぱりしすぎて不思議
時代が変わっても、フレームワークをさくっと切り替えるだけで対応できるし、VES も
簡単に交換可能なところが夢があると思われ
また、C++ 自体の拡張の邪魔にならないところとかもいい
Sun も JNI の仕様をこれにしないかな。そしたら、JVM も使う気になるのに

870:デフォルトの名無しさん
06/03/08 08:24:21
Java をネイティブ拡張したものがが仮にあったとして、
C++/CLI とどっちを使う？？

871:デフォルトの名無しさん
06/03/08 08:38:56
その仮とやらの質による。存在しないものと比較しても仕方がない


872:デフォルトの名無しさん
06/03/08 09:48:43
おい！！！！
だれだよ、俺のプロジェクトで勝手に /clr:pure にした奴は！
おかげで全部 __clrcall になっててリンクできずに
一晩悩んだじゃないか！

さて、そろそろ帰るか。

873:デフォルトの名無しさん
06/03/08 19:50:08
>>870
Javaをネイティブ拡張したもの≒C#

874:デフォルトの名無しさん
06/03/08 20:04:29
Java = C++--
C# = Java++ = C++--++

875:デフォルトの名無しさん
06/03/08 21:20:07
>>873
ネイティブじゃナインじゃん

876:デフォルトの名無しさん
06/03/08 21:26:46
String^ arg_1 = abc;
String^ arg_2 = def;
textBox1->Text = arg_1 + arg_2;
としたら
abcdef
と出力出来ますが
textBox1->Text = arg_1 + endl + arg_2;
: error C2679: 二項演算子 '+' : 型 'overloaded-function' の右オペランドを扱う演算子が見つかりません (または変換できません)。
となり、期待していた
abc
def
が出来ません
誰かrg_1とarg_2の間に改行を入れて
abc
def
となる様にしてください。
ｵﾅｶﾞｲｼﾏｽ

877:デフォルトの名無しさん
06/03/08 21:33:42
System::Environment::NewLine

878:デフォルトの名無しさん
06/03/08 21:34:09
textBox1->Text = arg_1 + endl + arg_2;
じゃなくて
textBox1->Text = arg_1 + "\n" + arg_2;
でいいじゃん。

std::endl はマニピュレータで、、
マネージド型である String に対して
+ 演算子がオーバーロードされているなんてことはまずない。


879:デフォルトの名無しさん
06/03/08 21:36:40
"\r\n"にしないとだめではないか？

880:デフォルトの名無しさん
06/03/08 21:45:08
変だな？
textBox1->Text = arg_1 + "\n" + arg_2;
としたら
コンパイルも通ったんだけど
textBox1に表れた文字が
abc・def
全角文字の・に似た記号が出ます（多分全角の・とは違う気がするが、定かではない）
秀丸に貼り付けると
abc
def
と改行されてるんだが、なぜ？


881:デフォルトの名無しさん
06/03/08 21:47:30
>>880
サンクスできましたが、解説もｵﾅｶﾞｲｼﾏｽ
なんで
"\n"では駄目で"\r\n"なの？


882:デフォルトの名無しさん
06/03/08 21:54:42
Windowsの改行コードは"\r\n"だから。
UNIXとかのコンソールプログラムでは\nで
Macは"\r"

883:デフォルトの名無しさん
06/03/08 21:56:39
そしてC/C++は\nを使い、テキストモードでの入出力時には環境固有の改行コードと\nとで変換をしている。

884:デフォルトの名無しさん
06/03/08 21:57:50
ウィンドウズはそういうもん。
Unix : 円 n
Windows : 円 r 円 n
旧 mac : 円 r

コンソールアプリは透過的に 円 n ⇔ 円 r 円 n やってくれるが
テキストボックスとかはやってくれない。
秀丸じゃなくってノートパッドならやっぱりナカテンが出ると思う。


885:デフォルトの名無しさん
06/03/08 21:58:49
みんなでケコーン

OS X は ¥n になったよ ... 関係ないですが。

886:デフォルトの名無しさん
06/03/08 22:01:40
>>882->>885
>>881です
ご丁寧にありがとうございました、よく理解できました
しかし皆さん本当に良く知ってますね

887:デフォルトの名無しさん
06/03/08 22:01:47
>>884
どっちかと言うと円記号よりもバックスラッシュ。

888:デフォルトの名無しさん
06/03/08 22:16:41
完璧な回答を出しているのにスルーされてる>>877がｶﾅｼｽ

889:デフォルトの名無しさん
06/03/08 22:31:06
>>887さん
ありがとう
ｽﾏｿ、やっぱりC++/CLIならこうですよね
(ﾟдﾟ)(｡_｡)(ﾟдﾟ)(｡_｡) ｳﾝｳﾝ
msdnでよく調べます


890:デフォルトの名無しさん
06/03/09 18:13:54
String型の変数arg_1を書き込みたいのですが、
下記のコードでコンパイルも通りるのですがアプリケーションのコンポーネントで、
ハンドルされていない例外が発生しました〜後略
別のプロセスで使用されているため、プロセスはファイル'C*\hoge.txt'に
アクセスできません。
となってしまいます、どこがおかしいのでしょうか？

protected:
void button3_Click(Object^ /*sender*/, System::EventArgs^ /*e*/){
　　using ::System::Windows::Forms::DialogResult;
　　Stream^ myStream ;
　　SaveFileDialog^ saveFileDialog1 = gcnew SaveFileDialog();
　　saveFileDialog1->Filter = "txt files (*.txt)|*.txt|All files (*.*)|*.*" ;　　　saveFileDialog1->FilterIndex = 2 ;
　　saveFileDialog1->RestoreDirectory = true ;
　　if(saveFileDialog1->ShowDialog() == DialogResult::OK)
　　{
　　　　if((myStream = saveFileDialog1->OpenFile()) != nullptr)
　　　　{
　　　　// Code to write the stream goes here.
　　　　System::IO::StreamWriter^ sw = gcnew
　　　　System::IO::StreamWriter(saveFileDialog1->FileName);
　　　　sw->Write(arg_1);
　　　　sw->Close();
　　　　myStream->Close();
　　　　}
　　}
}

891:デフォルトの名無しさん
06/03/09 18:29:48
なんでSaveFileDialog->OpenFileで開いてるのにさらにStreamWriterで開き直す？
すでに開いているストリームに対してStreamWriterを使うのならStream^を渡す。

892:デフォルトの名無しさん
06/03/09 18:50:37
最近よう、気のせいか初心者歓迎スレに変わってきてないか？
なんか、聞けばいいと思っている輩が増えてきた気がするんだが

893:デフォルトの名無しさん
06/03/09 18:53:25
>>891
SaveFileDialog->OpenFileに書き込むには
どうしたらいいですか？


894:デフォルトの名無しさん
06/03/09 19:15:18
System::IO::StreamWriter^　sw　=　gcnew　System::IO::StreamWriter(myStream);

初心者はC#かVBからはじめるのがいいよ。MSDNの見方くらい覚えような。

895:デフォルトの名無しさん
06/03/09 20:52:02
>>894
ありが�d


896:デフォルトの名無しさん
06/03/10 01:26:35
C++/CLI みたいなマニアな言語を使おうとする奴が
なぜこんなところで教えてくんしてるのか判らん。
(マニア、というのは、それでないと書けないほどのアプリを
書かないといけないはめになっていないと使わないだろう、
ぐらいの意味。)
MSDN 読めるぐらいでないと C++/CLI 手を出さないと思うんだが、
どうなってんだろう？

897:デフォルトの名無しさん
06/03/10 03:18:05
しらんがな。

898:デフォルトの名無しさん
06/03/10 08:44:22
>>896
少しはC++をやっていて、新しい言語に手を付けずに.Netが使えるぞと思っているんだよ、きっと。
実際はC++とC++/CLIとは別物だということを知らず。

899:デフォルトの名無しさん
06/03/10 09:08:02
つーか、自然な流れだと思うぞ。

一般的にC++が普及してた。
ライブラリはMFCやらWin32APIやらATLを使ってたであろう。
そして、MSの次期スタンダードなライブラリが、.NETになった。
じゃあ、C++から.NETを使おうか。

こんな感じでしょ。
間違いだとも思わない。

900:デフォルトの名無しさん
06/03/10 09:11:06
ええっと、言語間の違いよりも、
ライブラリ間の違いのほうが余程大きいと思うんですが...

901:デフォルトの名無しさん
06/03/10 09:18:01
一般的に旧VBが普及してた。
PC以外で死滅気味だった言語が台頭。サーバーサイドJavaや組み込みC++。
サーバーサイドや組み込みに足を踏み入れるドトネトとＣ丼を強制。
ﾌﾞﾋﾞ厨氏滅＆ドトネト氏産。
ｵﾈｶﾞｲC++からドトネト使ってトンでも言語mc++ → C++/STL.CLI

902:デフォルトの名無しさん
06/03/10 09:22:57
>>901
日本語でおｋ

903:デフォルトの名無しさん
06/03/10 09:44:39
899=線能されてる

C++の文法複雑＋マネージドの理解＋旧ＣＯＭの理解を要するなんてサイアクじゃん。
で、C++のBoostなんかは使えないという利点が無いオマケ月。

904:デフォルトの名無しさん
06/03/10 09:51:19
>>903 ネイティブな領域では普通に Boost 使えてるけど？
たとえば Boost.Serialization で既存のデータを読み込んで、
Windows Forms で表示したり ADO.NET で DB に投入したりできる。

905:デフォルトの名無しさん
06/03/10 09:54:30
>>904
書いてて自分の文章の複雑さに気付かない？

906:デフォルトの名無しさん
06/03/10 09:56:50
ｽﾚﾘﾝｸ(tech板:115番)
こういうこともあるみたいだけど。

907:デフォルトの名無しさん
06/03/10 10:01:59
>>904 ネイティブな領域では普通に Boost 使えてるけど？

なんだ、丸々大ウソか。
さすが線能されてるだけある。

M$もCOMでC++を汚しきったが、mc++で文法破壊、CLIでライブラリ破壊だね。

908:904≠899
06/03/10 10:16:42
>>906 それ書いたの俺。で、そのオチが >>872

909:デフォルトの名無しさん
06/03/10 10:20:06
>>908
>だれだよ、俺のプロジェクトで勝手に /clr:pure にした奴は！

PUREでない混合だと激遅になるドトネトに何の意味があるのかと小一時間。

910:904≠899
06/03/10 10:24:15
>>909 pure でやるなら、既存のライブラリの多くを
あきらめるってことなので、俺なら C# を選択する。

911:デフォルトの名無しさん
06/03/10 10:28:38
>あきらめるってことなので、俺なら C# を選択する。

ソースコードの価値ってのは既存コードだったり、
環境変わってもコンパイルしたりすると動くことだったりするのに、
馬の骨Ｃ丼に何の価値があるのかと。

912:デフォルトの名無しさん
06/03/10 10:29:34
ｽﾚﾘﾝｸ(tech板:1番)
　　　　　　　　 ,. -‐'''''""¨¨¨ヽ
　　　　 　 　 (.＿＿_,,,... -ｧァﾌ|　　　　　　　　　　あ…ありのまま　今　起こった事を話すぜ！
　 　 　 　 　 |i i|　 　 }!　}} /／|
　　　　 　 　 |l､{　 　j}　/,,ｨ//｜　　　　　　　『.NET framework 2.0を入れたと思ったら
　　　　　　　 i|:!ヾ､_ﾉ／ u {:}//ﾍ　　　　　　　　何故かノータッチデプロイメントがぶっ壊れた』
　　　　　　　 |ﾘ u' }　 ,ﾉ　_,!V,ﾊ |
　　 　 　 ／´fト､_{ﾙ{,ィ'ｅﾗ　, ﾀ人　　　　　　　　な…　何を言ってるのか　わからねーと思うが
　　　　 /' 　 ヾ|宀| {´,)⌒`/ |<ヽﾄiゝ　　　　　　　　おれも　何をされたのか　わからなかった…
　　　　,ﾞ　 ／ )ヽ iLﾚ 　u' |　| ヾｌﾄﾊ〉
　　 　 |／_／　 ﾊ !ニ⊇　'／:} 　V:::::ヽ　　　　　　　　頭がどうにかなりそうだった…
　　　 /／ 二二二7'T'' ／u'　__ /:::::::/｀ヽ
　　　/'´r　-―一ｧ‐ﾞＴ´　'"´ ／::::／-‐ 　＼　　　移植や修正が必要だとか
　　 / // 　 广¨´ 　/'　　 ／:::::／´￣｀ヽ ⌒ヽ　　　　そんなチャチなもんじゃあ　断じてねえ
　　ﾉ ' /　 ノ:::::`ー-､___／:::::／/ 　 　 　 ヽ　　}
_／｀丶　/::::::::::::::::::::::::::￣`ー-{:::...　　　 　　　ｲ　 もっと恐ろしいものの　片鱗を味わったぜ…

913:904≠899
06/03/10 10:31:16
>>911 だから今俺は C++/CLI 使ってるんだってば。

914:デフォルトの名無しさん
06/03/10 10:37:16
>>913
で、C++/CLI複雑じゃない？それだけ価値あるということ？

915:904≠899
06/03/10 10:38:48
>>914 使わざるを得ない場面があるということ。
あと、マゾにはたまらないって言うこと。

916:デフォルトの名無しさん
06/03/10 11:13:29
自分で判断できないような人はC#やっといた方がいい。
C++/CLIは必要があって使うもの。

917:デフォルトの名無しさん
06/03/10 11:29:40
既存のライブラリの多くを諦める事になるからC♯って意味分からん。
C♯だったら、多くを諦めるどころか、全部諦めにゃならんだろｗ
ヤケクソやってんのか？ｗ

918:904≠899
06/03/10 11:45:23
>917 そんなこといってないじゃん。
既存のライブラリを使いたいから /clr:pure あきらめて
C++/CLI つかってます、って書いてんのに。

919:デフォルトの名無しさん
06/03/10 11:56:18
ヒント；Ｍ＄ジレンマ

920:デフォルトの名無しさん
06/03/10 13:48:25
>>918
君は正しい。ただあんまり一生懸命レスすること無い。疲れるだけだから。

921:デフォルトの名無しさん
06/03/10 19:38:26
昔：VB-VC-Windwos
今：.NET Framework-C++/CLI-Windows



922:デフォルトの名無しさん
06/03/10 20:36:09
伸びてると思ったら不毛な議論が続いてたようだな。
アンチが何したいのかわからんがこんなところで騒いでも無駄ですよ

923:デフォルトの名無しさん
06/03/11 09:58:42
皆さんはやっぱり、C++/CLIでもファイルの入出力とか自作のライブラリー等
作成されてるのですか？Stream オブジェクトとか、MSDN見る限り、素人目には
既に完成されていると思うのですが、個人的にパラメータを渡して読み込み、書き込み
モードで開いたりとかテキストモードで開いたり、バイナリモードで開いたりとか、やったほうがもっと楽でミスも少なくて、いいのかなぁーと思ったりするのですが、
いかがなものでしょう？


924:デフォルトの名無しさん
06/03/11 10:07:31
逆に聞くが>>923は今まで入出力に自作のライブラリを使っていたのか？

925:デフォルトの名無しさん
06/03/11 10:10:33
>>923 C++/CLI でも、っていうか、マネージドの領域では
.NET Framework べったりのプログラミングしてます。

C++/CLI 使うメリットはネイティブとの橋渡しができる
ことだと思ってるんで、ネイティブの領域では
従来通りの自作のライブラリーを多用しています。

926:デフォルトの名無しさん
06/03/11 10:36:50
>>923
何言っているんだかわからん。
Streamのどこが気に入らなくて、どういうことをやっているわけ?

927:デフォルトの名無しさん
06/03/11 10:47:06
>>926 抽象化されていないもっとファイルシステムべったりの
いじり方をしたいのでは、と推測するけど、まぁそういうことが
したけりゃ Windows API 叩くのも C の標準ライブラリ
叩くのも低レベルファイルアクセス関数群叩くのも
C++ の標準 I/O ストリーム使うのも自由、としか言いようがないな。


928:デフォルトの名無しさん
06/03/11 20:59:39
テキストボックスに
0
1
2
3
4
5
6
7
8
9
と表示したいけど

for( int i = 0 ; i < 10 ; i++ ){
　　String^arg = Convert::ToString(i);
　　textBox1->Text = arg + "\r\n";
}
これだと
9
しか表示できないんですよね(；´∀｀)
うーんわからん


929:デフォルトの名無しさん
06/03/11 21:03:49
これはひどい

930:デフォルトの名無しさん
06/03/11 21:04:01
>　textBox1->Text　=　arg　+　"\r\n";　

931:デフォルトの名無しさん
06/03/11 21:05:39
>>928 そりゃ、Text に最後に設定されるのが
"9\r\n" だからだろ。
arg = じゃなくて arg += とかじゃないの？
と、試しもせずにカキコ

932:デフォルトの名無しさん
06/03/11 21:09:22
>>931
で、そのargはどこに行くんだ

933:928
06/03/11 21:17:24
>>930さん
>>931さん
残念ですが巧くいきません、同じ結果です

934:デフォルトの名無しさん
06/03/11 21:27:42
textBox1->Add(arg);

935:デフォルトの名無しさん
06/03/11 21:31:10
StringBuilder^ builder = gcnew StringBuilder();

for(int i = 0;i < 10; i ++)
{
　builder->AppendFormat("{1}{0}",System::Environment::NewLine,i.ToString());
}
this->textBox1->Text = builder->ToString();

936:928
06/03/11 21:58:21
>>935さん
ありがと、巧くいきました
StringBuilderクラス初めて知りました
builder->AppendFormat("{1}{0}",System::Environment::NewLine,i.ToString());
の"{1}{0}"は何を意味するものですか？


937:デフォルトの名無しさん
06/03/11 22:15:05
>>936
引数の２番目（{1}）と１番目（{0}）

.NETでは基礎的なこと。

938:デフォルトの名無しさん
06/03/11 22:21:51
うんざりするほどの教えてｸﾝだな

939:デフォルトの名無しさん
06/03/11 22:28:44
理解していない {1}{0} を教えてもらった通り
使っただけで「うまくいきました」と言える神経が理解出来ない

940:デフォルトの名無しさん
06/03/11 23:07:57
正直、C# に移って .net framework の使い方から勉強してきてほしいものだ
.net framework 総合ってあったよな

941:デフォルトの名無しさん
06/03/11 23:23:19
enum classのインスタンスを
switchの条件式に使うとunsafeにならない？
Reflectorでみたらunsafeになってたんだけど...orz

942:デフォルトの名無しさん
06/03/12 00:01:20
しかし、海外ではC#なんて朽ち果ててるのに、ここは鎖国な人ばかりですか?


943:デフォルトの名無しさん
06/03/12 00:03:12
>>942
じゃ、その海外では何を使ってるの？
あちこちでその書き込み見るんで、
マジで教えて欲しいんだが。

それにここ C++/CLI のスレッドだし。

944:デフォルトの名無しさん
06/03/12 01:06:44
北米でのサンデープログラマはJavaよりもC#が多いってニュースみたことあるけど

945:943
06/03/12 01:14:43
ちなみに、クライアントサイドでのJavaの案件なんて
ほとんど見たこと無い。

946:デフォルトの名無しさん
06/03/12 01:19:23
ref class のデータメンバにどうしてもネイティブクラスの
インスタンスを持たせたいんだけど、混合はできないから
ポインタで持たせるしかない？

ref class ManagedClass {
　 　 　 中略
　 　 　 NativeClass* nativeClass;
　 　 　 中略
};

みたいに。せめて std::auto_ptr つかって

ref class ManagedClass {
　 　 　 中略
　 　 　 std::auto_ptr<NativeClass> nativeClass;
　 　 　 中略
};

って書きたいけど、結局は混合になるからだめなんだよな。


947:デフォルトの名無しさん
06/03/12 01:36:31
gcroot
auto_gcroot

948:デフォルトの名無しさん
06/03/12 02:08:28
>>943

VB。つーか、こんな簡単な事もわからないヤツがいるのか。
日本人同士で馴れ合ってるから、バカになるんだよ。


949:デフォルトの名無しさん
06/03/12 02:38:05
>>948
明らかにどっちもやったことない苦し紛れ臭漂うコメントだな。

950:デフォルトの名無しさん
06/03/12 03:25:39
>>949
いや、ぜんぜん。

つーか、やったことがある・ないって話はしてない。ばかだね。あんた。


951:デフォルトの名無しさん
06/03/12 03:38:45
>>950
ないのならいかに自分が馬鹿な話をしてるかわからんのも仕方ない。

952:デフォルトの名無しさん
06/03/12 03:45:21
>>951
もうチョイ日本語、勉強しましょうねー。

953:952
06/03/12 04:05:27
アンカミス

×>>951
○>>952

954:デフォルトの名無しさん
06/03/12 04:05:29
>946
そのためのファイナライザと割り切るしかないんでない
心配なら、管理クラスを別途作って、そこからポインタを受け取ってもいいんだし

955:デフォルトの名無しさん
06/03/12 04:09:20
初歩的な質問ですみませんが、お願いします
hoge_0.txt
hoge_1.txt
略
hoge_9.txt
という10個のファイルを作ろうと思い
for(int i = 0;i < 10; i ++){
　　Stream^ myStream ;
　　String^x=Convert::ToString(i);
　　StreamWriter^ sw = gcnew StreamWriter ("c:\\hoge_"+x+ ".txt");
　　sw->Close();
myStream->Close();
}
（書き込む部分は省略させて貰います）
コンパイルは通りますが、
「オブジェクト参照がオブジェクト　インスタンスに設定されていません。」
と表示されてしまいます、
hoge_0.txt一つだけc:\直下に作成されています
どうしてでしょうか？


956:デフォルトの名無しさん
06/03/12 04:13:58
コード見直せ　明らかにおかしいだろ

957:デフォルトの名無しさん
06/03/12 04:15:06
StreamWriterをCloseするときにStreamも一緒にCloseしてるからじゃね。

958:デフォルトの名無しさん
06/03/12 04:16:39
C(++) もやったことないのに C++/CLI に手を出すのは無謀

959:デフォルトの名無しさん
06/03/12 04:17:16
コンパイラさんが myStream が初期化されてないよって警告出さんのか

960:デフォルトの名無しさん
06/03/12 04:24:17
指摘されて今気づきました
Stream^ myStream ;

myStream->Close();
を、おまじないみたいに勘違いしてたようです

961:デフォルトの名無しさん
06/03/12 04:30:55
おまじないとな

962:デフォルトの名無しさん
06/03/12 05:24:46
次スレのテンプレにあれだ、初心者お断りとでも書いとけ。

　　　 ＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
　　　｜
　　　｜★ 初心者に扱える言語ではありません ★
　　　｜
　　　｜　・初心者はまず C/C++ か C# をしましょう。
　　　｜　・両方とも中級者以上になったら来てください。
　　　｜
　 　Λ Λ　 ／
　　(,,ﾟДﾟ)⊃ ﾁｭｳｲ!
〜/U /
　U U ￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣


963:デフォルトの名無しさん
06/03/12 05:42:05
C#はやらんでもええ。

964:デフォルトの名無しさん
06/03/12 06:05:50
>>963
いや、このスレにずっといて必要だと思ったから書いたのだけど？
CLRの基本的なことも分かってないようなやつは危ない。
C#では仕様的に避けられてたり、ふらっとスレでも聞かないような
レベルの質問ばかりじゃん。

んで一番速く理解できるのはC#だし、C++と文法似てるし。

965:デフォルトの名無しさん
06/03/12 08:36:56
というか、移行組にとって辛いのは、.net framework の使い方がわからないというところじゃね？
だから、C++ はわかるけど、それを CLI の流儀でどう書けばいいのかわからなくて、初心者ｽﾚ
で聞くような質問をここでしてしまう、と

最近紹介されて知名度が上がってきた分、飛びついてくる奴らがなんかくらくらするような
質問をしてしまうわけで、.net ｽﾚへ誘導というのも、言語の垣根を越えた C++/CLI の可能性を
示すという点でいいのかも


966:デフォルトの名無しさん
06/03/12 08:45:29
C++/CLI は C++ しか知らない人がマネージドなプログラムを
書くための言語ではなくて、C++ で仕事してきて、かつ、
C# などで .NET Framework 上で動くプログラムも作ってきて、
両方の資産とノウハウを抱えている人がそれらの分断に悩んで
たどり着くソリューションだと思う。

967:デフォルトの名無しさん
06/03/12 08:52:04
>966
それは漏れもそう思うんだけど、実際にはあの顔文字使う教えてｸﾝみたいなやしが
あれだけ言われても MSDN もチェックせずに気軽に尋ねにきていやがるこのｽﾚの現状を
考えると、あるべき論ではなぁ
ｽﾚのふいんきをもっと殺伐させて、気軽に質問できないようにした方がいいかもな
後は、答えるときは罵倒しながら、丁寧に答えるとか

>980 ｽﾚ立てよろ

てんぷれ作る？

968:デフォルトの名無しさん
06/03/12 09:51:53
とりあえず教えて君はレベルに関係なくスルーすればいいんじゃないのかな?
排除を全面に出しすぎるのも大人げないというか。

managed C++ → C++/CLI
URLﾘﾝｸ(www.microsoft.com)
［特集］ Visual C++ 2005 いままたC++が熱い！「C++/CLI」として大進化したVisual C++ 2005
URLﾘﾝｸ(www.atmarkit.co.jp)
Calling Native Functions from Managed Code
URLﾘﾝｸ(msdn2.microsoft.com)(en-US,VS.80).aspx

C++/Cli Essentials
URLﾘﾝｸ(www.amazon.com)
Shared Source Cli Essentials
URLﾘﾝｸ(www.amazon.co.jp)

C++/CLI設計者のblog
URLﾘﾝｸ(blogs.msdn.com)
URLﾘﾝｸ(blogs.msdn.com)

STL.NET
URLﾘﾝｸ(www.microsoft.com)
URLﾘﾝｸ(www.dinkumware.com)

C++の今後
URLﾘﾝｸ(216.55.183.63)

969:デフォルトの名無しさん
06/03/12 10:03:33
>>1 に >>964-966 あたりのことをさらっとかいておくとよいのでは？

----------------
C++/CLI は単なる C++ の拡張ではなく、既存の C++ のコード資産と
.NET Framework をはじめとしたマネージドなコード資産の橋渡しを
するものです。.NET Framework でのプログラミングになれていない人は
Visual Basic .NET や C# である程度基礎的な概念を学習してから
取り組む方がよいでしょう。
----------------

とか。

970:デフォルトの名無しさん
06/03/12 10:04:11
>>968 排除は本望じゃないけど、誘導は必要だ、ということで。

971:デフォルトの名無しさん
06/03/12 11:01:01
C# と同じような間隔で XML ドキュメントを書き込んでたら、
C++/CLI では XML ドキュメントってサポートされてないんだね。
そのへんは C++ と同じなんだから当たり前か。

ところで、マウスポインタを識別子の上に持って行ったときに
現れるチップでもコメントを表示して欲しい名x。亜

---

次ページ

最新レス表示

スレッドの検索

類似スレ一覧

話題のニュース

おまかせリスト

▼オプションを表示

レスジャンプ

mixiチェック！

Twitterに投稿

オプション

しおりを挟む

スレッドに書込

スレッドの一覧

暇つぶし2ch

---

5372日前に更新/240 KB
担当:undef