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

malloc(sizeof(char)*(strlen(s)+1))
ではなく
malloc(strlen(s)+1)
と書くような糞コードばかり見て育った、
悪しき慣習を引きずった人は引退すべし

>>1
YOU死んじゃいなYO

そんなに悔しかったか。

何もたてなくても・・・

sizeof(char) => sizeof(*s) じゃだめか？と俺が言った。

>>1 
こういうのが孤軍奮闘して、単に議論がダラダラと続いているだけなのに、最終的には
「宗教論争」と言い出して「どちらでもいい」ということにしてしまうんだよなぁ。

2chの片隅で、そんなことをしても、なにがどうなるってわけでもないんだけど、
弱い人は、精神防衛せずにはいられないんだろうなぁ。

>>5
それもいいかもね。
ただ、charとワイド文字の切り替えを意識してるコードだって知らない人がみたら、意図をつかみにくいかも。

>>7
切り替えがなくとも、
sの指す先の型を人間が手作業で書くのは良くないので、
ミス防止のためには、コンパイラに仕事させたほうがいいと思う。

可読性だけの問題なのかね。

複数箇所に
malloc(strlen(s)+1)
のようなコードを書くこと自体が間違い。

最低でも関数でラップすべきだし、
C++ならstd::basic_stringを使うべきだろう。

>>8
char固定なら、いらないじゃん。

>>10
ぜんぜんOK

それにラッパー書かなくても、フツーはstrdup()使う。

ちんちんが臭いんです＞＜

>>11
char固定であることを人間が保証してやるなんて馬鹿馬鹿しい。

>>12
可哀想に。恵まれない職場にいるんだね。

sizeof(char)は必ず1である事が定義されてるんだから
別にいいじゃんねぇ

そもそも strlen はcharの文字列の長さを求める関数であって
多バイト文字の文字数を求めるなら strlen を使っちゃダメだろ。

#define sizeofchar 1

>>14
ええ? malloc()のラッパーって話じゃなくて、malloc(strlen(s)+1)のラッパーってことだよね?
職場のヘンなコードばっかり見てないで、いろいろコードを見たほうがいいと思われ。

>>14
strlen()使うんだから、char以外は使えないじゃん。

>>16
文字列複製用のメモリ確保だと思われるから、長さはバイト数でいいんじゃね?

意味の問題。

mallocの引数は「バイト数」
strlenの返り値は「文字数」

sizeof(char) == 1バイト

>>22
保証は無い。(まだそんなマシン動いてるかどうかはともかく)

>>23
100%保障。
sizeof(char)が1でないコンパイラがあったら捨てたほうがいい。

一応ANSIならとかつけたほうがいいんでねぇの？
sizeof( char ) != 1の環境は見たこと無いけど・・・

問題なのはバイトの方！

>>26
だからcharは1バイトだって。

>>25
何も書いてない時の ANSI 縛りは、暗黙の了解事項だろ。

そうでないとなんでもありありになっちゃうし。

まえスレの人は、charが1バイトってくらいは分かったうえで、いろいろ言ってる様な印象だったけど、
ちがう人と交代したのかな?

牛乳タンクの容量を割り当てる関数があるとしよう。引数はリットル型だが、実はintのtypedefだ。

箱の中に複数本の牛乳パックが入っている。
本数を問い合わせる関数があるとしよう。返り値は本数型だが、実はintのtypedefだ。

箱の中の牛乳パックを開けてタンクに入れようとする。
同じintのtypedefだからといって、
リットル型の引数に、本数型を渡していいものだろうか。

俺はダメだと思うね。
たとえ1本1Lと決まっていても、本数型からリットル型に変換する段は踏むべきだ。

いちいち
hoge = (type*)malloc(sizeof(type)*size) ;
なんて書いてる人いるの?

初心者だって、
#define MALLOC(type, size) ((type)*)malloc(sizeof(type)*(size))
くらいして、
hoge = MALLOC(char, strlen(s)+1) ;
って書くだろ?

だいたい、いまどきCオンリーなんて、なにか理由があるときくらいなもので、
普通はC++だから、文字列クラスを使うだろう。

いまだにチマチマとstrlenとかstrcpyとかやってるから、
つまらないバグやセキュリティホールを作り込んでしまうんだよ。

>>30
strlen()のリターン値は文字数==バイト数で、malloc()引数もバイト数じゃん。

>>30
強いtypedefのあるD言語をお使いください。

>>31
> 初心者だって、 ・・・って書くだろ? 

それ、たとえば誰が書いてるの?
職場の先輩とか?

malloc()の戻り値をcastするやつはバカ

俺は*sizeof(char)は付けない派だが。(付いてても気になら無いけど)

>>31
これはちょっと全体的に反対。

＞#define MALLOC(type, size) ((type)*)malloc(sizeof(type)*(size))
そんな訳の分からないマクロ作るぐらいなら、素直にcalloc使うよ。

＞普通はC++だから、文字列クラスを使うだろう。
そんな普通は無いだろ。

>>36
名前欄消し忘れた・・・。
是非スルー頼む。orz

>>36
全体的に賛成だがcallocになるのか？ラッパー関数とかじゃなくて？

> 普通はC++だから
ｗｗｗ

>>32
たまたま 文字数==バイト数 なだけじゃん。

>>40
「規格上」文字数==バイト数。
たまたまじゃない。

>>35
Cではキャストは不要だがC++では必要。
まぁ、C++でmallocを使うこと自体がおかしいが。

>>41
たまたま「規格上」一致する組み合わせ

>>38
>>31のマクロだと「型と要素数を指定してメモリを獲得する」機能が欲しそうだったんで、
指定の仕方が近いcallocを持ってきただけだよ。

>>1やらの話なら、文字列長渡してメモリのアドレス返すラッパならアリじゃないかなぁ。
個人的には面倒だからやらないけども。

>>40
たまたまじゃないよ。
あつかってる文字セットが収まる範囲を1バイトにしてるんじゃん。

ここで文脈を読まずに文字数==バイト数なのはASCIIコードだけだとかいってみる

>>44
すでに_strdupがあるもんな。

「文字列の尻には\0があるから、+1文字分の領域が必要」
ということに対処するコードは一ヶ所だけにまとめておくべきで、
プログラム全体に散在させるべきではないよね。
それが後で変るかどうかは関係ない。

あちこちにmalloc(strlen(s)+1)と書けばいいと言う人間は、
構造化プログラミングを否定していると思う。

>>45
牛乳パック1本が1リットルと決まっているからといって、
リットル数を与えるべきところに本数を与えていいと思うか?

>>47
malloc(strlen(s) + sizeof(char)) って書くってこと?

恒久的に一本一リットルなら何の問題もないだろ。

>>50
恒久的にってのもだけど、論理的にも一文字1バイトだし。

俺もsizeof(char) == 1 だと思ってたけど、TCHARがWindowsのAPIがらみの定義らしいとこまで調べたので、strlenもwindowsの特殊仕様な可能性を考えてました。
(引数の型がTCHARとやらに変わるなど、思い込み)
無知なのに口だしてごめんなさい。

strlenがchar固定。sizeof(char)==1バイトが、規格から明らかならば、
sizeof(char)はいらないよね。

察するに>>40,>>43は「バイト数」と言う言葉と、「文字数」という言葉を
厳格に分けたいというところかな？

それに対して、１バイト==sizeof(char)は規格上定義されているから
分けて考える必要はないという反論。ってことですね。私はこっち派。

>>47,>>49
このスレで議論の中心になってるのは、+1ではなくて、
>>1の１行目、"sizeof(char)*" -charのサイズを掛けている-部分だと思うよ。

>>49
どこから、そういう発想がでてくるのだろ。

size_t CalcRequiredMemoryForString(const char* s) {
return sizeof(char)*(strlen(s)+1) ;
}

もっと細かく分けて

size_t ScanAscizStringLength(const char* s) {
return strlen(s)+1 ;
}

size_t CalcRequiredMemoryForString(const char* s) {
return sizeof(char)*ScanAscizStringLength(s) ;
}

とかでもいい。

そしたら、
char* s2 = malloc(CalcRequiredMemoryForString(s)) ;
と書けるようになるっしょ。

論点は、　(1)charのサイズの問題　(2)sizeof(char)を書くか　なのかな。

(1)はラッパを書く、(2)は書いたら弊害があるのか？　でダメ？

>>53
strlen()+1だけの関数とか、そんなのつかってるのオタクの職場くらいですよ。

>>53
壮大な釣り?
＞size_t ScanAscizStringLength(const char* s) {
string lengthはどう考えてもstrlen()の戻り値そのままだろ。
stringに形容詞がつくだけで長さが変わるなんて気色悪い。
getStringSize()って名前なら判らんでもないが。

で、malloc(sizeof(char) * stringSize)なら「あ〜あ、一一書いているよ」で済むが、
malloc(CalcRequiredMemoryForString(string))なんて書いていたら「戯け」の一喝だな。
# CalcRequiredMemoryForDoublePrecReal()なんてのも作るのか?

>>55
ふつう文字列クラス使うよな。

strlenとかstrcatとかstrcpyなんて直接使わないもの。

>>56
ふつうC++なので、やるとしてもテンプレート関数だな。

>>57
mallocとか使ってることから、ここはC限定ではないのかな？

>>53
そこまで書くんだったら >>49 程度で済ました方が良いと思う。それと、その関数名だと長すぎて使いたくない。

>>54の(2)sizeof(char)を書くか
http://www.kouno.jp/home/c_faq/c7.html#8

一般的には、どっちでも良いってよ。

ポイントとしては、
無知やうっかりミスによってバグを生じさせない
ということ。

+1が必要なことを知らない人もいるし、
+1を書き忘れることもあるし、
sizeとlengthを書き間違えることもある。

じゃぁどうすればいいか。
Cを捨ててC++で文字列クラスを使うべき。

>>59
C++でもmalloc使う人いるんだよねぇ。

> >>49 程度で済ました方が良いと思う。

strlen(s) + sizeof(char)
これこそ意味不明だねぇ。

1文字分ってことなら、
sizeof(char)
ではなく
sizeof(char)*1
としないとねぇ。

そうするなら
sizeof(char)*(strlen(s)+1)
になるわなぁ。

> その関数名だと長すぎて使いたくない。

いちいち手でタイプする人いるんだよねぇ。
ミスタイプしたりするからコピペが基本よ。

>>62
長い数式を書かない人なんだね・・・

>>53
まあ、常識的に考えてこんな関数つかわねーよな。

>>53とか>>55>>56とか
void *getBufByLen(int length)
{
　return malloc(length + 1);
}

まぁこのぐらいのラッパなら良いんじゃないの？
strlen(str)+1がどのぐらい出てくるかにもよるんだろうけどさ。

どうしても「+1」をソースコードから出来るだけ消したいなら、俺なら
#define LEN2SIZE(x) ((x)+1)
でも作って、LEN2SIZE(strlen(str))で書くか。
したら、今度は副作用がどうとか言われんのかねぇ。

>>65
そこまでして+1を消すと、かえって読みにくくなるよ。
strlen(s) + 1 と直に書くのがいちばん素直なCのコード。
技巧に走りすぎてもよくない。

>>66
そうは思うけどさ。
たまに上司の好みで結構色々言われんのよ。
（俺も多分好みで妙なコード書いてるとは思うけど）

んで、そこで激論しても時間無駄だから、
まぁ良いかと思えることは従うことにしてる。

今のところ「+1消せ」は言われたことないけど、
そういう指示が出たらこうするかな、ってぐらいのモン。

>>62
ごもっともです。

ところで、もともとの質問主の環境は VC++6.0 みたいですね。
素直にC++の文字列クラスを使うのがいいのかな...

>>65
getBufByLenではなくallocBufByLenにしたほうがいいと思う。

>>62
>C++でもmalloc使う人いるんだよねぇ。
それは酷い。

ひょっとしてJavaに移植するときとか、そこまで考えてるのか？
Cだけなら sizeof(char)==1 が仕様で定義されてるけど

乱れる倫理。１０歳以下のセミヌード！
http://www11.big.or.jp/~magmell/science/watchfiles/semi01.jpg

うわ・・本当に脱いでる・・・

蝉の脱皮だろ

この板では空気を読む必要は無い。

>>71

#include <stdio.h>

int main()
{
printf("%d\n",sizeof(char));
return 0;

}

をCでコンパイルしてみたか？
C++でもコンパイルしてみたか？

>>72
これはアブラゼミだね

>>75
CとC++でsizeof(char)は絶対１なのは仕様で保証してるんだけど・・・

1バイトは8ビットとは限らないが、charは1バイトと規格で決まっている。
ってことでしょ？

>>75
もう帰れ無能。

>>43
Cの規格での「文字」の定義は「1バイトに納まるビット表現」。
規格書ちゃんと嫁。

>>80
文字っつーかcharな。単に文字とか言うとまた噛み付いてくるで。

>>81
>単に文字とか言うと
規格に於ける定義の話をしてるんだが。

>>82
それならきっちり「文字型」といった方が誤解ないよねとか
文字とだけ言うとシングルバイト文字とマルチバイト文字を
ごっちゃにするやつが出てくるから 規格話するなら正確に
みたいあｎ

>>75
関係ない話なんだが、
sizeof演算子の結果の型はsize_tだけど、こういう場合はintにキャストしなくていいの？

>>70
C++だろうとmallocは使えるでしょう?
mallocしたものをdeleteしたりしなければ。

>>80
charが1バイトなのは当然として、
1を掛けるのを省略して書いて良いのかどうか
という問題だろう。

>>85
使えるけど、new があるのに
>mallocしたものをdelete
する危険を冒してまで態々使う意味が判らない。

>>86
「省略しちゃいけない」とする理由が
「文字数とバイト数は意味が違うから」であれば、
規格上は「文字」＝「1バイト文字」であり
「文字数＝バイト数」であるから
「省略しても問題ない」よね？という確認。

問題は無いね
どうすべきかとなると宗教論争になりそうだ

>>86
C FAQにあるよ

つきつめるとCHAR_BITすら意味をなさないからあまり気にするものでもないと思うが

>>87
> 「文字数＝バイト数」であるから

それは数値の一致であって、意味の一致ではない。
あくまでも「1バイト文字」の「文字数」なのだから。

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

>>91
はあ…
>それは数値の一致であって、意味の一致ではない。
意味の一致だってばさ。頭悪いなあ。
「規格では、strlen() はバイト数を戻す」
これで納得した？

charやstrlenをハードコーディングしちゃうなら*sizeof(char)を書く意味はほとんど無いと思うなぁ。

>>87
new使ったってその危険はdeleteとdelete[]を間違える危険にかわるだけじゃね？

なんつーか
みんな暇なの？

規格では、strlen() はバイト数と等しい値を返す
だろ?

strlenの返す値の意味がバイト数ではなく文字数だと言いたいんですかね。

そんなに不安ならコメント書いとこうぜ

>>96
格納するのに必要なバイト数
ではないのは確かだな。

>>1
アルファベット＝レターと非アルファベット記号＝キャラクターとストリングの意味からして、strlenが間違い。

外人は文字が2バイトかもしれないなんて考えてないから、
strlenという関数名なんだろ。

>>94
意味のない議論をしたがる厨房が集まってるだけだろ

このスレ、すんごい伸びだな。

>>84
整数型の暗黙の変換ルールがあるから問題ない。
ただ、size_tは符号無しだから、
intに変換されることで情報が失われるかも分からんね。

>>100同感
2バイトあれば全世界の文字が収まると勘違いしていたしな。

してません

このさい8バイトでいいだろ。

>>100
記号一つに2バイトなんて無意味だし不可能。
strlenが誕生した時代は数バイトのメモリが数万円。

んなわけないだろ

そんなにsizeof書きたくないんだったら高級言語つかえよ

なんじゃそりゃ

そんなにsizeof書きたいんだったら高級言語使うなよ

>>108
PDP-11は、メモリ64KB程度搭載で、1万ドルくらいだったそうだな。
当時の為替レートからすると、360万円か。

数バイト数万円は違うが、数Kバイト数万円くらいだな。

>>111
C言語は高級言語ではないな。

>>112
メモリのコストはその一部でしょう

>>1
#defineで定義しておけ。

>>114
昔のコンピュータは、メモリのコストは一部なんてもんじゃなく、かなりを占めていたのよ。

MSXの32KB増設RAMカートリッジが1万円以上だったのを
思い出したような

Cができたのってやっとシリコンメモリが普及し始めたころだっけ？

>>84
キャストするべき。
size_tがintと同じサイズである保証は全くない。
sizeof(int) == sizeof(long)の環境に限定するなら、省略するのもありかも試練が。

C FAQを見てはいけないスレはここですか？

>>118
PDP-11の頃

>>120
C FAQは聖典ですか?

聖典ｗ

>>121
>C FAQは聖典ですか?
いいえ、常識です。

>>100
>>107
UTF-16とか思い出してあげてください。

>>123
C FAQ では、sizeof(char)を使うのは、プログラムがわかりやすくなるから、一興だと言ってるが?

>>124
UTF-16は1文字=2バイトじゃねーよ

>>125
ぜんぜんいらねーよ。

とも書いているね。まあどっちも正しいってことだな。

書かなかったからといって不正なプログラムというわけではない。

ということだな。

>>126
小学生からやり直せ

>>129
Cにおいてsizeof(char)=1は仕様だが、
1バイトが8ビットなのは仕様ではない。

つまんねー内容をだらだらだらだら
何を言い合ってんのおまえら (w

ここの人達が、同じプロジェクトに放り込まれたら、
どうなるんだろう...
C FAQ は理解しやすくなる「かも」とかいてあるけど、
逆に意図が分からなくて困惑する人もいるかも。

同じプロジェクトに入ったら個人レベルでソースファイルを分割し
他人が担当しているソースファイルは一切見ないようにすればＯＫ。
レビューとかあれば、同じ信念をもち曲げないメンバーでする。

そんなプロジェクトやだなぁｗ

>>130
>>100と>>107がC言語の規格が決まった当時の話をしてるのに、
>>124はもっと最近の話をしてるところが突っ込みどころなわけであって。

ナニコレ。
＞UTF-16は1文字=2バイトじゃねーよ

＞Cにおいてsizeof(char)=1は仕様だが、
＞1バイトが8ビットなのは仕様ではない。

誰がUTF-16の1文字=2バイトとか言ってんだ？
んー・・・もしやUTF-16は1バイトが8ビットの環境て使うべきでない、
とかそういう意見をお持ちの方？

>>134
charは文字だろ

って話の寄り道だったんじゃないか？

マロック・ストラレン

文字の型を隠蔽してsizeof(TCHAR)でいくね

>>137
C++ のクラスをWin32とWinCEで使いまわす俺には必須だぜ！

ところで、>>129 がどこに突っ込んでるのかが知りたい。
UTF-16の1文字は2バイトとは限らないし
2オクテットとも限らないわけだが。

1バイトのビット数ってこの話にはあんまり関係ないような

>>138
根本的にズレてるって意味だろう。
>124 は別にUTF-16が1文字=2バイトだとは言ってないから。

>>138
Win32でもUnicodeでやればいいじゃんかー。

スレの趣旨がわからなくなってきた

1nibble=4bit

1nibble=4bit
1byte=8bit
1word=16bit
1dword=32bit
だっけか
環境とか詳しいことは知らんが

1ワードは36bitだよ。

1byte=8bitとは限らない。

32ビット256Kワードとかよくある話だな

>>142
暇つぶし

結論。
必ず１だから省略すべし。

省略するのは最適化コンパイラの仕事であって人間の仕事ではない。

コンパイラは省略しません。そういう意味では無駄にコストが発生します。
# 勿論、コンパイルのね。

>>151
いや、定数の演算だから消えてなくなるだろ

もう、どっちなんですか！！！？

>>152
消えてなくなると言うことは、コンパイラは省略せずにちゃんと最適化したということですね。

意味はあっても価値はない。ってところかしら？
価値が無いからと言って、消して良いのか？
でも最適化でけされるよ。
消されなかったら実行時のコストだな。
じゃあ、今、消しておこう。

消してしまったsizeof(char)を復元する必要が出てきたときに
莫大なエネルギーが消費されるからそのままにしておいたほうがいいお。

仕事でスパゲッティコードをリファクタリングしたときに、
元のコードをコメントで残しとけとか言われて非常に苦労した覚えがあるお。

＞元のコードをコメントで残しとけ
リファクタリングもへったくれもありませんな。

>>156
>復元する必要が出て来たとき。
上の方で誰か書いてたけど、ラッパー関数にするか、マクロにするかして、
一度に変えられる様にしておけば良い。
復元してもどうせ１だからそのまま使う訳じゃないだろう。

>>156
＞sizeof(char)を復元する必要
Cの仕様が変更にならない限りその必要は無いからな
どうだろうな

subversionでいいじゃん

…そう言って通る職場なら良いけどな

svn厨は退場してください

じゃあＣＶＳで・・・ごめん、悪かった

それならよし！

それでいいんかい！

ふつーbzr

もうねmallocなんてあちこちで書いてちゃだめなんだよ。
ラッパーとか言うのも違うな。
構造化だよ。オブジェクトを作る段でだけ利用するんだ。
そもそもＣ＋＋の偉い人がnewなんてすばらしい関数を
用意してくれているんだから、new使えよ。

Ｄの偉い人が動的配列なんてすばらしい機能を
用意してくれているんだから、動的配列使えよ。

vector使うお！！

え？newって関数なの？演算子かと思ってたんだが・・・

C++のnewは演算子だな。

newだって寿命管理はプログラマがやらなきゃいけないわけで、
mallocと同じように、
考えて使うところを狭めないと、
収拾が付かなくなる。

ってことはoperator newでオーバーロードできたりするの？

>>173
何を今更。だからやろうと思えばOS管理外からメモリを引っ張ってくる事だってできる。

smart_ptr<T> ptr = Allocator<T>();
みたいなカスタムアロケータ用意するとか

演算子は全て関数だと乱暴な言い方も当然出来る。

>>176
挙動が違うんだけど。

で、sizeof(char)の省略いいの？わるいの？

いい

文法的にも、プログラム的にも、省略するのは間違いではない。
だが、
プログラムを人間が読んで理解する上では、省略しないほうがよい。

>180みたいな人間に合わせるために、省略しない方がいい。
>180みたいな人間が見ることがないコードなら、遠慮することなく省略していい。

>>180
そもそも理解の妨げにならない、という話をしてるんじゃないのか。

>>180
逆、コンピューターの作法に人間が合わせてるだけ。
人間様はシンプルな方が理解しやすい。

>>182
>>180 は理解が足りない、って話じゃないの？

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

>>185
>181

#define SZCHAR 1

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

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

こうすればいいじゃね

>>187
aho

>>187
βακα..._〆(ﾟ▽ﾟ*)

>>187
Ma nuke.

>>185
汎用的に書くからには、それで正しく動作するように書き、テストもすべきだ。
見かけ倒しで実際にはダメなんてのは迷惑。
だから、charでしか正しく動作しないのであれば、charで書いておくべきだ。

VCならTCHAR使えってこった。

_TCHARとTCHARの違い、わかって言ってる?

>>188
気やすくAhoと言うな。

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

/*sizeof(char)*/

なんかchar型のサイズが1バイトって前提の話になってるけど
C++だとcharのサイズって1(単位なし)だよな。
で、各型のサイズはcharのサイズの整数倍であることが保証されている。

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

>>196
1バイトが8ビットであることも決まっていない。
CHAR_BITは8以上となっているから、1バイト=7ビットでは規格合致できないけど。

>>196
C、C++は 絶対何があってもsizeof(char)は1バイト
と規格で定めてる。
それ以外の環境はありえないし存在しない。

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

>>197
とりあえず、規格上のサイズ指定に使われている単位と
環境上で実際にサイズ指定に使われている単位って違うよなってことを
指摘したかっただけなんだ。

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

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

>>199
そういうこと。外から見てcharが2オクテットだったとしても、
CHAR_BIT == 16にして、sizeof (char) == 1にすれば規格合致できる。

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

>>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に渡すときはそれを
使ってバイトサイズに変換しろっていうまとめをするとすれ違いにならないかな?

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

>>202
＞17文字余計にタイプすると人件費にして2円位になるから
計算方法kwsk

>>201
wikipediaでもなんでも見ればいいだろ。

>>203
例えば1500円/人時で5秒2円位。17文字タイプだとその位にはなる

>>201
ISO/IEC 14882(C++の規格だ） の5.3.3 Sizeof にこう書いてある。

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

>>206
いや、お前さんは流れ読めてなさ杉だろ。

#define sizeof(char) 1

>>207
＞charのサイズが2バイトのC++環境とかだと
っていう>>201の前提がこれで無くなった っていうだけだよ

>>201後半
それはない。
そうだとすると、malloc(2)の返すポインタが
要素数2つのchar配列として使えないという意味になるではないか。

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

>>209
sizeofの単位がバイトとはどこにも書いてないだろう

>>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とした環境依存。
実用上同じでないと使い勝手が悪いというのならそれには同意。

C99ではsizeofの結果はバイト数ってことになってるな。

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

>>212
The sizeof operator yields the number of bytes in the object representation of its operand.

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

>>201
次のネタどうぞ

sizeof()の返り値はバイト数
malloc()の引数はバイト数

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

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

The strlen function returns the number of characters that precede the terminating null character.

1を掛けても掛けなくても数値は変わらないよね

strlenの引数は char* だから文字数＝バイト数と考えてよいのでは？
それとも漢字が混じるとそれも1文字として扱われるだろうか？
だとしたら、sizeof(char)掛けてもバイト数にはならないよね。

>>216
戻り値はキャラクタ数
1キャラクタは1バイト
よって戻り値はバイト数

ってことだね

それは数値の一致であって、意味の一致ではない。
あくまでも「1バイト文字」の「文字数」なのだから。

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

仕様上キャラクタ＝バイトです。
たまたま文字を意味するときだけ
わかりやすくキャラクタと表記します。
そのため、byte という型はありません。

だってさ。なるほどね。

？

>>221
1バイト文字の文字数がバイト数と等しいと見なすことの何がいけない。

プログラムのコードに現われない、暗黙の変換を行うから、いけない。

>>225
暗黙じゃないだろ・・・

>>225
こんな自明な事柄、変換じゃないだろ。

自明だからといって省略するのは、悪い癖だなぁ。

そもそも変換じゃないだろ。

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

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

お前ら、こんな下らない話で、よくここまでスレを伸ばしたなぁ。

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

最近はもうC自体あんまり使わない

>>231
話がループしてるからいくらでも伸びる気がする。
ところで、
「散在させる」ってのはどこから出てきた？
strlenを使わないなら何を使う？(あくまでCだとして)
sizeof(char)を省略すべきでない？

ここでstrlen_sだなんて言ってみるテスト

>>231
くだらないからこそだろう

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

>>233
マクロ、ライブラリ、クラスの中で使うのではなく、
ベタベタと書くコードの中で使う = 散在させる

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

そうだ、マルチバイト文字が存在するからいけないんだ!
今日から、みんな、英語で生活!
それで全員ハッピーだ!

Die job death car?

>>236
「散在させる」はスレの流れから読み取ったわけじゃないのね。

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

ここで新たな判断基準を持ち込んでみる。

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

馬鹿発生

アホが来たよ・・・

>>231
C言語なら「普通」strlenを使うと思う。

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

今時charの内部形式を意識しないといけない言語は使うな。

>>243
何かにつけてstrlenする、糞遅くて信頼性の低いプログラム書いてるのか。ご苦労さまです。

本当、何かにつけてstrlenの必要に迫られるCは疲れるよ。

>>245
C厨だがそこには同意

strlen

struct {
size_t bufferLen ;
size_t validLen ;
char szBuffer[1] ;
} ;
とかの構造体を使って、バッファの長さや有効長を管理したらいいじゃないか。
szBuffer[1]と言いながら、実際にはヒープから長い領域を貰うのは気持ちわるいかもしれないが。

>>245
自分がそうだからといって人もそうだとは限りません。
間抜けですね。

>>249
そこまでするくらいならC++使う。そもそも使えるときは使っている。

>>250
どんなコードを書いているのか披露してほしい。お手本にするから。

>>245
fgetsで文字列を読み込んだり、コマンドライン引数を受け取ったりした際に
得られた文字列長を調べるための、strlenより高速で信頼性のある方法を教えてくれまいか？

freadを使う

それはstrlenより高速で信頼性のある方法なのか？

>>253
まず、得られた文字列の長さを調べる必要が、本当にあるのかな。
次に、何かにつけてfgetsするのかな。

必要あるからする

本当は必要ないのに、必要だと思い込んでいる可能性を疑ってみた?

もちろん

で、strlenより高速で信頼性のある方法は？

じゃぁ>>253は具体的にコードを例示してね。

strlenより高速で信頼性のある方法マダー？

strlenよりも高速で信頼性のあるstrlen互換の関数の話ではないぞ。

基本的に、
気やすくstrlenやstrcpyを使わない
ってだけで、かなり速くなるし、安全性も高まる。

酷い例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') { なんたら }
}

strlenよりも高速で信頼性のあるstrlen互換の関数マダー？

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

>>267
> strlen,strcpyの安全性が低く感じるのは、呼び出し元の安全性が低いから。

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

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

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

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

安易に使わないってどゆこと？

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

>>269
実際にどんなコード書いてるの? 晒してみなよ。

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ぐらい普通に使うと思うんだけどねぇ。

なんかボーっとしてる間に、えらいスレ進んでてびっくりだ。
253と271とコレ以外は俺じゃないんで一応。

>>271
それは
「何かにつけてstrlenする」
には該当しないと思うが。

>>272
すまんね　>>257と>>259は俺だ
君の振りをしたつもりは無いんだけどね

こんなどうでもいいことを真剣に議論してるｗ
ワラタｗ

それはよかった

>>273
>>243に対して>>245だったから、strlenを全否定してるように見えたんで、
「まぁ使うんじゃないの？」ぐらいの感じで書いただけだよ。

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

結論は出ましたか。

結論：
sizeof(char)は省略してもいい
strlenは必要な場合もある

上げんな糞
>>1死ね

adobePの新作期待age

>>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でないならわかるが

まあCとC++に限って言えば100% 1だからなぁ

いい加減ループしすぎ。

まぁスレタイがねループしてくださいって言ってるようなもんだからね

ループといえば for(;;) と while() の戦争もあったな
オレは意味なくdo〜while派だけど

じゃあ俺はgotoを使うぜ！

三木は3つまでしかまとめられなかったので 3岐
後藤は5匹を統括してたから 5統

ﾅﾂｶｼｽ

ネオジオは100メガビット

>>288
三木は右手だからじゃなかったっけ？

それもあるな
なんかこう言葉遊びもあそこまで行くと芸術レベルだよな

>>284
今頃ノコノコ出てきて画期的なご意見を述べて行かれる
>>282 みたいな間抜けがいる限り、ループは不滅です。

exit(0);

いまどきマロックなんか使うかよｗ
newを使えnewを！

VirtualAllocは多用しますが何か?

sizeof(char)+1が必ず2でも、省略すべきではない
http://pc11.2ch.net/test/read.cgi/tech/1187521586/

再帰

おもしろいことに、関心と一般の議論の大きさは、
機能の重要性と反比例していることが多い。
その理由は、大きな機能より小さな機能のほうが明確な意見を持ちやすく、
流行のような、一時的な関心を引きやすいからだ。
〜〜Bjarne Stroustrup『C++の設計と進化』

>>299
そして、プログラムとは、小さな機能を集めて大きな機能を実現していく。
だから、小さな機能を議論することは、最終的に大きな機能
そして、重大な機能を議論することにつながるのである。

ああいえば上祐

ttp://msdn2.microsoft.com/ja-jp/library/xa1a1a6z(VS.80).aspx

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

http://dist.dc.kumamoto-u.ac.jp/~km3534/12/index.html
の問題2
「自分なりの理由」があればどちらでも良い。
という答えな気がする。

>>303
純真な若者に示す手本として、
s = (char *)malloc(sizeof(char)*n + 1);
というのは、随分と酷いな。

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

意味として間違ってる!

>>304
まあね、書くのならこのスレの様に
sizeof(char)*(n+1)
のようにヌル文字分も含めるべきだね。

>>303
どうしようもない問題集だな。特に問題4の辺りは終わっている。

演習3のプログラムも酷い。

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

>>303のURLのソースを見ると、スタイルシート"masato.css"を使ってる。

ttp://www.kumamoto-u.ac.jp/
のトップページでmasatoを検索すると、
ttp://www.syst.cs.kumamoto-u.ac.jp/~masato/pe2/index.html
がヒットする。似たようなセンスの問題が。

ttp://www.syst.cs.kumamoto-u.ac.jp/~masato/pe2/02/index.html
の問題4は、>>303の演習3と似てる。

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

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

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

だって、Apache インストール済みだもん。
ttp://dist.dc.kumamoto-u.ac.jp/

ttp://www.syst.cs.kumamoto-u.ac.jp/~masato/pe2/02/index.html
> 問題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;
> }

>
> 1. 「配列aとmallocで確保された領域bの違いは，
> 静的に確保されるメモリ領域と，
> __に確保されるメモリ領域という違いがある．」
> __に入る適切な言葉を以下から選びなさい．
>
> a.愛ゆえ
> b.俺的
> c.仮想的
> d.動的
>
> 2. b[2]の型は何ですか？

これは問題の間違いを正しなさい、という課題なのかな。

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

さらに、for文の書き方が酷い。

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

sizeof(char)の話に集中しましょうね。

大学のプログラミング演習の課題を添削するスレ
http://pc11.2ch.net/test/read.cgi/tech/1188501699/

>>302
そういうことやってるから細かいバグが残ったりなかなか取れなかったり
するんだろ。しっかりしろといいたい。

そうだな。

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

世界一安定してる会社のコーディングスタイルならともかく、バグだらけの会社のそれを例に出されてもな

>>317
コード量が膨大だから、バグ含有率が低くても、バグ件数は膨大になるんだよ。

>>318
ああいうコードが積み重なってるからね
バグが多くなるのもうなずけるよ・・・

>>302
ほんと、あそこのサンプルコードってゴミばっかりだよな。

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

また1つごみを見付けたんで記念カキコ
http://msdn2.microsoft.com/ja-jp/library/y0cka9es(VS.80).aspx

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

>>321
酷すぎるｗｗ
その前にあるNULL代入も意味無いしｗ
constもキャストもないからコンパイルも通らんだろうなｗ

何がやりたいのかよくわかんねーソースだな

>>321
あれだな、
1.まず鍋を用意します。
2.次に鍋を投げ捨てます。
3.そして既に作っておいたカップラーメンを食べます。
みたいな感じか。

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

>>321
非NULLは真になるよって言いたいんじゃまいか

せめてnew char[12]と書けよと思う。

strcpyしたかったのかな。"Hello world!"で12文字だからnew char[12]じゃ足りないけど。
str.CopyChars(str.GetBuffer(), "Hello world!", 12);　と書いとけばいいのにｗ

>>321は良い踏み絵だな
判ってない奴が浮き出てきた

charというのは組込型ではなくクラスなのか?

>>328
何が？

>>329
ATL/MFC のコードなんだから C++。
なので char はクラスではない。

>>328
>>327みたいな奴の事だろう

>>332
>>327みたいな奴は何がわかってないの？

>>328
よく判ってないんで、>>321のソースを解説してはくれまいか？

// 動的に確保した領域のポインタをpszSrcに代入
pszSrc= new char(12);
// newに成功した場合
if(pszSrc)
// 動的に確保した領域を無視して、文字列リテラルのポインタをpszSrcに保存
// 動的に確保した領域はリークする
pszSrc= "Hello world!";

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

＞// 動的に確保した領域のポインタをpszSrcに代入
＞pszSrc= new char(12);
構文エラー。

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

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

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

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

>>335
　　pszSrc= new char(12);
は、C だと↓こんな感じ。
　　(pszSrc = malloc(1)) = 12;

あああ尻穴忘れた！
　　*(pszSrc = malloc(1)) = 12;

>>336
12はcharの初期化子として有効。エラーにはならない。

エレガントなメモリリークだなぁ

mallocが失敗する可能性は考慮しないのか？
つーか、mallocってNULL以外が返ったとしても
実はメモリ確保に成功したかどうか不明だという
おそろしいバグがあるんだがLinuxって怖いよな

mallocやnewが失敗する状況って、かなりヤバいよね。

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

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

＞だから、mallocやnewに失敗した時点で、OSから再インストールするハメになるわけで、
おいおい、普通はrebootで充分だろ。

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

>>343
rebootで十分という保証があれば、ね。

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

OSからとかねぇよｗ
書き込み中の電源断でさえジャーナルファイルシステムなら通常問題無いのに、
メモリ確保失敗くらいで整合性取れなくなるとかｗ

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

1GiBのメモリ確保しようとして失敗したって状況なら、
メモリ確保失敗したとユーザに通知したり、
そのために数KiBのメモリを確保したりしようとしてもいいと思う。

>>345
ファイルシステムのレベルで問題がなくても、ファイルの中身のレベルでは問題だよ。

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

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

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

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

＞ユーティリティか何かがhttpd.conf壊したって、
＞OSどころかapacheから入れなおす馬鹿は居ないだろ。
見たことあるな。
俺はこれをWindows病と名づけた。

あーいるいる、「取り敢えず再インストールしてみました」って香具師。

ネトゲのクライアントは、たまにWindowsの設定やらシステムファイルやらをぶち壊す奴が居る

あ、補足。
多分mallocは関係ない。

しばらく前、幻想三国志2っちゅーゲームでアホほど再起動かかってOSが不安定になった。
再起動の原因がメモリリークと気付くのが遅すぎた・・・。

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

突然だがスレを激しく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);

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

＞文字数→バイト数として扱いたい意図
ここは自明だろーがよ
というのが反対派の意見だと思う。

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

>>354
一方俺はC++を使った。

まぁ、俺も現実的にはC++使うな。
だけどC++使うからこそ観念的に省略しないんだけどな。

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

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

誤記は脳内保管で。

>>357
ぶっちゃけ未対応ソフトの多バイト文字対応をするときは
charをwchar_tに機械変換♥ なんて絶対しないから
もうその辺はすごい勢いでどうでもいい話だと思う。

そもそも文字型が独立しておらず、charやunsigned charが
整数型の1つである（JavaやC#でいうbyteにあたる型）という時点から
もう文字とバイトをごっちゃにするのは始まっている。

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

機械変換とかじゃなくて、テンプレート関数の話な。
allocator((Tr::getlen(s)+1) * Tr::char_size);
みたいな感じで実装して、型はコンパイル時に決まる。

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

ぶっちゃげcharだけなんてXMLも扱えねぇよ最近。

>>360
文字とバイトがごっちゃというのは整理出来ていないから。

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

型について、ちょい脱線するけど・・・。
時刻を保持する型を使ってて、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 を入れるとか、
場合によってはハードコーディングとか、もう見てられない。

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

ミリ秒以前にうるう秒

<= じゃなくて < を使えば済む話じゃないのか

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

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

>>363
文字とバイトがごっちゃというのは俺に言っているのか？
俺は、CとC++が文字とバイトをごっちゃに扱っていると言ったつもりだ。
だから俺にそんなこと言われても、お門違い。

wchar.hなど有るし、文字とバイトをごっちゃに扱ってるようには思えないが・・・
それにchar==文字でなく、char*==nul終端文字ストリームというのがあったから
SJISなどをそれなりに扱えて来たわけだし。

ちなみに、java,C#などは文字型が本当の意味で独立してるわけじゃなく、
単に内部のエンコードを割り切ってUTF-16に統一してるだけ。
昔、C言語がasciiで十分と考えたように。

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

UTF-16もサロゲートペアを考えるとchar==１文字とならない。
Unicode領域で固定バイトが出来るのはUTF-32だけ。
でもascii１文字に4byteも使うことと、
サロゲートペアの文字があまり重要でないことからUTF-32で扱っているシステムは少ない。

未来の言語のcharは32bitかもしれない。

おれは>>355と同じように考える。
>>357,>>361で抽象化とか総称化とかって話がでてるけど、
そのようなケースになったときは、そう書けばいい。

しかし、このスレでは‘sizeof(char)’は抽象化されてない。
あくまで、>>1の記述に的を絞って考えたらやっぱり冗長かなーと。。。

>>354
> char*    strmalloc(int len){return len<0?NULL:malloc((len+1)*sizeof(char   ));}

len=0のときにNULLにしてしまうのは、ちょっと馴染みがないんだが。

え？

>>354
その引数lenの型は、size_tにして、条件演算子は排除。

>>373
len<0が0を含むっていうのは、ちょっと馴染みがないんだが。

ごめん、寝ぼけてた。
真と偽を逆に見てた。

>>375
あ、確かに、size_tだな。size_tってunsignedって保証あるんだったっけ？
\0を入れられない、len==-1(len+1が0に)でNULL以外が帰ると都合が悪いので負の数を弾いてた。

>>369
例えばmemsetなどのmem〜関数がごっちゃにしている例。

wchar_tはいいが、後付なのでここでは省きたい。

Shift_JISなどはマルチバイト文字なのだから、
char1つで表せないのは当たり前のことだ。

>>370
charが単に16ビット符号無し整数型とは別に存在するだろ。
Javaにはそんな整数型は無いが、いずれにせよcharが
整数として演算可能な型ではないことを言いたかっただけ。

>>371
D言語はUTF-32も扱える

>>379
「D言語は」って・・・Cだと扱えないのか？

>>379
そりゃmem*でも文字列は扱えるけど、普通は str* wcs* を使うだろう。
文字列にmem*使う奴が悪いと思うが。

>wchar_tはいいが、後付なのでここでは省きたい。
Cの規格自体、かなり昔から何度も改訂されてるし、
今ではwchar_tも正式な仕様なのに、後付け扱いはあんまりかと・・・。
まぁCではtypedefなんで後付け感は確かにあるけど。

> charが単に16ビット符号無し整数型とは別に存在するだろ。
> Javaにはそんな整数型は無いが、
> 整数として演算可能な型ではないことを言いたかっただけ。
javaのcharは16ビット符号無し整数で、整数として演算可能だよ。

> D言語はUTF-32も
プログラミングで言えばlinuxのgccのwchar_tも32bitだっだはず。
俺が言いたかったのはUTF-32を内部コードとして使ってるOS,ライブラリ,ソフトウェアが少ないってこと。

>>380
UTF-32用の組み込み型があるって意味だと思う、
（Dはそもそも強いtypedefがあるから、組み込みでなくても問題ないけど）
「標準」っていうことが重要になる。

標準でないと、各々作ってしまう。
typedef unsigned longならまだいいけど、
構造体やクラス化されると他ライブラリとの互換性がね・・・。

>>378
size_tは普通 signed な何かです。

いいえ、unsigned intかunsigned longであることのほうが普通です。

ssize_tと間違えていたよ

>>371
D言語はUnicodeを知っていて、UTF-8,-16,-32の変換は勝手にやってくれるらしいぜ。

import std.stdio;
void main() {
string s = "AΑあ"; // UTF-8の配列
writefln(s.length); // 当然長さは、6
foreach(i, dchar c; s) // UTF-32で取り出す
writefln(i); // 0, 1, 3 ... 自動でUnicodeスカラ値単位に区切ってくれる！
}

> // 当然長さは、6
当然？

素直に考えれば、長さは3だと思うけど。

string は const(char)[] のaliasだから、ただのUTF-8シーケンスなのです。
だから、長さは6なのです。

Dはちょっと見ないあいだにますます変な機能が追加されてんだな

const(char)[] って何だよｗ

D言語って、そんなに悪くないと思うよ。
同じことをC++でベタベタとコードを書いたり、
可読性の酷くわるいマクロや、テンプレートを駆使しすぎるよりは。

385はうそっぱちなので真に受けないでください

デーげんごっていつのまにかたいへんなことになってんだな

さすがに、みんな飽きたな。
次のネタを検討しようか。

引数を1つしか取らないようなprintfを書くな。
そういうコード例の参考書は買ってはいけない。

ってのはどうよ。

Cの標準化の人達は、なんで、print を用意しなかったのかな。
putsとカブっているとはいえ、引数1つのprintfが氾濫するよりはマシだろうに。

puts は最後に改行文字を出すぞ

文盲？

コンパイラが最適化するからどうでもいいんじゃないの？

>>393
よくあるprintfの酷い使い方。

printf("==== ほげほげ version 1.0 ======\n") ;
printf("Programed by foobar\n") ;

一行ずつ別々にprintfを呼ぶなら、putsでもいいんじゃないか。

>>395
そんな変な最適化をするコンパイラなんて捨ててしまえ。

そういうのに慣れていると、
printf("私のコードは100%safeです。\n") ;
なんていう恐ろしいことをやる馬鹿が出てくるんだよ。

puts, gets, putchar, getchar, printf, scanfまるごとなくしてしまえ。
f版でいいよ。

gets, putsとfgets, fputsは微妙に挙動が違うのが癪だが。

少なくともgccはフォーマット文の中身まで見て最適化するよ

gccが最適化するからprintfを変な使い方をしてもいい、というのは間違いだと思う。
すでに書かれてしまった膨大なコードのために、変態な最適化をしてくれるのだと思う。

void OutputMessage(char* s) {
printf(s) ;
}

こんな関数があったとしたら、
OutputMessage("100%safe") ;
なんて呼び出す輩が出てくる。

gccがprintfの引数を見て最適化してくれればバグが顕在化しないが、
最適化しない環境に持っていけばバグが顕在化してしまう。

>>397
俺的には-Wallで警告出るから問題ない

>>402のようなのは警告でないっしょ?

でるよ。

>>401
俺は何でもかんでもprintf使う方だけど、コレは無いなぁ・・・。

void OutputMessage(char* s) {
printf("%s",s);
}


puts、fputsなんてここ5年ぐらい使ってない。
対話なCUI作るときは(滅多に作らないけど)cursesなことが多いし、
ログ出力は定型で吐くラッパ作ることが多いし、
出力部分をgrepするのに、いちいち正規表現やなんかで色々指定するのダルい。

>>405
そのまさかをやる人間が少なくないのですよ。

printfに渡す文字列に対してサニタイジングを行うべし
なんて真顔で言う人間までいる。

あたしゃprintf("<>")なんてのはやるがね。

>>400
一般論だが、
想定外の変なデータにあわせてプログラムを書き換えるというのは
たいていあとでほころびが出たりしますよな。

ん？　printf("\n") ; 　がだめってことか？

何で悪いのか判らん・・・

別にいいと思うよ。

かつては、printfをどこかで使ってるなら出力は全部printfにしたほうが、
さらにもう一つputs関数がリンクされてしまうよりも
実行ファイルが小さくなるという効能があったのではないかと思う。

>>1
死ね

そもそもputsとfputsの挙動が違うのがな
今日の言語設計者は気持ち悪くて、そんなことできないと思う。

しょうがない。

もとはと言えば64KB程度のメモリで動いていたマシンのOSと、OSの上で動くプログラムを書くとき、
メモリを節約するために共通コードを関数としてライブラリ化したような代物だから。

ところで、sizeof(char)=sizeof(short)=sizeof(int)=2っていう設定のトンデモコンパイラがあるらしい。
一応、C言語の規格上これは間違っていない。（型のサイズは決められてないからね。）

kwsk

sizeof(char)=2は規格上まずいだろ

>>415
>>206

もちろん、Cでもsizeof(char)は1だと明確に定められてるから。よろしく。

>>415
「だから sizeof(char) は省略すべきではない」という主張？...でもなさそうだな。
このスレタイは「必ず1でも」って条件付きだから関係ないよね。

無次元の1と1バイトって同一視して話していいんだっけ。

数学で毎回全ての問題の全ての数字に （注意：これは10進数）
みたいな但し書きをかかれるようなものだろ。

415はsizeof(char)が2になるトンデモコンパイラをはやく晒してくれ

論理1バイトが物理2バイトだったらどうか。
自分でも書いててよくわからんが。

>>424
charが、1バイトが、16ビットの可能性はあるかもしれない

それでも1バイトは1バイトだ

>>419
それどこに書いてる？
ISOかJISの規格票のどちらかでいいから教えて

>>426
ISO/IEC 9899とか。
ついでにググったらすぐ出てきた


6.5.3.4 The sizeof operator の抜粋な
2. The sizeof operator yields the size (in bytes) of its operand....
3 When applied to an operand that has type char, unsigned char, or signed char,
(or a qualified version thereof) the result is 1.

なるほど
さんくす

>>415
> ところで、sizeof(char)=sizeof(short)=sizeof(int)=2っていう設定のトンデモコンパイラがあるらしい。
> 一応、C言語の規格上これは間違っていない。（型のサイズは決められてないからね。）

それどこが出してる？
製品名と会社のweb siteのどちらかでいいから教えて

>>429
ひょっとしたら、sizeof(char*)=sizeof(short*)=sizeof(int*)と完治害してんじゃね？

未だにsizeof(char)を書いてる人っているの？

javaのcharは2バイトって聞いたぜ。
…どうでもいいか。

Cプログラマの為に、ポイントをまとめたドキュメントを販売しています。
プロのプログラマでもあまりにレベルが低い人が多すぎます。
そんな人に限って、自分のレベルの低さを自覚していない、、、

本人は構わないかもしれませんが、その下についた新人プログラマは
たまったものではありません。（私が経験しました。）

今になって分かりました。
彼らもまた、理解できていなかったのです。

プログラミング言語の一番の習得の近道はきちんと理解している人にアドバイスをもらうこと。です。
（何といったって、参考にしようとする市販の本さえ、　きちんと説明してくれていないのですから、
　その証拠にC言語の学習で悩む人がどんなに多いことか）

私のC言語に取り組んだ7年間をすべてぶつけたつもりでテキストを作りました。

私の会社の後輩からは、どんなテキストよりもわかりやすかった！や、
今まで教えてくれていた先輩や、テキストたちが、ちゃんと理解できていないことがわかりました。
と、嬉しいコメントをたくさんもらいました。

そしてなにより、彼らの社内での評価がとても高いということが、私の誇りです。

宣伝と言ってしまえば、そうなってしまうかもしれませんが、ひとりでも多くのプログラマを救いたい。

プログラムの世界そのものの実力を底あげに貢献し、
無意味なバグに、残業したり、悩んだりして欲しくないのです。

興味がある方はどうか、下のサイトをみてみてください。
http://mori.eco.to/

>コンピュータの専門学校に入学、在学中に情報系の国家試験である、基本情報処理技術者、ソフトウエア開発を取得。
専卒かよ。

>>433
ブラクラ注意

専門学校ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

>>431
templateで間接的になら

sizeof (TCHAR)で間接的になら

>>435
おいおい、ブラクラではなかったぞ。

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

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

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

>>439
Hello,worldは基本中の初歩であって
これをバカにする理由が思い当たらないんだが

puts("hello world");
ってやるべきってこと？

そんなことを言い出したらフォーマット文字列の中に
足がすくんじゃって何も書けなくなってしまうわけだが

正統派の基本を馬鹿にするのは新しいまがいものを売るときの基本
結局同じことの繰り返しになるわけだが

30年間でほとんど進歩してないな。

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

>>442
それが正しい。

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

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

中身をみないで擁護できるのは本人だけ。

入門書の何が問題かというと、「ポインタがわかりません」なんて人を今だに量産していること。
しかも、そこに書かれていることが、次の段階の本で否定されていたりする。

>>439
どうやって文字列が表示されるのかを勉強している身としてはとてもバカにできない内容なんだが、
どういう内容を載せるべきだと言ってるのか教えて欲しいな。

printfは、C言語の仕様の一部ではあるものの、ライブラリの一関数に過ぎない。
printfやscanfの使い方は、ライブラリのマニュアルを読めばわかることであって、
入門書で解説すべきなのは、それらの使い方ではなく、
マニュアルを読めばわかるようになるための必要な前提知識である。

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

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

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

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

CもようやくOSを意識しないでプログラムを組める時代になったのか

>>450
ないよ。

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

それを言いはじめたら、標準ライブラリの多くの文字列がらみの関数がNGになるよ。
たとえばstrcpyがバッファオーバーランしうる、とか。

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

除算も同じ意味でNGだな

プログラム言語だけでプログラムが動くわけじゃないからな

>>454
除算は「検知」はできるでしょ？

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

printfの引数不正も検知できますよ。
除算よりは面倒ですが。

どうやって?

printfの呼び出し元で実引数の型情報を渡すようにinstrumentする。

なるほど。

大変だな。

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

>>460
そうだよ。
だから、Cを使うということはそのあたりの危険性と利便性をトレードオフする
考え方をもたないと駄目です。
やたら安全性をどうこう言っててもprintf使うだけでもう台無しです。

もう、かまってチャンは卒業しなよ

やっぱり>>453だよな。

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

だからバカはC言語使わないでください。おねがいします

バカなのでC言語しか使えません。
他の言語は難しすぎて。

Java だって + と - 間違えたら間違った計算結果が出てくるわけで・・・

間違えることのでき、なおかつ、それを機械的に検出できない箇所の数が、道具によって変る

っていう話しなんだよ。

たんによくあるセキュリティ的な話でそ。
Java で間違ったものを toString() しても機械が気付くわけでもなし。

>>468
セキュリティに限らず、いかにバグの入り込む余地を減らすか、ってこと。
余地が少なければ、バグの有無を確認するための工数が減るわけよ。

まあ、コンパイル時にチェックできるところはやるのは当然として、
実行時のチェックは性能とのトレードオフもあるから、Ｃは今ぐらい
で丁度いいと思う。

いろいろチェックしたらJavaと同じことをやることになって、Javaよりも遅くなったりしてね。

Cは機械寄りだから技術者以外には使えないのは当然だと思う。

>>469
まだわかってないな。

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

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

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

>>473
printfに限った話ではないし。

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

>>474
だからそれが printf とどう関係するんだよ、という話。
「限った話ではない」ではなく、全く関係のない独立した話ですよ。

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

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

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

yosoでやれ

>>475
仮にprintfが他よりバグ発生契機が多いとは言えないとして、
それで一体お前は何を主張したいんだ？

printfフェチ？

不当にCを貶めようとしてるヤツに怒ってるんじゃないの？

そんな奴いたか？

>>475
引数の順序などを取り違える
ことと、
書式化指定文字列での型指定を間違える
ことを分けて考えようぜ。

>>474
どうでもいいけど、

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

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

話を発散させるためなら内容なんてなんでもいいんだぜ？

>>479

>>467
>>469
>>474

>>481
たぶん>>467だと思う。

>>484
具体的に>>474のどこが間違いで、何が機械的に検出できないんだ？

高さを表わすint型の値と重さを表わすint型の値は、
型は同じだけれども、値の意味が違う。

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

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

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

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

>>486
そのプログラムの「意味」というのには、
　ソースが英語で書かれてる
というのが大前提としてあるよね。

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

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

height = weightを機械的に検出しなきゃいけないってどんだけｗ
なんのための変数名だよ

例がわかりやすいように、わざと豪快に間違ったコード片を書いた。

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

その手の間違いでNASAの火星探査が失敗したってニュースがあったような

>>488
問題は人間じゃなくて、機械がそれを英語かどうかを判断できないってこと

>>488
例えば、heightをheiと省略したらその「意味」は通じなくなるし、
他にもhaightとミスタイプしたら通じなくなる。

>>491
そりゃデバッグが足りなかっただけで、
それを言語仕様のせいにするのはちゃんちゃらおかしいだろｗ

そこでアプリケーションハンガリアンですよ。
http://local.joelonsoftware.com/mediawiki/index.php/%E9%96%93%E9%81%95%E3%81%A3%E3%81%9F%E3%82%B3%E3%83%BC%E3%83%89%E3%81%AF%E9%96%93%E9%81%95%E3%81%A3%E3%81%A6%E8%A6%8B%E3%81%88%E3%82%8B%E3%82%88%E3%81%86%E3%81%AB%E3%81%99%E3%82%8B

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

>>494
そういう考え方だと大きなプログラムのデバッグは大変だな。

機械的ってのはコンパイラが検出という意味ではないのか。

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

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

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

heightとweightの話をしてるのに気づかない人がいた

>>496
>474に出てくる変数はすべてint型ですが？
少なくとも、今の話題にtypedefは関係ないよね。
それはまた別の話。

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

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

>>500
>BMI指数なんかは、体重/身長^2 で計算するんだがこれは論理エラーなのか？
BMI指数の次元が 重さ/長さ^2 であるってだけのことだなぁ。

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

http://www.boost.org/libs/mpl/doc/tutorial/dimensional-analysis.html
C++なら次元解析なんかメタプログラミングで独自の型システム構築すればいいだけなのにね！

>>501
例えば、PV=nRT で V=1, nR=1 なら簡略化して P=T と書けるよね。
つまり、pressure = temperature、圧力 = 気温 となるわけだ。
これは正しいんだよな？

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

仮にheight = weightが正しい（意図してそうする）のであれば、
型でいうところのキャストみたいに、明示すればいいということだと思う。

前提を隠されて「圧力 = 気温」と言われたら、間違ってるとしか言えない。
間違いと言われたくないなら前提を隠さないでくれ。

>>504, 505

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

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

>>500
> 少なくとも、今の話題にtypedefは関係ないよね。

いや関係ある。

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

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

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

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

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

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

>>503
> 例えば、PV=nRT で V=1, nR=1 なら簡略化して P=T と書けるよね。

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

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

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

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

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


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

>>507
型が同じか違うかで、この問題の解答が全く変わってくる。
「基本的には同一の問題」というのはダウトだろう。
実際、>>507の１，２，３で間違い検出の可能性が全く違っているし。

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

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

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

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

省略すべきでないのは型の使い分け・型変換の明示だろう。*1なんかいらない。
charとかstrlenとかをハードコーディングしちゃうのではね。

素で間違えてた。眼鏡買ってくる。

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

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

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

関数をハードコーディング？

>>509
変数の取り間違い、という同一の問題です。
段階0として、人間が目を皿にして探す、ってのを入れてもいいよ。

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

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

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

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

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

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

>>510
>　つまり、１は常に省略される可能性があるし、それは常に正しくあるべき。

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

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

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

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

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

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

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

おう、515は名前欄かきわすれた。

>プログラムを読んだ人間に意図がわかるようにするために省略すべきではないのよ。
それは常識が共有できている時しか成り立たない。
変なコードが書いてあったら書いた奴に意図を聞きたくなる。

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

問題はいらない派がわかってて省略しているのかどうか

>>514
LINT の類でお勧めは何だ？

splint

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

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

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

>>515
> 機械的に検出するためには、機械的に検出できるようにコーディングするのよ。
> コンパイル時にエラーになるだけが、検出ではないよ。
>
間違いを検出するのは、コンパイル時ではないということ？？？
あなたの主張が全く見えないので、以下で確認させて欲しい。

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

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

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

>>521
> weightとかheightや他の英単語をキーワードとして扱うということ？

No.

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

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

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

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

> 問１）

3

> 問２）

4

> 問３）

7

ﾜﾗﾀ
答えられないのかよ

>>523
電波に付き合うなよ

適当に振ったネタが予想以上に好評でウケタｗ

そもそも変数名にheightやweightってつけるのは、人の目から見て意味のある名称にして
人間が間違えないようにするため。
それを機械的にって根本的におかしいだろ。

>>527
> なんで明らかにダメな方向に誤解して、その誤解の上でしか成りたたない反論をするんだろ。

趣味で独自の作法でプログラム書いてる人間には理解できない世界のお話。

>>524の未熟さが微笑ましい

世の中には、

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

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

また古い話を持ち出してきたなぁ。

そのネタ飽きた

ていうかmallocするとバグの元になるから
そもそもなるべくmallocしないで済む設計にするのがいいよ

プログラム組むとバグの元になるから...

だからデバッグ済みのライブラリを使うのですよ。

そのライブラリを呼び出すコードがバグの元になるから...

> なんで明らかにダメな方向に誤解して、その誤解の上でしか成りたたない反論をするんだろ。

ネタだから。

ネタをネタとわからない人には（

>>474 が書いたコードを見てみたい・・・

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

typedef int WEIGHT;
typedef int HEIGHT;

WEIGHT weight;
HEIGHT height;

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

PODと非PODを区別しろよ

そういうのはクラス化するという例をEffective C++で最近読んだ。

>>543
そう言う問題じゃなくて、POD であることはわかってるけど、
プログラマが別の型と定義したんだから、 警告するようにすれば
身長 × 体重 なんてしてしまうバグを減らせると言うことなんだ
ろう。

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

strong typedefを知らずにこんなスレに書き込む奴がいたのか
2008年だぞ今年…

後からのこのこ現れて間抜けな事を書き捨てていく奴って何なの？
流行ってんの？

>>547
よう、低脳

>>548
よう、ド低脳

独自の拡張にメリットを見い出せないからこそBOOST(ライブラリ)やD(派生言語)でstrong typedefを実現しているのだけれど
>>547
間抜けだという理由をどうぞ
さぞかし説得力のある解説をして下さるのだろう

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

3ヶ月も経ってからレスしてたらやっぱり間抜けだろ。

ｽﾚ違い…ってのはまあ、3月以降全部そうか。

>>551
わざわざ煽りレスして理由がそれってのは苦しいと思うが…

IDないと句読点や三点リーダの不備が余計目立つな。

日本語でokというか、独り言なら書かなくてよし

馬鹿な＞１っているもんだな

#define strlen(a)
って宣言してみる。

はいはい

いいえいいえ

どちらでもいい、という結論を受け入れられない人って結構困るよな

strncpy(str1, str2, str2 - strrchr(str2, '.'))
みたいな場合でも、
strncpy(str1, str2, sizeof(char) * (str2 - strrchr(str2, '.')))
とか書かなきゃならんか？

アホらし。

>>561
いやそこはだめだろ。memcpyではあるまいし。
wchar_t版でもなんでもそこでsizeofをかける必要はないぞ。

>>560
2chはいっぱい居るねー、そういう固い人

sizeof(char)をかけるのではなく,
sizeof(char)で割らなきゃいけないところか？
普段Cでマルチバイトとか使ってないんでよくわからん。

str2 - strrchr(str2, '.') の結果は「文字数」だが
strncpy の第3引数もまた「文字数」(バイト数ではない) だからな。

おっと、>>561が恥ずかしい。

http://hibari.2ch.net/test/read.cgi/news4vip/1310186887/l50

駄スレを埋め立てようぜ

ptrdiff_t最高や！

もう4年も前なのか

#define char long

main(){ printf("%d",sizeof(char));}

こらｗ

>>570
すげぇ
これにコンパイル通るのか・・・こえぇなぁ
これやっちゃったあとってもうcharは復活する手段無し？

undef 知らないの？

信頼できないソースで
#undef char
#undef short
#undef int
#undef long
とか胸熱

hage

超久々に新着に上がってきて何かと思った

>>570でこのスレの議論終了
sizeof(char) == 1とか言ってたやつ涙目

正気かよお前

>>1
コンピューターサイエンスに対する適性が薄そうな雰囲気が漂っている

sizeof(char)と書いてあればテンプレート化の際に
sizeof(T)に置換し易い

シンタックスでセマンティクスを表せるなら
それを使った方が人にも機械にも認識しやすいコードになる

charが常に1バイトなことを理解できてなかった奴が
無理やりあとからこじつけてるようにしか見えないな

1バイト単位で処理したいときがどうしても出るから、
charが1バイトじゃなくなったら、どうすんの？ってかんじだなｗ
(char *)にキャストしてクリクリとポインタ進める動きが大事だろ。

>>581
明白でも書くべきという主旨が理解出来なかったか
文盲は悲しいな

>>6で終わってたｗ

sizeof(TCHAR)で

ワードアドレッシングマシンとかは考慮してない訳ね

ほしゅ

おねがいTCHAR

xmalloc

charが1でない環境でコンパイルされる可能性のあるときだけ気をつければよい

>>1の理論によると、sizeof(long)も4と書いてはいけないことになる。
ありえない。

そりゃぁ、いかんだろ。sizeof(long)は4だと決まっているわけではないのだから。

自分しかコンパイルしなくて
しかもそのコンパイルする環境でlongが4ならそれでいいだろ
いちいちsizeof関数が実行されないぶん高速化されるわけだし

酷い釣りだ

>>593
sizeof 演算子使ってるところのアセンブラ見てみ。
あ、答え書いちゃった。

可読性だな。なんのサイズかパッと見で分かるし。

何のサイズかはどうでもいいんだよ
必要なサイズが確保されていればそれでいい

何？
C言語ってアセンブラまで見なきゃいけないの？

いけないのです。
実用的にCを使うならアセンブラは必修です。

全てのコンパイラが同じコード吐くとでも思ってるのか

違うコードを吐くからこそ自分で目視確認しなければならない。

めんどくさ

アセンブラできる俺かっけー！したいだけにしか見えない

ANSI/ISO/JISでは、sizeof( char )は1、と定義されているけど
俺は標準規格がいつ変更になってもいいように
sizeof( char ) は書くようにしている。

cに実用的な使い方なんてあったの?

wchar_tがあるからcharのサイズが変わることは無いしかえる必要性も無い
逆に変えちゃうと1バイトを表すプリミティブ型がほかに無くなってしまう。
（新しい規格にはbyte_tとかあったっけ？）

むしろサイズが変わったときのことを考えるなら
charをそのまま使わずtypedefして使えって思うけどｗ

> 逆に変えちゃうと1バイトを表すプリミティブ型がほかに無くなってしまう。

そうそうれ。おれはそれが理由で安心して省略してる。

へーダンゴちゃんは物知りだねえ。

C#だとsizeof(char)は2だな

大丈夫だよ
C#のコードをそのままCに持ってきてもたいがい
コンパイルすら通る見込みはないから

>>606
int iSize = strlen( pName );
char* pBuf = (char*)malloc( iSize+1 );
strcpy( pBuf, pName );
で、もし sizeof( char ) が1じゃなくなったら
メモリを壊すだろ

> で、もし sizeof( char ) が1じゃなくなったら


これはありえない仮定を持ち出すという詭弁だな

なぜcharのサイズを変える必要があるのか
wchar_tを用意したからcharのサイズは今のままでいい
という発想が欠落した無能人間乙としか

大体にstrlen + malloc + strcpyじゃなくてstrdup使えば1行ですむだろ
そんな無駄なコードを得意げに書くから実力がつかないんだよ

てかいくらバカでもstrncpy使うわ

>>,,・´∀｀・,,）っ-○○○
必死だな

自覚の無いバカを黙らせるにはこれくらい言ってやらないとダメ

何がダメかって書いておくわ

１．ドヤ顔で言う割りにmallocがNULLを返したときの処理を考慮してない
（strdupはメモリ確保失敗時点でコピー操作を止めてくれる）

２．strcpyはいちど走査するまでソース文字列の終端がわからない。
なので、1バイトコピーするごとに終端文字判定が必要になる。
（あるいは、また内部でstrlenですか？）

strncpyというよりはmemcpyが一番無駄がないのかな。
コピー終端がわかっているので、終端までの間は大きなワードサイズでの
コピー操作を行うことができる
（x86ならmovntdqで16バイトずつコピーするのが最速ですよ）





で、そもそもchar配列のサイズのことを考慮するのであれば
　　　sizeof (char)
ではなく、
　　　sizeof hoge_str[0]
じゃないとダメだろ？
単体のcharのサイズとchar配列の1要素のパディングサイズが将来にわたって
同じである保障がどこにある？

結論：お前らのクソ宗教は不完全

>>,,・´∀｀・,,）っ-○○○

メモリーの破壊例として
やっつけで書いたと思われるサンプルコードにそこまで噛み付くとは
マジで必死だな
m9(^Д^)ﾌﾟｷﾞｬｰ

俺はお前と同類と思われたくないからsizeof(char)を省略しないことにする

↑お前は同一人物か同レベルのアホだと自分で証明してるわけだが。

sizeof (char)を別に書こうが書くまいがどっちでもいい
そんなことで無駄な時間を費やすなというだけで

書かなきゃいけない理由の説明が不適格だと指摘してるだけだよ


> で、もし sizeof( char ) が1じゃなくなったら

このDQNな仮定の致命的な欠陥の理由をもう一つだけ指摘しよう
charのサイズが変わってしまうと、ASCIIやUTF-8など8ビット単位のエンコードの
テキストを読み書きしてるプログラムがほぼ全滅してしまうわな。

これはsizeof(char)を入れれば解決という話ではない
sizeof(char) == 2になるとfgetcで2文字分入ってきてしまう。
もともとASCII文字列の1文字を1データとしてマッピングできる型としてchar型が
あるわけでそれ以上でもそれ以下でもない。

charのサイズは変わるかもしれないものではなく「変えてはいけない」のが
C/C++の仕様であって、おそらく地球上のどこにも存在しない
標準規格を守らないコンパイラの挙動を考慮しろなんてヴァカな話はない。

そもそも >>1 * sizeof (char) * sizeof (char) * sizeof (char) * sizeof (char)
sizeof (char) * sizeof (char) * sizeof (char) * sizeof (char) * sizeof (char) *
sizeof (char) * sizeof (char) * sizeof (char) * sizeof (char) * sizeof (char) *
sizeof (char) * sizeof (char) * sizeof (char) * sizeof (char) * sizeof (char) *
sizeof (char) * sizeof (char) * sizeof (char) * sizeof (char) * sizeof (char) *
sizeof (char) * sizeof (char) * sizeof (char)をはじめとする sizeof (char)を
書く派の言い分が総じておかしいのは「省略する」という考え方そのものよ。
本質的に必要のない式を付加してるだけにすぎないのに。

タイプ量が増えるしコードが長くなって幅をとったり行が長くなるだけで
何一つメリットがない。
むしろわざわざ * sizeof(char) をつけてる人のコードの品質こそ逆に俺は
信用しないことにしている。
仕様を理解せずに書いてる可能性が高いってことだからな。

WindowsでUnicode APIベースのプログラム書いててもASCIIデータは扱うし
Unicode移植時にcharの操作を機械的にすべてwchar_tに置換すればいい
って発想もたいがい危い。

とりあえず規格で決まってるcharのサイズが変更される確率は限りなく0 *
sizeof (char) * sizeof (char) * sizeof (char) * sizeof (char) * sizeof (char) *
sizeof (char) * sizeof (char) * sizeof (char) * sizeof (char) * sizeof (char) *
sizeof (char) * sizeof (char) * sizeof (char) * sizeof (char) * sizeof (char) *
sizeof (char) * sizeof (char) * sizeof (char) * sizeof (char) * sizeof (char) *
sizeof (char) * sizeof (char) * sizeof (char) に等しいことは確定的に明らか。

プリプロセッサで
KYARA_SAIZUとしていつでもきりかえられるようにしようそうしよう

そんなしょっちゅうstrlenやらなきゃいけないコード書くならヒープ領域自体に
サイズを格納して管理しようぜ。

typedef char* OreoreString;
#define OreoreStringSize(buf) (*(uint32_t*)(buf-4))
#define OreoreStringRewriteSize(buf, newSize) (*(uint32_t*)(buf-4) = newSize)

OreoreString OreoreStringAlloc(size_t n) {
　　char* buf = malloc(n + 4);
　　if (!buf) return NULL;
　　*((uint32_t*)buf) = n;
　　return buf + 4;
}
void OreoreStringFree(OreoreString buf) {
　　free(buf - 4);
}
OreoreString OreoreStringDuplicate(OreoreString src) {
　　int size = OreoreStringSize(src);
　　char* cpy = malloc(size + 4);
　　if (cpy) memcpy(cpy, src-4, size);
　　return cpy;
}

こんなコードをだいがくいちねんせいくらいに書いたことがあったが
なにげにMacのCoreFoundationの文字列がこれに近いデータ構造に
なってるんだよな。
NULL終端つけておけば普通のC文字列関数も使えるし。

自作PC板の荒らしは出ていけ

向上心の無いバカはプログラマーやめちゃえばいいよ

>>621
sizeof (uint32_t)が4より大きくなったらどうするんだ！！１！

BSTR型だな

>>624
名前通りのサイズにならないデータ型ってある意味面白いなｗｗｗｗ
typedefの意味なすｗｗｗｗ
stdint.hの定義がおかしいトンデモ処理系で正常に動くことなんてプログラマが
保障する必要ないよね。

たしかにBSTRも確かにPASCAL文字列＋C文字列のハイブリッド的な実装だ。
個人的に文字列処理でCは使いたくない。C++の煩雑さもたいがいだけど。

団子今日はへるみさんdisらないの?

俺氏、ここの書き込み見てsizeof(char)を
つけることを決意
省略派が痛すぎる

628 * sizeof(char) * sizeof(char) * sizeof(char) * sizeof(char) * sizeof(char)
が「省略」とかあほなことを言ってますよ

もしsizeof(char)をかけなければいけないと主張してる奴の
トンデモ加減が理解できないならプログラマの才能ないよ

仕様の意味を深く理解せずにプログラム書いてる奴のコードの品質なんて
総じて低い。

>>628
痛いのは省略派じゃないぞ。例えば>629-630のことなら
そもそも省略なんて言っちゃうのがどうかしているんだぞ派とでも言うべきだw

switch (n) {
case(1):　〜
case(2):　〜
case(3):　〜
}
return(0);
とかわざわざ括弧をつける奴とか

for (i = 0; i < I_MAX; i++) {
　　for (j = 0; j < J_MAX; j++) {
　　　　　for (k = 0; k < K_MAX; k++) {
　　　　　　　　/* 何かしらの処理 */
　　　　　　　　if (cond) {
　　　　　　　　　　break_flag = 1;
break;
　　　　　　　　}
　 　　　}
　　　　　if (flag) break;
　　}
　　if (flag) break;
}

↑みたいな、gotoを使ったほうがよっぽどきれいに書けるコードを平気で書く奴とか
（そもそもK&Rでも多重ループを抜けるときにgotoを使うのはむしろ推奨されている）

もっと強烈な奴だと
#define then
#define begin {
#define end }
みたいなマクロを定義して「PASCAL風だ！」とドヤ顔する奴とか
このスレの1とその同意者みたいな、意味も無く式に sizeof (char) を掛ける奴とか
みんな、頭弱いんですよ。

確かに痛いな

お前ら知ってる？

for (int i = 0; i < array.size(); i++)

は

for (int i = 0 * sizeof(char); i * sizeof(char) < array.size() * sizeof (char); i += 1 * sizeof (char))

の省略表現なんだぜ。


整数型をとる関数の返り値でreturn 1; とかやってるのも
実は return 1 * sizeof (char); を省略したものなのだ。
省略が嫌いな人はちゃんと書くように心がけよう。



極論だけど、「省略」という概念を勝手に作り出すというのはこういうことなんだよ。

ダンゴさん荒ぶってるなｗ
あなたそんなキャラでしたっけ？ｗ

sizeof(char)を使うべきと主張してる例として出てくるコードが
strdup()の車輪の再発明しかないという現実に絶望したのだ

別にsizeof(char)いいと思うけどなぁ
ほんの少しだけ柔軟
別にめんどいなら1書くしなー
というかこういう話は規約レベルであって個人なら適当でええんでないの

そういうヤカラは
if (isfoo(a) == TRUE)
と書いて満足げだったりするからタチ悪い。

>>637
本来必要の無い冗長な式ととわかった上で「別にいい」というのなら
何も反論はない。好みの問題だからな。
書くべき理由も無いし書いたらダメという理由もない。

書かないことを「省略」という概念で捉えるバカは救いようが無い。
sizeof (char)を掛けるのが害悪なのではなく
言語の基本的な仕様すら正しく理解せずにコードを書く人間が
バグの根源なのだ。

strlen()は引数のアドレスから'\0'のアドレスまでの差分を返す関数だから
>>1のような例の場合には仮にcharが2バイトになろうが4バイトになろうが無意味だな

いや、書くとしたらmalloc(strlen(s)+sizeof(char))か

だからさ何度も言ってることだけど
charが2バイト以上になったらテキストファイルをメモリマッピングして
読み書きしてるプログラムがほぼ全滅するじゃん。

絶対あってはいけないことを仮定し、それに対するなんの解決にもならない
オレオレ解決策を提示するのは野暮だね。

名前欄のところにAA使うヤツってイタいのしか居ないのか？

uy
,,・´∀｀・,,）っ-○○○

それとも、技術力が低いところと粘着質なところをみると同一人物か？

>>643
uyと顔文字だったら技術力は桁違いだぞ。それが読み取れないとしたら、余程読解力が足らないんじゃないか?

ぷろぐらまには観察力も必要
好き・嫌いだけで思考停止する奴は向いてない

uyってただの基地外じゃなかったっけ

まあコテはだいたいキチガイだからキチガイ認定しておけば九分九厘正しい

>>643←これが技術力低いやつの典型だな

>>648
本当に粘着性だな
それとも成り済ましか？

>>647
コテはただの基地ではない。自意識過剰な基地。

>>637