Path: ccsf.homeunix.org!ccsf.homeunix.org!news1.wakwak.com!nf1.xephion.ne.jp!onion.ish.org!gcd.org!news.yamada.gr.jp!news.media.kyoto-u.ac.jp!not-for-mail From: OOTANI TAKASHI Newsgroups: fj.comp.lang.c Subject: Re: =?ISO-2022-JP?B?GyRCOzA5YDFpOzs7UhsoQihSZTobJEIkMyRzJEobKEI=?= =?ISO-2022-JP?B?GyRCJTMhPCVJPXEkLyEpGyhCKQ==?= Date: Sun, 13 Mar 2005 02:36:41 +0900 Organization: Public NNTP Service, Kyoto University, JAPAN Lines: 49 Message-ID: References: <42320110.7079%katoh@pop12.odn.ne.jp> <42328fca.7081%katoh@pop12.odn.ne.jp> <4232f725.7082%katoh@pop12.odn.ne.jp> NNTP-Posting-Host: pdd4e9a.ykhmac00.ap.so-net.ne.jp Mime-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=ISO-2022-JP X-Trace: caraway.media.kyoto-u.ac.jp 1110649003 1506 218.221.78.154 (12 Mar 2005 17:36:43 GMT) X-Complaints-To: news@news.media.kyoto-u.ac.jp NNTP-Posting-Date: Sat, 12 Mar 2005 17:36:43 +0000 (UTC) User-Agent: T-gnus/6.15.13 (based on Oort Gnus v0.13) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.4 Emacs/20.7 (i386-msvc-nt5.1.2600) MULE/4.1 (AOI) Meadow/1.15 (SHOUBU:63) Cancel-Lock: sha1:EdYpEXAOtiVV65RoqiYd4Em1bbA= Xref: ccsf.homeunix.org fj.comp.lang.c:554 In article <4232f725.7082%katoh@pop12.odn.ne.jp> Hideki Kato writes: >>> && や || は,一方の値に依っては,残りを計算しなくても全体の値が決まると >>> いう,その演算の(ある意味特殊な)性質を利用しているので,?: 演算子とは >>> 若干性質が異なるように思えます.例えば,& や | の仲間の ^ (exclusive or) >>> にはこれは適用できません. >> >>&& と &、|| と | は全く異なる演算子なんで、^ を持ち出しても無意味です。 > > 「全く」異なる,のでしょうか? それなら何故同じ文字を用いたのでしょう. > + と ++ の関係と同様に,類似性があるから同じ文字を用いたと考える方が自然 > だと思います. すいません。まさにその点が見解の相違点なので、「全く異なる」と書いたのは 自分の土俵で話をしたわけで、まずかったと思います。 << 今は && || の話なんで、ビット単位の演算子である & | ^ を持ち出すのは と書くべきだったか。 && || の & や | との類似点を重視するのか、式の中に制御構造を持ち込んだことを 重視するのかによって見解が分かれるわけです。 >>and,or は全引数を評価してからand/or演算をする仕様であっても動作するように >>書くべきという考えでしょうか。condだけ対象外な理由がわかりません。 > > 読み難い,バグり易い,cond で十分,が理由です. 単なる慣れの問題のように思えます。 もし私が加藤さんと共同でコーディングすることになれば、私がand/orを制御構造的に 使えばそれは加藤さんに直感的に通じないのでバグの元になるでしょうけど。 みんなのand/orに対する思いが統一されていれば大丈夫ですよね。 ああ、そういう意味ではオープンソースなんかでは不特定多数なんで問題の元になるかも。 でもやっぱりそういう意味でも慣れの問題でしょう。皆が慣れればOK。 まあ、lispでは制御構造目的でand/orを積極的に使うべきとまでは思いませんけど。 and/orを使ったほうが見やすければためらう必要は無いと思います。 >># Cでも 0||3 が1でなく3になればすっきりすると思いますが。 > > ふむむ,それも面白いかも. Cでは 0||3 が1になってしまうんで「制御構造派」は「& | 類似重視派」に比べて 分が悪いと思っています。 -- tksotn