トップページ⇒tech
149コメント60KB

gnuのコードは糞コード

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさんNGNG
その想いやよし。
だけど、コードは腐っていませんか?
ex.gccのインラインアセンブラのシンタクスは何よ?
思想面での大いなる感謝はしつつも、コードがアレじゃね、のスレッド。
0002デフォルトの名無しさんNGNG
根底に流れるものは、
「動けばいいや。ソース公開しとくから、気になった奴は直せよ」
の精神です。
0003デフォルトの名無しさんNGNG
グニュグニュ
0004デフォルトの名無しさんNGNG
おめーがアセンブラを理解できないだけだろーが。
インラインアセンブラを使わざるを得ない部分があることを
もしかして知らないのか？
0005デフォルトの名無しさんNGNG
神話化しすぎてる。
議論する人は、本当にgnuのソースを見て言っているの?
0006デフォルトの名無しさんNGNG
> ex.gccのインラインアセンブラのシンタクスは何よ?
シンタクスについていっているわけじゃねーだろ。
コードだよ、コード。
0007デフォルトの名無しさんNGNG
インデントのスタイルが気に入らない････。
0008デフォルトの名無しさんNGNG
>>2が正解
0009デフォルトの名無しさんNGNG
>>1
gcc のインラインアセンブラの文法は、良いと思うぞ。使うレジスタを
指定しないで済む（32bit 汎用レジスタのどれか、みたいな書き方が
できる）ので、コンパイル時に最適なレジスタ割り当てが行えるわけ
だし。

ただソースコードに関しては、ホントにダメなものが多いよな。binutils
とか読むと目が腐るよ。

>>2
正解。Linux も同じノリを受け継いでるので、コードはぐちゃぐちゃ。少
しは Solaris とか 4.4BSD を見習って欲しいものだ。
0010デフォルトの名無しさんNGNG
ここでいうコードってつまり実装のことと思っていいですか？

直接読んだことはないが、どっかの本に、
「Stallmanはアーキテクト(として一流)だ。
狭義のプログラマ(として一流)かどうかはさておき」
みたいなことが書いてあったけど、ほんと？＞ソース読んだ人

あ。GNUといってもStallman一人じゃないな。
あそこって今何人くらいで書いてるんでしょう？
0011デフォルトの名無しさんNGNG
作った人には読みやすいんだよ、きっと。
0012デフォルトの名無しさんNGNG
そればっかじゃないけど、例えば、の話でシンタクスを言ってるだけよ。
あんたら、あたま良いかもしれんけど、あたしゃ理解できんね。

ex...linux/arch/i386/traps.c

#define _set_gate(gate_addr,type,dpl,addr) \
do { \
int __d0, __d1; \
__asm__ __volatile__ ("movw %%dx,%%ax\n\t" \
"movw %4,%%dx\n\t" \
"movl %%eax,%0\n\t" \
"movl %%edx,%1" \
:"=m" (*((long *) (gate_addr))), \
"=m" (*(1+(long *) (gate_addr))), "=&a" (__d0), "=&d" (__d1) \
:"i" ((short) (0x8000+(dpl<<13)+(type<<8))), \
"3" ((char *) (addr)),"2" (__KERNEL_CS << 16)); \
} while (0)

この、"3"とか言うのは位置オペランド?
0013デフォルトの名無しさんNGNG
>思想面での大いなる感謝はしつつ

って気持ちがあるんなら綺麗に書きなおしてフィードバックしろや
ガタガタ文句言ってるだけでスキル無いんだろ？
0014デフォルトの名無しさんNGNG
僕は議論について行けないけど、コード見るなら
Linux kernel じゃなくて、
4.4bsdとか、見たほうが良いのかな?
(それって、今じゃ netbsd?)
0015デフォルトの名無しさんNGNG
腐っているといえばマイクロソフトのサンプルの方が
遥かに腐っているような気がするなあ。
あーゆーサンプルソースを元に育った人間が書くコードが恐ろしい。
0016sageるNGNG
gnuにしろ、MSにしろ#ifdefが多すぎて読みたくなくなる・・・。
0017デフォルトの名無しさんNGNG
gnuのconfigure使うソースだと
config.hで吸収されるんじゃない？>16
それ以外は機能の有無や互換性とかだと思うけど
0018デフォルトの名無しさんNGNG
ていうか、俺は思想が大いに気にいら無いんだが。
あれが「オープン」？
0019デフォルトの名無しさんNGNG
>>14
目的にもよるが、カーネルの勉強したいなら Linux より NetBSD の方
が良いと思うよ。Linux は設計も実装も、ちょっと……ね。

ただ最近の UNIX カーネルは規模が大きく、慣れないと見通しが効か
ないかも。もしカーネルを読むのが初めてなら、もっと小さいコードで慣
らしておくことを勧める。

Lions' Commentary on UNIX を買ってきて UNIX Version 6 のソース
を読むとか、インターネットからマイクロカーネルのソースを探してきて
読むとかね。有名どころのマイクロカーネルだと、誰かしか内部構造を
解説する論文を書いてるので、それとソースコードを合わせて入手す
るのが吉。

……ぜんぜん、このスレッドと関係ないな。sage だ。
0020デフォルトの名無しさんNGNG
>>12
せめて info ぐらいは読んで下さいな。

http://docs.freebsd.org/info/gcc/gcc.info.Extended_Asm.html から抜粋

asm ("combine %2,%0" : "=r" (foo) : "0" (foo), "g" (bar));

The constraint `"0"' for operand 1 says that it must occupy the same
location as operand 0. A digit in constraint is allowed only in an
input operand, and it must refer to an output operand.

しかし、典型的に汚いコードを持ってきたね。なんで Linux のヒトって
マジックナンバーを多用して、バイナリのパックもマクロなどで隠蔽せ
ずに直接シフト演算で解決しようとするかな。読みにくくてかなわん。
0021デフォルトの名無しさんNGNG
>>18
GNU思想をあれこれ言うためのスレは既にあるので、
そっちへ逝って語りましょう。
0022デフォルトの名無しさんNGNG
>>20
きっと芸術作品なんでしょ。
素人には壺やら絵画の良し悪しが分からないのと似ているのではないかと。
0023デフォルトの名無しさんNGNG
>>9
LinuxのコードがぐちゃぐちゃなのはGNUのノリ関係なく
Linus君がヘボってだけじゃないのですか？

>>10
StallmanやGNUに雇われてる人が書いたコードってGNUのコード全体の半分もないでしょ。
0024デフォルトの名無しさんNGNG
>>22
いやいや、それは違うと思うぞ。
ほんとに糞だったりもするのだ。
0025デフォルトの名無しさんNGNG
>>20 >>23
ビット演算オタクだと思う。
0026デフォルトの名無しさんNGNG
>>25
すごい好意的な捉え方だね（笑
0027デフォルトの名無しさんNGNG
>>20 >>23
一般人が、
#define PLUSONE(a) ((a)+1)
とはしないのと同レベルだろう。
0028デフォルトの名無しさんNGNG
アセンブラ上がりが多いんじゃない？
シフトでキャリー拾って飛ぶのが早いとかって感覚。
癖ってついちゃうと落とすのが大変だな。(w
0029デフォルトの名無しさんNGNG
emacsのソースも「おいおいこんなんかよ」と
思った。
0030デフォルトの名無しさんNGNG
完成して動作するプログラムの前には、
卓上のオブジェクト指向など足元にも及ばない。
0031デフォルトの名無しさんNGNG
>>30
卓上ってなんだ？机上のことか？
まぁいいけど、一応混じれ酢するなら、
そんな寝言を「常に」言う奴には未来は任せられないってのは確かだ。
今時全部を汗で書く奴はほぼ絶滅したってのと同様に。

それにOOなんてとっくの昔に、世間に定着した技術になってる。
未だにそれに頓着しない奴なんて一部の老年ドキュだけ。
003230じゃないけどNGNG
>>31
きれいだけど動かないコードより汚くても動くコードの方が価値がある、という図式は絶対にくつがえらない。
0033デフォルトの名無しさんNGNG
>>31
＞卓上ってなんだ？机上のことか？
新しい2ch養護老人ホーム
0034デフォルトの名無しさんNGNG
>>32
そりゃそうだが、それ以前に、誰が動かないと言った？

まぁ、指向に動くも動かないも無い(動くものを実装すりゃいいんだ)けどさ。
あとは、机上って何なのかが永遠(藁)の謎だな。
003523NGNG
>>25 >>27
えっと、なんで俺にレスするのだい？
0036デフォルトの名無しさんNGNG
>>27
一瞬、意味無いじゃんって思ったのだが
同じ意味を持ったコードをマクロで括っとけば
後で変更することになった時に楽って話？
bit演算をマクロで隠すのはコードを見やすくする意味もあるが
あなたの挙げた例には、その意味とは違うよね？
0037デフォルトの名無しさんNGNG
同じ動くコードなら綺麗な方がいい。メンテもしやすいし。
0038デフォルトの名無しさんNGNG
理解できないが、「きれいだけど動かないコード」と「汚くても動くコード」しか
世の中にないと思ってるやつがいるようだな。
0039デフォルトの名無しさんNGNG
多人数の意見（コード）を取り入れながらあれだけ
多くの環境に対応するには汚くなっても仕方ない気がするけど
望ましい、じゃなくて現実ってそんなもんかなって感じ。
gnu のコード見てると、良くも悪くもハッカーライクな匂いがする。
0040デフォルトの名無しさんNGNG
これぞと思われるOOPで書かれて、いろんなところで移植されているプログラムで何かある？
004132NGNG
>>38
そうは思ってないよ。
「きれいで動くコード」と「汚くて動くコード」の比較は自明だから言わないだけ。
0042デフォルトの名無しさんNGNG
読みにくいコードはソース公開のありがたみも半減
0043デフォルトの名無しさんNGNG
「きれいだけど動かないコード」と「汚くても動くコード」があったら
俺は「きれいだけど動かないコード」のほうがいいなぁ。

これは「なぜ動かないのか分かるコード」と「なぜ動くのか分からないコード」
と言い換えてもいいんだけれど。

どう？
0044デフォルトの名無しさんNGNG
>>43
それはおまえが馬鹿なだけ。

コードが綺麗とか汚いとか言ってる人って、Pentium系のニーモニック体系の汚さも文句言うのかな？
0045デフォルトの名無しさんNGNG
>>43
動かないと意味なし
0046デフォルトの名無しさんNGNG
>>43
大規模な場合は俺も「きれいだけど動かないコード」のほうがいい。
何年も付き合わされるわけだから、理解できないほど汚いコードだったら
作り直したほうがいい。
0047デフォルトの名無しさんNGNG
きれい/汚いとか動く/動かないは程度問題じゃないの？
簡単にこっちの方がいいなんて言えるわけないよ。
0048デフォルトの名無しさんNGNG
>>44
君は>>43の言う「なぜ動くのか分からないコード」 のほうを選ぶってこと？
だとしたら君は自分の馬鹿さ加減に気が付いてないだけだと思う。
0049デフォルトの名無しさんNGNG
>>48
あるいは無責任つー感じだな。
0050デフォルトの名無しさんNGNG
>>48
44はあほSEかﾄﾞｷｭｿクライアントだろ？
0051デフォルトの名無しさんNGNG
エレガントな設計にこだわって、
納期になっても完成しないプログラムの方がいいとでも？
0052デフォルトの名無しさんNGNG
自分は綺麗なコードを書くよう心がけたいと思います。
汚いコードを書くヤツがいたら注意したいと思います。
0053デフォルトの名無しさんNGNG
>>51
長期にわたる開発だったら納期が遅れたほうがいいだろうね。
開発側にとっては。ひいてはクライアントにとっても。
0054デフォルトの名無しさんNGNG
>>13
そうしたいのは山々だけど、今からじゃ規模がでかくてどっから手を付けてイイかわからんジャン。
不具合にその場しのぎの対処を、じゃなくて、根本からあの汚いソースをどうにかしたいって事なんだから。

つーかみんなでdiffを１から書きなおさんか？cvsで日本語使ってるとマージで落ちるんだけど……
ソース覗いてﾋﾞﾋﾞﾀよ。
0055デフォルトの名無しさんNGNG
>>51
「Linuxの革命」読んだ感じでは、
結局納期って奴がソフトのレベルを下げる元凶の1つ、
だと読めなくもないっす。まぁ当然なんだけどさ。
糞プログラムで地上を埋めたいかどうか、ってことだな。

ところでGNUおよびLinux。Raymondによると
それぞれ伽藍およびバザールの代表選手らしいが、
比較するとどっちがどれくらいコード汚いの？
0056デフォルトの名無しさんNGNG
>>54
cygwin上のRCSで、まともに動くのを見たことがない気がする
んだけど、もしかして理由はソレ？
cygwin環境だと、改行とか文字コードでなにかと色々いじめる羽目になるんでさ。
0057デフォルトの名無しさんNGNG
汚いけど完成したプログラム＞綺麗だけど完成しないプログラム
継ぎ接ぎで汚いけどセキュリティーホール塞がれたプログラム＞綺麗だけど実は穴だらけのプログラム
0058デフォルトの名無しさんNGNG
馬鹿だなぁ〜「なぜ動くのかわからないコード」なんて、あるわけないじゃん。
「なぜ動くのか理解できないコード」なら、担当者の知能レベルで納得できるけどさ。

「保守しやすい」ってさ、「怠慢こける」と同意語？？
0059デフォルトの名無しさんNGNG
>>58
そのとおり
0060デフォルトの名無しさんNGNG
う〜ん。開発期間が5年を超えるようなものだったら
俺も「きれいだけど動かないコード」のほうがいいな。
デバグと仕様変更のときに困っちゃうんだよね、「汚いけど動くコード」って。

>>58
>馬鹿だなぁ〜「なぜ動くのかわからないコード」なんて、あるわけないじゃん。
よ〜く調べないと分からないという意味ならゴロゴロあるね。
0061デフォルトの名無しさんNGNG
#ifが大量にあって汚いけど移植性が良いプログラム＞綺麗で簡潔に書いてあるけど移植できないプログラム
0062デフォルトの名無しさんNGNG
使うだけなら汚くても構わないけどな。

>>54
diffは差分生成アルゴリズムを調べていたときに読んだよ。
というか読めなかったよ。
0063デフォルトの名無しさんNGNG
「きれいだけど動かないコード」は動くようにできるしな。
「汚いけど動くコード」は、一度動かなくなったとき大変だ。
0064デフォルトの名無しさんNGNG
きれいで動くコードが欲しい
0065デフォルトの名無しさんNGNG
diff書き直しプロジェクトに一票。
大元のソースはどこから落せますか?乞うULI。
有志のみんなでソースコードを見てみようじゃないですか。
0066デフォルトの名無しさんNGNG
>>65 たしかにモノ見ないでうだうだいってても始まらないよな
0067デフォルトの名無しさんNGNG
ftp://ftp.ring.gr.jp/pub/GNU/diffutils/
0068デフォルトの名無しさんNGNG
職場では 綺麗で動くコードを こころがけていますが、
ヘタレは本当にヘタレなコードしか書きませんね。
それを修正する工数なんて認められるわけないので、
ストレスたまりっぱなしです。はい。
0069デフォルトの名無しさんNGNG
ソースも見ないでうだうだ言う奴はほっとけって。
GNUdiffのどこが腐ってるって?
コードを見ながら議論しよう。
0070デフォルトの名無しさんNGNG
>>62
　調べるっていうか、パクろうとしたわけね。
「参考にする」と「コピー」は、別の意味だぞ。
　で、自分で diff 書いてみて、それを、オープンソースに
反映させる気は全然ないんでしょ？
0071デフォルトの名無しさんNGNG
>>70
まあ、あわよくばパクろうとは思ったけどね。
使われているアルゴリズムの論文を読んだものの、
実際にどうコードに落とすかぴんと来なかったのでソースを読んだ。
結局はdiff解読は諦めてxyzzyの作者のサイトにある説明とサンプルコードを元に、
差分生成プログラムを書いたよ。

＞自分で diff 書いてみて
ごめん。
研究で使い捨てるプログラムだったのでdiffほど高度なものは必要なかった。
それに、diffは使う分には申し分ないので、僕は書き直す意味はないと思う。
diff上位互換のソフトを作るならいいけどね。
使われているアルゴリズムは違うけど、
PerlでAlgorithm::diffというdiffもどきの動作をするプログラムがあるので、
参考になるかも。
0072デフォルトの名無しさんNGNG
おめーは全然分かってないぞっと。>>70
参考にしても、パクってもいいんだよ..GNU
自分でスクラッチで diff を書くんじゃなくって、みんなが見れる、
diffのどこが悪くって、あんたはどういうふうに直せば
好いんだって、って話をしてるのよ。
0073デフォルトの名無しさんNGNG
うーみゅ。
GNU diff のどの辺がダメなのかな?
ソースを落して見てみたけど、あたいの技倆ぢゃ見切れない。
確かに、頭のほうは case 文が多いけど、これは
仕様から来ているもんで、コードが腐っているかどうか
とはまったく無関係でしょ?
うだうだ言ってないでコードを見て発言したらどう?
0074デフォルトの名無しさんNGNG
>>73

>うーみゅ。
ﾃﾞﾌﾞｦﾀ確定。
0075デフォルトの名無しさんNGNG
ちょっと読んでみた
static char *option_list PARAMS((char **, int));
とかANSI以前のコンパイラでも動作させようとしてるのが伺える。

多分、ANSI以前のコンパイラをサポートしないようにすれば
もう少し奇麗になると思う。
0076@NGNG
>>74
>>うーみゅ。
>ﾃﾞﾌﾞｦﾀ確定。
どことなく某氏に似た感じだ。
彼は内科医の超ナイスガイだったと記憶している。
0077デフォルトの名無しさんNGNG
読める、読めない。書ける、書けない。そんなのが問題じゃないだろ。
時間と暇さえあれば誰でも小さいものなら書ける。質はこの際問わない。

だがよ、労力かけて作ったものについてあーだ、こーだ言うのは、
自分が作り直す気があるものだけにしてくれ。
コードを公開してくれていることをもう少し考えろ。
0078デフォルトの名無しさんNGNG
>>77
いや、あーだこーだ言うのは悪くはないだろ。
むしろいいことだ。
0079デフォルトの名無しさんNGNG
ポジティブな提案をしないようなやつのあーだこーだは
意味無し。別に言ってもいいけど、大抵価値なし。
0080デフォルトの名無しさんNGNG
>>79
1:現状じゃ駄目であり、
2:有効な代案もとりあえず見つからない、

という場合においては、批判する(あそこが駄目だと言う)
ことしか出来ないんじゃないか？

その批判を読んで(読まなくてもいいが)、
もっと有能な人が有効な代案を成してくれるのを
待つ(しかない)という状態は、
無いわけじゃないだろう。残念ながら。

それとも、そういう場合にすら黙秘してろ、とでも？
008178NGNG
糞なものを糞と言わないと、糞なものが増えるのだよ。
言ってても増えるかもしれん。
しかし言ったほうが減るのは確かだ。
0082デフォルトの名無しさんNGNG
せっかく、具体的なクソコードの例（？）が出てきたみたい
だから。「gnuのコードはクソ派」の人は、具体的に例を挙
げて「こういう風に書いた方が解りやすい！」って書いてく
れない？抽象論ならオレにだって出来るぞ（笑）
0083デフォルトの名無しさんNGNG
>>82
ここでいう抽象論ってなんだ？
そもそも抽象とはなんなのかを理解してるか？(藁

言葉が足りないことを抽象と呼ぶのは止せ。
それこそが(抽象だかなんだか知らぬが)問題をぼやけさせる元凶だ。

で、改善案(笑)。そういうのは抽象じゃなくて厨房って呼ぶんだよ(藁
0084デフォルトの名無しさんNGNG
プログラマたるものコードで語れ
0085デフォルトの名無しさんNGNG
>>84
オマエモナー！

そういう訳で、語りまくりコードのアプ希望！
0086デフォルトの名無しさんNGNG
---------------------------------------------------------------
0087デフォルトの名無しさんNGNG
>>86
デブオタうぜぇ
0088デフォルトの名無しさんNGNG
extern int RES_NO;
void omaemona(void){
if(RES_NO>999)return;
printf(">>%d\nオマエモナー\n",RES_NO - 1);
omaemona();
}

int main(){
printf(">>%d",RES_NO - 1);
omaemona();
return 0;
}
0089結局、NGNG
結局、みんな ソースなんて読んでないんだよね。
読んでも良いか悪いかをわかるほどのスキルもないって事だよ。
0090名無しさんNGNG
>つーかみんなでdiffを１から書きなおさんか？
それをregexでやりましたが、
やった後気持ちよかったです。
「抜いた」って気分。
0091デフォルトの名無しさんNGNG
>>89
うん。
ソースは読んだけど、良いか悪いかはわかりませんでした。
0092デフォルトの名無しさんNGNG
>>89
うん。
ソースは読んだけど、良し悪しはわかりませんでした。
009391-92NGNG
二重投稿すまそ。
0094デフォルトの名無しさんNGNG
>>90
で？
君の書いたコードはどうなったの？
0095デフォルトの名無しさんNGNG
GNU のコードってどこからダウンロードできるの?
0096デフォルトの名無しさんNGNG
>>95
ftp://ftp.dnsbalance.ring.gr.jp/pub/GNU/
0097デフォルトの名無しさんNGNG
>>95
ftp://alpha.gnu.org/
0098デフォルトの名無しさんNGNG
俺もGNUのソースって糞だと思うぞー
Cで書いててもまともに構造化プログラミングしてないじゃん。
動けばいい、ってレベル。
こんなソース書く奴と一緒に仕事したくないね、って感じ。
0099デフォルトの名無しさんNGNG
emacsはかなりきついと思うけどどうよ。
まぁ俺にはそんなスキルはないが。
0100名無しさんNGNG
GPLったって赤の他人のソースの集まりだから
ひとからげにはできんのです。
flexなんかだともともとはbsdだし。

ここではRMSとかMIKEとかGNUでは多く見かける署名の
ソースを論じるとすれば、
案外セオリーに忠実なソース多いよ。
ファイル名なんかもどこぞの名著の章立てにほぼ忠実に
対応しそうなくらい。
マイナーな技法とかでちょっと悩むけど関数の分け方とか
は行数で分けるって言うより章立てっぽく素直に分けてるし。
0101デフォルトの名無しさんNGNG
>>98
具体的にダメな箇所をきぼーん。
私もスキル無いけど、勉強になると思うので。
0102デフォルトの名無しさんNGNG
>>101
ダメなコード読むより、いいコードを読んだほうが勉強になるって。
0103デフォルトの名無しさんNGNG
>>102
いいコードある場所おしえてちょ。
どんなのがいいコードかよくわからないので
0104デフォルトの名無しさんNGNG
ちょっとややこしい事やったら、特にCで、そんな綺麗なコードなんて書けないよ

たいていは簡単に理解出来ないものさ。
010598NGNG
>>100
具体的なプログラム名称あげてみりん。

>>101
tarをライブラリ化しようとしてソース見たけど、
tarのプログラム用のデータ構造べったりでアルゴリズム書いてるから、
とても切り出せるシロモンじゃなかったよ。
ほかのプログラムにも言えるけど、エラー発生時もprintf系関数で直書きしてるしね。

俺だったら、tarの機能を持つライブラリを作り、
それを使ってstdio用のフロントエンドを作るね。
tarのアルゴリズム自体にOS依存性なんかはないから、
それを切り出せないソースはあまり有用でない。
それよりもアルゴリズムを解説した文書の方が欲しい。
0106デフォルトの名無しさんNGNG
>>105 JavaのZipInput(Output)Stream みたいやね
0107デフォルトの名無しさんNGNG
「いいコードを鑑賞するスレ」とかって無いかなあ。
0108デフォルトの名無しさんNGNG
>tarのプログラム用のデータ構造べったりでアルゴリズム書いてるから、
>とても切り出せるシロモンじゃなかったよ。

それはObject指向っていうんじゃないのか？(藁
データ構造とアルゴリズムが切り離せるとは限らんだろ。
0109デフォルトの名無しさんNGNG
自分が使うために書いたプログラムを
「オマエも使ってみ」
みたいなノリで公開してきた歴史があるからね。
自分が読めればそれでよしってのも納得できる。

よりよいプログラムにしようとか、みんなで一本のプログラムを
書こうってのは最近の話でしょ。

で、なかなかそういう流れにならないのは、相変わらず自分勝手(笑)な
年寄りの書いたコードがまだまだ現役で、若い人に元気がないから
じゃないのけ？
0110デフォルトの名無しさんNGNG
そもそも前提が間違っている。
ライブラリ単位ではなくプロセス単位でのオブジェクト指向なのだ。
0111デフォルトの名無しさんNGNG
>>108
データ構造とアルゴリズムをセットにして、関連のないものは別のモジュールにしましょう、
ってなことを強く言い始めたのはオブジェクト指向だね。
オブジェクト指向の場合、モジュール＝クラスかな。
でも、そんなことは構造化プログラミングでも意識すれば書けます。

gnuのコードは、「時代に合わせてよりよりコードに変えていく」という
ことをしてないから、明らかに時代遅れなんだろうね。
今の時代、「システムにはコンソールがあります」という前提のC標準ライブラリは逝って良しなんだけどさ。
011298=111NGNG
汚いCのソースって、ドキュメント性ないから嫌い。

>>110
それじゃ継承できませんぜ。
0113デフォルトの名無しさんNGNG
>>112
継承問題 >>110 もある(OSがそれをサポートすれば別だが)し、

あとプロセス単位だと重すぎるんで、汎用性が無く却下な場合が多い。

あと、これ重要だが、実行主体であるプロセスという単位だと
「メソッドを呼ぶ」つまりObjectから見ると「メソッドが呼ばれる」
という雰囲気をやりにくいってのもある。
唯一のメソッドは「プロセス起動」(笑)。
シグナル呼ぶって手も無いでもないが、メソッドの数が
最初から決められて変えられないなんてのは
OOPとしては結構寒いので大抵却下。

プロセスの「起動」って実は、Constructと
デフォルトメソッド(藁)のスタートとが
癒着してて分離できないんで、結構辛い。
main()に余計(藁)な処理をできるだけ書かずに
なんでもかんでもシグナルハンドラに書くという手も
あるだろうけど、それって嫌でしょ？
元よりOOPが似合わないモデルなんだよ、プロセスって。
0114デフォルトの名無しさんNGNG
　　　　　§
　　　　　,§､　ﾌﾟﾗｰﾝ
　　　,ｰ./ﾊ,§
　　 〈:://二§_
　　／ヽ　　ヽ　ヽ
　　|::　|::..　　|　　|
.　 |::　|:::. 　　|　　|　　　　　死んでお詫びします･･･
　 〈::　〉::　　 |　/ |
.　 |::　|::　　　ｌ　　|
.　 |::　|＿___∧＿,|
　 （((〈:::　_ /　　/)
　　　|::::　　|::　　|
　　　|:::: 　 |::　　|
.　　　|:: ＝|:::　=|
　　　 |::::　 |:: 　 |
.　　　 |:::　 ||::::　|
　　　　|＿_,||＿_|
　　　　/::__) /::__)
　　　 /　/ /ノ,/　））
　　　 ~^~　~^~
　　　＿＿＿＿
0115（　´∀｀）NGNG
>>110
>ライブラリ単位ではなくプロセス単位でのオブジェクト指向なのだ。
主語がよくわからない。
・オブジェクト指向はプロセス単位であるべきだ
・tarはプロセス単位のオブジェクト指向だ
前者なら知らん。俺は拒否（できる場合には拒否）。
後者なら、コンポーネント指向のほうがしっくりくる。
パイプで接続するってことだよね？オブジェクトとして扱っているが、
設計がオブジェクト指向だとは思えない。
0116116NGNG
>>113
>あとプロセス単位だと重すぎるんで、汎用性が無く却下な場合が多い。
重い→汎用性がない？
ここの論理展開がわかんない。どうして？

>あと、これ重要だが、実行主体であるプロセスという単位だと
>「メソッドを呼ぶ」つまりObjectから見ると「メソッドが呼ばれる」
>という雰囲気をやりにくいってのもある。
「雰囲気をやる」ってどういう意味？
ってのはおいとくとしても、全体的に意味わかんない。
プロセスをオブジェクトと見てソケットでメッセージパスするのは
なんでダメなの？
0117116NGNG
>プロセスの「起動」って実は、Constructと
>デフォルトメソッド(藁)のスタートとが
>癒着してて分離できないんで、結構辛い。
>main()に余計(藁)な処理をできるだけ書かずに
>なんでもかんでもシグナルハンドラに書くという手も
>あるだろうけど、それって嫌でしょ？

ここもよくわかんない。例外処理以外のIPCにシグナル使う人って
気が狂ってない？普通ソケット使うと思うけど。
0118Login:PenguinNGNG
でかいデータのreadなんかは細切れでループ回すと
性能が出ないんで一気にreadしてタイムアウトなどの
中断をalarmやiteimerでやる。
signalハンドラは空リターン。
あ、これも例外的な処理かもしれない。
0119デフォルトの名無しさんNGNG
きれいなソースの見本を見せてください。
0120デフォルトの名無しさんNGNG
きれいなソースの見本を見せてください。
0121Login:PenguinNGNG
ケントンプソンと署名の入ったshのソース。
AT&Tの有料ライセンス。
行儀よくはないけど、すらすらすらすら。
なんか奇麗。
0122デフォルトの名無しさんNGNG
>>121
有料ライセンスっていくらくらいですか？
0123Login:PenguinNGNG
しらない。WAREZじゃないけどソースは闇ルートだもん。
0124デフォルトの名無しさんNGNG
>>123
闇ルートって、どこで手に入るんですか？
0125デフォルトの名無しさんNGNG
>>123
闇ルートって、どこで手に入るんですか？
0126デフォルトの名無しさんNGNG
>>98=>>111のきれいなソースで勉強したいのですが
0127デフォルトの名無しさんNGNG
>>121
それ、何に付いてきました？

手元には System III のソースがあるんだけど、これは悪名高い Bourne
氏の書いた C だか Modula だか分からんコード。コードの質自体は悪く
ないが、C のソースとしてはちょっと……という代物。

>>119
BSD のソースは、わりと洗練されてる。
0128デフォルトの名無しさんNGNG
>>113
素のプロセスモデルそのままだと、辛いやね。

でもまぁ Java の RMI とか RPC みたいに、ライブラリやら何やらの手厚い
サポートがあれば、それなりにイケルと思うがどうよ？
0129111NGNG
>>126
Webでいくつか公開してるから探してごらん。
って、ヒントなしだと無理か〜。

そうだなぁ、時計みたいなライブラリとか〜。
0130デフォルトの名無しさんNGNG
>>113
単に、見立てを楽しんでいるだけなのでそのつもりで。

プロセスをオブジェクトに見立てると無理があるかもしれないけど、プロセスをメソッドに見立てるとどう?
Unixというクラスにlsやpwdのメソッドがある感覚。
呼び出しは重いけど、そこは富豪的ということで。

基本的なインターフェースは継承している(SolarisでもLinuxでもlsは使える)。
0131116NGNG
>>128
>素のプロセスモデルそのままだと、辛いやね。
>>130
>プロセスをオブジェクトに見立てると無理があるかもしれないけど

辛いとか無理があるとかってどうしてなのー？解説きぼん
継承だってコードをラップして起動すればできると思うがどうか。
実行時性能にかかわることは将来的に無視してよいファクターに
なりつつあるし、むしろコードの生産性からしたらプロセスごとに
実行環境を維持したまま単体テストができてうれしいと思うんだけどな。
ウェブサービスな雰囲気だし。
0132デフォルトの名無しさんNGNG
>>131
> 継承だってコードをラップして起動すればできると思うがどうか。

それを毎回一から実装してたら大変でしょ、って話。せめて COM 並のフレー
ムワークがないと、足回りの実装だけで疲れてしまうよ。あとはプロセス境界
を超えて動作するデバッガもね。

> 実行時性能にかかわることは将来的に無視してよいファクターに
> なりつつあるし、

それは、さすがにダウトだな。

今時の CPU は、キャッシュヒット率を高く保つことで高速動作を実現している
わけだが、プロセスを切り替えるとなるとキャッシュを別プロセスとカーネルに
侵食される（アーキテクチャによっては、プロセス切り替え時に TLB をフラッ
シュして命令キャッシュも破棄する必要アリ）ので、覿面に遅くなる。

関数呼び出しに比べたら現状 fork() & exec() は 3 桁は遅いし、RAM の動作
速度向上は CPU に比べると極めて緩やかなため、今後数年間で 3 桁の速度
差を補えるほど急激な改善が見られるとは考えにくいしね。

……とかマジレスするのは野暮ってものか。スレ違いなんで sage。
0133116NGNG
>>132
ではsage進行で。

>それを毎回一から実装してたら大変でしょ、って話。せめて COM 並のフレー
>ムワークがないと、足回りの実装だけで疲れてしまうよ。あとはプロセス境界
>を超えて動作するデバッガもね。

これは一回作ればいいだけの話でしょう。毎回作る必要はないよね？
現在の環境が整っていないだけの話で、実行時効率・コード生産性
という長期的な観点からは直接関係ないよね。

>今時の CPU は、キャッシュヒット率を高く保つことで高速動作を実現している
>わけだが、プロセスを切り替えるとなるとキャッシュを別プロセスとカーネルに
>侵食される（アーキテクチャによっては、プロセス切り替え時に TLB をフラッ
>シュして命令キャッシュも破棄する必要アリ）ので、覿面に遅くなる。

今時のMPUにはTLBを複数セット持てるイカしたアーキテクチャのものも
あるようだが、それはさておき。

>関数呼び出しに比べたら現状 fork() & exec() は 3 桁は遅いし、RAM の動作
>速度向上は CPU に比べると極めて緩やかなため、今後数年間で 3 桁の速度
>差を補えるほど急激な改善が見られるとは考えにくいしね。

関数呼出→コンテクストスイッチ、コンストラクタ→fork&execという対応から
すると、関数呼出とfork&execを比較するのはちょっと違うような気がするが、
まあそれも置いておくとして、

実際問題としてDBとか科学技術計算とかがコンピューティングパワー・
インテンシヴなことはわかるんだが、アプリケーション比でいったら
圧倒的に多いはずのビジネスアプリケーションの分野でそこまで
コンピューティングリソースを使うものってある？

むしろJavaとかがはやるご時世、生産性に超重いスタンスを置いた
開発手法を考えてみるのも面白いと思うんだがどうか。
0134116NGNG
補足。
もちろんDBがビジネス用途でないとは言わない。
DBMSは気合を入れてチューンしてもらって結構。
上で言ってるビジネスアプリってのはそれを呼び出す側の
アプリケーションのことね。
0135130NGNG
面白い、面白い。

>> プロセスをオブジェクトに見立てると無理があるかもしれないけど
> 辛いとか無理があるとかってどうしてなのー？解説きぼん

無理があると、頭から否定した表現はまずかったようですね。
プロセスと言うかコマンド呼び出しをメソッド呼び出しに見立てるのはどう?という提示をしてみただけ。

プロセス起動の重さは、リモートの関数呼び出しと比較すれば問題ないでしょう。
0136111NGNG
多態はどうなん？
lsがメッセージだとして、送り先が常にシェル一つとかいうんだったら全然ありがたくないよ。
0137デフォルトの名無しさんNGNG
>>133
> これは一回作ればいいだけの話でしょう。毎回作る必要はないよね？

汎用的なフレームワークを一回作ってしまえば、後は使いまわしできるけど、
その「汎用的なフレームワーク」を作るのが大変なんだよなぁ。とりあえず、
目の前の問題を解決するだけの仕組みなら簡単なんだが。

> 今時のMPUにはTLBを複数セット持てるイカしたアーキテクチャのものも
> あるようだが、それはさておき。

あと、プロセス識別子を TLB のエントリに突っ込んでおけるアーキテクチャ
も多いね。これだとプロセス切り替え時に TLB をフラッシュする必要がない
ので、効率的。
0138毒NGNG
汚いコードからのしか動かんこともある>原因：虫
汚いコードからのほうが早いこともある>原因：bug
重箱の隅つつくようなこと言うな。
もしかしたらきれいなコードにしたら同じ筈なのに動かんマシン出てきたりして。
0139デフォルトの名無しさんNGNG
>>138
それはバグって言うんだよ。
0140デフォルトの名無しさんNGNG
汚いコードといえばknuthのTeXだと思うが…
0141デフォルトの名無しさんNGNG
>>140
ネタ？
0142デフォルトの名無しさんNGNG
>>140
knuthが書いたコードって意味？
それともTeXに読ませるコード？
0143中途半端に速度を気にするとNGNG
コードが腐っていくよね。
0144デフォルトの名無しさんNGNG
>>116-117
>重い→汎用性がない？

確かに変な言い草だたかも。
その重さのペナルティを甘受できる限られた状況でしか
Objectと見なして使いたくはないよなぁという程度。

>プロセスをオブジェクトと見てソケットでメッセージパスするのは
>なんでダメなの？

それで渡されたMessageを、誰がどう処理します？
受けたOjbectもといProcessの、main()(から呼ばれた任意の関数)「が」
ポーリングする羽目になるんと違う？
ポーリング(Callbackモデルに対する一種のエミュレーション)を許すなら
まぁそれでもいいんだけど、ちょっとダサいよね。

それともwaitだかselectだか(詳しいことは知らぬ)で
Messageが来るまでポーリングのLoopを停止することにする？
まぁそれでもいいけど、やっぱりなんかダサイな。

こういう部分をラップするのをフレームワークにやらせる、
ってのはまぁ常套手段だけど、どうせmain()をmain()として使わないなら
最初から OSのモデルがそうなってくれても良いはず。
main()じゃなくてKernelがやってくれても良いはず。

>>130
ProcessがMethodなら、Instanceは何だと思います？
FileSystem全体が「1つの」Objectだ、くらいに考えないと
おかしなことになると思うけど、それって使い難くないっすか？
メンバ変数(藁)の数や量が天文学的に多すぎ。
やっぱりInstanceは適当に小さくないと使い難いっすよ。

ま、ディレクトリ1つを1 Instanceと見なす、っていう系を
想像してみたことなら有る(藁
ポインタはSymLinkね。リモートObjはNFS。
でもあんまり冴えた案じゃないとは思う。Toyプログラムには使えるかもだが。

>>135
>プロセス起動の重さは、リモートの関数呼び出しと比較すれば

そんなに重いのNetって？
一緒にするのは不味いだろけど、mLanなんてものが存在するらしい。
MIDI messageとかのリアルタイム音楽データをNetwork(普通のTCPの世界じゃないけど)で
やりとりしちゃう代物らしい。音楽Studioで機材間を繋ぐのに使うらしい。
つまりミリ秒オーダー。

で、それに匹敵する速さのProcess起動って、
どのOSでも見たこと無い(って俺は厨房だが)んですけど…。
0145デフォルトの名無しさんNGNG
TeXの文法の事だったりして。
あの文法は糞だけど、数式書くには他に方法ないからなぁ。
0146135NGNG
>>144
instanceはOSそのもの。
POSIXインターフェースを継承した、LinuxやSolarisというクラス。

ファイルがメンバ変数、コマンドがメソッド。
すごいfatクラスなのは、その通り。
インターネットが、巨大オブジェクトのコレクション。
リモート呼び出しもLANなんてケチなことは言わずに、地球の裏側のサーバとかの話。

まあ、見立てを楽しんでいるだけで、バカじゃないと言われれば、その通りと応えるような話です。

ディレクトリをオブジェクトに見立てるのも悪くないね。
使えるとか使えないとかいうレベルに持ち込む部分が貧乏くさいけど。
0147デフォルトの名無しさんNGNG
>>145
Amaya + MathML でどうよ？
印刷がしおしおなので、TeX か PDF へのコンバータがあればなあ。
0148116NGNG
>>144
>それともwaitだかselectだか(詳しいことは知らぬ)で
>Messageが来るまでポーリングのLoopを停止することにする？
>まぁそれでもいいけど、やっぱりなんかダサイな。

日本の将来を担うかもしれない厨房君に一つアドバイスを。
自分があまり知らない分野について自信満々な態度で語るのは
痛いことになる確率が非常に高いので控えた方がよろしい。
ネットワークプログラミング全般について勉強してから
もう一度いらっしゃい。
0149デフォルトの名無しさんNGNG
>自信満々な態度で語るのは

へりくだっていても駄目な内容なら駄目(藁

それに控えたら厨房は厨房のままだから
十分に殴ってあげとけ。
それで生き残った奴だけ相手にすればよい。

>ネットワークプログラミング全般

「あんたが言う」それって、OldType技術か？(藁

っていうかあんた(名前を信じるならば)116なのか？
＞プロセスをオブジェクトと見てソケットでメッセージパスする
っていう眠い話を書いてた当人なのか？(藁

いや、話自体は眠くはないんだけどね。アメーバとかの話だと思えば。
■ このスレッドは過去ログ倉庫に格納されています