>>592
具体的なことをかいてくれないとかけなだろ。
大体位置から書かないといけないわけじゃないし。

Cでいいとか言っている連中は昨日今日Cを覚えたばかりで
うれしくなってる厨房だから相手にしなくていいよ。
彼らももうちょっと成長してトイプログラムでないプログラムを書くよう
になれば設計のよしあしの判断がつくかもね。

残念なことに設計のよしあしがわかりだしたらEmacsはダメなことがわかっちまうな

>>603
それはどうかな？
世の中にはUNIXだけじゃなくてlispという設計思想も
十分な地位を得ていると思うぞ。

「通信網の費用比性能は1年で倍になる。通信網の性能比費用は1年で半分になる。」
本当にこんな事を言ったんだろうか。
あんまり将来を予見する能力はないのかもしれないね。

「ビルジョイの法則はジョークのつもりだった。
こんなに広まると分かっていたら言わなかったのに」

emacsに拡張性があったらフォークしてないだろ

>>590
> 性能を追求したい場合も、モノリシックな設計よりは、モジュール化されていた
> ほうが良いに決まっている。(エディタではないが)apacheのように

意味がわからん。

性能の具体的な例で言えば、モノリシックカーネル＞＞＞＞マイクロカーネルだぞ。
モジュール化を進めることで、よぶんなオーバヘッドが生じるていういい例だ。

実際には、モジュール化によるメンテナンス性の良さと性能のトレードオフで
ハイブリッドなんつーのもでてくるわけで。

もの知らないにも程がある。

>>595
> 長さを特に限定しない文字列処理を
> Cで書いてみろよ。面倒くさいから。

うーむ、まともに返事書くのもアフォらしい・・・

まぁ、2chにはまともな話できるヤツはいないんだな・・・。

>  emacsに拡張性があったらフォークしてないだろ
vimなんかそれこそ「今の構造じゃKDEにポーティングできません」
てんでyzisが始まったわけだが。

>>608
書き方が悪かったかな。
確かに性能を拡張性、保守性を犠牲にしてまで追求するなら
モノリシックな設計になるだろうが、実のところテキストエディタで
モノリシックな設計にすることで獲得できる可能性がある微妙な性能上の
優位など、ほぼ問題にもならず、むしろ拡張性や保守性のほうが
はるかに重要だから、モジュラリティを重視すべきだ、という主張なのね。

OSカーネルについて今更誰もが知っていることを教えてもらわんでも
よろしい。

>>609
事実だろ。めんどうくさいのは。

Perlで
$s =~ s/\bint\b/long/g;
とか書けるようなおよそ単純で下らない仕事に、Cで何行費やすと思ってんだ
試しに書いてみそ。

テキストエディタは何しろテキストを扱うんだから、
カスタマイズするとしたら、テキストをいじくるコードがどうしても
大量に出てくるだろ。

char* s = substitute(s, "\\bint\\b", "long", GLOBAL);

>>615
それはsubstitute()という関数が利用可能と仮定しての話だな。
この場合は静的な置換だからおｋだが、Perlならeフラグを使うようなケースでは
あっさり破綻するな。

char*s = substitute(s, "\\bint\\b", "long", GLOBAL|EVAL, eval_func);
こんな感じかな。perlのeフラグ知らんけど。

>>617
おいおいｗ
静的な置換じゃないんだから、引数"long"はないだろう。
それと、そのインタフェースはGCを仮定してるのか？
誰がメモリを確保して、誰が破棄するんだ？

Cの基礎から教える気はない

>>619
検索置換の過程でeval_func()は恐らくメモリを確保する必要があるし、
substitute()は何度も文字列を切り貼りする過程でやはりメモリを
確保する必要がある。
ついでに、そのsubstitute()とやらはその例ではリテラルを引数に取っているが、
スタックやヒープに確保された文字列を引数に取ることもあるだろう。
それを必要なら誰かが一貫性を持って解放してやらなきゃいかんのがCだ。

そうだな、Cの基礎だよ。

yzisてなんだろ。明日ぐぐってみる

eval_func()は「必ず」ヒープ上に確保した文字列を返す。また、内部的に
使用したメモリはfree()する。
substitute()はeval_func()の返した文字列をfree()する。
また、内部的に確保した文字列はfree()するが、呼び出し側から与えられたものと
戻り値はfree()しない。
　　：
といった類のコンベンションが必要かな。恐らくは。そして誰もがそれに
従わなければならないが、コンパイラによってそれはチェックできないし、
場合によってはメモリリークするだけなので、原因の追究が難しいこともある。
無論C++ならずっとことは楽だし、CでもGCを使うなら随分マシだが。

そして、そこまで頑張ったとしても、malloc()やstrlen()使いまくりのコードで、
大して早くも無いのだろう。

>>620
当たり前のこと並べられても、あなたが何がいいたいのかさっぱりワカラン。

>>623
いや、面倒くさいだろ？というだけだが。
それが面倒だと思わないのなら、あんたとは全く感性が合わないな。
C++でさえなく、Cを使いたいようなドメインもあるだろうが、
テキストエディタでの文字列処理は、明らかにそうではない。

>>622
なんとなくこのレスだけ読んだ感想なのだが。

eval_func()の仕様は聞いてる限り、別段悪い仕様とは思えない。
何が不満だったのかな？もしくは、どういう仕様のせいであなた
がハマッテ時間を費やしたのかな？

>>624
面倒くさいと思うならば、面倒くさくないような工夫を考えたほうがいい。
いま扱っているバッファ領域を超えてアクセスしてしまわないかとか
毎回気をつけるくらいだったら、気をつけなくてすむ仕組みを考えた
方がいい。

その仕組みは別にCだからできないということはない。

>>625
いや、「Cでは当たり前」であっても、エラーを起こしやすいよ。
たかがエディタのカスタマイズのためにいつも書きたい類のコードではない。

>>626
残念ながら、それはC++ほど上手くはできん。
GCやapacheのpoolのようなものを使えばかなりマシにはなるが、
そこまでしてCに固執する理由がわからんよ。

世にこんだけバッファオーバーフローが原因のセキュリティホールが
溢れかえってるのがCの問題の傍証と言えるんじゃまいか。

>>628
別に言語に固執しているわけじゃない。が、言語にとらわれないように
したほうがいい。あの言語だからこれはできない！んじゃなくて、
あの言語でもこうすればなんとかなる、という考え方をしたほうが
いいんじゃない。

これから先、自分の好きな言語でスクラッチから書ける仕事ばかりでは
ないのだから。他人の書いたコードをメンテナンスする仕事もたくさん
ある。

言語に固執する理由はないが、その場その場で工夫できる力をつける
のは大事だ。まぁ、ネル・・ｗ

>>630
俺は一言も「出来ない」とは言ってない。
「エラーを起こしやすい」「面倒くさい」と言ってるだけだぜ。
そうしたことが、結局はソフトウェアの品質にも繋がってくる。
頑張ればCでもC++でSTLやboostを駆使したコードと同じ機能を
達成できるかもしれんが、はるかに大量の無駄な労力を必要とするし、
デバグも大変になる。より高級な言語を使っていれば、より
マシなことにその労力を費やすことが出来る。

必要なら俺はCのコードも書く。だが、何も好き好んで、向いていない
ドメインでCを選ぶ必要は無いだろうと言っている。
無駄な説教だな。

>>631
寝れなくなりそうだが・・これ書いたら絶対寝る！（たぶん・・・

＞頑張ればCでもC++でSTLやboostを駆使したコードと同じ機能を
＞達成できるかもしれんが、はるかに大量の無駄な労力を必要とするし、

別段ライブラリなんて、一回書けばその後その会社でずっと再利用
可能なものなんよ。初期投資なんてたかがしれてるっつーの。

＞必要なら俺はCのコードも書く。だが、何も好き好んで、向いていない
＞ドメインでCを選ぶ必要は無いだろうと言っている。

Cがメインのドメインなんて、いくらでも存在するわ。
組み込みの世界に行けば、Cが許されずにそのCPUのアセンブラオンリー
の環境もいくらでもある。

あんな、計算機の性能があがって高級言語がどんどん広まるってのは
その通りだと思う。しかし、全部の会社が同じようなCPU使って、同じような
言語つかって、差別化はアイディアでなんとかします！で、うまくいくと思うのか？

実際はそうじゃないんだよ。会社ごとに得意な分野があって、それぞれ得意な
分野で使用メモリ量削減とか、消費電力削減に血眼になってるわけだ。
あなたがいってるのは、オナニーにしかすぎないわけだ。

かなり本題とはずれてきたが・・・。

>>632
なんつうか君、C++使ったこと無いだろ。
CでC++のSTLやboostレベルの「ライブラリ」を書くのは「不可能」なんだよ。

で、「テキストエディタ」の話をしてるのに、何で「組込み」の話が
出てくるんだ。アホじゃないの？

>>633
＞CでC++のSTLやboostレベルの「ライブラリ」を書くのは「不可能」なんだよ。

不可能とか言ってるお前の脳みそに乾杯だわ・・・。

>>634
あのな。クラスもコンストラクタもデストラクタも例外もテンプレートも継承も無い
言語で、どう同じ機能を実現するんだよ。
デストラクタが無いから明示的にfree()だのclose()だのが必要になるんだろ。


ここまでのアホは久々に見たわ。

>>635
どうやったら、実現できるか夏休みの宿題にしとくわ・・

例えばスコープ抜けた時に自動的にデストラクタを呼ぶようなコードを
C++コンパイラは挿入する。
それに似た機能をもつ特殊なCコンパイラを書けば可能だろうが、それはもはや
「C」ではない。
そうでなければ、明示的にプログラマがデストラクタ相当物を呼ぶコードを書く
しかなく、それは当然C++に比べてエラーを生みやすく使い勝手も悪いものになる。

すげぇな。Cでライブラリ書けばC++の真似ができると思ってる奴がいるのか

そんなら、C++なんて要らないだろｗ

うんうん。Cで書けば何でもCだな。
そういえばclispとかcpythonとか云うもんな



　　　　　　 　 /＼＿＿/＼
　　　　　　 ／ ,,,,,　　　 ,,,,, ::＼
　　　　　　 |　（●） ,､ （●）　::|
　　　　　　 |　　 ノ(,＿.)ヽ　　.::|　　 ＋
　　　　　　 |　　　 -==-　　　.::|　+
　　　　　　 ＼＿　`--'　＿_／　　　　+
　r､　　　 　r､／ヾ ￣　下ヘ
　ヽヾ　三　|:l1､＿ヽ___/__ .ィヽ
　　＼>ヽ/ |｀ ｝　　　 　 n_n|　|
　　　ﾍ　lノ `'ｿ 　 　 　 lﾟωﾟ|　|
　　　　/´　 /　　　　　　 ￣|.　|
　　　　＼. ｨ 　 ＿＿＿＿　|　 |
　　　 　 　 |　ﾉ　　　　 　　l | 　|

ﾅｲﾅｲｗ

Emacsならlispで書けることもCで書いて、バグがあったら即セグフォか。

え、Vimは落ちたことないって？
そりゃまあBramさんたちが多大な労力を払ってテストしてくれてるんでしょう。
お客さん面したユーザにはどうでもいいことでしょうがねｗ

>>640
セグフォるタイプのバグならまだマシな部類だ。すぐに露見するからな。
リークだのバッファオーバーフロー（の可能性）だのは一見動いているように
見えるから始末が悪い。

こりゃ単なる釣りでしょ。
話そらずばかりで
エディタの拡張にCを使うのは馬鹿らしいという反論には直接答えてない。

Cでいいっつってる奴は20年前で脳みそが止まってるんだろｗ
今時必要も無いのに何でもアセンブラで書こうとする奴はただのアホだが、
Cについても同じことが言える。

ところでVim7のmatchparen機能だが、これはCでハードコーディングするんじゃなくて
Bramが直々にVimスクリプトで書いてるんだよな。
なんか珍しい。

>>637
> それは当然C++に比べてエラーを生みやすく使い勝手も悪いものになる。
それはあなたの思い込みでしかないわけ。

これ以外にレスする価値があるものなんてまったくないが(>>637-643な)。
下のはアフォすぎて、あきれたのでレスしとく

> エディタの拡張にCを使うのは馬鹿らしいという反論には直接答えてない。
アフォ

> Cでいいっつってる奴は20年前で脳みそが止まってるんだろｗ
何度も繰り返すが、「もの知らないにも程がある」

まぁ、気が向いたらまたレスするわ

↑
こういうアホが居るから世の中からデスマやセキュリティホールが消えないんだね

まともに反論できないから、「アフォ」を連呼するだけになったな。
詭弁の特徴のガイドラインで言うところの「知能障害を起こす」って奴だ。

さだめしシェルスクリプトでいいものもCで書き、PerlやphpのCGIでいいものも
ASAPIやNSAPIで書いているんだろう。
ツールボックスアプローチの理念なんて一切理解して無いんだろうな。

>>647
と、思いたいのですね＾＾

#!/usr/bin/sh と書かれたCGIがほとんど配布されてないのは
なぜですか？

普通は#!/bin/shだからじゃないですかね。
そういうCGIなら俺の手元にありますよ。