by
Anonymous Coward
on 2014年01月07日 17時13分
(#2523323)
Phoronixにて > The C++ standards committee is looking at adopting > a Cairo C++ interface as part of a future revision > to the ISO C++ standard to provide 2D drawing. とありますから、ここの情報を信用するなら『a Cairo C++ interface』との 記載があるのでインターフェイスであるのは明確かと。 # それに普通に考えて、標準化の際に規程するのはインターフェイスですし。
Common Lisp の仕様は確かにでかいんですが、実はほとんどは 組み込みライブラリの仕様です。 組み込みライブラリの部分を除いた狭い意味での言語仕様と言うと、 Common Lisp の場合、special form の部分になるわけですが （それ以外の仕様は、Common Lisp 自身を用いて記述可能だからです）、 special form は少ないですよ。 狭い意味での言語仕様なら、Common Lisp よりも C++ の方が、 はるかにでっかいです。 昔は Ada の言語仕様もでかいと言われて、1980年のチューリング賞記念講演 「皇帝のふる着」(The Emperor's Old Clothes) では、その点が批判された わけですが、いまや Ada より C++ の方がでかいですね。
Cairoはモダンな実装ではないと思う (スコア:3, 興味深い)
http://people.mozilla.org/~roc/Samsung/Mozilla2DGraphics.pdf [mozilla.org]
ここでFirefoxがCairoを捨てた理由が述べられてるけど、ステートフルなAPIってのが駄目らしい。
デファクトになりつつあるskiaとかDirect2Dはステートレスで、実際Firefoxが使うようになって早くなった。
(Linux版も次の27でskiaを使うようになるようだ)
そんな逆風が吹いている中でだけに、このニュースは意外だ。
それだけ設計や実装が綺麗だということなんだろうね。これで開発に弾みがついてくれればいいけど。
Re: (スコア:0)
注文したら一瞬で出てくるというのは本当だったのか
#それはすき家
##GOTOが多かったりしたら嫌だな
Re: (スコア:0)
「ステートレス」って待ち時間がないことだと思ってますか？
Re: (スコア:0)
こっちかも。> Firefoxが使うようになって早くなった
Re: (スコア:0)
設計が奇麗というか、ステートフルなAPIはレガシーコードを残したまま拡張が可能という特徴がありますので、そこが評価されてるんじゃないでしょうか。
ただ、こういったコンテキストにグローバル変数を持たせるような構造はモジュール化を酷く阻害するんですよね。
性能が出ない上に教育にも悪いといった結果にならなければいいのですが。
Re: (スコア:0)
ステートフルといったら、十数年前 OpenGL の入門書を読んだ時にも、それはステートフルだと思ったけどな、最近はどうなの？今も同じなら、OpenGL はやっぱり遅いということになるの？
C++ 用だということは、Template あたりで実装されて、コンパイラで最適化したら速くなったりしないのですかね。
Re: (スコア:0)
ステートフルだから遅いとか速いとかそういうことではなく、
現代のブラウザで描画ライブラリとして使うには相性が悪いということ。
リンク先のPDFでは
「CSSはステートレスだし、CanvasはステートフルだがCairoのものとは別物だ。
だからステートフルな描画ライブラリだとステート管理が大変になる」（結果として遅くなる）
みたいなことが書いてある。
Re:Cairoはモダンな実装ではないと思う (スコア:2)
いや、事前に幾つもステートを用意しておいてそれを指定するやり方と比べて、
ステートフルだと何かする度に毎回状態を書き換えないといけないから一般論として遅いと言っていいと思うよ。
ステートレス≧ステートフルなイメージだけど。
ようするに、同じステートで後で描画する為にステートを(メモリ)コピーしておかなければ
いけないのが直接的な遅い原因だと思う。
OpenGLで言えば、glPushMatrix()は単純にMatrixをメモリコピーしてて超遅い。
何度Matrixのポインタを直接指定できないのかと思ったもんだ…(遠い昔の記憶)
ライセンスが (スコア:0)
ライセンスも（汚染的な意味で）クリーンならよかったのにな。
Re: (スコア:0)
インターフェースが採用されるのか実装が採用されるのかはっきりしないな
Re:ライセンスが (スコア:3, 参考になる)
Phoronixにて
> The C++ standards committee is looking at adopting
> a Cairo C++ interface as part of a future revision
> to the ISO C++ standard to provide 2D drawing.
とありますから、ここの情報を信用するなら『a Cairo C++ interface』との
記載があるのでインターフェイスであるのは明確かと。
# それに普通に考えて、標準化の際に規程するのはインターフェイスですし。
またインターフェイスしか規程されませんから、実装者がどのようなライセンス
にするのかは実装者の自由でしょう。
# それこそ、Cairoがイヤなら別のライセンスで実装すれば良いだけです。
Re:ライセンスが (スコア:1)
問題になりうるのはAPIそのもの(とドキュメント)の知財的なあれこれですね。話の持って行き方によっては「AndroidにおけるOracle対Google訴訟、陪審員はGoogleによる著作権侵害を認める [srad.jp]」みたいな話になる可能性もゼロでではありませんし。
まあ、ほぼゼロでしょうけれど。
ただ、やや、勇み足というか、そんなに性急に決まるわけでもないと思います。この手のベクタ→ラスタの画像ライブラリは成熟しつつあると思うので、いずれ、(2D)画像APIの標準化は避けられない流れですし、個人的にはそっくりそのままcairoで大賛成ですが、今は観測気球的な段階であって、話が流れる可能性だって低くはないでしょう。
私は、結局のところ、HTMLCanvasっぽいAPIになるんじゃないか、と予想しています。主にネーミング的な問題で。あと、広大の鈴木さんが言っているように、フォントの問題に突っ込むと泥沼なので、とりあえずは、文字をレンダリングするのは諦める方向で始める方がいいと思います。
Re: (スコア:0)
> # それこそ、Cairoがイヤなら別のライセンスで実装すれば良いだけです。
まさにAppleがやってることですよね。clangなどまさに「gccがイヤだから作った」わけだし。
Re: (スコア:0)
俺もインターフェイスだとおもうんだけど、とはいえクリーンなコードや構造 と言ってしまっているのが本当なら 実装見ての話なんだろうねと疑問に思う
Re: (スコア:0)
MPLはリンクしても適用されないのだが、
どこまで大きくなる？ (スコア:0)
汎用のプログラミング言語の規格の範囲ってどこまで拡大していくんですかね？ 際限なく肥大化しているように思うのですが
Re: (スコア:0)
ライブラリは最小にしてほしいよな。
Re: (スコア:0)
デカければデカイ方がいいに決まってんじゃん。スマポとかいったい何種類あったと思ってるのさ、
標準ライブラリは貧弱だと、ライブラリやフレームワーク毎に再発明されるんだよ。
Re:どこまで大きくなる？ (スコア:1)
外部のライブラリでまかなえるならライブラリでいいじゃん、がC系の流儀なので、少なくともCとC++では正しい姿なのです。
よそでは、完全なキッチンシンクを目指す開発者がいるいっぽうで
ユーザーは結局オレオレキッチンを構築してるような気がする。
Re:どこまで大きくなる？ (スコア:2)
その「ライブラリ」に対して、定番のインターフェースが欲しいってことですよ。
かつては、printfなどのファイル入出力ライブラリすら互換性がない時代もありました。
Whitesmith C とか、BDS-C とか。
TCP/IPのプログラミングをするのに互換性がない時代がありました。
BSD系のsocketと、SystemV系のTLIの対立。
それが、ファイルIOが規格として標準化されたり、socketが実質的な標準になったおかげで、
今では「C/C++をつかえば、非常にポータビリティの高いプログラムを記述することも可能」になってます。
それぞれのプラットフォームで使うライブラリは違っても、インターフェースが同じなのでコードが共用できる。「ネットワークを使うコンソールアプリケーション」程度なら、MacとWindowsとLinuxでほぼ同じコードを動かすことは全然難しくない。
WindowsのWinSock2だけはちょっとビミョーで、「まったく同じ」に出来ないのが悲しいとこですが。
C/C++がグラフィック系に弱いというか、簡単に使える「標準/定番のライブラリ」がない、というのは確かですし。
グラフィック系の標準インターフェースを決めるというのは喜ばしいことだと思いますね。
ちょっとしたグラフィックアプリで、「同じコードが Win/Mac/X でそのまま動く」なんて、ちょっとわくわくしますよ。
#まあ、今でも SDL とか OpenGL+AUX で出来るって言われそうですが。
#どちらも、コードの構造が専用化されてしまいますので、既存のコードにちょっとグラフィック機能を追加したい、という目的には使いにくいんすよね。
Re: (スコア:0)
Cairoがそこまで一強といえる決定版ライブラリなら今後も外付けで問題ないと思いますし、
そうでないならば一方言を無理に標準へ組み入れて定番扱いしても災いの種になりそう。
# 「C++の規格にOpen**を含めよう」っていう提案をさらに唐突にした感じ
Re: (スコア:0)
誰も依存するライブラリを増やしたいから、結局ライブラリ毎にオレオレキッチンが出来るのさ、
なんで標準化できるならさっさと標準化した方がいい。
Re: (スコア:0)
＞ デカければデカイ方がいいに決まってんじゃん。
私もそう思う。
＞ ライブラリは最小にしてほしいよな。
のACさんは「汎用」じゃなくてリソースに制限のある組み込み向けをやっているとか、
言語や開発環境自体の移植をやっているとかじゃあるまいか。
遠い昔、Common Lisp の言語仕様の大きさに途中で解説書を投げ出したヘタレなのでAC。
Re:どこまで大きくなる？ (スコア:2)
C++も十分言語仕様がでかいよ
ライブラリ部はフルセットで自分で書いているところはある程度のサブセットを強制してくれる機能がほしい
コーディングルールだと逸脱することあるからね
Re: (スコア:0)
そしてまたひとつ仕様が増える。
#実際あったら便利そうではありますね
Re: (スコア:0)
Common Lisp の仕様は確かにでかいんですが、実はほとんどは
組み込みライブラリの仕様です。
組み込みライブラリの部分を除いた狭い意味での言語仕様と言うと、
Common Lisp の場合、special form の部分になるわけですが
（それ以外の仕様は、Common Lisp 自身を用いて記述可能だからです）、
special form は少ないですよ。
狭い意味での言語仕様なら、Common Lisp よりも C++ の方が、
はるかにでっかいです。
昔は Ada の言語仕様もでかいと言われて、1980年のチューリング賞記念講演
「皇帝のふる着」(The Emperor's Old Clothes) では、その点が批判された
わけですが、いまや Ada より C++ の方がでかいですね。
Re: (スコア:0)
「デカければデカイ方がいいに決まってんじゃん」→「私もそう思う」→言語仕様の大きさに途中で解説書を投げ出す
Re: (スコア:0)
標準ライブラリに採用された仕様が微妙に使えないのでみんなが微妙に違うものを再発明してさらにカオスのズンドコということもありがち。
Re: (スコア:0)
入出力、ロケール、シグナル、スレッドあたりは伝統的にわかるけども、
「ISO準拠」のために2Dユーティリティの面倒まで見ないといけないのは
実装者にとっては何だか余計な負担だと思いますね。
外付けの有用なライブラリ全て規格に組み込む方針でしょうか。
グラフィック難民の思い出 (スコア:0)
と呆然とした経験者としては、C++の処理系に標準のグラフィックライブラリって、一体どこへどうやって出力するんだ!? との驚きが強い。
まあ、出力先は画面には限らないし、環境ごとにGUI表示する方法も何か用意されてるんだろうけど。
Re:グラフィック難民の思い出 (スコア:2)
PC-9800なら、master.libとかsuper.lib, gr.libみたいなのが有った気がするする。
Cairoの出力先なら、http://cairographics.org/manual/cairo-surfaces.html に書いてある。
Re:グラフィック難民の思い出 (スコア:1)
> PC-9800なら、master.libとかsuper.lib, gr.libみたいなのが有った気がするする。
いったい何時の話をしてるんですかーてツッコミたくなりますね。
N88BASICから移ったとかいうと、遅くとも1980年代じゃないかな。
一方、master.lib [vector.co.jp]は1992年。super.lib や gr.lib はもうちょっと前だったと思うけど、それでも、「初期のDOSプログラミング」時代には存在しなかった新参ライブラリ。
初期のDOSプログラミングでの、グラフィックライブラリの定番といえば、Borland TURBO C の BGI だと思う。
#BGIといえば、埋め込みメッセージ [srad.jp]を思い出す…
Re: (スコア:0)
DOS環境の充実を知らないまま、PC98に元から付いていたBASICでずっと遊んでたところで、
さくさく動くDOS用のゲームを見て、そっちへの移行を決意した感じでした。
その後、その手のゲームを作るにはその手のライブラリが必要だというのを知り、
super.libにはお世話になりました。ちょうどその辺りの時代です。
Re:グラフィック難民の思い出 (スコア:2)
その昔, 2Dグラフィックの国際規格としてGKS [coocan.jp], 3DグラフィックスではPHIGS [wikipedia.org]が有って, CADの分野では標準的に使われていました.
でも, 1990年代後半からはプロプラ規格のDirectXやOpenGL(こちらは今では標準規格になってますけど)に駆逐されて今に至るという感じですね.
どうもグラフィックス技術って, 汎用言語, 特に性能を要求するC++みたいな言語の規格に組み込むほどには枯れてはいないと思うんですけどね. 簡易性と互換性を重視する軽量言語ならいいかもしれませんが.
Re:グラフィック難民の思い出 (スコア:1)
その昔, 2Dグラフィックの国際規格としてGKS, 3DグラフィックスではPHIGSが有って, CADの分野では標準的に使われていました.
Calcompェ…
Re: (スコア:0)
出力先は画面には限らないし、環境ごとにGUI表示する方法も何か用意されてる
ってのがまさにCairoの役割。ここから更に環境ごとに下位層のライブラリやドライバへと分岐していくその端緒的ライブラリ。
以下Wikipediaより
出力バックエンドとして X Window System (XlibとXCB), GDI (Microsoft Windows), Quartz (OS X), イメージバッファ, PostScript, PDF, SVG をサポートしている。実験的に、OpenGL, OpenGL ES 2.0, OpenVG, BeOS, OS/2, DirectFB をサポートしている。
今回のはAPI規格としてCairoをモデルにしますって話で、実装は各処理系デベロッパ任せ。
WindowsでもLinuxでもprintfやsocketなのと一緒。それが規格ってもの。