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'で開くだけじゃんｗ
お前が何をいわんとするのかさっぱりわからない。
268:デフォルトの名無しさん
06/09/03 10:41:28
俺もため息が出るよ。
醜くてもやむをえずそれを書いた人の心中察するあまり…
269:デフォルトの名無しさん
06/09/03 10:48:59
で、>>267を
try{
hoge.init();
hogest.init();
・
・
・
}
って書くと
catch()
catch()
catch()
・
・
・
って書かなきゃいけないじゃん。
俺、これをやるぐらいなら>>267のほうが１００倍ぐらいいいと思うんだけど。
エラーが起きたらエラーが起きたその箇所にその内容が書いてあるほうがいいと思うんだけどなぁ。
270:デフォルトの名無しさん
06/09/03 11:21:30
>>267
＞これってfopenを'a'で開くだけじゃんｗ
あ、いけね、「新規作成して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行ファイル内容を出力」の肝腎な後半を忘れてた。
日本語でおｋ
>で、漏れはその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
だって全然検索ヒットしないよ。
入れてみたものの誰も使ってないんじゃない？
Ｃ言語の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
そんなもんＣでもできるし、継承関係ないけど…。
ひょっとして釣り？
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)
これはおｋだよな？
(つД`) つーかもう俺泣きてぇ。
この 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ホントは使いたいんだろ？
堀川に嫉妬してるんだろ？白状してご覧よｗｗｗ
どうみても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を０で初期化する。
こういうのとか、
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
いねーよ、そんな奴ｗ
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
意味が変わってきたら、それに応じてリファクタリングかけるべきだな。
いつでも変数の意味は正確な物にしておくほうがベター。
考えても意味がないっていうのは、ちょっと良い考え方ではない。
一人案件でも、仮に趣味のコードでも、このへんは変わらんよ。
数ヶ月後の自分は、今の自分からみたら他人並。
その時に、わかりやすいコードとコメントが意味を持ってくるものだし。
本当に作り捨てで今だけ解ればいいっていうなら、手を抜くのも有りではあるが…
案件なら、作りっぱなしでもう２度とコードみないって訳にもいかなかったりするだろ？
入社半年目なら、今のうちに考え直す方が良いよ。
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
思われない思われないｗ 俺もネタ以外では普通にそうやる。
関数型言語っぽいやりかたは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:３８０
06/10/08 12:37:24
＞３８１
いや俺はできる限り、あらん限りの方策で
すべて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 を使ってる時点で俺的にｏｕｔなんだが
390:デフォルトの名無しさん
06/10/08 22:23:22
*=ってなんでつかｗｗｗｗｗｗ
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がＣ++で書いたとは限らない
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 で求まる。
うはっＷＷＷオレ天才ＷＷ
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
あぁ、ここに書き込んでたのか。
クラス名・変数名スレに書き込んだつもりだったんだけど
どこいったんだかわからなくなってた。
で、だ、これ、適当にしたほうがっていうのは
名前に関して２時間とか３時間とか１日とか悩んでも
結局変更することになるんだからほどほどにしとけって意味。
＃ ていうか、俺が悩んでつけた名前って言うのは
後から見るとピントはずれなことが多い。
リファクタリングをしないって意味じゃない。
Ｃだとリファクタリング大変だけど・・・。
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
464:デフォルトの名無しさん
06/11/22 22:49:57
>>461
火星語
465:458
06/11/23 00:11:50
>459,460
あれが一番常識的っつー意味で「普通」なのではなく
あーいう書き方をしてもそれほど変とも言い切れない、
という意味で「普通」です。
まぁかなり限定的だけど…
466:デフォルトの名無しさん
07/01/14 15:04:58
このスレでまたコードの更正やっていいですか？ｗ
467:デフォルトの名無しさん
07/01/14 20:30:42
ok
468:デフォルトの名無しさん
07/01/15 14:01:00
while(*d++ = *s++);
469:デフォルトの名無しさん
07/01/17 02:29:29
>>459
クソﾜﾛﾀ
470:450
07/01/21 18:48:43
#ifndef __HEADER_H__
#define __HEADER_H__
#define VOLTAGE0_STRING "voltage1"
#define VOLTAGE1_STRING "voltage2"
#define VOLTAGE2_STRING "voltage3"
#endif //__HEADER_H__
-------------------------------------
いろいろな意味で勘弁してよ～
471:デフォルトの名無しさん
07/02/09 06:05:45
#define BASE \
unko_t **my_unko;\
int penis_count;\
struct SuperPenis {
BASE
...
}
struct OldCunt {
BASE
...
}
こういうの嫌い。ていうかマクロで変数定義済ませるコードはイヤ。
472:デフォルトの名無しさん
07/02/09 10:19:26
そんなヤツはおらんやろ～
473:デフォルトの名無しさん
07/02/09 10:39:18
>>471
これは酷い。
474:デフォルトの名無しさん
07/02/09 16:23:19
>>471
うーん。本来
struct Base {
unko_t **my_unko;
int penis_count;
}
struct SuperPenis {
Base base;
...
}
struct OldCunt {
Base base;
...
}
であるべきなのを、
その様なベタ書きなデータ設計を強制されるなら
自分もやってしまいそうです
475:デフォルトの名無しさん
07/02/09 16:33:33
やるなよ。
476:デフォルトの名無しさん
07/02/09 17:28:00
ところがこれが VC のコードで DECLARE_BASE とかいう名前だと
さほど違和感が無いあたり、漏れはMSに毒されてるな・・・
477:デフォルトの名無しさん
07/02/10 05:53:40
オプソのライブラリとかでもよく使われてる。＞マクロによる一括変数定義
名前空間が特定のライブラリ色に染められるのが不愉快。
こんなだから、再利用性の低いコードばかり生まれるんだよな。
ちなみに、>>471 の方法は、Perlのコードに使われてたのを引っ張ってきた。
478:デフォルトの名無しさん
07/02/10 11:52:37
それにしても例に使ってる変数名と構造体名はどうにかならなかったものか。
479:デフォルトの名無しさん
07/02/11 04:43:32
かたじけない。
480:デフォルトの名無しさん
07/02/11 11:49:31
>>471, >>476
最近の開発で、委譲ベースのMemoryPoolクラスを用意して、
#define MEMORYPOOL_DECLARE(CLS, NUM) ¥
typedef MemoryPool<CLS, NUM>::MyMemPool ¥
static void * operator new(size_t size) {return MyMemPool::alloc(size);} ¥
static void operator delete(void * p, size_t size) {MyMemPool::free(p, size);} ¥
みたいなのを作ったばかり・・・。
481:デフォルトの名無しさん
07/02/11 12:42:49
>>480
マクロを使わずにこんなんじゃ駄目だったの？
俺は多重継承でこういういmixin的な使用方法をわりとするけど。
template<typename CLS,int NUM>struct MemoryPool :{
...
...
static void * operator new(size_t size) {return alloc(size);}
static void operator delete(void * p, size_t size) {free(p, size);}
};
class CLS : public MemoryPool<CLS,100>{
...
};
482:デフォルトの名無しさん
07/02/11 13:28:54
>>481
出来ればそうしたかったんだけど、
MemoryPoolクラスの中身を↓な風に作ってて・・・。
template<typename T, size_t NUM>
struct MemoryPool {
unsigned char * buffer_[sizeof(T)];
...
static MemoryPool block_[NUM];
...
};
class Hoge : public MemoryPool<Hoge, 100> {
....
};
ってすると、sizeof(T)が確定しなくて、
コンパイルエラーになってしまう。
作りを大幅に変えずにエラーを回避する方法はないだろか・・・?
483:デフォルトの名無しさん
07/02/11 16:15:41
開発環境は何使ってるんだ？
>>482 の方法で、Visual Studio 2005 Express だと問題なくコンパイルできるぞ。
ただ、
class Hoge: public MemoryPool<Hoge, 100>{
は、当然 Hoge の再定義になるから、
class Hoge1: public MemoryPool<Hoge, 100>{
... とする必要あるけど。
また、うまく動作するかは試してないけどな。
484:デフォルトの名無しさん
07/02/11 17:55:42
>>483
環境はVC++6.0です。
> class Hoge1 : public MemoryPool<Hoge, 100>
これだと新たにクラスを作らないといけないので・・・。
ところでさっきのコードは不正確でした。
実際はこんなかんじです。
Effective C++(だかModern C++ Design)を参考にしています。
template<typename T, size_t NUM>
struct MemoryPool {
union Chunk {
unsigned char buffer_[sizeof(T)];
Chunk * next_;
};
static Chunk block_[NUM];
static bool blockInitialized_;
static Chunk * head_;
static void * alloc(size_t size);
static void free(void * p, size_t size);
};
スレ違いのような気もするけど、自分がヘタレだと云う点では
間違っていないな・・・。
485:481
07/02/11 18:32:39
>>484
んーそういう場合は実体化のタイミングをずらせばOK。
..なんだけどVC6ってこれ大丈夫だっけ。VC6はtemplate絡みのバグ多すぎでイケるか自信ない...
template<typename T>
union Chunk{
unsigned char buffer_[sizeof(T)];
Chunk * next_;
};
template<typename T, size_t NUM>
struct MemoryPool {
static Chunk<T>*block(){static Chunk<T>block_[NUM];return block_;}
static bool blockInitialized_;
static Chunk<T>* head_;
static void * alloc(size_t size);
static void free(void * p, size_t size);
};
486:デフォルトの名無しさん
07/02/11 20:03:46
>>485
おお。試してみたところ期待通りの結果(継承に置き換え可能)になりました。
(そのままでもOKでしたが、ChunkはMemoryPoolのインナークラスにしました)
なるほど実体化の遅延ですか。勉強になりました。
487:デフォルトの名無しさん
07/02/12 03:29:09
480です。しまった、ちゃんとお礼を云ってなかった。
>>481さん、>>483さん、ありがとうございました。
スレ汚しすみません。
488:デフォルトの名無しさん
07/03/17 20:25:00
chokin = chokin != 0 ? chokin : 0;
489:デフォルトの名無しさん
07/03/17 20:27:06
最適化で消滅しそうだな
490:デフォルトの名無しさん
07/05/10 16:49:30
ム板のその４の次スレ、ここでいいの？
491:デフォルトの名無しさん
07/05/10 16:50:16
↑
×ム
○マ
492:デフォルトの名無しさん
07/05/21 18:57:37
age。
493:デフォルトの名無しさん
07/06/01 00:09:59
今やってるプロジェクト、Cで作っているけど動的なメモリ確保は禁止なんだぜ？
リークの原因になるからだって。
494:デフォルトの名無しさん
07/06/01 00:30:24
>>493
一昔前のゲームプログラムとか（携帯機なら今でも）、組み込みだと当たり前では？
495:デフォルトの名無しさん
07/06/01 01:33:15
どこの「当たり前」だよ
496:デフォルトの名無しさん
07/06/01 01:48:40
そもそも動的に割り当てるほどのメモリが無いというならともかく、
リークするからとmallocを禁止するのは当たり前とは言えないだろうな。
497:デフォルトの名無しさん
07/06/01 08:08:12
mallocがクソな環境もあるんだよ
498:デフォルトの名無しさん
07/06/01 10:02:54
普通に使っていてリークするようなクソmallocがあるのか、
そりゃたいへんだな。
499:デフォルトの名無しさん
07/06/01 12:14:13
リンクオプションで領域確保しておいて、その中で自前で管理するってプロジェクトはあったな。
500:デフォルトの名無しさん
07/06/02 12:22:58
リークするからと言う理由だけじゃなくて、そもそも必ず確保できるわけじゃない
可能性があるから malloc() 禁止のところは組み込みなら普通にある。
misra malloc とかでぐぐってみ。
501:デフォルトの名無しさん
07/06/02 13:26:43
> 確保できるわけじゃない可能性があるから malloc() 禁止のところは組み込みなら普通にある。
そんなことは誰でもしってます
502:デフォルトの名無しさん
07/06/02 13:36:13
> そんなことは誰でもしってます
とりあえず知らない人間はいないことをどうやって証明したのかｋｗｓｋ
503:デフォルトの名無しさん
07/06/03 03:28:59
マロックさんをわるくいうんじゃない！！
504:デフォルトの名無しさん
07/06/04 11:10:03
>>502
誰もが最初は知らなかった筈ですから、
「誰でも」が「遍く」ではないことは想像できることです。
では「誰でも」とはどういった範囲の人たちを指しているのでしょう？
それは >>500 のみぞ汁。
505:>>500
07/06/04 22:57:36
> 「誰でも」が「遍く」ではないことは想像できることです。
言い訳乙。
少なくとも俺は、唐突に「誰でも」って書かれたら、全世界の人間を想定する。
506:デフォルトの名無しさん
07/06/04 23:02:35
お前が宇宙人を差別することは分かった。
507:デフォルトの名無しさん
07/06/05 06:16:20
自分が悪い時に、素直に間違いを認めず「だけど、～」って関係ない事象を語って
煙にまこうとする奴を見た時は「ヘタだなぁ」と思うな。
コードじゃないけど。
508:デフォルトの名無しさん
07/06/05 06:53:36
なんか>>504から臭ってこない？
509:デフォルトの名無しさん
07/06/05 09:26:57
組込みやらないやつはsbrkとか自分たちで実装する
環境なんて思いもよらないんだろうな。。。
組込みやらないやつは
void main
を見て
int main
じゃないから下手だ、とか言うんだろうな。
510:デフォルトの名無しさん
07/06/05 10:37:29
組み込みにはOSがないと思い込んでいるなら下手どころじゃないがな。
511:デフォルトの名無しさん
07/06/05 10:59:34
石屋にはなりたくない。へたすりゃ携帯屋だもん。
512:504
07/06/06 11:15:24
>>505
>言い訳乙。
504 ≠ 500 ですよ。間抜けですね。
>全世界の人間を想定する。
素人が知ってるわけがないでしょうに。間抜けですね。
513:>>500
07/06/06 22:33:39
自演乙。
514:デフォルトの名無しさん
07/06/14 20:32:22
変数宣言とか行末コメントを揃えて書いてあるのを見ると、下手だと思ってしまう。
多分、コボラーを連想しちゃうからだと思う。
unsigned int hogehoge1;
int hogehoge2;
double hogehoge3;
間違いなくずれていると思うが、変数の開始位置が揃っていると思ってけれ。
515:デフォルトの名無しさん
07/06/14 21:08:51
>>514
これはいまのソースコードがプレーンテキストで記述されていることからくる
問題であって本来テーブル記述できるべきもんだと思うし、俺は揃えてある
ほうが好きだけどなぁ。
516:デフォルトの名無しさん
07/06/14 21:42:22
可読性のために変数を揃えることはある
517:デフォルトの名無しさん
07/06/14 22:07:47
揃えようが揃えまいが可読性は変わらないな、俺の場合。
下手に揃えてあると、修正が面倒くさい。
変数を一個追加するだけなのに、全ての変数宣言を修正する羽目になったりするし。
518:>>500
07/06/14 23:27:27
変数宣言は俺も昔は揃えてたけど、最近はあまり気にしなくなった。
でも、行末コメントは今でも揃えてる。ばらばらだと読み辛いから。
519:デフォルトの名無しさん
07/06/15 01:52:54
このソース評価してやってくれませんか、皆さん。
ｽﾚﾘﾝｸ(tech板:625番)
イマイチ反応がなくて寂しかったので
よろしくお願いしますm(_ _)m。
520:デフォルトの名無しさん
07/06/15 02:07:24
PL/SQL なんだけど、テーブルからデータを取得する関数が
すでに作ってあるから使って、といわれた。
ライブラリを見てみたら、関数は戻り値が整数型でエラーコードを返す。
これはまいい。
引数を見ると、最初に２つくらいがDB検索のキー。
そしてその後ろに、１０個近くのデータ出力用の引数がずらりと並んでいた。
デフォルト引数など用意されているはずもなく、
俺が必要なのはそのうちの１つか２つなのに、この関数を使うためには、
まったく必要のないダミーバッファを引数として渡さなければならないという。
そんなもん使う気にもなれず、select 文書きましたよ。where条件だって
その方が自在だしな。
521:デフォルトの名無しさん
07/06/15 07:46:27
>>520
せめてNULLなら無視してくれる仕様だったらよかったのにな
522:デフォルトの名無しさん
07/06/16 18:53:06
そういう仕様を考えるのは、汎用機あがりに多いね。
523:デフォルトの名無しさん
07/06/17 01:06:10
>>520
いまいち状況よくわからんけど、ラッパー書けば済む話じゃないのか？
524:デフォルトの名無しさん
07/06/17 06:20:25
そうだよな。そこでデザインパターンの登場ですよと。
525:デフォルトの名無しさん
07/06/17 19:26:18
ラッパークラスにHeyYoと名付けたら怒られた。
526:デフォルトの名無しさん
07/06/17 21:18:39
ラッパークラス名にhogeって書いたら怒られた
URLﾘﾝｸ(www.hoge.org)
527:デフォルトの名無しさん
07/06/18 00:17:01
// 消費税を計算する
price = price + 1.5; // 1.5かける
かけてないじゃん
そんなコメントはいらん
*= 使え
ぼったくりすぎだろ
べた書きすんな。何のために期間管理付きの設定ファイル作ったと思ってんだコノヤロウ
と、コードより指摘事項が長くなるようなレビューを続けること1週間。
コンパイラも静的解析ツールも馬鹿の前には無力。もう疲れた...
528:デフォルトの名無しさん
07/06/18 15:42:29
>>527
もつかれｗ
なんというか、プログラミング以前の数々の間違いにﾜﾛﾀｗ
529:デフォルトの名無しさん
07/06/18 18:10:21
デンマークですら消費税25%だぞw
530:デフォルトの名無しさん
07/06/18 21:04:57
ちょｗｗｗｗ
これはぜひとも晒しageなくてはｗ
531:デフォルトの名無しさん
07/06/18 21:06:07
>>527を「price *= 1.05」に直してきたら「将来消費税率が上がったら税額計算してるとこ全部書き直すの？」と突っ込む。
んで、「#define TAX_RATE 1.05 …」とやってきたら「累進税率になったらどうしよう？」
そして「int tax_in(int price){ return price * TAX_RATE; }」→「品目別税率になるかもしれないね」
ここでキレたり泣き出さなかった新人がようやく使い物になる。
532:デフォルトの名無しさん
07/06/18 21:09:05
>>531
超アホな癖がつくからそんなことを新人にやるな。
533:デフォルトの名無しさん
07/06/18 21:13:16
税率が変わることは可能性が高いから考慮するが、後ろの2つは切り捨てていいだろう。
くだらないことを考えて複雑なコードを書くヤツは下手糞。
534:デフォルトの名無しさん
07/06/18 21:19:32
>>533
禿道
「かもしれない」可能性論で実装するのはアホ
大体、消費税が大きく変わったら、そこで予算取って仕事にするんだから、
今下らない理由で無駄な作業をやらせるのは愚行
>「累進税率になったらどうしよう？」
ならなかったら、この作業分の無駄をどうpayするんだ？
>「品目別税率になるかもしれないね」
ならなかったら、この作業分の無駄をどうpayするんだ？
535:デフォルトの名無しさん
07/06/18 21:24:41
>>534
真の問題はその作業分が無駄になるだけじゃなくソースコードが
肥大化することでメンテナンスコストが増大することだろ。
536:デフォルトの名無しさん
07/06/18 22:02:40
むしろ真の問題は帰りがけに背中を刺されること。
537:デフォルトの名無しさん
07/06/18 22:05:17
むしろそれは最善の解決策
538:デフォルトの名無しさん
07/06/18 22:08:36
とりあえず >>531 みたいな馬鹿がいるとこ就職しちまったヤツには深く同情する。
539:デフォルトの名無しさん
07/06/18 22:19:23
将来の事を考えてバリアント型にしておきましたッ!!
540:デフォルトの名無しさん
07/06/18 22:27:50
お前の将来は何時までたっても泥沼なのかyo
541:デフォルトの名無しさん
07/06/18 22:51:03
> 税額計算してるとこ全部書き直すの？
そもそも、税額計算してるところが複数ある設計に問題があるだろ...。
542:デフォルトの名無しさん
07/06/19 00:20:34
みんな、531をそんなに苛めるなよ。
531は会社で評価されていなくて、新人を苛めるくらいしか仕事が無いんだよ。
本人は、「俺って先を読んで設計できる上級者」とか思っているんだから。
余り苛めると引きこもりになっちゃうぞ。
543:デフォルトの名無しさん
07/06/19 07:13:54
でもリファクタリングがはやって、思考停止するやつが増えたような気もする。
今回の流れみたいな雰囲気で話するやつが多い。
今回はの流れはわかるけど。
極論を話すやつもいるから。単に仕事をするのがいやって理由だったりする。
そのくせ、締め切りまぎわにまでリファクタリングとかって引っ張る。
設計の思考停止を実装でカバーってな風。
544:デフォルトの名無しさん
07/06/19 08:10:33
それなんて俺？
545:デフォルトの名無しさん
07/06/19 15:17:45
> そのくせ、締め切りまぎわにまでリファクタリングとかって引っ張る。
おれおれ
546:デフォルトの名無しさん
07/06/19 21:51:18
>>531みたいに未来の仕様を先回りして実装するのは下手だが
実際に仕様が追加されたとき(>>531の例でいうと累進税率や品目別税率)に
何箇所も直したりプログラムの構造を変えなくちゃいけなくなったりするのも下手
すなわちYAGNI
547:デフォルトの名無しさん
07/06/20 00:13:58
CVSとgrepと正規表現置換ができるエディタがあれば無問題
548:527
07/06/20 01:10:39
>>531
一個だけ補足。
新人じゃないよ。
549:デフォルトの名無しさん
07/06/20 02:16:37
>>548
オチだとしたらできすぎだよw
おつかれ。
550:デフォルトの名無しさん
07/06/20 07:19:46
設計の妥当性の検証って１週間～１ヶ月くらいはかかると見ておいた方がいいね。
例えば、ふと思いついた設計が、実は糞仕様だったのでその実装をやり直すってよくあるだろ。
まあ、実装してみなければわからん糞さってのもあるけど。
そこを熟成させるために実装を遅らせる効果は大きい。
バージョン管理していても、その糞実装したコストは変わらないわけで。
551:デフォルトの名無しさん
07/06/21 00:52:35
規模も複雑さも書かずに１週間～１ヶ月と言われてもなぁ。
552:デフォルトの名無しさん
07/09/03 15:47:43
よしあげてやる
553:デフォルトの名無しさん
07/09/04 16:13:00
>>132
>それ以前に何故にthisを明記するか。
this->とやると、入力補完出来るんだよ。
554:デフォルトの名無しさん
07/09/04 19:03:30
this入力しないとメンバも保管できないIDEってｗｗｗｗ
555:デフォルトの名無しさん
07/09/04 19:11:58
if (f.isVisible() == true)
みたいな不要なことをするやつ。
#define SIZE 10
for (int i = 0; i < SIZE; i++)
みたいにして意地でも配列を使う奴。
typedefしまくってるやつ。
556:デフォルトの名無しさん
07/09/04 19:52:53
>>554
井出って、誰だよwwww
557:デフォルトの名無しさん
07/09/04 20:40:53
>ぱっと見て「ヘタだなぁ」と思うコード
俺のコード。