トップページ⇒tech
709コメント230KB

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

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん2007/10/28(日) 15:59:01
コーディングスタイルについて熱く語れ
0002デフォルトの名無しさん2007/10/28(日) 16:03:26
余裕の2get
0003デフォルトの名無しさん2007/10/28(日) 16:03:38
インデント禁止
0004デフォルトの名無しさん2007/10/28(日) 16:11:07
改行禁止
0005デフォルトの名無しさん2007/10/28(日) 16:21:22
()禁止
0006デフォルトの名無しさん2007/10/28(日) 16:30:23
if文の比較では定数は左に置くよな、常識的に考えて。

if(0==a){
　 処理
}

みたいに
0007デフォルトの名無しさん2007/10/28(日) 16:32:04
if文なんて使ってるやつはばかです
0008デフォルトの名無しさん2007/10/28(日) 16:35:08
include禁止
0009デフォルトの名無しさん2007/10/28(日) 16:37:07
>>6
スペース入れろよ。
0010デフォルトの名無しさん2007/10/28(日) 16:39:10
>>6
詳細は
http://pc11.2ch.net/test/read.cgi/tech/1193250955/l50
こっちを参照で。
0011デフォルトの名無しさん2007/10/28(日) 16:39:35
必死だなｗ
0012デフォルトの名無しさん2007/10/28(日) 16:59:53
>>9
スペース禁止
0013デフォルトの名無しさん2007/10/28(日) 17:01:05
ｶﾞｯ禁止


ぬるぽ
0014デフォルトの名無しさん2007/10/28(日) 17:04:46
WinMainっていうのは定型だし、無視される引数もありいちいち書くのは面倒臭い
というわけで

#define WINDOWS_APPLICATION_ENTRYPOINT(hinstance,lpcmdline,ncmdshow) \
int WINAPI _tWinMain(HINSTANCE hhnstance, HINSTANCE, LPTSTR lpcmdline, int ncmdshow)

というようなマクロを使って
WINDOWS_APPLICATION_ENTRYPOINT(hinst,lpcmdline,ncmdshow)
{
　　return 0;
}
と書くのはどうでしょうか？
コード内部で参照するパラメータ名は使用する側が自由に決めることができます
0015デフォルトの名無しさん2007/10/28(日) 17:13:55
define禁止
0016デフォルトの名無しさん2007/10/28(日) 17:26:27
NULL禁止
0017デフォルトの名無しさん2007/10/28(日) 17:27:51
http://www.google.co.jp/search?q=%E3%82%B3%E3%83%BC%E3%83%87%E3%82%A3%E3%83%B3%E3%82%B0%E3%82%B9%E3%82%BF%E3%82%A4%E3%83%AB&sourceid=navclient-ff&ie=UTF-8&rlz=1B3GGGL_jaJP229JP231

コーディングスタイルに意味があるとしたらそれはプロジェクト内で統一することのみで
どう決めるかはまったく問題ではない。
もちろん一定以上の知的水準と経験を持った人間が決めればの話だが。
0018デフォルトの名無しさん2007/10/28(日) 17:33:54
goto奨励
0019デフォルトの名無しさん2007/10/28(日) 18:00:20
>>17
> コーディングスタイルに意味があるとしたらそれはプロジェクト内で統一することのみで

誤読してるかもしれないが、コーディングスタイルの意義として、プロジェクト内でのスタイルの統一しかない
ということであれば、それに全く同意できない。

まず、可読性ありき。
0020デフォルトの名無しさん2007/10/28(日) 18:44:05
もしコーディングスタイルを決める意義が「統一することのみ」だったら、
「一定以上の知的水準と経験を持った人間」が決める必要さえないしな。
0021デフォルトの名無しさん2007/10/28(日) 18:53:14
それじゃあ、変数名いってみようか。

ハンガリアン記法はクソ。

変数定義の箇所に型情報は記述されており、
適切に実装されたスコープ内では充分に目に付く。
型情報をたどれないほどに変数定義から離れた変数は、
同時に関数などのクソ設計を匂わせており、クソ。
0022デフォルトの名無しさん2007/10/28(日) 18:57:04
>>21
ttp://local.joelonsoftware.com/mediawiki/index.php/%E9%96%93%E9%81%95%E3%81%A3%E3%81%9F%E3%82%B3%E3%83%BC%E3%83%89%E3%81%AF%E9%96%93%E9%81%95%E3%81%A3%E3%81%A6%E8%A6%8B%E3%81%88%E3%82%8B%E3%82%88%E3%81%86%E3%81%AB%E3%81%99%E3%82%8B
0023デフォルトの名無しさん2007/10/28(日) 19:04:11
> アプリケーションハンガリアン
> システムハンガリアン

シモニイすまんかった（´；ω；｀）
0024デフォルトの名無しさん2007/10/28(日) 19:20:22
>>22
またMSがいらんことを・・・
0025デフォルトの名無しさん2007/10/28(日) 19:27:55
１、２、ハンガリアン！
２、２、ハンガリアン！
0026デフォルトの名無しさん2007/10/28(日) 19:31:21
>>22
それ読んだとき、めっちゃバグりそうな書き方だとおもったな。
内部で処理するときは、HTMLエンコードしないで処理して、表示のときに一括して、エンコーディングしたほうが
いいと思ったよ。
unsafeとsafeを混在させて処理してたら、いくらネーミングで工夫してもミスるだろって。
0027デフォルトの名無しさん2007/10/28(日) 19:33:32
>>25 どぅわ～
0028デフォルトの名無しさん2007/10/28(日) 20:22:40
joelなんか糞派登場
0029デフォルトの名無しさん2007/10/29(月) 02:29:59
関数名、変数名は6文字以内。
0030デフォルトの名無しさん2007/10/29(月) 13:10:06
//char a, *b, *const c, const *d;
char a, *b, *const c;char const *d;

char const *dを続けて宣言できないのが悔しい。
0031デフォルトの名無しさん2007/10/29(月) 19:49:30
考えるときはマンダム
立った時はジョジョ立ち
0032デフォルトの名無しさん2007/10/29(月) 20:24:41
牛乳は瓶の奴しか飲んではいけない。
飲むときは腰に手を当てること。
0033デフォルトの名無しさん2007/10/29(月) 21:59:31
>>29
俺が就職したばかりの頃は、
リンカの制限で関数名は4文字までだった。
プリプロセッサは16文字まで対応してたから、
マクロ使ったりして工夫してたなぁ。

今考えると冗談みたいな話だ。
0034デフォルトの名無しさん2007/10/29(月) 22:11:03
最初の文字がi, j, k, l, m, n の変数は整数型。他は実数。
0035デフォルトの名無しさん2007/10/29(月) 22:51:24
>>34
文字列、真偽値は…？
つーかクラスオブジェクトは…？
0036sage2007/10/30(火) 00:34:16
hsqscsName (html-safe, sql-safe, command-line-safe)
hsqscusName (html-safe, sql-safe, command-line-unsafe)
hsquscsName (html-safe, sql-unsafe, command-line-safe)
:
0037362007/10/30(火) 00:37:04
orz
0038デフォルトの名無しさん2007/10/30(火) 00:41:26
今さらだけど>>6はどうかと思うな
見てから理解するのに時間がかかる

実際にあの方式使ってる人どのくらいいる？
0039デフォルトの名無しさん2007/10/30(火) 00:43:46
>>38
コードサーチでオプソをググったら腐るほどいた
0040デフォルトの名無しさん2007/10/30(火) 03:27:07
ヘアースタイルは7:3厳守。
0041デフォルトの名無しさん2007/10/30(火) 05:24:12
エラーコードを解析する時は三白眼、効果音は
　┣” ┣” ┣” ┣” ┣” ┣”
0042デフォルトの名無しさん2007/10/30(火) 09:17:13
>>38
999:1くらいだと思う。もちろん1の方。
0043デフォルトの名無しさん2007/10/30(火) 21:37:51
>>38
俺はデキる奴だぜー、と思い込んでるけど実際はそうでもない人が使いそう
0044デフォルトの名無しさん2007/10/31(水) 01:39:14
< とか > とかの向きを揃える目的なら使っちゃだめか？
0045デフォルトの名無しさん2007/10/31(水) 02:55:54
定数を左に置くのは、次の場合だけだな。
if (0 < x && x < 100)
本当はif (0 < x < 100)と書きたいけど、書けないのでその代用としてだ。
0046デフォルトの名無しさん2007/10/31(水) 23:03:42
returnやsizeofの後をカッコでくくるかどうかって話はもう出た？
0047デフォルトの名無しさん2007/10/31(水) 23:06:40
return の後の括弧は無し
sizeof の後の括弧は有り
0048デフォルトの名無しさんNGNG?2BP(125)
return はくくらないのにsizeofはくくりたくなるんだよな。。
0049デフォルトの名無しさん2007/10/31(水) 23:08:24
習慣っつーか慣用句みたいな感じ
0050デフォルトの名無しさん2007/10/31(水) 23:09:44
括弧つけるべきか否か迷う時間が勿体無いので、
なんでも括弧つけることにしてる。
0051デフォルトの名無しさん2007/10/31(水) 23:45:58
return 0; ならいいとしても、return i * 2; みたいになると、括弧で括りたくなる。
0052デフォルトの名無しさん2007/10/31(水) 23:52:18
昔、会社のコーディング規約決める時に、returnの後の括弧は無しじゃね？
って言っても、みんな、returnの後は括弧付けるって言って引かないから、
もう、どっちでも良い事にしちゃった。

0053デフォルトの名無しさん2007/11/01(木) 00:30:32
実際どっちでもいいし
0054デフォルトの名無しさん2007/11/01(木) 00:33:31
>52
燃料投下。
ttp://www.st.rim.or.jp/~phinloda/cqa/cqa6.html#q20
0055デフォルトの名無しさん2007/11/01(木) 07:23:14
やっぱりキチガイは一人だけだったか。
奴が来ないとこんなに静か。
0056デフォルトの名無しさん2007/11/01(木) 08:35:41
交差点で１００円ひろおったーよー
0057デフォルトの名無しさん2007/11/01(木) 21:05:04
ちびまるこちゃんだな。
0058デフォルトの名無しさん2007/12/20(木) 03:21:44
なんでもかんでもみんな マスゲームを踊ってるよ
ピョンヤンの丘にはボカッと 巨大な銅像献上
いつだって 忘れない 金日成偉い人 そんなの常識
パッパパラリラ
ピーヒャラピーヒャラ おなかが減ったよー
0059デフォルトの名無しさん2008/01/21(月) 02:38:32
>今さらだけど>>6はどうかと思うな
>見てから理解するのに時間がかかる
今更だが、

1. if ( hogehogeflag == 0 )
2. if ( hogeHoge( parameter_list ) > 0 )
3. while( ( c = fgetc( stdin ) ) != EOF )

とかよりは

1. if ( 0 == hogehogeflag )
2. if ( 0 < hogeHoge( parameter_list ) )
3. while( EOF != ( c = fgetc( stdin ) ) )

の方が大事なことが先に書いてあって分かりやすくて読みやすくね？
特に3.の場合なんか前者だと条件比較の意味を理解するのに最初fgetc()から←方向にcを読んで次に→方向に読み直してEOFを探さなきゃならんし。
それとも俺がそういうコミニティで育ったからか？
0060デフォルトの名無しさん2008/01/21(月) 03:46:07
私は三つとも上のほうが読みやすいと感じる。
数字の 0 よりも、フラグとか関数呼び出しのが「大事なこと」だと思う。
コミュニティ次第なんだろうね。

ただ私なら、 3 は

for (;;) {
c = fgetc(stdin);
if ( c == EOF ) break;
...
}

みたいに書く。
0061デフォルトの名無しさん2008/01/21(月) 04:45:23
出力（条件比較や返値）より入力（関数呼出や引数）が「大事なこと」だと思えば上のほう、
if ( hogeHoge( parameter_list ) ～
入力（関数呼出や引数）より出力（条件比較や返値）が「大事なこと」だと思えば下のほう、
if ( 0 < hogeHoge( ～
ってところではないかな。

定数と一時変数を使えば
err = hogeHoge( parameter_list );
if ( err == SUCCESS )
2 は 1 の問題に出来るな。

ただし 3 はイディオムなので、私でも>>60のように分解はしないな。
0062デフォルトの名無しさん2008/01/21(月) 05:06:08
ん、制御とデータで分けた方が適切なのかな。

"hogehogeflag が", "hogeHoge( parameter_list ) が", "while 内で c に fgetc( stdin ) を代入" のように データ中心に考えれば上のほう、
1. if ( hogeh...
2. if ( hogeHoge( para...
3. while( ( c = fgetc( stdin )...

"0 の場合に", "返却値が 0 より大きければ", "while は c が EOF になるまで" と制御中心に考えれば下のほう、
1. if ( 0 == ...
2. if ( 0 < hogeHoge( ...
3. while( EOF != ( c = fgetc( ...

になるね。
0063デフォルトの名無しさん2008/01/21(月) 08:38:08
定数左に置く人はfor文でもやっぱり左に置くの？
for (i = 0; N > i; ++i) みたいな感じに
0064デフォルトの名無しさん2008/01/21(月) 09:58:03
>for (i = 0; N > i; ++i) みたいな感じに
そりゃ不等号の向きによるんでね。if文でも同じやろ。
for( i = 0; i < N; ++i )
for( i = N; 0 < i; --i )

定数右に書く人は"N より大きい"を if ( i > N ) って書くん？
気持ち悪くね？
0065デフォルトの名無しさん2008/01/21(月) 10:11:40
それもそうだ。
0066デフォルトの名無しさん2008/01/21(月) 10:38:05
>>64
不等号の向きが数直線だと思い込む方がどうかしている。
つまり0より大きいと0より小さいがならぶときに、
if (var > 0) ...;
if (var < 0) ...;
と書くか
if (0 < var) ...;
if (var < 0) ...;
と書くかの違いなわけだが。

例えば、このvarが関数呼び出しになっても後者のように書くということなのだろ?
それが気持ち悪いと思えないなら、私とは相容れない種類の人間だと言うことだ。
0067デフォルトの名無しさん2008/01/21(月) 10:46:16
>>64
私はそれぞれ

for ( i = 0; i < N; i++ )
for ( i = N; i > 0; i-- )
if ( i > N )

って書く。
逆は気持ち悪いって感じる。

「 i が N より大きい」をそのまま書いたら i > N でしょ。
N < i は「 N が i より小さい」。
0068デフォルトの名無しさん2008/01/21(月) 10:56:56
私は基本的には定数右派だが、不等号については後者かな。
やはり var < 0 ってのは直感的ではないし見ていて気持ちが悪いって感じる。
0069デフォルトの名無しさん2008/01/21(月) 10:59:26
>>68
おお、これは新しい意見だ。
ついに、var < 0 が否定されたぞ。
0070デフォルトの名無しさん2008/01/21(月) 10:59:59
>>68訂正
× var < 0
○ var > 0
0071デフォルトの名無しさん2008/01/21(月) 11:04:38
私は < だろうが > だろうが関数呼び出し相手なら
if (0 <= func(
if (0 == func(
if (0 >= func(
だなぁ。
0072デフォルトの名無しさん2008/01/21(月) 11:07:39
>>70
だろうな。
さすがに var < 0 を 0 > var って書く人はいないか。
いないよな？
0073デフォルトの名無しさん2008/01/21(月) 11:10:36
よし纏めよう。
・定数右派
基本的に、常に定数が右。不等号の向きなんて関係ねぇ。
・定数左派
基本的に、常に定数が左。不等号の向きなんて関係ねぇ。
・不等号は数直線派
基本的に、不等号は常に左を小さく。定数の位置なんて関係ねぇ。

ダメだ、>71も恐らく例外があるのだろうし分類しきれない……
0074632008/01/21(月) 11:22:37
>>64-72
回答ありがとう

なるほどねー
1. 数直線に合わせる派
2.1. 評価対象を常に左に置く派
2.2. 評価対象を常に右に置く派
がいるみたいだね

…これ、どっかのMLの過去ログにもありそうだな
0075デフォルトの名無しさん2008/01/21(月) 11:42:38
基本的に短い物が左。
そして変数同士の不等号は数直線派。
変数か定数かなんて関係ねぇ。

な俺は結果的に
即値 < 変数・定数 < 式 < 関数
な順番になるな。

定数左ってよりは即値左か？
画面が狭かった頃の規約の名残だな。
0076デフォルトの名無しさん2008/01/21(月) 13:24:24
こんなものは理屈じゃなくて、数学の記法では普通 0=x でなく x=0 と書くというのが一番大きい気がするけどな
不等号は3項関係なら数直線だが2項関係ならやはり変数を左辺に書くのが数学でも一般的だと思う
0077デフォルトの名無しさん2008/01/21(月) 13:59:49
その理屈だと関数が絡んだときにおかしくないか？
数学だとy=f(x)の方が一般的でないか？
0078デフォルトの名無しさん2008/01/21(月) 14:12:06
>数学だとy=f(x)の方が一般的でないか？

その記法は定数相手には使わないような。
確かに y については y = f( x ) 的な書き方をするけど、f(x) については f(x) = a * x + y 的な書き方もするはず。
だからまあプログラミングの記号と数学の記号とでは微妙に意味が違うので全てを同じルールでは扱えないが、それでも変数と定数に限れば 0=x ではなく x=0 だろう。
これはもう理屈とか抜きに。
0079デフォルトの名無しさん2008/01/21(月) 14:27:50
>>78
数学に限って言えば、
＞0=x ではなく x=0 だろう
これは状況によりけりだな。まぁ、
＞プログラミングの記号と数学の記号とでは微妙に意味が違うので全てを同じルールでは扱えないが、
は正しいと思うので、数学のルールは適用できないんだけどね。
0080デフォルトの名無しさん2008/01/21(月) 16:34:55
&&とか||が絡むなら不等号の向きをそろえるけど
それ以外なら気にしないな。
0081デフォルトの名無しさん2008/01/21(月) 16:36:21
またこの話か。去年さんざん「祭り」したのに。

もう秋田。
0082デフォルトの名無しさん2008/01/21(月) 18:25:42
わざわざ来なくてもいいのに（笑）
0083デフォルトの名無しさん2008/01/21(月) 18:34:21
基本的には数直線に合わせるけど、場合によっては変えるね。
言葉や数式で表現するとどうなるかを頭に置きながら
理解しやすい方を選択する。
0084デフォルトの名無しさん2008/01/21(月) 20:01:32
Cプログラマの為に、ポイントをまとめたドキュメントを販売しています。
プロのプログラマでもあまりにレベルが低い人が多すぎます。
そんな人に限って、自分のレベルの低さを自覚していない、、、
　本人は構わないかもしれませんが、その下についた新人プログラマは
たまったものではありません。（私が経験しました。）
　今になって分かりました。
彼らもまた、理解できていなかったのです。
　プログラミング言語の一番の習得の近道はきちんと理解している人にアドバイスをもらうこと。です。
私のC言語に取り組んだ7年間をすべてぶつけたつもりでテキストを作りました。
　私の会社の後輩からは、どんなテキストよりもわかりやすかった！や、
今まで教えてくれていた先輩や、テキストたちが、ちゃんと理解できていないことがわかりました。
と、嬉しいコメントをたくさんもらいました。
そしてなにより、彼らの社内での評価がとても高いということが、私の誇りです。
　興味がある方はどうか、下のサイトをみてみてください。
http://mori.eco.to/
0085デフォルトの名無しさん2008/01/21(月) 20:04:01
ｳｾﾞｪ
0086デフォルトの名無しさん2008/01/21(月) 21:33:16
みるまでもなくネタだろ
0087デフォルトの名無しさん2008/08/02(土) 01:43:31
最近、カプセル化は要らん子な気がしてきた。
真面目に適用したところで可読性や保守性は上がるどころか下がることの方が多いし、
getter/setterを書くより、コメントやドキュメントをしっかり書いた方が良い気がする。
0088デフォルトの名無しさん2008/08/02(土) 02:58:06
getter/setter が無いと、ついつい直接書き換えして
後の挙動が掴めなくなってしまう俺みたいな屑も居るので書いてくれて良い
0089デフォルトの名無しさん2008/08/02(土) 09:35:09
つーか、そもそも下駄雪駄がある時点で間違いだろ。ちゃんと意味を考えたI/Fにするべきだ。
0090デフォルトの名無しさん2008/09/28(日) 15:35:28
>>87
getter/setterがある時点でカプセル化に失敗してるよ
0091デフォルトの名無しさん2008/09/28(日) 17:00:45
getter/setterだけでも、代入と取得のみに操作を限定できる利点がある。
メンバのアドレスを取られる心配がないだけでも幾らか安心感があると思うよ。
0092デフォルトの名無しさん2008/09/28(日) 20:03:24
ブレークポインタもかけやすいしな。
だけとgetter/setterが多くなるとカプセル化の意義が薄れてしまうのも忘れてはならないね
0093デフォルトの名無しさん2008/09/29(月) 03:59:22
設計から導き出されるのが、いい getter/setter
実装から導き出されるのが、悪い getter/setter

悪い getter/setter でも、将来の変更に備えて、無いよりマシ。
0094デフォルトの名無しさん2008/10/04(土) 02:42:58
基本的な値はコンストラクタで受け取るだけで、その後はgetterのみ。
どうしても後から値を変更する必要があるとか、設定値の種類が多すぎる場合のみsetterを使うかな。
0095デフォルトの名無しさん2009/02/03(火) 14:10:18
無限ループは
while(true){
}
って書くのが一番美しいと思うんです
0096デフォルトの名無しさん2009/02/03(火) 14:28:30
for ("ever") {
}
0097デフォルトの名無しさん2009/02/03(火) 19:29:38
>>95
それは意図しているのかそれともミスなのかが判断できない。

for(;;)
{
}

このほうが意図が明確
0098デフォルトの名無しさん2009/02/03(火) 21:00:25
誘導されてきました

int* a;
int *a;

どっちのほうが見やすいですか？
0099デフォルトの名無しさん2009/02/03(火) 21:32:24
int*型として考えるなら前者
変数自身がポインタと考えるなら後者
0100デフォルトの名無しさん2009/02/03(火) 22:04:58
int* a, b;
とかやられるとヤヴァイから後者がいい
0101デフォルトの名無しさん2009/02/03(火) 22:32:07
ポインタ型と普通の型をまとめて宣言しないでほしい
0102デフォルトの名無しさん2009/02/03(火) 22:37:07
resありです＾＾
0103デフォルトの名無しさん2009/02/03(火) 22:55:50
>100
こんなのコンパイルエラーで検出出来るだろJK
0104デフォルトの名無しさん2009/02/03(火) 23:31:31
>>103
コンパイルに数分かかるプロジェクトを書いた事が無いのか
0105デフォルトの名無しさん2009/02/04(水) 00:31:53
>>100
変数宣言分けるからどうでもいい
0106デフォルトの名無しさん2009/02/04(水) 00:42:39
そもそも1行に2つも宣言しないよな
0107デフォルトの名無しさん2009/02/04(水) 10:03:18
テンプレートではint*で１つの型なのに、>>100の例があるから困る。
でも俺はint* a;派。
0108デフォルトの名無しさん2009/02/04(水) 10:55:18
結局、CもC++も書く私はint * a;で落ち着きましたとさ。
0109デフォルトの名無しさん2009/02/04(水) 12:23:17
>>107
俺もint* a派。型を意識したりテンプレート使うとそうなるよね。
複数宣言はしない。行を分けてコメントを書く。だから>>100は無いものとしてC/C++で書いてる。
0110デフォルトの名無しさん2009/02/04(水) 13:04:35
>>100
絶対賛成！

型がどうこういってるやつは、
typedef int *intpとかするがいい。
0111デフォルトの名無しさん2009/02/04(水) 21:26:38
ポインタを typedef した時の const の挙動がなあ・・・
0112デフォルトの名無しさん2009/02/05(木) 00:51:29
Code Complete には int *p にせよと書いてあったが、俺は >108 方式。

>>104
リンクまで込みでじゃなくて、一つのファイルをコンパイルするので？
そこ辞めてヨソ行った方がいいかも。
0113デフォルトの名無しさん2009/02/05(木) 01:00:05
>>112
趣味で書いたやつでテンプレートをひどく使ってそういう事態になったことはあるが、
仕事なら絶対にできないな。
0114デフォルトの名無しさん2009/02/05(木) 09:44:40
なんでC/C++は宣言の時、int *a, *b;という構文にしたんだろう？
キャストやテンプレートではint*を使うことになるのに。

スレ違いか。
0115デフォルトの名無しさん2009/02/05(木) 17:16:21
>>114
*aがint型と読めるという話はよく聞く。
関数・配列が複雑に絡み合ったのも、そうやって解読していくし。

C++はCとの互換のため。
0116デフォルトの名無しさん2009/02/05(木) 19:33:24
>>114
constへのポインタとconstポインタを
はっきり書きわけられることはメリット。

ぱっと見はわかりにくい文法だけど、
関数へのポインタとかも含めていろいろ
わかってくると、全体としては悪くないと
納得せざるをえないと思う。
0117デフォルトの名無しさん2009/02/05(木) 20:44:49
>>116
それがどうした
0118デフォルトの名無しさん2009/02/05(木) 21:24:38
>>116
const int* a, b;// aもbもconstへのポインタ
int* const c, d;// cもdもconstポインタ
こういう文法にして欲しかった。

関数へのポインタの宣言はかなり気持ち悪く感じる(typedefの挙動なんか特に)。
こっちもなんとかして欲しかった。
0119デフォルトの名無しさん2009/02/05(木) 21:28:31
でも、ポインタを戻り値とする関数と区別するためにはやむを得ないんだよな・・・
0120デフォルトの名無しさん2009/02/07(土) 04:21:07
>116
単純に記述量を減らすためかと。

例： int a = 1, *p = &a;
0121デフォルトの名無しさん2009/02/07(土) 10:03:22
>>120
別の型を1行で宣言したいと思わない。
むしろint *a,*bがint* a,bで宣言できたら、1行で宣言する変数が１つ増える毎に1文字タイプ量が減ってありがたい。
0122デフォルトの名無しさん2009/02/07(土) 10:16:16
>>119
関数へのポインタの宣言は例えばboost::function風に
void F(int);
function_ptr<void, int> a = &F;
これなら見やすい。
0123デフォルトの名無しさん2009/02/07(土) 17:22:52
今でも、C++でBoost使えば、functionっぽく書ける。実際に使うかどうかは別として。
void f(int, double);
boost::mpl::identity<void (int, double)>::type* pfn = f; //void (*pfn)(int, double) = f;と同じ
まあ素直にtypedefすべきだな。
01241202009/02/08(日) 00:38:56
無名の構造体て書けなかったっけ?
そのポインタを宣言するのに必要な気がする。

struct ｛
｝ obj, *p;
0125デフォルトの名無しさん2009/02/08(日) 00:41:41
それって、コンパイラが勝手に適当な名前を付けるやつだっけ
0126デフォルトの名無しさん2009/02/08(日) 10:25:49
>>124
そのp使い道なくない？
型名が無名だから関数の引数に渡せるわけじゃないし、ヒープから確保することもできない。
0127デフォルトの名無しさん2009/02/08(日) 12:50:57
インスタンスが２つあれば、その切り替えに使えるかもしれないが、
ま、そこまでするなら型名付けた方がいいと思う。
0128デフォルトの名無しさん2009/02/08(日) 13:07:35
typedef struct ｛
｝ t, *p;
こんなのなら見るけど
0129デフォルトの名無しさん2009/02/09(月) 21:09:40
>>99
C言語のこの仕様はポインタの理解をさまたげてくれたなあ・・・
Delphiは前者が前提なんだが、C挫折してDelphiやってはじめてポインタの概念がわかったよ俺は
ポインタって「なんとかのポインタ」で1つの型なんだ、と気づくまでにやたら時間がかかた。
0130デフォルトの名無しさん2009/02/10(火) 12:22:29
ポインタ宣言に使う記号がアスタリスクなのもややこしいよね。
ポインタ絡みで間接演算子使うだけに。
0131デフォルトの名無しさん2009/02/10(火) 12:28:56
if(flag){
}
if(flag == true){
}
どっちを選べばよいか･･･
0132デフォルトの名無しさん2009/02/10(火) 12:34:02
>>128 構造体の typedef 禁止
0133デフォルトの名無しさん2009/02/10(火) 13:29:14
>>131
前者に決まってる。論理定数との比較は無意味。
http://www.kouno.jp/home/c_faq/c9.html#2
0134デフォルトの名無しさん2009/02/10(火) 15:04:14
if(flag){
この間にいくつスペースを挟めばいいのかわからない
0135デフォルトの名無しさん2009/02/10(火) 16:26:13
入れなくてもいいし、入れるのならif (flag) {がお勧め。
0136デフォルトの名無しさん2009/02/10(火) 17:11:33
"if"の後に一個、
"("の後に一個、
")"の後に一個スペースを入れないと、
かつ、二個以上入れた場合、コンパイルできない

とかいう仕様だったらいいのに。
俺は末期か・・・
0137デフォルトの名無しさん2009/02/10(火) 20:49:28
if の後に空白を入れるスタイルだと、
条件が二行以上に渡る場合に４タブで綺麗に揃う
0138デフォルトの名無しさん2009/02/10(火) 20:52:17
>>136
MS信者？
0139デフォルトの名無しさん2009/02/10(火) 20:53:07
if ( hoge) {

こうか？
バランス悪すぎ
0140デフォルトの名無しさん2009/02/10(火) 23:27:25
>137
漏れはこう
if( 条件1
|| 条件2 )
0141デフォルトの名無しさん2009/02/11(水) 00:28:58
既存のコードにあとから手を付ける場合は、出来るだけ合わせて書いてるな
0142デフォルトの名無しさん2009/02/11(水) 01:38:12
最近はワイドモニタだから、右に長くなりがちだなぁ。

基本は>>140と一緒だが。
0143デフォルトの名無しさん2009/02/11(水) 01:57:32
じじいに言わせると80桁を越すと犯罪らしいぜ
0144デフォルトの名無しさん2009/02/11(水) 02:00:18
コーディング規約でも規定されない限り、横の長さはそれほど神経質に考えないな
ある程度は工夫するけど
0145デフォルトの名無しさん2009/02/11(水) 03:22:49
モニタが大きくなるとかえって80桁とかに縛りたくなる。
横にいくつもウィンドウを並べてみるのに都合がいい。
0146デフォルトの名無しさん2009/02/11(水) 06:14:45
端末エミュレータを三つ並べても100桁表示できるご時世だから、気にしてもねぇ。
そんな私はどちらかと言えばこっち。
if (条件1 ||
   条件2) {
0147デフォルトの名無しさん2009/02/11(水) 15:00:02
デバッガでトレースしやすいように１行で書いてる。
if (条件1 || 条件2 || 条件3 || 条件4 || 条件5 || 条件6 || 条件7 || 条件8 || 条件9 || 条件10) {
0148デフォルトの名無しさん2009/02/11(水) 15:06:14
ソースコード関係ないけど、未だにWindowsのデスクトップの縦のアイコン数は、1024ｘ768時代の数だなｗ
でも最近Windows7使ってると、その傾向はなくなってきた（Vistaは常用したことない）

エディタは、文字数による改行なしで設定するのが俺のジャスティスだな
0149デフォルトの名無しさん2009/02/11(水) 22:19:15
>>133
別に後者がいいとはまったく思わないが
trueとTRUEは違う
よってそのリンク先は根拠にならない
0150デフォルトの名無しさん2009/02/11(水) 22:25:43
>>149
true でも TRUE でも以下の話は同じ。
> もし君が「if((a == b) == TRUE)」が「if(a == b)」の改良版であると信じるのなら、な ぜそこで止めるのか。なぜ「if (((a == b) == TRUE) == TRUE)」を 使わないのか

論理定数との比較自体が無意味。
0151デフォルトの名無しさん2009/02/11(水) 22:26:58
((a == b) == TRUE)
↑これ何の冗談？ｗ
0152デフォルトの名無しさん2009/02/11(水) 22:30:57
>>151
つまりそういう皮肉
0153デフォルトの名無しさん2009/02/11(水) 23:00:51
>>150
それ、主題じゃないし
さらにその例はFAQそのものが不適切だ

論理定数との比較云々じゃなくて（そこは同意する）
そのFAQが違うだろって話ね
0154デフォルトの名無しさん2009/02/11(水) 23:16:29
>>153
うるせぇなぁ。少しは応用しろよ。

>131 へのレスで挙げてるんだらこういうことだろ。
もし if(flag == true) が if(flag) より良いと思うのなら、なぜそこで止めるのか。
なぜ if(flag == true == true) を使わないのか。
0155デフォルトの名無しさん2009/02/12(木) 01:10:46
処理上は無意味でも
if ( flag )より
if ( flag == true )のが
わかりやすくないか？
0156デフォルトの名無しさん2009/02/12(木) 01:13:50
それじゃflagが２だったらとおらねぇだろ
0157デフォルトの名無しさん2009/02/12(木) 01:16:11
それでいいじゃんｗ
2が入ること自体がおかしい
0158デフォルトの名無しさん2009/02/12(木) 01:27:37
>>155
処理上は無意味でも
if ( flag == true )より
if ( flag == true == true )のが
わかりやすくないか？
0159デフォルトの名無しさん2009/02/12(木) 01:41:46
trueはfalse以外が仕様だからそれじゃダメだっての。

if ( flag )
if ( flag != false )

これ以外は許されない
0160デフォルトの名無しさん2009/02/12(木) 01:47:26
>>159
flag の型がちゃんと bool ならどっちでもいっしょ。

それよりも if ( flag != false != false ) のが（以下略
0161デフォルトの名無しさん2009/02/12(木) 02:12:25
>>160
C言語だとダメなやつもあるから、0と0以外にしとくのが安全なスタイルってもんだよ。

比較演算の結果でてくる論理を比較するのもありだけどね。

assert( (p == NULL) != false );
0162デフォルトの名無しさん2009/02/12(木) 02:15:40
>>161
わざわざ「flag の型がちゃんと bool なら」って書いてあるのに何言ってんの？

> assert( (p == NULL) != false );

ねーよ
0163デフォルトの名無しさん2009/02/12(木) 02:33:29
いやいや、そこはこうでしょ
assert( (p == NULL) != false != false);ってのが(ry
0164デフォルトの名無しさん2009/02/12(木) 02:47:00
だからさ、FAQの
> もし君が「if((a == b) == TRUE)」が「if(a == b)」の改良版であると信じるのなら、な ぜそこで止めるのか。なぜ「if (((a == b) == TRUE) == TRUE)」を 使わないのか
これがそもそもおかしい
おそらく原作者はジョークのつもりだったろうが、真に受けてるアホがいるからな・・・
0165デフォルトの名無しさん2009/02/12(木) 02:58:25
Cの(ユーザー定義の)TRUEとC++の(言語の)trueの違いがわかってない奴がいるな
Cでif(flag==TRUE)は間違いだが、C++でif(flag==true)は書き方の問題だ
書き方の問題＝好みだよ

ここでif((flag==true)==true)を持ち出す奴はジョークが理解できないってことだ
0166デフォルトの名無しさん2009/02/12(木) 03:50:19
>>164
で、何がいいたいの？論理定数との比較を擁護するつもりなの？
0167デフォルトの名無しさん2009/02/12(木) 04:00:02
>>165
はなから技術的な正しさとか間違いとかを問題としてるんじゃない。
論理定数との比較に意味が無く、混乱の元でしかないから書くべきではないという話だ。
(... == true) も (... != false) も同じくらいに意味が無い。
0168デフォルトの名無しさん2009/02/12(木) 04:43:58
意味あるじゃん
ある特定の人間にとっては見やすいという意味が
0169デフォルトの名無しさん2009/02/12(木) 05:01:14
カスみたいな意味だな。
0170デフォルトの名無しさん2009/02/12(木) 10:58:38
一番ダメなのは is～, has～, can～ などの自然に読み下せるように工夫した命名規則を
台無しにしてしまうこと。

if (x.isReady()) で済むところを
if (x.isReady() == true) だの
if (x.isReady() != false) だの
わざわざノイズを混ぜるのが許せない。
0171デフォルトの名無しさん2009/02/12(木) 11:49:41
俺はif(flag)派だが、if(flag==true)なソースを見てもいちいち噛み付かないな
TRUEは明らかに不味いがtrueは見た目の問題、見易いかどうかは主観だからな
それをノイズと感じるのも自由だし、そんなのは人に押し付けなければどっちでもいい

それよりTRUEとtrueを混同して大昔のFAQを持ち出したり、
技術と好みの違いが分からない奴の方がスキル低いだろ
0172デフォルトの名無しさん2009/02/12(木) 13:42:38
TRUEとの比較には問題があるなんて>>133なども当然理解しているだろ。
それは誰もが理解しているという前提で、本筋からそれるのでスルーしただけにしか思えない。
0173デフォルトの名無しさん2009/02/12(木) 22:31:56
初見のソースでif( hoge == true ) と書かれていると、hogeがboolになっているか、
そうでなければtrue/falseの2値しか取り得ないのかチェックする手間が生じる。
初見じゃなくてもどうなってるかいずれ忘れるかもしれない。
（そんなの気にしないとかってのは論外過ぎる）

if( hoge != false ) も、万人がつっかえず読めるソースであるとは言い切れない。
0174デフォルトの名無しさん2009/02/13(金) 00:20:00
もしかしてflagが２でも==trueなら通るのか？
0175デフォルトの名無しさん2009/02/13(金) 00:35:12
flagに2が入っている時点で不具合だとしか思わない
bool型ならな
0176デフォルトの名無しさん2009/02/13(金) 01:02:25
素直に!=falseにしとけよ。
0177デフォルトの名無しさん2009/02/13(金) 04:07:26
>>172
理解してたらtrueに対してFAQ(TRUE)を持ち出さないだろ
0178デフォルトの名無しさん2009/02/13(金) 10:51:29
ヘンなケースだけど if (flag) 形式は
うっかり bool の配列を渡してハマりそうになったことあるなぁ
bool array[2];
if (array)
みたいな
0179デフォルトの名無しさん2009/02/13(金) 14:13:43
>>173
初見のソースでif(hoge==1)と書かれていると、hogeがintになっているか、
チェックするのか？しないだろ？
ただのいいがかりじゃねえか、おまえの頭が論外だよｗ
0180デフォルトの名無しさん2009/02/13(金) 14:19:19
読み違えてるよ
0181デフォルトの名無しさん2009/02/13(金) 14:23:58
hoge == 1 は何とも思わないが、 hoge == true を見つけたら bool 値に対する理解が
不十分な可能性を疑わざるを得ないだろうね。バグを探してるときならなおさら。

signed/unsigned が混在してたり、可変長引数にキャスト無しの NULL を渡してたり、
ループ変数に char が使ってあったりするのと同じ。言語仕様の不十分な理解から出る
バグのにおいがする。
0182デフォルトの名無しさん2009/02/13(金) 14:37:11
hoge==true見つけただけで言語使用を理解してない可能性を疑うってどんだけレベルの低い環境なんだ
ところで181の挙げた例に細かいミスがあるんだが、普段の俺ならスルーしてあげる
だが181の論理によれば、俺からみたら181は言語使用を理解してないと疑わざるを得ない
0183デフォルトの名無しさん2009/02/13(金) 14:38:48
言語使用→言語仕様
01841812009/02/13(金) 14:43:46
何かミスがあるというなら言語仕様を理解していないと疑われるのはしかたがないと思うけど、
できればはっきりと指摘してほしいところだね。
0185デフォルトの名無しさん2009/02/13(金) 14:46:01
どうせハッタリだろ。
0186デフォルトの名無しさん2009/02/13(金) 15:08:25
なんか話ずれてるけど
173はif(hoge==true)ならhogeがboolかチェックするんでしょ？
もうその時点でありえないんだけど、そんな底辺レベルの職場なら
if(hoge==1)でもhogeがintかチェックする必要がある、チェックしないのはダブスタじゃん
って意味だよね、違う？

普通の職場なら同僚やらオープンソースで
if(hoge==true)見つけても、「あらあら、このひとはtrueと比較しちゃうんだ」って思って終わりだよ
どんだけ病んだ職場で働いてるんだ、転職したほうがいいよ
0187デフォルトの名無しさん2009/02/13(金) 15:25:30
>>186
hoge == true （あるいは hoge != false ） を書くような人は bool 型や if 文になどついての理解が
あやふやな可能性が高いので、同様に理解の不足から int == true などという間違いを犯している
可能性があることを推測できる。

hoge == 1 を見ただけではそのような推測はできない。

関連箇所でのバグを探してるんじゃなければスルーすることも多いだろう。それが普通だというのも
妥当な話だ。しかし、スレタイを読む限りここでそれを主張するのは無意味だろう。
0188デフォルトの名無しさん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) ....

って、かかんとあかんわけ?
0189デフォルトの名無しさん2009/02/13(金) 20:15:31
関数が何返したのか分かりにくい
01901732009/02/13(金) 22:09:36
>179,182
if( hoge == TRUE )のケースを考えてみてよ。
hogeは本当にTRUEかFALSEしか取り得ないのか不安にならない?
漏れが指摘したいのはむしろこっちの方なんだよ。

if( hoge == true )の場合は気にし過ぎってのは素直に認める。
（コンパイルすりゃすぐ分かるというのはEnter押してから気付いた）
でもバグ発生時には疑うべき記述だと思う。
0191デフォルトの名無しさん2009/02/13(金) 23:40:30
if ((!!flag == true) != false) {
　　flag = true;
　　flag = true; // 念のためもう一度
}
これくらいやっとけば安心
0192デフォルトの名無しさん2009/02/14(土) 00:48:46
実際、trueやfalseと比較し捲くっているコードを整理したら、若干ではあるけど
所要時間に有意差が認められたからなぁ。
0193デフォルトの名無しさん2009/02/14(土) 01:01:22
(1) if( hoge == TRUE )
(2) if( !!hoge == true )
(3) if( hoge == true )
(4) if( hoge )

最悪のケースを想定した場合、読み手が考え込む時間が一番短いのは(4)でしょ。
ifの動き、hogeの値、コーディングスタイル、ネーミング位しか悩める要素が無いんだから。
他は最悪、型とか脳内演算とかで、余計な思考時間を生んでしまう恐れがある。
0194デフォルトの名無しさん2009/02/14(土) 01:35:45
true との比較では所要時間に差は出るだろうが
false との比較で差が出るのは最適化レベルがおかしいんじゃないのか
01951922009/02/14(土) 01:41:23
>>194
trueもfalseも纏めて整理したから、falseの有無で差があるかは確認していない。
0196デフォルトの名無しさん2009/02/14(土) 01:42:04
あえて(2)を混ぜて誤魔化してないか？ｗ
0197デフォルトの名無しさん2009/02/14(土) 11:27:41
trueと比較しない場合
>>178みたいなのでハマるくらい?
0198デフォルトの名無しさん2009/02/14(土) 11:52:14
逆にboolをtrueと比較して困るケースの具体例、つか経験談ってある？
0199デフォルトの名無しさん2009/02/14(土) 11:58:59
>>198
1以外の値が入ってるときとか。
0200デフォルトの名無しさん2009/02/14(土) 11:59:12
>>198
>194
0201デフォルトの名無しさん2009/02/14(土) 16:47:04
ちょっと違う話かも知れんが、

if (式) {
　return true;
} else {
　return false;
}

なんてプログラムを見ることがたまにある。
最初からreturn 式;にしろよ、って思う。
0202デフォルトの名無しさん2009/02/14(土) 16:48:03
変更になりそうな箇所がおおいならそう書くこともある。
0203デフォルトの名無しさん2009/02/14(土) 19:46:26
漏れはこうだなあ。

if (式) {
　return true;
}
return false;
0204デフォルトの名無しさん2009/02/14(土) 19:54:47
そういうのを書く時は最終的にtrueを返すようにしてるな
0205デフォルトの名無しさん2009/02/14(土) 19:55:23
return (式) ? true : false;
0206デフォルトの名無しさん2009/02/14(土) 21:41:18
>>205
これはないな。
0207デフォルトの名無しさん2009/02/14(土) 21:58:37
式が関数でtrue/falseの意味が取り違える可能性があるような名前ならアリかもな。
0208デフォルトの名無しさん2009/02/15(日) 16:12:23
>>205
俺もこれだけはやっちゃダメだろとは思う
マクロならそうなるけど

自分のことしか考えてないタイプ
0209デフォルトの名無しさん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;
}
--
これ見たときはどうしてくれようかと思った。
0210デフォルトの名無しさん2009/02/15(日) 17:55:06
設計書にそういう「ロジック」を書いてるんだろうなあ。。。

1. 引数は値、レベル、反転フラグとする。
2. 反転フラグが _False であれば、以下を行う。
　　1) ・・・
3. 上記以外の場合、以下を行う。
　　1) ・・・

日本人プログラマが10人いれば、8人は何も考えずにコーディングを行う。
1人は、「反転フラグて。。。呼び出し側で結果を反転させりゃいいのに。。。」とか思いながらコーディングを行う。
残りの1人だけが「なんで設計書にロジック書いてんだｗｗｗこの現場やべえｗｗｗ」と笑い、辞める。
0211デフォルトの名無しさん2009/02/15(日) 18:11:22
>>210
設計書を書いた奴と相談するっていう選択肢が無いのが悲しいな。
0212デフォルトの名無しさん2009/02/15(日) 20:05:55
_Booleanはどういう定義なんだよソレｗ
02132092009/02/15(日) 20:14:34
>>212
おっと、書き忘れてた。
＞typedef enum { _False = 0, _True = 1 } _Boolean;
だとさ。ちなみに、Sun-OSのcc(標準ではc99としてコンパイルする)を使っているのに
c99禁止と言う不思議なコーディング規約(と言っても明文化されていない)だし。

>>210
>209のコードに関しては、設計者=コーダーの可能性大。
0214デフォルトの名無しさん2009/02/16(月) 05:43:24
"<="や">="を書くことが幼稚な気がして今まで避けてきたんだが
"<"や">"は小数を扱うのが正しい使い方で、
整数を扱う場合はイコールをつけたほうが直感的な気がする
for(int i=0; i<10; i++)
ってのが一般的で10回カウントするってのが直感的にわかるけど
なんというか、行って帰ってきて結果的にはあってるって感じで、
for(int i=0; i<=9; i++)
のが1から9まで1ずつカウントするって意味で
正しい使い方な気がする
0215デフォルトの名無しさん2009/02/16(月) 05:47:32
１からじゃなくて０からでした
0216デフォルトの名無しさん2009/02/16(月) 06:00:51
>>205が何でだめなのか、プログラミング初級者の俺に教えてくれ
無駄がなくてわかりやすいと思うんだが
0217デフォルトの名無しさん2009/02/16(月) 07:21:32
1. 返り値がニ値しか取りえないなら、isHoge関数にすべき
2. 構文糖衣はあくまで糖衣
3. 流し読みする時に目に入り辛い
(最後の行だからいい？一カ所使われていると、
複数箇所使われている可能性が高いから、結局同じこと)
0218デフォルトの名無しさん2009/02/16(月) 07:39:52
>>214
＞１からじゃなくて０からでした
こういう馬鹿が居るから直感的じゃないんだよ。
0219デフォルトの名無しさん2009/02/16(月) 09:29:50
>>216
「? true : false」の部分が丸々冗長。
単純にこれを消しても同じ意味だよ。
0220デフォルトの名無しさん2009/02/16(月) 22:36:57
式が bool 型ならそうだろうが
そうじゃなけりゃえらい違いだよ。
bool 型へのキャストは警告出すコンパイラがあるんで、
やむを得ず ? true : false としないといけない。
マクロ化したいけど、作ってもみんな使ってくれないし・・・。
0221デフォルトの名無しさん2009/02/16(月) 22:44:33
強制的に bool にしたいなら !!(式) でいいだろ。
0222デフォルトの名無しさん2009/02/16(月) 22:56:47
Cだったら、0か0以外にしとけばいいんだよ。
0223デフォルトの名無しさん2009/02/16(月) 22:59:57
>>220
条件演算子なんか使わなくても、比較式入れとけばいいじゃん。
0224デフォルトの名無しさん2009/02/16(月) 23:10:01
真偽値を比較するなんてとんでもない！
0225デフォルトの名無しさん2009/02/16(月) 23:26:09
>>224
真偽値だったら、そのままreturnすればいいんじゃね?

#define true 0
#define false -1
↑みたいな変態的な定義でもされてたら、条件演算子もやむなしって気がするけど。
0226デフォルトの名無しさん2009/02/16(月) 23:44:02
自分だったら!!よりは? true : false選ぶなあ。
0227デフォルトの名無しさん2009/02/16(月) 23:48:27
>>225
bool hoge(int ch) {
　return isupper(ch);
}

isupper の戻り値は真偽値（int 型の非0/0）だが bool ではない。
コンパイラによってはそのまま return すると文句言われる事がある。
0228デフォルトの名無しさん2009/02/16(月) 23:58:38
>>227
いや、だから、真偽値以外だったら、比較にすればいいんじゃね?って話。

　return isupper(ch) != 0;


0229デフォルトの名無しさん2009/02/16(月) 23:58:49
>>225
それが標準だったらどんなに良かったかと常々思ってる。
0230デフォルトの名無しさん2009/02/17(火) 00:03:33
>>229
trueやfalseが標準で定義されていて、
n > 0 みたいな比較式の結果と違う値になってたらよかったってこと?
0231デフォルトの名無しさん2009/02/17(火) 00:15:34
>>228
真偽値を比較するなんてとんでもない！
ぶっちゃけ読み辛くてしゃーない。
0232デフォルトの名無しさん2009/02/17(火) 00:23:21
>>231
ああ、それはそうだな。
Cライクな真偽値と、C++のboolを併用するときはしかなないのかね。
static_cast<bool> とかするとどうなるんだろう。
0233デフォルトの名無しさん2009/02/17(火) 00:25:08
VC++はboolへのあらゆる直接的な変換は警告出した気がする
0234デフォルトの名無しさん2009/02/17(火) 00:25:56
g++はノーキャストでも完全スルーなんだが
0235デフォルトの名無しさん2009/02/17(火) 00:52:23
>>220
式が bool じゃなくて return するのに問題があるというのなら、
? の左に書くのだって同じ問題があるはずじゃないか。
やっぱり、? 以降は単純に冗長だよ。
0236デフォルトの名無しさん2009/02/17(火) 22:58:25
だーかーらー、五月蝿い警告が出るコンパイラへの対策なだけだと言うとるに。
どのコンパイラでも警告でないならそのまま返したいさ、そりゃ。
0237デフォルトの名無しさん2009/02/18(水) 01:36:14
>>236
うるさいっていうかアホだろ。

return での bool への変換は警告するのに
? 演算子の前に置いたときの bool への変換は出ないとか、
意味がわからん。

そもそも警告を黙らせるためのコードなんか書いちゃいけない。
警告によって指摘された問題に対策しないといけない。
0238デフォルトの名無しさん2009/02/18(水) 04:04:58
そりゃそうだ。C/C++に、?の左側に置いた式はbool型に変換されるなんて規則はないから
そこでbool型への変換だなんて警告が出るわけない。
0239デフォルトの名無しさん2009/02/18(水) 04:33:49
>>238
何を根拠にそんなこと言うの？
C++ の ? は bool に変換して評価するよ。
5.16 Conditional operator p1
> The first expression is contextually converted to bool (Clause 4).
0240デフォルトの名無しさん2009/02/18(水) 05:14:14
そうだったのか。
C99だけ見ていたが、こっちは、0と比較して云々となっていて、
_Boolへ変換するとは書かれていなかった。
C++もそんな調子だと思っていたよ、すまない。
0241デフォルトの名無しさん2009/02/18(水) 13:47:17
C99 なら _Bool f(int x) { return x == 1; } でも比較演算自体は int だから警告が出るというのか？
それもアホだな。
0242デフォルトの名無しさん2009/02/18(水) 14:45:41
そんなこと言ったら C99 では true も false も int 型なわけで。

結局のところ "? true : false" がまったく冗長なだけの記述には違いないね。
0243デフォルトの名無しさん2009/02/18(水) 19:22:44
ECMAScriptなら冗長でないよ
0244デフォルトの名無しさん2009/02/18(水) 21:31:42
どでもいいけど、システムハンガリアンって呼ばれてる
変数のタイプをプリフィックス/ポストフィックスとして
つける命名規則だけは絶対裂けるべきだ

一部に改訂が入って、使ってる型の定義が変わった場合の
メンテナンスはとんでもないことになる
0245デフォルトの名無しさん2009/02/19(木) 00:03:28
下手に否定するより、よりベターな手法を教えてそっちに誘導した方が良い。
チーム全体に徹底させるだけの権限と統治力を持ってない場合は特に。

人は力強く押さないとあらぬ方向に進むが、引っ張れば割とすんなり思った方向へ進む。
0246デフォルトの名無しさん2009/02/19(木) 12:32:31
>>244
WIN16→WIN32→WIN64の悲劇ですね。
0247デフォルトの名無しさん2009/02/19(木) 21:33:35
WORD型やDWORD型なら、typedefを書き換えればいい
たぶん・・・
0248デフォルトの名無しさん2009/02/19(木) 23:15:01
スタイルスレで聞きたいと思ったことが１つあるんだ。

C++のcppの方にソースを見やすくするために関数を小分けにしたものを
staticで記述して使ってるんだが、private関数にするべきかね？
0249デフォルトの名無しさん2009/02/19(木) 23:28:51
>>248
privateにしなくてもいいんじゃね?
C++のprivateって、そもそもが美しくないし。
0250デフォルトの名無しさん2009/02/19(木) 23:47:33
どっちかっていうと、外部にも派生クラスにも公開する気がない関数はクラスに含めるべきじゃないと思う。
クラスのインターフェイスとは関係ない、実装側だけの問題なら、実装側で完結してるほうが美しい。
static 関数なら、いくら変更しても外部には影響しないし。
0251デフォルトの名無しさん2009/02/20(金) 00:02:01
継承したときにvirtualつけて使いたいけど、クラス外からは使われたくないものに
だけつけときゃいいのか。
0252デフォルトの名無しさん2009/02/20(金) 00:02:30
static関数化できるものなら、Utilityクラスとかにして
外に出しちゃうのも良い鴨
02532492009/02/20(金) 00:05:44
staticって、クラスのメンバとしてか。。。
勘違いしてた。
0254デフォルトの名無しさん2009/02/20(金) 00:16:57
メンバのstaticではなく実装用の小規模な補助関数ってことで。
0255デフォルトの名無しさん2009/02/20(金) 01:12:07
>>248
.cpp ローカルな関数は static じゃなくて無名名前空間を使う。
private にすべきかどうかはクラスのメンバであるべきかどうかで区別する。

何も考えずに書くと private 関数の宣言をヘッダに書くことになるんで何かおかしな
感覚になるけど、 pimpl とかインターフェース継承とか使って隠せば問題ない。
0256デフォルトの名無しさん2009/02/20(金) 01:22:53
なるほどね。いわゆるCのstatic関数ってのは推奨されてないのかな。
そこまで意識して気をつけようとも思わないけど、気が付くと疑問に思う。
0257デフォルトの名無しさん2009/02/20(金) 01:25:22
>>256
関数や変数だけならいいんだけど、 C と違って .cpp ローカルな struct や enum も
グローバルに置いてると定義がかぶってアウトだから、なるべく無名名前空間を使う
癖をつけておいたほうがいいよ。
0258デフォルトの名無しさん2009/02/20(金) 12:56:17
>>257
それだけなら別にアウトじゃない。
規格としてはダメかもしれんが。

ただ、メンバ関数はリンケージをファイル
スコープにできないから、無名名前空間が
絶対必須。
0259デフォルトの名無しさん2009/02/21(土) 17:20:06
addとappendや、eraseとremoveの使い分けってどうしてる？
0260デフォルトの名無しさん2009/02/21(土) 17:28:41
addは追加、appendは付加。
eraseは消去、removeは除去。ついでに言えばdeleteは削除。

まぁ、それでも巧く決まらないときは既存ライブラリの命名に倣ったりするが。
0261デフォルトの名無しさん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に近いのかな？
0262デフォルトの名無しさん2009/02/21(土) 21:03:27
erase(A) はAによって識別される何かを削除する
delete(A) はAを削除する
remove(A) はAを取り除くが削除されるかどうかは仕様次第
0263デフォルトの名無しさん2009/02/22(日) 13:37:57
append は後ろに追加するような意味だから
例えば map や set には使えない
でも add なら使えると思う
0264デフォルトの名無しさん2009/02/22(日) 17:56:13
使われ方みると前 insert,後 appendで対って感じだな
0265デフォルトの名無しさん2009/02/23(月) 13:48:14
ちなみに、先頭に加えるのは prepend っていう。
0266デフォルトの名無しさん2009/02/23(月) 14:29:25
難しく考えないでAddFirst/AddLastでいいと思う
javaや.NETのコレクションではそうなってる
0267デフォルトの名無しさん2009/02/23(月) 16:32:13
似た言葉をニュアンスの違いで使い分けたりするのはやめるべき
0268デフォルトの名無しさん2009/03/21(土) 10:44:11
ははは
0269デフォルトの名無しさん2009/04/17(金) 16:59:50
突然このスレにたどりついた俺は

if(hoge(var) == 0) じゃなくて、絶対 if (0== hoge(var)) 派だ

なぜなら左辺が変数のときに

if(var == 0) じゃなくて、絶対 if (var = 0) と書いてバグらせてしまう
奴がプロジェクトに出るからだ（中々見つけにくいんだな、このバグ）

後、関数の出口の return が必ず末尾の一つだけってプロジェクトに
参加したことがあるけど、処理の条件が変わっても、メモリリークが
出にくい構造になるのは良いと思った
0270デフォルトの名無しさん2009/04/17(金) 17:10:55
> 後、関数の出口の return が必ず末尾の一つだけってプロジェクトに
> 参加したことがあるけど、処理の条件が変わっても、メモリリークが
> 出にくい構造になるのは良いと思った

これは結局ケースバイケースで、関数的（副作用がない）なコードが主か、
副作用とかバリバリか、で変わってくるよね。
あと、例外的な場合の処理にgotoを許すか、とか。
0271デフォルトの名無しさん2009/04/17(金) 17:44:38
>中々見つけにくいんだな、このバグ
最近のコンパイラなら確実にwarning出すんでそうでも無い
0272デフォルトの名無しさん2009/04/17(金) 22:26:29
ついでに言えば、比較対象が0ではなくて変数だったらやっぱり検出できないから殆ど意味がない。
0273デフォルトの名無しさん2009/04/18(土) 01:02:21
RAII 使え、 const 付けとけ、って話でもあるな。
0274デフォルトの名無しさん2009/08/21(金) 17:39:24
まぁOOPが不可能なプロジェクトなら、そういうリーク対策にも意味はあるかもしれんね
OOPが可能なら、RAII（厳密にはデストラクタによる資源解放）の徹底も可能だよな
0275デフォルトの名無しさん2009/08/31(月) 12:09:43
>>269
C/C++で、zeroとの比較をするのであれば、
if (hoge(var) == 0)とぜすに、if (!hoge(var))の方が目的がはっきりする

比較する数値がたまたまzeroであるのなら、数字で比較すべきではない
定数化された変数を用いるか、#defineマクロで名付けられた定数を用いるべきだ

よって条件式に、数字が書き込まれている時点で何かおかしなコードであると思われる
0276デフォルトの名無しさん2009/08/31(月) 12:32:58
>>275
しかしstrcmpの時ははゼロを扱っていいと思う。
0277デフォルトの名無しさん2009/08/31(月) 12:38:20
おばかのきわみ > #define ZERO 0
0278デフォルトの名無しさん2009/08/31(月) 12:55:27
>>276
その場合、BASE_CMPとか名付けて比較したほうが分りやすい予感
0279デフォルトの名無しさん2009/08/31(月) 13:11:50
>>278
少なくとも俺は今、BASE_CMPナニソレ？(´･ω･`)　ってなってるが。
0280デフォルトの名無しさん2009/08/31(月) 13:12:58
>>278
CMP_OBJCTじゃね?
0281デフォルトの名無しさん2009/08/31(月) 13:15:20
>>275
あほか。
「ゼロと比較する」という処理ならコードにそのまま書いたほうがいいだろｊｋ
0282デフォルトの名無しさん2009/08/31(月) 13:22:58
#define STREQ(a, b) !strcmp((a), (b)) みたいなマクロに
0283デフォルトの名無しさん2009/08/31(月) 13:28:21
>>282
それなら辛うじて許せるような気もするが、
strcmpくらいそのまま使えよ、ってのが正直なところ。

strcmp(a, b) < 0 // a < b
strcmp(a, b) > 0 // a > b
strcmp(a, b) == 0 // a == b

という、並べて書いた上での法則がせっかくあるのに。
0284デフォルトの名無しさん2009/08/31(月) 18:55:48
>>278
わかりやすくねーよ。
イディオムはそのままにするべき。
0285デフォルトの名無しさん2009/08/31(月) 19:01:39
strcmpの場合
比較対象と同等か、大きい、もしくは、小さいだから
>>282よりはマシだろ
0286デフォルトの名無しさん2009/08/31(月) 19:04:58
>>285
意味不明(´･ω･`)
0287デフォルトの名無しさん2009/08/31(月) 19:25:05
>>275
> if (hoge(var) == 0)とぜすに、if (!hoge(var))の方が目的がはっきりする

そんなバナナ

0との比較なら素直に==0、真偽値としての比較ならそのまま、ってのが普通の感覚だと
思うけどなぁ。まぁ最後は主観だからあれだけど。
0をマクロに入れるなんてのは論外。
0288デフォルトの名無しさん2009/08/31(月) 19:51:24
NULLの分らんアホばっかだな
0289デフォルトの名無しさん2009/08/31(月) 20:10:03
>>287
0との比較の「0」とは何かという話じゃないの？
0290デフォルトの名無しさん2009/08/31(月) 20:14:06
>>288-289
お前ら二人は一体なにをいってるんだ？
0291デフォルトの名無しさん2009/08/31(月) 21:11:58
NULL自体が要らないマクロ
0292デフォルトの名無しさん2009/09/05(土) 23:12:56
初心者なんですが、if (cond == false)って書き方と
if (!cond)ってどちらにすべきですか？
ずっと後者だと思っていたのですが、前者もたまに見かけるので
わからなくなってしまいました。
0293デフォルトの名無しさん2009/09/05(土) 23:50:59
>>292
論理定数との比較はそもそもナンセンスなので、前者は論理値に対する理解が
あやしい感じがする。

たいした理由じゃないんだけど、どちらかというと後者にしといたほうがいいと思うよ。
0294デフォルトの名無しさん2009/09/06(日) 00:27:29
>>293
ありがとうございます。このまま後者の書き方を続けていきます。
0295デフォルトの名無しさん2009/09/06(日) 10:41:39
その cond の名前が ablable とか enabled なら ! allowed のような書き方が良いだろう。
availability とか visibility とかだと、「可視性ですか？」 じゃ頭弱いみたいだから 「可視性は偽ですか」の方が分かりやすいと思う。
専用に enum 作れという話だけど。
0296デフォルトの名無しさん2009/09/11(金) 19:06:43
//これはだめ
hoge(foo,bar);

//これはおｋ
hoge(foo, bar);
0297デフォルトの名無しさん2009/09/11(金) 20:49:45
http://www.eetimes.jp/content/3107

1TBS って初めて聞いた。
0298デフォルトの名無しさん2009/09/11(金) 21:31:02
>297
これ思ったけど、1TBSの方が図2のような間違いは簡単に検出できるような。
（単純に /;\s*{/ で検出できる。オールマンスタイルの場合、ツールによってはマッチしない）

でも個人的にはオールマンスタイルのが好きだけどな。
0299デフォルトの名無しさん2009/09/12(土) 07:31:42
俺は1TBSくらいの黒っぽさが好みだな
もちろん黒すぎるのは辛いけど、オールマンだとちょっと白っぽく感じる

まぁこれはさすがに完全に好みの問題だろうと思うな…
0300デフォルトの名無しさん2009/09/13(日) 02:47:08
そもそも筆者のコメントを打つ位置が気に入らない。 //行末に書くな
0301デフォルトの名無しさん2009/09/13(日) 03:18:16
俺は//の後にスペースがないのが気に入らない
0302デフォルトの名無しさん2009/09/13(日) 11:47:43
一番のツッコミどころは比較式の左辺に定数だろ。
0303デフォルトの名無しさん2009/09/25(金) 00:36:47
そもそも
if(!x)
とか
if(!(z=x-N))
とかやることが多いから==使わないな。
0304デフォルトの名無しさん2009/09/25(金) 07:48:41
条件式に関数呼び出しを書くなってルールもあったな
0305デフォルトの名無しさん2009/09/25(金) 09:26:21
へぇ。どういう理屈でそんなルールが認められるのかさっぱりわからんな。
0306デフォルトの名無しさん2009/09/25(金) 10:21:31
>>305
&& や || のショートカットと関数の副作用の関係
f0() || f1() || …
f0 が成立すると f1 以降が評価されないってのを知らないやつがいるそうだ
なので、こう書かなきゃいけない。とてもうざい。
v0 = f0(); v1 = f1(); …
if (v0 || v1 || …)
0307デフォルトの名無しさん2009/09/25(金) 10:25:40
>>306
それ、 (s && strlen(s) > MIN) とかいう時はどうすればいいの？
0308デフォルトの名無しさん2009/09/25(金) 10:59:33
int len = -1;
if (!s) {
len = strlen(s);
if (MIN < len) {
...
}
}
0309デフォルトの名無しさん2009/09/25(金) 11:00:20
!sじゃなくてsなｗ　素で間違えた。
0310デフォルトの名無しさん2009/09/25(金) 11:26:08
そんなルールおとなしく守ってるプログラマなんてほんとにいるの？
何なの？ばかなの？しぬの？
0311デフォルトの名無しさん2009/09/25(金) 12:08:10
>>310
元請けにコードの監査部隊がいて意地でも書き直させる方法を取っていた
うざくってしょうがなかった
0312デフォルトの名無しさん2009/09/25(金) 12:10:14
その監査部隊を短絡評価の講習要員にすればいいのに。
0313デフォルトの名無しさん2009/09/26(土) 21:43:06
308の書き方だと、正しく読めない/書けない奴が居るから仕方が無い。
一方、漏れらに308の書き方を強制しても、せいぜい能率が落ちるだけ。

実戦の世界じゃ、手駒の性能を上げるよりは数を増やす方が効果的だしな。
平均能力UPの為に手駒を減らすより、平均能力を下げてでも手駒を増やそうってのは
冷徹ではあるが正しい方策。
0314デフォルトの名無しさん2009/09/26(土) 23:32:37
へぼいコーディングルールの話になると、その理論がよくでてくるけど、実際はコーディングルールを
決めてるやつがヘボいだけだろうな。ほとんどの場合。

それに「ヘボいヤツを使うためにヘボいコーディングルールが有効」理論が、本当に正しいかすごい疑問だし。
0315デフォルトの名無しさん2009/09/26(土) 23:42:03
まぁ俺の持論とは真逆だな
ウンココーダの頭数揃えても、精鋭一人にも劣る
0316デフォルトの名無しさん2009/09/27(日) 09:34:49
> 実戦の世界じゃ、手駒の性能を上げるよりは数を増やす方が効果的だしな。
> 平均能力UPの為に手駒を減らすより、平均能力を下げてでも手駒を増やそうってのは
> 冷徹ではあるが正しい方策。

「人月の神話」に燦然と挑戦しているな。
まぁそのような開発分野もあるんだろう。多分。
0317デフォルトの名無しさん2009/09/28(月) 09:09:58
「ヘボいヤツを使うためにヘボいコーディングルールが有効」理論は確かに疑問だが、
十分な精鋭を確保できるプロジェクトなんてほとんど無いんだから、大量のヘボが存在
するのは前提だと思う。
加えて上司も無能だと、そのヘボが逐次投入されてチームは恐竜に、プロジェクトは
タールの沼に。
0318デフォルトの名無しさん2009/09/29(火) 21:53:42
>316
そうでもないと思うが。
1つのプロジェクトに投入する人員については、「人月の神話」の理論で良いけど、
複数のプロジェクトに人員を配置する場合は、>313の理論の方が適している。

308みないなルールは大規模なプロジェクトほど多く、小規模なプロジェクトほど比較的フリーだろ?
（逆な例もある事は承知している）
0319デフォルトの名無しさん2009/09/29(火) 21:57:10
短絡評価が分からないだけならまだしも、「教えても理解できない」という人員なんか
さすがに切り捨てても困らないと思うけどな
0320デフォルトの名無しさん2009/09/29(火) 22:31:14
簡単なコードを量産するような人海戦術プロジェクトでも、上位の2,3割だけ使って、
のこりはじゃまにならないように遊ばせておいても、あんがい生産性あがるんじゃないかって気もする。
0321デフォルトの名無しさん2009/09/29(火) 23:13:59
>>318
人月の神話、読んでないか忘れてるだろ。

>>319
短絡評価に限って言えばその通りだけど、教えられても理解できない部分は人によって違うから。

>>320
論文報告を楽しみに待ってる。
0322デフォルトの名無しさん2009/09/30(水) 00:10:59
どうでもいいけどstrlen()が返すのはintじゃなくてsize_tだよ
0323デフォルトの名無しさん2009/10/01(木) 20:40:57
ストレンツォ容赦せん！
0324デフォルトの名無しさん2009/10/11(日) 14:52:50
>>318
つまり、たとえば優秀なプログラマなら3ヶ月で終わる仕事を一年かけて
（原則同じくらいの人数で）やるけど、
同時に抱えられるプロジェクト数を増やして会社としてのスケールメリットを得るって話？
要するに節約できるのは総務だの人事だのの管理コストの話であって
プロジェクトそのものの効率は上がってないと思うが…
0325デフォルトの名無しさん2009/10/12(月) 02:57:19
>324
プロジェクトの効率は上がらなくても、利益は上げられる罠。
場合にもよるが。
下手すりゃ投入人員と期間を増やせばその分儲かる。

糞ルールがまかり通ってる現場って、大体は上がこんな思想で動いてる希ガス。
0326デフォルトの名無しさん2009/10/12(月) 03:57:31
まぁ、その思想を最高だと思って布教しようとしたりしなきゃどうでもいいけどな
0327デフォルトの名無しさん2009/10/17(土) 11:55:45
javaで

public void XXX() throws YYY, ZZZ {
}

のthrows以下が長くなると80桁超えますけど見やすい折り返し方ないですか？
eclipseのデフォルトで整形すると

public void XXX() throws YYY,
　　　　ZZZ {
}

とやってくれましたけど見づらいな。
0328デフォルトの名無しさん2009/10/17(土) 12:44:58
>>325
思想とか計算づくで、レベル低いんじゃなくて、ただレベル低いだけなんじゃないの?
効率が利益に結びつかないから、淘汰されないだけで。
0329デフォルトの名無しさん2009/10/18(日) 21:42:59
>>324
保守要員みたいなところにエース級は投入せんだろ。

むしろ OJT で勉強させるために新人を。。。
0330デフォルトの名無しさん2009/10/20(火) 11:51:05
>>327
行が長くなるときどう折り返すか
ttp://java-house.jp/ml/archive/j-h-b/009166.html#body
0331デフォルトの名無しさん2009/10/20(火) 12:09:53
C++ 使っててカンマとか演算子の「前」で折り返して、演算子の類が行頭にくるように
してたんだけど、 Python 使い出したらそうもいかなくなって、今は微妙な気持ちです。
0332デフォルトの名無しさん2009/10/20(火) 12:20:08
>>331
英語では普通、カンマやセミコロンなどは単語の後ろに空白なしにつける。当然、改行はその後。
演算子もそれに準じる。
0333デフォルトの名無しさん2009/10/20(火) 13:57:32
>>331
（ ・∀・）人（・∀・ ）ﾅｶｰﾏ

.append(foo)
.append(bar)
.toString();

+ fooooooooooooooooooooooo
- (baaaaaaaaaar % baaaaaaaaz);

= {
11111111111
, 2222222222
, 3333333333
}

if (
(cooooooooooooooond)
|| (baaaaaaaar && bazzzzzzzz)
)

文末を見るより、文頭を見るほうが目の動きが少ない。
0334デフォルトの名無しさん2009/10/20(火) 14:05:42
. を先頭にもってくるのは許せるが、 , を先頭にもってくるのが許せないのはなぜだろう。
0335デフォルトの名無しさん2009/10/24(土) 22:25:29
if ～ else if ～ else の各節にコメントをつけたいとき、俺はこのように書いているんです。
// こういう場合はこう
if (...)
{
}
// こういう場合はこう
else
{
}

ところが、節を分断するのはよくないと言う人がいるんですね。それはそれで一理あります。
その人はこう書いている。
if (...) // こういう場合はこう
{
}
else // こういう場合はこう
{
}

このやり方だと、条件式が長くなったり複数行にわたると、ちっと面倒なことになる。
みなさん、if文のコメントはどのように書いていますか？
0336デフォルトの名無しさん2009/10/24(土) 22:35:25
>>335
if にコメント付いてれば else へのコメントは冗長だろ？考えるだけ無駄。
0337デフォルトの名無しさん2009/10/24(土) 23:21:52
冗長なんて言ったらコメントなんて書けなくなる。
それに複数のelse ifがある場合はコメントがあった方がいい。
0338デフォルトの名無しさん2009/10/25(日) 00:16:58
>>337
お前はなんのためにコメントが書きたいの？
コメントを書くことが目的なの？
0339デフォルトの名無しさん2009/10/25(日) 01:41:21
// コメント
if(...) {
}
else {
// コメント
}
0340デフォルトの名無しさん2009/10/25(日) 02:39:09
>>339
俺もそれだ。
0341デフォルトの名無しさん2009/10/25(日) 02:43:33
俺はこうだわ。space efficiant!!

if(...) { // コメント
  foo();
} else if(...) { // コメント
  bar();
} else {
  foobar();
}
0342デフォルトの名無しさん2009/10/25(日) 07:39:57
漏れは内容に応じて使い分けた方が良いと思うけど。

// 分岐全体について。
if( ... ){　　　// 式について。
　// ブロック内の処理&実行条件の概要
}
else {
　// ブロック内の処理&実行条件の概要
}


（例）
// ～と～を切り分ける
if( … 　　// ～をチェック
&& … ) { // ～をチェック
　// ～の場合、～する
}
else {
　// ～の場合、～する
}
0343デフォルトの名無しさん2009/10/25(日) 14:06:52
こうしてる
if(...) {
　// ...なら～
} else {
　// ～(条件についての記述は無し)
}
0344デフォルトの名無しさん2009/11/22(日) 14:45:58
お前ら、そんな面倒なコメントつけるくらいなら
is_こういう場合() っていう関数作ってif に入れとけよ。

どうしてもコメント書きたかったら
is_こういう場合() のところに書けばすっきりしていいだろ。
0345デフォルトの名無しさん2009/11/23(月) 06:06:37
>344
それだと is～() が何をチェックしてるのか知りたくなったら、一々中身を見なきゃ分からないし、
is～() の条件を変えたくなったら、使ってる場所を全部チェックした上で変更するか、
「使われない関数」が生じるのを覚悟で別な関数を追加しなきゃならん。
（まぁ静的リンクのみなら、コンパイルすれば何処で使ってるかは分かるけど）

is～()の名称自体は「何を」チェックするかに留めて、「何故」チェックするかとか
条件式全体が何を意味するかとかは、コメントに書く方がよっぽど面倒が無い。
0346デフォルトの名無しさん2009/11/23(月) 10:58:02
>>345
> それだと is～() が何をチェックしてるのか知りたくなったら、一々中身を見なきゃ分からないし、
ちゃんと名前付けて、関数宣言部分にコメント書けば、そんなことにはならないよ。
中身見るのはバグを疑うときぐらい。

> is～()の名称自体は「何を」チェックするかに留めて、「何故」チェックするかとか
> 条件式全体が何を意味するかとかは、コメントに書く方がよっぽど面倒が無い。
コメントに書いて良いのは「何故」だけだな。
0347デフォルトの名無しさん2009/11/23(月) 11:01:17
仕方なくわかりづらいコード書くときしか関数の中にコメントは書かないな
外側に書いたドキュメントだけでいい
0348デフォルトの名無しさん2009/11/23(月) 11:01:32
>>345の思考様式だと関数を細かく分けることは悪になりそうだなｗ
適切な名前の関数を作ってどんどん分けるのは常識レベルだと思ってたが
03493452009/11/23(月) 18:28:36
漏れは>344の言葉をそのまま鵜呑みにすると

　// Hogeの場合
　if ( isFoo() && isBar() )

のようなコードも、コメント付けるより

　if( isHoge() ）

とした方が良いって事になるのを否定しただけです。
ちょっと言葉足らずで意図不明瞭だったのは申し訳ない。
↓以外は>346-348全てに同意。


>346
>コメントに書いて良いのは「何故」だけだな。

この言葉を鵜呑みにすると、「何時呼び出す」とか書けない。
これは「5W1Hが単純に読み取れない場合だけ」のがより適切だと思う。


>348
>適切な名前の関数を作ってどんどん分けるのは常識レベルだと思ってたが

これは「どんどん」「分ける」の間に「適切な粒度になるよう」が抜けてる。
0350デフォルトの名無しさん2009/11/23(月) 20:50:16
適切に分けてりゃ、関数名は「何を」チェックするかだけ示せば十分>>344のように
運用できるだろ
0351デフォルトの名無しさん2009/11/23(月) 23:17:29
>>349
>>コメントに書いて良いのは「何故」だけだな。
>
> この言葉を鵜呑みにすると、「何時呼び出す」とか書けない。

コードに呼び出しタイミングは書いてあるのに、なんでそんなことを
コメントに書きたいの？

それとも、関数を作った側がどんなときに呼び出すべきか想定してる
ってこと？
それなら関数の側にコメント書くから、やっぱり if にコメント書くことには
ならないよ。
0352デフォルトの名無しさん2009/11/23(月) 23:53:41
ってゆーか、さ、
if ((flag & F_OPT1) && (flag & F_ERROR_ABORT)) // デバッグが有効で abort する場合
{ ... }
else
{ ... }

みたいに謎の条件判断とコメント両方つけるぐらいなら

if (is_abort_on_debug(flag))
{ ... }
else
{ ... }
って書くだろ？
03533542009/11/24(火) 00:15:33
ついでに言っとくと、>>342 みたいに
細切れでコメントつけるのはあんまり好きじゃない。

if (is_debug() && // デバッグモードをチェック
　　is_error_abort() ) { // エラーで abortするかチェック
　　// デバッグ時エラーならアボートする
　　... // 必要な処理をする
} else {
　　// デバッグモードでないか、エラーでも abort しない場合
　　nr_error++; // エラーカウンタを更新
　　... // 必要な処理をする
}

みたいに、C言語の日本語直訳を書くだけになりやすい。


それなら
/*****************************
* この関数は○○の時は△△します。
* 詳細は http://＜社内サイトの仕様書置き場＞
* の □□ のフローを参照してください。
* データフォーマットは grep -r Hoge_data ./sub1/include で探してしてください。
*****************************/
とでも書いてあったほうがわかるよ。
0354デフォルトの名無しさん2009/11/24(火) 00:17:52
オレだよ、オレオレ
03553542009/11/24(火) 02:45:53
>350
「AかつB ⇒ Cである」の「Cである」が、一言で言えるなら>344で十分だけど、
常にそうであるとは限らんでしょ。
「Aである」「Bである」とか、一言で言える「Cである」は
>344の方針で良いと思うけど。


>351
すまん、if文へのコメント限定ではなく、コメント全般で考えてた。
if文へのコメント限定だったら、「何時真になる」とか。


>352
その例、漏れなら下のいずれかにする。
1,2の場合はコメント無し。3は政治的理由等で1,2が採択できない場合の最後の手段。

(1) if ( (flag & F_OPT_DEBUG) && (flag & F_ERROR_ABORT) )
(2) if ( isDebug(flag) && isAbort(flag) )
(3)　if ( (flag & F_OPT1)　　　　　　　　　//デバッグON
　　　　&&(flag & F_ERROR_ABORT) )


>353
352も漏れだけど、そーいう実況的コメントを書けという意図ではない。
コメントを書くなら、対象が明示的になる位置に書くべきでないの?
という趣旨で書いてる。
0356デフォルトの名無しさん2009/11/24(火) 02:47:03
>355=>345≠>354
orz
0357デフォルトの名無しさん2009/11/24(火) 02:54:18
>>352のコードは二つのことを一つの関数で表してるから微妙だな。
>>353や>>355のコードの方が良い。

だが、>>345で言ってることはどうにも奇妙に感じられる。
要は、コードで語り合った方がいいタイプってことだな。
0358デフォルトの名無しさん2009/11/27(金) 18:45:01
中身が1行のif文やfor文について

// 1
if (...)
　　...;
{}省略してバグ混入したら嫌。

// 2
if (...) { ...; }
デバッグの時にブレークポイントが置きにくい。1行が長くなりそうなのも×。

// 3
if (...)
{
　　...;
}
行数取りすぎて画面内に表示されるコードが減ってしまう。if (...) {にすれば1行減るけど普段使ってないから一貫して使いたくない。

// 4
if (...)
{ ...; }
インデントがないのが見にくそう。かと言って{がインデントされているのも気持ち悪い。

それぞれデメリットがあって悩ましいです。
皆さんはどう書いていますか？
0359デフォルトの名無しさん2009/11/27(金) 19:00:25
「{}省略してバグ混入」とはちょくちょく聞く意見だが、
生まれてこの方十数万行書いてきたが、
一回もソレになったことがない。

中括弧書き忘れたからといってバグるやつも、
バグるから書いておけばいいと考えるやつも、
死んでしまえと思う。

その程度の注意力と読解力、記述力しかないのなら、
人間やめてしまえと思う。
0360デフォルトの名無しさん2009/11/27(金) 19:25:27
>359
確かに中括弧省略によるバグ混入のリスクがどの程度あるのか疑問ですね。
しかし、その反論も中括弧を省略するメリットがなければ意味がなくないですか？
中括弧を書く僅かな手間で、少しでも注意力のいらないコードが書けるのなら理にかなっていると思いますが。
0361デフォルトの名無しさん2009/11/27(金) 19:56:23
>>360
ifに一行くっついてて、それにもう一行加えるんだろ？　すぐ下とかに。
それを書くときに中括弧が必要か否かに注意を払えないやつ、
書き忘れ、などと捕らえてしまうやつは死んだほうがいい。
変更を加えるとき、いつだってその挿入行の前後への注意は必要だ。

その注意力すら欠いておいてプログラミングをしようとするのは怖い。

> 中括弧を書く僅かな手間で、少しでも注意力のいらないコードが書けるのなら理にかなっていると思いますが。

それは否定していない。ただ、効果は有るが、全体にとって微少だと思ってる。
ただ、そんなヤワなサポートに頼ってしまう時点で、既に色々ダメだ。

個人的にはこうしてる。

if (cond) return; // continue, breakなども

if (cond) {
 abababa;
} else {
 abababa;
}

これは、注意力軽減への配慮でもなんでもなく、
見た目を統一したいがためにそうしてる。
ネストを避けるための式は右側に書いちゃう。
それ以外で中括弧はいつもつける。elseがなくてもつける。

> 中括弧を省略するメリット

メリットなんざ特に思いつかない。あえて言うなら見た目。
0362デフォルトの名無しさん2009/11/27(金) 19:57:15
中括弧省略によるバグは実際会社で２例ほど見た
自分だけがいじるコードならいいだろうけど
後々他の馬の骨がいじる可能性も考えると
{ } 省略はやめた方がいい

ちなみに、俺は開始 { は if と同じ行に書く派
そして { } 内が短くても { の次は改行を入れ、} は単独行にする
昔は { を if の次の行に書いてたけど間延びするのでやめた
でも、行が長いと間が詰まりすぎると感じる事もあるので微妙な所
0363デフォルトの名無しさん2009/11/27(金) 20:01:17
最初は一行でも後で書き足すことも多いので大抵は常に括弧付ける。
括弧あった方が見やすいし。
0364デフォルトの名無しさん2009/11/27(金) 20:46:51
>>361
> それは否定していない。ただ、効果は有るが、全体にとって微少だと思ってる。
コーディングスタイルで重要なのは統一する事ですよね。
どっちでもいいような事でも、できるだけ合理的な方を選びたいです。

> ネストを避けるための式は右側に書いちゃう。
> それ以外で中括弧はいつもつける。elseがなくてもつける。
参考になります。
確かにreturnなどは1行が長くなる事が少ないですし、if文の右側でもいいですね。

>>362,363
やはり中括弧は省略しない方がいいんですね。
0365デフォルトの名無しさん2009/11/27(金) 22:05:58
お前らLinux KernelとGNUのコーディング規約調べてみｗ
0366デフォルトの名無しさん2009/11/27(金) 22:11:31
Linuxカーネルは、単文を中括弧で囲むのを基本的に禁止してるね。
if文の分岐の片方が単文な時だけ、特例として中括弧で囲うルールだったはず。
0367デフォルトの名無しさん2009/11/27(金) 22:54:07
後から追加して複文になったときの問題だけじゃなくて、
if-else のネストで意図したものと異なる方に
else がくっつくことがあるって問題もあるんだぜ
0368デフォルトの名無しさん2009/11/28(土) 03:28:03
それでもLinuxは無駄な中括弧を排除してるし、それであの巨大プロジェクトが一応は
問題なくやれてる訳だよな
ぶっちゃけ、こだわるほどのことではないんだろ
0369デフォルトの名無しさん2009/11/28(土) 13:16:28
Linuxいじるような人は概ねレベルが高いだろうから問題ないんだろうな
というイメージだが、実際の所どうなんだろう
0370デフォルトの名無しさん2009/11/28(土) 13:29:00
しっかり統一できてればいいんじゃね
0371デフォルトの名無しさん2009/11/28(土) 13:49:06
VC使っててもミスる人いるのに
vimやemacsで大丈夫なの？
0372デフォルトの名無しさん2009/11/28(土) 21:56:34
ミスとか以前に、他の複数行のif文と見た感じが統一されなくて気持ち悪いのは俺だけ？
0373デフォルトの名無しさん2009/11/28(土) 22:21:16
統一性は別に気にならないな
単一文 if は単一文 if で統一されていれば
0374デフォルトの名無しさん2009/11/29(日) 02:03:11
ぶっちゃけ、if-breakやif-returnまで中括弧入れてると冗長感はかなりあったから、
俺はLinux方式の方が好みかな
Perlなんかは逆に中括弧の強制が言語的に決まってたりするし、それはそれでいい
と思うけど（つーかPerlはreturn ifとかand returnとか好き放題に書けるしな）
0375デフォルトの名無しさん2009/11/29(日) 09:11:32
rubyみたいなif修飾子があれば最高なんだよな。
next if condとかってスカッとする。
0376デフォルトの名無しさん2009/11/29(日) 18:16:18
Perlのstatement modifierをそのままパクった奴だな
さらにそのパクリ元はBASIC/PLUSらしいが、どういう言語かシラネ
0377デフォルトの名無しさん2009/11/29(日) 21:10:43
else if () は中括弧なしの単文だよな。


>>368
Linux はコードのチェックインの前に基本的に
Kernel ML へのパッチ提出でレビューを経るから
抜けはそこで指摘できる。

一人でコーディングするなら後任のことも
考えて {} つけといたほうがいい。
0378デフォルトの名無しさん2009/11/30(月) 02:01:45
そんなのミスる奴は、悪いけど擁護しきれないレベルだと思うんだが
まともかつ慣れた奴でそんなミスをやる奴っているの？
0379デフォルトの名無しさん2009/11/30(月) 16:36:53
都市伝説だと思うよｗ
0380デフォルトの名無しさん2009/12/02(水) 01:12:47
>>378
新人をいきなり投入ってあるよ。
ま、一人に投げっぱなしじゃないけど、
char *foo(void)
{
　　char buff[128];
　　。。。
　　return buff;
}
みたいなコード書くヤツでも平気で
投入されてくるから要注意だｗ


そういえば、
for (...);
{
/* 何かの処理 */
}
で、ループの中が一度しか実行されない病
にはまった事はあるｗ
0381デフォルトの名無しさん2009/12/05(土) 00:53:50
人いないのかよ。

ぬるぽ！
0382デフォルトの名無しさん2009/12/05(土) 02:18:36
>>381 ガッ
0383デフォルトの名無しさん2009/12/05(土) 09:47:04
対応する中括弧のインデントの階層を同じにしろといつも思ってる
なんでみんな階層変えて書くの？死ぬの？
0384デフォルトの名無しさん2009/12/05(土) 11:38:34
>>383 が言いたいのは

if (...) {
}

スタイルは嫌いだ、ってこと？
0385デフォルトの名無しさん2009/12/05(土) 18:53:46
一つのクラス内やファイル内に記述する関数やメソッドの順番ってどうしてる？
たとえばCで f1()からf2()とf3()が呼ばれて、f3()からf4()が呼ばれる場合、自分は
void f2() { ... }
void f4() { ... }
void f3() { f4(); ... }
void f1() { f2(); ... f3(); ... }
のように、呼び出される関数を上の方に書いてるんだけど、
呼び出される関数を下の方に書くスタイルもあるよね。
こういう理由でこういうスタイルにしているというのがあれば教えて。
0386デフォルトの名無しさん2009/12/05(土) 19:12:42
トップダウンで実装してる時はトップダウンで。
ボトムアップで実装してる時はボトムアップで。

# コーディング規則があるときや、既存のプロジェクトでは他に合わせて。
0387デフォルトの名無しさん2009/12/05(土) 20:35:30
>>385
eclipseにメンバをソートする機能があるから、それでアルファベット順にソート。
0388デフォルトの名無しさん2009/12/06(日) 00:23:38
>>385
プロトタイプ宣言はつけてるのでどんな順番でもいいのだが、
追加・変更した関数を上に持ってくる。 だいたい
いじる関数は決まってるからな。

自然と、下に行くほど枯れた関数ということになる。
機能単位でまとめられるようであれば別ファイルに
くくり出すときに雑魚は下の方でソートしてる。


起動時間などの最適化をかけるために順序を
変えることもある。 起動時に使うものをなるべく
一箇所に集めて上に持ってくるとか。
0389デフォルトの名無しさん2009/12/06(日) 00:49:16
宣言を繰り返すのが面倒だから、呼ばれる側が上。
自然とファイルローカルな関数が上に来て、外部関数は下に来る。
ヘッダで宣言してる外部関数は、ヘッダでの宣言順にあわせる。
0390デフォルトの名無しさん2009/12/06(日) 11:46:02
他人のソースをいくつか読んでみて、
見やすいのと見難いので比較してみれば？

わしは前フリ長いの嫌いなんで、上位の関数を
上に書いて欲しい。 わからないところだけ下を見る。


つか、クラスで最初に private もって来る奴とかいないだろ？
それと同じことじゃね？
0391デフォルトの名無しさん2009/12/06(日) 12:08:47
>>390
ふつーにいるだろ? privateを最初に書くの。
0392デフォルトの名無しさん2009/12/06(日) 12:09:15
if(hoge)
if (hoge)
if( hoge )

どう書く？
カッコが入れ子になった場合に一番見やすいのは最後だと思うが野暮ったい
0393デフォルトの名無しさん2009/12/06(日) 12:13:30
if (hoge)

関数やマクロの場合は hoge(...) と、カッコの前を空けない。
if (...), for (...), while (...) などは空ける。
0394デフォルトの名無しさん2009/12/06(日) 12:29:09
>>392
2番目がふつー。
0395デフォルトの名無しさん2009/12/06(日) 13:13:26
if ( hoge )
だな。

for, while も同様。
0396デフォルトの名無しさん2009/12/06(日) 13:17:05
カッコの内側に空白を入れるのは、マイクロソフトのサンプルとかが
そのスタイルだよね。
0397デフォルトの名無しさん2009/12/06(日) 13:20:39
MSはC++では1番目，C#は2番目
0398デフォルトの名無しさん2009/12/06(日) 13:21:20

訂正C++は3番目
0399デフォルトの名無しさん2009/12/06(日) 13:24:19
今MSDNのサンプルで確認したら統一されてないな。
あったりなかったり。
カッコの内側のスペース。
0400デフォルトの名無しさん2009/12/06(日) 13:28:46
VS2008のオートフォーマットは、デフォルトでは、C#はカッコの
内側にスペース入れない設定。
C++は、設定項目がなかった。
0401デフォルトの名無しさん2009/12/07(月) 17:33:08
一番大切な事は、それを書いて自分が何を感じるかだ
0402デフォルトの名無しさん2009/12/07(月) 19:33:21
>>401
もちろんコスモを感じる
0403デフォルトの名無しさん2009/12/08(火) 00:30:35
ブランクを感じる。

ごめん、書いてみたかっただけw
04043852009/12/08(火) 12:23:16
なるほど、色々参考になった。
自分の場合、ソースの流れを追うときに、呼び出される関数が上にあるか下にあるかが
あらかじめ分かってた方がスムーズに追えるかなと思うんだが、順番を気にしない人が
けっこう多いんだね。
0405デフォルトの名無しさん2009/12/08(火) 13:46:29
>>404
というより、関数の間に依存関係がありすぎるのはキモイ。
>>385の例で言うとf1->f3->f4ていうのが深い。

俺ならpublicなインタフェースに対し、その実装から、
privateなメソッドを一回呼び出したりする程度。
だから順番としては、（基本、互いに呼び出しあったりしない）publicなものを上にババーと書いて、
下のほうにprivateなメソッドをコソコソと書く。_fなどとprefixをつけて名前を汚して書く。
0406デフォルトの名無しさん2009/12/08(火) 13:52:38
>>405
関数の深さ制限って、何のため？深くて何が悪いの？
「そろそろ関数分けるか・・・あ、もう３段目だ。やめとこ。」とか言っちゃうの？

名前を汚すって、何のために？
private なりファイルローカルなり、もっとマシな仕組みが言語側にあるでしょ？

どっちも意味わかんない。
0407デフォルトの名無しさん2009/12/08(火) 14:06:17
> 「そろそろ関数分けるか・・・あ、もう３段目だ。やめとこ。」とか言っちゃうの？

言わない。「そろそろ関数分け」たりしない。
適切に設けられた関数は既に簡潔に表現されてる。
結果、そんなに呼び出しが深くなったりはしない。

> 名前を汚すって、何のために？

すまない、完全にこれは蛇足。
privateでかつ、仮状態のメソッドを区別するためにそうしてるだけ。
汚い名前をつけとくと、落ち着かないでしょ？
キレイな名前がつくときは、整理されて明確な役割を担ったとき。
ま、この話題はどうでもいいな。
0408デフォルトの名無しさん2009/12/08(火) 14:31:20
f1(){ f2(); f3()}
f2(){ f3(); f4()}
f3(){ f4(); }

のようにスパゲティに依存してるのはちょっと気持ち悪いが、
単に深くなるのは気にしないな。

ていうか関数が2層しかない、って相当単純なものしか書いてないんじゃないの？
0409デフォルトの名無しさん2009/12/08(火) 14:36:58
>>407
関数の表記が簡素であることと呼び出しの深さがどう関係するの？

…あ、もしかして「適切にファイル分割された状態であれば、ひとつの
ファイル内でそんなに深くなることはないはず」ってこと？
0410デフォルトの名無しさん2009/12/08(火) 14:39:14
> 言わない。「そろそろ関数分け」たりしない。
> 適切に設けられた関数は既に簡潔に表現されてる。

事後の関数分けをしないでもいいって、どんな神プログラマだよｗ
0411デフォルトの名無しさん2009/12/08(火) 14:41:21
> ていうか関数が2層しかない、って相当単純なものしか書いてないんじゃないの？

しらんがなｗ

それと、二層どころか、ほとんどは一層だよ。
publicなメソッドから、同じクラスのほかのpublicメソッドを呼び出したりはしない。
メソッドのオーバーロードの場合は除いて、ね。
publicメソッドからたまーに、privateなメソッドを呼び出したりするだけ。

だから、publicなメソッド同士の記述の順番なんぞどうでもいい。
なぜなら、そこに呼び出しあうような関係は無いから。
privateメソッドがそれらの間にあると読みにくいと思うから、
上のほうか、下のほうにまとめておく。邪魔だから。
0412デフォルトの名無しさん2009/12/08(火) 14:42:14
> 事後の関数分けをしないでもいいって、どんな神プログラマだよｗ

残念、俺は糞プログラマだよｗ
0413デフォルトの名無しさん2009/12/08(火) 14:42:55
底辺はリファクタリングを知らない。
0414デフォルトの名無しさん2009/12/08(火) 14:47:21
>>412
なんだ。そうか。納得した。

自覚があるなら >405 みたいなミスリーディングな主張は控えていただきたい。
0415デフォルトの名無しさん2009/12/08(火) 15:38:25
コーディング規約の大半は普通のプログラマのためではなく、
あなたの隣に座っているプログラマのような何かが生産し続ける、
見ただけで死ぬような目潰しコードを多少は見られるようにするという
崇高な試みのために存在する。
0416デフォルトの名無しさん2009/12/09(水) 00:16:00
むしろコーディングに主義主張を持つ俺らみたいのが二人以上いると
宗教戦争を起こすので「めんどくせえからこーしとけ」的なルールな気もｗ
04173852009/12/09(水) 02:05:52
>>411
なるほど。たしかにメソッドの記述の順番が気になる箇所は、
関数をどんどん深く呼び出してる箇所とほぼ一致してるなあ。
そういう箇所はコードが読みにくいというよりも、そもそも
クラス構造に問題がありそう。
そういった、クラスの構造や粒度などについて書かれてる
書籍でおすすめのものがあれば教えてくれるとうれしい。
0418デフォルトの名無しさん2009/12/09(水) 12:10:51
ソースを上から順に読むとか、飛び先を目で探すとかってことは
めったにないんで、べつに順番はどうでもいい。
気になるんだったら、アルファベット順にでも並べとけばいい。
04194112009/12/09(水) 13:29:14
>>417
まず大前提としてはKISS(Keep it simple, stupid)があって、
これはいつまでたっても我々にとって有効な指針になると思う…。

「Cプログラミング診断室　藤原 博文」
　構造化のテクを磨くことも大事。楽しい読み物。
　余計なことやヘンなことはしない、ということの大事さが分かる。

「リファクタリング　マーチン ファウラー」
　目新しさは無いかもしれないが、押さえておいていいかも。

「オブジェクト指向における再利用のためのデザインパターン　GoF」
「オブジェクト指向入門 第2版 原則・コンセプト　バートランド・メイヤー」
　自力で独学でOOP能力を高めていくのも大事だけど、
　OOPとは何ぞや、優れた設計とは何ぞや、を本から学びたければ。
　個人的に、デザパタ本は手垢で黒くなってきてるほど読んでる。

> クラスの構造や粒度などについて書かれてる書籍

で、肝心のコレはちょっと思いつかないｗ

ただ、図書館行って片っ端から技術書立ち読みしたら、
それっぽい本にきっと出合えると思う。
アジャイルなんたらっていう赤い本も面白かった気が。
技術系MLアーカイブを追っかけたり
（ttp://java-house.jp/ml/topics/topics.html#style）
するのもいいかも。なんかいい本あったら教えてｗ
0420デフォルトの名無しさん2009/12/09(水) 13:35:48
Ｃプログラミング診断室
ttp://www.pro.or.jp/~fuji/mybooks/cdiag/index.html

これならお手軽に読める。内容はちょっと古いかもしれないし、
内容のすべてに同意できるとは限らないけど、
ある程度の距離を保って読めば、やっぱ今でも面白いかと。
0421デフォルトの名無しさん2009/12/10(木) 00:01:11
カーニハンの「プログラミング作法」ぐらい読んどけよ。
0422デフォルトの名無しさん2009/12/10(木) 00:09:02
診断室で一番共感したのは、糞グラマを無理に使うくらいなら切り捨てた方がマシ、
ってとこだな
04233852009/12/11(金) 01:01:26
>>419,420
ありがとう。「Cプログラミング診断室」読んでみる。
0424デフォルトの名無しさん2009/12/12(土) 02:46:17
関数を分割するべきか否かを、関数の行数や
if等のネストの深さで、機械的に判断するのは間違い。
…などと書いてみるテスト。

一連の処理の固まりを、「処理内容が大体想像できる一文」で
置換する（記述を要約する）のが正しい関数化の手法であって、
行数等を判断基準に関数化するというのは、
ぶつ切りしてるに過ぎないと思う。

でもってこの「～する」の一文を見つけたり、まとめられるように
フローをアレンジする能力ってのが、プログラムのセンスって奴だと思う。
0425デフォルトの名無しさん2009/12/13(日) 00:14:47
バカを統制するのには機械的な基準はある程度有効
0426デフォルトの名無しさん2009/12/13(日) 00:28:09
「こういうコーディングスタイル、ダサいよな」みたいな話題で、
わざわざ「俺はバカどもを使ってるから仕方なくやってんだよ」って
反論してくるやつって、実は本人がそのダサいスタイルなんじゃないかって
気がしてならない。
0427デフォルトの名無しさん2009/12/13(日) 18:32:43
無能プロジェクトリーダの決める規準より言語設計者の決めるものの方がまし、
という意味で、言語がこと細かにスタイルを規定して欲しい。
0428デフォルトの名無しさん2009/12/13(日) 19:15:24
Pythonのことか
0429デフォルトの名無しさん2009/12/13(日) 20:28:37
>425
関数名（+引数等） = 処理内容の要約となるよう設計（分割）すべき、
ってルールはさほど難しく無いと思うんだ。

…と思ったけど要約できん奴は、ダラダラ書くんだろうな…
ダラダラ書かせない為に機械的制限は有効だと思うけど、
えてして基本が忘れ去られてる、と思うんだ漏れは。
0430デフォルトの名無しさん2009/12/14(月) 23:31:25
そして void add_A_and_B(void) みたいな
関数を書く奴が出てくるんだな。
0431デフォルトの名無しさん2009/12/14(月) 23:36:42
そんなレベルならどんな規則で縛ろうと無意味
0432デフォルトの名無しさん2009/12/15(火) 02:07:21
>430
そーいうのを良しとするとは書いてなかろう。
そーいうのばかり抑制する事に気を取られて、
基本的な部分がおざなりになってるということ。
0433デフォルトの名無しさん2009/12/22(火) 15:01:18
enum { SpecialID1, SpecialID2 }; でそれぞれに値を
記憶する場所があってそれを設定する場合に

1) Set_SpecialID1or2(SpecialID1, int value)
2) Set_SpecialID1(int value), Set_SpecialID2(int value)
3) Set(SpecialID1, int value)
4) Set_Special(flag, val1, ...) //flag： １のみ、２のみもしくは両方を指定可能

どれが好き？

わしは 3) でこっそり実装して 2) の
マクロを提供って感じなんだがオススメとかある？
0434デフォルトの名無しさん2009/12/22(火) 18:47:11
>>433
マクロはよくない。
0435デフォルトの名無しさん2009/12/22(火) 23:01:42
だって、シンボル数が増えると
起動時間遅くなるから。。。
0436デフォルトの名無しさん2009/12/23(水) 01:22:14
>>433
口頭で動作を説明する場合の表現に近いコードを選ぶべし。
0437デフォルトの名無しさん2009/12/23(水) 19:35:57
じゃ、SVOC だな。
0438デフォルトの名無しさん2009/12/24(木) 03:10:27
>433
漏れならこう書く。

　bool SetHoge( int key, int value )
　bool GetHoge( int key, int& value )
　int GetHoge( int key, int error_value = 0 )　　//手抜き版

エラーハンドリングが不要なケースではもっと端折るけど。
0439デフォルトの名無しさん2009/12/24(木) 21:47:18
なんかこういうのってデザインパターンにないんだっけ？
0440デフォルトの名無しさん2009/12/24(木) 22:07:50
ない
0441デフォルトの名無しさん2010/01/27(水) 12:43:02
>>433
本当に、単純に値を出し入れするだけなら
3)かなあ。これSpecialIDの設定はintじゃないよね？

ところで、C#をやるようになってから
C++でこの手の値入出力系のメンバにGet,Setをつけなくなった。
こんな感じ。

class tes
{
private:
　int m_data;
public:
　int Data() const { return this->m_data; }
　void Data(int data) { this->m_data = data; }
};

実装していて今の所問題ない。俺の場合は。
これって、どんな問題が考えられる？
0442デフォルトの名無しさん2010/01/28(木) 00:36:10
>>441
x.Data(0);
↑一見して何してんのか読み取れない。
0443デフォルトの名無しさん2010/02/20(土) 16:25:28
>>442
分かるじゃん。
Dataは何らかのオブジェクトのコレクション (Datumの複数形だからね) を表していて
その0番目の要素を参照しようとしてるんだよ。


・・あれ？ 違う・・だと・・？
0444デフォルトの名無しさん2010/02/20(土) 16:28:26
rubyとかだとね、x.data = 0と書けるね。
0445デフォルトの名無しさん2010/02/21(日) 09:56:48
コーディングルールとして完全に縛ってれば別に問題は無いんじゃね。初期化子とかに
似ているといえば似ている気もしなくもないし。
ただ、暗黙の変換に似た気持ち悪さは感じるが。
0446デフォルトの名無しさん2010/02/21(日) 17:38:20
関数をオーバーロードにするか、別名の関数にするかの判断基準ってどうしてます？
0447デフォルトの名無しさん2010/02/21(日) 23:09:19
漏れは機能が似てるならオーバーロードするね
0448デフォルトの名無しさん2010/02/21(日) 23:14:09
そういうのはクラスを使う人のための配慮だから実装がどうだからオーバーロード使うとかいう
基準を設けるのは間違ってるだろ
0449デフォルトの名無しさん2010/02/22(月) 00:08:58
メリットが何もないからオーバーロードはしない
0450デフォルトの名無しさん2010/02/22(月) 02:43:29
メリットのある場合もある
無い時はしない方がいい

暗黙の型変換とかと同じで、しないと大変なことになるんじゃなければ、しない方がいい
0451デフォルトの名無しさん2010/02/22(月) 08:31:37
>>447-450
どうもです。
利用者が引数に渡す型が違う事を意識するものは、オーバーロードを使わない方針にします。
0452デフォルトの名無しさん2010/03/05(金) 16:33:59
関数で、自分では操作しないけど戻り値は自己責任で自由に使ってねって言う場合、

std::vector<int> &GetVector() const { return const_cast<std::vector<int> &>(this->m_vector); }

こんな感じで書いてるんだけど、まずいかな。
const関数なんで使う側はコピーを返してると勘違いするとか。
なんか、自分ではいじらない、ただ渡したものは自由に使っていいよ
っていうものの正しい書き方が見えない。orz
0453デフォルトの名無しさん2010/03/05(金) 17:00:54
const_castが必要になる状況は不自然。無理を通している。
constのvectorってのも不可解。何に使うつもり？
0454デフォルトの名無しさん2010/03/05(金) 17:09:19
constメソッドにするとvs2008ではメンバが
const定義扱いでコンパイルされるらしい。
this->m_vectorはconstじゃないけど、GetVector() const;で内からそのまま返すと

error C2440: 'return' : 'const std::vector<_Ty>' から 'std::vector<_Ty> &' に変換できません。

とエラーが出る。
0455デフォルトの名無しさん2010/03/05(金) 19:14:42
>>454が何を言っているのかわからない
0456デフォルトの名無しさん2010/03/05(金) 19:34:56
>>452
＞なんか、自分ではいじらない、ただ渡したものは自由に使っていいよ
＞っていうものの正しい書き方が見えない。orz
非constメンバ関数にするべき。
0457デフォルトの名無しさん2010/03/05(金) 19:57:36
const 版と非 const 版を作る。
const オブジェクトに対しても使えるようにするなら、メンバを mutable 修飾する。

スタイル的には、そんな設計がおかしい。
変更する必要のある側が保持して、使う側はその時点のものを借りる関係であるべきだ。
452 のは、ヨソの家の無線LANにただのりするような構造だ。
仕方の無いときはあるが、そんな時は別のスレがふさわしい。
0458デフォルトの名無しさん2010/03/05(金) 20:55:11
>>455
ああごめん。vs2008だとこれが通らないよって話。
class tes
{
private:
std::vector<int> m_vector;
public:
std::vector<int> &GetVector() const { return this->m_vector; }
};

>>456
そういうもんかー。
内部遷移が複雑なロジックとかだと、中で余計な事しないよ的な意味で
constつけといた方が喜ばれるかと思ったけど、取っておくか。㌧クス。
0459デフォルトの名無しさん2010/03/06(土) 01:04:58
>>452
> 関数で、自分では操作しないけど戻り値は自己責任で自由に使ってねって言う場合、

それ、メンバに持ってるのがおかしいだろ。
0460デフォルトの名無しさん2010/03/06(土) 02:23:03
>>458
通るわけねえだろ const なめんな。
通るコンパイラを見せてみろ。
スタイルの問題じゃなくて知識の問題だってんだ。
0461デフォルトの名無しさん2010/03/06(土) 03:11:30
>>459
そういうもんかー。
内部遷移が複雑なロジックとかだと、中で余計な事しないよ的な意味で
constつけといた方が喜ばれるかと思ったけど、取っておくか。㌧クス。

>>460
>>452～>>455の流れで>>458に続く。
知識じゃなくて日本語の問題だなぁおいｗ
0462デフォルトの名無しさん2010/03/06(土) 03:20:03
>>461
なんで >459 へのレスが >456 へのレスと同じになるの？
0463デフォルトの名無しさん2010/03/06(土) 13:45:49
>>460
> const なめんな。

なんかカッコイイ発言だなｗ
0464デフォルトの名無しさん2010/03/06(土) 13:53:10
コンパイルエラーが出るからconst外しをするとか
コーディングスタイル以前の問題
0465デフォルトの名無しさん2010/03/06(土) 13:59:57
> 内部遷移が複雑なロジックとかだと、中で余計な事しないよ的な意味で

メンバ変数、しかもベクタ丸ごと外に晒そうなんて考える奴が言う台詞か？ｗ
0466デフォルトの名無しさん2010/03/06(土) 17:28:15
>>465
なるほど。サンプルが悪いと。
んでは誰か聞かせて欲しいんだけど

中で余計な事しないよ的な意味でのconst

ってあり？なし？もしくは、これを実現する場合は
>>457のconst 版と非 const 版を作る。が最良？
0467デフォルトの名無しさん2010/03/06(土) 17:33:42
>>466
それって普通の「内部状態変更しないよ的な意味でのconst」と何が違うの？
0468デフォルトの名無しさん2010/03/06(土) 17:44:49
上の例だと、渡す時は内部状態を操作しないけど、戻り値は自己責任で自由に使ってね
それによって内部状態が変更されるよって言う場合。
std::vector<int> &GetVector() const;
0469デフォルトの名無しさん2010/03/06(土) 18:00:30
>>468
外部で自由に設定していいものを「内部状態」とは言わんだろうし、
それを反映してコードでもメンバ変数にするべきじゃないでしょ。
ってすでに >457 も >459 も言ってるんだけど、それについてはどう
なのさ？
0470デフォルトの名無しさん2010/03/07(日) 00:54:36
>>466
const tes ctes;
があったとき、ctes が変更されそうな操作をコンパイラがエラーにしてくれるのは素晴らしいことだ。
非 const メンバ関数を呼んだり、非 const ポインタ（や参照）への変換はもちろんエラーだ。
他に、オブジェクト内部の変数のアドレスを返すことについても、コンパイラは追跡してくれる。
非 const のアドレスを返すと、外から内部状態を変更されてしまうかも知れないから、わざわざチェック
してエラーにしてくれる。

458 のエラーは、C++ の規格でそうなっている。
とても有難い機能で、コンパイラベンダのみなさんがこの機能を頑張って実装してくれたお陰で、僕らは
constness の追跡について機械任せでいられる。
これにより、 const メンバ関数だけを呼ぶ限り、const オブジェクトについて、関数を呼んだ時も呼んだ
後も内部状態が変化していないことを想定していいことになる。お行儀のいいコードならだけど。
だから、const の意味を二つに分ける必要なんて無い。

アリナシの話は、それどころか原則 const であるべきで、観念的に副作用がある場合のみ非 const
であるべき。

そして const 版と非 const 版の両方が必要なら実装すればいい。
0471デフォルトの名無しさん2010/03/14(日) 17:06:10
C++のクラスでメンバ変数が多いとき、コンストラクタ初期化子を
改行して書くと思うんだけどどう書く？
セミコロンとカンマをどこに持ってくるのかが知りたい
1)
hoge::hoge()
　　: foo(),
　　bar(),
　　baz()
2) googleスタイル？
hoge::hoge()
　　: foo(),
　　　bar(),
　　　baz()
3)
hoge::hoge()
　　: foo()
　　, bar()
　　, baz()
4)
hoge::hoge() :
　　foo(),
　　bar(),
　　baz()
0472デフォルトの名無しさん2010/03/14(日) 17:08:09
セミコロンじゃなくてコロンだった
0473デフォルトの名無しさん2010/03/14(日) 17:18:54
// インラインなら
hoge(): foo(apple), bar(banana),
　　yaw(orange), baz(strawberry)
{ ... }

// ソースに書くならこう
hoge::hoge():
foo(apple), bar(banana), yaw(orange),
baz(strawberry)
{
...
}
0474デフォルトの名無しさん2010/03/14(日) 18:31:09
やっぱコロン、カンマは後ろに持ってきたほうが見た目がいいよね
回答ありがとう
0475デフォルトの名無しさん2010/03/15(月) 08:29:36
俺は真逆で、コロンが前に来てないと落ち着かない
というより、前置か二項っぽい意味合いのものは、行頭に来るように置くのが普通
だと思うけどなぁ
0476デフォルトの名無しさん2010/03/15(月) 09:18:03
自分を中心に地球が回ってると考えるタイプの方ですね
0477デフォルトの名無しさん2010/03/15(月) 09:59:37
つーか、ある程度まともなコーディング基準で、>>475に反するものは見たことが無い
>>473に反するものは良く見る

もちろん、どこかには反対の例もあるかもしれんけど
0478デフォルトの名無しさん2010/03/15(月) 10:19:09
普通かどうかで言えば、コンマが後ろにくるのが普通だと思われているからこそ
enum 宣言や配列初期化子に余分なコンマがあっても許されるようになったのだろう。

俺は後ろ派だが、手前派には
・行単位の追加削除移動の時に手当ての必要が少ない
・縦に並べた時に筆算のようになるし、自然言語と親和する
というようなメリットがあるので理解できる。

後ろ派はメリットよりは慣習的なものだと思う。
改行の持つ意味合いが強かった頃の名残りではなかろうか。

コロンに関しては、元の英語での使い方が一対一や一対多の左側を明示するもの
なのだから、makefile やラベルのように後ろに付けるのが普通だろう。
0479デフォルトの名無しさん2010/03/15(月) 10:27:34
コロンは前、カンマは後ろ派
0480デフォルトの名無しさん2010/03/15(月) 10:29:51
訂正

ラベルのコロンは当然後ろ
クラス初期化子のとこのコロンは前

つか、色々ソース見ても、>>471の1か2が普通じゃね？
0481デフォルトの名無しさん2010/03/15(月) 10:33:48
漏れ、改行しないんだけど

hoge::hoge(): foo(), bar(), baz()
0482デフォルトの名無しさん2010/03/15(月) 10:54:36
短いのはそれでいいんじゃね
0483デフォルトの名無しさん2010/03/15(月) 19:44:16
>>480
根拠を書かずに普通っていうと、476が出るぞ。
0484デフォルトの名無しさん2010/03/15(月) 22:10:50
>>483
いろんなソースをそれなりに見てる人なら大体同じように感じると思うけどな
統計でも取らなきゃ文句言われるってんなら知らん
0485デフォルトの名無しさん2010/03/16(火) 14:42:09
>>484
君の経験上普通なのは疑ってない。
君の経験を普通だとする根拠を求めている。

例えば、Win32, *nix, 汎用機、マイコン、クライアントサイド、サーバサイド、
官公庁調達、金融系、業務系、Web 系、オープン系、データベース、
パッケージソフト、ガジェット、デーモン、デバドラ、分散、超並列、
大手、下請け、大学/研究所、他にも色んな分類の仕方があると思うが、
さまざまなカルチャーがある。

分類の抽象度は任せるが、いくつかを挙げて、
　「こういった分野では普通だ」
　「経験したこれとこれとこれの全ての分野で普通だ」
とするなら、ずっと説得力があるのではないだろうか。
0486デフォルトの名無しさん2010/03/16(火) 15:40:54
俺なら>>471の3。
この流儀に俺が行き着いたのは、SQLでクエリを書くようになってから。
文字列を*に置き換えて全体の形を表すと、

*******
***********
*****
********
******************

のように右側がデコボコし、そこにandやらorやら,やらが来ると、読むとき目がウネウネする。
区切り、中身（？）、の二種類で、文字のサイズが固定なものを左に持ってきたほうが、
読みやすさが増すと思う。上記の例を使ってカンタンに表すと、区切りを@として、

*******@
***********@
*****@
********@
******************

より、

*******
@***********
@*****
@********
@******************

がマシだという理屈。
0487デフォルトの名無しさん2010/03/16(火) 20:15:54
>>485
平たく言うと、普通○○なんじゃね、はこのスレでは絶対禁止ってことだな
0488デフォルトの名無しさん2010/03/16(火) 20:29:02
>>486
ちょっとわかる。
SQLで長いWHERE節を書いてると、
普通の言語以上になんかくどく感じる。

ただ、AND/ORは行頭にまとめた
ほうがいいのでは、と思いつつ、今は
まだ行末に書くようにしてる。
0489デフォルトの名無しさん2010/03/17(水) 00:10:58
漏れも3)派。
でも区切り記号ではなく演算子の場合は行末の方が優れている部分もあると思う。
例えば一次的に演算子を置き換えてみたい場合、↓みたいに書ける。

　***** + //-
　*****

でもやっぱ3)が好き。
0490デフォルトの名無しさん2010/03/17(水) 00:40:35
ttp://codepad.org/nYNt4bQw
0491デフォルトの名無しさん2010/03/17(水) 20:09:46
>>487
学問カテと技術系板では、無限定の「普通」を使うべきではないと思う。
別に「普通」であることの証明を求めているわけじゃなくて、根拠を求めてるだけなんだけどね。
0492デフォルトの名無しさん2010/03/17(水) 23:51:51
>>491
俺は、技術系板では無限定の「普通」を使うべきではない、とは思わないな。
学問と技術なんざ別物だ。
0493デフォルトの名無しさん2010/03/19(金) 16:10:52
技術系の板で根拠の無い発言を当然とするのは残念だ。
0494デフォルトの名無しさん2010/03/19(金) 21:52:08
技術系じゃ完全な根拠を要求するのは不可能だろ
0495デフォルトの名無しさん2010/03/19(金) 22:07:52
ぶっちゃけ心理学とか社会学とかもかなり根拠曖昧なままやってるしな
0496デフォルトの名無しさん2010/03/21(日) 00:10:13
お前ら携帯か？ 流れ読めよ。

>>494
何で「完全な根拠」なんていう、文脈から外れたものを持ってくるんだ。
経験が根拠ならどういう経験なのかを、実験が根拠ならどういう実験かを述べよというだけのことだ。

>>495
実験なりモデルなり、根拠は論文に提示してあるだろう。
おかしなものは否定したらよい。
具体的に何か一つでも挙げてみろ。


ハイゼンベルクの不確定性原理やらゲーデルの不完全性定理やらが定着した現在、そんな完全な証明なんて求めるわけが無い。
だがしかし、何かを主張する時に口からでまかせ言っていいことにはならないし、そうでないと説得すべく努力すべきだ。
0497デフォルトの名無しさん2010/03/21(日) 13:55:32
> 何かを主張する時に口からでまかせ言っていいことにはならないし

ならなくはないだろうｗ　好き勝手言えばいいし、それを止めるすべは無い。
ただ、それなりの根拠がないと相手にすらされないだけでｗ
0498デフォルトの名無しさん2010/04/03(土) 01:47:17

ちと聞きたいんだけど、
privateなメンバ変数、関数の頭にアンダースコアつけるマーチンファウラー式って、protectedなメンバ変数や関数にもアンダースコアつけるもの？

自分がよく見るJavaだと、privateに付けてるコードの中でもprotectedになるとバラバラな感じだけど、どっちが主流or論理的根拠があるのかな

つかファウラーたんはなんて言ってるんだろう？
0499デフォルトの名無しさん2010/04/03(土) 11:20:33
それをマーチンファウラー式と呼ぶのは知らなかったｗ
0500デフォルトの名無しさん2010/04/03(土) 15:40:03
名前をアンスコで始めるのはやめたほうがいいんじゃね？
厳密に言うと _MyFunc とか C++言語の規定違反だったと思うけど。

ま、つけるなら public 以外全部だな。
05014982010/04/04(日) 11:44:39
>>499
ファウラーたんが発祥らしい

>>500
なるほど、public以外ぜんぶが主流か
自分はJavaが多いんで他あんまり知らないんだけど、C++は規約違反なのかあ
C#とかは末尾にアンスコつけるらしいね

0502デフォルトの名無しさん2010/04/04(日) 13:48:42
> C#とかは末尾にアンスコつけるらしいね
　　　　　　　　　 　　　＿＿＿_
　　　　　　　　　　　／　　 　 　＼
　　　　　　　　 　／　─　 　 ─　＼
　　　　　　　　／ 　 （●） 　（●）　 ＼　　　
　　　　　　　　|　 　 　 （__人__）　 　　 |
　 　　　　　　 ＼　 　　 ｀ ⌒´ 　　 ,／
　r､　　　 　r､／　　　　　　　　　　ヘ
　ヽヾ　三　|:l1　　　　　　　　 　　　　ヽ
　　＼>ヽ/ |｀ ｝　　　　　　　　　 　　|　|
　　　ﾍ　lノ `'ｿ 　　　　　　　 　　　　|　|
　　　　/´　 /　　　　　　　　　　　　 |.　|
　　　　＼. ｨ 　　　　　　 　 　 　 　　|　 |
　　　 　 　 |　　　　　　　 　 　 　 　 | 　|
0503デフォルトの名無しさん2010/04/04(日) 14:50:07
あ、ごめん
末尾にアンスコもC++か

「末尾 アンダースコア」でぐぐったらC++の話が出てくるから、さっきの規約違反回避のためにそうやるのかな？

つけておくとコードみたらすぐわかるし、thisとかいらなくなるし、コード内で名前重複しづらくなるし、メソッドでも付けるぐらい気にいってるけど、最近は付けない風潮なのかなあ
0504デフォルトの名無しさん2010/04/04(日) 14:52:20
アンスコってアンダースコートの事かと思った
0505デフォルトの名無しさん2010/04/05(月) 00:18:23
>>500
_[A-Z].* と __[A-Z].* が処理系予約って話だろ?
処理系の解釈も OS 込みとか, 言語処理系単体とかあるみたいだな
0506デフォルトの名無しさん2010/04/05(月) 21:55:39
>>503
スコープを知りたくなること自体が、設計か実装が悪臭を放っている可能性を
示唆していると考える人は否定的になる。
プラグマチックに考えるなら、そのルールが有益になるチームはいくらでも
あるだろうと思う。
0507デフォルトの名無しさん2010/04/05(月) 22:27:28
だからといって敢えて削除するメリットがあるとも思えないし
混乱を深めるだけだと思う
0508デフォルトの名無しさん2010/04/05(月) 23:22:03
そうそう
付けないメリットより、付けるメリットの方が多い気がするんだよね

IDEが発達していらなくなるという主張も聞いた事あるけど、IDEだからこそ、一文字目からアンダースコアの有無による補完リストのフィルタリングとかできて便利だと思うんだが
0509デフォルトの名無しさん2010/04/05(月) 23:59:24
一文字目アンスコはC/C++で規格違反になると何度言えば（ry
見苦しかろうが m_ とかにすれ
0510デフォルトの名無しさん2010/04/06(火) 00:47:59
アンスコってアンインストールの事かと思った
05115062010/04/06(火) 14:53:28
>>507
削除しろなんて言って無いし。

>>509
規格で予約されているのは、先頭のアンダースコアに続く大文字と、
出現位置を問わず二連続のアンダースコア。
先頭のアンダースコアに続いて小文字が現れるのは規格適合。
0512デフォルトの名無しさん2010/04/06(火) 21:13:10
正確には何らかのネームスペース内ではだな
グローバルネームスペースでは不適合
0513デフォルトの名無しさん2010/04/06(火) 21:14:49
メンバでは結局適合だけどね
ただ混乱を避けるために一律禁止した方が良い
よく知らない人が書いちゃうし
0514デフォルトの名無しさん2010/04/06(火) 21:22:11
こいつらはgotoで書いて良いかどうかって議論をあまり聞かないが、どうだろうか

　for (i = 0; i < n; i++) {
　REDO:
　　...
　　if (...) goto REDO;
　　...
　}

REWIND:
　for (i = 0; i < n; i++) {
　　...
　　if (...) goto REWIND;
　　...
　}

どちらもgoto使うのが一番簡潔かつ分かりやすいと思うのだが、
必要になるケースが少ないからか、議題に上る事すらない気がする
でもたまーに必要になることがあるのよね
その時いつもgoto使いたくなるけど我慢して別の方法を使ってるが、
やっぱりgoto使うのが一番エレガントだと思うのだがどうよ
0515デフォルトの名無しさん2010/04/06(火) 23:05:32
REWINDは時々使う
REDOはほとんどcontinueで代用できる
0516デフォルトの名無しさん2010/04/06(火) 23:16:28
でも、i-- して continue; とか
i++ を最後に書いて continue; とか
何かキモくね？
0517デフォルトの名無しさん2010/04/07(水) 00:44:07
まぁ、continue や break も字面が違うだけで goto だからな。

else の ない if 文は goto 書いてあってもなくても
実質 goto だし、goto はよく使うよ。


ループの中で goto 使うときは while() で書いたほうが
気持ちの上では抵抗が少ないかな。
0518デフォルトの名無しさん2010/04/07(水) 01:06:20
>>514
REDO のほうは do ... while(...); のほうがよくないか？
REWIND はループを関数化して戻り値で分岐するかなぁ。
0519デフォルトの名無しさん2010/04/07(水) 08:16:11
for の再初期化式以外でループ変数を触るような場合は、
while か do で書くかな。
その goto REWIND はありだと思うけど。
0520デフォルトの名無しさん2010/04/07(水) 18:52:37
>>518
１カ所なら do-while でいいと思うけど
２カ所以上あったら面倒くさいと思う
redo のある言語もあるくらいだし、
その redo の代わりに goto 使うのはありじゃないかな
0521デフォルトの名無しさん2010/04/09(金) 22:57:22
for( int i=0,step=1; i < n; i+=step,step=1 ) {
　...
　if( ... ) {
　　step=0;　　//REWND時は　step=-i
　　continue;
　}
　...
}
0522デフォルトの名無しさん2010/04/10(土) 08:15:27
きったねえソースだな
0523デフォルトの名無しさん2010/04/13(火) 02:32:01
if (n == 0) goto end;
start1:
i = 0;
start2:
...
if (!...) goto start3;
goto start1;
start3:
...
i++;
if (i >= n) goto end;
goto start2;
end:

あんまり面白くなかった。。。
0524デフォルトの名無しさん2010/04/15(木) 01:05:19
for文のトコとかフラグを使う辺りが醜いのは認めますが…だめっすかね。>522

●>521のメリット
・ネストが無駄に深くならない。
・通常のfor文同様、ループ処理の肝となる処理が1行に集約されてる。

・カウンタの更新タイミングが明確。
　例えばカウンタを直接操作する方法でやってしまいがちな、↓のようなミスを防げる。
　　　if( i == x )　i = 0; //カウンタリセット(処理は継続)　← この行を追加
　　　...
　　　++data[i];　// data[x] にincrementされない。

・フローの制御方法が（比較的）単純明快。↓
　　for( int i=0,step=1; i < n; i+=step,step=1 ) {
　　　if( ... ) step = 0;　// もう1回
　　　if( ... ) step = -i;　// 最初から
　　　if( ... ) step = -n;　// n個戻る
　　　if( ... ) step += n;　// n個スキップ
　　}
0525デフォルトの名無しさん2010/04/15(木) 17:17:58
>>524
毎回そのコメント書くんならいいんじゃない？
ただ、step=1 がレギュラーケースじゃない場合を考えて、step=1/*次へ*/ もループ中に書いたほうがいいと思うけど。
記述意図を明確にする意味なら、data や i を構造体にラップしてそれを操作する関数群を用意した方が良いだろう。
0526デフォルトの名無しさん2010/04/15(木) 20:40:40
>>524
＞・ネストが無駄に深くならない。
goto 使った時とネストの深さに変化は無いし、
goto を使った方が if がすっきりする

＞・通常のfor文同様、ループ処理の肝となる処理が1行に集約されてる。
一行にたくさんの処理を詰め込んだだけで、分かり辛くなるだけ
goto だと単純な上に、ラベルにより意味も明解

＞・カウンタの更新タイミングが明確。
goto を使った方が分かりやすい
i+=step,step=1 なんて頭を使ってどういうコードか理解しないと分からない

＞・フローの制御方法が（比較的）単純明快。
step が途中で変わるのはとても分かり辛い
普通、そういう場合は for でカウンタを操作するのをやめて、
常に { } 内で直接カウンタを操作するようにする

そもそも、REDO や REWIND が必要なケースは稀であり、
そんな稀なケースに、より単純で明解な実装法があるにも関わらず、
複雑な技巧を凝らしたコードを仕込むのは得策ではない

goto が最も危険なのは、変数宣言を下に飛び越えたり、ブロック内に飛び込んだりする時だが、
REDO や REWIND はこの使い方には相当しない
飛ぶ位置はループ頭やループ前という極めて安全な位置のみであり、
かつ、どんな処理を行いたいのかが極めて分かりやすく、
goto を使う事に問題は無いと言える
0527デフォルトの名無しさん2010/04/15(木) 22:20:30
>>524
そこまで制御書くなら for じゃなくて while 使うなあ
0528デフォルトの名無しさん2010/04/16(金) 02:23:13
>525
関数とかでラップしちゃうとカウンタの変化するタイミングとかが却ってわかり辛いと思うんですが。
例えば↓
　　for( Counter<int> i = 0; i < n; i.increment() ) {
　　　if( ... ) i.retry();　//← retry実行後、i の値はどうなる?
　　　std::cout << i <<std::endl;　// retry実行時、何が出力される?
　　}
これだと i を直接操作する方がよっぽど素直かと。
（わざわざ「step」を使うのは、直接操作した場合生じる問題を回避するため）

>526
素直にgoto使う方がよりシンプルなのは否定しません。
ただ524は「gotoを使わない」という前提ありきで書いてます。
「公開しないコード書く時」あるいは「明示的に許可されてる」のでない限り
gotoは使うべきじゃ無いと思うので。

>527
その辺は適当に読み変えて下さい。
個人的な趣味&行数を抑える目的&etcで for1行にしました。
0529デフォルトの名無しさん2010/04/16(金) 07:02:33
> 「公開しないコード書く時」あるいは「明示的に許可されてる」のでない限り
> gotoは使うべきじゃ無いと思うので。
ダイクストラも罪作りなことをしたもんだ。
0530デフォルトの名無しさん2010/04/16(金) 09:23:16
教条的にGOTOを排除しようとするのは80年代に蔓延したおかしな傾向だろ。
ダイクストラが言ったのは60年代末。
0531デフォルトの名無しさん2010/04/16(金) 20:46:59
>>528
goto 使わない場合は次のように実装できる

REDO:
for (int i = 0; i < size; ++i) {
　bool redo;
　do {
　　redo = false;
　　if (...) { redo = true; continue; }
　} while (redo);
}

REWIND:
bool rewind;
do {
　rewind = false;
　for (int i = 0; i < size; ++i) {
　　if (...) { rewind = true; break; }
　}
} while (rewind);

カウンタに一切手を加えない分、step を使うよりは分かりやすい
もちろん、goto の方が分かりやすいが
0532デフォルトの名無しさん2010/04/16(金) 21:39:42
REDOを多重ループにすると今度はbreakでループを抜けられない…
とか思ったけど、そんなレアケース考えてもしょうがないか
0533デフォルトの名無しさん2010/04/16(金) 21:46:21
複雑なら関数化も視野に入れていいんじゃない
0534デフォルトの名無しさん2010/04/16(金) 23:11:08
じゃC++0xのラムダ関数で
05355252010/04/16(金) 23:44:09
>>528
もっと説明的なコードを書こうよ、って話。
Counter<int> i なんて名前じゃ曖昧になって当然。
CodeIterator currentCode(data, CodeIterator::Head);
if (...) currentCode.rewindToHead();
とかにしようよ。
先頭に巻き戻した後に、何が出力されるかどうかもないでしょ。先頭のだよ。

その構造は、中間言語処理や書式化文字列処理など、様々な場面で登場する。
その時々に相応しい構造と命名をしたら良い。
0536デフォルトの名無しさん2010/04/18(日) 13:34:35
>531
漏れはその書き方が一番無難だと思う。
goto使う方法はgotoの使用が許されるなら最善手だとは思うけど、
叩かれるのを覚悟して使うほどのメリットは無いと思う。
（叩かれるのを覚悟して>521を書いた奴が言う台詞じゃ無いけど）

>535
そこまで書くよりは、普通に↓と書く方が良いと思うけど。
　for( int i=0; i<n; ++i ) {
　　if( ... ) i =-1;　//最初から
　}
ただこの例を見ても分かるように、カウンタを直接弄る方法は
「最初から」が何故-1なのか直感的に分かり辛い。
（>535みたいな書き方しても同様の問題が出てくる。）
だから>521。でもって↑も521も、下手に関数化するよりは
手の内を全て見せてしまった方が分かり易いと思われる。

まぁそこまでやるなら素直に>531のが良いとは思いますが。
0537デフォルトの名無しさん2010/04/18(日) 13:35:59
追記。
ただ>531のredoは
　for (int i = 0; i < size; ++i) {
　　do {
　　　// 繰り返す処理
　　} while ( ... );
　}
と書くべきかと。フラグ要らんでしょ。
0538デフォルトの名無しさん2010/04/18(日) 13:57:59
本当は if は途中に出てきてるのだよ
0539デフォルトの名無しさん2010/04/18(日) 14:52:50
>538
>531
>if (...) { redo = true; continue; }
continueしとるで。
0540デフォルトの名無しさん2010/04/18(日) 18:10:11
こういうことだよ

for (int i = 0; i < size; ++i) {
　bool redo;
　do {
　　redo = false;
　　...
　　if (...) { redo = true; continue; }
　　...
　} while (redo);
}
0541デフォルトの名無しさん2010/04/18(日) 18:12:11
>>514の一つ目をdo while文で書いたときのフラグなしバージョン
for (...) {
　do {
　　...
　　if (...) continue;
　　...
　　break;
　} while(true);
}
まあ、redoはできても通常のcontinue、breakができなくなるけどね
0542デフォルトの名無しさん2010/04/18(日) 18:17:17
通常の意味でのcontinueはdo while文の中でbreakすればいいか
ややこしい…
0543デフォルトの名無しさん2010/04/18(日) 18:32:55
お前らおかしいぞ
普通に goto 使え
0544デフォルトの名無しさん2010/04/18(日) 19:51:37
飛び先を制御するためだけに
ループしない while を用意するのは邪悪
0545デフォルトの名無しさん2010/04/18(日) 21:16:50
普段gotoを使わないから>>514のようなケースのとき
gotoを使うってとこまで頭が働かないな
0546デフォルトの名無しさん2010/04/19(月) 08:13:33
無限ループは for (;;) {} で、ループしないループは do {} while (0) で、
というのはイディオム。
0547デフォルトの名無しさん2010/04/19(月) 19:25:34
do {} while (0); は continue しようが何しようが必ず抜けるから
continue した時はループする >>541 とは全く別の話だな
0548デフォルトの名無しさん2010/06/12(土) 22:46:29
>>514のコードを書き換えるという前提では、結局gotoを使うのが一番簡潔に
なるんだろうけど、実際のコーディングではケースバイケースで全然違う書き方を
すると思う。
いったん普通にループを抜けてからREWINDやREDOに相当する処理を別にするとか。
0549デフォルトの名無しさん2010/06/18(金) 01:39:17
最近言語に関係なくインデントにスペース2つを使うプロジェクトを
よく見る気がするんですが、これって元々どの辺の文化で使われていたんでしょうか？
0550デフォルトの名無しさん2010/06/18(金) 19:27:50
スクリプト言語じゃないかね
0551デフォルトの名無しさん2010/06/18(金) 19:50:49
GNU?
0552デフォルトの名無しさん2010/06/18(金) 23:54:30
ぐにゅ？
0553デフォルトの名無しさん2010/06/28(月) 10:51:33
>>549-552
2桁インデントはGNUスタイルだろ。
indentがインストールされている環境なら、indent -gnu <ソースファイル> でGNUスタイルに整形される。
0554デフォルトの名無しさん2010/06/28(月) 10:59:34
GNU indent 2.2.3で試してみた。
::::::::::::::foo.c // オリジナル
#include <stdio.h>
int main()
{
for (int ic = 0; ic < 10; ++ic) {
if (ic % 2 == 0) printf("%d\n", ic);
}
return 0;
}
::::::::::::::foo.kr.c // K&Rスタイル
#include <stdio.h>
int main()
{
for (int ic = 0; ic < 10; ++ic) {
if (ic % 2 == 0)
printf("%d\n", ic);
}
return 0;
}
::::::::::::::foo.gnu.c // GNUスタイル
#include <stdio.h>
int
main ()
{
for (int ic = 0; ic < 10; ++ic)
{
if (ic % 2 == 0)
printf ("%d\n", ic);
}
return 0;
}
0555デフォルトの名無しさん2010/06/28(月) 15:41:41
>>554
navi2chとかchalice使いでないと違いわからんだろ、これ
0556デフォルトの名無しさん2010/06/28(月) 16:30:35
>554を変換してみた
::::::::::::::foo.c // オリジナル
#include <stdio.h>
int main()
{
    for (int ic = 0; ic < 10; ++ic) {
        if (ic % 2 == 0) printf("%d\n", ic);
    }
    return 0;
}
::::::::::::::foo.kr.c // K&Rスタイル
#include <stdio.h>
int main()
{
    for (int ic = 0; ic < 10; ++ic) {
        if (ic % 2 == 0)
            printf("%d\n", ic);
    }
    return 0;
}
::::::::::::::foo.gnu.c // GNUスタイル
#include <stdio.h>
int
main ()
{
  for (int ic = 0; ic < 10; ++ic)
    {
      if (ic % 2 == 0)
        printf ("%d\n", ic);
    }
  return 0;
}
0557デフォルトの名無しさん2010/06/29(火) 22:32:49
>>555
ニョロカッコの位置と改行位置で分かるだろ?
0558デフォルトの名無しさん2010/12/12(日) 19:10:07
以下のような理由をあげて、 「構造体の typedef 禁止！！！」つったのに
平気で typedef srruct foo { ... } foo_t; をやってくるおまえらは
なにものですか > 今度使ってる害虫
Avoid using typedefs for structure types. Typedefs are problematic
because they do not properly hide their underlying type; for example you
need to know if the typedef is the structure itself or a pointer to the
structure. In addition they must be declared exactly once, whereas an
incomplete structure type can be mentioned as many times as necessary.
Typedefs are difficult to use in stand-alone header files: the header
that defines the typedef must be included before the header that uses it,
or by the header that uses it (which causes namespace pollution), or
there must be a back-door mechanism for obtaining the typedef.
0559デフォルトの名無しさん2010/12/12(日) 20:19:08
>>558
それを挙げて禁止とか言ったんなら、英語の読めない中途半端な経験者だったんだろう。
一般的な解説と、具体的なデメリットとを繋いで説明できればよかったのにね。
0560デフォルトの名無しさん2010/12/13(月) 02:21:42
キャッチボールで相手のレベルに合わせて投げるのと同じように、
コミュニケーションでも相手のレベルに合わせて伝えるべき。
子供相手に変化球投げたりしないだろ?

と、昔上司から言われた台詞を貴方にも。
0561デフォルトの名無しさん2010/12/13(月) 03:09:28
>>559, 560
そのほかに指示したのは、「名前の長さは長くても20文字程度に押さえてね」だけで、
こっちは守られてるのに、「構造体の typedef 禁止」は無視するってのはおかしくないか？

一部の地域には構造体を typedef しなきゃいけない宗教的理由でもあるのか？
0562デフォルトの名無しさん2010/12/13(月) 03:53:23
>>561
少なくとも、妄信的にtypedefする奴はいる。
0563デフォルトの名無しさん2010/12/13(月) 07:30:35
>>561
http://www.google.co.jp/search?q=%E5%85%A5%E9%96%80+typedef+struct

名前20文字以内が守れてるってのは、普通にやってればなかなかそこまで
長くならないってだけかもしれない。
0564デフォルトの名無しさん2010/12/13(月) 22:03:37
妄信的に単語を短縮する奴もいる。
酷いのだと何でもかんでもアルファベット3文字とか。
特にCOBOLer上がり。
0565デフォルトの名無しさん2010/12/14(火) 00:18:34
H8環境でC++使ってないとtypedefだらけになる。
0566デフォルトの名無しさん2010/12/23(木) 22:21:26
>>558
そういうトラブルは typedef を禁止したところで
なくならないし未然防止にもならない。

そもそも言語に対するスキルというか
リテラシーが低いことが問題。

名前の長さも同じこと。 不思議な省略単語濫用で
20文字以内になっても意味がない。
0567デフォルトの名無しさん2010/12/23(木) 23:58:54
>>566
んなことは分かてる、なんでルールを無視するんだ？ と言ってる
実際にあった話だが、顧客指定でLaTeXでドキュメント寄越せと言われたらどうするよ
0568デフォルトの名無しさん2010/12/24(金) 01:23:48
タグ名と typedef 名が同一ならよいのだから、そのくらいはヴァリデータツールを書いて、通らなければコミットできないようにしてしまえばよいのではないか。
0569デフォルトの名無しさん2010/12/24(金) 13:17:29
>>568
同一ならいいってわけじゃないだろう。 >>558 は読んだか？
0570デフォルトの名無しさん2010/12/26(日) 10:09:36
まぁ、下請けになめられてるんだろうな。
0571デフォルトの名無しさん2010/12/28(火) 19:29:32
>>569
読んだ上で問題ないと判断したんだが、具体的にどういう場合に不具合があるんだ？
そこにある三つの問題全てクリアになると思うよ。
0572デフォルトの名無しさん2010/12/28(火) 22:13:38
>>571
"they must be declared exactly once"
"the header that defines the typedef must be included before the header that uses it"

A.h で struct A だけが宣言されていて、使う側で毎度 struct A と書く場合、
使う側で A.h をインクルードせずに struct A の前方宣言で済ませることができる。

A.h で struct A の宣言に加えて typedef struct A A があり、関連する関数の宣言に
struct A* ではなく A* が現れる場合、 A* を使うためには必ず A.h のインクルードが
必要になる。

問題が３つだとしたら２つは残ってるように見える。
何か誤解されてるんじゃなかろうか？
0573デフォルトの名無しさん2010/12/29(水) 18:29:41
>>572
コーディング規約にすることで未然に防ぎたい不具合の具体的な例をお願い。

> A.h で struct A の宣言に加えて typedef struct A A があり、関連する関数の宣言に
> struct A* ではなく A* が現れる場合、 A* を使うためには必ず A.h のインクルードが
> 必要になる。

根拠が分からない。
手元の三つのコンパイラでコンパイルでき、警告さえ出さない。
俺が失念している規格があるのかもしれないから、具体的に示してもらえるとありがたい。

> A.h で struct A だけが宣言されていて、使う側で毎度 struct A と書く場合、
> 使う側で A.h をインクルードせずに struct A の前方宣言で済ませることができる。

というわけで、こちらも前方宣言で済ませることができる。
ただし typedef struct A A; の一行が余分に必要になる。
ちなみに C++ なら余分の typedef も不要。


と、ここまで書いてようやく気づいたが、同じ typedef 名の typedef がいけないということか。
typedef struct A A;
typedef struct A { int a; } A;
とあると、後者でエラーになるということか。

ちなみにこれは gcc ではエラーだが、cl と bcc32 ではスルーだった。
もちろん C++ ならどれも ok。

その理由で禁止なら、支持できるが、本当にこんなことを言ってたの？
0574デフォルトの名無しさん2010/12/29(水) 18:34:40
>>573
> 手元の三つのコンパイラでコンパイルでき、警告さえ出さない。

どんなコードでテストしてるの？

> というわけで、こちらも前方宣言で済ませることができる。
> ただし typedef struct A A; の一行が余分に必要になる。
...
> typedef struct A A;
> typedef struct A { int a; } A;
> とあると、後者でエラーになるということか。

前方宣言のつもりで複数のヘッダに typedef struct A A; と書いたとしたら、
それらのヘッダをひとつの翻訳単位にインクルードすればやっぱりエラーになるだろ。
0575デフォルトの名無しさん2010/12/30(木) 02:33:59
C禁止にしてC++に統合しようぜ。
0576デフォルトの名無しさん2010/12/30(木) 07:16:23
そんな事したらリーナスおじさんが黙っていない
0577デフォルトの名無しさん2010/12/30(木) 11:06:58
俺もOOPは大好きだが、
OOPLとしてのC++にも感謝してるが、
どっちか無くせといわれたら、C++がイランなｗ
Cは必要だな。
0578デフォルトの名無しさん2010/12/30(木) 15:26:15
>>573
> もちろん C++ ならどれも ok。

C++ でも微妙だったりする。
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#407
0579デフォルトの名無しさん2010/12/30(木) 23:31:39
揚げ足取りならC++ならC的な書き方もできるがね。

とはいえ組み込み系だと環境構築してる間に開発期間がなくなる勢いだから
トップダウンでCを減らして欲しい。ボトムアップじゃムリポ。
0580デフォルトの名無しさん2010/12/31(金) 09:26:49
>>579
組み込み系だとC++が使えない程度に貧弱なハードの場合も多々あるんだが
つか、テンプレートとか使うとC++ってコードサイズが見積もれなくないか？
0581デフォルトの名無しさん2011/01/01(土) 01:27:35
逆に、constなんかはCよりC++の仕様のほうが組込にも向いているように思う。

自分の知り合いは、テンプレートは使う（もちろんコードサイズ増加は織り込み済み）が、
それよりも動的メモリ確保(malloc/new等)禁止のほうを気にかけている感じだった。
これももちろん分野によるのだろうけど。
0582デフォルトの名無しさん2011/01/01(土) 04:27:25
if文の中に長い関数式を書くのはあまり好みではないので分けて書くことが多いけどどうよ
何をあほな書き方してんだと思うかいな。

if (MessageBox("保存しますか?", "内容が変更されています", MB_YESNO | MB_ICONQUESTION) == IDYES)
文;
----------------------------------------------------
const char * const pc1 = "保存しますか?";
const char * const pc2 = "内容が変更されています";
int num1 = MessageBox(pc1, pc2, utype);
// もしくは
// const LPCTSTR lpctstr1 = "保存しますか?";
// const LPCTSTR lpctstr2 = "内容が変更されています";
// uint utype = MB_YESNO | MB_ICONQUESTION;
// int num1 = MessageBox(lpctstr1, lpctstr2, utype);
int num2 = num1 == IDYES;
if (num2)
文;
0583デフォルトの名無しさん2011/01/01(土) 11:57:47
え？　折角変数使うのにnum2みたいな糞名前？

そんなんつけるくらいなら
int ret = MessageBox(pc1, pc2, utype);
if (ret == IDYES)

こうするほうがまだマシでは？
else if (ret == IDCANCEL)などと続けられることも考えて。
0584デフォルトの名無しさん2011/01/03(月) 13:24:29
>>580
ハード性能の貧弱さで C++ が使えなくなるなんてことはないよ。

例外、 RTTI 、テンプレートとか、機能や具体的な使い方に応じて
費用対効果が見合わないことはあるだろうけどね。
でもそれは組み込みにかかわらずあたりまえの話。

マイナーすぎてコンパイラが無いっていう方向の貧弱さを言ってるんだったら別。
0585デフォルトの名無しさん2011/01/03(月) 14:07:45
>>584 主記憶64kでやってみろよ
0586デフォルトの名無しさん2011/01/03(月) 14:46:28
>>585 別に問題ありませんが何か？
0587デフォルトの名無しさん2011/01/03(月) 22:32:32
>>585
むしろその環境に対して C++ の何が問題を起こすと思っているのか聞きたい。
0588デフォルトの名無しさん2011/01/11(火) 01:09:09
C++ が問題というよりは、組み込みでテンプレとか
ガンガン使っておいて ROM/RAM 足りませんみたいな
こと言ってくる奴が多すぎて困る。

バグったらバグったで自分じゃ解析できないから
ヘルプミーだと。 C++禁止にしようぜ。
0589デフォルトの名無しさん2011/01/11(火) 23:44:50
テンプレ禁止しろよ
0590デフォルトの名無しさん2011/01/12(水) 10:53:19
テンプレってリソース喰うん？
0591デフォルトの名無しさん2011/01/12(水) 11:49:57
>>590 いいえ
0592デフォルトの名無しさん2011/01/12(水) 12:12:04
リソースを食うコードを書いてしまいやすいと言うべきかな
0593デフォルトの名無しさん2011/01/12(水) 12:22:45
なにこのほほえましいスレ。
0594デフォルトの名無しさん2011/01/12(水) 18:43:10
>>588
禁止というか免許制にすればいいのにとは思う
0595デフォルトの名無しさん2011/01/12(水) 20:08:48
http://sky.geocities.jp/tcshacina/hash.c
これは？
0596デフォルトの名無しさん2011/01/24(月) 02:34:22
Javaで使い終わった変数にnullセットとか意味あんの？
ゴスリングも、今のGCは賢いからそんなことせんでええと言っているし、
そもそもスタイルとして美しくないので嫌いなんだが。
あと、宣言時のnullセットも同じく。
ここの先輩諸氏はどう思われますか。
0597デフォルトの名無しさん2011/01/24(月) 03:50:41
宣言時のnullセットは意味が無いな
0598デフォルトの名無しさん2011/01/24(月) 09:14:31
インスタンス変数で、null代入しないとオブジェクトリークになる、
というのでもない限りいらんだろ。
0599デフォルトの名無しさん2011/01/24(月) 09:17:46
GC目的のつもりの代入に限って言えば、
それを強いるなど狂気の沙汰だ。
0600デフォルトの名無しさん2011/01/24(月) 10:34:58
生存時間の長いローカル変数に対して、時間がかかる処理の前にnull代入するのは意味がないこともないよ
GCの世代昇格を防いだり
0601デフォルトの名無しさん2011/01/24(月) 11:02:17
>そもそもスタイルとして美しくないので嫌いなんだが。

なぜそう思う？
0602デフォルトの名無しさん2011/01/24(月) 22:59:59
>>596
VB出身者が必要だと思ってるんだろ。それ。
0603デフォルトの名無しさん2011/01/24(月) 23:02:00
使い終わった変数にnullを入れると安全になるって思い込んでるヤツは
よくみるな。
それで安全になるようなコードの書き方をしてるなら、そっちを見直すべき
なんだけど。
0604デフォルトの名無しさん2011/01/29(土) 15:50:46
C++なら新人に多重deleteされないようにdeleteし終わったらNULL入れておくかな。
C++はNULLのdeleteは「何もしない」のが仕様として決まっているから。
無条件deleteでも問題ない話になる。
0605デフォルトの名無しさん2011/01/29(土) 17:09:13
コーディングルールの話をしてて、それはダメだってことになると、
「これはヘタクソには有効だ」って反論がでてくるけど、ヘタクソ向けの
コーディングルールなんていらないよな。
だいたいヘタクソに対しても別に有効じゃねえだろって感じだし。
0606デフォルトの名無しさん2011/01/29(土) 19:15:53
よう俺。
デメリットを指摘しても「でも僕はこっちの方がいいです。慣れですよ」とか言われるし。
0607デフォルトの名無しさん2011/01/29(土) 20:13:55
個人でプログラムしてるのなら、
周りの人間がそいつのコーディングスタイルをどうのこうの言っても意味が無い
好みの問題に他人が口出しするものではない

が、チームを組んでプログラムしてたり、
そいつのソースを将来別の誰かがメンテしたりするのなら、
コーディングスタイルを合わせるよう「命令」しないといけない

デメリットやメリットは無意味で、問答無用で「命令」だ
0608デフォルトの名無しさん2011/01/29(土) 20:37:06
もしかして:スレ違い
0609デフォルトの名無しさん2011/01/29(土) 20:38:07
ヘタクソにコーディングルールを強いると、生産性が落ちてバグが増えそうで怖い。
なのでヘタクソのコーディングルールに合わせるのです。
0610デフォルトの名無しさん2011/01/29(土) 20:54:06
>>609
> 生産性が落ちてバグが増えそうで怖い

見えないものを怖がるな

どのようなヘタクソに、どのようなコーディングルールを強いた場合、
生産性がどれくらい落ちて、バグがどれくらい増えるのか、ちゃんと検証すればいい

検証の結果、本当は逆に生産性が上がってバグが減るのかも知れない
0611デフォルトの名無しさん2011/01/29(土) 21:51:55
>>604
スマートポインタ、最低でも auto_ptr で自分で delete 書かないほうがいいだろ。
確実だし、デストラクタでヌル詰めるとか無駄だし。
0612デフォルトの名無しさん2011/01/30(日) 01:19:42
>611
>最低でもauto_ptr
そしてコンテナでハマると。

>609,610
バカをフォローする手間を省くためだと思う。
ルールを決めるに当たって
・バカでも憶えやすい・理解しやすい
・特定の条件下では最も無難
・機械的にチェックしやすい
に傾きがちなのもきっとそのせい。
0613デフォルトの名無しさん2011/01/30(日) 02:32:19
昔は馬鹿を育てたんだけどな
俺も育てられたし
0614デフォルトの名無しさん2011/01/30(日) 15:27:32
ポインタをnullクリアより、変数のスコープを小さくしましょうとか、
使い回しをやめろとか教えたほうがいいだろ。

ポインタをnullクリアって、バグがおきないとかバグを発見しやすくする
工夫じゃなくて、バグってもなんとなく動いちゃう工夫だし。

あと上から目線で馬鹿向けって言ってるけど、使い終わったポインタを
NULLクリアするって言ってるやつって、馬鹿向けじゃなくて本気でそれ
がいいって思ってるっぽいし。
0615デフォルトの名無しさん2011/01/30(日) 15:38:08
スタイルというより教育だな。
0616デフォルトの名無しさん2011/01/30(日) 15:49:28
ある程度熟達すればコーディングスタイルにほとんどばらつきが出ない Lisp 系は、
コーディングスタイルという点ではけっこういい言語かも知れない
0617デフォルトの名無しさん2011/01/30(日) 15:51:29
馬鹿の度合いにもよるけどな。
とにかくいじらせるコード量を減らすこと。
今はそれで対処できるのでそうしてる。
教育できそうな馬鹿っていいよね。
うらやましいよ。
こっちの馬鹿は英単語すら読めねえんだぜ。
だから当然エラーメッセージもw
0618デフォルトの名無しさん2011/01/30(日) 15:54:38
>>616
ループを回すのに、dolist や loop を使うか、map 系を使うかというのでちょっ
と悩む。
0619デフォルトの名無しさん2011/01/30(日) 15:57:54
>>614
> 本気でそれがいいって思ってるっぽい
一概にそうとは言いきれない

無限ループ
入力 -> フィルター -> 出力 ==> 別プロセス

をやると, 世代別 GC しか持ってない言語だと, フィルターの出力段近くで使っ
てる変数とか出力バッファがらみの動的オブジェクトは明示的に null 代入し
ないとメモリー足りなくなる
0620デフォルトの名無しさん2011/01/30(日) 16:15:53
deleteしたポインタにnull入れても無意味だし、GCある言語でも
スコープはずれたり使いまわししてる変数にnull入れても無意味。
0621デフォルトの名無しさん2011/01/30(日) 17:20:47
GC目的以外ならnullは有効だろう。
シングルトンパターンでの生成を遅延させたりするとき、
bool isinitedみたいなよけいないもんを使うより単に、
Foo foo = null;
getInstance() {
if (foo == null) foo = new FooBig();
return foo;
}
とすれば満足では。

あと、Foo::delete(Foo **foo)みたいにして
中でdelete *foo; *foo = null;とかさせておいて、
呼び出し元で、それ以降の望まないfoo->bar()を失敗させるのもやった。
当時はこれでうまくいったと思ってたが、今見るとなんかアホっぽいけど。
0622デフォルトの名無しさん2011/01/30(日) 17:35:24
ポインタのnullクリアは、GC関連なら特殊なパターン以外は意味ないし、
バグを防ぐって意味なら、変数のスコープを狭くしなさいとか、使いまわしは
やめなさいとかってルールのほうがいいよね。
0623デフォルトの名無しさん2011/01/30(日) 21:49:58
不正アクセス防止になるじゃねーの？　JAVAなんか使わないから知らんけど。
0624デフォルトの名無しさん2011/01/30(日) 22:16:04
いやならないんじゃないの?
0625デフォルトの名無しさん2011/01/31(月) 00:20:16
ぬるぽが出るんじゃないの？
0626デフォルトの名無しさん2011/02/05(土) 00:36:57
nullクリアが真価を発揮するのは、デバッガでソース追う時。
スパゲティなソースでも、きちんとnullクリアしてるかどうかで
デバッグのしやすさが格段に違う。

「追いやすいコード」を目指すなら、多少手間でもnullクリアをしとくべき。
読みやすさを心がけてるなら、追いやすさも当然心がけるよな?
0627デフォルトの名無しさん2011/02/05(土) 01:19:09
free(p);
#if DEBUG
p = NULL;
#endif

ですねわかります
0628デフォルトの名無しさん2011/02/05(土) 02:04:04
>>626
null クリアでトレースしやすくなる理由がわかりません。
0629デフォルトの名無しさん2011/02/05(土) 16:34:51
>627
そしてリリース版/デバッグ版の挙動の違いに悩まされる訳ですね。分かります。

>628
一部のデバッガが、未初期化・delete後の領域に
0xccとか埋める理由を考えてみると良いかと。

とか書くとnullクリアしなくても、その機能だけでも十分とか言い出すんだろうな。
0630デフォルトの名無しさん2011/02/05(土) 16:42:32
>>629
0xcc とか埋めるのはデバッガじゃないよ。
VC++ でデバッグビルドの時のデフォルト動作だったはず。

で、その機能はトレースのしやすさとは関係ないと思うんだけど、どういうこと？

うっかり破棄後のポインタを触る可能性を考えるなら、スマートポインタを
使っておけばスコープアウトで解放するんだからほぼ根絶できるし、
スコープアウト前に解放する場合はスマートポインタが null クリア相当の
ことはするし。

手間をかけてでも null クリアしとけというのはやっぱりわからん。
0631デフォルトの名無しさん2011/02/05(土) 20:54:22
Javaの話じゃなかったのか
0632デフォルトの名無しさん2011/02/05(土) 21:35:50
Java で 0xcc 埋めとか、無いよな。
0633デフォルトの名無しさん2011/02/06(日) 18:13:55
そんなもん入ってたら大変なことになるだろうな
0634デフォルトの名無しさん2011/02/06(日) 21:32:52
>>633
なんで？

プログラマやデバッガが Java の意味として解釈できるアクセス対象は、
せいぜいバイトコードまでで、そりよりしたのレベルはランタイムに依るから、
実際のところ 0xcc で埋められていようといまいと、何も起こらないと思うんだが
（正確にはインターフェースのこちら側にとっては何も起こってないように見える）
0635デフォルトの名無しさん2011/02/06(日) 21:45:00
>>634
その 0xcc 埋めは Java では実装できないだろ。
JVM の実装として話すんなら C++ 以下の話だろう。
0636デフォルトの名無しさん2011/02/06(日) 22:13:55
>>635
> その 0xcc 埋めは Java では実装できないだろ

だから、プログラマやデバッガの立場では 0xcc 埋めできないんだから、
実際に 0xcc が入っていても大変なことになんてなるわけないと思うんだが
0637デフォルトの名無しさん2011/02/06(日) 22:22:39
>>636
そういうことか。
「Java の話ではない」って流れについて言ってるのかと思った。ごめん。
0638デフォルトの名無しさん2011/02/07(月) 00:29:09
>630
>うっかり破棄後のポインタを触る可能性を考えるなら、スマートポインタを
>使っておけばスコープアウトで解放するんだからほぼ根絶できるし

それはメモリ管理が楽になるだけであって、トレースしやすさとは別の話だと思うけど。
トレースし易いってのは、nullとか0xCCとか埋められれば、特定のアドレスの値を
見れば状態が分かるとかいう事だと思うが。
0639デフォルトの名無しさん2011/02/07(月) 00:32:55
0xccが無効なオブジェクト扱いになるんかいな。NULLは処理系として例外扱いだろ？
0640デフォルトの名無しさん2011/02/07(月) 00:36:36
>>638
0xcc の話なら確かに「特定のアドレスの値を見れば状態が分かる」けど、
破棄後のポインタにヌルを入れてもそんなことにはならないよ。
0641デフォルトの名無しさん2011/02/07(月) 00:47:22
>640
ポインタの値を見れば、そのポインタの状態は一目瞭然ですよね。
0642デフォルトの名無しさん2011/02/07(月) 00:51:49
>>641
スコープアウトさせてしまえば見るまでも無く状態は明白ですよね。
0643デフォルトの名無しさん2011/02/07(月) 00:56:31
>642
「デバッガでポインタをウォッチしているケース」は想定してます?
0644デフォルトの名無しさん2011/02/07(月) 01:01:32
>>643
してません。何のためにそんなことしてるのかな？
0645デフォルトの名無しさん2011/02/07(月) 01:36:36
例えば
　Hoge *p = new Hoge()
　if( … ) {
　　// 何かの処理
　}
　moge( p );
のようなソースで、一々ソース追わずに moge() まで飛ばしてから p を見るとか。
0646デフォルトの名無しさん2011/02/07(月) 01:43:58
>>645
だから、たとえば何のために p を見るの？それで何が知りたいの？
0647デフォルトの名無しさん2011/02/07(月) 01:48:41
デバッガを使わないとコーディングもデバッグもできない人が世の中にはいるようで。
0648デフォルトの名無しさん2011/02/07(月) 02:39:24
>646
>たとえば何のために p を見るの？それで何が知りたいの？
仕様通りの結果が得られたかを 知るため/知りたい。
null 埋めルールが徹底されてりゃ、途中で p が delete されたかどうかも
pを見るだけで容易に分かる。
p の先を見たり、大袈裟なツールに頼る必要も無い。
「トレースしやすい」とはそーいうことです。

>647
古文書の解析にはデバッガ必須。
0649デフォルトの名無しさん2011/02/07(月) 02:43:55
>>648
> null 埋めルールが徹底されてりゃ、途中で p が delete されたかどうかも
> pを見るだけで容易に分かる。

その null 埋めルールを徹底するためにもスマートポインタ使ったほうがいい（ >>630 ）
ってのはわかってて言ってるの？
0650デフォルトの名無しさん2011/02/07(月) 02:49:12
>>645
いまどき生ポインタ使って自分で delete するやつなんていねーだろ。
0651デフォルトの名無しさん2011/02/07(月) 03:01:24
>649
分かってて言ってます。
（勿論スマートポインタを使う方が賢いと言うことも。）

>で、その機能はトレースのしやすさとは関係ないと思うんだけど、どういうこと？
とか言ってるから、null埋めそのものがトレースにどう有益かを述べてるだけですが何か。
0652デフォルトの名無しさん2011/02/07(月) 03:31:41
つまり、「おいらの頭はスカスカだから、NULL埋めしてデバッガで追わないとどうしようもないスパゲッティコーディングしかできないよ」ってことですね。判ります。
0653デフォルトの名無しさん2011/02/07(月) 03:33:11
或いは、「適切にコーディングされた工芸品のようなコードでもデバッガで追わないと理解できないくらい頭がゆるゆるなんです」とか。
0654デフォルトの名無しさん2011/02/07(月) 03:33:33
>>651
あぁそうなの。てっきり >>626 の「多少手間でもnullクリア」に賛同してる人なのかと思ってた。

明示的にコードを書くかどうかを別にした「null埋めそのものがトレースにどう有益か」に
異論は無いよ。ありがとう。
0655デフォルトの名無しさん2011/02/07(月) 03:40:56
>652
貴方のような物分りの悪い方に「このポインタは用済み」ってのを明示するためです。
0656デフォルトの名無しさん2011/02/07(月) 03:42:50
nullを埋めないと明示できないのか。
0657デフォルトの名無しさん2011/02/07(月) 05:01:59
スマートポインタを使えない状況も考慮すると、NULL埋めを徹底させた方がいい気もするなぁ

実際の大規模プロジェクトの現場では、スマートポインタで統一させるのと
初期化/使用後にNULL埋めを徹底させるのと、どっちが多いんだろうか？
0658デフォルトの名無しさん2011/02/07(月) 08:55:11
Cに縛られているロートルが多いと言うことを鑑みると、後者が多いと思われ。
なんせ未だにカラム制限のあるコーディング規約もあるくらいだ。
0659デフォルトの名無しさん2011/02/07(月) 09:11:44
>>657
> スマートポインタを使えない状況も考慮すると、NULL埋めを徹底させた方がいい気もするなぁ

どんな状況だ？
最低でも std::auto_ptr は使えるだろ。
0660デフォルトの名無しさん2011/02/07(月) 10:28:07
馬鹿なプログラマがスマポ使えないんだお。
0661デフォルトの名無しさん2011/02/07(月) 11:28:21
スマポが必要になったことが無い。俺が馬鹿だからだろうか。
0662デフォルトの名無しさん2011/02/07(月) 11:37:22
>>661 そのとおりか、あるいは経験不足か、あるいは経験過多です。
0663デフォルトの名無しさん2011/02/07(月) 11:42:21
つまり、明日は晴天だけど時々曇りで場合によっては雨ということですね
0664デフォルトの名無しさん2011/02/07(月) 11:47:12
>>659
組み込み系やデバイスドライバ開発だと
スマポが使えない/使わないケースがよくあるよ
場合によってはC++ NGでCだけでの開発を求められたりとか
0665デフォルトの名無しさん2011/02/07(月) 11:50:40
>>664
それ、技術的な制約でそうなるの？（だとしたらどんな制約？）
それとも決定権のある人が無理解なだけなの？
0666デフォルトの名無しさん2011/02/07(月) 12:25:09
>>665
OSが提供する安全なユーザ空間の上でしかプログラムを組んだ事の無い
アプリ屋さんだと、ちょっと想像しにくいと世界だと思う
そういうもんなんだよとしか言えないし面倒なんで詳しい説明はしない
OSの構造や設計法あるいはリアルタイムOSの解説など
ネットで調べるなり本を読むなり該当スレへ質問するなり自分で考えてくれ
0667デフォルトの名無しさん2011/02/07(月) 12:32:07
>>666
いや、俺は組み込み屋なんだが。
幸いにして関わったプロジェクトでは C++ コンパイラが使えたんで、
何の問題も無く使えている（ような気がする？）。
もちろん OS のある環境とまったく同じというわけにはいかないけど、
少なくともスマートポインタを使わない理由は無い。現に使えている。

なんだろうな？
まぁもうちょっと調べてみるよ。
0668デフォルトの名無しさん2011/02/07(月) 12:39:41
スマートポインタは何を解決してくるの？
deleteの書き忘れ？
deleteを書き忘れちゃうようなコードを書く人のためのもの？
0669デフォルトの名無しさん2011/02/07(月) 13:33:50
しょぼい組み込みだとコンパイラがないとか
コンパイラの信頼性とか、そういう世界なのかな。
0670デフォルトの名無しさん2011/02/07(月) 14:26:40
>>668
マーフィーの法則によるとdeleteを書き忘れない人は存在しない
0671デフォルトの名無しさん2011/02/07(月) 14:35:02
()や{}を書く時セットで両方記入しておいて、
カーソル移動して中身を後から書いてる。
同様に、new書いたらdeleteを直後に書く。

直後じゃなかったとしても、生成と破棄はセットで設計してるから大丈夫。
対になるものはいつも対応を取りながら進めていく。
0672デフォルトの名無しさん2011/02/07(月) 14:57:55
>>667
ちなみにターゲットマシンのCPUは何でございましたでしょうか？
0673デフォルトの名無しさん2011/02/07(月) 17:30:18
>>671
だからそれを人力でやってるのが駄目なんだっつーの。
そりゃ普通そう書くよ。
0674デフォルトの名無しさん2011/02/07(月) 23:04:20
>671
変なフレームワークや仕様を強要されてる場合、newとdeleteを
別々のクラス/関数/スレッド/etcで実行せざるを得なかったりして
必ずしも1対1にできるとは限らないと思う。
0675デフォルトの名無しさん2011/02/07(月) 23:29:24
>>671
そのやりかただと return や例外やその他いろいろ破綻する可能性が残る。

>>668 スマートポインタはこういった問題を防ぐためにある。
0676デフォルトの名無しさん2011/02/07(月) 23:31:54
>>672
ARM7,9,11 と PowerPC 系が少し。
0677デフォルトの名無しさん2011/02/08(火) 01:00:25
> newとdeleteを別々のクラス/関数/スレッド/etcで実行せざるを得なかったりして

そういうときはまず設計を改めたいものだ。
生成期間の管理があやふやになってスマポに頼るような時、
すでに半分棺桶に体突っ込んでるようなもの。どの道破綻する。
0678デフォルトの名無しさん2011/02/08(火) 01:23:28
>>676
ゲーム? のはずないか。
そのあたりは c++ いけるしな。
0679デフォルトの名無しさん2011/02/08(火) 07:58:22
>>677
> そういうときはまず設計を改めたいものだ。
メッセージ作って他のスレッドに投げてそのスレッドがさらにまた…
ってな事はしないのか？
0680デフォルトの名無しさん2011/02/08(火) 14:14:39
スマポが嫌われるのは、多分
・どれを weak_ptr にするかでどうせ後々面倒が起こって、それじゃ delete 忘れ修正の手間と大差ない
・余分なメモリアロケーションが発生するのが嫌だ
のどちらかが大きいのではなかろうか。

参照カウンタではなくリンクリストで実装された侵入型ならどちらも回避できる。
が、リンクリストでの実装は参照カウンタに比べて遅いのだとか。


スマポが delete 忘れを解決するというが、たとえばコンストラクタで new したものを
delete する程度なら、調査追跡も楽だから、スワポなんて無くていい。

スワポがあると助かるのは、例えば、寿命の管理が面倒な場合など。
例えば、何らかのキューにオブジェクトを突っ込む必要があるような場合、突っ込んだ
側にとってはもう不要だが、キューから取り出す側はまだ delete されると困る、という
ような場合。

他には例えば、 Factory メソッドで生成するとか、new するオブジェクトと delete する
オブジェクトが違う場合などは、delete 忘れの追跡が面倒になることもあるから、スワポ
が便利。

スワポが必要になる状況が無いとか、ハンドルとかのスワポ以外の対策があるなら、
別に無理に使う必要は無い。


>>679
俺はスマポ反対ではないが、そういうときにリソースをやりとりして
誰の持ち物か分からなくなるようなのは行儀悪すぎるだろう。
0681デフォルトの名無しさん2011/02/08(火) 14:32:50
>>680
> ・どれを weak_ptr にするかでどうせ後々面倒が起こって、それじゃ delete 忘れ修正の手間と大差ない
> ・余分なメモリアロケーションが発生するのが嫌だ

なら std::auto_ptr や boost::scoped_ptr を使わない理由は無いな。

> スマポが delete 忘れを解決するというが、たとえばコンストラクタで new したものを
> delete する程度なら、調査追跡も楽だから、スワポなんて無くていい。

そのやりかただと代入やコピーコンストラクタや例外やその他いろいろ破綻する可能性が残る。

> スワポがあると助かるのは、例えば、寿命の管理が面倒な場合など。

スワポってなぁに？

> 俺はスマポ反対ではないが、そういうときにリソースをやりとりして
> 誰の持ち物か分からなくなるようなのは行儀悪すぎるだろう。

boost::scoped_ptr なら移動不可能な単一所有権。
std::auto_ptr (std::uniqe_ptr) なら移動可能な単一所有権。
boost::shared_ptr なら共有される所有権。

単一所有権なら誰の持ち物かは明白。
共有される所有権が誰の持ち物か分からなくなるのは、まぁ当然だよね。
0682デフォルトの名無しさん2011/02/08(火) 14:33:54
s/std::uniqe_ptr/std::unique_ptr/
0683デフォルトの名無しさん2011/02/08(火) 15:16:56
> 他には例えば、 Factory メソッドで生成するとか

createみたいなメソッドはもう格上げして、
使う側からしたら　(new, create) <--> delete
という扱いにすればその心配はないかも。

deleteの追跡とやらは、createを呼び出した側での話しになる。
0684デフォルトの名無しさん2011/02/08(火) 21:24:29
>>658
> なんせ未だにカラム制限のあるコーディング規約もあるくらいだ。
Linux カーネルとか *BSD とか Solaris とかのの話か?
06856802011/02/08(火) 23:55:19
>>681
> なら std::auto_ptr や boost::scoped_ptr を使わない理由は無いな。
scoped_ptr の類まで嫌う人たちがいるのかな？

> スワポってなぁに？
市況2板を見た後だったので FX 脳になってた。
0686デフォルトの名無しさん2011/02/09(水) 00:31:41
>>684
んにゃ、某大手家電メーカーの特定部署。1行80カラム以内で
コメントは(行単位でないなら)41カラムだかどこだかより前に出現してはいけない。
インデントも確か特殊だった記憶がある。
0687デフォルトの名無しさん2011/02/09(水) 10:18:54
あー、そういう環境じゃしょうがないよね。
0688デフォルトの名無しさん2011/02/13(日) 00:26:14
>>686
富士通みたいな所だな。
0689デフォルトの名無しさん2011/02/22(火) 12:38:52.11
某fj2で、携帯作ってるトコなんかだと
自動的にテスト仕様書を生成するために

//:　unkがmoreそうな場合はleaveする
　if (iUnk < iMore) {
　　User::Leave(EGodBlessYou);
　}

みたいに、「//:」を0カラム目にしてコメントを書け
という規定があるね
0690デフォルトの名無しさん2011/02/27(日) 23:18:33.78
プリプロセスの#includeとかが行頭にないとコンパイラがスルーしたことならあったな。
もう直ったのかshc
0691デフォルトの名無しさん2011/03/02(水) 16:28:45.71
20年くらい前かな
関数名のプリフィックスを2文字、機能単位で3文字、ユニークな部分を3文字に制限された
チームがあった
0692デフォルトの名無しさん2011/03/02(水) 20:36:20.17
うっせーバカ！現在進行形だ！
0693デフォルトの名無しさん2011/03/06(日) 19:22:45.45
今まさに、boostが使えない（or入れるのに手間がかかる）プロジェクトに居るんだが、
std::auto_ptrのみで、このスレで紹介されたような状況を対応する方法はあるのだろうか？
0694デフォルトの名無しさん2011/03/06(日) 19:35:04.41
>>693
コピーしたときの妙な特性さえ把握してれば普通に使える奴だよ std::auto_ptr は。
何が心配なの？
0695デフォルトの名無しさん2011/03/10(木) 22:21:32.27
>>694
すまん、書き方が悪かった。
一番聞きたかったのは、boost::sheard_ptrでないと解決できないような問題は存在する（多いのか）？
大抵の問題はstd::auto_ptrを駆使すれば問題を解決できるのか。

boost::sheard_ptrはboostが使える環境でないと使えない。（あたりまえだけど）
で、組込み系だと使えるライブラリが制限されていることは多いんで、
boostがあれば解決、だと、現実解にならない場面が多いのよ。
0696デフォルトの名無しさん2011/03/11(金) 00:39:48.77
仮に boostがあれば解決だったとして、
boostが使えない環境で boost::sheard_ptr 相当の、
あるいは必要な部分だけの機能を自作することは現実的ではないの？
0697デフォルトの名無しさん2011/03/11(金) 01:27:42.99
>>695
そんなもん、「作るものによる」としか言えないに決まってるじゃねーか。
心配している「状況」を挙げないと。
0698デフォルトの名無しさん2011/03/11(金) 19:06:21.02
>>695
スレ違い。
本を読んで自分で考えろ。その後まだ質問があれば、適切なスレで質問するといい。
0699デフォルトの名無しさん2011/03/20(日) 01:23:32.02
std::auto_ptr はコンテナ（vectorとか）との相性が悪い。
0700デフォルトの名無しさん2011/06/05(日) 05:34:53.68
横に長いソースはやめてください
フルHDのモニタでエディタ全画面表示にしてもラップするって酷いお
0701デフォルトの名無しさん2011/06/05(日) 06:57:16.18
フォントがでかすぎるんじゃねぇの?
0702デフォルトの名無しさん2011/06/06(月) 00:11:56.44
>>701
お前に俺の気持ちは分からない
0703デフォルトの名無しさん2011/06/06(月) 01:25:22.03
しらんがな
0704天使 ◆uL5esZLBSE 2011/07/03(日) 22:33:58.14
２０１１年、Ruby,Perl,PHP,Pythonって並べたときにさ
ここで、Ruby以外を選ぶ奴ってマジでなんなんだろうな


本当にバカだな
0705デフォルトの名無しさん2011/07/03(日) 23:46:31.28
巣に帰れ
0706デフォルトの名無しさん2011/09/17(土) 23:31:20.71
C++のコンストラクタ初期化子のインデントについて

CHoge() : hoge1(0), hoge2(0), hoge3(0), ...

この初期化子を1行1メンバで並べるときインデントはどうしてますか？
VS2008だと半角スペースが2つ入るんだけどMSはそういうスタイルなのかしら
0707デフォルトの名無しさん2011/09/18(日) 00:35:41.14
VS って自動で埋め込まれるインデントの
量（空白３つ分とか）をユーザーが設定することはできないの？
0708デフォルトの名無しさん2011/11/22(火) 12:56:04.40
どうなの？
0709デフォルトの名無しさん2011/11/22(火) 16:45:32.56
>>700
同意だわ。読みづらい。
最近は異常に識別名が長すぎるんだよな。
■ このスレッドは過去ログ倉庫に格納されています