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

【.NET】 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化とかはしてなかったんですが、試してみます。

476:デフォルトの名無しさん
06/01/19 12:26:53
>>475
refタイプでない普通のクラスはrefクラスでラップする必要がある。ダイレクトには渡せない。

477:デフォルトの名無しさん
06/01/19 13:41:47
>クラスへの参照を受け取って処理結果をその中に返す

可能だろ。

478:デフォルトの名無しさん
06/01/22 14:20:10
参照クラスを値クラスに変換する
template等は用意されているのでしょうか？

479:デフォルトの名無しさん
06/01/26 10:52:47
ｷｲﾀ?( ﾟдﾟ)ｵｸｻﾝ(ﾟдﾟ )ｱﾗﾔﾀﾞﾜｧ

480:デフォルトの名無しさん
06/01/29 18:09:11
C++/CLI が次の VS まで生き残ってるか、かなり不安。
とはいえ、C++/CLI を結構使ってるけど。

481:デフォルトの名無しさん
06/01/29 19:45:25
C#→C++への変換ってできんの？

482:デフォルトの名無しさん
06/01/29 19:50:24
そりゃいくら何でも無理だろ。

483:デフォルトの名無しさん
06/01/29 20:27:13
>>481
ｺﾝﾊﾟｲﾙ→.net reflector

484:デフォルトの名無しさん
06/01/29 21:01:45
cli_class<T>::m_member' : 指定されたメンバは初期化できません。
というエラーが出るのですが、m_memberをコピーするにはどうしたらいいのでしょうか？

generic <typename T> ref struct cli_class
{
T m_member;
cli_class(const cli_class% n)
:m_member(n.m_member) //error
{}
};

485:デフォルトの名無しさん
06/01/29 23:25:35
generic <typename T> where T : System::ICloneable ref struct cli_class
{
T m_member;
cli_class(const cli_class% n)
//:m_member(n.m_member) //error
{
if ( n.m_member != nullptr )
m_member = safe_cast<T>(n.m_member->Clone());
}
};

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

486:デフォルトの名無しさん
06/01/30 11:48:01
二項演算子で単項で使われていなかったものオンパレードですね

487:デフォルトの名無しさん
06/01/30 13:02:57
cli_class が確定してなくね？
generic <typename T> ref struct cli_class
{
　　T m_member;

　　cli_class()
　　{}
　　cli_class(cli_class<T>% n)
　　　　:m_member(n.m_member) //error
　　{}
};

const 付けると、型パラメータも影響を受けてキャストできなくなるから
const 外した

488:デフォルトの名無しさん
06/01/31 17:35:17
GCC の仲間に C++/CLI コンパイラが仲間入りする日が
いつかやってくると思う人、いる？

489:デフォルトの名無しさん
06/01/31 17:51:54
ﾉｼ Java もコンパイルできてるんだから、CLI抜きでやっちゃいそうな気がする

490:デフォルトの名無しさん
06/01/31 18:02:27
>>489
おまい、それ普通のgcc。

491:デフォルトの名無しさん
06/01/31 18:09:14
mingwで構造化例外って実装されてるの?

492:484
06/01/31 18:49:53
>>487
なるほどconstはずしたらできました。
ありがとうございました。

493:デフォルトの名無しさん
06/01/31 19:34:10
>490
ああ、実行エンジン無しで作っちゃいそうな気がするってこと

494:デフォルトの名無しさん
06/02/01 00:17:29
CLRのこと?

495:デフォルトの名無しさん
06/02/01 06:59:47
ランタイムはコンパイラコレクションが
提供しなくてもいいんじゃない？

496:デフォルトの名無しさん
06/02/01 08:47:44
GCC で CIL を出力するだけじゃ意味がないから、exe を実行するときバインドするの実行
エンジンはCLR か mono に頼るの？

497:デフォルトの名無しさん
06/02/01 09:02:05
>>496 そうなるだろうなぁ。
mono の mcs の方が C++/CLI コンパイルできるように・・・
ならないだろうな。

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

498:デフォルトの名無しさん
06/02/01 09:55:46
monoって実行ファイル起動時に外部エンジンにアタッチしてやりとりできるいい仕組みって
ある？　Java の JNI で C/C++ から VM 叩くようなヤシ

499:デフォルトの名無しさん
06/02/01 10:32:17
DLL の呼び出しと同じ仕組みが使えた気がする。

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

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

500:デフォルトの名無しさん
06/02/01 10:34:03
ｽﾚﾘﾝｸ(tech板:21番)
の兄弟の片割れが漏れなんだが(もう一人は誰か知らん)
その詳細なリポートを書いた mono の前スレが見れん。

501:デフォルトの名無しさん
06/02/01 10:34:53
それはそうと、JNIって「C/C++ から VM 叩くようなヤシ」か？
漏れ JNI は使ったことないんだけど、逆じゃね？

502:デフォルトの名無しさん
06/02/01 10:38:03
つーわけで、CLI からは DLL と同じように so が呼び出せると思う。
かなりオープンというか、なんというか・・・

503:デフォルトの名無しさん
06/02/01 10:59:04
連投ごめん。リンク間違えた。
ｽﾚﾘﾝｸ(tech板:21番) ね。

504:デフォルトの名無しさん
06/02/01 13:05:25
>501
JNI は Java からの C 呼び出しと、C/C++ からの JVM 呼び出しの両方を規定してるお

505:デフォルトの名無しさん
06/02/01 13:14:26
>>501 お、そうか。スマンコ
ネイティブコードからの呼び出しは正直シランコ

506:デフォルトの名無しさん
06/02/03 09:47:25
ええっと、長年Cオンリーでやってきたロートルなんですが、
新しい（？）ポインタの^に関して、詳しく解説した書籍とかありませんでしょうか？

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

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

507:デフォルトの名無しさん
06/02/03 10:18:32
managedなだけよ

508:デフォルトの名無しさん
06/02/03 10:43:00
>>506
JavaやLispやCLIの実行環境がどうなっているか調べろ。

509:デフォルトの名無しさん
06/02/03 12:53:41
>>508
それを詳しく解説した書籍とかを訊いてんだよ、ボケが。

510:デフォルトの名無しさん
06/02/03 13:02:48
そんな怒らないでよ(w
これ読みなよ、日本語はいいのがないから。

Shared Source Cli Essentials
URLﾘﾝｸ(www.amazon.co.jp)

511:デフォルトの名無しさん
06/02/03 15:55:01
>>506
C++のclassは理解してますか？
class objectを指すポインタと思えばよいかと。

512:デフォルトの名無しさん
06/02/03 19:54:02
template引数を使おうとしたらエラーが出るのですが、何がいけないのでしょうか？

ref struct F{//FNの引数にしようかなと
int operator()(int a){return a;}
};

generic <typename FN> ref struct Fn{
void test(){
FN fn;
fn.operator ()(100);// : error C2039: '()' : 'System::Object' のメンバではありません。
}
};

513:512
06/02/03 20:13:31
generic -> template
にしたら通りました。
generic の typename は Object前提になるのかな

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

515:デフォルトの名無しさん
06/02/03 23:42:54
単に、マネージドとネイティブの混合型になるから駄目なだけ

516:デフォルトの名無しさん
06/02/03 23:44:42
>515 は違った。genericsは背景型が System::Object型であることを前提としており、
コンパイル時では閉じない限り、型が確定しない
そこら辺が、文字列置き換えの template とは性質が違う

517:512
06/02/04 02:33:08
>>516
なるほどなっとくしました。
ありがとうございました。

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

518:デフォルトの名無しさん
06/02/04 02:45:42
つーか、512よ。インターフェイスで拘束されているわけでもない不定の FN 型の fn
のメソッドが呼び出せるわけないだろ？

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

519:512
06/02/04 13:45:57
>>518
すいません。ファンクタのconvariantなケースでなくて、
C++/CLIで一般に遭遇した場合という意味です。
以下のような感じでやってみたのですが、インターフェイスの実装ができませんでした。
他言語だとどうなるのか調べんとだめかな...
//NG
typedef String^ MyType;
typedef System::Collections::Generic::IEnumerator<MyType> MyEnumeratorType;
typedef System::Collections::Generic::IEnumerable<MyType> MyEnumerableType;
//OK
//typedef Object^ MyType;
//typedef System::Collections::IEnumerator MyEnumeratorType;
//typedef System::Collections::IEnumerable MyEnumerableType;

ref struct MyTest :public MyEnumerableType
{
ref struct MyEnumerator : public MyEnumeratorType
{
virtual property MyType Current { MyType get () { return nullptr; } }
virtual bool MoveNext(){ return false; }
virtual void Reset(){}
};
virtual MyEnumeratorType^ GetEnumerator() { return gcnew MyEnumerator();}
};

520:519
06/02/04 15:03:57
private: virtual Object^ System::Collections::IEnumerator::Current { Object^ get() sealed {return nullptr;} }
という風にC#を真似てみたけどだめみたいでした。
以下はC#でのサンプル

class MyTest :System.Collections.Generic.IEnumerable<string>
{
class MyEnumerator :System.Collections.Generic.IEnumerator<string>
{
public virtual string Current { get { return null; } }
public virtual bool MoveNext(){ return false; }
public virtual void Reset(){}
public virtual void Dispose(){}
object System.Collections.IEnumerator.Current { get { return null; } }
};
public virtual System.Collections.Generic.IEnumerator<string> GetEnumerator(){ return new MyEnumerator();}
System.Collections.IEnumerator System.Collections.IEnumerable.GetEnumerator() { return new MyEnumerator(); }
};

521:519
06/02/04 16:15:08
covariant return value の場合、２段階で実装すればなんとか可能でした。

ref struct MyTestBase :public System::Collections::IEnumerable
{
ref struct MyEnumeratorBase :public System::Collections::IEnumerator
{
virtual property Object^ Current { Object^ get () { return nullptr; } }
virtual bool MoveNext(){ return false; }
virtual void Reset(){}
};
virtual System::Collections::IEnumerator^ GetEnumerator() { return gcnew MyEnumeratorBase();}
};

ref struct MyTest :public MyTestBase,System::Collections::Generic::IEnumerable<String^>
{
ref struct MyEnumerator:public MyEnumeratorBase,public System::Collections::Generic::IEnumerator<String^>
{
virtual property String^ Current { String^ get() new {return nullptr;} }
virtual ~MyEnumerator(){}
};
virtual System::Collections::Generic::IEnumerator<String^>^ GetEnumerator() new {return gcnew MyEnumerator();}
};

522:デフォルトの名無しさん
06/02/04 18:01:17
managed　C++　やろうぜ！！　002
ｽﾚﾘﾝｸ(tech板)l50

523:デフォルトの名無しさん
06/02/04 18:07:52
ref　classのメソッドでEnumWindowsを使おうとしてます
コールバック関数をクラスのメソッド、LPARAMをこのクラスのポインタとしたいのですが
いい方法はありますでしょうか?

524:519
06/02/04 21:59:53
値型だとインターフェイスからしか派生できないから
521の手法使えないね...orz

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

525:デフォルトの名無しさん
06/02/04 22:31:14
>>523
P/Invokeの場合にはcallbackにはdelegateを使うんだっけな。
C++/CLIの場合はコールバック用のクラスとメソッドは普通のclassで作って
ref　classに包含したほうが楽だ。

526:デフォルトの名無しさん
06/02/04 22:33:29
>523
過去ログにがいしゅつ

527:523
06/02/04 23:47:58
>>525
ありがとうございます
チャレンジしてみます。

528:523
06/02/05 02:31:27
delegateとコールバックで検索したら見つかりました
URLﾘﾝｸ(www.microsoft.com)

529:デフォルトの名無しさん
06/02/05 19:43:18
generic parameterからgcnewできないと思ったら
new制約なんてあったんだね。
C#にあるみたいなんで試してみたらできたよ。

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

530:デフォルトの名無しさん
06/02/05 23:48:54
System.Windows.Forms.ShowDialog()をした時にタスクバーに
Windowが追加されちゃいます
タスクバーに出てこない方法ってりますか?

531:デフォルトの名無しさん
06/02/06 00:31:03
>>530
ShowInTaskbar

532:デフォルトの名無しさん
06/02/06 01:08:43
>>531
さんくす！

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

534:デフォルトの名無しさん
06/02/06 03:45:59
C++/CLIだと値クラスのプロパティとインデクサををref化できるね。
C#ではやり方が悪いのかできなかった。言語思想が違うためだろうか
これができないとインデクサで変更を扱う値型のコンテナが作れない気がするんだが...

value struct Val{int val;};

value struct Test
{
void test(){ Test test;test[100].myt.val=200;Console::WriteLine(test.myt.val); }
Val myt;
property Val% default[int]{ Val% get(int index){ return myt; } }
};

535:デフォルトの名無しさん
06/02/06 09:34:19
sage

536:デフォルトの名無しさん
06/02/06 12:59:49
Equals を使うな。使う事を推奨するな。
URLﾘﾝｸ(www.ailight.jp) ...

537:デフォルトの名無しさん
06/02/06 15:53:01
>>536
リンク修正
URLﾘﾝｸ(www.ailight.jp)
URLﾘﾝｸ(www.ailight.jp)

538:デフォルトの名無しさん
06/02/06 16:16:06
ようするにさらし上げ?

539:デフォルトの名無しさん
06/02/06 17:05:29
>>534
setするほうのプロパティを作ればよいだけではないのか?

540:534
06/02/06 19:13:17
>>539
それだとプロパティへの代入はできるけど、プロパティを介する変更ができないと思う。
Val%をValに変更してsetをつけても、test[100].val=200;だと変更できない
Val tmp;tmp.val=200; test[100]=tmp; なら変更可能だけど...

問題なさそうで問題あるケース
generic <typename T1,typename T2> value struct M
{T2 myt;
property T2% default[T1]{
T2% get(T1 t1) { return myt; }
void set(T1 t1,T2% val){myt = val;}}
};
T2%だと　M<int,M<int,int>> m; int i=100; m[100][100]=i; //と書ける //ただ変数にしないといけない難点が...
T2だと m[100][100]=100;と書けるが変更できない

541:デフォルトの名無しさん
06/02/06 19:53:28
海外の大御所がある雑誌で言った。

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

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

542:デフォルトの名無しさん
06/02/06 20:05:34
>>541
大御所が誰だか教えて

543:デフォルトの名無しさん
06/02/06 20:13:56
プラウガもC++/CLIやってるけどな。
URLﾘﾝｸ(www.dinkumware.com)

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

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

544:デフォルトの名無しさん
06/02/06 20:33:14
将来も何もmanaged　C++はC++/CLIまでの暫定版なんだから、
managed　C++の将来はC++/CLIじゃないか。
managed　C++は　OldSyntaxだべさ。

545:デフォルトの名無しさん
06/02/06 20:39:32
どれかひとつ選ばなければならないとしたら不本意ながらC++/CLIを選ぶしかないわな。

546:デフォルトの名無しさん
06/02/06 20:46:22
レヴューリリースだわな、managed C++は。

547:デフォルトの名無しさん
06/02/06 20:49:30
正直、記憶力がおいつかない。

548:デフォルトの名無しさん
06/02/06 20:55:37
でも、サービスパックも出てない VisualStudioを使うほどバカじゃなし。
MS製以外でコンパイル通るヤツってある?

549:デフォルトの名無しさん
06/02/06 23:39:31
>>548
無いよ。バカ

550:デフォルトの名無しさん
06/02/07 00:04:25
バカじゃん

551:デフォルトの名無しさん
06/02/07 01:01:12
おまえら、VS2005マジで使うの?　バカじゃん。
すでに、MSはSP出荷を確約してるんだぞ。

552:デフォルトの名無しさん
06/02/07 01:44:04
>>551
じーっと枯れるのまってろこのうすらタコ！

553:デフォルトの名無しさん
06/02/07 02:14:49
>>548
VB6でも使っとけよ wwww

554:デフォルトの名無しさん
06/02/07 02:41:12
>>552
N88　BASIC

555:デフォルトの名無しさん
06/02/07 10:21:32
バカが3匹。

556:デフォルトの名無しさん
06/02/07 10:51:33
Win32コンソールアプリケーションの

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

557:デフォルトの名無しさん
06/02/07 11:32:34
漏れは
int main(const int argc, const char* const argv[])

558:デフォルトの名無しさん
06/02/07 13:00:33
>>557
そこまでいくなら戻り値もconstにしてはどうか？

559:デフォルトの名無しさん
06/02/07 13:21:59
>>558 参照返しじゃないから意味なし。

560:558
06/02/07 13:27:44
>>559
ああ、確かに意味は無いなｗ

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

561:デフォルトの名無しさん
06/02/07 14:04:04
argcの場合、意義はともかくプログラム上の意味が変わる。

562:デフォルトの名無しさん
06/02/07 14:21:19
うっかり書き換えるとコンパイラにゴルァされるとか

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

564:デフォルトの名無しさん
06/02/07 15:01:05
>>558 お前素直な奴だな

565:デフォルトの名無しさん
06/02/08 00:54:04
そこでconst_castの登場だな

566:デフォルトの名無しさん
06/02/08 18:26:06
全部ILで書こうぜ

567:デフォルトの名無しさん
06/02/08 19:24:23
遅いからヤダよ。

568:デフォルトの名無しさん
06/02/09 01:52:44
STL/CLIお蔵入り

569:デフォルトの名無しさん
06/02/09 04:28:08
固定長配列はcli::array以外に用意されてない？

570:デフォルトの名無しさん
06/02/09 11:58:31
>568

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

571:デフォルトの名無しさん
06/02/09 12:38:09
BOOST.NETも出たりとか。
正直大混乱。

572:デフォルトの名無しさん
06/02/09 13:44:43
正直いってWinXPのSP2入れたくないからとかいう理由で
SP1を使ってる馬鹿と同レベルの理屈だな

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

573:デフォルトの名無しさん
06/02/09 17:47:52
>>571

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

574:デフォルトの名無しさん
06/02/09 22:47:44
>>572

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

575:デフォルトの名無しさん
06/02/10 21:58:53
値型にデフォルトコンストラクタと代入演算子を定義できる
.NET言語ってあるんかな？

576:デフォルトの名無しさん
06/02/10 22:01:31
フレームワーク内のprivateないくつかの構造体を見ると、
デフォルトコンストラクタ使ってるのがいくつかあるな。

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

577:デフォルトの名無しさん
06/02/10 22:20:02
>>575
つIL (ilasm)
まぁぶっちゃけいらないっていうかあってもまずやっちゃいけないしな

578:575
06/02/10 23:53:50
>>576,577
どうも

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

こんな感じで試してみようかな...
URLﾘﾝｸ(www.gdncom.jp)

579:575
06/02/11 01:08:41
やってみたけどよくわからんかった。でも
templateの部分特殊化でCLI型が使えるみたいだから、それでcreateすればいいか.

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

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

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

581:デフォルトの名無しさん
06/02/11 09:40:08
C++/CLIは便利だと思うが、棲み分けに失敗した感じがするな。
C#で統合するはずが、C++/CLIで統合されるとは…。
本当は.NET対応はC#だけでよかったんだと思う。

582:デフォルトの名無しさん
06/02/11 10:25:45
>>580
managedなobjectをどう扱いたいかによるだろ?

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

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

583:デフォルトの名無しさん
06/02/11 10:29:11
おまえら、どのエディション使ってるの？

584:デフォルトの名無しさん
06/02/11 10:35:44
>>582 うむ、いっていることは分かる。
まさに数値計算して可視化、ってのは仕事で必要。
しかも膨大な数値計算用のライブラリ(自作+他作)がすでにある。

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

585:デフォルトの名無しさん
06/02/11 11:10:32
C++/CLIは、CLIに頼らなければいけない時だけ、
managedなコードを書かなければいけないC++だろ?

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

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

586:デフォルトの名無しさん
06/02/11 11:11:09
>>585
> managedなコードを書かなければいけないC++だろ?

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

587:デフォルトの名無しさん
06/02/11 11:15:34
>>585 ふむ、いわれてみればそうだな。
俺があまりにも boost 依存なコードを書きすぎていただけだと思う。

588:デフォルトの名無しさん
06/02/11 15:56:27
>>581
いろんな言語が使用できるっていうのが.NETのうたい文句のひとつだったから
C#だけって言うのはいただけない

589:デフォルトの名無しさん
06/02/11 16:22:28
馬鹿はスルーしる

590:デフォルトの名無しさん
06/02/11 16:26:50
.NETって実際複数言語で開発してたりすんの？

591:デフォルトの名無しさん
06/02/11 16:48:36
>>590 俺はドトネトは C# しか使ってないけど、
俺が使ってるアセンブリが C++/CLI や VB.NET
で作られているかどうかは知らない。

592:デフォルトの名無しさん
06/02/11 16:53:16
VC++はVC++で作られていますという件はもはや過去のもの？

593:デフォルトの名無しさん
06/02/11 17:26:02
「ドトネト」って言う呼び方はアンチっぽいからやめてくれ

594:デフォルトの名無しさん
06/02/11 17:31:18
エロビデオのネバスペみたいなもんか。

595:デフォルトの名無しさん
06/02/11 17:39:26
Win32APIなどのネイティブ呼び出しをC++/CLIでラップしてあとはC#で開発してる。
windows.h　の関数や定数の定義をそのまま使える上にInteropで呼び出しも高速なので
P/Invokeよりぜんぜんいいよ。

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

596:デフォルトの名無しさん
06/02/11 18:07:08
>>595
狂おしいほどに同意
アセンブリの中にネイティブコードを突っ込めるから
逆コンパイルにも対抗できるし。

597:デフォルトの名無しさん
06/02/11 20:57:49
そんなことしたら64bitでそのまま動かないじゃん

598:デフォルトの名無しさん
06/02/12 03:52:02
>>597
32bitで何か問題でも?

599:デフォルトの名無しさん
06/02/12 16:51:41
C++/CLIがNativeとManagedの混合アプリを作るのに優秀なのは理解できるが、
/clr:safe　なアプリをあえてC++/CLIで作ることに意味があるのだろうか。

600:デフォルトの名無しさん
06/02/12 17:37:42
>>599
特になし。C++/CLIはC++使い慣れてる(C++ライブラリを膨大に抱えてる)人を
.NETに繋ぎとめておくためのもの。

601:デフォルトの名無しさん
06/02/12 21:00:01
2003のWin32APIやMFCを2005ExpressEditionで使おうと
頑張ってみたが無理だった。
Win32APIはコンパイル通るけど警告出るし、
MFCに関しては全くお手上げ。

602:デフォルトの名無しさん
06/02/12 22:31:04
>>601
WinAPIは2003から持ってこなくても最新のPlatform　SDKを入れればいいだろうに。

603:デフォルトの名無しさん
06/02/12 23:14:27
C++/CLIはVB.NETで作ったクラスライブラリを呼び出すことも可能？

604:デフォルトの名無しさん
06/02/12 23:33:15
可

605:デフォルトの名無しさん
06/02/12 23:51:30
>>602
最新のSDK持ってきたら、警告なくなったよ。ありがと。

606:デフォルトの名無しさん
06/02/13 08:02:58
managed C++ みたいに C++/CLI もやっぱやーめたなんてことにはならんだろうな？
前者はなんか標準化団体には出されてたんだっけ？後者はだされてたよな？

607:デフォルトの名無しさん
06/02/13 08:05:18
>>605
感謝は言葉ではなく物で示せ。

608:デフォルトの名無しさん
06/02/13 12:44:28
>606
今、ISO で標準化の審査中

609:デフォルトの名無しさん
06/02/13 13:03:53
>>608 それは C++/CLI だよね？
もう Managed C++ はいらんでそ。

610:デフォルトの名無しさん
06/02/13 14:01:33
(1)for each( int obj in v)
(2)for each( int^ itr in v)
(3)for each( int% r in v)

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

611:デフォルトの名無しさん
06/02/13 15:26:41
>>609
URLﾘﾝｸ(www.ecma-international.org)
これがISOに提出された。まあISOになる可能性はないと思うけれど。

612:デフォルトの名無しさん
06/02/13 16:55:39
>>611 あれ？ないの？

613:デフォルトの名無しさん
06/02/13 17:22:33
CLI 自体はすでに ISO 標準になってるんだよな。
Java VM も ISO 標準にすればいいのに。
Java 言語とは切り離して。

614:デフォルトの名無しさん
06/02/13 18:06:42
で、ISO 標準て何の役に立つの？

615:デフォルトの名無しさん
06/02/13 18:07:31
ネームバリュー

616:デフォルトの名無しさん
06/02/13 18:10:32
実質を無視したネームバリューなら、
Java >>>>>>（壁）>>>>>> Ｃ丼（I$O）
だね。

617:デフォルトの名無しさん
06/02/13 18:13:08
>>616 実質的なネームバリューだと思うけど。

618:デフォルトの名無しさん
06/02/13 21:22:11
>>616
Java のネームバリューってかなり実質的なものだと思うぞ。

619:デフォルトの名無しさん
06/02/13 23:26:25
>>613
EMCAの時に、J2EEも同時に採用されることにこだわった。
当時は、IBMその他ベンダーが独自ビジネス向けフレームワークの覇権を争っていた。

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

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

620:デフォルトの名無しさん
06/02/14 04:09:12
>>618
確かにJavaはネームバリューだけだな

621:デフォルトの名無しさん
06/02/14 09:09:07
ドトネッツは実質ＮＯ．１

（ベーパーウェア部門）

622:デフォルトの名無しさん
06/02/14 13:57:47
>610
vの中身を書き換えたいときは、必然的に(3)
(1)と(2)でコンパイル結果に差が出るかは知らんが、同じなら(2)の方が他の参照型などと統一性が採れると思う

623:デフォルトの名無しさん
06/02/14 22:40:58
int^ だとボックス化のコストが高くない？

624:610
06/02/15 09:08:44
>>622,623
値型の場合、(1)が無難な気がしてきた。(2)はテンポラリGCポインタなのか...(3)はなんか怪しい...
参照型の場合、(2)しか選択もうない気が、第４の選択肢は危険ぽいし...

ref struct Test{
Test(){}int x;Test(int in_x) :x(in_x){}
static void test(){
System::Collections::Generic::List<int> v;v.Add(1);v.Add(2);v.Add(3); //case1
//cli::array<int>^ v = {1,2,3}; //case2
#define SHOW for each(int i in v){Console::WriteLine(i);}
for each(int i in v){i *= 2;}SHOW;//result->{1,2,3}
for each(int^ p in v){(*p) *= 2;}SHOW;//result->{1,2,3}
//for each(int^% p in v){(*p) *= 2;}SHOW;//danger
for each(int% r in v){r *= 2;}SHOW; //case1->{1,2,3},case2->{2,4,6} -> unsafe code
}
static void test2(){
System::Collections::Generic::List<Test^> v;v.Add(%Test(1));v.Add(%Test(2));v.Add(%Test(3));
//cli::array<Test^>^ v ={ %Test(1),%Test(2),%Test(3) };
#define SHOW2 for each(Test^ t in v){Console::WriteLine(t->x);}
for each(Test^ p in v){(*p).x *= 2;}SHOW2;//result->{2,4,6}
for each(Test^% r in v){(*r).x *= 2;}SHOW2;//result->{4,8,12},case2->{2,4,6} -> unsafe code
}
};

625:デフォルトの名無しさん
06/02/15 12:54:23
>624
何を悩んでいるのかよくわからん
列挙する型に合わせれば良いんじゃないか？
適材適所だろ

626:デフォルトの名無しさん
06/02/15 16:25:30
^うざ

627:デフォルトの名無しさん
06/02/15 19:45:53
よーく見ると、顔に見えてくる。

628:デフォルトの名無しさん
06/02/18 14:49:04
VS 2005 C++だす
×　String str = "Hello";
○　String ^str = "Hello";
いちち^付けないといけないみたいですね、
^ってどういう意味ﾃﾞﾂｶ

629:デフォルトの名無しさん
06/02/18 15:09:39
>>628
C++/CLIに於けるポインタ

630:デフォルトの名無しさん
06/02/18 15:17:47
そっか、それで
*を^に変えろって困憊羅が言ってるの、見たような希ガスル
しかしなぁー、なぜ換える必要があるのかと、悩む事小10分
*アスタリスクはなんか他の用途でつかってるのかなぁ？？

631:デフォルトの名無しさん
06/02/18 15:30:01
こう覚えた方が早い
* を使っているのは C++
^ を使っているのは CLI 拡張

632:デフォルトの名無しさん
06/02/18 15:44:42
>>630
*のポインタ型同士はポインタ演算があるから演算子多重定義ができない。
^の追跡ハンドルならそのようなことがないから演算子多重定義ができる。

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

634:628
06/02/18 16:32:13
ｽﾏｿ
×　GUIが使えるWin32でアプリケーションを作りたくて
○　GUIで動作するWindowsアプリケーションを作りたくて

635:デフォルトの名無しさん
06/02/18 16:45:58
初心者ならC#へ行ってみてはどうかと惑わしてみる。
VS2005C++使った事無いけど、アンマネージド(ネイティブ)は作れるはずだ。

636:デフォルトの名無しさん
06/02/18 16:55:38
2005は普通に「Win32コンソールアプリケーション」でネイティブを作れるはずだが…
Expressだと違うのか？

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

638:デフォルトの名無しさん
06/02/18 17:15:12
>>633
コンソールアプリケーションとテキストボックスのつながりがわからん

639:デフォルトの名無しさん
06/02/18 17:36:48
すんません、又間違えていました
CLRからWindowsフォームアプリケーション作成でした

640:デフォルトの名無しさん
06/02/18 21:12:37
他スレから誘導されてきました。

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

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

641:640
06/02/18 21:26:55
投稿して気付いたのですが、Sizeの部分をハンドルにしたら設定出来るようになりました。
何故かがわからないですが・・・。

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

642:デフォルトの名無しさん
06/02/18 21:48:34
>>641
System.Drawing.Sizeは型値だから扱いが面倒だのう。

643:デフォルトの名無しさん
06/02/19 06:34:22
>>633
スレ違い
ｽﾚﾘﾝｸ(tech板)

644:デフォルトの名無しさん
06/02/19 14:36:44
>>641
というかそれはあまりよろしくない。たぶん。

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

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

645:644
06/02/19 14:43:34
にゃー、コード間違いすぎ

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

こう。

646:デフォルトの名無しさん
06/02/19 15:20:04
そんなんわからん奴はC#やJavaも微妙だろ。

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

648:デフォルトの名無しさん
06/02/19 20:48:42
Visual C++ 2005 Express Edition の環境で、はまってしまい、皆さんのお知恵を拝借したいです。

Webのダウンロードなのですが、
方法1
　　WebClient^ wc = gcnew WebClient();
　　Stream^ st = wc->OpenRead("URLﾘﾝｸ(www.yahoo.co.jp)");
　　Encoding^ enc = Encoding::GetEncoding("euc-jp");
　　StreamReader^ sr = gcnew StreamReader(st, enc);
　　String^ out = sr->ReadToEnd();
　　Debug::WriteLine(out);
これはうまくいきWebデータの取得ができます。

方法2
WebClient^ wc = gcnew WebClient();
Byte ^ myDataBuffer = wc->DownloadData("URLﾘﾝｸ(www.google.co.jp)");
Encoding^ enc = Encoding::GetEncoding("euc-jp");
String^ out = enc->GetString(data);
このコードだとコンパイルエラーです。
エラーメッセージは、
.\MainForm.cpp(50) : error C2440: '初期化中' : 'cli::array<Type,dimension> ^' から 'System::Byte ^' に変換できません。
　　　　with
　　　　[
　　　　　　Type=unsigned char,
　　　　　　dimension=1
　　　　]
　　　　この変換を実行可能なユーザー定義変換演算子がないか、または演算子を呼び出せません。

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

649:デフォルトの名無しさん
06/02/19 21:05:11
>>648
WebClient::DownloadData()の戻り値の型はcli::array<unsigned　char>^。
Encoding::GetString()の引数もcli::array<unsigned　char>^。

650:デフォルトの名無しさん
06/02/19 21:12:35
^　←なんかコレうざい。よくわからないけど腹立たしい。

651:デフォルトの名無しさん
06/02/19 21:18:36
(^^:

652:デフォルトの名無しさん
06/02/19 21:20:18
^<T>^

653:648
06/02/19 21:44:16
>>649
Byte を cli::array<Byte> にしたところ、できました。

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

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

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

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

654:Pascal
06/02/19 23:09:23
>>650
呼んだ?

655:デフォルトの名無しさん
06/02/20 00:22:49
>>650
あなたの心が汚れてるからですよ(^^;;;

656:デフォルトの名無しさん
06/02/20 00:30:26
そんなばかな^^;

657:デフォルトの名無しさん
06/02/20 01:26:15
>>650-652
ヤベ、ツボにはまったｗ

658:デフォルトの名無しさん
06/02/21 10:07:18
>>422-423
＞ダイレクトに C++ を知らずに、C++/CLI に手を出すのは、止めた方がいいだろ
＞さっさとC#かVBで始めたほうがいいと思う。

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

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

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

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

次ページ