C/C++ Coding Style Thread

C言語、C++言語のコーディングスタイルについて
クールに語るスレッドです

特にこれから学習する人は、まだ独自の癖が付く前に
ｺﾞﾗｧされにくいコーディングスタイルを身につけましょう

#include <2c.h>

main(){
return 0;
}

int count, temp, data;
カンマの後にスペースを置き、空白の美を堪能する

if (foo > 10){
if, whileの直後もスペース推奨。関数との差別化を図る

if (...)
{
}
else
{
}

と書く奴はキモイ

>>4
int count, temp, data;
これは以下のようにするように推奨しているけど少数派かね。
int count= 0; //変数の意味を記述
int temp = 0;
int data = 0;
理由は、編集のし易と
int *a,b;とあったときにbをポインタと勘違いするミスを防ぐため。

if (...) {

} else if (...) {

} else {

}

クール。グルービー

if (...)
{ // ここにコメント
}
else
{ // ここにコメント
}

>>6
私もそのようにすることを推奨している。

>>6
ちなみに、ポインタは
int *a;
よりも
int* a;
を推奨している。

>>10
変数宣言構文の意味を勉強してから出直しな。

>>10
へ？　なんで？

>>11
出直すのは君の方ね。

if( ){

}
else if( ){

}
else{

}

これ、知ってからずっと愛用。
カッコの対応関係が見やすい。

まさか
int *a;
で、aの型は？って聞かれたらint型だなんて言わないよね。

if () {
　hoge; // 詰まってて見にくい
}

if () {
　　　　　　　// 空いてて見にくい
　hoge();
}

if ()
{
　hoge();　// 安心
}

>>10
そういうやつがいるから
int* a,b;
のbをポインタだと勘違いするやつが出てくるんだよ・・・

>>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;
という書き方は許されないから、間違うことはない。

int*a
は a が int* 型だという意味ではなく
*a が int 型だということは理解してる？

>>19
それは理解しているが、ポインタは用途が違う事が多いので、
扱いを変える必要がある。
ゆえに明記する。

>>18
そのルールを守っているプロジェクト内ではそれで完結できるが、
そいつが別のルールの(一行で複数宣言を許す)プロジェクトに移ったとき、
17みたいのを見て勘違いしないか？
文法を理解してないそいつが120%悪いが、世の中出来るやつばかりじゃないからな・・・。

>>21
もちろん、int* a;のような記述もコーディングルールの一部だから、
別のルールに従う必要があるときはそのルールに従うべきだよ。
int *a;と書かないといけないルールだったらそうすればよい。

勘違いしててもコンパイラの型チェックで引っかかるんで気づくんじゃない？

引っかからないようなコンパイラ使ってるプロジェクトなら、それこそ「アホはコード触るな」で。

だれかemacs用の2chスタイルを定義してください。

>>16
でも、そんなお前でもループは

while(1){
}

とか　

for(;;){

}

だろ？

if ( hoge ) {
;
} else {
;
}

>>25
ときどきスペース空けてくれ

っていうか、これに従え
http://www.sra.co.jp/wingnut/standards-j_toc.html#Top

俺も昔は>>8派だったけど、コードコンプリート読んでからぶらさがり型に変えたよ。

>>25
Java では if や while もそう書いてるが
C++ では全部>>16

for (int i=1; i<10; i++)
1+2-3*4/5

　　↑
どっちが見やすいですか？
　　↓

for (int i = 1; i < 10; i++)
1 + 2 - 3 * 4 / 5

>>31
for (int i=1; i<10; i++) 1+2-3*4/5 ;

>>31
後者

>>31
+ - の前後はスペース入れる
* / の前後は入れない。

>>34
それいいな

for ( int i = 1; i < 10; i ++ ) 1 + 2 - 3*4/5;

f(void)
f()
どっち？
Cでは意味が異なるんだっけ。
C++限定で。

10=18は重度な精神疾患です
以下処方箋

int* aでもかまわないのですが

int* a, b, c;
とか書かれるとその人はbやcもint*型と誤解しているのでは？と悪い印象をあたえます

素直に
int *a, b, c;
と書きなさい

宣言数が少ないならそれでいいけど、その他変数とポインタ変数とは使い道が
違うので、結果的に分けて宣言することが多くなると思う。

ただポインタは全部分けて書くっていうのはちょっとわからん。
> http://pc5.2ch.net/test/read.cgi/tech/1095180315/971

C++だと変数は必要になったタイミングで宣言できるから、
複数まとめて宣言する必要が無いんだよな。

Cだってブロック作ればどこにだって宣言できるもん！

>>38
全く直されるいわれはない。
これはスタイルの問題であり、開発者がコード見た時により見やすくするためのもの。
一行ごとに一つの変数を定義するというあらかじめ定義されたルールがある以上、
int *a,b,c;
なんていう書き方は許さないのだから、当然
int* a,b,c;
などとは書けない。
と何度も同じ事を書かないといけないのか？
int *a;なんていう書き方の方が全然素直ではない。
int型のポインタとint型を同じ行で定義するのは意味的に良くない。

↑ヴァカ？

＞結果的に分けて宣言する
＞int型のポインタとint型を同じ行で定義するのは意味的に良くない

まあ要するにこういうことだわな。
たまたま出来るからやりたければやればいいんじゃないのという。

int a, b, c;

と宣言しておいて
aは使う段階になったら

*(int *)a

とする
これで完璧

int *a = NULL;
*a がintなのにNULLで初期化というのも妙だしな。
int* a = NULL;
ならばしっくりくる。

>>44
>>42と>>39をいっしょにするなよ
>>39はポインタ変数の役割が他のIntと違うから別個に宣言すると言ってるだけ
>>42のほうは int と int* が別物だと考えている

>>47
全く理解できない
それより、病院いけ？

46=47
そんな理解でC/C++使わないでくれ

>>49
>46=47
そんな理解でレスしないでくれ

とりあえず >>43,48,49 はトリップつけてよ。
面倒だから。

>>int* a;
えー？！
じゃ、関数ポインタは
int(*) a(void) = NULL;
って書くんですか？

「変数名」と「他のもの」は離して書くよ。
関数ポインタならこうする

int (* fncptr)(void) = NULL;

>>53
> 「変数名」と「他のもの」は離して書くよ。
じゃあ
int * a;
って書けばいいんじゃない？

CとC++ならスタイルも変わってくると思う
Cなら
int *a, *b, *c;

C++なら使うときにひとつずつ
int* a = new int(hoge);

>>50
で、君はどこスレの600?

>>56
バカ、このスレの未来から来たんだよ。

もしかしてドライもんのおともだちだったりするんだ…

int a = val; を
int a; と a = val; を一緒にした書き方の延長線上で見てしまうと、

int *a = ptr; が
int *a; と *a = ptr; では、辻褄が合わなくなるので、

int* a = ptr; と書くようにすることで、
int* a; と a = ptr; が 最初のと同様の見方が出来るからじゃないの？

宣言時の *a と 代入時の *a では
括弧を省略できるため見た目同じでも
意味するところは異なるのが原因だと思うけど...

代入時は *(a) とでもする？

int* a, b, c;

>>59
>宣言時の *a と 代入時の *a では
>括弧を省略できるため見た目同じでも
>意味するところは異なるのが原因だと思うけど...

アフォ。
ではこれをどう説明するんだよ。

int a[] = {123, 345, 567};

今時int *aなんて書いてるのはおっさんCプログラマでしょ。
C++の勉強のためにWebでいろんなコード見てきたけど、ほとんどint* aだよ。
参照もint &aなんて書いてるのかな？

昔はint* aだったけど最近はint *aにするようにしてる
昔は単純なプログラムしか組めなかったからどっちでもよかったけど
constとか関数ポインタ、多重ポインタとか使うようになるとint *aのほうが都合がよくなる

int * a;
最強。

const int*と int const*って違いがよく分からん

a[b]とb[a]の違いみたいなもんだ。
俺はint constだけど、世間一般ではconst intのほうが主流かな。

constの位置が違うと全然違う意味だから

>>67
（ ・∀・）ﾆﾔﾆﾔ

char *const
char const*

最強は
char const * const

最強はvoid const*だろ

int *a,b,c;
決定

>>70
> 最強は
> char const * const

だな。const char * const だと、どうしてよ？って思っちゃうし。

突然ですが、三項演算子
(cond)
　? foo
　: bar;
です。ハテナとコロンは揃えます。
いじょ。

3項演算子って結局はif文と同じコンパイル結果になるから、一行で書かないなら
if文で書いた方がわかりやすいと思う。
3項演算子の利点は一行で最小限の文字数で書けるところだと思っているけれど。。

俺もそう思う。

if-else文と違って値を返すのが三項演算子の特徴なんじゃないの？
フロー制御だけならif-elseでいいけど。

値を返すならなおさら一行で書かないとややこしくなる気がする…

失礼。値は返します。
一列だと コロン が埋もれてしまい見た目に探すのがつらいです。
（異論あるんだろーな。。）

>>74
> です。ハテナとコロンは揃えます。

演算子の記号が行先頭にくるように改行するのはGNUコーディングスタンダードの
条件文の書き方に通じるものがあるね。
if (condA
&& condB
&& condC)
ってやつ。

>>42

> int型のポインタとint型を同じ行で定義する
間違い。


>>45
最悪。

>>45
最高。

>>77
禿同
値を使わないのなら三項演算子ではなく if-else を使うべし。
値を使う場合、if-else で書いた場合についても考えてみて、
複雑さが同程度だったら if-else を使う方が好ましい。

代入する値をわける場合とか、
if だと分岐したとき代入し忘れがあって怖い。
?:なら確実に代入できるので極力?:にしてる。
長くなりそうなら関数に抜き出して?:でディスパッチする。

checkstyle で使うなと起こられるのがつらい。

printf("....%c", .... eol?'\n':',');
みたいな使い方は？

>>85
便利だよねえ。

三項演算子使わないとreturnが増殖したりする所で使わないのはアフォだ

引数が長いときは
rhs.assign(
　　　　make_transform_iterator(lhs.begin(), thef)
　　　,　make_transform_iterator(lhs.end() , thef));←最後の「);」これをここにいつも書いてんだけどどうよ？

vector< vector<int> >←「vector<int>>」のエラー対策の為に空けるスペースを先頭にも空けるて揃えるのがお気に入り。

漏れなら
rhs.assign
(
　　make_transform_iterator(lhs.begin(), thef),
　　make_transform_iterator(lhs.end() , thef)
);

でも引数2個くらいなら
rhs.assign(make_transform_iterator(lhs.begin(), thef),
　　make_transform_iterator(lhs.end() , thef));

ぶっちゃけ、*の位置や改行なんかどうでもいい。
変数・関数名やスコープの最小化のほうが重要。

>>89
最初そう書こうかなと考えたこともあったんだけど
やたらと空白が目立って全体を眺めたら関数名との繋がりが希薄にかんじて････却下したんですよね。

>>90
それでも悪くは無いんですけど、
make_の開始位置が上と下じゃ揃わないから途中から書くのをやめました。ここじゃズレてましたけど・・・

最後の「));」を「) );」こうしてもいいですけどなんかしっくりこないんですよね。
じゃ改行か？と言ったら>>89に言ったような美徳センスが付きまとっていまいちなんですよね。

やっぱり個人差なのかな。

>>91
お前はナ。

ttp://www.01-tec.com/document/code_design/vol01.html
ここを参考にしながら書くのがよろしいかと

>>94に書いてあった
ブラケットでスコープわけって普通に使われてんの？

func()
{
　{
　　int a, b;

　}

　{
　　int c;

　}
}

>>95
俺は普通に使ってるけど

私もふつうに使っていますよ

ほんとだ。スコープ分けてるＹｏ。
96 名前：デフォルトの名無しさん[sage] 投稿日：04/10/03(日) 11:10:26
>>95
俺は普通に使ってるけど

97 名前：デフォルトの名無しさん[sage] 投稿日：04/10/03(日) 11:12:46
私もふつうに使っていますよ

わたくしも使っております　　　　（21歳　家事手伝い）

また山崎か。

>>95
普通だけど、私は使っていない

クラシックCの場合
int get_hoge_fuge(args...)
みたいな関数の命名ですが、特にget,setで始まる場合は
アンダースコア _ 入れるかどうか迷うんですよね。
私はいちおう「入れる派」なんですが
ライブラリにあるやつとか ex.) getchar, gethostbyname, ...
のきなみ続けて次の単語書いちゃってるし、
外は雨降りだし、Javaの人はいいなぁって思う今日この頃。

getHogeFugeって書けば解決

Shift同時押しは微妙にタイプ速度を下げるので大文字禁止、アンダーバーも禁止。
括弧は仕方が無いがもっと打ちやすいところにほしい。

>>104
シフトキーを使うのも億劫になる程の
タイピング量が必要になるコードの方を
まずは禁止すべきだな。

>>103
ラクダ記法はJavaコーディングスタイルだったっけ。

コメントの
/*
*
*/
と
/*
 *
 */
どっち？
アスタリスクが縦に揃うほうがいいなあ。

>>107
CやC++ではDoxygenに対応したコメント記法をするのが良いと思います。
後でDoxygenにかけることも考慮して。

>>108
doxygenって初めて知ったよ！
いいじゃん！
俺もこれからそうする！！

>>107
/*
comment
*/

Doxygen なら

/*!
\brief comment
*/

スペースが抜けてた
/*
　　comment
*/

Doxygen なら

/*!
　　\brief comment
*/

doxygenはjavadocスタイルの方が宮須行きがする。
\や!より@の方が目に優しい気がするような気がしないでもないかもしないかな、という気がした気がした。

自分も＠派。
JISだと'￥'になるのが悪いのかな。
'＼'なら'／'との組み合わせで見やすいのかも。

日本以外の人たちって \ が ＼なんだよな・・・。
目立たないし、文字列のなかでエスケープに使われてると激しく見にくくないかな・・・。

>>114
慣れるとそうでもない。TeXとか使っていると\の方が違和感があるかも

visualC++もバックスラッシュだよね（？）
確か...？

\よりもバックスラッシュのが好きだなあ。
特にパスの区切り文字としては見た目、\より直感的な気がします。
Win では \\ の代わりに / もパスの区切り文字として
使えるんですよね。タイプが楽だし気に入っているんだけど
ソースのポータビリティを考えたら、使わんほうがいいんでしょうね…。

>>117
一部のAPI（PathXXX系）が対応してないから使わないほうが無難だね。
Perlとかだと /＼r＼n/＼n/ とか読みにくくね？

別に読みにくくないよ?
日本のユーザ以外は皆バックスラッシュなわけだし。
むしろ、￥に慣れた人が英語情報を見るとそんなとこでもひっかかったりして
余計にとっつきが悪くなるんじゃないかと変な心配してしまうんだけど。

Unicodeで文字コード世界統一のはずなのに、日本だけ世界と一部違うものが
Unicodeとされているというのもなんだか悲しいよう。

為替レートとか外国で表示するとき\どうしてんだろう？

大体の場合0xA5がYEN SIGNだから、

今に至っては\の役割はもう無いね。
これからはバックスラッシュに変えていくべきだと思うんだけど。

Unicode?
たんにフォントの問題だろ

文字集合。

0x5CがYEN SIGNとして使われてしまうのはフォントの問題では済まないよ。

そのように使われないならその問題なくて
「日本人はなぜかバックスラッシュが見たくもないほど嫌いらしい。
どれくらいかというとバックスラッシュの代わりに円記号を表示させるくらい
嫌いらしい。」という程度の話になるけど。

アホですな。

みなさん、キャストは、

static_cast とか、reinterpret_cast　とか、使ってますか？

C++的に言えば、使った方がいいんだが、どう考えてもCキャストのほうが読みやすい。

使ってはいる。けれども同意。

>>127
Cスタイルキャストは禁止してる。
理由は以下のとおり。
・Cスタイルキャストは強力すぎる
・Cスタイルキャストは見つけにくすぎる
・Cスタイルキャストは dynamic_cast できない

ちなみに、どう考えたらCスタイルキャストのほうが読みやすいことになるのかわからない。

書きにくいってのならわかるね。
字数多いし。むしろ書きにくいから(ry

Cスタイルキャストに警告を出すコンパイラってあるかね？

あるよ。

dynamic_castをほとんど使ったことがない俺は
たぶん何か間違ってるんだと思う。

>>133
そんなことないと思う。
C++ の危険な領域に入り込んでいない健全な姿だよ。

キャストなんて使わないで済ますのが一番。
dynamic_cast の出番は、時間さえあれば設計を見直すべきところがほとんど。

protected データ メンバを宣言してはいけない
------------------------------------------------------------
ルールの理由:
private ではなくprotected としてデータ メンバを宣言すると、
メンバ関数中にカプセル化できたはずのメンバが派生クラスから見えてしまいます。

例
//
// protected データ メンバを宣言してはいけない
//
class A
{
　　protected:
　　int i; 　　// 違反
};

>>136
素人でつか？

>>136
「俺様ルールの違反」とちゃんと書け。

コンストラクタから直接グローバル データにアクセスしてはいけない
--------------------------------------------------------------------------------

ルールの理由:
異なるコンパイル単位中の静的オブジェクトの初期化順序は、
C++ の言語定義では定義されていません。
そのため、コンストラクタからグローバル データへのアクセスは、
未初期化オブジェクトからの読み取りになる場合があります。

例
//
//　コンストラクタから直接グローバル データにアクセスしてはいけない
//

int a;
class A
{
public:
　　A();
private:
　　int b;
};
A::A()
{
　　b = a; // 違反
}

かわいく書く。

for(i=0; i<100; i++){　　// 100回がんばる

}

かわいくに反応して“がんばる”が…くそっ俺の脳みそがぁぁ




かわいいじゃねぇか

>>129
const void *p;
const_cast<int *>(static_cast<const int *>(p));
こんなんだったらCスタイルキャストの方が読みやすいかもしれない

>>129
画像演算とか。
一つの式中にキャストが10個くらい現れたりする。
C++キャストでは長すぎて意図が分からなくなってしまう。
const_castはさすがにCキャストで代用しようとは思わないが、
PODに対するreinterpret_castやstatic_castはCキャストのほうが分かりやすい時もある。

>>142-143
カッコ悪いプログラムがカッコ悪いソースになる。それがいいんじゃねぇか。

>>139
いずれにしても a の初期化し忘れ。

>>145
aは0で初期化される

コボラーと大してレベル変わらんなお前ら

int *a, *b; // ポインタ
int a, b;

これ最強

C++ の const Class & や Class* は必ず typedef してから使う。

typedef const Class & ClassRef;
typedef Class* ClassPtr;

>>149
ウザ

二重インクルードヘッダーは、
"__" + プロジェクト名＋ファイル名
にする。

【例】
HelloWorld プログラムの Hello.h ファイルは、
#ifndef __HELLOWORLD_HELLO_H
#define __HELLOWORLD_HELLO_H
...
#endif
とする。

何が言いたいんだ…？
文句を言いたいのか、上記のように統一しろと主張しようとしてるのかわからんぞ

>>151
ISO/ANSI規格では識別子の初めに _ が2つ続く物はコンパイラ・ライブラリ関数のために予約されているので駄目だ。

>>153
"_" がふたつだけじゃなくて、ひとつでも予約されてるんじゃなかったっけ？
(つまり "_" で始まる名前はすべて標準ライブラリ用に予約されてる)

漏れのインクルードガードは、ファイル名 (ピリオドを '_' に
変換したもの) + '_' だな。大文字/小文字はそのまんまだ。

　#ifndef MotherHacker_h_
　#define MotherHacker_h_

ここで気になるのが #endif なんだけど

　a. #endif // !MotherHacker_h_　( '!' あり )
　b. #endif // MotherHacker_h_　( '!' なし )
　c. #endif　　( なんもなし )

てめーらはどれ派？
漏れは昔は c.，以前は b. だった。でも今は a. 派。

漏れは
#ifndef MOTHER_HACKER_H__
#define MOTHER_HACKER_H__

#endif// MOTHER_HACKER_H__

最後の_が２つなのがミソ

>>154
本当だ。
今まで'_'の次に英大文字か'_'の場合だけが予約かと思っていた

>>156
インクルードガードのときだけ例外的にb派。
#ifdef HOGEに対しては#endif // defined HOGEとしている。

漏れは
#endif // !defined( _suffix_hoge_h_included_ )

漏れは//にスペース入れない
  　#ifndef MotherHacker_h_
  　#define MotherHacker_h_
  　#endif//MotherHacker_h_
なぜって識別子の位置が揃うから

>>160
> なぜって識別子の位置が揃うから
うーん、気持はわからなくはないけど。
#elseや#endifに条件式をコメントとして入れとくのは、そもそも#ifの位置が
遠く離れてて把握できなくても条件式をすぐに理解できるようにするためでしょ？
そんな状況なら桁の位置が揃ってるかどうかなんて、どうでもいいと思うんだけど。
桁揃えが気になるような距離なら、そもそも条件式をコメントに書かなくてもいいし。

>>156
残念だがそのミソは予約されている。

【規約】
プリプロセッサ命令は #if や #ifdef の中ではインデントさせる。
ただし # は必ず行頭に配置せよ。

例：
#ifdef HOGE
# include <hoge.h>
# ifdef FOO
#  #include <foo.h>
#endif
#endif

>>164 なんで？なんかいいことあるの？

入れ子が複雑になっても、読みやすい、修正しやすい。
入れ子をベタで書くのはよくない作法だろ。

>>164
↓こんなんも、#だけ行頭に動かすの？
{
　while(...)
　{
　　if(...)
　　{
　　#if HOGE
　　　...;
　　#endif
　　　...;
　　}
　}
}

1カラム目以外に'#'があるとディレクティブと見做さないコンパイラがあったなぁ。

基本的に if 文は>>5のスタイルで書いているがキモいのか・・・？
>>7や>>14も嫌いではない。

俺は14の方がキモいと思う。
同じく普段は5を使っているが、行数制限があるときは7スタイルも使う。

このあたりはもう好みの問題でしょ。
個人的には>>14で書いてる。
>>5は、if の次に { だけの行がくるのがスカスカな感じでちょっといや。

>>5 のスタイルの方がネストしたときの括弧の対応がわかりやすいと思うけどなぁ・・・

Windows 2000 のコードとか、FFFTP なんかは、 >>5 のスタイルで書かれてるね

まぁ、>>14 の書き方でも絶対に間違わないって言う地震があるのならいいんじゃないの

好みの問題

私は>>7だな。

つまり>>5のやつが言葉を間違えたんだろ。キモイは言いすぎ。好みの問題でしかない。
俺は>>14だが。

>>14はなんだか中途半端な気がして、気持ち悪い。
なんか、切れそうで切れない生首のような、ほとんど首無しニックのような、気持ち悪さ。

>>5使ってるよ。

>5も好きじゃないんだが、
if (...)
　{
　　...;
　}
else
　{
　　...;
　}
って書かれるとどうもね。
#2段も下げるなって感じ?

>>177
GNUスタイルですな。慣れればいいのかもしれないが、


俺は>>7でタブは8カラム。以前までタブでなくスペース派
だったんだが、今はまあいいかなと思えるようになった。
タブを行頭にしか使わなければ環境依存も(ある程度)
許容できるし。

TABを使ったソースを別の環境で見たときに見た目が違うということがあっても
別に大した問題ではないだろう。
TABをスペースに置き換えるなんてエディタの機能で一発だったりするでしょ。
手間は大したこと無いから全然気にしないで、自分の環境で一番やりやすいやりかた
ですれば良いと思うよ。

CodeWizard とかの静的解析ツール使えばいいんじゃないの

流儀違うとCVSに落としたりするとき困るよな
全部2TAB→スペース変換してコミット

>>45 は

*(int *)&a

じゃないのか？

>>182
それじゃ a と同じになっちゃうだろ。

長い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
);

printfに限らず俺はインデントした上で右側にカンマ付けるけどな。
こうしている人の方が多いと思っているし。

継続行はCodeCompleteに倣って演算子を右に書く。

全体はApacheスタイルに近い。
タブは4カラムで、スペースじゃないけど。

ここは重複スレです

Cのマナーいろいろ
http://pc5.2ch.net/test/read.cgi/tech/1029584140/

>>187
仕切り厨ウザイ

こいつぼけ

>>189
おまえがな。

voidで返す関数はreturn書く？

voidで返す?

C++ならreturn void;

返り値がvoidならreturnは省略した方がコードが短くなって読みやすくなると思うんだけど。

そもそも値を返さないのがvoid

>>191
条件 return の場合以外書かない。

>>191
関数であると明確にするために、書いておく。

関数以外のものがあるわけじゃないのに…

pascalの癖が抜けないんだろう

>>199
悪いが、Pascalなんぞやったことないんだが。

>>200
無学を自慢するな

じゃ、VBか。

そもそも返り値がvoidの関数を作る事自体が間違えなんじゃないの？
処理は全部副作用だけなんて…

>>201
どこがどう自慢だったんだね？
むしろ謝っているとしか言えないが。

>>204
石黒級の馬鹿だな。まず日本語をなんとかしろよ。

>>205
何か日本語の使い方でおかしいところなんてあったか？
お前こそなんとかして反論しようとして
無理やり絞り出したようにしか見えんな。

もまいらもちつけ

低級な言い合いは止めてくれ

アセンブリはやっておくべきだよ

>>209
うまい

mov ax, 4c00h
int 21h

>>206
それ本気で言ってる？
もう必死すぎだなｗ

>>212
あまり強く言いすぎると、釣りってことにして逃げちゃって興醒めだよ。
真綿で首を絞めるみたいにイジらないと。

>>213
多分それ以前に>>212が釣りなんでは

そういうことは真綿で首を絞めてから言ってくれ。

日本語って言うならおれは>>203が気になるな。他でも見るが
「間違い」だろ？

>>216
本人だが同意

>>217
単純にtypo?

「Pascal やったことないと無学」ってことにしたい >>201 が
キチガイだったということで。

そりゃ無学だろ

http://www.page.sannet.ne.jp/mtoga/lang/c/text/bih-c_tf.txt
たまたま見つけた最悪なコードの見本。

アセンブラやったことないよ
パスカルやったことないよ
スクイークやったことないよ
シーシャープやったことないよ
セックルやったことないよ

一番ダメなプログラマーはどれ？

１５日C++とSTLとテンプレ使えるようになる苦行教えてくれ。
耐えて、使えるようになりたい。

>>223
AC++というつまらない本を熟読する

>>222
パスカルやったことないよ

Ruby知らないというのは致命的・

>>224
MC++ はどう？

pascalが何の単位か分からない奴は無学

ヘクトパスカル？

>>229
メガバイトって言っているのと同じだよ

>#define unint unsigned int /* 型名の 別名を定義します。 */
>#define unlong unsigned long

ﾜﾛﾀ

>>221、>>231のサイトって、中学生に教えている積もりなのか?
余りに痛々しいんだが。

ｋ

switch〜caseのインデントってどうしてる？
俺は

switch(n){
case 0:
　　cout << "0" << endl;
　　break;
default:
　　break;
}

caseとswitchのインデントレベルは同じにしてるけど。

>>234
タブを４として、スペース２個を入れる。

>>235
K&Rと同じにしてる。
つまり同じレベル。

同じにしてる。
基本的にインデントが一気に2段下がることが無いように頑張っている

俺は>>235と同じだな。

switch(n)
{
case 0:
　　cout << "0" << endl;
break;
default:
break;
}

俺はこう。
switch (n) {
case FOO:
　　foo();
　　break;

case BAR: {
　　int x = bar(n);
　　baz(x);
　　break;
}

default:
　　/* NEVER REACH HERE */
　　abort();
}

switch (n)
{
case FOO:
　　foo();
　　break;

case BAR
　　{
　　　　int x = bar(n);
　　　　baz(x);
　　　　break;
　　}
}
俺のスタイル。

switch (n)
{
case FOO:
　　foo();
　　break;

case BAR
　　{int x = bar(n);
　　baz(x);
　　break;
　　}
}
俺のスタイル。

そう言えばswitchとclassのインデントの付け方は同じになっている。

>>243
それがpublic、protected、privateのことなら俺も同じ。

b

switch (...) {
　case 1 : {
　　foo();
　} break;
　case 2 :
　case 3 :
　case 4 : {
　　foo();
　} break;
　case 5 :
　　foo();
　　// Fall Through
　default : {
　　foo();
　} break;
}
俺のスタイル。
switchは滅多に使わんがなー

↑馬鹿発見

>>246
そうかそうか、それは素晴らしい書き方だな。よーくわかったぞ。

>>247-248
必死だなｗｗｗｗ

switch (n)
{
case FOO:
　　foo();
　　break;
case BAR
{
　　int x = bar(n);
　　baz(x);
}
　　break;
}

>>250
おお、なんと感動的な書き方なんだ。正直、俺は感動した。

俺スタイルは>241に酷似。

switch (n)
{
case FOO:
　　foo();
　　break;

case BAR:
　　// baz(int&) の引数のために実体となる変数が必要 ← みたいに、なんかコメントしとく
　　{
　　　　int x = bar(n);
　　　　baz(x);
　　}
　　break;
}

漏れは>>250に似てるけどこうかな
switch(n)
{
case FOO:
{
　　foo();
　　break;
}
case BAR:
{
　　int x = bar(n);
　　baz(x);
　　break;
}
　　
}

禿は禿本で
case FOO:
    foo();
    break;
case BAR: {
    int x;
    bar();
    break;
}
こう書いてたっけ？
個人的には{で改行しない方が若干見やすいかなぁ

いまやC++は(boostの)シリアライズを持っているので
メンバ変数にhoge_と尻尾に_を付けるのではなく
一時変数に_を付ける
spiritのサンプルにあった。
メンバに堂々と何もつけないのはなかなか気持ちがよいな

>>255
> 一時変数に_を付ける

激しく受け入れ難い。

てかメンバもローカルも_無しでよくね？

↑禿同
this->が付いてたらメンバ。

>>258
技術的なメリット、デメリットでは this-> が最強なんだよな。
・クラステンプレートのコードでは付けないと恐ろしい罠に嵌りかねない。
・bool Is〜() な関数を自分で呼ぶときも this->Is〜() が読みやすい。
・無節操にメンバに触りまくって最適化を台無しにする糞コードが減る。

問題は、一般性が皆無なことだな。

this-> と等価な . （単項ドット演算子）を作って、
省略不可にすれば、・・・どうなっていただろう？

this必須でもいいけど、初期化リストのとこではthisつけられないよね？確か。

初期化リストならメンバか継承元であることが自明だから医院で内科医?

class AAA {
  int size;
public:
  AAA (int size)
    : size(size) // この行
  {}
};

こんなコードが通るのが微妙に気持ち悪かったり。
かといってメンバ名と仮引数名にうまく別の名前をつけられる妙案がない……。
this->size(size) って書ければ多少気持ち悪さも減るかと思ったの。そんだけ。

>259の案を採用して、
class AAA {
int size;
public:
AAA(int size) : .size(size) {}
};
はどう?
これも気持ち悪い?

> this-> と等価な . （単項ドット演算子）を作って、
> 省略不可にすれば、・・・どうなっていただろう？

視認性が悪いものを必須にするのはちょっとなぁ。
いっそPythonよろしく、メンバ(変数|関数)の参照はthis必須の方がまだまし。

それに、visitor.visit(this)があるから、thisキーワードを
なくせるわけじゃなし、見づらい構文糖衣の意味しかないと思われ。

this必須がコンパイラで強制できればそれでもいいんだけど、
そうじゃないならm_プレフィクスの方がいいな。

流れ斬り！

クラス内のメンバ関数の実体を書く順番は
a)宣言と同じ順に
b)重要なもの、呼ばれる頻度などの順に書き、宣言と順番が違う

c)宣言から b) の順で、実体はその順
d)んなもん気にしてない


他にオレ流あるなら追記ヨロ
あと、protected とかの種類別に分けてる or 分けてない？

>>266
漏れ的には、
1) public -> protected -> private の順で宣言も実装も行う
2) コンストラクタとデストラクタは全てのメンバ関数に先駆けて書く
という感じ。

全部宣言のところに実装も書く

メンバ関数の実装ではお互いに他のクラスの定義を必要とすることがよくあるので、
基本的に宣言は宣言だけ。
実装は別ファイル。
テンプレートを除いてインライン関数も使わない。

例外は3つあって、一つは単に値を返すgetter系。
もう一つはシグネチャの違う他のメンバ関数を呼ぶだけのようなもの。
3つめは初期化リストだけで済んでしまって中身が何もないコンストラクタ。
これらは宣言のところに実装も書いてしまう。

実装のファイルでは意味的なグループごとに関数を近接させる。
public等のアクセス修飾は関係なし。

メンバ変数だからって、特に目印はつけないのですか？

とりあえず >>257- は読んだのか？

漏れの場合、条件付きインラインとかの為にも、
ヘッダーには宣言だけ書いてる。インライン関数は全部.inlに。
見た目もすっきりするし、最適化とかデバッグの時に有利かと。

age

void
hoge()

か

void hoge()

か

識別子がクソ長かったら適当にこんな感じでバラしていく
return_type
　　function_name
　　　　(argument1_type argument1_name,
　　　　argument2_type argument2_name)
{
}

template <typename T>
void hoge(T arg)

>>276 の書き方もしくは、

template<typename T>
ReturnType
FunctionName(
　　ArgType1 arg1,
　　ArgType2 arg2)
{
}

for(int i = 0; i < n; i++) {
}

for(; ; ) {
}

無限ループでも、例外なく ; の後にスペースを空ける。

hoge

marudasi(lambda() {baka;} );
と書ける処理系作ったおれはスゴイ

まあシンタックスで困ることはほとんどないな
こだわる人は勉強してる人が多いけど

>>270
付けない
無くて困ると言う事は、クラスが巨大過ぎる気がする

>>282
付けてる人同士のソースの相互理解容易度の高さを知らないんだね
どんなに小さいクラスでも有用だよ。

俺はm_プレフィクス派だな。
1. 見てわかる
2. リファクタリング用の機能がなくても一気に置換できる
3. this->は長い上にどこかのメンバ関数の中でつけ忘れててもコンパイルでき
処理系で強制できない。

>>283
まあ、美意識の問題が大きいので（慣れもかな）
m_は、個人的に、異様に汚く見える（あくまで主観）
ローカル変数は、宣言即初期化派＆＆
それが追い辛くなるほどメソッドを大きくしない派
なので、メンバ変数と区別が付かない||相互理解が不便なんて事は無い

>>285
きこえてアムロ？メンバ変数とローカル変数を見分けるまでの作業量が全然違うのよ。
単純化するためにグローバル変数とかスタティック変数とかは抜きにして説明すると

■メンバ変数とローカル変数に命名方法の区別をしない場合
1) ある変数を見る。
2) その変数より前の部分を関数のはじめまでみる
3) 途中に宣言があればローカル変数、引数に指定されてれば引数、どちらでもなければローカル変数と決定できる。

■プリフィックス又はサフィックスでメンバ変数のみ印付けをしている場合
1) ある変数を見る
2) その変数に印付けがされていればメンバ変数、そうでなければローカル変数か引数

上下方向への視点の動きがまったく発生しなくなるのがおわかりいただけて？

俺も、m_ はマイクロソフト系ツール使うまで、全く不要と思っていたが、使い始めるとやめられなくなる。

>>286
否、だから・・・
＞上下方向への視点の動きが
そんな事が邪魔になる様なコードを書かないって話。
逆に、それで解りづらくなると、メソッドの構成とかを見直すから
無い方が良い気もしないでもない。。

見分けが解りやすいと、その辺が鈍感になる


それから
＞1) ある変数を見る。
＞2) その変数より前の部分を関数のはじめまでみる
こんな追い方しなきゃいかんと言う事は
メソッドが長すぎるんでないかい？？

さらに、それから、別にm_を否定してる訳ではない、念の為

>>288
視点って目が見てる部分のことだよ？
速読術でもやってる人ならわからないけど
普通の人間は"面"全体を注目することはできない。
文章の中やコードの中であれば、一行しか注目はできないの。
ここまでOK？

ある変数名に注目してしまった時、
コードが2行以上ならばもう他の行は同時には注目できないでしょう？
そのある変数名に注目した段階で判別できる方法が
何らかのプリフィックスやサフィックスを使う方法で、
一度別の部分に注目する場所を移してから判別するより
遥かに効率がいいの。

あなたのコードが全てベーマガに掲載されそうな一行コードならいいんだけど。

＞文章の中やコードの中であれば、一行しか注目はできないの。
？
人間の視点って「"面"全体」は見ること出来ないけど
「ある程度のかたまり」で認識できると思うけど
逆に、「一行しか」って注目は難しい気がする
横だけの集合だけ注目度が高くなるのも
ちょっと不思議な気がしないでもない

標準の set を実装する場合など、自然な命名だと
メンバ変数に size なんてのが置きたくなって
メンバ関数の size() と被ってしまう。
m_ はそんな時にも助けになる。

size_

>>292 流れを読むようにしような。

>>290
結局"おれはm_とか付けたくない"っていう結論ありきで
相手の話を理解しようとして聞いてないじゃない
あんたはソースの中に縦書きでも探してれば？

それとも縦書きに釣られすぎて横方向に文字読みながら
縦方向にも縦書きを探せるなんてかわいそうな
特殊技能でも身に着けちゃってるのかね

まあしょせんハンガリアン命名記法だから、いまさら論争自体がなあ。
コードレビューとして考えて意味の把握のしやすさのほうが問題で、
個人的には単純に視点の移動を作業量と考えるのはメリットが無い。
絶対的な利便性があるわけでもなく、強制はナンセンス。
そうしたい人だけそうすれば。

>そうしたい人だけそうすれば。
訂正、そういう規約がある/必要な場合にその人が守ればいいだけ。

m_ プリフィックスをハンガリアンとか言ってる時点で見識のレベルの低さが露呈してるんだけどね。

所詮、ローカルルールでしょ

わたしも、所詮ローカルルールと言う意味などでハンガリアンみたいなもの
と言ってるのだが、
>>297
ほう、見識が高いと、m_ プリフィックスはハンガリアンではないと?
それはそれで言い分があるかもしれないから、まともに見識のあることを
喋ってごらん。喋れるなら。通じない根拠や相手の非難だけにすり替えないで。

>>299
別におれは297じゃないんだけどさ。

もとの書き込み(>295)では「みたいなもの」などと言わずに、そのものだと言い切っている。
「ハンガリアンはプリフィックス」は真だと思うが、
「プリフィックスはハンガリアン」とは言えないだろう。

「ごめんなさい」が言えない人ですか？

> 「ハンガリアンはプリフィックス」は真だと思うが、
> 「プリフィックスはハンガリアン」とは言えないだろう。

ごめん、「m_ プリフィックス」ってなってるのを見落としてた。
「m_ プリフィックス」はハンガリアンじゃなくて
ただのメンバ変数を表すプリフィックスだから
言いたいことは同じだけどね。

>>299
m_プリフィックスがハンガリアンだという資料があれば俺に教えて欲しいくらいだ。
まず君はここらへんから読みたまえ。
http://www.radiumsoftware.com/hungarian_notation.html
メンバ変数か否かというのはC/C++言語における"型"かね？
そうではないだろう？

>>300-302
なんだ、見識どうこうといって、やはりその話なんだ。
もちろん m_ がオリジナルな意味での Hungarian Notation でないのは
ttp://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvs600/html/hunganotat.asp
もともと否定しない。しかし(少なからぬ人と同じように)スコープを示す
一種の拡張ハンガリアンとしてのローカル規約であると捉えるので、
ttp://msdn.microsoft.com/library/default.asp?url=/library/en-us/stg/stg/coding_style_conventions.asp
m_ どうこうの強制や論争自体がナンセンスであると。
(たいてい賛成派もきちんと理由を挙げられない)
で、別に m_がハンガリアンであろうとなかろうと論旨には全く関係無いが、
そういうところを見識といって揶揄するぐらいしかできないと?

>>303
なんかスレが伸びてると思えば。もう頭悪いね君としか言いようがないな。

1. m_ はcoding style convensionであって、属性をコード化するハンガリアン
とは関係ない(ハンガリアンの延長線上と看做す向きもあるが見解の分かれる
ところであるし、個人的には牽強附会と思う)。
論争が意味ないとかいうのは一連の議論を否定するただの煽りでしかなく、
m_プレフィクスの無用性について意味のある主張をしたいのなら命名法で
区別することによるメリットがないことを示せ。もしくは>>295の
> コードレビューとして考えて意味の把握のしやすさのほうが問題で、
というのがm_プレフィクスにより激しく損われるという論拠でもよい。
(それが他人にとってm_プレフィクスの有用性に優越するかどうかは別の問題だ
が、個人・場合による問題なので異なる見解が両立し得る)
一般のハンガリアン記法の適用を否定する主張としては一理あるが、我々は
m_プレフィクスについての議論をしているのであり、ハンガリアンの延長線上と
君が看做したからといって盲目的に適用するのは無茶と言うもの。

2. ただの煽りでしかなければ見識がないと言われるのは必然である。しかも
> で、別に m_がハンガリアンであろうとなかろうと論旨には全く関係無いが、
という主張は
> まあしょせんハンガリアン命名記法だから、
で始まる>>295自体の意味を否定する。即ち>>295が無意味な煽りであり、295には
見識がないということを自分で立証している。

3. ちゃんと理由は挙げられているのに個別に反証することなく
> (たいてい賛成派もきちんと理由を挙げられない)
と書いているのは他人のレスをろくに読みもしていないことを立証している。

>1.
>ハンガリアンの延長線上と看做す向きもあるが見解の分かれる
>ところであるし、
>(それが他人にとってm_プレフィクスの有用性に優越するかどうかは別の問題だ
>が、個人・場合による問題なので異なる見解が両立し得る)
つまりどちらかの立場をとること自体に問題は無い。
>区別することによるメリットがないことを示せ。
すでに>>288等(295とは別人)も繰り返してるだろう。
結局"おれはm_と付けてる"っていう結論ありきで
相手の話を理解しようとして聞いてないじゃない
#288等補足:
#コードレビューとして考えて意味の把握のしやすさのほうが問題で、
#個人的には単純に視点の移動を作業量と考えるのはメリットが無い。
#(個人的には可読性が落ちるケースが少なくない。m_をつけて
#よしとして全体としての意味をとりにくい名前のままの事があるから、
#とも思っている)
>2.
煽られたと思うところ、喰いつきやすそうな所だけ問題にしたい、と。
<絶対的な利便性があるわけでもなく、強制はナンセンス。
<そういう規約がある/必要な場合にその人が守ればいいだけ。
>3. ちゃんと理由は挙げられているのに個別に反証することなく
ええと、そのちゃんとというのは >>286,289 あたりですか?
(直後にも反論(?)ついてるようですが)

君、謝っちまったほうが楽になるよ。
自分の価値が下がるわけじゃない。むしろ上がるさ。

>>306
"おれはm_と付けてる"から揶揄に終始しますと。ご苦労様です。
別にまともな論が無かろうと、そういう規約がある/必要な場合に
そうするのは止めやしない。まこといまさら論争自体がナンセンス。

俺、どっちが悪いとか言って無いのになぁｗｗｗ
食いついた方が、実は自分が不利だと悟ってる方だと思って
書き込んでみたがこううまくいくとは思わなかった。

ほほーぅ、それでそれで？

結論: 295はアフォ。
そろそろ次の話題行きましょ。

305はあれで反論したつもりになってるんだろうか。
自分で相手の主張を肯定していることに気がつかない頭の弱さｶﾜｲｿｽ。

>>274
後者。grep で関数名引いた時、返す型が表示されないってのは
かなり痛い。

>>312
つ grep -B 1

>>308
レス先書かなきゃ、直前のレス宛だと考えるのが普通ですよ。

こういうのがわからない人のコードって、さぞ自分勝手なんだろうな :-)

m_とかg_とか付けるとかってさぁ、自分だけでプログラムしてるならいいけど
多人数で作ってると付けて欲しいんだよね。
人によってスタイル違うしクラスからグローバル変数使いまくりな
タココード書く奴が足引っ張って大変。
メンバ関数内で何も付けずにローカル、メンバ、グローバル変数が
入り乱れた他人のコードを追うのはきついぞ。
そんなので新人がマルチスレッドのコード書くもんだからたまらん。
何も付けない派の奴らにお見舞いしたいコードだ。

>>315
それはプレフィクスごときで解決する問題じゃないと思うが……

多人数で作るならある程度のコンベンションを決めるのは当たり前だと思う
m_ でも g_ でも付けないでもいいから、とにかく揃えておくというのが重要かと

タココードを書くやつがいるというのは別問題だな

グローバル変数はそれなりに存在価値がある。
staticメンバ変数として隠蔽されていた方が、かえって追跡しにくい場合もある。
タココードの場合は、独自の名前空間にいれるよう強要すれば問題解決でしょ・・・多分。

ま、手軽に、using namespace xxx を
グローバルスコープで宣言された日には手も足もでないんだけどね。

>>318
> グローバル変数はそれなりに存在価値がある。
> staticメンバ変数として隠蔽されていた方が、
> かえって追跡しにくい場合もある。

具体的にどんな場合？

>>318
タコかどうかなんて、ほぼ書き上げられたソースを見るまで
判らん場合もあるわけで

Socketまわりなんかタコどころか糞コードだからな

逆に言えば（当然のことながら）
ネーミングルールを決めただけでタココード/糞コードがそうでなくなることなど無い

>>323
・・・確かに。
タコのタコたる所以は、命名ルール無視などという生易しいものではない罠。

タココードでもネーミングルール守っていてくれれば、まだマシなのでは？

グローバルやstatic変数にコールバック関数が入り乱れる自分にしか
理解できないコードを書く奴を抑止できる状況にもっていけない
場合は多々ある。せめてg_だけでもいいから付けてくれ。
予期せぬ不具合はグローバルがらみが多すぎる。

蛸コード書く香具師のプレフィックスほど当てにならないものはない。
結局、自分で検索してマーキングした方が間違いなかったりする。

>>325
タココード見たことないのか？
お前がタコじゃないか？

>>328
おまえのように１か０かしか言わない奴っているよな
そして何も状況は変わらない
そりゃタコを育てる時間があったり、タコを入れ替えて優秀なマを入れる
余裕のある所はそうするのが最善だろうが

　　 _＿　, −､/:::::::::::::::::::::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

そんな瑣末な方言の議論はさておき、メンバ変数のためだけに
set_xxxx,get_xxxx関数を作るのがコーディングに真の勝者なのだ。

全部インラインにしておけよ。遅いから。

E・∇・ﾖﾉｼ　＜333ｹﾞｯﾄ♫

>>330
なんでオマエ関西風味よ？ｗ

>>331
プロパティ

節分です

STLの名前って最初がみんな小文字だから矢田
俺のクラスとか変数とか関数とか皆最初大文字なのに
統一できない

>>337
いっそ、std::find()→StdFind()みたいな置き換えインクルードファイルでも作ればいいじゃん。
#一度作ればずっと使えるわけだし。

>>338
自分の名前空間に入れろよ。

>>339
漏れに言うなよ。

>>338
言い方が冷たいよ…もっとお母さんみたいに言ってくれ。

すまん、言葉には聞いたことがあるのだが、それがどんなものなのか知らないんだ。

お母さんを知らずに育ったのか…(´・ω・) ｶﾜｲｿｽ

インライン関数は淫乱なのですか？

そうでもないよ。

クラスの変数をprotectedにするかprivateにするかで先輩と議論しなりました。

僕は派生されるクラスからもアクセスできるようにprotectedに入れたいのですが、
先輩はprivateにいれてアクセス用の関数を作るべきだといいます。
その方が変数名が変わったとき、派生クラスを直さなくてよいから、
というのが理由だそうですが、どうも納得行きません。
どうにか説得できないでしょうか？

>>346
protected は中途半端。
方針としては中途半端。
「見えちゃ嫌だけどちょっとは見えたほうが」
そんなの微妙すぎ。

>>346
protected な変数が必要になるのはカプセル化が弱いせいではないか？
よく考えることだ。

たとえば、変数を protected にするということは、何かしら
特別な意味を持った操作を想定しているのではないか？
そうだとしたら、変数は private にしてその操作を関数にするべきだ。

逆に見えてもいいってことは、どういじったところで問題ないんじゃないか？
そうだとしたら、その変数は public でいい。

どちらにも当てはまらないときだけ、 protected を使う根拠になる。

>>346
↓こんなのがエラーになるから嫌だ。
class B { protected: int n; };
class D : public B { int f(B& b) { return b.n; } };

>>1
Sleep(∞)

（・,Ｊ・）

派生クラスが親の変数にアクセスできなきゃ不便でしょうがなくない？
全部Set/Get関数使うの〜？

>>352
だからそれは設計が悪いんだって。

いや設計とかじゃなくて…

// もし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.
};
// 書いてて知恵熱が出てきた

>>352
ユーザーがクラスのメンバにアクセスできなきゃ不便でしょうがなくない？
全部Set/Get関数使うの〜？

って聞かれてる気分だ。

Personクラスに「名前」があって、もしprivateに置かれてたら
Personから派生したStudentは名前無しって事か。
学生は辛いな。

>>357
Person の「名前」が private なら、 Person に「名前」があることは
Person 以外だれも知らないから問題ない。

Person に「名前」ある（と外部が知っている）ということは、
Person の「名前」は public であるから Student が Person を
public 継承していれば何も問題ない。

>>355
private だとメンバ変数が消えるとでも思ってんの？

>>359
アクセスする手段がなければ存在しないのと大差ないでしょ。
見えなくするってのはそういうことかと思ったのだけど。

カプセル化ちゃんと学んだらどうだ。

>>360
アクセスする手段はそのメンバを持ってるクラスが提供するんだよ。

>>362
漏れが書いたコード見て言ってる?
規定クラスにはそういうI/Fを用意したけど、派生クラスで敢えてオーバーロードで潰しているんだけど。

もしかして>359=>361=>362?
喪前様のレスからは意味のある情報が一つも引き出せないのだけれど。

>>363
潰してる？アップキャスト一発で破綻するだろ？

>>358
>Person の「名前」が private なら、 Person に「名前」があることは
>Person 以外だれも知らないから問題ない。


StudentはPersonなんだから名前がある事を知っていた方がよくない？
privateだとStudentからも見えないわけだが。

Person has-a Name.
Student is-a Person.

よって、Student has-a Name.

>>365
> StudentはPersonなんだから名前がある事を知っていた方がよくない？
> privateだとStudentからも見えないわけだが。

そこで public にしないのは何故だ？

Person の「名前」って言っても、実際はデータメンバと参照用メソッドがあって
それぞれにアクセス制限を選ぶことが考えられる。
private なデータメンバと、 public な参照用メソッドがあるのが一般的だな。
protected の出番はなかなか思い当たらない。

ちなみにここで議論されていることって
何かにまとめられているの？

関係ないけどCをオブジェクト指向っぽくできないものかと
思案中・・・
一応組み込み向けの本でそれらしきのがあったのでそれを参考にしてますが・・・

>>368
「カプセル化」という基本事項にまとめられると思ってる。
クラスを作る意義のひとつだな。

C でオブジェクト指向なんてメンドクサイから C++ 使えよ。

pythonつかえ。
悩みから開放されるぞ。

「みんな大人だ」

「Cをオブジェクト指向っぽく」なら、せっかくだから Objective C 使え
C++ よりずっとセクシーだぞ

>>367
>protected の出番はなかなか思い当たらない。

派生クラスだけにアクセスさせたい変数はprotectedでいいのでは？
そうゆう変数って普通に沢山あると思うけど。

>>372 >>348

> そうだとしたら、変数は private にしてその操作を関数にするべきだ。

その関数を protected にするなら同じやん

>>374
同じだと思うなら private にしとけよ。
protected なデータメンバだと派生クラスから変更できてしまうからカプセル化が崩れる。

D&Eにもprotectedな変数を使うと駄目だというような事が書いてある。

これだな。
http://www.google.co.jp/search?q=%22you+don%27t+have+to+use+protected+data+in+C%2B%2B%22

某別スレで以前、なんでもかんでもprivateにする奴はC++のど素人…みたいな事を
言ってる奴いたな
会社でそういうソースを見て頭がいたくなったとかなんとか
たいそうな達人ですなｗ

>>375
セオリーと現実の違いだと思う。
すべてをカプセル化するのは現実的にはオーバーヘッドが大きすぎる。
熟練したＣ＋＋プログラマならprivateとprotectedをきちんと使い分できる。

>>379
きちんと使い分けた場合 protected の出番はごく稀になると思うんだが、どうかね？
特にデータメンバにおいては皆無になるだろう。

>>379
inine がある C++ ではオーバーヘッド無しでカプセル化を実現可能じゃないか？

つまり、ここは一部の「熟練していると思い込んでいるC++プログラマ」が一人(或いは数人で)
強硬にカプセル化を否定しているのを、普通にC++を使えているプログラマ連中が
ﾆﾖﾆﾖしながら構っているのを、慣れてないC++プログラマが困惑しながら見守っている
スレだということで宜しいか。

いや全然違うけど。

>>381 ×inine ○inline

protectedを使う事が熟練Ｃ＋＋マだと勘違いする子が右往左往するスレ

俺もちょっと興味あるな。
誰か識者の人解説してくれないかな。
protectedとpublicの概念に、明確な違いがあるのなら。

public＝公共の場で全裸
protected＝自分ちで全裸
private＝風呂で全裸

家族になら見られてもいいって人はprotectedもアリだと思うよ。

継承を使わない奴にはprotectedは必要ない。

protectedだとうっかり窓から外の人に全裸が見えてｱｳﾁ。

>>389
具体例をきぼん

>>390
卑猥なやつだな。しかもageてるし。恥ずかしいだろ。

↑
恥ずかしいなら手術すればいいのに。

NVIパターンの話だな

protectedの使い道分かってない人って結構多いんだね…
ﾋﾞｸｰﾘ

>>394
じゃあお前が誰でも納得できるように説明してみろやカス

ヒント：継承

つーかツマンネ。
全部privateで書いて、とうしても必要になったらprotectedに変えればいいじゃん。
もっと面白いコーディングスタイルの話題は無いのか？

>>388
ﾌﾟ　設計が悪い事に気づいてない奴が一人

もうgetterとsetter書くの面倒だし全部publicで良くね？
eclipseのJDTみたいに、チェックボックスにチェック入れるだけで
getterとsetter書ける開発環境があればprivateにしてやるよ。

>>399
そんな奴がいるから VB とか C# にはプロパティなるものがあって、
Visual Studio にはプロパティ生成機能が付いてる。

>>397
自分が理解できない事には「ツマンネ」で終わらす気ですか？

EA買ってソース自動生成すれば？

そこまでいくとスレ違いじゃね
もう「コーディング」じゃなくなるから

そんなに手間を惜しみたいのなら#defineでゲッターセッター作れカス

コーディングスタイルを統一するためC/C++用のsource code formatter/beautifierを
使いたいんですが、Windows用でおすすめがあれば教えて下さい。

オブジェクトコンポジションで単純な委譲を使うとき、
移譲先が同じ翻訳単位内なら直にリンクしてくれたりするんですかね？

継承元は継承先にとって自分自身なんだから好きに出来て当然。
でも他人にはおれが分からないんだから、おれにアクセスするならコミニケーション取ってねって事でしょ。
だからおれは継承元クラスでは protected は結構使ってるな。
カプセル化を理由になんでもかんでも Set,Get なんでうざいだけじゃね？

コミュニケーションだな(/ω＼)

Gettter/Setterは単に値を読み書きして実装詳細を隠すだけではなく、
そこで値の検査をするなどと言ったこともできる、って当たり前のことだよな？

>>409
当たり前のことだな。カプセル化を否定してる訳じゃないよ。
でも値チェックするまでもないようなメンバとかも結構あるでしょ。
必要だと思う物はカプセル化してる。
使い勝手は人それぞれだけど、おれは直接アクセスできる方が便利だと思える箇所はそれなりにあるな。
こんなこと言うと、設計が甘いって言う人が出てくるんだけどな(´∀｀)

おれ的ルールはどうでもいい

おれを信じよ

おｋ

>>407
今までで一番まともな見解。
やっぱり仕事としてプログラマしてる人は分かってるね。

>>407
さすがプロの人の意見は参考になります（＞＜）

>407の人気に嫉妬

なにこの自作自演

抽象クラスのメンバ変数とか場合によってprotectにしてる

>>418
抽象クラスにメンバ変数はねーべ？

え？

な、なんだってー！

あーごめん。勘違いしてた。

なにこのｼﾞｻｶｰの巣窟ｗｗｗ

>>418
すればいいんじゃね？

抽象クラスだからって、 protected データメンバの出番が無いことに変わりはないね。

>>425
それはお前だけ。

>>426
じゃぁ抽象クラスと protected データメンバの関連って何なのさ？

まずは自分で調べようよ。
いつまでも教えて君のままじゃ進歩しないよ。

調べると >>376-377 みたいなのが出てくるわけだが。

こんなのもある。
http://www.gotw.ca/gotw/070.htm
> protected data is evil (this time with no exceptions). Why is it evil? Because...

確かに初心者には使わせない方がいいね。
protectedやfriendは上級者向き。

実装継承も上級者向き。
無茶なキャストも上級者向き。
goto も上級者向き。

上級者向きって言葉は便利だね。

上級者向きってことは、もっと経験をつめってことだからな。
婉曲表現大好き日本人。

>>431
リンク先読んだか？上級者とか関係ないよ。

private public は低級者向き。

議論がループしてる。
もうこのスレも終わりだなｗ
他の話題ないのかよｗｗｗ

過則勿憚改

自分の過ちを認める勇気も、技術者には必要だ。

過則勿憚改

自分の過ちを認める勇気も、技術者には必要だ。

過ぎたるは則ちフンドシ改めることなかれ

データも仮想関数も全く同じ理由でpublicにすべきではない
二つは同じ歴史をたどっている
データに関しては周知の通りだがそれが分かるには時間がかかった
Javaでさえ失敗している。仮想関数についても同じことになるだろう。
要するに一つの関数/クラスに一つの機能。
これを守るのはすごく難しい。たとえばconst_iterator。
これは明らかに一つのクラスが二つの機能を持っておりC++のコードを倍に増やした
名前が形容詞で修飾されていたらその関数/クラスの設計はたいてい間違っている

>>440
お前は何を言っているんだ？(ミルコ風

>>440
神

>>440
const_iterator が間違いだったとして、どうすれば正解だったの？

>>443
ヒント：protected

　 　∩＿＿＿∩　　 　　　　　　｜
　　 | ノ＼　　　　 ヽ　 　　　　　　|
　　/　　●゛　　● |　　　　 　　　|
　 |　∪　　( _●_)　ミ　 　　　　　j
　彡､　　　|∪|　　 |　　　 　　　 Ｊ
/　　　　 ∩ノ ⊃　 ヽ
(　 ＼　／ ＿ノ　|　 |
.＼　“　　／＿＿|　 |
　　＼ ／＿＿＿ ／

そもそも >>440 は論旨が不明瞭。

>>440
const_iterator が持ってる二つの機能って何？

constとiterator

>440
NVIは言いたいことは解らないでもないが、
今のところ、わざわざそうするべき状況に出会った事がないから実感が持てない。

>const_iterator
要素のconst性とコンテナのconst性のこと？

Cで組み込み系（ファーム開発など）をやってる人は
これを読んだらどう？
ttp://www.amazon.co.jp/gp/product/4789833399/503-6690732-8287916?v=glance&n=465392

>>450
面白そうな本だね。俺、別に組み込み系とかやってるわけじゃないけど、
今度、本屋に行った時に読んで良さそうだったら買ってみるよ。

>>450
MMSといったら悪名高きDシリーズじゃないか。

>127あたり
vc++使っててchar(...)みたいなキャストができることを知って多用してます。
ほかでもOK？

アクセッサとメンバ。get〜set〜とかくのが面倒なのでこんな感じ
class Foo
{
int m_hoge;
int hoge() { return m_hoge; }
void hoge(h) { m_hoge = h; }
};

>>347 面白いんだけどスルーされてる？

>>453
関数型キャストはいつでも使えるわけではないし、折角C++には濫用防止の戒めを兼ねて
テンプレート型キャストがあるのでそちらを使うべきです。

実数値を整数値に丸めるときなんかは(仕様を承知で) int(sin(...))なんて使うのはありだと思いますが。

>>455
コピペに反応しろと?

>>457
あれってコピペなの？的確なレスだと思うけど。

>>458
ttp://google.co.jp/search?q=そんなの微妙すぎ

>>459
それは知ってる。っていうか、それ知らないと面白くない。

cは限りなく正解に近いw

>>453
その形式のキャストも標準Ｃ++のうち。正確にはコンストラクタ呼び出しの構文。

いまさらだけど、>>127
D&E読め、static_castの類はわざと読みにくく作られている。

実務でCのソースみると、グローバル変数を多用する
人がほとんどなんだけど、どうして？
構造体も使わないし、自分でやってて分け分からなく
ならないのかな？

グローバル変数多用派のご意見をお聞きしたい。

関数に引数を渡したりするのが面倒くさいんだろう。

>>463
過去の汚物を引き継いでるプロジェクトほどその傾向が強い。
一部の教条主義者はローカル変数は遅い、構造体は遅い、と信じていたりするし。

>>463
別言語がメインの開発者

あえて言語を特定しないのですね

>>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 };
};

>>468
他の環境に移植することが予め無いってわかってるんだったら仕事でも
処理系依存の機能を積極的につかってもいいと思うぞ。

スレッド間のフラグとか、めんどくさい時は
外部変数にしちゃってるわ。

>>463

プロジェクトの規模が小さいのでは？

まぁ、品質管理が最低なことには変わらんが・・・。

>>472 >>473
保守乙

空行，どんな感じで使う？

>>475
・複数行にわたる宣言（および定義）が連続する場合は
　１行以上の空行で区切りを見つけやすくしておく。
・１行以上を占めるコメントの前には空行を置き、コメントが
　後続のコードに関するものであることを明らかにする。

言葉にするのは難しいな。

printf("hello");　と
printf( "hello" );　と
printf ("hello");

ケースバイケース

基本的に使わない。
関数／メソッドの区切りにのみ使う。

EmacsでCのソース書いてるが、コーディングスタイルは
gnu, k&r, bsd, stroustrup, linux 等が設定できる。
我流コーディングスタイルの癖を付けたくないんでとりあえず
好みに近いstroustrupを選んでるが・・・


gnuスタイルはキモイ。(さすがrms...)

if (ptr != NULL) ...;
if (ptr == NULL) ...;
と
if (ptr) ...;
if (!ptr) ...;
はどっちがいい？

他人に見せる可能性がある場合は後者。

じゃなくて前者。ごめん。

if (ptr) が好きなんだけど ptr != NULL の方が多数派なんだよなぁ

>>482
プログラムの動作を口に出して読んでみれば、前者のほうが自然だと感じられる。

if (ptr != NULL)   if ptr is unequal to NULL
if (ptr == NULL)   if ptr is equal to NULL
if (ptr)           if ptr is valid
if (!ptr)          if ptr is invalid

ヌルで無いことと valid であることは同値ではないぜ。

だから？

if ptr points something
if ptr points nothing

で？

if(ptr->isValid())
isValidはNULLとかinvalidポインタでも動くようにstaticメンバ関数で

それどうやって使うの？

>>493
おまいが訊いてのは使い方？　それとも作り方？
使い方なら、そのまんま >>492 の通りなんだが。

って、よくみたら>>492はアホなこと書いてるな。
staticメンバ関数にしたら意味がねぇだろが。

だから？

このナポリタンは高速移動をしていないと言える。

それからどした？

>>492
ヌルに -> した時点で未定義動作。

>>498
そんなことはないだろ。これは普通に動くし。
#include <iostream>
class null {
public:
bool isnull() const {return this;}
};
int main() {
null* ptr;
if(ptr->isnull()) {
std::cerr << "null !" << std::endl;
}
return 0;
}

いいえ、未定義です。あなたの処理系が動くようなコードを偶然吐いているだけです。

>>499
NULLどころか、ポインタを初期化すらしていない件について。

馬鹿な>>499がいるスレはここですか？

499のコンパイラは警告すらはかないのか

>>499の書いたプログラムは怖くて実行できません。

初期化しないポインタがヌルにならないのは大問題のような気がしてきた
Javaみたいにぬるぽガッってなってくれたほうが安心だな
499みたいなのを見るとそう思う。

>>505
C/C++ の本質は高級アセンブラだから、パフォーマンスが犠牲に
なるようなことは原則として勝手にやらない。
まぁ、お前みたいなヤツはJavaなりC#なりでも使ってなさいってこった。

C++ならスマポ使うから無問題

そうか、そうなのか。うーん、なるほど。

>>500
ああ、ごめんごめん。ptr = 0 の初期化と return this == 0 に直してね。
それはともかく、単純なクラスの非静的メンバなら、暗黙の this 引数を 0 に
しても呼び出せるのは自明だ、ということが言いたかったんだけど、それ
すらも未定義ということ?

コンストラクター

コンスという名前のトラクター

どうなんだろうね。
どっちにしてもお行儀が良いとは言えないけど。

>>509
最初から未定義だって言ってるだろ。

>>509
ほぼすべて環境で問題なく動作すると思われるが、
それとこれとは関係ない話で、未定義は未定義。

>>499のように動かない実装上の理由は想像しにくいが、
ある日ある時ある環境でカーネル破壊して落ちてもそれは「正しい動作」となる。
未定義というのはそういうことじゃないかね。

>>513-514
そうだね。つまらんことに粘着してスレ違いネタを続けてすまんかった。

>>515
やっぱりお前は馬鹿だな。

>>506
でも現実として、「変数は必ず初期化しろ」みたいなTipsが解説書に書かれる訳で、
パフォーマンスの為にコンパイラが自動でやらないことを
結局プログラマがコードで書くのは馬鹿馬鹿しい気がするよ。

>>517
初期化してない変数を勝手に 0 で初期化して
実行時コストを伴いながらプログラマの選択肢を
奪うことには議論の余地がある。

言語デザインの面で考えるのであれば、
未初期化な変数定義を認めないのが正解だと思う。

「変数は必ず初期化しろ」の類はナンセンスにしか思えない

そもそも未初期化でバグるようなコードは
必要な前処理を怠っているという点でそれ自体が潜在的なバグであって、
盲目的な初期化をさせたところで、（必要な前処理をやっていなければ）
バグの顕在化を遅れさせるだけだと思う

あとこういうケースで初期化させるのも無意味だと思う
int a /* = 0 */;
if (ある条件) {
　　長い処理;
　　a = 何か;
} else {
　　他の処理;
　　a = 違う何か;
}
ここでaを使う;

int a = ある条件 ? (長い処理 , 何か ) : (他の処理 , 違う何か);
ここでaを使う

もっと簡単にローカル関数を定義できれば便利なんだけどと
思うことはよくある。

別に今のままでも支障はないんだけど、
初期化不要宣言をしたときだけ
初期化されない仕様でもいいかもしれない。

>>520
長い処理って書いてるやん。お前それ一行で書く気かよ。
第一whileとかが入ってたら展開できないぞ。
関数化するってのは無しな。

>>523
なんで無しなの？
関数にしとけばaをconstにできるし、
長い処理ってのはそれ自体のコストが大きい可能性が高いから、
一回だけの関数呼び出しのコストなんて気にする状況じゃないと思うが。

関数化してもしなくても単純に読みづらい。
最後の値が代入されると直感的に理解しにくい式になることが予測できる。

ヘッダーで using namespace std するのは、よくないよね。

うん。

int *p1, *p2, *p3;

int a;
{
int a;
/*hogehoge no syori*/
}

なんてのはよく使う

shadowは嫌いだなあ

保守age

プロパティ欲しい。

結局protectedってどうやって使ったらいいんでしょう(´・ω・`)
friendはファクトリクラスからのみ作成するようにする場合に保険の意味も兼ねて
テンプレートのファクトリクラスに対して指定してつかってますが…

>>534
必要だと思うまで使わなくていいよ。

ポリシークラスのデストラクタはprotectedにすべし、とかあったような

自然とprivate基本じゃなくてprotected基本で作るようにならねえか？

>>537
そんなバカな。カプセル化壊れまくりんぐじゃねーか。

>>537
中卒溶接工童貞DQNﾊｯｹｿ！

まだカプセル化なんて、宗教信じてんのか。
醍醐味は、ポリモーフィズムとdynamic_cast
〜ＣＯＭ／ActiveXだろ。

日本で書かれた糞本読んでるとそうなります

それもJava教っぽいなあ

コンストラクタで初期化リストを書き並べるのは、どう書くのが正しいんだろうか？

class Hoge {
Foo foo_;
Bar bar_;
FooBar foobar_;
public:
Hoge(Foo const& foo, Bar const& bar)
: foo_(foo)
, bar_(bar)
, foobar_(foo, bar)
{
// 処理
}
};

自分はこんな感じでコロンとカンマを並べてるんだが、果たして変だろうか

英文を見慣れた人間にとっては、単純に気持ち悪い。
日本語で読点を先頭に書くようなもんだからね。

キモいんだけど、このスタイルのほうが理に適ってるんだよねぇ。

外人でも:先頭で書く人いるから英文云々はあまり関係ないんじゃないの？

>>545
>544

>>546
>547

最近 カプセル化 って言葉を発することが恥ずかしいと
思うのだが、
俺だけ？

なんでだよ。

行末のコメントってどうしてますか？
タブで揃えた場合、タブのスペース数が変わるとずれてしまうし･･･

揃えようとするのが間違い。
しかし世の中にはおかしな風習が残っている会社もあって、
行内コメントは必ず45カラムから始めて79カラムまでと決められていたりもする。

>>550
タブはコードの前までしか使わない。
（ここだけタブ）x: （ここにはスペース） // コメント

まあ、手動でスペース調整してコメントの位置そろえても、
最近は Visual Studio の整形機能とかでスペース消されちゃうけどね。
>>551 の言うとおり、そろえようとするのが間違いかと。

そこでマクロですよ

そもそも行末にコメントを置かなければいいわけだ。

なるほどー。
色々アドバイスありがとうございます。

>>544
配列の初期化や enum の最後に余分なカンマがあってもいいのは
何でだと思う？
(enum のは C だけか。)

>>556
なんか例えが変な気が。

enum の最後とかは、
例えばスクリプトで自動生成したりするときに、
最初または最後の行だけ特別扱いしなくてもいいから。

>>544 が言いたいのは、
, が行頭にある方が、
前の行から続いてることがわかっていいんじゃね？

ってことでは。

話が逸れるが

関数のオーバーロードとかtemplate引数の数で擬似オーバーロードとかなら
Boost.Preprocessorで量産したりするけど、
enumを自動生成したりする機会なんてあるかな。

コード上ではほとんどトークンの列挙だけだから、
普通手打ちでやるんじゃね？

>>558
なんかのデータベースからデータを抽出して、そいつらの ID を列挙するときとか。

Boost.Preprocessorってググったんだけど、どっか
詳しいページない?

>>558
手打ちでやるにしても、最後の行だけ特別扱いってのを気持ち悪がる人いるよ。

>>560 http://www.boost.org/libs/preprocessor/

int *a, b, *c, &d; // OK?

#include ""は.cppに#include<>は.hファイルに書くでOK？

NG

仕事でSymbian使い始めてからSymbianのコーディングスタイルに毒された。
引数はaFooで内部変数はiFooとか。

>>564
標準インクルードファイルは<>で括って、ローカルインクルードファイルは""で括る。
それらの中間に当たる、非標準の汎用インクルードファイルやプロジェクト外の共通インクルードファイルは適宜決めること。

ふむふむ

標準のいんくを""でくくってもOKだったり、検索パスも同じ？機能的な違いが判らん。

>>569
""で括った場合は、先ずカレントディレクトリを探す。それ以外は<>と同じ。

つまり、間違って"stdio.h"なんてファイルを作ってカレントに置いたとしても、
<stdio.h>でインクルードしていたらそんなの関係ない。

汎用ライブラリのインクルードみたいなものは、<>で括ってサーチパスに追加するのが無難。

厄介なのは、自分のプロジェクト外だが標準ではなくて、更新の可能性もありそうなファイルかな。
仮に、プロジェクトから見て"../common/include/someHeader.h"だるとして、次のどれかを採用することになると思う。
・#include <someHeader.h>してサーチパスに"../common/include"を追加。
・#include <include/someHeader.h>してサーチパスに"../common"を追加。
・#include "../common/include/someHeader.h"する。
# 絶対パス指定はするべきではない。
Unix系なら、こんな手段もある。
・#include "common/someHeader.h"して、ln -s ../common/include commonする。

>>570
一般的には処理系依存だよ。どのコンパイラの解説をしてくれているのか明示してくれ。

一般的にはどの処理系でも当て嵌まりそうだが。つーか、最後の一行についてはunix系と明示しているし。

>>572
「どの処理系にでも〜」っていう根拠は何かあるの？
規格にあるのは、 "" に対する処理系依存の検索で見つからなかったときには
<> と指定されたかのように処理しなおすこと。そして <> の検索方法もまた処理系依存。

あと、最後の一行がそれより上の説明をUnix系の話に限定するわけじゃないだろ。

>>571
一般的なコンパイラの話。
私の知る限り、よく使われるコンパイラで大きく逸脱しているものは無いと思うので。
違う例があるなら、指摘してくれれば嬉しく思います。

>>574
とりあえず gcc は明示的にオプションで指定されない限りカレントディレクトリを
探したりしない。 -iquote なんてオプションもあって、 >570 とはまるで挙動がちがう。
http://gcc.gnu.org/onlinedocs/cpp/Search-Path.html

gcc を含めずに「一般的なコンパイラ」というのはさすがにあんまりだと思うよ。

一般的なコンパイラって何？

gcc が違うとなると、それも聞きたいな。

gccでは、""で括ったインクルードファイルをカレントから探してくれないと言う
素っ頓狂なことを>575は言いたいらしい。
では聞くが、カレントにあるインクルードファイルをインクルードするにはどうしたらいいのかね?

>>578
カレントにあるソースをコンパイルするとか、 -I. を指定するとか。
リンク先読んでないの？

なんだろ、>575=>571は単純な読み違いをして駄々を捏ねているのか、
それともなにやら深い勘違いをしているのだろうか。或いは単純に、
>570が「カレントファイルのあるディレクトリ」を「カレントディレクトリ」としたことが気に入らないのだろうか

あーなんだ、3行目だったかw

なんだ、そういうことか。その意味でカレントディレクトリと言うのはやめといたほうがいいよ。
http://www.google.co.jp/search?q=%e3%82%ab%e3%83%ac%e3%83%b3%e3%83%88%e3%83%87%e3%82%a3%e3%83%ac%e3%82%af%e3%83%88%e3%83%aa

で、「カレントファイルのあるディレクトリ」を検索してくれないコンパイラなら、
一気にマイナーになるけど、ルネサスのコンパイラがそう。こっちは逆に
特に指定しない限り一般的な意味での「カレントディレクトリ」しか見ない。

unsigned int はどんな風にtypedefしてますか?
1. typedefしない
2. BSD風に u_int
3. Windows風に UINT
4. その他?

1. typedefしない

必要ならstdintを使う。それ以外は1.

4. intを省略する。
static const unsigned FooVal = 0;
unsigned func(unsigned foo) {return foo;}
for (unsigned ic = 0; ic < sizeof(array) / sizeof(* array); ++ic) {
unsigned rtn = func(array[ic]);
std::cout << unsigned(sizeof(rtn));
}
// などなど

<windows.h>をインクルードしていたらUINTは使うけど、
そうでないときはunsignedにする。自分でtypedefはしない。

サイズが予測できるべきならcstdintの適当な型。
メモリに依存する値、または数や大きさを表すならstd::size_t。
大きさの上限を仮定すべきでないならunsigned。
longは使わない。

皆さん、ありがとうございます。
やはり、統一的な定義はないのですね。
stdintは使っていたのですが、普通の数値までいちいちサイズ指定するのも変かと思いまして。
int省略でいこうと思います。(今まで省略できることを知らなかったなんて言えないよな…)

>>589
int の省略は一般的じゃないから、あんまりおすすめできないなー。
省略できるのを知らない人はざらに居るよ。初めて目にした人を
いちいちびっくりさせるのはよくないと思う。

サイズ指定するのが変だと思うなら、 unsigned int って書いても
問題は解決してるでしょ。

でも、unsigned short int と書く香具師は少ない。

>>590
ついこの間までWindowsばっかりでUINT慣れしてたせいか、長く感じてしまうんですよ。
たしかにunsigned単体って見かけないし、4文字しか減らないし、
省略しない形に慣れた方がいいような気がしてきました。

そもそもshort intと書かない

typedef unsigned uint;

C++で、void a(void)とvoid a()はどっちがお勧め？

void a()
コンストラクタも同じ表記だから

どっちを呼びたいの？

＿|￣|○　>596 に一票入れとく。

a(void)きもい→a()にしようって過去があるからa()を推す。

>>596-599
回答ありがとう。満場一致でvoid a()なのね。俺もvoid a()に統一するよ。
Cからの流れで(void)って書いてただけだから、書かなくていいC++では違和感を常々感じてましたです。

その表現には違和感を覚えるな。

頭の頭痛が痛くなってしまうな。

if( Func( GetUnko( a ), reinterpret_cast< void * >( b[ c + d ] ) ) );

こんな感じの書き方が好きです。

>>600
自分はa(void)派。
理由は一目で関数呼び出しと区別できるからかな。
そんなに強い理由じゃないし、こだわりはあまりないけどね。

>>603

あ〜自分もそう。一時変数はなるべく作りたくない。
でも意味がわかりにくいと思ったら、一時変数作るか関数にする。

>>604
やめて。コンパイル通らないから

そうなの？どの環境で？

C++

>>608
C++ の関数宣言でも (void) は引数リストとして有効だよ。

C とは違って typedef された void は受け付けないらしいが。

あら そうやった？
VC++のバージョンとが上がると急にエラーになったりする
ことになるから、
書かない方がいいと思うよ＜(void)

何か勘違いしている悪寒。

>>610 ねーよ。

>>610
ないな。いまのところ。6〜9はOKと思われ。
言語仕様は正確に知らないが。

8.3.5 関数
...
<<仮引数宣言節>>が空の場合、その関数は実引数を受け取らない。
仮引数並びが(void)の場合、空の仮引数並びと同等とする。...

だそうだ

そうか俺の勘違いだった。すまぬ。
互換上の仕様だけど今後も残りそうな仕様だな

(void)のコードが山のようにあるからそうそう消せないだろうし、弊害がるわけでもないしって所じゃないかな。

>606 は、604が戻り値を省略したからコンパイルが通らないと主張しているのだと思ってた。

>>617 それだと戻り値省略で void になるとかいう話になっちゃうだろ。さすがにそれは無い。

仮引数の命名規則というものを見たことが無いのですが、
普通は考えないものなのでしょうか？

例えば引数で値を返す関数の場合
bool func( int* val_ ){
　*val_ = 0; // 取り合えず 0
　int val;

　.. ローカル変数 val をいじる処理 ..

 *val_ = val; // 返却
return true; // 成功
}
みたいにすると分かりやすいと思っているのですが
こんな事考えてるのは自分だけ？

どうでも良いけどメンバ変数は m_ 派です

引数はたまたま宣言場所がちょっと上の方にあるだけのローカル変数みたいな感じだからなぁ。 ローカル変数と全く同じ命名だわ。

仮引数の命名規則と実装の話がどう繋がっているのかわからない。

val_が関数利用者側から意図を汲みやすい名称かという話なら
意味不明ぐらいの感想しかない。ヘッダのみ提供ならなおさら。

val_が失敗成功に関わらず0で初期化される、成功時に結果が設定されるという話なら
ヘッダに利用上の注意としてコメントを残しておくだけだろう。

失敗なのに0クリアされるような関数は嫌いだ。

ちゃんとコメント書くからそんなことする必要ない
dest という変数名は使うことはあるけど

>>621
実装者視点の話と思うよ。(関数利用者側のメリットはなさそう)
619の例だとローカル変数と衝突しなくてすむ。

自分は前はp_(pはパラメータの意)をつけたり
619のように最後に_つけたりしてたけど
今は何もなし(ローカル変数と同じ)だな。
ちなみに_最後につける方法はメンバ変数にする場合も見かけるね。

関数のプロトタイプの一覧だけ渡されたときに、仮引数にわけの分からん修飾がしてると気持ち悪い。

そんなの宣言と実装で名前変えられるじゃん。
実装は接頭辞付きって規則で統一した上で。

果たしてそこまでして接頭辞をつけるほどの利点はあるのだろうか

他人のソースを読むときに、あったほうがいいと思ったことがある。
でも関数が長いとか変数名が変とか、設計上の問題のせいかも知れない。

設計が良い場合は思わなかった気がするな。

ほす

++i;
i++;
どっち

i++;

演算子多重定義があるから++i;

>632
はしょりすぎじゃね？
i++ だとインクリメント前の値を返す無駄な処理が発生する→最適化されたら同じじゃね？
→演算子多重定義があるから一般には最適化できない

→それに合わせて、組込型であることが明白な状況でも++i使うようになる

後置である必要がなければ前置を使おう

203++;

つまりC++ではなく++Cだと言いたいわけだね

もともとCへのトランスレータだったから、返ってくるのがインクリメント前のCなのが正しいのだ。

++C++

>>639
error C2105: '++' には左辺値が必要です。

Д-C-Д

+(+C++)

C/C++ Coding Style Thread
http://pc11.2ch.net/test/read.cgi/tech/1096687703/

関数ポインタの配列を返す関数へのポインタを引数に取り、
関数ポインタの配列を返す関数ポインタの配列を返す関数について、
どのように書くのがよいですか？
1. typedef使う場合
2. typedef使わない場合
でよいので記述せよ。

宿題スレ行け

>>645
ぷぷ（ｗ
解らないやつ発見（ｗ

「デフォルトの名無しさん」ってだっさくない？
ダサいよ。うんダサい。

ということで、
  [error C743: 名前がありません。]
にしようぜ。というか、しろ。

さっさと変更依頼だせ。

ここ自治スレとかの類ではないよ。

>>645,>>646
痛いな、関数は配列を返せません。
void (* (* (* function(void (* (* var(void)) [])(void)) [])(void)) [])(void);
当然、配列返そうとしているから、間違えだけど。
void (* (* (* functionz(void (* (* var(void)) [])(void)) [])(void)) [])(void);
たしかに、この名前いいな。

関数は配列を返せるだろ。

配列の先頭要素を指すポインタなら返せる
それで充分かどうかは場合による

十分ていうより配列なんか値で返すのは非効率じゃね？
でも、構造体でくるんだら値でも返せる。

上の方でprotectedの変数アクセス云々の話があったが

例えばsinを子に公開しているクラスがあったとして、
class A
{
protected:
　static double sin[0x10000];
};
初め高速化の為に配列で準備していたのをWindowsCEなんかの
低リソース環境に移植するために
class A
{
protected:
　static double sin(double);
};
にしたくなった。そいう時子class全域に広まる影響はどうするんだろう？
初めから、関数アクセスに限定してれば何にも危惧すること無いのにな。

話は変わるが、趣味範囲でプログラムを書くとき
class T
{
　int value;
public:
　int Value(void)const;　　//getter
　int Value(int);　　　　　　//setter
};
見たいな感じでよくね？と思う。まず、setterとgetterを間違えることないし、
テンプレート関連で多少融通が効いて便利。

あと、Mozila関連の規約はなかなか面白いね。
https://developer.mozilla.org/Ja/C___Portability_Guide

>>653
その下駄は兎も角、雪駄は何故intを返すんだ?

元の値じゃね？

T a;
int b;
b=a.Value(5)+3;
てな事をするため。
まぁ、T&を返してもいいんだけど。
b=a.Value(5).Value()+3;
ってなんだよなぁ。

>>653
protected メンバ変数なんて使わない。
広まる影響については、自業自得ということでがんばれとしか言えない。

getter/setter にルールを決めるなんてナンセンス。
普通に、クラスに必要なインターフェースをクラスごとに考えろ。

Mozzila のそれはいい加減に古すぎるし、大量のコンパイラを
想定する必要なんてないことがほとんど。

そもそも下駄雪駄を無駄に作るのは、privateの意義を半分くらい失うってことだしね。

もっずぃら

Mozilla 、な。

オープンソースではとりあえず private にされるとめんどい。
あるクラスを使っている別のファイルでその変数にアクセスしたい時、
setter/getter を作らなければならなくなるので、
その別ファイルだけの diff だけではなく、クラスのファイルの diff も必要になる。

なんでこうカプセル化を堂々とぶち壊すアホが後を絶たないかね。

カプセル化のメリットを理解してないからじゃね？

>>661
>>653見たいな事になったらどうすんの？
例えば、時間を管理するとしてlongの変数一つで扱うか
hour,minuts,secondと3つに分けて扱うとか
いくらでもprivate領域は変えられるんだからね。

誰でも若い時分には他人の培ってきたノウハウに対して懐疑的になり、
例えばグローバル変数を利用してピンポイントの効率化を行なって悦に入り、
そうはしない他人よりも自分の方が能力があると錯覚してしまう時期があるもんだよ。
斯く言う私も、10代の頃はそうだった。

カプセル化のメリットよりも、パッチを投げにくいデメリットのほうがでかいことがある。
カプセル化のデメリットを考えずにメリットだけを信じるというのは思考の停止である。
偉い人が唱えたアイデアを盲信せずに、自分なりにメリット、デメリットを考えてみる。
そういうステップを踏んでみると、メリット、デメリットの「度合い」というものも状況によって異なることに気付けるはずだ。
あえてカプセル化を採用しないコーディングスタイルもありうるかもしれない、と気付けるはずだ。
>>662-664 君達はそこまで考えたことがないのだろう。


カプセル化至上主義ですか…。try{} catch{} のエラー処理は常に使用すべきですか？

>>665 そういうステップを踏んできたのならいいだろうね。

つまり、自分勝手な改修を行ないたいがためにカプセル化のデメリットがあるとほざいているのか。
もっと真っ当な解決策がそこにあるかもしれないのにそれを模索しようとしない姿勢こそが思考停止ではないのかな?

オープンソースにおいて、
関数は可能な限り private メンバ関数にすべきですか？
それとも全て public メンバ関数にすべきですか？
メリット、デメリットを一緒に教えてください。
自分なりの解答はありますが、皆さんの意見を教えてください。
できれば議論の形になっていただけるとうれしいです。

オープン開発なら、能う限りprivateにすべきだと思うがね。

いや、オープンとか関係ないから。

>>661
その理屈で public にしてるとさ、元のクラス側の実装を変更しようと思った時には
逆に使ってる側の別ファイルも合わせて書き換えないといけなくなるんでしょ？

詭弁だよ。もしくは元クラスを書き換える可能性を無視した、浅はかで自分勝手な考え。

>>666
昔、嫌々VB6.0で組まされたことがある。それもチームで。
アレには、Classとモジュールと言うのがあって一応カプセル化は
できるようにはなってんだ。一つの規約として「変数だけはpublicに
するな」を設けた。しかし、メンバーのレベルが低すぎて勝手に変数共有。
そしてカプセル化が破しどこで勝手に変更されてるのか分からない。
依存コードの除去に苦労したよ・・・。
あんな事2度とごめんだ。

オプソでも似たようなもん。勝手に変数共有なんかされるとみんなが困る。
人のことを考えろよ。

>>666
様々な試行錯誤を経てカプセル化については　メリット＞＞＞デメリットという結論なんだな。
俺も昔はメンバ変数はprotectedで勘弁してよって思ってたが、今ではしっかり設計をすればprivateでokであることが解ってきた。
諦めてカプセル化を壊すことこそが思考停止だとおもう。もう少し設計を見直すべきだな。

カプセル化を壊すのは設計が妥当ではないといういい指標となると思う

メソッドは基本public。理由があればprivate/protected

俺は必要になるまではなんでもprivateだな。

外にサービスを提供するのがpublic
内部で使うものはprivate
カスタマイズに使うものはprotected

非公開から公開は簡単。逆は難しい。
だから最初に公開するものはとっても悩む。

他人が使うものを作ると実感する。

提供されているクラスで（こっちは手を入れれない）でなんでこれが
privateなんだよってことがよくある。
あったまくる。最悪。どうしようもない。

>>679 提供元に文句言えよ。

>>679
触って欲しくないからだろ。

＞こっちは手を入れれない
この頭の悪さが物語っているな。

おまいらつまらんやつらだな。
仲良しとしか組んだことないだろ

どうしようもないときはprivateメンバだろうが何だろうがアクセスすればいいだけだよ。
privateだからとかバイナリしかないとかは大した障害にならないね。

#define private public

>>685
一応それはillegalだよね？
だいたいそれでうまくいくけど。
プリプロセッサの段階でそれをdenyする実装ってあるんだっけ？

いやまったく合法だ

↑↑VCだと、privateとpublicではマングリングが違うため、ソースが（リコンパイルが）必要になる罠

>>688
何が言いたいのかさっぱりわからん。
アクセス修飾変えるんだからリコンパイルが必要なのは当然だが、そこでなんでマングリング？
686の話とどう繋がるのか教えてくれ。

>>689
アクセス指定子によってマングル名が変わるからコンパイルはできるけどリンクできないってことだろ。
リンクするためにはライブラリ？も同じアクセス指定子でリコンパイルが必要ってこと。

いつも思うけど、マングリングってエロいよなｗ

おまいは中学生か!
でも確かにエロいよなぁ

>>690
そうそう。代理での回答ありがとうん

どう書いてる？
char ch; //もしかしたら誰かがint chに変えちゃうかも知れない

style A) printf("%c", ch);
style B) printf("%c", int(ch));
style C) printf("%c", char(ch));

AとCはintへの自動昇格目当てな

>>690
いや、マングリングが変わらなくてもコンパイラがVCじゃなくてもコンパイルとリンクは発生する。（勿論例外はあるけど）
なぜ686にそれを指摘するのかが俺には理解できなかったんだわ。

>プリプロセッサの段階でそれをdenyする実装ってあるんだっけ？
これ俺も知りたかったから689が何か言おうとしてるっぽいんで理解しようと思ったんだが・・・意味不明だったんで質問してみた。

プリプロセッサ様を妨げるものなんていないよ

プリプロセッサさんマジパネェっす

>>694 A 以外に意味が見出せないんで、何を迷ってるのかわからん。

>>697
わろたｗ

>>698
%c に対する引数は int を与えないといけないので、明示的にキャストするかどうか。
さもなくば可変引数における暗黙の型ルールを把握しておかないといけない。

>>699
そんなもん、%cを学んだ段階で把握できることだろ。
それとも何か、入門書と言う奴はそんなことも書かれていないのか?
だとしたら、マニュアルページに補足されているといいかも知れないな。
駄菓子菓子、そのキャストは余りに神経質に過ぎると思うぞ。
それを言い出すと例えば、ch == '\t'なんてのもそのまま書けなくなってしまう。

>>699
キャストしてもしなくても、「可変引数における暗黙の型ルール」を把握しておかないと
いけないことに変わりはないはずなんで、何を迷ってるのかわからん。

入門書は可変引数の場合の型昇格書いてないやん

入門書を書く奴は、知識がないのに書いているか、判りきっていてて説明できないか、どっちかだろうからな。

template内で使用するなら、可変長引数で型変換の
オーバーロードが通じないぶん意味があるかもな。
type a;
printf("%c",static_cast<int>(a));
でもまぁ、だったら最初からstd::cout使っとけやって話だが。

どこに改行/空白入れる？　typedef/usingする？
std::list<mylib::common::MyClass<charT>* > container;
std::vector<std::basic_string<CharT> >
もにょもにょ・・・
std::transform(
boost::make_indirect_iterator(container.begin()),
boost::make_indirect_iterator(container.end()),
std::back_inserder(strs),
boost::bind(&mylib::common::MyClass<charT>::format,_1,"%1:%2:%3");
);

なんかひどいから書き直す
template<class CharT>
func(std::list<mylib::common::MyClass<CharT>*> container,
std::vector<std::basic_string<CharT> > &strs)
{
もにょもにょ・・・
std::transform(
boost::make_indirect_iterator(container.begin()),
boost::make_indirect_iterator(container.end()),
std::back_inserder(strs),
boost::bind(&mylib::common::MyClass<charT>::format,_1,"%1:%2:%3") );
}

template<class CharT>
func(std::list<mylib::common::MyClass<CharT>*> container,
std::vector<std::basic_string<CharT> > &strs)

この3行は改行しないで一列にしちゃうな。
なんでかっていうと、VC++2008では、{ }内全体を隠す機能があって
1関数/1クラスが1行にまとまって検索しやすくなるので。

小まめに改行してるソース読むと、いい加減モニタ買い換えろよと思う

80桁ルールを守る価値はそれなりにあるぞ

今となっては80桁は窮屈だぞ。

Unix系の端末で快適にソースを閲覧できる状態というのは確かに必要なこともあるし、
80桁ってのはデファクトとしてそれなりの意味があるんじゃないのかな。
事実色んなオープンソースプロジェクトが80桁ルールを守って書かれてるし
やろうと思えば全然難しくないしね。

まあ80桁は狭いと思うにしてもせいぜい100桁か120桁くらいが限界じゃないかな。
あまり横に突き出してしまうと、結局折り返しが発生する環境が出てきて、
可読性が損なわれてしまう。
自分が読めればいいだけならいくらでも横に伸ばせばいいけど。

>>708-711
http://stackoverflow.com/questions/110928/is-there-a-valid-reason-for-enforcing-a-maximum-width-of-80-characters-in-a-codhttp://stackoverflow.com/questions/110928/is-there-a-valid-reason-for-enforcing-a-maximum-width-of-80-characters-in-a-cod

ごめんミスった。
>>708-711
http://stackoverflow.com/questions/110928/is-there-a-valid-reason-for-enforcing-a-maximum-width-of-80-characters-in-a-cod

エディタ横２列で見ることもあるから80桁は守ってる（厳密ではないが）

自宅と会社のWindowsでは、xyzzyでバッファ2枚取ると丁度100カラム。
客先と会社のLinuxでは、端末エミュレータを3枚並べると丁度100、100、80カラム。
なので80-100で収まるようにコーディングしている。

teratermだろどうせ
無理すんな

端末エミュレータと聞いて、teratermを連想する馬鹿発見。

まぁ、客先の現場に行くとサーバがSunだしLinux端末がないから使っているけどさw

俺、Xでもだいたいターミナルエミュレータいくつか並べる使い方しかしないから、
最近はもっぱらWindowsからTeraTermでつないで使ってる。

色づけ厨なのでputtyしか使わない

仮想化おいしいです。

ソースコードがMacで保存されているとかいうエラーが出るのだけど、どういうこと？

>>721 きっと、ソースコードがMacで保存されているんだと思う。

LF

今時そんなエラー吐くエディタは要らんな。

for ( ; ; )/*~~~~ \(; ; )*/


無限ループはこうかく

こうだろ

#define _

for(;_;)

#define は反則だろ・・。

#define do_ob (for)
#define p_q (;;)

do_ob (p_q)

>727
展開すると

　(for)((;;))

コレが通るコンパイラを教えてクレ。

>>728


defineのあとのカッコ（）は無視されます

>729

#define A (1+2)
#define B (3+4)

printf( "%d\n", A * B );

>>729
むしろ>>730のようにカッコを無視してもらっては困る場合が多いんだけど

>>729
だから、どのコンパイラがそんな挙動をするのかと。

>>730

11

>>733
>732

「コメントは無視される」と間違えてる気ガス。

#define A 1 // コメント書いてもちゃんと通るYO!
printf( "%d\n", A );

香ばしいな

>>735
＞「コメントは無視される」と間違えてる気ガス。
誰が?

>>737
>735は日本語が不自由なんだよ。>735は、
「>729はコメントが無視されることと同様にと括弧も無視されると勘違いしているのじゃないか」
と言いたいのだろ。

まぁ、普通はそんな間の抜けた勘違いはしないがな。

俺の書いた>>325のせいで殺伐としてるなw

#define 325 735

上記2つ725の間違いです＞＜

スタイルの前にまともに動くコードを書けって感じ、、、

#define good ;;

お？

String ToString()
{
return ( this->Type == HogeType.A ) "A" :
( this->Type == HogeType.B ) "B" :
( this->Type == HogeType.C ) "C" :
( this->Type == HogeType.D ) "D" :
( this->Type == HogeType.E ) "E" :
( this->Type == HogeType.F ) "F" :
( this->Type == HogeType.G ) "G" :
( this->Type == HogeType.H ) "H" :
( this->Type == HogeType.I ) "I" : "";
}

「?」付けるの忘れた・・・orz

>>745
きもいｗ 許せないｗ
俺ならハッシュ使って返すｗ

MFCみたいに継承つかったら？

クラスの頭にCつけるのなんでかと思ってたけど、
public:
　const CHoge&Hoge()const{return hoge;}
ができるのね。
ちょっと惹かれる。

GetHogeにするのは嫌なのか・・

>>749
頭のC要らないよ。クラスであることを表すってことなら class ってふつうに書けばいいんだよ。
public:
　const class Hoge&Hoge()const{return hoge;}

>>750
単に値を取り出すだけなのに動詞とかキモイ。
「x の hoge」は x.Hoge() が自然。 x.GetHoge() ってなると自然に読み下せない。
取り出した値を使った式を書いた場合にさらに読みづらくなる。

>>751
コンストラクタと名前被るからって意味じゃないかとエスパー。

それでは読み出し専用なのか書き込み専用なのか読み書き両用なのかわからないじゃないか！

…などと、どうでもいいことをぐりぐり掘り返してみた。
個人的にはどっちでもいいやって感じ。