＞FrontPage＞Roast+
※今はもうこっちに移転：
http://sourceforge.jp/projects/roast/
ごーまだけでも香ばしいのに～♪コーンだけでも香ばしいのに～♪
ごまっとコーンの香ばしｺｵｵｵｵｵｵｵｵｵｵｵｵｵｵｵﾝ！！
はい。ミューです。（何
「枯れた技術」と言う言葉があります。
私も最初は「古くなって誰からも使われなくなったヨボヨボ爺さんのような今更の技術」の事を言っているのかと思いました。でもそういう事ではありません。
「枯れた技術」の「枯れた」は、バグや問題と言ったものを泉から湧き出る水に例え、
それらが枯れた、即ち出尽くして、もうこれ以上バグや問題が殆ど出ないであろう技術を指します。
一般的に多くの場合、ハードウェアやソフトウェアに対し使います。
例えば古くからあるICチップや、ネットワーク機器等のハードウェア。
ソフトウェアで言えば、Apacheなんかは古くから存在していて、今では多くの企業までもが標準的に採用するHTTPサーバーとなっています。
さて。私がふと思ったのは、ソースコードにおいても、「枯れた技術」と言うのは存在するのではないか？と言う事。
例えば、SAFE_DELETE、SAFE_RELEASEと言った定番マクロが存在します。
バッファオーバーランを抑止する方法としてstrcpyの代わりにstrncpyを使ったり、strcatの代わりにstrncatを使ったりします。
しかしそれらは共通のライブラリとして誰かが作った訳ではなく、各自が、ないし会社のソースコードとして、
集約される事無く、ただ点々と抱え込まれているだけなのです。
この為何が起こるのかと言えば、例えばCを初めて触った人間はSAFE_DELETEなんて知らないし、SAFE_RELEASEなんかも知らない。
なので普通にNULLチェックもせずに「delete hoge;」とか「hoge->Release()」等と書いてしまうし、
strcpyやstrcatも普通に使ってしまう。仮に知ったとしても、例えば「strncpy(to,from,strlen(from));」のような誤った書き方をしてしまったり、
共通関数化やマクロ定義化せずに「strncpy(to,from,sizeof(to)-1);」と直書きしてしまったり、結果、-1をつけ忘れたり、事前にmemset()していなかったり・・・と言う事が発生してしまうと思うのです。
そして現に、それらの問題はこのC言語と言うものが開発されて以来25年近くもの間、延々と繰り返されて来たと思うのです。
その結果起きた問題は、単なる何百、何千万と言う数のプログラマの無駄な労力に留まっていなかったと考えています。
C++と言う新たなCの拡張言語が1980年代前半に登場したものの、相も変わらずこれらの問題は解決されず、
これらの貧弱な標準機構の問題に飽き飽きし、絶望したプログラマはJavaを開発しました。
1995年の話です。その後、Javaの成功からさまざまなインタプリタ言語、LLが誕生しました。
Perl──はJavaの登場以前からありましたね──、Ruby、PHP、Python、そういや.NET系もか・・・今や世界はLL一色です。
その間C/C++プログラマは何をしていたかと言えば、指をくわえてじっとそれを眺めていた・・・どころか、どんどんそれら、RubyやPython、C#、そして一番大きな流れはJavaへと、言語を乗り換えて行きました。
それは本当によかったのか？それで本当に正しかったのか？C/C++はもはや古い時代の、20世紀の化石なのでしょうか・・・？
私はそんな風には思っていません。確かにCPUのパフォーマンスは格段に向上し、使う事の許されるメモリ領域も飛躍的に大きくなりました。
しかし、プログラムと言うものはそれと同じくらいのスピード・・・か、それ以上に高度、複雑化している、と、私は見ています。
Pythonは早くて人気だそうですね。JavaのJITコンパイラは今や内容によってはCに匹敵する速度だそうです。
どう思いますか？この実情を。結局プログラマはなんだかんだ言いつつも実行速度を気にし、その呪縛からは逃れられないのです。
私はいずれ近い将来、ネイティブコンパイルへの回帰、パラダイムシフトが起こるのではないかと踏んでいます。
それがJavaのJITコンパイラの最終形として、高度に最適化されたバイナリコードを実行時に生成するようになるのか、
はたまた、RubyやPythonが登場してきたように、新たな言語が作られるのかどうか分かりませんが・・・。
ただ、その回帰が行われた際、その回帰先としてのC/C++が用意出来れば───。
そう考えているのです。
そのためには、枯れた技術の集約が不可欠です。
今のままでは、多くのプログラマはC/C++に回帰する事無く、
JavaのJITを改良したり、新たな言語を起こす事になるでしょう。
「Roast」と言う名前。勘のいい方は何やら匂うものを感じたかも知れません。
そうです。かの「Boost」から来ているものがあります。
Boostは非常に優れたライブラリです。
拡張的なコンテナ、shared_ptrのようなメモリ管理、関数オブジェクトやメタプログラミング等、
非常に多くの有用な機能を持っています。
しかし私はそのBoostに対し、不満もあります。
前衛的で、それまで誰も思いつかなかったような「C++でこんな事まで出来るのか」と言った機能を実装しているのはいいのですが、
SAFE_DELETEや、SAFE_RELEASEと言ったプリミティブなものについては、とんと定義されていません。
・・・まぁ、shared_ptrに代表されるオブジェクト思考的なメモリ管理機能や、Release等もマクロでやらず、ちゃんとテンプレートを使ってやれ、
とのことなんでしょうが・・・
個人的にな理由としてもう一つ、（そしてもしかすると他の多くの人も思って居るかも知れない）Boostライブラリが余りに巨大すぎる、と言うのもあります。
今、1.39.0のファイルサイズを調べてみたら188MBもありました。
ファイル数は実に2万7千ファイル。解凍にもべらぼうな時間が掛かりましたし、ちょっと移動するにもこれまたべらぼうな時間が掛かります。
（実のところ私は昔ちょっと使った程度なので、）他の話を聞くに、コンパイルにもかなりの時間が掛かると聞きます。
高機能なのは良いのですが・・・ここまで来るとやや「使い勝手が悪い」と言う印象が個人的には出てきます。
Roast+は、これらBoostの問題に対するアンチのライブラリとして作っています。
・・・別にBoostを潰そうとか言うつもりではありません。ただ、これらBoostで足りないと思っている所を補いたいと思っているのです。
まず、Boostにはない、原始的な、よく使われるテクニックのマクロや関数の定義、
またこれに加えて、あると便利な関数やクラス、マクロ。・・・少なくともJava程度の使い勝手は実現しておきたいな、と思っています。
そしてコンパクトである事。
ソースコードがトータルで、どんなに大きくとも1MB程度に収まる規模にしたいと考えています。
Boostに似た語感の名前を挙げて行って、丁度「Roast」と言うのが「焼く」「あぶる」と言った意味であり、
「枯れた」に近い意味であったため、この名前を採用しました。
枯れるどころか、なんかもう焼け焦げちゃってますが・・・。まぁそれくらい非常に枯れ切ったものを集約するんだ、と言う事で・・・。
Boostに似た語感の名前を挙げて行って、丁度「Roast」と言うのが「焼く」「あぶる」と言った意味であり、
「枯れた」に近い意味であったため、この名前を採用しました。
枯れるどころか、なんかもう焼け焦げちゃってますが・・・。まぁC/C++のおこげと言うような言い方をすれば、
それなりに美味しそうで、使えそうな感じがするのではないかと。
Roastの最後についている「+」についてですが、
これは、ただの”C”と、”C++"の”中間”、と言う意味です。
具体的にどういう事かと言うと、可能な限り、Cでも使用可能な実装としたいと思っています。
ただし、どうしてもクラスを用いた方が良さそうな場合などではクラスを用います。
例えばには、マクロや、関数等では、Cでもコンパイル可能なようにします。
「//」によるコメントを使わないようにしたり、extern "C"で囲ったり、変数宣言を処理の途中に記述しない（Cでは変数宣言は全て最初のうちにしなければいけないので・・・）、等です。
何もかもをC互換にするつもりはなく、例えばソケット通信ライブラリなどではクラスを用います。
これは、ソケット通信等ではクラス化した方が使い勝手が良いからです。むしろクラス化しないで単純な関数とするのであれば、
余りライブラリとして作る利点は薄いです。基本的に無理なくC化と言うか、コメントを//に置き換えたり、変数宣言位置を最初に移動するだけで
Cでも使えるようになるのであれば、/**/コメントに置き換えたり、変数宣言位置を移動する──程度の話です。
Open-MGLのLicenseは基本的にMIT Licenseですが、その中のRoast+のみは、
zlib/libpngライセンスをベースにした、独自のライセンスを使おうかと思っています。
ただ、一つのプロジェクト内で、複数のライセンスが混在していいのかどうか謎なので、
「駄目だ。」と言う事が分かった際や、また、複数のライセンスが混在している事により混乱を招くようであれば、
別プロジェクトとして分離する事も検討しています。・・・と言うか最終的にはそれが理想でしょう。
とりあえず現段階ではまだ「構想」「プロトタイプ」のレベルであるとして、
Open-MGLの配下としています。（矢鱈滅多とプロジェクトを分離させるのもまた、混乱を招きますので・・・）
[PageInfo]
LastUpdate: 2010-06-01 01:27:32, ModifiedBy: myun2
[Permissions]
view:all, edit:members, delete/config:members
Fork
edit