「Goは興味あるけど、会社は(Python|Ruby|PHP|Perl|Java|C#)だからなぁ」というあなた。 個人的なCLIツールを、Goで書き直してみたらいかがでしょう？ GoはLL並に書きやすいだけでなく、LLには無い優れた特徴を兼ね備えた言語なのです。
以下のコードはビルドできません。「マネージ 'hoge' をアンマネージ 'Native' で宣言できません。」というメッセージが出ます。 class Native { public: StringBuilder^ hoge; }; managedな変数hogeがGCによって移動された場合に、unmanagedなクラスではその追跡ができなくなるのが要因です。これを克服する方法を以下に書いていきます。 なお、ここでいうmanagedな変数とは、ref classです。型名の後ろに ^ が付くものです。 方法1 : ポインタで保持する GCで動かないよう固定するといえば、System::Runtime::InteropServices::GCHandleの出番です。 GCHandle::Alloc によってmanagedオブジェクトのハンドルを取得します。ハンドルはIntPtrに変換でき、また
始めに C++/CLI はおそらく旧来のライブラリを .net のアセンブリに変更されるのに一番利用されると考えています。 そのとき、一番面倒なのは、旧来の MBCS や wchar_t 型と System::String をどうやりとりすればいいのかという点です。 ここでは、MultiByte ないし、 WideChar の System::String 型とのやりとりについて記述しておきます。 MultiByte から System::String に WideChar から System::String に System::String から MultiByte に System::String から WideChar に Visual Studio 2008 での追加機能 MultiByte から System::String に これは特に問題も疑問の余地もないですよね。 std
Not your computer? Use a private browsing window to sign in. Learn more about using Guest mode
重要度が高まるC++ いま一部でプログラミング言語「C++」の重要度が高まっている。ここで勘違いをされると困るので念のために強調しておくが、これは「C++の重要度は高まるだろう」という未来予測を書いているわけではない。すでに一部では重要度は高まっている、という現在の状況について書いているのである。 恐らく、このように書けば、そんなバカなと思う人も多いと思う。なぜなら、C++といえばすでに過去の言語であり、しかもJavaの誕生とともに、生産性の悪い失敗作のレッテルを張られて葬り去られたといっても過言ではないからだ。そして2005年のいま、すでにJavaすらもほころびが見える古い言語となっている。Windows環境であれば、明らかにJavaよりも生産性に優れるC#もあれば、大きく進化したVisual Basicもある。このような状況で、Javaを振り返るならともかく、それよりもさらに古いC++
外池と申します。 他のスレッドにおいて、C++/CLIにおけるCLRのクラスの定義と利用の方法について大いに議論されているところですが、以下の点について私の中で整理がつかなくなってきたので、ご存知の方にご教示いただきたく。 １）さらに別のスレッドですが、「このままでは、MFCとCLRが両方混在した形になっています」というような指摘を受けるコーディングが示されていたことがありました。 あるいは、 2) CLRの配列であるarray <T>^ と、C++の標準的な配列と、同じコーディングの中に混在させて使用することがでるようです。 まず、２）についての「混在可能」の理解は、正しいでしょうか？ 正しいとして、 MFCの利用やC++の標準的な配列の利用には、プラットフォームに依存したポインタの操作とメモリ管理の手法が必要であり、そのためにはネイティブコードが必要だと思われます。一方で、CLRに準拠
CLIは混在モードで使用すると、.NETの機能とネイティブなC++を同時に使用することができる非常に便利なものですが、いくつか注意しなければならい点があります。 今回は、そのCLI混在モードでのアプリケーション開発時の注意点の１つについてです。 ・サンプルの準備 まずはじめに、VisualStudioのウィザードで、C++/CLIのWindowsFormアプリケーションのプロジェクトを作成します。 そして、作成したフォームクラスにボタンコントロールを追加して、こんな感じのフォームを作ります。 そして、作成したボタンコントロールのイベントを作ります。 不要な部分はすべて省略しますが、ここまでの手順でフォームクラスのソースコードは以下のようになっていると思います。 #pragma once namespace CLIForm { // 略 public ref class Form1 : pu
引用元はこの辺かな． また，システムグローバルなキー入力の監視方法には主に3通りあります． (フィルタ)ドライバの作成 キーボードフックの使用 低水準キーボードフックの使用 有名な『窓使いの憂鬱』は1を，かおくさんから紹介があった『Xkeymacs』は2を使用しています． 1 は最も強力ですが最も手間がかかります．2は特定アプリケーションのみを監視するのには便利ですが，フックハンドラは DLL に実装しなければならないため .NET での実装上問題があります．また，2ではAlt+Tab などの一部のキーストロークはフックできません．3は使用可能環境に Windows NT 4.0 SP3 以降という制限がありますが，キーボードドライバや SendInput API によって入力された直後をフックすることが出来ます．また3はフックハンドラを DLL に置く必要がないという特徴があり，.NET
復元ディスクやスナップショット機能を使う場合、マスタとなる仮想ファイルに書き込む必要はないので、読み出しのみのファイルでも問題はなさそうだが（実際、復元ディスクやスナップショットでは、マスタの仮想ディスク・ファイルへの書き込みは発生しない）、このように設定画面でエラーとなってしまい、設定を完了することができない。 なおVirtual PCやVirtual Serverの場合は、警告メッセージは表示されるものの、マウントすることは可能である。なので、読み出しのみの仮想ディスク・ファイルをマウント後、復元ディスクを有効にしておけば、仮想マシンを起動して利用できる。 差分ディスクを自動的に作成させる このような問題を避けつつ、マスタとなる仮想ディスク・ファイルを読み出しのみの属性を付けて保護する簡単な方法として、差分ディスクを作成して利用するという方法がある。マスタの仮想ファイルを保護したまま、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
