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

---

[2ch|▼Menu]

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がスタックオブジェクトのように書けることをいいたかったんだろうけど。
川俣とかが取り上げているほど、たいしたものじゃない。あの人は大げさに書く文体
が売りだからな。いい悪いは別にして。

660:デフォルトの名無しさん
06/02/21 21:17:52
通のお勧めは関数のオーバーライド
ディスポーズ・パターンの変形に目が眩んでちゃ、まだまだ

661:デフォルトの名無しさん
06/02/21 21:25:46
>>660 ポリモにならんじゃん

662:デフォルトの名無しさん
06/02/21 21:32:20
>>658
~hogeか!hogeが使われている場合に下のようなコードを自動生成してくれる。
GC.SuppressFinalize(this)がむき出しにならないだけスマートだね。VB.NETにもほしい機能だと思う。
void　Dispose(bool　disposing)　{　if　(disposing)　~hoge();　else　!hoge()　}
void　Dispose()　{　Dispose(true);　GC::SuppressFinalize(this);　};
void　Finalize()　{　Dispose(false);　}
deleteしたり　{　ClassA　a();　...;　}　でスコープから離れた場合は
Dispose()が呼び出されるだけでその場でGCされるわけではない。

663:デフォルトの名無しさん
06/02/22 00:50:01
!hogeなんてあったんだ

664:デフォルトの名無しさん
06/02/22 07:21:27
>>662
いや、えーと、このスレにいる以上知っている。
ildasmでも確認したしな。ああ、そうか、それをC++/CLI用語でFinalizerというのか。


665:デフォルトの名無しさん
06/02/22 12:42:51
>661
おまいはC++/CLIにおける関数上書きの奥の深さに気付いていない

ここに IEnumerable を継承したインターフェイス IEA と IEB がある
その双方を実装した ref クラス RAB は明示的オーバーライドによって列挙の方式を
IEA と IEB によって変更できる
つまり、RAB から取得したインターフェイスによって、for each のオーダーを自由に
選択できるわけだ

666:デフォルトの名無しさん
06/02/22 16:05:53
MSがC++/CLIを捨てるのは何年後くらいですか？

667:デフォルトの名無しさん
06/02/22 16:13:12
MFCの如くこの劣悪貧を１０年使うかも。
C++ってだけでもSTLやBoostが混ざってくると複雑なのに、正直CLIはカンベンて感じだおね。

668:デフォルトの名無しさん
06/02/22 17:22:04
>>667
駄菓子菓子、これがないとネイティブとかからCLRが非常に使いにくい。
ほら、次でWPFとかなんかたくさんあるし。

669:デフォルトの名無しさん
06/02/22 23:36:01
マイクロソフトがもうｲﾗﾈと思ったら容赦なく捨てにくるさ。


670:デフォルトの名無しさん
06/02/23 02:00:23
>>669

そりゃ日本だけ。海外ではVBerが反乱おこして、msも今では Love VB, Love C#だとよ。

671:デフォルトの名無しさん
06/02/23 02:53:32
C#は、VC++とVBの中間を行くような言語だから、
どっちからも反発が強いだろうね。


672:デフォルトの名無しさん
06/02/23 03:03:54
反発はしないけど、C++で出来るなら C++ Nativeでやっちゃうよ。
必要なとこだけ CLIで .Netなんてライブラリ感覚で使えばいい。

673:デフォルトの名無しさん
06/02/23 03:20:44
/clrでNativeコンパイルすると遅くなる？



674:デフォルトの名無しさん
06/02/23 08:50:40
>673
>348

675:デフォルトの名無しさん
06/02/23 09:37:51
>>669
要るだろ。

だって、C++市場をCLIで混乱させることにより、
開発者をWin＠ﾌﾞﾋﾞ or Win＠Ｃ丼で留めておける。

676:デフォルトの名無しさん
06/02/23 10:00:24
>>674

遅くなるのは事実としても、何で遅くなるんだろ?
異なるライブラリがリンクされるからか?　lstrcmp自体の実装が異なるのか?

それとも呼び出し時にスタックチェックでも入ってるのかね…。


677:デフォルトの名無しさん
06/02/23 14:21:46
>676
単純なループでは簡単に結論が出ない問題かもしれない
ちなみに漏れの環境では
CLR 6 - 7 sec.
Native 8 sec.
となった。意外だがCLRの方が早い
Win のほうは -02 -0t を付けた状態で、CLRの方はデフォルトのリリースモジュールだ

678:
06/02/23 22:30:11
>>670
そんな話しきいたことネ

679:デフォルトの名無しさん
06/02/23 22:47:11
誰か、C++/CLI で吐いた実行ファイル、
mono で動かした奴いる？？

以前 VS.NET 2003 の C# で書いたコンソールアプリなら
mono で動かしたことあるんだけど。

680:デフォルトの名無しさん
06/02/23 23:22:55
mono がそもそも .net framework 2.0 に対応してたか？
してるなら、/clr:pure で動くだろう

681:デフォルトの名無しさん
06/02/24 08:17:28
nullptr

682:デフォルトの名無しさん
06/02/24 11:48:08
ｶﾞｯ^

683:デフォルトの名無しさん
06/02/24 17:24:15
>>678

URLﾘﾝｸ(blogs.msdn.com)

ケツの穴が広がるぐらい、ハードに読めや。


684:デフォルトの名無しさん
06/02/24 21:07:35
>>683
良く読んだよ

>表の顔の日記　

> 裏の顔の日記
> さっさと消えてくんないかな。 うざいんだけど、 まじで。


685:デフォルトの名無しさん
06/02/25 04:29:20
という電波でも飛んでるのか?


686:648
06/02/25 11:39:03
また教えてください。

C++での構造体の以下の宣言
typedef struct tagHOGE{
　　int x;
　　long y[4];
}HOGE;

これをマネージ環境にしようとした場合
typedef struct tagHOGE{
　　int x;
　　long y[4];　← ここが混合型らしい
}HOGE;

.\MainForm.cpp(26) : error C4368: 'y' をマネージ 'HOGE' のメンバとして定義できません。混合型はサポートされていません

というエラーが出ます。
単に4つのlong型の配列の定義がしたいのですが、マネージ環境では、どのようなやり方があるでしょうか?


687:デフォルトの名無しさん
06/02/25 11:43:26
typedef struct → typedef value struct
では？

688:648
06/02/25 12:05:23
>>687
そうです。コピペ間違いました。

value struct HOGE{
　　int x;
　　int y[4];
};

と記述してます。

689:デフォルトの名無しさん
06/02/25 12:17:18
・・・value型使わず、ネイティブ型で定義すれば？

690:デフォルトの名無しさん
06/02/25 12:20:37
あとは ref にして array<long>^ y で宣言して、コンストラクタで初期化するか

691:デフォルトの名無しさん
06/02/25 12:23:04
value struct HOGE
{
　　int x;
　　array<long>^ y;
};
はコンパイルが通るが、仕様上これでいいのか？

692:デフォルトの名無しさん
06/02/25 12:38:17
ok
ハンドルは nullptr で初期化される

693:648
06/02/25 12:58:50
皆さん、早速のレス、ありがとうございます。

>>689

ネイティブで定義すればできることは確認してます。
ただそうすると少し複雑なソフトを組んだ場合、きちんとメモリの後処理をしないと
メモリリークが発生するので、マネージにすればメモリガベージの効用であまり複雑に
考えなくともよいかな、と思っているのです。

>>691

そのやり方もわかります。

各関数で、
void func1(void)
{
　　HOGE wk1;
　　wk2.y[2] = 123;
}

void func2(void)
{
　　HOGE wk2;
　　wk2.y[2] = 456;
}

というようなことをしたいのです。

2〜3日あがいてみて自分ではできなそうだったら、ネイティブで定義してやっていきます。
マネージ環境に慣れていけば、そのうち、何か気づきがあると信じて進むしかありません。


694:デフォルトの名無しさん
06/02/25 13:05:44
2〜3日あがくなら2〜3日かけてマニュアル読んだほうがいいような気がする

695:デフォルトの名無しさん
06/02/25 13:45:46
>>693
値型にGCを求める必要がある？

696:デフォルトの名無しさん
06/02/25 14:23:50
C++/CLIのスレ見てると無意味にvalueを使いたがる人が多い気がするな。
valueは動作に癖があるから基本refで作ったほうがいいと思う。

697:デフォルトの名無しさん
06/02/25 16:22:08
value使ったほうが処理速度が速いとでも思い込んでいるんじゃ？
クセがあるには同意。


698:648
06/02/25 17:38:04
いろいろとサイトをまわりまして、以下のようにしたところ動いているように見えます。
public ref struct HOGE {
　　int x;
　　array<long>^ y;
　　HOGE() {
　　　　y = gcnew array<long>(4);
　　}
};

void func(void)
{
　　HOGE^ abc = gcnew HOGE;
　　abc->x = 10;
　　abc->y[2] = 20;
　　for(int i=0; i<4; i++){
　　　　Debug::WriteLine(abc->y[i]);
　　}
}

検討違いのコードでなければよいですが。

みなさん、いろいろとレスありがとう。


699:デフォルトの名無しさん
06/02/25 20:55:45
>>698
これでも平気。
void　func()
{
　　　　HOGE　abc;
　　　　abc.x　=　10;
　　　　abc.y[2]　=　20;
　　　　for　(int　i　=　0;　i　<　4;　i++)　{
　　　　　　　　Debug::WriteLine(abc->y[i]);
　　　　}
}

700:デフォルトの名無しさん
06/02/25 22:33:45
C++は真のローカル変数を使える言語なんだから、（ユーザー定義オブジェクト
がスタック上に配置できる）GCが必要な場合ってのはそんなに多くはならない
ってビョーン先生が言ってた。

701:デフォルトの名無しさん
06/02/25 23:11:17
>>700
それはわかるけれど、C++/CLIはCLIの世界にあわせないといけないからさ。

702:デフォルトの名無しさん
06/02/25 23:42:48
C++/CLIは二つの言語が同居しているようなものだからな。
C++の拡張というより建て増し。

703:デフォルトの名無しさん
06/02/25 23:49:05
>699
それだと、配列のサイズが3で固定されちゃわない？

704:デフォルトの名無しさん
06/02/26 00:22:20
>>702
二世帯住宅

705:デフォルトの名無しさん
06/02/26 00:49:18
ビョーン先生が取り扱っている案件はそうかもしれんけどな。
動的にオブジェクトが増えたり減ったりする案件のほうが多い。

706:デフォルトの名無しさん
06/02/26 00:56:47
>>700
しかしビョーン先生はGCをそんなに否定していない。
既存のC/C++のコードと互換性を保ったまま導入できるのなら、
C++に入れてもいいというようなことをD&Eで書いている。

707:デフォルトの名無しさん
06/02/26 20:57:17
>>705
vector使えばええやん。メンバかローカルにしておけばdeleteいらん。

708:デフォルトの名無しさん
06/02/26 21:08:56
>>707
グローバルでもdeleteいらんぞ

709:デフォルトの名無しさん
06/02/26 21:14:38
別に GC なんて C++/CLI の利点じゃないだろ
単に .net framework を既存の C++ と混同することなく使えるってとこが一番重要さ

C++/Smalltalk とか C++/Squeak とか出てこないかな

710:デフォルトの名無しさん
06/02/27 01:56:21
【初心者歓迎】C/C++室 Ver.25【環境依存OK】から誘導されてきました( ｀・ω・´)ﾉﾖﾛｼｸｰ
VC8でopenFileDialogを使いたくて
MSDNのソースを試してみようと
URLﾘﾝｸ(msdn2.microsoft.com)
説明を読み
フォームに Button を配置して
using namespace System;を宣言して、
下記のコードを試したのですがエラーが出ます、何か読み込んでいないファイルがあるか設定のミスだと思うのですが、原因が分かりませんよろしくお願いします。
private:
　　voidbutton1_Click(Object^/*sender*/,System::EventArgs^/*e*/)
　　{
　　　　Stream^myStream;
　　　　OpenFileDialog^openFileDialog1=gcnewOpenFileDialog;

　　　　openFileDialog1->InitialDirectory="c:\\";
　　　　openFileDialog1->Filter="txtfiles(*.txt)|*.txt|Allfiles(*.*)|*.*";
　　　　openFileDialog1->FilterIndex=2;
　　　　openFileDialog1->RestoreDirectory=true;

　　　　if(openFileDialog1->ShowDialog()==::DialogResult::OK)
　　　　{
　　　　　　if((myStream=openFileDialog1->OpenFile())!=nullptr)
　　　　　　{
　　　　　　　　//Insertcodetoreadthestreamhere.
　　　　　　　　myStream->Close();
　　　　　　}
　　　　}
　　}
error C3083: 'DialogResult': '::' の左側のシンボルには、型を指定しなければなりません
error C2039: 'OK' : '`global namespace'' のメンバではありません。
error C2065: 'OK' : 定義されていない識別子です。


711:デフォルトの名無しさん
06/02/27 07:06:19
>>710
System::Windows::Forms::DialogResult::OK　とフルで書く。

712:デフォルトの名無しさん
06/02/27 07:26:28
>>711
最後まで仕様が揺れた所かも知れないね。

713:デフォルトの名無しさん
06/02/27 10:47:00
この状況って System::Windows::Forms まで using で指定しているから、単純にグローバル
スコープ指定していることが問題なんじゃね？
12行目の ::DialogResult を意味なく、:: で始めるな、と

714:デフォルトの名無しさん
06/02/27 11:06:47
>>713
ところがどっこい
DialogResult::OK　と書くと今度は
System::Windows::Forms::Form::DialogResultが無いというエラーになる。
using　namespace　は探しに行ってくれないらしい。

715:デフォルトの名無しさん
06/02/27 11:38:26
ん、サンプルだと :: で始めてるな
っていうか、>710 って名前空間 System しか宣言してないって言ってるが
using namespace System::Windows::Forms が宣言されている環境では
::DialogResult::OK でエラーなくコンパイルできるな

先頭 :: の名前検索ルールって、グローバル指定じゃないんだ・・・

716:デフォルトの名無しさん
06/02/27 13:38:23
>>714
using namespace System::Windows::Forms;
してあるということ? その"Form"は何よ?

>>715
namespace N { int x; };
using namespace N;
int x;
int f(void) { return x; } ←このxはambiguousになる。それで正しい。

---

次ページ

最新レス表示

スレッドの検索

類似スレ一覧

話題のニュース

おまかせリスト

▼オプションを表示

レスジャンプ

mixiチェック！

Twitterに投稿

オプション

しおりを挟む

スレッドに書込

スレッドの一覧

暇つぶし2ch

---

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