sizeof(char)が必ず1でも、省略すべきではない

sizeof(char)が必ず1� ..

437:デフォルトの名無しさん
08/02/28 13:45:03
>>431
templateで間接的になら

438:デフォルトの名無しさん
08/03/04 17:38:06
sizeof (TCHAR)で間接的になら

439:デフォルトの名無しさん
08/03/21 00:22:32
>>435
おいおい、ブラクラではなかったぞ。

>>434
学歴は関係ないと思う。

8,800円払って中身みたわけではないのだが、
大学の教授が書いているC言語入門書にも、
とんでもなく酷い本があるのだから、
もはや学歴や肩書きは関係ないと思うのよ。

BASIC時代のPRINTをそのまま引きずった、
printf("Hello, world\n");
なんてのが平然と書かれている本を見るたびに、
こんなので勉強したら無駄な時間を食うのは当然だなと思うし。

440:デフォルトの名無しさん
08/03/21 02:42:30
>>439
Hello,worldは基本中の初歩であって
これをバカにする理由が思い当たらないんだが

441:デフォルトの名無しさん
08/03/21 02:51:38
puts("hello world");
ってやるべきってこと？

442:デフォルトの名無しさん
08/03/21 03:12:25
そんなことを言い出したらフォーマット文字列の中に
足がすくんじゃって何も書けなくなってしまうわけだが

443:デフォルトの名無しさん
08/03/21 03:17:33
正統派の基本を馬鹿にするのは新しいまがいものを売るときの基本
結局同じことの繰り返しになるわけだが

444:デフォルトの名無しさん
08/03/21 03:35:57
30年間でほとんど進歩してないな。

マイクロソフトの新しいバージョンのVisual C++が出る度に、まっさきに、
Visual C++ バージョンほげほげ対応という冠を付けた本が出るのだが、
いまだに本編は相変わらず昔のままで、付録的に
コンソールで cc hoge.c とやってコンパイルするのと同等のことをやる方法を
ちょろっと書いているだけで、Visual C++のデバッガの使い方を説明せず、
変数の値をprintfを埋め込んで標準出力に出して確認することを第一に教えている。

445:デフォルトの名無しさん
08/03/21 03:39:09
>>442
それが正しい。

printfの第一引数が書式化文字列であるとういことを初手から叩き込むべき。
printf("%s\n", "hello, world!");
これくらい、わざとらしくやってもいいくらいだ。

そうでもしないと、↓みたいなことをやるマヌケが出てくるからな。
void print_message(const char *p)
{
printf(p);
}

446:デフォルトの名無しさん
08/03/21 16:48:42
中身をみないで擁護できるのは本人だけ。

447:デフォルトの名無しさん
08/03/21 17:00:16
入門書の何が問題かというと、「ポインタがわかりません」なんて人を今だに量産していること。
しかも、そこに書かれていることが、次の段階の本で否定されていたりする。

448:デフォルトの名無しさん
08/03/21 21:15:11
>>439
どうやって文字列が表示されるのかを勉強している身としてはとてもバカにできない内容なんだが、
どういう内容を載せるべきだと言ってるのか教えて欲しいな。

449:デフォルトの名無しさん
08/03/21 22:15:53
printfは、C言語の仕様の一部ではあるものの、ライブラリの一関数に過ぎない。
printfやscanfの使い方は、ライブラリのマニュアルを読めばわかることであって、
入門書で解説すべきなのは、それらの使い方ではなく、
マニュアルを読めばわかるようになるための必要な前提知識である。

ってなことを頭の片隅に置いて聞いて欲しい。

hello, worldのサンプルなんだけど、なんかC言語っぽくないんだよね。
短くてエッセンスが凝縮されているサンプルが思いつかないんだけどさ。

>>448
> どうやって文字列が表示されるのかを勉強している

C言語とはあまり関係ないなぁ。
ライブラリがOSのシステムコールを呼んで、あとはOSが処理してる。

450:デフォルトの名無しさん
08/03/22 05:04:58
CもようやくOSを意識しないでプログラムを組める時代になったのか

451:デフォルトの名無しさん
08/03/23 03:19:41
>>450
ないよ。

452:デフォルトの名無しさん
08/03/23 03:37:29
>>445
という以前に、フォーマット文中に誤った引数が指定できて、しかも
その間違いがコンパイラでも内部処理でも検知できないっていう
printfの仕様上の欠陥があるわけで、そもそもprintfを使うことそれ自体が
NGだという話になるんじゃないの？

453:デフォルトの名無しさん
08/03/23 04:14:43
それを言いはじめたら、標準ライブラリの多くの文字列がらみの関数がNGになるよ。
たとえばstrcpyがバッファオーバーランしうる、とか。

そもそも、
今さらC言語を使わないといけない、しかも、習得するプログラミング言語の最初がC言語でなければならない
っていう状況に閉じ込められた時点で、その人は終わっていると思う。

454:デフォルトの名無しさん
08/03/23 11:02:22
除算も同じ意味でNGだな

455:デフォルトの名無しさん
08/03/23 12:01:53
プログラム言語だけでプログラムが動くわけじゃないからな

456:デフォルトの名無しさん
08/03/23 14:37:08
>>454
除算は「検知」はできるでしょ？

まあ、言いたいことはわかるけど。

457:デフォルトの名無しさん
08/03/23 17:53:21
printfの引数不正も検知できますよ。
除算よりは面倒ですが。

458:デフォルトの名無しさん
08/03/23 18:20:34
どうやって?

459:デフォルトの名無しさん
08/03/23 19:20:51
printfの呼び出し元で実引数の型情報を渡すようにinstrumentする。

460:デフォルトの名無しさん
08/03/23 19:33:19
なるほど。

大変だな。

そこまでしてCを使うのは。

461:デフォルトの名無しさん
08/03/24 21:13:13
>>460
そうだよ。
だから、Cを使うということはそのあたりの危険性と利便性をトレードオフする
考え方をもたないと駄目です。
やたら安全性をどうこう言っててもprintf使うだけでもう台無しです。

462:デフォルトの名無しさん
08/03/24 21:18:20
もう、かまってチャンは卒業しなよ

463:デフォルトの名無しさん
08/03/24 21:39:43
やっぱり>>453だよな。

いまさらC言語入門なんて。

464:デフォルトの名無しさん
08/03/24 21:48:43
だからバカはC言語使わないでください。おねがいします

465:デフォルトの名無しさん
08/03/24 22:04:12
バカなのでC言語しか使えません。
他の言語は難しすぎて。

466:デフォルトの名無しさん
08/03/24 22:40:59
Java だって + と - 間違えたら間違った計算結果が出てくるわけで・・・

467:デフォルトの名無しさん
08/03/24 22:59:48
間違えることのでき、なおかつ、それを機械的に検出できない箇所の数が、道具によって変る

っていう話しなんだよ。

468:デフォルトの名無しさん
08/03/24 23:18:09
たんによくあるセキュリティ的な話でそ。
Java で間違ったものを toString() しても機械が気付くわけでもなし。

469:デフォルトの名無しさん
08/03/24 23:46:10
>>468
セキュリティに限らず、いかにバグの入り込む余地を減らすか、ってこと。
余地が少なければ、バグの有無を確認するための工数が減るわけよ。

470:デフォルトの名無しさん
08/03/24 23:55:12
まあ、コンパイル時にチェックできるところはやるのは当然として、
実行時のチェックは性能とのトレードオフもあるから、Ｃは今ぐらい
で丁度いいと思う。

471:デフォルトの名無しさん
08/03/24 23:59:58
いろいろチェックしたらJavaと同じことをやることになって、Javaよりも遅くなったりしてね。

472:デフォルトの名無しさん
08/03/25 00:35:28
Cは機械寄りだから技術者以外には使えないのは当然だと思う。

473:デフォルトの名無しさん
08/03/25 15:13:05
>>469
まだわかってないな。

＞バグの入り込む余地を減らすか
という観点では、printf が他の関数等よりもバグ発生契機が多いとは言えないだろう、
と言ってるわけ。もちろんセキュリティに関しては全く別だよ。

実際 gcc は printf("name=%s, qty=%d\n", qty, name) に warning だしてくれるけど、
Java は WriteLine( "name="+qty.toString()+"qty="+name) をスルーする。
printf でチェックが必要なら他のどの方法でもやはりチェックが必要。

漏れは LISP 使いだし出力は全て内部構造のままS式で出すよ、という人は別だけど。

474:デフォルトの名無しさん
08/03/25 15:27:34
>>473
printfに限った話ではないし。

int height ;
int weight ;
中略
height = weight ;
こういうのを機械的に検出できるかどうかは、
微々たる事ではあるが、
ソフトウェアの規模が大きくなってくると重要よ。

475:デフォルトの名無しさん
08/03/25 15:49:47
>>474
だからそれが printf とどう関係するんだよ、という話。
「限った話ではない」ではなく、全く関係のない独立した話ですよ。

>>469なんか、まるで printf の仕様がバグ発生契機を増やすかのように
さぞもっともらしいことを書いているが、ではどの処理系でどう書けば引数の
取り違えによるバグを避けられるかは一切提示していない。

>>474に至っては、printf の仕様の問題点については一切語らずに、
「に限った話ではない」との一言で、あたかもprintfに他の同等の処理よりも
多くの問題点があるかのようにほのめかしている。

printf に問題があるなら、プログラマなんだからもっとストレートフォワードに
この処理系のこういう書式化指定法ならバグが減る、と実例を出して批判して。

476:デフォルトの名無しさん
08/03/25 16:20:46
yosoでやれ

477:デフォルトの名無しさん
08/03/25 16:46:28
>>475
仮にprintfが他よりバグ発生契機が多いとは言えないとして、
それで一体お前は何を主張したいんだ？

printfフェチ？

478:デフォルトの名無しさん
08/03/25 17:26:31
不当にCを貶めようとしてるヤツに怒ってるんじゃないの？

479:デフォルトの名無しさん
08/03/25 17:27:18
そんな奴いたか？

480:デフォルトの名無しさん
08/03/25 18:27:14
>>475
引数の順序などを取り違える
ことと、
書式化指定文字列での型指定を間違える
ことを分けて考えようぜ。

481:デフォルトの名無しさん
08/03/25 22:31:54
>>474
どうでもいいけど、

> int height ;
> int weight ;
> 中略
> height = weight ;
> こういうのを機械的に検出できるかどうかは、

これは一体何が言いたいんだ？

482:デフォルトの名無しさん
08/03/25 22:35:59
話を発散させるためなら内容なんてなんでもいいんだぜ？

483:デフォルトの名無しさん
08/03/25 22:37:15
>>479

>>467
>>469
>>474

484:デフォルトの名無しさん
08/03/25 22:52:23
>>481
たぶん>>467だと思う。

485:デフォルトの名無しさん
08/03/26 08:04:24
>>484
具体的に>>474のどこが間違いで、何が機械的に検出できないんだ？

486:デフォルトの名無しさん
08/03/26 09:10:16
高さを表わすint型の値と重さを表わすint型の値は、
型は同じだけれども、値の意味が違う。

だから、
height = weight ;
のような代入は、
C言語の言語仕様的には間違っていないが、
プログラムの意味的には間違っている。

それを機械的に検出できないとは言ってない。
工夫して検出可能にすることもできる。

工夫して検出可能にするか、
あるいは、
小細工せず検出不可能のままにするかは、
自由だ。

ただ、ソフトウェアの規模が大きくなってくると、
「人間が注意してコーディングして、しっかりテストすればいいんだ」
なんて言ってられなくなるので、
機械的に検出できるものは検出しよう、ということになるわけ。

487:デフォルトの名無しさん
08/03/26 09:28:17
>>486
そのプログラムの「意味」というのには、
　ソースが英語で書かれてる
というのが大前提としてあるよね。

仮に、heightが横幅でweightが縦幅を意味する言語があったら、
そのプログラムの「意味」は全く正しいということになる。

488:474
08/03/26 09:55:54
>>487
このスレを読み書きしている人で、
heightとweightが英語だと理解しなかった人がいたら、
手をあげて欲しい。
そういう人がいたなら、次からは何か改善するよ。

489:デフォルトの名無しさん
08/03/26 10:02:53
height = weightを機械的に検出しなきゃいけないってどんだけｗ
なんのための変数名だよ

490:474
08/03/26 10:25:44
例がわかりやすいように、わざと豪快に間違ったコード片を書いた。

ここまで豪快なミスは少ないだろうが、このタイプのミスをしたことの
ある人はいるでしょう?

491:デフォルトの名無しさん
08/03/26 10:37:20
その手の間違いでNASAの火星探査が失敗したってニュースがあったような

492:デフォルトの名無しさん
08/03/26 10:37:42
>>488
問題は人間じゃなくて、機械がそれを英語かどうかを判断できないってこと

493:デフォルトの名無しさん
08/03/26 10:41:07
>>488
例えば、heightをheiと省略したらその「意味」は通じなくなるし、
他にもhaightとミスタイプしたら通じなくなる。

494:デフォルトの名無しさん
08/03/26 10:43:10
>>491
そりゃデバッグが足りなかっただけで、
それを言語仕様のせいにするのはちゃんちゃらおかしいだろｗ

495:デフォルトの名無しさん
08/03/26 11:27:35
そこでアプリケーションハンガリアンですよ。
URLﾘﾝｸ(local.joelonsoftware.com)

496:474
08/03/26 11:34:13
>>492
>>493
貴方達が人工知能的なアプローチしか頭にないのは、わかった。
俺らはtypedefを使ってコーディングして、それを機械的にチェックする。

497:デフォルトの名無しさん
08/03/26 11:47:31
>>494
そういう考え方だと大きなプログラムのデバッグは大変だな。

498:デフォルトの名無しさん
08/03/26 13:11:47
機械的ってのはコンパイラが検出という意味ではないのか。

TypedWidth redBoxWidth;
TypedHeight redBoxHeight;
　　:
TypedWidth blueBoxWidth = redBoxHeight;
TypedWidth GreenBoxWidth = (redBoxWidth + redBoxHeight) / 2

とかコンパイルエラーになったら途方に暮れるもんな。

幅と高さは、型を分ける必要は感じないな。
熱量と体積とか、加速度と質量とかなら、型を分けて演算や代入に制限を加えるのは望ましいと思う。

499:デフォルトの名無しさん
08/03/26 14:48:04
heightとweightの話をしてるのに気づかない人がいた

500:デフォルトの名無しさん
08/03/26 15:59:06
>>496
>474に出てくる変数はすべてint型ですが？
少なくとも、今の話題にtypedefは関係ないよね。
それはまた別の話。

>>497
というかさ、コンパイラにプログラムの意味を解釈させるというのは、全く現実的な話じゃないわけさ。
プログラマの意図する「意味」とコンパイラの意図する「意味」の整合性を保つのがどれだけ大変かわかってるの？
テストを行う方が圧倒的に簡単だし、
そもそも俺には「コンパイラに意味を解釈させれば論理エラーが減る」
という考え方の方がよっぽどデバッグを大変にすると思うんだよね。

>>499
そこで質問なんだが、なぜ重さを高さに代入してはいけないの？
BMI指数なんかは、体重/身長^2 で計算するんだがこれは論理エラーなのか？
超体重理論の公式が、高さ＝重さ*2.5 だった場合はどうなんだ？
他にも、例えば Tundere = Deredere はエラーになるのか？
Yandere = Tundere の場合はどうなのか？

501:デフォルトの名無しさん
08/03/26 17:07:34
>>500
>BMI指数なんかは、体重/身長^2 で計算するんだがこれは論理エラーなのか？
BMI指数の次元が重さ/長さ^2 であるってだけのことだなぁ。

>超体重理論の公式が、高さ＝重さ*2.5 だった場合はどうなんだ？
それはきっと次元を持つ比例定数が省略されてるな。（超体重理論って何？）
PV=nRTのRみたいな。

502:デフォルトの名無しさん
08/03/26 17:19:08
URLﾘﾝｸ(www.boost.org)
C++なら次元解析なんかメタプログラミングで独自の型システム構築すればいいだけなのにね！

503:デフォルトの名無しさん
08/03/26 17:19:45
>>501
例えば、PV=nRT で V=1, nR=1 なら簡略化して P=T と書けるよね。
つまり、pressure = temperature、圧力 = 気温となるわけだ。
これは正しいんだよな？

そこで何度も同じ事を聞いて申し訳ないんだが・・・
なぜ height = weight が絶対に間違いだと言い切れるんだ？
どうして重さを高さに代入するのが「論理エラー」になるんだ？
比例定数1が隠されてる可能性は絶対にないと言い切れるのか？

504:デフォルトの名無しさん
08/03/26 17:27:12
仮にheight = weightが正しい（意図してそうする）のであれば、
型でいうところのキャストみたいに、明示すればいいということだと思う。

505:デフォルトの名無しさん
08/03/26 17:57:12
前提を隠されて「圧力 = 気温」と言われたら、間違ってるとしか言えない。
間違いと言われたくないなら前提を隠さないでくれ。

506:デフォルトの名無しさん
08/03/26 18:32:12
>>504, 505

>>474の
> int height ;
> int weight ;
> 中略
> height = weight ;

をエラーにするっていうのはこういう意味だよ。

507:474
08/03/26 18:55:09
>>500
> 少なくとも、今の話題にtypedefは関係ないよね。

いや関係ある。

1. 引数の型が違う → 型をチェックすれば、検出できる間違いがある
2. 引数の型は同じだが、値に互換性がない → 値の互換性をチェックすれば、検出できる間違いがある
3. 引数の型が同じで、値にも互換性があるが、変数を取り違えている → お手上げ

こういう3段階があるものの、基本的には同一の問題だろう。

> コンパイラにプログラムの意味を解釈させるというのは、全く現実的な話じゃないわけさ。

その通り。俺に対して反論してる人が現実的ではない話を持ち出してるだけだぞ。
なんで明らかにダメな方向に誤解して、その誤解の上でしか成りたたない反論をするんだろ。

> BMI指数なんかは、体重/身長^2 で計算するんだがこれは論理エラーなのか？

そういう計算をする関数は数が限られているのだから、
それが意図したものであれば、慎重にチェックの対象から外せばいい。

508:474
08/03/26 19:05:52
>>503
> 例えば、PV=nRT で V=1, nR=1 なら簡略化して P=T と書けるよね。

そこでスレタイ。1だからといって省略すべきではない。

そして、間違える余地を減らすためにも、
PをV、n、R、Tから求める関数を作って必ず使うようにすべき。
関数を使う以上、引数には1を渡すしかあるまい。

いまどきのコンパイラはinline展開してくれるからP=Tと同じ結果になろう。

> なぜ height = weight が絶対に間違いだと言い切れるんだ？

なぜなら、間違ってheight = weightと書いたという例だから。

>>506
色々とバグで痛い目を見ると、考え方が変ってくるかもよ。

509:デフォルトの名無しさん
08/03/26 19:45:35
>>507
型が同じか違うかで、この問題の解答が全く変わってくる。
「基本的には同一の問題」というのはダウトだろう。
実際、>>507の１，２，３で間違い検出の可能性が全く違っているし。

> なんで明らかにダメな方向に誤解して、その誤解の上でしか成りたたない反論をするんだろ。
>
>>474 を見たら、「コンパイラによる意味解釈」ということしか思いつかないのだけど。。。
他に>>474の解釈があるなら是非教えて欲しい。
「型が同じでも違っても基本的には同一の問題だから、型チェックでどうにかする」
みたいな詭弁は無しの方向で頼む

> それが意図したものであれば、慎重にチェックの対象から外せばいい。
>
チェックの対象から外すというけど、そもそもそのチェックって一体どうやってやるんだい？
型チェックなら、古の言語Ｃでもすでにやってし、
なによりそれでで解決がつくなら、>>474でint型しか出さなかった理由がわからない。
確認するけど、型チェックは大前提としあって、
他にも意味論を持ち出せばさらにバグが減らせるという主張でいいんだよね？

510:デフォルトの名無しさん
08/03/26 19:47:23
> そこでスレタイ。1だからといって省略すべきではない。
>
仮に sizeof(char) が省略すべきでないとしても、省略することは常に可能。
つまり、１は常に省略される可能性があるし、それは常に正しくあるべき。
というか、１をかけるかどうかで意味が変わってきたら、
「だから○○は使えねえんだよｗ」　（○○には好きな言語やライブラリ名をどうぞ）
とか言われそうなんだけど

> なぜなら、間違ってheight = weightと書いたという例だから。
>
たしかに>474はそれを間違いだと知ってるかもしれない。
でも、少なくとも俺にはそれが分からなかったし、もっと言えばコンパイラにはなんのことやらチンプンカンプンだろう。
なのでコンパイラにそれが間違いだと教える必要があるのだけど、それは一体どうやってやるの？

511:デフォルトの名無しさん
08/03/26 19:59:24
省略すべきでないのは型の使い分け・型変換の明示だろう。*1なんかいらない。
charとかstrlenとかをハードコーディングしちゃうのではね。

512:498
08/03/27 14:19:26
素で間違えてた。眼鏡買ってくる。

>474とそのフォロワーが何人かいるのだとおもうが、

>509
多分フォロワーは、（現実的に可能なら）型を分けるべきという議論をしていると思う。
>474は、>496でtypedefでも機械的にチェックできると言ってるが、フォロワーは同意しないかもしれない。

圧力と気温を別の型として扱う型システムが手に届くところにあったら >509 も使うでしょ？
今は自前で定義するもの大変だし定番ライブラリも無いしね。

513:デフォルトの名無しさん
08/03/27 16:10:03
関数をハードコーディング？

514:474
08/03/27 22:48:04
>>509
変数の取り間違い、という同一の問題です。
段階0として、人間が目を皿にして探す、ってのを入れてもいいよ。

> >>474 を見たら、「コンパイラによる意味解釈」ということしか思いつかないのだけど。。。
> そもそもそのチェックって一体どうやってやるんだい？

LINTの類いを使っていないと、それしか思いつかないのかもしれないね。

> >>474でint型しか出さなかった理由がわからない。

C言語のtypedefはtypedefしてたってintはintだよ。

> 確認するけど、型チェックは大前提としあって、
> 他にも意味論を持ち出せばさらにバグが減らせるという主張でいいんだよね？

「意味論」なんて持ち出してないぞ。

515:デフォルトの名無しさん
08/03/27 22:57:35
>>510
>　つまり、１は常に省略される可能性があるし、それは常に正しくあるべき。

省略したらバグるべきだとは主張してませんが?

してもしなくても動作は変らないけど、
プログラムを読んだ人間に意図がわかるようにするために省略すべきではないのよ。

> 少なくとも俺にはそれが分からなかった

例や文章が不適切でゴメンね。
でも、今までの話で分かったでしょ?

> なのでコンパイラにそれが間違いだと教える必要があるのだけど、それは一体どうやってやるの？

機械的に検出するためには、機械的に検出できるようにコーディングするのよ。
コンパイル時にエラーになるだけが、検出ではないよ。

>>513
charやwchar_tを直に書かず、マクロやテンプレートによって切り換え可能にすることに対して、
それらを直に書くことをハードコーディングというのだろう。

516:474
08/03/27 22:57:56
おう、515は名前欄かきわすれた。

517:デフォルトの名無しさん
08/03/28 00:02:37
>プログラムを読んだ人間に意図がわかるようにするために省略すべきではないのよ。
それは常識が共有できている時しか成り立たない。
変なコードが書いてあったら書いた奴に意図を聞きたくなる。

そしてスレタイ。*sizeof(char) を書くべき派といらない派は、この点において常識を共有できていない。

518:デフォルトの名無しさん
08/03/28 00:39:49
問題はいらない派がわかってて省略しているのかどうか

519:デフォルトの名無しさん
08/03/28 14:45:44
>>514
LINT の類でお勧めは何だ？

520:デフォルトの名無しさん
08/03/28 15:18:57
splint

521:デフォルトの名無しさん
08/03/28 19:25:44
>>514
> LINTの類いを使っていないと、それしか思いつかないのかもしれないね。
>
LINTでどうやって間違いを検出するのかというと・・・
Ｃ言語ならforとかwhileとかを「キーワード」という特別な扱いにして
その周辺の文法や、他にもよくありがちな構文上の間違いが無いか検証するわけね。
話を戻すとつまり、weightとかheightや他の英単語をキーワードとして扱うということ？

> C言語のtypedefはtypedefしてたってintはintだよ。
>
>>474で重要なのは、weightとheightが「同じ型である」ということなわけ。
同一の型の代入を、「変数名が間違っている」という理由でどうやってエラーにするの？
と何度も聞いているのだけど。

> でも、今までの話で分かったでしょ?
>
ぜんぜん分からないのだけど。。。
>>474は一体何が問題なのか？　というところから分からない

522:デフォルトの名無しさん
08/03/28 19:41:51
>>515
> 機械的に検出するためには、機械的に検出できるようにコーディングするのよ。
> コンパイル時にエラーになるだけが、検出ではないよ。
>
間違いを検出するのは、コンパイル時ではないということ？？？
あなたの主張が全く見えないので、以下で確認させて欲しい。

問１）　>>474は具体的にどこが間違っているのか？
１、weightとheightが同じ型であるところが間違っている。これらは型を分けるべき
２、（同じ型であっても）名前が間違っているのは明らかだから、代入したらエラーがでるべき。
３、その他

問２）　あなたのいう「機械的に検出」とは具体的にどのような方法で行うのか？
１、weightとheightの型を分ける
２、weightやheightや他の英単語をキーワードとして登録し、その使われ方をチェックする
３、コンパイラや他の何か(例えばLINTやリンカなど)に意味解析をさせる
４、その他

問３）　>>474の間違いを検出するフェーズは具体的にどこか？
１、コンパイルの開始前（いわゆるLINT）
２、字句解析時
３、構文解析時
４、構文木を作った後の独自のエラーチェック時
５、コード生成時
６、実行時
７、その他

523:474
08/03/28 22:06:15
>>521
> weightとかheightや他の英単語をキーワードとして扱うということ？

No.

> 同一の型の代入を、「変数名が間違っている」という理由でどうやってエラーにするの？

さぁ。
それはあなたが言い出したことなのだから、自分で考えてくださいな。

>>522
> 間違いを検出するのは、コンパイル時ではないということ？？？

コンパイル時に限らない。

> 問１）

3

> 問２）

4

> 問３）

7

524:デフォルトの名無しさん
08/03/28 22:10:35
ﾜﾗﾀ
答えられないのかよ

525:デフォルトの名無しさん
08/03/28 22:47:39
>>523
電波に付き合うなよ

526:デフォルトの名無しさん
08/03/28 22:56:07
適当に振ったネタが予想以上に好評でウケタｗ

527:デフォルトの名無しさん
08/03/28 23:18:40
そもそも変数名にheightやweightってつけるのは、人の目から見て意味のある名称にして
人間が間違えないようにするため。
それを機械的にって根本的におかしいだろ。

528:デフォルトの名無しさん
08/03/28 23:26:51
>>527
> なんで明らかにダメな方向に誤解して、その誤解の上でしか成りたたない反論をするんだろ。

529:デフォルトの名無しさん
08/03/29 01:45:42
趣味で独自の作法でプログラム書いてる人間には理解できない世界のお話。

530:デフォルトの名無しさん
08/03/29 16:29:22
>>524の未熟さが微笑ましい

531:デフォルトの名無しさん
08/03/29 23:11:22
世の中には、

mallocしたものをfreeするとバグの原因になるからfreeしないほうがいい
どうせプロセスが終了するときに解放されるのだから

なんて言う人もいるのですよ。

532:デフォルトの名無しさん
08/03/29 23:28:43
また古い話を持ち出してきたなぁ。

533:デフォルトの名無しさん
08/03/30 00:43:34
そのネタ飽きた

534:デフォルトの名無しさん
08/03/30 16:27:19
ていうかmallocするとバグの元になるから
そもそもなるべくmallocしないで済む設計にするのがいいよ

535:デフォルトの名無しさん
08/03/30 17:45:10
プログラム組むとバグの元になるから...

536:デフォルトの名無しさん
08/03/30 21:25:10
だからデバッグ済みのライブラリを使うのですよ。

537:デフォルトの名無しさん
08/03/30 21:51:22
そのライブラリを呼び出すコードがバグの元になるから...

538:デフォルトの名無しさん
08/03/30 21:53:52
> なんで明らかにダメな方向に誤解して、その誤解の上でしか成りたたない反論をするんだろ。

539:デフォルトの名無しさん
08/03/30 22:58:15
ネタだから。

540:デフォルトの名無しさん
08/03/30 23:37:05
ネタをネタとわからない人には（

541:デフォルトの名無しさん
08/03/30 23:51:53
>>474 が書いたコードを見てみたい・・・

何か放流してくれないかな？

542:デフォルトの名無しさん
08/06/12 07:39:29
typedef int WEIGHT;
typedef int HEIGHT;

WEIGHT weight;
HEIGHT height;

height = weight; // warning: 型の異なる代入ですというコンパイラは存在するのか

543:デフォルトの名無しさん
08/06/12 07:51:23
PODと非PODを区別しろよ

544:デフォルトの名無しさん
08/06/14 23:56:31
そういうのはクラス化するという例をEffective C++で最近読んだ。

545:デフォルトの名無しさん
08/06/15 00:44:21
>>543
そう言う問題じゃなくて、POD であることはわかってるけど、
プログラマが別の型と定義したんだから、警告するようにすれば
身長 × 体重なんてしてしまうバグを減らせると言うことなんだ
ろう。

>>542
言語は違うけど、Pascal とか Ada はそう言う型を定義できる。
現状の枠内でやろうとするなら、>>544 の方法がいいと思う。

546:デフォルトの名無しさん
08/09/16 23:54:11
strong typedefを知らずにこんなスレに書き込む奴がいたのか
2008年だぞ今年…

547:デフォルトの名無しさん
08/09/17 09:21:36
後からのこのこ現れて間抜けな事を書き捨てていく奴って何なの？
流行ってんの？

548:デフォルトの名無しさん
08/09/17 23:29:21
>>547
よう、低脳

549:デフォルトの名無しさん
08/09/18 00:57:02
>>548
よう、ド低脳

550:デフォルトの名無しさん
08/09/18 07:56:04
独自の拡張にメリットを見い出せないからこそBOOST(ライブラリ)やD(派生言語)でstrong typedefを実現しているのだけれど
>>547
間抜けだという理由をどうぞ
さぞかし説得力のある解説をして下さるのだろう

単純に既存のC/C++処理系の拡張としてtypedef警告が実装されていたら
WindowsやOpenGLのプログラムなんてやってられないと思うのだがね

551:デフォルトの名無しさん
08/09/18 08:41:21
3ヶ月も経ってからレスしてたらやっぱり間抜けだろ。

552:デフォルトの名無しさん
08/09/18 11:44:15
ｽﾚ違い…ってのはまあ、3月以降全部そうか。

553:デフォルトの名無しさん
08/09/18 17:42:08
>>551
わざわざ煽りレスして理由がそれってのは苦しいと思うが…

554:デフォルトの名無しさん
08/09/21 05:21:06
IDないと句読点や三点リーダの不備が余計目立つな。

555:デフォルトの名無しさん
08/09/21 06:25:06
日本語でokというか、独り言なら書かなくてよし

556:デフォルトの名無しさん
08/10/20 09:05:31
馬鹿な＞１っているもんだな

557:デフォルトの名無しさん
08/10/24 01:19:22
#define strlen(a)
って宣言してみる。