enumとか使っていると、文字列型列挙体が欲しくなってきます。 VB.NETはまだ初心者ですけど、ちょっと考え付いたのでメモ書き。 以下コードと解説 コード Public Structure sampleStructure Public Const hoge As String = “hogehoge” Public Const fuga As String = “fugafuga” Public Const foo As String = “foofoo” Public Const bar As String = “barbar” ‘構造体用インスタンスメンバをダミー実装 Private dummy As String ‘構造体のReferenceEqualsを参照出来なくする。 Private Shadows Function ReferenceEquals() As Object Return New Object End Function ‘構造体のEqualsを参照出来なくする。 Private Shadows Function equals() As Object Return New Object End Function End Structure 解説 ポイントはインスタンスメンバのdummy実装と、shadowsによる参照制限 インスタンスメンバのdummy実装はもしかしたら何とかできるかもしれない。

最近JavaからC++に移ったのだが、 Javaに比べて美しく書けないし、 CからC++に移った人のソースコードが読みにくい （JavaからC++に移った人のソースは読みやすい） これはJava書きとC書きの間に大きな隔たりがあるのじゃないだろうか？と考える。 昔関わったプロジェクトでC書きが納品したプログラムの修正をしたことがあったが、 読みづらく根を上げたことがあった。 （プロジェクトでは「古文書」と呼ばれていた） あの時は、C書きの人のソースが汚いだけかと思っていたが、 もしかしたらC書きの間ではメジャーな書き方なのかもしれない。 やはりC++のバイブル的なものを一読しなかればいけないだろうと思い、 少し調べてみると、 Scott Meyersの「Effective C++」がバイブルだという話だ。 (Gofのデザパタ本も読んだほうがいいんだろうが、まずはコーディングバイブル） さー買うぜ！って思い立ち本屋に直行。 見つけたEffective C++ なんだか More Effective C++ と書いてある、 気にせず購入しようとしたら、お金が足りない！ その時は購入をあきらめ、家に帰ってからAmazonで注文しようとすると、 どうもさっき本屋で見たものとは表紙が違う。 よくよくAmazonのコメント欄を見ていくと、 どうやらScotto MeyersのEffective C++は有名本でもあるらしく、 数人の訳者が訳本を出しているようだ。 中にはひどい訳本もあるらしく、私が買おうとしていたMore Effective C++は かなり評判が悪い。 そういったコメントの中で吉川邦夫氏という名前が見つかる、 彼が訳者の本は評判が良いようだ。 検索し見比べてみると、Amazonの本に対する評価も彼の本だけ満点がついている。 よし、吉川邦夫氏訳本を買うぞーとAmazonで注文しようとするも在庫切れ、 う～ん、流石吉川邦夫（笑） 近所の書店で注文するために、 AmazonからISBNコードを抽出。 そういえば、ISBNコードって書籍出版物に対するＩＤコードなんだろうけど、 ISBN-10とISBN-13があるんだね。 どう違うのだろう？両方ともメモって書店に渡さないと分からないのだろうか？ 気になって調べてみると ISBN-10は旧コード体系 ISBN-13は新コード体系 ということだそうだ どうやら旧コードの10桁ISBNでは足りなくなったので、 13桁にしたようだ。 よって13桁のほうを書店に持っていけば問題ない。 以下本当にどうでもよい記述。 -———————————————— ちなみに吉川邦夫氏のEffective C++ ISBNは ISBN-10 : 4756118089 ISBN-13 : 978-4756118080 ISBN-10のコード体系は A BBBB CCCC D A = 言語コード（日本語だと４）

いつもどおりiGoogleでNEWS記事を確認しようとすると 変なリンクがGoogleのトップページに貼ってあることに気づいた。 Chrome? 検索BOXに投げ込み調べてみると、 新しくGoogleが開発したWebブラウザだそうだ。 おお、そんなものまで作ったのか！ と え・・・またブラウザ増えるのか・・・やだなぁ 両方の感想がポっとでた。 とりあえず、インストールして触ってみて気になった点をいくつか プロキシ設定などはIEと共有している。 GoogleツールバーをインストールしようとするとFireFox2と判断され、出来ない （FireFox2のダウンロードを促される） 開発／管理の下にJavaScriptデバッガとコンソールが標準実装されている。 (もし使い勝手がよければFireFox3 + FireBugに変わる JavaScript開発のディファクトスタンダートにとって代わるかもしれない。 JavaScriptエンジンはV8（Google独自エンジン） GoogleGearsの設定がデフォルトで入っている。 シークレットモードがある（ブラウザに履歴などを残さずにブラウジングすることが出来る） JavaScriptエンジンが滅茶苦茶早い。 個人的に気になったのは、JavaScript関係とシークレットモードかな 他にも色々機能はあるみたいだけど、 とりあえずこんなもの。 Chrome用Googleツールバーが出来るまでは、とりあえず乗り換える気はないかな。 あ、でもGoogleNoteBookやRSSリーダー使うときは使うかも。 とりあえずjavaScriptはべらぼうに早い。 画像のDLが重いようなAjaxアプリでは体感出来ないが、 処理に時間がかかるようなアプリ（GoogleDocsのスプレッドシート編集など）をしていると結構体感出来る。 JavaScriptが早いという証左に以下サイトがある。 Google ChromeのJavaScriptエンジンV8の性能評価 参照すると、爆速がうたい文句のFireFox3.0より9倍近く早い。 （といっても既存のネット上のAjaxアプリが軒並み早くなるわけじゃない。 DL速度＋JavaScript処理速度＝ユーザーが感じるAjax処理速度なのだから） とここまでがそこそこ肯定的意見。 以下否定的 またブラウザが増える！（Web屋としての叫び） 最近の仕事はWeb屋じゃないから、多少他人事になってしまうけど。 LAMPだと基本全ブラウザ対応、 交渉次第でIE6～IE7とFireFox2.0とFireFox3.0対応が標準となる イントラのStruts系フレームワークの業務アプリだとIEしばりもしくはIE7までしばり イントラ系はまだいい、契約時に使用ブラウザを決定してしまえばいいんだから、 ただECサイトとかだと、顧客としては全ブラウザに対応してくれというし、 こちらもしてあげたい。 描画エンジンもJavaScriptエンジンも既存のものと違うとなると 怖いところはある。 ただjavaScriptエンジン（V8）に関しては、 今のままでいけるのではないだろうか。 現在prototype.jsなどで書かれている IEとFireFox両方対応のJavaScript（※1）があるのだけど、 それをV8エンジンは理解してくれると思う。 理由としては FireFoxとGoogleが今まで仲良くしていたこと。 FireFoxはW3C準拠であること、 Geekの集団GoogleがW3Cに準拠しないわけないこと よってFireFoxで動くものはV8エンジンでも動く・・・と思う。（※2） 少なくとも動くようには動いていくはずだ、現行動かないとしてもバグリストに追記されるはず。 HTML解釈スタイルシートに関して、 こちらもFireFoxと同じようになると・・・信じたいが、 FireFoxにMozira独自のプロパティがあったりするのが少し怖い。 ※1 テーブル要素操作などでIEとFireFoxで微妙な差異があるのだが、 prototype.jsはうまい具合に両方で動くものを書いている。 ※2 IEだとActivXを使ってローカルファイルにアクセスすることが出来る。 FireFoxだと別のファイルストリームにアクセスする必要がある。 そんなわけで、全てのJavaScriptがChromeで動くわけではないが、 ほぼ全てといってもいいのではないだろうか。