【初心者お断り】ガチ規格準拠C専用スレ Part133

[表示 : 全て最新50 1-99 101- 201- 301- 2chのread.cgiへ]
Update time : 05/09 17:48 / Filesize : 70 KB / Number-of Response : 365
[このスレッドの書き込みを削除する]
[＋板最近立ったスレ＆熱いスレ一覧 : ＋板最近立ったスレ／記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

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/

【このスレ住人としての心得】
わざとスレ違いあるいはごく低レベルな質問を繰り返して
流れを妨害する荒らしがいます。適当に誘導して放置してください。
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
君の脳内言語の話はスレ違いだ。
242 名前：デフォルトの名無しさん [2008/05/20(火) 22:05:48 ]: C言語をはじめたばかりであまりわからないのですが、
ビットシフトはなんの役に立つのでしょうか？
243 名前：デフォルトの名無しさん mailto:sage [2008/05/20(火) 22:23:18 ]: >>242
それなんてコピペ？

こんな感じでよろしいか？
244 名前：デフォルトの名無しさん mailto:sage [2008/05/20(火) 22:27:14 ]: おｋ
245 名前：デフォルトの名無しさん mailto:sage [2008/05/21(水) 00:41:16 ]: >>241
反論できなくなったら、脳内言語ときたか。

だったら、>>221 あたりでそう書きゃいいと思うが、
しょせん耄碌爺には無理か。(w
246 名前：デフォルトの名無しさん mailto:sage [2008/05/21(水) 01:18:38 ]: 煽るな
247 名前：デフォルトの名無しさん mailto:sage [2008/05/21(水) 01:38:16 ]: >>245
>>233 >>236
248 名前：デフォルトの名無しさん mailto:sage [2008/05/21(水) 10:51:11 ]: >>245
つまりこういう事だな。
「脳内言語だって気が付くのが遅せーんだｙｐ」
249 名前：デフォルトの名無しさん mailto:sage [2008/05/21(水) 23:45:16 ]: 昔の知識で煽ったら、反撃くらって撃沈しただけだろ。
250 名前：デフォルトの名無しさん mailto:sage [2008/05/22(木) 01:22:46 ]: 俺言語の話なんかする奴が悪いな
251 名前：デフォルトの名無しさん mailto:sage [2008/05/22(木) 04:36:43 ]: 俺言語君の知識は、最近のCPUは速いって事だけだったからな。
反論する余地は無いな、たしかに。
252 名前：デフォルトの名無しさん mailto:sage [2008/05/22(木) 07:42:58 ]: お前らも煽るな
253 名前：デフォルトの名無しさん mailto:sage [2008/05/22(木) 10:44:54 ]: 大勢のフリした一人だろ。煽っているのは。
254 名前：デフォルトの名無しさん [2008/05/22(木) 11:51:11 ]: おやそくの一言が出ました。
255 名前：デフォルトの名無しさん mailto:sage [2008/05/22(木) 11:55:57 ]: お夜食？
256 名前：デフォルトの名無しさん mailto:sage [2008/05/22(木) 12:18:30 ]: ↓　タイプミスをプギャーして勝ち誇るAAをどーぞ
257 名前：デフォルトの名無しさん mailto:sage [2008/05/22(木) 12:19:49 ]: m9（＾д＾）
258 名前：デフォルトの名無しさん mailto:sage [2008/05/22(木) 17:41:00 ]: ぐぐってもプギャーの意味分からなかった。
259 名前：デフォルトの名無しさん mailto:sage [2008/05/22(木) 22:44:05 ]: > 俺言語君の知識は、最近のCPUは速いって事だけだったからな。
> 反論する余地は無いな、たしかに。

にもかかわらず反論してた爺は哀れだな。(w
260 名前：デフォルトの名無しさん mailto:sage [2008/05/23(金) 05:38:05 ]: いつまでも爺爺言ってる奴が根に持ちすぎてて怖い
将来犯罪起こしそうだな
261 名前：デフォルトの名無しさん mailto:sage [2008/05/23(金) 07:38:27 ]: 脳内言語だと解ってからは、だれも反論なんかしちゃいないのにな。
262 名前：デフォルトの名無しさん mailto:sage [2008/05/23(金) 23:57:40 ]: >>261
> 脳内言語だと解ってからは、だれも反論なんかしちゃいないのにな。

>> 反論してた

爺は日本語も不自由らしい。(w
263 名前：デフォルトの名無しさん mailto:sage [2008/05/24(土) 01:01:27 ]: 俺言語の話してるのに、C言語の話だと思って反論してやんのプギャー
こうですね、よくわかります。
264 名前：デフォルトの名無しさん mailto:sage [2008/05/24(土) 01:50:10 ]: ひっかかった、くやしいムキー。
こうですね、よくわかります。
265 名前：デフォルトの名無しさん mailto:sage [2008/05/24(土) 02:09:10 ]: いつまでやってんの！
266 名前：デフォルトの名無しさん mailto:sage [2008/05/24(土) 02:26:07 ]: ケンカはやめて（＞＜）
267 名前：デフォルトの名無しさん mailto:sage [2008/05/24(土) 11:46:20 ]: 爺で検索すればいいからわかりやすいな
268 名前：デフォルトの名無しさん mailto:sage [2008/05/24(土) 17:49:54 ]: C89 との違いのみを完全に全て列挙したような資料ってありますか？
269 名前：デフォルトの名無しさん mailto:sage [2008/05/24(土) 17:51:43 ]: C89 と C99 との違い・・・です。
270 名前：デフォルトの名無しさん mailto:sage [2008/05/24(土) 18:03:32 ]: 完全かどうかは知らないけど
seclan.dll.jp/c99d/
とか

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef