アカウント名:
パスワード:
汎用のプログラミング言語の規格の範囲ってどこまで拡大していくんですかね？ 際限なく肥大化しているように思うのですが
ライブラリは最小にしてほしいよな。
デカければデカイ方がいいに決まってんじゃん。スマポとかいったい何種類あったと思ってるのさ、標準ライブラリは貧弱だと、ライブラリやフレームワーク毎に再発明されるんだよ。
外部のライブラリでまかなえるならライブラリでいいじゃん、がC系の流儀なので、少なくともCとC++では正しい姿なのです。
よそでは、完全なキッチンシンクを目指す開発者がいるいっぽうでユーザーは結局オレオレキッチンを構築してるような気がする。
その「ライブラリ」に対して、定番のインターフェースが欲しいってことですよ。
かつては、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 で出来るって言われそうですが。#どちらも、コードの構造が専用化されてしまいますので、既存のコードにちょっとグラフィック機能を追加したい、という目的には使いにくいんすよね。
Cairoがそこまで一強といえる決定版ライブラリなら今後も外付けで問題ないと思いますし、そうでないならば一方言を無理に標準へ組み入れて定番扱いしても災いの種になりそう。
# 「C++の規格にOpen**を含めよう」っていう提案をさらに唐突にした感じ
誰も依存するライブラリを増やしたいから、結局ライブラリ毎にオレオレキッチンが出来るのさ、なんで標準化できるならさっさと標準化した方がいい。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
皆さんもソースを読むときに、行と行の間を読むような気持ちで見てほしい -- あるハッカー
どこまで大きくなる？ (スコア: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)
誰も依存するライブラリを増やしたいから、結局ライブラリ毎にオレオレキッチンが出来るのさ、
なんで標準化できるならさっさと標準化した方がいい。