探検
コーディングスタイルにこだわるスレ
■ このスレッドは過去ログ倉庫に格納されています
1デフォルトの名無しさん
2007/10/28(日) 15:59:01 コーディングスタイルについて熱く語れ
519デフォルトの名無しさん
2010/04/07(水) 08:16:11 for の再初期化式以外でループ変数を触るような場合は、
while か do で書くかな。
その goto REWIND はありだと思うけど。
while か do で書くかな。
その goto REWIND はありだと思うけど。
520デフォルトの名無しさん
2010/04/07(水) 18:52:37521デフォルトの名無しさん
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;
}
...
}
...
if( ... ) {
step=0; //REWND時は step=-i
continue;
}
...
}
522デフォルトの名無しさん
2010/04/10(土) 08:15:27 きったねえソースだな
523デフォルトの名無しさん
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:
あんまり面白くなかった。。。
start1:
i = 0;
start2:
...
if (!...) goto start3;
goto start1;
start3:
...
i++;
if (i >= n) goto end;
goto start2;
end:
あんまり面白くなかった。。。
524デフォルトの名無しさん
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個スキップ
}
●>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個スキップ
}
525デフォルトの名無しさん
2010/04/15(木) 17:17:58 >>524
毎回そのコメント書くんならいいんじゃない？
ただ、step=1 がレギュラーケースじゃない場合を考えて、step=1/*次へ*/ もループ中に書いたほうがいいと思うけど。
記述意図を明確にする意味なら、data や i を構造体にラップしてそれを操作する関数群を用意した方が良いだろう。
毎回そのコメント書くんならいいんじゃない？
ただ、step=1 がレギュラーケースじゃない場合を考えて、step=1/*次へ*/ もループ中に書いたほうがいいと思うけど。
記述意図を明確にする意味なら、data や i を構造体にラップしてそれを操作する関数群を用意した方が良いだろう。
526デフォルトの名無しさん
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 を使う事に問題は無いと言える
＞・ネストが無駄に深くならない。
goto 使った時とネストの深さに変化は無いし、
goto を使った方が if がすっきりする
＞・通常のfor文同様、ループ処理の肝となる処理が1行に集約されてる。
一行にたくさんの処理を詰め込んだだけで、分かり辛くなるだけ
goto だと単純な上に、ラベルにより意味も明解
＞・カウンタの更新タイミングが明確。
goto を使った方が分かりやすい
i+=step,step=1 なんて頭を使ってどういうコードか理解しないと分からない
＞・フローの制御方法が（比較的）単純明快。
step が途中で変わるのはとても分かり辛い
普通、そういう場合は for でカウンタを操作するのをやめて、
常に { } 内で直接カウンタを操作するようにする
そもそも、REDO や REWIND が必要なケースは稀であり、
そんな稀なケースに、より単純で明解な実装法があるにも関わらず、
複雑な技巧を凝らしたコードを仕込むのは得策ではない
goto が最も危険なのは、変数宣言を下に飛び越えたり、ブロック内に飛び込んだりする時だが、
REDO や REWIND はこの使い方には相当しない
飛ぶ位置はループ頭やループ前という極めて安全な位置のみであり、
かつ、どんな処理を行いたいのかが極めて分かりやすく、
goto を使う事に問題は無いと言える
527デフォルトの名無しさん
2010/04/15(木) 22:20:30 >>524
そこまで制御書くなら for じゃなくて while 使うなあ
そこまで制御書くなら for じゃなくて while 使うなあ
528デフォルトの名無しさん
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行にしました。
関数とかでラップしちゃうとカウンタの変化するタイミングとかが却ってわかり辛いと思うんですが。
例えば↓
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行にしました。
529デフォルトの名無しさん
2010/04/16(金) 07:02:33 > 「公開しないコード書く時」あるいは「明示的に許可されてる」のでない限り
> gotoは使うべきじゃ無いと思うので。
ダイクストラも罪作りなことをしたもんだ。
> gotoは使うべきじゃ無いと思うので。
ダイクストラも罪作りなことをしたもんだ。
530デフォルトの名無しさん
2010/04/16(金) 09:23:16 教条的にGOTOを排除しようとするのは80年代に蔓延したおかしな傾向だろ。
ダイクストラが言ったのは60年代末。
ダイクストラが言ったのは60年代末。
531デフォルトの名無しさん
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 の方が分かりやすいが
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 の方が分かりやすいが
532デフォルトの名無しさん
2010/04/16(金) 21:39:42 REDOを多重ループにすると今度はbreakでループを抜けられない…
とか思ったけど、そんなレアケース考えてもしょうがないか
とか思ったけど、そんなレアケース考えてもしょうがないか
533デフォルトの名無しさん
2010/04/16(金) 21:46:21 複雑なら関数化も視野に入れていいんじゃない
534デフォルトの名無しさん
2010/04/16(金) 23:11:08 じゃC++0xのラムダ関数で
535525
2010/04/16(金) 23:44:09 >>528
もっと説明的なコードを書こうよ、って話。
Counter<int> i なんて名前じゃ曖昧になって当然。
CodeIterator currentCode(data, CodeIterator::Head);
if (...) currentCode.rewindToHead();
とかにしようよ。
先頭に巻き戻した後に、何が出力されるかどうかもないでしょ。先頭のだよ。
その構造は、中間言語処理や書式化文字列処理など、様々な場面で登場する。
その時々に相応しい構造と命名をしたら良い。
もっと説明的なコードを書こうよ、って話。
Counter<int> i なんて名前じゃ曖昧になって当然。
CodeIterator currentCode(data, CodeIterator::Head);
if (...) currentCode.rewindToHead();
とかにしようよ。
先頭に巻き戻した後に、何が出力されるかどうかもないでしょ。先頭のだよ。
その構造は、中間言語処理や書式化文字列処理など、様々な場面で登場する。
その時々に相応しい構造と命名をしたら良い。
536デフォルトの名無しさん
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のが良いとは思いますが。
漏れはその書き方が一番無難だと思う。
goto使う方法はgotoの使用が許されるなら最善手だとは思うけど、
叩かれるのを覚悟して使うほどのメリットは無いと思う。
（叩かれるのを覚悟して>521を書いた奴が言う台詞じゃ無いけど）
>535
そこまで書くよりは、普通に↓と書く方が良いと思うけど。
for( int i=0; i<n; ++i ) {
if( ... ) i =-1; //最初から
}
ただこの例を見ても分かるように、カウンタを直接弄る方法は
「最初から」が何故-1なのか直感的に分かり辛い。
（>535みたいな書き方しても同様の問題が出てくる。）
だから>521。でもって↑も521も、下手に関数化するよりは
手の内を全て見せてしまった方が分かり易いと思われる。
まぁそこまでやるなら素直に>531のが良いとは思いますが。
537デフォルトの名無しさん
2010/04/18(日) 13:35:59 追記。
ただ>531のredoは
for (int i = 0; i < size; ++i) {
do {
// 繰り返す処理
} while ( ... );
}
と書くべきかと。フラグ要らんでしょ。
ただ>531のredoは
for (int i = 0; i < size; ++i) {
do {
// 繰り返す処理
} while ( ... );
}
と書くべきかと。フラグ要らんでしょ。
538デフォルトの名無しさん
2010/04/18(日) 13:57:59 本当は if は途中に出てきてるのだよ
539デフォルトの名無しさん
2010/04/18(日) 14:52:50 >538
>531
>if (...) { redo = true; continue; }
continueしとるで。
>531
>if (...) { redo = true; continue; }
continueしとるで。
540デフォルトの名無しさん
2010/04/18(日) 18:10:11 こういうことだよ
for (int i = 0; i < size; ++i) {
bool redo;
do {
redo = false;
...
if (...) { redo = true; continue; }
...
} while (redo);
}
for (int i = 0; i < size; ++i) {
bool redo;
do {
redo = false;
...
if (...) { redo = true; continue; }
...
} while (redo);
}
541デフォルトの名無しさん
2010/04/18(日) 18:12:11 >>514の一つ目をdo while文で書いたときのフラグなしバージョン
for (...) {
do {
...
if (...) continue;
...
break;
} while(true);
}
まあ、redoはできても通常のcontinue、breakができなくなるけどね
for (...) {
do {
...
if (...) continue;
...
break;
} while(true);
}
まあ、redoはできても通常のcontinue、breakができなくなるけどね
542デフォルトの名無しさん
2010/04/18(日) 18:17:17 通常の意味でのcontinueはdo while文の中でbreakすればいいか
ややこしい…
ややこしい…
543デフォルトの名無しさん
2010/04/18(日) 18:32:55 お前らおかしいぞ
普通に goto 使え
普通に goto 使え
544デフォルトの名無しさん
2010/04/18(日) 19:51:37 飛び先を制御するためだけに
ループしない while を用意するのは邪悪
ループしない while を用意するのは邪悪
545デフォルトの名無しさん
2010/04/18(日) 21:16:50 普段gotoを使わないから>>514のようなケースのとき
gotoを使うってとこまで頭が働かないな
gotoを使うってとこまで頭が働かないな
546デフォルトの名無しさん
2010/04/19(月) 08:13:33 無限ループは for (;;) {} で、ループしないループは do {} while (0) で、
というのはイディオム。
というのはイディオム。
547デフォルトの名無しさん
2010/04/19(月) 19:25:34 do {} while (0); は continue しようが何しようが必ず抜けるから
continue した時はループする >>541 とは全く別の話だな
continue した時はループする >>541 とは全く別の話だな
548デフォルトの名無しさん
2010/06/12(土) 22:46:29 >>514のコードを書き換えるという前提では、結局gotoを使うのが一番簡潔に
なるんだろうけど、実際のコーディングではケースバイケースで全然違う書き方を
すると思う。
いったん普通にループを抜けてからREWINDやREDOに相当する処理を別にするとか。
なるんだろうけど、実際のコーディングではケースバイケースで全然違う書き方を
すると思う。
いったん普通にループを抜けてからREWINDやREDOに相当する処理を別にするとか。
549デフォルトの名無しさん
2010/06/18(金) 01:39:17 最近言語に関係なくインデントにスペース2つを使うプロジェクトを
よく見る気がするんですが、これって元々どの辺の文化で使われていたんでしょうか？
よく見る気がするんですが、これって元々どの辺の文化で使われていたんでしょうか？
550デフォルトの名無しさん
2010/06/18(金) 19:27:50 スクリプト言語じゃないかね
551デフォルトの名無しさん
2010/06/18(金) 19:50:49 GNU?
552デフォルトの名無しさん
2010/06/18(金) 23:54:30 ぐにゅ？
553デフォルトの名無しさん
2010/06/28(月) 10:51:33554デフォルトの名無しさん
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;
}
::::::::::::::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;
}
555デフォルトの名無しさん
2010/06/28(月) 15:41:41 >>554
navi2chとかchalice使いでないと違いわからんだろ、これ
navi2chとかchalice使いでないと違いわからんだろ、これ
556デフォルトの名無しさん
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;
}
::::::::::::::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;
}
557デフォルトの名無しさん
2010/06/29(火) 22:32:49558デフォルトの名無しさん
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.
平気で 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.
559デフォルトの名無しさん
2010/12/12(日) 20:19:08560デフォルトの名無しさん
2010/12/13(月) 02:21:42 キャッチボールで相手のレベルに合わせて投げるのと同じように、
コミュニケーションでも相手のレベルに合わせて伝えるべき。
子供相手に変化球投げたりしないだろ?
と、昔上司から言われた台詞を貴方にも。
コミュニケーションでも相手のレベルに合わせて伝えるべき。
子供相手に変化球投げたりしないだろ?
と、昔上司から言われた台詞を貴方にも。
561デフォルトの名無しさん
2010/12/13(月) 03:09:28 >>559, 560
そのほかに指示したのは、「名前の長さは長くても20文字程度に押さえてね」だけで、
こっちは守られてるのに、「構造体の typedef 禁止」は無視するってのはおかしくないか？
一部の地域には構造体を typedef しなきゃいけない宗教的理由でもあるのか？
そのほかに指示したのは、「名前の長さは長くても20文字程度に押さえてね」だけで、
こっちは守られてるのに、「構造体の typedef 禁止」は無視するってのはおかしくないか？
一部の地域には構造体を typedef しなきゃいけない宗教的理由でもあるのか？
562デフォルトの名無しさん
2010/12/13(月) 03:53:23 >>561
少なくとも、妄信的にtypedefする奴はいる。
少なくとも、妄信的にtypedefする奴はいる。
563デフォルトの名無しさん
2010/12/13(月) 07:30:35 >>561
http://www.google.co.jp/search?q=%E5%85%A5%E9%96%80+typedef+struct
名前20文字以内が守れてるってのは、普通にやってればなかなかそこまで
長くならないってだけかもしれない。
http://www.google.co.jp/search?q=%E5%85%A5%E9%96%80+typedef+struct
名前20文字以内が守れてるってのは、普通にやってればなかなかそこまで
長くならないってだけかもしれない。
564デフォルトの名無しさん
2010/12/13(月) 22:03:37 妄信的に単語を短縮する奴もいる。
酷いのだと何でもかんでもアルファベット3文字とか。
特にCOBOLer上がり。
酷いのだと何でもかんでもアルファベット3文字とか。
特にCOBOLer上がり。
565デフォルトの名無しさん
2010/12/14(火) 00:18:34 H8環境でC++使ってないとtypedefだらけになる。
566デフォルトの名無しさん
2010/12/23(木) 22:21:26 >>558
そういうトラブルは typedef を禁止したところで
なくならないし未然防止にもならない。
そもそも言語に対するスキルというか
リテラシーが低いことが問題。
名前の長さも同じこと。 不思議な省略単語濫用で
20文字以内になっても意味がない。
そういうトラブルは typedef を禁止したところで
なくならないし未然防止にもならない。
そもそも言語に対するスキルというか
リテラシーが低いことが問題。
名前の長さも同じこと。 不思議な省略単語濫用で
20文字以内になっても意味がない。
567デフォルトの名無しさん
2010/12/23(木) 23:58:54568デフォルトの名無しさん
2010/12/24(金) 01:23:48 タグ名と typedef 名が同一ならよいのだから、そのくらいはヴァリデータツールを書いて、通らなければコミットできないようにしてしまえばよいのではないか。
569デフォルトの名無しさん
2010/12/24(金) 13:17:29570デフォルトの名無しさん
2010/12/26(日) 10:09:36 まぁ、下請けになめられてるんだろうな。
571デフォルトの名無しさん
2010/12/28(火) 19:29:32572デフォルトの名無しさん
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 のインクルードが
必要になる。
問題が３つだとしたら２つは残ってるように見える。
何か誤解されてるんじゃなかろうか？
"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 のインクルードが
必要になる。
問題が３つだとしたら２つは残ってるように見える。
何か誤解されてるんじゃなかろうか？
573デフォルトの名無しさん
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。
その理由で禁止なら、支持できるが、本当にこんなことを言ってたの？
コーディング規約にすることで未然に防ぎたい不具合の具体的な例をお願い。
> 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。
その理由で禁止なら、支持できるが、本当にこんなことを言ってたの？
574デフォルトの名無しさん
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; と書いたとしたら、
それらのヘッダをひとつの翻訳単位にインクルードすればやっぱりエラーになるだろ。
> 手元の三つのコンパイラでコンパイルでき、警告さえ出さない。
どんなコードでテストしてるの？
> というわけで、こちらも前方宣言で済ませることができる。
> ただし typedef struct A A; の一行が余分に必要になる。
...
> typedef struct A A;
> typedef struct A { int a; } A;
> とあると、後者でエラーになるということか。
前方宣言のつもりで複数のヘッダに typedef struct A A; と書いたとしたら、
それらのヘッダをひとつの翻訳単位にインクルードすればやっぱりエラーになるだろ。
575デフォルトの名無しさん
2010/12/30(木) 02:33:59 C禁止にしてC++に統合しようぜ。
576デフォルトの名無しさん
2010/12/30(木) 07:16:23 そんな事したらリーナスおじさんが黙っていない
577デフォルトの名無しさん
2010/12/30(木) 11:06:58 俺もOOPは大好きだが、
OOPLとしてのC++にも感謝してるが、
どっちか無くせといわれたら、C++がイランなｗ
Cは必要だな。
OOPLとしてのC++にも感謝してるが、
どっちか無くせといわれたら、C++がイランなｗ
Cは必要だな。
578デフォルトの名無しさん
2010/12/30(木) 15:26:15 >>573
> もちろん C++ ならどれも ok。
C++ でも微妙だったりする。
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#407
> もちろん C++ ならどれも ok。
C++ でも微妙だったりする。
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#407
579デフォルトの名無しさん
2010/12/30(木) 23:31:39 揚げ足取りならC++ならC的な書き方もできるがね。
とはいえ組み込み系だと環境構築してる間に開発期間がなくなる勢いだから
トップダウンでCを減らして欲しい。ボトムアップじゃムリポ。
とはいえ組み込み系だと環境構築してる間に開発期間がなくなる勢いだから
トップダウンでCを減らして欲しい。ボトムアップじゃムリポ。
580デフォルトの名無しさん
2010/12/31(金) 09:26:49581デフォルトの名無しさん
2011/01/01(土) 01:27:35 逆に、constなんかはCよりC++の仕様のほうが組込にも向いているように思う。
自分の知り合いは、テンプレートは使う（もちろんコードサイズ増加は織り込み済み）が、
それよりも動的メモリ確保(malloc/new等)禁止のほうを気にかけている感じだった。
これももちろん分野によるのだろうけど。
自分の知り合いは、テンプレートは使う（もちろんコードサイズ増加は織り込み済み）が、
それよりも動的メモリ確保(malloc/new等)禁止のほうを気にかけている感じだった。
これももちろん分野によるのだろうけど。
582デフォルトの名無しさん
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)
文;
何をあほな書き方してんだと思うかいな。
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)
文;
583デフォルトの名無しさん
2011/01/01(土) 11:57:47 え？ 折角変数使うのにnum2みたいな糞名前？
そんなんつけるくらいなら
int ret = MessageBox(pc1, pc2, utype);
if (ret == IDYES)
こうするほうがまだマシでは？
else if (ret == IDCANCEL)などと続けられることも考えて。
そんなんつけるくらいなら
int ret = MessageBox(pc1, pc2, utype);
if (ret == IDYES)
こうするほうがまだマシでは？
else if (ret == IDCANCEL)などと続けられることも考えて。
584デフォルトの名無しさん
2011/01/03(月) 13:24:29 >>580
ハード性能の貧弱さで C++ が使えなくなるなんてことはないよ。
例外、 RTTI 、テンプレートとか、機能や具体的な使い方に応じて
費用対効果が見合わないことはあるだろうけどね。
でもそれは組み込みにかかわらずあたりまえの話。
マイナーすぎてコンパイラが無いっていう方向の貧弱さを言ってるんだったら別。
ハード性能の貧弱さで C++ が使えなくなるなんてことはないよ。
例外、 RTTI 、テンプレートとか、機能や具体的な使い方に応じて
費用対効果が見合わないことはあるだろうけどね。
でもそれは組み込みにかかわらずあたりまえの話。
マイナーすぎてコンパイラが無いっていう方向の貧弱さを言ってるんだったら別。
585デフォルトの名無しさん
2011/01/03(月) 14:07:45 >>584 主記憶64kでやってみろよ
586デフォルトの名無しさん
2011/01/03(月) 14:46:28 >>585 別に問題ありませんが何か？
587デフォルトの名無しさん
2011/01/03(月) 22:32:32 >>585
むしろその環境に対して C++ の何が問題を起こすと思っているのか聞きたい。
むしろその環境に対して C++ の何が問題を起こすと思っているのか聞きたい。
588デフォルトの名無しさん
2011/01/11(火) 01:09:09 C++ が問題というよりは、組み込みでテンプレとか
ガンガン使っておいて ROM/RAM 足りませんみたいな
こと言ってくる奴が多すぎて困る。
バグったらバグったで自分じゃ解析できないから
ヘルプミーだと。 C++禁止にしようぜ。
ガンガン使っておいて ROM/RAM 足りませんみたいな
こと言ってくる奴が多すぎて困る。
バグったらバグったで自分じゃ解析できないから
ヘルプミーだと。 C++禁止にしようぜ。
589デフォルトの名無しさん
2011/01/11(火) 23:44:50 テンプレ禁止しろよ
590デフォルトの名無しさん
2011/01/12(水) 10:53:19 テンプレってリソース喰うん？
591デフォルトの名無しさん
2011/01/12(水) 11:49:57 >>590 いいえ
592デフォルトの名無しさん
2011/01/12(水) 12:12:04 リソースを食うコードを書いてしまいやすいと言うべきかな
593デフォルトの名無しさん
2011/01/12(水) 12:22:45 なにこのほほえましいスレ。
594デフォルトの名無しさん
2011/01/12(水) 18:43:10 >>588
禁止というか免許制にすればいいのにとは思う
禁止というか免許制にすればいいのにとは思う
595デフォルトの名無しさん
2011/01/12(水) 20:08:48596デフォルトの名無しさん
2011/01/24(月) 02:34:22 Javaで使い終わった変数にnullセットとか意味あんの？
ゴスリングも、今のGCは賢いからそんなことせんでええと言っているし、
そもそもスタイルとして美しくないので嫌いなんだが。
あと、宣言時のnullセットも同じく。
ここの先輩諸氏はどう思われますか。
ゴスリングも、今のGCは賢いからそんなことせんでええと言っているし、
そもそもスタイルとして美しくないので嫌いなんだが。
あと、宣言時のnullセットも同じく。
ここの先輩諸氏はどう思われますか。
597デフォルトの名無しさん
2011/01/24(月) 03:50:41 宣言時のnullセットは意味が無いな
598デフォルトの名無しさん
2011/01/24(月) 09:14:31 インスタンス変数で、null代入しないとオブジェクトリークになる、
というのでもない限りいらんだろ。
というのでもない限りいらんだろ。
599デフォルトの名無しさん
2011/01/24(月) 09:17:46 GC目的のつもりの代入に限って言えば、
それを強いるなど狂気の沙汰だ。
それを強いるなど狂気の沙汰だ。
600デフォルトの名無しさん
2011/01/24(月) 10:34:58 生存時間の長いローカル変数に対して、時間がかかる処理の前にnull代入するのは意味がないこともないよ
GCの世代昇格を防いだり
GCの世代昇格を防いだり
601デフォルトの名無しさん
2011/01/24(月) 11:02:17 >そもそもスタイルとして美しくないので嫌いなんだが。
なぜそう思う？
なぜそう思う？
602デフォルトの名無しさん
2011/01/24(月) 22:59:59 >>596
VB出身者が必要だと思ってるんだろ。それ。
VB出身者が必要だと思ってるんだろ。それ。
603デフォルトの名無しさん
2011/01/24(月) 23:02:00 使い終わった変数にnullを入れると安全になるって思い込んでるヤツは
よくみるな。
それで安全になるようなコードの書き方をしてるなら、そっちを見直すべき
なんだけど。
よくみるな。
それで安全になるようなコードの書き方をしてるなら、そっちを見直すべき
なんだけど。
604デフォルトの名無しさん
2011/01/29(土) 15:50:46 C++なら新人に多重deleteされないようにdeleteし終わったらNULL入れておくかな。
C++はNULLのdeleteは「何もしない」のが仕様として決まっているから。
無条件deleteでも問題ない話になる。
C++はNULLのdeleteは「何もしない」のが仕様として決まっているから。
無条件deleteでも問題ない話になる。
605デフォルトの名無しさん
2011/01/29(土) 17:09:13 コーディングルールの話をしてて、それはダメだってことになると、
「これはヘタクソには有効だ」って反論がでてくるけど、ヘタクソ向けの
コーディングルールなんていらないよな。
だいたいヘタクソに対しても別に有効じゃねえだろって感じだし。
「これはヘタクソには有効だ」って反論がでてくるけど、ヘタクソ向けの
コーディングルールなんていらないよな。
だいたいヘタクソに対しても別に有効じゃねえだろって感じだし。
606デフォルトの名無しさん
2011/01/29(土) 19:15:53 よう俺。
デメリットを指摘しても「でも僕はこっちの方がいいです。慣れですよ」とか言われるし。
デメリットを指摘しても「でも僕はこっちの方がいいです。慣れですよ」とか言われるし。
607デフォルトの名無しさん
2011/01/29(土) 20:13:55 個人でプログラムしてるのなら、
周りの人間がそいつのコーディングスタイルをどうのこうの言っても意味が無い
好みの問題に他人が口出しするものではない
が、チームを組んでプログラムしてたり、
そいつのソースを将来別の誰かがメンテしたりするのなら、
コーディングスタイルを合わせるよう「命令」しないといけない
デメリットやメリットは無意味で、問答無用で「命令」だ
周りの人間がそいつのコーディングスタイルをどうのこうの言っても意味が無い
好みの問題に他人が口出しするものではない
が、チームを組んでプログラムしてたり、
そいつのソースを将来別の誰かがメンテしたりするのなら、
コーディングスタイルを合わせるよう「命令」しないといけない
デメリットやメリットは無意味で、問答無用で「命令」だ
608デフォルトの名無しさん
2011/01/29(土) 20:37:06 もしかして:スレ違い
609デフォルトの名無しさん
2011/01/29(土) 20:38:07 ヘタクソにコーディングルールを強いると、生産性が落ちてバグが増えそうで怖い。
なのでヘタクソのコーディングルールに合わせるのです。
なのでヘタクソのコーディングルールに合わせるのです。
610デフォルトの名無しさん
2011/01/29(土) 20:54:06 >>609
> 生産性が落ちてバグが増えそうで怖い
見えないものを怖がるな
どのようなヘタクソに、どのようなコーディングルールを強いた場合、
生産性がどれくらい落ちて、バグがどれくらい増えるのか、ちゃんと検証すればいい
検証の結果、本当は逆に生産性が上がってバグが減るのかも知れない
> 生産性が落ちてバグが増えそうで怖い
見えないものを怖がるな
どのようなヘタクソに、どのようなコーディングルールを強いた場合、
生産性がどれくらい落ちて、バグがどれくらい増えるのか、ちゃんと検証すればいい
検証の結果、本当は逆に生産性が上がってバグが減るのかも知れない
611デフォルトの名無しさん
2011/01/29(土) 21:51:55612デフォルトの名無しさん
2011/01/30(日) 01:19:42 >611
>最低でもauto_ptr
そしてコンテナでハマると。
>609,610
バカをフォローする手間を省くためだと思う。
ルールを決めるに当たって
・バカでも憶えやすい・理解しやすい
・特定の条件下では最も無難
・機械的にチェックしやすい
に傾きがちなのもきっとそのせい。
>最低でもauto_ptr
そしてコンテナでハマると。
>609,610
バカをフォローする手間を省くためだと思う。
ルールを決めるに当たって
・バカでも憶えやすい・理解しやすい
・特定の条件下では最も無難
・機械的にチェックしやすい
に傾きがちなのもきっとそのせい。
613デフォルトの名無しさん
2011/01/30(日) 02:32:19 昔は馬鹿を育てたんだけどな
俺も育てられたし
俺も育てられたし
614デフォルトの名無しさん
2011/01/30(日) 15:27:32 ポインタをnullクリアより、変数のスコープを小さくしましょうとか、
使い回しをやめろとか教えたほうがいいだろ。
ポインタをnullクリアって、バグがおきないとかバグを発見しやすくする
工夫じゃなくて、バグってもなんとなく動いちゃう工夫だし。
あと上から目線で馬鹿向けって言ってるけど、使い終わったポインタを
NULLクリアするって言ってるやつって、馬鹿向けじゃなくて本気でそれ
がいいって思ってるっぽいし。
使い回しをやめろとか教えたほうがいいだろ。
ポインタをnullクリアって、バグがおきないとかバグを発見しやすくする
工夫じゃなくて、バグってもなんとなく動いちゃう工夫だし。
あと上から目線で馬鹿向けって言ってるけど、使い終わったポインタを
NULLクリアするって言ってるやつって、馬鹿向けじゃなくて本気でそれ
がいいって思ってるっぽいし。
615デフォルトの名無しさん
2011/01/30(日) 15:38:08 スタイルというより教育だな。
616デフォルトの名無しさん
2011/01/30(日) 15:49:28 ある程度熟達すればコーディングスタイルにほとんどばらつきが出ない Lisp 系は、
コーディングスタイルという点ではけっこういい言語かも知れない
コーディングスタイルという点ではけっこういい言語かも知れない
617デフォルトの名無しさん
2011/01/30(日) 15:51:29 馬鹿の度合いにもよるけどな。
とにかくいじらせるコード量を減らすこと。
今はそれで対処できるのでそうしてる。
教育できそうな馬鹿っていいよね。
うらやましいよ。
こっちの馬鹿は英単語すら読めねえんだぜ。
だから当然エラーメッセージもw
とにかくいじらせるコード量を減らすこと。
今はそれで対処できるのでそうしてる。
教育できそうな馬鹿っていいよね。
うらやましいよ。
こっちの馬鹿は英単語すら読めねえんだぜ。
だから当然エラーメッセージもw
618デフォルトの名無しさん
2011/01/30(日) 15:54:38■ このスレッドは過去ログ倉庫に格納されています
ニュース
- 【日本人の旅行離れ】国内旅行すら行けなくなった……オーバーツーリズムだけじゃない 旅行者減少の異常事態 [ぐれ★]
- 高市首相の答弁書に「台湾有事答えない」と明記 存立危機発言当時 ★12 [蚤の市★]
- 中国の渡航自粛要請1カ月 大阪の観光バス予約ゼロ、東北にも波及 [蚤の市★]
- 【神戸】エレベーター「かご」なく男性医師が転落死 大手「三菱電機ビルソリューションズ」の担当者、安全装置切り放置か [ぐれ★]
- 【福岡】「人が道路に寝込んでいた。顔面から出血し、うなり声をあげている」 福岡市中央区で男性はねられ死亡 タクシー運転手逮捕 [ぐれ★]
- 女性天皇「賛成」69%、将来の皇位継承「不安」68%…読売世論調査 [蚤の市★]
- 高市、メガソーラー廃止。環境破壊が社会問題化 [792147417]
- クリスマスに何かする「予定なし」は54％。 過去最高水準に。ケーキの値上げもあって節約志向へ [663766621]
- 他人のリクエストで自分の癖と異なる絵を上げる絵師いるじゃん？
- 🏡おい！返事しろ︎︎！知的障害者！
- 日本人がホルホルの対象にしている生物、海外にも生息すると判明 [603416639]
- キミプリ→ゼッツ→ゴジュウ→猥談