サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
掃除・片付け
meg-nakagami.hatenadiary.org
ちょっと特殊な環境下で xml をパースする必要があって、いろいろと xml パースライブラリを探したのですが、どれもちょっとづつ求めるものと違うところがありうまく行かず、自前で xml パーサを書く必要がありました。 その時のことを書いてみようかと思います。 開発言語 開発言語は C++ です。ですが、以下の様な制約がありました。 言語はほぼ C++03。 例外が使用できない。 RTTI が使用できない。 boost は使用できない。(標準ライブラリはOK.) boostはヘッダのみで使用できるものであれば導入することは可能ではあるのですが、プロジェクトのメンバーを説得することができませんでした。 実行環境の特性 実行環境はちょっとした組み込み機器です。 メモリは潤沢にあるのですが、その割り当て(malloc)が無視できないレベルで遅いため、細切れの new(malloc) をできるだけ
例えば何らかの設定ファイルに true か false という値が書いてあって、それを読み出して拡張機能の有無を変更しなければいけないとします。いろいろ状況は違うだろうけど、とりあえず std::wstring GetProperty( const char* pch ) という関数で "EnableExtention" という Property を取ってくるものとします。 こういうのを何も考えないプログラマがこういうのを作るとこんなかんじでしょうかね。 if( GetProperty( "EnableExtention" ) == "true" ){ // ここで拡張機能をなんとかする。 } とりあえずこれで問題はないかもしれません。 ですが、これだとおそらく半年ぐらいたってから、『EnableExtentionの設定が効かない』といって問題になります。 調べてみると、設定ファイルには
2019/10/31 を持って8年間勤めてきたドワンゴを退職しました。 ドワンゴ退職エントリの旬は過ぎているよう気もしますし、こんな何年も放置していたブログで今更何をと思わなくもないですが、なんとなく自分の気持ちの整理もかねて適当に綴ってみようと思います。 何をやってきたか 各種のゲームデバイス、PS Vita, Wii U, 3DS, Nintendo Switch 上でのニコニコプレイヤーの実装をずっとやってきていました。 それぞれのデバイスでのシステム部分というか、ゲームデバイス上での非ゲームアプリケーションフレームワーク、そんなものを作り続けてきた感じです。 これらのニコニコ動画クライアントは、私の手を完全に離れてしまうことになります。 もっとできることはたくさんあるし、改善すべき点もたくさんある。愛用してくれているユーザーに対して自分が出来るはずのすべてを提供することができなかっ
GoogleChrome は ProgramFiles ではなく、LocalAppData(C:\Users\[ユーザー名]\AppData\ もしくは C:\Documents And Settings\[ユーザー名]\Local Settings\Application Data\)にインストールされる。 このLocalAppDataは(MSがどう考えるかわからないが)システムに影響を与えない個人向けのアプリケーションのデフォルトのインストール先の選択肢として検討すべきものであると思われる。 メリットとしては、 アクセスに管理者権限(IntegrityLevel High)の必要がない 64bit環境のディレクトリリダイレクトの影響を受けない などがある。 デメリットとしては、ユーザーごとのディレクトリであるため、マシン単位でのインストールが出来ない、共有DLLなどを配置することができ
PHP の strval 関数のマニュアルPHP: strval - Manualに strval() は配列に対して使うことはできず、 __toString メソッドを実装していないオブジェクトに対しても使うことはできません。 という記述があるけれども、これはドキュメントとしておかしいと思う。 『使うことはできません』とかいったところで実際渡せてしまうのだから、書くべきなのは、どうなってしまうのか、あるいはその関数の実装側としてクライアントにどうしてほしいのかだと思う。 『配列、もしくは__toString メソッドを実装していないオブジェクトを strval に渡した結果は未定義とします。』 とか、 『strval はスカラー値を文字列化することを想定しているため、配列、もしくは__toString メソッドを実装していないオブジェクトを渡さないでください。』 とか、そういうふうに書か
前のエントリ設定ファイルから true か false を読み出す。 - meg_nakagamiの日記ですけど、これは C++ 的にはまだまだ甘いので、みんながある程度 C++ を詳しく知っている、もしくは向上心があって知らないことを学習の機会とみなしてくれる人であるという恵まれたプロジェクトであったらどんなものを作るか考えてみます。 いろんな前提が考えられるかと思うのですが、 複合的なデータ構造は格納しない、 key = value のスカラー値のみを扱う。 keyは殆どの場合予め定められたものを使用する、プログラムでキーを生成して格納するという用途でも使用できるべきだが、そのような用法は優先しない。 保存は SetProperty、取得は GetProperty で文字列を扱う仕組みがすでにできている。 SetProperty、GetProperty はあらゆる文字列を扱うことができ
試しに公開してみた https://code.google.com/p/lix-failable/source/browse/ こいつですが、 例えばこういう関数を作るとして、 // 普通は失敗しない何かをする。失敗時は false を返す、失敗理由は(Win32の)GetLastError で。 BOOL DoSomething( int x); この 『失敗理由は GetLastError()』 というのは、概念的にはその関数のシグネチャに含まれていますが、シンタックス的にはシグネチャではありません。 かといって、ここで『ErrorCodeを返す』ように変更してしまうと、エラーハンドリングの記述が直感的ではなくなる、という問題が発生してしまいます。 BOOL DoSomething( int x); // どこかで DWORD err = DoSomething( path ); if
このページを最初にブックマークしてみませんか?
『meg_nakagamiの日記』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く