5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

この会社辞めようと思ったソースコード#A

1 :仕様書無しさん:03/04/10 20:23
この会社辞めようと思ったソースコード。
プログラマとして幻滅するソースコード。
プログラマを悩ませるソースコード。
COBOL ライクなソースコード。(゚д゚)マズー
をつらつらと綴っていって頂戴。

ちなみにここは質問スレじゃないよ。
技術的な質問がしたいならム板に逝って。

前スレ
この会社辞めようと思ったソースコード#9
http://pc.2ch.net/test/read.cgi/prog/1045401372/

2 :仕様書無しさん:03/04/10 20:24
■過去スレ
この会社辞めようと思ったソースコード
#1http://mentai.2ch.net/prog/kako/997/997104873.html
#2http://pc.2ch.net/prog/kako/1001/10010/1001076034.html
#3http://pc.2ch.net/prog/kako/1015/10158/1015861447.html
#4http://pc.2ch.net/prog/kako/1021/10215/1021560641.html
#5http://pc.2ch.net/prog/kako/1029/10291/1029120005.html
#6http://pc.2ch.net/prog/kako/1029/10291/1029120005.html
#7http://pc.2ch.net/prog/kako/1036/10367/1036779521.html
#8http://pc.2ch.net/test/read.cgi/prog/1040451049/(未HTML化)

■関連スレ
この会社辞めようと思った上司の一言#8
http://pc.2ch.net/test/read.cgi/prog/1046862372/


3 :仕様書無しさん:03/04/10 20:28
3getできたら、情報処理試験まで2ch止める!

4 :仕様書無しさん:03/04/10 20:31
Aってなんだよ?

5 :仕様書無しさん:03/04/10 20:32
16進?

6 :仕様書無しさん:03/04/10 20:35
いや・・つられないでヨちょっと・・

7 :仕様書無しさん:03/04/10 20:37
いや今日はうれしいから何でもありかな手・・・

8 :仕様書無しさん:03/04/10 20:38
>>5
どうかしたのか?


9 :5:03/04/10 20:39
番茶に鰹節入れて飲む生活からの脱退です。

10 :仕様書無しさん:03/04/10 20:42
今までの生活を想像してなんかワロタよ

11 :5:03/04/10 20:43
今日はうれしくて味の素も入れました

12 :剛万太郎 ◆OPb3r6Vs1g :03/04/10 20:53
>>11
http://www.kit.hi-ho.ne.jp/kokumin-shinbun/090901ajinomoto.html
くだらない記事だが読んでみて

13 :5:03/04/10 20:58
國民新聞・・・。なんか読めない漢字だらけ

14 :仕様書無しさん:03/04/10 22:40
>>12
つーか、人口増加と物価上昇で補正すると全然違うグラフになるだろ、コレ...

15 :仕様書無しさん:03/04/10 23:15
「関数の長さ(ステップ数)は短めに」ってよく言われることなんだけど、
一行の長さは大体、何桁(カラム)まで許せる?

漏れの基準としては、100桁くらいまでに収まるようプログラムを
記述するようにしてるんだけど(ちなみにコメントを横に書くときは49桁目に
揃えるように気を付けてる)、今日引き継ぎで渡されたソースをサラッと
眺めてみると、異常ともいえるくらい「横方向」に長いんだ、コレが。

プログラム記述が100桁超というのはまだ許せるとして(それでもif文が
延々横方向に伸びてるのは見づらい)、コメントが300桁超というソースは
始めて見たよ。
コメントを最後まで読むために、ずっと横にスクロールしなきゃなんないし、
作った香具師はいったいどんなエディタ使っていたんだ。(w

見やすくするためにまず整形しなきゃ、まずはそれからだな。
くそっ、ポインタの'*'も型の方に付いていたり、変数のほうについていたり
ヘタすりゃ中間にあるぞ・・・なんだこりゃ? (激鬱




16 :仕様書無しさん:03/04/10 23:36
>15 72カラムですが何か?

17 :仕様書無しさん:03/04/10 23:46
>>15
>作った香具師はいったいどんなエディタ使っていたんだ。(w
端で折り返せば

18 :仕様書無しさん:03/04/10 23:47
integer CPP_Util_P6250L3270P::Member295(xinteger iIndeString,const String* pszStr)
{
  //取得
  String *pTmp = new String [ ( util_3269_g4_string( m_pBuffer ) + util_3269_g4_string( pszStr ) ) + 1];
  memset( pTmp, 0, ( util_3269_g4_string( m_pBuffer ) + util_3269_g4_string( pszStr ) ));
  //チェック
  if(iIndeString != 0 )
  {
  //比較
  if(util_3277_g4_string(m_pBuffer[iIndeString]) == ok )
  {
   //減算
   decliment( iIndeString -- );
  }
  //比較
  else if (util_3277_g4_string( m_pBuffer[iIndeString - 1 ] ) == ok)
  {
   //加算
   incliment( iIndeString );


19 :18続き:03/04/10 23:48
  }
  }
  //比較 
  if( iIndeString >= util_3269_g4_string( m_pBuffer ))
  {
   //連結
   util_3270_g4_string( pTmp, m_pBuffer );
   util_3279_g4_string( pTmp, pszStr );
  }
  //非該当
  else
  {
   String *ppBuffer = m_pBuffer;
   if(iIndeString !=0 )
     util_3271_g4_string( pTmp,m_pBuffer,iIndeString);
   //連結
   ppBuffer += iIndeString;
   //連結
   util_3279_g4_string( pTmp, pszStr );
   //連結
   util_3279_g4_string( pTmp, ppBuffer );
  }
  //連結
  *this = pTmp;
  //解放
  util_2057_p14_memory( pTmp );
  //返戻
  return util_3269_g4_string( m_pBuffer );
}


20 :18:03/04/10 23:52
解説

Stringはcharと等価
integerはintと等価
xintegerはunsigned intと等価
okはtrueと等価
util_3269_g4_stringはstrlenと等価(だったような気がする)
util_3270_g4_stringはstrcpyと等価(だったような気がする)
util_3279_g4_stringはstrcatと等価(だったような気がする)
util_3271_g4_stringはstrncpyと等価(だったような気がする)
util_3277_g4_stringは不明

もう辞めた会社だし、いいや。

21 :仕様書無しさん:03/04/11 00:04
int getValue(){
(中略)
return ret;
return 0;
}

22 :仕様書無しさん:03/04/11 00:07
なんだかコボルくさいな・・・
関数番号?を間違えるととんでもない結果に。 ((;゚Д゚)ガクガクブルブル

23 :仕様書無しさん:03/04/11 00:19
コメントの意味不明さとインデントの平坦さがイカす

24 :( ´∀`)< ヌルポ :03/04/11 00:24
設計者の意図がワカラン。
なんのメリットがあるのだ。

とりあえず、2行目のmemsetのlengthは、+1したほうが幸せかも。


25 :仕様書無しさん:03/04/11 01:15
この間見たコード。字句解析系。

書いた人は、
「速度優先で最適化すると、速過ぎてうまく動かないんですよね。
 「コードサイズ優先」の最適化だと、うまく動くんですけど」
とかゆってた。
void C::foo() {
  char tmp;
  CString a = m_str;
  int l = strlen( a ); //←なぜかstrlen2回
  for( l = strlen(a); l > 0; i-- ) {
    strcpy( &tmp, a.Right(l).Left(1) ); // tmpのサイズ足りない。
    // tmpを使って、何か処理
  }
}

どこから突っ込んでいいのか解んなくて、
とりあえず、「tmpをtmp[2]にして、値を参照するときはtmp[0]にして下さい」
ってだけゆっておいた。

>>派遣社員のKさん、この書き込み見ても、笑ってゆるして。

26 :仕様書無しさん:03/04/11 01:18
今日コード変換クラスとやらのクラス設計書を見せてもらったんだが
1コードずつ定数きってあった。
さすがにげんなり。
まぁ扱う文字が限られているっていうのもあるけど・・


27 :26:03/04/11 01:18
文字コードのことね。ごめん。


28 :仕様書無しさん:03/04/11 01:33
>>25
おれもその会社で働かせて下さい
そこならトップを取れそうな気がしまつ。

29 :仕様書無しさん:03/04/11 02:27
>>18
アルゴリズムの隠蔽のためですか?
 でも納入されたソースがこれだったら客は切れるのでは?

30 :仕様書無しさん:03/04/11 04:41
コーディング規約の「変数には必ずプレフィクスを付けろ」と「コードに修正
を加えるときは、修正元をコメントとして残せ」のコンボは強烈だ。

short型の変数をlong型に修正する必要があったんだが、それはもう
見るも無残なコードになった。



31 :仕様書無しさん:03/04/11 04:45
>>30
cvs教えてやれ

32 :仕様書無しさん:03/04/11 06:29
>>25
tmp = *(a.Right(l).Left(1));
とか書いたらいいんじゃない?

いっそのこと
char *a = m_str + strlen(m_str);
for (; a-- > m_str;) {
tmp = *a;
}
とか。

33 :仕様書無しさん:03/04/11 06:56
>>30
shortやlong等の数値のプレフィックスはnとかにまとめれば問題ない。

34 :仕様書無しさん:03/04/11 07:57
>30
これに懲りて、次からは生の型を使わず、必ず typtedefしておくこった

35 :仕様書無しさん:03/04/11 09:58
header 中の typedef と衝突するのが嫌い。
コモン header に勝手に追加する奴がいるとね。
(勝手に追加させてる点でプロジェクト進行が既に破綻してるのか)

36 :仕様書無しさん:03/04/11 10:05
コーディング規約で「ファイルが多くなって判りづらくなるので、ヘッダファイル使用禁止」という
プロジェクトがあったっけなー


37 :仕様書無しさん:03/04/11 10:33
>>36
「原則」っていう言葉を知らない人間が、コーディング規約作ると悲惨な事になる。
馬鹿は黙ってろ。って事だな。

38 :仕様書無しさん:03/04/11 10:42
>>36
おれもその会社で働かせて下さい
そこならトップを取れそうな気がしまつ。


39 :仕様書無しさん:03/04/11 10:57
>>38
馬鹿?そーゆう会社はそーゆう文化のトップが居るんぢょ。


40 :#:03/04/11 11:00
>>39
つか、>38はそういう文化ではトップクラスなんだろ。

41 :仕様書無しさん:03/04/11 11:01
>>28, 38
2回目でワロタ。
参照先を変えるだけで何度でも使える再利用可能なレスだな。

42 :仕様書無しさん:03/04/11 11:32
俺のコードってコボラーの書いた
Cなんだな〜と思ったよ。このスレみて。
もっと勉強します。
いままで書いたコードを引き継いだ皆さん
本当すみません。

43 :仕様書無しさん:03/04/11 19:36
勉強しなくていい
転職しろ

もうソース書くな

44 :仕様書無しさん:03/04/11 21:55
>42
引き継いだ香具師も元コボラーなら問題ないかも

45 :仕様書無しさん:03/04/11 23:33
>>30
short -> long 2階級特進の変更だけでもDQNの臭い...

46 :仕様書無しさん:03/04/11 23:42
>>45
2階級って何が?

short=16bit
long=32bit
は確定だよな。

24bitの型って何?





47 :仕様書無しさん:03/04/12 00:06
どっちもどっち

48 :仕様書無しさん:03/04/12 00:18
2byte -> 2階級 ?

49 :仕様書無しさん:03/04/12 00:18
>>46
勝手に確定させないように。
2階級ってのは
sizeof(short) ≦ sizeof(int) ≦ sizeof(long)
つーこっちゃないの?

50 :仕様書無しさん:03/04/12 00:24
あれ?shortとlongはC言語(という前提だが)では
確定されてなかったっけ?(;´Д`)

51 :仕様書無しさん:03/04/12 00:27
short=16bit
long=32bit
int=CPU依存

52 :仕様書無しさん:03/04/12 00:30
次のWindowsはintが64bitになるのかナ


53 :仕様書無しさん:03/04/12 00:42
long よりでかいintステキ。
CPUが64bitなら16bit数値や32bit数値は速度低下の原因ではないだろうか。



54 :仕様書無しさん:03/04/12 00:52
>>51
short と long の bit長は決まってない。

55 :仕様書無しさん:03/04/12 00:55
たしかに >>46 >>51 のような会話をしている会社はやめたくなるな。

56 :仕様書無しさん:03/04/12 01:19
ANSI Cの規約とは違うが、
現実問題としてshort=16bit、long=32bitを想定したプログラムがあまりにも多く、
これを変えるとバグるプログラムが続出することが予想されるため、
64bit整数は別の名前(long long型とか)にしようという動きはある。

57 :名無しさん@Emacs:03/04/12 01:27
>>56
> ANSI Cの規約とは違うが、
> 現実問題としてshort=16bit、long=32bitを想定したプログラムがあまりにも多く、
> これを変えるとバグるプログラムが続出することが予想されるため、
> 64bit整数は別の名前(long long型とか)にしようという動きはある。

というか、すでにそうなってますよ。
http://seclan.dll.jp/c99d/c99d05.htm

58 :仕様書無しさん:03/04/12 01:40
Public Sub 帳票U()
On Error Goto エラー
・・・
エラー:
End Sub



59 :仕様書無しさん:03/04/12 01:44
Select * From 寺Oさんクエリー

って、寺Oさんって誰だよー!!

60 :仕様書無しさん:03/04/12 01:45
>>59
日立の(さ)技師 寺Oさんじゃないの?

61 :仕様書無しさん:03/04/12 01:48
100 CLS:CLEAR:SCREEN 2,,,1
110 OUT &H5AE,2

今時BASICはねーだろ。(半導体製造装置)
しかもうちらに投げてよこすんじゃねぇ!
行番号付BASICなんて何年ぶりなんだ。
もはや中古市場でも見当たらんパソコンで打ち込むのはいやじゃ!!

62 :仕様書無しさん:03/04/12 02:01
>>55がやめたくなる会社ばっかりだと思うが実際
つか>>55がどんな優秀な会社にいるのか気になる

63 :!で参照する言語氏ね:03/04/12 02:08
Me!タイマー0.Enable = False
・・
Me!タイマー49.Enable = True


64 :仕様書無しさん ◆Rhvbchu7bg :03/04/12 03:55
>>63
その前に、全角のObject名称の方が俺は嫌だ。(w

65 :仕様書無しさん:03/04/12 05:56
>>63
つーか、あんたが無知晒しているだけなんだが。
参照はピリオド、コレクションから指定したキーの要素を取得するときは!
その例ではコレクション(MeのControls)は既定なので省略されているが。
別に参照を!でやっているわけじゃない。

66 :仕様書無しさん:03/04/12 07:36
>>57
つーかまんどくせぇから_int64とかってVC見たくサイズを明記するように
したらいいのに。。

67 :仕様書無しさん:03/04/12 10:01
>>66
それもある。
http://seclan.dll.jp/c99d/c99d09.htm#dt19990621

はやいとこすべてのCコンパイラがC99準拠になってほしいものだ。

68 :仕様書無しさん:03/04/12 11:21
>>56 >>66 みたいなこと言ってる奴とも仕事したくねぇなぁ…。
準拠度はともかく、C99 の内容ぐらい理解しとけよ…。

69 :CODASYL:03/04/12 12:07
COBOL85の内容なら理解してます!(ビシッ

70 :57:03/04/12 12:57
>>66
俺のまわりでは
#include <inttypes.h>
してから int32_t とか uintptr_t とかを使うのが標準だな。

C99で int32_t とかを定義しているインクルードファイルは stdint.h だが、
これは SUSv2(The Single UNIX Specification, Version 2) には
残念ながら存在しない。

でも、代わりにSUSv2では inttypes.h がこれらの整数型を定義している。
http://www.fsmlabs.com/developers/docs/html/susv2/xsh/inttypes.h.html
しかも inttypes.h はC99にも存在し、これは自動的に stdint.h を読み込む
ように定義されている。

でことで、inttypes.h をインクルードしておけば、C99準拠の環境はもちろん、
ほとんどのUNIX likeな環境でも int32_t などの整数型が使える。
お勧めでっせ。


71 :仕様書無しさん:03/04/13 00:05
stdint.h はC委員会が捏造したヘッダで、C99ができるまでどこにも存在しなかった、という都市伝説を聞いたことがあるぞ。

72 :仕様書無しさん:03/04/13 00:47
45です。
Solarisの64ビットコンパイラでしばらく作業してましたので頭の中が
以下の様になってました。
short 2Byte
int 4Byte
long 8Byte
32ビットコンパイラなら int == long ですね。
駄目だ詩嚢。

73 :仕様書無しさん:03/04/13 01:10
荒らして!
http://ip.tosp.co.jp/i.asp?i=rorimani

74 :仕様書無しさん:03/04/13 02:21
intやlongのビット長が気になるようなコード、書いたことねーよ!

75 :仕様書無しさん:03/04/13 02:40
良く分かってないんだけど、そらりすは long long ではなく
long が 8 バイト長整数なの?

76 :仕様書無しさん:03/04/13 03:23
>64 同意
>65
63が会社辞める代わり65よ引継ぎいてやれ。




77 :仕様書無しさん:03/04/13 04:17
>>74
それはintの範囲で収まる数字しか使ってないだけだろ。

78 :仕様書無しさん:03/04/13 04:37
>63は49個のタイマーで辞めたいのかと。

79 :仕様書無しさん:03/04/13 12:00
>>78 名前欄見ろよ。

80 :仕様書無しさん:03/04/13 12:57
>>18
incliment()
decliment()
には誰もつっこまないのね、、、。


81 :仕様書無しさん:03/04/13 16:04
>>78
50個ではないのか?

82 :仕様書無しさん:03/04/13 16:23
>>75
 Solaris の純正コンパイラには64ビットコードを出力するオプションが
あるんよ。(ディフォルトは32ビット)
 で64ビット時は long が8バイトになります。
 long long は使ったないなぁ...有るかも知れんが...
 HP-UX のコンパイラには有った記憶が有る。

 でも long long って「にょろにょろ」だよね。
 なんかダセ!!



 

83 :75:03/04/13 17:12
>>82
どもです。
あまり突き詰めて考えたことが無かったから、変だったらツッコんでほしいけど。
64 bit コンパイル時に
int = そのシステムのワード長って意味で 64bit 長になるのなら分かるけど
32 bit 長のままで
long = 64bit 長, int 32bit 長になるのは…正直感覚がついていけない。

# long long int っていうのは確かに名前はダサいと思うですよ。


84 :75:03/04/13 17:26
と、K&R 見てみたら、

16≦intのbit長
32≦longのbit長

shortのbit長 ≦ intのbit長 ≦ long のbit長
intは“通常は”特定の計算機に自然な大きさ

なのね。なんとなく理由が分かった。
(現実にはそうも言ってられない事実もあるけど)


85 :仕様書無しさん:03/04/13 17:30


86 :仕様書無しさん:03/04/13 18:13
                             >>1
                          __↓
                         /    ̄ ̄ー―-_
         ▲               )           /
        /ハハハ\             |\|\|\___イ
.     /      \            | /\  /\lllll|
   /   _   _  \          | /・\ /・\ |
.   |   ⊂⊃ ⊂⊃  |          |   ̄/、  ̄ ̄  )
  (|    ∴  ∪ ∴ |             |    ̄     /
   \      <=>  /           ヽ  <三>  /
    \____/               ヽ    /
          ∧               /| \/
  ,r‐‐‐‐‐‐‐‐‐'´ `゙‐‐‐‐‐‐‐‐‐‐、r‐‐‐‐‐‐'´ `゙‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐、
 |  立て逃げか。        |  そんなに卑怯者、卑怯者と |
 i  やっぱり君は卑怯者だな。i  言わないでくれよ〜(泣    i


87 :仕様書無しさん:03/04/13 19:04
>>75==>>83はJavaを知らないのか。

88 :75:03/04/13 21:00
>>87
ええ、知りません。でも、一応生きてまつ。

89 :仕様書無しさん:03/04/13 22:18
javaなんか役に立たない分野もあるから大丈夫だ

90 :仕様書無しさん:03/04/14 01:40
っていうか、どっからどう見てもJAVAの話なんぞしてねぇだろうに、、、
おまえは日本語しらんのか?

91 :仕様書無しさん:03/04/14 02:30
>>90
JAVA では long は 64bit長 なのだと
勉強する機会を与えてくれたと思ってるですよ。

92 :75:03/04/14 03:04
というか、こちらさんスゴくわかりやすくてよかったでつ。

ttp://msugai.fc2web.com/java/

さっそく make 時のソース自動生成処理の一部を置き換えて
みようかと思うです。

93 :仕様書無しさん:03/04/14 08:49
long longって、最初のlongが形容詞で後のlongは名詞なの?

94 :仕様書無しさん:03/04/14 09:46
>>93
前半が副詞で、後半が動詞。
(長く、切望する)

95 :仕様書無しさん:03/04/14 10:01
long long agoと一緒

96 :仕様書無しさん:03/04/14 10:41
Please Please Me と一緒

97 :仕様書無しさん:03/04/14 10:41
あれだろ、イースター島の未解読文字だよな。

98 :仕様書無しさん:03/04/14 12:07
No No Darlin' とも同じだな

99 :仕様書無しさん:03/04/14 12:26
>>83
その指摘は正しいと思う。私も初めはそう思ったので...
でもそうすると4バイト整数が無くなり不便なので int を4バイトに
したのではと邪推してみました。

100 :仕様書無しさん:03/04/14 13:03
>>97
その指摘は正しいと思う。私も初めはそう思ったので...
でもそうするとロングがロンゴになり解読不能なので ヨハネの黙示録を解読しようと
したのではとキバヤシになってみました。

101 :仕様書無しさん:03/04/14 13:37
ここなら入れるさ
.      / ̄\  +.  ∧_∧アハハハ テンゴクヘイッチャウヨー  +
  イクナヨー( ´∀`)    (´∀` )  
      (つ  つ     (つ  つ■
.   +  ( ヽノ      ( ヽノ        +
      し(_)      し(_)

http://society.2ch.net/test/read.cgi/traf/1046749189/l50
http://tmp.2ch.net/test/read.cgi/company/1046775680/l50
田中真紀子と親密な日本ロジテム(一部上場)で違法残業しすぎによる過労死者


102 :仕様書無しさん:03/04/14 13:40

  (⌒\ / ̄\  +
   \ヽ( ´∀`)  ザンギョウダイヨコセ  
    (m   ⌒\        +
 +    ノ    / /   +
     (   ∧ ∧ 
   ヘ丿 ∩Д` )         +
   (ヽ_ノゝ _ノ   ■
 ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄

103 :仕様書無しさん:03/04/14 13:42
>>100
違うよ。それは、「し、のたうちまわる」とかいうのだろ。

104 :仕様書無しさん:03/04/14 13:47
火の玉食う

105 :仕様書無しさん:03/04/14 20:13
>>86
さくらももこ?

106 :仕様書無しさん:03/04/15 01:42
ウチの会社、booleanの値が3つもあるぞ

107 :仕様書無しさん:03/04/15 01:51
ブール代数を真っ向から否定してますね

108 :仕様書無しさん:03/04/15 02:35
true false ????

109 :仕様書無しさん:03/04/15 03:52
http://www.rak2.jp/town/user/sevenstar777/
↑ココの掲示板で(もう消されたようだが)
「2ちゃんねるって知ってる?そこにいる奴等キ○ガイばっかりだよ(笑)」
みたいな発言をガマ(だったかな?)ってやつがしてた。
http://www.rak2.jp/town/user/sevenstar777/

110 :仕様書無しさん:03/04/15 09:38
TRUE と FALSE と ハイインピーダンス

111 :仕様書無しさん:03/04/15 09:59
3値論理(trueとfalseとundef)というのもあるにはあるが……

112 :はしのえみ好きー:03/04/15 10:10
「booleanの値が」って限定してるからなあ

113 :仕様書無しさん:03/04/15 10:15
>>106
OracleのBOOLEAN型はTRUE、FALSE、NULLの3値を持ちますが何か?

114 :仕様書無しさん:03/04/15 10:20
ま、世の中白と黒だけじゃ片付かないってこった

115 :仕様書無しさん:03/04/15 12:50
TRUE,FALSE,限りなくFALSEに近いTRUE

116 :仕様書無しさん:03/04/15 12:59
新ネタ出ないね。
もうネタ切れなんですかね...
保守 age

117 :仕様書無しさん:03/04/15 13:02
数学でいうbool代数は2値とは限りません。0,1の2値は必須だというだけです。

118 :仕様書無しさん:03/04/15 13:09
返り値がBOOLで、でもその数値をフラグとして扱わなきゃいけない場合とかもあるしね

119 :仕様書無しさん:03/04/15 19:01
そりゃ設計が腐ってるだけだ(藁)

120 :はしのえみ好きー:03/04/15 19:43
>>117
すまん。二値なのは二元bool代数だったな。逝ってきます。

121 :仕様書無しさん:03/04/16 09:37
>119
Microsoftのプログラムを腐ってると言えるあなたの実力を知りたいなあ

・・・・ま、腐ってないとは言えんけど

122 :!119:03/04/17 00:08
>121
アプリの設計の事を指してるんじゃないの?

123 :仕様書無しさん:03/04/17 00:55
>121
Win32 APIにそんなのあったような気もするけど、
どこの製品だろうとやっぱりその仕様は腐ってるだろう。
ま、あれだけでかいんだ。腐った部分の100個や200個あるでしょ。

124 :仕様書無しさん:03/04/17 09:15
最近見たのだとTrackPopupMenuとかそうだな。

ま、False=0、True=0以外ってなってれば、それをフラグ扱いしても
別になんにもおかしくないと思うけど、俺は。

でもBooleanの値が3つってのは嫌だ。

125 :山崎渉:03/04/17 11:59
(^^)

126 :仕様書無しさん:03/04/19 18:13
さっき、古くからあるソースをコンパイルしたら
3桁にのぼると思われる数のwarningが…。

127 :仕様書無しさん:03/04/19 18:18
>>126
それは、昔のコンパイラと現在のコンパイラの、
解釈のちがいでつ。

128 :仕様書無しさん:03/04/19 18:26
>>113
そりは誤解。
NULL はそもそも値を戻さない、つまり値ではない。

129 :仕様書無しさん:03/04/19 18:49
> ま、False=0、True=0以外ってなってれば、それをフラグ扱いしても
「以外」は「=を含む」という解釈が一般的だが、0と非0にはそれは
適用できませんね。False=0, True=not(False)でないと安心できません。

130 :仕様書無しさん:03/04/19 19:18
>>129
>「以外」は「=を含む」という解釈が一般的だが・・

以上、以下なら「=を含む」のは当然だが、以外でも同じ扱いで考えると、
全く日本語が成立しなくなるだろ。

131 :goo国語辞典より:03/04/19 19:35
いじょう ―じやう 1 【以上/▼已上】
(名)
(1)数量・程度などを表す名詞の下に付けて、それより多いこと、また、優れていることを表す。
数量を表す用法では、その基準点を含む。


いか 1 【以下/▼已下】
〔古くは「いげ」とも〕
(1)数量・程度などを表す名詞の下に付けて、それより少ないこと、または劣っていることを表す。
数量を表す用法では、その基準点を含む。


いがい ―ぐわい 1 【以外】
(1)そのほかであること。そのほかのもの。
「日曜―は外出している」「そうする―に手がない」
(2)それより外側であること。
「巡査の視線―に免るることを得ざりしなり/夜行巡査(鏡花)」


132 :仕様書無しさん:03/04/19 20:47
>>129
>「以外」は「=を含む」という解釈が一般的だが
    _, ._
  ( ゚ Д゚)

133 :仕様書無しさん:03/04/19 21:15
>>129
(゜Д゜)ハァ?
0を含むか否かって話しだろ。なんで=が...

134 :仕様書無しさん:03/04/19 21:20
この会社辞めようと思った社員=>>129

135 :仕様書無しさん:03/04/19 21:29
2ちゃんねるをやめようとおもいますた

136 :仕様書無しさん:03/04/19 22:59
おめあら、釣られ過ぎ(ワラ


137 :仕様書無しさん:03/04/19 23:04
おめこの粗探し、略しておめあら

138 :仕様書無しさん:03/04/19 23:13
>>129=>>136 ( ´,_ゝ`)プッ

139 :仕様書無しさん:03/04/19 23:23
>>138
    _, ._
  ( ゚ Д゚)


140 :仕様書無しさん:03/04/19 23:49
値ではなく、「真」か「偽」 本来の解釈でいいんじゃないの。


141 :仕様書無しさん:03/04/20 00:11
>>129
>「以外」は「=を含む」という解釈が一般的だが

(゚д゚) それは意外だな。



あっ! 勿論、「意外」は「一般的なこと」だよね。うん。

142 :仕様書無しさん:03/04/20 00:14
false、大false、統計学。

143 :仕様書無しさん:03/04/20 00:53
>>124
TrackPopupMenuの戻り値ってなんでBOOLなんだろう。
IDを返すんだからUINTでよさそうな気がするんだが。


144 :仕様書無しさん:03/04/20 00:57

俺は良く
memset(p, '\0', sizeog(hoge));
と書くのだが、

人の書いたソースで
memset(p, NULL, sizeog(hoge));
というのを見て悩んでます。

NULLってこーゆー使い方もアリなん?


145 :仕様書無しさん:03/04/20 00:59
sizeog(hoge);

146 :仕様書無しさん:03/04/20 01:00
問題ない。でも普通は前者

147 :仕様書無しさん:03/04/20 01:06
あと、ずっと気になってんのが

(char *)NULL

みたいに、NULLにキャストするやつ。


キャストなんかしなくたってヘッチャラなのが
NULLの長所じゃないのか?

NULLってもっと自由なもんじゃぁないのか??


148 :仕様書無しさん:03/04/20 01:07
コンパイラから見たらどちらも
memset(p, 0, sizeog(hoge));

149 :仕様書無しさん:03/04/20 01:26
>>147
NULL が引数の型が明示されていない関数の引数として書かれていて、
かつ、 #define NULL 0 だった場合は妙なことになるかも。

# 旧方式の関数宣言の場合とか、可変長の引数をとる関数の可変長部分の引数の場合とか。
# もちろんプロトタイプ宣言が無い場合も。

150 :仕様書無しさん:03/04/20 01:32
>>143
Win16では成否を返すのみだった名残では。
IDが欲しいケースって滅多に無いなぁ、どんな時に使う?

151 :仕様書無しさん:03/04/20 01:52
>>150
MSDN曰く

>uFlags パラメータで TPM_RETURNCMD を指定した場合、
>ユーザーが選択したメニュー項目の識別子が返ります。
>ユーザーが何もメニュー項目を選択せずにメニューを取り消した場合や、
>エラーが発生した場合は、0 が返ります。

ってことだから、例えば右クリックメニューで選択したメニューの
IDが返るってことなのかな。


152 :仕様書無しさん:03/04/20 02:35
MECHANIC SHOOTING 0.7というフリーのSTGのソースに驚愕・・・
http://www.vector.co.jp/soft/win95/game/se280887.html



153 :仕様書無しさん:03/04/20 02:52
memset(p, 0, sizeog(hoge));
これでやってる

154 :CODASYL:03/04/20 02:57
>>152
ソース公開してんの?
それとも関係者?

155 :仕様書無しさん:03/04/20 03:01
>>154
なぜか圧縮ファイルにcppファイルが入ってる。

156 :仕様書無しさん:03/04/20 03:21
>>152
ある意味超大作だな(藁

157 :仕様書無しさん:03/04/20 03:24
ちょっと中見てみたけどこりゃまじですごいな。必見。
Cプログラミング診断室にも余裕で載っちゃうよ。


158 :仕様書無しさん:03/04/20 03:29
他にも作品があるようだが、全部こんなソースなのか??

159 :仕様書無しさん:03/04/20 04:28
長いなあ、これ…。
いつか出た数百のifのネストみたいな感じ屋根。

160 :仕様書無しさん:03/04/20 04:34
デバッグが大変だろうな、コレ
バグで動かなくなるし<やったのかよ

161 :山崎渉:03/04/20 05:47
   ∧_∧
  (  ^^ )< ぬるぽ(^^)

162 : :03/04/20 14:12
むしろこれは、
「精巧なメカニック」シューティングだから、
このソースでいいと思う。


163 :仕様書無しさん:03/04/20 15:28
久々に笑わせてもらいました。
ツッコミどころ満載ですな。


164 :仕様書無しさん:03/04/20 16:51
1M超えるソースは見る気もしないが...
これ作った人は、なぜかダウンロード回数が増えて喜んでるのだろうか?

165 :あぼーん:あぼーん
あぼーん

166 :仕様書無しさん:03/04/20 17:19
>>152
タダシンか、懐かしいな。

167 :仕様書無しさん:03/04/20 18:35
>>152
正直、作者の熱意に脱帽する。

ソースがここまでスゴイ状態になると、
普通は気持ちが折れてしまうか、
「自分は何かマズイ事をしているのでは」
という疑念が湧いてくるはず。

その両方の気持ちを押しつぶすほどの
開発に対する執念というのは正直スゴイ、
....見習いたくはないが。

168 :仕様書無しさん:03/04/20 19:01
見てみた。ラビリンスだなぁ。ある意味アタマいいけど。

169 :仕様書無しさん:03/04/20 21:08
そうだよねぇ。
頭はいいんだと思うんだけど、その頭のよさを別の方向に向けてほしい。

170 :仕様書無しさん:03/04/20 22:59
まさか、この1ファイルで、ソースファイルはすべてなのか??

171 :仕様書無しさん:03/04/20 23:25
>>170 正解

172 :仕様書無しさん:03/04/20 23:30
彼が、”プロ”のプログラマでないことを心から祈る今日この頃です。

173 :仕様書無しさん:03/04/20 23:44
大丈夫だ。このソースを見せて取ってくれる所は・・・

174 :仕様書無しさん:03/04/21 00:05
>>173
ある。未だに「これは凄いステップ数だね!大規模アプリ作れるなんて凄いよ君!」って言うやつは存在する。

175 :仕様書無しさん:03/04/21 00:24
自前のロジック記述用スクリプトからCのコードに落とした...ってのはなさそうだな。

モジュール化、OOやパターンをたたき込めば化けそうではある。


176 :仕様書無しさん:03/04/21 00:27
>>152
…すばらしい。どういう勉強の仕方をするとこうなっちゃうのかな。

177 :仕様書無しさん:03/04/21 01:12
>>160
漏れもやった。弾幕系シューティングは苦手でつ。

ソースも見た。どうも画面上のキャラ全部について
1個1個丁寧に処理してるみたいでつね。


178 :仕様書無しさん:03/04/21 01:17
el 使ってんのか・・・。
学生時代に使ったなぁ。

しかし、
あの頃は我も笑えるコード書いていた。

class A{
int i;
int j;
void func();
};

void A::func(){
for(i=0;i<5;i++)
printf("hello world!!");
}


見るも無残。。。

179 :仕様書無しさん:03/04/21 03:00
>>152
「メイン画面2」ってコメントがついている関数の名前が"Main3Screen"。
「メイン画面3」ってコメントがついている関数の名前が"Main2Screen"。

ソースとコメント内容の乖離っぷりが……

180 :仕様書無しさん:03/04/21 03:02
>>179
いや、それであってるんだよw

181 :仕様書無しさん:03/04/21 03:12
まじですか?
とはいっても内部を読もうとはちいとも考えてないんだが

182 :仕様無しさん ◆ukNwLv.g/w :03/04/21 06:19
>>175
| モジュール化、OOやパターンをたたき込めば化けそうではある。

きっと関数一つ毎に1ファイルにしたり、
インスタンス一つ毎にクラス一つ書いたりしそうだよ...

183 :仕様書無しさん:03/04/21 06:37
いったいお前は何のためにiを渡してるのかと、
void BitBossVoll4_1_1(int i)
{
 for (i=0;i<VOLL4_1_1MAX;i++) {
  elDraw::Layer((int)Voll4_1_1[i].Px,(int)Voll4_1_1[i].Py,Eshot3BMP,0,0,16,16);
 }
}

184 :仕様書無しさん:03/04/21 06:58
このソースを個別につっこむのはタブーだな。スレがすぐ埋まるぞ。

185 :仕様書無しさん:03/04/21 07:04
専用のスレがいるな。

【もうだめぽ】MECHANIC SHOOTINGを解析・ダメ出しするスレ Review.23

186 :仕様書無しさん:03/04/21 09:49
↑長げぇよ。

高校の頃のI先輩が、BASICでコメント一切なしのソースを書いて
シューティングを作り、更新時に過去のソースのバックアップも
取らなかったため、途中でゲーム開始と同時に自分が死ぬバグが
出た原因がわからず、文化祭の展示物がシューティングから1枚絵のみに
なったことがあったのを思い出したyo。

187 :仕様書無しさん:03/04/21 11:02
MECHANIC SHOOTING
ロックオンの綴りが間違ってるYO
というつっこみはありでつか?

188 :仕様書無しさん:03/04/21 11:30
なめるな こっちは 初期化だけで、30超ファイルの人間がいるんだぞ!
ソースの公開は、会社関係でアレだからできん。
負けるな! ○○○!

さて、そろそろラップ関数でも・・・

ギネスは君をまっている。

189 :仕様書無しさん:03/04/21 12:09
まぁ、こいつは単に初心者なだけだわな。
「一応動くものが作れる」とこまで学習した以上、そのまま突き進まずにはいられなかったんだろう。

ここまで動くものを作ったなら、効率化の必然性を理解するのは早いぞ、多分。
次に作るものではだいぶ進歩してるだろうよ。

自分で何も作ったことが無いままプロジェクトのはじっこに加わる奴より、
多分まっとうなプログラマーになると思う……。

190 :仕様書無しさん:03/04/21 12:18
>>189
>次に作るものではだいぶ進歩してるだろうよ。
氏のページには、すでに似たような作品を何本も出してるようなのですが。

191 :CODASYL:03/04/21 12:20
今ダウンロード中
とりあえずDoxygenに掛けてみるか。

192 :CODASYL:03/04/21 12:30
うお!Doxygenがクラッシュしやがった。
糞コードフィルタ機能でも付いてんのか?

193 :仕様書無しさん:03/04/21 12:40
でもまあ、携帯関係の人は知っているだろーけど、
 「動いててバグないからおっけー」
なソフトウェアや機器が世の中にどれだけあることか・・・・

194 :仕様書無しさん:03/04/21 12:44
static int i,j; // 汎用

泣けてくる…。

195 :仕様書無しさん:03/04/21 12:56
マジで添削スレほすぃ

196 :仕様書無しさん:03/04/21 13:05
>>193
そんなの携帯関係に限った話でもないだろうに……
納期に追われた事のあるプログラマなら、誰でも知っていること。

漏れ、100%これで満足だ、ってプログラム、未だ書いたことねーよ。

197 :仕様書無しさん:03/04/21 13:32
>漏れ、100%これで満足だ、ってプログラム、未だ書いたことねーよ。
HelloWorldなら100%満足じゃんとか一瞬思ったけどGNU Helloを思い出した。
http://www.gnu.org/software/hello/hello.html
http://ftp.gnu.org/gnu/hello/


198 :100%満足な日本語書けないっぽ:03/04/21 13:33
×HelloWorldなら100%満足じゃんとか
○HelloWorldなら100%満足なもの書けるじゃんとか

199 :193:03/04/21 17:38
>>196
納期に追われていないのんびりした環境でも、携帯関係はふつうに”そう”なっていることが多いんだよ

200 :仕様書無しさん:03/04/21 23:49
それも携帯だけじゃないがな。
特に埋め込み系だと・・・

201 :仕様書無しさん:03/04/22 00:02
>>200
>埋め込み系?

202 :仕様書無しさん:03/04/22 00:08
新しい 2ch 用語が出た

「埋め込み系」



203 :仕様書無しさん:03/04/22 00:08
>>201
インプランテッド分野・・・

204 :仕様書無しさん:03/04/22 00:10
梅子
久美子

205 :仕様書無しさん:03/04/22 00:14
宇宙人がもたらした新しい技術ですね?
どこやらの教授も自分を実験台にしてマイクロマシンの埋め込みをやってるようだが。

206 :仕様書無しさん:03/04/22 00:18
いや、偽装ツールでしょ?
「うめ〜このみかん」とか・・・

207 :仕様書無しさん:03/04/22 00:20
埋め込み系ってあれじゃないか
電子透かしとかJPEGに危ないツールを仕込んだりするヤシ。

208 :仕様書無しさん:03/04/22 00:26
43551行あたりのコード見るとめまいが・・・


209 :仕様書無しさん:03/04/22 00:34

ソ ー ス コ ー ド 殺 人 事 件 ?

210 :仕様書無しさん:03/04/22 00:39
>>208 のソースを見ると吐き気が・・・

211 :仕様書無しさん:03/04/22 00:41
ス パ ゲ ッ テ ィ 殺 人 事 件 ?

212 :仕様書無しさん:03/04/22 00:57
遠隔殺人で完璧なアリバイが手に入る悪寒

213 :仕様書無しさん:03/04/22 01:14
中継ルーターが MAC 記憶してた罠

214 :仕様書無しさん:03/04/22 01:33
こんな火曜サスペンス劇場見たくないでつ・・・

215 :古畑任ジャブ郎:03/04/22 02:12
全員「では犯行に使われた IP アドレスは NAT ルーターだったと?」
古畑「そうです、犯人は〜、何らかの方法でこの NAT の利いたネットワークに
   自分のマシンを持ち込み〜、遠隔から糞壁さんを殺したわけです。まさに
   石を隠すなら砂利の中といったところでしょうか〜。犯人は〜たくさんの
   マシンと利用者がいるにネットワークに自分を紛れ込ませたわけです〜。
   しかもこのネットワークは DHCP で全マシンに動的 IP アドレスを割り
   当てているためマシンの特定がしにくいという事からも〜、犯人はかなり
   用意周到だったと〜思われます」
古畑「しかし、こんな犯人でも間抜けなミスを犯してしまいました〜。な〜んと、
   DHCP の IP 割り当てテーブルに時刻付きで MAC アドレスが記録されて
   いたんですね〜。00:30:f1:ff:ff:ff という NIC は、山崎渉さん、
   あ な た の T h i n k P a d で つ ね ?」


ゴールデンじゃ絶対無理な古畑だな。

216 :仕様書無しさん:03/04/22 02:17
西村京太郎、パケットの遅延とバイパスを使ったサスペンスドラマ第一弾

「殺意の ICMP」

TBS 夜 7:30 放送

217 :仕様書無しさん:03/04/22 02:33
おまいら面白過ぎw

218 :仕様書無しさん:03/04/22 06:07
「犯人はこのサブネットにいる!」


219 :仕様書無しさん:03/04/22 06:24
「湯煙〜」とかないんですか?

220 :仕様書無しさん:03/04/22 06:27
>>219
ただし結露無きこと

221 :仕様書無しさん:03/04/22 06:28
8つハッカー村


222 :仕様書無しさん:03/04/22 07:26
おやつハッカー村

223 :仕様書無しさん:03/04/22 07:44
で、携帯や埋め込み系だとなんで「動けばいい」になるの?
PGの能力が低いの?

224 :仕様書無しさん:03/04/22 07:54
俺は埋め込み系じゃないからしらん。

225 :ミ,,゚Д゚彡 ◆A6VzDeLphI :03/04/22 08:36
>>215
モナ畑任三郎 みとけ。

http://members.tripod.co.jp/kotna/yokoku.swf
http://www.geocities.co.jp/SiliconValley-Sunnyvale/8339/monahata1.swf
http://www.geocities.co.jp/SiliconValley-Sunnyvale/8339/monahata2.swf
http://www.geocities.co.jp/Milano-Cat/9269/monahata3.swf
http://www.geocities.co.jp/SiliconValley-Sunnyvale/8071/monahata4.swf



226 :仕様書無しさん:03/04/22 08:57
折れは嵌め込み系


227 :仕様書無しさん:03/04/22 09:21
私は食い込み系

228 :仕様書無しさん:03/04/22 09:38
こめかみ系

229 :仕様書無しさん:03/04/22 09:40
>>219
温泉は硫黄で金属がさびるからやばいらしいね。
PCとか簡単にいかれるらしい。

230 :仕様書無しさん:03/04/22 11:16
>>220
なんか,大笑いしてもた.

231 :仕様書無しさん :03/04/22 13:22
ソースコードじゃないけど某○塚の下請けにいたとき、
VBA+Oracleでの製作経験数年って香具師に
”トランザクションってなに?”って聞かれた時はメマイがしたよ。

232 :仕様書無しさん:03/04/22 17:49
>>231
> ”トランザクションってなに?”って聞かれた時はメマイがしたよ。

Javaやってるのに
「クラスパスってなに?」
って聞かれたときみたいだ。

233 :仕様書無しさん:03/04/22 18:20
自称C経験者が「#undefってなに?」と言うのにも似ているな。

#今日、自称C言語5年の人に聞かれた。

234 :ヽ(´ー`)ノ:03/04/22 18:26
>>233
「#include っておまじないじゃないの?」と言われた時は鼻血が出そうになりました。


235 :仕様書無しさん:03/04/22 18:37
派遣の女の子は最後まで「スタジオ・テン・エイチ」と呼んでた > stdio.h

236 :仕様書無しさん:03/04/22 18:47
>>235
これは何だろね、わざとっぽいけど。
可愛いと思って使ってるんなら許す。

237 :仕様書無しさん:03/04/22 19:23
>>234
ああ、言ったことあるわ、それ。

まあ、そのころはCは殆ど知らなかったし、昔読んだある雑誌にそう書いてあったんだ。
許してくれ。

238 :仕様書無しさん:03/04/22 20:40
俺もhello, world表示するプログラムの解説でそう言われた
いきなりそれ説明しても???だろうし適切だったと思ふ


239 :仕様書無しさん:03/04/22 22:52
すたんだーどあいおーへっだー、でいいんだよね?
不安になってきた・・・

240 :仕様書無しさん:03/04/22 22:56
>>239
えすてぃーでぃーあいおーてんえっち

241 :仕様書無しさん:03/04/22 23:17
てん、じゃないポチといえ
ちるだ、じゃないにょろといえ

242 :仕様書無しさん:03/04/22 23:57
>>241
了解、”.NET”は”ぽちっとねっと”でつね(w

243 :仕様書無しさん:03/04/23 00:55
スタンダード・インプット/アウトプットヘッダーファイルをインクルードして〜とか言われたい?
それならまだスタヂオ・テン・エイチの方が可愛いと思うが・・・。

俺はエスティーディアイオーと呼ぶがそれはそれ。

244 :仕様書無しさん:03/04/23 01:16
>242
 なんか爆発しそうだな(w

245 :仕様書無しさん:03/04/23 04:47
ワロタ

246 :仕様書無しさん:03/04/23 05:40
しかし stdio.h を呼称すること自体、稀だと思うのだが...


247 :ヽ(´ー`)ノ:03/04/23 10:08
>>238
いや、始めはそれでいいんたけど(俺もそう聞いたし)、業務歴6,7年の方に言われると、
鼻血ブーですよ。

// ちなみにエスティーディーアイオーかなぁ。
// 実は creat みたいに studio のスペルミ(嘘

248 :仕様書無しさん:03/04/23 10:10
スペルマ?

249 :仕様書無しさん:03/04/23 19:57
某社のVisual Studioってひょっとして・・・(ぷっ


250 : :03/04/23 21:52
スタンダードアイオードットヘッダ

以外は認めぬ!(゚Д゚)ゴルァ!

251 :仕様書無しさん:03/04/23 22:05
スタンダードインプットアウトプットドットエイチ、だな。漏れの場合。

252 :仕様書無しさん:03/04/23 22:08
いつものやつ、だな。漏れの場合。

253 :仕様書無しさん:03/04/23 23:40
スタッドアイオーヘ
に決まっておる

254 :仕様書無しさん:03/04/24 00:28
すたぢぅぃおぽちえっつい

255 :仕様書無しさん:03/04/24 00:42
しーえすてぃーでぃーあいおー

256 :仕様書無しさん:03/04/24 06:29
スタンダードアイオーエイチ。

257 :仕様書無しさん:03/04/24 08:34
しーすりーぴーおー

258 :仕様書無しさん:03/04/24 21:24
>>257
おまえがスレッドストッパーか!!

259 :仕様書無しさん:03/04/24 22:53
陽気なconio.h

260 :仕様書無しさん:03/04/24 23:03
えすてでぽちへ

261 :仕様書無しさん:03/04/24 23:14
「この会社やめようと思ったソースコード"の音読の仕方"」スレでつな。

262 :仕様書無しさん:03/04/25 00:38
ねどく ってなに?

263 :仕様書無しさん:03/04/25 01:24
dim i as integer

i=text1.text
if IsNumeric(i)=true then


264 :仕様書無しさん:03/04/25 10:11
>>263
少し上を見るとOn Error Resume Nextが書いてある罠とか。

265 :仕様書無しさん:03/04/25 11:45
( ゜д゜)
>>263 はifの結果が常に真になるじゃん、て話しじゃないの?

266 :仕様書無しさん:03/04/25 11:47
>>265
その前に数字でなかったら代入時にエラー

267 :仕様書無しさん:03/04/25 12:56
>>266

264 名前:仕様書無しさん 投稿日:03/04/25 10:11
>>263
少し上を見るとOn Error Resume Nextが書いてある罠とか。


268 :仕様書無しさん:03/04/25 13:33
結論としては「VBは糞」でよい?

269 :仕様書無しさん:03/04/25 15:03
>265
「数値型変数」の中身が「数値」かどうかを調べる事に
何の意味があるのか小一時間問い詰めたい訳だ。

270 :仕様書無しさん:03/04/25 22:14
数値型変数に NaN は格納できないの?

271 :仕様書無しさん:03/04/25 22:34
Not a Number 数じゃない

272 :仕様書無しさん:03/04/26 00:00
むむ。
VB.NETでは序数・被序数いずれも0のDouble値の除算を行うと
結果はSystem.Double.NaNになる、とあるな。
試しに計算結果をDoubleに入れてSystem.Concole.Outに出してみたら
「NaN (非数値)」と出た。
てことでDoubleにはNaNは入る(ようにこじつけてある)と思われ。
(´-`).。oO(てか、Javaがそーなんだもんな……)

# ちなみにVB6.0でやると計算時にオーバーフロー実行時エラーになる罠。

273 :仕様書無しさん:03/04/26 02:15
NaN でそんなもんを数だと思うかなー。の略です。

274 :仕様書無しさん:03/04/26 09:59
>>270
NaNもいいけどカレーもね(* ^ー゚)ノ


275 :仕様書無しさん:03/04/26 10:47
NaNだって!?(MMR AA略

276 :仕様書無しさん:03/04/26 11:10
NaNぽ

277 :仕様書無しさん:03/04/26 11:51
>263
実はtext1.textもintegerとか。

278 :仕様書無しさん:03/04/26 18:14
IEEE754フォーマットにはNaNが含まれます。
±∞もある。

279 :仕様書無しさん:03/04/26 19:52
>>273
うまいっ。
昨日RMSの講演聞いたばっかりだから、再帰命名を見ると嬉しくなります。

280 :仕様書無しさん:03/04/26 21:08
>>273
>>279

・・・・「 ど こ が 略 な ん だ 」


以上。

281 :仕様書無しさん:03/04/26 21:51
NaNは次のように再帰的に定義されています。

NaN is not A Number.


282 :仕様書無しさん:03/04/26 22:33
NaN'snt A NumberじゃないとNINANになっちゃうぞ

283 :仕様書無しさん:03/04/27 00:38
Not Anything but NaN.
末尾再帰にしないとスタックがもったいないでしょ。

284 :V:03/04/27 01:45

☆^〜^★ 50音順で探せて楽して得する
http://sagatoku.fc2web.com/
   あなたの探し物きっとみつかるよ☆^〜^★



285 :仕様書無しさん:03/04/27 03:03
今さらながらstdio.h話ですが、
初めて見た頃は

セットディオ!かっこいい!何かジョジョっぽい!

と思いますた。テレビの前のみんなもそうだよね?

286 :仕様書無しさん:03/04/27 03:41
先輩このソース、インクルードスタジオエッチを
唱えないで大丈夫なんですか〜

新人って可愛い。今年はどんな珍発言が聞けるかな・・・

ちなみに漏れはスタンドアイオーって読んでる。
スタンダードって長いし。

287 :仕様書無しさん:03/04/27 03:46
if(returncode.errorcode == COM_ERROR) {


288 :仕様書無しさん:03/04/27 03:55
>>286
エステーデーアイオー

289 :仕様書無しさん:03/04/27 04:31
たしかに >>286 のようなセンスない香具師がいる会社は辞めたくなるな。
standardとstandじゃ全然違うだろ・・・

290 :仕様書無しさん:03/04/27 07:39
スタンダードアイオーヘッダー

って読むな。ちなみに stdlib.h は

スタンダードリブヘッダー


291 :仕様書無しさん:03/04/27 07:57
errFlag = true;
ret = func1()
if (ret == 1) {
  ...
  errFlag = true;
  ret = func2();
  if (ret == 1) {
    ...
    errFlag = true;
    ret = func3();
    if (ret == 1) {
      ...
 


292 :仕様書無しさん:03/04/27 07:57
     errFlag = true;
      ret = func4();
      if (ret == 1) {
        ...
        errFlag = true;
        ret = func5();
      }
      else {
        errFlag = false;
      }
    }
    else {
      errFlag = false;
    }
  }
  else {
    errFlag = false;
  }
}
else {
  errFlag = false;
}

if (errFlag == false) {
  funcLogWrite();
  return -1;
}
else {
  ...
  return 0;
}

293 :仕様書無しさん:03/04/27 07:58
>>291-292
誰かこいつをリファクタリングしてくれ。擬似コード的で
構わないので。(T_T)

294 :仕様書無しさん:03/04/27 09:48
func1〜5が何を返してるかによるな
1以外はエラーなのか?

295 :仕様書無しさん:03/04/27 09:50
ちゅっか、errFlagはtrueだとエラーなのか
falseだとエラーなのか

それを込みで要リファクタリングなのね・・・

296 :仕様書無しさん:03/04/27 09:55
皮をかぶせるなりなんなりして...の部分を直前の関数に含めてしまう。
その後に

if ( func1 () && func2 () && func3 () && func4 () )
{
  ...
  return 0;
}
else
{
  funcLogWrite ();
  return -1;
}

というのはどう?

297 :仕様書無しさん:03/04/27 10:01
>>293
この程度で音を上げる貴様はぬるい、修行せよ。と言っておく。
だってワシ、こんなレベルじゃないヘボコードの拡張&改造を・・・

>>291->>292を見る限り、
(以下私見で話を進める。もし間違っていたとしても責任までは持てないので勘弁してほしい。)
errFlagはすなわち(ret != 1)と見れると思ふ。
この見解を信じるのであれば、
ret = func1()
if(ret == 1) {
...
ret = func2();
}
if(ret == 1) {
...
ret = func3();
}
if(ret == 1) {
...
ret = func4();
}
if(ret == 1) {
...
ret = func5();
}
if(ret != 1) {
funcLogWrite();
return -1;
}
...
return 0;
↑こんな感じ。どう?

298 :296:03/04/27 10:06
忘れ物。
func5 ()の帰り値は無視されてるみたいなので func5 ()はthen節に入れて下さい。

299 :仕様書無しさん:03/04/27 10:06
各funcが前の関数が1を戻さない限り実行してはダメ
func1〜4が同型の戻り値を返す
というのを条件とすると、

#define FUNC_NUM 5
int (*_func[FUNC_NUM])(void) = {func1,func2,func3,func4,func5};

errFlag = true;
for (i = 0; i < FUNC_NUM; i++) {
  ret = _func[i]();
  if (ret == 1) errFlag = true;
  else {
    errFlag = false;
    break;
  }
}
かな・・・

300 :297:03/04/27 10:07
・・・補足。
オリジナルの「errFlag」って、(func1〜func5を通るのが正常ルートと仮定すると)
「エラーあり」でfalse,「エラーなし」でtrueなのがまだややこしいと思ふ。
実は「not errorフラグ」?

301 :299:03/04/27 10:08
誤:func1〜4が同型の戻り値を返す
正:func1〜5が同型の戻り値を返す
ですた

302 :299:03/04/27 10:13
あ〜、
int (*_func[FUNC_NUM])(void) = {func1,func2,func3,func4,func5};

errFlag = true;
for (i = 0; i < FUNC_NUM && errFlag == true; i++) {
  ret = _func[i]();
  if (ret != 1) {
    errFlag = false;
  }
}
の方がスッキリかな?

303 :299:03/04/27 10:14
ごめんなさい
それぞれの結果に、
...の異なる処理があったのね・・・
逝ってくる・・・

304 :仕様書無しさん:03/04/27 10:22
なにか盛り上がってるな。

>>300
errFlagはfunc4 ()が1を返したらtrueである
func4 ()が1以外を返した or 実行されければfalseである。

にも関わらずあちこちで手をつけてるのが紛らわしいとオモタ。

305 :297:03/04/27 10:23
>>299
ついでに言うと、この手の相談の場合、引数指定とかは省略して質問するのがたぶん普通で、
func1〜func5のプロトタイプが同じとはとても思えん。
(サンプルコードから戻り値intであるのは察せられるが。)

以上、説教口調で偉そうだったボクも逝きま〜す!

306 :動画直リン:03/04/27 10:26
http://homepage.mac.com/hitomi18/

307 :296:03/04/27 10:29
良く見たらfunc1〜5は順番に実行されてるだけだな。
funcLogWrite ()は例外処理っぽいからgotoで飛ばすのもアリか。

ところでC言語前提だよね。コレ。
>>296もそう思って書いてたけど。

308 :仕様書無しさん:03/04/27 10:37
素直に、
errFlag = false;
if (func1() == 1) {
  ...;
  if (func2() == 1) {
    ...;
    if (func3() == 1) {
      ...;
      if (func4() == 1) {
        ...;
        func5();
        errFlag = true;
      }
    }
  }
}
ってとこ?
静的解析的にはよくないけど・・・

309 :仕様書無しさん:03/04/27 10:39
errFlagはローカル変数じゃないかもな。
そうでもないと関数呼び出しの前にerrFlag = true;がある理由がわからん。

310 :仕様書無しさん:03/04/27 10:42
>>309
確かに、func1〜5でerrFlagを見てたら泣くな

311 :しつこく297:03/04/27 10:57
>>310
さらに、func1〜5の呼び出しが1箇所じゃなかったら・・・!
さらに、「製品テスト&出荷済みだから基本構造の再設計はなしね。」というシバリがついたら・・・!


今日は休日だ。洗濯ももう終わる。ネットやめてゲームに戻るか。

312 :仕様書無しさん:03/04/27 11:03
>>311
>>今日は休日だ。洗濯ももう終わる。ネットやめてゲームに戻るか。
そうだ、GWだ。
土日連休という大型のな・・・

313 :仕様書無しさん:03/04/27 17:28
「どにちれんきゅう」ってなに?おいしいの?

314 :仕様書無しさん:03/04/27 18:17
>>313
あまずっぱい

315 :仕様書無しさん:03/04/27 18:19
>>291〜293 は、仕事に行ってるのか?
それともただの教えて君か?

316 :仕様書無しさん:03/04/27 20:00
>>315
直してクンだよ

317 :仕様書無しさん:03/04/27 20:36
>>316
素直に笑った。そやね、確かに。
>>291
気持ちはわかるぞ。がんばってね。

318 :293:03/04/27 21:37
みなさん。ご迷惑をおかけしました。仕事やっと終わりますた。

このコード(>>291-292)は協力会社の PG さんが書いたものなの
ですが、結局怖くていじることができませんでした。

>>299 さんのコードが一番すっきりしてますが、>>305
おっしゃってますようにそれぞれ引数が異なっているため、
関数ポインタのテーブルを利用してループにするという技は使え
ません。

結局 >>297 的にするのが一番無難ですね。まあバグは直せ
たので、無理に構造をいじる必要はないのですが。今後これの
保守をやらされるかと思うと。

ちなみにこのコードは某大手の次期統合システムの中心に位置する
プログラムの一部です。こういう if-else の深いネストが至るところに
あって死にそうです。なんでうちはこういうコードを書く会社に仕事を
発注してるんだろ。
# うちは 2 次受けで、このコードを書いたのは 3 次受けの人です。

>>295
errFlag はエラーなら false 、正常なら true です。理解しがたい
感覚。普通逆だろうに。名前も isErrorOccured くらいにして欲しい。

>>308
これだけは勘弁してください。(T_T)

>>315
ただの教えて君ですた。(死

319 :仕様書無しさん:03/04/27 22:08
こんなのはダメ?
関数の出口が1つじゃなくても良い事を逆手にとって
リファクタリングの「ガード節による入れ子条件記述の置き換え」を適用する

// メインルーチン
if(!wrapper()){
funcLogWrite();
return -1
}
return 0;



// 一連の処理をラッパ関数でくくって
// 「ガード節による入れ子条件記述の置き換え」を適用
wrapper(){
 if (func1() != 1) return false;
 ...
 if (func2() != 1) return false;
 ...
 if (func3() != 1) return false;
 ...
 if (func4() != 1) return false;
 ...
 if (func5() != 1) return false;
 return true;
}

320 :仕様書無しさん:03/04/30 15:41
bool b = true;
b = b && func1() != 1;
b = b && func2() != 1;
b = b && func3() != 1;
b = b && func4() != 1;
b = b && func5() != 1;
return b;

321 :仕様書無しさん:03/04/30 17:40
>>320

お題はコレ↓
>>291-293

322 :仕様書無しさん:03/05/01 08:49
 errFlag = true;
 ret = func1(); if (ret != 1) goto errFlag_false;
 ...
 errFlag = true;
 ret = func2(); if (ret != 1) goto errFlag_false;
 ...
 errFlag = true;
 ret = func3(); if (ret != 1) goto errFlag_false;
 ...
 errFlag = true;
 ret = func4(); if (ret != 1) goto errFlag_false;
 ...
 errFlag = true;
 ret = func5();
 ...
 return 0;
errFlag_false:
 errFlag = false;
 funcLogWrite();
 return -1;

これで本質は崩れてないと思うんだけど,どをでしょを。
goto 禁止令が出てないことが前提です。
あと,ret も errFlag もグローバルだと仮定して。

323 :320:03/05/01 18:36
bool errFlag = true;
errFlag = errFlag && func1() == 1;
errFlag = errFlag && func2() == 1;
errFlag = errFlag && func3() == 1;
errFlag = errFlag && func4() == 1;
errFlag = errFlag && func5() == 1;
って書き直せってこと?


324 :仕様書無しさん:03/05/01 18:44
>>323
" ... "で省略されている処理

325 :仕様書無しさん:03/05/02 09:23
>>324
ああ。299みたいのもあったから。

ここはひとつ、for-switch構文を使ってですねぇ...
for(int i = 0; i < 5 && ! errFlag; i++ ) switch(i) {
  case 1:
    ...
    errFlag = func1() == 1;
    break;
  case2:
    ...
    errFlag = func2() == 1;
    break;

なんか邪悪だが。


326 :仕様書無しさん:03/05/02 09:34
 for(a=1,b=2,i=1; i<10; i++) 
のようにforの中に関係ない変数の初期化を入れたり
2次元配列a[N][N]の全ての要素を0にするのに
 for(i=0, k=0; i<N, k<N; i++,k++) a[i][j]=0;
にして、全部0に出来たとしてる香具師がガバガバいるよ。
Cをやった事あると言ってる新人だけどさ。
おかしな配列初期化コードを書いた奴は、新人同士では結構出来る奴と思い込まれてたりする。

327 :仕様書無しさん:03/05/02 09:36
a[i][k]=0だ。iとjじゃわかりにくいと思ったので修正したら忘れてた〜

328 :仕様書無しさん:03/05/02 09:38
>326
memset

329 :仕様書無しさん:03/05/02 09:44
>>326
まだ新人なんだろ。許してやれよ。

330 :仕様書無しさん:03/05/02 09:47
int a=10;
int b;
memcpy( a , b , sizeof( int) );
こんな感じのコードでコンパイルが通らないと言って悩んでた香具師
何を指摘すべきか混乱しちまったぞい。

331 :仕様書無しさん:03/05/02 09:59
>>330
コンパイルエラーはエラーのうちに入らないっす!

332 :仕様書無しさん:03/05/02 10:27
個人的には、>>319が一番すっきりなんだが、
(errFlag周りの処理を追加すれば)
今の顧客のコーディング規約に、
・関数の出口は1つでなければならない(returnは一つのみ)
ってのがあるんで鬱


333 :仕様書無しさん:03/05/02 10:31
>>332
gotoで無理矢理とばしてしまえと。

334 :仕様書無しさん:03/05/02 10:32
getIsStatus()

というJavaのメソッド名を見てしまった。

335 :仕様書無しさん:03/05/02 10:34
>>326
>>for(a=1,b=2,i=1; i<10; i++) 
>>のようにforの中に関係ない変数の初期化を入れたり
ていうのも嫌だが、わしは、

void hoge(void)
{
  int max = 0;
  int i = 0;

  max = getMax();
  for (i = 0; i < max; i++) {
    ...;

のように、auto変数の宣言と(無駄、意味のない)初期化をやる奴もイヤ

336 :仕様書無しさん:03/05/02 10:34
>>334
ただのIsStatusプロパティのgetterっしょ?


337 :仕様書無しさん:03/05/02 10:38
>>333
当然、gotoの使用は厳禁です
・continueの禁止
・switch以外でのbreakは禁止
と。
これらを守る=構造化=誰にでも読める
という意識があるらしい。

338 :仕様書無しさん:03/05/02 10:41
>>335
3行前に書いた自分のコードが信用ならないという特異性格の私はよくやります。

もし初期化していない値を参照してしまっていたら・・・
という心配だな。

339 :仕様書無しさん:03/05/02 10:43
>>338
どうせ最適化で消滅するしね。

340 :仕様書無しさん:03/05/02 10:55
>>338
初期化されていない方がエラーを検出できる可能性が高くない?
下手に0初期化してると、たまたま動いちゃうとか

>>339
実行コード上はそうだけど、ソース上に意味ありげに
書いてあるのがね・・・、気になるのは俺だけ?
俺だけか・・・

341 :仕様書無しさん:03/05/02 10:57
未初期化の変数をつくる奴がイヤ。

342 :仕様書無しさん:03/05/02 10:59
void hoge(void)
{
  int const max = getMax();
  for (int i = 0; i < max; i++) {

これで文句は無いな?

343 :仕様書無しさん:03/05/02 11:10
>>340
0で初期化して動いているのならそれでいいと思う。
未初期化でたまたま動かれるよりは...

344 :仕様書無しさん:03/05/02 12:11
>>341
未初期化は、静的解析ツールで検出できるし、
ほんとの未初期化ならコンパイラも警告だしてくれるから・・・

>>342
文句というか、落ち着くんです。
脳内で、
int i;
i = 0;
for (i = 0; ......
と置き換えちゃってるのかもしれません。

>>343
両方とも「たまたま」な動作なんだから危険
ツールで検出できない分、意味無し0初期化の方が、より危険
と、思ってます

これらの理由で辞めようと思ったことはないので、スレ汚してでした。スマソ > ALL。

345 :仕様書無しさん:03/05/02 18:27
errFlag = true;
if ((ret=func1()) != 1) goto logwrite;
...
errFlag = true;
if ((ret=func2()) == 1) goto logwrite;
...
errFlag = true;
if ((ret=func3()) == 1) goto logwrite;
...
errFlag = true;
if ((ret=func4()) == 1) goto logwrite;
...
errFlag = true;
if ((ret=func5()) == 1) goto logwrite;
...
return 0;

logwrite:

errFlag = false;
funcLogWrite();

return -1;

346 :345:03/05/02 18:29
ミスった。の再び・・・

errFlag = true;
if ((ret=func1()) != 1) goto error;
...
errFlag = true;
if ((ret=func2()) != 1) goto error;
...
errFlag = true;
if ((ret=func3()) != 1) goto error;
...
errFlag = true;
if ((ret=func4()) != 1) goto error;
...
errFlag = true;
if ((ret=func5()) != 1) goto error;
...
return 0;

error:

errFlag = false;
funcLogWrite();

return -1;

ってのはどうよ?

347 :仕様書無しさん:03/05/02 18:30
さらにスマソ。>>322で既出だった。欝死

348 :仕様書無しさん:03/05/02 19:01
mozilla では >322 (>346 も等価) のような雰囲気のコードが推奨されているモヨン
ttp://jt.mozilla.gr.jp/hacking/mozilla-style-guide.html#Errors
# 「エラーからはすぐにリターンしてください」のコードは
# カッコの数が・・あれれ?(笑い

349 :仕様書無しさん:03/05/02 20:56
内部クラスのメソッドのコメントが

/**
* ここはJavaDocに出力されない
*/

だった。

350 :仕様書無しさん:03/05/02 21:02
スレ違いの予感

351 :仕様書無しさん:03/05/02 21:03
あ、ごめん。スレ違いの予感は>>349じゃないですよ。
糞コードを晒すだけにしようや。

352 :仕様書無しさん:03/05/03 02:09
public void foo (String str) {
  ...
  if (str.equals(null)) {
    ....

もうね(略)


353 :仕様書無しさん:03/05/03 02:59
ぬllぽいんてれxせpちおn

354 :仕様書無しさん:03/05/03 23:00
n回繰り返すとき

(1)
for (int i = 0; i < n; i++)

(2)
for (int i = 1; i <= n; ++i)

どちらを使いますか?

355 :仕様書無しさん:03/05/03 23:07
特殊な用途でもない限り、1かと。
forループではカウンタで配列の順次参照を行うことが多いから、
自然とそういう書き方が習慣付く。

356 :仕様書無しさん:03/05/03 23:09
>>354
誤爆?

357 :仕様書無しさん:03/05/03 23:14
>>355
あぁ、配列をいじるときは添え字が0からだから、そうなるなぁ。
一応、2は、自然数を意識して、n回っていうのが確実に伝わるように…って。

>>356
なんとなくこのスレに書いてみた。。

358 :仕様書無しさん:03/05/04 00:25
>357
自然数で行くなら
for(int i = n; i > 0; i--)
でやれ。

359 :仕様書無しさん:03/05/04 00:36
>>358
辞めたくなった(w

360 :仕様書無しさん:03/05/04 00:41
>359
8086ぐらいの頃までは、>>358のように減算したほうが数え上げるより速かったんだが...。
マシン語に落ちたときに命令数が少ないから。

最近は最適化されていそうだからわからんけどな。

361 :仕様書無しさん:03/05/04 00:47
>360
VCでは最適化されてた。
さすがに賢いと思った。

362 :仕様書無しさん:03/05/04 00:50
>>360
Delphiでも最適化されていた。
(そういうことだったのかと初めて知った。)


363 :仕様書無しさん:03/05/04 01:33
>>357
でも、for (int i = 0; i < n; i++) も for (int i = 1; i <= n; ++i) も
nって書いてあるんだから分かると思われ。
for (int i = 0; i <= n-1; i++)
だったらダメだと思うけど。

364 :仕様書無しさん:03/05/04 02:41
初心者なんだけど、なんでforの中にintって書くの?
void main(void){
   int i;
   int n;

   for(i = 0; i < n; i++){
}
}
じゃだめ?

365 :仕様書無しさん:03/05/04 02:44
>>364
変数のスコープについて勉強汁

366 :仕様書無しさん:03/05/04 03:13
>365
VC6だと実は同じだったりするんだがなw

>364
forの中に変数宣言を書くと、その変数のスコープが
forループの中だけに制限できるから。
……少なくとも、言語仕様的にはその筈。

367 :仕様書無しさん:03/05/04 03:32
>>366
スコープって意味がわからないんだけど、
intの領域をforの中だけで確保するってことですか?


368 :仕様書無しさん:03/05/04 03:43
>367
そうそう、そんな感じで思ってくらはい。

369 :仕様書無しさん:03/05/04 03:55
>>366
おいおい、言語仕様っていっても、
CとC++で違うし、どの仕様かによっても違うぞ。

370 :仕様書無しさん:03/05/04 04:04
>>369
少なくとも今は、forの初期文で変数を宣言するか否かについて話しているんだから
C++かC99について話しているということだろうし、C++とC99なら最近の仕様はみんな
>>366の言う通りじゃないか?(実装はまた別にして)

371 :仕様書無しさん:03/05/04 04:12
>>370
VC6なんてコンパイラ依存の話をもちだすくらいならはっきりかくべきだね。
とくにC++。

372 :仕様書無しさん:03/05/04 05:29
学校でC習ってるんだけど、main関数内で使う変数は、全部main()のすぐ下で宣言してたけど・・・。
ループ内で宣言する方が良かったのか

373 :仕様書無しさん:03/05/04 07:07
最近の風潮としては、下で宣言できるものを上でまとめて宣言するのは嫌われる傾向がある。
変数の影響を局所化しておかないと、メンテや変更が難しくなるというのがその理由。

374 :仕様書無しさん:03/05/04 07:27
スコープとかは本の最初の方にも載ってたような…。
もしかしたら後かもしれないけど、読んでみるとええよー。

でもだんだんスレタイトルからネタがずれてきているのでこのへんで。
次どぞー>↓

375 :仕様書無しさん:03/05/04 09:33
次どぞー↓

376 :仕様書無しさん:03/05/04 09:44
オッホンさてと



次どぞー↓

377 :仕様書無しさん:03/05/04 09:44
ネタ切れ

378 :仕様書無しさん:03/05/04 09:45
つり銭切れ

379 :仕様書無しさん:03/05/04 10:19
↑おまい両替に行って来い

380 :仕様書無しさん:03/05/04 10:48
お前ら、さっさと辞めて公務員に汁!

381 :仕様書無しさん:03/05/04 16:22
ループ内での宣言は、避けるようにした方が良いと思うが。

382 :仕様書無しさん:03/05/04 17:03
次どぞー↓


383 :仕様書無しさん:03/05/04 17:05
次ぶっぞー↓

384 :◆ItkaRMAJ7. :03/05/04 17:21
このスレはネタスレになりました!

385 :仕様書無しさん:03/05/04 18:33
int hex2int(char *hex)
{
int result=0;
for(int i=0;i<strlen(hex);i++)
{
result *= 16;
for(int j;j<16;j++)
{
if( hex[i] == "0123456789ABCDEF"[j] )
{
result += j;
break;
}
}
}
return result;
}

386 :仕様書無しさん:03/05/04 20:27
>>385 j を初期化したまえ。話はそれからだ。

387 :仕様書無しさん:03/05/04 20:38
int hex2int( char const hex[] )
{
  int const int_bits = std::numeric_limits< int >::digits + 1;
  int const bits_per_degit = 4;
  char const* p = &hex[0];
  int result = 0;
  int result_bits = 0;
  for(;;)
  {
    int const c = *( p++ );
    if( c == '\0' )
      return result;
    int value_of_c;
    if( '0' <= c && c <= '9' )
      value_of_c = c - '0';
    else if( 'A' <= c && c <= 'F' )
      value_of_c = 10 + ( c - 'A' );
    else if( 'a' <= c && c <= 'f' )
      value_of_c = 10 + ( c - 'a' );
    else
      throw std::invalid_argument( "'hex2int' met a non hexadecimal character" );
    assert( value_of_c < ( 1 << bits_per_degit ) );
    if( result != 0 )
    {
      result <<= bits_per_degit;
      result_bits += bits_per_degit;
      if( result_bits > int_bits )
        throw std::overflow_error( "'hex2int' caused overflow" );
    }
    result |= value_of_c;
  }
}

388 :仕様書無しさん:03/05/04 21:06
strtolでいいだろ?

389 :仕様書無しさん:03/05/04 21:11
はい。

390 :仕様書無しさん:03/05/04 21:19
マイナスは?

391 :仕様書無しさん:03/05/04 21:31
>>390
>>388に言ってるのか?
http://www.linux.or.jp/JM/html/LDP_man-pages/man3/strtol.3.html
マイナスも大丈夫

392 :仕様書無しさん:03/05/04 23:24
質問。

変数を初期化しないで宣言するのって俺は駄目だと思ってたんだけど、
そうでもないのか? >>335 見たいな奴。俺はよくポインタは C++ なら 0
で、 C なら NULL で初期化するんだけど。(宣言時に)

>>342 みたいにあらかじめ初期化すべき値がはっきりしているときは
こうするけど、未初期化の変数宣言は気持ち悪い。俺の感覚だと。

例えば、

char* p;
try {
  p = new char[256];
}
catch (bad_alloc) {
  delete[] p;
  throw;
}

こんなコードを書いた奴がいるとして、p ってどこ指してるか分からない
よね? なのに delete しちゃってる。これってまずいよね。でも p の
宣言時に 0 で初期化しとけば何も起きないことが保証されているはず。

どうよ?

393 :仕様書無しさん:03/05/04 23:28
そういうことをするなら初期化するのは当然。

ってだけのこと。

394 :仕様書無しさん:03/05/04 23:33
> 宣言時に 0 で初期化しとけば何も起きないことが保証されているはず。
そのコードは初期化の有無が問題なのではない。

395 :仕様書無しさん:03/05/05 00:46
変数がnullを値として取りうるかどうかで判断しないといけないよ。
null値になって欲しくない変数に初期値でnullを与えてしまうと、
初期化忘れの可能性があるコードを書いてもコンパイラが警告してくれない。Javaの話ね。

396 :仕様書無しさん:03/05/05 01:02
>392
newが返すアドレスをdeleteすれば問題無いんじゃない。
何で宣言時に初期化したがる?

397 :仕様書無しさん:03/05/05 01:12
>>396
値が不定な期間はバグの元だからだろ。

逆に聞きたいなぁ。何で未初期化で宣言したがる?

398 :仕様書無しさん:03/05/05 01:41
値が不定な期間にそれ使おうとすると
警告出してくれるから書かないな、俺(VC++の場合
ただし、クラスの場合は警告してくれないから
コンストラクタでメンバを初期化する

無駄なコードは書かずに
必要なものだけなるべく書きたいからかな、俺


399 :仕様書無しさん:03/05/05 01:50
ていうか、ぬるぽ delete[] してよかったっけ?
bad_allocってことは確保できなかったんでしょ?

400 :仕様書無しさん:03/05/05 02:00
NULL は delete しても free しても問題ないよ。


401 :仕様書無しさん:03/05/05 02:00
>>398
つまり、使う前には値を代入するわけだな。
宣言時の初期化が無駄なコードだって?
"int i; i = 0;"と"int i = 0;"だからコード量じゃないよな?
代入するまで使用しないってことは、変数の存在自体が
記憶領域(コンパイラ・コード読む人・最悪ランタイム)の無駄になってない?

>>399
ぬるぽはdelete[]してよし。
でも、>>392のコードでbad_alloc飛んだときはpへの代入は実行されてない。

402 :仕様書無しさん:03/05/05 04:07
おっとすまん、無駄というのは完全な間違いだったよ

そうではなくてこう・・・
ちょっと説明できないけど
読みやすさというか整合性というか
そういうのを考えるとそうしてしまう

でも全く使わないというわけではない
for(int i = 0; i < count; ++i)は今でも普通に使ってる

ちなみに以前は宣言時にできるだけ初期化してたけど
長くやっていて自然と宣言時に初期化しなくなっていた


403 :仕様書無しさん:03/05/05 04:10
それとnewの場合は例外使わずエラーチェックしてるけどまずいのかね?

char *p = new char[4];
if(!p)
 ErrorFunc();


404 :仕様書無しさん:03/05/05 07:32
>403
あなたの使うnewが失敗時に例外を投げず0を返すってことが
確実ならいいと思うけど…

405 :仕様書無しさん:03/05/05 11:55
>>392
本来必要の無い delete を書くことが間違ってる。

とにかく初期化するクセを付けとくと、バグコードもごまかせるよ、て話?

406 :392:03/05/05 14:14
>>405
>本来必要の無い delete を書くことが間違ってる。

確かに >>392 の例では delete は不要だね。俺も通常は書かない。

だけど、あるクラスライブラリの提供しているメソッドがあって、そのメソッ
ドを利用しているプログラムのバグ (バグ仕込んだのは俺じゃないので。
念のため) ではまった。負荷テスト時にプロセスが core dump した。

そのメソッドは引数がポインタの参照渡しになってて、例外発生時に
ちゃんとそのポインタが更新されるてるのかそうじゃないのかが呼び出し
元からだと判断つかないんだよ。0 で初期化しとかないとね。そのメソッドは
ちなみにメモリ確保系で引数に渡すポインタにその領域へのアドレスを
セットするようになってる。


407 :392:03/05/05 14:15
こんな感じ。

char* str;
T t;
...
try {
  t.alloc(str);
}
catch (T::AllocException& e) {
  // delete[] str??
  ...
}  

仮にそのメソッドが「メモリを確保した後」例外を返したならば、delete
しないとメモリリークだよねぇ? マニュアルにはそのへんのことが何も
載ってないからどうすればいいか分からない。ほとんどの実装では
メモリ確保できなかったから例外を返すんだろうけど。

極端な実例かも知れないけど、こういう場合だとやっぱりポインタ
を初期化しないとまずい。VC++ だと未初期化変数使用時には警告
を出すのか・・・。多分俺の使ってるコンパイラもそういうオプションが
あるんだろうな。今度調べてみるよ。しかしまあ常にまともな奴が
プログラムを修正するとは限らないんだから、安全側に振っておく
意味でも俺は宣言時の初期化は大事だと思う。

408 :仕様書無しさん:03/05/05 15:20
>>407
そこまで気にするのならリソースの
ラッパクラスを作ってみては?

あと「ライティングソリッドコード」で、
変数はありえない値(アドレスに奇数など)で初期化しておき、
参照されたらすぐ落ちるようにする、
というガイドラインがあったような。

409 :仕様書無しさん:03/05/05 15:47
↓読めば、未初期化変数が良くない理由がよくわかるよ。
ttp://groups.yahoo.com/group/boost/files/coding_guidelines.html#decl_initialization
ということで、初期化しないとconst使えねーじゃねーか。
>>402はconstを使わない人かな?

>>392
その例を理由に初期化を勧めるのは明らかにおかしい。
その例と未初期化の変数は、まるで関係ないと思う。

410 :仕様書無しさん:03/05/05 17:15
>>409
>>402は、初期化しないんじゃくて、
無駄になる初期化は書かないと言っているので、

>>ということで、初期化しないとconst使えねーじゃねーか。
>>>>402はconstを使わない人かな?
の突っ込みはおかしい

411 :仕様書無しさん:03/05/05 17:32
>>410
> > おっとすまん、無駄というのは完全な間違いだったよ
ということなので、「無駄になる初期化は書かない」なんて言っていないと思われ。

constの有効性を認めていれば、
> 長くやっていて自然と宣言時に初期化しなくなっていた
なんてことにはならないと思う。

412 :仕様書無しさん:03/05/05 17:37
>>408
>>ライティングソリッドコード
「マイクロソフトが実践してるバグ根絶手法」って眉唾物に感じるんだけど、
使える資料なのかな?もしかしてMS環境のみって事はないよね?

>>ラッパクラス
STLにはauto_ptrなるモノが用意されているみたいだけど、周りで使っているヤツを見たことがない。
便利そうな機能がある反面、副作用もありそうな気配がする。
コレ使ってる人います?


413 :仕様書無しさん:03/05/05 17:57
これ以上スレ違いな話題をつづけるなら、別スレに引っ越した方がいいとおもうのだが、
適当な引越し先はないのかね?

414 :仕様書無しさん:03/05/05 18:56
>>412
>「マイクロソフトが実践してるバグ根絶手法」って眉唾物に感じる
・・・何とも言えません。

>副作用もありそうな気配がする
「所有権」と言う概念を常に意識しておかないと、
副作用がある。
boost::scoped_ptrはもっと副作用が少なくて使いやすい。

415 :仕様書無しさん:03/05/05 21:27
>>412
auto_ptr 系列クラスを使ってる奴が皆無の職場か・・・
辞めたくなりません?

416 :412:03/05/05 21:34
>>414
>>「マイクロソフトが実践してるバグ根絶手法」って眉唾物に感じる
>・・・何とも言えません。
(´・ω・`)

>auto_ptr
thxやっぱそうなんだ。
boostは存在だけは知ってたけど、標準ライブラリじゃないから導入にはちょっと後ろ向きだったりする。
プログラム板のboostスレでも覗いてくるわ。

>>415
もう辞めました(・∀・)

>>413も言われてるように激しくスレ違いなわけなんだが、
どうも、糞コード→リファクタリング→コーディングスタイル&ポリシーの議論
って相性がいいみたいで脱線しちゃうようだ。
この手のトピックってどういったスレで展開すべきなんだろう?

417 :仕様書無しさん:03/05/05 21:38
>「マイクロソフトが実践してるバグ根絶手法」

「それは仕様です」ってやつだろ

418 :仕様書無しさん:03/05/06 00:52
>>417
ワラタ

419 :仕様書無しさん:03/05/06 02:20
>>408
> 変数はありえない値(アドレスに奇数など)で初期化しておき、
> 参照されたらすぐ落ちるようにする、
0xCDCDCDCD
0xFDFDFDFD
の類ですな。
Windowsで通常のアプリではありえない値。
ぬるぽも同じだと思うけどね。

420 :仕様書無しさん:03/05/06 02:32
フフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフフ

421 :仕様書無しさん:03/05/06 03:11
十字架も出なかったっけ?


422 :仕様書無しさん:03/05/06 18:52
ヒヒヒヒヒヒヒヒヒヒヒヒヒヒヒヒヒヒヒヒヒヒヒヒヒヒヒヒヒヒヒヒヒヒヒヒヒヒヒヒヒヒヒヒヒヒヒヒ

423 :仕様書無しさん:03/05/06 20:52
>>419
Unix の場合はどんなアドレスがいいのかな?

424 :仕様書無しさん:03/05/06 20:54
つーか、NULL でいいじゃん。妙な値入れると逆に、何か意図でもあるのかと思ってしまう。


425 :仕様書無しさん:03/05/06 22:10
NULLだとエラーなのかありえない値なのか区別できんがね。

426 :仕様書無しさん:03/05/06 22:27
>>424
いや、NULLと区別するために、わざと「妙な」値にしてるんだけどな。
意図的に。


427 :仕様書無しさん:03/05/06 23:25
SJISの文字列長をバイト単位で求めるのに、

int length; //長さ
char str[255]; //文字列
int cnt;

for(cnt = 0; cnt < 255; cnt++)
{
  if(str[cnt] == 0)
  {
    length = cnt;
  }
}

とかやってた。
一瞬組み込み機器のプログラムでもやってるかと錯覚した。


428 :仕様書無しさん:03/05/06 23:31
>>427
'\0'より後ろはどうなってるのかと(ry

429 :仕様書無しさん:03/05/06 23:59
コボラーですが、配列の添字は配列とセットで宣言するようにしてます。
意味のある(開始位置、終了位置など)の添字は別途宣言してます。
だいたいこんな感じ。

IX_TBL PIC S9(2) BINARY.
MAX_TBL PIC S9(2) BINARY VALUE 100.
1 TBL OCCURS 100.
3 TBL_CD PIC X(2).

PERFORM VARYING IX_TBL FROM 1 BY 1 UNTIL MAX_TBL < IDX
MOVE TBL_CD(IX_TBL) TO ・・・

添字にIJKLが飛び交うほうがやめたくなります。

430 :仕様書無しさん:03/05/07 00:13
今日発掘された先輩のソース

#define DATA_SIZE 15
int MainData[DATA_SIZE];
#undef DATA_SIZE
#define DATA_SIZE 20
int SubData[DATA_SIZE];
#undef DATA_SIZE
#define DATA_SIZE 80
int BackUpData[DATA_SIZE];
#undef DATA_SIZE

何がしたかったのか聞いたところ、
「define覚えたばかりで使いたかった」とのこと。

辞めたいと思ったよ・・・・


431 :仕様書無しさん:03/05/07 00:49
>>423
0xDEADBEEF

432 :仕様書無しさん:03/05/07 01:37
0xdeadface
0xbabeface

433 :仕様書無しさん:03/05/07 02:31
関係ないけど、「フフフフ・・・・」

って何?ときどき、ログとかで見かけるんですが
何か元ねたでもあるんでしょうか?
(無知でごめん)

434 :仕様書無しさん:03/05/07 07:35
0xBABEL

435 :仕様書無しさん:03/05/07 11:31
>>434
怖すぎです

436 :仕様書無しさん:03/05/07 17:12
>>424-426
どっちも大差ないだろw
#define UNINITIALIZED NULL
なり
#define UNINITIALIZED ((void*)0xCDCDCDCD)
なりにしておけば?

// 俺はそんなキモイコード見たくない

437 :仕様書無しさん:03/05/07 20:21
>434
ワロタ。

438 :仕様書無しさん:03/05/07 21:41
>>436
何か全然分かってない香具師だな。

439 :仕様書無しさん:03/05/07 22:14
>>433
S-JISだと フ は 0xCC

440 :仕様書無しさん:03/05/07 22:53
>433
ねおむぎ

441 :仕様書無しさん:03/05/07 23:13
>440

それは0xCBCBCBCBCBだ

442 :ネタじゃないぞ:03/05/08 00:11
そーいえば、昔Win95で「の」以外の文字が「フ」に化けて
画面中「フフフのフフフ」だらけになった事があった。

デバッグコードでも走ってたんだろか。
「の」だけ化けなかったのは謎が残るが…

443 :仕様書無しさん:03/05/08 03:36
>>436
だーかーらー、何度言えばわかるんだ。
ソース上で見て分かるんならNULLでいいんだよ。
これは、ランタイムにデバッガなんかで見た時にそういういかにもな値が入っていると初期化忘れがわかりやすいという理由でこういう値(0xDEADBEEFとか)にするんだよ。

わかるー?


そういえばどこかのコンパイラで、デバッグバージョンだとmalloc()した領域が0xdeadbeefで初期化されるってのがなかったっけ?


444 :仕様書無しさん:03/05/08 03:48
俺としては初期化忘れで論理エラーに繋がることが怖いのだが。
コンパイラが報告してくれなくても「ぬるぽ」でわかる。
null初期化は賛成。明示的初期化も賛成。


445 :仕様書無しさん:03/05/08 04:17
>>444
>初期化忘れで論理エラーに繋がる
そうならないように特定の値で初期化するんだろ。
nullで初期化したら正しいnullなのか初期化忘れのnullなのか区別できんだろ。

446 :仕様書無しさん:03/05/08 04:42
コンストラクタで全てのフィールドを初期化するのって、見た目がカコワルクならない?
オブジェクトの初期化はどうしてまつか?

// フィールド
private HashMap map = null;

public void ほげほげ() {
 // 使うときにメソッド内部で初期化
 map = new HashMap();
 return;
}


それとも、
// フィールド
private HashMap map = new HashMap();


447 :仕様書無しさん:03/05/08 04:48
>>446
実行途中でnull値を取り得る可能性が有るなら前者。
そうでないなら後者。

448 :仕様書無しさん:03/05/08 09:54

MessageBox("入浴されていません");



449 :仕様書無しさん:03/05/08 21:59
char a[9+1];
char b[9+1];
 …
if(lstrlen(a)==lstrlen(b){
  if(!memcmp(a,b,lstrlen(a)){
    ZeroMemory(a,sizeof(a));
    lstrcat(a,"localhost");
  }
}

まあ、会社辞めよう思うほどのコードでもないけど。
memcmpに否定演算子みたいな書き方って一般的には使われてるのかな?

450 :仕様書無しさん:03/05/08 22:12
>>449
> memcmpに否定演算子みたいな書き方って一般的には使われてるのかな?

普通に使ったりするけどね。
それよりも

> char a[9+1];
> char b[9+1];

何の意図があるのかと(ry

451 :仕様書無しさん:03/05/08 22:35
9文字+NULの意図かと?
マジックナンバー埋め込みはやらないけど、+1って書き方は良くやる。駄目?

452 :仕様書無しさん:03/05/08 22:38
/* start 2002/01/01 suzuki st2-89 */
switch(return_code){
/* start 2002/04/26 suzuki st2-157 */
/* case 1: */
case RETURN_OK:
/* 処理2 */
break;
/* case 2: */
case DATA_ACS_ERROR:
/* 処理2 */
break;
/* start 2002/03/20 suzuki st2-141 */
/* case 3: */
case PRS_COM_ERROR:
/* 処理3 */
break;
/* end 2002/04/26 suzuki st2-157 */

略(あと5つくらい似たようなのが続く)
/* end 2002/03/20 suzuki st2-141 */
default:
break;
}
/* end 2002/01/01 suzuki st2-89 */


453 :仕様書無しさん:03/05/08 22:40
>>449
確かに、微妙に嫌なコードだな…
・lstr???とchar[]の組み合わせ
・なぜかmemcmp(しかもlstrlen(a)を2回呼んでるし)
・なぜかゼロクリアしてからstrcat
こんなとこくらいか?

>memcmpに否定演算子みたいな書き方って一般的には使われてるのかな?
常套句。でもあまりお勧めはしない

>>450
9文字分+終端NULLと言う意図以外に何かある?
9っていう数字が何処から来たか?なら不明だけど

454 :449:03/05/08 23:03
>>453
>>memcmpに否定演算子みたいな書き方って一般的には使われてるのかな?
>常套句。でもあまりお勧めはしない
そっか。常套句か。なら覚えておこう。

455 :仕様書無しさん:03/05/08 23:12
>>427
ループの終わりまで0が見つからないとlengthが不定になる罠


456 :仕様書無しさん:03/05/08 23:14
>>455
どっかに0があることが保証されてるんでしょ

457 :449:03/05/08 23:27
>>455
むしろ0がいっぱいあったときに予定通りの値になるのか

458 :仕様書無しさん:03/05/09 00:35
今やってる仕事、JavaとCOBOLのハイブリッドなんだが、
COBOL捨ててJavaとTorqueで書くと半日あれば求められてる機能が
全部実装出来ることに気が付いた。
現在、JavaからCOBOLを呼び出すパートで3人が数週間拘束されている。
COBOL側は何人がどれだけ働いてるんだか・・・
FはとっととCOBOL捨てろよ。


459 :仕様書無しさん:03/05/09 00:39
>>458
2行目あたりでFの香りに気づいたオレって・・・

460 :仕様書無しさん:03/05/09 00:54
javaのソースコードを見て、クラスメンバがすべてstaticだった時。
アーアーアーアーアーアーアーアーアーアーアーアーアーアーアーと
さけ びたく、なりま。した

461 :仕様書無しさん:03/05/09 01:02
>>460
イク寸前

462 :仕様書無しさん:03/05/09 01:53
>>460
別にいいじゃん。性的で。

463 :仕様書無しさん:03/05/09 02:41
>>462
ぬるぽ印の座布団進呈

464 :仕様書無しさん:03/05/09 11:36
>>455

むしろ>>427で一番問題なのは、
Shift_JISを想定してるのにリードバイト判定してない事だと思われ。

465 :464:03/05/09 11:47
いや待てよ・・・
str[255]=SJIS文字列  0  0以外のバイト列
なら成功する処理なのか?

466 :バキュ ◆b.4YMMQI62 :03/05/09 12:31
(´・ω・`)久々に2ヒットしたのに名前書くの忘れてた >>434

467 :仕様書無しさん:03/05/09 19:13
>>466
手柄を横取りですか。流石ですね(w

468 :仕様書無しさん:03/05/09 19:26
直前に

memset(str, 0xff, 256) /* これをとるとなぜか動かない */

があるんだろう。きっと

469 :仕様書無しさん:03/05/09 20:45
>>460
思う存分叫ぶが良い。
http://java.sun.com/products/jdk/1.2/ja/docs/ja/api/java/lang/Math.html

470 :仕様書無しさん:03/05/09 21:49
>>468
さすがにそれくらい普通のコードなら
原因調べて分かるでしょ
そういうコメントは

int a;
a = a;  /* これをとるとなぜか動かない */
...

のように使うものかと。

471 :仕様書無しさん:03/05/10 00:52
>>470
なぜそんなもの入れると動くようになると分かったのかと
小一時間


472 :仕様書無しさん:03/05/10 01:09
a = a++;
さて、どうなるでしょう。

473 :仕様書無しさん:03/05/10 01:10
バッファーオーバーランでaの領域に食い込んでいるけれど、
a=aが無いと最適化のせいでaが消えるため。

474 :仕様書無しさん:03/05/10 01:22
>>472
なるようにしかならん罠

475 :仕様書無しさん:03/05/10 01:35
>462のいいじゃんstaticでという言葉を見てまたさらに発狂したくなりましいた

476 :仕様書無しさん:03/05/10 01:56
なぜだかわからないことってポンパイラの仕様とメモリに起因するものがほとんど。
俺もポンパイラって書いてる時点で(ry

477 :仕様書無しさん:03/05/10 02:41
見つけた時なんとなくうれしいw

478 :仕様書無しさん:03/05/10 09:05
$ ls
TanakaHonBuchoNoKaminoHitoKoe TanakaHonBuchoNoKaminoHitoKoe.cpp
TanakaHonBuchoNoKaminoHitoKoe.o

ソースコードじゃないな・・・


479 :仕様書無しさん:03/05/10 09:11
>>469
Mathはインスタンス作らないから良いんでは?
>>460の見たソースは、「2つ以上インスタンスが同時に存在すると、

480 :479:03/05/10 09:18
途中で送信しちゃったよ(´Д`)

きっと>>460の見たプログラムでは、常にひとつしか
インスタンスが存在しないんだろうなぁ・・・。
という事で。

481 :仕様書無しさん:03/05/10 09:39
複数インスタンスのために別名で静的なクラスをもうひとつ定義してたりして

482 :仕様書無しさん:03/05/11 11:32
class SonyTimer;


483 :仕様書無しさん:03/05/11 11:47
車オタクの奴がプログラムを
車の構造に当てはめて書いたであろうソースを引き継いだ。

キャブレタだのアクチュエータだの出てきてようわからん。


484 :仕様書無しさん:03/05/11 13:17
スレッドもタスクも使用しないで
mainが数千行のswitch〜caseで
場合分けされていたのには参りました。

そしてメインが一言、「見やすいプログラムでしょ?」


485 :仕様書無しさん:03/05/11 13:25
どうすりゃいいの?
      /        /       |    ヽ           \
 ∧ ∧/         /      |     ヽ          ∧\∧
( / ⌒ヽ        /         |       ヽ         ( / ⌒ヽ
 | |   |         /         |      ヽ           | |   |
 ∪ / ノ         /        |        ヽ         ∪ / ノ
  | ||   ミ    /            |           ヽ       / / /
  ヽ_)_)     ∧/∧         |        ∧ヽ∧  彡  しl_ノ
        ( / ⌒ヽ        |        ( / ⌒ヽ
 
 日本ロジテムの子会社せいも素で過労による自殺者が出た。
http://www.samos.co.jp
http://society.2ch.net/test/read.cgi/traf/1046749189/l50
http://tmp.2ch.net/test/read.cgi/company/1046775680/l50


486 :仕様書無しさん:03/05/11 14:22
>>484
タスクの使用って何??

487 :仕様書無しさん:03/05/11 15:03
帯に短しタスクに長し
・・・昼寝するか

488 :仕様書無しさん:03/05/11 15:05
渡辺タスク

489 :仕様書無しさん:03/05/11 15:15
変なやつばかり。タスクてくれ〜!

490 :仕様書無しさん:03/05/11 17:51
>>484

スレッド:=2chにおける「スレッド」のようなもの。

タスク:=2chにおける「板」のようなもの。



491 :仕様書無しさん:03/05/11 18:35
>490 ウソクサ

492 :仕様書無しさん:03/05/11 19:00
芸は身をタスク

493 :仕様書無しさん:03/05/11 19:57
フリートウッド・マック

494 :仕様書無しさん:03/05/11 23:39
>>493
勢いに任せて懐かしいものを・・・ベストヒットUSA世代ですか?

495 :仕様書無しさん:03/05/12 02:38
>>449
遅レス。
memcmp() の戻り値を論理演算子でどうにかするヤツとは
確かに仕事したくないな。これを常套句といっている>>453もヤだ。

496 :453:03/05/12 03:11
>>495
煽ってますか?
使う人間が多いから常套句と書いただけなんだが

497 :仕様書無しさん:03/05/12 11:55
try {
 ・・・・・・・
} catch (Exception e) {
 if(e instanceof XXXException) {
   throw (XXXException)e;
 } else {
  throw new XXXException(......);
 }
}

アフォかと。

498 :仕様書無しさん:03/05/12 12:10
>>497
ぬっころせ

499 :仕様書無しさん:03/05/12 23:44
>>495-496
常套句というか常識だと思ってたんですが…

500 :仕様書無しさん:03/05/13 01:04
>>499
数値に論理演算キモイ

501 :仕様書無しさん:03/05/13 01:27
では、ポインタに論理演算はどれくらい受け入れられるのかね?

502 :仕様書無しさん:03/05/13 01:29
memcmp()におけるパラメータが等価時の戻り値が
「偶然」、論理式の偽の値と同じである事を
混用しているのあって、例えコンパイラが許し
実装が許したとしても、意味論的には許しがたい点が
多くの批判を引き寄せているといっても過言では無い。








というコーディングだから批判されちゃうワケ。

503 :仕様書無しさん:03/05/13 01:39
>502
その幾つもの空行を入れるレス、何とかならんか!

504 :仕様書無しさん:03/05/13 02:02
>>503
同意。
書き込みにおいて改行を連続入力した数が
「偶然」、表示される改行の数と同じである事を
混用しているのあって、例えCGIが許し
ブラウザが許したとしても、読者的には許しがたい点が
多くの批判を引き寄せているといっても過言では無い。

505 :仕様書無しさん:03/05/13 02:06
>>504 といいつつ改行を入れてネタにしないのを批判されるワケ。

506 :仕様書無しさん:03/05/13 02:12
まったく、良心的なデベロッパ以外は消えろ

507 :仕様書無しさん:03/05/13 07:42
>>504
マ板はネタが命。>>505の言う通り。

508 :仕様書無しさん:03/05/13 11:39
「この板辞めようと思ったネタレス#0」はここですか?

509 :仕様書無しさん:03/05/13 22:42
ソースじゃないけど、ライブラリのディレクトリを覗いたら、
libxxxx.so.確認したのかよ!!
libxxxx.so.動くようにしろよ
libxxxx.so.再起動したら異常終了した
なんていうファイルがいくつもあった


510 :仕様書無しさん:03/05/13 23:58
>>506
そして誰もいなくなった・・・

511 :仕様書無しさん:03/05/14 01:13
>>510
そうだな。まずいソースを見ても、不景気だからみんな辞めようとは
思わないみたいだな

512 :仕様書無しさん:03/05/15 22:27
>>495 >>500あたりはJavaプログラマなんじゃないかな…と言ってみるテスト

しかし人いないね

513 :仕様書無しさん:03/05/15 22:42
>>512
Java は関係ないだろ。

bool を int に格上げするキモイ C++ プログラマもどきだっているしな。

514 :仕様書無しさん:03/05/15 23:34
というかBOOLがキモイ。勘弁してくれマイクロソフト。

515 :仕様書無しさん:03/05/16 00:15
intでbool的な論理演算するのは気にならなくても、
boolをintに格上げするのはすっごく気持ち悪い。

516 :仕様書無しさん:03/05/16 09:01
>>514
むしろ、INTとかLONGの方が(以下略

517 :仕様書無しさん:03/05/16 22:00
valiant

518 :仕様書無しさん:03/05/17 00:23
valiant最強伝説

519 :仕様書無しさん:03/05/17 01:18
で、valiantって何?勇敢な人?

520 :仕様書無しさん:03/05/17 01:31
java.lang.Objectの斜め上45度を行くヒーロー

521 :仕様書無しさん:03/05/17 01:32
>>519
valiant型

    ○VB厨が勇敢に, 雄々しく使う型

    <例> Dim a, b, c As Integer

522 :仕様書無しさん:03/05/17 11:25
それは variant ではないのか

523 :仕様書無しさん:03/05/17 13:06
プログラマは自分が確保した領域の名前と何が入っているかだけはおさえて欲しいよ。
つーか新人教育はここからはじめて欲しい…

●信長 は 三河 の 田4反 (ただし麦が植えてある) を 領土とした。

初心者はこの仕様を見て、
水が入ってるとかオタマジャクシがいるとか妄想しはじめるからな。

この場合、変数名と内容の違い自体が大問題だけど、現実の仕様もこんなもんだ

524 :仕様書無しさん:03/05/17 13:14
つーか、領域の名前と何が入ってるか
だけだと、その先が続かない罠

田は水と土の上にあってね
みたいな話がポインタに繋がるような気がしないでもない

525 :仕様書無しさん:03/05/17 13:42
●信長 は 三河 の 田4反 (ただし麦が植えてある) を 領土とした。

三河の田4反 = 田(三河,4);
三河の田4反.作物 = 麦;

信長.領土とする(三河の田4反);


新人でつが、こんなんじゃだめでつか?


526 :仕様書無しさん:03/05/17 14:43
>>525
田んぼは配列にしたほうがいいかも。

527 :仕様書無しさん:03/05/17 18:29
>>525
オブジェクト指向的に考えるなら
三河は、既に田を持っているようにすべきかと。
三河.田みたいにね。

いや、他の部分に比べてそこだけちょっと違和感感じたから一応ね

528 :仕様書無しさん:03/05/17 19:08
class 年貢{
 +取り立て ( 蔵 )
}
class 領地 {
 -所在地
 -面積
 -年貢目録
 +領地 ( 所在地, 面積, 年貢目録 )
 +取り立て ( 蔵 )
}
class 武将 {
 -蔵
 -領地目録
 +領土とする ( 領地 )
}

目録<年貢> 三河の田4反の年貢
三河の田4反の年貢.add ( 麦 )
領地 三河の田4反 ( 三河, 4反, 三河の田4反の年貢)
武将 信長
信長.領土とする(三河の田4反)

529 :仕様書無しさん:03/05/17 22:38
>>528 これは会社を続けようと思ったソースコードでしか?

530 :仕様書無しさん:03/05/17 23:53
VBのプロジェクトを開いたところ、
20ほどあるソースファイルの中に"Private"という単語が存在しなかった。
そして"Function"も存在しなかった。


531 :仕様書無しさん:03/05/18 00:45
>>530
みんな普通に使ってるよ?ちゃんとした思想のもとでやってるからね。
勉強して来なさい。


532 :仕様書無しさん:03/05/18 00:57
まあ、まどろっこしい話し方する上司がたくさん居るところも辞めたくなるがな。

533 :仕様書無しさん:03/05/18 01:40
>>532
>まどろっこしい話し方
どんな話し方?具体例きぼんぬ

534 :仕様書無しさん:03/05/18 01:52
ナニ?「織田信長」?

535 :仕様書無しさん:03/05/18 03:11
>>533
分かりにくい例え話の上に、同じところばかり何回も繰り返して言い
なかなか全部を言い終わらない話し方です。
いつまでたっても、文末がやって来ない。
具体例を出そうと思ったが、俺にはそんな文才はありませんでした。

会議でこういう人が発言すると死にそうになるよ。

536 :仕様書無しさん:03/05/18 06:48
>>535
あるある。
こっちがYesかNoの質問したのに、長々と話を続けて最後はうやむやになって終わってしまう。
結局「はい か いいえ で答えろ」と言わざるを得ない。モウネ、アフォカト

537 :536:03/05/18 06:49
あれ?ちょっと違ったかな・・・。マ、イッカ

538 :仕様書無しさん:03/05/18 08:14
つか、上にも下にもはっきりした答え出さないヤシ多いね。

そういうヤシの試験報告書とか見ると頭痛くなってくる。

539 :仕様書無しさん:03/05/18 10:39
定期的な会議で、
上層部は毎回同じ様な事話してばっかり。
しかも会社の将来真っ暗な話題が多いし、視野が狭い。
Webを「ウェーブ」と言う。
会社の終末は近いかもしれん。

540 :仕様書無しさん:03/05/18 15:27

パナウェーブ

541 :仕様書無しさん:03/05/18 17:28
アフォ上司の話はこちらで

この会社辞めようと思った上司の一言#9
http://pc.2ch.net/test/read.cgi/prog/1052406871/l50


542 :仕様書無しさん:03/05/18 17:46
>>539
ウェーブでも間違っていないと思うが・・・
ウェイブなら間違いだけど


543 :仕様書無しさん:03/05/18 17:53
>>542
ウェッブなら間違ってない。
ウェーブはwaveだろ。

544 :仕様書無しさん:03/05/18 18:01
>543
waveはウェイブだろ


545 :仕様書無しさん:03/05/18 18:09
>>544
ウェッウェッ おまいらは志村けんか。

546 :仕様書無しさん:03/05/18 19:24
英語をカタカナ表記しようとすること自体に・・・

とりあえず、ここで発音聞けば分かるが、webは伸ばしちゃダメだわな。

ttp://eiwa.excite.co.jp/view.jsp?block=44386&offset=682&id=NEW_EJJE

547 :仕様書無しさん:03/05/18 20:19
まぁ、トゥクッピプゥには勝てないわけだが

548 :仕様書無しさん:03/05/18 20:42
>>547
トゥ・・・TCP/IP?

549 :仕様書無しさん:03/05/18 20:44
>>547-548
オモシロ

550 :仕様書無しさん:03/05/18 21:48
この会社やめようと思った上司の一言#7から。

 322 名前:仕様書無しさん[sage] 投稿日:03/01/25 13:51
 今度の上司、TCP/IPを「とぅくぴっぷ」と読むんだよ。
 お前はガッちゃんかと。

今まで聞いた言い間違いの中では最強ですね。

551 :仕様書無しさん:03/05/18 22:07
ガッチャンみたいだな。クッピップー

552 :仕様書無しさん:03/05/18 22:15
もしかして「ホームページ」は「ウェッブページ」と
呼ぶべきだ!と強く主張する方ですか?

553 :仕様書無しさん:03/05/18 22:19
>>552
何かずれてるよ。

554 :仕様書無しさん:03/05/18 23:56
うん。ずれてる

555 :仕様書無しさん:03/05/19 00:05
Φ's

556 :仕様書無しさん:03/05/19 00:06
直しなよ。ズラ。

557 :仕様書無しさん:03/05/19 07:55
タラちゃんの足音なみの怪音だな。>>547

558 :仕様書無しさん:03/05/19 19:00
>>550
UDP/IPはどう読むのか、聞いてきてくれ。

559 :仕様書無しさん:03/05/19 19:18
>>558
「うどぅぴっぷ」じゃないか?


560 :仕様書無しさん:03/05/19 19:55
ゆーでーぴー すら あいぴー

おまえら情けないぞ

561 :仕様書無しさん:03/05/19 20:12
>>560
釣られんな。しかもageんな。流れを読め。

562 :仕様書無しさん:03/05/19 20:17
>>561
読めてないとでも?

563 :仕様書無しさん:03/05/19 20:32
>>562
どう考えても読めてないし、
そんなことより重要なことは、
うすら寒いってことだ。

564 :仕様書無しさん:03/05/19 20:38
>>563
敢えてやってみたのだが?
あんたみたいなのを釣るために。

565 :仕様書無しさん:03/05/19 20:48
>>564
あらら、「釣れた」って言っちゃった。

566 :仕様書無しさん:03/05/20 00:14
「GUI」を「ぐい」って呼ぶのは割と一般的なんでしょうか?
新しいプロジェクトに移ったら、客先含めみんなこう言ってるみたいですが。

567 :仕様書無しさん:03/05/20 00:43
http://www.google.com/search?hl=ja&ie=UTF-8&oe=UTF-8&c2coff=1&q=%E3%81%90%E3%81%84%E3%80%80%E3%81%98%E3%83%BC%E3%82%86%E3%83%BC%E3%81%82%E3%81%84&btnG=Google+%E6%A4%9C%E7%B4%A2&lr=lang_ja

568 :仕様書無しさん:03/05/20 01:13
>>566
「ぐい」はまあまあ通じる。
CUIを「きゅい」または「くい」とはいわないけどね。

569 :仕様書無しさん:03/05/20 01:18
GUI   グーイ
CUI クーイ

これが正しい読み方。マジレス。

570 :仕様書無しさん:03/05/20 01:31
>>569
なるほど。
GUIの時は一呼吸おいてから読むのが正しいのか。

571 :仕様書無しさん:03/05/20 01:35
>>569
正しくてもそういう読み方は人前では出来ない

572 :仕様書無しさん:03/05/20 02:46
http://www.wikipedia.org/wiki/GUI

573 :566:03/05/20 03:10
>>572
GUI, often pronounced "goo-ee"

おお、ほんとに「ぐーい」・・・感動した!!
明日から気兼ねなく「ぐい」を使おう

574 :ヽ(´ー`)ノ:03/05/20 09:10
他のところも張ってみる。
http://www2.alc.co.jp/ejr/index.php?word_in=GUI
> 略語のGUIは「グイ」と発音する。
マジか(;´Д`)オッサンの読み方だと思ってた


575 :仕様書無しさん:03/05/20 09:50
むしろGUI(ガイ)

576 :仕様書無しさん:03/05/20 12:28
GUI=ジー・ユー・アイ

577 :仕様書無しさん:03/05/20 18:41
GUY=ケツ・を・貸・せ

578 :仕様書無しさん:03/05/20 18:44

G O Group = ジー・オー・グループ

579 :仕様書無しさん:03/05/20 20:10
ってか、技術者発音のディをデーとか読んだり
ティをテーとか読むのに違和感覚えまくりの新人。

580 :仕様書無しさん:03/05/20 20:16
>>579
慣れたらそうでもなくなるよ。君も半年後には「デーデー」言ってる。

581 :仕様書無しさん:03/05/20 20:45
にちゃんねるの厨房文化に慣れるのも、そんなに時間かからないわけだし。

582 :仕様書無しさん:03/05/20 21:07
A アー
B ベー
C ツェー
D デー
「デー」で何も問題ないだろ?
もしかして外国語=英語の人?(プ
どうせおまいもヴァイラスのことをウィルスとかビールスって言ってんじゃねぇのか(プ


583 :仕様書無しさん:03/05/20 21:28
>>582
大変そうですね
がんばってください

584 :仕様書無しさん:03/05/20 22:02
>579
だって綺麗に発音するとあんた聞き取れないんだもん(藁
ディーヴィーディーよりデーブイデーのほうが、あんたでも聞き取れるだろ。

585 :仕様書無しさん:03/05/20 22:32
エイチ・ディー・ディーって言われると違和感あるよな

エヌ・ティー・ティーは大丈夫だけど
たぶん俺はエヌ・テー・テーって言っちゃてると思う

586 :仕様書無しさん:03/05/20 22:36
シーデー
と言ってしまいます



587 :仕様書無しさん:03/05/20 23:04
ミカカ

588 :仕様書無しさん:03/05/20 23:22
会社を辞めようと思ったソースコードだぞ>>おまいら

589 :仕様書無しさん:03/05/20 23:54
>>584
大変そうですね
がんばってください

590 :仕様書無しさん:03/05/21 02:06
1ヶ月程前から火消しに参加しているプロジェクト。

・コメント無しでヘッダファイルを山のようにインクルードしている
・グローバル変数とローカル変数の名前分けが無く区別がつかない
・モジュール変数とローカル変数の名前分けが無く(略)
・マクロ定数と変数の(略)
・ネストしまくりのif文switch文
・一つの関数でreturn文が10個以上
・当然return文にはカッコは欠かせません
・スペースが適当
・ブロックが適当
・というかインデントもずれてる

タスケテ…(つд`)

591 :仕様書無しさん:03/05/21 02:18
コーディングスタイルの話でスマンが

const int count=123;
for(int i=0;i<count;++i){
 x[i]=i;y[i]=i+1;z[i]=i+3;
}
if(x[100]==-13){ErrorMessage("error!");}
else if(y[3]<=32){sprintf(str,"%s%d","mes,z);

↑みたいに空白をほとんど使わないコードみると
見にくいだけじゃなく、すごく気分が悪くなる


592 :仕様書無しさん:03/05/21 02:22
>>591
これはあれか、いやがらせか。

593 :仕様書無しさん:03/05/21 02:29
>>591
同感。思わず読み飛ばしそうになる。いや、むしろ読み飛ばせ

594 :仕様書無しさん:03/05/21 02:33
それと、マジックナンバーが意味するものが見えない・・・。
上司は、まだかまだかと急かすし。


595 :仕様書無しさん:03/05/21 02:33
このスレだったかに以前
cppファイル一つに40000行を超えるコードのゲーム晒されてたけど
あれも空白ほとんどつかってなかったなぁ
まぁ空白以前の問題だったけど


596 :仕様書無しさん:03/05/21 02:50
たぶんメモリの制限・・・RAMが32KBしか入ってないのでは?

597 :仕様書無しさん:03/05/21 02:55
Javaのsrc.jarの中見ると、イライラする。
なんで { がないのだ。なんで変数名がわけわかなのだ。
それにjava.lang.Stringがあれ程importしてるとはな。
なあ、Johnよ。可読性って知ってるか?

598 :仕様書無しさん:03/05/21 03:45
>なあ、Johnよ。可読性って知ってるか?
ナンテヨメバイインデスカ?

599 :仕様書無しさん:03/05/21 07:37
>590
なんかツール一つで解決できそうなことも含まれているな

600 :仕様書無しさん:03/05/21 07:40
>>599
Eclipseに頼りすぎ

601 :仕様書無しさん:03/05/21 08:54
Anti-Virusを「ウイルスソフト」と呼ぶのは辞めてホスイ......

602 :仕様書無しさん:03/05/21 09:23
indent(2)

603 :仕様書無しさん:03/05/21 10:14
おまえら、indent コマンドも知らないのですか?

604 :仕様書無しさん:03/05/21 10:35
>>601
ハードディスクをハードと略したりとかな。

605 :仕様書無しさん:03/05/21 11:55
>>604
フロッピーディスクをフロッピーって略したりな。


606 :仕様書無しさん:03/05/21 12:25
コンパクトディスクを(ry

607 :仕様書無しさん:03/05/21 12:32
>>602
(2)か。どんなOSなんじゃろ。

608 :ヽ(´ー`)ノ:03/05/21 12:50
>>602,>>607
ワロタ

609 :仕様書無しさん:03/05/21 12:53
>>605
IPメッセンジャーを「あいぴー」って略したりな。


610 :仕様書無しさん:03/05/21 19:50
ドイツではCDは『つぇーでー』になるよ。
うつってしまって自分も言っているよぉ。
で、スレの本題だが、ドイツ人も英語が不得意な
PGがいて、そういう人のソースは、コメントは勿論
識別子系の名前付けも全部ドイツ語だよ。タスケテー


611 :仕様書無しさん:03/05/21 19:51
ディスケットだ。

612 :仕様書無しさん:03/05/21 19:53
>>610
ローマ字の変数名で対抗すれ

613 :仕様書無しさん:03/05/21 20:24
>>612
ありがd。そうするわ。
って出来ないのよ、、、。トホホ。
お蔭で妙な専門用語のドイツ語ばかり知っていくよ。
やくにたたねーーーー!!!


614 :仕様書無しさん:03/05/21 22:13
C言語も
アメリカでは「すぃー」で
ドイツでは「つぇー」なんだろうか。

やっぱり「しー」と発音してしまう日本人な俺。

615 :仕様書無しさん:03/05/22 00:09
>>605 さらにそれがフッロピーになってたりするんだ。これが。

616 :仕様書無しさん:03/05/22 00:28
コメントがやたら普段使わない漢字ばかりで、意味が判らなかった。
どうも中華系の人が書いてたようだ。
一瞬、ソースが文字化けしているかとオモタ。

617 :613:03/05/22 01:49
>>614
C言語は『すぃー』です。
もう現地時間19時近いのでかえります〜♪
みんな帰っちゃたょ。


618 :山崎渉:03/05/22 01:50
━―━―━―━―━―━―━―━―━[JR山崎駅(^^)]━―━―━―━―━―━―━―━―━―

619 :仕様書無しさん:03/05/22 02:49
このスレッド,549 まで下がってた
(;´Д`) JR山崎駅アク禁まだぁ?

620 :仕様書無しさん:03/05/22 04:01
/* これを取るとなぜかコンパイルもできない */
void main (void)
{
return;
}


621 :仕様書無しさん:03/05/22 04:22
/* 非論理的な仕様が原因 */
とか
/* 政治的な問題が原因 */
とか


622 :仕様書無しさん:03/05/22 07:25
>>620
ATLいじってるとなぜかリンク時にエラーが出る。

623 :仕様書無しさん:03/05/22 12:39
if(){
if(){
if(){
if(){
if(){
if(){
if(){

624 :仕様書無しさん:03/05/22 15:54
}}}}}}}

625 :仕様書無しさん:03/05/22 19:43
{{{{{{{{゚Д゚;}}}}}}}}

626 :仕様書無しさん:03/05/22 20:22
>>625
ワロタ

627 :仕様書無しさん:03/05/22 22:52
// C言語のバグにより正常動作しないためこの関数は使わないように 2002.12.XX. PPPP
switch( hoge )
{
  case moe:
   hoehoe();
   break;
   toretore();
   break;
   pichipichi();
   break;
   sagebouraku();
   break;
 default:
   return 0;
}



@消せよ
Aていうかなんでbreakの荒らし
BつーかPPPPってC言語4年やっててマスターしたって言ってる先輩じゃないか!?

628 :仕様書無しさん:03/05/22 23:17
>>627
4年じゃだめだ。言語は10年使ってはじめて味を出せる。

629 :仕様書無しさん:03/05/22 23:52
マ板のすごいところは、>>627のようなソースコードにも
「xxxっていう場合は有用だろ〜。○○○の途中でそうなったのかもしれないし」
とかレスがつくことだと思うんだが、さすがにこれは無理か

630 :仕様書無しさん:03/05/23 00:00
>>627
正常に動作しなくなった時点で
下からbreakを1個づつ追加してって
どこまでなら動くのかを確かめた時の痕跡では?

631 :仕様書無しさん:03/05/23 00:07
>>627
#define break itteyoshi()

632 :仕様書無しさん:03/05/23 00:07
>>630
それならこうなってるハズだろ?

switch( hoge )
{
  case moe:
   break;
   hoehoe();
   break;
   toretore();
   break;
   pichipichi();
   break;
   sagebouraku();
   break;
 default:
   return 0;
}

633 :仕様書無しさん:03/05/23 00:16
組み込み系で「スイッチ文使うのは推奨しない」となっているんだけど何故?

634 :仕様書無しさん:03/05/23 00:21
>>633
処理系によってはジャンプテーブルが作られてメモリ喰われるってことだろ。

635 :仕様書無しさん:03/05/23 00:29
>>633
某メーカーが実装してるスイッチに特許があるため
外部設計書ではタイマーという記述。

636 :633:03/05/23 00:37
>>634
あっそうか、THX

637 :仕様書無しさん:03/05/23 00:44
>>635
あっそうか。サンクス仔

638 :仕様書無しさん:03/05/23 16:31
>627
てか、その先輩の言う「C言語のバグ」って何〜?

639 :仕様書無しさん:03/05/23 17:10
if( 条件 == A ) {
 /* 処理80行ぐらい */
}
else if( 条件 == B ) {
 /* 処理80行ぐらい */
}
else if( 条件 == C ) {
 /* 処理80行ぐらい */
}
else if( 条件 == D ) {
 /* 処理80行ぐらい */
}
else if( 条件 == E ) {
 /* 処理80行ぐらい */
}
else if( 条件 == F ) {
 /* 処理80行ぐらい */
}
else {
 /* 処理80行ぐらい */
}

を4時間かかって解析しますた。
結果:
 どの処理でも常に同じ結果になる。



こんなソースばっかし・・・あの病院、よく死者出ないな。

640 :仕様書無しさん:03/05/23 21:27
>>632
いや、>>627の状態まで来てswitch{}から抜けるのを確認できたんで
次にtoretore();の中身の調査を始めたんだよ!
で、結局「C言語のバグしか考えられん!」って事になったとさ


641 :仕様書無しさん:03/05/23 22:05
>>639
性質悪いのはこんな感じ。
if( 条件 == A ) {
 /* 処理80行ぐらい */
}
else if( 条件 == B ) {
 /* 処理80行ぐらい */
}
else if( 条件 == C ) {
 /* 処理80行ぐらい */
 /* 処理A */
}
else if( 条件 == D ) {
 /* 処理80行ぐらい */
 /* 処理B */
}
else if( 条件 == E ) {
 /* 処理80行ぐらい */
 /* 処理A */
}
else if( 条件 == F ) {
 /* 処理80行ぐらい */
}
else {
 /* 処理80行ぐらい */
}

>>639のは考えてないことが明らかに読み取れるからまだいいって。
上記ソースは、考えてこれはナニ?下手に考えてるところが痛い。

642 :仕様書無しさん:03/05/23 22:44
>>641
こういうの書く人にOOPやってほしい、
どんなコードが出てくるのかが楽しみ

643 :仕様書無しさん:03/05/23 23:06
むしろ下手にOOPかじってる香具師より知らない方が
0から勉強するわけで、教え方によっては
いい感じのコードが書けるようになるかもね

644 :仕様書無しさん:03/05/23 23:08
>>642
こんな感じか。

if ( obj instanceof A ) {
 /* 80行ぐらい */
 C.method ();
} else if ( obj instanceof B ) {
/* 80行ぐらい */
 A.method ();
} else if ( obj instanceof C ) {

以下略。

645 :仕様書無しさん:03/05/23 23:21
>>644
オブジェクトとモジュールの区別が付いていないと

646 :仕様書無しさん:03/05/23 23:35
if( 条件 == 1 ) {
 new A();
}
else if( 条件 == 2 ) {
 new B()
}
………

もちろん各コンストラクタに全処理が

647 :仕様書無しさん:03/05/23 23:42
new Hoge()

if (A)
 Hoge.method_a()
elseif (B)
 Hoge.method_b()


以下同様

やっぱり1プログラム=1クラス(巨大)

648 :仕様書無しさん:03/05/23 23:45
>>647
new Hoge() の時点で全て完了している気がするが。
if (A)等はHogeのコンストラクタ内。


649 :647:03/05/23 23:47
>>648
そうか、そっちの方がいいね
巨大なクラス1個に、メソッドはコンストラクタのみッテことですね。

650 :仕様書無しさん:03/05/23 23:52
final class Hoge {
  public Hoge() {
    // 5000ステップ
       ・
       ・
       ・
       ・
       ・

  }
}

たぶん会社辞める。

651 :仕様書無しさん:03/05/24 01:09

各画面から呼び出す共通ルーチン。(共通処理は概ねこんな感じのが多数)

Sub Proc_A()
  IF ID = A THEN
   画面AのためのProc_A処理
  END IF
  IF ID = B THEN
   画面BのためのProc_A処理
  END IF
  IF ID = C THEN
   画面CのためのProc_A処理
  END IF
  以下、同様に各画面分の個別処理
End Sub

 「共通の処理をモジュール化することにより、保守性と生産性を確保し・・・」

 退職時期でもめてまつ。「あなたがやめたら誰が引き継げるんだ。無責任だ」
といわれましても、そもそも保守できないものを作ったのは誰かと、それを
承認してきたのは誰かと、小5時間ほど説教しました。


652 :仕様書無しさん:03/05/24 01:29
>>651
周りを責める気持ちわかるけど、結局、自分自信も当事者。



653 :仕様書無しさん:03/05/24 01:43
>652

すまん。そりゃ当事者といえば当事者だが。会ったこともない誰かが作ったものを
なんも資料がない状態で引き継がされて、とりあえず(工数が認められないので
サビ残で)調査したのをドキュメントにして、直せるところは手を入れて、トラブル報告が
来たら、深夜でも呼び出し喰らって徹夜で調査をして・・・ってのをやってたら、
体を壊して倒れたんだよ。ちなみに、上記の俺が無責任とのお言葉は、
倒れて仕事ができないつったときに言われた言葉。
もちろん、倒れる以前に、前もってアラームは散々伝えてあった。せめて人を追加
して欲しいと。

俺の体力と気力がスーパーマン並じゃなかったのは確かだが、
正直、許してホスイ。


654 :仕様書無しさん:03/05/24 01:55
>>646

class Hoge {
 public hoge() {
  // Hoge処理、メソッドはこれだけ
  // こういうクラスがいっぱいある。
 }
}

ってのを見たことが
ただの関数なんだけど使うときは

hoge = new Hoge();
hoge.hoge();

とやる

655 :仕様書無しさん:03/05/24 01:55
>>653
>>662は経験無しor浅い、もしくはPGとは立場の違う人間ではないか?
>>653の上司のような人間がいたら、前任者と同じように資料も残さず消えたいと思う
(よく小5時間もがんばれた、すごいよ>>653

656 :仕様書無しさん:03/05/24 02:04
>>653
誰が作ったかわからない物引き継ぐなんて珍しくないよ。
満足なドキュメントない状況もね。あんた甘いよ。何やっても不満だけで仕事辞めそう。
調査の修羅場は幾度も経験したよ。トラブルで時間制限付きの調査は気が狂いそうになる。
そして、客の煽りの中、焦って結果出してもお粗末様。
でもね、俺思うわけ。調査する毎に得るものあるだろ?
体壊したことに関してはとやかく言う気はない。お大事に。

657 :仕様書無しさん:03/05/24 02:22
俺が営業だったら、
新システム構築するような方向に顧客を持っていくけどな

658 :仕様書無しさん:03/05/24 02:24
>>657
そうだね、禿堂

659 :仕様書無しさん:03/05/24 02:31
ふと思ったがプロジェクトの生存期間(保守すべき期間)はどれくらいになるんだろう?


660 :仕様書無しさん:03/05/24 02:49
>>689
最初にプロジェクトの保証期間を決めて、
それを契約に盛り込んでから開発にかかりたいね。

661 :仕様書無しさん:03/05/24 02:51
だから、体力が続かなかったのは俺が悪かったって。
体直したら、毎朝ランニングして体力つけるようにするよ。

でも、営業云々ってのはあまり現実味がないなぁ。別の客とか
案件なら別だけど、機能アップするにしろ、基本的に同じ系統の
ものをまったく新規に作り直すのを金払ってくれるお客はそうそういない。
許してくれるほど予算にザルなところは、システムより先に潰れていく
ヨカン。いや、昔はいたけどさ。


662 :仕様書無しさん:03/05/24 08:45
>>659
プロジェクトとシステムを混同しちゃだめでしょ。
システムのライフサイクルの中でプロジェクトなんていくつも走るんだから。

システムのライフサイクルって観点だと作り手は5年くらいをめどにするのが普通じゃないかと。
でも、使う側は10年とか20年を考えてるんだよね。

663 :仕様書無しさん:03/05/24 08:47
>>656
めうらしい状況ではないからそれを我慢しなきゃだめってのは無茶だな・・・
改善する方向に動けない会社ならさっさと辞めたくなるのは事実。

それに解析してて気が狂いそうになるつくりのプログラムなんてあんまり得るものがなさそうなんだが。

664 :仕様書無しさん:03/05/24 11:03
>>663
禿堂。機能の切り分け方とかイビツな予感。

665 :仕様書無しさん:03/05/24 21:00
>>651
VB標準モジュールと見ますた。
早くVBから標準モジュールがなくなりますように。
(クラスモジュールonlyになっても困る?私はたぶんそっちの方がヨシ)


666 :仕様書無しさん:03/05/24 21:43
>>665逝け

667 :仕様書無しさん:03/05/24 23:53
VB のクラスには static がないから、
やっぱり標準モジュールがなくなると困るような気がする今日この頃。

668 :仕様書無しさん:03/05/25 00:01

 あまり使われない(返品なんかの)帳票で、合計値の値がおかしくなることがあるとの
報告あり。誰も原因が分からないと泣きつかれたのでチラッと見てみたら、

  for (...) {
   ...
   total =+ value;
  }

 ちゃんとテストしたのかと、それ以前になぜ見てすぐわかないのかと。そんな奴らが
作ったシステムの保守なんかしたくないぞ。


669 :仕様書無しさん:03/05/25 00:04
>>667
は?内部的に何やってるか理解した方がいいよ。

670 :仕様書無しさん:03/05/25 00:25
> それ以前になぜ見てすぐわかないのかと
なぜ見てすぐわかないのかと↑

671 :仕様書無しさん:03/05/25 01:35
>>667
標準モジュールに書いた関数にStaticって付けてみるとか。

672 :仕様書無しさん:03/05/25 01:38
VBに標準モジュール、クラスモジュールってあるけどどう違うの?
別に標準、クラス、どちらに書こうが処理に影響でないんだけど。
その辺がやっぱVBなのか。

673 :仕様書無しさん:03/05/25 01:54
>>672
クラスモジュールはパフォーマンス悪い。遅くなる。しかし利点がないわけでもない。
先ず、オブジェクト指向について学んで来い。話はそれからだ。
この前、うちの新人があんたと同じ質問したのを思い出したぜ。

674 :仕様書無しさん:03/05/25 01:58
VBでクラスモジュール使うぐらいならあっさりC#に逝けよ。

675 :仕様書無しさん:03/05/25 02:13
>>674
趣味で殺ってんじゃねーから、そんなにすぐ逝けるはずねーだろ。
おまいさんは開発途中であっさり使用言語変える香具師でつか?


676 :665:03/05/25 02:25
そういえば、長らくVBに触ってなかったので、フォームモジュールの存在を忘れてますた。(←バカ)
クラスモジュールは確かにパフォーマンス悪い(だいたいNewしないといけないところからしてそう)ですが、
>>651みたいな例は、そういえば各フォームのPrivateプロシージャとして
分けちゃうのがベストと思った訳であります。(今思い出した)
IDはフォーム(の種別ごとに)個別ですよね?
同じフォームが突然ID600になったり、突然ID150になったりしたら、私の言っとる事は意味を成しませんが。
>>667の意見も同意ですが、やっぱり標準モジュールはデメリットが大きひ・・・
>>666はトラディッショナルベーシックスタイル(GOTO, GOSUBでプロシージャへ飛ぶ。プロシージャへ引数は渡せない。「ローカル変数」という概念がない。パフォーマンス最適化を求めるためにはPEEKやPOKEだ!)で逝ってください。

677 :仕様書無しさん:03/05/25 02:37
>>676
>クラスモジュールは確かにパフォーマンス悪い
いまどきのマシンでは全く気にならない。てか、設計まずいんじゃないの?

678 :仕様書無しさん:03/05/25 02:42
VB厨の台詞がでました。「今時のマシン〜」

679 :仕様書無しさん:03/05/25 02:46
if ( FLG1=FLG_ON ||
FLG2=FLG_ON ||
FLG3=FLG_ON ||
      ・
      ・
      ・
FLG18=FLG_ON ) {

680 :仕様書無しさん:03/05/25 02:46
>>678
おっさん、知らないんだろ(w 

681 :仕様書無しさん:03/05/25 02:55
VB厨は他の言語と比べて本気で変わらないと思っているようです( ´,_ゝ`)

682 :仕様書無しさん:03/05/25 03:00
>>679
そういうコードは得てして設計が悪いんであって
ソースコード書いた香具師が悪いんじゃないと思うんだがどうよ?

って、よく見たら、=が1個しかないが、つまり、言いたいことはそういうことか?

683 :仕様書無しさん:03/05/25 03:08
>>682
「=が1個」の意味が分からんかったんだが、代入操作のことなんだね(w

684 :仕様書無しさん:03/05/25 03:11
>>677
>いまどきのマシンでは全く気にならない
そもそも、気になる気にならないを言ってるわけじゃない。事実を言ってあるだけ。

>>665
VBのクラスモジュールは、オブジェクト指向もどきを実現したいときに使うのさ。
構造化プログラミングしか脳のない香具師は恩恵がわからないね。



685 :仕様書無しさん:03/05/25 03:17
ReDim PreserveよりはCollection#Addのほうが速いな。
クラスモジュールとはあまり関係ないか。
もしかしてPreserveって連続メモリ領域を確保してる?

686 :仕様書無しさん:03/05/25 03:21
>>685
トレードオフの典型だね。Collection#Addのほうがメモリ消費量がかなり多い。

687 :仕様書無しさん:03/05/25 03:30
VBのCollectionってJavaで言うHashMapなわけ?
最大数がわからないデータ保持しようとしたらすぐCollection使う漏れはダメでつか?
今、クラスモジュールでフレームワーク作ろうとしてまつ。


688 :仕様書無しさん:03/05/25 05:47
>>687
今時VBでクラサバやってる香具師いるのか?
フレームワーク作っても使う機会がないと思われ。

689 :仕様書無しさん:03/05/25 06:49
VB6.0でクラサバやってます。

690 :仕様書無しさん:03/05/25 07:16
今時遅いからクラス使うなと言っている奴がいるのか?
そんならすべてがクラスのJavaなんて使えないじゃん。

691 :仕様書無しさん:03/05/25 07:17
>>688
フレームワークと聞いてクラサバしか思いつかないあなたは世界が狭いと思われます。

692 :仕様書無しさん:03/05/25 10:39
for(i=0;i<5;i++){
 if(i>=4){
 break;
 }
hogehoge;
}

プログラムが出来ると言う前提で入ってきた新人が書いたソース

693 :仕様書無しさん:03/05/25 10:52
>>690
Javaが遅いのは全部がクラスだからじゃねえだろ。

694 :仕様書無しさん:03/05/25 11:01
>>691
>>688はネタだと思う。

695 :仕様書無しさん:03/05/25 13:38
value1
=
100;

value2
=
200;

なんじゃこれ?なソースを面倒みてます。
無駄に改行ありまくり。


696 :仕様書無しさん:03/05/25 14:21
>>692
そういうコード普通に書いたりするんだけどダメか?
例えば、ちょっと変な例だけど

int a[MAX];
for(int i=0; i <= MAX+1; i++) {
  if (i == MAX) {
    //a[]の中に目的の物がなかった場合の処理
    break;
  }
  if (a[i] == hoehoe) {
    //a[]の中に目的の物があった場合の処理
    break;
  }
}

みたいな感じで。
まぁ、必要ないのに、そんなコードだったらアレだけど。

697 :仕様書無しさん:03/05/25 14:44
int a[MAX];
for(int i=0; i < MAX; i++) {
  if (a[i] == hoehoe) {
    //a[]の中に目的の物があった場合の処理
    break;
  }
}
if (i == MAX) {
  //a[]の中に目的の物がなかった場合の処理
}

じゃないか? よくあるパターンなら。でなければforではなくwhileにする。
for使っていながら、maxが配列の外に行くようなコードを書くのは
気持ち悪い。



698 :仕様書無しさん:03/05/25 15:00
>>697
> for(int i=0; i < MAX; i++) {

i の生存区間をforループ内にしたかったんじゃないの?
それにC++ってこの辺りの仕様が二転三転してなかったっけ?

699 :仕様書無しさん:03/05/25 15:03
>>697
コンパイルとおる?
i のスコープとかさ

700 :仕様書無しさん:03/05/25 15:45
>>699
コンパイルは通ってもまともに動かないケースもあると思います。
私はIsfoundとかのブーリアン変数と、見つかったときの添字を編集する変数を
別に用意して、ループの外に見つかったときと見つからなかったときの処理を書きますね。
ループの中には、「見つかったときにブーリアン変数をtrueにして添字を待避する」だけ。

シーケンシャルサーチしながら他にもいろいろなことをやるのが当たり前という
会社の風土だったらかなり嫌かも。

最近は、ネストが深いのよりも、if〜endif間が長い方が嫌です。

701 :仕様書無しさん:03/05/25 17:17
>>697 プ

702 :仕様書無しさん:03/05/25 17:22
>698

iの宣言を外に出せばいいだけだと思うが。
ループの条件に細工するくらいなら、俺はそうする。


703 :仕様書無しさん:03/05/25 17:47
処理すべき要素のインデックスを配列に格納するループと、
インデックスの配列を用いて処理を行うループに分けるのが正解か?
で、配列が空だったら専用の処理を書く、と。

704 :仕様書無しさん:03/05/25 17:53
>>702 同感。C++の仕様が二転三転したかどうかは知らないんだけど,VC++とかで
昔の仕様をひきずった方がいい部分がある(と聞いたけどよく知らない)からひきずっ
てる人が多いということではないかと思います。

705 :698:03/05/25 18:06
>>702
オレだってそうする。
ただ >>696 がそう書くようになっちゃったのは理由があるんじゃないのって話。

706 :仕様書無しさん:03/05/25 18:16
>705

>696の場合、そういうコードを普通に書いたりすると言ってるののが
ダメだと思う。

もし仮に必要性があったとしても、ループの終了条件は只でさえ問題が
潜り込みやすい所なんだから、あーゆートリッキーなことをするなら
誰が見ても明確に納得のいく形でコメントとしてキッチリと書いておかないと
後々保守するヤツが死ぬ。どっちにしろあまり普通とは思われないなぁ。


707 :仕様書無しさん:03/05/25 22:46
>>692の突っ込みどころは
for (i=0; i<4; ++i)
と何が違うんだというところじゃないかと。

・・・だよね。
不安になってきたので聞いてみる。

708 :仕様書無しさん:03/05/25 23:20
>>707
全然関係ないけど、++iって書かれると何か意味があるのか考えてしまう
俺の中では
  普通にインクリメント i++
  何か理由があって使う ++i
かな


709 :仕様書無しさん:03/05/25 23:30
うーん。漏れが読んだ限りのコードでは確かに副作用関係ないとき
後置++が多い気がするが、漏れは副作用を期待しないときは前置するなぁ。
まぁ、前置後置でパフォーマンスに差が出るほどのシビアなコーディングは
したことないんだけどさ(w

710 :仕様書無しさん:03/05/25 23:32
>>708
++i の方が効率良い場合があるとか無いとか。
逆だったかもしれんが。

711 :仕様書無しさん:03/05/25 23:35
>>710
そだね。C++のクラスメソッドの場合、++i だと、++処理後に自分自身を返すだけでいいのだけど、
i++ だと、インクリメント前の状態を覚えておいて、インクリメント処理後にインクリメント前の値を返す必要がある。
そのため、インスタンスのコピーが必要になって効率が悪くなる。


712 :仕様書無しさん:03/05/25 23:55
>>711
>クラスメソッド

staticメソッドのこと?

713 :仕様書無しさん:03/05/26 00:06
++iで統一する方がいいと思う。
i++も++iも(慣れれば)全然変わらんのだし、だったら>>711の理由で前置がいい。
漏れはインクリメント演算子書くときは前置しか書かん。
STLの考えにのっとって、「クライアントの労力は変わらないのに
効率が悪くなるメソッドを廃止」したい。

714 :仕様書無しさん:03/05/26 00:19
>711

受け取り手がいないのだから、どっちも同じ。実行時のパフォーマンスに差はないよ。
ただし、ソースを読んだときに違和感を感じたとしたら、その分だけソース理解の
パフォーマンスは落ちるな。

一人でコーディングして誰にも見せないのならいいけど、引き継ぐやつが
いるならそういう「まったくどうでもいいもの」は周りが違和感を抱きにくい
方にあわせとけ。


715 :仕様書無しさん:03/05/26 00:20
え・・・STLで・・・find_if()で・・・
イテレータがend()(もしくはそれに相当するもの)かどうかで・・・


716 :仕様書無しさん:03/05/26 00:58
>>714
そんなに可読性に影響することか?>前置後置の違い
こんな下らんことに注意力割いてコーディング速度を低下させる方が
よほど有害だと思うが。

「まったくどうでもいいもの」なら意識しないのが一番。

717 :仕様書無しさん:03/05/26 01:10
++は原則的に前に置くべきだ>Effective C++を参照されたい

なんで?という(よく分からない)人も今はそうしておきなさい
プログラムが良くなるおまじないだと思って(w


718 :仕様書無しさん:03/05/26 01:11
普段見慣れないものを見たら、単純なものであっても
何か隠された意図があるんじゃないかと疑いたくなるのは
人間のさがじゃないかねぇ。

俺は多分、++i を見たら、考えるだろうな。
…あまりにも大量に出てきたら、そういうもんだと思うけど。

719 :仕様書無しさん:03/05/26 01:54
今まで後置インクリメントやってた馬鹿は反省しろってこった

720 :仕様書無しさん:03/05/26 02:07
なるほどなぁ。今までintかポインタにばかり++を使ってきてたからコンパイラがうまく最適化して
くれることを期待してどっちでもいいと思ってきてたけど,相手がクラスだとそういうわけにもいか
ないってこともあるのか。いい勉強になったよ。これで今週もなんだか頑張れそうだ。ありがとう。

721 :仕様書無しさん:03/05/26 02:25
ターゲットがクラスの場合、まず"++"自体が実装されているかどうか
から確認する。インクリメントだから機械的に前置とかはしないな。


722 :仕様書無しさん:03/05/26 12:44
>ターゲットがクラスの場合、まず"++"自体が実装されているかどうか
>から確認する。インクリメントだから機械的に前置とかはしないな。

実装されてなかったらコンパイル通らないと思います。

723 :仕様書無しさん:03/05/26 13:08
Effective ++C

724 :仕様書無しさん:03/05/26 13:09
>>722

コンパイルするまで確認しないって、もしかしてカンやフィーリングで
コーディングしているのですか?


725 :仕様書無しさん:03/05/26 14:33
何というか、確認するのが当たり前で、
確認もせずに、++なんか、使えるわけがね〜
そんなの前置とか後置とか以前の問題じゃねーか


726 :仕様書無しさん:03/05/26 18:26
ゆゆゆれてええるうううう

727 :仕様書無しさん:03/05/26 20:45
>726 ビックシしたね。うちの職場がビルの高いとこだったから死ぬほど酔った

728 :仕様書無しさん:03/05/26 22:00
「レビューで納得いかなかったこと」っていうスレ立てようと思ったんだけど
重複になりそうな気もするのでここに書きまつ。
俺の今いるプロジェクトでは1つの関数につき出口は1つまでということになっている。
なのでこういうのは駄目で
if 良くなかったら
  終了
if 良くなかったら
  終了
肝の部分・・・

こう直さないといけないのでつ
if 良いなら
  if 良いなら
    肝の部分・・・
相談しても出口がいくつもあるとバグの原因になるしデバッグが大変だ
ということで全然取り合って貰えませんでした。

このコーディング規約についてどう思いますか?
もしかしてこれは新手の肩たたきなんでしょうか。

729 :   :03/05/26 22:05
ネットのバイト見つけた。バナー収入登録したら1000円くれるってさ。
http://members.goo.ne.jp/home/madcap0  
  

730 :仕様書無しさん:03/05/26 22:16
>>728
if 良くなかったら
  
else if 良くなかったら
  
else 肝の部分・・・

731 :仕様書無しさん:03/05/26 22:19
>>728のお題は終了ですか?

732 :仕様書無しさん:03/05/26 22:33
>>728
VBですか?

733 :仕様書無しさん:03/05/26 23:06
>>732
いえCです。

734 :仕様書無しさん:03/05/26 23:18
if (良いのなら && 良いのなら && 良いのなら)

735 :仕様書無しさん:03/05/26 23:19
>>728
returnの前にprintf入れてデバッグするやしのせい

736 :仕様書無しさん:03/05/26 23:22
まあ、後から見る奴にとっては、出口は一箇所の方がいいに決まってるわなぁ。

737 :仕様書無しさん:03/05/26 23:53
例外処理的な早めの脱出は
わかりやすくなることはあっても
わかりにくくなることはないと思うけどねえ

738 :仕様書無しさん:03/05/26 23:54
まあ、後から見る奴にとっては、エラー即リターンの方がいいに決まってるわなぁ。

739 :738:03/05/26 23:56
うっ。割り込まれた・・・。

エラー状態を最後まで引きずってると見難い。

同様に関数の最後の方にしか使いわない変数を関数の先頭で宣言するのも見難い。

740 :仕様書無しさん:03/05/27 00:27
>>739
Pascalはどうすればいいでしょうか?

741 :仕様書無しさん:03/05/27 01:21
>>728
flag = true
if 良くなかったら
  flag = false
if 良くなかったら
  flag = false
if flag = true then
肝の部分・・・

>>728と似たような規約がある
ウチの会社でよく見かけるコーディング

742 :仕様書無しさん:03/05/27 03:50
レビューの時の指摘。コーディング規約にもないのに

「なんで関数の途中にリターンがいっぱいあるの、分かりづらいYO!」

説得を試みたが無駄だった。

処理1
if 処理1がOKなら { 処理2 }
if 処理1〜2がOKまら{ 処理3 }
〜続く〜
最後にリターン。

報われない割に変更がかなり大変だった。

743 :仕様書無しさん:03/05/27 04:12
  ええじゃないか!!ええじゃないか!!良いのなら!!良いのなら!!ヨイ ヨイ ヨイ ヨイ!!
\                                                 ,/
   ̄ ̄ ̄ ̄ ̄∨ ̄ ̄ ̄∨ ̄ ̄ ̄ ̄∨ ̄ ̄ ̄ ̄∨ ̄ ̄ ̄ ̄ ̄ ̄ ̄∨ ̄ ̄ ̄ ̄ ̄
              ⌒
         ∧,,∧    ∩1,,∧    ∧,,∧゙    ∧,,∧     ∧,,∧
      ミ. ゚Д゚彡   | | ゚Д゚彡 ミ゚Д゚ 彡  ミ ゚Д゚彡    ミ ゚Д゚ 彡
     ((⊂   ⊃   /   ,⊃ ((⊂、  ⊃゙ ((⊂  ,⊃))  ((⊂、⊂ヽ
    (( ⊂,, ノ゙  ((( ,,_,,⊃゙  ((⊂,,_,, ) ((( ,,_,,⊃))  ((⊂,__,, )))
         (/,,     ヽ),,        (/,    ヽ),,        ,,(/


744 :仕様書無しさん:03/05/27 06:08
>>728
ばかやろぉ!
COBOL業界じゃ、ABORTフラグやらエラーフラグを立てて、そこらじゅうの処理のまえに、
IF ABORT = SW-OFF THEN
って書くのが常識なんだよ!
例外処理としてのGOTOとか書いてみろ!「構造化プログラミングだろ!」と言われるぞ!

745 :_:03/05/27 06:09
http://homepage.mac.com/hiroyuki43/moe/jaz02.html

746 :仕様書無しさん:03/05/27 06:10
>>742
[return FALSE]と[return TRUE]なんかをごっちゃにまぜこんでないか?
どうやったら説得に失敗すんだ?

747 :仕様書無しさん:03/05/27 06:28
>>740
Result := "ERROR!";
exit;


もしくはObjectPascalなら例外投げる。

748 :仕様書無しさん:03/05/27 06:57
C++で例外処理機構に慣れたところで、最近仕事でC使わないといけなくて、
オブジェクト生成関数が↓みたいな感じになってしまいます。
(生成関数はオブジェクトのポインタを返す)

リソース確保
if( 成功? )
{
 リソース確保
 if( 成功? )
 {
  リソース確保
  if( 成功? )
  {
   オブジェクト生成
   return オブジェクト
  }
  リソース解放
 }
 リソース解放
}
return 0;

Cでは普通どうするんでしょうか?
goto?

749 :仕様書無しさん:03/05/27 07:39
リソース確保を成功したかどうかの
フラグを返す関数内に入れて、

if (リソース確保 && リソース確保 && リソース確保)
{
 return オブジェクト生成;
}

リソース解放
リソース解放
リソース解放

return 0;

適用できない場合も多いと思いますが。

750 :748:03/05/27 09:14
>>749
残念ながら、適用できませんねぇ。
っていうか、それ、適用できる場合がものすごく限られてるような気がするんですが。

751 :仕様書無しさん:03/05/27 10:09
>>748
例えばファイルやメモリの場合、NULLをフラグとして扱い、gotoを使う
FILE *fp1 = NULL, *fp2 = NULL;
char *p1 = NULL, *p2 = NULL;
fp1 = fopen("aaa", "r");
if(fp1 == NULL) goto Error;
p1 = malloc(10);
if(p1 == NULL) goto Error;
fp2 = fopen("bbb", "r");
if(fp2 == NULL) goto Error;
p2 = malloc(10);
if(p2 == NULL) goto Error;
/* 全てリソースを確保した */
reurn OK;
Error:
/* リソースを確保していた場合、解放する */
if(p2 != NULL) free(p2);
if(fp2 != NULL) fclose(fp2);
if(p1 != NULL) free(p1);
if(fp1 != NULL) fclose(fp1);
/* リソース確保に失敗 */
return NG;

752 :仕様書無しさん:03/05/27 10:24
>>742
  do{
   if(...) break;
   if(...) break;
   :
  }while(0);
  return;

これが基本です(うそp)

753 :仕様書無しさん:03/05/27 10:56
>752

イチ抜け方式でのコーディングがふさわしい場合で、でも規約の縛りがあるときは、
まじでそれよくやります・・・。


754 :仕様書無しさん:03/05/27 13:10
このスレは
「この会社辞めようと思ったコーディング規約」
に変更されますた。

755 :仕様書無しさん:03/05/27 14:08
>>754

「プログラム内で使用する変数は全て予め申請し、許可が下りたもの
だけでなければならない」

という規約には悩まされました。グローバルだけなら分かるが、ローカル関数
のパラメータや、モジュール内の只のループカウンタまで申請が必要だった。

信じられないが、本当だ。(板違い)


756 :754:03/05/27 14:13

ある時、急な仕変でプログラムに手を入れなければならなくなった。
しかも、既に総合テスト中であり、修正は翌日の朝までに完了しなければ
ならない。ちなみに変数名の追加は、申請してから登録されるまで概ね
1週間(急がせて3日)程度かかる。仕方ないので、内容と合わない適当な
変数名でモジュールを組んで納品するしかなかった。
そのプログラムはまだ某金融系システムの基幹部分でまだ動いている
筈だ。

ごめん、保守の人。(俺のせいではないが)


757 :仕様書無しさん:03/05/27 14:14
↑ 名前欄 s/754/755/ だ。ごめん、754の人。


758 :仕様書無しさん:03/05/27 15:39
いま直しているコードの中にこんな関数見つけました。

void XXXX:helloworld(void) {
 rsout("helo,world(^^)"); //テスト com1に文字列出力
}

リサリサ先生・・・ハローの綴りが違ってるぜ・・・

759 :仕様書無しさん:03/05/27 15:45
「さ、さすが50歳!」


760 :仕様書無しさん:03/05/27 16:12
むしろ、HelloWorld関数が存在するそのコードがいったい何なのかが気になるな

761 :仕様書無しさん:03/05/27 16:22
>>760
そこのところだが…俺にもわからん…

出力関数のテストがしたかっただけかも…

762 :_:03/05/27 16:31
http://homepage.mac.com/hiroyuki43/hankaku/hankaku08.html

763 :m:03/05/27 16:31
◎よろしかったら見て下さい◎
http://endou.kir.jp/betu/linkvp2/linkvp.html

764 :仕様書無しさん:03/05/27 20:08
HELOって、SMTPの一言目の挨拶じゃん。

765 :748:03/05/27 23:36
>>751
>748をそのように書き換えるほうが歓迎されるのでしょうか?
とてもそうは思えなかったです。

もとのやつでいいとおもいますた。現状維持。

766 :仕様書無しさん:03/05/28 00:44
VBにてコーディング規則、「変数名は極力短く」

変数名を短くして利点あるんですか?リソース節約なんて過去の事じゃないのですか?
きょうび、「意味のある命名」が流行ってる時代に、このコーディング規則は納得いきません。
WindowsAPIの関数のように長い命名はどうかと思いますが。

767 :仕様書無しさん:03/05/28 01:54
「〜を満たすまでループ」という仕様に対して
ソースが↓のようになってて、1日悩んだ事があるな。

 while( TRUE ) {
  if( ... ) break;     // 引数チェック
   :
  ret = hoge( );     // メイン処理(本当のループはこの最深部に)
  if( ret != 0 ) break; // 戻り値チェック
   :
  break;  // ←ループしてない!?
 }

768 :仕様書無しさん:03/05/28 02:41
>>767
そんなので1日も?大丈夫か?1年目に悩んだんだ?新人の頃じゃなきゃ、おまえ終わってる。

769 :767:03/05/28 03:04
>>768
入社数年目でつい最近の事だったりしますが何か。


770 :仕様書無しさん:03/05/28 03:30
>>767の書き方はgoto禁止のときの定石だと思うがなあ。
1日悩んだ理由はきっとhoge()の中の人がグダグダだったんでしょ。

771 :仕様書無しさん:03/05/28 06:39
君はなぜgotoが禁止なのかを悩むべきだと思うのだが、、、

772 :仕様書無しさん:03/05/28 11:43
>>770
goto禁止の場合は>>752の方法が定石
無限ループとおもわせといて、最後に無条件breakは詐欺

お前、彼女に「今夜はずっと一緒にいようね」と言われて
数時間後にbreakされたらどうするよ。

773 :仕様書無しさん:03/05/28 13:04
>お前、彼女に「今夜はずっと一緒にいようね」と言われて
>数時間後にbreakされたらどうするよ。

それは何か致命的なエラーが発生したのでは?

774 :仕様書無しさん:03/05/28 13:29
フラグがたたなかったんだろ

775 :仕様書無しさん:03/05/28 13:34
while Erect or not Sunrise do
begin
 with GirlFriend do
  Sex;
end;

776 :ヽ(´ー`)ノ:03/05/28 13:48
> 「なんで関数の途中にリターンがいっぱいあるの、分かりづらいYO!」
そもそも、この主張の意味が分からない。break や return を使うのを避けて
トリッキーなコードを書くよりよっぽど分かりやすいと思うんだが…。

777 :仕様書無しさん:03/05/28 14:03
gotoと違ってreturn, breakは悪用する方が難しい気がするしね。

778 :仕様書無しさん:03/05/28 14:47
特にreturnは明々白々だしなあ。

779 :仕様書無しさん:03/05/28 15:55
それ以前に関数が長すぎるのが問題なんだよ。

780 :仕様書無しさん:03/05/28 15:59
関数の始まり
  try{
    200ステップくらいのコード

    return 0;
  }catch ( Exception e ){
    return -1;
  }
関数の終わり

781 :仕様書無しさん:03/05/28 16:08
>775
すいません、正直2回連続でするのもしんどいです

782 :山崎渉:03/05/28 16:42
     ∧_∧
ピュ.ー (  ^^ ) <これからも僕を応援して下さいね(^^)。
  =〔~∪ ̄ ̄〕
  = ◎――◎                      山崎渉

783 :仕様書無しさん:03/05/28 16:58
>>778

いや、きっとこんな関数を定義してる人なんだよ。

void retrun(int val)
{
  /* 何か */
}

で、returnの後の式を必ず()付きで使う。
return(1)とretrun(1)で動作が違う。ガクガクブルブル


784 :仕様書無しさん:03/05/28 17:34
だから return に括弧を付けるなと…(違

785 :仕様書無しさん:03/05/28 19:42
sizeofの括弧は許されますか?

786 :仕様書無しさん:03/05/28 22:37
>>785
sizeofに括弧無し???

void main(void)
{
 printf("%d\n",sizeof int);
}

こんな感じ?それとも他の言語?

787 :仕様書無しさん:03/05/28 22:45
きたぞ・・

788 :仕様書無しさん:03/05/28 22:53
来たなw
ここはひとつ、全員”流す”方向で…

789 :仕様書無しさん:03/05/28 23:16
>>787
>>788
何が来たんだ?俺にも教えれ

790 :仕様書無しさん:03/05/28 23:19
妖精だよ。妖精が目の前を通り過ぎてったんだよ。

徹夜明けの朝4時ごろにたまに現れるだろ? あれだよ。


791 :仕様書無しさん:03/05/28 23:32
レットランですか。
returnに括弧つけない方がいい理由って
似た名前の関数があったとき困るからなの?
本当でつか。

792 :仕様書無しさん:03/05/28 23:40
>>789
宗教論争を起こそうとたくらむ輩


793 :789:03/05/28 23:49
>>790
嗚呼・・・あれでつか。一斉にな。何なんだ?
毎度毎度、奇妙すぎて気持ち悪いんだけど?


794 :仕様書無しさん:03/05/28 23:50
 
/ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
| 先輩、"retrun is not found"が出てたのでライブラリにretrunモジュルを追加しときました

   ̄ ̄ ̄|/ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
  ∧_∧       / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
  ( ・∀・)  ∧ ∧ < って、タイプミスなおせや! ゴルァ!
 (  ⊃ )  (゚Д゚;)  \____________
 ̄ ̄ ̄ ̄ ̄ (つ_つ___
 ̄ ̄ ̄日∇ ̄\| 威TRON |\
       ̄   ========= \


795 :仕様書無しさん:03/05/29 00:04
威TRON

強そうなTRONだな。

796 :仕様書無しさん:03/05/29 00:20
顧客に渡された変数とかの名称設定ツール。

会社名  → KSYMEI
店舗名  → TPOMEI
製品名  → SEHMEI
責任者  → SEKNNSY
工場   → KJO
東/南/西/北 → HGS/MNM/NSI/KTI

SQLとか見ると一瞬どのテーブルから何を引き出してるのか分からなくなる・・・

797 :仕様書無しさん:03/05/29 00:25
>>796
突っ込みどころは
北=KTI だな、うん。

798 :仕様書無しさん:03/05/29 00:36
ソースの盗用防止だと思うが、それ。





・・・そう言うことにしておこうよ。

799 :仕様書無しさん:03/05/29 01:09
if (良いではないか && なりませぬ) {
    あ〜れ〜();
}

これでいつも「あ〜れ〜」が実行されてしまうのは何故でしょうか?

800 :仕様書無しさん:03/05/29 03:37
>>796
変数名がほとんど英語ベースなんだけど、
ちょっと難しい単語だけ日本語のローマ字表示という
気合いと一貫性のない例ならある。

変数といえば
hoge hoge2 hoge3 hoge4 ...
というのは常識ですね。

あと
i j k l ..
でループ回すのわかりにくい。特にiとjは間違えやすい。
ていうかジャイアント多重ループやめれ。

>>799
常に 「よいではないか」と「なりませぬ」がTRUEなのが、お約束だからです。


801 :仕様書無しさん:03/05/29 09:01
>>799
その帯は無限なのかと(ry

802 :山ア渉(^^) :03/05/29 09:15
fusianasanチェック

803 :仕様書無しさん:03/05/29 10:48
前いたところでは関数の出口1つって決まりだったんで
ret = NG;
do{
 if(例外条件) break;
 if(例外条件) break;
  
本処理;
ret = OK;
}while(0);

だったな…。

804 :修正:03/05/29 10:51
ret = NG;
do{
 if(例外条件) break;
 if(例外条件) break;

 if(本処理 != OK) break;
 ret = OK;
}while(0);

805 :仕様書無しさん:03/05/29 11:49
>>803
>>767 みたいにはまるやつもいるし、
好き嫌いが分かれる書き方なんで、
一時使っていたけど、止めた。

806 :仕様書無しさん:03/05/29 18:06
まぁ、しかし、かといって出口一つでもっといい書き方があるかというと
やっぱり無いわけでして。

なんかいいのある?

807 :仕様書無しさん:03/05/29 18:53
>>806
会社を辞めるとか。

808 :仕様書無しさん:03/05/29 21:19
>>806
>>741のようなステータス変数方式が冗長だけど読みやすいと思います。

チェックして
チェックOKなら
 別のチェックして
そのチェックもOKなら
 別のチェックして
  ・
  ・
そのチェックもOKなら
 本処理を実施

って感じで、日本語としても読みやすい方だし。

809 :仕様書無しさん:03/05/29 22:59
そういえば昔、if文でelse、else ifを使うなと言われたことがあるなぁ。
命名規則などコーディング規約を異常なまでにガッチリ固められ過ぎたらやる気低下するんだけど?
保守を考慮してのことだろうけど、それとはかけ離れた規約もみかける。
可読性を優先するところを「変数は半角英数5文字以内」とかね。







810 :仕様書無しさん:03/05/29 23:04
>>809
C臭がプンプン臭っている。C++でないことは間違いないな。

811 :仕様書無しさん:03/05/29 23:09
else if はともかく else を使わずに書くとかなり無駄な事がありそ。

でもコーディング規約有ると楽だよ。作れって言われるよりは…

812 :仕様書無しさん:03/05/29 23:12
>>811
喪前さんは、きっと普通のコーディング規約の元でやってるんだろうな

ふざけんな、と思うようなコーディング規約があると
ホントもうね(;´д⊂)

813 :実話:03/05/29 23:14
int dottikawakaranaitokiha0gahaitteimasu;

814 :仕様書無しさん:03/05/29 23:14
ifの条件にfalseとなるものを入れてはいけないという規約があった。

if (a != 0) {
 // 処理
}

↓これはこう書かなくてはいけなかった。

if (a == 0) {
} else {
 // 処理
}

815 :814:03/05/29 23:15
なんか文章が変だな。
まあ察してくれ

816 :仕様書無しさん:03/05/29 23:16
違う。いつも規約が無いサイトをウロウロしてる。
で、無いの?って聞くと、作ってって言われる。
作ってレビューでもめまくる。もう嫌になるよ。
途中returnとgotoで1日揉めるから。
そこそこ変でも有る方が良いよ。


817 :仕様書無しさん:03/05/29 23:45
うちの規約、if (i == 0)みたいな場合、if(0 == i)って書けって強制される。
まぁそれはいいけど、if(0 >= i)とか、if (str.len > i)とかif(x + y > i)みたいな
アホな書き方に何の意味があるのかと小一時間(ry

818 :仕様書無しさん:03/05/30 00:05
>>796
この命名規約、もしや日○ですか?

819 :仕様書無しさん:03/05/30 00:13
>>817

なぜだなんでだ・・・


主語をどちらととらえるかの問題なんだろうが。

820 :仕様書無しさん:03/05/30 00:27
>819

きっと、>817の会社の規約を作ったやつは、三田本あたりを
元ネタにしたんでないかな?

会社によってはCOBOL風なC規約とか、FORTRAN風JAVA変数名長制限
規約とかあるので、最近はあまり驚かなくなった。


821 :r:03/05/30 00:29
見たこのあるコーディング規約

1条5項
ファイルの先頭には、必ず以下のコメントブロックを挿入すること

// caution: このプログラムはC言語的な記述が散見されますが、間違いなくC++のコードです。
// module name:
// author:
// last update:



で、どのファイルにも、先頭に
「// caution: このプログラムはC言語的な記述が散見されますが、間違いなくC++のコードです。」
って書いてある。


822 :仕様書無しさん:03/05/30 00:38
>>817
if ( 0 >= i ) はきっと( i == 0 )と書いてしまわないように癖を
付けさせるのが目的だ、と言ってみるテスト。

>>821
と言うことは、どのプログラムもみんな
C++をC風に記述してあったのですか?

823 :仕様書無しさん:03/05/30 00:43
モジュール、変数、メソッドの命名規則で「アクセス修飾子を頭に明記(PR,PV,PT)」
マジ萎えた。コメント規則も含めて思うけど、解析のとき、精通してる人にとって必要な情報は、

・変数の型がわかる方がいい
・コメントは仕様上のことを記述(何を意図しているのか)
・更新履歴があった方がいい
・マジックナンバーは意図を明記(ってか極力使うな)

この程度だと思われる。

Vector i = new Vector(); // インスタンス生成

とか

// 32回ループ
for (int i=0; i<32; i++) {
  ....................
}

とか

lst.add(.........); // Listに追加

なんて書かれてた日には・・・・。

824 :仕様書無しさん:03/05/30 00:45
>>823
更新履歴はものによるなぁ。


825 :仕様書無しさん:03/05/30 00:56
>>823
Vectorをiってヤラれてるのが悲惨・・。

826 :仕様書無しさん:03/05/30 00:58
>変数の型がわかる方がいい
データ型が変わったときに痛い目に会う。

さぁ野郎どもかかってこい。

827 :仕様書無しさん ◆Rhvbchu7bg :03/05/30 01:17
>>826
はげど。
どっちかというと、目的を表す名称を付けて欲しいものだ。

828 :仕様書無しさん:03/05/30 01:25
>>817
は「if(0==i)」を「if(0=i)」などとタイプミスした場合、
コンパイルエラーで見つけられると言う姑息な手段のつもりでは?

829 :仕様書無しさん:03/05/30 01:27
>>817
if(0==i)を間違ってif(0=i)と書かない為じゃないの?

830 :仕様書無しさん:03/05/30 01:29
>>829
それ必須。やってないPGを観ると萎える。
但し、0 > i こうやってしまうのはもっと萎えるが。

831 :仕様書無しさん:03/05/30 01:29
>>826
メンバ変数とローカル変数でプレフィックス区別してたらいい。
そしたらデータ型変わっても一発置換で対応。

832 :_:03/05/30 01:31
http://homepage.mac.com/hiroyuki43/hankaku10.html

833 :仕様書無しさん:03/05/30 01:32
>>826
規約破る香具師はどこにでもいるから破綻する
規約程度なら我慢の範囲だが、思想を破る香具師も多数存在。

834 :あわび:03/05/30 01:51
★こっそり見せます★
http://endou.kir.jp/betu/linkvp2/linkvp.html

835 :仕様書無しさん:03/05/30 01:52
>829

その程度のtypoは10年前のコンパイラでもwarningとなってたから、
今更わざわざ見難く書く必要性はないと思われ。


836 :仕様書無しさん:03/05/30 04:42
>>835
昔の原理原則が幅を利かせてるから始末に終えないんだよな、この業界。
なぜ途中returnがいけないか?
だめだという奴に理由を聞いてもそう教わったと言われるからな。

30くらいの奴がこの業界の原理を変革してほしいな。


837 :山ア渉(^^) :03/05/30 07:22
>>836

たとえば、ALTER TABLEが幾多でもできる環境なのに、
テーブルを簡単に再構成できなかった時代を引きずっているのか
予備フラグ1,予備フラグ2 、予備フラグ3
とかいうカラムを作ったりするのも、「昔の原理原則ですかね」

838 :仕様書無しさん:03/05/30 08:44
実運用中のDBにフィールド追加するのは確かにしんどいけど、
予備フィールドが役に立ったことはないな。

839 :仕様書無しさん:03/05/30 09:56
>>837
山崎渉の新ネタキター

840 :仕様書無しさん:03/05/30 10:47
>837
昔といっても、それは比較的新しい原理原則ですね。
本当に古い時代なら、一つの項目中の何ビット目が○○フラグ、みたいな使い方を・・・

って山崎かよ

841 :仕様書無しさん:03/05/30 16:52
>>836
昔はなんで途中returnがイクナイものだったんでつか?(ピュア)

842 :仕様書無しさん:03/05/30 16:57
途中returnがイクナイってのは、
free()とかfclose()とかの後始末を、関数の最後にまとめておいて、
解放し忘れ、閉じ忘れが無いようにするためのものじゃねーの?
今も昔も無いと思うが。

843 :仕様書無しさん:03/05/30 17:07
そのへんはtry〜finallyとかの後発の制御構造が解決してるからなー

844 :仕様書無しさん:03/05/30 18:48
なんで山崎って名字の人間はクソばっかしなんだろう。
昔会った山崎哲○はアセンブラ&C++マスターと言ってたがCOBOLしか知らなかったし、
山崎タケーシはテストデータを全部消してしまって納品できなかったわ、
山崎智○はウソの進捗の連発で結果的にプロジェクト崩壊に追い込んでくれたわ、
山崎○之は風呂に1〜2週間入らないのが当然とか言って、いつも頭真っ白でガリガリ掻いててキモいわ・・・



845 :h196169.ppp.asahi-net.or.jp:03/05/30 20:53
(^^)

846 :仕様書無しさん:03/05/30 22:36
>>841
漏れも知らない。でも842の言う様な理由ではない。
資源を確保しない関数でも駄目と言われる。
COBOL世代に途中retrun駄目派が多いので、COBOLになんか関係あるのかな?
識者の意見きぼん

847 :仕様書無しさん:03/05/30 22:39
if(i==0)をif(i=0)って書いて
間違いに気付かずハマってる奴は結構多いよ
で、if(0==i)って書いてれば
もしif(0=i)ってtypoしたときにコンパイラが気付かせてくれる
ってことだろうけど、この書き方を徹底的に嫌う奴が多いから
変な習慣は付けない方がいいと思うよ


848 :仕様書無しさん:03/05/30 22:40
retrun

849 :仕様書無しさん:03/05/30 22:59
>if(i==0)をif(i=0)って書いて
>間違いに気付かずハマってる奴は結構多いよ

そのコードにwarningも出ないような、十数年前のコンパイラを使ってる方が多いのですか?

850 :仕様書無しさん:03/05/30 23:11
>>849
> そのコードにwarningも出ないような、十数年前のコンパイラを使ってる方が多いのですか?

世の中あなたが使ってるようなメジャーどころのコンパイラばかりじゃないですからね

851 :仕様書無しさん:03/05/30 23:13
>>846
構造化プログラミングって知ってる?

>>849
悲しいが開発環境に自分を合わせられるのもPGの能力のうち。


852 :hn ◆iKwMOjCT4s :03/05/30 23:17
やっぱ if(0==) は違和感ブリバリ

i が 0 なら、やる というのが自然に分かっていい。warning 出すコンパイラにもっと頼れ。

(ちなみにjavaじゃ if は真偽返さなきゃいかんね。)

853 :仕様書無しさん:03/05/30 23:21
>>847
> ってことだろうけど、この書き方を徹底的に嫌う奴が多いから

(例)
>>852

854 :仕様書無しさん:03/05/30 23:28
今時 if (0 == i) なんて書きたくて書いてる奴はほとんどいない。

>if(i==0)をif(i=0)って書いて
>間違いに気付かずハマってる奴は結構多いよ
warningをdisableにしてるやつかな?
warning鬱陶しいからといって重要な警告まで抑制するなんてアホなだけだと思う。

855 :817:03/05/30 23:34
遅いレスですいません。
もちろん、if (0==i)の意図はif (i=0)というミスを防ぐためで、
そこまではわかりますので、まぁしたがってもいいかなと。
しかし、間違い(誤代入)の起こりようのない不等式の場合も
if (0 < i)だし、あろうことかif (0 != strcmp(s, t))なんて変態的な
書き方まで強要されるのでいらいらするのですね。
大体右辺左辺ともに変数だったらどうあがいても無駄じゃん…。

856 :hn ◆iKwMOjCT4s :03/05/30 23:40
わかった。適当にソースコード整形フィルター作れ。コミットするときだけ整形しる。

857 :817:03/05/30 23:43
>>856
あ、それいいね。そうしよ。

858 :仕様書無しさん:03/05/30 23:45
if (0 != strcmp(s, t))を後からif (0 == strcmp(s, t))にする
可能性は否定出来ないな。

>変態的な

もともと一般人から見れば==だって!=だって十分変態的だと思うが。
左右が変わるぐらいで騒がなくても。
まあ、オレはそんな書き方しないけど。


859 :hn ◆iKwMOjCT4s :03/05/30 23:47
ちゅうかしかし、周りの人はどうよ、適応しているのか?

チームワークの観点からすると、できれば適応できりゃいいが、
皆がぶつくさ言いながら従ってるっていう状況なら(わからんけど、上司が異常なプライドの持ち主ってことはよくある話だ)
ナントカできないか考えたほうがいいよなぁ。

860 :仕様書無しさん:03/05/30 23:51
0 == i は日本人には分かりづらいから
i == 0 にしろといっても・・・。
if ( 0 == Panel.Labals.Items.GetSaruGechu( PSP, FuckU) )
# if ( Panel.Labals.Items.GetSaruGechu( PSP, FuckU) == 0)
# これは分かりづらい。結果を先に言えって主義なので。
なる使い方する場合も考慮すると、
0 == i の方が統一感あるので、好きだ。

861 :仕様書無しさん:03/05/30 23:52
0より大きく100より小さい時
(A) if((i > 0) && (i < 100))
(B) if((0 < i) && (i < 100))

(B)を使ってしまう俺は会社辞めたほうがいいですか?
0 < i < 100 をイメージして書いてるのですが・・・

862 :仕様書無しさん:03/05/30 23:54
3つ目を&&でつなぐときはどう書くのよ?

863 :仕様書無しさん:03/05/30 23:54
>>861
それは、漏れも(B)を使う達です。

864 :仕様書無しさん:03/05/30 23:59
範囲を書くときとか、順序が明らかになってほしいときとかは(B)だな

865 :hn ◆iKwMOjCT4s :03/05/31 00:00
OO言語じゃ .eql とか .equals とか == がメソッドとして定義されている場合が多いから、
やっぱ比較対照が前にあるほうが自然だ

866 :本気にしちゃダメっす:03/05/31 00:02
(例1)
  if( (hogehoge == 0)
   || (foo == 0) )
と書くより、
  if( (0 == hogehoge )
   || (0 == foo) )
と書く方が演算子が揃え易く、見た目が整然とする

(例2)
  if( this_is_long_name_function( this_is_longname_var, ...
↑のように画面からはみ出す位長い関数の戻り値を
見て分岐する処理があったとする。
関数の戻り値はbool型だから、trueを返してきたら実行か、
と思ったら末尾が
  this_is_longname_var ) == false ) {
だったり…なんて事があると嫌だから


867 :仕様書無しさん:03/05/31 00:04
いや確かに "".equals (str) とは書くけど、それはまた別じゃないか

ていうか >>861 は括弧つかいすぎな気がするが、これも決まってるのかな

868 :仕様書無しさん:03/05/31 00:06
>859

ああ、そりゃ規約を変えた方がいいな。
その規約に従うことによって検出される代入文となることのミスより、
不自然と感じる記述による条件式のミスによるバグの方がきっと多くなる。
多分1桁か2桁くらい。

おまけに前者については多くのコンパイラで検出できるし、かなり手抜きの
テストケースでもおそらくひっかかるが、後者の場合はコンパイラでは
まず検出されない上に、思い込みが絡む分だけテストをすり抜けたりするから
より厄介。


869 :仕様書無しさん:03/05/31 00:11
括弧は使ったほうが見やすいだろ

870 :仕様書無しさん:03/05/31 00:15
>>866
>(例2)

bool result;

result = this_is_long_name_function( this_is_longname_var, /* 中略 */ );

if( result == true )
{
  /* ... */
}

871 :仕様書無しさん:03/05/31 00:18
>>870
if( result )
{
  /* ... */
}

872 :仕様書無しさん:03/05/31 00:20
>>870
その後に、似たような処理があるなり、
その結果を複数の箇所で使用する場合は、そうするけど。
一回しか使わない場合は、resultを宣言しないっしょ。

873 :仕様書無しさん:03/05/31 00:20
>>870

switch (this_is_long_name_function( this_is_longname_var, /* 中略 */ )) {
case 0:
    /* hoge */
    break;
default:
    /* not hoge */
    break;
}


874 :仕様書無しさん:03/05/31 00:21
>>872

基本的にresultの確保はデバッグ時に便利だからよくやります :)


875 :仕様書無しさん:03/05/31 00:26
>>874
なるほど、そういう派かぁ。
Cやってたとき、先輩に言われたやり方だあ。
漏れは変数とステップを減らす派だから。

876 :pascalらー:03/05/31 00:28
だからいったじゃないか
代入は:=比較は=にしろって

877 :仕様書無しさん:03/05/31 00:31
ってか、ここはC言語でプログラム学んだヤシばっかなのか・・・。
考え方からして・・・。
>>876
もちろんだじゃないか!忘れた訳じゃないさ!

878 :仕様書無しさん:03/05/31 00:59
クラサバの頃から脳味噌固まったままのオヤジ共、
Webアプリなのにブラウザのクローズを許さず
ユーザーにログアウトを強要するとか、
ブラウザがクローズしたら自動でログアウトするとかは
お願いなんでもう諦めてください。
それは出来ねえんだってば。


879 :仕様書無しさん:03/05/31 01:09
適応力不足ってやつだな

880 :仕様書無しさん:03/05/31 01:23
>>878
いるよな、そういうやつ。
なんで俺がお前のオナニーにつき合わなければいけないのかと考えてしまう。
なんで不可能なことを不可能と認めようとしないのかが理解できない。
なんであまりにも不自然で無理がある仕様をごり押ししようとするのかが不思議で仕方がない。


881 :仕様書無しさん:03/05/31 01:34
0 との比較に 0 == foo と foo == 0 のどちらもありえない。

俺だったら if (!foo) と書く。もちろん真偽値との比較式も書かない。

と、新たな燃料を投入してみるテスト(w

882 :r:03/05/31 01:39
判ったよ。おれが今後コーディング規約作るときは
#define EQUALS ==
#define LET =
とかってマクロの使用を強要するようにしておくよ

883 :仕様書無しさん:03/05/31 01:51
なぜLET・・・

884 :仕様書無しさん:03/05/31 01:53
>>881
数値に論理演算キモイ

885 :r:03/05/31 01:57
>>883
いや、N-BASICがそうだったなぁっと...

886 :仕様書無しさん:03/05/31 02:03
なんちゃって英語で埋め尽くされたソースコードってのもあるな

887 :r:03/05/31 02:10
>>886
コボル?

888 :仕様書無しさん:03/05/31 02:14
>>885
そういう理由でコーディング規約を決めるなとあれほど・・・

889 :仕様書無しさん:03/05/31 02:16
>>887
英語ならまだいいよ……
なんちゃってローマ字の怒涛の攻撃に貴様は耐えられるのか??

890 :仕様書無しさん:03/05/31 02:58
>>884
C においては論理演算式も数値演算式もその結果については何ら違いは
ないのだが、何か?

891 :山ア渉(^^) :03/05/31 02:58
やっぱ変数名、関数名、クラス名、コメントは漢字で行こう
わかりやすいくていいよ

892 :仕様書無しさん:03/05/31 03:25
>>878
はげどう。
そんなにクラサバが良いならWebアプリ化なんぞしなきゃイイのに。

ああ、今度の仕様変更要求は
「全てのボタンにファンクションキーを割り当てろ」とか
「規定の桁数入力したら自動でフォーカスを移動しろ」とかそんなのばっか。
他に金かけることあるだろうと小一時間(ry

893 :仕様書無しさん:03/05/31 03:26
>>851
大昔に講習受けた記憶があるけど「モジュールの出口は1つ」なんて規約
あったっけ?
goto も上から下は認めてた様な…
ダイクストラの文献探してみるか…

894 :仕様書無しさん:03/05/31 03:42
途中でreturnって結局最後の行にgotoと同じ事だろ?
それを禁止してどうやって書くんだ?

それと関数の途中で抜けるはだめで、
ループの途中で抜けるはOKなのか?
関数の途中で抜けるのがだめな理由を考えると、
ループの途中で抜けるのもだめな気がするのだが。

895 :仕様書無しさん:03/05/31 03:43
>>870
bool isSuccess;

isSuccess = thisIsLongNameFunction(thisIsLongnameVariable, /* 中略 */ );

if (isSuccess) {
  /* ... */
}


896 :仕様書無しさん:03/05/31 06:25
世の中にはMISRA-Cという
自動車開発向けのC言語規格(規約)ものがあってな・・・

・gotoの使用禁止
・switch以外でのbreakの使用禁止
・continueの使用禁止
・判定式での代入式の禁止
・関数の出口は一つ
・a = *p++; のような文はだめとか

Cっぽくないソースができあがる規約もあるのよ・・・

897 :仕様書無しさん:03/05/31 08:23
さぞ糞ソースばかりになることであろうな

898 :仕様書無しさん:03/05/31 09:38
Javaなのに変数名も自由に使えません。
変数名管理システムに問い合わせることで変数名を取得。作者は元コボラー。
全てのクラスでユニークな名前をつけなくてはなりません。
スコープの意味なし。


変数名管理システム

○文字列型
○整数型
○小数型

○グローバル変数
○ローカル変数
○ループ変数
○テンポラリ変数

[変数名を取得]←ボタン


899 :仕様書無しさん:03/05/31 10:14
ちゃんと構造化してあれば
ハンガリアン記法やら変数名を気にする必要はない。

俺はJavaでもパッケージをかなり細分化するので、まったく同じクラス名がかなり出てくる。
foo.bar.Entry, foo.baz.Entry という構成はあっても、
foo.BarEntry, foo.BazEntry にはしない。

あくまで foo パッケージだけでフレームワークを作れる場合の話だけど。
(それこそ foo.Entry クラスが存在してて、foo.bar.Entry や foo.baz.Entry は
foo.Entry を継承してる)

コードをJustInTimeで解析してくれるIDEがないと開発効率に雲泥の差がでるけど、
ソースの綺麗さは抜群に良い。


900 :仕様書無しさん:03/05/31 10:14
グローバル関数使いまくりで解読不能
ある意味、gotoスパゲッティと同等

901 :仕様書無しさん:03/05/31 10:15
>>900
グローバル関数→グローバル変数
まちがえた

902 :仕様書無しさん:03/05/31 10:17
>>898

その場で発行されるのならまだいいよ。俺は>756だが、
紙で申請書を書いて変数名が払い出されるまで1週間
かかるんだぞ。
その間、後から一括置換できるようにユニークな変数名を
割り当てておいて、テストを実行。払い出されたところで置き換えて、
再度テスト。作業途中で変数名が変わるからわけ分からん。
もう、ウェーハッハッハッと笑うしかねーぞ。


903 :仕様書無しさん:03/05/31 10:21
なぜその元コボラーを頃さない?

904 :仕様書無しさん:03/05/31 10:49
作り逃げ

905 :仕様書無しさん:03/05/31 11:03
>>899
Eclipseつかってる?

906 :仕様書無しさん:03/05/31 11:10
hogeが1〜3であることが保証されている場合
switch( hoge )
{
  case 1:
    break;
  case 2:
    break;
  default:
    break;
}

レビュー中にプロならこう書こうよって言われますた。
その時はさらっと流しましたが、ほんとにこういう書き方すべきなんでしょうか?

907 :仕様書無しさん:03/05/31 11:12
hogeが1〜3であることが保証されている場合でも
switch( hoge )
{
  case 1:
    break;
  case 2:
    break;
  case 3:
    break;
  default:
    ShowErr();
    break;
}

って書いてしまいたくなる漏れは天然記念物的大馬鹿者ですか?


908 :仕様書無しさん:03/05/31 11:16
>>907
心配性か石橋を叩いて渡る性格

909 :仕様書無しさん:03/05/31 12:03
1-3が出力されるのが保証されている部分を素人が組んだなら>>907で。

例えば、仕様変更で出力が1-3ではなく1-5になった場合、
>>906だと3-5の動作がみんな同じになる → エラーも出ず危険。
>>907なら少なくとも、ShowErr関数が呼ばれるのでチェックが出来る。

計算速度も大して変わらないだろ?
漏れは、>>907をお勧めするな。

910 :仕様書無しさん:03/05/31 12:04
s/出力/hoge/g

911 :仕様書無しさん:03/05/31 12:41
おれも>>907だな。
そもそも、「hogeが1〜3であることが保証されている」なんて
ことを信用しない。

912 :906:03/05/31 12:42
漏れとしてはdefaultにある特定の値(=3)に対する
処理を割り当てるのは気持ち悪いな〜、と

ちなみにこれ、装置に制御用のパラメータを設定してるん
ですが他の装置に同じ値を設定したらやばいことになります(たぶん)
まあ、仕様変わったときに対処漏らさなければいいって言えばそれまでですけど

913 :仕様書無しさん:03/05/31 12:44
>>912
そっちの感覚の方がまともだと思われ。
指摘した人は何者ですか?

914 :仕様書無しさん:03/05/31 12:56
(・∀・)プロナラ!!

915 :仕様書無しさん:03/05/31 13:16
ヽ<`Д´>ノ ウリナラ イウナ ニダ!

916 :仕様書無しさん:03/05/31 13:38
>>898

おもしろいなそれ
CGIで公開したら使ってやろう


917 :仕様書無しさん:03/05/31 13:53
>>906のレビュアー絶対おかしいよ。
この話聞いたらdefault作った人も泣くと思う。

918 :仕様書無しさん:03/05/31 13:55
898のcgiを使ったところ
FNC1223_G_LNG_COMMON_KJOCODE_LOOP_0721なんつー変数名がじゃんじゃか製造されますた

919 :仕様書無しさん:03/05/31 14:09
>>918

どうせなら不正な変数名使ってないかチェックしやすいように
変数名の最後に変数名のMD5ハッシュを付加したらどう?

920 :仕様書無しさん:03/05/31 14:13
ASSERT( NULL != this );

全てのメソッドに付けてる漏れは逝ってよし。

921 :仕様書無しさん:03/05/31 14:15
JavaやC++なら、>>906
Cなら>>907にする。

922 :仕様書無しさん:03/05/31 14:16
>>920

それって意味あるの?
thisポインタが破壊されて、しかも0クリアされた
時しか意味ない気がするんだけど


923 :仕様書無しさん:03/05/31 14:17
どっかのサイトで見たんだけど、

#define begin {
#define end }

if(i==0)
begin
/* ... */
end

こんなばかそーすを実際に見たことある香具師いる?

924 :仕様書無しさん:03/05/31 14:18
>>923パスカル?すばらしい!!!

925 :仕様書無しさん:03/05/31 14:20
>>923

厨房の時BASICからはじめてC使って小文字にどうしても
なじめなくて

#define A a
#define B b
#define C c

ってやってたことがあったなあ



926 :仕様書無しさん:03/05/31 14:26
#define BEGIN {
#define END ;}
#define THEN BEGIN
#define ELSE END else BEGIN
#define ENDIF END
#define ENDWHILE END
#define DO do BEGIN
#define WHILE END while(
#define ENDDO );
#define REPEAT DO
#define UNTIL WHILE!(
#define ENDREPEAT )ENDDO
#define ENDFOR END
#define NEXT END
#define LOOP for(;;)BEGIN
#define ENDLOOP END
#define ENDSWITCH END


927 :仕様書無しさん:03/05/31 14:30
#include <stdio.h>

class CFoo
{
public:
void foo(){
printf( "CFoo::foo()¥n" );
};
};

void main()
{
CFoo *p = NULL;
p->foo();
}
間違ってたらスマソ

VC++6.0ではなにげに実行できる。
SunCCでも実行出来る。

928 :仕様書無しさん:03/05/31 14:34
>>927
んー、できても別におかしくないと思うけど…。

929 :仕様書無しさん:03/05/31 14:36
そりゃstatic methodだからじゃないの

930 :仕様書無しさん:03/05/31 14:36
>>927 それがどうしたの?

931 :仕様書無しさん:03/05/31 14:36
あ、methodじゃないか

932 :仕様書無しさん:03/05/31 14:37
>>929
static な method の意味が…

933 :932:03/05/31 14:39
あら、既に自省してたのね。失礼!

934 :いや、ネタだけど。:03/05/31 14:39
>907
1〜3だというなら
func[hoge-1]();
で飛ばしてしまえ、とか。

935 :920:03/05/31 14:48
ソマソ
927=920だ。

NULLポインタで呼び出してるバグを検出する際、
ちょっとはわかりやすくなると思ってさ。

936 :仕様書無しさん:03/05/31 14:49
>>928
俺よく分からんのだけど、
CFoo *p = NULL;
p->foo(); ←関数呼び出し
はOKってことなの?

解説キボン。

937 :仕様書無しさん:03/05/31 14:51
じゃー、 this と NULL を比較…。
おそらく問題が起こる時は、スタック上の未初期化のポインタで
method 呼ばれても NULL ではない可能性も高いけどね。

938 :920:03/05/31 14:53
実際あまり意味のないアサーションなんだよな・・・・

939 :仕様書無しさん:03/05/31 14:55
>>936
特にメンバ変数を読み書きしてないからな。
virtual でもないから vtable も参照しないし。

コンパイル時に CFoo クラスの foo() の呼び出しコードに
確定しちゃうんだよ。


940 :仕様書無しさん:03/05/31 14:55
未定義動作だけど、たいていの実装では呼び出し前にチェックするコードは生成されず、
thisにNULLが載って実行される、ってことで合ってる?

941 :仕様書無しさん:03/05/31 14:57
>>938
気持ちはワカル!

だって呼び出した側が悪いのに、自分の実装したクラスが
疑われる、ってことだもんね。

942 :928:03/05/31 14:58
>>936
コンパイラにしてみればpがどのクラスのポインタなのかが
わかれば、どの関数を呼び出せばいいのかは判断できるでしょ?
そしてその関数内で非staticのメンバ変数の参照なんかを
しない限りは、特に問題は起きない。
まぁ、>>927が変なコードなのは確かだけど。

943 :920:03/05/31 14:59
漏れの経験ではそんな感じ。

でもって、関数がしばらく実行されて、初めてメンバ変数かメンバ関数が
呼ばれると、そこでヤヴァイ事になる。

でもってデバッグのとき意外と苦労したりしてさ。

944 :仕様書無しさん:03/05/31 15:00
>>940
そだね。
コンパイラは CFoo クラスの foo() に this ポインタを渡すけど
この場合は this に NULL が渡されていると。

tihs == NULL チェックは、コンパイラの仕事ではないでつ。

945 :仕様書無しさん:03/05/31 15:03
>>923
そのすばらしいスタイルについては既に本が出版されており、
ソースコードがWeb上から入手できます。
http://www.res.kutc.kansai-u.ac.jp/~nakagawa/book.html

これを使う事でよりよいC言語のスタイルが身につき、
会社を辞めたくなること請け合いです。

946 :仕様書無しさん:03/05/31 15:06
>>945
書いてる本人は問題ない。むしろ気持ちがいいのだ。

問題はそのソースを保守する人間だ。

947 :928:03/05/31 15:07
>>945
おれはそれここで知ったけど、みんなそうかな(w
最初見たときかなり笑った。
http://www.pro.or.jp/~fuji/computerbooks/c/c.modula2.html


948 :仕様書無しさん:03/05/31 15:10
>>947
『Cプログラミング診断室』 第8章を上回る秀作
なの?…ちょと見てみたいなー


949 :仕様書無しさん:03/05/31 15:18
http://hp.vector.co.jp/authors/VA000092/jokes/strup.html
これはジョークだが、>>945のは本気なんだよな。
まさに「事実は小説より奇なり」

950 :仕様書無しさん:03/05/31 15:18
Modula-2とかいうマイナーな言語とCとを混ぜ合わせた気色の悪い
言語を覚えさせられた初心者は今後いったいどうなるのだろう?
言語仕様を覚えるので精一杯の初心者を惑わせて何が楽しいのだろう?

951 :仕様書無しさん:03/05/31 15:19
>>950
次スレよろ!

952 :950:03/05/31 15:29

次スレたてますた。
この会社辞めようと思ったソースコード#B
http://pc.2ch.net/test/read.cgi/prog/1054362467/l50

なんの捻りもないけど。スマソ

953 :仕様書無しさん:03/05/31 15:37
>>952
お疲れサマー
でも、ホントにそのまんまだぞ!w

954 :936:03/05/31 16:22
>>939 >>942
ありがd。
少し前に友達に
「このコード動くんだけど、途中でセグる」って言われて見たときのコードがそれだった。
実際には、
CFoo *p;
p->foo();
だったのだけれども。
調べたところ、pが初期化されてないのにfoo()が呼ばれてて、
その中でおかしくなってた。

未初期化のオブジェクトに対してメソッドを呼べないようにした方がいいと思うんだけど、そうしない理由は?
単にオブジェクトが初期化されてるかどうかを判断できないからということ?

955 :939:03/05/31 16:53
友達に見せてもらったコードでは、メンバ変数を触ってたんじゃないの?

CFoo に メンバ変数を増やして、
CFoo::foo() でそのメンバにアクセスするようなソースにしないと
seg fault になるようなソースにはならんのだが。

メンバに触ってれば(gcc だったら -Wuninitialized つければ)、
一応警告は出るはずだけど。

>>927 のソースでは、メンバをいじらないから、コンパイラも
特に問題がないとして -Wuninitialized つけても問題が出ないっす。
多分。

956 :936:03/05/31 17:23
>>955
えっと、自分は>>939のレスで十分理解できました。
要するにthisポインタを介したアクセスが存在しないメンバ関数はいつでも呼び出せる
(メンバ関数は暗黙的にthisポインタが渡されるだけのただの関数だから)ってことですよね。
これは規格の上で正しいものなのでしょうか?それとも環境依存なのでしょうか。

>友達に見せてもらったコードでは、メンバ変数を触ってたんじゃないの?
そうです。>>954ではそれを言いたかったのです。
言葉足らずですいません。

957 :928:03/05/31 17:31
>>956
ちゃんと調べてないが、規格上問題ないと思うぞ。
コンパイル時に、そのポインタが正しくオブジェクトを
指してるか指してないかのチェックがどれだけ大変だと
思うか考えてみ。(無理でしょ)

958 :939:03/05/31 17:34
>>956
this ポインタ、というかアドレスの妥当性は言語の取り決める範囲だろうか…
これ以上は言えないです。

959 :仕様書無しさん:03/05/31 17:36
>>957
貴様、未定義動作を問題ないと申すか?

960 :928:03/05/31 17:38
>>959
どういう意味で発言してますか?
私は「コンパイラがポインタが正しくオブジェクトを指しているか
どうかチェックしなくても問題ない」という意味で発言していますが。

961 :928:03/05/31 17:44
なんか日本語下手でしたね。もう一回書きますと、>>957
「”ポインタが正しくオブジェクトを指しているかどうか”を、
コンパイラがチェックしなくても(規格上)問題ない(のではないか)」
という意味の発言です。

962 :仕様書無しさん:03/05/31 18:08
>947

あの書き方を世に広めたという点では、おそらくこっちが大先輩。

林晴彦 「Cプリプロセッサパワー」

全編に渡って例のようなマクロが満載。本を開いて10分で頭が痛くなること
請け合い。悪影響の大きさで三田本と並ぶ怪作。

ttp://www.pro.or.jp/~fuji/computerbooks/c/cprepro.hayashi.html


963 :959:03/05/31 19:02
>>961
未定義動作と言ったら、実行時の動作の話。

「thisポインタを介したアクセスが存在しないメンバ関数はいつでも呼び出せるってことですよね」
に対しての「問題ない」がとてもコンパイル時のみの話とは読めなかったので。

964 :936:03/05/31 19:17
皆様レスどうもです。
>>957
>コンパイル時に、そのポインタが正しくオブジェクトを指してるか指してないかのチェックがどれだけ大変だと思うか考えてみ。(無理でしょ)
そう思った上での発言が
>>954 >単にオブジェクトが初期化されてるかどうかを判断できないからということ?
です。無理だろうというのはなんとなくわかります。

ところで、この問題の回避法は「気をつけること」と「>>920」でしょうか。

(自分はメソッド内でthis==0になったことがないのですが・・・。経験が浅いからなのでしょうか)

965 :920:03/05/31 19:43
実際問題として直接this==0の近辺でエラーが出ることはないかな。
それよりもは、そこから呼ばれていった別の部分(MFC等のライブラリ内)や、
もっと後の処理でおかしくなってたりとか。
でもって、ステップ実行したり、スタックを1つずつ戻っていって、
ふとthisの値をみると0になってたり。


966 :仕様書無しさん:03/05/31 19:44
>>965
thisは存在する。thisの向こうに誰もいないだけで。


967 :939:03/05/31 19:45
>>964
そうでつ。気をつける のはポインタを使う限りついてまわる話。
結果にコンパイラは「問題ない」コードを吐いたとしても、それは結果論。
そもそも未初期化のポインタを使う事自体が期待した動作ではないでしょう。

this == NULL なんかも利用者側が期待していないものの一つ、ってことに
過ぎないですよ。

968 :仕様書無しさん:03/05/31 19:48
>>965
Windows だとデカい値がポインタに入っているとアドレス扱いして、
0 に近い値だと ID ( リソースID ) 扱いしてたりしなかったかな…

自信なし。

969 :仕様書無しさん:03/05/31 19:57
漏れが知ってるのはCStringのコンストラクタかな。

気持ちが悪いのもほどがある。
CString s( IDS_NULLPO );


970 :969:03/05/31 20:00
スマソ間違えた。
CString s( (LPCSTR)IDS_NULLPO );
キャストしなくてはな。

971 :仕様書無しさん:03/06/01 02:10
会社のHPのindex.htmlのBODYタグが

<body background='bakku.jpeg onload="init();"'>

だったとき

指摘したら稟議書上げてくれって言われ…

972 :仕様書無しさん:03/06/01 03:12
>>971
タグって時点で終わっているもの。

973 :仕様書無しさん:03/06/01 03:19
>>972

>>971じゃないがBODYタグで合ってるだろ?
BODY要素開始タグとでも言って欲しいわけ?

974 :仕様書無しさん:03/06/01 03:23
>>973
>>972じゃないが Style Sheet 使えってことでは?

975 :仕様書無しさん:03/06/01 03:28
>>974
>>973だが、
>タグって時点で終わっているもの。
から
>Style Sheet 使え
が導き出せるのか?
たとえCSS使ってもonload使うならタグは省略不可だろうに。

976 :仕様書無しさん:03/06/01 03:31
えーっとつまり、>>972
>タグって時点で終わっているもの。
じゃなくて、
>backgroundって時点で終わっているもの。
だったら
>Style Sheet使え
ってことだろうと分かるんだけど。ってことです。

977 :仕様書無しさん:03/06/01 03:41
>>975
>>974じゃないが、へたしたらいつまでたってもこないイベントに依存するのか?

978 :仕様書無しさん:03/06/01 03:50
background=<STRONG>'</STRONG>bakku.jpeg onload="init();"<STRONG>'</STRONG>

誰も気付かないのか…
>971の会社のHP担当した奴並の無能揃いだな

979 :仕様書無しさん:03/06/01 03:50
>>977
>>975だが、どういう意味?

980 :仕様書無しさん:03/06/01 03:52
>>978
それ何のつもりだ?

981 :仕様書無しさん:03/06/01 03:52
無能かもしれんが知恵熱ぐらいは出るぞ。

982 :仕様書無しさん:03/06/01 03:54
>>978
それがどうかしたのか?今は>>971はあんまり関係ないだろ?

983 :仕様書無しさん:03/06/01 03:59
もはや誰一人として話が噛みあっていない罠。こんな会社あったらイヤだw

984 :仕様書無しさん:03/06/01 04:00
>>971-982
秀逸(w

985 :仕様書無しさん:03/06/01 04:17
てめーらのせいでタマちゃんの体の色が変色したぞ
どうしてくれる

986 :仕様書無しさん:03/06/01 04:17
>>978
なるほど!それは終わってる!

987 :仕様書無しさん:03/06/01 05:27
>>971
<body background='bakku.jpeg onload="init();"'>
            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
<
body background=
'bakku.jpeg onload="init();"'
>

騙し絵みたいなもんやな…。

988 :仕様書無しさん:03/06/01 07:50
こういう会議よくあるね・・・

989 :仕様書無しさん:03/06/01 13:17
>>978が一番マヌケだ。

990 :仕様書無しさん:03/06/01 13:21
<STRONG>'</STRONG>なんてどういう神経してるかわかんない。まじで。


991 :仕様書無しさん:03/06/01 13:34
ああ、あのカブトムシがモチーフのね

992 :仕様書無しさん:03/06/01 16:27
天が呼ぶ 地が呼ぶ 人が呼ぶ

993 :992の続き:03/06/01 16:43
退治てくれよう桃太郎

994 :仕様書無しさん:03/06/01 16:57
近所のTSUTAYAにあったスカイライダー(なぜか1巻と7巻のみ)
両方借りられてた。だれだよ俺以外にそんなの観たがるやつ。

995 :仕様書無しさん:03/06/01 17:01
>>994
夜のお前だ。

家の中をよく探してみろ。

996 :仕様書無しさん:03/06/01 18:50
sageてみる

997 :仕様書無しさん:03/06/01 18:50
あと4つ

998 :仕様書無しさん:03/06/01 18:51
あと3つ


999 :仕様書無しさん:03/06/01 18:52
あと2つだけど
俺が1000とったら速攻dat行きだ。
どうしよう

1000 :仕様書無しさん:03/06/01 19:07
1get

1001 :1001:Over 1000 Thread
このスレッドは1000を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。

216 KB
★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.02 2018/11/22 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)