2015年12月18日金曜日

「高度なレコード型」は要らない子

Lazarus や Delphi には、「Object 型(Object Types)」というものがあります。(参照: http://docwiki.embarcadero.com/RADStudio/Seattle/en/Classes_and_Objects#Object_Types )

とても便利な機能なのですが、あまりにも普通で抽象的すぎる名前を付けてしまったことを後悔しているのか、Delphi では非推奨の機能とされています。

しかし、何度でもいいますが Object 型は便利です。そのことに中の人も気付いたのでしょうか、Delphi では同じ機能が「高度なレコード型(Advanced Record)」として追加されました。(参照:http://docwiki.embarcadero.com/RADStudio/Seattle/en/Structured_Types#Records_.28advanced.29

FPC でも、ソースの先頭付近に、


{$modeswitch ADVANCEDRECORDS}
 

を追加すれば「高度なレコード型」を使用できます。
FPC では、「Object 型」は非推奨の機能ではありませんので、「高度なレコード型」の方がオプション扱いなのでしょう。
個人的には、「高度なレコード型」よりも「Object 型」を使ったほうがよい気がします。なぜなら、「高度なレコード型」は「承継(inherited)」がサポートされていないなど、どちらかというと「Object 型」の劣化版といえそうだからです。

「高度なレコード型」や「Object 型」の便利なところは、「Class型(Class Types)」とは異なり、宣言するだけで実体が作成され、スコープから抜けると実体が破棄されるところです。


type
  TMyStruct = object
  public
    item: integer;
  end;

var
   my: TMyStruct;
begin
  my.item := 100;
  ShowMessage(IntToStr(my.item));
end;

上で紹介済みの http://docwiki.embarcadero.com/RADStudio/Seattle/en/Classes_and_Objects#Object_Types では、「Object 型」は New と Dispose で生成と破棄ができると書いてあります。生成と破棄のタイミングを管理したいこともたしかに多いですが、それなら「Class型」を使えば十分ですから、「Object 型」で New と Disposeを使用するメリットはないでしょう。

ところで、「高度なレコード型」や「Object 型」で少々混乱しやすいのは、実体の作成とコンストラクタの関係です。

type
  TMyClass = class
  public
    item: integer;
    constructor Create(aItem: integer);
  end;

  TMyStruct = object
  public
    item: integer;
    constructor Create(aItem: integer);
  end; 

  :

var
  myclass: TMyClass;
  myobject: TMyStruct;
begin
  myclass:=TMyClass.Create(100);
  mystruct:=TMyStruct.Create(100);
  :
  myclass.Free;
end;

「Class型」の場合は、コンストラクタにより実体が作成されるのでイメージをつかみやすいですが、「Object 型」は var で宣言するだけで実体が作成されるのでコンストラクタという概念がいまいちピンときません。
個人的には、「Object 型」におけるコンストラクタは単なる「クラスメソッド(Class Method)」に過ぎないので、コンストラクタは使わず「クラスメソッド」を使えば十分だと考えています。

type
  TMyStruct = object  public
    item: integer;
    class procedure Create(aItem: integer);
  end; 
  :

var
  myobject: TMyStruct;
begin
  mystruct:=TMyStruct.Create(100);   :
end;

おそらく、「Object 型」におけるコンストラクタやデストラクタは、既述の New や Dispose で真価を発揮するものだと思います。そして既述のように、New や Dispose を使うくらいなら「Class型」を使った方がよいですから、「Object 型」ではコンストラクタやデストラクタの出番はないということになります。

・・・そうとすると、 「高度なレコード型」でもコンストラクタが使えるみたいなのですが、おそらくその出番はないでしょう。

2015年12月11日金曜日

TRect のお話

Lazarus や Delphi では矩形領域を現す TRect という便利な型とそれを操作するための便利な関数群が用意されています。
TRect は、上下左右の座標で定義されますが、標準では、下と右は+1してあげる必要があります。例えば、画面上の左上隅の1ドットを TRect で現すと Left = 0, Top = 0, Right = 1, Bottom = 1 となります。 もちろん、自己のプログラムの中で1ドットの矩形は Left = Right, Top = Bottom とするんだ!とすることは自由なわけですが、少なくとも Lazarus や Delphi の標準ルーチンはそのように処理しません。例えば 、矩形が空かどうかを調べる IsRectEmpty 関数は次のようになっています。

function IsRectEmpty(const Rect : TRect) : Boolean;
begin
  IsRectEmpty:=(Rect.Right<=Rect.Left) or (Rect.Bottom<=Rect.Top);
end;

左右あるいは上下の座標が同じなら空と判定してますね。

2015年11月5日木曜日

Lua でテーブルの内容を知りたいときは次のようなコードを使用します。

for k, v in pairs(table) do
  print(k .. " = " .. v)
end


pairs関数により、k にはキーが、vにはそのキーの値が返されます。

すべてのグローバル変数は _G というテーブルに格納されています。よって、

for k, v in pairs(_G) do
  print(k .. " = " .. v)
end


とすると全てのグローバル変数の情報を知ることができます。Lua では関数も全て変数として扱われますので、FlashAir などのような Lua を使える機器の隠しコマンドを発見するのに便利です。

2015年11月4日水曜日

UTF8文字列とUTF16文字列の相互変換

FPC 2.x で、UTF8文字列とUTF16文字列を相互に変換するには、次のように、UTF8Encode 関数、UTF8Decode 関数を使うのが一般的でした。










ソースファイルのコードページが UTF8 (デフォルト)の場合:

var
  s: string;
  ws: widestring;
begin
  s := 'あいうえお';
  ws := UTF8Decode(s);
  s := UTF8Encode(ws);
end;

FPC 2.x では、string 型の変数に ANSI 文字列が格納されているのか、それとも UTF8 文字列が格納されているのかを管理するのはプログラマのみの責任でした。
FPC 3.0 では最新の Delphi と同じく、 string 型にコードページという概念が追加されましたが、FPC 3.0 でも、string 型のデフォルトは UTF8 ですので、UTF8Encode 関数、UTF8Decode 関数を使用した上記コードは正しく動作します。もっとも、FPC 3.0 では、コードページという概念の追加により FPC 側が string 型の変数に何のコードページの文字列が格納されているのかを知ることができるようになったことから、コードページが異なる文字列の代入時に FPC が文字コードの変換を自動的に行うようになりました。なお、自動変換なんて余計なお世話だよ、という方は、 RawByteString 型を使用すれば自動変換を回避できます。

よって、FPC 3.0 では上記の例は次のように書くことができます。
なお、FPC 3.0 では widestring 型と unicodestring 型が厳密には異なるものとされるので、特に拘らない場合は unicodestring 型を使うのが無難です。ユニコード=16ビットではないので疑問の残るネーミングではありますが、Delphi のメーカーがそのようにネーミングしたので仕方ありません。


var
  s: string;
  s16: unicodestring;
begin
  s := 'あいうえお';
  s16 := unicodestring(s);
  s := string(s16);
end;

Decode や Encode という、どっちがどっちかよくわからない命名に悩まなくてよくなるだけでなく、ソースファイルのコードページが UTF8 でない場合にも対応できるようになります。
ちなみに、ソースファイルのコードページは、IDE でソースファイルを右クリックして、File Settings -> Encodeing で変更できます。

2015年10月29日木曜日

ユニコード文字列の取り扱い

Lazarusの標準文字コードはUTF8です。したがって、森鷗外の「鷗」のように、ユニコードにはあるがシフトJISにはない文字もあっさり使用できます。例えば、Label.Caption := '森鷗外'; のように。
そして、Lazarus には Delphi と同じく、ユニコード文字列を取り扱うためのルーチンが豊富に用意されています。したがって、自分でコーディングしてユニコード文字列を処理する場面では困ることはないと思います。

問題は、LCLやRTLなどにある既存のルーチンでのユニコード文字列の取り扱いです。代表的なものはファイルのパスで、例えば 多くのオブジェクトに搭載されている LoadFromFile メソッドには、パスをシフトJIS(ANSI)で渡さなければいけません。 したがって、 LoadFromFile(UTF8ToSys(filename)) のようにして、UTF8をシフトJISに変換して渡す必要があります。当然、ファイル名に、"森鷗外.txt"のようなユニコードにはあるがシフトJISにはない文字が含まれていた場合はエラーになります。これは、内部で Windows API をコールする際に、シフトJISしか使えないAPI、いわゆるA系のAPIを使っていることが主たる原因です。
この問題を解決するため、lazutf8classes や FileUtil ユニットなどに、ユニコード文字列に対応したルーチンが準備されています。その多くは、ParamStrUTF8やFileExistsUTF8、TFileStreamUTF8、TStringListUTF8 など、標準名+"UTF8"という名前がつけられています。これらが Windows API を使用する場合は、ユニコード文字列に対応したいわゆるW系のAPIを呼び出してくれます。
しかし、これで問題が全て解決するわけではありません。先程の例である LoadFromFile メソッドのほとんどでは内部でTFileStreamUT8ではなくTFileStreamを使用しているため、結局ユニコードのパスは使用できません。また、UTF8対応の関数を使う必要があるかという判断には、その関数がどういう処理をするのか、シフトJISとUTF8の違いはなんなのか、という知識が求められることになります。

以上は Lazarus 1.4 でのお話です。 Lazarus 1.4 は、FPC 2.6 をコンパイラとして使用するのですが、FPC 2.6 の基本ルーチンがANSIしか処理できないため上記のようになってしまっています。FPCに依存せずに Lazarus側が全て自前でユニコード処理をしてしまえばよいわけですが現実的ではないので、lazutf8classes や FileUtil ユニットなど最低限のものを苦肉の策としてLazarus側で準備しているわけです。
これに対し、現在RC2がリリースされている FPC 3.0 は、ユニコード標準対応を謳っています。誤解をおそれずに簡単にいってしまえば、多くの基本ルーチンで、引数がANSI文字列型の場合はA系APIを、ユニコード文字列型の場合はW系APIを適切にコールしてくれるようになります。これによって、上記の問題は完全に解決されます。FPC 3.0がLazarusの標準コンパイラになるのはおそらく Lazarus 2.0 からでしょう。待てない方は最新truncで試すことができます。

FPC 2.6 用に作成した自前のソースを FPC 3.0 でビルドすると、UTF8ToSys関数、 lazutf8classes や FileUtil ユニットなどのUTF8対応ルーチンを使用している箇所でWarningが出るので修正すべき場所がすぐ分かります。UTF8ToSys関数はもはや不要になりますし、TFileStreamUTF8などはUTF8を取ってTFileStreamを使えば良いことになります。


2015年10月28日水曜日

TXmlPropStorageとTIniPropStorageは要らない子

misc タブに TXmlPropStorage と TIniPropStorage というコンポーネントがある。
TFormのSessionProperties で指定したプロパティ(ちなみにフォームのプロパティだけではなくフォーム上にある子コントロールのプロパティも指定できる)の値をフォームクローズ時にファイルに保存し、次回フォーム作成時にその値をファイルから復元してくれるというコンポーネントである。
最初は、便利なコンポーネントがあって嬉しいな、という気持ちになるが、いざアプリに使おうとなると、余程の手抜きアプリでないかぎり使えないものであることが分かる。エラー処理が皆無なのである。
もちろん、ソースを追ってコンポーネントの仕組みなどを調べて、エラー処理をうまく追加することは可能かもしれないが、そんな手間をかけるくらいなら、TStrings クラスなどを使って、フォーム作成時にプロパティの値をファイルに保存し、フォームクローズ時にファイルから復元するコードを書いたほうが早い。TStrings クラスの便利さと、Lazarus のイベント処理の容易さが産んだ悲劇といえるかもしれない。