開発
C++とJavaのお話
ここ数日久々にC++のコードを書きました。
久々にしてはコード書けるもんだ。
Eclipseよりやっぱり自分はVisual Studioが好き。
ショーットカットキーを体が覚えてるってのもあるけど、
Eclipseって裏でJavaが動いてるので起動時に
“もっさり”
した感じがしてあんまり好きではない。
出来るだけロードするプロジェクトを減らしてるけど
あんまり起動スピード変わらず。
それにオープンソースって誰かが手厚くサポートを
する訳でなく、（基本的には）有志で開発が行われるだけ
なので、いざという時に困る。
商業的な都合が介在しないのでそこは良いと思うし、
オープンソースは開発が止まる事がなく
バージョンアップを続けるので安心というのもあるけど、
どちらかというと前バージョンのとの互換性を無視しがちな
気がするのであまり好きではないです。
ポインタっていいッス。
クイックマクロ、やっぱイイヨ！
けど、Javaアソシエイツ（SCJA）の勉強もしてたりする。
勉強してると、やっぱ基本はC++だよな、Javaって。
と、思う。けど、引数は参照型が参照渡し、基本データ型が
値渡ししかサポートしないとか、暗黙の型変換がC++より
厳しかったりして、
“当然そう”
と思ってた所で引っかかって練習問題で引っかかる。
あと、練習問題見る限りでは引っ掛け問題炸裂。
MCPの試験の方がもう少し素直な問題だったような。
しかし、この本で勉強してると
1章でオブジェクト指向
2章でUML
の解説をいきなりするのでオブジェクト指向を
理解してない人がいきなり見ると難しいんじゃないかと。
というか、自分もMFCの勉強してた時に
判ったような判らないような感じになった気がします。
3月までには試験をしたいと思うんですが。
「Edy」を使ってソニースタイルでカシコクお買い物
投稿日 : 18:53 | コメント (0) | トラックバック(0)
C#でリソース（Bitmap）をアセンブリに埋め込んでそれを利用する
以下、以下の設定として話を進めます。
・プロジェクトはhogeApp
・埋め込むビットマップはhoge.bmp
○ファイル埋め込み編
1.ビットマップをプロジェクトに追加
2.ビットマップのビルドアクションを
「EmbeddedResource（埋め込みリソース）」に設定
○ファイル読み込み編
1.現在実行しているアセンブリ取得
System.Reflection.Assembly.GetExecutingAssembly();
2.アセンブリに埋め込まれているリソースを読み込む
asm.GetManifestResourceStream("hogeApp.hoge.bmp");
3.リソースから読み込んだストリームからBitmapクラス作成
Bitmap bitmap = new Bitmap(stream);
投稿日 : 10:55 | コメント (0) | トラックバック(0)
Google、Ajaxアプリ開発ツールをオープンソース化
GWTがオープンソース化したらしい。ちらっとだけ使ってみましたけど、
Swingなどで普通のJavaアプリを組んで、それを変換かけて
Ajaxのコードに置き換えるという手法をとってる珍しいツール。
Eclipseなど使い慣れた環境でJavaのコードを書けばよいわけで、
そういう意味では他のプラットフォームより良い感じ。
ただ、個人的には普通にJavaScriptで組んだほうが早いっていう
感じが少ししてたりするので、どっちもどっちですが。
どちらにしろオープンソース化は歓迎すべき事ですね。
個人的にはATLもオープンソース化されて欲しい。
されないか。
投稿日 : 19:23 | コメント (0) | トラックバック(1)
ウィンドウズアプリの開発やりたい
最近、AS＋RPGでCGIの開発ばっかりやってるんで、VCやC#あたり方遠く遠く遠ざかってます。
VisualStudioのすばらしいIDEとフリーフォーマットの言語が懐かしいなぁ・・・
と思ったりとか。RPGとAS/400をご存知の方ならこの想いが届くでしょう。
あー、Windowsの開発やりてぇなぁ。ASはもういいよ。
投稿日 : 20:40 | コメント (0) | トラックバック(0)
C++/CLIについて思うこと
C++/CLIを覚えようと最近アプリを書いていたりしますが、純粋なC++と比べ、
言語仕様が変わっているので、昔から触っている者的には違和感あります。
元々マネージ拡張自体が「無理矢理」感があったので、
C++の言語拡張ではなく、「C++/CLI」として格上げされて、
全体的には多少は改善されても、払拭しきれないという感じもありますが。
C++/CLIは、public、private等のいわゆるアクセス指定子（だったっけ？）を、
メンバ変数やメンバ関数を書くたびに指定する必要があったりします。
（というか、VS2005がそういうコードを自動生成します）
public: bool Hoge()
{
.......
}
public: void HogeHoge()
{
.......
}
んで、これが何が嫌かというと、{ }の位置が気になる、という事。
今までは、基本的にヘッダーで宣言してソースファイルでコードを書くので、
ソースの方にはpublic/privateを書く必要がないんですが、
そうすると、
bool Hoge()
{
.......
}
void HogeHoge()
{
.......
}
という感じになり、{ } が一番端に合わせられるのでしっくりきます。
ずっとこれでやってたので「慣れてる」というのはありますが、
現在は、ヘッダーにコードを書いて、しかもアクセス指定子は常に
記述するので、その分 { } の前にインデントが発生するので嫌かなと。
もっと嫌なのが、public: とprivate:が混ざっているコードを書くと、
public: bool Hoge()
{
.......
}
private: void HogeHoge()
{
.......
}
というように、各関数ごとに { } のインデントの位置が異なる感じになり、
それを眺めていると、すごい嫌というか。感じ分かりますか？
C#では、
private void HogeHoge()
{
.......
}
というコードが生成されるので意識はしてなかったんですが。
あくまでベースがC++というのがあるんで仕方ないですが、
VS2005が生成するコードの記法はそうだ、というだけかもしれませんが、
なんかやだなぁ、と。
あとは、C++はハンガリー記法だろ！という頭があるんで、
そのスタイルが変わったのも嫌ですが。
VBあたりの型にアバウトな言語なら問題ないでしょうが、
C++だと型ってやっぱ常に意識する必要がでてくるので、
昔の方がいいのかなぁ、とおもったり。
けど、.NETのコードもWin32のコードも混ぜて使えるC++/CLIはすごいですが。
C#だと、Win32を.NETのP/Invoke機能で無理矢理呼び出してたのを、
C++/CLIだとWin32がネイティブで呼び出せるのでよいなと。
C#触ってると分かるんですが、実際本気でアプリを書こうとすると、
必ず何らかの拡張なりオリジナルのコントロールなりが必要になりますが、
そうすると、必ずWin32は必要になってくるんで、C#だと面倒なんです。
なので、敢えてC#に行かなくても、C++/CLIで良いな、と最近思う。
まー、C#でもコード書けますし、.NET 3.0でまた変わるでしょうが。
投稿日 : 09:21 | コメント (0) | トラックバック(0)
Webアプリケーション
最近CGIの開発を（それだけじゃないですけど）開発してるので、
だんだんWeb系に強くなってきましたが、オブジェクト指向から離れて
トンと久しい感じです。趣味ではやってますがね。
CGIなんて所詮データの入出力のロジックをしこしこ書いてるだけなんで、
あんまし面白みはなかったりして。
JavaだろうがPHPだろうが、結局やってる事がかわらないので、
どの言語でも大して面白くないかもな、って思います。
何か、WEB系のサービスとかやって見たいですね。
コンテンツ販売とかね。
投稿日 : 23:50 | コメント (0) | トラックバック(0)
Unicode in AS/400
今回は思い切りオフコンよりのお話を少々。
現在、AS/400（iSeries。最近、System i5に名前が変わりましたが、以下AS)で
開発をしてるんですが、最近そのシステムについて多言語対応の要望が多く、
Unicodeの対応をしてくれなんていう話があり、調査の日々。
結論から言うと、
「無理です」
ASとRPGが過去の遺産引きずりすぎて、Unicode対応できないそうな。
文字コードはEBCDICでお願いします（IBM公式回答にて）、みたいな。
多言語対応したいなら、ネイティブにサポートしたJavaがいいんだと。
でも、Javaで書くならASでなくてもいいんだし、
なによりシステムを1から書き直すなんて話になるんだから、
いやです。
けど、社長が乗り気だから、調査続けないとならんとです。
んで、明日はその打ち合わせがあって某I社の営業所に向かうんですが。
あんまり実りのすくない打ち合わせになりそうな。
だって無理なんだもん。
投稿日 : 00:33 | コメント (0) | トラックバック(0)
今更ながら.NET 2.0の感想
ゲイツ君の会社が開発環境のうち、Express Editionを期間限定で
無償公開してるので（1年限定）、とりあえず全部ダウンロード。
C# 2.0で遊んでみる。1.1のアプリも問題なくビルドできるし、動作もOK
まー、これは普通。
で、新しいコントロール群について試してみる。
MenuStripやToolStripは、良いですね。すばらしいです。
ToolStripeなどは標準のコントロールはだいたい乗っけられるようだし、
ToolStripContainerと組み合わせれば、メニューとツールバーを
並び替えたり、ウィンドウの下に並べ替えたり自由です。
同じような機能は昔からフリーで公開されてはいましたが、
標準で用意されたところがポイント高いですね。
ビジュアルデザイナでマウス操作だけで作れるし。
さすがメジャーバージョンアップなだけに力入ってます。
C++はまだ確認してないですけど、このコントロールって
.NET Frameworkだけなんでしょうかね？
.NET Frameworkのコントロールって、カスタマイズしくなると
結局コントロールにメッセージを送って操作する必要があったりして、
（しかもメッセージ送信はWin32 APIのSendMessageを使う必要がある）
なんだか面倒な事が多いんですけど、少しは使えるようになったんだろうか。
Frameworkの中をこれからじっくり見てみようかなと思います。
投稿日 : 22:59 | コメント (0) | トラックバック(0)
SharpDevelop 2.0
注目点としては、.NET Framework 2.0に対応した点と、
何よりデバッグ機能をサポートした点だろうと思う。
見た目も多少変わった。
触った感想としては、まだ出たばかりなので1.1より不安定ではある。
あと、まだローカライズが完全じゃない。
しかし、デバッガを別に起動しなくていいのは相当イイ。
あとは、今までは「コンバイン」という独自のファイルで管理してたのが
Visual Studioと同じソリューションファイルで管理するようになった。
あとは、リソースの取り扱いが1.1では特殊だったのが、
2.0からはVisual Studioとほぼ同じになった。
なので、かなり洗練されている感じがある。
Visual Studioからの乗り換えでもさほど違和感は無い感じ。
注意点としては1.1からのプロジェクトを2.0で使う場合、
さっきのリソースがらみの管理方法がかわったのが原因して、
プロジェクトの動きがおかしくなる可能性があるといった所か？
よって、
C#を開発するだけなら、VisualStudioは明らかに要らないと思う。
一応、MicrosoftもExpress版は期間限定で無料にしてるようなので、
好みで使ってもいいと思うが、選択肢が増えたのはいい事だ。
チームで開発するとかなれば、そういうサポートが無いので辛いが、
運用でカバーできなくも無いので使えない事はない（かも）。
投稿日 : 09:16 | コメント (0) | トラックバック(0)
.NET
勉強がてら作ってる.NET(C#)のアプリも大分完成に近付きました。
作ってるうちに気付いたのは、最終的にはAPIの力が必要だという事。
コントロールのスタイルをカスタマイズするのは、SendMessegeでメッセージを送らないといけないんですが、それ相当のメソッドはありません。
なので、API呼び出しが必要なんです。
じゃ、初めからC++で書いた方が良いんじゃない？って気がしてきました。
APIとのマーシャリングは面倒ですし。.NETの機能が必要ならマネージ拡張で良いし。
ま、勉強がてらなんで。
投稿日 : 21:04 | コメント (0) | トラックバック(0)
