- 1 名前：デフォルトの名無しさん mailto:sage [2008/01/24(木) 14:52:45 ]
- このスレは標準C規格や規格に合致した移植性の高い記法・技法に関するスレです。
C言語初心者の初歩的な質問、GUIなどの標準Cではできない事の質問、
ソース丸投げ、宿題、書籍 などは専門の別スレッド↓があるのでそちらへ。
Ｃ言語なら俺に聞け（入門篇） Part 24
pc11.2ch.net/test/read.cgi/tech/1201083176/
【初心者歓迎】C/C++室 Ver.47【環境依存OK】
pc11.2ch.net/test/read.cgi/tech/1200464091/
C/C++の宿題を片付けます 103代目
pc11.2ch.net/test/read.cgi/tech/1200318925/
【書き込む前に】
・まず問題を冷静に吟味してCの話か否かをはっきりさせてから質問しましょう。
・質問する前には最低限検索を。
・エラー(警告含む)が起きたのならばエラーメッセージを書きましょう。
【参考文献】
C FAQ 日本語訳
www.kouno.jp/home/c_faq/
Cプログラマ必読 ・プログラミング言語C(通称 K&R)
www.amazon.co.jp/exec/obidos/ASIN/4320026926/250-7563469-9920244
【このスレのログ】
前スレ：pc11.2ch.net/test/read.cgi/tech/1190261457/
他の過去ログ：nssearch.hp.infoseek.co.jp/clang/
【このスレ住人としての心得】
わざとスレ違いあるいはごく低レベルな質問を繰り返して
流れを妨害する荒らしがいます。適当に誘導して放置してください。
- 141 名前：デフォルトの名無しさん mailto:sage [2008/04/23(水) 23:14:40 ]
- >>137
> 未定義なので実装依存と書けばいいの？
違う。
未定義は何が起っても文句を言うなと言うこと。
(実行したらＰＣが壊れるような実行ファイルを生成しても規格には違反しない。)
実装依存は何が起るかは環境によって違うけど、環境毎に何が起るかは決まってい
ると言うこと。
>>137, >>139-140
すまん、仮定義のことすっかり忘れてた。
- 142 名前：デフォルトの名無しさん mailto:sage [2008/04/23(水) 23:23:02 ]
- 未定義は規格は挙動を定義しないということで、
何が起こっても規格に反しないということではあるが、
処理系独自に挙動を定義することまでを禁止する物でもない。
もちろん、それに頼ったコードは通常移植性が低い訳だが。
処理系依存は処理系ごとに挙動を定義することが求められている。
未規定は未定義と似ているが、
正常なコードの中で挙動がきちんと定められていないものを言う。
関数の引数に書かれた式の評価順とか。
- 143 名前：デフォルトの名無しさん mailto:sage [2008/04/24(木) 00:20:37 ]
- 仮定義は初耳でした、勉強になりました
ありがとうございます
- 144 名前：デフォルトの名無しさん mailto:sage [2008/04/24(木) 00:30:36 ]
- うげ、仮定義って翻訳単位跨いでも使えるのか。
知らなかった。
- 145 名前：デフォルトの名無しさん mailto:sage [2008/04/24(木) 00:49:31 ]
- 本当に翻訳定義またいで使えたっけ？
- 146 名前：デフォルトの名無しさん mailto:sage [2008/04/24(木) 01:24:54 ]
- 規格を見る限り、仮定義があると翻訳単位の一番下に = 0 で初期化された宣言があると見なされるようだ。
複数の翻訳単位がある場合は二重定義になりそう？
- 147 名前：デフォルトの名無しさん mailto:sage [2008/05/05(月) 14:08:05 ]
- >>141-142
処理系依存・実装依存は処理系定義(implementation-defined)だけじゃない。
適当なこと言うなよ。
未定義・未規定・処理系定義
どれも処理系の実装に依存してるだろ。
- 148 名前：デフォルトの名無しさん mailto:sage [2008/05/05(月) 14:20:11 ]
- 処理系定義は実装には依存しないだろ。
- 149 名前：デフォルトの名無しさん mailto:sage [2008/05/05(月) 14:22:21 ]
- 実装によって挙動が違うことを規格が許している、ことを
実装に依存している、と言うのであって、
処理系定義は実装に依存していると思うが？
- 150 名前：デフォルトの名無しさん mailto:sage [2008/05/05(月) 14:28:03 ]
- 処理系定義は仕様としての表明であり、実装とは切り離されている。
具体的なモノとは分けて考えるべきだろう。
- 151 名前：デフォルトの名無しさん mailto:sage [2008/05/05(月) 15:08:26 ]
- JISでは処理系と訳されてるけどimplementation definedだから「実装」だべ
- 152 名前：デフォルトの名無しさん mailto:sage [2008/05/05(月) 15:18:25 ]
- その文脈で
>>147
>どれも処理系の実装に依存してるだろ。
の意味を説明できるのか？
- 153 名前：デフォルトの名無しさん mailto:sage [2008/05/05(月) 15:28:53 ]
- >>147 おおむねこんな意味かい?
処理系定義: 動作も結果も保証しないがどうのような振る舞いを示すかは
処理系が保証しなければならない
未規定: 動作の保証はないし処理系の振る舞いによって何が起るかは
不明
未定義: 何が起っても文句は言えない.
処理系自体も振る舞いを規定する必要はない
- 154 名前：デフォルトの名無しさん mailto:sage [2008/05/05(月) 15:31:09 ]
- そもそもX3010に〜依存って言葉はあるんでしょうか？
- 155 名前：デフォルトの名無しさん mailto:sage [2008/05/05(月) 15:36:43 ]
- >>153
未規定：規格が動作を明示することを求めいていない
例）関数の実引数は、どれから評価してもよいし、明示する必要もない。
- 156 名前：デフォルトの名無しさん mailto:sage [2008/05/05(月) 15:37:40 ]
- ない。
一部の人間が勝手にimplementation definedと混同してるだけ。
>>136とか>>141とか>>142とか
- 157 名前：デフォルトの名無しさん mailto:sage [2008/05/05(月) 16:07:28 ]
- 「規格が明確に定義していない」には3種類あって、以下のように定義されている。
・処理系定義（implementation defined）の動作
どう動作するかを実装が選択する。そのプログラムがコンパイルできないというのは許されない。
（この構成概念を使ったプログラムは誤りというわけではない。）
（実装が）何を選んだかは（コンパイラの作者が）文書にしておかなければならない。
規格が合法な動作をいくつか用意していてそこから選ぶことができるかもしれないし、
必要条件をとくに課していないかもしれない。
・未規定（unspecified）の動作
処理系定義の動作に似ている。ただし、どういう動作を選んだかは文書にする必要がない。
・未定義（undefined）の動作
本当に何が起きても不思議はないことを意味する。規格は何の必要条件も課さない。
コンパイルできないかもしれないし、誤った動きをするかもしれないし
（クラッシュしたり黙って誤った結果を出したり）、
あるいはたまたまプログラマの意図したとおりの動きをするかもしれない。
以上、CFAQより抜粋
- 158 名前：デフォルトの名無しさん mailto:sage [2008/05/05(月) 17:52:27 ]
- もうメタ議論くらいしかすることないのな
- 159 名前：デフォルトの名無しさん mailto:sage [2008/05/05(月) 21:08:20 ]
- うん。
- 160 名前：デフォルトの名無しさん mailto:sage [2008/05/06(火) 01:46:45 ]
- >154 >156
ただ、CFAQには「実装依存」を「処理系定義の動作」という意味で使っている場所がある。
正確ではないが、その言葉に出くわして意味を解釈する必要があるときは、そのように読むのが一般的であるかもしれない。
- 161 名前：デフォルトの名無しさん mailto:sage [2008/05/06(火) 05:08:14 ]
- それはimplementation definedの正確でない訳だったりしないの?
- 162 名前：>>136 mailto:sage [2008/05/06(火) 11:07:05 ]
- 一般的な機論において、特に混乱するわけでもないから「〜依存」って
書いてるだけ。後出しで X3010 出してきて混同してるとか言われても、
「また KY 君かよ」としか思えない。
- 163 名前：デフォルトの名無しさん mailto:sage [2008/05/06(火) 11:13:34 ]
- >>161
当たったところ、原文では implementation-defined と書いてあった。
ただそもそも日本語で実装依存といった場合におおよそ何を意味するかという話であるので
（だから正確でないのは承知の上であることは書いた）。
- 164 名前：デフォルトの名無しさん mailto:sage [2008/05/06(火) 22:59:28 ]
- つまり
「実装依存」は場面によって指している物が違うから
implementation definedの訳としては使わないほうがよい。
ということだな。
- 165 名前：デフォルトの名無しさん mailto:sage [2008/05/07(水) 00:01:21 ]
- implementationは普通に訳せば実装という意味だから処理系定義という訳もアレかもしれんがな
「実装依存」そのまんまの意味であるimplementation-dependentはかなり広く使われてるようだが特定の言語に限った話じゃないしね
- 166 名前：デフォルトの名無しさん mailto:sage [2008/05/07(水) 01:26:51 ]
- 一般の議論ではよく使われる「依存」だが、このスレでは非推奨の
用語ということにしたほうがよさそうだな。
このスレでは直訳した「実装定義」か、JIS用語の「処理系定義」、
「未規定」、「未定義」を使い分けるということで。
- 167 名前：デフォルトの名無しさん mailto:sage [2008/05/16(金) 13:13:18 ]
- C++ が存在するのに新しい C 言語の仕様を策定するのは、C++ のコンパイラは
実装が難しいからですか?
- 168 名前：デフォルトの名無しさん mailto:sage [2008/05/16(金) 13:32:46 ]
- C++はCの上位集合ではありませんが？
- 169 名前：デフォルトの名無しさん mailto:sage [2008/05/16(金) 15:05:56 ]
- 上位集合ではないが、ほとんどの場合ソースを変更する必要がないか、
少し変えれば両方で動くようになる。
C99 のように C++ との互換性に問題を作ってまで新しい仕様を作る
必要はないんじゃないか?
- 170 名前：デフォルトの名無しさん mailto:sage [2008/05/16(金) 15:49:33 ]
- C++なんかどうでもよくね
- 171 名前：デフォルトの名無しさん mailto:sage [2008/05/16(金) 20:03:05 ]
- C99なんて誰も必要としていない
- 172 名前：デフォルトの名無しさん mailto:sage [2008/05/16(金) 23:16:34 ]
- inlineとか変数宣言のブロック先頭縛り廃止とかのC++追随と
vsnprintfにlong longなど有名どころの独自拡張の追認だけにしておけば、
もう少し広まった気がする。
- 173 名前：デフォルトの名無しさん mailto:sage [2008/05/16(金) 23:21:10 ]
- Bjarne 先生に相談しないで仕様を決めてしまったのかな。
- 174 名前：デフォルトの名無しさん mailto:sage [2008/05/17(土) 00:14:23 ]
- スレ違い
- 175 名前：デフォルトの名無しさん mailto:sage [2008/05/17(土) 09:22:23 ]
- 構造体の宣言と同時に初期化は有用
- 176 名前：デフォルトの名無しさん mailto:sage [2008/05/17(土) 09:27:21 ]
- C++も0xで対応するんじゃなかったっけ
initializer_listとか
- 177 名前：デフォルトの名無しさん mailto:sage [2008/05/17(土) 11:17:20 ]
- いちいち構造体のタグ名の前に struct を付けないといけないのは面倒くさい。
typedef しなくてもタグ名をそのまま型名として使えるようにしてほしい。
- 178 名前：デフォルトの名無しさん mailto:sage [2008/05/17(土) 12:01:17 ]
- C++でもつかっとけ
- 179 名前：デフォルトの名無しさん mailto:sage [2008/05/17(土) 13:19:14 ]
- コンストラクタはいらないがデストラクタが欲しい。
- 180 名前：デフォルトの名無しさん mailto:sage [2008/05/17(土) 17:11:10 ]
- typedef すればいいから正直あまり困らないな ＞struct
- 181 名前：デフォルトの名無しさん mailto:sage [2008/05/17(土) 23:03:42 ]
- 自分へのポインタを持つ構造体宣言するときにちょっと書くワードが多いくらいだろう
大した問題じゃない
というか自分はC++でも typedef struct … しちゃうな、なんとなく気持ち悪くて
- 182 名前：デフォルトの名無しさん mailto:sage [2008/05/18(日) 01:22:06 ]
- 自分へのポインタを持つ構造体も、事前に typedef しとけば・・・
って、その typedef を書く必要があるから結局は面倒なんだが。
- 183 名前：デフォルトの名無しさん mailto:sage [2008/05/18(日) 03:02:46 ]
- Cでstruct tagを自動でtypedefしないのは、名前空間の問題にひっかかるからかな？
- 184 名前：デフォルトの名無しさん mailto:sage [2008/05/18(日) 03:08:40 ]
- 特に理由はなかったんだろう。
何となく struct を付けた方がいいんじゃね？ と思って仕様を作った。
でも、実際には面倒臭かったので C++ では必須ではなくなった。
それだけのことなんだろう。
- 185 名前：デフォルトの名無しさん mailto:sage [2008/05/18(日) 03:24:45 ]
- 名前空間は、新規格で導入しない理由のひとつではあると思う。
構造体（共用体）タグが「通常の識別子」として扱われる改定がされた場合でも、
逆に従来の構造体タグ名前空間のままでtypedefされる改定となった場合でも、
もし過去にそうならないことに因って書かれたコードがあったらコンパイルできなくなる。
どちらでもない新しい名前空間を作るにしても、旧来のコンパイラを改良する手間は
名前空間の管理に手を入れる関係上、それなりの手間が必要になる。
そこまでして導入するほどの問題では絶対にない。と思う。気がする。
- 186 名前：デフォルトの名無しさん mailto:sage [2008/05/18(日) 04:01:36 ]
- structってつけてくれた方が構文解析が楽だから、とかはさすがにないか。
- 187 名前：デフォルトの名無しさん mailto:sage [2008/05/18(日) 11:01:15 ]
- 多分そうだと思う。
変数がブロックの先頭でしか宣言できないのも抽象構文木の構造に自然に合うからだと思う。
現在の C から派生した言語はほとんどこういう制限はない。
- 188 名前：デフォルトの名無しさん mailto:sage [2008/05/18(日) 11:37:50 ]
- 昔はマシンが非力だったから
少しでも楽にしたかったのかもしれないね。
- 189 名前：デフォルトの名無しさん mailto:sage [2008/05/18(日) 12:12:20 ]
- 配列の境界検査をしない、という仕様がまさにそれ
- 190 名前：デフォルトの名無しさん mailto:sage [2008/05/18(日) 12:13:10 ]
- しないと言い切るとこのスレ的には間違ってるか
境界検査をしなくてもよい、だな
- 191 名前：デフォルトの名無しさん mailto:sage [2008/05/18(日) 12:41:11 ]
- C++ の std::vector も境界チェックを行う at と行わない operator[] を用意してるから
非力だったからやらない、というわけではないと思われ。
- 192 名前：デフォルトの名無しさん mailto:sage [2008/05/18(日) 12:44:49 ]
- 安全と効率を天秤に掛けて、効率を取る漢らしい言語なんです
- 193 名前：デフォルトの名無しさん mailto:sage [2008/05/18(日) 12:46:03 ]
- []で境界チェックしないのはCとの互換性のためだろ
未定義動作に互換性もへったくれもない気がするけど
- 194 名前：デフォルトの名無しさん mailto:sage [2008/05/18(日) 12:46:22 ]
- 可能な限り、安全は言語でサポートするものではなく
ライブラリでサポートするべき、って感じだな。
最大限の効率を約束する。
- 195 名前：デフォルトの名無しさん mailto:sage [2008/05/18(日) 12:46:57 ]
- >>193
std::vector は C にないから
互換性なんてどうでもいいと思われるが。
- 196 名前：デフォルトの名無しさん mailto:sage [2008/05/18(日) 13:10:54 ]
- VRAM直書きの時、境界検査されたらちょっとヤだな。
- 197 名前：デフォルトの名無しさん mailto:sage [2008/05/18(日) 13:26:26 ]
- 論理エラーまでチェックしていたら OS なんて書ける性能はでないよ。
- 198 名前：デフォルトの名無しさん mailto:sage [2008/05/18(日) 15:06:53 ]
- >>195
メモリ配置の連続性要求はCとの互換性のため
- 199 名前：デフォルトの名無しさん mailto:sage [2008/05/18(日) 15:08:34 ]
- >>198
連続性要求と境界チェックは別の話だっしょ。
- 200 名前：デフォルトの名無しさん mailto:sage [2008/05/18(日) 15:30:03 ]
- 境界チェックしてほしいなら /RTCs を付ければいいよ。VC 以外は知らない。
- 201 名前：デフォルトの名無しさん mailto:sage [2008/05/18(日) 16:06:54 ]
- >>199
連続性要求と境界チェックは同じだとは言っていない。
「互換性なんてどうでもいい」なら連続性要求も必要ないはずだと言いたいだけ
- 202 名前：デフォルトの名無しさん mailto:sage [2008/05/18(日) 16:12:50 ]
- 俺のカンでは話がかみあってないな
- 203 名前：>>136 mailto:sage [2008/05/18(日) 16:13:31 ]
- >>196
VRAM サイズの配列を宣言して、VRAM のアドレスにマップできるようにすればいいだけ。
>>197
いつの時代だよ。
爺は早めに引退しとけ。
- 204 名前：デフォルトの名無しさん mailto:sage [2008/05/18(日) 16:14:08 ]
- >>201
普通の配列の話じゃなくて std::vector の話なんだけどな。
普通の配列に関しては互換性も理由の１つだろう（それだけじゃないとは思うが）。
- 205 名前：デフォルトの名無しさん mailto:sage [2008/05/18(日) 16:14:46 ]
- >>203
そうやってどんどん OS を重くしてるから
Vista みたいに叩かれるんだよ
- 206 名前：デフォルトの名無しさん mailto:sage [2008/05/18(日) 16:33:09 ]
- >>204
配列じゃなくてstd::vectorに連続性要求があるんだけど
- 207 名前：デフォルトの名無しさん mailto:sage [2008/05/18(日) 16:52:19 ]
- まぁ「レガシーAPIにstd::vector渡せますか？」
というのはC++のFAQだよな
次の規格ではstd::stringもそうなるんだっけ
- 208 名前：デフォルトの名無しさん mailto:sage [2008/05/18(日) 16:57:42 ]
- std::string::c_str() があるのにそんな必要あるの?
- 209 名前：デフォルトの名無しさん mailto:sage [2008/05/18(日) 17:07:54 ]
- 現在のc_strはコピーが発生する可能性があってパフォーマンスに響くかもしれない。
- 210 名前：デフォルトの名無しさん mailto:sage [2008/05/18(日) 17:10:49 ]
- どう考えても>193がおかしい
Cにはvectorが存在しないのだから互換性が問題になるはずがない
- 211 名前：デフォルトの名無しさん mailto:sage [2008/05/18(日) 17:12:25 ]
- Cで書かれたライブラリとのバイナリ互換性とか
- 212 名前：デフォルトの名無しさん mailto:sage [2008/05/18(日) 17:50:29 ]
- >>206
だから連続性要求の話なんて誰もやってないんだってば・・・。
境界チェックの話だ。
- 213 名前：デフォルトの名無しさん mailto:sage [2008/05/18(日) 17:53:11 ]
- そもそもだなぁ
なんで std::string::c_str() な話がこのスレで出てくる？
- 214 名前：デフォルトの名無しさん mailto:sage [2008/05/18(日) 18:11:46 ]
- もし境界チェックを行う必要が無いという仕様が
大昔はマシンパワーが弱かったからという問題で作られたのなら
C++ を作る時に std::vector で at でも operator[] でも境界チェックをすれば良かった。
でもそうしなかったということは、それだけの問題じゃないってことだろう。
という話。
- 215 名前：デフォルトの名無しさん mailto:sage [2008/05/18(日) 18:16:35 ]
- だからCもC++も基本的に効率側に仕様を倒すんだよ
安全性はライブラリで頑張る方針
- 216 名前：デフォルトの名無しさん mailto:sage [2008/05/18(日) 18:22:08 ]
- そういうこと。
昔マシンパワーが弱かったからじゃなくて、
マシンパワーに関わらず効率を取るってこった。
- 217 名前：デフォルトの名無しさん mailto:sage [2008/05/18(日) 18:31:08 ]
- マシンパワーが高くなっても 10 分かかっている処理は速い言語で 5 分にしたいよ。
アプリにもよるけど。
- 218 名前：デフォルトの名無しさん mailto:sage [2008/05/18(日) 18:32:57 ]
- >>215
> 効率側に仕様を倒す
ちゃう, 特に C に関しては高級言語だと思ってはいけない
freestanding な環境でも動作可能, つか, 標準ライブラリを使用せず
(libgcc とかは微妙だけど)に動作可能なバイナリを吐き出せる事も
求められている.
実際 crt.o を自前で書けば, 標準ライブラリを使わずに実行イメージを
作ることが可能(しつこいけど libgcc とかは微妙)
境界チェックに関しては微妙だけど...
- 219 名前：デフォルトの名無しさん mailto:sage [2008/05/18(日) 18:34:22 ]
- >>212
だから境界チェックしてない理由(の1つ)に連続性要求と同じ理由は考えられないのかと
言ってるだけなんだが。
std::vectorがCにないから互換性の問題がないなら
operator[]で境界チェックをやることだって互換性の問題を起こさない
- 220 名前：デフォルトの名無しさん mailto:sage [2008/05/18(日) 18:39:34 ]
- >>219
連続性要求は C++98 ではなく C++03 で導入された。
- 221 名前：デフォルトの名無しさん mailto:sage [2008/05/18(日) 19:19:52 ]
- >>203
世の中Cで書いたプログラムのターゲットは3GHzクラスばかりじゃないんだよ。
- 222 名前：デフォルトの名無しさん mailto:sage [2008/05/18(日) 19:37:35 ]
- >193は自分のレスをもう一回冷静に読み直せ
>191はvectorの境界チェックのみの話しかしていない
だからそもそも互換性や連続性の話は関係ない
お前が勝手にoperator[]全般の話を持ち出したから話がかみ合ってないだけだ
- 223 名前：デフォルトの名無しさん mailto:sage [2008/05/18(日) 19:43:16 ]
- これは俺のカンだけど
>>193はoperator[]はあらゆるオブジェクトで同じもんだと思ってるね
でなきゃ互換性なんてセリフ出るはずがない
- 224 名前：デフォルトの名無しさん mailto:sage [2008/05/18(日) 19:48:39 ]
- >>219
vectorの連続性要求の理由はそのほうが直感的かつ便利だからであってCとの互換性からではない。
なぜならvectorはCに存在しないから。C++にしか存在しないものがCとC++の間での互換性で問題になる は ず が な い 。
- 225 名前：デフォルトの名無しさん mailto:sage [2008/05/18(日) 19:50:43 ]
- >>224 だったらスレタイ読んで出直してこい
- 226 名前：デフォルトの名無しさん mailto:sage [2008/05/18(日) 19:53:11 ]
- >>225
お前はレスの流れを読むべきだな
- 227 名前：デフォルトの名無しさん mailto:sage [2008/05/18(日) 21:48:21 ]
- >>221
で、それがどうかしたのか？
非常にタイトな部分には、チェックをはずせるようにしとけばいいだけだろ。
しょぼい環境の奴は、頭もしょぼいのか？ (w
- 228 名前：デフォルトの名無しさん mailto:sage [2008/05/18(日) 21:52:24 ]
- 仕様と処理系の区別もつかないくらい耄碌してるのか。
- 229 名前：デフォルトの名無しさん mailto:sage [2008/05/18(日) 23:26:28 ]
- 「ディフォルトは検査するが、指定した部分の検査をしなくてもいいように指示できる」
と言う言語仕様にすればいいだけ。
どこに処理系の話が出てくるんだ？
# 耄碌爺って他人を耄碌してると思いたがるよな。(w
- 230 名前：デフォルトの名無しさん mailto:sage [2008/05/18(日) 23:33:09 ]
- C言語の仕様は
「チェックなんて効率の悪い事はデフォルトではしない。検査は各々自己責任でやれ」
というスタンスなんだよ
- 231 名前：デフォルトの名無しさん mailto:sage [2008/05/19(月) 00:14:36 ]
- 耄碌してんじゃなくて若くて無知なだけだったか。
- 232 名前：デフォルトの名無しさん mailto:sage [2008/05/19(月) 00:21:52 ]
- >>230-231
はぁ？ いまごろ何言ってんの？
そんなこと >>192 に書いてある。
耄碌爺はちょっと前のレスすら覚えてないらしいな。
病院に行った方がいいぞ。
- 233 名前：デフォルトの名無しさん mailto:sage [2008/05/19(月) 01:14:18 ]
- 話の整理
197 「Cぐらい男らしい言語じゃないとOSなんて組めないよねー」
↑ 偏見というほどでもないがたぶん誇張
203 「そんなことはない、今のマシンのスペックなら（他の言語でも）十分いけるよ」
↑ 正しいとは言い切れないが間違いではない
221 「そんな高スペックの環境ばかりじゃないんだよ」
↑ ここがずれてる 203はそんな環境でCでない（チェックの厳しい）言語を使えとは言ってない
227 「低スペックな環境なら（その言語の機能で）チェック外すようにできればいいだろ」
↑ まあ正論
230 「Cはそういう言語じゃないんだよ」
↑ Cでない言語の話をCの話と勘違いしている
というわけで話の理は203にある
だが煽るのはやめろ
- 234 名前：デフォルトの名無しさん mailto:sage [2008/05/19(月) 02:40:18 ]
- 自演乙、と言えばいいのか？
- 235 名前：デフォルトの名無しさん mailto:sage [2008/05/19(月) 05:16:42 ]
- すっかり違う言語にかわっちゃうような機能を、オプションでつけはずし？
配列とポインタが交換可能なのはC言語の特徴ですよ。
ポインタが配列を指してるかどうかのチェックからするんですか？
- 236 名前：デフォルトの名無しさん mailto:sage [2008/05/19(月) 05:47:52 ]
- ああ、そうか、>>203は最初からC言語の話なんかしてないのか。
>>233 解説ありがとう。
ということで、スレ違いだな。
- 237 名前：デフォルトの名無しさん mailto:sage [2008/05/19(月) 12:44:06 ]
- C言語は最適化のヒントを与える機能を追加すれば後は拡張しなくていいよ。
C言語の役割はある程度ポータビリティーがあって可能な限り性能を出すこと。
どんなに CPU の性能が上がってもこの需要はなくならない。
- 238 名前：デフォルトの名無しさん mailto:sage [2008/05/19(月) 15:40:22 ]
- できることが増えるスピードよりやりたいことが増えるほうが速いからな
- 239 名前：デフォルトの名無しさん mailto:sage [2008/05/19(月) 22:33:30 ]
- >>235
相変わらず、頭固いネェ。
> 配列とポインタが交換可能なのはC言語の特徴ですよ。
未だに配列アクセスよりポインタアクセスの方が常に速いとか
思ってるんだろうな...。
- 240 名前：デフォルトの名無しさん mailto:sage [2008/05/20(火) 06:08:38 ]
- 頭の固い人間 VS 論点がズレている人間
の対決はいつ見ても不毛
- 241 名前：デフォルトの名無しさん mailto:sage [2008/05/20(火) 10:01:59 ]
- >>239
君の脳内言語の話はスレ違いだ。
|
 |
