どこかのだれかへ

ボク、プログラマ。

海外フォーラムって改行少ないよね

最近とあるゲームの英語フォーラムを見るとき、英語の勉強だと思って英和辞典ツールを開きつつ頑張って自分で読んでいるんですが、正直辛いです。

英語フォーラムを開くと、長々とした英文がずらーっって表示されて圧倒されるんですが、それにしても精神への威圧がやけに強いと常々感じていました。こういう風に感じるのは、きっと自分が英語が苦手だからだと思っていたんですが、最近はそれとは別にそう感じる理由に気づきました。

海外フォーラムは、改行がすごい少ないんですよね。これはたぶん海外というよりかは日本が特殊なのだと思います。

日本の場合、メールにしろフォーラムにしろ、見やすいように句点、句読点や段落で改行することが多いと思います。画面の端まで行って自動改行ってあんまり見ないですよね。

ところが海外の場合は基本は改行しない。1つのことに関してはずらずらと書いていきます。で端まで行って自動改行されてます。

別にこの書き方はそれはそれでいいんですけど、画面いっぱいにテキスト表示されるのは、日本語でもちょっと辛いのに英語なんてもう読む気がすぐになくなってしまう・・・・・・。

最近は少しでも気持ちが緩和されるようにウィンドウの横幅を狭めて見たりしています。早くこの苦手意識をなくしたいですね。

ヘッダーファイルではnamespace内でもusing指令は書いちゃダメ

仕事のプログラムを見ていたら、ヘッダーのnamespace内にusing namespace XXXを書いている人がいました。ヘッダーファイルにusing指令を書くのは御法度です。しかしusing指令はブロックスコープなので、もしやこれは大丈夫なのかな?と思い、以下のような実験コードを試してみました。

namespace A
{
    void FuncA(){}
}

namespace B
{
    using namespace A;

    void FuncB()
    {
        FuncA(); // OK
    }
}

namespace B
{
    void FuncB2()
    {
        FuncA(); // OK Oh...
    }
}

希望としては"using namespace A"はB::FuncB2()には効かないとうれしかったんですが使えてしまうようで、別ブロック同名前空間が汚染されていることが確認できました。つまりこんなコードが書かれたヘッダーファイルをインクルードしてしまうと、それ以降は汚染されてしまうので、ヘッダーファイルにこのようなコードを書くのはNGとなります。これが出来るとclassメンバー変数とか書くのが楽になるなぁと思っていましたが、甘くはないようです。

プロジェクトによってはビルド時間短縮のためにcppファイル内で複数のcppファイルをincludeしてオブジェクトファイル数を減らす、なんて手法があったりするんですが、そうなったらcpp側の実装にもusing指令の汚染が広がってしまい、なかなかきついことになってしまいます。

やってから知りましたが、そもそも名前空間スコープとブロックスコープは扱いが全然違うようです。CppReference.comで仕様を確認しましたが、そこにも「名前空間スコープとブロックスコープに有効」と書いてありました。

仕事の方は・・・・・・現状汚染がひどいので「この名前空間内ではusing指令効いているよ!」を仕様にするのが早いと感じています。すでに汚染が広がっているのに動いているし、接頭辞ルールがあって切り分けできているので、たぶん大丈夫なはず、と信じたいです。

visual_studio.vimをpython3.xで動くようにした

普段、Visual StudioVimを交互に使っているのですが、この行き来を簡単にするvisual_studio.vimというものがあったですが、これがずいぶん前からメンテされていないようでした。

とりあえず自分の環境はPython 3.7なんですが、このプラグインが2.xでしか動かなかったのでforkしてPython3で動くように修正しました。

forkしたプロジェクトは以下になります。
GitHub - tepp91/visual_studio.vim: Vim and Microsoft Visual Studio .NET integration

バイナリデータを拡張性高くするためにXmlみたいな構造を作ってみた感想

バイナリデータって拡張にすごく弱くて、以前苦労しました。バージョンごとに構造体を書いていて管理が面倒でコードも汚くなっていきました。

そこで考えました。key-valueみたく、識別子・サイズ・値を1セットとして、すべてのメンバーやブロックを構成することで、自由にパラメータを追加したり削除することができるんじゃないだろうかと。つまり、JsonXmlのバイナリ化です。

仕事でやる機会がなかったので、現在家で開発中のゲームのフォントデータで採用してみました。

で、実際試したところ、

  • 書くのがめっちゃ面倒
  • ファイルサイズがでかくなる
  • 読み込みが遅い

という問題が出たので止めました。

書くのがめっちゃ面倒、に関してはおそらくXmlからコードに変換するツールとか作れば解決できるとは思います。

実は同じような構想のフレームワークはすでに存在していて、Message PackやGoogleのProtocl Buffersが該当します。Protocol Buffersを見つけたときは「まさにこれだ!」と思ったんですが、生成されるコードが非常に大きく複雑でわかりにくかったので止めました。もっとシンプルなものが欲しかったです。

ファイルサイズがでかくなる、はそりゃ当然で、全部の変数にID(4byte)とサイズ(4byte)を付けたためです。4byte整数1つのために8byteつけりゃ当たり前です。ちなみに当初924KBあったフォントデータは、現在ベタなやり方でやり直した結果、245KBになっています。差がひどい!

読み込みが遅い、も当然で構造体のコピーとメンバ一つ一つswitchに分岐して読み込むじゃ全然違うよねっていう。これは測定していないのでなんともですが、まあ書くのもしんどいです。

つまり拡張性を得るための犠牲がでかすぎたので止めました。今はベタに構造体並べたフォーマットでやっています。フォーマットが変わったら?もう全コンバートでいいんじゃないですかね。

でもいつかは、シンプルで、追加に強いバイナリフォーマットというのを考え出したいところです。

MVVMのViewModelの必要性を感じた

WPFではMVVM(Model/View/ViewModel)パターンを利用しますが、簡単なツールの場合はViewModelの存在意義があんまり無く、恩恵を受けにくく、その存在意義を忘れがちです。

ViewModelがある理由はView(WPFでいえばxaml関係)に関する都合を吸収するためですが、今まで作ってきた小さなツールの場合はそれを必要とすることがあまりなく存在意義は分かっていた物の結構適当に作っていました。

例えば今までだと、ModelにObservableCollectionのプロパティがあるとしたら、ViewModelではそのインスタンスを受け取って同じインスタンスをViewに渡していました。

しかし現在ツールを作っている中で、このコレクションヘのデータの追加を別スレッドでやりたいと思いました。しかしインスタンスをそのままViewに渡しています。ViewはUIスレッドじゃないと更新できません(例外が発生する)つまり、View側の都合でModelに制限が掛かっている状況なのです。せっかくのMVVMなのに、VMが機能してないせいでなんの意味もない状況だと気付きました。

たしかに、ViewModelは結果的に小さいツールでは要らない子になるかもしれまんが、こういうこともあるので、今後はちゃんとViewModel作ろうと思いました。

Google XML Document Format Style Guide

UIエディタの保存にXMLを使用としたときに、要素と属性の使い分けをどうすればいいんだろうかと考えてたときに出会ったのが、Google XML Document Format Style Guideでした。

https://google.github.io/styleguide/xmlstyle.html

C++のスタイルガイドはよく見てましたが、XMLのスタイルガイドもあるのは知りませんでした。

BitmapImageをbyte[]に変換する

各フォーマット毎にBitmapEncorderがあるので、コレを使います。

BitmapImage image = /*pngイメージ*/;
var encorder = new PngBitmapEncoder();
encorder.Frames.Add( BitmapFrame.Create( image ) );
using( var stream = new MemoryStream() )
{
    encorder.Save( stream );
    data = stream.ToArray();
}