07/07/15 19:19:36
>>349 いや、あれだよと突っ込んでほしいのか?
351:仕様書無しさん
07/07/15 20:54:06
>>349
自爆装置を仕込んでいるのか
352:仕様書無しさん
07/07/15 20:55:06
>>349
コードを追記したら
func(); // 目がぁ～目がぁ～
はお約束だな
353:310
07/07/15 21:44:15
変な議論呼んだようですまん
貼った俺自身もこのメソッドが何をしたいのかよく分からなかったんだが、
呼び出し先メソッドが↓のレスなんで、
どうやら接続した後の切断処理をやってるつもりなのかなぁ、と考えてる
354:310
07/07/15 21:46:05
// 接続先のファイルサイズを取得
public long getFileSize(String cnurl) {
boolean isCnct = cnct(cnurl) ; // ※接続テストをしているらしい
if (!isCnct) { return -1; } // 接続可能ならtrue
URL url;
try {
url = new URL(cnurl);
HttpURLConnection urlconn;
urlconn = (HttpURLConnection)url.openConnection();
long fullsize = 0;
Map headers = urlconn.getHeaderFields();
String key = "Content-Length" ;
String e = (headers.get(key)).toString();
e = e.substring(1,e.length()-1) ;
fullsize = Long.parseLong(e) ;
boolean isDisCnct = discnct(cnurl) ; // ※ここで310呼び出し
if (!isDisCnct) {
return -1 ;
}
if(fullsize < 0)
return -1 ;
else
return fullsize ;
} catch (IOException e1) {
}
return 0;
}
355:仕様書無しさん
07/07/15 22:08:18
なんというコード・・・
356:仕様書無しさん
07/07/15 22:18:14
何したいわけ？
357:仕様書無しさん
07/07/15 22:27:07
cnct（対象URLに接続）
↓
getFileSize（ファイルサイズ取得）
↓
discnct（切断処理）
・・・がやりたかったのかな？
358:仕様書無しさん
07/07/15 23:41:45
たった二十行程度のコードに
山のように突っ込みどころが・・・
359:仕様書無しさん
07/07/15 23:55:07
>>310のコメント
// このURLへは今後接続しないことを示す
が、
/** @return true 切断成功 false 失敗。このURLへは今後接続しない */
ならまぁよかった、ということなのかな。
360:仕様書無しさん
07/07/16 00:49:09
つか成功したかどうかHashかなんかで管理して
余計なオブジェクト毎回接続するたびに作らないようにしね？
結果の保持が必要な場合は別途なにかクラス作って
突っ込んだ方がよくね？
361:仕様書無しさん
07/07/16 01:01:17
あまりにひどいコードに絶望した…！
でもそういうコードを以前見かけたことが
あるのに気づいて更に絶望した！！
362:仕様書無しさん
07/07/16 02:02:50
コメントにアスキーアートがはってあったぞ
「カイジ」のやつ
363:仕様書無しさん
07/07/16 02:11:13
__,,,.... -―‐- .._ そりゃあ…かまわない
／vV/／／∠∠彡:ﾆﾆヽ おまえらの疑問に答えること それ自体は容易い 簡単だ
{/`ｰ-‐'''"´ 二二ニニl 例外時の処理はこれこれこう こういうメソッド行き
/ｰ--‐''''"´ 二二ニﾆ| 返り値は…？パラメータは？
,/ー---‐'''"´＿_ ﾆﾆ二二| そんなコメントは いくらでもできる
〈べヽ ｌ. ヾニ-‐'''ヾ> =r-､ニﾆ|
},-o-> ヽPニﾆ ﾐ ｽ.|ﾆ二| しかし 今 オレが そんなコメントを 仮に付けたとしても
. |二/,' ー― ' `に!|二ﾆﾄ､ その真偽はどうする…？
｜/,' __ ヽ＼ r＜二ニ| ＼
| ｢r---一ァ'! ｜ ＼ニ| |`'ｰ-､__ 真偽など どうでもいいから
| !｀ 三￣ ｌ | ＼! ｜ 読みたいと言うのか…？
＼ _.. -''" ／| |
_,.. ‐'''"`ー ＜´ ／ ｜ ｜ ククク……
364:仕様書無しさん
07/07/16 02:23:55
>>363
一見まともなコメントにこんなの付いてたら嫌になるな。
365:仕様書無しさん
07/07/16 05:00:11
何を信じればいいのかw
366:仕様書無しさん
07/07/16 05:06:11
>>363
プログラマやめろよ、つかやめてくれｗ
367:仕様書無しさん
07/07/16 12:26:01
>>354
酷いな・・・8行で済むのにそんなにダラダラと・・・
368:仕様書無しさん
07/07/16 13:11:02
>>363
お前とは仕事したくねぇよ・・
369:仕様書無しさん
07/07/16 19:13:26
納期は命より重いっ・・・！
370:仕様書無しさん
07/07/16 20:32:25
ざわ・・・
ざわ・・・
ざわ・・・
俺のバグですたorz
371:仕様書無しさん
07/07/17 11:34:53
>>344
ローカル関数に関してはそのルールで書く人を知っている。
本人曰く、『どーせ俺しか読まねぇし』。
372:仕様書無しさん
07/07/17 12:00:04
3年後の「俺」には読めない罠。
373:仕様書無しさん
07/07/17 12:44:05
あるあるｗｗｗ
374:仕様書無しさん
07/07/17 12:51:10
>>372
一年後に読める自信がないです。
覚えているうちに仕様変更とかあればいいんだが…
375:仕様書無しさん
07/07/17 12:54:19
違う仕事一個でも挟むと無理そうだ
376:仕様書無しさん
07/07/17 13:05:25
>>372
三週間でも微妙
377:仕様書無しさん
07/07/17 13:50:59
>>376
って言うか、たったの3連休で頭真っ白なんですが・・・
先週までの俺が何をどうしたかったか、やっと何となく解ってきたｗ
今週の俺によると、先週までの俺は未熟者だったらしいｗｗ
378:仕様書無しさん
07/07/17 16:11:58
前日の日記をつけろ。毎日3行程でいいぞ。
379:仕様書無しさん
07/07/17 19:13:28
似たようなのもう出てそうだが、
Hoge1()
{
__asm {
：
：
}
}
Hoge2()
{
__asm {
：
：
}
}
7000行ほどでコメント一切無し
380:仕様書無しさん
07/07/17 19:32:47
Cool！ｗ
381:仕様書無しさん
07/07/17 19:45:12
>>379
昔は、マシンコードを定数の配列にして、関数ポインタで指してたり．．．
382:仕様書無しさん
07/07/17 19:55:24
定数ならまだいいが、技術的な制限から、コードを実行中に書き換えながら走らせることもあったな。
当分使われないコードセグメントはメモリから削除して、空いた空間に別のコードセグメントをロードしたりとかもしたし。
今となってはOSが担当する処理だが、その当時はそんなトリッキーなことを強いられたもんだ。
383:仕様書無しさん
07/07/17 19:59:06
>>381
今でもやっていたりする....
384:仕様書無しさん
07/07/17 20:04:59
辞めさせられないようにする為の保険か？
385:仕様書無しさん
07/07/17 21:29:30
メモリに入りきらない。
386:仕様書無しさん
07/07/17 22:01:34
>>379
何か問題でも？
387:仕様書無しさん
07/07/18 02:59:01
せめてコメントぐらいはつけて欲しいな
388:仕様書無しさん
07/07/18 03:38:17
ソースコードが残ってなくてＲＯＭがあるんだけど、バグ対処してねとかいうのもあったな。
電算室（古っ！）に配属になって初めて書いたプログラムが自己変更コードだった。指導者乙。
そういうのがお行儀悪いことだと知るのはその１０年後。
389:仕様書無しさん
07/07/18 11:48:54
10年は長いですね。
390:仕様書無しさん
07/07/18 11:58:05
その部署の文化になってればそれが当たり前になっちゃうからなあ。
391:仕様書無しさん
07/07/18 12:07:48
>>388
Intel 8x86 の時は、自己書き換えしても問題なかったから、メモリの制約とあいまって、
むしろあたりまえのプログラミング技法だったと思う。
80x86nになってキャッシュの概念が出てきて、メモリ上で自己書き換えしてもそのコードが
保持されないので問題が顕在化して、行儀が悪いということになった。
392:仕様書無しさん
07/07/18 12:17:59
行儀の問題はキャッシュとは関係ないっしょ
393:391
07/07/18 12:42:13
いや、この場合は関係あると思ってるんだが。
「キャッシュのために今までのノウハウが使えなくなった」が「行儀が悪い」にすりかえられた。
まあ今じゃ通用しないノウハウだし、「行儀が悪い」という言葉にはよっぽどのひねくれ者じゃなければ
逆らおうと思わないから、いいけどね。
394:仕様書無しさん
07/07/18 12:48:29
すげーどうでもいいことだが。
x86の自己書き換えはパイプラインで問題になった。
キャッシュは最初から対策してる。
395:仕様書無しさん
07/07/18 13:10:44
自己書き替えはそれこそZ80の時代から「行儀が悪い」とされてましたが何か
396:仕様書無しさん
07/07/18 15:13:54
86 系で自己書き換えのときのキャッシュのフラッシュ（の欠落）が問題になったのは
ハーバードアーキテクチャを初採用した Pentium から。
Mac では 68040 を積んだ Quadra から。
メモリ上の自己書き換えやコード生成は今でも結構使われていて別に問題のある技法でもない。
他により妥当な方法があるのに使いたがるのは問題ある行為かもしれないけど。
397:仕様書無しさん
07/07/18 18:36:28
今はメモリ使い回すメリットがほとんどないだろ
メモリが小さかった時代には一つのひゅほうだったかもしれないが
398:仕様書無しさん
07/07/18 19:09:25
ひゅほうでんせつ
399:仕様書無しさん
07/07/18 21:19:00
最近は
データ領域:書き換え○ 実行×
コード領域:書き換え× 実行○
みたいなことやるしな。
400:仕様書無しさん
07/07/19 00:50:51
LISPだと自己書き換えってどういう感じに捉えられているんだろう？
401:仕様書無しさん
07/07/19 01:00:31
すべてがS式なんだから、コード書き換えもアリとは思う。
けど、アルゴリズムとしてトリッキーに過ぎる感はあるな。
で、そういう感覚もっていることは、PGとしては大事。
402:仕様書無しさん
07/07/19 01:11:23
longjumpで書き換えまくるのは普通だし
今でもそうゆうコード書いてる。
書くなって言われるけどなんでって思う
403:仕様書無しさん
07/07/19 01:18:32
テクニックとしては面白いんだけどな。バッファオーバーラン攻撃の基本だし。
だからといって、製品の中に自己書き換えを組み込むのは勘弁。動的に書き換わるコードは追跡が難しすぎる。
動的コード生成にしても、機械語直接生成よりもスクリプトを吐く方が簡単に済みそう。
404:仕様書無しさん
07/07/19 01:26:53
>>402
longjmpは自己書き換えしなくても作れるだろう。
ものすげー変なCPUまで把握してないが。
405:仕様書無しさん
07/07/19 02:18:03
コード書き換えはマルチタスクで動かせないだろ
406:仕様書無しさん
07/07/19 06:58:17
iTRON準拠のマルチタスク環境では動いていたというか動かしていたよ。
407:仕様書無しさん
07/07/19 10:06:50
>>405
>コード書き換え
と
>マルチタスク
に、まるで相関がない。
408:仕様書無しさん
07/07/19 15:50:24
自己書き換えはすたれてるけど、コード生成自体は ATL のサンクとか
JIT コンパイラ的技法とかで必要に応じて使われているよね。
409:仕様書無しさん
07/07/19 18:43:12
HaskellのコンパイラがDEP（データ実行防止）に引っかかった。
HaskellはHaskell自身で書かれているらしいから、どうもコード生成or自己書き換えしてるっぽい。
まだまだ現役だな。
410:仕様書無しさん
07/07/19 19:24:16
>>409
>>408
>JIT コンパイラ的技法
411:仕様書無しさん
07/07/19 22:37:16
ふとリコンフィギュラブルを思い出した。
URLﾘﾝｸ(www.atmarkit.co.jp)
412:仕様書無しさん
07/07/19 23:57:15
ふとりプリキュアに見えた
413:仕様書無しさん
07/07/20 00:28:50
>>412
病みすぎ
414:仕様書無しさん
07/07/20 14:03:15
うーん。「自己変更コード」とか「自己書き換えコード」とか呼ばれているけど。
誰も「自己改竄コード」とは呼ばないな。
415:仕様書無しさん
07/07/20 14:08:29
普通は悪用目的の書き換えを指すんじゃまいか？改竄て。
416:仕様書無しさん
07/07/20 23:08:58
進化するコード
417:仕様書無しさん
07/07/20 23:32:27
>>414-416
だんだんウィルスになってないか？
418:仕様書無しさん
07/07/21 00:35:34
暴走してウィルス化するなんていかにも漫画的なシチュエーションだ
419:仕様書無しさん
07/07/21 01:11:30
ソースが貼られず自称上級者の醜い言い争いばっかりじゃねーか
もっとトンデモソースで俺を癒してくれよ
420:仕様書無しさん
07/07/21 03:18:33
switch( cValue ) {
case 0:
hogehoge( );
break;
case 1:
・・・
case 255:
hugahuga( );
break;
default:
ASSERT( False );
break;
}
421:仕様書無しさん
07/07/21 05:19:36
これでcValueがucharなら笑えるな
422:仕様書無しさん
07/07/21 08:40:07
関数名が func0()～func255() じゃないってことは、コボラーじゃないのか....
423:仕様書無しさん
07/07/21 09:22:02
while( flg == TRUE){
switch( hoge){
case 1:
hage1();
hoge = 2;
break;
case 2:
hage2();
hoge = 5;
break;
・・・・・
case 25:
hage25();
hoge = 10;
break;
}
}
こんな感じのswitch文が3つあってループの関数は1000行くらいある。
当然コメントも仕様書もマニュアルも何もない。あるのはソースだけ。
VC++1.52でコンパイルするのだが、改変して行数が増えるとコンパイラがコンパイルしてくれない。
case12 とかで hoge = 0 とかしてるのと、あっちこっちジャンプしながら
最終的にcase12にたどり着くので無限ループにはなっておらず、しょっちゅうトラブるが、大抵はなんとなく動いている。
だけど何で動いているのか分からない上に、改造しようにも手がつけられない。
424:423
07/07/21 09:24:38
あ、case 12ではhoge=0じゃなくてflg=FALSEだった。
ま、5年ほど前に面倒見させられたソースです。
その部分はごっそり書き直したけどね。
425:仕様書無しさん
07/07/21 09:25:14
>>423
コードの意味がわからないってのはわかるが、
改変して行数が増えるとコンパイラが通らないって何？
VC++1.52だと最大行数の制限があるの？
426:仕様書無しさん
07/07/21 09:27:51
>>423
パーサーとかそんな感じで作るけど
#ifdef DEB_PRINTしこんで
コールグラフ作ればいいだろ。
んで文法作ればいい。おそらく処理しきれない
例外を見過ごして別の規則に遷移してるだけ
じゃねーの？
427:仕様書無しさん
07/07/21 09:28:44
１６ビットの制限とかあるんじゃね？
428:仕様書無しさん
07/07/21 09:33:31
>423
hogeX()や各case値に意味あるんだろうから、そっから状態遷移図でも描いて見れば。
429:仕様書無しさん
07/07/21 09:46:32
>>428
hogeX()や各case値に意味あるケースは稀じゃね？ｗ
430:仕様書無しさん
07/07/21 09:49:31
そうなのかｗ
431:仕様書無しさん
07/07/21 09:55:27
caseでのコードではこんなのあったな＠Java
メンテしろと言われたけど、拒否したら左遷された
後任は自殺未遂したらしいけど・・・
うろ覚え
int i = 20;
label WHILE_LABEL;
while(true) {
switch (i) {
case -3:
i = func3();
break WHILE_LABEL;
case -2:
i = func3();
break WHILE_LABEL;
case -1:
i = func3();
break WHILE_LABEL;
// 中略
case 50:
i = func50();
break;
default:
i = func0();
}
}
423のに似ているけど戻り値がリザルトコードになっていてマジでカオス
432:仕様書無しさん
07/07/21 10:25:39
オブジェクト指向はおろか構造化すら怪しいグラマが必死に考え出したコードっぽいな。
こんなコードが随所にあるなら431は拒否して正解だ。
433:431
07/07/21 10:31:32
随所どころか、辛うじて理解できた一部だよ
結局、ほとんど理解できなかった
434:仕様書無しさん
07/07/21 10:42:34
例はちょっと書けないけど最強にカオスなコードならあるぞ
make
yaccでmake+コード自動生成
生成コードmake
yaccでmake+コード自動生成
・・・
これが15回も繰り返されるカオスなコードあったよ
435:仕様書無しさん
07/07/21 11:58:45
>>434
それは何のプログラムなの？
436:423
07/07/21 12:10:28
>>425
1関数のサイズの上限が決まってたと思う
>>426,428
何年も前に終わった仕事について批判されてもなぁ・・・
大体1関数が1000行って時点で何かおかしいんだから直して当然だろ
437:仕様書無しさん
07/07/21 13:08:52
関数ってどんなに多く書いても数百行で済まないか？
絶対処理分割できるぞ
438:仕様書無しさん
07/07/21 14:23:36
>>436
関数の制限じゃなくてswitchの制限だと思うよ。
439:仕様書無しさん
07/07/21 14:51:16
>>437
普通に手続き言語をやってくれば、どんなに長くても数百行なんだが、
大昔のPLCしか触ったことない奴だとだらだら書く事しか知らなくて、1000行とかいく事がある。
440:仕様書無しさん
07/07/21 16:49:09
実行される行数が50を超えたらそれは長すぎ。
441:仕様書無しさん
07/07/21 16:52:49
>>440
実行される行数ってコンパイルした後の話か？
442:仕様書無しさん
07/07/21 17:38:24
実行後の行数なんて意識する必要ないだろ、５０行超えたら読みにくいだけ
443:仕様書無しさん
07/07/21 17:43:39
別にコードなんて動けばどーでもいいんだよ
オマイラだってどうせ適当に書いて後は野となれ山となれだろう？
この会社辞めようと思ったソースコードなんてお高くとまってないで
正直になれよ
プログラムなんてちゃんと動けばそれでいいんだよ
444:仕様書無しさん
07/07/21 17:44:18
煽り乙
445:仕様書無しさん
07/07/21 17:54:01
>>443
中国産は長い・意味不明・動かないの3拍子揃ってるぜｗ
446:仕様書無しさん
07/07/21 18:05:21
>>445
コメントが中国語なら尚可。