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

**デフォルトの名無しさん** · 2007/10/28(日) 15:59:01

コーディングスタイルについて熱く語れ

**デフォルトの名無しさん** · 2010/03/06(土) 03:11:30

>>459
そういうもんかー。
内部遷移が複雑なロジックとかだと、中で余計な事しないよ的な意味で
constつけといた方が喜ばれるかと思ったけど、取っておくか。㌧クス。

>>460
>>452～>>455の流れで>>458に続く。
知識じゃなくて日本語の問題だなぁおいｗ

**デフォルトの名無しさん** · 2010/03/06(土) 03:20:03

>>461
なんで >459 へのレスが >456 へのレスと同じになるの？

**デフォルトの名無しさん** · 2010/03/06(土) 13:45:49

>>460
> const なめんな。

なんかカッコイイ発言だなｗ

**デフォルトの名無しさん** · 2010/03/06(土) 13:53:10

コンパイルエラーが出るからconst外しをするとか
コーディングスタイル以前の問題

**デフォルトの名無しさん** · 2010/03/06(土) 13:59:57

> 内部遷移が複雑なロジックとかだと、中で余計な事しないよ的な意味で

メンバ変数、しかもベクタ丸ごと外に晒そうなんて考える奴が言う台詞か？ｗ

**デフォルトの名無しさん** · 2010/03/06(土) 17:28:15

>>465
なるほど。サンプルが悪いと。
んでは誰か聞かせて欲しいんだけど

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

ってあり？なし？もしくは、これを実現する場合は
>>457のconst 版と非 const 版を作る。が最良？

**デフォルトの名無しさん** · 2010/03/06(土) 17:33:42

>>466
それって普通の「内部状態変更しないよ的な意味でのconst」と何が違うの？

**デフォルトの名無しさん** · 2010/03/06(土) 17:44:49

上の例だと、渡す時は内部状態を操作しないけど、戻り値は自己責任で自由に使ってね
それによって内部状態が変更されるよって言う場合。
std::vector<int> &GetVector() const;

**デフォルトの名無しさん** · 2010/03/06(土) 18:00:30

>>468
外部で自由に設定していいものを「内部状態」とは言わんだろうし、
それを反映してコードでもメンバ変数にするべきじゃないでしょ。
ってすでに >457 も >459 も言ってるんだけど、それについてはどう
なのさ？

**デフォルトの名無しさん** · 2010/03/07(日) 00:54:36

>>466
const tes ctes;
があったとき、ctes が変更されそうな操作をコンパイラがエラーにしてくれるのは素晴らしいことだ。
非 const メンバ関数を呼んだり、非 const ポインタ（や参照）への変換はもちろんエラーだ。
他に、オブジェクト内部の変数のアドレスを返すことについても、コンパイラは追跡してくれる。
非 const のアドレスを返すと、外から内部状態を変更されてしまうかも知れないから、わざわざチェック
してエラーにしてくれる。

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

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

そして const 版と非 const 版の両方が必要なら実装すればいい。

**デフォルトの名無しさん** · 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()

**デフォルトの名無しさん** · 2010/03/14(日) 17:08:09

セミコロンじゃなくてコロンだった

**デフォルトの名無しさん** · 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)
{
...
}

**デフォルトの名無しさん** · 2010/03/14(日) 18:31:09

やっぱコロン、カンマは後ろに持ってきたほうが見た目がいいよね
回答ありがとう

**デフォルトの名無しさん** · 2010/03/15(月) 08:29:36

俺は真逆で、コロンが前に来てないと落ち着かない
というより、前置か二項っぽい意味合いのものは、行頭に来るように置くのが普通
だと思うけどなぁ

**デフォルトの名無しさん** · 2010/03/15(月) 09:18:03

自分を中心に地球が回ってると考えるタイプの方ですね

**デフォルトの名無しさん** · 2010/03/15(月) 09:59:37

つーか、ある程度まともなコーディング基準で、>>475に反するものは見たことが無い
>>473に反するものは良く見る

もちろん、どこかには反対の例もあるかもしれんけど

**デフォルトの名無しさん** · 2010/03/15(月) 10:19:09

普通かどうかで言えば、コンマが後ろにくるのが普通だと思われているからこそ
enum 宣言や配列初期化子に余分なコンマがあっても許されるようになったのだろう。

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

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

コロンに関しては、元の英語での使い方が一対一や一対多の左側を明示するもの
なのだから、makefile やラベルのように後ろに付けるのが普通だろう。

**デフォルトの名無しさん** · 2010/03/15(月) 10:27:34

コロンは前、カンマは後ろ派

**デフォルトの名無しさん** · 2010/03/15(月) 10:29:51

訂正

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

つか、色々ソース見ても、>>471の1か2が普通じゃね？

**デフォルトの名無しさん** · 2010/03/15(月) 10:33:48

漏れ、改行しないんだけど

hoge::hoge(): foo(), bar(), baz()

**デフォルトの名無しさん** · 2010/03/15(月) 10:54:36

短いのはそれでいいんじゃね

**デフォルトの名無しさん** · 2010/03/15(月) 19:44:16

>>480
根拠を書かずに普通っていうと、476が出るぞ。

**デフォルトの名無しさん** · 2010/03/15(月) 22:10:50

>>483
いろんなソースをそれなりに見てる人なら大体同じように感じると思うけどな
統計でも取らなきゃ文句言われるってんなら知らん

**デフォルトの名無しさん** · 2010/03/16(火) 14:42:09

>>484
君の経験上普通なのは疑ってない。
君の経験を普通だとする根拠を求めている。

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

分類の抽象度は任せるが、いくつかを挙げて、
　「こういった分野では普通だ」
　「経験したこれとこれとこれの全ての分野で普通だ」
とするなら、ずっと説得力があるのではないだろうか。

**デフォルトの名無しさん** · 2010/03/16(火) 15:40:54

俺なら>>471の3。
この流儀に俺が行き着いたのは、SQLでクエリを書くようになってから。
文字列を*に置き換えて全体の形を表すと、

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

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

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

より、

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

がマシだという理屈。

**デフォルトの名無しさん** · 2010/03/16(火) 20:15:54

>>485
平たく言うと、普通○○なんじゃね、はこのスレでは絶対禁止ってことだな

**デフォルトの名無しさん** · 2010/03/16(火) 20:29:02

>>486
ちょっとわかる。
SQLで長いWHERE節を書いてると、
普通の言語以上になんかくどく感じる。

ただ、AND/ORは行頭にまとめた
ほうがいいのでは、と思いつつ、今は
まだ行末に書くようにしてる。

**デフォルトの名無しさん** · 2010/03/17(水) 00:10:58

漏れも3)派。
でも区切り記号ではなく演算子の場合は行末の方が優れている部分もあると思う。
例えば一次的に演算子を置き換えてみたい場合、↓みたいに書ける。

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

でもやっぱ3)が好き。

**デフォルトの名無しさん** · 2010/03/17(水) 00:40:35

ttp://codepad.org/nYNt4bQw

**デフォルトの名無しさん** · 2010/03/17(水) 20:09:46

>>487
学問カテと技術系板では、無限定の「普通」を使うべきではないと思う。
別に「普通」であることの証明を求めているわけじゃなくて、根拠を求めてるだけなんだけどね。

**デフォルトの名無しさん** · 2010/03/17(水) 23:51:51

>>491
俺は、技術系板では無限定の「普通」を使うべきではない、とは思わないな。
学問と技術なんざ別物だ。

**デフォルトの名無しさん** · 2010/03/19(金) 16:10:52

技術系の板で根拠の無い発言を当然とするのは残念だ。

**デフォルトの名無しさん** · 2010/03/19(金) 21:52:08

技術系じゃ完全な根拠を要求するのは不可能だろ

**デフォルトの名無しさん** · 2010/03/19(金) 22:07:52

ぶっちゃけ心理学とか社会学とかもかなり根拠曖昧なままやってるしな

**デフォルトの名無しさん** · 2010/03/21(日) 00:10:13

お前ら携帯か？流れ読めよ。

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

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

ハイゼンベルクの不確定性原理やらゲーデルの不完全性定理やらが定着した現在、そんな完全な証明なんて求めるわけが無い。
だがしかし、何かを主張する時に口からでまかせ言っていいことにはならないし、そうでないと説得すべく努力すべきだ。

**デフォルトの名無しさん** · 2010/03/21(日) 13:55:32

> 何かを主張する時に口からでまかせ言っていいことにはならないし

ならなくはないだろうｗ　好き勝手言えばいいし、それを止めるすべは無い。
ただ、それなりの根拠がないと相手にすらされないだけでｗ

**デフォルトの名無しさん** · 2010/04/03(土) 01:47:17

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

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

つかファウラーたんはなんて言ってるんだろう？

**デフォルトの名無しさん** · 2010/04/03(土) 11:20:33

それをマーチンファウラー式と呼ぶのは知らなかったｗ

**デフォルトの名無しさん** · 2010/04/03(土) 15:40:03

名前をアンスコで始めるのはやめたほうがいいんじゃね？
厳密に言うと _MyFunc とか C++言語の規定違反だったと思うけど。

ま、つけるなら public 以外全部だな。

**498** · 2010/04/04(日) 11:44:39

>>499
ファウラーたんが発祥らしい

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

**デフォルトの名無しさん** · 2010/04/04(日) 13:48:42

> C#とかは末尾にアンスコつけるらしいね
　　　　　　　　　　　　＿＿＿_
　　　　　　　　　　　／　　　　＼
　　　　　　　　　／　─　　 ─　＼
　　　　　　　　／　（●）　（●）　＼　　　
　　　　　　　　|　　　（__人__）　　　 |
　　　　　　　＼　　　｀ ⌒´ 　　 ,／
　r､　　　　r､／　　　　　　　　　　ヘ
　ヽヾ　三　|:l1　　　　　　　　　　　　ヽ
　　＼>ヽ/ |｀｝　　　　　　　　　　　|　|
　　　ﾍ　lノ `'ｿ　　　　　　　　　　　|　|
　　　　/´　 /　　　　　　　　　　　　 |.　|
　　　　＼. ｨ　　　　　　　　　　　|　 |
　　　　　 |　　　　　　　　　　　 | 　|

**デフォルトの名無しさん** · 2010/04/04(日) 14:50:07

あ、ごめん
末尾にアンスコもC++か

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

つけておくとコードみたらすぐわかるし、thisとかいらなくなるし、コード内で名前重複しづらくなるし、メソッドでも付けるぐらい気にいってるけど、最近は付けない風潮なのかなあ

**デフォルトの名無しさん** · 2010/04/04(日) 14:52:20

アンスコってアンダースコートの事かと思った

**デフォルトの名無しさん** · 2010/04/05(月) 00:18:23

>>500
_[A-Z].* と __[A-Z].* が処理系予約って話だろ?
処理系の解釈も OS 込みとか, 言語処理系単体とかあるみたいだな

**デフォルトの名無しさん** · 2010/04/05(月) 21:55:39

>>503
スコープを知りたくなること自体が、設計か実装が悪臭を放っている可能性を
示唆していると考える人は否定的になる。
プラグマチックに考えるなら、そのルールが有益になるチームはいくらでも
あるだろうと思う。

**デフォルトの名無しさん** · 2010/04/05(月) 22:27:28

だからといって敢えて削除するメリットがあるとも思えないし
混乱を深めるだけだと思う

**デフォルトの名無しさん** · 2010/04/05(月) 23:22:03

そうそう
付けないメリットより、付けるメリットの方が多い気がするんだよね

IDEが発達していらなくなるという主張も聞いた事あるけど、IDEだからこそ、一文字目からアンダースコアの有無による補完リストのフィルタリングとかできて便利だと思うんだが

**デフォルトの名無しさん** · 2010/04/05(月) 23:59:24

一文字目アンスコはC/C++で規格違反になると何度言えば（ry
見苦しかろうが m_ とかにすれ

**デフォルトの名無しさん** · 2010/04/06(火) 00:47:59

アンスコってアンインストールの事かと思った

**506** · 2010/04/06(火) 14:53:28

>>507
削除しろなんて言って無いし。

>>509
規格で予約されているのは、先頭のアンダースコアに続く大文字と、
出現位置を問わず二連続のアンダースコア。
先頭のアンダースコアに続いて小文字が現れるのは規格適合。

**デフォルトの名無しさん** · 2010/04/06(火) 21:13:10

正確には何らかのネームスペース内ではだな
グローバルネームスペースでは不適合

**デフォルトの名無しさん** · 2010/04/06(火) 21:14:49

メンバでは結局適合だけどね
ただ混乱を避けるために一律禁止した方が良い
よく知らない人が書いちゃうし

**デフォルトの名無しさん** · 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使うのが一番エレガントだと思うのだがどうよ

**デフォルトの名無しさん** · 2010/04/06(火) 23:05:32

REWINDは時々使う
REDOはほとんどcontinueで代用できる

**デフォルトの名無しさん** · 2010/04/06(火) 23:16:28

でも、i-- して continue; とか
i++ を最後に書いて continue; とか
何かキモくね？

**デフォルトの名無しさん** · 2010/04/07(水) 00:44:07

まぁ、continue や break も字面が違うだけで goto だからな。

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

ループの中で goto 使うときは while() で書いたほうが
気持ちの上では抵抗が少ないかな。

**デフォルトの名無しさん** · 2010/04/07(水) 01:06:20

>>514
REDO のほうは do ... while(...); のほうがよくないか？
REWIND はループを関数化して戻り値で分岐するかなぁ。

**デフォルトの名無しさん** · 2010/04/07(水) 08:16:11

for の再初期化式以外でループ変数を触るような場合は、
while か do で書くかな。
その goto REWIND はありだと思うけど。

**デフォルトの名無しさん** · 2010/04/07(水) 18:52:37

>>518
１カ所なら do-while でいいと思うけど
２カ所以上あったら面倒くさいと思う
redo のある言語もあるくらいだし、
その redo の代わりに goto 使うのはありじゃないかな

**デフォルトの名無しさん** · 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;
　}
　...
}

**デフォルトの名無しさん** · 2010/04/10(土) 08:15:27

きったねえソースだな

**デフォルトの名無しさん** · 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:

あんまり面白くなかった。。。

**デフォルトの名無しさん** · 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個スキップ
　　}

**デフォルトの名無しさん** · 2010/04/15(木) 17:17:58

>>524
毎回そのコメント書くんならいいんじゃない？
ただ、step=1 がレギュラーケースじゃない場合を考えて、step=1/*次へ*/ もループ中に書いたほうがいいと思うけど。
記述意図を明確にする意味なら、data や i を構造体にラップしてそれを操作する関数群を用意した方が良いだろう。

**デフォルトの名無しさん** · 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 を使う事に問題は無いと言える

**デフォルトの名無しさん** · 2010/04/15(木) 22:20:30

>>524
そこまで制御書くなら for じゃなくて while 使うなあ

**デフォルトの名無しさん** · 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行にしました。

**デフォルトの名無しさん** · 2010/04/16(金) 07:02:33

> 「公開しないコード書く時」あるいは「明示的に許可されてる」のでない限り
> gotoは使うべきじゃ無いと思うので。
ダイクストラも罪作りなことをしたもんだ。

**デフォルトの名無しさん** · 2010/04/16(金) 09:23:16

教条的にGOTOを排除しようとするのは80年代に蔓延したおかしな傾向だろ。
ダイクストラが言ったのは60年代末。

**デフォルトの名無しさん** · 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 の方が分かりやすいが

**デフォルトの名無しさん** · 2010/04/16(金) 21:39:42

REDOを多重ループにすると今度はbreakでループを抜けられない…
とか思ったけど、そんなレアケース考えてもしょうがないか

**デフォルトの名無しさん** · 2010/04/16(金) 21:46:21

複雑なら関数化も視野に入れていいんじゃない

**デフォルトの名無しさん** · 2010/04/16(金) 23:11:08

じゃC++0xのラムダ関数で

**525** · 2010/04/16(金) 23:44:09

>>528
もっと説明的なコードを書こうよ、って話。
Counter<int> i なんて名前じゃ曖昧になって当然。
CodeIterator currentCode(data, CodeIterator::Head);
if (...) currentCode.rewindToHead();
とかにしようよ。
先頭に巻き戻した後に、何が出力されるかどうかもないでしょ。先頭のだよ。

その構造は、中間言語処理や書式化文字列処理など、様々な場面で登場する。
その時々に相応しい構造と命名をしたら良い。

**デフォルトの名無しさん** · 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のが良いとは思いますが。

**デフォルトの名無しさん** · 2010/04/18(日) 13:35:59

追記。
ただ>531のredoは
　for (int i = 0; i < size; ++i) {
　　do {
　　　// 繰り返す処理
　　} while ( ... );
　}
と書くべきかと。フラグ要らんでしょ。

**デフォルトの名無しさん** · 2010/04/18(日) 13:57:59

本当は if は途中に出てきてるのだよ

**デフォルトの名無しさん** · 2010/04/18(日) 14:52:50

>538
>531
>if (...) { redo = true; continue; }
continueしとるで。

**デフォルトの名無しさん** · 2010/04/18(日) 18:10:11

こういうことだよ

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

**デフォルトの名無しさん** · 2010/04/18(日) 18:12:11

>>514の一つ目をdo while文で書いたときのフラグなしバージョン
for (...) {
　do {
　　...
　　if (...) continue;
　　...
　　break;
　} while(true);
}
まあ、redoはできても通常のcontinue、breakができなくなるけどね

**デフォルトの名無しさん** · 2010/04/18(日) 18:17:17

通常の意味でのcontinueはdo while文の中でbreakすればいいか
ややこしい…

**デフォルトの名無しさん** · 2010/04/18(日) 18:32:55

お前らおかしいぞ
普通に goto 使え

**デフォルトの名無しさん** · 2010/04/18(日) 19:51:37

飛び先を制御するためだけに
ループしない while を用意するのは邪悪

**デフォルトの名無しさん** · 2010/04/18(日) 21:16:50

普段gotoを使わないから>>514のようなケースのとき
gotoを使うってとこまで頭が働かないな

**デフォルトの名無しさん** · 2010/04/19(月) 08:13:33

無限ループは for (;;) {} で、ループしないループは do {} while (0) で、
というのはイディオム。

**デフォルトの名無しさん** · 2010/04/19(月) 19:25:34

do {} while (0); は continue しようが何しようが必ず抜けるから
continue した時はループする >>541 とは全く別の話だな

**デフォルトの名無しさん** · 2010/06/12(土) 22:46:29

>>514のコードを書き換えるという前提では、結局gotoを使うのが一番簡潔に
なるんだろうけど、実際のコーディングではケースバイケースで全然違う書き方を
すると思う。
いったん普通にループを抜けてからREWINDやREDOに相当する処理を別にするとか。

**デフォルトの名無しさん** · 2010/06/18(金) 01:39:17

最近言語に関係なくインデントにスペース2つを使うプロジェクトを
よく見る気がするんですが、これって元々どの辺の文化で使われていたんでしょうか？

**デフォルトの名無しさん** · 2010/06/18(金) 19:27:50

スクリプト言語じゃないかね

**デフォルトの名無しさん** · 2010/06/18(金) 19:50:49

GNU?

**デフォルトの名無しさん** · 2010/06/18(金) 23:54:30

ぐにゅ？

**デフォルトの名無しさん** · 2010/06/28(月) 10:51:33

>>549-552
2桁インデントはGNUスタイルだろ。
indentがインストールされている環境なら、indent -gnu <ソースファイル> でGNUスタイルに整形される。

**デフォルトの名無しさん** · 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;
}

**デフォルトの名無しさん** · 2010/06/28(月) 15:41:41

>>554
navi2chとかchalice使いでないと違いわからんだろ、これ

**デフォルトの名無しさん** · 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;
}

**デフォルトの名無しさん** · 2010/06/29(火) 22:32:49

>>555
ニョロカッコの位置と改行位置で分かるだろ?

**デフォルトの名無しさん** · 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.

**デフォルトの名無しさん** · 2010/12/12(日) 20:19:08

>>558
それを挙げて禁止とか言ったんなら、英語の読めない中途半端な経験者だったんだろう。
一般的な解説と、具体的なデメリットとを繋いで説明できればよかったのにね。

**デフォルトの名無しさん** · 2010/12/13(月) 02:21:42

キャッチボールで相手のレベルに合わせて投げるのと同じように、
コミュニケーションでも相手のレベルに合わせて伝えるべき。
子供相手に変化球投げたりしないだろ?

と、昔上司から言われた台詞を貴方にも。