一昨日から一泊で、沼津で行われた第3回TOPPERS開発者会議に参加しました。主な議題は、SMPカーネル（対称型マルチプロセッサ向けカーネル）、標準割り込み処理モデル、改定ロードマップ、そしてASPカーネルでした。

例によってあまり具体的なことは書けないのですが、TOPPERSプロジェクトが扱っているカーネルも種類が増えてきたので、従来のカーネルとの互換性がいろいろと問題になるというか、しがらみになってきている印象を受けました。

最近の技術検討の多くは、一般のユーザーからみればほとんど興味のないような重箱の隅的なものも多いのですが、完成度を上げていく過程ではこうした作業は不可欠だと思います。特に、（カーネル間や処理系間の）ポータビリティに関する議論は非常に細かく、（特定環境で動けばよい）普通のアプリケーション開発ではあり得ないような話をしていたりします。

他には、最近よく話題になるのはgoto論争です。goto論争自体は非常に古いテーマですが、今日に至るまでこれといった結論は出ていません。この話題は、よく宗教論争といわれますが、goto肯定派と否定派の溝はなかなか埋まらないようです。

ところで、TOPPERSプロジェクトの技術会議に集まる多くの方々はgoto肯定派のようで、この話題が出た場合でも、肯定派と否定派の対立のような構図はなく、いかにしてgotoを容認させるかといった話になりがちです。

私もgotoは躊躇なく使う方ですが、不特定多数を相手にしているとgotoを禁止したくなる気持ちもわからなくもありません。つまり、自分はgotoを使えても、周りにgotoを正しく使いこなせない同僚が何十人もいると、個々に正当性を検証するよりは全面的に禁止にしたいのでしょう。逆に、gotoを使うべきところで使わないと、可読性が下がりますし、コードの複雑さも増します。gotoの使い方が分かっている者にとって、gotoを使えないのは大きな足かせになるわけです。

以前にも書いたように、私は宗教論争は必ずしも嫌いではありませんが、gotoに関しては、立場や状況が異なるもの同士が、自分の立場や状況にあった方針を世間一般に対して強要しようとしても、やはり無理がありますね。

goto論争の話が大半を占めてしまいましたが、（非会員の目に触れる）ここで書ける内容が限られているのでそうなっただけで、2日もかけてgoto論争をやっていたわけではないので誤解のないようにお願いします。

日本時間では今日から、Borland Developer Studio 2006の切り売り的存在であるTurbo Explorerがダウンロードできるようになっています。切り売りですので、実際には4種類の製品から構成されています。すなわち、Turbo Delphi、Turbo C++、Turbo Delphi for .NET、そしてTurbo C#です。

上記のように、言語別に4種類あるほか、それぞれにExplorer EditionとProfessional Editionの2種類があります。Editionの違いは、Explorerの方は無償でダウンロードできる代わりに、自分で作ったコンポーネントやサードパーティ製のコンポーネントを使うためにIDEを拡張したりカスタマイズできないことと、サードパーティ製のコンポーネントが含まれていないことのようです。

私自身、（C++ Builder Xではない）C++ BuilderやDelphiは長い間触っていなかったので、IDEを拡張＆カスタマイズできなかった場合に、コンポーネントを使うのがどれぐらい面倒になるのかピンと来ませんが、ソースコードを直接触るつもりなら十分使えるのではないかと予想しています。

ところで、ライセンス上の問題なのか、設計上の問題なのか分かりませんが、なぜかTurbo Explorerの複数の製品を同時にインストールすることができないようです。そのために、今回はTurbo C++のみをインストールしてみたわけです。

なお、ざっとライセンスを見た感じでは、Delphi 6のときのように商用や業務での利用ができないということはなさそうです。今後、主にフリーウェアの開発の舞台で、MicrosoftのVisual C++ 2005 Express Editionが事実上.NET開発にしか使えないこともあり、Win32ネイティブの開発にはTurbo C++を使うといった棲み分けができてくるかもしれませんね。

せっかくなので、C++処理系（主にライブラリ）についてもざっと見てみました。bcc32のバージョンは、5.82と表示されますが、実際には5.8.2のようで、Borland Developer Studio 2006のものと同じです。標準C++ライブラリは、今回はVisual C++と同じDinkumware製のものを採用しているようで、バージョンアップのたびにころころ（RogueWave → STLport → Dinkumware）変わるのはどうもいただけません。

バージョンアップしたときに泣きを見ないようにするには、各実装の独自仕様に依存しないようにするか、いっそ常にSTLportの最新版をインストールするなどの対策が必要になりそうです。また、Dinkumware製のライブラリということで、C99やTR1対応を期待したのですが、残念ながらそこまでは無理だったようです。

今後、もう少し使ってみて、また使用感などをレポートできたらと思います。

ここのところ息抜きを兼ねて、C++ Standards Committee's Library Technical Report (TR1)に対応したライブラリを作り始めています。といっても、Boost C++ LibrariesやらGSLやらを寄せ集めて、体裁だけを整えた「いんちき」ライブラリです。実態にふさわしいように、TR1fakeという名前を付けてみました。

寄せ集めなのですぐにできるだろうと思っていたのですが、いざ着手してみると、思った以上に作業量が多いことに気付きました。特にC99互換のライブラリがかなり多く、ここでやっていることとほとんど同じことの繰返しなので、いきなりモチベーションが下がっています。

結局、C99の部分もほとんどは寄せ集めにすることにしました。つまり、処理系がC99に対応していればそれを利用し、なければリンクエラー止む無しという無責任な対応を取ることにしました。GSLを使った数学ライブラリも、GPLに汚染されるのが嫌ならリンクしない（結果として使えない）で済ませることになるので、大差ないかなと勝手に決めています。

TR1は「Effective C++ 第3版」でも紹介されているだけあって、実際に処理系がサポートするようになるまでのつなぎとして、TR1fakeが完成すればそれなりに利用価値があるのかなと考えています。もし、できがよければ公開しますが、あまり期待はしないでください。

公開以来、ご好評いただいておりますDoxygen翻訳サイトですが、このたび、皆さんとより積極的に情報交換できる場として、FreeMLのサービスを利用したメーリングリストを設置することにしました。

ご興味のある方は下記よりご参加いただけます。なお、実際の活動開始は来週辺りからになると思います（参加者の集まり次第です）。

Doxygenメーリングリスト に入ろう！ [利用規約]
	メールアドレス

TOPPERSプロジェクトの中で、会費をお金ではなく身体で払うべき立場（特別会員）である私は、月に1回、コンポーネント仕様WGの打ち合わせのために名古屋にいっています。先週の火曜日もそうだったのですが、たまにはその話もしてみたいと思います。

まず "TECS" という名称についてですが、TOPPERS Embedded Component System を略したものです。TECSが目指しているものとして、公には次の3点が挙げられています。

1. 大規模アプリを効率よく開発できること
2. ソフトウェア部品の流通性がよくなること
3. 分散処理フレームワークが実現されること

これだけではあまりにも漠然としていて、何のことやらさっぱり分かりませんね。というわけで、私なりに勝手な解釈を付け加えてみたいと思います。

まず、1.の「大規模アプリを効率よく開発できること」についてです。最近では組み込み開発も大規模になってきていて、当然開発に携わる人数も増えてきています。そうなってくると、アプリケーションを部品に分割して、開発境界をはっきりさせる必要が出てくるわけです。TECSでは、コンポーネント図や記述言語を定義することで、そうした部品化がしやすくなります。

次に、2.の「ソフトウェア部品の流通性がよくなること」についてです。μITRONをはじめとしたリアルタイムOSでは、ソフトウェア部品の不足が問題になることがよくあります。TCP/IPプロトコルやファイルシステムなどは割りとあるのですが、GUIツールキットやUSBとなってくると、かなり選択肢が狭くなってきます。しかも、A社のファイルシステムとB社のGUIツールキットでは、相性がいまいちで組み合わせて使いにくかったりもします。そこで、TECSという標準化された枠組みが必要になるわけです。

最後に、3.の「分散処理フレームワークが実現されること」についてです。コンポーネント間の結合は、最も単純な関数呼び出しによるものから、タスク間通信によるもの、シリアル通信やTCP/IPなどによるもの、更には専用ハードウェアの制御を伴うものまでさまざまです。タスク間通信といっても、普通のスレッド形式のものもあれば、メモリ保護カーネルやマルチプロセッサ・カーネルのようなメモリ空間を共有できないものではプロセス間通信に近くなります。汎用の分散フレームワークでは、最も汎用性を高めるために最も重いものにあわせて動的に処理しますが、TECSでは静的な最適化を行うことで、関数呼び出しで済むものは関数呼び出しにというように、最も適した接続方法を適用することができます。

とまあ、こんな風に書いてもよく分かりませんね。興味のある方は一度WGに参加してみてください。会員しか参加できませんが、準会員であれば入会金・年会費とも5,000円でOKのようです。
WGも最初のうちは大勢で打ち合わせをしていたのですが、現在では大体6,7名程度になってしまいました。来るもの拒まず、去るもの追わずという言葉がぴったりな雰囲気です。万年マンパワー不足ですので、冷やかしでもよいので参加していただくと助かります。