AB開発日記

朝っぱらからアスワドを聞きながら作業に勤しんでおります。”Shy Guy” が一押し。なんか、休日モードになってしまいそう（いけない いけない）

Aswad – Shy Guy

さて、本日は時間を有効的に使いながら、CP2の不具合待ちとガベコレ調査を引き続き行っていたいと思います。

何度も話に出てきている通り、開発者向けにコッソリとリリースさせてもらっているAB5β4ではString型への添え字アクセスへの対応が微妙です（新String型への移行を全く行っていないAB5CP1では問題ないです）。例えば、

Dim s As String
Dim c As Char
s="test"
c=s[0]

このような記述は可能なのですが、下記のコードは未だエラーとなってしまいます。

Dim s As String
s="test"
s[0]=Asc("a")

本来であれば、文字列sの内容が “aest” に変化してほしいところ。AB5β4では、

s[0]=Asc(“a”)

の表記を

s.Chars[0]=Asc(“a”)

というふうにして一時的に凌いでもらうようお願いしているところです。しかしながら、AB4用に開発したソースコードにおいて、このようなStringアクセスが生じている部分をすべて書き換えてくださいなというお願いをするのは非常に酷な話ですし、AB5のうたい文句である下位互換性の信憑性を揺るがす問題であることも事実です。

そこで、[]演算子のオーバーロードロジックにもう一段階ひねりを加え、添え字アクセスによる代入も可能にしようと考えています。まず思い浮かぶのがC#で採用されるインデクサ。例えば、下記のようなコードでオブジェクトへの添え字アクセス（読み書き）を可能にしてくれます。

public class C
{
  int[] values = { 1, 2, 3 };
  
  public int this[int index]  // インデクサの宣言．
  {
    get { return values[index]; }
    set { values[index] = value; }
  }
}

public class TestIndexer
{
  public static void Main()
  {
    C c = new C();
    
    c[1] = 1;  // インデクサを使用した書き込み．
    Console.WriteLine(c[1]);  // インデクサを使用した読み込み．
  }
}

“public int this[int index]” という部分のindexの型をstringなどに書き換えれば、連想配列のような機能も実現可能とのこと。get/setアクセサを指定して云々というのがインデクサの仕様のようですが、このget/setアクセサに相当する演算子オーバーロード機能を盛り込むことで、完全にインデクサの仕様をカバーできるような気がします。例えば、先ほどのコードを次バージョンのABを想定して書き直すと、下記のような表現になります。

Class C
    values[3] As Long

    Sub C()
        values[0]=1
        values[1]=2
        values[2]=3
    End Sub

    'getアクセサ相当
    Function Operator[] (index As Long) As Long
        Return values[index]
    End Function

    'setアクセサ相当
    Sub Operator[]= (index As Long, value As Long)
        values[index]=value
    End Sub
End Class

Dim pobj As C()
pobj[1]=1
Print pobj[1]

当然ながら、Operator / Operator= のパラメータであるindexの型を書き換えることで、連想配列のように扱うことも可能になります。こうなってくると、オーバーロードチックに記述するのか、get/setアクセサを指定して記述するのかの違いなだけで、事実上はインデクサの機能と同等になるのではないかと考えられます。

どちらが直感的であるのかは使い手によって意見が食い違うところでしょう。私もC#を利用して積極的にインデクサという機能を使い込んだことがありませんので、両者が本当に同一の機能を提供するものなのかどうか、厳密にはわかりませんが、特段問題がなければ[]=演算子のオーバーロードを導入してそれをABのインデクサとして扱いたい考えです。

まずは調査から。一般的に、GCと言うとJavaや.NET言語で採用されている印象がありますね。確保されたメモリを自動的に解放してくれるというプログラマにとっては非常にありがたい機能、強いて言えば一度でもコレに慣れてしまうと、C言語のmalloc/freeには戻れないという話さえも耳にします（私の周りでもこの状態に当てはまる方が何名かいます）。

GCの実装は、言語が提供するか、ライブラリが提供するかに分別されます。JavaはVMが担当し、.NETはCLRが担当します（ガッチリと、言語が提供しています）。逆に、C/C++でGCを活用したい場合は、BoehmGCやboost::shared_ptrなど、外部ライブラリを取り込むことで実現できたりもします。これらの問題は手法ですので、将来的にABはこの方法でいきますということは、現時点では言及できません。

そして、GCにはいくつかの種類があるようです。それぞれのメリット・デメリットも様々。しかしながら、昨今のオブジェクト指向言語に一番適した手法が見いだされてきているようです。

• 参照カウンタ方式 … オブジェクトポインタのコピーと破棄を監視し、参照カウンタの増減を行う。カウンタが0になったら自動的にdeleteしてあげる。
• Mark & Sweep … メモリ使用量が増えるなどの一定条件が整った場合にGCを発動させる方式。スタティック領域とスタック領域（即ち、グローバル変数とローカル変数すべて）をスレッド毎にチェックし、使われていないオブジェクトポインタがあればdeleteしてあげる。
• 世代型GC … Mark & Sweep方式を新世代、旧世代の2つの世代にわけて効率的に管理する手法。Javaが世代型GCの採用を行っているのは有名な話。

ネイティブコンパイラとして実装しやすいのは、まずは参照カウンタでしょうか。しかし、参照カウンタ方式はGCの負荷が分散されるメリットの反面、循環参照への未対応や処理速度の鈍化が慢性的な問題として浮上してしまうという非常に大きなデメリットも存在しています。これらの問題から、最近の言語が積極的に参照カウンタ方式のGCモドキを採用するという傾向は薄いようです。

私の頭の中でも、明確な実装手法が整理されていないのですが、どうやらMark & Sweepの手法をベースにした、保守的GCの機構を言語ベースで提供するというのが一番良い方法なのかもしれません。欲を言えば、優秀な仮想マシンが提供するGC機能をコンパイラが提供する一機能として実現していきたいものです。

どちらにせよ、ABはNew 〜 Deleteでオブジェクトの確保・破棄を行うのを一般的な手法として提示しているので、それらを根本から覆すことは避けようと思います。将来的に、GCNew、GC_mallocなどの機構を取り入れられれば良いかな〜と思っています。

Wikipedia – ガベージコレクション:

http://ja.wikipedia.org/wiki/%E3%82%AC%E3%83%99%E3%83%BC%E3%82%B8%E3%82%B3%E3%83%AC%E3%82%AF%E3%82%B7%E3%83%A7%E3%83%B3

チューニングのためのJavaVM講座（後編）〜ガベージコレクタの仕組みを理解する〜:

http://www.atmarkit.co.jp/fjava/rensai3/javavm02/javavm02_1.html

皆さんは、文字列操作に強い言語といったら、何を思い浮かべますか？

私は正規表現を標準完備し、変数と文字列の親和性の高いPerl、PHP、Rubyなどを思い浮かべます。これらの言語はHTML、JavaScriptなどの二次的な言語（または自身の言語コード）の生成が要求されることから、文字列操作に特化した設計がなされているといっても過言ではありません。

どちらかというと、システム記述的な要素が高いC/C++、VB、C#などの言語（もちろんABもこの部類）は文字列を一つのパラメータとして重要視する傾向が高く、リテラル文字列との親和性の高さは二の次になっています。

C= C= C= C=┌( ・_・)┘→→→

開発者向けバージョンのAB5β4では、新しいString型が従来コードとの互換性を取り戻してきました。これを完全なものにすれば、AB4→AB5へ移行するユーザーの皆様に対して、下位互換という視点から貢献できそうです。更には、String型が列記として一つのクラスとして表現されるので、かなり細かく文字列操作メソッドを用意していくことが可能になります。

こんなタイミングですので、新String型の導入と同時に、ヒアドキュメントを扱えるようにリテラル文字列の仕様も企んでいる最中であったりもします・・・f(^^;;;

たかがString型、されどString型ということでコンパイラの再設計をしているところですが、AB5でどこまで言語仕様を落とし込むかが問題です。

確かに、演算子のオーバーロードを用いれば、String型をクラスモジュールとして実装することは可能です。今現在、私の手元にあるテストコードでは、ABコンパイラと演算子オーバーロードを活用したStringクラスが正常に稼動しています。もちろん、Print命令やInput命令も従来通り利用できますし、メモリ管理の仕様がオープンになることでString型特有のバグも減少の方向に進むかと思います。

しかし、AB5ではただ単に演算子のオーバーロードでString型の一件を済ませてしまうのは、ちょっともったいない感じもします。というのも、C#、VBなどを見習うと、C/C++やABにはない下記のような機能を持ち合わせ、オーバーロードなどという “ウラ技” 的な発想ではなく、クラスモジュールが提供する正統派な機能として、これらの問題を解消しています。

• インデクサ … オブジェクトに対して添え字アクセスが可能
• プロパティ … メンバと同様のアクセス方法で、任意の処理を実行可能

オーバーロードを悪く言うつもりはありませんが、手続き型の言語仕様の側面から見て例外的な手法を提供するのであれば、こういうやり方が正しいのかもしれません。

さてさて、String型がある程度動くようになったところで、開発者向けにβ版のリリースをしていこうと思います。今回のβ版は、従来のString型を一掃するというバグバグしい内容となっているので、一般公開は避けさせていただきます。

コミュニティにて、ゲストユーザーの皆様に確認コードをお願いする形にしたにもかかわらず、スパム投稿がいっこうに止みません。

日常的には、コミュニティを時々除いて良からぬ記事を削除してまわるのですが、土日に家をあけて、帰ってきた瞬間にコミュニティを開くと、とんでもないことになっていたりします。

それらのスパム投稿はすべて英語メッセージ。そこで今回は、ひらがなを含まないメッセージを弾くようなフィルタを、ゲストユーザーに限る形で導入させていただきました。この手法は私としても不本意ではありますが、日本語を使ったコミュニティまで崩壊しかねませんので、やむなくの対策でございます。

迷惑メールフィルタみたいなある程度のクオリティを保ったプラグイン、phpBBにもないものでしょうか？？

ひょんなことから、清水エスパルス vs FC東京の試合会場（日本平スタジアム）に出向きました。

試合のハーフタイム中にFUNKY MONKEY BABYSの生ライブをやっていたので聞き入ってみると、意外とイイ感じの曲じゃないですか。「ALWAYS」が入ってるCD、買ってみようかな〜☆

FUNKY MONKEY BABYS – ALWAYS

今、私のPCの中にあるABを構成しているソースコードでは、従来のString型の前面撤廃がなされています。その代わりに、AB5CP1のライブラリに含まれている開発途中のCStringがそれに取って代わる存在になりつつあります。

しかし、現状のCStringを従来のString型へ移行するのは、至難の業。発想としては、+演算子などを有効にして文字列演算を行えるようにするということで良いのですが、パラメータの引渡し、ローカル領域内での確保と解放のタイミング、演算過程で生じる一時オブジェクト保存領域の制御など、実はいままでコンパイラが行ってきた部分をコンパイラ自信が汎用化し、それらの具体的な処理の流れをStringクラスモジュールライブラリとして定義していかなければなりません。

それにしても、演算子のオーバーロードの連続となるソースコードに対するコンパイラのデバッグは辛いものがあります。何階層にもなって呼ばれるオーバーロード解決用のモジュール、その中を一つ一つチェックするのですが、出てくる単語は “+” とか “=” ばかり…

現状ですと、実用的なStringクラスモジュールを稼動させられるのかどうか、ちょっと自信がありませんが、なんとかこの壁は乗り越えたいところです。

まぁ、String型そのものは特段珍しい存在ではありませんが、このような些細な仕様がその言語で実現できるコーディングレベルを左右するものだと感じます。

コンパイラレベルで実装していた従来のString型は、絶対的な存在だったのかもしれませんが、それらをクラスモジュールとして持たせることで無限の拡張性が生まれるのです（なんと素晴らしいことだ！！）。

「火曜22:00〜 結婚できない男」で出てくる金田のホームページって、ネット上に存在してるんですね。ちょっとした発見でした☆

金田のホームページ（更新されてるかもっ！？）

http://www.ktv.co.jp/shinsuke/kaneda/index.html

スケジュールが合わないときには録画をしてまで見たいドラマ、ホント久しぶりです。

AB5CP1で未完成の機能の一つに「ブレークポイントの設定/解除」があったと思うのですが、本日、その機能のおおよその部分が完成致しました。

これでDebugステートメントの嵐から抜け出すことができます。「いざデバッグコンパイルしたものをエクスプローラから直接実行してみたら、Debugステートメントのおかげで強制終了してしまう（←これは仕様上、致し方ないのです…）」、こんな悩みも解消されることでしょう。

今、設置されたブレークポイントをプロジェクト保存時に一緒に保存させようかどうか悩んでいるところです。オプション項目にすれば間違いないでしょうが・・・