1 :
デフォルトの名無しさん :
2005/03/25(金) 19:53:00 javaはC/C++からポインタをなくしたりGCを導入することで メモリ管理にまつわるバグを出にくくした。 そのような考えを推し進めてバグの出にくい言語仕様を考えよう。
>>1 は根本的なことを判っていない。
プログラムが無ければバグも出ない。
つまり、言語仕様を考える前に、
如何にしてプログラムの存在しない世界を作るか、
を考えるべきだ。
これまた
>>2 に思い切った電波を仕込むアグレッシブなスレだな
4 :
デフォルトの名無しさん :2005/03/25(金) 20:39:19
俺はこんなバグを出したという情報募集。 それを回避できる言語仕様を考えていこう。
文字を組み合わせて意味を成すからいけない コンピュータでなぜ文字→単語→文という粒度が必要になるのか?
>>1 もうプログラミング言語は進化し終わった
あとは手法の問題
バグの出にくい言語仕様を考えるより、バグの影響を最低限に抑える環境を考えた方が建設的な気がする。
>>2 はMDAのことを言っているようにとれなくもない。
UIのバグはどうにかならんものか
誰かが作ったものを買う。
Javaに残っている「バグが出やすいところ」を解析するのが 一番の近道かと
言語仕様だけでバグの出にくさとか狙っても防げるのは瑣末なミスばかりで testabilityが落ちるために却ってトータルの生産性は落ちる罠。
>>6 おとといは馬をみたの。きのうは鹿、きょうはあなた。
言語の進化ってなんだろう…
というか、作り方を簡単にするのではなく、作り手を教育した方がいいと思う。 駄目な奴は何を使っても失敗する。
作り方を簡単にする、ねぇ・・・(ニガワラ
JAVAやVBよりもバグになる要素が多い、Cやアセンブラだって、まともな奴が作ればバグは出ない Cやアセンブラよりもバグになる要素が少ない、JAVAやVBだって、アホが作ればバグは出る バグが出にくくすると言うことは、できることも少なくなると言うことで 制限のあるような言語を完璧に作っても意味ないと思うよ 俺も、教育を何とかした方がいいと思う 高度なことをやるためには、やはりCやアセンブラのような、 ハードを気にする言語が必要だって コンピュータのことが解らないプログラマを大量生産しても、先細りになるだけ Cやアセンブラレベルの事ができて、バグが出づらい言語をと言うのなら理解できるが、 JAVAの焼き直しとか、そう言うのはあまり意味がない
19 :
1 :2005/03/26(土) 17:30:05
私としては実用性がどうこうという議論はひとまず置いといて 学術的な興味としてどのような言語がバグが出にくいか考えたい。 そのためにはかなり強い制限をかけてもよいと思う。 実行性能も気にするな。 意味は後からついて来る!
20 :
デフォルトの名無しさん :2005/03/26(土) 18:05:42
文系でもできるもん! VBOracleASP
23 :
1 :2005/03/26(土) 18:23:38
>>12 テストのし易さは重要なファクターだと思う。
それも言語仕様に含められないだろうか。
そもそも関数型言語ではコンパイルさえ通れば論理的なバグは発生しない訳だが… 発生するとすればコンパイラにバグがあるってことになる。 Cなどでは論理的なバグに悩まされることも結構あるんだよね。
それでいて、どうして生産性が高いと言われ続けているのか結構疑問かもかも。
>どうして生産性が高いと言われ続けているのか 馬鹿には使えないようになってるから
C系のプログラム言語はリソースが豊富だしな 言語仕様そのものが生産性を上げるわけではないと思う
バグの出にくい言語仕様なんてもんは無いと思う。 バグが埋もれにくい(=発見しやすい)言語仕様はあるだろうが。
Design By Contractとかだね
>>29 いや、俺が考えてたのはそういう事じゃない。それは、結局検出する機構を用意しているに過ぎない。
> バグが埋もれにくい(=発見しやすい) > 検出する機構を用意している おなじじゃんw
人間は多少のバグは脳内訂正できるから問題なし。
どっかで誰かが言ってたが、 プログラムを作るのにも資格が必要なんじゃないかと。 たとえば命にかかわるプログラムの場合 なんちゃら資格が必要だとか。
typedef で型名を定義した場合、再定義ではなくまったく 新しい型として扱われる。たとえば、 size_t と int では別の型となる。 enum 型で列挙された値以外の定数を enum変数に代入するとコンパイル エラーになる。
そんなのいまどき当たり前
39 :
デフォルトの名無しさん :2005/03/27(日) 12:43:36
たとえばさ、
BaseClass class {
省略
void Method1(void);
省略
};
DerivedClass class {
省略
void Method1(void);
省略
};
なんていう記述があったときに、言語仕様としてMethod1の呼び出しで
明示的にクラス指定をしなければならないとするか、
実装者に任せてコンパイラの警告に任せるとするかってするのは
全然違うよな。言語仕様として曖昧性を許さないというのは重要なことだと思うよ。
ほかにも多重継承を言語の仕様からはずしてしまうなんていうのも
言語仕様としてバグが出にくくしているといえると思う。
>>1 はそういうこと言ってるんじゃないの?
で、具体的なネタも振らずに逃げたわけだが。
41 :
デフォルトの名無しさん :2005/03/27(日) 16:14:38
42 :
デフォルトの名無しさん :2005/03/27(日) 16:43:25
CPUからX87FPUをとっぱらって 有理数をサポートするX88RPUを開発してくっつける
それは、バグの発生と関係あるのか ? まさか、誤差とバグを混同してるなんてことないよな。
まぁまぁ、おまいら。とりあえず要求定義しようではないか。
型推論入れろー!
Javaで十分バグが出にくいと思うんだけど・・・ そもそもバグって最適化にミスった時にしか起きないよね? 普通に組めばまず起きない
47 :
デフォルトの名無しさん :2005/03/27(日) 19:01:21
>>45 型推論って余計にバグの温床になりそうな気がする。
>>47 例えば、どんな時?
型推論だとテンプレートも要らないし、論理的なバグが激減すると思うんだけど…
49 :
♥ :2005/03/27(日) 19:52:14
分析結果⇔外部設計⇔詳細設計⇔実装 を統合できる開発環境があればいいのではないかな。 1.前工程の成果物を作成した時点ですでに次工程の成果物がある程度できてる。 2.後工程の成果物に変更を加えれば前工程の成果物にも自動で変更が加えられる。 メリットは 1.下位工程への落としこみ、上位工程の修正時の人的ミスの減少 2.各工程のドキュメントが同時に変更されるので、検証が容易。 でも言語仕様とはちがうかな。。
50 :
デフォルトの名無しさん :2005/03/27(日) 20:18:50
不完全性定理によると 「その論理の無矛盾性はその論理が無矛盾である限り証明できない」。 よって完全な言語仕様を定義することさえできないのだっ!のだっ!のだっ! 反論は受け付けません。
数学の無矛盾性の証明不能を数学的に証明したわけね
ああ、相対性理論の話ね。あるあるw
>>50 それの証明はされているけど、論文には載せられないよね。量が多すぎて。
54 :
デフォルトの名無しさん :2005/03/27(日) 20:56:18
ロジックの複雑さを常に一定に保てる仕様とか
関数型言語で解決?
57 :
デフォルトの名無しさん :2005/03/28(月) 00:19:21
58 :
デフォルトの名無しさん :2005/03/28(月) 00:25:31
誤差がもしないとしたら そもそも誤差によって起こる矛盾を回避する為の 例外的コードを書く必要がなくなり 結果その部分で虫を含む可能性はなくなる 虫というのは自然発生する訳でもなし その原因をみないで何がわかるか? 虫を排するもっとも優れた方法は そもそもプログラムを書かないこと これもひとつの真理だろ
>>58 つまらん事言ってるから、お前は今後は無視
>>50 その公理系の内側からは証明できないって話じゃなかったか?
最近は大概の機能がコンポーネントとして抜き出されてる
>>58 を好意的に受け止めるとそういう理屈でバグを回避してることになる
てことは「バグの出にくい言語」=「コンポーネントの多い言語」か
「バグの出にくい」じゃなくて、「バグの入りにくい」だろ!
より多くの規格品をかき集めることが大切なんだろうね。 gotoとかも定型化された使い方なら安全・綺麗・効果的となる。 細かいパズルより大きなパズルの方がバグが出ないのは当然のこと。
んで、客先でレビューして、あんな事もできない、こんな事もできないと叩かれるわけだ(鬱
66 :
デフォルトの名無しさん :2005/03/28(月) 12:46:54
>>1 Javaにポインタはある。
それを意識しなくてもいいというだけだ。
仕様書を見てみろ
_ '´ ヽ ! j リノ)))) ヘヘェ♪ _ l ll*゚ ヮ゚ノ∫_ 〔ノ二二,___ リ リ __,二二ヽ〕 |:::::::::::::::::::::::::::ヽ ゜ ゜/::::::::::::::::::::::::::/ 〉::::::::: :::::::::::::〉 ・ 〈:::::::::::::: ::::::::〈 バッ |:::::::::::::::::::::::::/ ■ ヽ::::::::::::::::::::::/ 〔:::::::::::::::::::::/ ノ~ヽ ヽ::::::::::::::::::| ヽ:::::::::::::::::/ /::::::::::::\ ):::::::::::::::::::ゝ ノ:::::::::::::::::::| |_〜─〜-| |〜〜〜/
68 :
デフォルトの名無しさん :2005/03/28(月) 14:35:20
>>66 そりゃVMレベルの、つーか、バイトコードレベルの話じゃね?
プリミティブ型以外は事実上ポインタじゃねーの?
>>69 _
'´ ヽ
! j リノ)))) ヘヘェ♪
_ l ll*゚ ヮ゚ノ∫_
〔ノ二二,___ リ リ __,二二ヽ〕
|:::::::::::::::::::::::::::ヽ ゜ ゜/::::::::::::::::::::::::::/
〉::::::::: :::::::::::::〉 ・ 〈:::::::::::::: ::::::::〈 バッ
|:::::::::::::::::::::::::/ ■ ヽ::::::::::::::::::::::/
〔:::::::::::::::::::::/ ノ~ヽ ヽ::::::::::::::::::|
ヽ:::::::::::::::::/ /::::::::::::\ ):::::::::::::::::::ゝ
ノ:::::::::::::::::::| |_〜─〜-| |〜〜〜/
71 :
デフォルトの名無しさん :2005/03/28(月) 16:55:15
>>69 まぁそうなんだがちゃんとリファレンスカウントされてる
って点が違うとおもわれ。
GCマンセーってことだな
73 :
デフォルトの名無しさん :2005/03/28(月) 19:04:16
バグのないプログラムはないが、デバッグできないバグはない。 と言うわけで日本語で充分じゃん。
74 :
デフォルトの名無しさん :2005/03/28(月) 20:00:40
誰も表明ベースについて言ってないけどあれが良いと思う。 型をさらに限定した感じ。
配列てバグの温床じゃね? 配列のない言語ってできないもんかね。
>>75 配列はリストの特殊形。そしてリストはデータ構造の唯一の基本形。
無理ですね
77 :
デフォルトの名無しさん :2005/03/28(月) 21:00:56
>75 Pure Lispなんてどう?
for文を無くしてforeachだけでプログラム組めないもんだろか。 とかいってみるテスト。
アフォ発見 といってみるテスト。
>>74 表明ベースってナニー?
ぐぐっても出てこないよぅ。
Prolog
83 :
デフォルトの名無しさん :2005/03/29(火) 02:45:10
パクリ元はEiffelだが
今日もバグを出してしまった。 はやくバグの出ない言語を作ってくれ。
86 :
デフォルトの名無しさん :2005/03/29(火) 22:43:53
仕様が変わったときに影響範囲を自動で検出できるといいんだけど。
87 :
デフォルトの名無しさん :2005/03/29(火) 23:14:40
仕様変更ってのは機能追加の場合も多いだろ。今までにない機能を追加するのに、それの影響範囲を自動で検出するなんて理論的に無理。あらかじめ想定内(豚社長っぽいいいまわしだワラ)の仕様変更なら可能かもしれんが。
そもそもコード書かなければいいんじゃないかな GUIでボタンを置いていくかのように必要な機能を組み合わせるだけ って出てるね。でもそれくらいしか・・・
89 :
デフォルトの名無しさん :2005/03/29(火) 23:47:05
ソースコードの有無の問題じゃねーだろ。そもそもがソフトウェアは何を持ってバグとするかが微 妙だから「仕様です」なんて他では考えられないセリフが生まれた。仕様は、必ずしも論理的なも とは限らないことに注意を払うべき。バグを作りこまないスーパー言語は、カオスを含むビジネス ロジックなどはコンパイルエラーが出て実装できませんなんて冗談ができあがりそうだ。
90 :
デフォルトの名無しさん :2005/03/30(水) 00:44:22
>>87 仕様変更の情報を何らかの形で与えてやれば
まったくの無理でもないような気がするけど。
まあ非常に難しいのは認めるが。
仕様のバグはどうすればいいですか?
「GUIでボタンを置いていくかのように必要な機能を組み合わせるだけ」でも バグ出す香具師はゴマンといる・・・
ナマスモノニリック理論を使えばいいんじゃない?
一方、ソ連は鉛筆を使った。
想定できるバグ(*1)を起こしうる記述を徹底的に制限して、 その類は全部コンパイル エラーにさせる。 アルゴリズムや記述方法(インデントの有無など)も バグの引き金になるようなものは一切認めない。 *1 仕様との不一致は無視 ウザそうだ
よっしゃぁぁぁぁああああ、やっとコンパイル通ったぞぉぉおぉぉぉ! って感じに喜べそうだ
>>95 想定の範囲内というのが、堀江の脳内並みに広大になりそうだ。
lintとかってバグをつぶすのに役に立ってるのかね。 あんまり役に立ってないイメージがあるんだが。
使いこなせないのと便利じゃないのは同意じゃないわけで
Adaなんかが確かバグを出しにくい(≒コーディングメンドクサイ) あれこれの機能を持っていたような・・・
int a; int len; len = GetFileSize("〜.bmp"); Error(line: 1) - 分かりにくい名前をつけることはできません。 Error(line: 2) - インデントに問題があります。 Error(line: 2) - 変数名と用途があっていません。 : :
インデントはともかく、裏を返せばコンパイラの辞書にない変数名は付けられないと。
>>99 eclipse のようにリアルタイムで通知してくれればまた別だろうね。
106 :
デフォルトの名無しさん :2005/03/31(木) 16:12:51
全ての変数はボラタイル
強い型付け&型推論
108 :
デフォルトの名無しさん :2005/03/31(木) 19:31:09
1関数80行超えるとコンパイルエラー
ネストが5以上はコンパイルエラー
110 :
デフォルトの名無しさん :2005/03/31(木) 21:02:01
ソースコードにおけるコメントの比率が5〜10%に収まっていないとコンパイルエラー。
個人的に#if 0 〜#endifの箇所はいっそのこと削除してほしい 漏れはバリバリ残してるがな
>>109 え、なんで〜 lispとかネストしまくりやん!!!
MISRA-Cとかどうなの?
114 :
デフォルトの名無しさん :2005/03/31(木) 21:18:43
依存関係のある関数どうしで重複ロジックがあるとコンパイルエラー
え〜 関数の多重定義できないの〜 最低
インデントをもっと進化させられないだろうか。 ネストが深くなるとちゃんとインデントしてあっても わけわからんくなる。
117 :
デフォルトの名無しさん :2005/03/31(木) 21:33:40
朝ごはん食べてないとコンパイルエラー
118 :
デフォルトの名無しさん :2005/03/31(木) 21:40:13
スレッドや子プロセスは非サポート
ユニットテストが完備していないとコンパイルエラー
名前規則に反しているとコンパイルエラー
マジックナンバーはコンパイルエラー
ねーねー、2次元構文(レイアウト)を採用することでどんな利点があるの?
2次元構文て何
>>123 ブロックをインデントで表したりする構文。
125 :
デフォルトの名無しさん :皇紀2665/04/01(金) 05:09:28
>>94 かなりワロタw
以下知らない人用のコピペ
アメリカのNASAは、宇宙飛行士を最初に宇宙に送り込んだとき、
無重力状態ではボールペンが書けないことを発見した。
これではボールペンを持って行っても役に立たない。
NASAの科学者たちはこの問題に立ち向かうべく、10年の歳月と120億ドルの開発費をかけて研究を重ねた。
その結果ついに、無重力でも上下逆にしても水の中でも氷点下でも摂氏300度でも、
どんな状況下でもどんな表面にでも書けるボールペンを開発した!!
一方ソ連は鉛筆を使った。
error: 平日18:00から9:00までおよび土日はコンパイルサービスを休止しております。
>>85 例えば、ある返り値を持つ関数(関数は必ず返り値を持つものだけど)を定義しても、
プログラムが停止するかどうかを判定できない。
返すべき値があるはずなのに停止しないというのはバグだけど、それがバグかどうか見付ける
プログラムは書けない。
つまり、バグを完全に見つけ出すコンパイラは書けない。
よって、バグのでない言語はない。
129 :
デフォルトの名無しさん :int 2ch =05/04/02(土) 01:49:42
なんかかなり好意的に読まないとわけわかんない文章なんだけど。
だったら好意を持ってくれ。
>>129 ところで、どのあたりがわけわかんないの?書き直すから。
>>131 129ではないが、128だけでは日本語としてかなり足りない部分があると思う。
単に言葉を並べただけで、論理展開を説明する文章になってない。
停止って何よ
それ以前に前提が間違っている。
>>135 プログラムが停止するかどうかを判定できない、の部分なら証明済みだよ
>(関数は必ず返り値を持つものだけど)
139 :
デフォルトの名無しさん :int 2ch =05/04/02(土) 10:53:04
とりあえずバグを消すのには、エディタを作るべきだと思う。
言語に求められているのはただひとつ。
代入記号と同値記号を全く別物にすること。
あと
>>125 サンクス。
>>138 必ず持たなければならないよ。voidであっても返り値は持つ。
>139 Algol, Pascal
なぜあの言語がでてこない?
あのってなんだ
Haskellをモデルにしてさらなる拡張をしようじゃないか。 いまのところHaskellが最先端でしょ?
145 :
デフォルトの名無しさん :int 2ch =05/04/02(土) 11:56:19
>>128 それはメモリを無限に使って良い場合だよね。
メモリの上限が決まっていれば停止性は極めて簡単に判定できる。
>>145 原理的に可能というだけで、簡単に判定できるとは思えないのだけど。
>>145 それはメモリの上限を越えたら停止しないってことにするわけ?
それは実行してみないと解からないことだからコンパイラでは実質不可能だよね
メモリに上限があるときには、理論的には全ての組み合わせを検証できるわけ。 そうすると無限ループとかもわかる。
>>148 どういう場合のことを言っているのかよくわかんない。
例を出してみてくれる??
そして、全ての場合に成り立つの?
リファレンスぶっ飛んで自分のプログラム領域を破壊していてもわかるの?
>>151 明示的なポインタを禁止すればそういうこともなくなる。
メモリ上にプログラムとデータを置いて、 いつでもメモリの状態を記録したり、値を設定できるようなエミュレータを考える。 メモリのサイズは有限とする。 (レジスタやHDDも値を保存するものなのでメモリに含める) メモリのサイズが有限なので、全ての状態について 次のステップでメモリがどうなるかを調べることができる。 (プログラム領域を壊すことも含まれる) 現実的なサイズのメモリに対して、全てを調べるというのは不可能だと思うけど、 理論的にはできる、という話。 要は有限オートマトンです。
>>153 それは実際に実行するよりも時間がかかるので…あまり…意味なかったり^^;
まぁ、メモリは無限ってことで考えようよ。
無限ループから自ら脱出しない関数は想定しなくていいの? 関数から脱出しない(当然返り値もない)のに正しいわけだが。
>>155 全ての場合ではなく、ある制約上では判定できそうだね
誰か証明して〜
>>155 プログラムで使用される全ての変数を監視し、同じ組み合わせが過去に1回以上現れたら
無限ループと判定出来る。何故なら、全ての変数は高々有限通りの値しか取らないから。
整数同士の割り算をしたときに無限小数になるけど、途中で出てくる「余り」が有限の値しか取らないため、
有限時間で無限小数か否かを判別できるのと同じこと。
但し、余程小さなプログラムで無い限り、プログラム内の全ての変数の組み合わせは天文学的な数になるので、
現実的ではない。
それでも、while の終了条件が現れるかどうかを検証したり(3n+1問題のような未解決問題を含む場合は無理)、
for (i=start; i<goal; i--)/* start < goal */
のようなコードに対して警告を出すようにすれば、ある程度バグを抑えることが出来る。
再帰関数の場合も、終了条件が書かれていなければエラーとする方法がある。
余程高度な(巨大という意味ではなくて、数学的に)プログラムでない限り、
停止条件の判別はそれほど難しくないはず。
でも、こんなめんどくさくメモリをモジュール領域と分離して常時監視するようなスタックもなく とろそうな言語(と言うより環境つーか、Smalltalk?)を作るのは、きっとC++かCなんだよね?
>158 理論と実装の違いがわかってないアホ発見!
「メモリの管理が完璧に行える=バグがでない」という認識のもとで議論が進んでるようなの ですが、そもそもそーゆーもんなんですか?あんまり低次元の言語使ったことないからわか らんのよ。やっぱメモリうんぬん言ってる人はCやアッセンブラの使い手なのかしら。
>>160 理論だからメモリと言ってるのだけど、
本当はレジスタとか補助記憶とかネットワークとかも含まれるわけ。
そんでありとあらゆる状態を把握して、こういうときにはこうなる
ということがわかっていればバグは出ない、という直感的には当たり前な話。
もちろん現実には全ての状態を把握することはできないし、
理論上でもメモリが無限にあったら状態は把握できない。
いきなり低レベルな話だが、 m_memberとかmember_とか_memberとかややこしいので言語仕様として命名規約を定めてほしい。
>>162 あなたはfortranの悪夢を再現したいのですか?
Cが「バグの出やすい言語仕様」である事を(しぶしぶながら)認める。 #だってCにはそんな設計思想ないもん
VBは??
C系の言語(C,C++,Javaなど)やFortranなどしか扱った事がない人は一度StandardMLなどの言語を扱ってみることを奨めてみるテスト。
どの言語でも、アホが書けばバグが出る。 まともな奴が書けばバグは出ない。
「プログラミング言語なんて,一つ知っていれば十分だ」 と考えている人がいるかもしれないが,それは大きな間違いだ. 確かに,どのようなプログラミング言語を使ったとしても,その記述能力はチューリングマシンと同じである. しかし,「プログラムを記述することができる」ということと「プログラムを自然な形で,容易に記述することができる」 ということには大きな隔たりがある. プログラミング言語というものは,ある特定の目的を想定して設計されているから,与えられた問題に対して適切な プログラミング言語を選択することは,そのプロジェクトの成否を左右する重要なことだ.
>>168 そうでもなかったりするんだよな
Cかアセンブラができれば、まず間違いなく殆どのことができる。
(まー、アセンブラは別の意味でダメだろうけど)
Cもライブラリを作って、あとはロジックだけ入れれば動くような
資産を作っておけば、他の言語とあまり開発効率も変わらない。
ただし、習得までに時間が掛かるので、使われていないだけ。
特に大規模な場合、技術者が集まらない。
そんな俺も今メインの仕事はJAVAだがな。
ぽかーん
1つの言語という概念を捨てる。どこの国の言語や方便でも対応できる。 「B747で羽田から伊丹まで運行するフライトシミュレータ」と打つだけで開発できる。 コンピュータは隅々まで完璧なものを作ろうとするのでそこを制限する。 人間が可能性を作り上げるのではなくコンピューターが作ろうとする無限を 人間がここまで開発するというゴールを決めるだけ。 これぞ誰もが求める最高の言語だ。
そして人間が、B74はどういう物かという情報を入力し間違えて事故になる 結局、どんなに簡単にしても駄目な奴は駄目
プログラミング言語はJAVAが最期のメジャー言語。 もう、終わったんだっ!終わったんだよっ!!!!!!!! チクショウっ!
そうだね、>172のように飛行機の機種を間違えるようじゃ危なくて仕方ないよな。
>>171 名指しで人を殺せと命令したらネット伝ってどこかの政府機関にアクセスして
その人の家に向けてミサイル発射させたりするんだろ?
>B74はどういう物 Bカップ74cmじゃなかったのか。。。
この前からナンセンスなことばかり言っていたやつかい? まぁ、いいか、と思ってスルーしていたけど、いい加減考えてから書き込んでくれ。
自作自演のにおいを感じる
非正格な方が定義の順番を気にしないでいいからバグが減ると思うんだけど、どうだろう。
結局関数型言語が最強ってことか
でもhaskellまでいくと理解できる人がほとんどいなくなっちゃんだよね。
バグの出やすい言語から出にくい言語を推測してみるのはどうだ?
あれだ、再帰と束縛だけ定義した言語ってのはどうだ?制御構造は再帰だけでできるし。
意外と再帰でループ書くのって面倒だよ SchemeやMLみたいにnamed-letやlet recみたいな特殊構文ないと
実はif文も入らないから非常にシンプル。 再帰でループって別に慣れたらむずかしくないと思うけど…
あとcdeclだと末尾コールのフレーム縮小できないんだよね 全部stdcallにするか、根本を変えるしかない
>実はif文も入らないから非常にシンプル。
無知が
>再帰でループって別に慣れたらむずかしくないと思うけど…
>>186 適当こくなよ
factorial 0 = 1 factorial n = n * factorial (n-1)
>>186 let recって束縛でしょ?これがなんで特殊なの???
あのなあ、それでif文消えても、なんか増えてるだろ、おい
>>194 何が増えてるの?
多重定義しただけじゃん。
>>193 let recなしでループ書こうとか思ってんのか
多重定義じゃないと思うなあ・・
>>196 MLだとletの代わりにlet recって書かないとダメだけど、その言語だとそうだというだけで、束縛は束縛。同じ意味やもん。
無知というより、頭悪いだけか
多重定義じゃなかったらなんて呼ぶんだよ!!!
条件式の数だけ関数を定義してくのか おめでたい頭だな
多相定義っていうのかな?
まあ関数型にはif文の他にもパターンマッチによる分岐があると言いたかった、と
>>205 いいや、再帰と束縛で全部かけるっていいたかったんだ!!!
オトコって都合良いこと言うわよね
>>207 惚れ直したかい?奥さん。ってキモいってキモすぎるお前もキモいんだよ!!!!糞ネカマにまで馬鹿にされちまった。
209 :
デフォルトの名無しさん :2005/04/05(火) 12:30:41
>>192 (if 文からは話それるけど)
factorial (-1) だと無限loopになるよね。
この点はadaだと、ループの終了条件をコンパイル時に検出できるけど。
Haskellでは、これをチェックする仕組みとかあるのかな?
>>193 束縛される名前の有効範囲が違う。
>>209 adaは知らないのだけど、haskellでは停止性判定なんてできないよー。そもそも停止性って判定できないでしょ?
>>209 それに、ループの終了条件はプログラムを組む時点で書いてやらなくちゃいけないもん。
まぢれす。BrainF**kにしたまえ。この板のどこかにあるから。
スレタイトル間違ったな。 あまりにも漠然だ。 だからー王道としては「バグとは?」っていうところからハイらなきゃならんでしょ。 制約を大量につける方向の意見がたくさん出てたけど、DBの設計とかでも 主キーさえ設定されていないシステムとかあるからなぁぁぁぁ。。ホント良くうごいてると思うよ。
絶対に欲しい言語仕様 ・ 一つの関数 (って概念が無ければロジックの塊) が50行を超えることはできない
普通にswitch文入ると50行超えそうだよ
http://www.rubyist.net/~matz/20050402.html#p02 空白の使い方に自由度がありすぎる、
TOOWTDI (There's Only One Way To Do It) 原則から言えば望ましくない。
よって、
* インデントは厳密に空白4つ。タブ問題もこれで解決。
* 冗長な括弧は禁止(例: return (1) は駄目、return 1が有効だから)。
* 左括弧直後および右括弧直前の空白は禁止。
* 引数括弧およびインデックス参照のブラケット直前の空白は禁止。
* コンマやセミコロンの前の空白は禁止。
* コンマやセミコロンには厳密に一つだけの空白(行末を除く)。
* 行末のセミコロンは禁止(冗長だから)
* 式の中で二つ以上の連続する空白は禁止。
* 代入および比較演算子の前後には必ず空白が必要。
* 演算子の左右の空白の量は等しくなければならない。
* 式の中の空白の数に変化がある場合には
演算子の優先順位を反映していなければならない。
つまり、"1*2 + 3*4" は大丈夫だが、 "1*2 + 3 * 4" は駄目。
しかし、推奨されるのは"1*2+3*4" である。
* コロンの前の空白は禁止。
* ディクショナリリテラルではコロンの直後に厳密に一つだけの空白。
スライスのコロンの直後の空白は禁止。
* ブロックの短縮形式 ("if x: y") は廃止。改行とインデントを使うこと。
というルールを導入する。
>>216 switchで50行超えてる時点でダメ
一ブロック30行以内。ブロック内に更にブロックを含む場合は、その行数を除いて30行以内。 Ex. any func { ...; // a { ...; // b } ...; // c } // b < 30, a + c < 30 更にネストの制限があればそこそこに抑えられるんジャマイカ。
>>220 その手のものを知ってれば218みたいなことを言いださないのは自明じゃない。
つまり218には全く情報工学的な知識がないってのは明らかなんだから
そのレベルに合わせてやんなよ。
30行とかいうアホみたいな制限つけても、
foo() {
...
return foo_2();
}
foo_2() {
...
return foo_3();
}
のようにtail callでカスケードして回避されたら本末転倒だね。
>>218 みたいな素人は口出すなよ。
ここで発言して良いのは少なくともコンピュータサイエンスの初歩を学んだ事がある人間だけだ。
コンピュータサイエンスとswitchの行数がなんで関係があるのかw
コンピュータサイエンスの初歩ってなにかな? 大学で情報処理関連の学科を修めること?
>>225 自分で考えて判断しろ。未熟だと思うなら来るな。
コンピュータサイエンス未修者どころか既知概がいるな
他人に押しつける最低条件を提示しておいて、自分で考えろって(w
コンピュータサイエンス関連の査読つき論文を一本でも書いたやつは素人では無いと判断しよう。
最近switch文なんか使わないな
つうか普通分岐が多くなったら保守性を考えて
ジャンプテーブルとか多態を使うとかするだろ
そういう意味じゃ
>>218 のいう事はわかるけど
コンピュータサイエンスの初歩ってなんだろうな
231 :
220 :2005/04/11(月) 02:28:07
>>230 たとえばバイトコードインタプリタだと、
case I_ADD:
stack[sp-2] = stack[sp-2] + stack[sp-1];
sp--;
break;
程度のcaseがずらずら並ぶことが多いわけよ。
こんなもん、ジャンプテーブル(関数ポインタのテーブル?)や多態を使って
書いたとして、何かいいことあるか?
Plaugerの「プログラミングの壺」でも、switch caseはサブルーチンが長くなっても
しょうがないケースとして挙げられていたと思う。
古い表現だが。 「情報的強度を持つ」と表現されるモジュール/関数かな
233 :
デフォルトの名無しさん :2005/04/24(日) 15:41:57
トレンドマイクロのウィルスバスターが原因のシステム障害。 これ、絶対に「バグが出にくい言語仕様」とかいうレベルで解決できるバグじゃないっしょ。 真相はわからないけど、 Windows SP2 のあるファイルをウィルスと誤検出して何度もアタックしてCPU使用率100% になってしまってるそうです。いつもは、「隔離に失敗しました」とか出るけどね。今回はなんでかね。 まともにテストやってれば絶対防げるたぐいの障害だったと思うんだが、 テストしてないとかってもう問題外だよね。( ´,_ゝ`)プッ
しかし代替しようにも物が某ノートンしかない現実
avast! や AVG でいいんじゃない。 ClamAV はマクロウィルスが弱いなぁ。
236 :
デフォルトの名無しさん :2005/04/29(金) 00:53:19
関数型言語はHowではなくWhatを書くというがまだまだHowを書いてるように思う。 ソートとかでも sort(array) { return x,x in permutation(array),all i in 0..array.length-2,x[i]<=x[i+1]; } みたいに書けないもんだろうか。もしこれでいけたらバグも減ると思うんだが。
>length-2 一目でバグの予感のするコードだな
239 :
デフォルトの名無しさん :2005/04/29(金) 09:01:26
バグが出にくくするには、一文字入力する毎にすべてをチェックする、強力なプロセッサがあればいいのでは
eclipseはそれに近くねーか。
242 :
デフォルトの名無しさん :2005/04/29(金) 10:00:18
ランダムに置き換えてソートされていたら終了するていうアルゴリズムどうかな 運がよければ一発でソートできるかも
バブルソートでも、運がよければソートする前にもうソートされてるかも
244 :
デフォルトの名無しさん :2005/04/29(金) 10:58:10
それは入力データに依存してるじゃない ランダムソート法では入力データには依存しないことが証明されている 「運」という概念をプログラミングに持ち込むというわけ 勝ち組のためのプログラミング手法ね
ワラタ
意外と笑い話でないかも 実用範囲で実現するはずはないが 並列にすべての入れ替えをやらせてみて 失敗したものは殺すという具合に
Prolog みたいな言語だと、そういうのが普通だったり。 実際に並列処理できるかどうかは別として。 だからパズルなんかに強い。
249 :
デフォルトの名無しさん :2005/04/30(土) 21:24:30
誰でも思いつくからといって 特許にならないというわけではない
誰も特許の話なんかしてないわけだが...。
>>242 発想が10年遅い
まあこれからは君もシャッフルソートの普及につとめるのだ
236のコードでコンパイラがソートだと認識できれば 最適化でクイックソートのコードを吐けるんじゃないかな。
253 :
デフォルトの名無しさん :2005/06/03(金) 22:59:50
ソートとか懐かしいな。クイックソートのアルゴリズムを、友人とあーでもないこーでもないと
言いながら考えてた頃が一番楽しかった。今では苦痛でしかないが。
んで、
>>242 の言うランダムソートって早い?速さの期待値ではバブルソートと同じに思うんだが。
そこまで速いわけねーし、つまらん。
>>248 >この世の果てて恋を唄う少女YU−NO
>このゲーム、並列世界を探索しているときは、2で書いたとおり高いストーリー性と
>ゲーム性を有した作りになっているのですが、目的の場所であるデラグランドではそう
>でもなくなります。ルート分岐はないですし、アイテムを使ってゲームを進展させていく ...
>homepage3.nifty.com/konbatto/yu-no.htm - 18k - キャッシュ - 関連ページ
何が言いたいのかわからん・・
エロゲヲタの普及活動はキニシナイ
236のまね。 だれか解読してくれ。 u(sequence<vertex> x) { return all i,j in x.index , i!=j { x[i]!=x[j]; } } l(graph g) { return { x in g.vertex.subsequence | u(x); x.length>=3; all i,i+1 in x.index { {x[i],x[i+1]} in g.edge; } {x[0],x[x.length-1]} in g.edge; } } is_t(graph g) { return l(g).length==0; }
258 :
257 :2005/06/07(火) 22:24:58
しまった。 一箇所プログラム間違ってた。 まあ、いいや。大筋はあってるし。
>>236 とか
>>257 みたいなのは、 Prolog 辺りでなら素直に書けると思うけど。
>>236 なんかは
ascending([]).
ascending([_|[]]).
ascending([H|T]) :- [S|_] = T, H =< S, ascending(T).
sort(List, Result) :-
permutation(List, Result), ascending(Result).
だいたいこんな感じで、ちゃんと動くし。
Prologのことは知らんがそれはO(nlogn)で動くわけ?
もちろん動かない。 順列作って一つずつチェックするんだから、 O(n!) とかじゃないかな。
ランダムソート法の話が出てるが量子コンピュータ使えば実現の可能性は無くも無いな まあ、要素4つまでですとか、激しく実装制限付きそうだが
263 :
デフォルトの名無しさん :2005/07/07(木) 09:11:57
バグ低減に関係あるかわからないけど ちょっと思ったことをチラシの裏。 ある float i は0.0〜∞までの値域を持ち、 1.0以上の値を入力されるとループして 必ず0.0〜1.0の間に収まるように処理される。 そしてこの float i を受け取る関数 void f( float i ) があるとする。 皆さんが f を設計する場合 i に大して何らかのチェックを設けるだろうか? もし自分なら、i が値域に収まるよう加工すると思う。 void f( float i ){ i = upper_loop( i, 1.0 ); ・・・ しかし、これだと f を呼び出す側がちゃんと値域に収めていた場合、 同じ処理を2度行うことになり無駄になってしまう。 i = upper_loop( i, 1.0 ); f( i ); この例以外にも、たとえばNULLチェックなど 当てはまるケースは少なくないように思う。 これを静的に回避出来るような仕様をもった言語は今存在するだろうか? 回避することは可能だろうか?
負けずにチラシの裏 「もし自分なら」のほうが正しい 0.0〜1.0の値域をもつ変数型を定義可能に 回避する事に意味があるとは思わない。 仕様明示すれば無駄なことする奴はいないだろうし、いたとしても呼ぶ側の問題
>>263 の言いたいことは判らんではないのだが、
>>264 はいっちょん判らん。
#まぁ、チラシの裏だからな。
>>262 4つまでじゃバブルソートでもよさげだな
現場からの声っぽく書いてみる。 Java の言語仕様はメモリーリーク系のバグが出にくいよ。 変に気を使ってメモリー管理するプレッシャーから開放された。 いま、変に気を使っているのはスレッド。 スレッド関係のバグ多いよ。めちゃくちゃ気を使う。 言語仕様のレベルでスレッド絡みのバグが出にくいものなんて できると嬉しいねぇ。
現場じゃなくたってみんな感じてることだよそれは。
スレッドを使ったプログラムを書いたことのないへたれなおれに どの辺が気を使うのか教えてクレ。
>>269 如何にまともな人間に書いてもらうかが、一番気を遣うと思われ。
#まさかへたれを自認しているのに自分で書く気を起こすわけじゃないよな?
最初はみんなへたくそ(≠へたれ)。
273 :
269 :2005/07/20(水) 21:02:43
デットロックて食事する哲学者とか? そんなのもう解決した問題かとおもてた。 現実はもっと複雑になるのかな?
>>273 スレッドを使ってプログラミングしてみると良い
って言うか、解決してる。
>>275 まずはお前の言う「解決してる」の定義を説明してみろ。
1.5使ってみればよい話なんじゃないの?
278 :
デフォルトの名無しさん :2005/07/23(土) 16:43:28
1.5とはなんじゃらほい
話の始まり(
>>267 )がJavaだからSDKのバージョンのことじゃない?
1.5でスレッドの何が改善されてデッドロックが起きなくなったのかは知らないけど
次期C++では const句,throw句の他に cpp句でcスタイルのプログラムを出来なくして欲しいね。
別に JDK5.0 (1.5) でも、スレッド周りの言語仕様は何も変わってないよ。
>>275 はいい加減なこと書いて釣りしてるだけじゃないのか?
>>263 性的に回避したいのなら、
f( float i ) {
assert( 0 <= i && i <= 1.0 );
}
でよいような。。。
284 :
デフォルトの名無しさん :2005/07/23(土) 23:16:48
>>283 assertではリリースビルドでは消えてしまうし
結局関数fに範囲外の値が渡されてしまう可能性が残ってしまう。
そういった「もし○○でなかったら〜」という受身の姿勢ではなく
「○○である保障をつける」というアプローチが出来れば、
より安全になるし、余計な処理も減るし、最適化も効きやすくなるんではないかと。
例えば、楕円体の物体と点との衝突判定する関数がある。
bool detect_collision_of_point_and_ellipsoid( const vector3& point, float_t radiusR, float_t radiusS, float_t radiusT)
{
assert( radiusR != 0.0f && radiusS != 0.0f && radiusT != 0.0f);
const float_t m = radiusR / radiusS;
const float_t n = radiusR / radiusT;
return point.x * point.x + m * m * point.y * point.y + n * n * point.z * point.z <= radiusR * radiusR;
}
radiusSとradiusTは除数になるのでゼロであってはならない。
半径がゼロでは楕円体として存在できないから、この制限は当然と言える。
だったら最初からradiusSとradiusTは、ゼロには絶対にならないという保障を付けてしまえばいいとか。
XMLってこれと似たような仕様を持っていたような・・
計算の度に0になって無いかチェック入れないとダメじゃん。
なんでいきなりXML。DbCを知らんのだろうか?
287 :
デフォルトの名無しさん :2005/07/24(日) 00:19:28
デバッガ上とかで、デッドロックそのものって検知できる? 「今こことここでデッドロックしてますねざまーみろ」と言ってくれるような デバッガってありますか?
COBOLでの話@JavaWorldだが、変数名を漢字に書くようにしたらしたらバグが1/3減ったらしい。 たしかに、ケアレスミスは減りそう。 案外日本語プログラムでまともなのがでたらいいのかも。
日本語で文章を書いても
>>288 のようなごくごく短い文ですらケアレスミスを含む
ようでは、その効果はあまり期待できなさそう。
290 :
デフォルトの名無しさん :2005/07/24(日) 08:13:02
PHPをはくホームページビルダーみたいなソフトが、オープンソースで開発されて、 大量のプラグインが供給されれば、最強じゃない?プログラムを書かなくていいんだし みんなプログラムをしなくていい、SEになろうぜ デスマからも開放で最強
>>289 連番を振っただけの変数名よりは遥かにマシだと思う。
一バイトかなだらけの糞ソースが誤変換だらけの糞ソースになるだけだろ。
>>291 連番を振るような人は日本語にしても連番振るんでない?
壱弐参四五六七八九拾
最終的にはリファクタリングするとして、最初のクラス図を書いてソースコードを 生成する部分には日本語が使えると便利だと思う。
普通に日本語も使えると思うのだが。 好むかどうかは兎も角、kaisuuなどとローマ字綴りをしてもいいし、 変換するスクリプトを一つ書いておくだけでもいいと思うぞ。
>>296 ん〜、て言うか、ぶっちゃけ、
>>295 を満たす様なEclipse用のプラグインが
欲しいんだよな。とか思ってたら普通に使えるし!>日本語
public class テストクラス {
private Vector メッセージリスト;
public テストクラス() {
メッセージリスト = new Vector();
}
}
こんなのを普通にコンパイルして実行可能だった( ゚д゚)ポカーン
普通に無理だと(Eclipseが文句言うだろうと)思って試してみた事もなかっ
たのが敗因か・・・・・・・・にしても、キモ!w
でも、やっぱ日本語は読みやすい。setメッセージ等というメソッドを見て
ると、やっぱ珍妙には感じるが・・・・・・
>>297 日本語、結構便利だぞ。
学生の頃、フルアセンブリ言語のソース書いたときは
全てラベルをS−JIS全角で記したよ。
マクロはアルファベットで書いて住み分けして。
英語だと先頭だけ大文字とか全部大文字とかして種類を区別できるけど 日本語シンボルだと難しいよね。何か妙案はあるかね。
>>285 先の例の目的はあくまで静的にゼロチェックすることだ。動的にやっては意味がない。
たとえば「( A - ( B / C ) ) * D」という式があるとする。この解がゼロになる条件は自明的に得ることができる。
・A と ( B / C )が同じ値
・Dがゼロ
以上の条件をいずれも満たさない場合、この式の解は非ゼロであると保障することができる。
しかし、全ての値が静的に決まる訳ではない。人間による入力やファイルからの読み込み、時間や乱数など
動的にしかわからないものもある。
しかしその場合も上のように方程式を解くことによって、「動的に入力される値がこの値ならばゼロになる」のような
例えるなら「危険な値」を特定することが出来る。
301 :
デフォルトの名無しさん :2005/07/25(月) 04:54:22
>>287 スレッドというのは手続き型言語の範疇を超えている。
その例は不適切だ。
自分的には、そもそもデットロックが起こる可能性のある手法を
なんとかデットロックが起こらないように組む、これがそもそも間違っているのではないかと思う。
例えば、今流行のGPUのShader言語は複数の処理が並列に実行されるがデットロックが起こることは
決してない。これが正しい並列プログラムのやり方だと思う。
>>300 それを行うにはすべての関数で逆関数を求める必要があるから
事実上不可能だな。
まぁ言語仕様自体をそれが可能な範囲に制約してしまうという
アプローチもあるが、機能的にかなり限定された言語になって
しまうだろう。
>>300 どうでもいいけどその例の場合、Cが0かどうかのチェックが先に来なくては意味がないね。
>>2 的を射てるな。
システムを構成するコードが減れば減るほど保守性は向上する。
これには無理矢理トリッキーな手法でソースコードを短くする行為は含めない。
究極は彼の言うようにコードを一行も書かずにシステムを構築することだ。
それで客の要求を満たせるのであればそれはすべての人が幸せになる解決策だ。
>>304 実務においてSEがその方針をとると、製作工数が発生しないので会社もSE自身も嬉しくない罠。
#更に市販ソフトのインストール作業と顧客へのチュートリアルをさせられる罠。
>>305 なるべくコードを書かずしてカスタマイズする方法を確立すればいい。
エンジニアリングに工数も発生するが低級な面倒なバグは減る。
高レベルなバグは比較的取りやすいわけで。
だからフレームワークや○○ツクール的なアプリケーションの開発というのは有用だと思う。
307 :
デフォルトの名無しさん :2005/07/29(金) 19:39:02
俺のクラスにも307みたいなのいるよ。
な ん だ こ れ は
310 :
770 :2005/07/29(金) 20:47:04
おれならMLでスマートに書くけどねw
311 :
デフォルトの名無しさん :2005/07/29(金) 22:49:23
おれならハスキルルでエレガントに書くけれどね
314 :
デフォルトの名無しさん :2005/10/05(水) 00:13:54
100人でペアプロしよう! もしくは、 1つの関数に3とおりの処理を記述し、すべてが一致しないと先に進めない処理系を作ろう。
315 :
デフォルトの名無しさん :2005/10/08(土) 22:55:36
>>1 ポインタを使いこなせない「自称『C』使い」を排斥するだけで
解決するのでは?
バグ出す奴=ポインタを使いこなせない奴 という考えが短絡的で愚か
>>316 誰もそんな事言ってないようですが。
何か受信しちゃいましたか?
悪い電波さ
319 :
デフォルトの名無しさん :2005/10/13(木) 19:50:50
は?
アルゴリズム単位で記述する言語
それって関数型言語・・
#私はいま、「車輪の再発明」を目撃したのだろうか?
標準出力に文字列しか出力することができない言語 子息演算や関数やクラスという概念も無い。 これでバグはでない!
仕様:「0l」を出力せよ。 実装:「O|」を出力。 ハイ、バグの出来上がり。
OCRで読み込めばOK
変数の値によって処理が分岐したり、繰り返しがあったり、いろんなことが出来るような 言語仕様だからバグがでるんだよ。その言語で出来ることを減らせばバグも経る。 例えば: 入力されたソースプログラムのバイト列のどこかに、一つでもビットが立っていれば、 68 65 6c 6c 6f 2c 20 77 6f 72 6c 64 0a という13バイトを出力し、 ビットが立っていなければ何もしない。という言語仕様。 これならバグは出にくい。
327 :
デフォルトの名無しさん :2005/10/15(土) 03:50:16
最近、「継承」に懐疑的で、インターフェースだけでなんとかならないだろうか、と考えてます。 少なくとも「再利用できるから継承する」とか、「親クラスの機能を置き換えるために継承する」 というのは動機として不純だと思う。 どのオブジェクト指向言語も Object を頂点とした系統樹を育ててきたけれど、 言語によってそれは全然バラバラ。Java,MFC,C#しかり。SmallTalkも全然違う。 それって、考えてみれば変な気がする。 どれもオブジェクト指向なのに、そのとっても大事な系統樹が全然違うなんて。 そもそも、オブジェクトを系統立てること自体が間違いじゃないだろうか? まず「クラス」よりも「インターフェース」が大事、と言うのは同意が得られるよね。 基本的にはインターフェースを中心に置いた設計がいいと思う。 継承の動機って何だろう? その動機を他の形で置き換えられれば、継承は必要なくなるはず。 util的な実装に置き換えられないだろうか? アスペクトの織り込みでできないだろうか?
>>2 には割合同意。ただプログラムが皆無になるということはなくて、
プログラムはできるだけコンパクトにして、できるだけデータに追い出すってのは
正しい方向性だと思う。
ただあれね。文字ベースのコードってのは「書いてあること以外は何もないよ」っていう
安心感はあるから、細かい仕様を気にする以上そういった特質は必要なものだと思う。
>>327 も通った道だなぁ。
依存関係を減らすことがプログラムの独立性を上げて、再利用しやすくする道なのに、
継承ってのは非常に密接な依存性を導入してしまう。
327が言うように、あまり「継承が基本」みたいな言語仕様はよろしくない気はする。
リスクの少ない包含(has a)+インタフェース継承なんかを簡単に書けるほうが良いかもしれない。
interface I {
hoge();
fuga();
};
class A : implements I {
hoge();
fuga();
};
class B : implements I {
A a : hoge, fuga for I; // インタフェースIのhoge,fugaはaに対応させる
};
アスペクト志向はまだ勉強してないなぁ。
>>327 だから継承とかインターフェースとかの技法は
「オブジェクト指向」とは何の関係もないんだよカスが
ま、オブジェクト指向はアセンブラでもできる作法論であって、継承とかはただの言語仕様だからな。
template じゃダメ?
333 :
329 :2005/10/16(日) 18:35:25
>>332 C++のだとすれば・・・
templateはもう1段階の複雑性を導入してる感じで、
バグが出にくい・・・とは相反する気がする。
うまく使えばバグ抑止に貢献するとはいえ、
ちょっと敷居(うまく使うために必要な知識レベル)が高すぎないか?
言語仕様的にバグが出にくいというからには、敷居は低めに設定する必要があると思うし。
敷居が高いかねぇ……
>>334 発想力のすばらしい人のコードを見るとたぶんそんな事は言わなくなると思う
336 :
デフォルトの名無しさん :2005/10/17(月) 01:09:36
言語かライブラリか? Javaはスレッドとかシリアライズとかを言語に取り入れていますよね? synchronizedとか、transientとかがJava構文にあるのが何よりの証拠です。 今までの言語では、それらはライブラリ側の仕事をでした。 一方、C#ではeventやdelegateも言語仕様に含まれています。 どちらがいいんでしょうね?
>>335 それはテンプレートに限らないと思うが。
338 :
デフォルトの名無しさん :2005/10/17(月) 02:02:39
a-zより記号が多いからキライ。>template
templateはエラーが意味不明ですさまじくデバッグしにくそうなんだが
templateベースの頭の逝かれたライブラリは バグ以前にコンパイルが通らねーからなぁ。 バグ防止にはそりゃいいかもな。
>>336 プログラムを書く上で基本的な構造に大きく影響する機能は
言語に取り込んでしまったほうがいいんじゃないかな。
文法上わかりやすく記述できる可能性が高まるし。
Schemeがいいよ 記述も簡単でバグで困ったことない
343 :
デフォルトの名無しさん :2005/10/17(月) 12:50:06
>>338 lispとか存在自体が我慢ならないでしょ?w
>>344 338じゃないが、正直LISPには我慢ならない。
再帰が人間に理解しやすいわけないじゃんか、と。
346 :
デフォルトの名無しさん :2005/10/17(月) 20:34:11
347 :
345 :2005/10/17(月) 21:27:04
>>346 もちろん再帰をやたら使ってあるコードは、俺にも理解しにくいよ。手続き的な書き方と比べるとね。
LISPのソースって、手続き的に書けるロジックでやたら再帰を使う傾向があるから、
そういう場面を指して言ってる。
とはいえ再帰が必要な場面も当然ある。
・・・とマジレスしてみた。
348 :
デフォルトの名無しさん :2005/10/17(月) 21:29:10
まあ、使う人間の頭の中がバグだらけならどんな言語で作ってもバグだらけになるな
LISPは演算子がない故に処理が手に取るようにわかるからなあ。 括弧に目をつぶれば全て同列に扱えるのは利点だな。 しかもC++テンプレート以上の記述能力を備えた超強力なマクロの存在がある。 まさに言語単体としては最強の開発ツールだろうな。
Perlで@{${$hashname}{${$keyname}}}とかするのが最凶
話はまずヴァルゲイン殿を作ってからだ。
ヴァルゲインは作る側の頭にバグがあっても自動的に訂正してくれる。
意味不明な単語を出して流れを止めないように・・・ どっかの小説かなんかのようだが
そりゃ、メフィストフェレスだって、ロボットだって、小説の中の話だよ。 ライトノベルだからってなめてんじゃねーぞ。
>>354 レスはぇぇよ
なめてないから、そんでどうすればバグの出にくい言語仕様になるんですか
つまり、どんな頭の悪い人間でも思った通りのことをできるようにしようと思ったら、 人工知能チックになっちゃうね、っていうありきたりの話だよ。
で、その人工知能の仕様は?
それを含めて、まだ研究途上だろうよ。
>>358 だから考えてくれよ。そういうスレなんだから。
人工知能って要はコンパイラ+インタプリタなんだろ?多少インテリジェントな。
人工知能は作るのが難しいからもう人力で良いよ
ゆとり教育弊害にあった職に就けないニート達を薄給でバイトとしてこき使えば 人工知能の代わりを果たしてくれるよ。
>>361 いや、まじでゆとり教育初期の失敗世代は使えないから無理
364 :
デフォルトの名無しさん :2005/10/21(金) 23:14:51
範囲チェックを文法に入れてしまうのはどうだろうか? 例えばこんな感じ。 var month: int(1..12); その変数にアクセスするたびに、範囲チェックが走る。 相当遅くなりそうだけれど、コンパイルオプションで無効にもできる。
365 :
デフォルトの名無しさん :2005/10/21(金) 23:22:15
ちなみに範囲外になると、java.lang.OutOfRangeExceptionが投げられます。 Javaではキャストやポインタチェック、配列の添え字のチェックをしているので、 範囲チェックをするのも悪くないかもしれない。
366 :
デフォルトの名無しさん :2005/10/21(金) 23:28:30
エクセル使えばいいんじゃね?
言語を知ってる知らないレベルの人間は、このスレではしばらくROMれ。
ん? 車輪の再発明を指摘しただけだが、なんか気に障ったか?
車輪の再発明というか、最近再注目され始めたDBCだろ。 このスレでもがいしゅつ。
Javaのアノテーションみたく制約条件を書ける様にすれば良いんじゃね? テストケースなんかもソースにぶち込めちゃうと良くない?
オブジェクト指向とか、エージェント指向とか言って、新たなBUGが目立って来たな。
覚えたつもり君たちが使ってますからね
>>371 > 車輪の再発明というか、最近再注目され始めたDBCだろ。
遥か昔からPascalに備わっている機能だと何度いt(ry
Del厨うざい
だから、範囲チェックじゃなくて制約条件がいいってば
380 :
デフォルトの名無しさん :2005/10/26(水) 14:12:11
UnitTest メソッドかクラスを付けないとコンパイル通っても実行できない
381 :
デフォルトの名無しさん :2005/10/26(水) 18:57:41
バグを生む主な原因 必要以上に分岐が多く複雑化し、作者の知能のレベルを超えた場合。 だれてもやりがちな例として、n要素nのm状態について場合分けして n行m列の行列で表される連立方程式並みに複雑化。 俺の解決策 状態をそれぞれクラス化し状態の視点から事象を考えると プログラムが簡素化する。 なおn,mが小さいときは無意味。
382 :
381 :2005/10/26(水) 20:34:48
Syntax Error wwww n要素n-->n要素 俺の実例として、通信とゲームが別スレッドで動作してるプログラムで、 サーバー通信関係を全て1つのクラスで処理していたの(10万行)を改修し、 ゲーム状態別にクラスを作ってそれぞれに通信イベント処理機能をもたせたところ 異常に簡素化した。(2万行)
381の知能レベルまで読んだ
設計方法論と言語仕様を混同している方がいますね
最長不倒関数 って言葉を思い出した
アンチパターン って言葉も思い出した
そもそも通信サーバプログラムに対して状態遷移を考慮した作りにしてない時点で糞
悪い習慣のプログラミングをしてると、「あ〜ま〜え〜は↑〜あ↓〜ほ↑〜か↓〜」って 言ってくれる言語がいいかもしれない
おじさま、もうおやすみになって…
391 :
デフォルトの名無しさん :2005/10/28(金) 10:45:05
プログラミング言語でバグが出易いのは、言語がとても繊細すぎるからだよ。 ほんの1文字間違えてもバグが出る。 もっと冗長でロバストな言語ならバグは少なくなるだろう。 実現したい仕様について、目的から書き始め、 目的については大目標から詳細項目まで、網羅しなければならない。 目的が記載し終わってから、方法 の記述に入るが
テキストで書くから綴りミスやらが出るんであって、図形を組み合わせてプログラムすれば良いじゃん
>>393 15角形を書くつもりが16角形を書いてしまうミスをするかもしれない。
RGB(0, 0, 0)とRGB(1, 1, 1)の区別ができません。
じゃあ匂いで
>>397 女の子の香りと秋葉系の臭いの区別は何とか付きます
鼻が詰まったらバグに気付かない罠。
そして華麗に400
バグ捜査犬を育成しよう
犬って目がいいの
直ぐに無臭のバグが開発されて元の木阿弥
prologでちゃんと動くコード書ければバグ率圧倒的に少なくなる気がする
>>404 波平とフネは夫婦、と書き忘れるかもしれない。
・・・Prolog=磯野家、というイメージが離れない・・・
従来: // someFunction()はnullを返すかもしれない関数 SomeClass instance = someFunction(); // nullかどうかをチェックする必要あり if (instance == null) throw new NullPointerException(); 新仕様:null を許すか,許さないかを区別する「null 拒絶識別子」 // クラス名に ! がついている場合,そのままではコンパイルエラー SomeClass! instance = someFunction(); // "(!null)" キャストの必要がある。 // 自動で null チェックをし,null が返ってくれば例外発生 SomeClass! instance = (!null) someFunction(); # (以上は「Curl」に備わっている機能です) // null を許さないので,自動でオブジェクトを生成 SomeClass! instance; SomeClass! instance(10, "string");
408 :
407続き :2005/11/12(土) 10:04:10
// 「消極的 null 拒絶修飾子」は,言語側で NullObject パターンをサポート class SomeClass extends BaseClass { /** NullObject コンストラクタ */ null() { super(); // BaseClass の NullObject コンストラクタ member_ = "(null)"; mayBeNull = null; // メンバは null を許容する } } // null が返ってきたら NullObject を得る SomeClass? instance = someFunction(); // キャストは不要だが,とりあえず推奨 SomeClass? instance = (?null) someFunction(); // 明示的な NullObject 取得 SomeClass? instance; SomeClass? instance = null; BaseClass? base = (SomeClass?) null; // NullObject は null と等しい if (instance == null) put("I'm a NullObject. " + instance.toString()); // "!" のクラスへは,キャスト不要 SomeClass! notNull = mayBeNullObject; // こんな事も可能 SomeClass! notNull = (?null) someFunction(); SomeClass! notNull = (?null) null; // 明示的に NullObject 取得 // null と比較するなら,こうする? if (notNull == (?null) null) put("I'm a NullObject.");
どうしたの?
いやー,javaとかにこんな機能があったらいいなーと思って。。。
でも、それってNullPo例外出れば初期化忘れだって一発で解る事が、 勝手に初期化される事で想定外の初期化が行われ複雑性が増さない? こういう機能をつけるならパラメータ付コンストラクタは排除すべきだと思うけど
なるほどー。なら new で明示的な初期化は必須ですかの。 SomeClass! instance; // コンパイルエラー SomeClass! instance = new SomeClass(); NullObject のヤシも,null 単体で初期化できるのはバグの元? SomeClass! instance = new null SomeClass(); BaseClass? base = new null SomeClass(); ↓これくらいは許せるかな。。。 SomeClass? instance = new null; 最近,仕事で NullObject パターンに出くわしたり Curl 使ったりで いろいろ考えさせられてます。 いっそ,こういう事を言語側の方で強制してくれればもっと楽なのかな,とか。。。
初期化以外の代入は書かないってことかな。 関数型言語方面だとNullとObjectのいずれか2値もしくは1つを強制できたりするけど。
414 :
デフォルトの名無しさん :2005/11/15(火) 22:56:15
バグの出にくい言語仕様といったらBASICでは?
まあ、インタプリタは支離滅裂な動作はしても、暴走まではしないからなw
>>416 ム板からさようなら。もう来なくていいです。
この前WinXPが暴走して、カラフルモザイクチカチカ画面が出現。 うあ、BASIC/DOS時代みたい、なつかスイー と、 しばらく見とれてしまたよ。
419 :
デフォルトの名無しさん :2005/11/17(木) 11:43:35
>>418 そういうのってハード側の問題って気がする
こんな言語ならバグ0。 Program ::= Expresstion* Expresstion ::= Program*
Expresstion……
ぬるぽを無くすには、静的にnull汚染を閉じこめる。 当然、初期化なしはコンパイルエラー。 nullを返し得る関数は他と区別して、その返値を受ける変数も他と区別。 nullチェックしてからでないと使えなくする。 clean( Object o, map.get#("hoge")) { //返値がnullでない場合。oに(非null)返値が入る。 } null { //返値がnullの場合。ここでoを使うとコンパイルエラー } Object o = map.get#("hoge") //clean文以外でnullが帰り得る関数を使うとコンパイルエラー
424 :
デフォルトの名無しさん :2005/11/18(金) 03:01:48
30行(文)以上のメソッド、30メソッド以上のクラスは、コンパルが通らない言語。
425 :
デフォルトの名無しさん :2005/11/18(金) 12:58:10
>>423 あんまりガチガチにするとそれを抜けようと訳ワカメのコード書く奴が出るから
変な実装なら素直にぬるぽが出たほうが良いと思うぞ
訳ワカメのコードをコンパイルすると、コンパイラが、 画面から殺人光線を出してコーダーを殺す言語。
とにかくコーダーを殺す言語。
428 :
デフォルトの名無しさん :2005/11/18(金) 13:27:32
Haskellつかえばだいたいおk。
>>428 Haskellだと糞コーダーを半殺しに出来たりするんですか???
糞コーダーが雲散霧消する
>>423 そんなメンドイことすると処理の流れが追えなくなるぞ。
null ポインタを経由したアクセスは確かにバグの温床
だけど、それを避けるために他のバグが増えるようでは
意味がない。
まだ、null を返そうとしたら例外発生することを強要
した方がましだと思う。
なぜ追えなくなる? nullが返り得るなら対処するのは当たり前だろ。 さらに、NullObjectパターンを支援する仕組みがあればばっちり。 >まだ、null を返そうとしたら例外発生することを強要 >した方がましだと思う。 そんなのどうやんだよ。 そもそも、動的じゃ大して意味ねぇだろ。
>>432 431じゃないけど
例外は、エラー状態を認知させ、プログラムの死という罰則を用いて
その状態を改めようとします。
すなわち、例外を捕捉しなければアプリケーションの停止という動作が
単純に保障されるわけですよ。
これは大して意味のないことですか?
動的にNullバグを捕まえることはtry catch使えば 今の言語仕様でも可能だから大して意味無いって言ってるんでしょ 実行前にNullバグを捕まえときたいって言ってるんじゃねーの?
Javaの仕様的にムリ そういった強制はhaskellとかの関数型言語が得意
全ての処理は結果を疑え。全ての処理は結果を返せ。 って事で、void 型の返り値の関数定義を抹殺!
結果のいらないvoid型はバグの原因にはならないでしょ 戻り値を使う必要無し=NULLポインタが発生しない なので、むしろバグ抑制に繋がる
void* 型の返り値を抹殺というなら話は分かる
>>438 戻り値をvoidにして、参照型引数で結果を貰うタイプの場合は?
>>432 From:
Mail: sage
----------------
>>432 > なぜ追えなくなる?
だから実際にコード書いてみなよ。
clean( Object o1, map.get#("hoge1")){
...
clean( Object o2, map.get#("hoge2")){
...
clean( Obejct o3, map.get#("hoge3")){
...
} null {
...
}
} null {
...
}
} null {
...
}
みやすいか?
特に問題なのは、null が帰ってくる時の多くはエラーの場
合だから、o1, o2, o3 で null が帰ってきた場合でもほ
とんど同じエラー処理書いたりすることがあるけど、対応し
にくいだろ?
>>432 > そんなのどうやんだよ。
コンパイラにポインタを返す関数の時は null チェックを
入れるように組み込めばいいだけの話。
> そもそも、動的じゃ大して意味ねぇだろ。
馬鹿かおまえ。
おまえのやつだって、所詮は動的に分岐するかないだろ?
要は、null の時を処理を必ず書くことを強要しているだ
けに過ぎない。
例外版で null に対する処理をきちんと書かせるなら、
catch() 節を書くのを強要すればいいだけの話。
443 :
デフォルトの名無しさん :2005/11/20(日) 01:47:16
それって、ぬるぽが出るのがちょっと早くなるだけじゃん。
バグの解決はちょっと早くなる事はあるかも知れないけど、
バグが出にくくはならない。
>>423 は、nullを返して良いメソッドでnullが返った場合の対処が強制される。
nullを返して良いメソッドはどうするんだ?null全面禁止か?
返すべき物がないという状況はどうしても存在すると思うが。
それに対して無理にNullObjectみたいのを返しても無駄だろ。
444 :
デフォルトの名無しさん :2005/11/20(日) 01:48:15
>>423 nullを許すかどうかを明示的に分けるのはいいアイディアですね。
ただ、文法的にはもう少し工夫がいるかも。
多分、constとかと同じようにmodifierみたいにするといいのでは?
例えば以下のような感じです。nullable が新しいキーワードです。
nullable File findFile(File path, String pattern) {
for (File f : path.listFiles()) {
if (match(f, pattern)) return f; // 見つかった
}
return null; // 見つからなかった
}
引数 path, patternはnull不可です。
戻り値はnull可です。だから return null も可能です。
また、nullableな変数をそうでない変数に代入することは可能だけれど、
その逆は不可になります。
>javaはC/C++からポインタをなくしたりGCを導入することで >メモリ管理にまつわるバグを出にくくした。 しかし、一方で参照が残っていつまでもFreeされないオブジェクトによる メモリ溢れという新たな問題が発生した。
446 :
デフォルトの名無しさん :2005/11/20(日) 01:54:24
あっ、最後のは逆ですね。
447 :
デフォルトの名無しさん :2005/11/20(日) 02:06:41
構文はこんな感じ? clean { receive( Object o1, map.get#("hoge1") ) { ... } ... receive( Object o2, map.get#("hoge2") : Obejct o3, map.get#("hoge3")){ ... } } null { ... }
>>444 その関数の戻り値を代入する型もnullableでなければならないわけだが、
そうするといつまで経ってもnullableでない変数に引き渡せないということにならないか?
nullable T を T にキャスト とかそんな感じのことができればいいんじゃね キャストできなければキャストエラーで
451 :
デフォルトの名無しさん :2005/11/20(日) 12:20:56
null完全廃止でいいべ。’null’つうリテラルも廃止。 返すモンがないことがあるメソッドは、 nullを返す代わりにNoReturnValue extends Throwableを投げる。
453 :
デフォルトの名無しさん :2005/11/20(日) 14:32:38
if (hoge == null) hoge = "hoge"; を hoge _= "hoge"; って書けるようにするといいと思う。
何の意味があるのか意味が分からん。
NPE防止のためにとりあえずなんか入れとくって事か? うわ、超危険人物発見、直ちに抹消せよ
NullPointerException 略して んぺ
まあ、零番地操作で例外処理を起こすハードウェアにしておけば問題無いだろ。
457は素人
assertion をサポートすりゃ平気のような気がするんだけどなぁ。 null 返すとか返さないとかも。 …… assert を書き忘れるとバグに繋がるが。
静的と動的の違いも解らんのか。 というかそれ以前に、強制と任意の区別も付かんのか。 ネタだと思いたい。
>>459 事前表明は実行時でしか機能しません。
ここではそういったことではなく、
どこかでnullを返すよう仕向けられるという時点で設計意図と反するわけで
値型やC++の参照のように原理上、実体=nullの状態がありえない保障が欲しい、
という話をしているように感じます。
言語仕様的な制約によって実行前に事前にエラーを検出する機構ということです。
そういったサポートを受けたい場合、現状としては高度な型機構を持つ関数型言語を使うか、
表現力が格段に貧弱ですが全てを値渡しで書くしかないでしょう。
462 :
デフォルトの名無しさん :2005/11/21(月) 10:59:05
>>461 nullブロックとnullableどっちの話をしてる?
nullableならまあありかな?と思うけど、nullブロックはちょっとって気がする
それならもっとブロックへnull代入チェックだけじゃない一般化された制約条件みたいなのを記述できる方が良い
>>462 たぶんどっちの話でもない気がする・・。
だから一般化したら、
>>452 みたいに非実行時例外だろ。
静的にチェックできる制約はそんなに浮かばないが。
452みたいな考え方はありだと思うけど 例外処理はオーバーヘッドが大きくなるからあまり使いたくない if文でNULLかNotNULLかの場合分けで済むなら例外を投げるまでも無く コンパイラが自動的に場合分けをすれば済む話だし
466 :
デフォルトの名無しさん :2005/11/21(月) 15:50:54
↓以下、静的にチェックできる制約を考えて列挙
467 :
459 :2005/11/21(月) 20:34:24
ぶっちゃけさ、静的にチェックできる 『データ型の制約』 って、つまり 『型』 なんだよな。 今ある assertion は動的チェックが多いけど、静的チェックに昇華する気になれば昇華できるのではないかと。 思った。思っただけ。
>>467 言ってることはまったくその通り。
どんなことができるのかは型を定義できる言語をひとつふたつ学んでみれば分かる。
例) Haskell, OCaml, SML
1文目はそうだが、2文目はただの妄想じゃないのか? 静的チェックに置き換えられるassertなんてどんだけあるんだよ。
>444のアイデアは面白いなーと思ったが Java のような言語に加えるのは大変だろうなと思った。 既存のコードが使えなくなるからね。。。 Java に加わるとすれば、nullable じゃなくて notnull みたいな逆の意味のキーワードになるじゃろか?
471 :
デフォルトの名無しさん :2005/11/23(水) 01:28:34
わざわざコンパイルが厳しくなる新しいキーワード用意しても そういうのがまさに必要なPG共が使うわけがねぇ。assert文すら使われてねぇだろ。
静的チェックに置き換えられるassertはけっこうあると思うぞ。 超がんがる処理系があったらだけど。 つかプログラマが脳内で静的チェックするからこそassertを書けるんだし。
つか実際に使われてんのは>451で出てるC#2.0だけなのか? # 他の関数型言語は自前でなんとでもできる、てか・・・ ちょと触ってみてぇ。 実際に触ってみれば、利点とか欠点とかも分かりそうなもんだ。
>>471 コンパイル条件を厳しくするキーワードを導入しても、だれも使わないというオチになりそうだから、
なにも修飾子をつけないと最も厳しいコンパイル条件となって、修飾子をつけていくことで制限を
外す、という設計思想じゃなきゃだめだな。
そうすると、制約だらけでウザいだけの言語になって、さらに既存の言語の拡張という形はとれなくなるが。
>>472 ← こいつは、動的・静的を全く解っていない。
現場のPGってやっぱこんなんばっかりか?
それとも、常識を覆すアイデアがあるなら披露汁
>>474 それをいったら、ただの静的型だってウザい。
LispとかJavaScriptとかPythonとか書いてると実感する。
コンピュータ側に指示を出す言語じゃなくてPGに指示を出す際にバグの出ない言語が欲しい
そういう言語があったとして、理解できる奴は読む側に回らないと思うぞ。
仕様書記述言語でもつくるか。 そうすると、仕様書記述言語からプログラミング言語へのトランスレータが開発されて、PG全員解雇。 しかし、仕様書ライタなる新たな職業が誕生し、仕様書デバッグなる工程が必要となる。
>>476 言語の問題ではなく、コンパイラのソフトウェアとしての問題。スレ違い
形式的仕様記述言語 の検索結果 約 22,800 件中 1 - 10 件目 (0.20 秒)
バグがあるからこそPGの飯の種が尽きない。
バグがでなくなったら別の仕事すればいいじゃん。バカ?
>>478 そうなったらその仕様書はソースと呼ばれる
静的なチェックの方が動的なチェックよりも好ましい というのはいまいち納得がいかない。 どうやら定説のようだがなんで?
静的チェックはコンパイル時に暴かれる。 動的チェックはそのチェックする箇所が実行されないとチェックされない。 たとえばコンパイルと実行で別のコンピュータを使うという事態が考えられる。
>>484 > 静的なチェックの方が動的なチェックよりも好ましい
どこの定説だ?
普通に考えて、静的チェックで全部チェックできればそ
れが一番だと思うが。
できねーから、併用するしかないんだろ。
>>483 そもそも、仕様書・コード・ドキュメント、この3種は含まれる情報量は本来過不足なく等しいはずで、
単にどの工程で誰が何の目的で作成するかの違いしかない。
要するに三重の無駄。
どれか1個にすべし。
わざわざ言われなくても、うちにはコードしかありません><
職業プログラマは大変ですねぇ。 僕は趣味でフリーウェア公開してる程度だからとても気軽ですよww
490 :
デフォルトの名無しさん :2005/11/24(木) 06:20:17
全ての型に文法的に範囲を指定できれば、数値がらみのバグはかなり減ると思うんだが。 型の宣言に値の範囲を強制するというのはどうだろう。 例えば0から100までの整数を型として定義したら内部で自動的に範囲チェックを掛けてくれる。 int(0-100) val; val=100; // これはOK val+=2; // これはNG もちろん、既存の言語(JavaやC++)でもこういうクラスを作ることは可能だが、手間や実行速度の関係で実際にやるところは少ない。 だが、言語仕様でそうなってれば抵抗無く使えると思うんだが。
>>490 pascal系なら、範囲型というのがあるよ。
部分範囲型の間違いだ Delphiだと こんな感じ var x,y:0..99; <----部分範囲型の変数を定義 begin x:=100; <----------コンパイル時エラー for x:=low(x) to High(x) do begin {$R+} <-------実行時範囲チェックを有効にすると y:=x+1; <------- 実行させるとこの行で例外が発生 Caption:=format('%d',[y]); end; end;
しかし、大抵は直値代入じゃなくて変数を介した処理中におかしくなるだろ。 結局実行時チェック。バグが出にくい、と言う意味じゃあんま意味なし。 バグったときの原因調査は早くなるだろうけど。
>>489 あー・・Vecterとかに登録してある10分で作れるようなプログラムね。いい加減うざいんだよね〜検索して引っかかると。
495 :
489 :2005/11/24(木) 18:05:11
>>494 趣味とはいえ、さすがにそんな簡単なのは公開してませんよw
こないだ作ったのはリバースコネクションに対応した遠隔操作ソフトと、プロセスマネージャから
隠蔽できるキーロガーです。もちろん、どっちも健全な利用しかできないようにしてありますw
その10分で出来るプログラムに、1ヶ月掛けて丁寧にバグをたっぷり仕込んで 客から金取るのがおまえね。
趣味と職業の違いは、プログラムとしての難易度じゃなくて、職業の場合、 自分が一生使わないプログラムを作るケースが多いってとこだな
趣味でPDA用のプログラムを作ったら、 自分が一生使う気の無い機能を要求されたり 入手困難な派生機対応要求されたり。 付き合いがあるし進んで実機デバッグしてくれたから作ったけど、 寧ろ仕事なら拒否もできたかせめて吹っかけることくらいできたのに……
>>498 オプソにして、自分で機能追加させれば解決。
ひょっとして500
501 :
デフォルトの名無しさん :2005/11/25(金) 18:02:47
>>493 でもたとえば、MAX100同士の掛け算なら左辺はMAX1万じゃないと
おかしいとか、オーバーフローの可能性があるとか、そういう警告は
だせたりしない?
それは言語仕様の問題ではなくなってしまうのだよ
神はこう言われた バグあれ するとバグがうまれた まで読んだ
それなら私は悪魔と共に歩もう。
>>502 そんなことはないだろ。
部分範囲型をもってる言語のちょっと賢い処理系なら、
そういうことをやることはたいして難しくない。
逆に、そういう型をもたない言語でやるのは基本的に無理。
ただ、そういう警告が有効かと言うと、かなりウザイと
思われて Off されるのがオチだと思う。
>>501 だからそれがコンパイル時に判定できるのは、実質直値同士の場合だけ。
あんま意味なし。
>>506 演算子に範囲型を適用すれば実行しないで値を保障できるよ。
int(0..100) operator *(int(0..100) left, int(0..100) right);
例えばこの演算子はかならずint(0..100)の値を返すことが保障される。
内部的に値をクリップするか、例外を投げるのかはその定義次第。
例外投げるってそりゃつまり動的チェックじゃん。 バグが出にくいんではなく、バグが分かりやすいだけじゃん。
つまり実行時にどうあれ、演算子*の返却型について引き続き int(0..100)という 範囲型が適用され、より限定的に型判定を続行できる。
それは解るけど、バグが出にくくなる訳じゃない。 俺は知らないけどPascalにあるの? で、他の言語が真似しないって事は、やっぱ…。
>>508 このメリットがわからなければそれでいいんじゃないの。
不要だって人は不要なんだろうし、別にわからないからって
今のところ馬鹿にされたりしないだろうしね。
>>510 Cみたいないい加減な言語に慣れてるから
部分型が扱えるとどういう利点があるかって事が、たぶん想像できないんだろうね。
関数型言語とか一部の強い型付け言語でしか使えないし。
型がきちんと一貫してチェックができる事に意味があるんじゃなくて、 ソフトのバグが減ることに意味がある。型は手段。 バグが早期に例外が出て分かりやすくなると言うメリットは認めるよ。 しかし、スレタイにはマッチしないだろ。
例えばクラスの継承ツリーも一種の部分型制御なんだけど、 一般的に広まってる言語ではそういう大雑把な視点でしか見えないから いきなり範囲型といわれても利点がぼやけてくるんだろう。
そんなに利点があるならもったいぶらず教えてくれよ。こっちは土方なんだから。 範囲内が保障されてるってのは、現実的な意味ではうそで、範囲外になったら例外になるだけでしょ。 「実行が継続されている場合は」という隠れた前提条件がある。 その前提条件を満たす事こそがバグを出さないということで、 それ自体をサポートしてくれないと意味がない。 解ってないけど、保障、というには、型が演算で本当に閉じていないといけないんじゃないか。 もちろん、整数に範囲を付けるというのじゃ、もともと無理な話。
>>515 LISP辺りで「見なす」という訓練をした後に強型付きのMLとかを学習すると
その辺が見えてくるんじゃないかと。
範囲というより集合という言い方の方が近い。
部分型と範囲外なら例外、の関係が解らん。 具体例キボン schemeをほんのちょっとだけやってるし、 Haskellのほんのほんのさわりだけなぞった事はある。
もしかして、 int も int(1...100)も同じコードで処理できる事自体が嬉しいと言うことか。 バグが出にくいというのとは関係ないように思うが。
例えばintも広い意味では範囲型、集合型の1つと言える。 インテルのIA32に対応したC言語処理系のint型が32bitなのはプロセッサのレジスタの 大きさなどの制限という現実からの反映というだけであり、 「intは32bitで表現できる値の集合を表現した型」と言い換えることができる。 shortなら16bit、charなら8bitの範囲。 これはプロセッサが「たまたま」これらの型を直接表現できるだけで、 もしもintの計算でオーバーフローしたら、ハードウェアがそれを 検出してくれたりするだけのこと。 これ以外の範囲の型があったとしても別に驚くことではないと考えられると思う。
>517 schemeわかるならSICPでも読んでみなよ
それはそうだね。 ただ、範囲を狭くしてオーバーフローしやすくして嬉しいとは思えない。 intじゃなくてchar使うのは、基本的に単にメモリ節約でしょ。
>>518 違うお。
型を限定できて嬉しい、ということだお。
和田先生の糞訳本を買うだけ買って読んでない…。 どの辺? 気合い入れてやっぱ読んでみるかな。
>>522 それは
>>515 >>521 で実利を否定してるんだけど…。
どう考えてもオーバーフローしやすくして嬉しいとは思えない。
schemeじゃ逆に32bit制限を外す方向だと思ってるけど。
だから数字というまとまりじゃなくて、それ1っこ1っこをみなきゃわからないお 範囲とかじゃなくて、奇数だけ集めた型とか欲しくなったときとか考えるお^^
なるほど。 (奇数に閉じてない)割り算を静的に禁止できれば嬉しいかも。 ただ現実には、奇数のような、演算の大半が閉じてるようなのが欲しい場面はほとんど無くて、 欲しいのは、演算で閉じようがない、業務やシステムの都合による制約が保障されてる物。 というのは、単にそれは手続きベースだからなのか? 制約はコードの外部に存在する以上、あまり関係ない気がする。
>>526 d楠。読んでみるっすよ。
…SICP見つからない。どこいったんだ。サイトで英語読むか…orz
まだこのスレに出てきてないみたいなので書いておくと、 バグを減少させる方法としては副作用をなくし、参照透過性を保つというやり方が既にある。 現実的には副作用を一切起こさないということはできないので、 副作用を別の概念としてモデル化し、そのコンテキスト上では 論理的に存在しないものと「見なす」技法が関数型言語で発達している。
>>529 それは多分メンドクサイのと実装時に無駄なコードが増えるような気が(直感で)する
その辺はどうなんだい?
ノイマン型思考をやめればいいんじゃないかな。 慣れだと思う。
532 :
デフォルトの名無しさん :2005/11/26(土) 11:23:55
もうnullについては File file = getFile() || new NullFile(); でいいよ。
そうするとNullObjectパターンは万能かという話になる。 そして、ダメな場合はどうするのか。
バグの出にくいことと abortしにくいこととは 全く違う概念だからなぁ
>>534 同意。その二つを混同しているレスがあったので念の為に同意しておく
つうか、ヒューマンエラーを無くすには、人以外がプログラミングに従事すれば良いと思うよ。
そりゃ人以外がやればいくらエラー出てもヒューマンエラーじゃないけどなw
バグをなくすには徹底したテストあるのみ。 レビューなんぞは糞の役にも立たないですよ。 (言語仕様と関係ないか)
構造上のBUGはテストなんか何万回繰り返しても無駄だったりするんだがな。
レビューで8〜9割のバグを摘出できるとか言うデータもあるようだがどうにも納得がいかん。 プログラムなんぞ眺めててもバグなんぞ一向に見えてこん。 プログラムなんぞ動かしてなんぼだろ。 みんなレビューやってる?
>レビューで8〜9割のバグを摘出できるとか言うデータもあるようだが 確か国際事務機会社の調査だったかな >みんなレビューやってる? そのような調査結果の有無とは無関係に、 そんな事を工数かけてやって、バグの発見が遅れたら誰も責任取れないからw やっているところは少数派では
やってるよ〜。 理解の足りてないコーダや詰めの甘いプログラマは自分のコードを説明させると それだけでぼろぼろバグ(及びその予備軍)を出してくれるし、 その間にそいつの書いたコードを読んでいると潜在的なバグが見えてきたりするし。 尤も、バグを潰すことより保守性を上げることの方が主たる目的なんだけどね。
レビューが意味ないなんて言う奴が居るなんて、マジで信じられん。 馬鹿が馬鹿なレビューしてたらそうなのかもしらんが、 レビューしないなんてあり得ない。
545 :
デフォルトの名無しさん :2005/11/28(月) 00:47:34
逆に天才ハッカーばかりでバグなんて元々ほとんどあり得ない、 という夢の世界もあるかもしれんが。
テストで出にくいバグ(=調査が大変なバグ)も見つけられるし、 テストだけだと、ただ「大体動く」だけで、 保守も拡張も出来ないゴミコードがリリースされうる。
少なくとも自己レビュー位はやるんじゃないのか? テストで見直しをちゃんとやりましょうとか小学校で言われただろ
548 :
デフォルトの名無しさん :2005/11/28(月) 01:51:33
引数自体は書き換え不可で 戻値をいっぱい返せるとか bool foo(int a, string & result) ↓ bool, string foo(int a) 凡ミスが結構減りそう
549 :
デフォルトの名無しさん :2005/11/28(月) 01:54:08
単純にリスト返すだけならPerlやRubyでもサポートしてるような。 Cだって構造体返す手があるしね。スタックに巨大オブジェクト作るのは感心しないが。
>>549 わかった風な口叩けばいいってもんじゃないよ。
参照透過性を維持するには重大な欠陥を同時に抱えることになる。
それに気づいてない馬鹿なんだろうけど、
今どきの言語のどこにそんな常識があるの?
>>550 単純データならどうとでもなるんだけどね。
構造的なデータを副作用なしで効率良く扱うのは先端の関数型言語でも
まだ課題の1つになっている。
関数型言語では特殊化や、修正が起こる部分について結合を弱くすること
によってコストを減らすなど、ある程度の言語のサポートが得られるが、
何の根拠も持たない言語では修正が発生するたび、適切に自力で
コンストラクトするしかない。配列みたいな特性のコンテナデータを修正する
場合は悪夢が待っている。
仕様そのものがバグでした・
顔を見ればどれくらいバグを出す奴かは推測がつく。
御自分よりもバグが少ない人もですか?
顔のバグが多い奴ほど、バグは出さない法則
557 :
549 :2005/11/30(水) 00:59:26
>>551 常識と書いたのは、参照透過が じゃなくて、
単なる多値返却なら という事なんだが。
…どうやってもそうは読めんな orz
プログラマ採用面接で顔だけで判断する香具師はありえんだろ
しかし、顔はあらゆる面接の類で重要視される。
560 :
デフォルトの名無しさん :2005/11/30(水) 11:00:35
顔というより話を聞いて日本語の会話が成立しない場合は採用しないな
話よりなにより顔だ。
顔より味だ
>>558 落とす理由が見た目だけで、誰が納得すると思う?
>>563 つまりありえんのだからお前の言ってることと同じだと思うが?
落とした理由をわざわざ説明する会社があるかボケ。納得も糞もない。 面接は顔が一番重要。これは常識。
ブサイクは性格悪いからな。 顔が歪むと心も歪む。
顔と言うより、顔つきや態度だな
>顔が歪むと心も歪む 逆
技術スレが、こういう下らんネタになると伸びるというのが、 ム板のレベルの低さを物語っているな。
>>569 みんなもう手持ちのネタが尽きたんだよ。
レベル低いっていうならおまいがネタ振れ。
整形するとバグが減るのか
確かにインデント整形するのは良いですね
574 :
573 :2005/12/02(金) 12:48:28
>>573 >ム板に技術スレ勃てる奴
…いや合ってるよ!阿呆は俺だろ!
575 :
デフォルトの名無しさん :2005/12/02(金) 13:13:11
逆、裏、対偶が判ってないやつ多すぎ
ド・モルガンの法則知らん香具師も大杉
久美子も大杉
大杉とレスする奴も(ry
ド モリガン (Morrigan) 【分類】 ケルト神話(Celtic mythology) 【解説】 カンムリ烏の姿で血を求め戦場を飛び回る、戦いの女神。 クー・フーリンに惚れるが、相手にされなかったことに腹を立て、 事ある毎に彼の戦いの邪魔をする。その後、命を助けられてからは 彼の味方をし、生き絶えたクー・フーリンの肩にとまった鳥も、彼女だったのだ。
相 手 に さ れ な か っ た こ と に 腹 を 立 て、 事 あ る 毎 に 彼 の 戦 い の 邪 魔 を す る 。 まるでおまえらにそっくりだな
神話レベルのツンデレか すげーなモリガン
ちょい、スレの進行も鈍っているようなので初カキコ ウチは機械化上がりだったんだけど、講義で品質管理についてこうならった 1.目的に合い、実行可能な使用の決定 2.使用目的に合うかの確認 3.製造中はいりうる不良要因の排除 4.安定不変の作業 5.製造から発送までの全行程の全員検査 6.納入後の情報収集とサービス 正直な話、コッチの業界ではみんな話が「1」の段階で止まっている。 頭の中で「動けばコード」みたいなところがあって 現場の中に品質って言うのは1〜6でまとまって作る者だって言う意識がない ・IT業界自体ゼンゼン若のはわかるし ・ソフトウェア開発も技術的に若い ・ソフトウェア自体は複雑だっていうのも分かる でも、ここのスレも思考の対象が「言語仕様」で話が止まっている節がある… 正直、良い品質を作ろうって意味では何処の行程であれ、効果があればよいのだから 少し発想を広げてみたらどうかな?
このスレで扱ってるバグは……『3』だけじゃないか? とくに1と2はバグじゃなくて仕様設計のミスだろう。
585 :
583 :2005/12/03(土) 00:04:12
うにゅ、適切な非難だと思う。 個人的には、バグについて広く話せたらその方がありがたいのもあるので、話の枕としては必要なものだと思ったのだ あと、少し具体的な話なんだけど、バグを上手に排除するには ・バグの入りにくい言語 ・注入してしまったバグを事前に発見しやすい言語 ・出てきたバグの原因を特定しやすい言語 は消せる者さえ消せれば基本的に等価なので考えるとき狭まらないで欲しい 釈迦に説法だった人も多数なんだろうけど 個人的には、現代の良いところは開発現場ではIDEもセットにして言語を考えるのが当たり前になりつつことなので IDEと仲良しになる事に糸口がありそうな気がするけど…。
少なくとも、自分の書いた日本語の間違いを放置するような香具師が書いたコードは信用ならんと言うことさね。
コードレビューはしてますか?
コードレビューしやすい言語はバグが発見しやすいか否か
>>853 まあ、結局のところ営業がいくらで握ってきたかで品質なんて物は決まるからな
本質的に作る事が出来ない金額で物を作れと言われる場合が殆どだから、
どこを端折るかというと顧客への納品時にばれない品質から端折る
>>591 お前今時中の人とか言ってんじゃねぇ。ズレてんだよ。
ツンデレももう古いっての。
そんじゃデレツン 交際中はデレデレなんだけど結婚した途端ツンツン
夫に言えない結婚してから機嫌を損ねる理由ベスト3 1.トイレで用を足すときに便器を汚す(特に小便) 2.紙がなくなっても自分で交換しない 3.ゴミを溜める
>>596 俺はそのすべての問題をクリアしているからいい男
コードレビューのコストを減らして、コードレビューを支援すると言う意味で、 可読性を残した上で、コード(ステップ数)が短くて済む言語というのは、 重要なのでは。 保守コストも下がるし。 いまだにLOCで仕事を計る馬鹿な会社が敵だが。(うちだ…orz)
ステップ数が短くてすむというのはライブラリを充実させるということ?
ライブラリに動作実績がなければ意味ない
>>599 LISPやPrologだとCOBOLの五分の一くらいの
ステップ数になるといった意味では。
ただライブラリを増やすだけじゃなくて テンプレートやMix-Inのようなパラメタライズ。
仕様にバグが無い様にするのが重要
604 :
デフォルトの名無しさん :2005/12/11(日) 10:34:51
○Perl5.8.7(OS依存除くルートにあった.cと.hだけ) $ wc *.h|grep total 37441 149383 1244389 total $ wc *.c|grep total 103778 339711 2659553 total 計 約140Kstep ○Pugs6.2.10(src以下すべて) $ find src -type f -exec cat {} >> /tmp/all \; $ wc /tmp/all 71040 315200 2213460 /tmp/all 計 約71Kstep ■ 結論 Haskell >>>>>>>>>>>>>> C
>>601 バグの出にくい言語仕様という観点からいえば
LISPやPrologのライブラリを育ててこなかったのは
ソフトウェア界の怠慢。
東証のシステムは結局何で書かれていたんでしょうか COBOLで書かれていたのを最近Javaでリプレースしたとか
607 :
601 :2005/12/12(月) 09:13:45
>>605 言語もシステムのライフサイクル通しての総コストの
少ないものが選択されていると考えるべき。
画像処理が必須のWINDOW環境ではこれらの言語が選択
されなかったのも仕方がない。
再び、人工知能技術の応用という方向に焦点が移れば、
変わってくるのでは。
画像処理……俺の知っている画像処理とは違うようだ。
あなたの知ってる画像処理も困難だと思いますが
611 :
デフォルトの名無しさん :2005/12/12(月) 13:17:15
>>606 COBOL+Cに決まってる
UIに関しては一部Java(Web)も混じってるかも試練
612 :
デフォルトの名無しさん :2005/12/12(月) 13:25:06
>>606 あそこはシステム一本でマッコウ勝負してる
世界でも特有のドケチ取引所と聞いたが
言語の問題じゃない。
Prologの場合、オブジェクト指向との相性が どうなんだろうね。そういう枠組み全くなしでは 今後やっていかれないと思うが。
Prolog にバグという概念は成立しない
ビットマップを操作するようなプログラムでは
一々TrailStackにpush,popするPrologはとても
採用できない。そういう意味で汎用言語ではない。
ただ、バグの寡多という点では優位であることは
間違いない。言語仕様という観点からはこれ以上の
ものを想定することは難しいと言ってもよい。
やはり、上位層にProlog、下位層にC++というような
切り分けで業務プログラムは開発されるべきだった。
現在のPrologが
>>613 の問題も含めて、こういう期待に
応えられるかどうかかなり疑問だが・・・。
そこでProlog++
いやObjective-Prolog
>>615 > 言語仕様という観点からはこれ以上の
> ものを想定することは難しいと言ってもよい。
Prologは頭部にたかだか1つの述語しか書けない。
しかし複数の述語が書ける言語が研究レベルでは存在している。
実用化したらPrologは過去の遺物になる。
620 :
デフォルトの名無しさん :2005/12/14(水) 06:58:18
もっと国家ぐるみでMLにちからいれればいいじゃん。 国に収めるソフトはすべてMLでかかせりゃいいんだよ。
621 :
デフォルトの名無しさん :2005/12/14(水) 09:22:57
>>618 20年以上前に、東北大の野口教授の下でそういう研究が
されていた。計算量が膨大になるんじゃないかってことで
あまり相手にしなかったのだが、何か、画期的な転回でも
あったのだろうか。
622 :
デフォルトの名無しさん :2005/12/14(水) 12:52:06
Σ
623 :
デフォルトの名無しさん :2005/12/15(木) 23:46:40
いまさらPrologかよ。メニーコアに向けてKL1だろ
メニーコアか。 シングルスレッドでもバグが絶えないというのに 厄介な時代になったものだ。
625 :
デフォルトの名無しさん :2005/12/16(金) 04:16:36
言語で作るからおかしくなるのではないか? これからは 絵で作った方が直感的に分かっていいのではないか?
>>623 「バグの出にくい」だけに拘ればの話です。
>>625 NTTのオープンハウスだっけ・・あれで図形言語がどうのこうのっていうポスター発表しているやつがいて、
質問に答えられないでオドオドしていたのを思い出した。
多分、ビジュアルプログラミングだと思う 日本は結構研究盛んな国らしいけど、本とかいっこうに見かけないんだよね 以前どこかの本で「ビジュアルプログラミングの本を書いてくれないか」 と依頼されたんだけど「使い物になるか専門家の間でもはっきりしていない」ということで、ユーザーインターフェイス全般の話をしていた本があった。 図形化すると全体が良く見渡せるって言うのは大賛成なんだけど 数万行のコードをフローチャートに書き換えた場合、どんな恐ろしいことになるかなんて言うのは、火を見るより明らかなわけで 図形にするならするで、後々コードが巨大化しても見やすいようにする工夫は必要だよね
630 :
デフォルトの名無しさん :2005/12/17(土) 00:15:39
ヴィジュアルだとなんでバグが減るん? つか、MDAとか関係あるん?
つまり図形や色などの視覚的要素を追加することで 幼稚園児並の知能があればレゴブロックで何かをこしらえるように プログラミングできる。 あるいはPCのパーツをかき集めて自作パソコンを組み立てる様なもの。 規格化された部品を組み合わせるだけでプログラムが完成する。 CUIに対するGUI、すなわちコマンドを叩くよりアイコンをダブルクリックする ことが好まれるように、名前だけでなくイメージ化することで、 より直感的に脳へ働きかける。
まぢで図形化がよくみわたせるとおもってるんでつか? その前に、#define文使うのやめてくれ。
たしかにCUIよりGUIの方がよくみわたせるね。 UNIX文化はさっさと滅んでください。
>>633 単位時間にキーボードから入力できる情報量と
用意されたICONの包含する情報量の比較だが、
どんなものか。
バッチファイルなら実用的な範囲でGUI化できそう
iconが姉歯化していないかの検証も必要。
この流れだと、LabViewできる香具師は神? ドキュメント性が悪いし保守を考えると紙屑なんだけど。
638 :
218 :2005/12/17(土) 22:36:14
>ヴィジュアルだとなんでバグが減るん? だね、基本的に「保守性が高いコードを期待できる」の方の話になってしまう スレの主旨とズレている気がするね。 まぁ、話題が停滞しているので話を広げるのも悪いとは思わないが… >まぢで図形化がよくみわたせるとおもってるんでつか? 君がUMLは全く役に立たないと思っているなら、図形化は無意味と言うことなんだろうね >単位時間にキーボードから入力できる情報量と、用意されたICONの包含する情報量の比較 俺はもう、文字を表示するのに「system.put.println」とか仰々しく18タイプもしたくないんだ! 言語が偏ってる?ゴメソorz まぁ、Wordとかと違って「コーディング」だけできるUIなら ショートカット周りの工夫で、解決できるんジャマイカ
MAX/MSPもビジュアル言語の範疇かな? 確かに想定外のバグは出にくい気がする。 やれることが限られているからってのもあるけど。
やれることが限られているのは日帝が人材を奪ったから。
>>638 その言語は補完が提供されるIDEがあるわけで、偏ってるのはお前の脳味噌かと
言語が文字の変わりに図形を使用しても、バグが減る理由がない。 見渡しなら、テキストからの変換ツールがあればいい。 プログラミングの裾野を広げるには役立つが、 入力まで図形なんて、まともなプログラミングには生産性低すぎ。 昔だが、Mindstormでプログラミング環境が図形言語だったが、 気の利いた作品はみんなそんな環境は潰して普通にC++でコーディングされたものだった。
漏れもプログラムはソースだけで充分だと思う FlashのActionScriptとかが典型的な例だ
↑使いにくいっていう例ね
645 :
デフォルトの名無しさん :2005/12/18(日) 04:14:56
UMLって図形っぽいよな・・・。
まあ、UMLじゃ動作保障無いけどな
MDAだって、結局UMLだけしょうもなくてテキスト言語併用だろ。
648 :
デフォルトの名無しさん :2005/12/19(月) 04:41:18
全部を図形にする必要はないんじゃない? レベルによって変えればいいと思う。
図形的に編集できる言語じゃなくて、コンパイル時に図形情報としてロジックを出力できる言語ならいいんでは? ロジックの確認にだけ、図形情報を用いる。
点(命令)を羅列していくんじゃなくて、ワイアドロジックみたいな 感じでスレッドを線で表現して、それにフローチャートのように 分岐、繰り返しがくっついたようなものってないのかな。 線と線の間にはボックスがあって、それを突っつくと手続き型言語のような 命令文が入ってる。
あるよ めちゃくちゃ開発効率悪いよ
652 :
デフォルトの名無しさん :2005/12/20(火) 11:04:43
業務はマルチスレッドなのに顧客の頭のなかがシングルスレッドだったりする
いまさらだがとりあえず言っとく
>>625 なあに、かえって免疫力がつく。
ビジネスロジック系のバグ潰しは厳しいなぁ。 大抵のバグはこの辺に仕込まれるんだよなぁ… 仕様、設計とコードの食い違いというかなんというか。 あくまで「プログラム」の範疇でいうなら、 モジュール又はメソッドの入出力の完全検査以外にあるまい。 配列とか配列のようなクラスの中身の型を制限するのは C++ではテンプレ、Java5ではGenericsで実現済み( ArrayList<String> )だから、 次はサイズの制限も簡単に書けるように… たとえば ArrayList<String>[0<][1000>=] とか書けるようにして、 それ以上のサイズの配列が渡される可能性がある呼び出し部分はエラーにしちまうとか。 そうすることでありえない値が入力されて発生するようなバグは減ると思うんだが…
>>654 std::vectorのat()でできますが。
#operator[]()を使われると制限できないが、そもそもvectorを使ってくれる保証もない。
>>651 そこまでは知っているんだけど、実際に触って確かめられないんだよねぇ
誰か窓環境で動くモノとかあったら、配っているところ知らない?
657 :
デフォルトの名無しさん :2005/12/20(火) 15:35:27
>>656 Fの運用監視ツールの運用設計画面なんかどうだ
658 :
デフォルトの名無しさん :2005/12/21(水) 00:00:20
バグを無くすには分岐とループを無くすのが効果的だよ つまりエクセル最強
659 :
デフォルトの名無しさん :2005/12/21(水) 00:25:49
平面図形だからいけないんだ。これからの時代は立体だ。 で、3Dに見える眼鏡かけてデータグローブで立体になってる オブジェクトを鷲掴みにして積み上げる。穴開けてねじ止め。 コンクリ固めて鉄筋を通す。 でも耐震強度偽装されて震度5で倒壊。
660 :
デフォルトの名無しさん :2005/12/21(水) 07:57:21
構造化プログラミングなんてキッシュイーターがやることだね。 本物のプログラマはgoto文を恐れずに使う。
661 :
デフォルトの名無しさん :2005/12/21(水) 11:39:07
>>658 エクセルは分岐できるじゃん、ループは怒るけど
キッシュおいしいよね
日本人じゃねーからナァ キッシュなんてよー食わねーよな
本物のプログラマって、あれ、ただの時代遅れだろ。 古き良き、っていう郷愁なのかも知れないが。
>>664 あれは
Fortran -> C++
アセンブラ -> C
Pascal -> Java
と置き換えれば今でも通用するw
ソフトウェアの専門職に就くためには資格試験を通らなければなれないようにすべきだ
禿銅
金が絡むくだらない連中が反対しなければ良かったんだ。
>>667 その資格、毎年更新を義務化とかじゃなきゃすぐに意味なくなるぞ。
C#とJavaのどっちを試験問題に採用するかでMicrosoftとSunがモメたりするわけですね。
>>661 確かに分岐はできるけど、影響範囲は通常そのセルの中だけだと
思うから、非常に限定的だよ。
>>671 特定の言語を覚えているかどうかなんて問題外。
まぁ、試験用の独自言語を作ればどこも文句は言わないだろう。
>>673 現実的でない試験課題がでる意味の無い資格だとか文句が出ると思うが。
そこでLISPですよ
>>674 現実的でない??
貴方の頭は一つの言語しか理解できないようにできているんですか?
現実って何ですか?言語の試験は別でしょう。
場合によれば、毎回問題用紙に疑似言語の説明が書いてあって、ある種の問題はそれを参考にして解答するようにすればいいな。
678 :
デフォルトの名無しさん :2005/12/21(水) 23:24:19
679 :
デフォルトの名無しさん :2005/12/21(水) 23:54:02
そういう部分はGC走らないようにコードを組むべきでは?
682 :
デフォルトの名無しさん :2005/12/22(木) 03:39:56
>>678 Javaってそんなに長々と止まる時あるか?
別スレッドでGCは動きっ放しだから、中々止まらないのでは?
683 :
デフォルトの名無しさん :2005/12/22(木) 06:57:31
684 :
デフォルトの名無しさん :2005/12/22(木) 06:58:49
今時GCでギャーギャー言うヤツは素人
GCログ見てみろ。 一瞬で終わってる。 まれに起きるFULL GCだけ、数秒かかってるけど。 つーかFULL GCってメモリがかなり圧迫されてない限り、ヒマな時しか起きないし。
687 :
デフォルトの名無しさん :2005/12/22(木) 15:43:21
スマートポインタ使えばGCいらなくない?
スマートポインタを用いた、参照カウンタ式ガーベジコレクションは 循環参照の問題と、実行スピードの問題がある。 参照カウンタのコストは結構高くつく。特にマルチスレッド環境では。 トータルの処理コストは他のガーベジコレクションに負ける。
689 :
デフォルトの名無しさん :2005/12/22(木) 22:06:43
速度有線の代表の一つといえる様なゲーム開発で、D言語が噂されているように 一定以上大規模なら、バグに悩まされるよりGCに頼った方が良いのが今の時代だよね 正直、後の時代、新しい言語がGC持たないというのはないんじゃないのかな。 汎用言語ならなおさら
>>683 どっちでもいいじゃん。
慣用的にアセンブラで通るんだから。
あと、「アセンブリ」っていうんなら、なぜ「アセンブリ言語」と言わないのか不思議なんだよ。
……俺、普通に使ってる気がするんだが。
692 :
デフォルトの名無しさん :2005/12/22(木) 23:30:54
アセンブリ言語と言わなかったのは私の落ち度だが、 アセンブラで書けよ コンパイラで書けよ 違和感あるだろ?
JIS用語では「アセンブラ言語」だったな確か。
コンパイラ言語
実際に書ける香具師なら読み方なんか気にしないぞ
696 :
デフォルトの名無しさん :2005/12/23(金) 08:15:14
「コンパイラ」は直訳すると「翻訳者」なので、アセンブリ言語で 書かれたソースから機械語に変換するアセンブラもコンパイラだと 言える。
アセンブラはニモニックと機械語を一対一で置き換えてるだけ ソースを翻訳している訳ではないのでコンパイラと呼ぶのは不適切
単なる翻訳でなく、意訳するのがコンパイラの仕事。 その意訳のためにかえってバグが生じることも稀にあるが、多くの場合恩恵の方が大きい。
699 :
デフォルトの名無しさん :2005/12/23(金) 08:27:58
T図式だとどっちも同じ。
>>698 アセンブラは「単なる翻訳」ですらない。
assembling language = 記号言語 assembler language = アセンブラ言語
確かに、文字列置換を翻訳と考えるのは無理があったな。
com・pile ━━ vt. 資料を集める; 編集[編成]する; おまえら、知ったか辞めとけって。翻訳て…こんなん高校英語だろw
中卒が辞書の一行目だけ引っ張って知ったかしてるwww 【動-5】《コ》コンパイルする、機械語に翻訳する◆コンパイラー言語(機械コードと一対一に対応しない言語、使いやすい言語)の翻訳。アセンブラ言語(機械コードと一対一に対応する言語、コンピュータ技術者向きの言語)の翻訳はassemble。
ついでに言うとcompileを翻訳としておくとinterpretは通訳の意味だから 人にコンパイラとインタプリタの違いを説明するときに都合がよい。
まあ、こんぴゅーたーの分野でコンパイラっつったら 翻訳と翻訳してまず間違いないわな
OSを基本ソフト、ソースコードを設計図と言い張るくらい微妙だけどな
IBM用語
鍵盤
作譜言語で算帖に算譜を記述して、翻訳系に掛ける。
711 :
デフォルトの名無しさん :2005/12/25(日) 02:59:57
えっと、ゴメン。このスレ終わるかのごとくつまらないこと閃いちゃったんだけど
バグとは「プログラマの意図しない動作をする」ことだから、その原因は
・文法ミスで、意図しない動作を組み込んでしまう
・ライブラリの知識不足で、意図しない動作を組み込んでしまう
なんかの、ヒューマンエラーという事になるんだよね…。
まさしく、プログラミングというのはバグを入れ込む作業ということだよなぁ…
で、話の続きなんだけど。
「バグを入れにくい言語使用」なら、上の単純なミスを減らす言語を考えることなんだよね
>>62 とかも言っているけど。っていうか、2chのお約束でスレの1-100の間で基本的なことなら大体出ている気が…。
まず、バグを定義しろ。
>>704 その辞書いますぐ棄てた方がいいぞ
コンパイラ=使いやすい言語
www
アセンブラ=コンピュータ技術者向きの言語
禿藁
>>711 そういう視点で観れば Python なんかは果てしなくバグを産みやすいな
715 :
711 :2005/12/25(日) 06:11:12
自分Python歴3日なので、特に興味本位で、その実例上げて欲しい 多分、Python人口自体も少ないので、Pythonで頻出するバグも良くリストアップされていないと思うし
pythonはお約束をみんなが守ることでその辺を解決しようとしてる。 Perlの方が歴史が長い分やばいんじゃね?
717 :
デフォルトの名無しさん :2005/12/25(日) 09:15:21
このスレタイに関していうとD言語とかいい線いってるとおもうね
自分にとっては「Cの設計者が不可能か不可能に近いほど困難と判断したテーマ」 を延々と話している様にしか見えないのだけれど
バグを定義しないと話が進まないな
定義厨うざい。 バグがどんなものかなんてなんとなくわかんだろ。
723 :
デフォルトの名無しさん :2005/12/25(日) 20:33:31
そうか?部分の仕様が既に問題を抱えてる類のバグがあまり語られてないように思うが。 そしておうおうにして、この手のが一番厄介。
724 :
デフォルトの名無しさん :2005/12/25(日) 20:37:16
>>717 D言語にこのスレのどんな機能が盛り込まれてる?
華麗にスルーできない機能
726 :
デフォルトの名無しさん :2005/12/26(月) 10:30:28
>>721 なんとなくじゃダメなんだよ
最近の建築偽装問題にも通じるところがあるが、曖昧なところが多ければ多いほど不正を見逃す原因になる
>>721 おまえがダメな方の人間だということはよくわかった
>>724 表明はCにもあるけど契約プログラミングはDから
>>723 その辺はもう少し上級レベルのモデリングとかでなんとかするんじゃないの?
言語仕様によってどこまでカバー出来るかな。
733 :
デフォルトの名無しさん :2005/12/28(水) 00:36:48
バグの定義は一応「作成者の意図しない動作をする」でいいんじゃないのかな?
適当に広いし…
>>723 例えば
・if(a==0)と書くつもりがif(a=0)と書く
・引数のスペルをタイプミス
とか、超有名な類かな…
テクニック的にはif(0==a)と書くのが常套手段だけど
正直な話、if文の条件式中じゃ代入は禁止したほうがいいかも
最近の言語じゃたいていそうなってない? 条件式の型がboolじゃないとエラー
735 :
デフォルトの名無しさん :2005/12/28(水) 01:47:01
>>733 コードが、そのコードを作成した者の意図しない動作をする、ということか?
でも、そんなのって、通常ほとんどなくないか?
コードから呼び出してる先の動作が理解と違ってたり、
もともと意図に入ってない条件が実は存在したり、
もともとの意図が間違ってる、とかがほとんどだけど。
動的言語だと違うのかな?
あるいは読み返しとかしないのかな?
仕事のコーディングで読み返ししないなんて俺には考えられないけど。
>>735 通常はほとんどないから虫であって、ワサワサ湧いてきたら怖いぜ。
まあ、概ねバグってるときはそうなんだけれども。
言語のほうでやれるのは「バカ避け(という語が嫌いな方は
フール・プルーフで)」しかないだろう。
つまりウッカリミスをつぶすGCであったり、
戻り値返すべきところを返さなきゃゴルァするとか、
ぬるぽってたら例外投げて沈めるとか、ガッとか。
GCはメモリ開放しなくていいから楽、みたいな認識しかほとんどされてないのが不幸。
738 :
デフォルトの名無しさん :2005/12/28(水) 03:46:57
まず人間にバグがあり、それがプログラムに転写されているのだ。 よってバグのないプログラムを作りたいのならまず人間をデバッグ する必要がある。
しかし、あまりアイデアを盛り込まない禁欲的な 言語仕様というのはあるだろう。
Pascalとか? あれはコンパイラ側の都合で手抜き仕様で作られてるからな。 書きにくくて仕方ない。
741 :
デフォルトの名無しさん :2005/12/28(水) 17:28:36
簡潔という意味ならschemeに並ぶモノが思いつかないかな 例え機能を増やしても、バグが出ない様に、出ても分かる様にするのが今の時代の流れだから、長いものには巻かれて構わないと思うよ。 というか、そうでもしないともう現場をのりきれないでしょう…
「何でもできるよ」的言語はもう10年以上も昔にダメだしされてるじゃん。
なんでも出来る言語=アセンブラ/機械語
確かに、何も出来ない言語にBUGの入る余地は無い罠w
遅レスだが、not nullはAda(2005)にあるぞ
せっかくNULL返してるのに、判定しないでアクセスしようとするからダメなんだよ。 言語仕様以前のコーディングの問題だからなぁ・・・。
バカかお前。お前はなんでもかんでもコーディングの所為にしてろ。もうくんなアホ。
ここってネタスレじゃなかったの?
ということは、not nullがあるのはC#2.0とAda(2005)だけか。 実用されているとは言い難いな。 >436見て「あ、いいな」とか思ったけど、実務で使うのはもう少し後にするか。。。
753 :
デフォルトの名無しさん :2005/12/31(土) 18:10:25
だからMLとかで書けばいいじゃん。
>752 ん?Curlにもnot nullがあるって事かな? >407に書いてある事がよく分からん。。。 >753 言語を選べれば苦労しないさ。。。
>754 >言語を選べれば苦労しないさ。。。 じゃあこんなとこ来るなよw
すばらしい言語ができて、それが一般的になれば使える可能性あがるし
757 :
739 :2006/01/01(日) 00:27:32
>>740 亀レスというか、年が明けてしまった。おめでとうございます。
MLを念頭に置いていました。Pascalというと参照型を採用した
ことが物議を醸した時代ですね。
バグは作法でしか対応できないとは思いません。
>>751 C#2.0にnot nullなんてあったっけ?Nullableならあるけど
ポインタ廃止しても、ヘッダファイル廃止しても、バグが減るどころか増えてるじゃん
C#のNullable…本来nullが格納できない型がnullを格納できるようにする Adaのnot null…本来nullが格納できる型からnullを禁止する ちょっとちゃうな。確かに。
762 :
デフォルトの名無しさん :2006/01/07(土) 02:47:27
> 本来nullが格納できる型からnullを禁止する こうならいいが、 > 本来nullが格納できない型がnullを格納できるようにする これって、このスレ的には全然意味なくね?
763 :
デフォルトの名無しさん :2006/01/07(土) 02:54:55
>>407-412 いいな。
しかし、こうなるとif文やtry-catch文も式になって欲しいな。ついでに多値代入も。
764 :
デフォルトの名無しさん :2006/01/07(土) 04:52:58
ここまで出てないのが不思議だが、 ダウンキャスト禁止。
>>764 dynamic_cast もダメなの?
766 :
デフォルトの名無しさん :2006/01/07(土) 11:37:39
当然だろ。
767 :
デフォルトの名無しさん :2006/01/07(土) 11:42:59
変数名も、型情報として扱うってのはどうだ。 つまり、型は直接使えず、型のインスタンスを使う、みたいな。 何が嬉しいって、変数名はそれが何であるかを表してる。 int sec = hoge(); int hoge() { … return millisec; } なんてのを防止できる。
> 変数名も、型情報として扱う 名前だけじゃなくて、型にDbCの制約みたいなファセットを設けられるといいな。 null可否も含めて。 型一貫性矛盾はもちろんコンパイルエラー。 ファセットは静的チェックできる物はコンパイル時チェックするし、 そうでないのはキャスト箇所で動的チェック。 Date deadline:<never null, must isWeekday()> = new Date(…);
ここに書き込んでる奴らはまずAdaでそれなりの規模のプログラムが書ける様になってから来い
>>769 自然数 N が与えられたとき、
1 から N までの数字を N 個並べる組み合わせをすべて
列挙するプログラムは Ada で書くとどうなりますか?
例えば N = 3 のとき
1 2 3
1 3 2
2 1 3
2 3 1
3 1 2
3 2 1
となるようにです。
よろしくおながいします。
774 :
デフォルトの名無しさん :2006/01/07(土) 20:54:47
>>773 解ってないな。
ダウンキャストが必要になるって事は設計に穴があるって事だ。
だいたい、自分でキャストしておいて実行したらそこで例外発生って事は、それ自体バグだろ。
775 :
デフォルトの名無しさん :2006/01/07(土) 21:15:02
776 :
デフォルトの名無しさん :2006/01/07(土) 21:20:17
だから
>>769 にAdaで書いてみろって言ってんだろ
>>774 解ってないな。
ダウンキャストが必要 イコール 設計に穴、という
短絡思考しかできないんだろ。つまりお前の脳味噌に穴が空いているってことだ。
> ダウンキャストが必要 イコール 設計に穴、という短絡思考 お前の脳が蜂の巣でないなら、短絡思考でないことを示せよ。
gotoがある イコール 設計に穴
やっぱ蜂の巣か。
1時間半しか待てんのか。
手抜きと省略は違う罠
784 :
773 :2006/01/09(月) 14:09:24
>>774 > だいたい、自分でキャストしておいて実行したらそこで例外発生って事は、それ自体バグだろ。
バグなら例外吐くんだし、例外が検知されなければバグは見当たらないってことでしょ?
バグの出にくい言語ってのは、バグを検知しやすいという側面もあるでしょ?
何も否定されて無いように思うんだけど。
785 :
デフォルトの名無しさん :2006/01/09(月) 14:56:28
>例外が検知されなければバグは見当たらないってことでしょ? おいおい。基本が解ってないな。 「テストは、バグの存在は証明できるが、バグの非存在は証明出来ない。」 常識ですよ。 だいたい、ダウンキャストに失敗したら例外なんて、今当たり前に普及してるだろ。 そうなるまえに、そんなバグを仕込めないようにすると言ってるの。
>>784 > バグの出にくい言語ってのは、バグを検知しやすいと
> いう側面もあるでしょ?
バグの出にくい言語と、バグを (実行時に) 検知し易い
言語 (と言うか、たぶん環境) は、全然違う概念だぞ。
今はまだ一生懸命バグを見つけてつぶして出荷している
のが現状だから、バグを検知し易いシステムと言うのも
今はまだ重要なんだけど、本当はバグを混入できないよ
うな言語や環境があれば面倒なテストなんかせずに出荷
できるでしょ? ここは、そういう夢物語を語り合うス
レだよ。
ダウンキャストについては、エラー出さずに実行される方が恐い。
いや、どんなけ言語仕様がよくてもテストは必要だろ。
790 :
デフォルトの名無しさん :2006/01/09(月) 23:20:12
791 :
デフォルトの名無しさん :2006/01/09(月) 23:21:55
>>785 > 「テストは、バグの存在は証明できるが、バグの非存在は証明出来ない。」
知ってるから”見当たらない”という単語を使ったんだが。
> そうなるまえに、そんなバグを仕込めないようにすると言ってるの。
システム記述言語の側面を捨てるということなら、キャスト全部禁止(アップキャストは暗黙の変換)ということで同意できる。
>>787 どの時点のバグの話をしてるの?
要求
分析
設計
コーディング
どこから?
上流設計より上は言語の範疇じゃないように思うんだけど。
792 :
デフォルトの名無しさん :2006/01/09(月) 23:25:30
>>789 そりゃそうだ。だが、いくらテストしてもバグは残る。
なら入らなくて良いバグは最初から入らない方が良いに決まってる。
793 :
デフォルトの名無しさん :2006/01/09(月) 23:27:12
>>791 >システム記述言語の側面を捨てるということなら、
kwsk
794 :
デフォルトの名無しさん :2006/01/09(月) 23:44:48
現状の静的言語を使ってまともに開発してて残るのは、 > 設計 この辺 > コーディング に起因するバグがほとんど。ここをどうにか汁。
>>789 もちろんバグの混入はコーディング時だけじゃないから
全てのテストが不要になるわけじゃない。
でも、(夢物語だが) 言語仕様がきちんとしてれば、例
えばコーディングミスにかかわるテストは不要になるだ
ろ。願わくば、上流工程でもすばらしいツールが開発さ
れてテストがどんどん不要になればいいんだが…。
>>791 > 知ってるから”見当たらない”という単語を使った
言い訳なのか、話の流れが読めてないのか良くわからん
が、とにかく見苦しい。
> どの時点のバグの話をしてるの?
普通にスレを読んでりゃ、コーディング + 設計少々
ぐらいはわかりそうなもんだが…。
>>793 バイナリファイルを扱うときに構造体にキャストするとか、そんな感じじゃね?
ローレベルなの書いてるとキャスト無いとつらいからなあ
設計段階で既にBUGってるシステムを検知出来なきゃ、無駄な事さ♪
>>795 > が、とにかく見苦しい。
もう一回
>>774 ,784,785 を読みなよ。
俺も言葉足らずのところがあって >774 の
> ダウンキャストが必要になるって事は設計に穴があるって事だ。
これを否定する気はないということを追加しておく。
ただ、それの必要なレイヤも存在するから、当時の俺の、例外を吐くから構わないという意見になる。
> 普通にスレを読んでりゃ、コーディング + 設計少々
> ぐらいはわかりそうなもんだが…。
アンタだと知ってれば聞かないよ。
799 :
デフォルトの名無しさん :2006/01/10(火) 08:38:51
結局二人が「望んでいるもの」は 一致していたわけだ。
800 :
デフォルトの名無しさん :2006/01/10(火) 13:14:39
100%バグと返せ、誤検出率を気にしなけりゃ完璧。
大体バグって言うのは人間共が自分の主観で決めるもので
コンピュータ側からしたら言われたとおりにしているだけ
言った事と思ってたことが違うのを自動的に検出しろっていうのは原理的に不可能だ
バグの検出は結局「思ってた事」を知ってるプログラマにしかできない。
まあ、可読性でも上げとけってこった。
一方で何故バグが生じるかと言えばその言語で可能な操作が多すぎる為だ
その性でプログラマが意図と異なる操作を指示してしまう危険が増える
バグの発生を減らしたきゃ自由度の低い言語を使えって事
バグ排除以外の言語の能力を全て無視すりゃ
究極形は
>>2 で」結論が出とる
プログラマ側でやりたいことは、プログラム上では数学的処理に変換されているけど、ここにバグ検知の見解の限界があると思う それなら、コードに対して強力なタグ付けを行って、コンパイラ側にプログラマの意図を類推しやすい形でコードを書いてあげられれば、ミスの汲み出しがしやすくなると思うんだけど…
自然言語->論理式->ロジックプログラミング という流れにポイントを絞る時期がきているのではないか。 これなら焦点が合わせやすい。
804 :
デフォルトの名無しさん :2006/01/10(火) 14:26:51
> 言った事と思ってたことが違うのを自動的に検出しろっていうのは原理的に不可能だ その通り。 だが、言ったことの中の矛盾は検出できる。 それが、バグを出にくくする言語仕様ということ。 ついでにいうと、思ってる事を正確に沢山言わせた方が検出しやすい。 だから、動的言語より静的言語の方がステップが増える傾向がある。 もちろんそれだけじゃなくて > まあ、可読性でも上げとけってこった。 こういうようなのも重要だけど。
805 :
デフォルトの名無しさん :2006/01/10(火) 14:29:41
> それなら、コードに対して強力なタグ付けを行って
プログラミングではプログラマの意図について名前を使う。
>>767-768 が、その具体案ではないか。
実行中のメモリやデータ構造が見える開発環境。
>言ったことの中の矛盾は検出できる 局所的な矛盾なら検出できる。そしてそれはどんな言語でも文法チェックと言う形で検出する。 だがグローバルな矛盾の検出は全ての入力に対する試験が必要になるので計算量的に不可能。
808 :
デフォルトの名無しさん :2006/01/10(火) 15:16:54
具体的に何を言ってるのかよくわからん。 グローバルに全然別に開発された部分同士で、 型の整合のチェックがなされて矛盾が検出される訳だが。
いわゆる実行時エラーの類のこと
810 :
デフォルトの名無しさん :2006/01/10(火) 15:25:18
というか、局所的な矛盾なら検出できる文法というのを披露していただきたい。
811 :
デフォルトの名無しさん :2006/01/10(火) 15:26:54
おまいはコンパイラに怒られたことがないのか?
812 :
デフォルトの名無しさん :2006/01/10(火) 15:28:18
>>809 ますます意味が分からん。
文法チェックなら、コンパイル時に行えるわけだが。
そして、実行時にエラーとして検出できる矛盾とはいかなるものか。
813 :
デフォルトの名無しさん :2006/01/10(火) 15:30:34
>>811 名前間違えとかその手のことか。
それなら、局所もグローバルも関係ないだろうよ。
開放したメモリを弄るのは明らかに矛盾だろ?
815 :
デフォルトの名無しさん :2006/01/10(火) 15:38:42
なるほど。しかしそれは型情報があればグローバルも局所もないな。 というか、いまどきGC前提だろ。
いや、局所とかグローバルといっても変数の話をしてるわけじゃないから 文単位での矛盾か文の集合体としての矛盾かというだけ それに、GCは開放し忘れを防ぐだけで開放してしまった物を弄ることには何の影響もないぞ
817 :
デフォルトの名無しさん :2006/01/10(火) 15:48:18
おいおい、まだ弄れる物を解放するGCなんて怖くて使えんぞw
ふむ、今時はメモリの開放は全てGC任せが前提なのか
>>816 GC 使うならそうでないとあまりありがたくないだろ。
820 :
819 :2006/01/10(火) 22:31:26
プログラムは書いた通りに動いてるだけ
それをバグとするか仕様と考えるかは使う方の受け止め方次第 昔からのエンジニアはプログラムには元々バグがあるものだと 織り込み済みでそれを回避した使い方を考えて使うもの 最近の風潮(バグ=罪悪説)は素人が参加しだしたために広まったもの
「バグではありません。仕様です」つう釈明を流行らせたところもあるねw 昔では考えられない釈明だけど。 そしてユーザーは「回避した使い方を考えて使う」わけだ
824 :
デフォルトの名無しさん :2006/01/10(火) 23:18:29
馬鹿電波が紛れ込んできたな
>>824 俺はこのスレの初めから最後までバカしかいないと思ってる。
バカの出にくい言語仕様を考える。
それよりも、バカなことをしたくならない言語仕様を考えてくれ。
828 :
デフォルトの名無しさん :2006/01/11(水) 01:38:48
>>767-768 は、膨らませて練り上げると、いい機能になりそうなんだが、どうだろう。
広い範囲での整合性のチェックといったら、結局、
型情報のチェックしかない。(ほかにあったらあげて欲しい)
なら、型情報をリッチにしていろいろチェックできるというのは、筋が通ってると思うのだが。
つtypedef
830 :
デフォルトの名無しさん :2006/01/11(水) 01:47:29
もちろんそれもいいんだけどね。もっとリッチに行こうぜ。
つstruct, class
強制ハンガリアンかよ。
error 10 行 : i はハンガリアン表記ではありません . error 11 行 : j はハンガリアン表記ではありません . error 12 行 : k はハンガリアン表記ではありません .
つまり、木は森に エラーは大量のエラーに バグは大量のバグに隠せと言うことだな うむ、実に奥が深い
反ガリ案は違うと思うが…
概出かもしれんが次元解析してくれるとうれしい
837 :
デフォルトの名無しさん :2006/01/11(水) 08:37:25
変数に値をセットしたあと、その変数を参照することなく、 更に値をセットしうるときや、関数を抜けちゃいうるようなとき、 コンパイルエラーになるってのはどうだ。
賢いIDEなら、コーディング段階でそれぐらい出来そうだな。
>>837 そんなWARNINGを出すコンパイラは普通にある希ガス
-Wallをつけないでコンパイルする奴は馬鹿。
841 :
デフォルトの名無しさん :2006/01/11(水) 11:35:04
>>836 それって型推論とか違うのかな。よくわかってないけど。
あと、
>>767-768 みたいに、同じdoubleでも、ちゃんと型作って、さらに型同士の関係を定義しておくと。
ただ、金融の一部を除いて、業務のシステムではあんまり出番がなさそうな…。
>>841 角度をラジアンに変換するときに
rad = Θ * PI / 180;
見たいな計算をする訳だけど、
うっかり
rad = Θ * 180 / PI;
と書くと次元エラーを警告
ハンガリばかり連呼しているバカは一生コーダやってろよ。お前らは研究者に向いていない。
844 :
デフォルトの名無しさん :2006/01/11(水) 13:07:34
>>842 だからそれ、型チェックでしょ
180の型が度で。
>>842 次元解析でそれがエラーになるのはおかしい。
radian=degree*定数。
>>844 の言ってることもずれてる。
846 :
デフォルトの名無しさん :2006/01/11(水) 14:17:51
だから、ここでのPIの型をradにしろって話だろ
俺はバグが見つけやすい言語であればいいじゃんと思ってたんだが 実行前に見つけるの前提? ってことはスクリプト系はここではスレ違いってことでいい?
「バグの出にくい」と逝っている以上は 実行中に見つかるのは手遅れだろ?
こうですか?わかりません(><) class rad{ double operater/(rad); rad operater*(rad); rad operater+(rad); rad operater-(rad); }
850 :
デフォルトの名無しさん :2006/01/12(木) 00:31:24
>class rad{ いいと思います。(radの掛け算はないと思うし、割り算はdoubleになると思うけど) でも単位ごとにクラスができてたら、言語自体が収集つかなくなってしまいます。 実装レベルではπをdoubleとしながらも、コンパイラに「πはradianだよ」という 情報を与えてエラーにできないでしょうか?
だからclass定義するんじゃねえか馬鹿
>>850 > でも単位ごとにクラスができてたら、言語自体が収集つかなくなってしまいます
はぁぁぁぁ?????
radrad operater*(rad);
double sin(rad); double cos(rad); double exp(rad); とか定義しておかないといけない気が巣
855 :
デフォルトの名無しさん :2006/01/12(木) 08:48:51
>>851 新しい言語仕様を考えるスレで、なぜ既存言語仕様の話を?
>>852 もっとラジカルに型をバンバン楽に作らせろって事だと。
typedef double radian;
typedef double degree;
const <radian / digree> PI = およそ3 ;
double rad = Θ * PI / 180; //コンパイルエラー
radian rad = Θ * PI / 180; //コンパイルエラー
radian rad = Θ * PI / (digree)180; //OK.
double rad = Θ * 180 / PI; //コンパイルエラー
radian rad = Θ * (digree)180 / PI; //コンパイルエラー
こんな感じ。
あ、なんで const <radian/digree> PI なんだ。 const degree PIでよか。
まとめ 結局C++もまともに使えていない馬鹿が 俺がバグを出すのは俺のせいじゃない言語が悪いんだ という妄想で暴れてるスレ
858 :
デフォルトの名無しさん :2006/01/12(木) 11:56:35
世の中の95%のPGがC++をまともに使えない件について で、いちいちclassつくらんで次元解析する方法よろ
言語仕様を考えるスレなんだから、C++ とかの既存の言語でどうするかはスレ違いだよな 要するに次元は型情報で、次元解析は型検査なんだから 次元を何らかの形で記述できる文法にすれば十分可能な希ガス double とか int とかの既存の型に次元情報を追加する形になるのかな dimdecl m; // 単位次元の宣言 dimdecl kg; dimdecl s; dimdef N = kg * m / (s * s); double<kg> mass = 5.656 kg; double<m/s/s> acc = 7.878 m/s/s; double<N> f = mass * acc; Google電卓が参考になるかも
結局、前の方でも言われているけど 「強力な型チェック機能」が重要になるっていうのが一つの結論になるのかな? 個人的意見として、Javaみたいな堅苦しくって仰々しい言語になると返って使いすらいので Lispやrubyみたいな手に馴染む感じを失わない文応でもあって欲しいんだけど
861 :
850 :2006/01/12(木) 12:48:40
>>文応 文法…orz
「総称」などの概念は、生まれた経緯(理由)は違うものの よりバグの出にくい言語仕様って言うことができますよね? (↑の場合は型キャストのミスというバグからの開放)
>>859 それやりだすと補助単位が面倒だから補助単位は言語仕様に盛り込めないかね。
後は単位変換とか。
dimdecl g;
dimsubunit k = 1000;
double<g> mass = 5.656 <k>g;
dimdecl m;
dimdecl ft = 0.3048 m;
double<m> height = 10000 ft;
864 :
デフォルトの名無しさん :2006/01/12(木) 13:27:40
確かにGenericプログラミングとかパラメタライズトクラスとか近いな、というか、同じなのか? たしかGenericプログラミングスレがあった気がするが
お前ら、ジェネリックとかアスペクト、アジャックスとかetc..のしょうもない言葉に釣られすぎ。 もっと骨のある奴はいないのか。
LISP クロージャ 無名関数 構造体ベース志向
868 :
デフォルトの名無しさん :2006/01/12(木) 18:56:19
土方を骨のある奴とは、モノは言い様だな
>>868 このスレは研究者のためのスレだけど、コーダには現場の意見を言ってもらいたい。
言語という具体的な道具を考える段階では、机上だけで考えても仕方がないのだから。
逆に言うと、コーダは机上の話には口を出すな、という事でもある。
JavaScriptのように文字列を関数に出来れば速くならないか?
トレース出力にコードとデータが混在していればクロスリファレンスしたくなくなる デバッグに役立つじゃん
コーダーの立場でいえば、ライブラリや情報やIDEも考慮して、一番早くできればいい バグがでないとしても、コーディング終わるのに他の100倍時間のかかる言語はいらない
874 :
デフォルトの名無しさん :2006/01/12(木) 20:41:40
Perl6を2/100ヶ月で作れるんならお前の意見はもっともだ
並列処理を記述するのにforkやpthreadを記述した時点で負けだと思う
876 :
デフォルトの名無しさん :2006/01/12(木) 20:58:47
>>871 Java6あたりでコンパイラ起動、リフレクション、動的バイトコードロード駆使すれば出来る
ツリービューとかツリー構造のデータを記述するのに向いた言語って無い? 多くの人がここで躓くんだ Perlベースのモジュールで見たって5−6種類はもうすでにあるんじゃないかなと思うぐらいすごい そしてXML
879 :
デフォルトの名無しさん :2006/01/12(木) 21:57:46
>>876 今のJavaでもテキストファイルに吐いて、javacでコンパイルして、クラスローダで読み込めばできるよ。
ビジュアルプログラミング言語みたいなのはないのかな マウスだけで全部プログラミングできてしまうようなやつ。
>>877 上手く説明する自信ない すまん
コーディングオンリーで完成させる時間(バグでない言語)
コーディング+修正で完成させる時間(バグ出る言語)
この2つを比較して上の方の時間の方が短ければよい
>>880 ⇒
>>637 て言うか、ビジュアルだからバグらないわけじゃないんだ
が、定期的にこの意見が出てくるな。
>>881 コーディングにかかる時間と、+修正 にかかる時間の大
体の比率もわからんのか?
まあ、完成までの時間しか考慮に入れていない時点で厨と
いうのはバレバレだがな。
>>880 操作をマウスで行うのか表示を画像形式にするのか良くわかんない PAD図で表示するとか構文解析図を表示するとか
>まあ、完成までの時間しか考慮に入れていない時点で厨と >いうのはバレバレだがな。 他に何の時間を考慮しろと?
>>1 >>11 循環参照するポインタのリファレンスカウントがゼロにならないバグを組み込んだ
Ver1完成させるまでにかかる時間が少ないといいね Ver1からVer1.1完成させるまでの時間が少ないといいね Ver1.1からVer1.3完成させるまでの時間が少ないといいね? 他に何の時間を考慮するんだ?
Ver1からVer1.2に上がるまでの間に人が辞めてかないといいね まず鬱になる これ基本
890 :
デフォルトの名無しさん :2006/01/12(木) 23:27:02
MKSA<1,0,-2,0> 加速度[m/s^2] こんな感じにすると単位同士の演算も簡単になりそうな気がします。
>>879 今のJavaじゃjavacが使えるかどうかやそもそもjavacでよいのかが分からない
D言語マンセースレはここですか? しょっちゅうインデックス外の配列にアクセスしてしまいArray Bounds Error起こしてしまうんですが何とかならないでしょうか?
894 :
デフォルトの名無しさん :2006/01/13(金) 00:01:25
つiterator
言語を進化させるより人間の脳を進化させた方が早い
>>891 いやだからアマチュアさんにプロは何の時間を考慮するのか教えてくれと
鶏を割くに焉ぞ牛刀を用いん >894
作業時間 Χ(x) 眠る時間 f(x) とすると Χ(x)+f(x)=24時間を満たす最小の f(x) を得られる x が求められる公式がこのスレで欲しい
899 :
デフォルトの名無しさん :2006/01/13(金) 00:31:43
>>893 配列を使わない。
>>896 売ってからのバグ対策とかは思いつかないの?
マジな話、バグ "0" になるならソフトによっては
100倍でも十分なケースもあるよ。
この流れで関係なくね?それ。 それとも改修のこと?
マニュアル作る時間じゃないのか?
>>901-902 パッチ配布(M$ではサービスパックなどとぬかしておるが)に掛かる時間のことだな
>>904 いまだにパッチの当たってないPCがわんさかあることを考えると、
時間は無限大とも言えるかも知れないですね。
>>903 マニュアルにバグがあるケースも多いですね。
ソフトの改変でセキュリティが弱くならない言語仕様を考えたくなる
>>879 今のJavaじゃなくてもリフレクションや 動的バイトコード生成&ロードだったら 1.1 の頃からできるし。
1.InputStreamでクラスファイルのバイナリを読む 2.ClassLoader#defineClass()にバイナリを渡してロード 3.Class#forName→Class#newInstance()→Class#getMethod→Method#invoke って漢字か
完成までの時間しか考慮にいれないのは当たり前の話だ 保守作業が発生したとき、保守作業の完成までの時間が少ないといい バージョンアップが発生すれば、バージョンアップの完成までの時間が少ないといい 完成までのコーディングと保守のコーディングを何で分けて考えるの? 同じコーディングじゃん それで最終的に早い方がいいってだけじゃん?
保守の発生回数が少ないのが一番良いね
完成までを100として、保守が1でも1000回というのと、 保守も100だけど2〜3回で収束するというのとを比べると、 どっちがいいかっていう問題ですね。
次スレタイトル 保守のしやすい言語仕様を考える
ファームウェアで保守なんて考えたら罰が当たるよ
開発速度が100倍になったら保守という作業は消滅する って聞いた事がある
だから、30歳過ぎて、社会の政治的な要因に太刀打ちできるような 立場になってからもデザインパターンみたいな一技術で重宝されるような 人物に対して「逃げ道だよな」って言ってるの。20代の奴がやりたくてもできないような ところで自分をアピールする術を持ってないのかって。 中堅者のやることっていったら、20代の奴が仕事をしやすいように、いろいろと根回しすることだろ? 年齢重ねても、やることが20代の延長だったら会社に居る意味ねーよ。 スパゲティコードだとか、その辺は中堅社員が口出すことじゃねーって。 むしろ、20代の奴が気付いて、中堅社員に意見をUPして、それから中堅社員が根回しするのが理想。 要は、いい歳こいて低レベルな話してんじゃねーよって。もっと抽象的になれってことだ。
狂牛病を直すソフトウェアとか 鶏インフルエンザを予防するのとか
高齢化社会に備えて自宅で園芸をするための言語仕様とか考えといたほうがいいかも
路上駐車を防ぐ言語もいる 非常に重要 交通の妨げになる
女に縁のなかった俺がモテまくりでウハウハな言語キボンヌ
だから、30歳過ぎて、狂牛病に太刀打ちできるような 立場になってからも鶏インフルエンザみたいな一予防で重宝されるような 高齢化社会に備えて「自宅で園芸をするための言語仕様とか考えといたほうがいいかも」って言ってるの。路上駐車の奴がやりたくてもできないような ところで自分をアピールする術を持ってないのかって。 中堅者のやることっていったら、路上駐車の奴が交通の妨げをしやすいように、いろいろと根回しすることだろ? 年齢重ねても、やることが路上駐車の延長だったら会社に居る意味ねーよ。 防ぐ言語もいるだとか、その辺は非常に重要じゃねーって。 むしろ、路上駐車の奴が気付いて、女に縁のなかった俺がモテまくりで、それから中堅社員が根回しするのが理想。 要は、いい歳こいてウハウハな言語キボンヌじゃねーよって。もっと抽象的になれってことだ。
922 :
デフォルトの名無しさん :2006/01/13(金) 23:42:56
枯れたライブラリが山盛りで、 自分でほとんどコーディング量が少なくて済めばバグも出にくい
もうこのスレ削除していいでしょや? バカしかいない。このバカ!クズ!
まあ、コーディング量が少なければバグも少ないのはわ
かるが、たった2行でも日本語として??な書き込みし
かできない
>>922 がいる限り、バグは無くならないで
あろう。
コーディング量以前の問題だって早く気づけ、このバカ!クズ!
927 :
デフォルトの名無しさん :2006/01/14(土) 00:29:54
人間が作るからバグができる。 つまりバグがある言語は作った人の血が通っている。って昔の偉い人が・・・・
まぁ、あれだよ 2割8割。お前ら8割
お前らはね、努力もせずにバグがでるーバグがでるーとか言ってるのね。 そして、自分のバカさ加減を言語とか、コーディングスタイルとか、スパゲッティコードのせいにしたりするわけ。 〜スタイルだの、〜指向だの、といろいろいいわけを考える訳ね。 もうこのバカ!クズ!
山本インセンティブでどう?
>>929 馬鹿って言うやつが馬鹿だってママが言ってたお
1000だったらバグの出にくいオパイうp
まあ、コーディング量が少なければバグも少ないのはわ
かるが、たった2行でも日本語として??な書き込みし
かできない
>>922 がいる限り、バグは無くならないで
あろう。
おれもそう思った
936 :
デフォルトの名無しさん :2006/01/14(土) 10:45:59
副詞ひとつでガタガタ言ってんなカス共 くやしかったら、まともなネタ振ってみろ
>>922 が「副詞ひとつ」の問題とはとても思えない件について
>>936 プログラムだったら、カンマ一つで何百万ドルか吹っ飛
んだ例もありますが?
て言うか、
>>922 のどの副詞を修正したら
>>922 が
まともな日本語なるんだ?
ウチはスペースひとつで一億円ぶっ飛びましたが何か?
ウチはバグ数千個でプロジェクトぶっ飛びましたが何か?
害虫のバグ一つで今日のデートが吹っ飛びましたが何か。
ウチはカウントダウン一回でロケットがぶっ飛びましたがなんか
944 :
デフォルトの名無しさん :2006/01/15(日) 00:58:28
関数型言語は、マイナーながらそれなりに市民権を得つつある。 しかし、論理型言語や並列型言語がそうでないのは何故だろう。
STLやらBoost.LambdaからC++ユーザを関数型へ染めたのだ、とデムパしてみるテス。
味噌を作るための言語仕様はありますか?
>>945 確かに、C++というメジャー言語が、多数のユーザに
関数型の考え方を見せ付けたってのはあるだろうね。
味噌の地域性を表現する表象言語が必要になりました どんな文法がよろしいでしょうか 記号体系でも結構です
なぜってね いつも食べているものじゃないと安全管理に対する意欲が沸かないでしょ
なんか、低脳荒らしがゴミレス量産してるな。
次スレはマ板だな
953 :
915 :2006/01/15(日) 09:27:22
>>932 「新規開発のほうが保守するより安上がりになる」という意味さ
>>953 母体が 100倍以上あったら駄目ジャン。
つーか、テストの工数とか考えてないだろ。
955 :
デフォルトの名無しさん :2006/01/15(日) 13:02:13
M$は数年毎にOSを新規開発してるからなぁ ある意味脅威的だよなぁ
新規開発じゃねぇだろ。単なる改造拡張。
958 :
デフォルトの名無しさん :2006/01/15(日) 14:07:19
リッチな型情報を容易に使えること、というのが結論ということでよろしいか。 あと、馬鹿ネタ書いてる奴はマ板行け。
959 :
デフォルトの名無しさん :2006/01/15(日) 14:11:54
960 :
デフォルトの名無しさん :2006/01/15(日) 14:20:08
961 :
デフォルトの名無しさん :2006/01/15(日) 14:35:02
>>943 並列型言語は、
プログラムの潜在的な並列性を完璧に検出・並列実行できるため、
逆に処理記述の粒度が細かくて、面倒というか、コードが長くなるらしい。
あと、関数型言語以上に発想というか考え方の違いが大きいとか。
いや、全然解ってないんだけど。
解ってる人ツッコミよろ
962 :
訂正 :2006/01/15(日) 14:35:31
>>944 並列型言語は、
プログラムの潜在的な並列性を完璧に検出・並列実行できるため、
逆に処理記述の粒度が細かくて、面倒というか、コードが長くなるらしい。
あと、関数型言語以上に発想というか考え方の違いが大きいとか。
いや、全然解ってないんだけど。
解ってる人ツッコミよろ
豆腐を4ラインで製造する言語仕様を考える
コンパイラ言語逝ってよし
965 :
デフォルトの名無しさん :2006/01/15(日) 16:32:17
もうお父さん型無しだよ。
966 :
デフォルトの名無しさん :2006/01/15(日) 16:37:10
カタナシヨーグルト
話について行けない低脳ゴミPGが暴れてるな。 お前が早く業界から去ることが、お前も含めたみんなのためになる。
968 :
デフォルトの名無しさん :2006/01/15(日) 17:59:08
オマエモナー
Visual D
Borland D Builder
>>962 KLICの場合は書き手の感覚では、Prologと同じレベル。
バックトラックしないのだからまったく別の言語だが、
とくに粒度が細かいとか、コードが長くなることはない。
面倒臭さに至ってはこちらの方が楽。
>>958 >>960 型無し言語スレ、最初はあほかと思ったけど、途中議論始めてからは良スレ化したね
>どうせなら、型と双璧をなす(俺主観)、「ロール」も
>チェック対象になるような言語が欲しいです。
何この俺
>>960 結局、何年も前のスレと、似たようなこと話してるんだね、このスレ。
このスレ独自の話題もない訳じゃないが。
その「ロール」って、上の方にあった、名前を型の属性にするってのと似てるな。
c言語で int a = 1; int b = 3; float c = a / b; で計算すると c=0 になってしまいます。 float c = 1.0 * a / b; だとちゃんと c = 0.3333 になります。 これって結構バグの温床になっているような気がするけど、 うまい回避方法ってありますか? これはもうc言語特有の問題なんでしょうか。
976 :
デフォルトの名無しさん :2006/01/16(月) 01:44:14
float c = (float)a / b;
>>975 みたいな言語仕様を理解できてない馬鹿が存在すると、
いくら言語が優れていても意味なー
>>975 コンパイラが警告だしてくれりゃそれでいいんじゃない?
>>973 言語の進化は、私たちが驚くに値するほどゆっくりしか進行していないと言うのが解釈として正しいと思うよ。
何処でも同じ話題が出ると言うことは、欲しい言語の方向は結構決まっているみたいなんだけどね。
>>979 発想が何かに縛られているということではないかな。
単に大昔に通り過ぎてすでに実装されている機能を知らない馬鹿共が 車輪の再発明さえもできずにそれを夢見てるだけ
無知と馬鹿は違うし、車輪の再発明くらいはしてるだろ。
それよりもどうやって車輪で毎日食べる豆腐が作れるかだ これでバグの温床が減るはず
車輪だって4つ再発明すれば車ができぞ。
>>984 実際最近の電気自動車の車輪は車輪の再発明に近いものがある
>975 型の厳格な言語としてそれは当たり前の動作。 暗黙に変換される事こそバグの元だろ。
>>986 1.0 を掛けると陽に移行したことになるの?
私は頭の硬いCOBOLで、Cは解らないのですが、
>>975 はそういう思い付きの言語仕様に対する
疑義のように読み取れますが。
assert( typeof(a).float == YES ); みたいなの付けてチェックするとか
Java流に書けばアサーションていうの必要ないんじゃん
>>982 無知の自覚が無いのが馬鹿
そしてこのスレには明らかに馬鹿が居る
強力な型付けがバグを減らすために重要って事が一つの結論なら どういう文法であれば、型付けの煩雑さと、バグ削減の有用さを上手にまとめられるかとかの議論も欲しいな 既存の言語への拡張でも良いし、新しい言語を提案するのも良いし うまく行けば後の世に繋がる
993 :
デフォルトの名無しさん :2006/01/16(月) 17:57:28
Adaで書け
994 :
デフォルトの名無しさん :2006/01/16(月) 18:50:37
いっそのこと論理型言語に乗り換えろ
995 :
975 :2006/01/16(月) 19:26:25
レスどうもです
>>976 だからそういう(float)のようなものを付けなければいけないことに
気づかないことが多いのではないかと思ったんです。
>>978 コンパイラはgccですが、警告は出してくれませんでした。
>>986 そんなもんですかねー?確かにこの計算で0を答えとして求めたい
という場合もあるかもしれないな。
>>988 そうです。いちいち型キャストとか考えなければいけないのは
めんどくさいと思ったので。
>>989-990 そんな方法があるんですか。勉強してみます。
>>991 ぎ、ギクッ
暗黙のキャストが邪悪なのは常識
しかし,利便性と天秤にかけた結果敢えて残されている
利便性を捨てて避けたければTypedefで見かけ上別の型にしてしまえば良いだけの話
>>975 は型が理解できていない初心者というだけ
演算子の記号をもう一つ付け加えられればいいかと思うけどね [int][浮動小数除算をする記号][int] が (float)[int]/(float)[int]) を糖衣したもの の様な …VBだと逆のは有るんだけどな
int が何バイトか OS 毎に違うのではなく、言語で固定、ってのはどうよ。
うっほっほー やっほっほっほ うっほほーい
1001 :
1001 :
Over 1000 Thread このスレッドは1000を超えました。 もう書けないので、新しいスレッドを立ててくださいです。。。