07/08/26 00:16:02
>>231
やめなさいｗ
233:デフォルトの名無しさん
07/08/26 01:06:27
>>231
とてもアリな気が今した!
234:デフォルトの名無しさん
07/08/26 20:47:53
>231
コレ継承先から継承元の変数見るのが面倒では…
あー、もしや変数は全部privateにしろって事?
235:デフォルトの名無しさん
07/08/26 21:13:48
>>234
＞あー、もしや変数は全部privateにしろって事?
当たり前じゃん。
236:デフォルトの名無しさん
07/08/27 00:31:17
>>234
structなしでint m_x;とか書いたのに比べて、なにか不便になることってあるの?
237:デフォルトの名無しさん
07/08/27 00:41:08
2～3行増える。
素直にint x_, y_;にしとけばタイプ量も減る。
238:デフォルトの名無しさん
07/08/27 01:24:03
231のmをポインタにした感じのコードなら書いたことある。
例外にも強いしコピー・交換も楽で速いしなんて思っていたら、
どうみても劣化pimplです、本当にありがとうございましたというオチ。
239:デフォルトの名無しさん
07/08/31 23:34:42
>>237
タイプ量だけ?
>>234 の継承とかなんとかは関係ないの?
240:デフォルトの名無しさん
07/09/01 22:41:02
>>237
メンバ数が多いと、逆にタイプ数は減らないか？ｗ
241:デフォルトの名無しさん
07/09/04 00:15:46
アフォな質問ですまん。
>231の例でx,yの初期化ってどうやって書けば良い?
242:デフォルトの名無しさん
07/09/04 00:38:14
>>241
普通にコンストラクタの初期化部で書けばよろしいかと。
243:241
07/09/05 00:12:31
>242
サンプルコードを書いて貰えませんか?
少なくとも漏れの知ってる書き方をみる限りでは、
>231の方法はやっぱダメだとしか思えませぬ。
244:デフォルトの名無しさん
07/09/05 00:47:14
structが無名だから初期化できないね。ま、コンストラクタで代入するってことで。
--
class Hoge {
struct {
int x;
int y;
} m;
public:
Hoge() {m.x = 0; m.y = 0;}
Hoge(int x, int y) {m.x = x; m.y = y;}
};
245:デフォルトの名無しさん
07/09/06 00:18:43
x,yがconstか参照で、かつコンストラクタの引数経由で
外部から初期値渡したい場合は?
それ考えると>231はやっぱ使い物にならん。
246:デフォルトの名無しさん
07/09/06 00:54:42
struct に名前を付けてコンストラクタ書けばいいだけの話じゃないの？
247:デフォルトの名無しさん
07/09/06 01:14:03
最早>231はどうでもいいがw
＞x,yがconstか参照で、かつコンストラクタの引数経由で
＞外部から初期値渡したい場合は?
条件後出ししていいなら、構造体に名前つけさせてくれ。
248:デフォルトの名無しさん
07/09/06 20:24:05
>246,247
structに名前付けるのはいいけど、
通常1回書けばすむはずの処理を、2回書かなきゃダメだよね?
そうじゃないスマートな書き方を知っているなら是非ご教授を。
249:デフォルトの名無しさん
07/09/07 13:03:53
>>248
2回って、何で？ Hoge は InnerHoge に丸投げするだけでしょ。
250:デフォルトの名無しさん
07/09/08 00:21:38
>>249
Hogeのコンストラクタとその内部構造体のコンストラクタで
2回初期化を書かなければいけない（そしてそれがスマートでない）
と248は言っているのだろう。
251:デフォルトの名無しさん
07/09/18 16:57:12
あーの、Windowsでアンダースコア区切りの命名規則を採用している方に質問なのですが、
皆さんはWinMainの引数とかAPIのコールバック関数にもアンダースコア区切りで命名しますか？
それともWinAPIに関連する変数は例外的にハンガリアン+CamelCaseで命名しますか？
当方、先週Windows畑に飛ばされたばかりのへっぽこPGなんですが、
どうにも気になって気になって。。。
252:デフォルトの名無しさん
07/09/20 02:06:24
Gtk+なんかだとAPIそのもの以外は徹底的にアンダースコア区切りで命名してるな
253:1/2
07/10/05 00:49:37
なんか、コーディング規約で this を返すのは駄目っていうのをどっかで読んだんだけど
こういうのはどうなの？
(サンプルソースの意図は、oldTest() の if 文を無くして test() のようにシンプルにすること)
public class Test {
private static void oldTest(String[] params){
for (int i = 0; i < params.length; i ++) {
if (0 < i) {
System.out.print("," + params[i]);
}
else {
System.out.print(params[i]);
}
}
}
private static void test(String[] params){
Printer printer = FirstPrinter.instance;
for (String param : params) {
printer.print(param);
printer = printer.nextPrinter();
}
}
public static void main(String[] argv){
test(argv);
}
}
254:2/2
07/10/05 00:50:41
abstract class Printer {
abstract void print(String param);
abstract Printer nextPrinter();
}
class FirstPrinter extends Printer {
static final FirstPrinter instance = new FirstPrinter();
void print(String param){
System.out.print(param);
}
Printer nextPrinter(){
return SecondPrinter.instance;
}
}
class SecondPrinter extends Printer {
static final SecondPrinter instance = new SecondPrinter();
void print(String param){
System.out.print("," + param);
}
Printer nextPrinter(){
return this;
}
}
255:デフォルトの名無しさん
07/10/05 00:58:07
>>253
コード読んでないけど、駄目って言う理由がないんならどうでもいいんじゃね？
256:デフォルトの名無しさん
07/10/05 01:31:13
メソッドチェーンするのに便利だしthisを返しておいた方がいいと思ったんだけど、
駄目って言う理由はなんなんだろう。
257:デフォルトの名無しさん
07/10/05 01:58:23
>>256
ちょっとよくわからないで言うけど
this を返してもらった奴がこれを使うときにthisの実体がなくなっちゃてたりするケースってない？
258:デフォルトの名無しさん
07/10/05 03:18:25
>>257
だって呼び出している側がインスタンス保持しているのに、
なくなっているってことが通常ある?
259:デフォルトの名無しさん
07/10/05 03:53:45
>>257
コード見る限り Java だから、それはありえない。
260:デフォルトの名無しさん
07/10/05 05:18:48
入出力関係のオブジェクトだと閉じてる可能性はあるね。
261:デフォルトの名無しさん
07/10/05 15:25:15
まじわからないで言う、ごめん
インスタンスを持っているならthisを返す意味はある？
汎化という目的で独立性を高めるために他の処理でこれを使うことを考慮したら
インスタンスが失われることを考えてthisを返してはいけないとか
262:デフォルトの名無しさん
07/10/05 15:26:27
if を使ってる処理のほうが、「何をしているか」がよくわかる
263:デフォルトの名無しさん
07/10/05 19:00:26
>>261
instance.foo().bar().baz()
とかやりたいってことない? これを指してメソッドチェーンといったんだけど。
264:デフォルトの名無しさん
07/10/05 20:10:40
operator overloading なんかだと this を返さないと成り立たないけどねw
まあ、java にはないから関係ないけど
265:デフォルトの名無しさん
07/10/09 15:59:59
副作用がある場合はthisを返さないってポリシーはあるな。
266:デフォルトの名無しさん
07/10/09 20:15:56
>>253
シンプルどころか複雑怪奇になってる。
さらにメモリ使用量も増えてるし、速度も遅くなっていそう。
そして、return this;よりはreturn SecondPrinter.instance;の方がいいだろう。
最悪なのは、親クラスのクラス変数を子クラスで隠蔽しているところだな。
267:デフォルトの名無しさん
07/10/09 20:35:42
個人的に思ったのは、
「this を返すAPI を作るな」っていうコーディング規約は、
「メソッドチェーンを前提にした API を作るな」っていうのが本来の意図であって、
そうでなければオーケーなんじゃないかと。
>>266
今回はサンプルがはじめからシンプルだったために、結果的に複雑怪奇になってしまったわけで、
実際にはトレードオフで適用すればいいのだと思います。
＞最悪なのは、親クラスのクラス変数を子クラスで隠蔽しているところだな。
親クラスで定義しているのは抽象メソッドだけで (つまり実質的にインタフェースといえる)、
クラス変数は存在しないはずなのですが・・・
＞return this;よりはreturn SecondPrinter.instance;の方がいいだろう。
あー。確かに。言われてみれば。
ただ、今回は Printer をシングルトンで実装できたけど、
例えば任意のセパレータの文字を指定して CSV ファイルを構築できるように
Printer を改造したような場合は、各インスタンスが状態を持つようになるので
this を返すような実装になると思う。
まあ、この場合でも Printer をイミュータブルになるように設計して
Flyweight の getter メソッドを活用して this を返さないような仕組みにすることは出来るけど
そこまでやると冗長になる気がする。
268:デフォルトの名無しさん
07/10/23 19:22:00
保守代わりに転載。
C++0x 2
ｽﾚﾘﾝｸ(tech板:172番)
269:デフォルトの名無しさん
07/12/15 02:35:34
private:
bool isHoge_;
だけでなく、
private:
void doHoge_();
とか、
template<class Hoge_>
のように準ローカルな名前全てにアンダーバーを付けたくてウズウズしてしまうのですが、
そのようなコーディング規約が見付かりません。
常識的にあまり推奨されないのでしょうか？
270:デフォルトの名無しさん
07/12/15 02:39:55
>>269
どうして？
271:デフォルトの名無しさん
07/12/15 03:03:06
>>270
発端は、templateのタイプ名が外部の通常のクラス名と衝突してしまったため、
冗長にせざるを得ない場面があったからです。
ならばメンバ変数に習い、「末尾にアンダーバー」イコール「スコープ限定」にしてしまえば、
衝突も避けられるし、読む時にも迷子になり難いのではないかな・・・と。
272:デフォルトの名無しさん
07/12/15 03:44:57
>>271
そんな局所的な理由で規約になるわけないんじゃないの？
273:デフォルトの名無しさん
07/12/15 04:41:14
後ろにアンダーバーなんて始めて見たな。
前ならそうしてる人結構いるよ。
274:デフォルトの名無しさん
07/12/15 04:59:49
前につけるとすぐ予約名になるまたは予約名とまぎらわしいから、やめといたほうがいい。
275:デフォルトの名無しさん
07/12/15 07:12:05
>>271
つまりボキャブラリが貧弱なのを _ でごまかそうということですね
英語の辞書を買ったらどうでしょう
冗長といっても、いくら長くてもいいと思う
あとで別の人間が解析するときに、
grepをかけたら似た様なのがゾロゾロって
猛烈に格好悪い
276:227
07/12/15 07:45:38
>>274
これっていつから言われてるの？
昔は＿ 前だったのに・・・
>>271
それってローカル側優先で処理されるよね?
TXxxx
とかにするってのもどうかね
277:デフォルトの名無しさん
07/12/15 09:53:59
>>276
> これっていつから言われてるの？
「言われてる」ってのが何のことかわからないけど、予約名の規定自体は
知ってる範囲では ISO C++98, C99 とかで決められてる。たぶんそれより前の
C89 からそんなに変わってないと思うから、少なくとも 10 年以上前から使っちゃ
マズイってことにはなってたはず。
278:デフォルトの名無しさん
07/12/15 10:26:40
>>276
MS-DOS の初期のころから内部の実装で使われていた気がする
279:デフォルトの名無しさん
07/12/15 11:02:48
>>273
オレは何度も見たことあるよ。
280:デフォルトの名無しさん
07/12/15 12:33:25
>>279
確かに、C の関数の場合は後ろに _ をつけると()と離れて絵的に悪くないかも知れないけど
いまひとつ _ を前後に使う意味がわからないな
_ があることでなにかを示すようには見えないな
もっと、適切な方法があるならそれを選んだほうがいいように思う
見てわかるような名称にするように文になっていたっていいと思う
昔の関数名なんか変なのあるよな
creat() なんて何を考えてるんだかｗ
'e' 一文字を省く理由がわからない
281:227
07/12/15 12:39:05
>>277-278
ごめ。
_ は前に普通に付ける時代があったんだけど（本とかで載っていた）
最近後ろに付ける勢力が急拡大している感じ。
いつからだろうと。
282:デフォルトの名無しさん
07/12/15 12:49:04
>>281
前につけることの問題を知らずに本を書いちゃうようなアホが淘汰されたんだろう。
いつからってこともないと思うぜ。
283:デフォルトの名無しさん
07/12/15 12:57:38
>271
利点、欠点を考えて判断すりゃいいんじゃない？
利点：ローカルスコープの関数・変数が一目でわかる
欠点：メンバー変数とメンバー関数のバッティングが発生する可能性がある（C++の場合）
-->別の命名規則で回避する必要あり
ぐらいかね？
ローカルスコープなんだし好きにすれば？という気もするけど。
284:デフォルトの名無しさん
07/12/15 13:28:58
>>282
_ 前に付けて問題になったことなど一度たりともないけどな。
メンバ変数なんてローカルだし。
__descspecとかのキーワードなんて __ だしな
285:デフォルトの名無しさん
07/12/15 13:56:19
>>280
creat()については名付け親がそうつけてしまったことを深く恥じているのだから、
もうそっとしておいてあげたらどうだw
286:デフォルトの名無しさん
07/12/15 15:40:04
釣りか本気か微妙な流れだw
287:デフォルトの名無しさん
07/12/15 23:55:12
>>284
__declspecはむしろ正しい使い方。
処理系予約の識別子なのだから。
288:デフォルトの名無しさん
07/12/16 00:04:35
>>287
？
いや、その通りだけど、>>284の趣旨は、「そういうのは"__"だから、"_"を前につけても問題が起こったことはない」でしょ。
289:デフォルトの名無しさん
07/12/16 01:34:46
ﾅｲｼﾌｫﾛｰ
290:デフォルトの名無しさん
07/12/16 01:42:20
>>280
歴史的なもの
識別子に5文字しか使えなかったシステムで付けられた名前を引きずってるだけ
291:デフォルトの名無しさん
07/12/16 02:50:52
>>284
一度もないのは分かるけど、
規格で「予約」と明記されているものをあえて使う理由が分からん。
ローカル名については「マナー」程度なのかな？
他の言語だと「予約」だったりするんだろうか。
292:デフォルトの名無しさん
07/12/16 07:00:04
2重の__ は予約かも知れないが、
グローバルの_ はstdio.hとかのライブラリと被るので
~~~~~~~~~~~~~~~
注意ってことじゃなかったかって気がするんだが。
手元に資料がないから確認は取ってないが
293:デフォルトの名無しさん
07/12/16 07:04:09
あ、一つ思い出した。
そういやBUFSIZ ってシンボル使えないよなｗ
294:デフォルトの名無しさん
07/12/16 11:04:04
>>292
どっちも「予約」だよ。識別子の利用範囲が違うだけ。区別するのがメンドイから
自分とこで作るルールに書くときは一括でダメってことにするのが簡単。
295:デフォルトの名無しさん
07/12/16 11:26:03
URLﾘﾝｸ(www.alles.or.jp)
ちょっと見つけた
296:デフォルトの名無しさん
07/12/16 13:52:19
>>295
うーーー。意味わかんない；
ごめんオレ馬鹿すぎ。エロイ人教えて。
297:296
07/12/16 13:58:19
あ、泣くほど読んだらわかった；
298:デフォルトの名無しさん
07/12/16 13:59:11
>>296
>281-282 にある
> _ は前に普通に付ける時代があった
> 前につけることの問題を知らずに本を書いちゃうようなアホ
の例じゃね？
299:デフォルトの名無しさん
07/12/16 15:05:06
まぁ明日ARMでも読んでみるわ。
メンバ変数名は、
グローバルなネームスペースを汚してるわけじゃないしね
300:デフォルトの名無しさん
07/12/17 02:42:38
っ >168
301:デフォルトの名無しさん
07/12/17 02:50:17
なぜ予約語とぶつかる可能性のあることをしようとするのか
いまひとつわからない
たしかに、かっこいいかもしれないけど
_や__が予約語に多いのだから、他人が見たら、
これらは予約語としてみられる可能性があるということでしょ？
できるだけ、必然的であるべきだと思うのだけど
でないと後で見てわからない気がするんだけどな
名称を考えるのがめんどくさいだけに思えるのは、オレが世間知らずだから？
302:デフォルトの名無しさん
07/12/17 02:54:48
C/C++ の入門書や入門サイトがそういうインクルードガードを書いてたり。
そういうのを見て覚えた奴が自己弁護のために抵抗してるだけ。目的なんか無い。
303:デフォルトの名無しさん
07/12/17 08:01:37
_で始まる予約語に何があるか言ってみろよ
304:デフォルトの名無しさん
07/12/17 08:05:56
>>300
やっぱ答え出てるじゃないか。
メンバ変数はグローバルじゃねえ。
関数名とグローバル変数に問題があるだけだろうな
305:デフォルトの名無しさん
07/12/17 11:48:40
>>301,303 予約語じゃなくて、予約識別子ね。
306:デフォルトの名無しさん
07/12/17 15:58:27
>>303
_STDLIB_H_
307:デフォルトの名無しさん
07/12/18 00:11:07
>>305
それならわかるわ
検索してみたら、いいページ掛かったわ
308:デフォルトの名無しさん
07/12/18 06:32:30
結局 _ をつけたがるのは
自分の作ったのを予約語扱いしてもらいたい 「格好つけしー」 か
考えるのが面倒で、 _ でもつけとけの 「横着者」 のどっちか
でいいの？
309:デフォルトの名無しさん
07/12/18 08:17:39
>>308
_ のあとの小文字は問題ねーってよ
310:デフォルトの名無しさん
07/12/18 08:33:41
>>309
昔のDOS系、MSのLIBなんかは _ の関数だらけ
これを予約語といえるかわからんが
それと同列のものにしたいということだろ？
311:デフォルトの名無しさん
07/12/18 11:31:02
>>309
何が問題ねーの？予約識別子じゃないの？
312:デフォルトの名無しさん
07/12/18 11:46:38
_ のあと小文字は、グローバルスコープ（ファイルスコープ）のみで予約。以下 >294
313:デフォルトの名無しさん
07/12/18 12:17:43
>>168の短い文章を理解するのに一体何レス費やせば気が済むんだ？
314:デフォルトの名無しさん
07/12/18 12:21:59
「ある目的のために」とか、わかりにくい誤訳が入ってたからじゃね？
315:デフォルトの名無しさん
07/12/18 22:50:44
グローバルな名前空間でとわざわざ限定してくれてるからじゃん
316:デフォルトの名無しさん
07/12/19 05:46:36
「感染してますが、コンドームをつけてれば大丈夫です」と言われてもやる気はしないのと同じ
例えが、ちがうか；
317:デフォルトの名無しさん
07/12/23 23:54:01
( ﾟдﾟ )
¶ノ ¶ノ |
／￣￣￣￣￣＼
./ （,） （,） ヽ
| |￣| |
ヽ ￣￣ /
| | | | |
.ノ .ﾉ ヽ ノ .ﾉ .|
(＿ノ (＿ノ .|
／ ／ ￣／ ／
< < .< <
ヽ ヽ ヽ ヽ
318:デフォルトの名無しさん
07/12/25 07:53:47
あ、そうそう そうすると
#ifndef _FILENAME_H
#define _FILENAME_H
はどんなシンボル名にしてんの？
#define H_FILENAME_H
とか？( ﾟдﾟ)
319:デフォルトの名無しさん
07/12/25 10:30:28
FILENAME_HでもMACRO_OF_FILENAME_Hでもお好きなものをどうぞ。
320:デフォルトの名無しさん
07/12/26 04:02:28
MACRO_OF_*は却下
321:デフォルトの名無しさん
07/12/26 04:09:12
#pragma onceでいいよもう
322:デフォルトの名無しさん
07/12/26 04:10:30
せっかくポータブルな方法があるのに、
そうじゃない手段をわざわざ使うのは気が引けるよ
323:デフォルトの名無しさん
07/12/29 11:30:30
規律正しいおまいらなら
#ifndef
の使用はもうやめたんだろ？
324:デフォルトの名無しさん
07/12/29 13:41:22
両方使うのは意味があるのかな？
325:デフォルトの名無しさん
07/12/30 00:07:39
>>323
なんで ifndef はいけないと思うの？
326:デフォルトの名無しさん
08/02/19 01:14:20
皆さんのスタイルを、GNU indentの引数で表現するってのはどうでしょか。
俺は単純に
indent -kr hoge.c
です。
327:デフォルトの名無しさん
08/02/19 14:45:58
>>325
名前がぶつかるかも知れない恐怖が
328:デフォルトの名無しさん
08/03/16 18:09:35
ソースのフルパスをマクロ名に入れとけば無問題ｗ
329:デフォルトの名無しさん
08/04/13 15:16:47
そんなにぶつかるのが怖いなら、GUIDでいいんじゃないか？インクルードガードなんか入力することなんかないんだからさ。
330:デフォルトの名無しさん
08/07/28 01:19:20
URLﾘﾝｸ(lolo.jp)
331:デフォルトの名無しさん
08/07/30 22:41:39
はてなで話題になってたが
URLﾘﾝｸ(d.hatena.ne.jp)
これを厳密に守るのはきついな……
332:デフォルトの名無しさん
08/08/07 15:47:21
これはJAVAを念頭に置いてるのか？
333:デフォルトの名無しさん
08/08/09 21:26:02
>>331
goto有害論並に偏りすぎてねぇか？
334:デフォルトの名無しさん
08/08/09 22:46:42
手続き型脳を矯正するには多少極端なくらいのショック療法が必要ってことだろ
335:デフォルトの名無しさん
08/08/25 00:22:16
OO厨だった学生時代はそういう病的に分割されたコードばっか書いてたな。
だけど、働き始めて周りの人間にソース追いにくいだのなんだの
不評だったせいでいつのまにか書かなくなったが。
336:デフォルトの名無しさん
08/10/01 21:55:22
C++でオペレータの宣言・定義するときにoperator=とかくのかoperator =とかくのかそういうのって決まってるの？
337:デフォルトの名無しさん
08/10/01 21:56:36
それは多分、インデントの量とか中括弧の位置なんかと同じテーマだと思うんだが。
338:デフォルトの名無しさん
08/10/01 23:43:18
>>336
検索しやすいように空けない。
339:デフォルトの名無しさん
08/10/02 00:07:24
operator\w= で検索すればおｋ
340:デフォルトの名無しさん
08/10/02 00:08:04
↑*追加しといて
341:デフォルトの名無しさん
08/10/02 20:45:35
\w じゃダメだろ。
342:デフォルトの名無しさん
08/10/03 01:01:52
じゃあ
operator\wktk=
343:デフォルトの名無しさん
08/10/09 08:01:21
elevaterⅡ
escalator⊿