syghの新フラグメント置き場

プログラミングTipsやコード断片の保管場所です。お絵描きもときどき載せます。

C# 6.0コンパイラーの興味深い挙動

C#言語はnullに関連する演算子が豊富です。

null合体演算子

null合体演算子は左側オペランドがnullでない場合は左側オペランドを返し、nullの場合は右側オペランドを返します。参照型のほか、Null許容型(Nullable)にも適用可能です。C# 2.0で追加されました。

x ?? alt

三項演算子で書くと以下のようになります。

x != null ? x : alt

null条件演算子

null条件演算子オペランドがnullでない場合はメンバーアクセス(.もしくは[])を実行します。参照型のほか、Null許容型(Nullable)にも適用可能です。C# 6.0で追加されました。

x?.SomeMethod();

if文で書くと以下のようになります。

if (x != null) { x.SomeMethod(); }

もしここでSomeMethod()が値型Tの戻り値を持つ場合、x?.SomeMethod()の評価結果はNull許容型T?となります。

応用

これらの演算子を応用して、「引数がnullでない場合はToString()を呼び出し、nullの場合は代替のリテラル文字列"N/A"を返す」という処理をスマートに書いてみます。

// (1)
public static string ConvertToNAIfNull<T>(T x)
{
  return x?.ToString() ?? "N/A";
}

もしこれらの演算子を使わずに書くとすれば、以下のようになります。

// (2)
public static string ConvertToNAIfNull<T>(T x)
{
  return x != null ? x.ToString() : "N/A";
}

いずれにせよ1行で書けますが、(2)はxが2回出現して冗長なので、特にメソッドではなくインラインで書く際に不便そうですね。厳密に言うと、(1)と(2)は完全互換ではありませんが、通例ToString()は空文字列""を返却することはあってもnullを返却することはないので実用上は問題ないはずです。

ここで興味深いのが、(1)のジェネリクスには参照型やNull許容型だけでなく、通常の値型を渡しても実体化できるということです。csc 2015 (Visual C# 2015) でもgmcs 4.6.2でも動作します。

Console.WriteLine(ConvertToNAIfNull(new int?(10)));
Console.WriteLine(ConvertToNAIfNull(default(int?)));
Console.WriteLine(ConvertToNAIfNull(10));

値型に対する?.演算子呼び出しは無効なので、一見コンパイルエラーになってしまう気がしますが、(1)のジェネリクスC#コンパイラーが内部で以下のように展開するせいで、値型を渡してもコンパイルエラーにはならず実体化できる、というからくりになっているようです。

// (3)
public static string ConvertToNAIfNull<T>(T x)
{
  if (x != null) {
    var t = x.ToString();
    if (t != null) {
      return t;
    }
  }
  return "N/A";
}

値型に対してはx != nullコンパイルエラーにはならず常に真なので、(2)や(3)のジェネリクスに値型を渡せるのは当然です。いずれにせよ、ConvertToNAIfNull()に値型を渡すと冗長なメソッドになってしまいますが。

Windows 10でPhotoshop CS5が起動に失敗するときの対処

Windows 10 Anniversary Updateをインストールした後、Photoshop CS5が起動時にクラッシュするようになりました。管理者特権だと起動します。仕方ないのでWindows 7互換モードに設定すると起動するようになりました。

もともとCS5はWindows 10に正式対応していないし、無償サポートの期限も切れているので、まあ仕方ないといえば仕方ないんですが、別に新機能が欲しいわけでもないのにサブスクリプション契約を続けなければならないCCに移行したいとは思いません。CS5に限らず、この先もWin10に大型アップデートが来るたびに同じようなアプリケーション互換性のトラブルが発生しそうです。ただでさえカオスでキメラな設計のWin10に、これ以上余計な機能や仕様変更を加えてどうするつもりなのか。もはや余計な機能追加なんて誰も望んでいません。本来アプリケーションを安定して動かすのがOSの役目なのに、今のWindowsは出しゃばりすぎです。

余談ですがWin10のUpdateOrchestratorの挙動は極悪すぎます。勝手にWindows Updateを実行したうえ、ユーザーの許可なく勝手にスリープやハイバネーションを解除してPCを再起動するなんて、横暴にもほどがあります。どれだけユーザーをバカにしているんでしょうか。Creators Updateでは多少緩和されているようですが、それにしてもアップデートのたびにプライバシー設定をリセットするのは極めて卑劣なやり口です。あとせっかくカスタマイズしたWindowsエクスプローラーの設定をリセットするのもやめて欲しい。

Photoshopのレイヤー数をスクリプトで数える

本業の仕事が忙しかったこともあり、前回の記事から1年近く何も書けませんでした。すでにはてな記法を忘れつつありますが、ぼちぼち頑張ります。

Photoshop内部では、レイヤーを"art layer"、グループ(フォルダーアイコン)を"layer set"と呼んでいます。
今日はExtendScriptを使って、ドキュメント中のレイヤーとグループの数を自動的にカウントしてみます。

function getArtLayerCount(layerSet) {
    var na = layerSet.artLayers.length;
    for (var i = 0; i < layerSet.layerSets.length; ++i) {
        na += getArtLayerCount(layerSet.layerSets[i]);
    }
    return na;
}

function getLayerCountPair(layerSet) {
    var na = layerSet.artLayers.length;
    var ns = layerSet.layerSets.length;
    for (var i = 0; i < layerSet.layerSets.length; ++i) {
        var pair = getLayerCountPair(layerSet.layerSets[i]);
        na += pair[0];
        ns += pair[1];
    }
    return [na, ns];
}

//alert("Total art-layer count = " + getArtLayerCount(app.activeDocument));

var pair = getLayerCountPair(app.activeDocument);
alert("Total art-layer count = " + pair[0] + "\n" + "Total layer-set count = " + pair[1]);

app.activeDocumentを基点として、関数を再帰的に呼び出すことでトータルのレイヤー数およびグループ数を求めます。今回はレイヤー数とグループ数のペアを管理するのに配列を使ってみました。
ちなみにこのスクリプト、かなり負荷が高いので、100個くらいレイヤーがあるときにExtendScript Toolkit上でデバッグ実行するとめちゃくちゃ時間がかかります。デバッグが済んで不具合がないことが確認できたスクリプトはjsxファイルとして保存し、Photoshop本体の[ファイル]→[スクリプト]→[参照]でファイルを指定して実行しましょう。

Photoshop v7.0以降ではレイヤー数の上限は事実上ないようなのですが、SAI v1.xではレイヤー数上限が256 (255?) 枚までとなっているため、定期的にレイヤー数を確認して、不要なレイヤーを削除したり結合したりしておく必要があります。SAI v2では上限が8190枚となる予定だそうです。ぶっちゃけ64bitネイティブ移植して各種上限を撤廃するだけであればそんなに開発に時間がかかるとは思えないんですが、大幅な機能追加や仕様変更を伴っているせいで正式リリースがいつになることやら……気長に待つしかなさそうです。

Windows 10の画像ファイル右クリックメニューに「プレビュー」を追加

無償アップグレードの期限ギリギリになりましたが、ついにWindows 8.1からWindows 10にアップグレードしました。Windows 10は昨年のプレビュー版のときにDirectX 12 APIを少しテストした際に、全体的な完成度の低さが目についたため、それ以来一切触っていませんでしたが、2015年7月のリリースから1年を経てそれなりにこなれてきたようなので、まず念のためWindows 8.1のイメージバックアップを取ってからWindows 10に移行しました。しばらく使い込んでみて、ダメだったら8.1に戻す予定です。いずれはWindows 10に誰しも移行せざるをえませんが、自分の場合現時点でよく使うクリエイティブ系ツールやゲームが正常に動かなければ意味がありません。

Windowsフォトビューアー

本題に入りますが、Windows 7/8.1では、エクスプローラーで画像ファイルを右クリックした際に表示されるコンテキストメニューに、「プレビュー」という項目が含まれていました。このコマンドは、画像を「Windowsフォトビューアー」というデスクトップアプリケーションで開くことができるもので、拡張子すなわち既定の「開く」コマンドに関連付けたアプリケーションとは別に独立して使用できるコマンドです。「Windowsフォトビューアー」は、IrfanViewなどとは違ってフォルダー内の複数ショートカットファイル群を連続プレビューしたり、エクスプローラー上の並び順でファイルを閲覧することができたりといったメリットがありました。全体的な操作性や対応画像の種類などはIrfanViewに若干劣る面がありますが、カラープロファイル対応というのも何気にポイントが高いです。残念ながらWindows 10ではこのコマンドがなくなっているだけでなく、クリーンインストールした際には「Windowsフォトビューアー」自体が無効化されています。今回は幸いWin8.1からのアップグレードインストールだったので、コマンドを復帰するだけで済みました。復帰の手順は下記のようなサイトで紹介されています。

ascii.jp
moshimore.jp
ryus.co.jp

毎回手作業で実行するのは面倒ですので、今回は「プレビュー」コマンド復帰の手順を一発で実行するためのレジストリファイルの内容を記載しておきます。UTF-16LE形式のテキストファイルで.reg拡張子を付けて保存してください。ただしご利用は自己責任でどうぞ。

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\SystemFileAssociations\image\shell\openwpv]
@="プレビュー"

[HKEY_CLASSES_ROOT\SystemFileAssociations\image\shell\openwpv\command]
@="%SystemRoot%\\System32\\rundll32.exe \"%ProgramFiles%\\Windows Photo Viewer\\PhotoViewer.dll\", ImageView_Fullscreen %1"

[HKEY_CLASSES_ROOT\SystemFileAssociations\image\shell\openwpv\DropTarget]
"CLSID"="{FFE2A43C-56B9-4bf5-9A79-CC6D4285608A}"

Windows 10とSAI

今のところ、Win10でSAI v1.2.xの挙動が若干おかしいのが気になります。SAIはファイルI/Oなどの時間がかかる処理をサブスレッドではなくメインスレッド(UIスレッド)で実行しているレガシーアプリケーションなのですが、多数のレイヤーの回転・拡大縮小中とか、ファイルオープンダイアログでのサムネイル自動生成中とか、巨大な画像ファイルの読み書き中とか、UIスレッドが固まる状況でタスクバー部分が一定時間まったく見えなくなる現象が出ます。処理が完了すればタスクバーは復帰しますが、それまでは操作ができなくなります。v1.2.0/v1.2.5で確認しました。Win8.1だと同様にUIスレッドがビジー状態になったときにSAIのウィンドウがボケる(バイリニアフィルターがかかったようになる)現象が出ていましたが、タスクバーが見えなくなるというレベルのひどさではありませんでした。一方、Visual Studio 2012/2013/2015の場合、起動時など「応答なし」状態に陥ることがあるときでもタスクバーまで巻き込むようなことは一切ないので、おそらくSAI自身の設計に起因する固有問題なのだと思いますが、後継となるv2.0もいまだにプレビュー版のままなので、SAIを仕事で使っている人はWindows 10に移行するのは待ったほうがよいかもしれません。画像編集アプリなのに64bit対応が遅れているというネックもあるものの、クリスタでは使い勝手や書き味が違うため、泣く泣く32bit版のSAIを使い続けているという状況なのですが、早いところなんとかして欲しいです。
ちなみに、ちまたで噂されているペンタブレットの遅延ですが、今のところ特に書き味が悪くなったという感じはありません。検証したのはIntuos Pro M (PTH-651) + 6.3.16-2ドライバー環境ですが、それなりに高速なCPUを積んでいるので気にならないだけかも。
※2017-02-05追記:
Windows 10 Anniversary Update (version 1607, build 14393) をインストールして、グラフィックスドライバーをGeForce 378.49 for Win10 x64に更新したらSAIフリーズ時タスクバー問題が解消されたようです。もしかするとWindows 10 November 2015 Update (version 1511, build 10586) もしくは358.91ドライバーのどちらかに問題があったのかもしれません。ちなみにUpdate 1607を適用すると、コンテキストメニューからプレビューコマンドが再び削除されますので、再度登録作業が必要になります。
※2017-07-29追記:
Windows 10 Creators Update (version 1703, build 15063) をインストールすると、SAIフリーズ時にウィンドウがデスクトップ全体に引き延ばされる(タスクバー部分まで伸びる)現象が出るようになりました。グラフィックスドライバーはGeForce 378.49でも384.94でも発生します。ただ、タスクバーよりもZオーダーが下なので、タスクバーがまったく見えなくなったり、操作できなくなったりという実害はありません(単純に動きが気持ち悪いだけ)。

その他の落穂拾い

Windows 10では「Windowsフォトビューアー」の代わりにUWPの「フォト」アプリが搭載されていますが、前述のようなエクスプローラーとの統合はなく使いづらいです。「Windowsフォトビューアー」のサブセットでしかなく、IrfanViewと比較するとカラープロファイルに対応していることだけしかメリットがありません。また、Windows 10の電卓は相変わらず使いづらいストアアプリ(UWPアプリ)版のみしか搭載されていません。Windows 10 EnterpriseのLTSB版には従来のデスクトップアプリ版の電卓が「win32calc.exe」という名称で提供されているらしいのですが、Win10 Home/Proにもデスクトップアプリ版をぜひ搭載して欲しいです。

Vulkan SDK付属のGLSLコンパイラー

2016年2月にVulkanの正式仕様とSDKがリリースされ、その後NVIDIAAMDなど大手GPUベンダー各社からもPC向け正式ドライバーがリリースされ始めているので、そろそろ試してみることにしました。まずはシェーダーのコンパイラーまわりから入ります。ちなみにVulkan仕様とSDKは、最初の正式リリース以降かなり頻繁にリビジョンアップが続けられています。

LunarXchange - The source for Vulkan development tools (sponsored by Valve)

Vulkan用GLSLコンパイラ

Vulkan SDKにはGLSLをコンパイルしてSPIR-Vを出力することのできるオフラインコンパイラー「glslangValidator」が付属します。

32bit版 (x86) は下記にインストールされます(Windows環境)。

%VK_SDK_PATH%/Bin32/glslangValidator.exe

64bit版 (x64) は下記にインストールされます。

%VK_SDK_PATH%/Bin/glslangValidator.exe

Visual Studio (Visual C++) の[カスタム ビルド ツール]でプロジェクトのビルド時にGLSLソースファイルからSPIR-Vバイナリを生成するとき、たとえば下記のように[コマンド ライン]の項目を設定します。

echo Now compiling GLSL source file to SPIR-V...
"$(VK_SDK_PATH)\Bin32\glslangValidator.exe" -V "%(Identity)" -o "$(OutDir)VkShaders\%(Filename).spv"

[出力ファイル]には「$(OutDir)VkShaders\%(Filename).spv」を指定します。
例として "VkShaders" サブフォルダーを挟んでいますが、このフォルダーはVisual Studioが勝手に生成してくれます。

なお、glslangValidatorはBOM付きUTF-8を扱えないので注意。BOMなしのUTF-8もしくはASCIIを使う必要があります。

#includeディレクティブ

GLSLは標準で #include ディレクティブをサポートしませんが、Google拡張とARB拡張は存在する模様。

#extension GL_GOOGLE_include_directive : enable
#extension GL_ARB_shading_language_include: enable

しかしVulkan SDK 1.0.13.0付属のglslangValidatorでGoogle拡張を有効にしても、実際に #include を使えるようにはなりませんでした。ARB拡張に至っては有効にすることすらできない模様。これのどこがリファレンスコンパイラーなのか……

なお、Googleは「glslc」と呼ばれるシェーダーコンパイラーを開発して公開している模様です。SPIR-Vにも対応しているらしい。試してはいませんが、こちらは #include が使えるものと思われます。
https://github.com/google/shaderc/tree/master/glslc

ちなみにGoogleのGLSLコンパイラー実装では、

#extension GL_GOOGLE_cpp_style_line_directive : enable

のようにして拡張を有効にすると、

#line 1 "test.frag"

のように #line ディレクティブの第2引数にファイル番号の数値ではなく任意文字列を使えるようになるらしいです。この拡張機能はVulkan SDK 1.0.13.0付属のglslangValidatorでも使える模様。もともと #line はGLSLコンパイル時にエラー/警告メッセージから問題発生個所を特定するなどの目的でプログラマーがファイル番号や行番号を明示的に制御するための機能で、OpenGLではコンパイル対象となる複数のGLSLソース文字列をオンメモリで結合するAPI (glShaderSource) が用意されている関係上、仕方なく存在しているような変な機能なんですが、せっかくオフラインコンパイラーがあるのにVulkan開発でも #line なんぞを明示的に使わないといけない時点でナンセンス極まりないです。ちなみにDirectXのHLSLには #include が完備されていて、#line のような余計な機能もありませんが、コンパイルエラー発生時のエラーメッセージは標準C/C++に比べるとやはり分かりづらいです。

#versionディレクティブ

glslangValidatorで #version 400 - #version 450 を指定したシェーダーをコンパイルすると、下記のような警告が出ます。

Warning, version 450 is not yet complete; most version-specific features are present, but some are missing.

要するにまだGLSL 4.xすなわちOpenGL 4.xの相当機能を完全に実装しきれていないらしい。#version 330 であれば警告は出ません。しかしこれではOpenGL 4.xアプリケーションを満足に移植できない可能性があります。なんとも情けない……
OpenGL 4.0で標準化されたシェーダーサブルーチン(Direct3D 11でいう動的シェーダーリンク)など、本質的にVulkanの仕様と相反する機能であれば使うことができないのも分かりますが、Vulkanと互換性のあるGLSL機能までも実装しきれていないのはダメすぎかと。こんなていたらくではだれも移植を始めてくれないでしょ……

HLSL互換機能

ちなみにVulkan SDK 1.0.13.0付属のglslangValidatorでは、-D オプションを付けることで、なんとHLSLが使えるようになる模様。確かSDK 1.0.5.0では -D オプションはまだ存在していなかったように思われます。Vulkanが要求している入力はSPIR-V中間表現であり、GLSLはあくまでフロントエンドでしかないため、別にHLSLが使えても不思議ではありませんが、もし本当にHLSLが使えるのであれば、多くの機能面で劣るGLSLは要らない子ですね*1

たとえば下記のような最小のHLSLピクセルシェーダーは、普通にコンパイルが通ることを確認しました。Direct3D 10以降のシステム値セマンティクスも使えるようなので、おそらくDirect3D 11およびシェーダーモデル5.0相当の機能は使えるものと思われます。

float4 main() : SV_Target0
{
  return float4(0,0,0,0);
}

ただしソースファイルの拡張子は、GLSLと同様のルールに従う必要があります(*.vert, *.frag など)。
また、#include も使えない模様。結局ただの劣化移植です。本家である fxc.exe には及びません。

結論

総論としては、やはりVulkanはSDKやドライバーを含めてまだまだ未成熟な模様です。実績および開発のしやすさでは、Direct3D 11/12とHLSLに軍配が上がるのは火を見るより明らか。特にせっかくのオフラインシェーダーコンパイラーの実装が現時点で微妙すぎるので、OpenGLから移行する気がまったく起こりません。あとVulkan API自体がDirect3D 12以上にローレベルなので、プログラミングの難易度も相当に高いです。

とはいえ、OpenGLでないがしろにされてきたシェーダーのオフラインコンパイルや、マルチスレッド・マルチGPU対応などに真面目に取り組んでいるVulkan APIの姿勢というか設計思想自体は評価できるので、開発環境も含めて今後の発展と進化に期待したいところです。Vulkanを用いて、Direct3D 11やOpenGL 4に近いインターフェイスを持つ上位ラッパーレイヤーを構築してくれれば、Direct3D/OpenGLからの移植も進むんじゃないでしょうか。あとC++バインディングが欲しい……

*1:コンピュートシェーダーに関しては例外で、エクステンションまで含めると実はGLSLのほうがポテンシャルが高いです。

INIファイルでUnicodeを扱う

今更ですが今日はINIファイルのお話です。初めに断っておきますが、ぶっちゃけWindowsアプリケーションでレガシーなINIファイルを使うのはもうやめましょうWindowsアプリケーション設定の管理には、今後はレジストリXMLファイルなどを使うべきです。

そもそもINIファイルとは?

INIファイルは昔からWindowsアプリケーションの設定管理に使われている簡易テキストフォーマットで、テキストエディターでも簡単に閲覧・編集することができるうえにXMLと比べて構造がシンプルなため、いまだによく使われていますが、その歴史はWin16時代にまでさかのぼります。自分はWin16を使ったことはありませんが、Windowsアプリケーションを開発していると、どうしてもINIファイルのようにWin16時代から引きずられてきた負の遺産に直面せざるを得ないことが多々あります。特にWin9x時代あるいはそれ以前に開発された昔のアプリケーションをメンテナンスする場合には、互換性維持のため泣く泣くINIファイルを使い続けないといけないこともあります。

INIファイルでは、具体的には下記のようにレコードを1行ずつ記録していきます。セクションやキーは複数含むことができますが、階層構造は扱えません。キーと値をつなぐ「=」の前後の空白は無視されます。

[SectionName]
KeyName=Value
; This is a comment.

コメントはセミコロン「;」で始め、改行で終わります。セミコロンではなく「#」をコメント開始記号に使っている人がときどきいますが、マイクロソフト仕様のINIファイルでは通用しないので注意しましょう。詳しくはWikipediaなどを参照してください。

Win32 APIでINIファイルを扱う場合、下記のような関数を使います。

ほかにも、複数のレコードを一括して読み書きするGetPrivateProfileSection/WritePrivateProfileSectionや、バイナリデータを16進数表記文字列で扱うGetPrivateProfileStruct/WritePrivateProfileStructなどもありますが、たいていはXXXString関数で事足りるでしょう。これらのAPIは、一部の引数にNULLを指定すると挙動が変わるなどかなり高機能ですが、ややモノリシックな感は否めません。もし互換APIを自前で書こうとすると、存外にかなり大変だと思います。

なお、.NET FrameworkにはレガシーなINIファイルを扱うAPIは用意されていません。P/Invokeなどを利用して上記Win32 APIを使うか、自前でパーサーを書く必要があります。

INIファイルの欠点

INIファイルをWin32 APIで読み書きする場合、デフォルトではANSIマルチバイトエンコーディングが使われます。つまり、Windowsのシステムロケール設定(CP932/CP1252などのコードページ)に左右されることになります。例えば、日本語版WindowsではCP932 (Shift_JIS) が使われることになります。これは国際化対応が必要となるアプリケーションでは致命的な制約です。ANSIマルチバイトエンコーディングのテキストファイルでは、現在OSに設定されているシステムロケールに対応するANSIマルチバイト文字/文字列にマッピングできないようなUnicode文字/文字列を直接読み書きすることができないからです。セクション名・キー名はもちろん値の文字列もコメントもASCIIのみに限定する、あるいは読み書きの際に自前のエスケープやエンティティ参照・数値文字参照を駆使する、という思い切った運用で回避するという方法もありますが……

しかし、実はUTF-16のBOMを持つテキストファイをあらかじめ作成しておき、そのファイルに対して前述のWin32 APIでアクセスすると、UTF-16のINIファイルを直接扱うことができるようになります。つまり、INIファイルでまともにUnicode文字/文字列を扱えるようになります。どうしてもINIファイルフォーマットを使い続けなければならない場合、UTF-16のINIは選択肢として検討してもよいでしょう。

そのほか、INIファイルでUTF-8エンコーディングを使う方法も一応あるのですが、これは制約の多い禁じ手です。説明と比較のため、UTF-16/UTF-8/ANSIのINIファイルをそれぞれ読み書きするC#サンプルプログラムを下記にアップロードしていますが、ANSI同様にUTF-8を使うのは避けたほうがよいでしょう。Win32 APIではなく自前でINIのパーサーを書くというのであれば、別にUTF-8を使ってもかまいませんが……

UnicodeIniFileTest1.zip

INIファイルの代替

INIファイルはすでに述べているようにレガシーな非推奨技術です。今後いきなりWin32 APIによるサポートが終了するといったことは考えられませんが、少なくとも積極的なサポートや技術革新はされないことくらいは肝に銘じておきましょう。
INIファイルの代替としては、レジストリXMLファイルがあります。

レジストリ

Windowsレジストリは大きく分けてシステムレジストリとユーザーレジストリの2つがあり、前者はオペレーティングシステム全体に影響を与えるため、書き換えには管理者権限(管理者特権)が必要となりますが、後者はWindowsログインユーザーごとにエントリが作成されるため、書き換えに特権は不要です。レジストリの実体は巨大なバイナリデータベースファイルの集合なので、バイナリデータも直接読み書きしやすいのが特徴です。文字列もUnicodeベースで標準的に管理されるため、INIファイルのような制限はありません。ただ、エンドユーザーがレジストリを編集するためには、起動に管理者特権が必要なレジストリエディター(regedit.exe)を使用しないといけないし、バックアップやレストアもファイルの単純コピーというわけにはいかないので、INIファイルほど気軽に扱えるものではないことは確かです。また、レジストリに依存してしまうと、Windows以外のプラットフォームにアプリケーションを移植する際にも問題となります。

XMLファイル

データ記述言語のデファクトスタンダードともいえるのがXMLです。XMLは主にWebで用いられることが多い技術ですが、MSXML/XmlLiteや.NET Framework/WinRTのようなマイクロソフト公式ライブラリによって標準サポートされているため、デスクトップアプリやUWPアプリでも扱いやすくなっています。Unicodeテキストの扱いも標準化されていますし、テキストフォーマットなので人間が直接編集するのにも困りません。バックアップやレストアもファイルの単純コピーで実施できるため、エンドユーザーにとっても扱いやすいです。欠点としてはXML自体がかなり巨大な仕様であるため、単純なアプリケーション設定を管理する方法としてはややオーバースペック気味であること、また特にDOMパーサーが重めであることが挙げられます。

汎用スクリプト言語/データ記述言語

そのほかの代替手段としては、Lua/Squirrel/Python/IronPythonといった汎用スクリプト言語や、JSONのようなデータ記述言語の処理系をアプリケーションに組み込んでしまうという方法も挙げられます。組み込みにはそれなりに手間がかかりますが、これらの言語は柔軟性が高く、スクリプト中で可変長配列データや改行を含むRaw文字列などを扱いやすいため、場合によってはINIやXMLよりも設定ファイルフォーマットとして適していることがあります。

結論

繰り返しになりますが、INIファイルはもうやめましょう

あの、キョーマさん……?


【DimensionW】「あの、キョーマさん……?」イラスト/sygh[sai] [pixiv]

2016年に入ってもう2か月ほど経ちますが、ようやく今年初めての更新になります。「DimensionW」から、百合崎ミラちゃん。このくらいだったらR18タグ付ける必要はないかな……と。DimensionW面白いですね。OPはなんだコレ!?って感じなんですがEDと対になっていて、双方ともめちゃくちゃよく動きます。

今期は面白いアニメが多くて取捨選択に苦労しました。SFは基本観る人ですが、ゲームやライトノベルからアニメ化される作品よりもコミックからアニメ化される作品のほうが好きかもしれません。DimensionWは攻殻機動隊に通じるものがあり、情報化社会に一石を投じるテーマが主軸になっています。アニメ第4話と第5話は難解で、たぶん1回観ただけでは伏線を見逃してしまうと思います。そもそもお風呂シーン→異空間転送→タオル1枚で逃走→鎖で拘束、の流れがインパクトありすぎて話が頭に入ってこないのも一因なんですが……

ちなみにDimensionWではおそらくもうひとつの空間軸を百合崎博士が発見・Wと定義し、コイルによって空間をねじ曲げることで「可能性」という名のエネルギーを取り出すという設定なんだと思いますが、実は我々の世界はすでにX, Y, Zに時間軸tを含めた4次元空間であり、理系人間的には「第4の次元」というのは普通時間軸tを指します。実際「可能性」というのは時間にも深い関わりがあるので、SF的にもかなり興味深い設定だと思います。