コーディングスタイルにこだわるスレ

1 名前：デフォルトの名無しさん [2007/10/28(日) 15:59:01 ] コーディングスタイルについて熱く語れ 161 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 02:12:25 ] >>160 C言語だとダメなやつもあるから、0と0以外にしとくのが安全なスタイルってもんだよ。 比較演算の結果でてくる論理を比較するのもありだけどね。 assert( (p == NULL) != false ); 162 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 02:15:40 ] >>161 わざわざ「flag の型がちゃんと bool なら」って書いてあるのに何言ってんの？ > assert( (p == NULL) != false ); ねーよ 163 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 02:33:29 ] いやいや、そこはこうでしょ assert( (p == NULL) != false != false);ってのが(ry 164 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 02:47:00 ] だからさ、FAQの > もし君が「if((a == b) == TRUE)」が「if(a == b)」の改良版であると信じるのなら、な ぜそこで止めるのか。なぜ「if (((a == b) == TRUE) == TRUE)」を 使わないのか これがそもそもおかしい おそらく原作者はジョークのつもりだったろうが、真に受けてるアホがいるからな・・・ 165 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 02:58:25 ] Cの(ユーザー定義の)TRUEとC++の(言語の)trueの違いがわかってない奴がいるな Cでif(flag==TRUE)は間違いだが、C++でif(flag==true)は書き方の問題だ 書き方の問題＝好みだよ ここでif((flag==true)==true)を持ち出す奴はジョークが理解できないってことだ 166 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 03:50:19 ] >>164 で、何がいいたいの？論理定数との比較を擁護するつもりなの？ 167 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 04:00:02 ] >>165 はなから技術的な正しさとか間違いとかを問題としてるんじゃない。 論理定数との比較に意味が無く、混乱の元でしかないから書くべきではないという話だ。 (... == true) も (... != false) も同じくらいに意味が無い。 168 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 04:43:58 ] 意味あるじゃん ある特定の人間にとっては見やすいという意味が 169 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 05:01:14 ] カスみたいな意味だな。 170 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 10:58:38 ] 一番ダメなのは is〜, has〜, can〜 などの自然に読み下せるように工夫した命名規則を 台無しにしてしまうこと。 if (x.isReady()) で済むところを if (x.isReady() == true) だの if (x.isReady() != false) だの わざわざノイズを混ぜるのが許せない。 171 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 11:49:41 ] 俺はif(flag)派だが、if(flag==true)なソースを見てもいちいち噛み付かないな TRUEは明らかに不味いがtrueは見た目の問題、見易いかどうかは主観だからな それをノイズと感じるのも自由だし、そんなのは人に押し付けなければどっちでもいい それよりTRUEとtrueを混同して大昔のFAQを持ち出したり、 技術と好みの違いが分からない奴の方がスキル低いだろ 172 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 13:42:38 ] TRUEとの比較には問題があるなんて>>133なども当然理解しているだろ。 それは誰もが理解しているという前提で、本筋からそれるのでスルーしただけにしか思えない。 173 名前：デフォルトの名無しさん mailto:sage [2009/02/12(木) 22:31:56 ] 初見のソースでif( hoge == true ) と書かれていると、hogeがboolになっているか、 そうでなければtrue/falseの2値しか取り得ないのかチェックする手間が生じる。 初見じゃなくてもどうなってるかいずれ忘れるかもしれない。 （そんなの気にしないとかってのは論外過ぎる） if( hoge != false ) も、万人がつっかえず読めるソースであるとは言い切れない。 174 名前：デフォルトの名無しさん mailto:sage [2009/02/13(金) 00:20:00 ] もしかしてflagが２でも==trueなら通るのか？ 175 名前：デフォルトの名無しさん [2009/02/13(金) 00:35:12 ] flagに2が入っている時点で不具合だとしか思わない bool型ならな 176 名前：デフォルトの名無しさん mailto:sage [2009/02/13(金) 01:02:25 ] 素直に!=falseにしとけよ。 177 名前：デフォルトの名無しさん mailto:sage [2009/02/13(金) 04:07:26 ] >>172 理解してたらtrueに対してFAQ(TRUE)を持ち出さないだろ 178 名前：デフォルトの名無しさん mailto:sage [2009/02/13(金) 10:51:29 ] ヘンなケースだけど if (flag) 形式は うっかり bool の配列を渡してハマりそうになったことあるなぁ bool array[2]; if (array) みたいな 179 名前：デフォルトの名無しさん mailto:sage [2009/02/13(金) 14:13:43 ] >>173 初見のソースでif(hoge==1)と書かれていると、hogeがintになっているか、 チェックするのか？しないだろ？ ただのいいがかりじゃねえか、おまえの頭が論外だよｗ 180 名前：デフォルトの名無しさん mailto:sage [2009/02/13(金) 14:19:19 ] 読み違えてるよ 181 名前：デフォルトの名無しさん mailto:sage [2009/02/13(金) 14:23:58 ] hoge == 1 は何とも思わないが、 hoge == true を見つけたら bool 値に対する理解が 不十分な可能性を疑わざるを得ないだろうね。バグを探してるときならなおさら。 signed/unsigned が混在してたり、可変長引数にキャスト無しの NULL を渡してたり、 ループ変数に char が使ってあったりするのと同じ。言語仕様の不十分な理解から出る バグのにおいがする。 182 名前：デフォルトの名無しさん mailto:sage [2009/02/13(金) 14:37:11 ] hoge==true見つけただけで言語使用を理解してない可能性を疑うってどんだけレベルの低い環境なんだ ところで181の挙げた例に細かいミスがあるんだが、普段の俺ならスルーしてあげる だが181の論理によれば、俺からみたら181は言語使用を理解してないと疑わざるを得ない 183 名前：デフォルトの名無しさん mailto:sage [2009/02/13(金) 14:38:48 ] 言語使用→言語仕様 184 名前：181 mailto:sage [2009/02/13(金) 14:43:46 ] 何かミスがあるというなら言語仕様を理解していないと疑われるのはしかたがないと思うけど、 できればはっきりと指摘してほしいところだね。 185 名前：デフォルトの名無しさん mailto:sage [2009/02/13(金) 14:46:01 ] どうせハッタリだろ。 186 名前：デフォルトの名無しさん mailto:sage [2009/02/13(金) 15:08:25 ] なんか話ずれてるけど 173はif(hoge==true)ならhogeがboolかチェックするんでしょ？ もうその時点でありえないんだけど、そんな底辺レベルの職場なら if(hoge==1)でもhogeがintかチェックする必要がある、チェックしないのはダブスタじゃん って意味だよね、違う？ 普通の職場なら同僚やらオープンソースで if(hoge==true)見つけても、「あらあら、このひとはtrueと比較しちゃうんだ」って思って終わりだよ どんだけ病んだ職場で働いてるんだ、転職したほうがいいよ 187 名前：デフォルトの名無しさん mailto:sage [2009/02/13(金) 15:25:30 ] >>186 hoge == true （あるいは hoge != false ） を書くような人は bool 型や if 文になどついての理解が あやふやな可能性が高いので、同様に理解の不足から int == true などという間違いを犯している 可能性があることを推測できる。 hoge == 1 を見ただけではそのような推測はできない。 関連箇所でのバグを探してるんじゃなければスルーすることも多いだろう。それが普通だというのも 妥当な話だ。しかし、スレタイを読む限りここでそれを主張するのは無意味だろう。 188 名前：デフォルトの名無しさん mailto:sage [2009/02/13(金) 20:14:16 ] あのさ, if (is_true_this(x) || is_true_that(x)) { } ってコーディングを許してくれないのはなぜ? 仕様的に副作用がない事を要求されている関数使って、なんで this_is_true = is_true_this(x); that_is_true = is_true_that(x); if (this_is_true || that_is_true) .... って、かかんとあかんわけ? 189 名前：デフォルトの名無しさん mailto:sage [2009/02/13(金) 20:15:31 ] 関数が何返したのか分かりにくい 190 名前：173 mailto:sage [2009/02/13(金) 22:09:36 ] >179,182 if( hoge == TRUE )のケースを考えてみてよ。 hogeは本当にTRUEかFALSEしか取り得ないのか不安にならない? 漏れが指摘したいのはむしろこっちの方なんだよ。 if( hoge == true )の場合は気にし過ぎってのは素直に認める。 （コンパイルすりゃすぐ分かるというのはEnter押してから気付いた） でもバグ発生時には疑うべき記述だと思う。 191 名前：デフォルトの名無しさん mailto:sage [2009/02/13(金) 23:40:30 ] if ((!!flag == true) != false) { 　　flag = true; 　　flag = true; // 念のためもう一度 } これくらいやっとけば安心 192 名前：デフォルトの名無しさん mailto:sage [2009/02/14(土) 00:48:46 ] 実際、trueやfalseと比較し捲くっているコードを整理したら、若干ではあるけど 所要時間に有意差が認められたからなぁ。 193 名前：デフォルトの名無しさん mailto:sage [2009/02/14(土) 01:01:22 ] (1) if( hoge == TRUE ) (2) if( !!hoge == true ) (3) if( hoge == true ) (4) if( hoge ) 最悪のケースを想定した場合、読み手が考え込む時間が一番短いのは(4)でしょ。 ifの動き、hogeの値、コーディングスタイル、ネーミング位しか悩める要素が無いんだから。 他は最悪、型とか脳内演算とかで、余計な思考時間を生んでしまう恐れがある。 194 名前：デフォルトの名無しさん mailto:sage [2009/02/14(土) 01:35:45 ] true との比較では所要時間に差は出るだろうが false との比較で差が出るのは最適化レベルがおかしいんじゃないのか 195 名前：192 mailto:sage [2009/02/14(土) 01:41:23 ] >>194 trueもfalseも纏めて整理したから、falseの有無で差があるかは確認していない。 196 名前：デフォルトの名無しさん mailto:sage [2009/02/14(土) 01:42:04 ] あえて(2)を混ぜて誤魔化してないか？ｗ 197 名前：デフォルトの名無しさん mailto:sage [2009/02/14(土) 11:27:41 ] trueと比較しない場合 >>178みたいなのでハマるくらい? 198 名前：デフォルトの名無しさん mailto:sage [2009/02/14(土) 11:52:14 ] 逆にboolをtrueと比較して困るケースの具体例、つか経験談ってある？ 199 名前：デフォルトの名無しさん mailto:sage [2009/02/14(土) 11:58:59 ] >>198 1以外の値が入ってるときとか。 200 名前：デフォルトの名無しさん mailto:sage [2009/02/14(土) 11:59:12 ] >>198 >194 201 名前：デフォルトの名無しさん mailto:sage [2009/02/14(土) 16:47:04 ] ちょっと違う話かも知れんが、 if (式) { 　return true; } else { 　return false; } なんてプログラムを見ることがたまにある。 最初からreturn 式;にしろよ、って思う。 202 名前：デフォルトの名無しさん mailto:sage [2009/02/14(土) 16:48:03 ] 変更になりそうな箇所がおおいならそう書くこともある。 203 名前：デフォルトの名無しさん mailto:sage [2009/02/14(土) 19:46:26 ] 漏れはこうだなあ。 if (式) { 　return true; } return false; 204 名前：デフォルトの名無しさん mailto:sage [2009/02/14(土) 19:54:47 ] そういうのを書く時は最終的にtrueを返すようにしてるな 205 名前：デフォルトの名無しさん mailto:sage [2009/02/14(土) 19:55:23 ] return (式) ? true : false; 206 名前：デフォルトの名無しさん mailto:sage [2009/02/14(土) 21:41:18 ] >>205 これはないな。 207 名前：デフォルトの名無しさん mailto:sage [2009/02/14(土) 21:58:37 ] 式が関数でtrue/falseの意味が取り違える可能性があるような名前ならアリかもな。 208 名前：デフォルトの名無しさん mailto:sage [2009/02/15(日) 16:12:23 ] >>205 俺もこれだけはやっちゃダメだろとは思う マクロならそうなるけど 自分のことしか考えてないタイプ 209 名前：デフォルトの名無しさん mailto:sage [2009/02/15(日) 17:18:59 ] static _Boolean checkLevel( double value, double level, _Boolean reverse ) {   if ( reverse == _False ) {     if ( level <= value ) {       return _True;     }   } else {     if ( value < level ) {       return _True;     }   }   return _False; } -- これ見たときはどうしてくれようかと思った。 210 名前：デフォルトの名無しさん mailto:sage [2009/02/15(日) 17:55:06 ] 設計書にそういう「ロジック」を書いてるんだろうなあ。。。 1. 引数は値、レベル、反転フラグとする。 2. 反転フラグが _False であれば、以下を行う。 　　1) ・・・ 3. 上記以外の場合、以下を行う。 　　1) ・・・ 日本人プログラマが10人いれば、8人は何も考えずにコーディングを行う。 1人は、「反転フラグて。。。呼び出し側で結果を反転させりゃいいのに。。。」とか思いながらコーディングを行う。 残りの1人だけが「なんで設計書にロジック書いてんだｗｗｗこの現場やべえｗｗｗ」と笑い、辞める。 211 名前：デフォルトの名無しさん mailto:sage [2009/02/15(日) 18:11:22 ] >>210 設計書を書いた奴と相談するっていう選択肢が無いのが悲しいな。 212 名前：デフォルトの名無しさん mailto:sage [2009/02/15(日) 20:05:55 ] _Booleanはどういう定義なんだよソレｗ 213 名前：209 mailto:sage [2009/02/15(日) 20:14:34 ] >>212 おっと、書き忘れてた。 ＞typedef enum { _False = 0, _True = 1 } _Boolean; だとさ。ちなみに、Sun-OSのcc(標準ではc99としてコンパイルする)を使っているのに c99禁止と言う不思議なコーディング規約(と言っても明文化されていない)だし。 >>210 >209のコードに関しては、設計者=コーダーの可能性大。 214 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 05:43:24 ] "<="や">="を書くことが幼稚な気がして今まで避けてきたんだが "<"や">"は小数を扱うのが正しい使い方で、 整数を扱う場合はイコールをつけたほうが直感的な気がする for(int i=0; i<10; i++) ってのが一般的で10回カウントするってのが直感的にわかるけど なんというか、行って帰ってきて結果的にはあってるって感じで、 for(int i=0; i<=9; i++) のが1から9まで1ずつカウントするって意味で 正しい使い方な気がする 215 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 05:47:32 ] １からじゃなくて０からでした 216 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 06:00:51 ] >>205が何でだめなのか、プログラミング初級者の俺に教えてくれ 無駄がなくてわかりやすいと思うんだが 217 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 07:21:32 ] 1. 返り値がニ値しか取りえないなら、isHoge関数にすべき 2. 構文糖衣はあくまで糖衣 3. 流し読みする時に目に入り辛い (最後の行だからいい？一カ所使われていると、 複数箇所使われている可能性が高いから、結局同じこと) 218 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 07:39:52 ] >>214 ＞１からじゃなくて０からでした こういう馬鹿が居るから直感的じゃないんだよ。 219 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 09:29:50 ] >>216 「? true : false」の部分が丸々冗長。 単純にこれを消しても同じ意味だよ。 220 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 22:36:57 ] 式が bool 型ならそうだろうが そうじゃなけりゃえらい違いだよ。 bool 型へのキャストは警告出すコンパイラがあるんで、 やむを得ず ? true : false としないといけない。 マクロ化したいけど、作ってもみんな使ってくれないし・・・。 221 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 22:44:33 ] 強制的に bool にしたいなら !!(式) でいいだろ。 222 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 22:56:47 ] Cだったら、0か0以外にしとけばいいんだよ。 223 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 22:59:57 ] >>220 条件演算子なんか使わなくても、比較式入れとけばいいじゃん。 224 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 23:10:01 ] 真偽値を比較するなんてとんでもない！ 225 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 23:26:09 ] >>224 真偽値だったら、そのままreturnすればいいんじゃね? #define true 0 #define false -1 ↑みたいな変態的な定義でもされてたら、条件演算子もやむなしって気がするけど。 226 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 23:44:02 ] 自分だったら!!よりは? true : false選ぶなあ。 227 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 23:48:27 ] >>225 bool hoge(int ch) { 　return isupper(ch); } isupper の戻り値は真偽値（int 型の非0/0）だが bool ではない。 コンパイラによってはそのまま return すると文句言われる事がある。 228 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 23:58:38 ] >>227 いや、だから、真偽値以外だったら、比較にすればいいんじゃね?って話。 　return isupper(ch) != 0; 229 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 23:58:49 ] >>225 それが標準だったらどんなに良かったかと常々思ってる。 230 名前：デフォルトの名無しさん mailto:sage [2009/02/17(火) 00:03:33 ] >>229 trueやfalseが標準で定義されていて、 n > 0 みたいな比較式の結果と違う値になってたらよかったってこと? 231 名前：デフォルトの名無しさん mailto:sage [2009/02/17(火) 00:15:34 ] >>228 真偽値を比較するなんてとんでもない！ ぶっちゃけ読み辛くてしゃーない。 232 名前：デフォルトの名無しさん mailto:sage [2009/02/17(火) 00:23:21 ] >>231 ああ、それはそうだな。 Cライクな真偽値と、C++のboolを併用するときはしかなないのかね。 static_cast<bool> とかするとどうなるんだろう。 233 名前：デフォルトの名無しさん mailto:sage [2009/02/17(火) 00:25:08 ] VC++はboolへのあらゆる直接的な変換は警告出した気がする 234 名前：デフォルトの名無しさん mailto:sage [2009/02/17(火) 00:25:56 ] g++はノーキャストでも完全スルーなんだが 235 名前：デフォルトの名無しさん mailto:sage [2009/02/17(火) 00:52:23 ] >>220 式が bool じゃなくて return するのに問題があるというのなら、 ? の左に書くのだって同じ問題があるはずじゃないか。 やっぱり、? 以降は単純に冗長だよ。 236 名前：デフォルトの名無しさん mailto:sage [2009/02/17(火) 22:58:25 ] だーかーらー、五月蝿い警告が出るコンパイラへの対策なだけだと言うとるに。 どのコンパイラでも警告でないならそのまま返したいさ、そりゃ。 237 名前：デフォルトの名無しさん mailto:sage [2009/02/18(水) 01:36:14 ] >>236 うるさいっていうかアホだろ。 return での bool への変換は警告するのに ? 演算子の前に置いたときの bool への変換は出ないとか、 意味がわからん。 そもそも警告を黙らせるためのコードなんか書いちゃいけない。 警告によって指摘された問題に対策しないといけない。 238 名前：デフォルトの名無しさん mailto:sage [2009/02/18(水) 04:04:58 ] そりゃそうだ。C/C++に、?の左側に置いた式はbool型に変換されるなんて規則はないから そこでbool型への変換だなんて警告が出るわけない。 239 名前：デフォルトの名無しさん mailto:sage [2009/02/18(水) 04:33:49 ] >>238 何を根拠にそんなこと言うの？ C++ の ? は bool に変換して評価するよ。 5.16 Conditional operator p1 > The first expression is contextually converted to bool (Clause 4). 240 名前：デフォルトの名無しさん mailto:sage [2009/02/18(水) 05:14:14 ] そうだったのか。 C99だけ見ていたが、こっちは、0と比較して云々となっていて、 _Boolへ変換するとは書かれていなかった。 C++もそんな調子だと思っていたよ、すまない。 241 名前：デフォルトの名無しさん mailto:sage [2009/02/18(水) 13:47:17 ] C99 なら _Bool f(int x) { return x == 1; } でも比較演算自体は int だから警告が出るというのか？ それもアホだな。 242 名前：デフォルトの名無しさん mailto:sage [2009/02/18(水) 14:45:41 ] そんなこと言ったら C99 では true も false も int 型なわけで。 結局のところ "? true : false" がまったく冗長なだけの記述には違いないね。 243 名前：デフォルトの名無しさん mailto:sage [2009/02/18(水) 19:22:44 ] ECMAScriptなら冗長でないよ 244 名前：デフォルトの名無しさん mailto:sage [2009/02/18(水) 21:31:42 ] どでもいいけど、システムハンガリアンって呼ばれてる 変数のタイプをプリフィックス/ポストフィックスとして つける命名規則だけは絶対裂けるべきだ 一部に改訂が入って、使ってる型の定義が変わった場合の メンテナンスはとんでもないことになる 245 名前：デフォルトの名無しさん mailto:sage [2009/02/19(木) 00:03:28 ] 下手に否定するより、よりベターな手法を教えてそっちに誘導した方が良い。 チーム全体に徹底させるだけの権限と統治力を持ってない場合は特に。 人は力強く押さないとあらぬ方向に進むが、引っ張れば割とすんなり思った方向へ進む。 246 名前：デフォルトの名無しさん mailto:sage [2009/02/19(木) 12:32:31 ] >>244 WIN16→WIN32→WIN64の悲劇ですね。 247 名前：デフォルトの名無しさん mailto:sage [2009/02/19(木) 21:33:35 ] WORD型やDWORD型なら、typedefを書き換えればいい たぶん・・・ 248 名前：デフォルトの名無しさん mailto:sage [2009/02/19(木) 23:15:01 ] スタイルスレで聞きたいと思ったことが１つあるんだ。 C++のcppの方にソースを見やすくするために関数を小分けにしたものを staticで記述して使ってるんだが、private関数にするべきかね？ 249 名前：デフォルトの名無しさん mailto:sage [2009/02/19(木) 23:28:51 ] >>248 privateにしなくてもいいんじゃね? C++のprivateって、そもそもが美しくないし。 250 名前：デフォルトの名無しさん mailto:sage [2009/02/19(木) 23:47:33 ] どっちかっていうと、外部にも派生クラスにも公開する気がない関数はクラスに含めるべきじゃないと思う。 クラスのインターフェイスとは関係ない、実装側だけの問題なら、実装側で完結してるほうが美しい。 static 関数なら、いくら変更しても外部には影響しないし。 251 名前：デフォルトの名無しさん mailto:sage [2009/02/20(金) 00:02:01 ] 継承したときにvirtualつけて使いたいけど、クラス外からは使われたくないものに だけつけときゃいいのか。 252 名前：デフォルトの名無しさん mailto:sage [2009/02/20(金) 00:02:30 ] static関数化できるものなら、Utilityクラスとかにして 外に出しちゃうのも良い鴨 253 名前：249 mailto:sage [2009/02/20(金) 00:05:44 ] staticって、クラスのメンバとしてか。。。 勘違いしてた。 254 名前：デフォルトの名無しさん mailto:sage [2009/02/20(金) 00:16:57 ] メンバのstaticではなく実装用の小規模な補助関数ってことで。 255 名前：デフォルトの名無しさん mailto:sage [2009/02/20(金) 01:12:07 ] >>248 .cpp ローカルな関数は static じゃなくて無名名前空間を使う。 private にすべきかどうかはクラスのメンバであるべきかどうかで区別する。 何も考えずに書くと private 関数の宣言をヘッダに書くことになるんで何かおかしな 感覚になるけど、 pimpl とかインターフェース継承とか使って隠せば問題ない。 256 名前：デフォルトの名無しさん mailto:sage [2009/02/20(金) 01:22:53 ] なるほどね。いわゆるCのstatic関数ってのは推奨されてないのかな。 そこまで意識して気をつけようとも思わないけど、気が付くと疑問に思う。 257 名前：デフォルトの名無しさん mailto:sage [2009/02/20(金) 01:25:22 ] >>256 関数や変数だけならいいんだけど、 C と違って .cpp ローカルな struct や enum も グローバルに置いてると定義がかぶってアウトだから、なるべく無名名前空間を使う 癖をつけておいたほうがいいよ。 258 名前：デフォルトの名無しさん mailto:sage [2009/02/20(金) 12:56:17 ] >>257 それだけなら別にアウトじゃない。 規格としてはダメかもしれんが。 ただ、メンバ関数はリンケージをファイル スコープにできないから、無名名前空間が 絶対必須。 259 名前：デフォルトの名無しさん mailto:sage [2009/02/21(土) 17:20:06 ] addとappendや、eraseとremoveの使い分けってどうしてる？ 260 名前：デフォルトの名無しさん mailto:sage [2009/02/21(土) 17:28:41 ] addは追加、appendは付加。 eraseは消去、removeは除去。ついでに言えばdeleteは削除。 まぁ、それでも巧く決まらないときは既存ライブラリの命名に倣ったりするが。 261 名前：デフォルトの名無しさん mailto:sage [2009/02/21(土) 17:48:20 ] ロングマンで一通り調べてみた appendは追記みたいな 順序付きリストの末尾に付け加えるということなのか add⊇append 議論領域をUとすると remove A from Bの操作の後はA B∧A∈Uだけど erase A from Bの場合はA B∧A Uとまぁそんな感じ？ delteはcomputer上での操作を強調してあったけど メモリから消えるって事だからプログラミングっていう議論領域だとeraseに近いのかな？

---

---

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

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