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

sizeof(char)が必ず1� ..

159:デフォルトの名無しさん
07/08/22 09:47:48
>>156
＞sizeof(char)を復元する必要
Cの仕様が変更にならない限りその必要は無いからな
どうだろうな

160:デフォルトの名無しさん
07/08/22 12:46:00
subversionでいいじゃん

161:デフォルトの名無しさん
07/08/22 21:07:24
…そう言って通る職場なら良いけどな

162:デフォルトの名無しさん
07/08/22 21:54:59
svn厨は退場してください

163:デフォルトの名無しさん
07/08/22 22:36:22
じゃあＣＶＳで・・・ごめん、悪かった

164:デフォルトの名無しさん
07/08/22 22:51:41
それならよし！

165:デフォルトの名無しさん
07/08/22 23:00:05
それでいいんかい！

166:デフォルトの名無しさん
07/08/23 01:40:32
ふつーbzr

167:デフォルトの名無しさん
07/08/23 20:54:00
もうねmallocなんてあちこちで書いてちゃだめなんだよ。
ラッパーとか言うのも違うな。
構造化だよ。オブジェクトを作る段でだけ利用するんだ。
そもそもＣ＋＋の偉い人がnewなんてすばらしい関数を
用意してくれているんだから、new使えよ。

168:デフォルトの名無しさん
07/08/23 21:34:07
Ｄの偉い人が動的配列なんてすばらしい機能を
用意してくれているんだから、動的配列使えよ。

169:デフォルトの名無しさん
07/08/23 21:54:16
vector使うお！！

170:デフォルトの名無しさん
07/08/24 00:15:47
え？newって関数なの？演算子かと思ってたんだが・・・

171:デフォルトの名無しさん
07/08/24 00:20:10
C++のnewは演算子だな。

172:デフォルトの名無しさん
07/08/24 00:32:18
newだって寿命管理はプログラマがやらなきゃいけないわけで、
mallocと同じように、
考えて使うところを狭めないと、
収拾が付かなくなる。

173:デフォルトの名無しさん
07/08/24 00:32:33
ってことはoperator newでオーバーロードできたりするの？

174:デフォルトの名無しさん
07/08/24 01:24:37
>>173
何を今更。だからやろうと思えばOS管理外からメモリを引っ張ってくる事だってできる。

175:デフォルトの名無しさん
07/08/24 01:44:33
smart_ptr<T> ptr = Allocator<T>();
みたいなカスタムアロケータ用意するとか

176:デフォルトの名無しさん
07/08/24 09:39:31
演算子は全て関数だと乱暴な言い方も当然出来る。

177:デフォルトの名無しさん
07/08/24 11:39:47
>>176
挙動が違うんだけど。

178:デフォルトの名無しさん
07/08/24 19:45:47
で、sizeof(char)の省略いいの？わるいの？

179:デフォルトの名無しさん
07/08/24 19:48:27
いい

180:デフォルトの名無しさん
07/08/24 20:52:42
文法的にも、プログラム的にも、省略するのは間違いではない。
だが、
プログラムを人間が読んで理解する上では、省略しないほうがよい。

181:デフォルトの名無しさん
07/08/24 22:22:15
>180みたいな人間に合わせるために、省略しない方がいい。
>180みたいな人間が見ることがないコードなら、遠慮することなく省略していい。

182:デフォルトの名無しさん
07/08/25 00:29:12
>>180
そもそも理解の妨げにならない、という話をしてるんじゃないのか。

183:デフォルトの名無しさん
07/08/25 03:38:00
>>180
逆、コンピューターの作法に人間が合わせてるだけ。
人間様はシンプルな方が理解しやすい。

184:デフォルトの名無しさん
07/08/25 09:16:43
>>182
>>180　は理解が足りない、って話じゃないの？

185:デフォルトの名無しさん
07/08/25 11:05:48
書く目的が、、、
(1).人間が理解しやすい、と言うなら、
「無くても理解できる。」、「無駄なコードに見える」
(2).char -> wchar_t や処理系固有の文字型に変更する可能性のためなら、
strlen はchar専用、またsizeof(char)と直接書くのも適切ではない。より汎用的に書くべき。
また#if などで、文全体を置き換えるとすれば、(1).より、無くても良い。
必要な型の場合のみ書く。
(3).その処理系はsizeof(char)自体が、1ではない。
このスレの前提「必ず１でも」に一致しないので、除外する。

186:デフォルトの名無しさん
07/08/25 13:54:03
>>185
>181

187:デフォルトの名無しさん
07/08/25 14:24:25
#define SZCHAR 1

p = (char*)malloc(SZCHAR*strlen(ps));

if(p == NULL)
{
return ERR;
}

こうすればいいじゃね

188:デフォルトの名無しさん
07/08/25 14:37:13
>>187
aho

189:デフォルトの名無しさん
07/08/25 14:44:33
>>187
βακα..._〆(ﾟ▽ﾟ*)

190:デフォルトの名無しさん
07/08/25 15:23:52
>>187
Ma nuke.

191:デフォルトの名無しさん
07/08/25 15:29:12
>>185
汎用的に書くからには、それで正しく動作するように書き、テストもすべきだ。
見かけ倒しで実際にはダメなんてのは迷惑。
だから、charでしか正しく動作しないのであれば、charで書いておくべきだ。

192:デフォルトの名無しさん
07/08/25 23:38:06
VCならTCHAR使えってこった。

193:デフォルトの名無しさん
07/08/26 01:33:34
_TCHARとTCHARの違い、わかって言ってる?

194:デフォルトの名無しさん
07/08/26 04:15:18
>>188
気やすくAhoと言うな。

AWKを作った偉い人の名前だぞ。

195:デフォルトの名無しさん
07/08/26 05:37:47
/*sizeof(char)*/

196:デフォルトの名無しさん
07/08/26 14:29:20
なんかchar型のサイズが1バイトって前提の話になってるけど
C++だとcharのサイズって1(単位なし)だよな。
で、各型のサイズはcharのサイズの整数倍であることが保証されている。

でも1=1バイトかどうかは環境依存だよな?
#あくまで企画上の話なので実際にcharのサイズが1バイトじゃない環境出せとかいうのはなしね。

197:デフォルトの名無しさん
07/08/26 14:37:23
>>196
1バイトが8ビットであることも決まっていない。
CHAR_BITは8以上となっているから、1バイト=7ビットでは規格合致できないけど。

198:デフォルトの名無しさん
07/08/26 14:58:19
>>196
C、C++は絶対何があってもsizeof(char)は1バイト
と規格で定めてる。
それ以外の環境はありえないし存在しない。

1バイトが8ビットかどうかはこのスレでは論じていない。

199:デフォルトの名無しさん
07/08/26 15:02:07
>>197
とりあえず、規格上のサイズ指定に使われている単位と
環境上で実際にサイズ指定に使われている単位って違うよなってことを
指摘したかっただけなんだ。

で、指摘の件だけど、それはcharのサイズ=1=2バイト(今の話なら14ビット)
で定義してやればその要件は満たすんじゃね?
CHAR_BITはcharを構成するビット数であって1バイトを構成するビット数の
話じゃないよな?

あと、バイトの出自ってIBMの内部呼称でbit octetからきてると思ったんだが
今はなんかビット数に関して不問にするみたいなのってあるのかな?

200:デフォルトの名無しさん
07/08/26 15:12:09
>>199
そういうこと。外から見てcharが2オクテットだったとしても、
CHAR_BIT == 16にして、sizeof (char) == 1にすれば規格合致できる。

いずれにせよ、198の言うとおりこのスレで話すようなことではないけどな。

201:デフォルトの名無しさん
07/08/26 15:47:31
>>198
プログラミング言語C第2版p44（ISBN4-320-02692-6)にはたしかに書いてあるね。
けどプログラミング言語C++第3版（ISBN-4-7561-1895-X)にはそんなこと書いてないよね。
charのサイズに関してはp110で言及してるけど、サイズが1であること、8ビット以上であること、
ほとんどの場合に8ビットバイトであることはかかれてるけど、1バイトとは書いてないよね。
#これよんで9ビットバイトって書いてもいいのかとは確かに思った。

まぁ、何が言いたいかというとcharのサイズが2バイトのC++環境とかだと
sizeof(char)をかけてもC++の仕様レベルで必要バイトサイズとれないよなって話。
#mallocの引数はバイト数なんだよね。

Cは厳密な話知らなかったから知らない。
#ちゃんとC++限定で話してたよね。

>>200
ということで、charのバイトサイズをべつに定義しておいてmallocに渡すときはそれを
使ってバイトサイズに変換しろっていうまとめをするとすれ違いにならないかな?

202:デフォルトの名無しさん
07/08/26 15:48:12
マルチバイトを扱うなら文字列関係は普通ライブラリ化する
不都合が発生してもそこだけ修正するので1の件は重要じゃない
反対にmalloc散らばりまくりの汚い実装なら
17文字余計にタイプすると人件費にして2円位になるから
わざわざ強要してもとコストがかさむだけでメリットがない

203:デフォルトの名無しさん
07/08/26 15:50:25
>>202
＞17文字余計にタイプすると人件費にして2円位になるから
計算方法kwsk

204:デフォルトの名無しさん
07/08/26 15:56:25
>>201
wikipediaでもなんでも見ればいいだろ。

205:デフォルトの名無しさん
07/08/26 16:07:59
>>203
例えば1500円/人時で5秒2円位。17文字タイプだとその位にはなる

206:デフォルトの名無しさん
07/08/26 16:14:51
>>201
ISO/IEC 14882(C++の規格だ）の5.3.3 Sizeof にこう書いてある。

sizeof(char), sizeof(signed char) and sizeof(unsigned char) are 1;

207:デフォルトの名無しさん
07/08/26 16:20:56
>>206
いや、お前さんは流れ読めてなさ杉だろ。

208:デフォルトの名無しさん
07/08/26 16:21:29
#define sizeof(char) 1

209:デフォルトの名無しさん
07/08/26 16:24:36
>>207
＞charのサイズが2バイトのC++環境とかだと
っていう>>201の前提がこれで無くなったっていうだけだよ

210:デフォルトの名無しさん
07/08/26 16:25:29
>>201後半
それはない。
そうだとすると、malloc(2)の返すポインタが
要素数2つのchar配列として使えないという意味になるではないか。

mallocが使う単位もまた、sizeofと同じ。

211:デフォルトの名無しさん
07/08/26 16:36:14
>>209
sizeofの単位がバイトとはどこにも書いてないだろう

212:201
07/08/26 16:36:27
>>209
いやいや。だから、規格だと1とは書いてあるけどそれが1バイトを意味するって書いてないよねってはなし。
たとえば1=1ワードとかあり得るわけで。昔とかだと1ワード9ビットとか10ビットのマシンってあったしね。
その1ってなんだ? っていうお話。

sizeof(char), sizeof(signed char) and sizeof(unsigned char) are 1;
じゃなくて、
sizeof(char), sizeof(signed char) and sizeof(unsigned char) are 1 byte;
ってかいてあるなら自分の言ってることは間違いってことになるけど。

>>210
そうだよ。だから、規格上ではホントにそれが保証できないって言いたいわけ。
malloc(8)の返すポインタが要素数2つのint配列として使えないのと同じってこと。

mallocが使う単位はbyteでsizeofの単位はC++に限って言うならcharのサイズを1とした環境依存。
実用上同じでないと使い勝手が悪いというのならそれには同意。

213:デフォルトの名無しさん
07/08/26 16:43:08
C99ではsizeofの結果はバイト数ってことになってるな。

> sizeof 演算子の結果は、そのオペランドの大きさ（バイト数）とする。

214:デフォルトの名無しさん
07/08/26 16:44:00
>>212
The sizeof operator yields the number of bytes in the object representation of its operand.

ってわけえ、sizeofはバイト数を返します

215:デフォルトの名無しさん
07/08/26 16:46:07
>>201
次のネタどうぞ

216:デフォルトの名無しさん
07/08/26 16:51:06
sizeof()の返り値はバイト数
malloc()の引数はバイト数

では、
strlen()の返り値は何?

バイト数なら、そのまま+1してmallocの引数に渡すのはOKだが、
文字数なら、sizeof(char)を掛けないと、バイト数にはならないよね。

217:デフォルトの名無しさん
07/08/26 16:56:47
The strlen function returns the number of characters that precede the terminating null character.

218:デフォルトの名無しさん
07/08/26 17:00:44
1を掛けても掛けなくても数値は変わらないよね

219:デフォルトの名無しさん
07/08/26 17:03:15
strlenの引数は char* だから文字数＝バイト数と考えてよいのでは？
それとも漢字が混じるとそれも1文字として扱われるだろうか？
だとしたら、sizeof(char)掛けてもバイト数にはならないよね。

220:デフォルトの名無しさん
07/08/26 17:03:27
>>216
戻り値はキャラクタ数
1キャラクタは1バイト
よって戻り値はバイト数

ってことだね

221:デフォルトの名無しさん
07/08/26 17:05:29
それは数値の一致であって、意味の一致ではない。
あくまでも「1バイト文字」の「文字数」なのだから。

省略してもプログラムは意図した通りに動くが、
プログラムが動けば何だっていいというのは間違い。

222:デフォルトの名無しさん
07/08/26 17:15:13
仕様上キャラクタ＝バイトです。
たまたま文字を意味するときだけ
わかりやすくキャラクタと表記します。
そのため、byte という型はありません。

だってさ。なるほどね。

223:デフォルトの名無しさん
07/08/26 17:19:42
？

224:デフォルトの名無しさん
07/08/26 18:17:13
>>221
1バイト文字の文字数がバイト数と等しいと見なすことの何がいけない。

225:デフォルトの名無しさん
07/08/26 18:25:17
プログラムのコードに現われない、暗黙の変換を行うから、いけない。

226:デフォルトの名無しさん
07/08/26 18:26:25
>>225
暗黙じゃないだろ・・・

227:デフォルトの名無しさん
07/08/26 18:34:00
>>225
こんな自明な事柄、変換じゃないだろ。

228:デフォルトの名無しさん
07/08/26 18:42:37
自明だからといって省略するのは、悪い癖だなぁ。

229:デフォルトの名無しさん
07/08/26 18:57:07
そもそも変換じゃないだろ。

230:201
07/08/26 19:23:37
>>213
>>214
これは知りませんでした。ご教授ありがとうございます。
たしかにsizeof(char)は常に1で、返すのはバイトサイズだからcharが
2バイトの環境ってあり得ないですね。
勘違いしてました。

>>215
ごめん。
俺の疑問は俺の誤解だったということで解決したから、次のネタはないの。。。
単発と言うことで許して。

231:デフォルトの名無しさん
07/08/27 01:09:02
お前ら、こんな下らない話で、よくここまでスレを伸ばしたなぁ。

いまどきmallocとstrlenを散在させるようなコードを書くほうがオカシイ。
strlenなんて使うか? ふつー。

232:デフォルトの名無しさん
07/08/27 01:14:17
最近はもうC自体あんまり使わない

233:デフォルトの名無しさん
07/08/27 01:23:27
>>231
話がループしてるからいくらでも伸びる気がする。
ところで、
「散在させる」ってのはどこから出てきた？
strlenを使わないなら何を使う？(あくまでCだとして)
sizeof(char)を省略すべきでない？

234:!= 231
07/08/27 01:25:34
ここでstrlen_sだなんて言ってみるテスト

235:デフォルトの名無しさん
07/08/27 01:28:31
>>231
くだらないからこそだろう

まさにこれこそが「自転車置場の議論」ってやつだな

236:デフォルトの名無しさん
07/08/27 01:35:19
>>233
マクロ、ライブラリ、クラスの中で使うのではなく、
ベタベタと書くコードの中で使う = 散在させる

ぶっちゃけ、適切に局在化されていれば、
多少マズいコードだろうと直せるので、
このスレで話しているようなことは、
どーでもよくなるんですよ。

237:デフォルトの名無しさん
07/08/27 01:39:54
そうだ、マルチバイト文字が存在するからいけないんだ!
今日から、みんな、英語で生活!
それで全員ハッピーだ!

238:デフォルトの名無しさん
07/08/27 01:57:57
Die job death car?

239:233
07/08/27 02:01:15
>>236
「散在させる」はスレの流れから読み取ったわけじゃないのね。

俺も同じ考えだけど、ちょっと論点がずれてる気がする。
「局在化」とか、「直せる」とかはこのスレには関係ないな。
局在化したその場所で「省略するかしないか」ってことが問われてる。
まあ、そこで、「どーでもよい」ってのが答えなんだろうけど。

240:デフォルトの名無しさん
07/08/27 04:21:09
ここで新たな判断基準を持ち込んでみる。

どちらが適切だと思うか主張する場合に、年収も書くこと。
年収の多い人のやり方が、すなわち、より成功に近い。

241:デフォルトの名無しさん
07/08/27 06:00:54
馬鹿発生

242:デフォルトの名無しさん
07/08/27 09:04:13
アホが来たよ・・・

243:デフォルトの名無しさん
07/08/27 09:28:33
>>231
C言語なら「普通」strlenを使うと思う。

NULL終端までのバイト数を取得する関数なんて作るのは、
まぁライブラリの標準関数が使えないプロジェクトぐらいじゃないの？

244:デフォルトの名無しさん
07/08/27 11:19:52
今時charの内部形式を意識しないといけない言語は使うな。

245:デフォルトの名無しさん
07/08/27 16:17:20
>>243
何かにつけてstrlenする、糞遅くて信頼性の低いプログラム書いてるのか。ご苦労さまです。

246:デフォルトの名無しさん
07/08/27 16:20:17
本当、何かにつけてstrlenの必要に迫られるCは疲れるよ。

247:デフォルトの名無しさん
07/08/27 16:25:11
>>245
C厨だがそこには同意

248:デフォルトの名無しさん
07/08/27 17:18:47
strlen

249:デフォルトの名無しさん
07/08/27 17:23:02
struct {
size_t bufferLen ;
size_t validLen ;
char szBuffer[1] ;
} ;
とかの構造体を使って、バッファの長さや有効長を管理したらいいじゃないか。
szBuffer[1]と言いながら、実際にはヒープから長い領域を貰うのは気持ちわるいかもしれないが。

250:デフォルトの名無しさん
07/08/27 17:36:12
>>245
自分がそうだからといって人もそうだとは限りません。
間抜けですね。

251:デフォルトの名無しさん
07/08/27 18:10:40
>>249
そこまでするくらいならC++使う。そもそも使えるときは使っている。

252:デフォルトの名無しさん
07/08/27 19:11:38
>>250
どんなコードを書いているのか披露してほしい。お手本にするから。

253:デフォルトの名無しさん
07/08/27 20:09:30
>>245
fgetsで文字列を読み込んだり、コマンドライン引数を受け取ったりした際に
得られた文字列長を調べるための、strlenより高速で信頼性のある方法を教えてくれまいか？

254:デフォルトの名無しさん
07/08/27 20:59:09
freadを使う

255:デフォルトの名無しさん
07/08/27 21:05:14
それはstrlenより高速で信頼性のある方法なのか？

256:デフォルトの名無しさん
07/08/27 21:29:46
>>253
まず、得られた文字列の長さを調べる必要が、本当にあるのかな。
次に、何かにつけてfgetsするのかな。

257:デフォルトの名無しさん
07/08/27 21:32:02
必要あるからする

258:デフォルトの名無しさん
07/08/27 21:34:11
本当は必要ないのに、必要だと思い込んでいる可能性を疑ってみた?

259:デフォルトの名無しさん
07/08/27 21:37:49
もちろん

260:デフォルトの名無しさん
07/08/27 21:38:54
で、strlenより高速で信頼性のある方法は？

261:デフォルトの名無しさん
07/08/27 21:44:29
じゃぁ>>253は具体的にコードを例示してね。

262:デフォルトの名無しさん
07/08/27 21:50:37
strlenより高速で信頼性のある方法マダー？

263:デフォルトの名無しさん
07/08/27 21:53:02
strlenよりも高速で信頼性のあるstrlen互換の関数の話ではないぞ。

264:デフォルトの名無しさん
07/08/27 21:55:18
基本的に、
気やすくstrlenやstrcpyを使わない
ってだけで、かなり速くなるし、安全性も高まる。

265:デフォルトの名無しさん
07/08/27 21:59:45
酷い例1
char buf[100] ;
char buf2[100] ;
fgets(buf, sizeof(buf), pFin) ;
if (strlen(buf) < sizeof(buf2)) { /* 無意味な長さチェック */
strcpy(buf2, buf1) ; /* ←無意味なコピー */
}

酷い例2
for (i=0 ; i<strlen(s) ; i++) { /* 無意味な有限回数のループ、無意味な毎度の関数呼び出し */
if (s[i] == 'X') { なんたら }
}

266:デフォルトの名無しさん
07/08/27 22:02:14
strlenよりも高速で信頼性のあるstrlen互換の関数マダー？

267:デフォルトの名無しさん
07/08/27 22:07:14
>>264
strlen,strcpyの安全性が低く感じるのは、呼び出し元の安全性が低いから。
速くなるってのは、一度取った長さを変数に入れておくとかってレベルの話かな？
いずれにしろ、これらに限らず「安易に使わない」って意味では同意できる。

268:デフォルトの名無しさん
07/08/27 22:25:48
>>267
> strlen,strcpyの安全性が低く感じるのは、呼び出し元の安全性が低いから。

人間はミスをするものだから、
機械的かつ強制的にチェックしなければ、
意味がない。

バッファの長さが十分であるという、
目に見えない約束なんてものは、
人間のミスには耐えられない。

> 速くなるってのは、一度取った長さを変数に入れておくとかってレベルの話かな？

そんな小手先の最適化ではなく、
strlenを本当に必要な場所でしか使わない、ということ。

269:デフォルトの名無しさん
07/08/27 22:28:11
安易に使わないってどゆこと？

必要だから使うんじゃないか。代替手段があるというのか？

270:デフォルトの名無しさん
07/08/27 22:29:30
>>269
実際にどんなコード書いてるの? 晒してみなよ。

271:デフォルトの名無しさん
07/08/27 22:30:02
253だが、257とか259とか俺じゃないんだが。

なんか>>261に指名されたんで、釣られてちょろっと書いてみる。
エラー処理が抜けてるのは行数削減のため。
引数に与えた文字列から始まる行を表示するプログラム。
fgetsでは無くて、引数の文字列長を取得する例なんで、
簡単のために最大255文字。

#include <stdio.h>
#include <string.h>
#define BUF_SIZE 256
int main(int argc, char *argv[])
{
int len = strlen(argv[1]);
char buf[BUF_SIZE];
FILE *fp = fopen("test.txt", "r");
while ((fgets(buf, BUF_SIZE, fp)) != NULL) {
if(strncmp(argv[1], buf, len) == 0) printf("%s", buf);
}
}

strlenぐらい普通に使うと思うんだけどねぇ。

272:デフォルトの名無しさん
07/08/27 22:32:33
なんかボーっとしてる間に、えらいスレ進んでてびっくりだ。
253と271とコレ以外は俺じゃないんで一応。

273:デフォルトの名無しさん
07/08/27 22:36:16
>>271
それは
「何かにつけてstrlenする」
には該当しないと思うが。

274:デフォルトの名無しさん
07/08/27 22:37:17
>>272
すまんね　>>257と>>259は俺だ
君の振りをしたつもりは無いんだけどね

275:デフォルトの名無しさん
07/08/27 22:50:29
こんなどうでもいいことを真剣に議論してるｗ
ワラタｗ

276:デフォルトの名無しさん
07/08/27 22:53:27
それはよかった

277:デフォルトの名無しさん
07/08/27 22:55:12
>>273
>>243に対して>>245だったから、strlenを全否定してるように見えたんで、
「まぁ使うんじゃないの？」ぐらいの感じで書いただけだよ。

ループ内とかで同じ文字列に対して何度もstrlen呼んだりとか
そういうのは無駄だと思うよ。

278:デフォルトの名無しさん
07/08/28 22:18:22
結論は出ましたか。

279:デフォルトの名無しさん
07/08/28 22:23:56
結論：
sizeof(char)は省略してもいい
strlenは必要な場合もある

280:デフォルトの名無しさん
07/08/28 22:28:44
上げんな糞
>>1死ね

281:デフォルトの名無しさん
07/08/28 23:30:57
adobePの新作期待age

282:デフォルトの名無しさん
07/08/28 23:46:39
>>1

sizeof(char)が必ず1なら
malloc(sizeof(char)*(strlen(s)+1))
ではなく
malloc(strlen(s)+1)
の方がいい

malloc(sizeof(char)*(strlen(s)+1))
だとsizeof(char) * が冗長

sizeof(char)が必ずしも1でないならわかるが

283:デフォルトの名無しさん
07/08/29 01:23:30
まあCとC++に限って言えば100% 1だからなぁ

284:デフォルトの名無しさん
07/08/29 01:26:43
いい加減ループしすぎ。

285:デフォルトの名無しさん
07/08/29 01:27:14
まぁスレタイがねループしてくださいって言ってるようなもんだからね

286:デフォルトの名無しさん
07/08/29 01:29:27
ループといえば for(;;) と while() の戦争もあったな
オレは意味なくdo～while派だけど

287:デフォルトの名無しさん
07/08/29 01:38:39
じゃあ俺はgotoを使うぜ！

288:デフォルトの名無しさん
07/08/29 01:41:03
三木は3つまでしかまとめられなかったので 3岐
後藤は5匹を統括してたから 5統

289:デフォルトの名無しさん
07/08/29 06:16:09
ﾅﾂｶｼｽ

290:デフォルトの名無しさん
07/08/29 06:40:54
ネオジオは100メガビット

291:デフォルトの名無しさん
07/08/29 07:43:01
>>288
三木は右手だからじゃなかったっけ？

292:デフォルトの名無しさん
07/08/29 11:02:31
それもあるな
なんかこう言葉遊びもあそこまで行くと芸術レベルだよな

293:デフォルトの名無しさん
07/08/29 13:07:42
>>284
今頃ノコノコ出てきて画期的なご意見を述べて行かれる
>>282　みたいな間抜けがいる限り、ループは不滅です。

294:デフォルトの名無しさん
07/08/29 21:26:11
exit(0);

295:デフォルトの名無しさん
07/08/29 21:49:41
いまどきマロックなんか使うかよｗ
newを使えnewを！

296:デフォルトの名無しさん
07/08/29 22:22:16
VirtualAllocは多用しますが何か?

297:デフォルトの名無しさん
07/08/29 23:13:24
sizeof(char)+1が必ず2でも、省略すべきではない
ｽﾚﾘﾝｸ(tech板)

298:デフォルトの名無しさん
07/08/29 23:20:02
再帰

299:デフォルトの名無しさん
07/08/30 19:28:14
おもしろいことに、関心と一般の議論の大きさは、
機能の重要性と反比例していることが多い。
その理由は、大きな機能より小さな機能のほうが明確な意見を持ちやすく、
流行のような、一時的な関心を引きやすいからだ。
～～Bjarne Stroustrup『C++の設計と進化』

300:デフォルトの名無しさん
07/08/30 22:41:51
>>299
そして、プログラムとは、小さな機能を集めて大きな機能を実現していく。
だから、小さな機能を議論することは、最終的に大きな機能
そして、重大な機能を議論することにつながるのである。

301:デフォルトの名無しさん
07/08/30 23:39:17
ああいえば上祐

302:デフォルトの名無しさん
07/08/31 00:56:46
URLﾘﾝｸ(msdn2.microsoft.com)(VS.80).aspx

世界一巨大なソフトウェア会社のコーディング例では、
len = _vscprintf( format, args ) // _vscprintf doesn't count
+ 1; // terminating '\0'
buffer = malloc( len * sizeof(char) );
のように、sizeof(char)を省略していない。

303:デフォルトの名無しさん
07/08/31 01:34:46
URLﾘﾝｸ(dist.dc.kumamoto-u.ac.jp)
の問題2
「自分なりの理由」があればどちらでも良い。
という答えな気がする。

304:デフォルトの名無しさん
07/08/31 01:41:50
>>303
純真な若者に示す手本として、
s = (char *)malloc(sizeof(char)*n + 1);
というのは、随分と酷いな。

s = (char *)malloc(n + 1);
ならともかく、
s = (char *)malloc(sizeof(char)*n + 1);
はダメだろう。

意味として間違ってる!

305:デフォルトの名無しさん
07/08/31 01:50:23
>>304
まあね、書くのならこのスレの様に
sizeof(char)*(n+1)
のようにヌル文字分も含めるべきだね。

306:デフォルトの名無しさん
07/08/31 01:53:05
>>303
どうしようもない問題集だな。特に問題4の辺りは終わっている。

307:デフォルトの名無しさん
07/08/31 02:23:04
演習3のプログラムも酷い。

例とはいえ、freeしないのは、どうかと。
それに、stdio.hしか#includeしてないぞ!!!

308:デフォルトの名無しさん
07/08/31 02:37:23
>>303のURLのソースを見ると、スタイルシート"masato.css"を使ってる。

URLﾘﾝｸ(www.kumamoto-u.ac.jp)
のトップページでmasatoを検索すると、
URLﾘﾝｸ(www.syst.cs.kumamoto-u.ac.jp)
がヒットする。似たようなセンスの問題が。

URLﾘﾝｸ(www.syst.cs.kumamoto-u.ac.jp)
の問題4は、>>303の演習3と似てる。

そして問題5は、
> 友情をテーマに，mallocと構造体を使った簡潔なプログラムを作りなさい．
という、涙が出そうな秀逸な問題だ。

ちなみに、URLを削って
URLﾘﾝｸ(www.syst.cs.kumamoto-u.ac.jp)
という研究室のWebのメンバーを見ると、助手らしい。

熊本大学だいじょうぶか?
こんな質の低い教育やってちゃイカんぞ。

309:デフォルトの名無しさん
07/08/31 02:49:46
だって、Apache インストール済みだもん。
URLﾘﾝｸ(dist.dc.kumamoto-u.ac.jp)

310:デフォルトの名無しさん
07/08/31 04:12:25
URLﾘﾝｸ(www.syst.cs.kumamoto-u.ac.jp)
> 問題2
> 以下のプログラムを見て，問に答えなさい．
> #include <stdio.h>
> #include <stdlib.h>
>
> #define SIZE 5
>
> int main()
> {
> int a[SIZE], i;
> int *b = (int *)malloc(sizeof(int)*SIZE);
>
> for (i = 0; i < SIZE; i++)
> a[i] = i * i;
>
> for (i = 0; i < SIZE; i++)
> b[i] = a[i];
>
> for (i = 0; i < SIZE; i++)
> printf("%d ", b[i]);
> printf("\n");
>
> return 0;
> }

311:デフォルトの名無しさん
07/08/31 04:12:51
>
> 1. 「配列aとmallocで確保された領域bの違いは，
> 静的に確保されるメモリ領域と，
> __に確保されるメモリ領域という違いがある．」
> __に入る適切な言葉を以下から選びなさい．
>
> a.愛ゆえ
> b.俺的
> c.仮想的
> d.動的
>
> 2. b[2]の型は何ですか？

312:デフォルトの名無しさん
07/08/31 04:15:56
これは問題の間違いを正しなさい、という課題なのかな。

配列aが「静的」だってよ。

313:デフォルトの名無しさん
07/08/31 04:16:42
さらに、for文の書き方が酷い。

同一行に書くのなら {} を省いても構わないが、
別の行に書くのなら {} は省くべきではないのに。

314:デフォルトの名無しさん
07/08/31 05:30:37
sizeof(char)の話に集中しましょうね。

大学のプログラミング演習の課題を添削するスレ
ｽﾚﾘﾝｸ(tech板)

315:デフォルトの名無しさん
07/08/31 09:32:49
>>302
そういうことやってるから細かいバグが残ったりなかなか取れなかったり
するんだろ。しっかりしろといいたい。

316:デフォルトの名無しさん
07/08/31 09:37:52
そうだな。

+1を人間がコーディングしていたら、+1し忘れて、バッファオーバーフローするわな。

317:デフォルトの名無しさん
07/08/31 10:12:40
世界一安定してる会社のコーディングスタイルならともかく、バグだらけの会社のそれを例に出されてもな

318:デフォルトの名無しさん
07/08/31 10:13:47
>>317
コード量が膨大だから、バグ含有率が低くても、バグ件数は膨大になるんだよ。

319:デフォルトの名無しさん
07/08/31 12:19:34
>>318
ああいうコードが積み重なってるからね
バグが多くなるのもうなずけるよ・・・

320:デフォルトの名無しさん
07/08/31 13:30:54
>>302
ほんと、あそこのサンプルコードってゴミばっかりだよな。

>>313
お前の推奨するスタイルなんかどーでもいいわけだが。

321:デフォルトの名無しさん
07/08/31 15:12:04
また1つごみを見付けたんで記念カキコ
URLﾘﾝｸ(msdn2.microsoft.com)(VS.80).aspx

pszSrc= new char(12);
if(pszSrc)
　　 pszSrc= "Hello world!";

322:デフォルトの名無しさん
07/08/31 15:41:38
>>321
酷すぎるｗｗ
その前にあるNULL代入も意味無いしｗ
constもキャストもないからコンパイルも通らんだろうなｗ

323:デフォルトの名無しさん
07/08/31 15:52:20
何がやりたいのかよくわかんねーソースだな

324:デフォルトの名無しさん
07/08/31 16:31:06
>>321
あれだな、
1.まず鍋を用意します。
2.次に鍋を投げ捨てます。
3.そして既に作っておいたカップラーメンを食べます。
みたいな感じか。

それにしても僅か8行でツッコミ所満載な上に
メモリリークのおまけ付きとか流石マイクロソフトだな。

325:デフォルトの名無しさん
07/08/31 16:36:02
>>321
非NULLは真になるよって言いたいんじゃまいか

326:デフォルトの名無しさん
07/08/31 16:36:14
せめてnew char[12]と書けよと思う。

327:デフォルトの名無しさん
07/08/31 17:10:02
strcpyしたかったのかな。"Hello world!"で12文字だからnew char[12]じゃ足りないけど。
str.CopyChars(str.GetBuffer(), "Hello world!", 12);　と書いとけばいいのにｗ

328:デフォルトの名無しさん
07/08/31 19:35:39
>>321は良い踏み絵だな
判ってない奴が浮き出てきた

329:デフォルトの名無しさん
07/08/31 20:59:23
charというのは組込型ではなくクラスなのか?

330:デフォルトの名無しさん
07/08/31 21:23:47
>>328
何が？

331:デフォルトの名無しさん
07/08/31 21:24:49
>>329
ATL/MFC　のコードなんだから　C++。
なので　char　はクラスではない。

332:デフォルトの名無しさん
07/08/31 23:56:30
>>328
>>327みたいな奴の事だろう

333:デフォルトの名無しさん
07/09/01 01:06:20
>>332
>>327みたいな奴は何がわかってないの？

334:デフォルトの名無しさん
07/09/01 02:00:21
>>328
よく判ってないんで、>>321のソースを解説してはくれまいか？

335:デフォルトの名無しさん
07/09/01 11:25:14
// 動的に確保した領域のポインタをpszSrcに代入
pszSrc= new char(12);
// newに成功した場合
if(pszSrc)
// 動的に確保した領域を無視して、文字列リテラルのポインタをpszSrcに保存
// 動的に確保した領域はリークする
pszSrc= "Hello world!";

C言語しか分からんけど、newをmallocに読み替えるとこんなところ。
C++だと文字列リテラルの代入は、なんかstrcpyみたいな動きすんのか？

336:デフォルトの名無しさん
07/09/01 11:36:12
＞// 動的に確保した領域のポインタをpszSrcに代入
＞pszSrc= new char(12);
構文エラー。

＞// newに成功した場合
＞if(pszSrc)
newはNULLを返さない。

＞// 動的に確保した領域を無視して、文字列リテラルのポインタをpszSrcに保存
＞// 動的に確保した領域はリークする
＞pszSrc= "Hello world!";
その通り。

＞C言語しか分からんけど、newをmallocに読み替えるとこんなところ。
＞C++だと文字列リテラルの代入は、なんかstrcpyみたいな動きすんのか？
しないしない。

>>324
寧ろ、こう。
・鍋を用意して一杯にお湯を沸かします(勿論、麺を入れたら溢れて大変ですね)。
・鍋は用意できましたか(当然である)?
・ではこちらに用意したカップラーメンをどうぞ(おいおい、鍋そのままw)。

337:デフォルトの名無しさん
07/09/01 12:01:38
>>335
　　pszSrc=　new　char(12);
は、C　だと↓こんな感じ。
　　(pszSrc　=　malloc(1))　=　12;

338:デフォルトの名無しさん
07/09/01 12:02:26
あああ尻穴忘れた！
　　*(pszSrc　=　malloc(1))　=　12;

339:デフォルトの名無しさん
07/09/01 12:15:23
>>336
12はcharの初期化子として有効。エラーにはならない。

340:デフォルトの名無しさん
07/09/01 15:08:20
エレガントなメモリリークだなぁ

341:デフォルトの名無しさん
07/09/03 04:22:12
mallocが失敗する可能性は考慮しないのか？
つーか、mallocってNULL以外が返ったとしても
実はメモリ確保に成功したかどうか不明だという
おそろしいバグがあるんだがLinuxって怖いよな

342:デフォルトの名無しさん
07/09/03 08:06:28
mallocやnewが失敗する状況って、かなりヤバいよね。

それらに対処するコードで、mallocやnewを使うと、ミイラ取りがミイラになる恐れがあるし、
OSの仮想メモリを食い尽くしている状況では、他のプログラムも動作続行が厳しくなっていて、
終了処理も正常に行えるか怪しい。予想もつかないような事態が次々に発生しそう。

だから、mallocやnewに失敗した時点で、OSから再インストールするハメになるわけで、
成功したかどうかチェックし、失敗したことがわかったところで、ろくに対処できないなら、
開き直って、mallocやnewをラップして、失敗したらexitしてしまい、
ラップしたものを使う側は、失敗することはないものとしてコードを書いてしまうのもアリかと。

343:デフォルトの名無しさん
07/09/03 09:14:15
＞だから、mallocやnewに失敗した時点で、OSから再インストールするハメになるわけで、
おいおい、普通はrebootで充分だろ。

実際Gnomeなんか使っていると、malloc()に失敗する頃には事実上操作不能になっているから、
諦めてとっととexit()ってのはありだと思う。
私の仕事関係では、常駐型アプリケーションの起動は基本的にスクリプトから行ない、
アプリケーションが異常終了したときには可能ならそのアプリケーションを再起動するようにしている。

344:デフォルトの名無しさん
07/09/03 09:42:29
>>343
rebootで十分という保証があれば、ね。

OSの上で走るすべてのプログラムが、
設定やデータをファイルに書く時、
一貫性を保てるように書いてくれればいいが、
そうでないと、
不正で壊れたファイルを読むことになり、
こまったことになってしまう。

345:デフォルトの名無しさん
07/09/03 13:09:01
OSからとかねぇよｗ
書き込み中の電源断でさえジャーナルファイルシステムなら通常問題無いのに、
メモリ確保失敗くらいで整合性取れなくなるとかｗ

基幹システムなどなら、ソフトウェアとして既に品質に問題有りだし、
個人PCやグループサーバーレベルで再インストは潔癖過ぎだろ。

346:デフォルトの名無しさん
07/09/03 13:13:01
1GiBのメモリ確保しようとして失敗したって状況なら、
メモリ確保失敗したとユーザに通知したり、
そのために数KiBのメモリを確保したりしようとしてもいいと思う。

347:デフォルトの名無しさん
07/09/03 13:32:25
>>345
ファイルシステムのレベルで問題がなくても、ファイルの中身のレベルでは問題だよ。

ファイルの中身までトランザクションやジャーナルでやっていれば大丈夫だが、
そうでないプログラムの場合、ファイルの中身の一貫性が失われてしまう。

348:デフォルトの名無しさん
07/09/03 13:56:19
>>347
>そうでないプログラムの場合、ファイルの中身の一貫性
345の下２行の通り。
重要なシステムなら論外、DBMSなどで一貫性の確保は必須だし、
それでも抜けた異常はバックアップからリカバリさせる。
OSからとかダウンタイム長すぎだろ。

それにメモリ不足でOS壊すってどんな状況？
viがLILOの設定ファイル書き換える最中に死んだって、
書き換え前にバックアップくらいしてるだろ。

ユーティリティか何かがhttpd.conf壊したって、
OSどころかapacheから入れなおす馬鹿は居ないだろ。

349:デフォルトの名無しさん
07/09/03 16:41:48
＞ユーティリティか何かがhttpd.conf壊したって、
＞OSどころかapacheから入れなおす馬鹿は居ないだろ。
見たことあるな。
俺はこれをWindows病と名づけた。

350:デフォルトの名無しさん
07/09/03 18:53:50
あーいるいる、「取り敢えず再インストールしてみました」って香具師。

351:デフォルトの名無しさん
07/09/03 20:36:44
ネトゲのクライアントは、たまにWindowsの設定やらシステムファイルやらをぶち壊す奴が居る

352:デフォルトの名無しさん
07/09/03 20:37:39
あ、補足。
多分mallocは関係ない。

353:デフォルトの名無しさん
07/09/03 21:53:13
しばらく前、幻想三国志2っちゅーゲームでアホほど再起動かかってOSが不安定になった。
再起動の原因がメモリリークと気付くのが遅すぎた・・・。

HDDがガリガリ鳴り出したらセーブして再起動とか、
偽典女神転生を思い出して懐かしかった。

354:デフォルトの名無しさん
07/09/03 22:57:44
突然だがスレを激しくrollbackしていいかな。

sizeof(char)は確かに仕様で1と決まっているけど、省略しない方が良い。
コメントやsizeof(char)==1の理解が無くても、
ソースを見るだけで文字数→バイト数として扱いたい意図が明確になる。
それにコンパイラの最適化でどうせコストは0だ。

ただ、そんな冗長なソースが散在しているのが嫌だというのも同意出来る。
しかしそれ以前に、文字列の操作なんて普通はラップしないか？

>malloc(sizeof(char)*(strlen(s)+1))
>malloc(strlen(s)+1)
両方とも、非常に短い関数以外でこんなん出てきたらどうかと思うんだが。

char*　　　　strmalloc(int　len){return　len<0?NULL:malloc((len+1)*sizeof(char　　　));}
wchar_t*　wcsmalloc(int　len){return　len<0?NULL:malloc((len+1)*sizeof(wchar_t));}
void　strfree(const　char*　　　　s){free(s);}　//　確保/解放を対とするためfreeを単純にラップ
void　wcefree(const　wchar_t*　s){free(s);}　//　確保/解放を対とするためfreeを単純にラップ

char* s2 = strmalloc(strlen(s));
strfree(s2);

これくらいは抽象化するだろ？お前らどうやってる？

355:デフォルトの名無しさん
07/09/03 23:21:41
＞文字数→バイト数として扱いたい意図
ここは自明だろーがよ
というのが反対派の意見だと思う。

a++; // 1を足す
っていうコメントを読まされるような感じというか

356:デフォルトの名無しさん
07/09/03 23:28:41
>>354
一方俺はC++を使った。

357:デフォルトの名無しさん
07/09/03 23:49:03
まぁ、俺も現実的にはC++使うな。
だけどC++使うからこそ観念的に省略しないんだけどな。

テンプレート関数とか作るとき
> ここは自明だろーがよ
> というのが反対派の意見だと思う。
そのはずの自明が、抽象化・総称化すればする程無くなっていく。
wchar_tの対応をしようとしただけで崩れる。
つまりその自明はあまり本質的でなかったということ。
むしろ、文字をchar型を扱うときに限り文字数とバイト数が同じになる、と考える。

文字列操作と言いながら型を強く意識するのは、やはりスマートとは思えないよ。

358:デフォルトの名無しさん
07/09/03 23:52:00
誤記は脳内保管で。

359:デフォルトの名無しさん
07/09/04 00:00:44
>>357
ぶっちゃけ未対応ソフトの多バイト文字対応をするときは
charをwchar_tに機械変換♥ なんて絶対しないから
もうその辺はすごい勢いでどうでもいい話だと思う。

360:デフォルトの名無しさん
07/09/04 00:11:32
そもそも文字型が独立しておらず、charやunsigned charが
整数型の1つである（JavaやC#でいうbyteにあたる型）という時点から
もう文字とバイトをごっちゃにするのは始まっている。

だから俺は文字 == バイトを甘んじて受け入れ、sizeof (char)を使わない。

361:デフォルトの名無しさん
07/09/04 00:15:20
機械変換とかじゃなくて、テンプレート関数の話な。
allocator((Tr::getlen(s)+1) * Tr::char_size);
みたいな感じで実装して、型はコンパイル時に決まる。

ちょっとした関数を総称化すると、
自分が自明だとか本質的だと思っていたものが、
そうでもないと気付かされるって話。

362:デフォルトの名無しさん
07/09/04 00:18:56
ぶっちゃげcharだけなんてXMLも扱えねぇよ最近。

363:デフォルトの名無しさん
07/09/04 00:28:46
>>360
文字とバイトがごっちゃというのは整理出来ていないから。

文字は文字集合として独立していて、バイトも文字集合とは関係無い。
その２つを繋いで、バイト列の上で文字を表現するルールがエンコーディング。
概念が頭の中で分かれていれば、unsinedだとかSJIS, UTF-8やらがあってもごっちゃにはならないはず。

364:デフォルトの名無しさん
07/09/04 00:30:07
型について、ちょい脱線するけど・・・。
時刻を保持する型を使ってて、8月中のデータを探すとき
(擬似コード。リテラルは変数に代入された値と思って)
if("2007/08/01" <= x && x <= "2007/08/31 23:59:59"){...}
のように書く奴が居る。

俺は
if("2007/08" <= x && x < "2007/09"){...}
と書く。月日は省略されると1、時間以下は0となる。(普通)

しかし、そう書く理由はソースが短くなるからじゃない。
if("2007/08/01 00:00:00" <= x && x < "2007/09/01 00:00:00"){...}
と書いても良い。
59:59だとか、9999だとかは、まずいサインだと思っている。
型を強く意識している場合は多いからだ、

上記の場合、この型がミリ秒まで保持することになったとき、
23:59:59は正確な最後ではなく、23:59:59.999と書く必要があり
僅かだが穴のあるプログラムとなる。

データ的にはピコ秒まで持てるようになったら？.999999...
精度の問題じゃない、結局は「2007/09/01に限りなく近い値」となる
なら2007/09/01 00:00:00と比較すれば良い。

ソートで単に最後にしたいものに 9999 を入れるとか、
場合によってはハードコーディングとか、もう見てられない。

必要以上に型の精度に依存しないで欲しい。

365:デフォルトの名無しさん
07/09/04 00:33:50
ミリ秒以前にうるう秒

366:デフォルトの名無しさん
07/09/04 00:36:45
<= じゃなくて < を使えば済む話じゃないのか

367:デフォルトの名無しさん
07/09/04 00:48:33
>>366
そう、そういう話。
でも使ってる精度が日まで(時以降が00:00)で、Webフォームから期間を入れられた場合、
開始日～終了日という入力欄では終了日も含むので、
x < 終了日+1 とせず、単に x <= 終了日とする奴が中々多い。
右の方がシンプルだし、わからんでもないが。

それで登録日時(時分秒が有る)とかを検索する処理でも同じソース使って馬鹿がって結果になってた。

368:デフォルトの名無しさん
07/09/04 00:52:32
>>363
文字とバイトがごっちゃというのは俺に言っているのか？
俺は、CとC++が文字とバイトをごっちゃに扱っていると言ったつもりだ。
だから俺にそんなこと言われても、お門違い。

369:デフォルトの名無しさん
07/09/04 01:04:36
wchar.hなど有るし、文字とバイトをごっちゃに扱ってるようには思えないが・・・
それにchar==文字でなく、char*==nul終端文字ストリームというのがあったから
SJISなどをそれなりに扱えて来たわけだし。

370:デフォルトの名無しさん
07/09/04 01:20:30
ちなみに、java,C#などは文字型が本当の意味で独立してるわけじゃなく、
単に内部のエンコードを割り切ってUTF-16に統一してるだけ。
昔、C言語がasciiで十分と考えたように。

その利便性はもちろん大きいけど、その代償としてUTF-8などを読み書きするとき
エンコード変換のオーバーヘッドを受け入れている。
※よほど巨大なファイルでない限り対したオーバーヘッドじゃないけど。

次ページ