C/C++ Coding Style Thread
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
NGNGクールに語るスレッドです
0002デフォルトの名無しさん
NGNGｺﾞﾗｧされにくいコーディングスタイルを身につけましょう
0003デフォルトの名無しさん
NGNGmain(){
return 0;
}
0004デフォルトの名無しさん
NGNGカンマの後にスペースを置き、空白の美を堪能する
if (foo > 10){
if, whileの直後もスペース推奨。関数との差別化を図る
0005デフォルトの名無しさん
NGNG{
}
else
{
}
と書く奴はキモイ
0006デフォルトの名無しさん
NGNG>>4
int count, temp, data;
これは以下のようにするように推奨しているけど少数派かね。
int count= 0; //変数の意味を記述
int temp = 0;
int data = 0;
理由は、編集のし易と
int *a,b;とあったときにbをポインタと勘違いするミスを防ぐため。
0007デフォルトの名無しさん
NGNG} else if (...) {
} else {
}
クール。グルービー
0008デフォルトの名無しさん
NGNG{ // ここにコメント
}
else
{ // ここにコメント
}
0009デフォルトの名無しさん
NGNG私もそのようにすることを推奨している。
0010デフォルトの名無しさん
NGNGちなみに、ポインタは
int *a;
よりも
int* a;
を推奨している。
0011デフォルトの名無しさん
NGNG変数宣言構文の意味を勉強してから出直しな。
0012デフォルトの名無しさん
NGNGへ？ なんで？
0013デフォルトの名無しさん
NGNG出直すのは君の方ね。
0014デフォルトの名無しさん
NGNG}
else if( ){
}
else{
}
これ、知ってからずっと愛用。
カッコの対応関係が見やすい。
0015デフォルトの名無しさん
NGNGint *a;
で、aの型は？って聞かれたらint型だなんて言わないよね。
0016デフォルトの名無しさん
NGNGhoge; // 詰まってて見にくい
}
if () {
// 空いてて見にくい
hoge();
}
if ()
{
hoge(); // 安心
}
0017デフォルトの名無しさん
NGNGそういうやつがいるから
int* a,b;
のbをポインタだと勘違いするやつが出てくるんだよ・・・
0018デフォルトの名無しさん
NGNGだから、
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;
という書き方は許されないから、間違うことはない。
0019デフォルトの名無しさん
NGNGは a が int* 型だという意味ではなく
*a が int 型だということは理解してる？
0020デフォルトの名無しさん
NGNGそれは理解しているが、ポインタは用途が違う事が多いので、
扱いを変える必要がある。
ゆえに明記する。
0021デフォルトの名無しさん
NGNGそのルールを守っているプロジェクト内ではそれで完結できるが、
そいつが別のルールの(一行で複数宣言を許す)プロジェクトに移ったとき、
17みたいのを見て勘違いしないか？
文法を理解してないそいつが120%悪いが、世の中出来るやつばかりじゃないからな・・・。
0022デフォルトの名無しさん
NGNGもちろん、int* a;のような記述もコーディングルールの一部だから、
別のルールに従う必要があるときはそのルールに従うべきだよ。
int *a;と書かないといけないルールだったらそうすればよい。
0023デフォルトの名無しさん
NGNG引っかからないようなコンパイラ使ってるプロジェクトなら、それこそ「アホはコード触るな」で。
0024デフォルトの名無しさん
NGNG0025デフォルトの名無しさん
NGNGでも、そんなお前でもループは
while(1){
}
とか
for(;;){
}
だろ？
0026デフォルトの名無しさん
NGNG;
} else {
;
}
0027デフォルトの名無しさん
NGNGときどきスペース空けてくれ
0028デフォルトの名無しさん
NGNGhttp://www.sra.co.jp/wingnut/standards-j_toc.html#Top
0029デフォルトの名無しさん
NGNG0030デフォルトの名無しさん
NGNGJava では if や while もそう書いてるが
C++ では全部>>16
0031デフォルトの名無しさん
NGNG1+2-3*4/5
↑
どっちが見やすいですか？
↓
for (int i = 1; i < 10; i++)
1 + 2 - 3 * 4 / 5
0032デフォルトの名無しさん
NGNGfor (int i=1; i<10; i++) 1+2-3*4/5 ;
0033デフォルトの名無しさん
NGNG後者
0034デフォルトの名無しさん
NGNG+ - の前後はスペース入れる
* / の前後は入れない。
0035デフォルトの名無しさん
NGNGそれいいな
0036デフォルトの名無しさん
NGNG0037デフォルトの名無しさん
NGNGf()
どっち？
Cでは意味が異なるんだっけ。
C++限定で。
003810の主治医
NGNG以下処方箋
int* aでもかまわないのですが
int* a, b, c;
とか書かれるとその人はbやcもint*型と誤解しているのでは？と悪い印象をあたえます
素直に
int *a, b, c;
と書きなさい
0039デフォルトの名無しさん
NGNG違うので、結果的に分けて宣言することが多くなると思う。
ただポインタは全部分けて書くっていうのはちょっとわからん。
> http://pc5.2ch.net/test/read.cgi/tech/1095180315/971
0040デフォルトの名無しさん
NGNG複数まとめて宣言する必要が無いんだよな。
0041デフォルトの名無しさん
NGNG0042デフォルトの名無しさん
NGNG全く直されるいわれはない。
これはスタイルの問題であり、開発者がコード見た時により見やすくするためのもの。
一行ごとに一つの変数を定義するというあらかじめ定義されたルールがある以上、
int *a,b,c;
なんていう書き方は許さないのだから、当然
int* a,b,c;
などとは書けない。
と何度も同じ事を書かないといけないのか？
int *a;なんていう書き方の方が全然素直ではない。
int型のポインタとint型を同じ行で定義するのは意味的に良くない。
0043デフォルトの名無しさん
NGNG0044デフォルトの名無しさん
NGNG＞int型のポインタとint型を同じ行で定義するのは意味的に良くない
まあ要するにこういうことだわな。
たまたま出来るからやりたければやればいいんじゃないのという。
0045デフォルトの名無しさん
NGNGと宣言しておいて
aは使う段階になったら
*(int *)a
とする
これで完璧
0046600
NGNG*a がintなのにNULLで初期化というのも妙だしな。
int* a = NULL;
ならばしっくりくる。
0047デフォルトの名無しさん
NGNG>>42と>>39をいっしょにするなよ
>>39はポインタ変数の役割が他のIntと違うから別個に宣言すると言ってるだけ
>>42のほうは int と int* が別物だと考えている
0048デフォルトの名無しさん
NGNG全く理解できない
それより、病院いけ？
0049デフォルトの名無しさん
NGNGそんな理解でC/C++使わないでくれ
0051デフォルトの名無しさん
NGNG面倒だから。
0052デフォルトの名無しさん
NGNGえー？！
じゃ、関数ポインタは
int(*) a(void) = NULL;
って書くんですか？
0053デフォルトの名無しさん
NGNG関数ポインタならこうする
int (* fncptr)(void) = NULL;
0054デフォルトの名無しさん
NGNG> 「変数名」と「他のもの」は離して書くよ。
じゃあ
int * a;
って書けばいいんじゃない？
0055デフォルトの名無しさん
NGNGCなら
int *a, *b, *c;
C++なら使うときにひとつずつ
int* a = new int(hoge);
0056デフォルトの名無しさん
NGNGで、君はどこスレの600?
0057デフォルトの名無しさん
NGNGバカ、このスレの未来から来たんだよ。
0058デフォルトの名無しさん
NGNG0059デフォルトの名無しさん
NGNGint a; と a = val; を一緒にした書き方の延長線上で見てしまうと、
int *a = ptr; が
int *a; と *a = ptr; では、辻褄が合わなくなるので、
int* a = ptr; と書くようにすることで、
int* a; と a = ptr; が 最初のと同様の見方が出来るからじゃないの？
宣言時の *a と 代入時の *a では
括弧を省略できるため見た目同じでも
意味するところは異なるのが原因だと思うけど...
代入時は *(a) とでもする？
0060デフォルトの名無しさん
NGNG0061デフォルトの名無しさん
NGNG>宣言時の *a と 代入時の *a では
>括弧を省略できるため見た目同じでも
>意味するところは異なるのが原因だと思うけど...
アフォ。
ではこれをどう説明するんだよ。
int a[] = {123, 345, 567};
0062デフォルトの名無しさん
NGNGC++の勉強のためにWebでいろんなコード見てきたけど、ほとんどint* aだよ。
参照もint &aなんて書いてるのかな？
0063デフォルトの名無しさん
NGNG昔は単純なプログラムしか組めなかったからどっちでもよかったけど
constとか関数ポインタ、多重ポインタとか使うようになるとint *aのほうが都合がよくなる
0064デフォルトの名無しさん
NGNG最強。
0065デフォルトの名無しさん
NGNG0066デフォルトの名無しさん
NGNG俺はint constだけど、世間一般ではconst intのほうが主流かな。
0067デフォルトの名無しさん
NGNG0068デフォルトの名無しさん
NGNG（ ・∀・）ﾆﾔﾆﾔ
0069デフォルトの名無しさん
NGNGchar const*
0070デフォルトの名無しさん
NGNGchar const * const
0071デフォルトの名無しさん
NGNG0072デフォルトの名無しさん
NGNG決定
0073デフォルトの名無しさん
NGNG> 最強は
> char const * const
だな。const char * const だと、どうしてよ？って思っちゃうし。
0074デフォルトの名無しさん
NGNG(cond)
? foo
: bar;
です。ハテナとコロンは揃えます。
いじょ。
0075デフォルトの名無しさん
NGNGif文で書いた方がわかりやすいと思う。
3項演算子の利点は一行で最小限の文字数で書けるところだと思っているけれど。。
0076デフォルトの名無しさん
NGNG0077デフォルトの名無しさん
NGNGフロー制御だけならif-elseでいいけど。
0078デフォルトの名無しさん
NGNG007974
NGNG一列だと コロン が埋もれてしまい見た目に探すのがつらいです。
（異論あるんだろーな。。）
0080デフォルトの名無しさん
NGNG> です。ハテナとコロンは揃えます。
演算子の記号が行先頭にくるように改行するのはGNUコーディングスタンダードの
条件文の書き方に通じるものがあるね。
if (condA
&& condB
&& condC)
ってやつ。
0082デフォルトの名無しさん
NGNG最高。
0083デフォルトの名無しさん
NGNG禿同
値を使わないのなら三項演算子ではなく if-else を使うべし。
値を使う場合、if-else で書いた場合についても考えてみて、
複雑さが同程度だったら if-else を使う方が好ましい。
0084デフォルトの名無しさん
NGNGif だと分岐したとき代入し忘れがあって怖い。
?:なら確実に代入できるので極力?:にしてる。
長くなりそうなら関数に抜き出して?:でディスパッチする。
checkstyle で使うなと起こられるのがつらい。
0085デフォルトの名無しさん
NGNGみたいな使い方は？
0086デフォルトの名無しさん
NGNG便利だよねえ。
0087デフォルトの名無しさん
NGNG0088デフォルトの名無しさん
NGNGrhs.assign(
make_transform_iterator(lhs.begin(), thef)
, make_transform_iterator(lhs.end() , thef));←最後の「);」これをここにいつも書いてんだけどどうよ？
vector< vector<int> >←「vector<int>>」のエラー対策の為に空けるスペースを先頭にも空けるて揃えるのがお気に入り。
0089デフォルトの名無しさん
NGNGrhs.assign
(
make_transform_iterator(lhs.begin(), thef),
make_transform_iterator(lhs.end() , thef)
);
0090デフォルトの名無しさん
NGNGrhs.assign(make_transform_iterator(lhs.begin(), thef),
make_transform_iterator(lhs.end() , thef));
0091デフォルトの名無しさん
NGNG変数・関数名やスコープの最小化のほうが重要。
009288
NGNG最初そう書こうかなと考えたこともあったんだけど
やたらと空白が目立って全体を眺めたら関数名との繋がりが希薄にかんじて････却下したんですよね。
>>90
それでも悪くは無いんですけど、
make_の開始位置が上と下じゃ揃わないから途中から書くのをやめました。ここじゃズレてましたけど・・・
最後の「));」を「) );」こうしてもいいですけどなんかしっくりこないんですよね。
じゃ改行か？と言ったら>>89に言ったような美徳センスが付きまとっていまいちなんですよね。
やっぱり個人差なのかな。
0093デフォルトの名無しさん
NGNGお前はナ。
0094デフォルトの名無しさん
NGNGここを参考にしながら書くのがよろしいかと
0095デフォルトの名無しさん
NGNGブラケットでスコープわけって普通に使われてんの？
func()
{
{
int a, b;
}
{
int c;
}
}
0096デフォルトの名無しさん
NGNG俺は普通に使ってるけど
0097デフォルトの名無しさん
NGNG0098デフォルトの名無しさん
NGNG96 名前：デフォルトの名無しさん[sage] 投稿日：04/10/03(日) 11:10:26
>>95
俺は普通に使ってるけど
97 名前：デフォルトの名無しさん[sage] 投稿日：04/10/03(日) 11:12:46
私もふつうに使っていますよ
0099デフォルトの名無しさん
NGNG0100デフォルトの名無しさん
NGNG0101デフォルトの名無しさん
NGNG普通だけど、私は使っていない
0102デフォルトの名無しさん
NGNGint get_hoge_fuge(args...)
みたいな関数の命名ですが、特にget,setで始まる場合は
アンダースコア _ 入れるかどうか迷うんですよね。
私はいちおう「入れる派」なんですが
ライブラリにあるやつとか ex.) getchar, gethostbyname, ...
のきなみ続けて次の単語書いちゃってるし、
外は雨降りだし、Javaの人はいいなぁって思う今日この頃。
0103デフォルトの名無しさん
NGNG0104デフォルトの名無しさん
NGNG括弧は仕方が無いがもっと打ちやすいところにほしい。
0105デフォルトの名無しさん
NGNGシフトキーを使うのも億劫になる程の
タイピング量が必要になるコードの方を
まずは禁止すべきだな。
0106デフォルトの名無しさん
NGNGラクダ記法はJavaコーディングスタイルだったっけ。
0107デフォルトの名無しさん
NGNG/*
*
*/
と
/*
*
*/
どっち？
アスタリスクが縦に揃うほうがいいなあ。
0108デフォルトの名無しさん
NGNGCやC++ではDoxygenに対応したコメント記法をするのが良いと思います。
後でDoxygenにかけることも考慮して。
0110デフォルトの名無しさん
NGNG/*
comment
*/
Doxygen なら
/*!
\brief comment
*/
0111デフォルトの名無しさん
NGNG/*
comment
*/
Doxygen なら
/*!
\brief comment
*/
0112デフォルトの名無しさん
NGNG\や!より@の方が目に優しい気がするような気がしないでもないかもしないかな、という気がした気がした。
0113デフォルトの名無しさん
NGNGJISだと'￥'になるのが悪いのかな。
'＼'なら'／'との組み合わせで見やすいのかも。
0114デフォルトの名無しさん
NGNG目立たないし、文字列のなかでエスケープに使われてると激しく見にくくないかな・・・。
0115デフォルトの名無しさん
NGNG慣れるとそうでもない。TeXとか使っていると\の方が違和感があるかも
0116デフォルトの名無しさん
NGNG確か...？
0117デフォルトの名無しさん
NGNG特にパスの区切り文字としては見た目、\より直感的な気がします。
Win では \\ の代わりに / もパスの区切り文字として
使えるんですよね。タイプが楽だし気に入っているんだけど
ソースのポータビリティを考えたら、使わんほうがいいんでしょうね…。
0118デフォルトの名無しさん
NGNG一部のAPI（PathXXX系）が対応してないから使わないほうが無難だね。
Perlとかだと /＼r＼n/＼n/ とか読みにくくね？
0119デフォルトの名無しさん
NGNG日本のユーザ以外は皆バックスラッシュなわけだし。
むしろ、￥に慣れた人が英語情報を見るとそんなとこでもひっかかったりして
余計にとっつきが悪くなるんじゃないかと変な心配してしまうんだけど。
Unicodeで文字コード世界統一のはずなのに、日本だけ世界と一部違うものが
Unicodeとされているというのもなんだか悲しいよう。
0120デフォルトの名無しさん
NGNG0121デフォルトの名無しさん
NGNG0122デフォルトの名無しさん
NGNGこれからはバックスラッシュに変えていくべきだと思うんだけど。
0123デフォルトの名無しさん
NGNGたんにフォントの問題だろ
0124デフォルトの名無しさん
NGNG0125デフォルトの名無しさん
NGNGそのように使われないならその問題なくて
「日本人はなぜかバックスラッシュが見たくもないほど嫌いらしい。
どれくらいかというとバックスラッシュの代わりに円記号を表示させるくらい
嫌いらしい。」という程度の話になるけど。
0126デフォルトの名無しさん
NGNG0127デフォルトの名無しさん
NGNGstatic_cast とか、reinterpret_cast とか、使ってますか？
C++的に言えば、使った方がいいんだが、どう考えてもCキャストのほうが読みやすい。
0128デフォルトの名無しさん
NGNG0129デフォルトの名無しさん
NGNGCスタイルキャストは禁止してる。
理由は以下のとおり。
・Cスタイルキャストは強力すぎる
・Cスタイルキャストは見つけにくすぎる
・Cスタイルキャストは dynamic_cast できない
ちなみに、どう考えたらCスタイルキャストのほうが読みやすいことになるのかわからない。
0130デフォルトの名無しさん
NGNG字数多いし。むしろ書きにくいから(ry
0131デフォルトの名無しさん
NGNG0132デフォルトの名無しさん
NGNG0133デフォルトの名無しさん
NGNGたぶん何か間違ってるんだと思う。
0134デフォルトの名無しさん
NGNGそんなことないと思う。
C++ の危険な領域に入り込んでいない健全な姿だよ。
0135デフォルトの名無しさん
NGNGdynamic_cast の出番は、時間さえあれば設計を見直すべきところがほとんど。
0136デフォルトの名無しさん
NGNG------------------------------------------------------------
ルールの理由:
private ではなくprotected としてデータ メンバを宣言すると、
メンバ関数中にカプセル化できたはずのメンバが派生クラスから見えてしまいます。
例
//
// protected データ メンバを宣言してはいけない
//
class A
{
protected:
int i; // 違反
};
0137デフォルトの名無しさん
NGNG素人でつか？
0138デフォルトの名無しさん
NGNG「俺様ルールの違反」とちゃんと書け。
0139デフォルトの名無しさん
NGNG--------------------------------------------------------------------------------
ルールの理由:
異なるコンパイル単位中の静的オブジェクトの初期化順序は、
C++ の言語定義では定義されていません。
そのため、コンストラクタからグローバル データへのアクセスは、
未初期化オブジェクトからの読み取りになる場合があります。
例
//
// コンストラクタから直接グローバル データにアクセスしてはいけない
//
int a;
class A
{
public:
A();
private:
int b;
};
A::A()
{
b = a; // 違反
}
0140デフォルトの名無しさん
NGNGfor(i=0; i<100; i++){ // 100回がんばる
}
0141デフォルトの名無しさん
NGNGかわいいじゃねぇか
0142デフォルトの名無しさん
NGNGconst void *p;
const_cast<int *>(static_cast<const int *>(p));
こんなんだったらCスタイルキャストの方が読みやすいかもしれない
0143デフォルトの名無しさん
NGNG画像演算とか。
一つの式中にキャストが10個くらい現れたりする。
C++キャストでは長すぎて意図が分からなくなってしまう。
const_castはさすがにCキャストで代用しようとは思わないが、
PODに対するreinterpret_castやstatic_castはCキャストのほうが分かりやすい時もある。
0144デフォルトの名無しさん
NGNGカッコ悪いプログラムがカッコ悪いソースになる。それがいいんじゃねぇか。
0145デフォルトの名無しさん
NGNGいずれにしても a の初期化し忘れ。
0146デフォルトの名無しさん
NGNGaは0で初期化される
0147デフォルトの名無しさん
NGNG0148デフォルトの名無しさん
NGNGint a, b;
これ最強
0149デフォルトの名無しさん
NGNGtypedef const Class & ClassRef;
typedef Class* ClassPtr;
0150デフォルトの名無しさん
NGNGウザ
0151デフォルトの名無しさん
NGNG"__" + プロジェクト名＋ファイル名
にする。
【例】
HelloWorld プログラムの Hello.h ファイルは、
#ifndef __HELLOWORLD_HELLO_H
#define __HELLOWORLD_HELLO_H
...
#endif
とする。
0152デフォルトの名無しさん
NGNG文句を言いたいのか、上記のように統一しろと主張しようとしてるのかわからんぞ
0153デフォルトの名無しさん
NGNGISO/ANSI規格では識別子の初めに _ が2つ続く物はコンパイラ・ライブラリ関数のために予約されているので駄目だ。
0154デフォルトの名無しさん
NGNG"_" がふたつだけじゃなくて、ひとつでも予約されてるんじゃなかったっけ？
(つまり "_" で始まる名前はすべて標準ライブラリ用に予約されてる)
0155デフォルトの名無しさん
NGNG変換したもの) + '_' だな。大文字/小文字はそのまんまだ。
#ifndef MotherHacker_h_
#define MotherHacker_h_
ここで気になるのが #endif なんだけど
a. #endif // !MotherHacker_h_ ( '!' あり )
b. #endif // MotherHacker_h_ ( '!' なし )
c. #endif ( なんもなし )
てめーらはどれ派？
漏れは昔は c.，以前は b. だった。でも今は a. 派。
0156デフォルトの名無しさん
NGNG#ifndef MOTHER_HACKER_H__
#define MOTHER_HACKER_H__
#endif// MOTHER_HACKER_H__
最後の_が２つなのがミソ
0157デフォルトの名無しさん
NGNG本当だ。
今まで'_'の次に英大文字か'_'の場合だけが予約かと思っていた
0158158=157=153
NGNGインクルードガードのときだけ例外的にb派。
#ifdef HOGEに対しては#endif // defined HOGEとしている。
0159デフォルトの名無しさん
NGNG#endif // !defined( _suffix_hoge_h_included_ )
0160デフォルトの名無しさん
NGNG#ifndef MotherHacker_h_
#define MotherHacker_h_
#endif//MotherHacker_h_
なぜって識別子の位置が揃うから
0161デフォルトの名無しさん
NGNG> なぜって識別子の位置が揃うから
うーん、気持はわからなくはないけど。
#elseや#endifに条件式をコメントとして入れとくのは、そもそも#ifの位置が
遠く離れてて把握できなくても条件式をすぐに理解できるようにするためでしょ？
そんな状況なら桁の位置が揃ってるかどうかなんて、どうでもいいと思うんだけど。
桁揃えが気になるような距離なら、そもそも条件式をコメントに書かなくてもいいし。
0162デフォルトの名無しさん
NGNG0163デフォルトの名無しさん
NGNG残念だがそのミソは予約されている。
0164デフォルトの名無しさん
NGNGプリプロセッサ命令は #if や #ifdef の中ではインデントさせる。
ただし # は必ず行頭に配置せよ。
例：
#ifdef HOGE
# include <hoge.h>
# ifdef FOO
# #include <foo.h>
#endif
#endif
0165デフォルトの名無しさん
NGNG0166デフォルトの名無しさん
NGNG入れ子をベタで書くのはよくない作法だろ。
0167デフォルトの名無しさん
NGNG↓こんなんも、#だけ行頭に動かすの？
{
while(...)
{
if(...)
{
#if HOGE
...;
#endif
...;
}
}
}
0168デフォルトの名無しさん
NGNG0169デフォルトの名無しさん
NGNG>>7や>>14も嫌いではない。
0170デフォルトの名無しさん
NGNG同じく普段は5を使っているが、行数制限があるときは7スタイルも使う。
0171デフォルトの名無しさん
NGNG個人的には>>14で書いてる。
>>5は、if の次に { だけの行がくるのがスカスカな感じでちょっといや。
0172デフォルトの名無しさん
NGNGWindows 2000 のコードとか、FFFTP なんかは、 >>5 のスタイルで書かれてるね
まぁ、>>14 の書き方でも絶対に間違わないって言う地震があるのならいいんじゃないの
好みの問題
0173デフォルトの名無しさん
NGNG0174デフォルトの名無しさん
NGNG俺は>>14だが。
0175デフォルトの名無しさん
NGNGなんか、切れそうで切れない生首のような、ほとんど首無しニックのような、気持ち悪さ。
0176デフォルトの名無しさん
NGNG0177デフォルトの名無しさん
NGNGif (...)
{
...;
}
else
{
...;
}
って書かれるとどうもね。
#2段も下げるなって感じ?
0178デフォルトの名無しさん
NGNGGNUスタイルですな。慣れればいいのかもしれないが、
俺は>>7でタブは8カラム。以前までタブでなくスペース派
だったんだが、今はまあいいかなと思えるようになった。
タブを行頭にしか使わなければ環境依存も(ある程度)
許容できるし。
0179デフォルトの名無しさん
NGNG別に大した問題ではないだろう。
TABをスペースに置き換えるなんてエディタの機能で一発だったりするでしょ。
手間は大したこと無いから全然気にしないで、自分の環境で一番やりやすいやりかた
ですれば良いと思うよ。
0180デフォルトの名無しさん
NGNG0181デフォルトの名無しさん
NGNG全部2TAB→スペース変換してコミット
0182デフォルトの名無しさん
NGNG*(int *)&a
じゃないのか？
0183デフォルトの名無しさん
NGNGそれじゃ a と同じになっちゃうだろ。
0184デフォルトの名無しさん
NGNGprintf(
"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
);
0185デフォルトの名無しさん
NGNGこうしている人の方が多いと思っているし。
0186デフォルトの名無しさん
NGNG全体はApacheスタイルに近い。
タブは4カラムで、スペースじゃないけど。
0187デフォルトの名無しさん
NGNGCのマナーいろいろ
http://pc5.2ch.net/test/read.cgi/tech/1029584140/
0188デフォルトの名無しさん
NGNG仕切り厨ウザイ
0189デフォルトの名無しさん
NGNG0190デフォルトの名無しさん
NGNGおまえがな。
0191デフォルトの名無しさん
NGNG0192デフォルトの名無しさん
NGNG0193デフォルトの名無しさん
NGNG0194デフォルトの名無しさん
NGNG0195デフォルトの名無しさん
NGNG0196デフォルトの名無しさん
NGNG条件 return の場合以外書かない。
0197デフォルトの名無しさん
NGNG関数であると明確にするために、書いておく。
0198デフォルトの名無しさん
NGNG0199デフォルトの名無しさん
NGNG0200197
NGNG悪いが、Pascalなんぞやったことないんだが。
0201デフォルトの名無しさん
NGNG無学を自慢するな
0202デフォルトの名無しさん
NGNG0203デフォルトの名無しさん
NGNG処理は全部副作用だけなんて…
0204197
NGNGどこがどう自慢だったんだね？
むしろ謝っているとしか言えないが。
0205デフォルトの名無しさん
NGNG石黒級の馬鹿だな。まず日本語をなんとかしろよ。
0206デフォルトの名無しさん
NGNG何か日本語の使い方でおかしいところなんてあったか？
お前こそなんとかして反論しようとして
無理やり絞り出したようにしか見えんな。
0207デフォルトの名無しさん
NGNG0208デフォルトの名無しさん
NGNG0209デフォルトの名無しさん
NGNG0210デフォルトの名無しさん
NGNGうまい
0211デフォルトの名無しさん
NGNGint 21h
0212デフォルトの名無しさん
NGNGそれ本気で言ってる？
もう必死すぎだなｗ
0213デフォルトの名無しさん
NGNGあまり強く言いすぎると、釣りってことにして逃げちゃって興醒めだよ。
真綿で首を絞めるみたいにイジらないと。
0214デフォルトの名無しさん
NGNG多分それ以前に>>212が釣りなんでは
0215デフォルトの名無しさん
NGNG0216デフォルトの名無しさん
NGNG「間違い」だろ？
0217デフォルトの名無しさん
NGNG本人だが同意
0218デフォルトの名無しさん
NGNG単純にtypo?
0219デフォルトの名無しさん
NGNGキチガイだったということで。
0220!=201
NGNG0221デフォルトの名無しさん
NGNGたまたま見つけた最悪なコードの見本。
0222デフォルトの名無しさん
NGNGパスカルやったことないよ
スクイークやったことないよ
シーシャープやったことないよ
セックルやったことないよ
一番ダメなプログラマーはどれ？
0223& ◆QWv3R1XL8M
NGNG耐えて、使えるようになりたい。
0224デフォルトの名無しさん
NGNGAC++というつまらない本を熟読する
0225デフォルトの名無しさん
NGNGパスカルやったことないよ
0226デフォルトの名無しさん
NGNG0227デフォルトの名無しさん
NGNGMC++ はどう？
0228デフォルトの名無しさん
NGNG0229デフォルトの名無しさん
NGNG0230デフォルトの名無しさん
NGNGメガバイトって言っているのと同じだよ
0231874
NGNG>#define unlong unsigned long
ﾜﾛﾀ
0232デフォルトの名無しさん
NGNG余りに痛々しいんだが。
0233デフォルトの名無しさん
NGNG0234デフォルトの名無しさん
NGNG俺は
switch(n){
case 0:
cout << "0" << endl;
break;
default:
break;
}
caseとswitchのインデントレベルは同じにしてるけど。
0235デフォルトの名無しさん
NGNGタブを４として、スペース２個を入れる。
0236デフォルトの名無しさん
NGNGK&Rと同じにしてる。
つまり同じレベル。
0237デフォルトの名無しさん
NGNG基本的にインデントが一気に2段下がることが無いように頑張っている
0238デフォルトの名無しさん
NGNG0239デフォルトの名無しさん
NGNG{
case 0:
cout << "0" << endl;
break;
default:
break;
}
0240デフォルトの名無しさん
NGNGswitch (n) {
case FOO:
foo();
break;
case BAR: {
int x = bar(n);
baz(x);
break;
}
default:
/* NEVER REACH HERE */
abort();
}
0241デフォルトの名無しさん
NGNG{
case FOO:
foo();
break;
case BAR
{
int x = bar(n);
baz(x);
break;
}
}
俺のスタイル。
0242デフォルトの名無しさん
NGNG{
case FOO:
foo();
break;
case BAR
{int x = bar(n);
baz(x);
break;
}
}
俺のスタイル。
0243241
NGNG0244デフォルトの名無しさん
NGNGそれがpublic、protected、privateのことなら俺も同じ。
0245デフォルトの名無しさん
05/01/30 14:52:510246デフォルトの名無しさん
05/02/03 22:24:32case 1 : {
foo();
} break;
case 2 :
case 3 :
case 4 : {
foo();
} break;
case 5 :
foo();
// Fall Through
default : {
foo();
} break;
}
俺のスタイル。
switchは滅多に使わんがなー
0247デフォルトの名無しさん
05/02/04 20:26:430248デフォルトの名無しさん
05/02/04 20:31:31そうかそうか、それは素晴らしい書き方だな。よーくわかったぞ。
0249デフォルトの名無しさん
05/02/27 15:11:54必死だなｗｗｗｗ
0250デフォルトの名無しさん
05/03/02 12:56:35{
case FOO:
foo();
break;
case BAR
{
int x = bar(n);
baz(x);
}
break;
}
0251デフォルトの名無しさん
05/03/05 03:57:03おお、なんと感動的な書き方なんだ。正直、俺は感動した。
0252デフォルトの名無しさん
05/03/05 19:25:32switch (n)
{
case FOO:
foo();
break;
case BAR:
// baz(int&) の引数のために実体となる変数が必要 ← みたいに、なんかコメントしとく
{
int x = bar(n);
baz(x);
}
break;
}
0253デフォルトの名無しさん
05/03/06 00:00:51switch(n)
{
case FOO:
{
foo();
break;
}
case BAR:
{
int x = bar(n);
baz(x);
break;
}
}
0254デフォルトの名無しさん
05/03/06 03:32:58case FOO:
foo();
break;
case BAR: {
int x;
bar();
break;
}
こう書いてたっけ？
個人的には{で改行しない方が若干見やすいかなぁ
0255デフォルトの名無しさん
05/03/08 00:16:03メンバ変数にhoge_と尻尾に_を付けるのではなく
一時変数に_を付ける
spiritのサンプルにあった。
メンバに堂々と何もつけないのはなかなか気持ちがよいな
0256デフォルトの名無しさん
05/03/08 00:45:46> 一時変数に_を付ける
激しく受け入れ難い。
0257デフォルトの名無しさん
05/03/08 19:00:080258デフォルトの名無しさん
05/03/08 20:56:40this->が付いてたらメンバ。
0259デフォルトの名無しさん
05/03/09 06:37:01技術的なメリット、デメリットでは this-> が最強なんだよな。
・クラステンプレートのコードでは付けないと恐ろしい罠に嵌りかねない。
・bool Is〜() な関数を自分で呼ぶときも this->Is〜() が読みやすい。
・無節操にメンバに触りまくって最適化を台無しにする糞コードが減る。
問題は、一般性が皆無なことだな。
this-> と等価な . （単項ドット演算子）を作って、
省略不可にすれば、・・・どうなっていただろう？
0260デフォルトの名無しさん
05/03/09 13:37:060261デフォルトの名無しさん
05/03/09 13:47:480262デフォルトの名無しさん
05/03/09 18:57:55int size;
public:
AAA (int size)
: size(size) // この行
{}
};
こんなコードが通るのが微妙に気持ち悪かったり。
かといってメンバ名と仮引数名にうまく別の名前をつけられる妙案がない……。
this->size(size) って書ければ多少気持ち悪さも減るかと思ったの。そんだけ。
0263デフォルトの名無しさん
05/03/09 19:03:41class AAA {
int size;
public:
AAA(int size) : .size(size) {}
};
はどう?
これも気持ち悪い?
0264デフォルトの名無しさん
05/03/09 19:04:38> 省略不可にすれば、・・・どうなっていただろう？
視認性が悪いものを必須にするのはちょっとなぁ。
いっそPythonよろしく、メンバ(変数|関数)の参照はthis必須の方がまだまし。
それに、visitor.visit(this)があるから、thisキーワードを
なくせるわけじゃなし、見づらい構文糖衣の意味しかないと思われ。
0265デフォルトの名無しさん
05/03/09 19:47:29そうじゃないならm_プレフィクスの方がいいな。
0266デフォルトの名無しさん
05/03/10 00:49:11クラス内のメンバ関数の実体を書く順番は
a)宣言と同じ順に
b)重要なもの、呼ばれる頻度などの順に書き、宣言と順番が違う
c)宣言から b) の順で、実体はその順
d)んなもん気にしてない
他にオレ流あるなら追記ヨロ
あと、protected とかの種類別に分けてる or 分けてない？
0267デフォルトの名無しさん
05/03/10 01:32:35漏れ的には、
1) public -> protected -> private の順で宣言も実装も行う
2) コンストラクタとデストラクタは全てのメンバ関数に先駆けて書く
という感じ。
0268デフォルトの名無しさん
05/03/10 02:59:050269デフォルトの名無しさん
05/03/10 11:46:21基本的に宣言は宣言だけ。
実装は別ファイル。
テンプレートを除いてインライン関数も使わない。
例外は3つあって、一つは単に値を返すgetter系。
もう一つはシグネチャの違う他のメンバ関数を呼ぶだけのようなもの。
3つめは初期化リストだけで済んでしまって中身が何もないコンストラクタ。
これらは宣言のところに実装も書いてしまう。
実装のファイルでは意味的なグループごとに関数を近接させる。
public等のアクセス修飾は関係なし。
0270デフォルトの名無しさん
05/03/16 10:55:250271デフォルトの名無しさん
05/03/16 10:57:200272デフォルトの名無しさん
05/03/18 06:34:51ヘッダーには宣言だけ書いてる。インライン関数は全部.inlに。
見た目もすっきりするし、最適化とかデバッグの時に有利かと。
0273デフォルトの名無しさん
2005/04/03(日) 01:17:180274デフォルトの名無しさん
2005/04/06(水) 11:06:38hoge()
か
void hoge()
か
0275デフォルトの名無しさん
2005/04/06(水) 12:47:11return_type
function_name
(argument1_type argument1_name,
argument2_type argument2_name)
{
}
0276デフォルトの名無しさん
2005/04/06(水) 12:50:11void hoge(T arg)
0277デフォルトの名無しさん
2005/04/06(水) 22:21:12template<typename T>
ReturnType
FunctionName(
ArgType1 arg1,
ArgType2 arg2)
{
}
0278デフォルトの名無しさん
2005/06/12(日) 05:19:09}
for(; ; ) {
}
無限ループでも、例外なく ; の後にスペースを空ける。
0279名無しさん＠そうだ選挙に行こう
2005/09/11(日) 14:42:070280デフォルトの名無しさん
2005/09/17(土) 11:31:43marudasi(lambda() {baka;} );
と書ける処理系作ったおれはスゴイ
0281デフォルトの名無しさん
2005/09/18(日) 20:12:33こだわる人は勉強してる人が多いけど
0282デフォルトの名無しさん
2005/11/08(火) 00:30:45付けない
無くて困ると言う事は、クラスが巨大過ぎる気がする
0283デフォルトの名無しさん
2005/11/08(火) 08:18:16付けてる人同士のソースの相互理解容易度の高さを知らないんだね
どんなに小さいクラスでも有用だよ。
0284デフォルトの名無しさん
2005/11/08(火) 20:46:401. 見てわかる
2. リファクタリング用の機能がなくても一気に置換できる
3. this->は長い上にどこかのメンバ関数の中でつけ忘れててもコンパイルでき
処理系で強制できない。
0285デフォルトの名無しさん
2005/11/09(水) 23:53:23まあ、美意識の問題が大きいので（慣れもかな）
m_は、個人的に、異様に汚く見える（あくまで主観）
ローカル変数は、宣言即初期化派＆＆
それが追い辛くなるほどメソッドを大きくしない派
なので、メンバ変数と区別が付かない||相互理解が不便なんて事は無い
0286デフォルトの名無しさん
2005/11/10(木) 00:33:08きこえてアムロ？メンバ変数とローカル変数を見分けるまでの作業量が全然違うのよ。
単純化するためにグローバル変数とかスタティック変数とかは抜きにして説明すると
■メンバ変数とローカル変数に命名方法の区別をしない場合
1) ある変数を見る。
2) その変数より前の部分を関数のはじめまでみる
3) 途中に宣言があればローカル変数、引数に指定されてれば引数、どちらでもなければローカル変数と決定できる。
■プリフィックス又はサフィックスでメンバ変数のみ印付けをしている場合
1) ある変数を見る
2) その変数に印付けがされていればメンバ変数、そうでなければローカル変数か引数
上下方向への視点の動きがまったく発生しなくなるのがおわかりいただけて？
0287デフォルトの名無しさん
2005/11/10(木) 01:36:470288デフォルトの名無しさん
2005/11/10(木) 02:25:02否、だから・・・
＞上下方向への視点の動きが
そんな事が邪魔になる様なコードを書かないって話。
逆に、それで解りづらくなると、メソッドの構成とかを見直すから
無い方が良い気もしないでもない。。
見分けが解りやすいと、その辺が鈍感になる
それから
＞1) ある変数を見る。
＞2) その変数より前の部分を関数のはじめまでみる
こんな追い方しなきゃいかんと言う事は
メソッドが長すぎるんでないかい？？
さらに、それから、別にm_を否定してる訳ではない、念の為
0289デフォルトの名無しさん
2005/11/10(木) 02:38:10視点って目が見てる部分のことだよ？
速読術でもやってる人ならわからないけど
普通の人間は"面"全体を注目することはできない。
文章の中やコードの中であれば、一行しか注目はできないの。
ここまでOK？
ある変数名に注目してしまった時、
コードが2行以上ならばもう他の行は同時には注目できないでしょう？
そのある変数名に注目した段階で判別できる方法が
何らかのプリフィックスやサフィックスを使う方法で、
一度別の部分に注目する場所を移してから判別するより
遥かに効率がいいの。
あなたのコードが全てベーマガに掲載されそうな一行コードならいいんだけど。
0290デフォルトの名無しさん
2005/11/10(木) 02:49:00？
人間の視点って「"面"全体」は見ること出来ないけど
「ある程度のかたまり」で認識できると思うけど
逆に、「一行しか」って注目は難しい気がする
横だけの集合だけ注目度が高くなるのも
ちょっと不思議な気がしないでもない
0291デフォルトの名無しさん
2005/11/10(木) 02:59:28メンバ変数に size なんてのが置きたくなって
メンバ関数の size() と被ってしまう。
m_ はそんな時にも助けになる。
0292デフォルトの名無しさん
2005/11/10(木) 03:04:200293デフォルトの名無しさん
2005/11/10(木) 03:13:090294デフォルトの名無しさん
2005/11/10(木) 07:56:03結局"おれはm_とか付けたくない"っていう結論ありきで
相手の話を理解しようとして聞いてないじゃない
あんたはソースの中に縦書きでも探してれば？
それとも縦書きに釣られすぎて横方向に文字読みながら
縦方向にも縦書きを探せるなんてかわいそうな
特殊技能でも身に着けちゃってるのかね
0295デフォルトの名無しさん
2005/11/10(木) 08:49:37コードレビューとして考えて意味の把握のしやすさのほうが問題で、
個人的には単純に視点の移動を作業量と考えるのはメリットが無い。
絶対的な利便性があるわけでもなく、強制はナンセンス。
そうしたい人だけそうすれば。
0296295
2005/11/10(木) 08:51:58訂正、そういう規約がある/必要な場合にその人が守ればいいだけ。
0297デフォルトの名無しさん
2005/11/10(木) 10:51:060298デフォルトの名無しさん
2005/11/10(木) 11:18:220299デフォルトの名無しさん
2005/11/10(木) 12:00:32と言ってるのだが、
>>297
ほう、見識が高いと、m_ プリフィックスはハンガリアンではないと?
それはそれで言い分があるかもしれないから、まともに見識のあることを
喋ってごらん。喋れるなら。通じない根拠や相手の非難だけにすり替えないで。
0300デフォルトの名無しさん
2005/11/10(木) 12:05:00別におれは297じゃないんだけどさ。
もとの書き込み(>295)では「みたいなもの」などと言わずに、そのものだと言い切っている。
「ハンガリアンはプリフィックス」は真だと思うが、
「プリフィックスはハンガリアン」とは言えないだろう。
「ごめんなさい」が言えない人ですか？
0301300
2005/11/10(木) 12:07:43> 「プリフィックスはハンガリアン」とは言えないだろう。
ごめん、「m_ プリフィックス」ってなってるのを見落としてた。
「m_ プリフィックス」はハンガリアンじゃなくて
ただのメンバ変数を表すプリフィックスだから
言いたいことは同じだけどね。
0302297
2005/11/10(木) 12:40:51m_プリフィックスがハンガリアンだという資料があれば俺に教えて欲しいくらいだ。
まず君はここらへんから読みたまえ。
http://www.radiumsoftware.com/hungarian_notation.html
メンバ変数か否かというのはC/C++言語における"型"かね？
そうではないだろう？
0303295
2005/11/10(木) 13:39:17なんだ、見識どうこうといって、やはりその話なんだ。
もちろん 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_がハンガリアンであろうとなかろうと論旨には全く関係無いが、
そういうところを見識といって揶揄するぐらいしかできないと?
0304デフォルトの名無しさん
2005/11/10(木) 14:20:48なんかスレが伸びてると思えば。もう頭悪いね君としか言いようがないな。
1. m_ はcoding style convensionであって、属性をコード化するハンガリアン
とは関係ない(ハンガリアンの延長線上と看做す向きもあるが見解の分かれる
ところであるし、個人的には牽強附会と思う)。
論争が意味ないとかいうのは一連の議論を否定するただの煽りでしかなく、
m_プレフィクスの無用性について意味のある主張をしたいのなら命名法で
区別することによるメリットがないことを示せ。もしくは>>295の
> コードレビューとして考えて意味の把握のしやすさのほうが問題で、
というのがm_プレフィクスにより激しく損われるという論拠でもよい。
(それが他人にとってm_プレフィクスの有用性に優越するかどうかは別の問題だ
が、個人・場合による問題なので異なる見解が両立し得る)
一般のハンガリアン記法の適用を否定する主張としては一理あるが、我々は
m_プレフィクスについての議論をしているのであり、ハンガリアンの延長線上と
君が看做したからといって盲目的に適用するのは無茶と言うもの。
2. ただの煽りでしかなければ見識がないと言われるのは必然である。しかも
> で、別に m_がハンガリアンであろうとなかろうと論旨には全く関係無いが、
という主張は
> まあしょせんハンガリアン命名記法だから、
で始まる>>295自体の意味を否定する。即ち>>295が無意味な煽りであり、295には
見識がないということを自分で立証している。
3. ちゃんと理由は挙げられているのに個別に反証することなく
> (たいてい賛成派もきちんと理由を挙げられない)
と書いているのは他人のレスをろくに読みもしていないことを立証している。
0305295
2005/11/10(木) 15:23:50>ハンガリアンの延長線上と看做す向きもあるが見解の分かれる
>ところであるし、
>(それが他人にとってm_プレフィクスの有用性に優越するかどうかは別の問題だ
>が、個人・場合による問題なので異なる見解が両立し得る)
つまりどちらかの立場をとること自体に問題は無い。
>区別することによるメリットがないことを示せ。
すでに>>288等(295とは別人)も繰り返してるだろう。
結局"おれはm_と付けてる"っていう結論ありきで
相手の話を理解しようとして聞いてないじゃない
#288等補足:
#コードレビューとして考えて意味の把握のしやすさのほうが問題で、
#個人的には単純に視点の移動を作業量と考えるのはメリットが無い。
#(個人的には可読性が落ちるケースが少なくない。m_をつけて
#よしとして全体としての意味をとりにくい名前のままの事があるから、
#とも思っている)
>2.
煽られたと思うところ、喰いつきやすそうな所だけ問題にしたい、と。
<絶対的な利便性があるわけでもなく、強制はナンセンス。
<そういう規約がある/必要な場合にその人が守ればいいだけ。
>3. ちゃんと理由は挙げられているのに個別に反証することなく
ええと、そのちゃんとというのは >>286,289 あたりですか?
(直後にも反論(?)ついてるようですが)
0306デフォルトの名無しさん
2005/11/10(木) 17:05:51自分の価値が下がるわけじゃない。むしろ上がるさ。
0307デフォルトの名無しさん
2005/11/10(木) 17:51:58"おれはm_と付けてる"から揶揄に終始しますと。ご苦労様です。
別にまともな論が無かろうと、そういう規約がある/必要な場合に
そうするのは止めやしない。まこといまさら論争自体がナンセンス。
0308306
2005/11/10(木) 18:34:58食いついた方が、実は自分が不利だと悟ってる方だと思って
書き込んでみたがこううまくいくとは思わなかった。
0309デフォルトの名無しさん
2005/11/10(木) 20:46:470310デフォルトの名無しさん
2005/11/10(木) 22:16:15そろそろ次の話題行きましょ。
0311デフォルトの名無しさん
2005/11/10(木) 22:47:43自分で相手の主張を肯定していることに気がつかない頭の弱さｶﾜｲｿｽ。
0312デフォルトの名無しさん
2005/11/19(土) 03:13:19後者。grep で関数名引いた時、返す型が表示されないってのは
かなり痛い。
0313デフォルトの名無しさん
2005/11/22(火) 00:59:22つ grep -B 1
0314デフォルトの名無しさん
2005/11/23(水) 17:13:43レス先書かなきゃ、直前のレス宛だと考えるのが普通ですよ。
こういうのがわからない人のコードって、さぞ自分勝手なんだろうな :-)
0315デフォルトの名無しさん
2005/11/26(土) 02:31:31多人数で作ってると付けて欲しいんだよね。
人によってスタイル違うしクラスからグローバル変数使いまくりな
タココード書く奴が足引っ張って大変。
メンバ関数内で何も付けずにローカル、メンバ、グローバル変数が
入り乱れた他人のコードを追うのはきついぞ。
そんなので新人がマルチスレッドのコード書くもんだからたまらん。
何も付けない派の奴らにお見舞いしたいコードだ。
0316デフォルトの名無しさん
2005/11/26(土) 04:43:41それはプレフィクスごときで解決する問題じゃないと思うが……
0317デフォルトの名無しさん
2005/11/26(土) 13:15:48m_ でも g_ でも付けないでもいいから、とにかく揃えておくというのが重要かと
タココードを書くやつがいるというのは別問題だな
0318デフォルトの名無しさん
2005/11/26(土) 13:36:21staticメンバ変数として隠蔽されていた方が、かえって追跡しにくい場合もある。
タココードの場合は、独自の名前空間にいれるよう強要すれば問題解決でしょ・・・多分。
0319デフォルトの名無しさん
2005/11/26(土) 13:43:54グローバルスコープで宣言された日には手も足もでないんだけどね。
0320デフォルトの名無しさん
2005/11/26(土) 14:07:00> グローバル変数はそれなりに存在価値がある。
> staticメンバ変数として隠蔽されていた方が、
> かえって追跡しにくい場合もある。
具体的にどんな場合？
0321デフォルトの名無しさん
2005/11/26(土) 14:56:06タコかどうかなんて、ほぼ書き上げられたソースを見るまで
判らん場合もあるわけで
0322デフォルトの名無しさん
2005/11/26(土) 15:17:250323デフォルトの名無しさん
2005/11/26(土) 20:49:16ネーミングルールを決めただけでタココード/糞コードがそうでなくなることなど無い
0324デフォルトの名無しさん
2005/11/26(土) 22:37:23・・・確かに。
タコのタコたる所以は、命名ルール無視などという生易しいものではない罠。
0325デフォルトの名無しさん
2005/11/26(土) 23:53:510326デフォルトの名無しさん
2005/11/27(日) 00:31:43理解できないコードを書く奴を抑止できる状況にもっていけない
場合は多々ある。せめてg_だけでもいいから付けてくれ。
予期せぬ不具合はグローバルがらみが多すぎる。
0327デフォルトの名無しさん
2005/11/27(日) 04:42:19結局、自分で検索してマーキングした方が間違いなかったりする。
0328デフォルトの名無しさん
2005/11/27(日) 16:37:26タココード見たことないのか？
お前がタコじゃないか？
0329デフォルトの名無しさん
2005/11/27(日) 17:08:41おまえのように１か０かしか言わない奴っているよな
そして何も状況は変わらない
そりゃタコを育てる時間があったり、タコを入れ替えて優秀なマを入れる
余裕のある所はそうするのが最善だろうが
0330デフォルトの名無しさん
2005/11/27(日) 19:44:03／:::::::::::::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
0331デフォルトの名無しさん
2005/12/04(日) 11:56:55set_xxxx,get_xxxx関数を作るのがコーディングに真の勝者なのだ。
0332デフォルトの名無しさん
2005/12/05(月) 02:24:340333ハーピィ
2005/12/05(月) 02:45:570334デフォルトの名無しさん
2006/01/01(日) 15:46:50なんでオマエ関西風味よ？ｗ
0335デフォルトの名無しさん
2006/01/05(木) 09:59:06プロパティ
0336デフォルトの名無しさん
2006/02/03(金) 16:12:470337デフォルトの名無しさん
2006/03/15(水) 06:14:52俺のクラスとか変数とか関数とか皆最初大文字なのに
統一できない
0338デフォルトの名無しさん
2006/03/15(水) 06:25:39いっそ、std::find()→StdFind()みたいな置き換えインクルードファイルでも作ればいいじゃん。
#一度作ればずっと使えるわけだし。
0339デフォルトの名無しさん
2006/03/15(水) 21:16:58自分の名前空間に入れろよ。
0341デフォルトの名無しさん
2006/03/18(土) 17:51:12言い方が冷たいよ…もっとお母さんみたいに言ってくれ。
0342338
2006/03/19(日) 17:05:020343デフォルトの名無しさん
2006/03/20(月) 14:14:290344デフォルトの名無しさん
2006/05/01(月) 07:35:440345デフォルトの名無しさん
2006/05/01(月) 07:47:460346デフォルトの名無しさん
2006/05/01(月) 09:18:33僕は派生されるクラスからもアクセスできるようにprotectedに入れたいのですが、
先輩はprivateにいれてアクセス用の関数を作るべきだといいます。
その方が変数名が変わったとき、派生クラスを直さなくてよいから、
というのが理由だそうですが、どうも納得行きません。
どうにか説得できないでしょうか？
0347デフォルトの名無しさん
2006/05/01(月) 09:21:05protected は中途半端。
方針としては中途半端。
「見えちゃ嫌だけどちょっとは見えたほうが」
そんなの微妙すぎ。
0348デフォルトの名無しさん
2006/05/01(月) 09:28:09protected な変数が必要になるのはカプセル化が弱いせいではないか？
よく考えることだ。
たとえば、変数を protected にするということは、何かしら
特別な意味を持った操作を想定しているのではないか？
そうだとしたら、変数は private にしてその操作を関数にするべきだ。
逆に見えてもいいってことは、どういじったところで問題ないんじゃないか？
そうだとしたら、その変数は public でいい。
どちらにも当てはまらないときだけ、 protected を使う根拠になる。
0349デフォルトの名無しさん
2006/05/01(月) 09:55:29↓こんなのがエラーになるから嫌だ。
class B { protected: int n; };
class D : public B { int f(B& b) { return b.n; } };
0350デフォルトの名無しさん
2006/05/01(月) 09:58:46Sleep(∞)
0351デフォルトの名無しさん
2006/05/01(月) 10:00:520352デフォルトの名無しさん
2006/05/01(月) 12:47:56全部Set/Get関数使うの〜？
0353デフォルトの名無しさん
2006/05/01(月) 13:16:38だからそれは設計が悪いんだって。
0354デフォルトの名無しさん
2006/05/01(月) 14:50:360355デフォルトの名無しさん
2006/05/01(月) 15:19:07class 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.
};
// 書いてて知恵熱が出てきた
0356デフォルトの名無しさん
2006/05/01(月) 18:25:35ユーザーがクラスのメンバにアクセスできなきゃ不便でしょうがなくない？
全部Set/Get関数使うの〜？
って聞かれてる気分だ。
0357デフォルトの名無しさん
2006/05/01(月) 18:59:59Personから派生したStudentは名前無しって事か。
学生は辛いな。
0358デフォルトの名無しさん
2006/05/01(月) 19:06:32Person の「名前」が private なら、 Person に「名前」があることは
Person 以外だれも知らないから問題ない。
Person に「名前」ある（と外部が知っている）ということは、
Person の「名前」は public であるから Student が Person を
public 継承していれば何も問題ない。
0359デフォルトの名無しさん
2006/05/01(月) 19:18:41private だとメンバ変数が消えるとでも思ってんの？
0361デフォルトの名無しさん
2006/05/01(月) 19:37:070362デフォルトの名無しさん
2006/05/01(月) 19:38:22アクセスする手段はそのメンバを持ってるクラスが提供するんだよ。
0363355
2006/05/01(月) 19:49:51漏れが書いたコード見て言ってる?
規定クラスにはそういうI/Fを用意したけど、派生クラスで敢えてオーバーロードで潰しているんだけど。
もしかして>359=>361=>362?
喪前様のレスからは意味のある情報が一つも引き出せないのだけれど。
0364デフォルトの名無しさん
2006/05/01(月) 19:54:57潰してる？アップキャスト一発で破綻するだろ？
0365デフォルトの名無しさん
2006/05/01(月) 19:57:17>Person の「名前」が private なら、 Person に「名前」があることは
>Person 以外だれも知らないから問題ない。
StudentはPersonなんだから名前がある事を知っていた方がよくない？
privateだとStudentからも見えないわけだが。
Person has-a Name.
Student is-a Person.
よって、Student has-a Name.
0366デフォルトの名無しさん
2006/05/01(月) 20:09:16> StudentはPersonなんだから名前がある事を知っていた方がよくない？
> privateだとStudentからも見えないわけだが。
そこで public にしないのは何故だ？
0367デフォルトの名無しさん
2006/05/01(月) 20:10:15それぞれにアクセス制限を選ぶことが考えられる。
private なデータメンバと、 public な参照用メソッドがあるのが一般的だな。
protected の出番はなかなか思い当たらない。
0368デフォルトの名無しさん
2006/05/01(月) 20:48:09何かにまとめられているの？
関係ないけどCをオブジェクト指向っぽくできないものかと
思案中・・・
一応組み込み向けの本でそれらしきのがあったのでそれを参考にしてますが・・・
0369デフォルトの名無しさん
2006/05/01(月) 20:56:01「カプセル化」という基本事項にまとめられると思ってる。
クラスを作る意義のひとつだな。
C でオブジェクト指向なんてメンドクサイから C++ 使えよ。
0370デフォルトの名無しさん
2006/05/01(月) 21:16:24悩みから開放されるぞ。
「みんな大人だ」
0371デフォルトの名無しさん
2006/05/02(火) 02:38:05C++ よりずっとセクシーだぞ
0372デフォルトの名無しさん
2006/05/02(火) 08:18:54>protected の出番はなかなか思い当たらない。
派生クラスだけにアクセスさせたい変数はprotectedでいいのでは？
そうゆう変数って普通に沢山あると思うけど。
0373デフォルトの名無しさん
2006/05/02(火) 08:20:430374デフォルトの名無しさん
2006/05/02(火) 08:23:13その関数を protected にするなら同じやん
0375デフォルトの名無しさん
2006/05/02(火) 08:25:42同じだと思うなら private にしとけよ。
protected なデータメンバだと派生クラスから変更できてしまうからカプセル化が崩れる。
0376デフォルトの名無しさん
2006/05/02(火) 08:43:350377デフォルトの名無しさん
2006/05/02(火) 10:41:38http://www.google.co.jp/search?q=%22you+don%27t+have+to+use+protected+data+in+C%2B%2B%22
0378デフォルトの名無しさん
2006/05/02(火) 11:15:14言ってる奴いたな
会社でそういうソースを見て頭がいたくなったとかなんとか
たいそうな達人ですなｗ
0379デフォルトの名無しさん
2006/05/02(火) 12:42:20セオリーと現実の違いだと思う。
すべてをカプセル化するのは現実的にはオーバーヘッドが大きすぎる。
熟練したＣ＋＋プログラマならprivateとprotectedをきちんと使い分できる。
0380デフォルトの名無しさん
2006/05/02(火) 12:47:08きちんと使い分けた場合 protected の出番はごく稀になると思うんだが、どうかね？
特にデータメンバにおいては皆無になるだろう。
0381デフォルトの名無しさん
2006/05/02(火) 12:49:28inine がある C++ ではオーバーヘッド無しでカプセル化を実現可能じゃないか？
0382デフォルトの名無しさん
2006/05/02(火) 12:55:46強硬にカプセル化を否定しているのを、普通にC++を使えているプログラマ連中が
ﾆﾖﾆﾖしながら構っているのを、慣れてないC++プログラマが困惑しながら見守っている
スレだということで宜しいか。
0383デフォルトの名無しさん
2006/05/02(火) 12:56:170384デフォルトの名無しさん
2006/05/02(火) 14:45:250385デフォルトの名無しさん
2006/05/02(火) 19:44:070386デフォルトの名無しさん
2006/05/02(火) 20:26:09誰か識者の人解説してくれないかな。
protectedとpublicの概念に、明確な違いがあるのなら。
0387デフォルトの名無しさん
2006/05/03(水) 08:01:23protected＝自分ちで全裸
private＝風呂で全裸
家族になら見られてもいいって人はprotectedもアリだと思うよ。
0388デフォルトの名無しさん
2006/05/03(水) 08:08:330389デフォルトの名無しさん
2006/05/03(水) 08:09:100390デフォルトの名無しさん
2006/05/03(水) 08:21:25具体例をきぼん
0391デフォルトの名無しさん
2006/05/03(水) 08:55:59卑猥なやつだな。しかもageてるし。恥ずかしいだろ。
0392デフォルトの名無しさん
2006/05/03(水) 09:43:29恥ずかしいなら手術すればいいのに。
0393デフォルトの名無しさん
2006/05/03(水) 09:49:470394デフォルトの名無しさん
2006/05/03(水) 12:40:52ﾋﾞｸｰﾘ
0395デフォルトの名無しさん
2006/05/03(水) 13:20:15じゃあお前が誰でも納得できるように説明してみろやカス
0396デフォルトの名無しさん
2006/05/03(水) 13:41:150397デフォルトの名無しさん
2006/05/03(水) 13:44:39全部privateで書いて、とうしても必要になったらprotectedに変えればいいじゃん。
もっと面白いコーディングスタイルの話題は無いのか？
0398デフォルトの名無しさん
2006/05/03(水) 14:03:52ﾌﾟ 設計が悪い事に気づいてない奴が一人
0399デフォルトの名無しさん
2006/05/03(水) 14:08:56eclipseのJDTみたいに、チェックボックスにチェック入れるだけで
getterとsetter書ける開発環境があればprivateにしてやるよ。
0400デフォルトの名無しさん
2006/05/03(水) 14:46:10そんな奴がいるから VB とか C# にはプロパティなるものがあって、
Visual Studio にはプロパティ生成機能が付いてる。
0401デフォルトの名無しさん
2006/05/03(水) 14:58:28自分が理解できない事には「ツマンネ」で終わらす気ですか？
0402デフォルトの名無しさん
2006/05/03(水) 15:54:370403デフォルトの名無しさん
2006/05/03(水) 15:59:26もう「コーディング」じゃなくなるから
0404デフォルトの名無しさん
2006/05/03(水) 20:13:120405デフォルトの名無しさん
2006/05/03(水) 21:55:12使いたいんですが、Windows用でおすすめがあれば教えて下さい。
0406デフォルトの名無しさん
2006/05/03(水) 23:27:26移譲先が同じ翻訳単位内なら直にリンクしてくれたりするんですかね？
0407デフォルトの名無しさん
2006/05/04(木) 07:35:21でも他人にはおれが分からないんだから、おれにアクセスするならコミニケーション取ってねって事でしょ。
だからおれは継承元クラスでは protected は結構使ってるな。
カプセル化を理由になんでもかんでも Set,Get なんでうざいだけじゃね？
0408デフォルトの名無しさん
2006/05/04(木) 07:36:250409デフォルトの名無しさん
2006/05/04(木) 08:23:38そこで値の検査をするなどと言ったこともできる、って当たり前のことだよな？
0410デフォルトの名無しさん
2006/05/04(木) 08:40:09当たり前のことだな。カプセル化を否定してる訳じゃないよ。
でも値チェックするまでもないようなメンバとかも結構あるでしょ。
必要だと思う物はカプセル化してる。
使い勝手は人それぞれだけど、おれは直接アクセスできる方が便利だと思える箇所はそれなりにあるな。
こんなこと言うと、設計が甘いって言う人が出てくるんだけどな(´∀｀)
0411デフォルトの名無しさん
2006/05/04(木) 09:44:530412デフォルトの名無しさん
2006/05/04(木) 10:02:590413デフォルトの名無しさん
2006/05/04(木) 12:58:120414デフォルトの名無しさん
2006/05/06(土) 15:44:31今までで一番まともな見解。
やっぱり仕事としてプログラマしてる人は分かってるね。
0415デフォルトの名無しさん
2006/05/06(土) 15:46:58さすがプロの人の意見は参考になります（＞＜）
0416デフォルトの名無しさん
2006/05/06(土) 15:49:230417デフォルトの名無しさん
2006/05/06(土) 16:17:200418デフォルトの名無しさん
2006/05/06(土) 23:06:400419デフォルトの名無しさん
2006/05/06(土) 23:28:13抽象クラスにメンバ変数はねーべ？
0420デフォルトの名無しさん
2006/05/06(土) 23:46:180421デフォルトの名無しさん
2006/05/06(土) 23:50:350422419
2006/05/07(日) 00:05:460423デフォルトの名無しさん
2006/05/07(日) 16:02:230424デフォルトの名無しさん
2006/05/07(日) 21:46:24すればいいんじゃね？
0425デフォルトの名無しさん
2006/05/07(日) 21:48:340426デフォルトの名無しさん
2006/05/07(日) 22:54:46それはお前だけ。
0427デフォルトの名無しさん
2006/05/07(日) 23:13:03じゃぁ抽象クラスと protected データメンバの関連って何なのさ？
0428デフォルトの名無しさん
2006/05/08(月) 07:17:41いつまでも教えて君のままじゃ進歩しないよ。
0429デフォルトの名無しさん
2006/05/08(月) 11:01:150430デフォルトの名無しさん
2006/05/08(月) 12:06:18http://www.gotw.ca/gotw/070.htm
> protected data is evil (this time with no exceptions). Why is it evil? Because...
0431デフォルトの名無しさん
2006/05/08(月) 20:10:15protectedやfriendは上級者向き。
0432デフォルトの名無しさん
2006/05/08(月) 23:24:22無茶なキャストも上級者向き。
goto も上級者向き。
上級者向きって言葉は便利だね。
0433デフォルトの名無しさん
2006/05/08(月) 23:44:23婉曲表現大好き日本人。
0434デフォルトの名無しさん
2006/05/09(火) 00:39:01リンク先読んだか？上級者とか関係ないよ。
0435デフォルトの名無しさん
2006/05/09(火) 00:49:360436デフォルトの名無しさん
2006/05/09(火) 01:42:20もうこのスレも終わりだなｗ
他の話題ないのかよｗｗｗ
0437デフォルトの名無しさん
2006/05/09(火) 01:46:27自分の過ちを認める勇気も、技術者には必要だ。
0438デフォルトの名無しさん
2006/05/09(火) 02:28:36自分の過ちを認める勇気も、技術者には必要だ。
0439デフォルトの名無しさん
2006/05/09(火) 15:52:400440デフォルトの名無しさん
2006/05/09(火) 18:16:18二つは同じ歴史をたどっている
データに関しては周知の通りだがそれが分かるには時間がかかった
Javaでさえ失敗している。仮想関数についても同じことになるだろう。
要するに一つの関数/クラスに一つの機能。
これを守るのはすごく難しい。たとえばconst_iterator。
これは明らかに一つのクラスが二つの機能を持っておりC++のコードを倍に増やした
名前が形容詞で修飾されていたらその関数/クラスの設計はたいてい間違っている
0441デフォルトの名無しさん
2006/05/09(火) 18:19:46お前は何を言っているんだ？(ミルコ風
0442デフォルトの名無しさん
2006/05/09(火) 19:21:18神
0443デフォルトの名無しさん
2006/05/10(水) 00:26:10const_iterator が間違いだったとして、どうすれば正解だったの？
0444デフォルトの名無しさん
2006/05/10(水) 07:53:09ヒント：protected
0445デフォルトの名無しさん
2006/05/10(水) 08:03:25| ノ＼ ヽ |
/ ●゛ ● | |
| ∪ ( _●_) ミ j
彡､ |∪| | Ｊ
/ ∩ノ ⊃ ヽ
( ＼ ／ ＿ノ | |
.＼ “ ／＿＿| |
＼ ／＿＿＿ ／
0446デフォルトの名無しさん
2006/05/10(水) 09:37:440447デフォルトの名無しさん
2006/05/10(水) 21:37:28const_iterator が持ってる二つの機能って何？
0448デフォルトの名無しさん
2006/05/10(水) 22:15:580449デフォルトの名無しさん
2006/05/10(水) 22:22:03NVIは言いたいことは解らないでもないが、
今のところ、わざわざそうするべき状況に出会った事がないから実感が持てない。
>const_iterator
要素のconst性とコンテナのconst性のこと？
0450デフォルトの名無しさん
2006/05/20(土) 12:35:41これを読んだらどう？
ttp://www.amazon.co.jp/gp/product/4789833399/503-6690732-8287916?v=glance&n=465392
0451デフォルトの名無しさん
2006/05/20(土) 12:55:52面白そうな本だね。俺、別に組み込み系とかやってるわけじゃないけど、
今度、本屋に行った時に読んで良さそうだったら買ってみるよ。
0452デフォルトの名無しさん
2006/06/01(木) 23:25:48MMSといったら悪名高きDシリーズじゃないか。
0453デフォルトの名無しさん
2006/06/29(木) 06:20:08vc++使っててchar(...)みたいなキャストができることを知って多用してます。
ほかでもOK？
0454デフォルトの名無しさん
2006/06/29(木) 06:23:13class Foo
{
int m_hoge;
int hoge() { return m_hoge; }
void hoge(h) { m_hoge = h; }
};
0455デフォルトの名無しさん
2006/06/29(木) 06:30:290456デフォルトの名無しさん
2006/06/29(木) 08:01:47関数型キャストはいつでも使えるわけではないし、折角C++には濫用防止の戒めを兼ねて
テンプレート型キャストがあるのでそちらを使うべきです。
実数値を整数値に丸めるときなんかは(仕様を承知で) int(sin(...))なんて使うのはありだと思いますが。
0457デフォルトの名無しさん
2006/06/29(木) 08:02:23コピペに反応しろと?
0458デフォルトの名無しさん
2006/06/29(木) 09:59:51あれってコピペなの？的確なレスだと思うけど。
0459デフォルトの名無しさん
2006/06/29(木) 11:28:34ttp://google.co.jp/search?q=そんなの微妙すぎ
0460デフォルトの名無しさん
2006/06/29(木) 11:42:48それは知ってる。っていうか、それ知らないと面白くない。
0461デフォルトの名無しさん
2006/06/29(木) 12:07:070462デフォルトの名無しさん
2006/06/29(木) 18:12:19その形式のキャストも標準Ｃ++のうち。正確にはコンストラクタ呼び出しの構文。
いまさらだけど、>>127
D&E読め、static_castの類はわざと読みにくく作られている。
0463デフォルトの名無しさん
2006/07/01(土) 17:36:38人がほとんどなんだけど、どうして？
構造体も使わないし、自分でやってて分け分からなく
ならないのかな？
グローバル変数多用派のご意見をお聞きしたい。
0464デフォルトの名無しさん
2006/07/01(土) 17:38:430465デフォルトの名無しさん
2006/07/01(土) 18:32:19過去の汚物を引き継いでるプロジェクトほどその傾向が強い。
一部の教条主義者はローカル変数は遅い、構造体は遅い、と信じていたりするし。
0466デフォルトの名無しさん
2006/07/01(土) 19:30:01別言語がメインの開発者
0467デフォルトの名無しさん
2006/07/01(土) 21:42:190468デフォルトの名無しさん
2006/07/02(日) 20:55:31趣味グラマ的には思いっきり環境依存してる‥‥
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 };
};
0469デフォルトの名無しさん
2006/07/02(日) 23:46:12他の環境に移植することが予め無いってわかってるんだったら仕事でも
処理系依存の機能を積極的につかってもいいと思うぞ。
0470デフォルトの名無しさん
2006/07/04(火) 19:09:54外部変数にしちゃってるわ。
0471デフォルトの名無しさん
2006/07/05(水) 11:12:03プロジェクトの規模が小さいのでは？
まぁ、品質管理が最低なことには変わらんが・・・。
0472デフォルトの名無しさん
2006/07/29(土) 20:30:380473デフォルトの名無しさん
2006/08/19(土) 16:27:010474デフォルトの名無しさん
2006/08/19(土) 16:28:24保守乙
0475デフォルトの名無しさん
2006/08/23(水) 08:51:360476デフォルトの名無しさん
2006/08/23(水) 09:05:450477デフォルトの名無しさん
2006/08/23(水) 09:17:46・複数行にわたる宣言（および定義）が連続する場合は
１行以上の空行で区切りを見つけやすくしておく。
・１行以上を占めるコメントの前には空行を置き、コメントが
後続のコードに関するものであることを明らかにする。
言葉にするのは難しいな。
0478デフォルトの名無しさん
2006/08/23(水) 09:45:59printf( "hello" ); と
printf ("hello");
0479デフォルトの名無しさん
2006/08/23(水) 12:26:320480デフォルトの名無しさん
2006/08/29(火) 15:55:23関数／メソッドの区切りにのみ使う。
0481デフォルトの名無しさん
2006/11/15(水) 13:30:42gnu, k&r, bsd, stroustrup, linux 等が設定できる。
我流コーディングスタイルの癖を付けたくないんでとりあえず
好みに近いstroustrupを選んでるが・・・
gnuスタイルはキモイ。(さすがrms...)
0482デフォルトの名無しさん
2007/02/06(火) 17:04:51if (ptr == NULL) ...;
と
if (ptr) ...;
if (!ptr) ...;
はどっちがいい？
0483デフォルトの名無しさん
2007/02/06(火) 17:49:230484483
2007/02/06(火) 17:54:120485デフォルトの名無しさん
2007/02/06(火) 18:44:130486デフォルトの名無しさん
2007/02/06(火) 22:10:20プログラムの動作を口に出して読んでみれば、前者のほうが自然だと感じられる。
0487デフォルトの名無しさん
2007/02/06(火) 23:37:07if (ptr == NULL) if ptr is equal to NULL
if (ptr) if ptr is valid
if (!ptr) if ptr is invalid
0488デフォルトの名無しさん
2007/02/06(火) 23:41:120489デフォルトの名無しさん
2007/02/06(火) 23:47:220490デフォルトの名無しさん
2007/02/06(火) 23:57:56if ptr points nothing
0491デフォルトの名無しさん
2007/02/07(水) 00:33:080492デフォルトの名無しさん
2007/02/07(水) 02:04:50isValidはNULLとかinvalidポインタでも動くようにstaticメンバ関数で
0493デフォルトの名無しさん
2007/02/07(水) 02:26:160494デフォルトの名無しさん
2007/02/07(水) 02:40:02おまいが訊いてのは使い方？ それとも作り方？
使い方なら、そのまんま >>492 の通りなんだが。
って、よくみたら>>492はアホなこと書いてるな。
staticメンバ関数にしたら意味がねぇだろが。
0495デフォルトの名無しさん
2007/02/07(水) 05:06:300496デフォルトの名無しさん
2007/02/07(水) 06:08:340497デフォルトの名無しさん
2007/02/07(水) 06:11:080498デフォルトの名無しさん
2007/02/07(水) 11:25:10ヌルに -> した時点で未定義動作。
0499デフォルトの名無しさん
2007/02/07(水) 20:56:17そんなことはないだろ。これは普通に動くし。
#include <iostream>
class null {
public:
bool isnull() const {return this;}
};
int main() {
null* ptr;
if(ptr->isnull()) {
std::cerr << "null !" << std::endl;
}
return 0;
}
0500デフォルトの名無しさん
2007/02/07(水) 21:13:480501デフォルトの名無しさん
2007/02/08(木) 02:25:41NULLどころか、ポインタを初期化すらしていない件について。
0502デフォルトの名無しさん
2007/02/08(木) 05:48:050503デフォルトの名無しさん
2007/02/08(木) 10:38:160504デフォルトの名無しさん
2007/02/08(木) 13:52:540505デフォルトの名無しさん
2007/02/08(木) 15:24:24Javaみたいにぬるぽガッってなってくれたほうが安心だな
499みたいなのを見るとそう思う。
0506デフォルトの名無しさん
2007/02/08(木) 15:53:19C/C++ の本質は高級アセンブラだから、パフォーマンスが犠牲に
なるようなことは原則として勝手にやらない。
まぁ、お前みたいなヤツはJavaなりC#なりでも使ってなさいってこった。
0507デフォルトの名無しさん
2007/02/08(木) 18:36:290508デフォルトの名無しさん
2007/02/08(木) 21:13:220509499
2007/02/08(木) 21:44:32ああ、ごめんごめん。ptr = 0 の初期化と return this == 0 に直してね。
それはともかく、単純なクラスの非静的メンバなら、暗黙の this 引数を 0 に
しても呼び出せるのは自明だ、ということが言いたかったんだけど、それ
すらも未定義ということ?
0510デフォルトの名無しさん
2007/02/08(木) 21:48:10コンスという名前のトラクター
0511デフォルトの名無しさん
2007/02/08(木) 21:49:57どっちにしてもお行儀が良いとは言えないけど。
0512デフォルトの名無しさん
2007/02/08(木) 21:51:04最初から未定義だって言ってるだろ。
0513デフォルトの名無しさん
2007/02/08(木) 21:59:13ほぼすべて環境で問題なく動作すると思われるが、
それとこれとは関係ない話で、未定義は未定義。
0514デフォルトの名無しさん
2007/02/08(木) 22:06:16ある日ある時ある環境でカーネル破壊して落ちてもそれは「正しい動作」となる。
未定義というのはそういうことじゃないかね。
0516デフォルトの名無しさん
2007/02/08(木) 23:44:52やっぱりお前は馬鹿だな。
0517デフォルトの名無しさん
2007/02/09(金) 08:25:54でも現実として、「変数は必ず初期化しろ」みたいなTipsが解説書に書かれる訳で、
パフォーマンスの為にコンパイラが自動でやらないことを
結局プログラマがコードで書くのは馬鹿馬鹿しい気がするよ。
0518デフォルトの名無しさん
2007/02/09(金) 08:57:01初期化してない変数を勝手に 0 で初期化して
実行時コストを伴いながらプログラマの選択肢を
奪うことには議論の余地がある。
言語デザインの面で考えるのであれば、
未初期化な変数定義を認めないのが正解だと思う。
0519デフォルトの名無しさん
2007/02/09(金) 11:04:28そもそも未初期化でバグるようなコードは
必要な前処理を怠っているという点でそれ自体が潜在的なバグであって、
盲目的な初期化をさせたところで、（必要な前処理をやっていなければ）
バグの顕在化を遅れさせるだけだと思う
あとこういうケースで初期化させるのも無意味だと思う
int a /* = 0 */;
if (ある条件) {
長い処理;
a = 何か;
} else {
他の処理;
a = 違う何か;
}
ここでaを使う;
0520デフォルトの名無しさん
2007/02/09(金) 12:15:43ここでaを使う
0521デフォルトの名無しさん
2007/02/09(金) 16:03:45思うことはよくある。
0522デフォルトの名無しさん
2007/02/09(金) 19:10:06初期化不要宣言をしたときだけ
初期化されない仕様でもいいかもしれない。
0523デフォルトの名無しさん
2007/02/09(金) 19:27:23長い処理って書いてるやん。お前それ一行で書く気かよ。
第一whileとかが入ってたら展開できないぞ。
関数化するってのは無しな。
0524デフォルトの名無しさん
2007/02/10(土) 01:19:41なんで無しなの？
関数にしとけばaをconstにできるし、
長い処理ってのはそれ自体のコストが大きい可能性が高いから、
一回だけの関数呼び出しのコストなんて気にする状況じゃないと思うが。
0525デフォルトの名無しさん
2007/02/10(土) 02:04:51最後の値が代入されると直感的に理解しにくい式になることが予測できる。
0526デフォルトの名無しさん
2007/02/16(金) 12:35:320527デフォルトの名無しさん
2007/02/16(金) 12:36:180528デフォルトの名無しさん
2007/02/16(金) 12:59:280529デフォルトの名無しさん
2007/04/16(月) 02:32:39{
int a;
/*hogehoge no syori*/
}
なんてのはよく使う
0530デフォルトの名無しさん
2007/04/16(月) 17:25:110531デフォルトの名無しさん
2007/06/08(金) 04:18:530532デフォルトの名無しさん
2007/06/08(金) 05:05:160533デフォルトの名無しさん
2007/06/09(土) 07:52:100534デフォルトの名無しさん
2007/06/09(土) 16:47:05friendはファクトリクラスからのみ作成するようにする場合に保険の意味も兼ねて
テンプレートのファクトリクラスに対して指定してつかってますが…
0535デフォルトの名無しさん
2007/06/09(土) 16:57:00必要だと思うまで使わなくていいよ。
0536デフォルトの名無しさん
2007/06/09(土) 21:51:070537デフォルトの名無しさん
2007/06/09(土) 22:28:360538デフォルトの名無しさん
2007/06/09(土) 22:30:16そんなバカな。カプセル化壊れまくりんぐじゃねーか。
0539デフォルトの名無しさん
2007/06/10(日) 13:27:45中卒溶接工童貞DQNﾊｯｹｿ！
0540デフォルトの名無しさん
2007/06/10(日) 16:21:33醍醐味は、ポリモーフィズムとdynamic_cast
〜ＣＯＭ／ActiveXだろ。
日本で書かれた糞本読んでるとそうなります
0541デフォルトの名無しさん
2007/06/10(日) 23:31:380542デフォルトの名無しさん
2007/06/14(木) 01:33:36class Hoge {
Foo foo_;
Bar bar_;
FooBar foobar_;
public:
Hoge(Foo const& foo, Bar const& bar)
: foo_(foo)
, bar_(bar)
, foobar_(foo, bar)
{
// 処理
}
};
自分はこんな感じでコロンとカンマを並べてるんだが、果たして変だろうか
0543デフォルトの名無しさん
2007/06/14(木) 02:10:16日本語で読点を先頭に書くようなもんだからね。
0544デフォルトの名無しさん
2007/06/14(木) 03:08:490545デフォルトの名無しさん
2007/06/14(木) 04:18:260546デフォルトの名無しさん
2007/06/14(木) 04:34:38>544
0547デフォルトの名無しさん
2007/06/14(木) 12:08:22>547
0548デフォルトの名無しさん
2007/06/14(木) 23:13:12思うのだが、
俺だけ？
0549デフォルトの名無しさん
2007/06/14(木) 23:17:200550デフォルトの名無しさん
2007/06/16(土) 11:15:09タブで揃えた場合、タブのスペース数が変わるとずれてしまうし･･･
0551デフォルトの名無しさん
2007/06/16(土) 11:25:16しかし世の中にはおかしな風習が残っている会社もあって、
行内コメントは必ず45カラムから始めて79カラムまでと決められていたりもする。
0552デフォルトの名無しさん
2007/06/16(土) 14:21:04タブはコードの前までしか使わない。
（ここだけタブ）x: （ここにはスペース） // コメント
まあ、手動でスペース調整してコメントの位置そろえても、
最近は Visual Studio の整形機能とかでスペース消されちゃうけどね。
>>551 の言うとおり、そろえようとするのが間違いかと。
0553デフォルトの名無しさん
2007/06/17(日) 16:29:390554デフォルトの名無しさん
2007/06/17(日) 16:30:460555550
2007/06/17(日) 17:19:59色々アドバイスありがとうございます。
0556デフォルトの名無しさん
2007/06/22(金) 11:36:38配列の初期化や enum の最後に余分なカンマがあってもいいのは
何でだと思う？
(enum のは C だけか。)
0557デフォルトの名無しさん
2007/06/22(金) 22:36:06なんか例えが変な気が。
enum の最後とかは、
例えばスクリプトで自動生成したりするときに、
最初または最後の行だけ特別扱いしなくてもいいから。
>>544 が言いたいのは、
, が行頭にある方が、
前の行から続いてることがわかっていいんじゃね？
ってことでは。
0558デフォルトの名無しさん
2007/06/22(金) 23:11:13関数のオーバーロードとかtemplate引数の数で擬似オーバーロードとかなら
Boost.Preprocessorで量産したりするけど、
enumを自動生成したりする機会なんてあるかな。
コード上ではほとんどトークンの列挙だけだから、
普通手打ちでやるんじゃね？
0559デフォルトの名無しさん
2007/06/23(土) 02:24:36なんかのデータベースからデータを抽出して、そいつらの ID を列挙するときとか。
0560デフォルトの名無しさん
2007/06/24(日) 09:53:20詳しいページない?
0561デフォルトの名無しさん
2007/06/24(日) 11:16:38手打ちでやるにしても、最後の行だけ特別扱いってのを気持ち悪がる人いるよ。
0562デフォルトの名無しさん
2007/06/24(日) 15:09:480563デフォルトの名無しさん
2007/11/07(水) 21:08:540564デフォルトの名無しさん
2008/02/24(日) 17:29:080565デフォルトの名無しさん
2008/02/24(日) 17:31:020566デフォルトの名無しさん
2008/02/24(日) 17:48:04引数はaFooで内部変数はiFooとか。
0567デフォルトの名無しさん
2008/02/24(日) 18:07:47標準インクルードファイルは<>で括って、ローカルインクルードファイルは""で括る。
それらの中間に当たる、非標準の汎用インクルードファイルやプロジェクト外の共通インクルードファイルは適宜決めること。
0568デフォルトの名無しさん
2008/02/25(月) 00:38:010569デフォルトの名無しさん
2008/02/25(月) 12:22:580570デフォルトの名無しさん
2008/02/25(月) 12:35:27""で括った場合は、先ずカレントディレクトリを探す。それ以外は<>と同じ。
つまり、間違って"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する。
0571デフォルトの名無しさん
2008/02/26(火) 01:18:53一般的には処理系依存だよ。どのコンパイラの解説をしてくれているのか明示してくれ。
0572デフォルトの名無しさん
2008/02/26(火) 04:32:090573デフォルトの名無しさん
2008/02/26(火) 07:27:29「どの処理系にでも〜」っていう根拠は何かあるの？
規格にあるのは、 "" に対する処理系依存の検索で見つからなかったときには
<> と指定されたかのように処理しなおすこと。そして <> の検索方法もまた処理系依存。
あと、最後の一行がそれより上の説明をUnix系の話に限定するわけじゃないだろ。
0574570
2008/02/26(火) 13:53:08一般的なコンパイラの話。
私の知る限り、よく使われるコンパイラで大きく逸脱しているものは無いと思うので。
違う例があるなら、指摘してくれれば嬉しく思います。
0575571
2008/02/27(水) 00:30:15とりあえず gcc は明示的にオプションで指定されない限りカレントディレクトリを
探したりしない。 -iquote なんてオプションもあって、 >570 とはまるで挙動がちがう。
http://gcc.gnu.org/onlinedocs/cpp/Search-Path.html
gcc を含めずに「一般的なコンパイラ」というのはさすがにあんまりだと思うよ。
0576デフォルトの名無しさん
2008/02/27(水) 00:47:590577デフォルトの名無しさん
2008/02/27(水) 00:59:100578デフォルトの名無しさん
2008/02/27(水) 01:50:16素っ頓狂なことを>575は言いたいらしい。
では聞くが、カレントにあるインクルードファイルをインクルードするにはどうしたらいいのかね?
0579デフォルトの名無しさん
2008/02/27(水) 01:59:07カレントにあるソースをコンパイルするとか、 -I. を指定するとか。
リンク先読んでないの？
0580デフォルトの名無しさん
2008/02/27(水) 02:00:11それともなにやら深い勘違いをしているのだろうか。或いは単純に、
>570が「カレントファイルのあるディレクトリ」を「カレントディレクトリ」としたことが気に入らないのだろうか
0581デフォルトの名無しさん
2008/02/27(水) 02:01:020582デフォルトの名無しさん
2008/02/27(水) 02:25:33http://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
で、「カレントファイルのあるディレクトリ」を検索してくれないコンパイラなら、
一気にマイナーになるけど、ルネサスのコンパイラがそう。こっちは逆に
特に指定しない限り一般的な意味での「カレントディレクトリ」しか見ない。
0583デフォルトの名無しさん
2008/03/25(火) 23:00:171. typedefしない
2. BSD風に u_int
3. Windows風に UINT
4. その他?
0584デフォルトの名無しさん
2008/03/25(火) 23:06:290585デフォルトの名無しさん
2008/03/25(火) 23:23:260586デフォルトの名無しさん
2008/03/26(水) 00:23:09static 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));
}
// などなど
0587デフォルトの名無しさん
2008/03/26(水) 11:28:51そうでないときはunsignedにする。自分でtypedefはしない。
0588デフォルトの名無しさん
2008/03/26(水) 20:35:47メモリに依存する値、または数や大きさを表すならstd::size_t。
大きさの上限を仮定すべきでないならunsigned。
longは使わない。
0589583
2008/03/26(水) 23:54:12やはり、統一的な定義はないのですね。
stdintは使っていたのですが、普通の数値までいちいちサイズ指定するのも変かと思いまして。
int省略でいこうと思います。(今まで省略できることを知らなかったなんて言えないよな…)
0590デフォルトの名無しさん
2008/03/27(木) 01:24:06int の省略は一般的じゃないから、あんまりおすすめできないなー。
省略できるのを知らない人はざらに居るよ。初めて目にした人を
いちいちびっくりさせるのはよくないと思う。
サイズ指定するのが変だと思うなら、 unsigned int って書いても
問題は解決してるでしょ。
0591デフォルトの名無しさん
2008/03/27(木) 07:43:360592583
2008/03/27(木) 23:23:24ついこの間までWindowsばっかりでUINT慣れしてたせいか、長く感じてしまうんですよ。
たしかにunsigned単体って見かけないし、4文字しか減らないし、
省略しない形に慣れた方がいいような気がしてきました。
0593デフォルトの名無しさん
2008/03/27(木) 23:23:470594デフォルトの名無しさん
2008/03/27(木) 23:26:010595デフォルトの名無しさん
2008/03/27(木) 23:36:160596デフォルトの名無しさん
2008/03/28(金) 00:38:01コンストラクタも同じ表記だから
0597デフォルトの名無しさん
2008/03/28(金) 00:41:240598597
2008/03/28(金) 00:55:470599デフォルトの名無しさん
2008/03/28(金) 02:19:320600595
2008/03/28(金) 12:39:12回答ありがとう。満場一致でvoid a()なのね。俺もvoid a()に統一するよ。
Cからの流れで(void)って書いてただけだから、書かなくていいC++では違和感を常々感じてましたです。
0601デフォルトの名無しさん
2008/03/28(金) 22:06:190602デフォルトの名無しさん
2008/04/06(日) 20:30:400603デフォルトの名無しさん
2008/05/10(土) 17:20:40こんな感じの書き方が好きです。
0604デフォルトの名無しさん
2008/05/11(日) 13:43:30自分はa(void)派。
理由は一目で関数呼び出しと区別できるからかな。
そんなに強い理由じゃないし、こだわりはあまりないけどね。
0605デフォルトの名無しさん
2008/05/11(日) 13:47:03あ〜自分もそう。一時変数はなるべく作りたくない。
でも意味がわかりにくいと思ったら、一時変数作るか関数にする。
0606デフォルトの名無しさん
2008/05/11(日) 16:58:42やめて。コンパイル通らないから
0607デフォルトの名無しさん
2008/05/11(日) 19:17:320608デフォルトの名無しさん
2008/05/11(日) 22:07:010609デフォルトの名無しさん
2008/05/11(日) 22:09:55C++ の関数宣言でも (void) は引数リストとして有効だよ。
C とは違って typedef された void は受け付けないらしいが。
0610デフォルトの名無しさん
2008/05/12(月) 01:37:52VC++のバージョンとが上がると急にエラーになったりする
ことになるから、
書かない方がいいと思うよ＜(void)
0611デフォルトの名無しさん
2008/05/12(月) 07:36:490612デフォルトの名無しさん
2008/05/12(月) 07:54:490614デフォルトの名無しさん
2008/05/12(月) 21:03:09...
<<仮引数宣言節>>が空の場合、その関数は実引数を受け取らない。
仮引数並びが(void)の場合、空の仮引数並びと同等とする。...
だそうだ
0615デフォルトの名無しさん
2008/05/13(火) 01:42:22互換上の仕様だけど今後も残りそうな仕様だな
0616デフォルトの名無しさん
2008/05/13(火) 12:18:020617デフォルトの名無しさん
2008/05/13(火) 12:42:460618デフォルトの名無しさん
2008/05/13(火) 13:08:240619デフォルトの名無しさん
2008/05/31(土) 17:55:53普通は考えないものなのでしょうか？
例えば引数で値を返す関数の場合
bool func( int* val_ ){
*val_ = 0; // 取り合えず 0
int val;
.. ローカル変数 val をいじる処理 ..
*val_ = val; // 返却
return true; // 成功
}
みたいにすると分かりやすいと思っているのですが
こんな事考えてるのは自分だけ？
どうでも良いけどメンバ変数は m_ 派です
0620デフォルトの名無しさん
2008/05/31(土) 19:15:580621デフォルトの名無しさん
2008/05/31(土) 19:29:57val_が関数利用者側から意図を汲みやすい名称かという話なら
意味不明ぐらいの感想しかない。ヘッダのみ提供ならなおさら。
val_が失敗成功に関わらず0で初期化される、成功時に結果が設定されるという話なら
ヘッダに利用上の注意としてコメントを残しておくだけだろう。
0622デフォルトの名無しさん
2008/05/31(土) 19:52:010623デフォルトの名無しさん
2008/05/31(土) 23:20:10dest という変数名は使うことはあるけど
0624デフォルトの名無しさん
2008/06/01(日) 10:35:46実装者視点の話と思うよ。(関数利用者側のメリットはなさそう)
619の例だとローカル変数と衝突しなくてすむ。
自分は前はp_(pはパラメータの意)をつけたり
619のように最後に_つけたりしてたけど
今は何もなし(ローカル変数と同じ)だな。
ちなみに_最後につける方法はメンバ変数にする場合も見かけるね。
0625デフォルトの名無しさん
2008/06/01(日) 11:20:040626デフォルトの名無しさん
2008/06/01(日) 11:34:07実装は接頭辞付きって規則で統一した上で。
0627デフォルトの名無しさん
2008/06/01(日) 12:06:180628624
2008/06/01(日) 13:53:55でも関数が長いとか変数名が変とか、設計上の問題のせいかも知れない。
設計が良い場合は思わなかった気がするな。
0629デフォルトの名無しさん
2008/07/31(木) 02:40:400630デフォルトの名無しさん
2008/08/27(水) 13:04:03i++;
どっち
0631デフォルトの名無しさん
2008/08/28(木) 02:08:490632デフォルトの名無しさん
2008/08/28(木) 02:19:050633デフォルトの名無しさん
2008/08/28(木) 21:37:45はしょりすぎじゃね？
i++ だとインクリメント前の値を返す無駄な処理が発生する→最適化されたら同じじゃね？
→演算子多重定義があるから一般には最適化できない
0634デフォルトの名無しさん
2008/08/28(木) 21:57:510635デフォルトの名無しさん
2008/08/28(木) 23:22:150636デフォルトの名無しさん
2008/08/29(金) 06:15:460637デフォルトの名無しさん
2008/09/07(日) 02:09:530638デフォルトの名無しさん
2008/09/07(日) 03:19:200639デフォルトの名無しさん
2008/09/07(日) 03:25:480640デフォルトの名無しさん
2008/10/05(日) 01:21:30error C2105: '++' には左辺値が必要です。
0641デフォルトの名無しさん
2008/10/05(日) 13:33:110642デフォルトの名無しさん
2008/10/05(日) 13:50:320643デフォルトの名無しさん
2008/10/26(日) 01:53:44http://pc11.2ch.net/test/read.cgi/tech/1096687703/
0644デフォルトの名無しさん
2008/10/26(日) 01:56:27関数ポインタの配列を返す関数ポインタの配列を返す関数について、
どのように書くのがよいですか？
1. typedef使う場合
2. typedef使わない場合
でよいので記述せよ。
0645デフォルトの名無しさん
2008/10/26(日) 02:17:140646デフォルトの名無しさん
2008/10/27(月) 00:03:46ぷぷ（ｗ
解らないやつ発見（ｗ
0647error C743: 名前がありません。
2008/10/27(月) 00:05:10ダサいよ。うんダサい。
ということで、
[error C743: 名前がありません。]
にしようぜ。というか、しろ。
さっさと変更依頼だせ。
0648デフォルトの名無しさん
2008/10/27(月) 00:09:420649error C743: 名前がありません。
2008/10/27(月) 03:17:17痛いな、関数は配列を返せません。
void (* (* (* function(void (* (* var(void)) [])(void)) [])(void)) [])(void);
当然、配列返そうとしているから、間違えだけど。
void (* (* (* functionz(void (* (* var(void)) [])(void)) [])(void)) [])(void);
たしかに、この名前いいな。
0650デフォルトの名無しさん
2008/10/27(月) 14:11:350651デフォルトの名無しさん
2008/10/27(月) 14:43:29それで充分かどうかは場合による
0652デフォルトの名無しさん
2008/10/27(月) 14:55:05でも、構造体でくるんだら値でも返せる。
0653デフォルトの名無しさん
2008/12/28(日) 16:53:21例えば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
0654デフォルトの名無しさん
2008/12/28(日) 18:00:48その下駄は兎も角、雪駄は何故intを返すんだ?
0655デフォルトの名無しさん
2008/12/28(日) 18:10:140656デフォルトの名無しさん
2008/12/28(日) 19:21:51int b;
b=a.Value(5)+3;
てな事をするため。
まぁ、T&を返してもいいんだけど。
b=a.Value(5).Value()+3;
ってなんだよなぁ。
0657デフォルトの名無しさん
2008/12/28(日) 20:44:08protected メンバ変数なんて使わない。
広まる影響については、自業自得ということでがんばれとしか言えない。
getter/setter にルールを決めるなんてナンセンス。
普通に、クラスに必要なインターフェースをクラスごとに考えろ。
Mozzila のそれはいい加減に古すぎるし、大量のコンパイラを
想定する必要なんてないことがほとんど。
0658デフォルトの名無しさん
2008/12/28(日) 21:12:440659デフォルトの名無しさん
2008/12/28(日) 21:13:550660デフォルトの名無しさん
2008/12/28(日) 21:33:450661デフォルトの名無しさん
2008/12/28(日) 21:46:39あるクラスを使っている別のファイルでその変数にアクセスしたい時、
setter/getter を作らなければならなくなるので、
その別ファイルだけの diff だけではなく、クラスのファイルの diff も必要になる。
0662デフォルトの名無しさん
2008/12/28(日) 21:48:510663デフォルトの名無しさん
2008/12/28(日) 22:08:140664デフォルトの名無しさん
2008/12/28(日) 22:12:25>>653見たいな事になったらどうすんの？
例えば、時間を管理するとしてlongの変数一つで扱うか
hour,minuts,secondと3つに分けて扱うとか
いくらでもprivate領域は変えられるんだからね。
0665デフォルトの名無しさん
2008/12/28(日) 22:53:31例えばグローバル変数を利用してピンポイントの効率化を行なって悦に入り、
そうはしない他人よりも自分の方が能力があると錯覚してしまう時期があるもんだよ。
斯く言う私も、10代の頃はそうだった。
0666デフォルトの名無しさん
2008/12/28(日) 23:09:32カプセル化のデメリットを考えずにメリットだけを信じるというのは思考の停止である。
偉い人が唱えたアイデアを盲信せずに、自分なりにメリット、デメリットを考えてみる。
そういうステップを踏んでみると、メリット、デメリットの「度合い」というものも状況によって異なることに気付けるはずだ。
あえてカプセル化を採用しないコーディングスタイルもありうるかもしれない、と気付けるはずだ。
>>662-664 君達はそこまで考えたことがないのだろう。
カプセル化至上主義ですか…。try{} catch{} のエラー処理は常に使用すべきですか？
0667デフォルトの名無しさん
2008/12/28(日) 23:10:580668デフォルトの名無しさん
2008/12/28(日) 23:16:46もっと真っ当な解決策がそこにあるかもしれないのにそれを模索しようとしない姿勢こそが思考停止ではないのかな?
0669デフォルトの名無しさん
2008/12/28(日) 23:17:00関数は可能な限り private メンバ関数にすべきですか？
それとも全て public メンバ関数にすべきですか？
メリット、デメリットを一緒に教えてください。
自分なりの解答はありますが、皆さんの意見を教えてください。
できれば議論の形になっていただけるとうれしいです。
0670デフォルトの名無しさん
2008/12/28(日) 23:19:380671デフォルトの名無しさん
2008/12/28(日) 23:28:210672デフォルトの名無しさん
2008/12/28(日) 23:40:19その理屈で public にしてるとさ、元のクラス側の実装を変更しようと思った時には
逆に使ってる側の別ファイルも合わせて書き換えないといけなくなるんでしょ？
詭弁だよ。もしくは元クラスを書き換える可能性を無視した、浅はかで自分勝手な考え。
0673664
2008/12/29(月) 08:00:55昔、嫌々VB6.0で組まされたことがある。それもチームで。
アレには、Classとモジュールと言うのがあって一応カプセル化は
できるようにはなってんだ。一つの規約として「変数だけはpublicに
するな」を設けた。しかし、メンバーのレベルが低すぎて勝手に変数共有。
そしてカプセル化が破しどこで勝手に変更されてるのか分からない。
依存コードの除去に苦労したよ・・・。
あんな事2度とごめんだ。
オプソでも似たようなもん。勝手に変数共有なんかされるとみんなが困る。
人のことを考えろよ。
0674デフォルトの名無しさん
2008/12/30(火) 11:38:17様々な試行錯誤を経てカプセル化については メリット＞＞＞デメリットという結論なんだな。
俺も昔はメンバ変数はprotectedで勘弁してよって思ってたが、今ではしっかり設計をすればprivateでokであることが解ってきた。
諦めてカプセル化を壊すことこそが思考停止だとおもう。もう少し設計を見直すべきだな。
カプセル化を壊すのは設計が妥当ではないといういい指標となると思う
0675デフォルトの名無しさん
2009/01/10(土) 11:08:350676デフォルトの名無しさん
2009/01/10(土) 11:50:100677デフォルトの名無しさん
2009/01/10(土) 14:55:09内部で使うものはprivate
カスタマイズに使うものはprotected
0678デフォルトの名無しさん
2009/01/17(土) 18:58:19だから最初に公開するものはとっても悩む。
他人が使うものを作ると実感する。
0679デフォルトの名無しさん
2009/01/17(土) 20:46:29privateなんだよってことがよくある。
あったまくる。最悪。どうしようもない。
0680デフォルトの名無しさん
2009/01/17(土) 20:58:310681デフォルトの名無しさん
2009/01/17(土) 21:00:18触って欲しくないからだろ。
0682デフォルトの名無しさん
2009/01/17(土) 21:25:49この頭の悪さが物語っているな。
0683デフォルトの名無しさん
2009/01/17(土) 22:24:57仲良しとしか組んだことないだろ
0684デフォルトの名無しさん
2009/01/18(日) 07:25:17privateだからとかバイナリしかないとかは大した障害にならないね。
0685デフォルトの名無しさん
2009/01/18(日) 07:37:090686デフォルトの名無しさん
2009/01/18(日) 12:42:28一応それはillegalだよね？
だいたいそれでうまくいくけど。
プリプロセッサの段階でそれをdenyする実装ってあるんだっけ？
0687デフォルトの名無しさん
2009/01/18(日) 13:32:310688デフォルトの名無しさん
2009/01/18(日) 17:53:190689デフォルトの名無しさん
2009/01/21(水) 01:21:34何が言いたいのかさっぱりわからん。
アクセス修飾変えるんだからリコンパイルが必要なのは当然だが、そこでなんでマングリング？
686の話とどう繋がるのか教えてくれ。
0690デフォルトの名無しさん
2009/01/21(水) 01:35:49アクセス指定子によってマングル名が変わるからコンパイルはできるけどリンクできないってことだろ。
リンクするためにはライブラリ？も同じアクセス指定子でリコンパイルが必要ってこと。
0691デフォルトの名無しさん
2009/01/21(水) 11:02:280692デフォルトの名無しさん
2009/01/21(水) 11:12:31でも確かにエロいよなぁ
0693デフォルトの名無しさん
2009/01/21(水) 19:54:11そうそう。代理での回答ありがとうん
0694デフォルトの名無しさん
2009/01/21(水) 19:57:09char ch; //もしかしたら誰かがint chに変えちゃうかも知れない
style A) printf("%c", ch);
style B) printf("%c", int(ch));
style C) printf("%c", char(ch));
AとCはintへの自動昇格目当てな
0695デフォルトの名無しさん
2009/01/21(水) 22:51:10いや、マングリングが変わらなくてもコンパイラがVCじゃなくてもコンパイルとリンクは発生する。（勿論例外はあるけど）
なぜ686にそれを指摘するのかが俺には理解できなかったんだわ。
>プリプロセッサの段階でそれをdenyする実装ってあるんだっけ？
これ俺も知りたかったから689が何か言おうとしてるっぽいんで理解しようと思ったんだが・・・意味不明だったんで質問してみた。
0696デフォルトの名無しさん
2009/01/21(水) 23:17:310697デフォルトの名無しさん
2009/01/22(木) 02:34:110698デフォルトの名無しさん
2009/01/22(木) 04:21:350699デフォルトの名無しさん
2009/01/22(木) 20:33:31わろたｗ
>>698
%c に対する引数は int を与えないといけないので、明示的にキャストするかどうか。
さもなくば可変引数における暗黙の型ルールを把握しておかないといけない。
0700デフォルトの名無しさん
2009/01/23(金) 00:18:37そんなもん、%cを学んだ段階で把握できることだろ。
それとも何か、入門書と言う奴はそんなことも書かれていないのか?
だとしたら、マニュアルページに補足されているといいかも知れないな。
駄菓子菓子、そのキャストは余りに神経質に過ぎると思うぞ。
それを言い出すと例えば、ch == '\t'なんてのもそのまま書けなくなってしまう。
0701デフォルトの名無しさん
2009/01/23(金) 00:45:50キャストしてもしなくても、「可変引数における暗黙の型ルール」を把握しておかないと
いけないことに変わりはないはずなんで、何を迷ってるのかわからん。
0702デフォルトの名無しさん
2009/01/23(金) 07:57:590703デフォルトの名無しさん
2009/01/23(金) 08:06:170704デフォルトの名無しさん
2009/01/24(土) 13:25:54オーバーロードが通じないぶん意味があるかもな。
type a;
printf("%c",static_cast<int>(a));
でもまぁ、だったら最初からstd::cout使っとけやって話だが。
0705デフォルトの名無しさん
2009/01/30(金) 09:37:33std::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");
);
0706デフォルトの名無しさん
2009/01/30(金) 09:44:12template<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") );
}
0707デフォルトの名無しさん
2009/01/30(金) 10:03:06func(std::list<mylib::common::MyClass<CharT>*> container,
std::vector<std::basic_string<CharT> > &strs)
この3行は改行しないで一列にしちゃうな。
なんでかっていうと、VC++2008では、{ }内全体を隠す機能があって
1関数/1クラスが1行にまとまって検索しやすくなるので。
0708デフォルトの名無しさん
2009/01/30(金) 10:40:160709デフォルトの名無しさん
2009/01/30(金) 11:07:240710デフォルトの名無しさん
2009/01/30(金) 12:17:050711デフォルトの名無しさん
2009/01/30(金) 12:37:2380桁ってのはデファクトとしてそれなりの意味があるんじゃないのかな。
事実色んなオープンソースプロジェクトが80桁ルールを守って書かれてるし
やろうと思えば全然難しくないしね。
まあ80桁は狭いと思うにしてもせいぜい100桁か120桁くらいが限界じゃないかな。
あまり横に突き出してしまうと、結局折り返しが発生する環境が出てきて、
可読性が損なわれてしまう。
自分が読めればいいだけならいくらでも横に伸ばせばいいけど。
0712デフォルトの名無しさん
2009/01/30(金) 14:42:11http://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
0713712
2009/01/30(金) 14:42:57>>708-711
http://stackoverflow.com/questions/110928/is-there-a-valid-reason-for-enforcing-a-maximum-width-of-80-characters-in-a-cod
0714デフォルトの名無しさん
2009/01/30(金) 17:10:000715デフォルトの名無しさん
2009/01/31(土) 00:45:27客先と会社のLinuxでは、端末エミュレータを3枚並べると丁度100、100、80カラム。
なので80-100で収まるようにコーディングしている。
0716デフォルトの名無しさん
2009/01/31(土) 07:39:44無理すんな
0717デフォルトの名無しさん
2009/01/31(土) 10:06:10まぁ、客先の現場に行くとサーバがSunだしLinux端末がないから使っているけどさw
0718デフォルトの名無しさん
2009/01/31(土) 14:53:56最近はもっぱらWindowsからTeraTermでつないで使ってる。
0719デフォルトの名無しさん
2009/01/31(土) 17:25:330720デフォルトの名無しさん
2009/01/31(土) 23:06:170721デフォルトの名無しさん
2009/10/10(土) 03:00:500722デフォルトの名無しさん
2009/10/10(土) 03:33:250723デフォルトの名無しさん
2009/10/11(日) 22:31:030724デフォルトの名無しさん
2009/10/18(日) 17:03:530725デフォルトの名無しさん
2009/10/18(日) 18:12:05無限ループはこうかく
0726デフォルトの名無しさん
2009/10/18(日) 23:37:59#define _
for(;_;)
0727デフォルトの名無しさん
2009/10/19(月) 00:18:53#define do_ob (for)
#define p_q (;;)
do_ob (p_q)
0728デフォルトの名無しさん
2009/10/19(月) 00:25:14展開すると
(for)((;;))
コレが通るコンパイラを教えてクレ。
0729デフォルトの名無しさん
2009/10/19(月) 21:38:33defineのあとのカッコ（）は無視されます
0730デフォルトの名無しさん
2009/10/20(火) 00:48:44#define A (1+2)
#define B (3+4)
printf( "%d\n", A * B );
0731デフォルトの名無しさん
2009/10/20(火) 12:02:05むしろ>>730のようにカッコを無視してもらっては困る場合が多いんだけど
0732デフォルトの名無しさん
2009/10/20(火) 12:07:05だから、どのコンパイラがそんな挙動をするのかと。
0733デフォルトの名無しさん
2009/10/20(火) 17:47:2611
0734デフォルトの名無しさん
2009/10/20(火) 18:07:49>732
0735デフォルトの名無しさん
2009/10/20(火) 23:16:03#define A 1 // コメント書いてもちゃんと通るYO!
printf( "%d\n", A );
0736デフォルトの名無しさん
2009/10/21(水) 02:42:120737デフォルトの名無しさん
2009/10/21(水) 09:36:17＞「コメントは無視される」と間違えてる気ガス。
誰が?
0738デフォルトの名無しさん
2009/10/21(水) 09:42:54>735は日本語が不自由なんだよ。>735は、
「>729はコメントが無視されることと同様にと括弧も無視されると勘違いしているのじゃないか」
と言いたいのだろ。
まぁ、普通はそんな間の抜けた勘違いはしないがな。
0739デフォルトの名無しさん
2009/10/21(水) 19:34:080740デフォルトの名無しさん
2009/10/21(水) 19:35:120741デフォルトの名無しさん
2009/10/21(水) 19:35:560742デフォルトの名無しさん
2009/10/21(水) 20:18:010743デフォルトの名無しさん
2009/10/21(水) 22:36:020744デフォルトの名無しさん
2010/11/12(金) 22:53:490745デフォルトの名無しさん
2010/12/29(水) 23:38:20{
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" : "";
}
0746745
2010/12/29(水) 23:39:550747デフォルトの名無しさん
2011/01/08(土) 01:49:46きもいｗ 許せないｗ
俺ならハッシュ使って返すｗ
0748デフォルトの名無しさん
2011/01/21(金) 19:55:390749デフォルトの名無しさん
2011/01/21(金) 20:22:09public:
const CHoge&Hoge()const{return hoge;}
ができるのね。
ちょっと惹かれる。
0750デフォルトの名無しさん
2011/01/21(金) 23:21:040751デフォルトの名無しさん
2011/01/22(土) 00:14:39頭のC要らないよ。クラスであることを表すってことなら class ってふつうに書けばいいんだよ。
public:
const class Hoge&Hoge()const{return hoge;}
0752デフォルトの名無しさん
2011/01/22(土) 00:19:55単に値を取り出すだけなのに動詞とかキモイ。
「x の hoge」は x.Hoge() が自然。 x.GetHoge() ってなると自然に読み下せない。
取り出した値を使った式を書いた場合にさらに読みづらくなる。
0753デフォルトの名無しさん
2011/01/22(土) 00:37:47コンストラクタと名前被るからって意味じゃないかとエスパー。
0754デフォルトの名無しさん
2011/01/22(土) 05:46:49…などと、どうでもいいことをぐりぐり掘り返してみた。
個人的にはどっちでもいいやって感じ。
■ このスレッドは過去ログ倉庫に格納されています