[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 601- 2chのread.cgiへ]
Update time : 05/09 10:26 / Filesize : 146 KB / Number-of Response : 696
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

Vim vs Emacs (Editor War)



1 名前:Anonymous [2001/03/07(水) 05:45]
とりあえず、Vim ラブラブです。Emacs なんぞ、「腱鞘炎で病院
いってから出社します。」といった、いいわけにしか使えない。

552 名前:名無しさん@お腹いっぱい。 [2007/07/21(土) 17:31:23 ]
コーディング、コンパイル、コンパイルエラー修正

までの作業はVimもEmacsもそれほど変わらんのじゃない?
今のVim以上の機能ってどんなんだろ。

デバッグ作業はエディタよりも、IDEで視覚的にやったほうが
はるかに効率いいし。

タグ補完、タグジャンプ(定義先に飛んだり、また戻ったり)、includeファイル
からの補完、行補完、コメント行を指定幅で自動整形、makeからエラーが
起きた箇所への自動ジャンプ、インクリメンタル検索、検索語ハイライト、
アンドゥ履歴

ぱっと思いつくだけで、Vimには上の機能はある。Emacsにもあると思うが。

俺はコーディングの際の非モーダルエディタのめんどくささが嫌いだから
Vim派だが。

553 名前:名無しさん@お腹いっぱい。 [2007/07/21(土) 17:37:22 ]
もちろん複数ウィンドウ表示もある。最近では、GUIタブやdiff機能なんてのも
あるな(使ってないが)。

Vimに実装して欲しい機能のアンケート結果が下記ページにあるが、この中に
EmacsにあってVimにないものが含まれてるかもしれないな(すでにVim7に
入ってるのもあるが。GUIタブとか、vimgrepとか)。
www.vim.org/sponsor/vote_results.php

個人的にはこれがほしい
make it possible to use Vim as a plugin in Eclipse

554 名前:名無しさん@お腹いっぱい。 mailto:sage [2007/07/21(土) 23:12:50 ]
vimに追加してほしい機能。
elispの様に自分で自由に機能拡張できるようなスクリプト言語の導入。
Vimにもスクリプトあるみたいだけど、
elispほど自由度は高くないし、使いやすいとはいい難いと思う。
独自言語とか扱う場合、どうしても自分でメジャーモードとか
lispでつくる必要がでてくる。
はじめVim使ってたけど、これだけのためにemacsを使い始めた。
Vimの方が動作が軽快なのは好きだけど。

555 名前:名無しさん@お腹いっぱい。 mailto:sage [2007/07/22(日) 01:48:03 ]
>>554
違う。自由に機能拡張できるようなスクリプト言語の導入では
決してEmacsのようにはならない。
そのスクリプト言語で全てを実装しないとEmacsのような高い
拡張性は得られないのだ。

556 名前:名無しさん@お腹いっぱい。 mailto:sage [2007/07/22(日) 02:15:41 ]
Emacs は殆ど C で書かれていたと思ったけど

557 名前:名無しさん@お腹いっぱい。 mailto:sage [2007/07/22(日) 02:22:22 ]
VimもほとんどCで書かれているからいっしょだね。

558 名前:名無しさん@お腹いっぱい。 mailto:sage [2007/07/22(日) 08:55:14 ]
emacsはlispインタプリタといくつかの基本関数だけCで
それ以外はlispで書かれてる。

559 名前:名無しさん@お腹いっぱい。 [2007/07/22(日) 10:42:58 ]
どうも理解出来ないのが、Emacs使いのLispみたいな拡張スクリプトが
ないといや、っていう主張なんだよな。

スクリプトなんかじゃなくて、Cソースそのものを変更すればいいじゃない。
んで、自分でいいと思うならそれを本家に反映するように努力すれば
いい。

560 名前:名無しさん@お腹いっぱい。 [2007/07/22(日) 10:49:14 ]
過剰要求・思考偏重・視野狭窄もまたEmacs使いの特徴なのです。



561 名前:名無しさん@お腹いっぱい。 mailto:sage [2007/07/22(日) 10:50:50 ]
それだと、手間かかりすぎでしょ。
emacsを開発することが目的ではなくて、
emacsを使用して仕事をするのが目的。


562 名前:名無しさん@お腹いっぱい。 [2007/07/22(日) 11:05:50 ]
>>561
仕事する目的なら、別にEmacs Lispのようにフルカスタマイズできない
といや!っていう主張は矛盾してないか?

563 名前:名無しさん@お腹いっぱい。 mailto:sage [2007/07/22(日) 11:23:55 ]
elispを書いて楽しむこともEmacsを使う目的に入っている
に決まってるじゃないか。

564 名前:名無しさん@お腹いっぱい。 [2007/07/22(日) 11:39:23 ]
>>563
Elispを書いて楽しむことと、仕事は直接は関係ないわな。

仕事が目的であれば、それを達成する手段はElispであっても
Vimのスクリプトであってもどっちでもいいわけで。

565 名前:名無しさん@お腹いっぱい。 mailto:sage [2007/07/22(日) 11:42:27 ]
そうそう、Vimで足りるような仕事しかしないのなら
Vimでいいんじゃないですかねぇ?

566 名前:名無しさん@お腹いっぱい。 [2007/07/22(日) 11:47:55 ]
>>565
意味がわからん・・・Emacsでないとできない仕事ってなんだ?

というかエディタだけでやらないといけない仕事ってなんだ?

567 名前:名無しさん@お腹いっぱい。 mailto:sage [2007/07/22(日) 12:06:53 ]
ま、Emacsでないとできないという仕事はないかもね。
結局はテキスト編集だから。確かにviでもgeditでもできますよ。
インデントはC-tとC-dを駆使して、サスペンドしてmakeして
ジョブ制御を駆使して行番号を見てエラー行にジャンプしても
Emacsを使ったのと同じプログラムが書けますね。
それで満足ならviでいいんじゃないですかね。

568 名前:名無しさん@お腹いっぱい。 mailto:sage [2007/07/22(日) 12:15:58 ]
>>554 の様に、独自言語を使わないといけない場合とかに、
elispだとメジャーモードとかが比較的楽にできる。
この、メジャーモードとかを作ったりするのになるべく時間をかけたくない。
vimのスクリプトではきつくない?


569 名前:名無しさん@お腹いっぱい。 [2007/07/22(日) 12:24:19 ]
>>567
Vimのことまったく知らないのはよくわかったが、せめて>>552で書いたVimの機能
にくらいは目を通してくれ。

自動インデント機能ももちろんあるし、範囲選択して'='コマンドおせばインデント
されていないものでも自動でインデントしてくれる。インデント用の言語も
C,Perl,Java,Ruby,...数え切れないくらいだ。それから、構文ハイライトで
言語の構文を色付けしてくれるし、括弧が足りなかったりするのも一目瞭然。

makeからエラーが起きた場所に自動で飛ぶ機能もある。Vimで':make'コマンド
実行するだけ。

elispのメジャーモードって何のことかわからないのが、独自言語のインデントだっ
たり構文ハイライトだったら、設定ファイル書くだけ。

570 名前:名無しさん@お腹いっぱい。 mailto:hage [2007/07/22(日) 12:46:59 ]
> elispのメジャーモードって何のことかわからないのが、独自言語のインデントだっ
> たり構文ハイライトだったら、設定ファイル書くだけ。
あんたも、ぜんぜん emacs のことまったく知らないじゃん。




571 名前:名無しさん@お腹いっぱい。 mailto:sage [2007/07/22(日) 15:08:18 ]
Vimに自分を合わせる気がないならVim使わないことだね


カナ入力と同じで慣れればローマ字入力より効率良いけども
慣れる気がないなら全く魅力を感じないみたいな

572 名前:567 mailto:sage [2007/07/22(日) 16:24:11 ]
>>569
Vimの機能についてはよく知ってるよ。
Vimとvi、ちゃんと区別して書いてるんだからちゃんと読んでくれ。
じゃあVimで:makeしたとしよう。
次にある単語を検索しようと思い、:grepしたとしよう。
さて、:makeしたときのエラーリストはどこへいってしまったのだろう。
Vim7でlocation listというのが追加されたけど、ウィンドウごとに
1つというまったく意味不明な仕様だよね。
ウィンドウごとに:grepと:makeのどちらか片方しかするなというのだろうか。

573 名前:名無しさん@お腹いっぱい。 [2007/07/22(日) 18:31:23 ]
>>570
まぁ、Emacsのことはあまりしらないが、「elispのメジャーモードうんぬん」
っていうEmacsの専門用語使わずに「Vimでこんなことできる?」って聞いて
くれたほうがありがたい。

574 名前:名無しさん@お腹いっぱい。 [2007/07/22(日) 18:34:14 ]
>>572
> Vimとvi、ちゃんと区別して書いてるんだからちゃんと読んでくれ。

Vimとviの違いをわかった上で、「Vim vs Emacs」というスレで「vi vs Emacs」
の構造に仕立て上げようとしてるのはさらにタチが悪い。

> じゃあVimで:makeしたとしよう。
> 次にある単語を検索しようと思い、:grepしたとしよう。
> さて、:makeしたときのエラーリストはどこへいってしまったのだろう。

これには若干不満を感じることもなくはない。それほど大きな不満ではないが。
Emacsでは区別されてるの?

575 名前:名無しさん@お腹いっぱい。 mailto:sage [2007/07/22(日) 21:08:24 ]
>>559
>スクリプトなんかじゃなくて、Cソースそのものを変更すればいいじゃない。

俺もそう思う。何が悲しくて劇遅のスクリプト言語で手足縛られながら
機能追加せにゃならんのかと。

576 名前:名無しさん@お腹いっぱい。 mailto:sage [2007/07/22(日) 22:45:25 ]
全然遅く感じないけどな。


577 名前:名無しさん@お腹いっぱい。 mailto:sage [2007/07/22(日) 22:53:39 ]
おまえら:colder

578 名前:名無しさん@お腹いっぱい。 mailto:sage [2007/07/22(日) 22:55:19 ]
一つのエディタをあまりに使いこなしすぎると離れがたくならんか
未だにVZを越える環境が見つからんとか言ってる元MS-DOSユーザを見てると
哀れになるよ

579 名前:名無しさん@お腹いっぱい。 mailto:sage [2007/07/22(日) 22:57:09 ]
Vim使いだけど、一時期Emacs使ってて思うこと。
俺はCはできてて、Emacs使い始めてElispをちっとかじってみた。
わざわざElisp覚えるよりも、今できるCで何か作ったほうが早いなと。

だから、別に何かを否定しなくても自分が好きならそれでいいじゃん

580 名前:名無しさん@お腹いっぱい。 [2007/07/22(日) 23:14:51 ]
>>578
VZを越える環境というか、今はWindows用にWZエディタがあるんじゃ
ない。別にWZ使いを否定するわけじゃない。事実うちの会社には
WZ使いで素晴らしい生産性をあげるプログラマいるしな(デバッグ
能力は高いとはいえないが)。

まぁエディタは開発のごく一部の生産性をあげるものにしかすぎない
わけで。別に一つのエディタから離れられなくなっても、その
エディタが使えない状況というのは、工夫すればそんなにない。

いまやLinux版WZエディタもあるんだぜ。別にネーティブにこだわら
なくてもすきなプラットフォームで編集して、その後にアップロード
なりなんなりすればいい。



581 名前:名無しさん@お腹いっぱい。 mailto:sage [2007/07/22(日) 23:21:51 ]
>>559 >>575 >>579
お前らVimに対してトリビアルでない変更をしたことがないのが
バレバレですよ。

582 名前:名無しさん@お腹いっぱい。 [2007/07/22(日) 23:25:33 ]
>>581
kwsk

583 名前:名無しさん@お腹いっぱい。 mailto:sage [2007/07/23(月) 04:53:17 ]
Emacsを批判するのにモードも知らんなんて始めから勝負あったな。w
いや、それじゃ余りに馬鹿すぎるから釣りかもしれないが。
しかし理由lispが面倒だからCで書くとか馬鹿すぎるw
お前らだってワンライナーをPerlで書いたりするだろ。
くだらん操作とか極めて特殊な操作をCで書いて
しかもエディタに組み込んだりしたら悲惨な事になるのは目に見えてる。


584 名前:名無しさん@お腹いっぱい。 [2007/07/23(月) 23:39:22 ]
>>583
Vimにもマクロはあるし、スクリプトもあるし、ちょっとした面倒な
作業ならいとも簡単に自動化できるわけで。Elispみたいにフルカスタマイズ
したいとこまでいくなら、じゃぁCソース直せばいいやん、ってことに
なるって話。

585 名前:名無しさん@お腹いっぱい。 [2007/07/23(月) 23:40:23 ]
Emacsのメジャーモードちとぐぐってみたが、別にVimでも
簡単にやれそうだ。

586 名前:名無しさん@お腹いっぱい。 mailto:sage [2007/07/23(月) 23:50:05 ]
つまんない対抗意識で素人発言連発は恥ずかしいよ。

587 名前:名無しさん@お腹いっぱい。 [2007/07/24(火) 00:03:15 ]
>>586
何の情報も出していないレスを書くほうが、俺にはよっぽど
恥ずかしいと思えるが。

588 名前:名無しさん@お腹いっぱい。 mailto:sage [2007/07/24(火) 00:23:08 ]
以前ちょっとだけvimを使ってたけど今はemacs使ってる。
vimのCのソースコードを直すとかいってる人って、
vim本体のコードのこと言ってるの?
それとも、本体とは別にCでマクロ動作をかけるってこと?
本体のコードを修正するっていう意味だったら、実用的じゃないと思うけど。
ちょっとした動作修正のためにそんなこといちいちやってられない。
それに、Cで動作書くのってあらかじめ関数が用意されてないと、かなり大変だと思うよ。

lisp嫌ってる人も多いけど、できるようになると括弧も苦じゃなくなる。
境界を越える: Lisp の美しさ
www-06.ibm.com/jp/developerworks/java/library/j-cb02067.shtml

589 名前:名無しさん@お腹いっぱい。 [2007/07/24(火) 00:33:43 ]
>>588
いやいや、ちょっとしたことをさせたいなら、Vimのマクロもあるし
スクリプトもあるって話・・・。Perlインタフェイスや、Rubyインタフェイス、
Pythonインタフェイスなどなどもある。なんでもかんでもソースなおせ!
といってるわけじゃないってことは、理解して欲しい。

んで、ちょっとしたことなら、Elispのようにフルカスタマイズできなくても
別にできるよ、というお話。でも、Emacs使いはElisp並にカスタマイズ
できないといや!と主張してるわけ。

ちょっとしたことじゃなく、根本を変えたいというならCソースその
ものを修正したらいいじゃない、というのがVim使いの俺の主張な
わけだが、理解してもらえるだろうか。

590 名前:名無しさん@お腹いっぱい。 mailto:sage [2007/07/24(火) 01:26:05 ]
実にどうでもいいが、カスタマイズ範囲は広いに越したことは無いだろ。
性能を追求したい場合も、モノリシックな設計よりは、モジュール化されていた
ほうが良いに決まっている。(エディタではないが)apacheのように、
あるいはeclipseのプラグインのようにね。
無論モジュールはスクリプトでも書けて、Cのモジュールの動作が気に食わない
場合は、スクリプトで置換えられるようになっているのが望ましい。

Vimがあまりにモノリシックなのは問題じゃないのかな。
winampに対するfoobar2000のような、より良い後継者が現れることを望む。



591 名前:名無しさん@お腹いっぱい。 mailto:sage [2007/07/24(火) 06:05:11 ]
スクリプト言語インターフェイスって、コンパイル時に有効にしないと
使えないじゃん。
だからそれを使って書かれているVimスクリプトも少ないだろ。
それに何種類もあることに意味あるの?
結局1種類の言語だけを標準で内蔵したほうがいいだろ。
つまりemacs lispみたいに。

592 名前:名無しさん@お腹いっぱい。 mailto:sage [2007/07/24(火) 06:54:22 ]
> 実にどうでもいいが、カスタマイズ範囲は広いに越したことは無いだろ。
C言語でいいじゃん

593 名前:名無しさん@お腹いっぱい。 mailto:sage [2007/07/24(火) 07:12:23 ]
yzisに期待・・・してももうダメなのかな?

594 名前:名無しさん@お腹いっぱい。 mailto:sage [2007/07/24(火) 09:29:28 ]
>>589
フルカスタマイズだからこそ、ちょっとした拡張で結構な事ができるんじゃないか。
労力がチョットなのと、できる事がちょっとなのは違う。
vimはチョットした事を出来るマクロ。
Emacsはちょっとした事でできるlisp。


>>591
むしろ、複数あるより一つの方がelispみたいに
膨大な遺産が蓄積されて便利だと思うね。
全部自分で作るなら種類があった方が良いけど。


595 名前:名無しさん@お腹いっぱい。 mailto:sage [2007/07/24(火) 10:08:26 ]
>>592
馬鹿ほどこういうことを言うんだよな。
いっぺんGCライブラリなどを使わずに、長さを特に限定しない文字列処理を
Cで書いてみろよ。面倒くさいから。

596 名前:名無しさん@お腹いっぱい。 mailto:sage [2007/07/24(火) 10:11:43 ]
>>594
インタフェースがwell-definedで、どの言語で書かれたモジュールからも
他の言語で書かれたモジュールが使用できるのなら、言語は問題ではないし、
全てが「資産」になるよ。

597 名前:名無しさん@お腹いっぱい。 mailto:sage [2007/07/24(火) 10:31:27 ]
Vim.NETで。

598 名前:名無しさん@お腹いっぱい。 mailto:sage [2007/07/24(火) 10:43:18 ]
>>596
それをチョット改造するのも違う言語で出来るなら別に良いけどな。

599 名前:名無しさん@お腹いっぱい。 mailto:sage [2007/07/24(火) 13:53:15 ]
emacsの拡張性が生きる場面ってあるの?
っていうか拡張性あるの?

600 名前:名無しさん@お腹いっぱい。 mailto:sage [2007/07/24(火) 16:55:55 ]
エディタは効率的に編集するためにあるんだからさ、
Cでやれといってる馬鹿は自分で入力する予定のテキストまで
Cでハードコーディングするといいよ。



601 名前:名無しさん@お腹いっぱい。 mailto:sage [2007/07/24(火) 18:22:52 ]
>>592
具体的なことをかいてくれないとかけなだろ。
大体位置から書かないといけないわけじゃないし。

602 名前:名無しさん@お腹いっぱい。 mailto:sage [2007/07/24(火) 18:28:41 ]
Cでいいとか言っている連中は昨日今日Cを覚えたばかりで
うれしくなってる厨房だから相手にしなくていいよ。
彼らももうちょっと成長してトイプログラムでないプログラムを書くよう
になれば設計のよしあしの判断がつくかもね。

603 名前:名無しさん@お腹いっぱい。 mailto:sage [2007/07/24(火) 18:38:50 ]
残念なことに設計のよしあしがわかりだしたらEmacsはダメなことがわかっちまうな

604 名前:名無しさん@お腹いっぱい。 mailto:sage [2007/07/24(火) 19:36:50 ]
>>603
それはどうかな?
世の中にはUNIXだけじゃなくてlispという設計思想も
十分な地位を得ていると思うぞ。

605 名前:名無しさん@お腹いっぱい。 mailto:sage [2007/07/24(火) 19:48:42 ]
upload.wikimedia.org/wikipedia/commons/a/a3/Bill_Joy_and_Paul_Saffo.jpg

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

606 名前:名無しさん@お腹いっぱい。 mailto:sage [2007/07/24(火) 20:45:31 ]
「ビルジョイの法則はジョークのつもりだった。
こんなに広まると分かっていたら言わなかったのに」

607 名前:名無しさん@お腹いっぱい。 mailto:sage [2007/07/24(火) 21:30:53 ]
emacsに拡張性があったらフォークしてないだろ

608 名前:名無しさん@お腹いっぱい。 [2007/07/25(水) 00:02:07 ]
>>590
> 性能を追求したい場合も、モノリシックな設計よりは、モジュール化されていた
> ほうが良いに決まっている。(エディタではないが)apacheのように

意味がわからん。

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

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

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

609 名前:名無しさん@お腹いっぱい。 [2007/07/25(水) 00:07:49 ]
>>595
> 長さを特に限定しない文字列処理を
> Cで書いてみろよ。面倒くさいから。

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

610 名前:名無しさん@お腹いっぱい。 [2007/07/25(水) 00:08:48 ]
まぁ、2chにはまともな話できるヤツはいないんだな・・・。



611 名前:名無しさん@お腹いっぱい。 mailto:sage [2007/07/25(水) 00:26:47 ]
>  emacsに拡張性があったらフォークしてないだろ
vimなんかそれこそ「今の構造じゃKDEにポーティングできません」
てんでyzisが始まったわけだが。

612 名前:名無しさん@お腹いっぱい。 mailto:sage [2007/07/25(水) 00:33:47 ]
>>608
書き方が悪かったかな。
確かに性能を拡張性、保守性を犠牲にしてまで追求するなら
モノリシックな設計になるだろうが、実のところテキストエディタで
モノリシックな設計にすることで獲得できる可能性がある微妙な性能上の
優位など、ほぼ問題にもならず、むしろ拡張性や保守性のほうが
はるかに重要だから、モジュラリティを重視すべきだ、という主張なのね。

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

613 名前:名無しさん@お腹いっぱい。 mailto:sage [2007/07/25(水) 00:48:12 ]
>>609
事実だろ。めんどうくさいのは。

614 名前:名無しさん@お腹いっぱい。 mailto:sage [2007/07/25(水) 00:55:55 ]
Perlで
$s =~ s/\bint\b/long/g;
とか書けるようなおよそ単純で下らない仕事に、Cで何行費やすと思ってんだ
試しに書いてみそ。

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

615 名前:名無しさん@お腹いっぱい。 mailto:sage [2007/07/25(水) 01:01:56 ]
char* s = substitute(s, "\\bint\\b", "long", GLOBAL);

616 名前:名無しさん@お腹いっぱい。 mailto:sage [2007/07/25(水) 01:11:45 ]
>>615
それはsubstitute()という関数が利用可能と仮定しての話だな。
この場合は静的な置換だからおkだが、Perlならeフラグを使うようなケースでは
あっさり破綻するな。

617 名前:名無しさん@お腹いっぱい。 mailto:sage [2007/07/25(水) 01:14:31 ]
char*s = substitute(s, "\\bint\\b", "long", GLOBAL|EVAL, eval_func);
こんな感じかな。perlのeフラグ知らんけど。

618 名前:名無しさん@お腹いっぱい。 mailto:sage [2007/07/25(水) 01:17:40 ]
>>617
おいおいw
静的な置換じゃないんだから、引数"long"はないだろう。
それと、そのインタフェースはGCを仮定してるのか?
誰がメモリを確保して、誰が破棄するんだ?

619 名前:名無しさん@お腹いっぱい。 mailto:sage [2007/07/25(水) 01:22:32 ]
Cの基礎から教える気はない

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

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



621 名前:名無しさん@お腹いっぱい。 [2007/07/25(水) 01:37:01 ]
yzisてなんだろ。明日ぐぐってみる

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

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

623 名前:名無しさん@お腹いっぱい。 [2007/07/25(水) 01:44:36 ]
>>620
当たり前のこと並べられても、あなたが何がいいたいのかさっぱりワカラン。

624 名前:名無しさん@お腹いっぱい。 mailto:sage [2007/07/25(水) 01:46:54 ]
>>623
いや、面倒くさいだろ?というだけだが。
それが面倒だと思わないのなら、あんたとは全く感性が合わないな。
C++でさえなく、Cを使いたいようなドメインもあるだろうが、
テキストエディタでの文字列処理は、明らかにそうではない。

625 名前:名無しさん@お腹いっぱい。 [2007/07/25(水) 01:47:34 ]
>>622
なんとなくこのレスだけ読んだ感想なのだが。

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

626 名前:名無しさん@お腹いっぱい。 [2007/07/25(水) 01:49:36 ]
>>624
面倒くさいと思うならば、面倒くさくないような工夫を考えたほうがいい。
いま扱っているバッファ領域を超えてアクセスしてしまわないかとか
毎回気をつけるくらいだったら、気をつけなくてすむ仕組みを考えた
方がいい。

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

627 名前:名無しさん@お腹いっぱい。 mailto:sage [2007/07/25(水) 01:49:47 ]
>>625
いや、「Cでは当たり前」であっても、エラーを起こしやすいよ。
たかがエディタのカスタマイズのためにいつも書きたい類のコードではない。

628 名前:名無しさん@お腹いっぱい。 mailto:sage [2007/07/25(水) 01:51:20 ]
>>626
残念ながら、それはC++ほど上手くはできん。
GCやapacheのpoolのようなものを使えばかなりマシにはなるが、
そこまでしてCに固執する理由がわからんよ。

629 名前:名無しさん@お腹いっぱい。 mailto:sage [2007/07/25(水) 01:55:26 ]
世にこんだけバッファオーバーフローが原因のセキュリティホールが
溢れかえってるのがCの問題の傍証と言えるんじゃまいか。

630 名前:名無しさん@お腹いっぱい。 [2007/07/25(水) 01:58:25 ]
>>628
別に言語に固執しているわけじゃない。が、言語にとらわれないように
したほうがいい。あの言語だからこれはできない!んじゃなくて、
あの言語でもこうすればなんとかなる、という考え方をしたほうが
いいんじゃない。

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

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



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

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

632 名前:名無しさん@お腹いっぱい。 [2007/07/25(水) 02:17:18 ]
>>631
寝れなくなりそうだが・・これ書いたら絶対寝る!(たぶん・・・

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

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

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

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

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

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

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

633 名前:名無しさん@お腹いっぱい。 mailto:sage [2007/07/25(水) 02:22:12 ]
>>632
なんつうか君、C++使ったこと無いだろ。
CでC++のSTLやboostレベルの「ライブラリ」を書くのは「不可能」なんだよ。

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

634 名前:名無しさん@お腹いっぱい。 [2007/07/25(水) 02:23:54 ]
>>633
>CでC++のSTLやboostレベルの「ライブラリ」を書くのは「不可能」なんだよ。

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

635 名前:名無しさん@お腹いっぱい。 mailto:sage [2007/07/25(水) 02:26:09 ]
>>634
あのな。クラスもコンストラクタもデストラクタも例外もテンプレートも継承も無い
言語で、どう同じ機能を実現するんだよ。
デストラクタが無いから明示的にfree()だのclose()だのが必要になるんだろ。


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

636 名前:名無しさん@お腹いっぱい。 [2007/07/25(水) 02:31:44 ]
>>635
どうやったら、実現できるか夏休みの宿題にしとくわ・・

637 名前:名無しさん@お腹いっぱい。 mailto:sage [2007/07/25(水) 02:38:34 ]
例えばスコープ抜けた時に自動的にデストラクタを呼ぶようなコードを
C++コンパイラは挿入する。
それに似た機能をもつ特殊なCコンパイラを書けば可能だろうが、それはもはや
「C」ではない。
そうでなければ、明示的にプログラマがデストラクタ相当物を呼ぶコードを書く
しかなく、それは当然C++に比べてエラーを生みやすく使い勝手も悪いものになる。

638 名前:名無しさん@お腹いっぱい。 mailto:sage [2007/07/25(水) 02:51:56 ]
すげぇな。Cでライブラリ書けばC++の真似ができると思ってる奴がいるのか

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

639 名前:名無しさん@お腹いっぱい。 mailto:sage [2007/07/25(水) 06:49:15 ]
うんうん。Cで書けば何でもCだな。
そういえばclispとかcpythonとか云うもんな



         /\__/\
       / ,,,,,    ,,,,, ::\
       | (●) ,、 (●) ::|
       |   ノ(,_.)ヽ  .::|   +
       |    -==-   .::| +
       \_ `--' __/    +
 r、     r、/ヾ  ̄ 下ヘ
 ヽヾ 三 |:l1、_ヽ___/__ .ィヽ
  \>ヽ/ |` }      n_n| |
   ヘ lノ `'ソ       l゚ω゚| |
    /´  /        ̄|. |
    \. ィ   ____ |  |
        | ノ       l |  |

ナイナイw

640 名前:名無しさん@お腹いっぱい。 mailto:sage [2007/07/25(水) 09:12:08 ]
Emacsならlispで書けることもCで書いて、バグがあったら即セグフォか。

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



641 名前:名無しさん@お腹いっぱい。 mailto:sage [2007/07/25(水) 09:18:41 ]
>>640
セグフォるタイプのバグならまだマシな部類だ。すぐに露見するからな。
リークだのバッファオーバーフロー(の可能性)だのは一見動いているように
見えるから始末が悪い。

642 名前:名無しさん@お腹いっぱい。 mailto:sage [2007/07/25(水) 09:33:11 ]
こりゃ単なる釣りでしょ。
話そらずばかりで
エディタの拡張にCを使うのは馬鹿らしいという反論には直接答えてない。

643 名前:名無しさん@お腹いっぱい。 mailto:sage [2007/07/25(水) 09:56:04 ]
Cでいいっつってる奴は20年前で脳みそが止まってるんだろw
今時必要も無いのに何でもアセンブラで書こうとする奴はただのアホだが、
Cについても同じことが言える。

644 名前:名無しさん@お腹いっぱい。 mailto:sage [2007/07/25(水) 14:36:46 ]
ところでVim7のmatchparen機能だが、これはCでハードコーディングするんじゃなくて
Bramが直々にVimスクリプトで書いてるんだよな。
なんか珍しい。

645 名前:名無しさん@お腹いっぱい。 [2007/07/26(木) 01:50:08 ]
>>637
> それは当然C++に比べてエラーを生みやすく使い勝手も悪いものになる。
それはあなたの思い込みでしかないわけ。

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

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

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

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

646 名前:名無しさん@お腹いっぱい。 mailto:sage [2007/07/26(木) 09:51:58 ]

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

647 名前:名無しさん@お腹いっぱい。 mailto:sage [2007/07/26(木) 10:52:38 ]
まともに反論できないから、「アフォ」を連呼するだけになったな。
詭弁の特徴のガイドラインで言うところの「知能障害を起こす」って奴だ。

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

648 名前:名無しさん@お腹いっぱい。 [2007/07/27(金) 02:29:34 ]
>>647
と、思いたいのですね^^

649 名前:名無しさん@お腹いっぱい。 [2007/07/27(金) 03:17:19 ]
#!/usr/bin/sh と書かれたCGIがほとんど配布されてないのは
なぜですか?

650 名前:名無しさん@お腹いっぱい。 mailto:sage [2007/07/27(金) 09:21:34 ]
普通は#!/bin/shだからじゃないですかね。
そういうCGIなら俺の手元にありますよ。



651 名前:名無しさん@お腹いっぱい。 mailto:sage [2007/07/30(月) 06:58:57 ]
何だかんだ言ってもTeXの設計の汚さだけは叩かないよな

652 名前:名無しさん@お腹いっぱい。 mailto:sage [2007/07/30(月) 17:44:11 ]
TeX…あれもバッドノウハウの代表例ですな。
まあ、高林氏はEmacsもバッドノウハウとして挙げているわけだが。






[ 続きを読む ] / [ 携帯版 ]

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<146KB

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef