04/10/02 12:28:23
C言語、C++言語のコーディングスタイルについて
クールに語るスレッドです
2:デフォルトの名無しさん
04/10/02 12:32:32
特にこれから学習する人は、まだ独自の癖が付く前に
ｺﾞﾗｧされにくいコーディングスタイルを身につけましょう
3:デフォルトの名無しさん
04/10/02 12:41:43
#include <2c.h>
main(){
return 0;
}
4:デフォルトの名無しさん
04/10/02 12:44:41
int count, temp, data;
カンマの後にスペースを置き、空白の美を堪能する
if (foo > 10){
if, whileの直後もスペース推奨。関数との差別化を図る
5:デフォルトの名無しさん
04/10/02 12:53:32
if (...)
{
}
else
{
}
と書く奴はキモイ
6:デフォルトの名無しさん
04/10/02 12:58:03
>>4
int count, temp, data;
これは以下のようにするように推奨しているけど少数派かね。
int count= 0; //変数の意味を記述
int temp = 0;
int data = 0;
理由は、編集のし易と
int *a,b;とあったときにbをポインタと勘違いするミスを防ぐため。
7:デフォルトの名無しさん
04/10/02 12:58:19
if (...) {
} else if (...) {
} else {
}
クール。グルービー
8:デフォルトの名無しさん
04/10/02 13:26:35
if (...)
{ // ここにコメント
}
else
{ // ここにコメント
}
9:デフォルトの名無しさん
04/10/02 13:32:21
>>6
私もそのようにすることを推奨している。
10:デフォルトの名無しさん
04/10/02 13:32:50
>>6
ちなみに、ポインタは
int *a;
よりも
int* a;
を推奨している。
11:デフォルトの名無しさん
04/10/02 13:36:22
>>10
変数宣言構文の意味を勉強してから出直しな。
12:デフォルトの名無しさん
04/10/02 13:36:51
>>10
へ？ なんで？
13:デフォルトの名無しさん
04/10/02 13:37:03
>>11
出直すのは君の方ね。
14:デフォルトの名無しさん
04/10/02 13:37:50
if( ){
}
else if( ){
}
else{
}
これ、知ってからずっと愛用。
カッコの対応関係が見やすい。
15:デフォルトの名無しさん
04/10/02 13:38:05
まさか
int *a;
で、aの型は？って聞かれたらint型だなんて言わないよね。
16:デフォルトの名無しさん
04/10/02 13:45:11
if () {
hoge; // 詰まってて見にくい
}
if () {
// 空いてて見にくい
hoge();
}
if ()
{
hoge(); // 安心
}
17:デフォルトの名無しさん
04/10/02 13:48:44
>>10
そういうやつがいるから
int* a,b;
のbをポインタだと勘違いするやつが出てくるんだよ・・・
18:デフォルトの名無しさん
04/10/02 13:52:41
>>17
だから、
int a, b, c;
という書き方はせず、
int a;
int b;
int c;
という風に書くというルールの下、
int* a;
int* b;
int* c;
という風に全て書けばaが何型か明記したことになる。
int *a;
int *b;
int *c;
という書き方はaが何型か明記していない。
ちなみに、このルールから言うと、
int* a,b;
という書き方は許されないから、間違うことはない。
19:デフォルトの名無しさん
04/10/02 13:54:24
int*a
は a が int* 型だという意味ではなく
*a が int 型だということは理解してる？
20:デフォルトの名無しさん
04/10/02 13:57:32
>>19
それは理解しているが、ポインタは用途が違う事が多いので、
扱いを変える必要がある。
ゆえに明記する。
21:デフォルトの名無しさん
04/10/02 14:12:13
>>18
そのルールを守っているプロジェクト内ではそれで完結できるが、
そいつが別のルールの(一行で複数宣言を許す)プロジェクトに移ったとき、
17みたいのを見て勘違いしないか？
文法を理解してないそいつが120%悪いが、世の中出来るやつばかりじゃないからな・・・。
22:デフォルトの名無しさん
04/10/02 14:16:31
>>21
もちろん、int* a;のような記述もコーディングルールの一部だから、
別のルールに従う必要があるときはそのルールに従うべきだよ。
int *a;と書かないといけないルールだったらそうすればよい。
23:デフォルトの名無しさん
04/10/02 14:18:32
勘違いしててもコンパイラの型チェックで引っかかるんで気づくんじゃない？
引っかからないようなコンパイラ使ってるプロジェクトなら、それこそ「アホはコード触るな」で。
24:デフォルトの名無しさん
04/10/02 14:19:49
だれかemacs用の2chスタイルを定義してください。
25:デフォルトの名無しさん
04/10/02 14:22:41
>>16
でも、そんなお前でもループは
while(1){
}
とか
for(;;){
}
だろ？
26:デフォルトの名無しさん
04/10/02 14:27:48
if ( hoge ) {
;
} else {
;
}
27:デフォルトの名無しさん
04/10/02 14:28:28
>>25
ときどきスペース空けてくれ
28:デフォルトの名無しさん
04/10/02 14:29:30
っていうか、これに従え
URLﾘﾝｸ(www.sra.co.jp)
29:デフォルトの名無しさん
04/10/02 14:34:38
俺も昔は>>8派だったけど、コードコンプリート読んでからぶらさがり型に変えたよ。
30:デフォルトの名無しさん
04/10/02 14:50:52
>>25
Java では if や while もそう書いてるが
C++ では全部>>16
31:デフォルトの名無しさん
04/10/02 16:12:35
for (int i=1; i<10; i++)
1+2-3*4/5
↑
どっちが見やすいですか？
↓
for (int i = 1; i < 10; i++)
1 + 2 - 3 * 4 / 5
32:デフォルトの名無しさん
04/10/02 16:19:08
>>31
for (int i=1; i<10; i++) 1+2-3*4/5 ;
33:デフォルトの名無しさん
04/10/02 16:20:05
>>31
後者
34:デフォルトの名無しさん
04/10/02 16:23:07
>>31
+ - の前後はスペース入れる
* / の前後は入れない。
35:デフォルトの名無しさん
04/10/02 16:25:45
>>34
それいいな
36:デフォルトの名無しさん
04/10/02 16:27:54
for ( int i = 1; i < 10; i ++ ) 1 + 2 - 3*4/5;
37:デフォルトの名無しさん
04/10/02 16:30:45
f(void)
f()
どっち？
Cでは意味が異なるんだっけ。
C++限定で。
38:10の主治医
04/10/02 16:32:58
10=18は重度な精神疾患です
以下処方箋
int* aでもかまわないのですが
int* a, b, c;
とか書かれるとその人はbやcもint*型と誤解しているのでは？と悪い印象をあたえます
素直に
int *a, b, c;
と書きなさい
39:デフォルトの名無しさん
04/10/02 16:37:05
宣言数が少ないならそれでいいけど、その他変数とポインタ変数とは使い道が
違うので、結果的に分けて宣言することが多くなると思う。
ただポインタは全部分けて書くっていうのはちょっとわからん。
> ｽﾚﾘﾝｸ(tech板:971番)
40:デフォルトの名無しさん
04/10/02 16:39:34
C++だと変数は必要になったタイミングで宣言できるから、
複数まとめて宣言する必要が無いんだよな。
41:デフォルトの名無しさん
04/10/02 16:41:29
Cだってブロック作ればどこにだって宣言できるもん！
42:デフォルトの名無しさん
04/10/02 16:42:12
>>38
全く直されるいわれはない。
これはスタイルの問題であり、開発者がコード見た時により見やすくするためのもの。
一行ごとに一つの変数を定義するというあらかじめ定義されたルールがある以上、
int *a,b,c;
なんていう書き方は許さないのだから、当然
int* a,b,c;
などとは書けない。
と何度も同じ事を書かないといけないのか？
int *a;なんていう書き方の方が全然素直ではない。
int型のポインタとint型を同じ行で定義するのは意味的に良くない。
43:デフォルトの名無しさん
04/10/02 16:43:17
↑ヴァカ？
44:デフォルトの名無しさん
04/10/02 16:45:23
＞結果的に分けて宣言する
＞int型のポインタとint型を同じ行で定義するのは意味的に良くない
まあ要するにこういうことだわな。
たまたま出来るからやりたければやればいいんじゃないのという。
45:デフォルトの名無しさん
04/10/02 16:46:53
int a, b, c;
と宣言しておいて
aは使う段階になったら
*(int *)a
とする
これで完璧
46:600
04/10/02 16:46:55
int *a = NULL;
*a がintなのにNULLで初期化というのも妙だしな。
int* a = NULL;
ならばしっくりくる。
47:デフォルトの名無しさん
04/10/02 16:47:55
>>44
>>42と>>39をいっしょにするなよ
>>39はポインタ変数の役割が他のIntと違うから別個に宣言すると言ってるだけ
>>42のほうは int と int* が別物だと考えている
48:デフォルトの名無しさん
04/10/02 16:49:02
>>47
全く理解できない
それより、病院いけ？
49:デフォルトの名無しさん
04/10/02 16:50:55
46=47
そんな理解でC/C++使わないでくれ
50:600
04/10/02 16:51:52
>>49
>46=47
そんな理解でレスしないでくれ
51:デフォルトの名無しさん
04/10/02 16:56:47
とりあえず >>43,48,49 はトリップつけてよ。
面倒だから。
52:デフォルトの名無しさん
04/10/02 17:00:32
>>int* a;
えー？！
じゃ、関数ポインタは
int(*) a(void) = NULL;
って書くんですか？
53:デフォルトの名無しさん
04/10/02 17:04:37
「変数名」と「他のもの」は離して書くよ。
関数ポインタならこうする
int (* fncptr)(void) = NULL;
54:デフォルトの名無しさん
04/10/02 17:09:08
>>53
> 「変数名」と「他のもの」は離して書くよ。
じゃあ
int * a;
って書けばいいんじゃない？
55:デフォルトの名無しさん
04/10/02 17:11:54
CとC++ならスタイルも変わってくると思う
Cなら
int *a, *b, *c;
C++なら使うときにひとつずつ
int* a = new int(hoge);
56:デフォルトの名無しさん
04/10/02 17:18:18
>>50
で、君はどこスレの600?
57:デフォルトの名無しさん
04/10/02 17:25:22
>>56
バカ、このスレの未来から来たんだよ。
58:デフォルトの名無しさん
04/10/02 17:28:33
もしかしてドライもんのおともだちだったりするんだ…
59:デフォルトの名無しさん
04/10/02 18:39:00
int a = val; を
int a; と a = val; を一緒にした書き方の延長線上で見てしまうと、
int *a = ptr; が
int *a; と *a = ptr; では、辻褄が合わなくなるので、
int* a = ptr; と書くようにすることで、
int* a; と a = ptr; が 最初のと同様の見方が出来るからじゃないの？
宣言時の *a と 代入時の *a では
括弧を省略できるため見た目同じでも
意味するところは異なるのが原因だと思うけど...
代入時は *(a) とでもする？
60:デフォルトの名無しさん
04/10/02 18:51:41
int* a, b, c;
61:デフォルトの名無しさん
04/10/02 18:59:02
>>59
>宣言時の *a と 代入時の *a では
>括弧を省略できるため見た目同じでも
>意味するところは異なるのが原因だと思うけど...
アフォ。
ではこれをどう説明するんだよ。
int a[] = {123, 345, 567};
62:デフォルトの名無しさん
04/10/02 19:35:01
今時int *aなんて書いてるのはおっさんCプログラマでしょ。
C++の勉強のためにWebでいろんなコード見てきたけど、ほとんどint* aだよ。
参照もint &aなんて書いてるのかな？
63:デフォルトの名無しさん
04/10/02 19:59:00
昔はint* aだったけど最近はint *aにするようにしてる
昔は単純なプログラムしか組めなかったからどっちでもよかったけど
constとか関数ポインタ、多重ポインタとか使うようになるとint *aのほうが都合がよくなる
64:デフォルトの名無しさん
04/10/02 20:54:19
int * a;
最強。
65:デフォルトの名無しさん
04/10/02 20:58:59
const int*と int const*って違いがよく分からん
66:デフォルトの名無しさん
04/10/02 21:12:49
a[b]とb[a]の違いみたいなもんだ。
俺はint constだけど、世間一般ではconst intのほうが主流かな。
67:デフォルトの名無しさん
04/10/02 21:31:14
constの位置が違うと全然違う意味だから
68:デフォルトの名無しさん
04/10/02 21:34:13
>>67
（ ・∀・）ﾆﾔﾆﾔ
69:デフォルトの名無しさん
04/10/02 21:41:47
char *const
char const*
70:デフォルトの名無しさん
04/10/02 21:42:38
最強は
char const * const
71:デフォルトの名無しさん
04/10/02 21:44:38
最強はvoid const*だろ
72:デフォルトの名無しさん
04/10/02 21:48:03
int *a,b,c;
決定
73:デフォルトの名無しさん
04/10/02 22:59:11
>>70
> 最強は
> char const * const
だな。const char * const だと、どうしてよ？って思っちゃうし。
74:デフォルトの名無しさん
04/10/03 01:04:37
突然ですが、三項演算子
(cond)
? foo
: bar;
です。ハテナとコロンは揃えます。
いじょ。
75:デフォルトの名無しさん
04/10/03 01:08:22
3項演算子って結局はif文と同じコンパイル結果になるから、一行で書かないなら
if文で書いた方がわかりやすいと思う。
3項演算子の利点は一行で最小限の文字数で書けるところだと思っているけれど。。
76:デフォルトの名無しさん
04/10/03 01:13:19
俺もそう思う。
77:デフォルトの名無しさん
04/10/03 01:24:24
if-else文と違って値を返すのが三項演算子の特徴なんじゃないの？
フロー制御だけならif-elseでいいけど。
78:デフォルトの名無しさん
04/10/03 01:27:58
値を返すならなおさら一行で書かないとややこしくなる気がする…
79:74
04/10/03 01:47:19
失礼。値は返します。
一列だと コロン が埋もれてしまい見た目に探すのがつらいです。
（異論あるんだろーな。。）
80:デフォルトの名無しさん
04/10/03 01:59:37
>>74
> です。ハテナとコロンは揃えます。
演算子の記号が行先頭にくるように改行するのはGNUコーディングスタンダードの
条件文の書き方に通じるものがあるね。
if (condA
&& condB
&& condC)
ってやつ。
81:デフォルトの名無しさん
04/10/03 08:02:51
>>42
> int型のポインタとint型を同じ行で定義する
間違い。
>>45
最悪。
82:デフォルトの名無しさん
04/10/03 09:03:09
>>45
最高。
83:デフォルトの名無しさん
04/10/03 09:17:54
>>77
禿同
値を使わないのなら三項演算子ではなく if-else を使うべし。
値を使う場合、if-else で書いた場合についても考えてみて、
複雑さが同程度だったら if-else を使う方が好ましい。
84:デフォルトの名無しさん
04/10/03 09:31:48
代入する値をわける場合とか、
if だと分岐したとき代入し忘れがあって怖い。
?:なら確実に代入できるので極力?:にしてる。
長くなりそうなら関数に抜き出して?:でディスパッチする。
checkstyle で使うなと起こられるのがつらい。
85:デフォルトの名無しさん
04/10/03 09:49:14
printf("....%c", .... eol?'\n':',');
みたいな使い方は？
86:デフォルトの名無しさん
04/10/03 10:03:58
>>85
便利だよねえ。
87:デフォルトの名無しさん
04/10/03 10:18:19
三項演算子使わないとreturnが増殖したりする所で使わないのはアフォだ
88:デフォルトの名無しさん
04/10/03 10:20:01
引数が長いときは
rhs.assign(
make_transform_iterator(lhs.begin(), thef)
, make_transform_iterator(lhs.end() , thef));←最後の「);」これをここにいつも書いてんだけどどうよ？
vector< vector<int> >←「vector<int>>」のエラー対策の為に空けるスペースを先頭にも空けるて揃えるのがお気に入り。
89:デフォルトの名無しさん
04/10/03 10:23:41
漏れなら
rhs.assign
(
make_transform_iterator(lhs.begin(), thef),
make_transform_iterator(lhs.end() , thef)
);
90:デフォルトの名無しさん
04/10/03 10:24:40
でも引数2個くらいなら
rhs.assign(make_transform_iterator(lhs.begin(), thef),
make_transform_iterator(lhs.end() , thef));
91:デフォルトの名無しさん
04/10/03 10:41:10
ぶっちゃけ、*の位置や改行なんかどうでもいい。
変数・関数名やスコープの最小化のほうが重要。
92:88
04/10/03 10:44:01
>>89
最初そう書こうかなと考えたこともあったんだけど
やたらと空白が目立って全体を眺めたら関数名との繋がりが希薄にかんじて････却下したんですよね。
>>90
それでも悪くは無いんですけど、
make_の開始位置が上と下じゃ揃わないから途中から書くのをやめました。ここじゃズレてましたけど・・・
最後の「));」を「) );」こうしてもいいですけどなんかしっくりこないんですよね。
じゃ改行か？と言ったら>>89に言ったような美徳センスが付きまとっていまいちなんですよね。
やっぱり個人差なのかな。
93:デフォルトの名無しさん
04/10/03 10:45:52
>>91
お前はナ。
94:デフォルトの名無しさん
04/10/03 10:53:17
URLﾘﾝｸ(www.01-tec.com)
ここを参考にしながら書くのがよろしいかと
95:デフォルトの名無しさん
04/10/03 10:55:46
>>94に書いてあった
ブラケットでスコープわけって普通に使われてんの？
func()
{
{
int a, b;
}
{
int c;
}
}
96:デフォルトの名無しさん
04/10/03 11:10:26
>>95
俺は普通に使ってるけど
97:デフォルトの名無しさん
04/10/03 11:12:46
私もふつうに使っていますよ
98:デフォルトの名無しさん
04/10/03 11:16:30
ほんとだ。スコープ分けてるＹｏ。
96 名前：デフォルトの名無しさん[sage] 投稿日：04/10/03(日) 11:10:26
>>95
俺は普通に使ってるけど
97 名前：デフォルトの名無しさん[sage] 投稿日：04/10/03(日) 11:12:46
私もふつうに使っていますよ
99:デフォルトの名無しさん
04/10/03 11:16:46
わたくしも使っております （21歳 家事手伝い）
100:デフォルトの名無しさん
04/10/03 11:17:22
また山崎か。
101:デフォルトの名無しさん
04/10/03 11:18:43
>>95
普通だけど、私は使っていない
102:デフォルトの名無しさん
04/10/03 12:39:59
クラシックCの場合
int get_hoge_fuge(args...)
みたいな関数の命名ですが、特にget,setで始まる場合は
アンダースコア _ 入れるかどうか迷うんですよね。
私はいちおう「入れる派」なんですが
ライブラリにあるやつとか ex.) getchar, gethostbyname, ...
のきなみ続けて次の単語書いちゃってるし、
外は雨降りだし、Javaの人はいいなぁって思う今日この頃。
103:デフォルトの名無しさん
04/10/03 12:52:27
getHogeFugeって書けば解決
104:デフォルトの名無しさん
04/10/03 12:56:21
Shift同時押しは微妙にタイプ速度を下げるので大文字禁止、アンダーバーも禁止。
括弧は仕方が無いがもっと打ちやすいところにほしい。
105:デフォルトの名無しさん
04/10/03 12:59:47
>>104
シフトキーを使うのも億劫になる程の
タイピング量が必要になるコードの方を
まずは禁止すべきだな。
106:デフォルトの名無しさん
04/10/03 13:34:56
>>103
ラクダ記法はJavaコーディングスタイルだったっけ。
107:デフォルトの名無しさん
04/10/03 13:40:37
コメントの
/*
*
*/
と
/*
*
*/
どっち？
アスタリスクが縦に揃うほうがいいなあ。
108:デフォルトの名無しさん
04/10/03 13:48:33
>>107
CやC++ではDoxygenに対応したコメント記法をするのが良いと思います。
後でDoxygenにかけることも考慮して。
109:107
04/10/03 13:57:08
>>108
doxygenって初めて知ったよ！
いいじゃん！
俺もこれからそうする！！
110:デフォルトの名無しさん
04/10/03 14:24:57
>>107
/*
comment
*/
Doxygen なら
/*!
\brief comment
*/
111:デフォルトの名無しさん
04/10/03 14:25:25
スペースが抜けてた
/*
comment
*/
Doxygen なら
/*!
\brief comment
*/
112:デフォルトの名無しさん
04/10/03 14:29:41
doxygenはjavadocスタイルの方が宮須行きがする。
\や!より@の方が目に優しい気がするような気がしないでもないかもしないかな、という気がした気がした。
113:デフォルトの名無しさん
04/10/03 15:00:36
自分も＠派。
JISだと'￥'になるのが悪いのかな。
'＼'なら'／'との組み合わせで見やすいのかも。
114:デフォルトの名無しさん
04/10/03 15:06:34
日本以外の人たちって \ が ＼なんだよな・・・。
目立たないし、文字列のなかでエスケープに使われてると激しく見にくくないかな・・・。
115:デフォルトの名無しさん
04/10/03 15:28:36
>>114
慣れるとそうでもない。TeXとか使っていると\の方が違和感があるかも
116:デフォルトの名無しさん
04/10/04 01:52:56
visualC++もバックスラッシュだよね（？）
確か...？
117:デフォルトの名無しさん
04/10/04 17:15:41
\よりもバックスラッシュのが好きだなあ。
特にパスの区切り文字としては見た目、\より直感的な気がします。
Win では \\ の代わりに / もパスの区切り文字として
使えるんですよね。タイプが楽だし気に入っているんだけど
ソースのポータビリティを考えたら、使わんほうがいいんでしょうね…。
118:デフォルトの名無しさん
04/10/04 17:50:38
>>117
一部のAPI（PathXXX系）が対応してないから使わないほうが無難だね。
Perlとかだと /＼r＼n/＼n/ とか読みにくくね？
119:デフォルトの名無しさん
04/10/04 20:35:15
別に読みにくくないよ?
日本のユーザ以外は皆バックスラッシュなわけだし。
むしろ、￥に慣れた人が英語情報を見るとそんなとこでもひっかかったりして
余計にとっつきが悪くなるんじゃないかと変な心配してしまうんだけど。
Unicodeで文字コード世界統一のはずなのに、日本だけ世界と一部違うものが
Unicodeとされているというのもなんだか悲しいよう。
120:デフォルトの名無しさん
04/10/04 21:11:37
為替レートとか外国で表示するとき\どうしてんだろう？
121:デフォルトの名無しさん
04/10/04 21:25:59
大体の場合0xA5がYEN SIGNだから、
122:デフォルトの名無しさん
04/10/04 22:07:37
今に至っては\の役割はもう無いね。
これからはバックスラッシュに変えていくべきだと思うんだけど。
123:デフォルトの名無しさん
04/10/05 02:24:18
Unicode?
たんにフォントの問題だろ
124:デフォルトの名無しさん
04/10/05 02:28:44
文字集合。
125:デフォルトの名無しさん
04/10/05 04:33:16
0x5CがYEN SIGNとして使われてしまうのはフォントの問題では済まないよ。
そのように使われないならその問題なくて
「日本人はなぜかバックスラッシュが見たくもないほど嫌いらしい。
どれくらいかというとバックスラッシュの代わりに円記号を表示させるくらい
嫌いらしい。」という程度の話になるけど。
126:デフォルトの名無しさん
04/10/05 05:53:06
アホですな。
127:デフォルトの名無しさん
04/10/22 02:31:16
みなさん、キャストは、
static_cast とか、reinterpret_cast とか、使ってますか？
C++的に言えば、使った方がいいんだが、どう考えてもCキャストのほうが読みやすい。
128:デフォルトの名無しさん
04/10/22 03:41:06
使ってはいる。けれども同意。
129:デフォルトの名無しさん
04/10/23 02:08:15
>>127
Cスタイルキャストは禁止してる。
理由は以下のとおり。
・Cスタイルキャストは強力すぎる
・Cスタイルキャストは見つけにくすぎる
・Cスタイルキャストは dynamic_cast できない
ちなみに、どう考えたらCスタイルキャストのほうが読みやすいことになるのかわからない。
130:デフォルトの名無しさん
04/10/23 02:47:22
書きにくいってのならわかるね。
字数多いし。むしろ書きにくいから(ry
131:デフォルトの名無しさん
04/10/23 09:23:45
Cスタイルキャストに警告を出すコンパイラってあるかね？
132:デフォルトの名無しさん
04/10/23 11:17:07
あるよ。
133:デフォルトの名無しさん
04/10/26 23:47:46
dynamic_castをほとんど使ったことがない俺は
たぶん何か間違ってるんだと思う。
134:デフォルトの名無しさん
04/10/26 23:54:04
>>133
そんなことないと思う。
C++ の危険な領域に入り込んでいない健全な姿だよ。
135:デフォルトの名無しさん
04/10/27 01:16:55
キャストなんて使わないで済ますのが一番。
dynamic_cast の出番は、時間さえあれば設計を見直すべきところがほとんど。
136:デフォルトの名無しさん
04/11/17 15:23:26
protected データ メンバを宣言してはいけない
------------------------------------------------------------
ルールの理由:
private ではなくprotected としてデータ メンバを宣言すると、
メンバ関数中にカプセル化できたはずのメンバが派生クラスから見えてしまいます。
例
//
// protected データ メンバを宣言してはいけない
//
class A
{
protected:
int i; // 違反
};
137:デフォルトの名無しさん
04/11/17 16:08:10
>>136
素人でつか？
138:デフォルトの名無しさん
04/11/17 16:21:57
>>136
「俺様ルールの違反」とちゃんと書け。
139:デフォルトの名無しさん
04/11/17 16:40:47
コンストラクタから直接グローバル データにアクセスしてはいけない
--------------------------------------------------------------------------------
ルールの理由:
異なるコンパイル単位中の静的オブジェクトの初期化順序は、
C++ の言語定義では定義されていません。
そのため、コンストラクタからグローバル データへのアクセスは、
未初期化オブジェクトからの読み取りになる場合があります。
例
//
// コンストラクタから直接グローバル データにアクセスしてはいけない
//
int a;
class A
{
public:
A();
private:
int b;
};
A::A()
{
b = a; // 違反
}
140:デフォルトの名無しさん
04/11/17 21:16:46
かわいく書く。
for(i=0; i<100; i++){ // 100回がんばる
}
141:デフォルトの名無しさん
04/11/17 21:37:06
かわいくに反応して“がんばる”が…くそっ俺の脳みそがぁぁ
かわいいじゃねぇか
142:デフォルトの名無しさん
04/11/17 22:25:44
>>129
const void *p;
const_cast<int *>(static_cast<const int *>(p));
こんなんだったらCスタイルキャストの方が読みやすいかもしれない
143:デフォルトの名無しさん
04/11/17 22:31:40
>>129
画像演算とか。
一つの式中にキャストが10個くらい現れたりする。
C++キャストでは長すぎて意図が分からなくなってしまう。
const_castはさすがにCキャストで代用しようとは思わないが、
PODに対するreinterpret_castやstatic_castはCキャストのほうが分かりやすい時もある。
144:デフォルトの名無しさん
04/11/18 00:54:49
>>142-143
カッコ悪いプログラムがカッコ悪いソースになる。それがいいんじゃねぇか。
145:デフォルトの名無しさん
04/11/18 03:37:33
>>139
いずれにしても a の初期化し忘れ。
146:デフォルトの名無しさん
04/11/18 10:06:12
>>145
aは0で初期化される
147:デフォルトの名無しさん
04/11/19 23:20:36
コボラーと大してレベル変わらんなお前ら
148:デフォルトの名無しさん
04/11/19 23:52:23
int *a, *b; // ポインタ
int a, b;
これ最強
149:デフォルトの名無しさん
04/11/20 20:28:56
C++ の const Class & や Class* は必ず typedef してから使う。
typedef const Class & ClassRef;
typedef Class* ClassPtr;
150:デフォルトの名無しさん
04/11/21 06:52:22
>>149
ウザ
151:デフォルトの名無しさん
04/11/21 10:12:08
二重インクルードヘッダーは、
"__" + プロジェクト名＋ファイル名
にする。
【例】
HelloWorld プログラムの Hello.h ファイルは、
#ifndef __HELLOWORLD_HELLO_H
#define __HELLOWORLD_HELLO_H
...
#endif
とする。
152:デフォルトの名無しさん
04/11/21 10:33:02
何が言いたいんだ…？
文句を言いたいのか、上記のように統一しろと主張しようとしてるのかわからんぞ
153:デフォルトの名無しさん
04/11/21 10:46:19
>>151
ISO/ANSI規格では識別子の初めに _ が2つ続く物はコンパイラ・ライブラリ関数のために予約されているので駄目だ。
154:デフォルトの名無しさん
04/11/21 11:27:42
>>153
"_" がふたつだけじゃなくて、ひとつでも予約されてるんじゃなかったっけ？
(つまり "_" で始まる名前はすべて標準ライブラリ用に予約されてる)
155:デフォルトの名無しさん
04/11/21 11:51:19
漏れのインクルードガードは、ファイル名 (ピリオドを '_' に
変換したもの) + '_' だな。大文字/小文字はそのまんまだ。
#ifndef MotherHacker_h_
#define MotherHacker_h_
ここで気になるのが #endif なんだけど
a. #endif // !MotherHacker_h_ ( '!' あり )
b. #endif // MotherHacker_h_ ( '!' なし )
c. #endif ( なんもなし )
てめーらはどれ派？
漏れは昔は c.，以前は b. だった。でも今は a. 派。
156:デフォルトの名無しさん
04/11/21 12:10:00
漏れは
#ifndef MOTHER_HACKER_H__
#define MOTHER_HACKER_H__
#endif// MOTHER_HACKER_H__
最後の_が２つなのがミソ
157:デフォルトの名無しさん
04/11/21 12:38:30
>>154
本当だ。
今まで'_'の次に英大文字か'_'の場合だけが予約かと思っていた
158:158=157=153
04/11/21 12:41:55
>>156
インクルードガードのときだけ例外的にb派。
#ifdef HOGEに対しては#endif // defined HOGEとしている。
159:デフォルトの名無しさん
04/11/22 00:07:48
漏れは
#endif // !defined( _suffix_hoge_h_included_ )
160:デフォルトの名無しさん
04/11/22 02:18:33
漏れは//にスペース入れない
#ifndef MotherHacker_h_
#define MotherHacker_h_
#endif//MotherHacker_h_
なぜって識別子の位置が揃うから
161:デフォルトの名無しさん
04/11/22 03:21:50
>>160
> なぜって識別子の位置が揃うから
うーん、気持はわからなくはないけど。
#elseや#endifに条件式をコメントとして入れとくのは、そもそも#ifの位置が
遠く離れてて把握できなくても条件式をすぐに理解できるようにするためでしょ？
そんな状況なら桁の位置が揃ってるかどうかなんて、どうでもいいと思うんだけど。
桁揃えが気になるような距離なら、そもそも条件式をコメントに書かなくてもいいし。
162:デフォルトの名無しさん
04/11/22 10:14:40
163:デフォルトの名無しさん
04/11/23 17:04:27
>>156
残念だがそのミソは予約されている。
164:デフォルトの名無しさん
04/11/23 20:52:14
【規約】
プリプロセッサ命令は #if や #ifdef の中ではインデントさせる。
ただし # は必ず行頭に配置せよ。
例：
#ifdef HOGE
# include <hoge.h>
# ifdef FOO
# #include <foo.h>
#endif
#endif
165:デフォルトの名無しさん
04/11/23 20:56:26
>>164 なんで？なんかいいことあるの？
166:デフォルトの名無しさん
04/11/23 20:57:35
入れ子が複雑になっても、読みやすい、修正しやすい。
入れ子をベタで書くのはよくない作法だろ。
167:デフォルトの名無しさん
04/11/23 21:07:49
>>164
↓こんなんも、#だけ行頭に動かすの？
{
while(...)
{
if(...)
{
#if HOGE
...;
#endif
...;
}
}
}
168:デフォルトの名無しさん
04/11/23 23:12:29
1カラム目以外に'#'があるとディレクティブと見做さないコンパイラがあったなぁ。
169:デフォルトの名無しさん
04/11/24 19:40:17
基本的に if 文は>>5のスタイルで書いているがキモいのか・・・？
>>7や>>14も嫌いではない。
170:デフォルトの名無しさん
04/11/24 20:01:33
俺は14の方がキモいと思う。
同じく普段は5を使っているが、行数制限があるときは7スタイルも使う。
171:デフォルトの名無しさん
04/11/24 20:04:22
このあたりはもう好みの問題でしょ。
個人的には>>14で書いてる。
>>5は、if の次に { だけの行がくるのがスカスカな感じでちょっといや。
172:デフォルトの名無しさん
04/11/24 22:49:23
>>5 のスタイルの方がネストしたときの括弧の対応がわかりやすいと思うけどなぁ・・・
Windows 2000 のコードとか、FFFTP なんかは、 >>5 のスタイルで書かれてるね
まぁ、>>14 の書き方でも絶対に間違わないって言う地震があるのならいいんじゃないの
好みの問題
173:デフォルトの名無しさん
04/11/24 22:51:59
私は>>7だな。
174:デフォルトの名無しさん
04/11/25 13:50:53
つまり>>5のやつが言葉を間違えたんだろ。キモイは言いすぎ。好みの問題でしかない。
俺は>>14だが。
175:デフォルトの名無しさん
04/11/25 20:13:12
>>14はなんだか中途半端な気がして、気持ち悪い。
なんか、切れそうで切れない生首のような、ほとんど首無しニックのような、気持ち悪さ。
176:デフォルトの名無しさん
04/11/26 14:38:36
>>5使ってるよ。
177:デフォルトの名無しさん
04/11/26 14:52:04
>5も好きじゃないんだが、
if (...)
{
...;
}
else
{
...;
}
って書かれるとどうもね。
#2段も下げるなって感じ?
178:デフォルトの名無しさん
04/11/26 14:59:41
>>177
GNUスタイルですな。慣れればいいのかもしれないが、
俺は>>7でタブは8カラム。以前までタブでなくスペース派
だったんだが、今はまあいいかなと思えるようになった。
タブを行頭にしか使わなければ環境依存も(ある程度)
許容できるし。
179:デフォルトの名無しさん
04/11/26 17:58:51
TABを使ったソースを別の環境で見たときに見た目が違うということがあっても
別に大した問題ではないだろう。
TABをスペースに置き換えるなんてエディタの機能で一発だったりするでしょ。
手間は大したこと無いから全然気にしないで、自分の環境で一番やりやすいやりかた
ですれば良いと思うよ。
180:デフォルトの名無しさん
04/11/29 23:35:29
CodeWizard とかの静的解析ツール使えばいいんじゃないの
181:デフォルトの名無しさん
04/11/30 01:45:33
流儀違うとCVSに落としたりするとき困るよな
全部2TAB→スペース変換してコミット
182:デフォルトの名無しさん
04/12/02 00:19:30
>>45 は
*(int *)&a
じゃないのか？
183:デフォルトの名無しさん
04/12/02 08:39:54
>>182
それじゃ a と同じになっちゃうだろ。
184:デフォルトの名無しさん
04/12/02 18:12:23
長いprintfのカンマは左側に書く。
printf(
"compless : %s\n"
"code : %xh\n"
"codesize : %xh\n"
"entry offset : %xh\n"
"begin offset : %xh\n"
"end offset : %xh\n"
,isompless?"true":"false"
,code
,codesize
,main_entry
,begin_entry
,end_entry
);
185:デフォルトの名無しさん
04/12/02 18:56:09
printfに限らず俺はインデントした上で右側にカンマ付けるけどな。
こうしている人の方が多いと思っているし。
186:デフォルトの名無しさん
04/12/03 18:44:42
継続行はCodeCompleteに倣って演算子を右に書く。
全体はApacheスタイルに近い。
タブは4カラムで、スペースじゃないけど。
187:デフォルトの名無しさん
04/12/08 09:12:31
ここは重複スレです
Cのマナーいろいろ
ｽﾚﾘﾝｸ(tech板)
188:デフォルトの名無しさん
04/12/08 09:17:24
>>187
仕切り厨ウザイ
189:デフォルトの名無しさん
04/12/08 09:31:06
こいつぼけ
190:デフォルトの名無しさん
04/12/08 10:21:59
>>189
おまえがな。
191:デフォルトの名無しさん
04/12/13 04:22:13
voidで返す関数はreturn書く？
192:デフォルトの名無しさん
04/12/13 04:35:34
voidで返す?
193:デフォルトの名無しさん
04/12/13 04:49:17
C++ならreturn void;
194:デフォルトの名無しさん
04/12/13 04:50:45
返り値がvoidならreturnは省略した方がコードが短くなって読みやすくなると思うんだけど。
195:デフォルトの名無しさん
04/12/13 05:17:00
そもそも値を返さないのがvoid
196:デフォルトの名無しさん
04/12/13 22:29:28
>>191
条件 return の場合以外書かない。
197:デフォルトの名無しさん
04/12/16 23:24:30
>>191
関数であると明確にするために、書いておく。
198:デフォルトの名無しさん
04/12/16 23:25:42
関数以外のものがあるわけじゃないのに…
199:デフォルトの名無しさん
04/12/16 23:47:17
pascalの癖が抜けないんだろう
200:197
04/12/17 03:16:35
>>199
悪いが、Pascalなんぞやったことないんだが。
201:デフォルトの名無しさん
04/12/17 03:24:20
>>200
無学を自慢するな
202:デフォルトの名無しさん
04/12/17 03:25:12
じゃ、VBか。
203:デフォルトの名無しさん
04/12/17 03:26:55
そもそも返り値がvoidの関数を作る事自体が間違えなんじゃないの？
処理は全部副作用だけなんて…
204:197
04/12/17 03:33:40
>>201
どこがどう自慢だったんだね？
むしろ謝っているとしか言えないが。
205:デフォルトの名無しさん
04/12/17 03:38:25
>>204
石黒級の馬鹿だな。まず日本語をなんとかしろよ。
206:デフォルトの名無しさん
04/12/17 03:46:05
>>205
何か日本語の使い方でおかしいところなんてあったか？
お前こそなんとかして反論しようとして
無理やり絞り出したようにしか見えんな。
207:デフォルトの名無しさん
04/12/17 03:57:40
もまいらもちつけ
208:デフォルトの名無しさん
04/12/17 04:03:40
低級な言い合いは止めてくれ
209:デフォルトの名無しさん
04/12/17 04:16:36
アセンブリはやっておくべきだよ
210:デフォルトの名無しさん
04/12/17 04:21:58
>>209
うまい
211:デフォルトの名無しさん
04/12/17 05:33:41
mov ax, 4c00h
int 21h
212:デフォルトの名無しさん
04/12/17 05:42:25
>>206
それ本気で言ってる？
もう必死すぎだなｗ
213:デフォルトの名無しさん
04/12/17 07:24:00
>>212
あまり強く言いすぎると、釣りってことにして逃げちゃって興醒めだよ。
真綿で首を絞めるみたいにイジらないと。
214:デフォルトの名無しさん
04/12/17 09:20:59
>>213
多分それ以前に>>212が釣りなんでは
215:デフォルトの名無しさん
04/12/17 09:21:21
そういうことは真綿で首を絞めてから言ってくれ。
216:デフォルトの名無しさん
04/12/17 09:38:18
日本語って言うならおれは>>203が気になるな。他でも見るが
「間違い」だろ？
217:デフォルトの名無しさん
04/12/17 12:06:40
>>216
本人だが同意
218:デフォルトの名無しさん
04/12/17 12:22:36
>>217
単純にtypo?
219:デフォルトの名無しさん
04/12/17 19:49:43
「Pascal やったことないと無学」ってことにしたい >>201 が
キチガイだったということで。
220:!=201
04/12/17 22:41:14
そりゃ無学だろ
221:デフォルトの名無しさん
04/12/17 23:06:33
URLﾘﾝｸ(www.page.sannet.ne.jp)
たまたま見つけた最悪なコードの見本。
222:デフォルトの名無しさん
04/12/17 23:09:32
アセンブラやったことないよ
パスカルやったことないよ
スクイークやったことないよ
シーシャープやったことないよ
セックルやったことないよ
一番ダメなプログラマーはどれ？
223:& ◆QWv3R1XL8M
04/12/17 23:11:52
１５日C++とSTLとテンプレ使えるようになる苦行教えてくれ。
耐えて、使えるようになりたい。
224:デフォルトの名無しさん
04/12/17 23:12:25
>>223
AC++というつまらない本を熟読する
225:デフォルトの名無しさん
04/12/17 23:24:40
>>222
パスカルやったことないよ
226:デフォルトの名無しさん
04/12/17 23:38:50
Ruby知らないというのは致命的・
227:デフォルトの名無しさん
04/12/17 23:43:08
>>224
MC++ はどう？
228:デフォルトの名無しさん
04/12/18 01:10:52
pascalが何の単位か分からない奴は無学
229:デフォルトの名無しさん
04/12/18 01:32:21
ヘクトパスカル？
230:デフォルトの名無しさん
04/12/18 01:35:44
>>229
メガバイトって言っているのと同じだよ
231:874
04/12/18 15:54:20
>#define unint unsigned int /* 型名の 別名を定義します。 */
>#define unlong unsigned long
ﾜﾛﾀ
232:デフォルトの名無しさん
04/12/18 16:16:00
>>221、>>231のサイトって、中学生に教えている積もりなのか?
余りに痛々しいんだが。
233:デフォルトの名無しさん
04/12/21 00:22:46
ｋ
234:デフォルトの名無しさん
04/12/21 00:47:17
switch～caseのインデントってどうしてる？
俺は
switch(n){
case 0:
cout << "0" << endl;
break;
default:
break;
}
caseとswitchのインデントレベルは同じにしてるけど。
235:デフォルトの名無しさん
04/12/21 02:55:19
>>234
タブを４として、スペース２個を入れる。
236:デフォルトの名無しさん
04/12/21 04:57:49
>>235
K&Rと同じにしてる。
つまり同じレベル。
237:デフォルトの名無しさん
04/12/21 06:01:18
同じにしてる。
基本的にインデントが一気に2段下がることが無いように頑張っている
238:デフォルトの名無しさん
04/12/22 00:36:28
俺は>>235と同じだな。
239:デフォルトの名無しさん
04/12/24 15:14:41
switch(n)
{
case 0:
cout << "0" << endl;
break;
default:
break;
}
240:デフォルトの名無しさん
04/12/24 17:47:57
俺はこう。
switch (n) {
case FOO:
foo();
break;
case BAR: {
int x = bar(n);
baz(x);
break;
}
default:
/* NEVER REACH HERE */
abort();
}
241:デフォルトの名無しさん
04/12/24 18:45:23
switch (n)
{
case FOO:
foo();
break;
case BAR
{
int x = bar(n);
baz(x);
break;
}
}
俺のスタイル。
242:デフォルトの名無しさん
04/12/25 13:37:04
switch (n)
{
case FOO:
foo();
break;
case BAR
{int x = bar(n);
baz(x);
break;
}
}
俺のスタイル。
243:241
04/12/25 18:46:13
そう言えばswitchとclassのインデントの付け方は同じになっている。
244:デフォルトの名無しさん
04/12/25 23:17:43
>>243
それがpublic、protected、privateのことなら俺も同じ。
245:デフォルトの名無しさん
05/01/30 14:52:51
b
246:デフォルトの名無しさん
05/02/03 22:24:32
switch (...) {
case 1 : {
foo();
} break;
case 2 :
case 3 :
case 4 : {
foo();
} break;
case 5 :
foo();
// Fall Through
default : {
foo();
} break;
}
俺のスタイル。
switchは滅多に使わんがなー
247:デフォルトの名無しさん
05/02/04 20:26:43
↑馬鹿発見
248:デフォルトの名無しさん
05/02/04 20:31:31
>>246
そうかそうか、それは素晴らしい書き方だな。よーくわかったぞ。
249:デフォルトの名無しさん
05/02/27 15:11:54
>>247-248
必死だなｗｗｗｗ
250:デフォルトの名無しさん
05/03/02 12:56:35
switch (n)
{
case FOO:
foo();
break;
case BAR
{
int x = bar(n);
baz(x);
}
break;
}
251:デフォルトの名無しさん
05/03/05 03:57:03
>>250
おお、なんと感動的な書き方なんだ。正直、俺は感動した。
252:デフォルトの名無しさん
05/03/05 19:25:32
俺スタイルは>241に酷似。
switch (n)
{
case FOO:
foo();
break;
case BAR:
// baz(int&) の引数のために実体となる変数が必要 ← みたいに、なんかコメントしとく
{
int x = bar(n);
baz(x);
}
break;
}
253:デフォルトの名無しさん
05/03/06 00:00:51
漏れは>>250に似てるけどこうかな
switch(n)
{
case FOO:
{
foo();
break;
}
case BAR:
{
int x = bar(n);
baz(x);
break;
}
}
254:デフォルトの名無しさん
05/03/06 03:32:58
禿は禿本で
case FOO:
foo();
break;
case BAR: {
int x;
bar();
break;
}
こう書いてたっけ？
個人的には{で改行しない方が若干見やすいかなぁ
255:デフォルトの名無しさん
05/03/08 00:16:03
いまやC++は(boostの)シリアライズを持っているので
メンバ変数にhoge_と尻尾に_を付けるのではなく
一時変数に_を付ける
spiritのサンプルにあった。
メンバに堂々と何もつけないのはなかなか気持ちがよいな
256:デフォルトの名無しさん
05/03/08 00:45:46
>>255
> 一時変数に_を付ける
激しく受け入れ難い。
257:デフォルトの名無しさん
05/03/08 19:00:08
てかメンバもローカルも_無しでよくね？
258:デフォルトの名無しさん
05/03/08 20:56:40
↑禿同
this->が付いてたらメンバ。
259:デフォルトの名無しさん
05/03/09 06:37:01
>>258
技術的なメリット、デメリットでは this-> が最強なんだよな。
・クラステンプレートのコードでは付けないと恐ろしい罠に嵌りかねない。
・bool Is～() な関数を自分で呼ぶときも this->Is～() が読みやすい。
・無節操にメンバに触りまくって最適化を台無しにする糞コードが減る。
問題は、一般性が皆無なことだな。
this-> と等価な . （単項ドット演算子）を作って、
省略不可にすれば、・・・どうなっていただろう？
260:デフォルトの名無しさん
05/03/09 13:37:06
this必須でもいいけど、初期化リストのとこではthisつけられないよね？確か。
261:デフォルトの名無しさん
05/03/09 13:47:48
初期化リストならメンバか継承元であることが自明だから医院で内科医?
262:デフォルトの名無しさん
05/03/09 18:57:55
class AAA {
int size;
public:
AAA (int size)
: size(size) // この行
{}
};
こんなコードが通るのが微妙に気持ち悪かったり。
かといってメンバ名と仮引数名にうまく別の名前をつけられる妙案がない……。
this->size(size) って書ければ多少気持ち悪さも減るかと思ったの。そんだけ。
263:デフォルトの名無しさん
05/03/09 19:03:41
>259の案を採用して、
class AAA {
int size;
public:
AAA(int size) : .size(size) {}
};
はどう?
これも気持ち悪い?
264:デフォルトの名無しさん
05/03/09 19:04:38
> this-> と等価な . （単項ドット演算子）を作って、
> 省略不可にすれば、・・・どうなっていただろう？
視認性が悪いものを必須にするのはちょっとなぁ。
いっそPythonよろしく、メンバ(変数|関数)の参照はthis必須の方がまだまし。
それに、visitor.visit(this)があるから、thisキーワードを
なくせるわけじゃなし、見づらい構文糖衣の意味しかないと思われ。
265:デフォルトの名無しさん
05/03/09 19:47:29
this必須がコンパイラで強制できればそれでもいいんだけど、
そうじゃないならm_プレフィクスの方がいいな。
266:デフォルトの名無しさん
05/03/10 00:49:11
流れ斬り！
クラス内のメンバ関数の実体を書く順番は
a)宣言と同じ順に
b)重要なもの、呼ばれる頻度などの順に書き、宣言と順番が違う
c)宣言から b) の順で、実体はその順
d)んなもん気にしてない
他にオレ流あるなら追記ヨロ
あと、protected とかの種類別に分けてる or 分けてない？
267:デフォルトの名無しさん
05/03/10 01:32:35
>>266
漏れ的には、
1) public -> protected -> private の順で宣言も実装も行う
2) コンストラクタとデストラクタは全てのメンバ関数に先駆けて書く
という感じ。
268:デフォルトの名無しさん
05/03/10 02:59:05
全部宣言のところに実装も書く
269:デフォルトの名無しさん
05/03/10 11:46:21
メンバ関数の実装ではお互いに他のクラスの定義を必要とすることがよくあるので、
基本的に宣言は宣言だけ。
実装は別ファイル。
テンプレートを除いてインライン関数も使わない。
例外は3つあって、一つは単に値を返すgetter系。
もう一つはシグネチャの違う他のメンバ関数を呼ぶだけのようなもの。
3つめは初期化リストだけで済んでしまって中身が何もないコンストラクタ。
これらは宣言のところに実装も書いてしまう。
実装のファイルでは意味的なグループごとに関数を近接させる。
public等のアクセス修飾は関係なし。
270:デフォルトの名無しさん
05/03/16 10:55:25
メンバ変数だからって、特に目印はつけないのですか？
271:デフォルトの名無しさん
05/03/16 10:57:20
とりあえず >>257- は読んだのか？
272:デフォルトの名無しさん
05/03/18 06:34:51
漏れの場合、条件付きインラインとかの為にも、
ヘッダーには宣言だけ書いてる。インライン関数は全部.inlに。
見た目もすっきりするし、最適化とかデバッグの時に有利かと。
273:デフォルトの名無しさん
05/04/03 01:17:18
age
274:デフォルトの名無しさん
05/04/06 11:06:38
void
hoge()
か
void hoge()
か
275:デフォルトの名無しさん
05/04/06 12:47:11
識別子がクソ長かったら適当にこんな感じでバラしていく
return_type
function_name
(argument1_type argument1_name,
argument2_type argument2_name)
{
}
276:デフォルトの名無しさん
05/04/06 12:50:11
template <typename T>
void hoge(T arg)
277:デフォルトの名無しさん
05/04/06 22:21:12
>>276 の書き方もしくは、
template<typename T>
ReturnType
FunctionName(
ArgType1 arg1,
ArgType2 arg2)
{
}
278:デフォルトの名無しさん
05/06/12 05:19:09
for(int i = 0; i < n; i++) {
}
for(; ; ) {
}
無限ループでも、例外なく ; の後にスペースを空ける。
279:名無しさん＠そうだ選挙に行こう
05/09/11 14:42:07
hoge
280:デフォルトの名無しさん
05/09/17 11:31:43
marudasi(lambda() {baka;} );
と書ける処理系作ったおれはスゴイ
281:デフォルトの名無しさん
05/09/18 20:12:33
まあシンタックスで困ることはほとんどないな
こだわる人は勉強してる人が多いけど
282:デフォルトの名無しさん
05/11/08 00:30:45
>>270
付けない
無くて困ると言う事は、クラスが巨大過ぎる気がする
283:デフォルトの名無しさん
05/11/08 08:18:16
>>282
付けてる人同士のソースの相互理解容易度の高さを知らないんだね
どんなに小さいクラスでも有用だよ。
284:デフォルトの名無しさん
05/11/08 20:46:40
俺はm_プレフィクス派だな。
1. 見てわかる
2. リファクタリング用の機能がなくても一気に置換できる
3. this->は長い上にどこかのメンバ関数の中でつけ忘れててもコンパイルでき
処理系で強制できない。
285:デフォルトの名無しさん
05/11/09 23:53:23
>>283
まあ、美意識の問題が大きいので（慣れもかな）
m_は、個人的に、異様に汚く見える（あくまで主観）
ローカル変数は、宣言即初期化派＆＆
それが追い辛くなるほどメソッドを大きくしない派
なので、メンバ変数と区別が付かない||相互理解が不便なんて事は無い
286:デフォルトの名無しさん
05/11/10 00:33:08
>>285
きこえてアムロ？メンバ変数とローカル変数を見分けるまでの作業量が全然違うのよ。
単純化するためにグローバル変数とかスタティック変数とかは抜きにして説明すると
■メンバ変数とローカル変数に命名方法の区別をしない場合
1) ある変数を見る。
2) その変数より前の部分を関数のはじめまでみる
3) 途中に宣言があればローカル変数、引数に指定されてれば引数、どちらでもなければローカル変数と決定できる。
■プリフィックス又はサフィックスでメンバ変数のみ印付けをしている場合
1) ある変数を見る
2) その変数に印付けがされていればメンバ変数、そうでなければローカル変数か引数
上下方向への視点の動きがまったく発生しなくなるのがおわかりいただけて？
287:デフォルトの名無しさん
05/11/10 01:36:47
俺も、m_ はマイクロソフト系ツール使うまで、全く不要と思っていたが、使い始めるとやめられなくなる。
288:デフォルトの名無しさん
05/11/10 02:25:02
>>286
否、だから・・・
＞上下方向への視点の動きが
そんな事が邪魔になる様なコードを書かないって話。
逆に、それで解りづらくなると、メソッドの構成とかを見直すから
無い方が良い気もしないでもない。。
見分けが解りやすいと、その辺が鈍感になる
それから
＞1) ある変数を見る。
＞2) その変数より前の部分を関数のはじめまでみる
こんな追い方しなきゃいかんと言う事は
メソッドが長すぎるんでないかい？？
さらに、それから、別にm_を否定してる訳ではない、念の為
289:デフォルトの名無しさん
05/11/10 02:38:10
>>288
視点って目が見てる部分のことだよ？
速読術でもやってる人ならわからないけど
普通の人間は"面"全体を注目することはできない。
文章の中やコードの中であれば、一行しか注目はできないの。
ここまでOK？
ある変数名に注目してしまった時、
コードが2行以上ならばもう他の行は同時には注目できないでしょう？
そのある変数名に注目した段階で判別できる方法が
何らかのプリフィックスやサフィックスを使う方法で、
一度別の部分に注目する場所を移してから判別するより
遥かに効率がいいの。
あなたのコードが全てベーマガに掲載されそうな一行コードならいいんだけど。
290:デフォルトの名無しさん
05/11/10 02:49:00
＞文章の中やコードの中であれば、一行しか注目はできないの。
？
人間の視点って「"面"全体」は見ること出来ないけど
「ある程度のかたまり」で認識できると思うけど
逆に、「一行しか」って注目は難しい気がする
横だけの集合だけ注目度が高くなるのも
ちょっと不思議な気がしないでもない
291:デフォルトの名無しさん
05/11/10 02:59:28
標準の set を実装する場合など、自然な命名だと
メンバ変数に size なんてのが置きたくなって
メンバ関数の size() と被ってしまう。
m_ はそんな時にも助けになる。
292:デフォルトの名無しさん
05/11/10 03:04:20
size_
293:デフォルトの名無しさん
05/11/10 03:13:09
>>292 流れを読むようにしような。
294:デフォルトの名無しさん
05/11/10 07:56:03
>>290
結局"おれはm_とか付けたくない"っていう結論ありきで
相手の話を理解しようとして聞いてないじゃない
あんたはソースの中に縦書きでも探してれば？
それとも縦書きに釣られすぎて横方向に文字読みながら
縦方向にも縦書きを探せるなんてかわいそうな
特殊技能でも身に着けちゃってるのかね
295:デフォルトの名無しさん
05/11/10 08:49:37
まあしょせんハンガリアン命名記法だから、いまさら論争自体がなあ。
コードレビューとして考えて意味の把握のしやすさのほうが問題で、
個人的には単純に視点の移動を作業量と考えるのはメリットが無い。
絶対的な利便性があるわけでもなく、強制はナンセンス。
そうしたい人だけそうすれば。
296:295
05/11/10 08:51:58
>そうしたい人だけそうすれば。
訂正、そういう規約がある/必要な場合にその人が守ればいいだけ。
297:デフォルトの名無しさん
05/11/10 10:51:06
m_ プリフィックスをハンガリアンとか言ってる時点で見識のレベルの低さが露呈してるんだけどね。
298:デフォルトの名無しさん
05/11/10 11:18:22
所詮、ローカルルールでしょ
299:デフォルトの名無しさん
05/11/10 12:00:32
わたしも、所詮ローカルルールと言う意味などでハンガリアンみたいなもの
と言ってるのだが、
>>297
ほう、見識が高いと、m_ プリフィックスはハンガリアンではないと?
それはそれで言い分があるかもしれないから、まともに見識のあることを
喋ってごらん。喋れるなら。通じない根拠や相手の非難だけにすり替えないで。
300:デフォルトの名無しさん
05/11/10 12:05:00
>>299
別におれは297じゃないんだけどさ。
もとの書き込み(>295)では「みたいなもの」などと言わずに、そのものだと言い切っている。
「ハンガリアンはプリフィックス」は真だと思うが、
「プリフィックスはハンガリアン」とは言えないだろう。
「ごめんなさい」が言えない人ですか？
301:300
05/11/10 12:07:43
> 「ハンガリアンはプリフィックス」は真だと思うが、
> 「プリフィックスはハンガリアン」とは言えないだろう。
ごめん、「m_ プリフィックス」ってなってるのを見落としてた。
「m_ プリフィックス」はハンガリアンじゃなくて
ただのメンバ変数を表すプリフィックスだから
言いたいことは同じだけどね。
302:297
05/11/10 12:40:51
>>299
m_プリフィックスがハンガリアンだという資料があれば俺に教えて欲しいくらいだ。
まず君はここらへんから読みたまえ。
URLﾘﾝｸ(www.radiumsoftware.com)
メンバ変数か否かというのはC/C++言語における"型"かね？
そうではないだろう？
303:295
05/11/10 13:39:17
>>300-302
なんだ、見識どうこうといって、やはりその話なんだ。
もちろん m_ がオリジナルな意味での Hungarian Notation でないのは
URLﾘﾝｸ(msdn.microsoft.com)
もともと否定しない。しかし(少なからぬ人と同じように)スコープを示す
一種の拡張ハンガリアンとしてのローカル規約であると捉えるので、
URLﾘﾝｸ(msdn.microsoft.com)
m_ どうこうの強制や論争自体がナンセンスであると。
(たいてい賛成派もきちんと理由を挙げられない)
で、別に m_がハンガリアンであろうとなかろうと論旨には全く関係無いが、
そういうところを見識といって揶揄するぐらいしかできないと?
304:デフォルトの名無しさん
05/11/10 14:20:48
>>303
なんかスレが伸びてると思えば。もう頭悪いね君としか言いようがないな。
1. m_ はcoding style convensionであって、属性をコード化するハンガリアン
とは関係ない(ハンガリアンの延長線上と看做す向きもあるが見解の分かれる
ところであるし、個人的には牽強附会と思う)。
論争が意味ないとかいうのは一連の議論を否定するただの煽りでしかなく、
m_プレフィクスの無用性について意味のある主張をしたいのなら命名法で
区別することによるメリットがないことを示せ。もしくは>>295の
> コードレビューとして考えて意味の把握のしやすさのほうが問題で、
というのがm_プレフィクスにより激しく損われるという論拠でもよい。
(それが他人にとってm_プレフィクスの有用性に優越するかどうかは別の問題だ
が、個人・場合による問題なので異なる見解が両立し得る)
一般のハンガリアン記法の適用を否定する主張としては一理あるが、我々は
m_プレフィクスについての議論をしているのであり、ハンガリアンの延長線上と
君が看做したからといって盲目的に適用するのは無茶と言うもの。
2. ただの煽りでしかなければ見識がないと言われるのは必然である。しかも
> で、別に m_がハンガリアンであろうとなかろうと論旨には全く関係無いが、
という主張は
> まあしょせんハンガリアン命名記法だから、
で始まる>>295自体の意味を否定する。即ち>>295が無意味な煽りであり、295には
見識がないということを自分で立証している。
3. ちゃんと理由は挙げられているのに個別に反証することなく
> (たいてい賛成派もきちんと理由を挙げられない)
と書いているのは他人のレスをろくに読みもしていないことを立証している。
305:295
05/11/10 15:23:50
>1.
>ハンガリアンの延長線上と看做す向きもあるが見解の分かれる
>ところであるし、
>(それが他人にとってm_プレフィクスの有用性に優越するかどうかは別の問題だ
>が、個人・場合による問題なので異なる見解が両立し得る)
つまりどちらかの立場をとること自体に問題は無い。
>区別することによるメリットがないことを示せ。
すでに>>288等(295とは別人)も繰り返してるだろう。
結局"おれはm_と付けてる"っていう結論ありきで
相手の話を理解しようとして聞いてないじゃない
#288等補足:
#コードレビューとして考えて意味の把握のしやすさのほうが問題で、
#個人的には単純に視点の移動を作業量と考えるのはメリットが無い。
#(個人的には可読性が落ちるケースが少なくない。m_をつけて
#よしとして全体としての意味をとりにくい名前のままの事があるから、
#とも思っている)
>2.
煽られたと思うところ、喰いつきやすそうな所だけ問題にしたい、と。
<絶対的な利便性があるわけでもなく、強制はナンセンス。
<そういう規約がある/必要な場合にその人が守ればいいだけ。
>3. ちゃんと理由は挙げられているのに個別に反証することなく
ええと、そのちゃんとというのは >>286,289 あたりですか?
(直後にも反論(?)ついてるようですが)
306:デフォルトの名無しさん
05/11/10 17:05:51
君、謝っちまったほうが楽になるよ。
自分の価値が下がるわけじゃない。むしろ上がるさ。
307:デフォルトの名無しさん
05/11/10 17:51:58
>>306
"おれはm_と付けてる"から揶揄に終始しますと。ご苦労様です。
別にまともな論が無かろうと、そういう規約がある/必要な場合に
そうするのは止めやしない。まこといまさら論争自体がナンセンス。
308:306
05/11/10 18:34:58
俺、どっちが悪いとか言って無いのになぁｗｗｗ
食いついた方が、実は自分が不利だと悟ってる方だと思って
書き込んでみたがこううまくいくとは思わなかった。
309:デフォルトの名無しさん
05/11/10 20:46:47
ほほーぅ、それでそれで？
310:デフォルトの名無しさん
05/11/10 22:16:15
結論: 295はアフォ。
そろそろ次の話題行きましょ。
311:デフォルトの名無しさん
05/11/10 22:47:43
305はあれで反論したつもりになってるんだろうか。
自分で相手の主張を肯定していることに気がつかない頭の弱さｶﾜｲｿｽ。
312:デフォルトの名無しさん
05/11/19 03:13:19
>>274
後者。grep で関数名引いた時、返す型が表示されないってのは
かなり痛い。
313:デフォルトの名無しさん
05/11/22 00:59:22
>>312
つ grep -B 1
314:デフォルトの名無しさん
05/11/23 17:13:43
>>308
レス先書かなきゃ、直前のレス宛だと考えるのが普通ですよ。
こういうのがわからない人のコードって、さぞ自分勝手なんだろうな :-)
315:デフォルトの名無しさん
05/11/26 02:31:31
m_とかg_とか付けるとかってさぁ、自分だけでプログラムしてるならいいけど
多人数で作ってると付けて欲しいんだよね。
人によってスタイル違うしクラスからグローバル変数使いまくりな
タココード書く奴が足引っ張って大変。
メンバ関数内で何も付けずにローカル、メンバ、グローバル変数が
入り乱れた他人のコードを追うのはきついぞ。
そんなので新人がマルチスレッドのコード書くもんだからたまらん。
何も付けない派の奴らにお見舞いしたいコードだ。
316:デフォルトの名無しさん
05/11/26 04:43:41
>>315
それはプレフィクスごときで解決する問題じゃないと思うが……
317:デフォルトの名無しさん
05/11/26 13:15:48
多人数で作るならある程度のコンベンションを決めるのは当たり前だと思う
m_ でも g_ でも付けないでもいいから、とにかく揃えておくというのが重要かと
タココードを書くやつがいるというのは別問題だな
318:デフォルトの名無しさん
05/11/26 13:36:21
グローバル変数はそれなりに存在価値がある。
staticメンバ変数として隠蔽されていた方が、かえって追跡しにくい場合もある。
タココードの場合は、独自の名前空間にいれるよう強要すれば問題解決でしょ・・・多分。
319:デフォルトの名無しさん
05/11/26 13:43:54
ま、手軽に、using namespace xxx を
グローバルスコープで宣言された日には手も足もでないんだけどね。
320:デフォルトの名無しさん
05/11/26 14:07:00
>>318
> グローバル変数はそれなりに存在価値がある。
> staticメンバ変数として隠蔽されていた方が、
> かえって追跡しにくい場合もある。
具体的にどんな場合？
321:デフォルトの名無しさん
05/11/26 14:56:06
>>318
タコかどうかなんて、ほぼ書き上げられたソースを見るまで
判らん場合もあるわけで
322:デフォルトの名無しさん
05/11/26 15:17:25
Socketまわりなんかタコどころか糞コードだからな
323:デフォルトの名無しさん
05/11/26 20:49:16
逆に言えば（当然のことながら）
ネーミングルールを決めただけでタココード/糞コードがそうでなくなることなど無い
324:デフォルトの名無しさん
05/11/26 22:37:23
>>323
・・・確かに。
タコのタコたる所以は、命名ルール無視などという生易しいものではない罠。
325:デフォルトの名無しさん
05/11/26 23:53:51
タココードでもネーミングルール守っていてくれれば、まだマシなのでは？
326:デフォルトの名無しさん
05/11/27 00:31:43
グローバルやstatic変数にコールバック関数が入り乱れる自分にしか
理解できないコードを書く奴を抑止できる状況にもっていけない
場合は多々ある。せめてg_だけでもいいから付けてくれ。
予期せぬ不具合はグローバルがらみが多すぎる。
327:デフォルトの名無しさん
05/11/27 04:42:19
蛸コード書く香具師のプレフィックスほど当てにならないものはない。
結局、自分で検索してマーキングした方が間違いなかったりする。
328:デフォルトの名無しさん
05/11/27 16:37:26
>>325
タココード見たことないのか？
お前がタコじゃないか？
329:デフォルトの名無しさん
05/11/27 17:08:41
>>328
おまえのように１か０かしか言わない奴っているよな
そして何も状況は変わらない
そりゃタコを育てる時間があったり、タコを入れ替えて優秀なマを入れる
余裕のある所はそうするのが最善だろうが
330:デフォルトの名無しさん
05/11/27 19:44:03
_＿ , －､/:::::::::::::::::::::l ヽ::::､:::::::::::::',::::::::::ヽ::::::::::::::::ヽ:::::::::::ヽ
／:::::::::::::t.- ､ﾉ::::::::::ｌ::::::::|::| ヽ::::i､:::::::::::､::::::::__ヽ:::::::::::::::｀､:::::::::::',
. / ::::::〃 }:::::::|:::l!::::::l|::| 丶:l.＼::::::::i＜::::::￣｀ヽ::::ｌ:::::ｌ::::::::::::i
i:::::::::::::;ｲ/｀ーr':::::::::!::|!::::::|lィ´ ヽ ＼:::ﾞ､ 丶::::ヽ＼:::::ｌ:::::l::::::::::::l
|::::::::::/ li ｌ::::::::::l:::ｌ|:／ !| ＼ ＼:ヽ ＼::', ﾞ､:::l:::::l::::::::::::!
. !:::::;:/ l! |::::::::::|::|ｲ:::| l:! ヽ_＿ ＼ ヽ::!､::l::::l::::::|
l::::l:! | |::::::::::l::| l:::! l __ 〃,￣::`ヽ､ ',::ﾍ:!-､:::::!
. ヽ|! ｜::::::::ｌ:| l:| ! ,, =＝､ {::::::::::ﾊ ヽ Ｙ ,ﾍ !:::|
!::!:::::l:l| l! 〃/´:::::ヽ い-‐ｸ 〈ヽ. ハ{
l:ｌ|:::::l:lヘ ｉ! {:;､_;;:::､} ｀¨´ !' ,.ｲ
l| l::::ト.{. `､ l! `ｰ-- ′ ,'r'´ l{
! ヽ:| ヽ. ﾍ ' /i{
｀iｰ､ 〃 おっちゃんら
}ハ _ ィl;{_ 悲観的な事ばっかやなぁ
` ､ ‘ ′ ,. '´ ヽ: :｀ｰ- ､ そんな人生おもろいかぁ?
｀j丁`i￢ｰ､‐ '´ ＼: :､: : :ヽ
,{ { : :∨ } ＿`_y: : : :.}_
／:! ヾ､ : :', _,.-‐'´￣: : : : :｀:ー--'j
/: : :| ヽ: } ／: : : :_;.-‐'´￣`ー- :___;ﾊ
/ : : :！ `ｆ‐'´:_;.-‐'´ i
331:デフォルトの名無しさん
05/12/04 11:56:55
そんな瑣末な方言の議論はさておき、メンバ変数のためだけに
set_xxxx,get_xxxx関数を作るのがコーディングに真の勝者なのだ。
332:デフォルトの名無しさん
05/12/05 02:24:34
全部インラインにしておけよ。遅いから。
333:ハーピィ
05/12/05 02:45:57
E・∇・ﾖﾉｼ ＜333ｹﾞｯﾄ♫
334:デフォルトの名無しさん
06/01/01 15:46:50
>>330
なんでオマエ関西風味よ？ｗ
335:デフォルトの名無しさん
06/01/05 09:59:06
>>331
プロパティ
336:デフォルトの名無しさん
06/02/03 16:12:47
節分です
337:デフォルトの名無しさん
06/03/15 06:14:52
STLの名前って最初がみんな小文字だから矢田
俺のクラスとか変数とか関数とか皆最初大文字なのに
統一できない
338:デフォルトの名無しさん
06/03/15 06:25:39
>>337
いっそ、std::find()→StdFind()みたいな置き換えインクルードファイルでも作ればいいじゃん。
#一度作ればずっと使えるわけだし。
339:デフォルトの名無しさん
06/03/15 21:16:58
>>338
自分の名前空間に入れろよ。
340:338
06/03/16 01:16:41
>>339
漏れに言うなよ。
341:デフォルトの名無しさん
06/03/18 17:51:12
>>338
言い方が冷たいよ…もっとお母さんみたいに言ってくれ。
342:338
06/03/19 17:05:02
すまん、言葉には聞いたことがあるのだが、それがどんなものなのか知らないんだ。
343:デフォルトの名無しさん
06/03/20 14:14:29
お母さんを知らずに育ったのか…(´・ω・) ｶﾜｲｿｽ
344:デフォルトの名無しさん
06/05/01 07:35:44
インライン関数は淫乱なのですか？
345:デフォルトの名無しさん
06/05/01 07:47:46
そうでもないよ。
346:デフォルトの名無しさん
06/05/01 09:18:33
クラスの変数をprotectedにするかprivateにするかで先輩と議論しなりました。
僕は派生されるクラスからもアクセスできるようにprotectedに入れたいのですが、
先輩はprivateにいれてアクセス用の関数を作るべきだといいます。
その方が変数名が変わったとき、派生クラスを直さなくてよいから、
というのが理由だそうですが、どうも納得行きません。
どうにか説得できないでしょうか？
347:デフォルトの名無しさん
06/05/01 09:21:05
>>346
protected は中途半端。
方針としては中途半端。
「見えちゃ嫌だけどちょっとは見えたほうが」
そんなの微妙すぎ。
348:デフォルトの名無しさん
06/05/01 09:28:09
>>346
protected な変数が必要になるのはカプセル化が弱いせいではないか？
よく考えることだ。
たとえば、変数を protected にするということは、何かしら
特別な意味を持った操作を想定しているのではないか？
そうだとしたら、変数は private にしてその操作を関数にするべきだ。
逆に見えてもいいってことは、どういじったところで問題ないんじゃないか？
そうだとしたら、その変数は public でいい。
どちらにも当てはまらないときだけ、 protected を使う根拠になる。
349:デフォルトの名無しさん
06/05/01 09:55:29
>>346
↓こんなのがエラーになるから嫌だ。
class B { protected: int n; };
class D : public B { int f(B& b) { return b.n; } };
350:デフォルトの名無しさん
06/05/01 09:58:46
>>1
Sleep(∞)
351:デフォルトの名無しさん
06/05/01 10:00:52
（・,Ｊ・）
352:デフォルトの名無しさん
06/05/01 12:47:56
派生クラスが親の変数にアクセスできなきゃ不便でしょうがなくない？
全部Set/Get関数使うの～？
353:デフォルトの名無しさん
06/05/01 13:16:38
>>352
だからそれは設計が悪いんだって。
354:デフォルトの名無しさん
06/05/01 14:50:36
いや設計とかじゃなくて…
355:デフォルトの名無しさん
06/05/01 15:19:07
// もしwings_がprotectedだとKiwiの羽が存在してしまうってことか?
class cBird {
cWings wings_;
public:
cWings const & wings() const {return wings_;}
void flap() const { ...; }
void fly() const { ...; flap(); ...; }
};
class cKiwi : public cBird {
public:
cWings const & wings(); // kiwi have no wings.
void flap() const; // kiwi can't flap.
};
class cPenpen : public cBird {
public:
void fly() const; // penpen can't fly.
};
// 書いてて知恵熱が出てきた
356:デフォルトの名無しさん
06/05/01 18:25:35
>>352
ユーザーがクラスのメンバにアクセスできなきゃ不便でしょうがなくない？
全部Set/Get関数使うの～？
って聞かれてる気分だ。
357:デフォルトの名無しさん
06/05/01 18:59:59
Personクラスに「名前」があって、もしprivateに置かれてたら
Personから派生したStudentは名前無しって事か。
学生は辛いな。
358:デフォルトの名無しさん
06/05/01 19:06:32
>>357
Person の「名前」が private なら、 Person に「名前」があることは
Person 以外だれも知らないから問題ない。
Person に「名前」ある（と外部が知っている）ということは、
Person の「名前」は public であるから Student が Person を
public 継承していれば何も問題ない。
359:デフォルトの名無しさん
06/05/01 19:18:41
>>355
private だとメンバ変数が消えるとでも思ってんの？
360:355
06/05/01 19:25:54
>>359
アクセスする手段がなければ存在しないのと大差ないでしょ。
見えなくするってのはそういうことかと思ったのだけど。
361:デフォルトの名無しさん
06/05/01 19:37:07
カプセル化ちゃんと学んだらどうだ。
362:デフォルトの名無しさん
06/05/01 19:38:22
>>360
アクセスする手段はそのメンバを持ってるクラスが提供するんだよ。
363:355
06/05/01 19:49:51
>>362
漏れが書いたコード見て言ってる?
規定クラスにはそういうI/Fを用意したけど、派生クラスで敢えてオーバーロードで潰しているんだけど。
もしかして>359=>361=>362?
喪前様のレスからは意味のある情報が一つも引き出せないのだけれど。
364:デフォルトの名無しさん
06/05/01 19:54:57
>>363
潰してる？アップキャスト一発で破綻するだろ？
365:デフォルトの名無しさん
06/05/01 19:57:17
>>358
>Person の「名前」が private なら、 Person に「名前」があることは
>Person 以外だれも知らないから問題ない。
StudentはPersonなんだから名前がある事を知っていた方がよくない？
privateだとStudentからも見えないわけだが。
Person has-a Name.
Student is-a Person.
よって、Student has-a Name.
366:デフォルトの名無しさん
06/05/01 20:09:16
>>365
> StudentはPersonなんだから名前がある事を知っていた方がよくない？
> privateだとStudentからも見えないわけだが。
そこで public にしないのは何故だ？
367:デフォルトの名無しさん
06/05/01 20:10:15
Person の「名前」って言っても、実際はデータメンバと参照用メソッドがあって
それぞれにアクセス制限を選ぶことが考えられる。
private なデータメンバと、 public な参照用メソッドがあるのが一般的だな。
protected の出番はなかなか思い当たらない。
368:デフォルトの名無しさん
06/05/01 20:48:09
ちなみにここで議論されていることって
何かにまとめられているの？
関係ないけどCをオブジェクト指向っぽくできないものかと
思案中・・・
一応組み込み向けの本でそれらしきのがあったのでそれを参考にしてますが・・・
369:デフォルトの名無しさん
06/05/01 20:56:01
>>368
「カプセル化」という基本事項にまとめられると思ってる。
クラスを作る意義のひとつだな。
C でオブジェクト指向なんてメンドクサイから C++ 使えよ。
370:デフォルトの名無しさん
06/05/01 21:16:24
pythonつかえ。
悩みから開放されるぞ。
「みんな大人だ」
371:デフォルトの名無しさん
06/05/02 02:38:05
「Cをオブジェクト指向っぽく」なら、せっかくだから Objective C 使え
C++ よりずっとセクシーだぞ
372:デフォルトの名無しさん
06/05/02 08:18:54
>>367
>protected の出番はなかなか思い当たらない。
派生クラスだけにアクセスさせたい変数はprotectedでいいのでは？
そうゆう変数って普通に沢山あると思うけど。
373:デフォルトの名無しさん
06/05/02 08:20:43
>>372 >>348
374:デフォルトの名無しさん
06/05/02 08:23:13
> そうだとしたら、変数は private にしてその操作を関数にするべきだ。
その関数を protected にするなら同じやん
375:デフォルトの名無しさん
06/05/02 08:25:42
>>374
同じだと思うなら private にしとけよ。
protected なデータメンバだと派生クラスから変更できてしまうからカプセル化が崩れる。
376:デフォルトの名無しさん
06/05/02 08:43:35
D&Eにもprotectedな変数を使うと駄目だというような事が書いてある。
377:デフォルトの名無しさん
06/05/02 10:41:38
これだな。
URLﾘﾝｸ(www.google.co.jp)
378:デフォルトの名無しさん
06/05/02 11:15:14
某別スレで以前、なんでもかんでもprivateにする奴はC++のど素人…みたいな事を
言ってる奴いたな
会社でそういうソースを見て頭がいたくなったとかなんとか
たいそうな達人ですなｗ
379:デフォルトの名無しさん
06/05/02 12:42:20
>>375
セオリーと現実の違いだと思う。
すべてをカプセル化するのは現実的にはオーバーヘッドが大きすぎる。
熟練したＣ＋＋プログラマならprivateとprotectedをきちんと使い分できる。
380:デフォルトの名無しさん
06/05/02 12:47:08
>>379
きちんと使い分けた場合 protected の出番はごく稀になると思うんだが、どうかね？
特にデータメンバにおいては皆無になるだろう。
381:デフォルトの名無しさん
06/05/02 12:49:28
>>379
inine がある C++ ではオーバーヘッド無しでカプセル化を実現可能じゃないか？
382:デフォルトの名無しさん
06/05/02 12:55:46
つまり、ここは一部の「熟練していると思い込んでいるC++プログラマ」が一人(或いは数人で)
強硬にカプセル化を否定しているのを、普通にC++を使えているプログラマ連中が
ﾆﾖﾆﾖしながら構っているのを、慣れてないC++プログラマが困惑しながら見守っている
スレだということで宜しいか。
383:デフォルトの名無しさん
06/05/02 12:56:17
いや全然違うけど。
384:デフォルトの名無しさん
06/05/02 14:45:25
>>381 ×inine ○inline
385:デフォルトの名無しさん
06/05/02 19:44:07
protectedを使う事が熟練Ｃ＋＋マだと勘違いする子が右往左往するスレ
386:デフォルトの名無しさん
06/05/02 20:26:09
俺もちょっと興味あるな。
誰か識者の人解説してくれないかな。
protectedとpublicの概念に、明確な違いがあるのなら。
387:デフォルトの名無しさん
06/05/03 08:01:23
public＝公共の場で全裸
protected＝自分ちで全裸
private＝風呂で全裸
家族になら見られてもいいって人はprotectedもアリだと思うよ。
388:デフォルトの名無しさん
06/05/03 08:08:33
継承を使わない奴にはprotectedは必要ない。
389:デフォルトの名無しさん
06/05/03 08:09:10
protectedだとうっかり窓から外の人に全裸が見えてｱｳﾁ。
390:デフォルトの名無しさん
06/05/03 08:21:25
>>389
具体例をきぼん
391:デフォルトの名無しさん
06/05/03 08:55:59
>>390
卑猥なやつだな。しかもageてるし。恥ずかしいだろ。
392:デフォルトの名無しさん
06/05/03 09:43:29
↑
恥ずかしいなら手術すればいいのに。
393:デフォルトの名無しさん
06/05/03 09:49:47
NVIパターンの話だな
394:デフォルトの名無しさん
06/05/03 12:40:52
protectedの使い道分かってない人って結構多いんだね…
ﾋﾞｸｰﾘ
395:デフォルトの名無しさん
06/05/03 13:20:15
>>394
じゃあお前が誰でも納得できるように説明してみろやカス
396:デフォルトの名無しさん
06/05/03 13:41:15
ヒント：継承
397:デフォルトの名無しさん
06/05/03 13:44:39
つーかツマンネ。
全部privateで書いて、とうしても必要になったらprotectedに変えればいいじゃん。
もっと面白いコーディングスタイルの話題は無いのか？
398:デフォルトの名無しさん
06/05/03 14:03:52
>>388
ﾌﾟ 設計が悪い事に気づいてない奴が一人
399:デフォルトの名無しさん
06/05/03 14:08:56
もうgetterとsetter書くの面倒だし全部publicで良くね？
eclipseのJDTみたいに、チェックボックスにチェック入れるだけで
getterとsetter書ける開発環境があればprivateにしてやるよ。
400:デフォルトの名無しさん
06/05/03 14:46:10
>>399
そんな奴がいるから VB とか C# にはプロパティなるものがあって、
Visual Studio にはプロパティ生成機能が付いてる。
401:デフォルトの名無しさん
06/05/03 14:58:28
>>397
自分が理解できない事には「ツマンネ」で終わらす気ですか？
402:デフォルトの名無しさん
06/05/03 15:54:37
EA買ってソース自動生成すれば？
403:デフォルトの名無しさん
06/05/03 15:59:26
そこまでいくとスレ違いじゃね
もう「コーディング」じゃなくなるから
404:デフォルトの名無しさん
06/05/03 20:13:12
そんなに手間を惜しみたいのなら#defineでゲッターセッター作れカス
405:デフォルトの名無しさん
06/05/03 21:55:12
コーディングスタイルを統一するためC/C++用のsource code formatter/beautifierを
使いたいんですが、Windows用でおすすめがあれば教えて下さい。
406:デフォルトの名無しさん
06/05/03 23:27:26
オブジェクトコンポジションで単純な委譲を使うとき、
移譲先が同じ翻訳単位内なら直にリンクしてくれたりするんですかね？
407:デフォルトの名無しさん
06/05/04 07:35:21
継承元は継承先にとって自分自身なんだから好きに出来て当然。
でも他人にはおれが分からないんだから、おれにアクセスするならコミニケーション取ってねって事でしょ。
だからおれは継承元クラスでは protected は結構使ってるな。
カプセル化を理由になんでもかんでも Set,Get なんでうざいだけじゃね？
408:デフォルトの名無しさん
06/05/04 07:36:25
コミュニケーションだな(/ω＼)
409:デフォルトの名無しさん
06/05/04 08:23:38
Gettter/Setterは単に値を読み書きして実装詳細を隠すだけではなく、
そこで値の検査をするなどと言ったこともできる、って当たり前のことだよな？
410:デフォルトの名無しさん
06/05/04 08:40:09
>>409
当たり前のことだな。カプセル化を否定してる訳じゃないよ。
でも値チェックするまでもないようなメンバとかも結構あるでしょ。
必要だと思う物はカプセル化してる。
使い勝手は人それぞれだけど、おれは直接アクセスできる方が便利だと思える箇所はそれなりにあるな。
こんなこと言うと、設計が甘いって言う人が出てくるんだけどな(´∀｀)
411:デフォルトの名無しさん
06/05/04 09:44:53
おれ的ルールはどうでもいい
412:デフォルトの名無しさん
06/05/04 10:02:59
おれを信じよ
413:デフォルトの名無しさん
06/05/04 12:58:12
おｋ
414:デフォルトの名無しさん
06/05/06 15:44:31
>>407
今までで一番まともな見解。
やっぱり仕事としてプログラマしてる人は分かってるね。
415:デフォルトの名無しさん
06/05/06 15:46:58
>>407
さすがプロの人の意見は参考になります（＞＜）
416:デフォルトの名無しさん
06/05/06 15:49:23
>407の人気に嫉妬
417:デフォルトの名無しさん
06/05/06 16:17:20
なにこの自作自演
418:デフォルトの名無しさん
06/05/06 23:06:40
抽象クラスのメンバ変数とか場合によってprotectにしてる
419:デフォルトの名無しさん
06/05/06 23:28:13
>>418
抽象クラスにメンバ変数はねーべ？
420:デフォルトの名無しさん
06/05/06 23:46:18
え？
421:デフォルトの名無しさん
06/05/06 23:50:35
な、なんだってー！
422:419
06/05/07 00:05:46
あーごめん。勘違いしてた。
423:デフォルトの名無しさん
06/05/07 16:02:23
なにこのｼﾞｻｶｰの巣窟ｗｗｗ
424:デフォルトの名無しさん
06/05/07 21:46:24
>>418
すればいいんじゃね？
425:デフォルトの名無しさん
06/05/07 21:48:34
抽象クラスだからって、 protected データメンバの出番が無いことに変わりはないね。
426:デフォルトの名無しさん
06/05/07 22:54:46
>>425
それはお前だけ。
427:デフォルトの名無しさん
06/05/07 23:13:03
>>426
じゃぁ抽象クラスと protected データメンバの関連って何なのさ？
428:デフォルトの名無しさん
06/05/08 07:17:41
まずは自分で調べようよ。
いつまでも教えて君のままじゃ進歩しないよ。
429:デフォルトの名無しさん
06/05/08 11:01:15
調べると >>376-377 みたいなのが出てくるわけだが。
430:デフォルトの名無しさん
06/05/08 12:06:18
こんなのもある。
URLﾘﾝｸ(www.gotw.ca)
> protected data is evil (this time with no exceptions). Why is it evil? Because...
431:デフォルトの名無しさん
06/05/08 20:10:15
確かに初心者には使わせない方がいいね。
protectedやfriendは上級者向き。
432:デフォルトの名無しさん
06/05/08 23:24:22
実装継承も上級者向き。
無茶なキャストも上級者向き。
goto も上級者向き。
上級者向きって言葉は便利だね。
433:デフォルトの名無しさん
06/05/08 23:44:23
上級者向きってことは、もっと経験をつめってことだからな。
婉曲表現大好き日本人。
434:デフォルトの名無しさん
06/05/09 00:39:01
>>431
リンク先読んだか？上級者とか関係ないよ。
435:デフォルトの名無しさん
06/05/09 00:49:36
private public は低級者向き。
436:デフォルトの名無しさん
06/05/09 01:42:20
議論がループしてる。
もうこのスレも終わりだなｗ
他の話題ないのかよｗｗｗ
437:デフォルトの名無しさん
06/05/09 01:46:27
過則勿憚改
自分の過ちを認める勇気も、技術者には必要だ。
438:デフォルトの名無しさん
06/05/09 02:28:36
過則勿憚改
自分の過ちを認める勇気も、技術者には必要だ。
439:デフォルトの名無しさん
06/05/09 15:52:40
過ぎたるは則ちフンドシ改めることなかれ
440:デフォルトの名無しさん
06/05/09 18:16:18
データも仮想関数も全く同じ理由でpublicにすべきではない
二つは同じ歴史をたどっている
データに関しては周知の通りだがそれが分かるには時間がかかった
Javaでさえ失敗している。仮想関数についても同じことになるだろう。
要するに一つの関数/クラスに一つの機能。
これを守るのはすごく難しい。たとえばconst_iterator。
これは明らかに一つのクラスが二つの機能を持っておりC++のコードを倍に増やした
名前が形容詞で修飾されていたらその関数/クラスの設計はたいてい間違っている
441:デフォルトの名無しさん
06/05/09 18:19:46
>>440
お前は何を言っているんだ？(ミルコ風
442:デフォルトの名無しさん
06/05/09 19:21:18
>>440
神
443:デフォルトの名無しさん
06/05/10 00:26:10
>>440
const_iterator が間違いだったとして、どうすれば正解だったの？
444:デフォルトの名無しさん
06/05/10 07:53:09
>>443
ヒント：protected
445:デフォルトの名無しさん
06/05/10 08:03:25
∩＿＿＿∩ ｜
| ノ＼ ヽ |
/ ●゛ ● | |
| ∪ ( _●_) ミ j
彡､ |∪| | Ｊ
/ ∩ノ ⊃ ヽ
( ＼ ／ ＿ノ | |
.＼ “ ／＿＿| |
＼ ／＿＿＿ ／
446:デフォルトの名無しさん
06/05/10 09:37:44
そもそも >>440 は論旨が不明瞭。
447:デフォルトの名無しさん
06/05/10 21:37:28
>>440
const_iterator が持ってる二つの機能って何？
448:デフォルトの名無しさん
06/05/10 22:15:58
constとiterator
449:デフォルトの名無しさん
06/05/10 22:22:03
>440
NVIは言いたいことは解らないでもないが、
今のところ、わざわざそうするべき状況に出会った事がないから実感が持てない。
>const_iterator
要素のconst性とコンテナのconst性のこと？
450:デフォルトの名無しさん
06/05/20 12:35:41
Cで組み込み系（ファーム開発など）をやってる人は
これを読んだらどう？
URLﾘﾝｸ(www.amazon.co.jp)
451:デフォルトの名無しさん
06/05/20 12:55:52
>>450
面白そうな本だね。俺、別に組み込み系とかやってるわけじゃないけど、
今度、本屋に行った時に読んで良さそうだったら買ってみるよ。
452:デフォルトの名無しさん
06/06/01 23:25:48
>>450
MMSといったら悪名高きDシリーズじゃないか。
453:デフォルトの名無しさん
06/06/29 06:20:08
>127あたり
vc++使っててchar(...)みたいなキャストができることを知って多用してます。
ほかでもOK？
454:デフォルトの名無しさん
06/06/29 06:23:13
アクセッサとメンバ。get～set～とかくのが面倒なのでこんな感じ
class Foo
{
int m_hoge;
int hoge() { return m_hoge; }
void hoge(h) { m_hoge = h; }
};
455:デフォルトの名無しさん
06/06/29 06:30:29
>>347 面白いんだけどスルーされてる？
456:デフォルトの名無しさん
06/06/29 08:01:47
>>453
関数型キャストはいつでも使えるわけではないし、折角C++には濫用防止の戒めを兼ねて
テンプレート型キャストがあるのでそちらを使うべきです。
実数値を整数値に丸めるときなんかは(仕様を承知で) int(sin(...))なんて使うのはありだと思いますが。
457:デフォルトの名無しさん
06/06/29 08:02:23
>>455
コピペに反応しろと?
458:デフォルトの名無しさん
06/06/29 09:59:51
>>457
あれってコピペなの？的確なレスだと思うけど。
459:デフォルトの名無しさん
06/06/29 11:28:34
>>458
URLﾘﾝｸ(google.co.jp)そんなの微妙すぎ
460:デフォルトの名無しさん
06/06/29 11:42:48
>>459
それは知ってる。っていうか、それ知らないと面白くない。
461:デフォルトの名無しさん
06/06/29 12:07:07
cは限りなく正解に近いw
462:デフォルトの名無しさん
06/06/29 18:12:19
>>453
その形式のキャストも標準Ｃ++のうち。正確にはコンストラクタ呼び出しの構文。
いまさらだけど、>>127
D&E読め、static_castの類はわざと読みにくく作られている。
463:デフォルトの名無しさん
06/07/01 17:36:38
実務でCのソースみると、グローバル変数を多用する
人がほとんどなんだけど、どうして？
構造体も使わないし、自分でやってて分け分からなく
ならないのかな？
グローバル変数多用派のご意見をお聞きしたい。
464:デフォルトの名無しさん
06/07/01 17:38:43
関数に引数を渡したりするのが面倒くさいんだろう。
465:デフォルトの名無しさん
06/07/01 18:32:19
>>463
過去の汚物を引き継いでるプロジェクトほどその傾向が強い。
一部の教条主義者はローカル変数は遅い、構造体は遅い、と信じていたりするし。
466:デフォルトの名無しさん
06/07/01 19:30:01
>>463
別言語がメインの開発者
467:デフォルトの名無しさん
06/07/01 21:42:19
あえて言語を特定しないのですね
468:デフォルトの名無しさん
06/07/02 20:55:31
>>454
趣味グラマ的には思いっきり環境依存してる‥‥
class Foo
{
int m_hoge;
int get_hoge() { return m_hoge; }
void set_hoge(h) { m_hoge = h; }
__property int hoge = { read=get_hoge, write=set_hoge };
};
469:デフォルトの名無しさん
06/07/02 23:46:12
>>468
他の環境に移植することが予め無いってわかってるんだったら仕事でも
処理系依存の機能を積極的につかってもいいと思うぞ。
470:デフォルトの名無しさん
06/07/04 19:09:54
スレッド間のフラグとか、めんどくさい時は
外部変数にしちゃってるわ。
471:デフォルトの名無しさん
06/07/05 11:12:03
>>463
プロジェクトの規模が小さいのでは？
まぁ、品質管理が最低なことには変わらんが・・・。
472:デフォルトの名無しさん
06/07/29 20:30:38
473:デフォルトの名無しさん
06/08/19 16:27:01
474:デフォルトの名無しさん
06/08/19 16:28:24
>>472 >>473
保守乙
475:デフォルトの名無しさん
06/08/23 08:51:36
空行，どんな感じで使う？
476:デフォルトの名無しさん
06/08/23 09:05:45