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


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

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



1 名前:デフォルトの名無しさん [2007/10/28(日) 15:59:01 ]
コーディングスタイルについて熱く語れ

159 名前:デフォルトの名無しさん mailto:sage [2009/02/12(木) 01:41:46 ]
trueはfalse以外が仕様だからそれじゃダメだっての。

if ( flag )
if ( flag != false )

これ以外は許されない

160 名前:デフォルトの名無しさん mailto:sage [2009/02/12(木) 01:47:26 ]
>>159
flag の型がちゃんと bool ならどっちでもいっしょ。

それよりも if ( flag != false != false ) のが(以下略

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が2でも==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になっているか、
チェックするのか?しないだろ?
ただのいいがかりじゃねえか、おまえの頭が論外だよw

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)を混ぜて誤魔化してないか?w

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人だけが「なんで設計書にロジック書いてんだwwwこの現場やべえwww」と笑い、辞める。

211 名前:デフォルトの名無しさん mailto:sage [2009/02/15(日) 18:11:22 ]
>>210
設計書を書いた奴と相談するっていう選択肢が無いのが悲しいな。

212 名前:デフォルトの名無しさん mailto:sage [2009/02/15(日) 20:05:55 ]
_Booleanはどういう定義なんだよソレw

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 ]
1からじゃなくて0からでした

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
>1からじゃなくて0からでした
こういう馬鹿が居るから直感的じゃないんだよ。

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 ]
スタイルスレで聞きたいと思ったことが1つあるんだ。

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の使い分けってどうしてる?







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

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

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