ぱっと見て「ヘタだなぁ」と思うコード その5at TECH
ぱっと見て「ヘタだなぁ」と思うコード その5 - 暇つぶし2ch1:デフォルトの名無しさん
06/08/12 01:56:11
禁止ネタ(超既出)
・長い関数
・深いネスト
・グローバル変数
・goto
・memset
・malloc - free
・局所ブロック
・サンプルコードのtypo
・記述スタイル
・関数・変数名

過去スレ
その4: スレリンク(tech板)
その3: スレリンク(tech板)
その2: スレリンク(tech板)
初代 : スレリンク(tech板)


2:デフォルトの名無しさん
06/08/12 02:00:16
まだやんの?

3:1
06/08/12 02:01:37
Cネタはもう枯渇気味なので、他言語ネタ求む。

4:デフォルトの名無しさん
06/08/12 02:27:23
Perlとか、上手い下手以前に手馴れた奴が書いたコードは解読不能

5:デフォルトの名無しさん
06/08/12 02:38:17
某スレより。
perl -e 'print $_[int(rand(@_ = <>))]' hoge.txt
たったこれだけで、吐き気がする。

6:デフォルトの名無しさん
06/08/12 02:39:42
AAにしか見えないなw

7:1
06/08/12 02:45:27
Perlの解読不能ネタはさんざん既出なんですが・・・

このスレ的には新しいので、どうぞお続けください。

8:デフォルトの名無しさん
06/08/12 02:53:35
そうさせていただきます

9:デフォルトの名無しさん
06/08/12 03:09:29
perlのrandってsrandしないでいいんだなぁ

10:デフォルトの名無しさん
06/08/12 04:18:23
java で

// double-checked locking を使う

とか自信満々にコメントされたエセ singleton に遭遇した時。

11:デフォルトの名無しさん
06/08/12 06:48:16
>>10
というか、そもそもdouble-checked lockingってJavaで上手く動かないから論外だよな。
URLリンク(www-06.ibm.com)

12:デフォルトの名無しさん
06/08/12 07:30:30
前スレとはうって変わって、為になりそうな予感

13:デフォルトの名無しさん
06/08/12 07:59:14
>>5
どうみても上手い下手の問題ではないので却下。
sedやawkで修行してくればPerlは天国に見えるよ

14:デフォルトの名無しさん
06/08/12 08:15:37
VC++ で ExcelのタイプライブラリのC++ヘッダファイルを自動生成したら、ロクにビルドを通らないシロモノだった件。

15:デフォルトの名無しさん
06/08/12 09:47:10
>>5
それ、intは無くてもいいな。
perl -e 'print $_[rand(@_=<>)]' hoge.txt

まあ、「不必要なものが付いてる」と、「可読性を考えずに削る」、
どちらが『ぱっと見ヘタ』かは判らないけど。

16:デフォルトの名無しさん
06/08/12 10:43:24 BE:49923252-2BP(200)
>>1 基本的なネタを延々とやることにこのスレの意義があるのに。。。

17:デフォルトの名無しさん
06/08/12 11:31:37
>>14
それは、バグとか仕様不良の類なので、スレ違い。

18:デフォルトの名無しさん
06/08/12 12:02:45
>>11
ぱっとみてアホレスですな。

10はdouble-checked lockingはダメ解法と踏まえた上でレスしてるのは明白なんだから
お前の「というか」とか意味不明すぎる。

何が"というか"だよ。
知識披露厨乙。

19:デフォルトの名無しさん
06/08/12 12:06:03
> ・局所ブロック
局所ブロックって、if とか for とか while なしで、{ } でブロック作るやつのこと?

20:まあ、釣られた俺もなぁ~。(w
06/08/12 13:20:30
お前が >>10 でないなら、「明白」なんてことは言えない。

お前が >>10 なら、double-checked locking はヘタとか言う
以前の話でスレ違い。

どちらにせよ、>>18 のレスは「ヘタな煽り」にしか見えない。

21:デフォルトの名無しさん
06/08/12 13:22:07
結論:オレサマイガイ ミンナ ヘタクソ

22:デフォルトの名無しさん
06/08/12 13:25:19
>>20
明白だってこともわからんアホですか。
しかもスレ違いと思ったけどレスしましたってアホですか。

ホントお前アホだなぁ…。

23:デフォルトの名無しさん
06/08/12 14:22:39
明日でも昨日でもいいじゃんかよ!

24:デフォルトの名無しさん
06/08/12 14:46:53
>>22
ププッ、顔真っ赤だぞ オ・マ・エ (w

25:デフォルトの名無しさん
06/08/12 14:52:06
ここはいいモヒカン族の養殖場ですね

26:デフォルトの名無しさん
06/08/12 15:55:13
>>24
アホの典型的負け犬の遠吠えレス乙
言い返せなくなるとソレだよな。

27:デフォルトの名無しさん
06/08/12 16:18:06
int Gethoge {
  if(hoge=TRUE){return 1;}
  return 0;
}

28:デフォルトの名無しさん
06/08/12 18:01:15
変数宣言時にとりあえずnewしてるのは嫌いだ。


29:デフォルトの名無しさん
06/08/12 18:04:56 BE:359446098-2BP(201)
ふつー宣言と同時にnew

30:デフォルトの名無しさん
06/08/12 18:09:15
BEのキチガイがまたいるな・・・

31:デフォルトの名無しさん
06/08/12 18:18:21
JavaやC++で関数定義の頭に宣言が固まってるコードは頭が悪いと思う。

32:デフォルトの名無しさん
06/08/12 18:31:46
> 28
> 31
使う箇所で宣言すりゃ普通その場でnewじゃね?


33:デフォルトの名無しさん
06/08/12 18:36:36
>>14
Officeのタイプライブラリなどを同時にインポートすればよいだけ。

ただたしかに、
「"xxx.h"をインクルードする前に"yyy.h"をインクルードする必要があります」
ということとと同じことだから、下手といえば下手。

34:デフォルトの名無しさん
06/08/12 18:41:49 BE:359446289-2BP(201)
>>31
>>32
そうだよな。
使う直前に宣言して、その場でnew。

関数の先頭でまとめて宣言してるのが行儀いいって思ってるアホとかたまに見るな。

35:デフォルトの名無しさん
06/08/12 19:09:14
>>26
何を言い返す必要があるんだろう…。

どうやら、>>11>>10 の唯一の自慢に触れてしまったみたいだな。(w

>>34
> 関数の先頭でまとめて宣言してるのが行儀いいって思ってるアホとか
> たまに見るな。

昔の流儀が抜けないだけだろ。

36:デフォルトの名無しさん
06/08/12 19:11:18
今でも入門書にK&R勧めてるのを見かけたりするもんなー
正直、正気を疑うところだが

37:デフォルトの名無しさん
06/08/12 19:14:51
>>32
気になるのは
Child c = new Child();
c = parents.getChild();
というような記述。

38:デフォルトの名無しさん
06/08/12 19:21:33
使いまわしの話か?

39:デフォルトの名無しさん
06/08/12 19:31:38
想像だけど。

使い回してるんじゃなくて、宣言時にアサインしたnew Child()は結局使っても
いないんだろう。ところが、ブロック開始時に宣言する習慣が抜けず、なおかつ
宣言したらその場で初期化すべし、という金科玉条を守るために使いもしないオ
ブジェクトを割り当ててる。

40:デフォルトの名無しさん
06/08/12 19:34:24
それは下手どころか間違ってんじゃねーか
初学者とかならさておき、そんなコードを恒常的に書く奴いんのか?

41:デフォルトの名無しさん
06/08/12 19:54:46
CやPascalみたいに使う変数が固まってくれてる方が個人的には読みやすい

Option Explicitがついてない上に、include先のグローバル変数、
それも「strPath」みたいなごく普通の名前のグルーバル変数が
縦横無尽に飛び交っている。そんなVBSが今まで読んだ中でも最凶のコード

42:デフォルトの名無しさん
06/08/12 20:02:40 BE:174730875-2BP(201)
>>41
>CやPascalみたいに使う変数が固まってくれてる方が個人的には読みやすい 

COBOLみたいに、プログラムの先頭で全部宣言してあれば最強ってことか。

43:デフォルトの名無しさん
06/08/12 20:02:44
>>40
間違ってるかどうかはともかく、問題が起きるとは限らないんだな。
だからブロック開始部分に限らず結構見かけるね。

44:デフォルトの名無しさん
06/08/12 20:20:04
金科玉条を守るためなら
とりあえず null で初期化すれば良いような。

45:デフォルトの名無しさん
06/08/12 20:21:42
最近どこかの質問スレで見かけたよ。
Class1 class1 = new Class1();
class1 = oldclass1;

Class1 class1 = oldclass1;
って何か違うんですか、どっち使うべきですか、って感じだった

46:デフォルトの名無しさん
06/08/12 20:27:54
>>35
何にも言い返す必要が無い癖に

> ププッ、顔真っ赤だぞ オ・マ・エ (w

とレスしたのか?
口を開けば矛盾が出るな。どこまでアホなの?

47:デフォルトの名無しさん
06/08/12 20:28:18
Class1のコンストラクタにある副作用が
必要なら上、そうでなければ下。

48:デフォルトの名無しさん
06/08/12 20:35:46
>>47
そんな副作用が必要だったらそれはそれで下手だ

49:デフォルトの名無しさん
06/08/12 20:39:12
18,22,24,26,35,46 をスルー。
キーワードはアホと行末の(wです。

50:デフォルトの名無しさん
06/08/12 21:43:55
>>44
それにすら気づかないから、下手なコードなんだろう。

51:デフォルトの名無しさん
06/08/12 22:51:50
>>46
どこが矛盾してるんだろうか…。

>>22 があまりにも必死に見えただけなんだけど。

もしかして日本語もあまり得意じゃないのかな? (w

52:デフォルトの名無しさん
06/08/12 23:16:19
もうすぐお盆なんだからそんなことで煽りあってると
ご先祖様に叱られるぞ

53:デフォルトの名無しさん
06/08/12 23:17:31
腹抱えて笑ってるだろうな無様さを

54:デフォルトの名無しさん
06/08/13 00:39:17
>>11
そういう趣旨だろ、>>10は。

55:デフォルトの名無しさん
06/08/13 00:41:55
>>48
それこそ、下手というより間違ってるな、だな。

56:デフォルトの名無しさん
06/08/13 01:07:45
>>45
つ *

57:デフォルトの名無しさん
06/08/13 01:12:57
いや、君の肛門さしだされても……

58:デフォルトの名無しさん
06/08/13 08:55:32
僕の肛門も無限ループしそうです

59:デフォルトの名無しさん
06/08/14 09:05:58
printf(hogestring);

こういうコードを見た時。脱力する

60:デフォルトの名無しさん
06/08/14 10:25:00
>>59
勝手に脱力してろ、アホ

61:デフォルトの名無しさん
06/08/14 10:39:19
俺は脱毛した。

62:デフォルトの名無しさん
06/08/14 10:40:10
数日前、auの端末でそれ系のバグがあって話題になってたね。

63:デフォルトの名無しさん
06/08/17 11:39:26
単発コメントはゴミ以下。プログラム全体を奏でる壮大なシンフォニーであってほしい。

64:デフォルトの名無しさん
06/08/17 12:40:14
do_something(foo);
do_something(foo); // 何故か二回呼ばないと駄目

65:デフォルトの名無しさん
06/08/17 16:41:55
int kesuna[4000];
↑このkesunaは何処からも参照されてないのに
消したら本当に実行時エラーが発生して噴いた。
そんなヘタなコード。(実話)
何でだ?

66:デフォルトの名無しさん
06/08/17 16:51:06
おそらく、ローカルに作った配列で範囲はみ出してスタック書きつぶしてるんだろ。
kesunaがあるとそこを書きつぶすので実害にならない。

67:デフォルトの名無しさん
06/08/17 16:55:39
なるほど~

68:デフォルトの名無しさん
06/08/17 16:59:31
感心している場合じゃないぞw
こわいコードだな。

69:デフォルトの名無しさん
06/08/17 17:01:38
>>65
それってあれだよね。
VCとかだったらデバッガモードでは動いてたけど
リリースモードにしたら動かなくなったみたいなパターンだね。


70:デフォルトの名無しさん
06/08/17 17:44:27 BE:99846645-2BP(201)
決まったタイミングで実行時エラーが出るなら、潰しやすいバグだと思うが。

71:デフォルトの名無しさん
06/08/17 17:55:42
下手とバグは分けましょう。

72:デフォルトの名無しさん
06/08/17 18:33:28
retrun answer + 1;   // なぜか1少ないので1足して戻す

73:デフォルトの名無しさん
06/08/17 18:35:45
// 100未満のときに、なぜか1少ないということがわかったので、そのときだけ1足して戻す
if (answer < 100) {
  return answer + 1;
} else {
  return answer;
}

74:デフォルトの名無しさん
06/08/17 18:37:23
// 100~1000のときだけ、正しい値になることがわかったので、
// それ以外は1足してもどす
if (answer >= 100 && answer <= 1000) {
  return answer;
} else {
  return answer + 1;
}

75:デフォルトの名無しさん
06/08/17 18:37:58
// テストの結果、10,000以上のときも・・・

泥縄

76:デフォルトの名無しさん
06/08/17 18:43:11
>>72
あるある。

77:デフォルトの名無しさん
06/08/17 18:44:55
// free(p);   // ここでfreeすると何故だか落ちるのでコメントアウト

78:デフォルトの名無しさん
06/08/17 18:46:03
「なぜか」「なぜだか」がキーワードですなw

79:デフォルトの名無しさん
06/08/17 21:38:38
>>72-78
>>71

80:デフォルトの名無しさん
06/08/17 21:51:07
いや、バグ対処の仕方が激しく間違ってるんだろ。

81:デフォルトの名無しさん
06/08/17 22:29:37
ヘタなデバッグのやり方を披露するスレじゃないだろ。

82:デフォルトの名無しさん
06/08/17 22:31:16
ネタ切れなんだから、なんでもいいじゃn

83:デフォルトの名無しさん
06/08/17 23:45:29
普通に考えたら、上手に書けてんのにバグってるなんて珍妙な事態は無いはずだしなー。
そう思うと結構難しいな、このスレ。

84:デフォルトの名無しさん
06/08/17 23:56:27 BE:209677076-2BP(201)
ネットでちょっと探したら、ゴロゴロころがってるけど。 > へたなコード

85:デフォルトの名無しさん
06/08/17 23:59:08
じゃ見つけて貼ってくれよ

86:デフォルトの名無しさん
06/08/17 23:59:35 BE:124808055-2BP(201)
こんなのとか。

URLリンク(www.tcp-ip.or.jp)

>/* [参考] 推奨する方法
>class Foo {           
>    int i ;                   
>...
>    const int& get2() { return i ; }    リタ-ンで返す場合


87:デフォルトの名無しさん
06/08/18 00:02:45
>>86
どこがどう下手なのか書きましょう。

88:デフォルトの名無しさん
06/08/18 00:04:44 BE:89862236-2BP(201)
>>87
ぱっとみて分かるようになりましょう。

89:デフォルトの名無しさん
06/08/18 00:06:07
>>86
最初につっこむのはむしろここじゃね?
>#include<iostream.h>
>....
>void main()


90:デフォルトの名無しさん
06/08/18 00:07:29
>>86
つか、そのサイト、古いしむちゃくちゃなので、いまさら感がある

91:デフォルトの名無しさん
06/08/18 00:08:08
関係ないが/* */うぜー

92:デフォルトの名無しさん
06/08/18 00:15:25
>>88
ぱっとみても分かりません。説明してください。

93:デフォルトの名無しさん
06/08/18 00:26:30
突込みどころがいろいろあるだけに、まずどこに対して突っ込むのが正解かわからないな。

94:デフォルトの名無しさん
06/08/18 00:28:38
intの参照を返すって辺りか

95:デフォルトの名無しさん
06/08/18 00:34:53
constの参照返しといて自分がconst関数じゃないあたりとかもか

96:デフォルトの名無しさん
06/08/18 00:47:05 BE:89862236-2BP(201)
>>94
あと、クラス内部への参照を外に渡してるってのも。

97:デフォルトの名無しさん
06/08/18 00:52:25
>クラス内部への参照を外に渡してる

いつでも許される類のもんじゃ無いにせよ、それ自体は別に有りだろ。
一応const憑いてるしな。

98:デフォルトの名無しさん
06/08/18 03:39:11
このサイト、1999年だか2000年だかに作られた古いページだから。
当時このページ見つけたとき、その時でもなんじゃこりゃ感はあったw

内容が書き換わってるのか書き換わってないのか知らないけど、
一番の「下手」は、作成日時と更新日時を各ページに載せてないとこだな。

99:デフォルトの名無しさん
06/08/18 03:46:13
思ってたより新しいな。

100:デフォルトの名無しさん
06/08/18 10:19:15 BE:49923825-2BP(201)
〉97
いや、ほとんどの場合、無しだろ。
const付きでも。

101:デフォルトの名無しさん
06/08/18 10:29:11
>>100
ほとんどの場合ということは、例外もあるということですよね。
どのような例外ケースがあるのでしょうか?

102:デフォルトの名無しさん
06/08/18 10:43:55
古いサイトは古いままのが多いよな

103:デフォルトの名無しさん
06/08/18 14:18:43
昔のサイトは古いよな~
びっくりだぜ
それに比べて最近のは先進的だね。
サイコー

104:デフォルトの名無しさん
06/08/18 21:10:12 BE:279569287-2BP(201)
URLリンク(www.nmn.jp)
これなんか10年も前だな。

105:デフォルトの名無しさん
06/08/18 21:43:45
>>104
どこがどう下手なのか書きましょう。

106:デフォルトの名無しさん
06/08/18 21:49:06
誰も下手だとは言ってないだろ。

107:デフォルトの名無しさん
06/08/18 21:51:33
>>106
リンク先読むとこだったじゃないか、ボケ

108:デフォルトの名無しさん
06/08/18 22:22:24 BE:199692858-2BP(201)
URLリンク(next1.cc.it-hiroshima.ac.jp)

サンプルのインデントがメチャクチャ。
なんでかなと思ってソースを見てみたら、wordで出力したhtmlだった。

109:デフォルトの名無しさん
06/08/18 22:32:22
どんどん下手なコードから遠ざかっていくなぁ

110:デフォルトの名無しさん
06/08/18 22:39:55
宗教論争は盛り上がるんだけど
非難一辺倒なコードはヘタ以前に
致命的な間違い犯してる場合が殆どやしねえ。

111:デフォルトの名無しさん
06/08/18 22:41:19 BE:314515679-2BP(201)
じゃ、109が酒の肴になるようなヘタなコードを披露するってことで。

112:デフォルトの名無しさん
06/08/18 22:42:14
いや俺酒飲まないし

113:デフォルトの名無しさん
06/08/18 22:50:06
昔書いたソース見てくるよ。

114:デフォルトの名無しさん
06/08/18 23:09:10
//test = hoge1(hage~moge);
//test = hoge2(moge~hage);
test = hoge3(hage~hage);
//test = hoge4(moge~moge);



コメントアウトが残ってる事自体は別として
何が悪くて何がしたくて何が良くてhoge3を残したのか
hoge1~4の先を全部読むまで全くわからんし
そうじゃなくても可読性低下させるだけの古い
糞コードを糞しつこく糞こびり付かせてると吐き気がする。

しかも古いコードはコメントアウトして残しておくようにとか指示する糞野郎の下だと
糞がぼとぼと降り注ぐ中で自分も糞を生産するという地獄絵図だよな

115:デフォルトの名無しさん
06/08/18 23:27:35
古いコード・・歳を取ってしまった自分
残しておけ・・俺を捨てないでくれ

というメタファーに気がつけ。


まぁそれはともかく。
マジックナンバー満載の素敵コードのおかげで
徹夜のデバッグを余儀なくされると殺意沸くよね。
ヘタとか以前に死ねと思うコード。

116:113
06/08/18 23:33:19
さらーっと眺めてきた。
下手は下手だけど、思ったほど酷くない気がした。もっと下手なのみたことあるし。

いろんな文字列定数がハードコーディングされてて、後から弄りづらそう(VB)。
「エラー '55' 対策」 とかコメント書いてるけど、何のエラーなのか分からん(VB)。
まるっきり手続き型言語みたいな書きかた(VB)。
ほとんどグローバル変数(Perl)。
探せばライブラリがいくらでもありそうなのを、頑張って車輪の再開発してる(Perl)。
GUIの処理が随分奥深いとこまで食い込んでる(Delphi)。
ビットフィールドの解析を配列読み込んで1byteずつしこしこ処理してる(Delphi)。
一行に纏めすぎ。if pbuf = nil then begin BlockRead(fh, buf, 512, AmtTransferred); pbuf := @buf; end;
200行くらいの、ほとんど同じ処理の関数が3つもある(計画性なく拡張したせいなのだが)。

117:デフォルトの名無しさん
06/08/19 00:15:48
>>115
殺人コードだな

118:デフォルトの名無しさん
06/08/21 21:55:00
某スレで汚いといわれたんで修正したんですが、まだ自身がないのでみてください。
URLリンク(up2.viploader.net)

119:デフォルトの名無しさん
06/08/21 22:22:01
過疎板で回転の速いうpろだにあげちゃだめって何度も言ったのに…。

120:デフォルトの名無しさん
06/08/21 22:28:41
>>118
気になったところ。

using namespace std; <-思わぬところで衝突するかも
if文             <-必ず括弧を付けよう
fin.close();         <-勝手にやってくれるから書くだけ無駄

121:デフォルトの名無しさん
06/08/21 22:40:40
>>118
クラス名や変数名を見ても目的がわかりづらい。aとかbとか使うな。
何も書かれていないmain.hやgetメソッドの存在意義がわからん。
ヘッダが無いと動かないってわけでもないし
set書いたらgetも書かなきゃいけないというわけでもない。

122:デフォルトの名無しさん
06/08/21 23:12:53 BE:19969722-2BP(201)
>>118

>if(b)
>   b = 0;
>else
>   b = 1;

boolにはtrueとfalseを入れればいいじゃん。
値の反転はこうで。
b = !b;



123:デフォルトの名無しさん
06/08/22 00:30:27
>>118
重要なのにコメント化


124:デフォルトの名無しさん
06/08/22 00:32:04
> bool b(0);

boolにもコンストラクタってあったの? 知らなかった...
いつも
bool b = false;
と書いてました。



125:デフォルトの名無しさん
06/08/22 00:58:35
bool(0)は関数形式のキャスト演算子では?

126:デフォルトの名無しさん
06/08/22 01:18:13
>>124
C++では、そのように組み込み型のオブジェクトもコンストラクタ引数を指定するのと同じ構文で初期化できる。

127:デフォルトの名無しさん
06/08/22 01:23:30
見たことないの関数やらクラスがあるが必要もなさそう
C言語の関数?それとも昔の表記方法?wは全部不要じゃん?
wstring
wifstream
wcout
imbue
locale

128:デフォルトの名無しさん
06/08/22 01:24:05
locale("japanese")よりlocale("")の方が良いと思う。
あと0x0D, 0x0Aではなく'\r', '\n'にしろ。(それでは良くない環境ならせめて'\x0a', '\x0d')

129:デフォルトの名無しさん
06/08/22 01:25:42
ここで指摘の多い様な、ぱっと見の下手なコードって
C++に集中してる気がするのは気のせいか?

適当に書いても適当に通っちまったり、オペレーターオーバーロードとかで
出鱈目やってもコンパイラ的には全然OKだったり、無法がまかり通るからなのかな…

130:デフォルトの名無しさん
06/08/22 01:48:28
Hoge::Hoge()
{
 this->isFuga = true;
}

よりも

Hoge:Hoge()
: this->isFuga(true)
{
}

が望ましい。


131:デフォルトの名無しさん
06/08/22 02:02:27
なんで?プリミティブななんとかが関係有る?

132:デフォルトの名無しさん
06/08/22 02:05:00
それ以前に何故にthisを明記するか。
voidは省略してやがる癖に。

133:デフォルトの名無しさん
06/08/22 02:07:57
>>131
コンストラクタ本体での設定は、初期化じゃなくて代入になる。
constメンバとか、参照メンバはこの方法じゃないと初期化できない。

134:デフォルトの名無しさん
06/08/22 02:14:04
>>133
まあ、普通に常識ではあるよな。
正直なところ基本型についてはどっちでやってもええやんとは思うが。
二重コンストラクタとか用意した方が取り回しの便利なクラスとかだと、
わざわざ無駄になる初期化部分を書くのが面倒ちい。

class Hage
{
int hige;
public:
Hage() { init(); }
void init() { hage = 0; }
};

とか。

135:デフォルトの名無しさん
06/08/22 05:08:27
>>129
コードがキレイかどうかを気にするのがC++プログラマに多いからじゃね?

136:118
06/08/22 08:53:29
>>120
わかりました、そうします。

>>121
まだちょっと実装不足です。

>>122
それがありました・・・orz

>>123
あれは実験コードで・・・今のもだけど

>>125
できるらしいです、Effective c++より

>>127
stringをマルチバイトでgetコマンドすると一バイトずつ読みバケるんで、
自分で処理するのにも自信ないのでc++のマルチバイト処理関数使ってます。
ちゃんと解説してる本やサイトなくてつらかった・・・

>>128
そういう方法で処理します。(enumハックでするとどうなるんだろう)

次にテンプレート化して提出します。え、そういうスレじゃない?

137:デフォルトの名無しさん
06/08/22 11:30:10
Effective C++なんて読むレベルの奴がこんな指摘されるはず無いのだが

138:デフォルトの名無しさん
06/08/22 14:24:07
うーん、いや実際に読んでるよ。読むだけ

139:デフォルトの名無しさん
06/08/23 01:36:00
MoreEffectiveもデザパタも読んでモヒカン入門した俺の頭のテカリ具合を見てくれ。
こいつをどう思う?

140:デフォルトの名無しさん
06/08/23 02:36:46
すごく…氏ね…

141:デフォルトの名無しさん
06/08/23 07:19:15
TYPOしたままやけくそで全部そのままTYPO名使ってるコード。
つーか置換しろよ…

142:デフォルトの名無しさん
06/08/23 08:54:23
検索する時困るんだよな。
確か stopFlag だったよなーと思って探しても見つからず途方にくれる。
実は stopFlug でした、とか。そりゃみつからねーや。

143:デフォルトの名無しさん
06/08/23 10:49:14
普通は見つからなかったらtypoだと思い"stop"で検索かける。

144:デフォルトの名無しさん
06/08/23 13:12:29
stapFlugだったりとか。

ちょっと長めの名前だと、補完使ったりコピペするので、
TYPOにしばらく気づかないことが多いな。

145:デフォルトの名無しさん
06/08/23 13:23:18
気付いたときには手遅れだったり。

146:デフォルトの名無しさん
06/08/23 13:25:49
typoはtypeのtypoだ、とまことしやかに説明している人がいた。

147:デフォルトの名無しさん
06/08/23 13:34:16
これまたリカーシブですね

148:デフォルトの名無しさん
06/08/23 20:46:08
一応クラスでは作り終わった?評価よろしくお願いいたします

URLリンク(maidx.net)

149:デフォルトの名無しさん
06/08/23 20:46:52
typoってどーゆーいみ?

150:デフォルトの名無しさん
06/08/23 20:52:07 BE:59908526-2BP(201)
昔fj見てたとき、なんでふつーに日本語で書かないんだろって思ってたよ > typo

151:デフォルトの名無しさん
06/08/23 21:15:11
typographical error

152:デフォルトの名無しさん
06/08/23 21:17:06
>>148

・識別子が全部小文字で非常に見づらい。
単語の区切りが明確になるようにアンダーバーを入れれ。
ローカル変数も然り。

・getdateinputinfってのが何なのかさっぱりわからんけど適切な命名ではないと思う。

・getstreamopenでなくてis_stream_open。
名前だけ見ると別の意味になる。

・コメントがなさすぎ。命名の微妙さとあいまって何をやってるコードなのかさっぱりわからん。


153:デフォルトの名無しさん
06/08/23 21:28:33
>>148
Error #503
Service Unavailable
BoostWeb BW4.2.16.1 Feb 24 2003 at bw03

154:デフォルトの名無しさん
06/08/23 22:50:17 BE:404376899-2BP(201)
>>148
>if(b){
>   value += a;
>}else{
>   value += a;
>}

これはバグ?


155:デフォルトの名無しさん
06/08/24 12:28:27
>>152
クラス名・変数名に迷ったら書き込むスレ。Part8
スレリンク(tech板)
ちょっと、行っています

>>153
即行消されたのか・・・

>>154
消し忘れです

一応やってみました
URLリンク(up2.viploader.net)
バグありでファイルを開いてインプットした後
閉じてもう一回読んだときファイルストリームができない・・・なぜ?

156:デフォルトの名無しさん
06/08/25 01:10:43
>ファイルをとじらせるバグってる
日本語でOK。

157:デフォルトの名無しさん
06/08/28 01:53:12
開発で見かけた、T芝のコード。
関数の途中で数箇所return的な処理をする代わりにgoto使ってる。

void xxx()
{
:
if( ... )
{
goto END;
}

switdh( ... )
{
case xxx:
goto END;
:
}

END:
return;
}

・・・こういう目的限定なら使ってもいいのか?俺は使わないが。

158:デフォルトの名無しさん
06/08/28 02:09:36
その例なら 普通に return した方が良い。

ただ、エラー処理が混じる場合は
goto を使った方がエレガントに書けるので
積極的に使えば良いという人も少なからずいる。
(goto排除原理主義者はこれを認めない。)

159:デフォルトの名無しさん
06/08/28 03:26:26
別に下手でも何でもないような。
まあ、行数多い中でやってるなら、分けろよとは思うかもしれないけど。

goto排他原理主義者って、なんであんなに頑ななんだろうね。
どう見ても使った方がいいだろって状況でも
grepかけて突きつけてきたりするもんなー。

多重ループん中から抜ける時とか、同じ条件のifだだ並べにしてる方が
三億倍はキモいと思うんだが、何がそこまで彼らの憎しみを駆り立てるのか。

160:デフォルトの名無しさん
06/08/28 04:27:43
なんでも極端にやるのはダメだよねぇ…
以前“短い関数”原理主義者を見かけたよ。
3行関数を大量生産したらかえって読みにくい。

161:デフォルトの名無しさん
06/08/28 05:52:50
C言語ならありかもしれないな。

C++では例外やアルゴリズムやオーバーロードがあるから
gotoは完全にいらない子だけどね。

162:デフォルトの名無しさん
06/08/28 06:42:02
アルゴリズムもオーバーロードも関係ないと思われ。
例外は確かにあるが、多重ループから抜けるのなんかに使ってたら、それこそヘタなコードだろ。
場合によっちゃJavaでだってバカにされるわ。

C++の例外は、そもそもデストラクション絡みの負荷がデカすぎて
使用を呑めない場合すらあるしなー。
Cで許されるのと同程度の使い方なら、C++で使ってたって何の問題もないと思うんだが。

163:デフォルトの名無しさん
06/08/28 07:09:16
アルゴリズム類の適用で多重ループ自体の出番を減らせられるのは分かるが、
なんでもかんでもそれで書いてたら、それはそれで馬鹿なコードだな

case文のラベル名指しで飛んでるようなコードは流石に有害指定してもいいとは思うが、
ぱっと見すぐわかる範囲で簡潔に使われてる程度で目くじら立てるのは…

164:デフォルトの名無しさん
06/08/28 13:10:51
よくあるのは、
:
:
return TRUE;
/* ↑ここまで正常系処理 */
error:
if (hoge) { hogeのリソースを解放; }
if (fuga) { fugaのリソースを解放; }
return ERROR;

みたいなやつ。hoge/fuga/...は一連の処理の最初にNULLで初期化しておく。

途中で処理が失敗したとき、どのリソースが割り当てずみかを気にせず、
末尾に飛べばいい。

165:デフォルトの名無しさん
06/08/28 13:11:41
TRUE/ERRORってのは変な組み合わせだな。てきとーに読み替えplz

166:デフォルトの名無しさん
06/08/28 14:16:05
>C++では例外やアルゴリズムやオーバーロードがあるから
なぜここにアルゴリズムが混じりますか??

167:デフォルトの名無しさん
06/08/28 14:35:00
>>160
> 以前“短い関数”原理主義者を見かけたよ。

Kent Beckのことですね。

168:デフォルトの名無しさん
06/08/28 14:47:44
>>164

正常系のリソース解放を一緒にすると下のようになるんだろうが、なんか微妙
なようなそうでないような。

result = SUCCESS;
goto end;
/* ↑ここまで正常系処理 */
error:
result = FAILURE;

end:
if (...)
if (...)
return result;

169:デフォルトの名無しさん
06/08/28 20:30:04
>>162
なんでそんな例外を忌み嫌うのかよくわからん。

頭固いんじゃないの?

170:デフォルトの名無しさん
06/08/28 23:10:24
>>162
> C++の例外は、そもそもデストラクション絡みの負荷がデカすぎて
必要なことをしているだけじゃないの?
例外を使わなくたって、デストラクタを呼ぶ必要がなくなるわけじゃないでしょ?

正常系の場合に(結果的に)無駄となることをする場合もあるけど、
例外を使うことによるメリットを考えれば普通は我慢できるはずだけど。


171:デフォルトの名無しさん
06/08/28 23:10:48
>>169
え?多重ループから抜け出すのに例外使うの?

下手だなー。

172:デフォルトの名無しさん
06/08/28 23:54:37
>>170
C++の例外処理は相当重たい処理だよ。
だからこそ例外を使わないというコンパイルオプションがあるくらいなのに。

173:デフォルトの名無しさん
06/08/29 00:26:04
>>168
頻出なイディオムなのに簡潔に書けないもんだから
C++やその他の言語で try-catch が生まれたって流れなんでしょうね。
たまに C++ で書く時は finally 使えなくてムズムズする。
きちんとデストラクタ書けって話なんだけど。

174:デフォルトの名無しさん
06/08/29 01:03:40
>>167
Kent Beckに限らず、Smalltalkerはn行を超えるメソッド(関数)が
ポコポコ出来るなんて信じられない、という発言を真顔でするね。

175:デフォルトの名無しさん
06/08/29 03:48:20
多重ループじゃなくてイテレーションなら一発で抜けられるのにな

176:デフォルトの名無しさん
06/08/29 04:57:44
goto信者が暴れていたようだな。
そんなに早さを求めたいのならC++なんて使うな。

177:デフォルトの名無しさん
06/08/29 05:05:42
C++ではデストラクタ以外にリソース解放コードを書いてはいけない
よってgotoはいらない
逆にスコープアウト時の処理が書けないレガシーな言語には必要。
Javaはgotoがないのでご覧のとおり悲惨なことになっている

178:デフォルトの名無しさん
06/08/29 08:51:11
ループを脱けるために例外を使うなんて、意味論的にも変だっつーの。

ところで、
LABEL:
 for(~) {
  for(~) {
   if (~) break LABEL;
  }
 }

で、外側のforまで一気に break してくれる構文のある言語があったような木がするんだけど、なんだっけ?


179:デフォルトの名無しさん
06/08/29 10:01:15
ラベル付きbreakはJavaにはあるな。C♯は goto ラベルか。
Perlだとbreakじゃなくてlastだが、これもラベルがつけられる。

Rubyだと
catch(:identifier) do
throw :identifier
end
と書く。 # これは例外処理ではない。

180:デフォルトの名無しさん
06/08/29 10:02:43
D言語の言語仕様にはあったが実際どう動くかわからない

181:デフォルトの名無しさん
06/08/29 17:12:25
>>177
関数内のある処理のために確保した一時メモリ領域とかもデストラクタで解放するの?
C♯のfinally構文に慣れたせいかいまいち理解できない。
具体的にどう書くの?



182:デフォルトの名無しさん
06/08/29 18:00:12
>>181
つ std::auto_ptr
auto_ptrは腐ってるという意見もあるようだが。

183:デフォルトの名無しさん
06/08/29 18:10:39
phpは break n; でn段のネストから抜ける

184:デフォルトの名無しさん
06/08/29 18:20:49
「n段」ってのがPHPらしい仕様だよな

185:デフォルトの名無しさん
06/08/29 18:44:12
>>182
ほへー。
それを徹底するくらいなら例外かgotoで終了処理したほうがよほどスマートだと思うんだけどな・・・

186:デフォルトの名無しさん
06/08/29 19:48:14
>>182
auto_ptrはauto変数としてのみ使うもんだと思ってる。
移動コピーはcreate関数なんかに効率を落とさず対応するためのもので、
基本的にはコピーしない、と。

>>185
struct file {
FILE *f;
file(const char *path) { f = fopen(path, "r+"); }
~file() { fclose(f); }
};
int main()
{
file f("foo.txt");
// 何かする

} // close

187:デフォルトの名無しさん
06/08/30 01:08:06
標準では未だにauto_arrayって入ってないんだっけ。
いや、自分で書いても一瞬だけどさ…。

188:デフォルトの名無しさん
06/08/30 11:14:53
>>181
つ[More Effective C++]

189:デフォルトの名無しさん
06/08/30 21:01:50
>>181
C#使いなら、System.IDispose.Disposeに書くようなことをC++ではデストラクタに書くと言えば通じるだろうか。
ただしusingに相当するものはなく、自動変数ならスコープを抜けるときに呼ばれるという感じ。

190:デフォルトの名無しさん
06/08/30 21:03:20
すまん、IDisposableだったな。

>>186
auto_ptrを自動変数として使うだけなら、scoped_ptrでいいだろと思う俺。
今はまだBoostだから使用に抵抗を感じるのかもしれないけどね。

191:デフォルトの名無しさん
06/08/30 22:13:15
boost馬鹿は死んでいいよ

192:デフォルトの名無しさん
06/08/30 23:53:53
おまいが死んだら一番じゃん

193:デフォルトの名無しさん
06/08/31 00:30:09
try{

}
catch(Exception e){
 if(e instanceof HogeException){...}
}

もうね、アホカと。馬鹿かと。

194:デフォルトの名無しさん
06/08/31 00:36:44
・飛んでくる例外の共通の親はException。
・各例外を捕まえたときの処理は同じだが結構分量アリ。
・捕まえずに上にそのまま通す例外もある
みたいな条件が重なったときは結構困るな。

195:デフォルトの名無しさん
06/08/31 00:42:10
どういう場合にそういう状況に陥る?
設計しなおすと結構シンプルになったりしそうなんだが。

196:デフォルトの名無しさん
06/08/31 00:45:16
・飛んでくる例外の共通の親はException。 →当たり前。
・各例外を捕まえたときの処理は同じだが結構分量アリ。 →メソッド化しろボケ。
・捕まえずに上にそのまま通す例外もある →catchしてthrowするか、何もするな。

どこがどう困るんじゃと。

197:デフォルトの名無しさん
06/08/31 00:48:57
>>196
こいつ下手そう

198:デフォルトの名無しさん
06/08/31 01:05:51
そうでもないよ

199:デフォルトの名無しさん
06/08/31 01:12:26
>>197
こう書いたらエエヤンっていってるだけなんだけど、だめ?

void exampleFunction()throws BarException{
 try{
  //FooException,BarException,BazExceptionが発生する可能性あり
 }
 catch(FooException e1){
  handleException();
 }
 catch(BarException e2){
  throw e2;
 }
 catch(BazException e3){
  handleException();
 }
}

200:デフォルトの名無しさん
06/08/31 01:24:53
>>196
Exceptionまでさかのぼらないと共通の親クラスが見つからない、
だから、まとめて捕まえるならExceptionで捕まえるか、
別々に書くかしないといけない、ということだね。

201:181
06/08/31 05:10:40
>>189
いや、C++も昔やってたからその辺のことはわかってるよ。
ただ一時メモリ領域もデストラクタで解放するっていうことに違和感を覚えただけ。


202:デフォルトの名無しさん
06/08/31 10:34:47
BarException をcatchする意味がないじゃん。

handleException() は、handleException(e1) とかで多胎にするよーな?

203:デフォルトの名無しさん
06/08/31 13:59:45
>>201
>一時メモリ領域
一瞬、スタック領域に取られたメモリの事かとおもた
じゃなかったら一時的かどうかはコンパイラには解らないから

204:181
06/08/31 15:12:31
スタック領域だったらそもそも解放とか気にする必要がないのではw
まあとりあえず自分の話題については>>182で一応の解決を見たのでこれ以上の問答は無用です。


205:デフォルトの名無しさん
06/08/31 21:21:42
例外も仕様の内だと思うんだけど。
なんでtry-catchなんて使うんだろうね。

ifとtryのどっちを使うのか明確にわけてあるプロジェクトにあたったことないな。

206:デフォルトの名無しさん
06/08/31 22:14:56
>>205
こいつ下手そう

207:デフォルトの名無しさん
06/08/31 22:39:56
>>206
おお!trycatchの適切な利用方法を説明してみてくれ。
なんかパっとしねぇの多いんだ。

208:デフォルトの名無しさん
06/08/31 23:30:19
>>202
rethrow する前にログったり BarException 固有の処理するけど
紙面の都合で省かれてるんだと思うことにしよう。

> 多胎
派生例外クラスにありとあらゆるケースの例外処理が書かれて
かえって可読性が下がる気がしなくもない。

209:デフォルトの名無しさん
06/09/01 00:23:55
当然のことだが、例外クラスはそれを使うクラスのことは知らない。
まさか、1クラスにつき1例外作るとか言うんじゃないだろうな。

210:デフォルトの名無しさん
06/09/01 00:34:41
そう。だから例外処理で多態は困難に感じる。

211:デフォルトの名無しさん
06/09/01 00:40:22
ここで「こいつ下手そう」発言君↓

212:デフォルトの名無しさん
06/09/01 00:42:04
>>211
こいつ下手そう

213:デフォルトの名無しさん
06/09/01 00:45:06
>>207
try {
resA->open(); // res: resource
resB->open();
resA->hoge();
resB->fuga();
resB->close();
resA->close();
}
catch () {
}

214:デフォルトの名無しさん
06/09/01 00:48:58
んなーこたーない

215:213
06/09/01 00:52:06
>>214
ん、俺?
俺いつもこうやってるよ。俺下手なのか?

216:デフォルトの名無しさん
06/09/01 00:52:40
ここでもやっぱり「こいつ下手そう」発言君↓

217:デフォルトの名無しさん
06/09/01 00:53:34
どう考えても213はおかしいだろ

218:デフォルトの名無しさん
06/09/01 00:53:42
>>213
見るからに例外安全じゃないコードだな。
close前に例外飛んだらout

もしRAIIだから大丈夫だとしたら逆にcloseを明示的に書いているのがダサい。

219:213
06/09/01 00:54:12
>>217
どこが?

220:213
06/09/01 00:55:14
>>218
あー、俺やっぱり下手だわ。
意味さっぱりわかんね。

221:デフォルトの名無しさん
06/09/01 00:56:35
>>218
エラーコードでいちいちエラーチェックするより、例外使ったほうがいいという例じゃないの?

222:デフォルトの名無しさん
06/09/01 01:00:20
>208-210
派生例外クラスじゃなくて、handleException を多態にするという意味では?

void handleException ( Exception& e ); // 共通の処理
void handleException ( BarException& e ); // BarExceptionだけの処理

try{
 //FooException,BarException,BazExceptionが発生する可能性あり
}
catch( Exception e ){
 handleException( e );
}

223:デフォルトの名無しさん
06/09/01 01:07:01
>>221
エラーチェックの話なら,
例外版は適切にRAIIとかfinally相当でリソースの後始末をするべき。
これだと例外を使うとリソースをリークするという話にしか見えん。

まともに例外を扱えないやつが例外を書くと危険極まりない。
下手糞の例外は下手糞のgotoよりはるかに凶悪

224:デフォルトの名無しさん
06/09/01 01:07:31
>>220-221
resA の open に成功して、resB の open に成功した場合、
resA のリソースが開放されないので例外安全にならない。
スコープ抜けたら勝手に開放される(RAII)のであれば
わざわざ close 呼んでるのが冗長。

225:デフォルトの名無しさん
06/09/01 01:11:43
>下手糞の例外は下手糞のgotoよりはるかに凶悪

まったくもってごもっとも。
つーか正直なところどんだけやってもC++の例外を使いこなす自信が持てん。

226:デフォルトの名無しさん
06/09/01 01:11:45
>>224
たぶん主張内容から推察するに
× resBのopenに成功
○ resBのopenに失敗
だな。
主張内容は完全に同意。

227:デフォルトの名無しさん
06/09/01 01:16:58
>>222
実際にやってみたか?引数のオーバロードは多態ではないから
e が BarException でも共通の処理のほうに飛ぶんだが。

228:デフォルトの名無しさん
06/09/01 01:17:16
>>222
オブジェクト自身が振る舞いを知ってる場合が多態で
入り口(呼び出し側)でオーバーロード用意して
振り分けしちゃうのは多態とは言わないと思ってました。
実際のところどうなんでしょう?

>>226
ご指摘の通り。しかも223氏が本質的な発言先にしちゃってるし。
もう俺寝た方が良さそう。

229:デフォルトの名無しさん
06/09/01 01:23:53
>>228
お休み、よい夢をー。

230:213
06/09/01 03:26:07
あー、それは当然catch内でやる。213はtry{}の例。

231:デフォルトの名無しさん
06/09/01 03:41:27
catch内でリソースの開放処理をするのも上手くない。
その時点でcloseなどの解体処理が正常時と異常時の二箇所に分散するということが確定するから。
エラー処理を一箇所でやるための例外でその処理が分散したら本末転倒。
そんなんするならgotoでエラー処理するほうが開放処理が一箇所にまとまる分マシとさえ言える。

結局資源開放するならC++ならRAIIが定石(他言語ならfinally)

232:231
06/09/01 03:54:18
あと、resB->open()時に発生した例外と
hoge(),huga()で発生した例外で開放するリソースが変わるからさらに面倒だな。
open時だとresAのみ、それ以外だとresA,resBを開放する必要がある。
こんなのを手動で開放処理書いてたら俺は間違いなくどこかでミスる自信がある。

233:デフォルトの名無しさん
06/09/01 03:58:32
> 間違いなくどこかでミスる自信がある
うん、間違いなくミスってるよw
resA->open()時に例外が発生する事象を見逃してる。
このケースだと資源の解放はいらない。

234:231
06/09/01 04:02:32
うへぇ、本当だ。やっぱりミスってたかー...
うーん、こういう解体処理はRAIIに任せなきゃ駄目だなマジで

235:デフォルトの名無しさん
06/09/01 04:03:46
つまり例外は使うなってことでFA?

236:デフォルトの名無しさん
06/09/01 04:05:09
>>231
例外が有効な例を教えてくれ

237:デフォルトの名無しさん
06/09/01 04:07:57
こっちで。

例外処理
スレリンク(tech板)

238:231
06/09/01 04:12:41
>>236 >>213のケースをRAIIで書くと有効な例になるんじゃね?
try {
    Resource resA(a->getResource());
    Resource resB(b->getResource()); 
    resA->hoge();
    resB->fuga();
}catch(){
  /* エラー処理を記述 */
}

どこにも開放処理はいらないし俺がミスる心配もない

239:デフォルトの名無しさん
06/09/01 06:58:19
ミスる心配が無いって気分いいよな

240:デフォルトの名無しさん
06/09/01 07:11:51
>>238
それだと、resA, resBに特化したエラー処理が書けないよ

241:デフォルトの名無しさん
06/09/01 07:57:56
COMでIDispatchとか使わされる状態だと例外ないとやってらんね

242:デフォルトの名無しさん
06/09/01 08:53:43
エラー処理は ResA.hoge()、ResB.hoge() の返り値を
switch-case なり if なりで判定して行う。
エラー処理と例外処理は別のものだよ。

243:デフォルトの名無しさん
06/09/01 10:41:22
>227
まぁ、>222のとおりだとそうなるけど。

catch(BarException e) を同様に作ってやればいいだけの話。

try{
 //throws FooException,BarException,BazException
}
catch( BarException be ){
 handleException( be );
}
catch( Exception e ){
 handleException( e );
}


244:デフォルトの名無しさん
06/09/01 11:37:27
以降、例外関連はこっちで。

例外処理
スレリンク(tech板)

245:デフォルトの名無しさん
06/09/01 13:07:27
これJavaの話?

246:デフォルトの名無しさん
06/09/01 22:39:05
>>240
try {
  Resource resA(a->getResource());
  Resource resB(b->getResource());
  try {
    resA->hoge();
  } catch(){
    // resA に特化したエラー処理
    // 処理を途中で止めるなら throw
  }
  try {
    resB->fuga();
  } catch(){
    // resB に特化したエラー処理
  }
}catch(){
/* エラー処理を記述 */
}

>>242
> エラー処理と例外処理は別のものだよ。

はぁ?

247:デフォルトの名無しさん
06/09/01 23:11:38
はぁ?

248:デフォルトの名無しさん
06/09/02 01:35:16
エラー処理と例外処理は別のものだろ。
それは間違いない。例外=エラーじゃない。
ファイルストリームの中でバッファ溢れを検知して例外投げて
捕まえた奴がフラッシュしてバッファ空にして処理続行、
別に変わった使い方じゃないし、どこにもエラーは無い。

249:デフォルトの名無しさん
06/09/02 05:35:40
はじめてtry-cacheがあって本当に良かったと思ったのはつい最近。
javascriptでregexpを評価する時に
食わせる正規表現が不完全な時に出るエラーメッセージをcacheして潰した時。

つーのも、無計画に追加していった自分用リンク集がいい加減肥大化して
目的のもの見つけるのが面倒くさくなってきたんで
regexpインクリメンタルサーチを搭載してみたんだけど
入力途中の、正しい正規表現かどうかかわからん文字列を
本当に正規表現として正しいのかどうか調べてから食わせるより
とりあえず食わせてみた後にエラー潰したほうが遥かに楽だったという話

250:デフォルトの名無しさん
06/09/02 06:39:17
>>249敢えて何も言うまい(´・ω・`)

251:デフォルトの名無しさん
06/09/02 10:38:15
>>249
2回間違えるあたり単なるスペルミスではなさそうだな。

252:デフォルトの名無しさん
06/09/02 12:53:01
キャッシュ?

253:デフォルトの名無しさん
06/09/02 13:26:45
「おまえらのコードは俺が理解できないから汚い。俺のコードは俺が理解しやすいから美しい。」
もう結論出てますよ。いつまで無意味な論争やっているんですか?

254:デフォルトの名無しさん
06/09/02 14:18:02
>ぱっと見て「ヘタだなぁ」と思うコード
>>248

255:デフォルトの名無しさん
06/09/02 14:50:25
>>249
正しい正規表現かどうか調べるのと
正規表現をビルドしてみるのとコスト変わらないのかな

文字列が正しい正規表現かどうか調べるメソッドが存在する処理系ってある?


256:デフォルトの名無しさん
06/09/02 17:16:03
正規表現オブジェクト内部で
処理する前に正しいかどうか調べてんじゃない?
バッファオーバーフローとかしたら致命的だし
ホットなループ内でエラーチェックするのはコストが高すぎる

257:デフォルトの名無しさん
06/09/02 20:33:26
ふつーの正規表現ライブラリなら構文食わせた段階でコンパイルされる。

まあたとえば空文字列にマッチしてしまうような正規表現はエラーではないが、
そういう用途には向いていないので実際のデータを食わせる前に判定した方がいいけどな

258:デフォルトの名無しさん
06/09/02 20:46:47
> 文字列が正しい正規表現かどうか調べるメソッドが存在する処理系ってある?

文字列が正規表現として正しいかを判定する正規表現を書けばいいんじゃないか?

259:デフォルトの名無しさん
06/09/02 21:40:27
正規表現ライブラリ内でパターンをコンパイルする時に
構文解析やってるはずなのに
その結果を返すメソッドが用意されてないからって
わざわざ自作するのは人間のコストが高すぎる。
とりあえずコンパイルして例外キャッチしてで十分に思う。
使用できる表現を限定する必要があるなら
頑張って自作するっきゃないだろうけど。

260:デフォルトの名無しさん
06/09/03 01:23:00
>>249が「例外があって良かった」の例になっていない件について

は、もう突っ込み入ってるのか

261:デフォルトの名無しさん
06/09/03 01:34:44
例外が便利なのは
・複雑なエラー状態を統一的に扱える
・複雑な呼び出し構造や一時変数の破棄をを自動的に処理できる
の2点なんだけど、
後者はデストラクタがきっちり定義された型の変数だけでコードを書いてないとあまり意味がない。
前者は誰がどう見ても便利。固定した構文があるだけでもぜんぜん違う。


まあ今時の言語なら実行時エラーを捕獲する機構は必須だわな。
プログラムが自分や他のモジュールについてのメタ情報を扱うのが最近の流行だ。

262:デフォルトの名無しさん
06/09/03 02:41:23
javascript のクロスブラウザ対応コードとかだと
最初にバージョン等で依存するメソッドなりプロパティなり参照させて
そいつをcatchして「これはECMA1.1だ。あっちはJScriptだな」
とかやっててため息が出る。
コード書いた奴のせいではないけど。

263:デフォルトの名無しさん
06/09/03 03:30:47
それは確かに
(スクリプトホストの実装が)ヘタだなぁ

264:デフォルトの名無しさん
06/09/03 08:59:17
>>261
> 例外が便利なのは

・正常系の処理が素直に書ける

ことに尽きると思う。

例外がないと、エラーチェックだらけで処理が追いにくい。

>>262
ため息をつくほどのことか? >>261 が言うように処理系がメタ情報を
提供するのが最近の流行だろうけど、ちょっと古い実装系だと提供す
る関数自体が未実装だったりするので過渡期のテクとしてはやむをえ
ないと思うよ。

265:デフォルトの名無しさん
06/09/03 09:08:29
>>264
それってメリットかなぁ・・・
俺はエラーの分岐もプログラムのうちだと思うけど。
そもそも正常系とわける意味がわからない。
エラー処理だって仕様の一部だよ。
あるべき場所になくて実は例外で飛んでるってのはかなり追いにくい。

266:デフォルトの名無しさん
06/09/03 10:11:14
>>265
それじゃ、試しにログ出力関数を作ってみてくれ。
仕様としては、指定された名前のファイルがあれば追記でなければ新規作成。
行の内容はタイムスタンプと指定された文字列。文字列中の非可読文字は適切に処理するってことで。
それを例外を使わずに書いたものと使って書いたものを用意すれば、
どっちが読みやすい(「追いやすい」か)とか議論もできるだろう。

267:デフォルトの名無しさん
06/09/03 10:40:55
>>266
>仕様としては、指定された名前のファイルがあれば追記でなければ新規作成。
>行の内容はタイムスタンプと指定された文字列。文字列中の非可読文字は適切に処理するってことで。
っていう関数(例えばwriteLog関数)を作って

re = hoge.init();
if(re != S_OK){
  writeLog("初期化失敗");
  return; //処理によってreturnするもよし、続行するもよし
}

re = hogest.init();
if(re != S_OK){
  writeLog("オプション無し");
}

って話じゃないの?
別に関数の中で色々とやることにメリットを感じないんだけど?
だってエラーがでた箇所みつけにくいじゃん。

ところで
>指定された名前のファイルがあれば追記でなければ新規作成
これってfopenを'a'で開くだけじゃんw

お前が何をいわんとするのかさっぱりわからない。

268:デフォルトの名無しさん
06/09/03 10:41:28
俺もため息が出るよ。
醜くてもやむをえずそれを書いた人の心中察するあまり…

269:デフォルトの名無しさん
06/09/03 10:48:59
で、>>267

try{

  hoge.init();
  hogest.init();
  ・
  ・
  ・
}

って書くと

catch()
catch()
catch()




って書かなきゃいけないじゃん。
俺、これをやるぐらいなら>>267のほうが100倍ぐらいいいと思うんだけど。
エラーが起きたらエラーが起きたその箇所にその内容が書いてあるほうがいいと思うんだけどなぁ。

270:デフォルトの名無しさん
06/09/03 11:21:30
>>267
>これってfopenを'a'で開くだけじゃんw
あ、いけね、「新規作成して1行ファイル内容を出力」の肝腎な後半を忘れてた。

で、漏れはそのwriteLog()相当の中身の話をしたかったんだがなぁ。
それはさておき、>269のcatch()の連続は何?

271:デフォルトの名無しさん
06/09/03 11:24:21
C++でinitというメンバ関数名を見るたびに嫌気が差す。
コンストラクタでええやん。

コンストラクタがあるのに何がかなしゅうて一々ケッタイな初期化せにゃあかんねん。

>>270
たぶん、例外要因全部別々にcatchしてる例外初心者でしょ。
俺ならstd::exception.whatで終わらせるけど。

272:デフォルトの名無しさん
06/09/03 11:35:26
>>270
>あ、いけね、「新規作成して1行ファイル内容を出力」の肝腎な後半を忘れてた。
日本語でおk

>で、漏れはそのwriteLog()相当の中身の話をしたかったんだがなぁ。
こんなのtrycatchに関係あるの?わからない。

>>271
>C++でinitというメンバ関数名を見るたびに嫌気が差す。
だってMFCからいってコンストラクタじゃウィンドウできてねーし。
継承して作ったら何もしようが無い。

>std::exception.what
なにそれ?資料少なすぎてマイナーなんじゃね?
なんかよくなるの?
基本的に処理とエラー内容はできるだけ離したくないんだけど?
俺のニーズにはあってるのかな?

273:デフォルトの名無しさん
06/09/03 11:39:47
>>272
標準ライブラリをマイナーと言われても困る。
>>270
俺は例外信者だけどこれ位の規模だと例外非使用でも大差ないと思う。
マルチバイト文字とかその辺まで凝るとまた話が違うかも知れんけど。
void writeLog(const char*filename,const char*logmsg){
    char buf[64],c;
    FILE*fp = fopen(filename,"a");
    if(fp){
        time_t tm = time(NULL);
        strftime(buf,64,"%H:%M:%S | ",localtime(&tm));
        fputs(buf,fp);
        while((c=*logmsg++)!='\0')
            fputc(isprint(c)?c:'.',fp);
        fputc('\n',fp);
        fclose(fp);
    }
}

274:デフォルトの名無しさん
06/09/03 11:41:23
>>273
だって全然検索ヒットしないよ。
入れてみたものの誰も使ってないんじゃない?
C言語のunionみたいさ。

275:デフォルトの名無しさん
06/09/03 11:43:14
>>271
コンストラクタでエラーが起きたときに
それを通知するには例外を使うのが普通だろうけど
そのリソースに代替物があって、初期化の失敗が
致命的なエラーにならないときには
例外ではなく戻り値で通知して欲しい、とか

まあ、オブジェクトが正常かどうかを
問い合わせる関数を追加すればいいのだろうけど。

276:デフォルトの名無しさん
06/09/03 11:46:23
URLリンク(www.google.co.jp)
std exception what の検索結果 約 4,800,000 件中 1 - 10 件目 (0.15 秒)

277:デフォルトの名無しさん
06/09/03 11:53:22
>>274
Cでunion使わないってありえねー。
C++だと継承でほぼ代用できるから利用価値が低下するけど。
>>275
その場合なら自分も例外処理にするよりも普通は成否を返すでしょうね。
C++のiostreamもそのパターンの場合は例外を投げないですしね。
例外を使う場合はむしろメモリ不足とかの代替とか無理な状況に使うほうが多いですし。

278:デフォルトの名無しさん
06/09/03 11:53:56
>>276
おお、検索の仕方が悪かっただけか。すまん。
でも、やっぱり、

catch()
catch()
catch()

って書くみたいなんだけど?

279:デフォルトの名無しさん
06/09/03 11:58:19
>>273
fputs(), fputc(), fclose()のエラー処理も入れてくれ。

>>272
「新規作成して1行目にファイル内容の概略を出力」でいい?
要は、ファイル名がerror.logなら"; error.log"と書いておくとかそんな感じで。
#この件は説明不足が続いて失礼。

>>276
それは余りに無意味な検索の仕方だ。3つの単語を別々に検索してしまうジャマイカ。

280:デフォルトの名無しさん
06/09/03 12:04:37
>>278
int main()
{
    try
    {
        // ...
    }
    catch(const std::exception& e)
    {
        std::cerr << e.what() << std::endl;
        return 1;
    }
}
そしてこのほかには殆ど完全にと言ってよいほどtry/catchが出てこないプログラム。

281:デフォルトの名無しさん
06/09/03 12:11:00
というか例外って使いこなせば使いこなすほど
try catchをほとんど書かなくなるんだよな(C++では)

282:デフォルトの名無しさん
06/09/03 12:14:00
処理を中断してログ吐いて終了するくらいしか手がないときにしか
例外って使わないしねぇ…

283:デフォルトの名無しさん
06/09/03 12:39:58
非チェック例外以外にチェック例外も用意したJavaですら
最近は「例外は基本的に実行時例外だけにしとけ。
どうにもならんような状態を知らせるか、
プログラミングミスを検出する目的で使え。」な流れだよね。

284:デフォルトの名無しさん
06/09/03 12:45:01
>>277
> Cでunion使わないってありえねー。
> C++だと継承でほぼ代用できるから利用価値が低下するけど。

kwsk

285:デフォルトの名無しさん
06/09/03 13:30:24
プログラムにバグがあるときでも何とかごまかすために使ってる>>例外

286:デフォルトの名無しさん
06/09/03 15:03:27
継承で利用価値が低下するってのは、俺にもよくわからんな。
struct RGBA
{
union
{
struct
{
unsigned char r, g, b, a;
};
unsigned char rgba[4];
};

みたいなのを、
class RGBA
{
unsigned int rgba;
public:
void set(unsigned char r, unsigned char g, unsigned char b, unsigned char a);
void set(unsigned int rgba);

}

みたいに書くからって話かな?

287:デフォルトの名無しさん
06/09/03 15:13:10
union と継承の関係もよくわからんが、
>>296 のプログラムと継承の関係はもっとよくわからん。

288:デフォルトの名無しさん
06/09/03 15:23:20
>>287
・>286のclass RGBAはunionを使っていない。
・struct RGBAを含む構造体は内包で実現することになるが、
class RGBAを含む構造体は継承で実現できる。
#が、意味は微妙。

289:デフォルトの名無しさん
06/09/03 15:42:01
277がC++だと継承で代用できるといったのはこういう例だと思う。
struct Hoge
{
    enum type_t {Foo, Bar, Piyo} type;
    union
    {
        struct foo_t {/* ... */} foo;
        struct bar_t {/* ... */} bar;
        struct piyo_t {/* ... */} piyo;
    };
};
typeによってunionのどのメンバにアクセスできるかが決まるというもの。

290:デフォルトの名無しさん
06/09/03 19:02:36
そんなもんCでもできるし、継承関係ないけど…。

ひょっとして釣り?

291:デフォルトの名無しさん
06/09/03 19:24:48
いや、289のようにCでは共用体でやっていたのを、C++では継承で代用…ってことなんではないかと。
自分の勘違いだったら申し訳ないが、自分は290の読解力こそ疑うが…。

292:デフォルトの名無しさん
06/09/03 19:29:06
>>290
ここまで説明せにゃならんのか。
void HogeHoge(Hoge* hoge)
{
    switch (hoge->type)
    {
    case Foo: /* fooの処理 */ break;
    case Bar: /* barの処理 */ break;
    case Piyo: /* piyoの処理 */ break;
    }
}
これをOOP風にすると、継承を使いunionを使わないようにすることができる。
class Hoge
{
    virtual void HogeHoge() = 0;
};

class Foo : public Hoge
{
    virtual void HogeHoge() {/* fooの処理 */}
};
//Bar, Piyoも同じ

293:デフォルトの名無しさん
06/09/03 19:50:11
union ってあるビットの塊をいろんなものに解釈するためにあると思うんだが。

Foo, Bar, Piyo が union だった場合、それぞれを Foo は Bar にも Piyo にも見えるけど、
Foo, Bar, Piyo が Hoge の派生だった時に、 Foo を Bar に見ることって無理っぽいんですが。

294:デフォルトの名無しさん
06/09/03 19:51:11
やっぱりUnionと関係ない気がするな。

295:デフォルトの名無しさん
06/09/03 19:57:45
共用体だからって、別のものに解釈させて使わなきゃならないってことはないんで、
292の例は別解釈をさせずに、統一的に扱うために使ってるんではないかと。
WinAPIのSendInputで使うINPUT構造体なんかも292の例と同じ使い方だね。

296:デフォルトの名無しさん
06/09/03 19:57:59
>>293
289/292では、typeに指示された型以外で共用体のメンバにアクセスしてはいけないという仕様。
FooをBarとして見るなどといったことはできない。

Cでは、こういうunionの使い方をされることも全くないわけではない。

297:デフォルトの名無しさん
06/09/03 20:20:49
あるunionの使い方についてはC++の継承で表現できる、なら納得。

298:デフォルトの名無しさん
06/09/03 21:32:28
>>292
なんかすげーヘタな設計を見た気がする...。

> virtual void HogeHoge() {/* fooの処理 */}

とか書いてごまかしてるけど、

union {
 char a;
 int b;
 float c;
} x;

に相当するもの書いてみ。自分がどんな変な設計してるかわかるから。

>>293
ビットレベルの別解釈と、メモリの節約 (=同一の領域をいろんな意味で使う) だろ。

>>295
それは、単にタグをつけてるだけの話。

継承とはまったく関係がない。

299:デフォルトの名無しさん
06/09/03 21:45:52
たとえば、Cでパーサを書くときって、Tokenをunionで実装したりしない?
union Token {
int keyword;
char *identifier;
int intValue;
double doubleValue;
};
これを、C++で書いたら、Tokenクラスを継承して、KeywordTokenとか、NumberTokenとかを
作成するような実装もありうると思うけど。


300:デフォルトの名無しさん
06/09/03 22:16:19
>>299
なるほど、すまんちょっと勘違いしてた >>292

class Base {};

class Char: Base { char a; };
class Int: Base { int b; };
class Float: Base { float c; }

みたいなイメージやね。

まあ、>>297 が正しいと思う。

301:デフォルトの名無しさん
06/09/04 08:31:25
unionでセットしたメンバ変数以外のメンバ変数として解釈するのはANSI-C的にはNG
複数のビット表現として解釈する使い方が~とかほざくやつは完全に標準違反。

302:デフォルトの名無しさん
06/09/04 14:56:30
だが、それを承知した上で使えば中々便利。

303:デフォルトの名無しさん
06/09/05 02:16:44
ついに1000体突破かよ
アイロボットみたいだな
株ロボもいつか夢を見るようになるのかなぁ

304:デフォルトの名無しさん
06/09/05 03:33:50
>ANSI-C的にはNG
実装依存じゃなかったか?

305:デフォルトの名無しさん
06/09/05 03:56:05
故にNGなんだろなー。
あまりにも典型的すぎるんで、使ってるから下手だとか言う気には到底なれんが。

306:デフォルトの名無しさん
06/09/23 20:57:55
なあおまえら聞いてください。

 #define MINUS_1  -1

これは明らかにうんこたれだ。
んがしかし

 #define MINUS_1  FunnyVariant(L"-1", FV_LONG)

これはおkだよな?

(つД`) つーかもう俺泣きてぇ。
この FunnyVariant をはじめ、DB操作もお金の計算も日付計算も専用のライブラリが用意されてて
↑あんな感じで FunnyVariant クラスに *文字列を* 入れて、数値を生成しなきゃならん。
こうやって、東日本全体を覆うアレのシステムは構築されてんだぜ。。。

307:デフォルトの名無しさん
06/09/23 21:09:20
>>306
>この FunnyVariant をはじめ、DB操作もお金の計算も日付計算も専用のライブラリが用意されてて
超巨大プロジェクトは、そうするのが普通。

308:デフォルトの名無しさん
06/09/24 02:45:21
アカデミックバカ世にはばかる、みたいな。

309:デフォルトの名無しさん
06/09/24 21:27:18
>>307
突込みどころはそこじゃないんじゃないか

310:デフォルトの名無しさん
06/09/24 22:46:23
これって、
FunnyVariant *anyval = new MINUS_1;
って感じで使うの?

311:デフォルトの名無しさん
06/09/25 00:28:37
一時オブジェクトで使うのが一般的なんだと思う。

312:デフォルトの名無しさん
06/09/25 23:10:55
>311
うん、そういう事。

 FunnyVariant yesterday = Calendar::addDay(today, MINUS_1);

みたいな感じでね。

>307
うんまあ、専用ライブラリが存在する事は、悪くはない事だと思う。
アルゴリズムに責任が持てるのは、いい事だよね。
っていうか、なぜ素直に

 FunnyVariant yesterday = Calendar::addDay(today, -1);

と書かせてくれないのかと(つД`)えーんえーん

313:デフォルトの名無しさん
06/09/25 23:45:47
> FunnyVariant yesterday = Calendar::addDay(today, -1);
このコードキモいな

314:デフォルトの名無しさん
06/09/26 00:18:03
まあ、俺が組んだ箇所は金の計算をunsigned intでやってあるけどね。

315:デフォルトの名無しさん
06/09/26 00:23:54
そもそも"FunnyVariant"ってネーミングがアレだな

316:デフォルトの名無しさん
06/09/26 02:06:22
FunnyVariant はコンテキストによって
整数型になったり通貨型になったり日付型になったりするわけ?
なぜそんなにもバリアントにこだわるんだろう。

317:デフォルトの名無しさん
06/09/26 03:53:49
>>314
是非コードの適用箇所を教えてください。
42億ほど用意して突撃させていただきます。

318:デフォルトの名無しさん
06/09/26 09:04:26
>>317
314の使っている環境ではunsigned intは64bit以上あるのでは?

319:デフォルトの名無しさん
06/09/26 09:53:58
>>316
コンテキストによるんじゃなくて、自分で指定してるじゃん。

320:デフォルトの名無しさん
06/09/26 10:53:01
>>318
そんな夢の無いこと言わないでください…

321:デフォルトの名無しさん
06/09/27 11:28:08
1900京円ほど用意して突撃させていただきます。

322:デフォルトの名無しさん
06/09/27 12:21:49
321が1990京円用意するより先に、
そこでのunsigned intのビット数はもっと増えていそう。

323:デフォルトの名無しさん
06/09/27 12:27:39
じゃあ、私は-1円振り込もっと。

324:デフォルトの名無しさん
06/10/01 01:01:34
【スパイウェア】Yahoo Emulator Part5【堀川水樹】
スレリンク(software板)

Yahoo Emulatorホントは使いたいんだろ?
堀川に嫉妬してるんだろ?白状してご覧よwww
どうみてもYahoo Emulator以上のソフト自分で作れない低能が堀川水樹でチンコ立てるスレです
ありがとうございました

325:デフォルトの名無しさん
06/10/01 01:20:07
>>323
そしたら大金持ちだな。

326:デフォルトの名無しさん
06/10/01 21:59:52
借金として処理されるだけな気がする

327:デフォルトの名無しさん
06/10/03 07:49:06
毎日の金利がオーバーフローし続けたりしてな。

328:デフォルトの名無しさん
06/10/04 00:22:37
sage

329:デフォルトの名無しさん
06/10/04 03:09:51
Sub しょりそのいち(ひきすう As Integer)
For かうんた = 0 to 10000 step 200
For かうんたに = 10000 to 0 step -200
(約300行略)
Next かうんたに
Next かうんた
'(゜β゜)/~~
End Sub



Function しょりそのごじゅうに(ひきすう As Long)
(略)
End Function

↑VisualBasic、コメントを除く処理が約1.5万行
入社初日に渡された、売り上げ集計ソフトの逃げた前任者のソースここまでに約1月
動作不安定、仕様を満たせそうに無い、変数宣言殆ど無し
必要なコメントは無く’(笑)とか’(泣)とか不必要なコメントは沢山ある
しかも標準モジュール-日記.basに上司に対する愚痴が山のように書いてある

もちろん最初からから全部書き直しました
書き直し総所要時間(デバック等を含む)約3日
書き直し後のソース約550行

550行のソースを1.5万行で書けるのはある種才能だと思う

330:デフォルトの名無しさん
06/10/04 08:57:36
あらゆる箇所にコメント書く香具師うぜー
本当に必要なコメントが埋もれてしまうがな

331:デフォルトの名無しさん
06/10/04 11:10:01
>330
居るよな、そういうヤツ。
酷い場合、そういうのがコーディングガイドになってたりするところもあるわなぁ('A`)
お互いにプロなんだから、そんな基本的なコメントいらんから、
てか、空気読めよ、みたいなヤツな。

典型的なのが、

int i=0; //変数iを0で初期化する。

こういうのとか、

exit 0; //リターンコード0を返し、処理を終了する

とかな。


332:デフォルトの名無しさん
06/10/04 11:13:34
print $_->[0],"\n" for sort{ $_->[1] }map{[$_,lc$_]} @ARGV;

おまえらはコレにコメント欲しい?なくても読める?
俺はなくても読めるし無いほうが簡潔だと思うけどどうよ?

333:デフォルトの名無しさん
06/10/04 11:18:02
前後の繋がりもあるから一概には言いにくいが、ぱっと見解りにくいと思われ

334:デフォルトの名無しさん
06/10/04 11:25:34
>>332
コメントがどうこう以前にウンコに見える

335:デフォルトの名無しさん
06/10/04 11:31:06
だめなコメント

print $_->[0],"\n" # 要素の最初のデータを表示
  for          # 要素を順に
   sort{ $a->[1] cmp $b->[1] } # 2番目の要素でソート
   map{[$_,lc$_]}  # 要素を元データとそれを小文字化したペアに変換
   @ARGV;      # コマンドライン引数

正しいコメント

# コマンドライン引数をケース非依存をソートして順に表示
print $_->[0],"\n" for sort{ $a->[1] cmp $b->[1] }map{[$_,lc$_]} @ARGV;

336:デフォルトの名無しさん
06/10/04 11:43:50
# ホルホル
print $_->[0],"\n" for sort{ $_->[1] }map{[$_,lc$_]} @ARGV;

337:デフォルトの名無しさん
06/10/04 11:48:47
>>331
いねーよ、そんな奴w

338:デフォルトの名無しさん
06/10/04 11:51:58
じゃあこれはどうよ?

$r=query($conn,"insert into t1(".join(',',sort keys %d).")values(".join(',',map{db_quote($d{$_})}sort keys %d).")");

339:デフォルトの名無しさん
06/10/04 11:54:32
言語仕様そのものがゴミクズ。

340:デフォルトの名無しさん
06/10/04 11:56:09
>>338
これは無理
こんなの一行で書くんじゃねえよ

341:デフォルトの名無しさん
06/10/04 16:51:43
>>338
ぱっと見、フィールド名と値の順番は大丈夫か、ちょっとどきどきする。

342:デフォルトの名無しさん
06/10/04 18:42:26
変数名もドキュメントの一部

343:デフォルトの名無しさん
06/10/04 23:26:04
変数名だけで何をやるのかが分かる

344:デフォルトの名無しさん
06/10/05 01:13:47
末尾の数字だけが違う以外は同名の関数が複数出てくるコード。

private Hoge createHoge(Fuga fuga){
 // なんか処理
}

private Hoge createHoge2(Fuga fuga){
 // createHoge と殆ど同じ処理
}

以下、createHoge6 あたりまで続く。

無印~6までの使い分け条件・使い分けが必要な理由は
コメントにも仕様書にもどこにも書いてない。

マジックナンバーがそこら中に分散、
一つの関数が300行越えるのはザラ、
等の諸症状も併発する。

345:デフォルトの名無しさん
06/10/05 01:16:02
class名見れば分かるのにメソッドにまでわざわざ長ったらしく書く奴

346:デフォルトの名無しさん
06/10/05 02:58:18
コメント読むとおつむの程度が知れる。

コメント読まれるとおつむの程度が知られてしまう。

だから漏れはコメントを書かない。


これぞ自衛的プログラミングの極意。


347:デフォルトの名無しさん
06/10/05 03:11:14
コード書かなきゃいいんじゃね?

348:デフォルトの名無しさん
06/10/05 07:20:14
それだ!

349:デフォルトの名無しさん
06/10/05 11:18:26
要求だけあって、仕様がない一人案件の場合、
おもむろに作り始めるんだけど、
そういう場合、変数やら関数の意味が
あとからだんだん変わってしまう場合が多いので
あまり真剣に考えても意味がない。
適当にしたほうが良い。

ということを学んだ入社半年目。

350:デフォルトの名無しさん
06/10/05 11:43:32
まーそういう事もままあるが、途中で随時リファクタリングしてる。
IDEが簡単な置き換えしかできないシケたヤツだとダルいけど。

351:デフォルトの名無しさん
06/10/05 11:44:05
>>349
こいつ下手

352:デフォルトの名無しさん
06/10/05 12:19:03
>>349
変数と関数で物事括ってるからマズいんでね?

353:デフォルトの名無しさん
06/10/05 15:17:29
>>349
死刑

354:デフォルトの名無しさん
06/10/07 09:44:47
>>349
意味が変わってきたら、それに応じてリファクタリングかけるべきだな。
いつでも変数の意味は正確な物にしておくほうがベター。
考えても意味がないっていうのは、ちょっと良い考え方ではない。

一人案件でも、仮に趣味のコードでも、このへんは変わらんよ。
数ヶ月後の自分は、今の自分からみたら他人並。
その時に、わかりやすいコードとコメントが意味を持ってくるものだし。
本当に作り捨てで今だけ解ればいいっていうなら、手を抜くのも有りではあるが…
案件なら、作りっぱなしでもう2度とコードみないって訳にもいかなかったりするだろ?
入社半年目なら、今のうちに考え直す方が良いよ。


355:デフォルトの名無しさん
06/10/07 13:02:17
袋叩き

356:デフォルトの名無しさん
06/10/07 14:02:25
変数名考えてる時って、頭の片隅で設計してるんよ。
見通しの悪い設計してるから良い名前が付けられない。

357:デフォルトの名無しさん
06/10/07 14:29:26
あー、プログラムの文脈以外に、識別子に意味もつけられたら便利かもと、唐突におもた

358:デフォルトの名無しさん
06/10/07 16:23:43
boolean型で変数名 flag

これ最強。

359:デフォルトの名無しさん
06/10/07 23:58:23
俺の bool b とどっちが強いかな??

360:デフォルトの名無しさん
06/10/08 00:08:23
5行くらいの関数で使うんならアリだぜ。

20行越えてたら殺す。

361:デフォルトの名無しさん
06/10/08 00:12:51
悪い、40行くらいのコードでも普通に使い倒してる。
二回死んどくから勘弁してくれ。

362:デフォルトの名無しさん
06/10/08 00:31:39
許す。

363:デフォルトの名無しさん
06/10/08 00:54:44
String s = new String();
s = "foobar";

364:デフォルトの名無しさん
06/10/08 00:57:24
void foo() throws Exception { ... }


365:デフォルトの名無しさん
06/10/08 06:28:02
今時、for文でループまわしているのを見たとき

366:デフォルトの名無しさん
06/10/08 07:10:51
>>365 kwsk

367:デフォルトの名無しさん
06/10/08 07:35:18
>>366
eachとかforeach使えってこと。
iteratorでも可
まあ、今時、それらができない言語は時代遅れだと思う

368:デフォルトの名無しさん
06/10/08 07:44:09
階乗の計算をeachやforeachで書ける?

369:デフォルトの名無しさん
06/10/08 08:58:17
>>368
もちろん、書かない。
わざわざ適していない方法で書く必要はない。
そういうときは、適している方法で書く。
例えば、再帰で書く

370:デフォルトの名無しさん
06/10/08 09:15:02
for文でループまわす必要があるのはリストよりはマップ。
キーと値を特定の順序で取り出したい場合は eachやforeachは弱い。

371:デフォルトの名無しさん
06/10/08 09:15:39
若者の都会かぶれが流行ってると聞いちょるがここまで進んでるたぁ、おれぁもうガマンならねぇ!
出直してけぇな>>369さん!

372:386
06/10/08 09:26:45
>>368
そういうのはfold_left系の関数の出番だな。
 ruby
(1..n).inject(1){|x,y|x*y}
 C++
#include<boost/iterator/counting_iterator.hpp>
#include<numeric>
#include<functional>
int fact(int n){
    return std::accumulate(
        boost::make_counting_iterator(1),
        boost::make_counting_iterator(n+1),
        1,std::multiplies<int>());
}

373:デフォルトの名無しさん
06/10/08 09:28:24
>>372
おっと名前欄にほかのスレの数字残ってたな。
その辺はスルーしといてくれ

374:デフォルトの名無しさん
06/10/08 10:01:34
うあ、面倒くさっ!

375:デフォルトの名無しさん
06/10/08 10:04:28
> (1..n).inject(1){|x,y|x*y}
うぉ。こんな風にかけるんだ

376:デフォルトの名無しさん
06/10/08 10:09:03
haskellだと
factorial n = product [1..n]
haskell万歳!

>>372
int fact(int n)
{
 int res = 1;
 for(int i=2;i<=n;++i)
  res *= i;
 return res;
}

と書いたら「ヘタだなぁ」と思われるの?

377:372
06/10/08 10:25:22
思われない思われないw 俺もネタ以外では普通にそうやる。
関数型言語っぽいやりかたはC++ではまだまだ面倒だからね。

378:デフォルトの名無しさん
06/10/08 11:02:23
普通に末尾再帰で書けばいいじゃん。
#include <cstdio>
#include <cstdlib>

template <typename T> inline T factrial(int n, T s = 1)
{
return n > 1 ? factrial(n - 1, s * n) : s;
}

int main(int argc, char ** argv)
{
printf("%d\n", factrial<int>(atoi(argv[argc - 1])));
printf("%.20g\n", factrial<double>(21));
return 0;
}

今時のコンパイラならループに展開するだろ。

379:デフォルトの名無しさん
06/10/08 11:41:00
末尾再帰の最適化って関数型言語限定だと思ってた…
今まで再帰のほとんどをループに直してた僕の努力は一体orz

380:デフォルトの名無しさん
06/10/08 11:52:17
Javaで、
引数、ローカル変数をできる限りfinalにしてない
コードをみると

あ、こいつはダメだ。

と思う。


381:デフォルトの名無しさん
06/10/08 12:17:21
引数までfinal化する必要があるかは程度問題だと思うんだが。
ローカル変数も同じ。

Java使ってまでC++と同じ流儀で徹底しないでもいいだろ。
C++でconstつけない奴は尻が二つに割れるまでチョップの刑だが。

382:380
06/10/08 12:37:24
>381
いや俺はできる限り、あらん限りの方策で
すべてfinal化するべきだと思っている。

383:デフォルトの名無しさん
06/10/08 13:24:59
うむ

384:デフォルトの名無しさん
06/10/08 13:47:24
Delphiで、引数にconstつけて周る俺がきましたぉ

385:デフォルトの名無しさん
06/10/08 13:59:43
なんでconsomeはないの?

386:デフォルトの名無しさん
06/10/08 18:29:22
>>376 378
下手かどうか以前にバグってるぞ

387:378
06/10/08 21:01:10
>>386
どっかバグってた?
#関数名以外でw

388:デフォルトの名無しさん
06/10/08 22:09:01
C++でクラスにする必要のない処理をわざわざクラス化してるとき

389:デフォルトの名無しさん
06/10/08 22:21:19
>>376 ++i  を使ってる時点で俺的にoutなんだが

390:デフォルトの名無しさん
06/10/08 22:23:22
*=ってなんでつかwwwwww

391:デフォルトの名無しさん
06/10/08 22:27:46
>>389-390
素人は帰れ。

392:デフォルトの名無しさん
06/10/08 22:35:47
resはどこで確保されてるか

393:デフォルトの名無しさん
06/10/08 22:37:08
>>389
C++の勉強をしましょう。
>>390
Cの勉強をしましょう。

394:デフォルトの名無しさん
06/10/08 22:37:52
>>392
>390が指摘している行の2行上。

395:デフォルトの名無しさん
06/10/08 22:44:24
はいはい、i++と++iは同じです。

396:デフォルトの名無しさん
06/10/08 22:50:20
>>395
C++の勉強をしましょう。

397:デフォルトの名無しさん
06/10/08 22:56:04
>>396
その話題飽きた

398:デフォルトの名無しさん
06/10/08 23:00:15
勉強しても++iとi++は同じであることがわかるだけだけどな。

399:デフォルトの名無しさん
06/10/08 23:02:50
>>398
C++の勉強をしましょう。

400:デフォルトの名無しさん
06/10/08 23:03:40
先に加算するか後で加算するかの違い
なんて関係ないことがほどんどだよな

401:デフォルトの名無しさん
06/10/08 23:05:07
C++の勉強をしましょう。

402:デフォルトの名無しさん
06/10/08 23:06:31
>>376がC++で書いたとは限らない

403:デフォルトの名無しさん
06/10/08 23:23:53
>>402
C++ですが、なにか?

404:デフォルトの名無しさん
06/10/08 23:29:36
>>401
何が違うのか説明してみろ。

405:デフォルトの名無しさん
06/10/08 23:30:20
この場合は何もかわらんな

406:デフォルトの名無しさん
06/10/08 23:30:37
しょうがないな、正解を言うぞ、
i++; は tmp=i,++i,tmp; という命令、階乗は ((1 + n) * n) / 2 で求まる。

うはっWWWオレ天才WW

407:デフォルトの名無しさん
06/10/08 23:33:43
中学の数学の勉強をしましょう。

408:デフォルトの名無しさん
06/10/08 23:35:01
>>400
i++の式値はi
++iの式値はi+1

前とか後とかじゃない、式値が違うだけだ

409:デフォルトの名無しさん
06/10/08 23:37:01
>>408
で、>>376の文脈で違いはあるのか?

410:デフォルトの名無しさん
06/10/08 23:38:00
>>409は400か?
>>400では>>376に言及してないぞ?
急に文脈を無視して>>376に関連付けられても困る

411:デフォルトの名無しさん
06/10/08 23:39:06
>>410
流れ嫁

412:デフォルトの名無しさん
06/10/08 23:39:31
shine!

413:デフォルトの名無しさん
06/10/08 23:42:05
0!が考慮されてないって意味じゃね?

あと++iとi++は戻り値が違う。

414:デフォルトの名無しさん
06/10/08 23:42:45
>>413
で、>>376の文脈で違いはあるのか?

415:デフォルトの名無しさん
06/10/08 23:43:12
>>414
無いね
それがどうしたの?

416:デフォルトの名無しさん
06/10/08 23:44:30
>>415
別に。
じゃ、この話題終了。

417:デフォルトの名無しさん
06/10/08 23:46:23
ここはぱっと見のコードの質を云々するスレなのだから、充分違うと思うが。

418:デフォルトの名無しさん
06/10/08 23:46:27
ところで int *iってして、*(++i++)はどんなのになるの?
文脈的に考えて

419:デフォルトの名無しさん
06/10/08 23:46:53
何が違うの?

420:デフォルトの名無しさん
06/10/08 23:47:49
>>418
Cを勉強しましょう。

421:デフォルトの名無しさん
06/10/08 23:49:29
>>420
答えられないということですね。

422:デフォルトの名無しさん
06/10/08 23:50:33
夏だなあ

423:デフォルトの名無しさん
06/10/08 23:50:33
「~しましょう」とか言ってる奴うぜー

424:デフォルトの名無しさん
06/10/08 23:51:25
鹿児島商

425:デフォルトの名無しさん
06/10/08 23:56:18
>>418
「i++が右辺値になり、それに前置++を使用しているのでコンパイルエラー」だと思う。

426:デフォルトの名無しさん
06/10/09 00:07:48
なんかこの話題最近見たきがするなぁ。

427:デフォルトの名無しさん
06/10/09 00:10:16
C++におけるpre/post incrementの知識を披露したいんでしょう。

428:デフォルトの名無しさん
06/10/09 00:10:45
このスレの80%はループでできて略

429:デフォルトの名無しさん
06/10/09 01:31:43
しかし無知が間違いと確信してるとこを指摘して
突っ込まれているところをニヤニヤしてる分には
ループでもいい

430:デフォルトの名無しさん
06/10/09 17:31:25
>>429
あんまり生産的なやり取りじゃないから
見てて気分よくないけどな。

431:デフォルトの名無しさん
06/10/09 17:42:01
馬鹿がうつるってのはあるけどな

432:デフォルトの名無しさん
06/10/10 03:04:39
つまり良くねーんじゃねーか。

433:あぼーん
あぼーん
あぼーん

434:349
06/10/11 10:48:49
あぁ、ここに書き込んでたのか。
クラス名・変数名スレに書き込んだつもりだったんだけど
どこいったんだかわからなくなってた。

で、だ、これ、適当にしたほうがっていうのは
名前に関して2時間とか3時間とか1日とか悩んでも
結局変更することになるんだからほどほどにしとけって意味。

# ていうか、俺が悩んでつけた名前って言うのは
後から見るとピントはずれなことが多い。

リファクタリングをしないって意味じゃない。
Cだとリファクタリング大変だけど・・・。

435:デフォルトの名無しさん
06/10/11 16:25:58
もういいって。

436:デフォルトの名無しさん
06/10/11 22:28:55
>>434
>俺が悩んでつけた名前って言うのは
名前で悩む前に設計がそれで適切なのかを考えてはどうか。
どの変数・関数がどんな役割を持つのかハッキリしないから
どんな名前つけて良いかが分からない。
役割がハッキリしてればその役割をそのまま名前に落とせば良い。

命名に詰まる時は、設計見直しのサインだよ。

437:デフォルトの名無しさん
06/10/12 01:49:11
他人が書いたコードを整理していると、しばしばネーミングに困る。

438:デフォルトの名無しさん
06/10/12 02:47:24
>命名に詰まる時は、設計見直しのサインだよ

悩んだ末にすっきり名前が決まると、なんつーかこう、宿便が抜けたような爽快感。
それだけで仕事が終わった様な気持ちになれるな。

いや、冗談抜きで名前が決まった時点で仕事の何割かは完了してるわけなんだけどさ。

439:デフォルトの名無しさん
06/10/14 21:34:09
lpszStrButtyakeBuririant0001->getSTRLFSPACETABCOMMA(index)->getSTRCONTROLSHIFTTAB(index_ind)->getChar(index_chr);

440:デフォルトの名無しさん
06/10/28 15:46:28
うわー。。。

441:デフォルトの名無しさん
06/10/28 18:35:19
malloc 関数で確保してるのに開放は delete 演算子。
2つのメンバ関数間でしか使われてないのでスタック割り当てで十分なはずだが、なぜかメンバ変数。
単体の画面アプリで外から呼ばれるはずもないのに、全てpublic関数。
const の検索結果0件。#DEFINEすら使ってない。何もかもリテラル。
default 句のない switch 文。default が不要な理由などどこにも書いてない。
JOIN すれば一発なのに、単体テーブルアクセスを内部で毎レコード繰り返してるDB参照処理。

どう見ても作り直しです。本当にありがとうございました。

442:デフォルトの名無しさん
06/10/28 18:41:50
つ ラップしちゃえ!

443:デフォルトの名無しさん
06/10/30 04:26:42
malloc(strlen(p)))

444:デフォルトの名無しさん
06/10/31 01:52:02
>>443
それだけ見ても、下手かどうか判断できないが。
例えばfgets()の直後に、改行文字を取り除いた文字列の複写を得たいのなら、妥当じゃないか。

445:デフォルトの名無しさん
06/10/31 13:04:04
>>444
その処理なら strdup でいいと思うが。

446:デフォルトの名無しさん
06/10/31 18:14:51
>>445
strdup がなかったら?

447:デフォルトの名無しさん
06/10/31 18:40:47
↓ strdup無いなんてどんな環境だよ
↓ ○○環境にはないんだよボケ
↓ だったら自分でやりゃいいだろボケ
↓ ○○も知らないくせに下手なコードとか言うなボケ
↓ (グダグダな流れが続く)

という予感

448:デフォルトの名無しさん
06/10/31 19:39:16
>>446
>strdup がなかったら?

malloc(strlen(p)+1) と strcpy だな。

449:デフォルトの名無しさん
06/10/31 19:48:18
>>448
長さ覚えといてmemcpyの方がだいぶ速いことがあるよ。

450:デフォルトの名無しさん
06/11/20 22:02:11
for(;;){
if(judge){
break;
}
~~~
~~~
}

451:デフォルトの名無しさん
06/11/20 22:09:22
>>450
そういうのは終了条件( if(judge){ break; } に相当するトコ)が
複雑になる可能性があるときに書くことあるなぁ。


452:デフォルトの名無しさん
06/11/20 22:13:26
>>451
理解の範囲を越えています。

453:デフォルトの名無しさん
06/11/20 22:21:05
>>443
コンパイルエラーじゃね?

454:デフォルトの名無しさん
06/11/20 22:53:55
>>453
その根拠は?

455:デフォルトの名無しさん
06/11/20 23:53:49
閉じ括弧が1つ多い。

456:デフォルトの名無しさん
06/11/21 01:01:21
セミコロンがない

457:デフォルトの名無しさん
06/11/21 11:19:53
セミコロン
は文の区切りです

458:デフォルトの名無しさん
06/11/21 23:56:48
>450
↓だったら普通。また将来↓にする予定で>450と書くのも分からんではない

for(;;){
 if(条件1){
  break;
 }
 if(条件2){
  break;
 }
 :
 if(条件N){
  break;
 }
 :
}

459:デフォルトの名無しさん
06/11/22 00:14:27
それは普通
for(;;){
if( is_must_to_break( ... ) ) break;
.
.
.
}
と書くだろ

460:デフォルトの名無しさん
06/11/22 00:16:25
>>458
while(is_proceding()) {
 :
}

461:デフォルトの名無しさん
06/11/22 02:34:05
>>459
be動詞+助動詞+to+動詞
についてkwsk


462:デフォルトの名無しさん
06/11/22 02:38:51
All your bases are belong to us.

463:デフォルトの名無しさん
06/11/22 02:45:42
FIXME: bloken English


次ページ
最新レス表示
レスジャンプ
類似スレ一覧
スレッドの検索
話題のニュース
おまかせリスト
オプション
しおりを挟む
スレッドに書込
スレッドの一覧
暇つぶし2ch