C++/CLI part3 - 暇つぶし2ch

C++/CLI part3 ..

271:268
08/11/15 21:10:32
>>268
やってみてます。
Form1クラスの
System::ComponentModel::Container ^components;
メンバって使われてます？

272:268
08/11/15 21:11:51
>>269
だった。。　自分に返信　ＯＲＺ

273:デフォルトの名無しさん
08/11/15 23:03:06
>>270
それでいいと思う。

どうしても気になるなら、リンカ→詳細のエントリポイントを書き換えろ。
サブシステムが/SUBSYSTEM:WINDOWSにさえなっていれば大丈夫。
例えば、mainCRTStartupにすればint　main(int　argc,　char　**argv)で始められる。
?mainCRTStartupStrArray@@$$FYMHP$01AP$AAVString@System@@@Zだと
int　main(array<System::String^>^　args)になる。
CRTの初期化が要らなければ、自分の関数を直接指定する。

274:268
08/11/16 10:17:18
>>273
ありがとうございます。

教えて頂いたところを試してみて、以下がわかりました。
・int __stdcall WinMain(HINSTANCE hInst ... )
　を使った場合には、サブシステム：設定なし　で動くようです。
・int main(array<System::String ^> ^args)
　を使いたい場合には、サブシステム：/SUBSYSTEM:WINDOWS
　エントリポイントmainで動くようです。

アップウィザードはの設定は後者ですが、
メイン関数からの引数が不要なら前者の方が楽ですね。

275:268
08/11/16 10:58:51
自分で作成したフォームクラス（MyForm.h, MyForm.cpp）
に対して，デザイナを使えるようにしようとしています．

とりあえず新しい項目の追加でWindowsフォームを選び，
作成されたFoo.hとFoo.cppの内容をMyForm.hとMyForm.cpp
に全て変更したら動きました．

デザイナで編集して，MyFormのコンストラクタから
InitializeComponent();を呼んでいます．

でもこれもやり方が違う気が．．

276:デフォルトの名無しさん
08/11/16 15:36:02
何がいいたいの？

277:268
08/11/16 18:57:42
MyForm.resx というXMLファイルを追加し，
ProjectName.vcproj というXMLファイルに変更を加えたら
MyForm.hがデザイナから認識され，編集できました．

既存のMyFormクラスに対して上記のXMLファイルの
設定を自動で行ってくれる方法は無いみたいです．

278:デフォルトの名無しさん
08/11/16 19:51:31
日記は自分の blog にでも書いたらいいんじゃないか

279:デフォルトの名無しさん
08/11/16 19:58:39
何の情報も提供せずに教えてくれってのよりは良いんじゃない？

280:デフォルトの名無しさん
08/11/16 20:31:19
この人、自分がやってることをぼそぼそ呟いて、自己満足してるだけだろ
ウィザードがやってることを見もせずに、ウィザードと同じことやってりゃ世話無い罠

281:デフォルトの名無しさん
08/11/18 23:52:34
自動的に作成されるメソッドに日本語が入らないようにするにはどうすればおｋ

282:デフォルトの名無しさん
08/11/20 20:59:21
過去の資源を再利用できること以外にC++/CLIがC#より優れてる点はどこですか？

283:デフォルトの名無しさん
08/11/20 21:09:52
Disposeパターンが言語に組み込まれてる
テンプレートが使える
マクロが使える

一番目は相互運用絡みだから除外するべきかも

284:デフォルトの名無しさん
08/11/20 22:09:49
__fastcallが使えないのが痛い

285:デフォルトの名無しさん
08/11/20 22:55:26
#pragma　unmanaged

286:デフォルトの名無しさん
08/11/21 09:27:31
C#（検証可能アセンブリ？）はリバースエンジニアリングが簡単という話を聞いたんですが
C++/CLIの混在アセンブリ、純粋アセンブリや検証可能アセンブリも同じなんですか？

287:デフォルトの名無しさん
08/11/21 09:46:21
マネージコードで書かれた部分は読み放題
Reflectorでほぼ完璧に逆コンパイル可能
C#ほどILが綺麗じゃないから若干読みづらいかも

288:デフォルトの名無しさん
08/11/22 17:46:58
>>285
#pragma unmanaged
int __fastcall func( int a, int b)
{
return a + b;
}
#pragma managed

これじゃ駄目なようですが

289:デフォルトの名無しさん
08/11/28 02:10:49
MSの常
・勝手に仕様拡張する
・なかなか、正規仕様に準拠しない

どやしつけられたのがJ++
総スカン食らったC++/CLI

J#でどやしつけられ、性根入れ替えてC#はよかったのに
またC++/CLIで汚点。
J#はみあたらんぞ

290:デフォルトの名無しさん
08/11/28 02:13:24
忘れてた
・勝手にサポートを打ち切る

291:デフォルトの名無しさん
08/11/28 10:56:03
今どうしても必要なときに必要なところだけ使う言語だもん
中途半端なフォームデザイナなんか付けたりするから勘違いする奴がいる

292:デフォルトの名無しさん
08/11/30 11:55:31
property TKey First;
のような省略記法って、何の意味がありますか？
アクセサを使わない場合と比べて、何か利点はあります？

293:デフォルトの名無しさん
08/11/30 12:07:44
記述を省略できる

294:デフォルトの名無しさん
08/11/30 12:15:20
generic< typename TKey, typename TValue >
public ref class Pair
{
public:
property TKey First;
property TValue Second;
//TKey First;
//TValue Second;

Pair(){}
};

stl::pairのようなクラスを作ったのですが、propertyを使うと、
テンプレートの型によって、代入出来たり出来なかったりするようです。
propertyを削除すると、代入出来るようになります。
何か理由わかりますか？
（続く)

295:デフォルトの名無しさん
08/11/30 12:19:11
(続き)
public value struct ValueTypeStruct
{
unsigned int A;
unsigned int B;
};

array< Pair< unsigned int, ValueTypeStruct >^ >^ arry;
arry = gcnew array< Pair< unsigned int, ValueTypeStruct >^ >(10);

for each( Pair< unsigned int, ValueTypeStruct >^% inv in arry)
{
inv = gcnew Pair< unsigned int, ValueTypeStruct >();
inv->First = ...; // <- OK
inv->Second.A = ...; // <- NG
inv->Second.B = ...; // <- NG
}

>>293
記述を省略して、デフォルトのアクセサを作ったとして
それのメリットは何ですか？
別にget、setに別にアクセサビリティを設定出来る訳ではないし、、
メンバ変数のアドレスを取れなくさせるとかですか？

296:デフォルトの名無しさん
08/11/30 13:06:46
>>290
いやいや、RedHatにはかなわんよ。
新版のLinuxパッケージをリリースしたら、旧版は即日サポート終了だからな。
あれには驚いた。

297:デフォルトの名無しさん
08/11/30 13:08:30
> inv->Second.A = ...; // <- NG
> inv->Second.B = ...; // <- NG
プロパティは実質的にメソッドなので値型だとコピーが作られる

> 記述を省略して、デフォルトのアクセサを作ったとして
> それのメリットは何ですか？
ILレベルじゃまったく別物
途中で検証が必要だからフィールドからプロパティに変えるか、ってほど気楽な変更ではない
そもそもインスタンスフィールドを公開するのはガイドラインに逆らってるしな

> 別にget、setに別にアクセサビリティを設定出来る訳ではないし、、
これは単にコンパイラの実装の手抜きだろ
C#じゃ設定できるし

298:294
08/11/30 13:08:31
自己解決しました。
inv->Second.Aとした場合、Secondはメンバではなく
get()の戻り値である一時変数であった為でした。

299:デフォルトの名無しさん
08/11/30 13:19:08
>>297
理解しました、ありがとうございました。

300:デフォルトの名無しさん
08/11/30 13:20:21
valuetypeは変更不可で設計したほうがこの手の間違いが少なくてすむよね。

301:デフォルトの名無しさん
08/11/30 13:33:23
>>300
値型と参照型の違いもそうなのですが、
プロパティの

inv->First = ...; // <- OK
と
inv->Second.A = ...; // <- NG
が、表面上は同じ代入なのに

内部的には、
inv->set_First( ...);
と
inv->get_Second().A = ...;
と、正反対の関数に分かれるってのは
デンジャラスだなーと思いました。
propertyのgetには、何か足りてないものがあるような感じです。

302:デフォルトの名無しさん
08/11/30 13:51:03
値型とプロパティは相性が悪いのよ。参照型のクラスだと問題ないでしょう。
だからP/Invokeのような特殊な用途を除いてイミュータブルにするルールになってる。
・・・のだけど、WindowsFormのPointやSizeはしっかり変更可能になってる（笑
ヘジたんの目が届かなかったのだろう。

303:デフォルトの名無しさん
08/11/30 13:52:10
>>302
ここで言う値型はプリミティブ型を除いたユーザー定義型の構造体のことです。念のために。

304:デフォルトの名無しさん
08/11/30 13:55:09
WinFormじゃなくてGDI+だな
その辺はむしろラップしてるアンマネージドとの兼ね合いじゃないか

305:デフォルトの名無しさん
08/11/30 14:03:29
WPFの構造体だってたいがい変更可能だよ
そのへんは割り切り設計
ちゃんとわかってたら問題ない

306:デフォルトの名無しさん
08/11/30 23:05:30
C++/CLIっていうか、.NETって
typedefのようなエイリアスって無いんですかね？
これじゃ何も作れないような、、皆さんはどうしてるんですか？

307:デフォルトの名無しさん
08/11/30 23:12:46
何を作りたいんだ？

308:デフォルトの名無しさん
08/11/30 23:20:20
マクロでも書けば委員者ね？

309:デフォルトの名無しさん
08/11/30 23:21:35
トリビアル・プロパティとトリビアル・イベントの存在意義はロック処理を自動でしてくれること
だった気がする

310:デフォルトの名無しさん
08/11/30 23:25:52
>>307
何か特定のソフトウェアに依存する話ではなく
一般的なものだと思います。

typedef classA< classB< classC > > > arg_type;
void func( arg_type a );

C++ではこう出来ていたものが、

void func( classA< classB< classC > > > a );

.NETではこれしか出来ないというのは
利用者側は、いちいちclassA< classB< classC > > >型のオブジェクトを宣言しろってことですか？

311:デフォルトの名無しさん
08/11/30 23:30:57
で、それだけで何も作れなくなるの？

312:デフォルトの名無しさん
08/11/30 23:33:12
>>310
アセンブリ横断ではその機能はないが、C++/CLIつまり同じソースか
includeするHeaderファイルの範囲なら使えると思うけど。
C#の場合は　using　xxx　=　System.YYY.ZZZ;　同じソースないなら出来る。

313:デフォルトの名無しさん
08/11/30 23:34:09
今のC#とVB.NETにはローカル変数の型推論もあるし、
常にclassA<classB<classC>>>と書かねばならないわけでもなかろう。
（もちろんクラスメンバや戻り値など、その必要性がある場面も依然として存在するが）

314:デフォルトの名無しさん
08/11/30 23:34:48
C++/CLIはtypedef使えるぞ。

315:デフォルトの名無しさん
08/11/30 23:39:54
>>310
むしろ出来ないってデマをどこで教わったんだ？
2,3行書けば検証できる話だぞ？
その例から「でもBoostのようなメタプログラミングが～」とか飛躍しないでくれよ。

316:デフォルトの名無しさん
08/11/30 23:45:16
>>311
激しく意欲を削がれます。
他にも、const参照が出来ないとか、
ちょこちょこ退化してる？みたいな部分が見え隠れするんで。
いろんなサイトの紹介文ではマンセー意見しか書いてなかったんで
余計にです。

>>312
CLRで使えないと、C++/CLI使う意味ないです。

>>314, >>315
>>312のいうアセンブリ横断のことです。
もちろん書いて試したし、検索もしました。

317:デフォルトの名無しさん
08/11/30 23:48:47
>>313
型推論について調べてみます。
アドバイスありがとうございます。

318:デフォルトの名無しさん
08/12/01 00:04:36
C++のconst参照みたいなコンパイラを騙くらかすだけのまがい物ではなく
実際に参照されているオブジェクトを変更不可として扱うconst参照を導入しようとすると
オブジェクトの検証にパフォーマンス上の問題が発生するのであえて採用してないそうだ。

319:デフォルトの名無しさん
08/12/01 00:28:26
オブジェクト指向では、内部の実装を隠蔽するわけだが、
それによって、一見読み取りだけのメソッドでも内部では何か状態を
更新してるかもわからないし。
const参照は、なんちゃってオブジェクト指向のC++と違って現代的な
オブジェクト指向とは相性悪いってことだな。

320:デフォルトの名無しさん
08/12/01 00:54:17
基のC++でもmutableとかあるしね。

逆に、.NETで表現するとしたら、IReadOnlyHogeとIHogeって2本立てにするのが落としどころだと思う。

321:デフォルトの名無しさん
08/12/01 20:19:45
複雑なジェネリック型を晒すなと.NETのガイドラインに書いてあるんだよね

322:デフォルトの名無しさん
08/12/01 20:31:51
Native C++の2次元配列から、C++/CLIの2次元配列に値をコピーしたいのですが、1つ1つの要素を代入する以外の、
一発でコピーできる方法が分からなくて困っています。
1次元配列の場合は、
double nativeVec[3] = {1, 2, 3};
array<double> ^cliVec = gcnew array<double>(3);
System::Runtime::InteropServices::Marshal::Copy(IntPtr(nativeVec), cliVec, 0, cliVec->Length);
でコピーできますが、
2次元配列の場合はどうすればいいのでしょうか？
以下のコードでは動きませんでした。
double native2DVec[3][3] = {{1, 2, 3}, {4, 5, 6}, {7, 8, 9}};
array<double> ^cli2DVec = gcnew array<double, 2>(3, 3);
System::Runtime::InteropServices::Marshal::Copy(IntPtr(native2DVec), cli2DVec, 0, cli2DVec->Length); // ここでエラー
エラーは、
error C2665: 'System::Runtime::InteropServices::Marshal::Copy' : 16 オーバーロードのどれも、すべての引数の型を変換できませんでした
です。

323:デフォルトの名無しさん
08/12/01 21:08:52
ピンしてmemcpyでどうだ。
#include　<cstring>

double　native2DVec[3][3]　=　{{1,　2,　3},　{4,　5,　6},　{7,　8,　9}};
array<double,　2>　^cli2DVec　=　gcnew　array<double,　2>(3,　3);
pin_ptr<double>　p　=　&cli2DVec[0,　0];
std::memcpy(p,　native2DVec,　sizeof　native2DVec);

std::copyでもできたけど、書くのが面倒だった。

ところで多次元配列の要素の連続性の保証ってあるよね？

324:デフォルトの名無しさん
08/12/01 21:52:35
>>323
できました！
連続性の保障は怪しい気もしますが、とりあえずは手元で動くのでokということにしておきたいと思います…

325:デフォルトの名無しさん
08/12/02 00:28:22
マネージ多次元配列はメモリレイアウトに関してなんら保障してなかったような・・・
ジャグ配列にして一行ずつコピーした方がいいんでね？
マーシャリングはともかくアクセスはジャグの方が速いし。

326:デフォルトの名無しさん
08/12/02 03:54:37
>>325
3x3行列なので、ジャグ配列にするのもなんかなあ、という気分なのです。
最悪2重forでコピーかなあ。

327:デフォルトの名無しさん
08/12/02 20:04:50
小さい行列を大量に扱うんだったら>>322-323みたいなのはかなり非効率だと思うよ
3×3と決まってるなら手打ちでいいじゃん

328:デフォルトの名無しさん
08/12/12 00:25:00
MFCのダイアログアプリで質問です。
画面上のボタンを押すとWindowsForm画面を開いています。
こんな感じです

ボタンの処理
Form1 ^ fm = gcnew Form1;
fm->Show();

画面は普通に開きますが
別プロセスみたいにメイン画面の下に隠れます
親ハンドルを指定すればいいのかな？と思い
下のようにしても裏に隠れます

Form1 ^ fm = gcnew Form1;
fm->Show(fm->FromHandle(GetSafeHwnd()));

親子関係にするにはどうやればいいのかわからないです。
fm->Parentやfm->Ownerを設定してもダメでした

MFCダイアログとWindowsForm画面の親子関係は無理なんでしょうか？
やりたいことはMFC画面上に.NETコンポーネントである
グラフコントロールを表示したいだけです。
素ではダイアログに組み込めないのでWindowsForm画面に組み込み
子画面として特定の位置に固定させようとしています。
画面は表示できたのに位置合わせだけがダメです。

329:デフォルトの名無しさん
08/12/12 08:05:01
MFC 側で Window Activate 時に Form を前にしてやればいいんじゃね？

330:デフォルトの名無しさん
08/12/12 08:07:09
後は、ホストするか
URLﾘﾝｸ(msdn.microsoft.com)(VS.80).aspx

331:328
08/12/12 08:28:12
レスありがとうございます。
少し進展がありました。

ラッパーというのを作って
public ref class HwndWrapper : public IWin32Window
{
public:
HwndWrapper(HWND handle)
{
this->handle = static_cast<System::IntPtr>(handle);
}

virtual property System::IntPtr Handle
{
System::IntPtr get()
{
return handle;
}
}

private:
System::IntPtr handle;

};

332:328
08/12/12 08:29:03
Showのところでこうやると親子関係できました。

HwndWrapper ^ww = gcnew HwndWrapper(GetSafeHwnd());
fm->Show(ww);

ただ、親が動いても子は元の位置のままなのでちょっと不便です
ウインドウ上にボタンが乗ってるように一緒に移動してくれません。
MFC側でコントロールするとどうしても遅れが生じるので不自然っぽいです。

どうもうまくいかないので教えていただいた
「MFC ダイアログボックスとしての Windows フォームユーザーコントロールのホス」
の方をやってみます。

333:デフォルトの名無しさん
08/12/12 10:02:59
子ウィンドウとownedウィンドウの区別も付いてないのか

334:328
08/12/12 10:52:09
ホストの方法でいけました
ありがとうございました

335:デフォルトの名無しさん
08/12/13 18:30:25
ぬこでも～のwindows SDK編のイントロダクションのコードが
cygwinでコンパイルで通りませぬ・・・
VSでも無理だったんですが原因わかりますか？

URLﾘﾝｸ(www.kumei.ne.jp)

336:デフォルトの名無しさん
08/12/13 18:38:46
スレチ、winAPIスレへ行け

337:デフォルトの名無しさん
08/12/13 18:53:26
char使ってるからunicodeがらみだろうが
すれ違いの上エラーの内容も書かない阿呆か。

338:デフォルトの名無しさん
08/12/15 01:57:38
VS2005の環境でプログラム書いていたのですが、
テキスト形式のデータを読みだそうとすると以下のエラーが出てきてしまいました。

System.ObjectDisposedException' のハンドルされていない例外が mscorlib.dll で発生しました。

追加情報: 閉じている TextReader から読み取ることはできません。

System.ObjectDisposedExceptionのことを調べてもいま一つどういうことなのかがわからなかったので、
何がダメだと言われているのか教えていただけないでしょうか？
初心者なので意味不明な質問になってしまっているかもしれませんが、よろしくお願いします。

339:デフォルトの名無しさん
08/12/15 02:03:39
端的に言えば、Close/Disposeを読んだ後に、まだ何かやろうとしてるということ。
自分でそれらを呼んでいるか、自動変数のスコープを抜けるときに自動的に呼ばれたか。

340:デフォルトの名無しさん
08/12/15 10:29:08
元のコードに原因がある。

341:デフォルトの名無しさん
08/12/15 13:12:47
>338
こっち池

くだすれ．NET（超初心者向け）
ｽﾚﾘﾝｸ(tech板)

342:デフォルトの名無しさん
09/01/04 04:35:53
参照クラスって、使用しなくなったインスタンスを自動開放してくれるって
ことでいいんだよね？

343:デフォルトの名無しさん
09/01/04 14:11:08
そんな単純なものじゃない
住む世界が違う

344:デフォルトの名無しさん
09/01/11 01:45:20
この言語でMFCは使えるんですか？

345:デフォルトの名無しさん
09/01/11 01:46:21
使える

346:デフォルトの名無しさん
09/01/11 02:07:07
フォームアプリからMFCサポートに変更
MFCアプリから.NET使用＆フォームアプリダイアログ作成
できるんですか？

347:デフォルトの名無しさん
09/01/11 02:08:36
できる。聞くばかりじゃなくて、やってみればいいだろ
単純な MFC アプリケーション作って、そこで CLR サポート有りにすればいい

348:デフォルトの名無しさん
09/01/11 02:11:00
MFCウィンドウ内に.NETコントロールを置くほうはCWinFormsControl/View/Dialgのクラスもある。

349:デフォルトの名無しさん
09/01/11 16:10:30
全然わかりません、MFCで共通言語ランタイムサポートを選ぶと/MTと一緒はダメと言われます。どの項目を選んでもダメです。
これはどうすればいいんですか？

350:デフォルトの名無しさん
09/01/11 16:38:36
MFC の共有DLLを使えよ。どの項目を選んでも駄目ですって条件反射で書いてるんじゃねぇ

351:デフォルトの名無しさん
09/01/12 11:22:55
VS2008を再インストールしたら治る可能性があります。とかいうからやったらほんとに治った
共通言語ランタイムサポートにできました！

352:デフォルトの名無しさん
09/01/18 05:10:12
アンマネージからrefクラスの関数を呼び出すにはどうすればいいんですか？

353:デフォルトの名無しさん
09/01/18 05:36:03
managed　->　managed　で呼び出すのと同じ

354:デフォルトの名無しさん
09/01/18 05:39:11
>>352
静的メンバなら>>353の言うとおり。
非静的メンバの場合、#pragma unmanagedや/clrなしの領域から直接呼ぶことは不可能。
#pragma managedな領域にそれを呼び出すだけのラッパー関数を置くしかない。
インスタンスの保持だけは、<msclr/gcroot.h>してmsclr::gcroot<>で可能。
例えばこんな感じ。
#include <msclr/gcroot.h>
msclr::gcroot<System::Object^> CreateObject()
{
return gcnew System::Object;
}
int GetHashCode(msclr::gcroot<System::Object^> const& h)
{
return h->GetHashCode();
}
#pragma unmanaged
#include <iostream>
int main()
{
msclr::gcroot<System::Object^> h = CreateObject();
std::cout << GetHashCode(h) << std::endl;
}

355:デフォルトの名無しさん
09/01/18 05:40:25
ラッパーはmanaged領域でのネイティブクラスでも可能。ただし、依然としてmsclr::gcrootは必要。
#include <msclr/gcroot.h>
class XObject {
public:
XObject() : o(gcnew System::Object) {}
int GetHashCode() {return o->GetHashCode();}
private:
msclr::gcroot<System::Object^> o;
};
#pragma unmanaged
#include <iostream>
int main()
{
XObject o;
std::cout << o.GetHashCode() << std::endl;
}

356:デフォルトの名無しさん
09/01/18 05:51:22
はっきり言って全然わかりません。同時に使うのは厳しすぎますね
じっくり解読しますありがとうございます。

357:デフォルトの名無しさん
09/01/18 07:01:49
354と355のコードでは、refクラス = System::Object、関数 = GetHashCodeとして書いてある、一応。

358:デフォルトの名無しさん
09/01/30 01:24:35
なぜに、MFC＋.NETなんて使う必要があるんだ？
.NETが許される案件なら.NETで押し通せばいいじゃん

大抵の案件は、.NETは拒否られる

359:デフォルトの名無しさん
09/01/30 01:28:02
自分の狭い世界で語られてもな

360:デフォルトの名無しさん
09/01/30 02:06:05
.NETは遅い

361:デフォルトの名無しさん
09/01/30 02:35:18
そーだね
でもrubyよりは速いよ
起動以外は

362:デフォルトの名無しさん
09/01/30 21:08:41
Visual Studio 2008がやたら、重いんで
ちょっとしたテストプログラムはテキストエディタで作成して
コマンドラインからビルドしたいんですけど、どうすればいいのかしらん？

363:デフォルトの名無しさん
09/01/30 21:16:08
nmake か VCBuild を使う

364:デフォルトの名無しさん
09/01/30 22:18:18
C++/CLIのString型とC言語のchar文字列は、
どのようにデータをやり取りさせればいいのでしょう？

char c_str[]="1234";
String ^cli_str;

cli_str = c_str; // cli_strに"1234"をコピー

と言った事をやりたいのですが。

365:デフォルトの名無しさん
09/01/30 22:31:23
cli_str　=　gcnew　String(c_str);

366:デフォルトの名無しさん
09/01/30 22:34:52
2008以降ならmarshal_asおよびそのソースコード

367:デフォルトの名無しさん
09/01/30 22:40:43
バカ正直にやるならASCIIEncoding

368:デフォルトの名無しさん
09/01/30 22:46:30
その実体はMultiByteToWideChar

369:デフォルトの名無しさん
09/01/30 22:49:20
ありがとうございます。
コンパイルやってみて上手く動きました。

String型文字列をchar型にコピーするのについても質問したいのですが、

c_str[0]=cli_str[0];

というのを繰り返す事でコピーできる事まで調べました。
これを行う為の関数のようなものはあるのでしょうか？

370:デフォルトの名無しさん
09/01/30 23:00:33
・・・みんないっぱい検索キーワード出してるじゃん
まじめに探したの？

371:デフォルトの名無しさん
09/01/30 23:08:35
marshal_contextを使うか、CString/CStringA/CStringWを使うか。
どっちもexpress　edtionだと使えなかったと思う。
裏技的にはsprintfを使う方法がある。

372:デフォルトの名無しさん
09/01/30 23:12:30
だから、WideCharToMultiByte があるじゃないか

373:デフォルトの名無しさん
09/01/30 23:17:04
>>372
それは単なるUNICODE-ANSI変換でない？

残りの方法はこんなとこ、使い方はぐぐってね。
Marshal::StringToHGlobalAnsi
Marshal::StringToHGlobalUni
PtrToStringChars

374:デフォルトの名無しさん
09/01/30 23:18:12
>>369
それ仮名・漢字が入ると死ぬよ。

375:デフォルトの名無しさん
09/01/30 23:19:24
Encodingが一番確実か

376:デフォルトの名無しさん
09/01/30 23:25:26
>>373
Unicode -> MBCS変換だろうけど
WideCharToMultiByteは変換に使えないの？

377:デフォルトの名無しさん
09/01/30 23:28:02
>376
そのまえにToArrayしてpin_ptrして、サイズ計算して、領域確保して変換だから
ほかの方法のほうが断然楽

378:デフォルトの名無しさん
09/01/31 01:33:06
>>377
ToArrayよりPtrToStringCharsだろ。
いずれにせよ、pin_ptr<const wchar_t>化してしまえば、
既存のライブラリが使えるので、持ち合わせがあればそんなに悪くない選択肢だと思う。

379:デフォルトの名無しさん
09/01/31 14:04:04
C++/CLIで書いたプログラムって
Monoで動く？

380:デフォルトの名無しさん
09/01/31 14:09:57
動くのもあるし、動かないのもある

381:デフォルトの名無しさん
09/01/31 14:23:46
/clr:safeのものは動く。
ただしSTL/CLIのサポートはまだのようだった。

382:デフォルトの名無しさん
09/02/01 01:06:00
cl.exe でコマンドラインからコンパイルすると
～.exe.manifest
なるものも生成され、削除すると～.exeが起動しなくなります。

ｅｘｅ単体で起動できるようにするにはどうしたらいいのですか？

383:デフォルトの名無しさん
09/02/01 01:13:32
>>382
mt -manifest HOGE.exe.manifest -outputresource:HOGE.exe;#1
これやると、manifestがexe内に埋め込まれるので、manifest無しで動く。

384:デフォルトの名無しさん
09/02/01 01:29:08
>>383
ありがとう

できました。多謝です

385:デフォルトの名無しさん
09/02/01 23:49:39
CLIｽﾚ伸びませんねｗ

実際に使ってるところある？

386:デフォルトの名無しさん
09/02/02 00:27:50
仕事で事前調査用に使ったが、周りに理解されず、本番はVC++6.0でMFC4.2ときたもんだｗｗｗ

なんか、布教にいい道具があればいいのだけど…。

387:デフォルトの名無しさん
09/02/02 01:41:31
WPFとかに対応しない限りまず消滅すると思った方がいいだろうね。

388:デフォルトの名無しさん
09/02/02 02:25:50
WPFが俺の思ってる物と同じなら、対応するとかナニ言ってるんだって感じ。

まあ、Cのポインタ全部絶滅させられるならどっちでもいいがw

389:デフォルトの名無しさん
09/02/02 02:27:19
>>388
絶滅させられないからこそのC++/CLIじゃないの？ｗ

390:デフォルトの名無しさん
09/02/02 08:48:55
今のところMFCのCArchive使ってファイル保存していた古いデータを
.NET側から簡単に読み込むためのモジュールを作るのに重宝してるってぐらいだなぁ。

391:デフォルトの名無しさん
09/02/02 19:55:31
WPFみたいなほとんどマネージコードによるマネージコードのための超高レベルフレームワークを
わざわざC++で使う意味がわからない

392:デフォルトの名無しさん
09/02/03 01:32:22
まぁP/InvokeやCOWだけじゃ困る場面もたまにはあるわけだし。
やってることは凄いんだが評価されないC++/CLI。

とりあえず「C++屋のための.NET言語」という勘違いをされ気味なのはなんとかすれ。

393:デフォルトの名無しさん
09/02/03 02:17:17
進化したMS版C++Builderくらいにしか思ってませんでしたｗ

394:デフォルトの名無しさん
09/02/03 02:20:41
使いやすいGUIライブラリ付きのC++という捉え方は誤解の元だね

395:デフォルトの名無しさん
09/02/03 02:27:14
どうして誤解なのか解説しちくりくり

396:デフォルトの名無しさん
09/02/03 03:16:05
使いやすくないからな。
GUI部分はC#でいいべ。

397:デフォルトの名無しさん
09/02/03 09:07:45
C#の「＃」は、++++ で C++++の略でしたっけ？

398:デフォルトの名無しさん
09/02/03 09:21:42
>>396
まあそうなんだが、GUIだけ分けるのもかえって面倒だったりするしな。

399:デフォルトの名無しさん
09/02/03 15:51:47
>>389
何言ってんだお前

400:デフォルトの名無しさん
09/02/04 00:28:07
>>397
別に略ではないな

401:デフォルトの名無しさん
09/02/04 15:17:24
で、どうしろと？

402:デフォルトの名無しさん
09/02/04 21:50:29
とりあえずチンコでも揉んでみたら

403:デフォルトの名無しさん
09/02/04 22:13:08
チンコとかの話しかしない人に必要な言語は
C++/クリ(ry

C++/CLIは地味だけど、商用デスクトップアプリで
.NET使う場合はよけて通れない言語じゃないかなぁ。
.NETなアプリはまだ本家MS様も出してないよね？
Expression もハイブリッドだし。

404:デフォルトの名無しさん
09/02/04 22:18:08
ネイティブとマネージドのミックスタイプのアプリはMSのプロダクトに増えたけど、
基本的にホスティングがおおいな。
C++/CLIはあまり見かけない。

405:デフォルトの名無しさん
09/02/04 22:53:46
>>404
あ～。ホスティングだったのか。
勘違いを正してくれてありがトン

406:デフォルトの名無しさん
09/02/04 22:59:00
XNAのWindows向けアセンブリくらいだろうなぁ。

407:デフォルトの名無しさん
09/02/04 23:36:35
俺の言ったカンファレンスじゃ、ベンダーがC++/CLI がベストと言って楽しそうだった

408:デフォルトの名無しさん
09/02/04 23:51:11
WPFも一部C++/CLIだな
XNAのフレームワーク部分はC#だよ

409:デフォルトの名無しさん
09/02/05 00:03:15
>>408
んー？　Reflectorで眺めた結果で予想してるだけだが、
Microsoft.Xna.Framework.Game.dll以外はほぼC++/CLIのアセンブリでしょ。
FBXインポータが3MB超なのも、もろにfbxsdkのバイナリとマージしてるからかと。

410:デフォルトの名無しさん
09/02/05 01:17:05
ネイティブとマネージドのミックスタイプのアプリは現在、どの程度可能
なのか？

C++Builderでは、確かDelphi(Object Pascal)のコードがコンパイルできたと思う
が、こういうことがネイティブとマネージドの間で透過的にできるのか？

もちろん、マネージドコードとネイティブコードの混在ははるかに難しいと
思うが、これを簡単に実現できる方法を提示してもらわないとマネージドは
使う気になれない。

大体、トラブルがリンカエラーで出てくるというのは、エラー箇所の特定が
非常に難しく、最悪の状態ではないか？

まぁ、C＃が良いみたいだけど、結局、VBだろが、VC++だろが、C#だろが
Windowsプログラミングになるとどの言語だろが関係ない。

結局、MIcrosofが決めた訳の分からん取り決めに振り回されることになる
から。

411:デフォルトの名無しさん
09/02/05 01:18:58
日記もつけたし今日は寝る。お休み。

412:デフォルトの名無しさん
09/02/05 01:29:23
>>410
その混在を実現しているのが今のところC++/CLIだけ。

#pragmaでネイティブとマネージドどっちのコードを吐くか切り替えられる。
ネイティブクラスとマネージクラスの混在（has Aでの包含）は
透過的ではないものの、手段は用意されている。

413:デフォルトの名無しさん
09/02/05 02:22:24
URLﾘﾝｸ(blogs.msdn.com)

ただのネイティブ関数呼び出しであるP/Invokeですら
導入した瞬間にこんだけの「隙」が出てきてしまうのだから
簡単に実現できる方法って言われてもお花畑だよなぁ。

理想に対する泥臭い現実解としてはイイ線いってると思うけどねぇC++/CLI。

414:デフォルトの名無しさん
09/02/05 02:58:44
とりあえずガンガン使っていくので今後ともよろしく＞C++/CLI

使って情報を出さないとね。ググった結果に引っかかるサンプル増やせば
ちったあ底辺広がるだろうし。

415:デフォルトの名無しさん
09/02/10 09:57:12
バイナリフォーマットで100MBほどのデータを
シリアライズしようとしているのですが、
デシリアライズするときにメモリを数倍も消費して
ロードできないのですが、

デシリアライズをカスタマイズしないとできないのでしょうか？

GC::Collectするとメモリがいっぱい回収できます。

416:デフォルトの名無しさん
09/02/10 20:58:03
諦めてXmlReaderかストリーミングでLINQ to XML使った方がいい

417:415
09/02/10 23:00:48
結局、自前で読み書きするようにしました。

418:デフォルトの名無しさん
09/02/11 13:54:41
>>392
> やってることは凄いんだが評価されないC++/CLI。

MSがC#を前面に押し出したから見向きされなくなったよね。
それにC++はもともと敷居が高い言語だけど、
マネージドが入るとさらに敷居が高くなるからね。
員数仕事じゃ使うの無理じゃない？

419:デフォルトの名無しさん
09/02/11 13:58:36
>>418
＞MSがC#を前面に押し出したから見向きされなくなったよね。
その頃はまだmanaged　C++といってほとんど試作品」だったよ

420:デフォルトの名無しさん
09/02/11 13:59:16
C++/CLIのコンパイラのソース出してくれないかなあ。
CLIじゃなくて、JVMのバインディング、面白そう。

421:デフォルトの名無しさん
09/02/11 14:00:00
>>419
「その頃」違いです。

422:デフォルトの名無しさん
09/02/11 17:01:01
そもそも、.NETはお金を頂くソフトウェア作るには不向き
・遅い
・ソース丸見え
・フレームワークインストール必須
・FAでは絶対に無理

枚挙に暇がない

423:デフォルトの名無しさん
09/02/11 17:35:54
今時そんなのが問題になるのか？

424:デフォルトの名無しさん
09/02/11 17:48:12
＞・ソース丸見え
あっちこちでネガネガしてる奴のようだ。ほっとくに限る。

425:デフォルトの名無しさん
09/02/11 18:58:12
組込みでC言語、VB6を少々

しかやった事無いけど、CLRでデータロガ作ってみた。
Windowsの知識はほとんど無いけど、すごく簡単ね

Win32Apiでやろうと思ってたけど、自分のツール程度ならCLRでいいかな。
とりあえず田舎で本が手に入らないからゴリ押し(ほぼC言語ｗ)で作成中、
勉強すればもっと便利に使えると思うんだけど・・・。

皆さんはどうやってC++/CLRを勉強したの？

426:デフォルトの名無しさん
09/02/11 19:00:29
勉強？
どこをどう勉強する必要があるんだ？？

427:デフォルトの名無しさん
09/02/11 19:17:43
>>425
C++の経験者が使う言語だと思ったほうがいい。
Win32APIやCのライブラリを使わないならVB.netやC#やったほうがいい。

428:デフォルトの名無しさん
09/02/11 19:18:12
デフォルトでスマートポインタなCOMの一種と考えるとそれほどでもない

429:デフォルトの名無しさん
09/02/11 21:36:59
C++とC#の経験があればそのまま使える
というか，そういう人にしか旨味のない言語
簡単だと思うのはC#やVB.NETを触ったことがないから

430:425
09/02/12 03:33:22
>>426-429
ありがとう、意見を参考に、ずっとC#のサンプルコードいじってた。
とりあえず腹減ったので寝ようかな。

>>427
当初Win32APIをやろうと思ったけど、開発効率重視で諦めました。

*組込み屋なんで速度と柔軟な処理が可能かが気になりましたが、
そんな難しいもの作るわけじゃ無いので。

431:デフォルトの名無しさん
09/02/14 19:15:48
E-mail欄ってほとんどE-mail欄の役割は果たしてないよね。