C++相談室 part148
■ このスレッドは過去ログ倉庫に格納されています
>>492-493
言語仕様にある true を避けているのだから、
その環境においては標準と異なる事情があるのだと察するべきじゃないの。
まあそういうことがあったらもっと別の名前を付けるべきだとは思うけど。
C/C++ はその性質上、様々なシステムの仲立ちをする機会があるし、
いろんな事情に左右される。
TRUE を 1 と定義する機会が多いのは確かだろうし、
そのときの習慣が確立されてもいるのもわかってるけど、
それが当たり前かっつーとそうとも言えんのじゃないかな。 趣味人だとかいってるがハチミツ餃子はたまに良い事いうから困る >>494
TRUE が 1 以外に定義されていても、TRUE の値は、if 文では真と解釈されることだけは保障されているので、if (b) は問題ない。
逆に BOOL b の場合、b が非0であるが、TRUE のマクロ値とは異なった値になっている場合がないとは保障はされない。
なので、if ( b == TRUE ) だと、TRUE ではないが b に真とみなせる値が入っている場合にすり抜けてしまう恐れがあり、重大バグの原因となる。 >>495
ハチミツじゃなくてはちみつな。
>>496
それが真偽値だというのが思い込みで、
実際には様々な可能性が有り得るってことだよ。
普通はこうだからこうみたいな話じゃなくて、
少なくとも言語仕様に無いのはわかってるんだから、
その環境でどうなってるかくらい確認したれやという話。
>>497
私は >>493 からあくまで現代の話だと読み取ったのでそのつもりで返答してるけど、
C/C++ のコードは長期的に使われやすいので現代という範囲の認識に齟齬はあるかもしれん。 WindowsAPIはC++限定じゃなくCを主軸に捉えてるだろ
クラスとか一切無いしマクロだらけだし
そもそもboolが無かったってのはそういうことやろ >>462
> MSDNの書き間違いかもしれないが、Win32 APIの一部にも「成功時はTRUEを返す」という
> 仕様の関数があるんだよな。
具体的にどれ？ >>493
TRUEが-1というと昔のBASICにそういうのあったね
だがその時代すでにCも存在していた >>496
何回ループしてるんだよ。
真(truthy)であることが要求されているなら if (b) だし、TRUEであることが要求されるなら
if (b == TRUE) だ。それを取り違えることがバグだ。 まあ失敗時はFALSE、とも書いてあるから、こう書くのが正解！
bRet32 = MakeSureDirectoryPathExists("C:\\tmp");
if (bRet == TRUE) {
// 成功すた
...
} else if (bRet == FALSE) {{
// 失敗すた
...
} else {
assert(0);
} あと>>461は、>>455の三択で選ぶならif (b == TRUE)だが
正しくは↓こう書くべき
bRet = GetMessage(...);
if (b == -1) {
// エラー1が発生すた、
....
} else if (bRet == FALSE) {
// エラー2が発生すた、
....
} else if (bRet = TRUE) {
// 成功すた、
...
} else {
assert(0);
}
つまり出題者>>455の知識と想像力の欠如が諸悪の根源 訂正orz
誤: bRet
正: bRet32
>>509訂正、
誤： {{
正： {
>>510訂正
誤： bRet = TRUE
正： bRet32 == TRUE C89にboolがないことに拒否反応を起こす頭の固い奴に迎合して作られたboolでないBOOL 先にWindowsがシステムコールとしての素朴な要請からbool型の実装型を定義して、
その後コンパイラメーカーがbool型の実装を別の方式にし出すよりは
よっぽどﾏｼやったろうが！
個人的にはBOOLは好きだがな
TRUE/FALSEを表すのに4バイトも使うところが
いかにもリッチなOSっぽく、使っていてリッチな気分になれる >>510
> } else if (bRet == FALSE) {
> // エラー2が発生すた、
> ....
エラーじゃないぞ
人の知識とか想像力とか言う前に自分の知識を見直せよw といっても成功していないのだからエラー扱いで差し支えないなのでは… >>510
GetMessageのマニュアルをちゃんと読めクソ雑魚
エラーの時は-1、WM_QUITの時はFALSE(0)を返すが、それ以外の時は「nonzeroを返す」としか言ってない
nonzeroというのはたくさんの値の集合であって、その判定をある特定の値と==で行うことはTRUEが1だろうと他の値だろうと完全な間違いだ
つまりお前のその糞プログラムは完全にバグっているし、お前がバカにしてる>>455らが言った通りの間違いをそのままやらかしてる クソ雑魚>>510はマニュアルを読まない可能性があるので、マニュアルの使用例貼っておきますね
GetMessageがFALSE(0)返したときの何がエラーだって？笑わせんなカス
TRUE以外ならassertで落としていいなんてどこに書いてある？勝手な妄想すんなゴミ
BOOL bRet;
while( (bRet = GetMessage( &msg, hWnd, 0, 0 )) != 0)
{
if (bRet == -1)
{
// handle the error and possibly exit
}
else
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
} >>519
>TRUE以外ならassertで落としていいなんてどこに書いてある？
それはこちらが聞きたい；
何を見てそう思ったのか？ >>519
変数いらねーから
for(;;)
switch(GetMessage(&msg, hWnd, 0, 0))
{
default:
TranslateMessage(&msg);
DispatchMessage(&msg);
break;
case 0:
return int(msg.wParam);
case -1:
throw std::system_error(std::error_code(int(GetLastError()), std::system_category()), "GetMessage");
} while(GetMessage( &msg, hWnd, 0, 0 ) >0)
{
TranslateMessage(&msg);
DispatchMessage(&msg);
} とｵﾓﾀがわかった
GetMessage()は WM_QUIT以外を受け取ったとき非0を返す、としか書かれていないから
bRet32 == TRUEでは正しい判定にならないのねん
使ったのがｽｹﾞｰ昔なので忘れていたが、そのときは多分>>519式に書いたから安心してﾎｽｲ しょうもない事で攻撃的になるやつなんなの
いつも吹いてしまうw >>506
BASIC というか、古の言語にはビット演算と論理演算の区別がないものが結構あった。
全てのビットが立った状態 (-1) を真ということにしておけば
ビット演算用の AND, OR, NOT がそのまま論理演算のそれとして使える。
昔はこれが気の利いた方法だったんだろう。 #define FALSE 0 ← 正しい
#define TRUE 1 ← 間違い くず! 0点!! 出入り禁止!!!
#define TRUE (!0) ← 正しい
if(b) ← 正しい
if(b != FALSE) ← 正しい
if(b == TRUE) ← 間違い くず! 0点!! 出入り禁止!!! >if(b != FALSE) ← 正しい
これこそ糞コード 意味的にboolなら
if (a)
if (!a)
で判断すべきだと思う if (a == TRUE)
if (a == TRUE == TRUE)
if (a == TRUE == TRUE == TRUE) もともと>>438と>>439を混同すんなという話なんだが、混同してる奴が次から次へと湧いて出てくるｗ >>528
#define TRUE (!0) ← 正しい
C/C++ では、!0 は、必ず1 になることが仕様化されているので、仕様に準拠している
処理系ではこれは必ず、
#define TRUE 1
と書くのと同じになるので、敢えて (!0) と書く意味は無い。 boolだろうがBOOLだろうがYESNOだろうが
意味がboolであればboolと同じ扱い >>529
糞コードだが
> if(b == TRUE) ← 間違い くず! 0点!! 出入り禁止!!!
より１億倍マシ >>528
1がイヤなら0もイヤだろう
#define FALSE (0!=0)
としないと >>537
マシとか言う以前にそもそも動作が違うんだが。
bがTRUEと一致するかどうか判断するのに他にどういう書き方をするというんだろう？ 普通はTRUEかFALSEしか入ってないんだよ
それ以外が入ってる可能性があるなら
普通TRUEがどうかの判断だけじゃダメじゃないか？ switch (b){
case FALSE:
...
case TRUE:
...
case ???
...
default
...
}
これで >>539
それは難しくいえば数学の集合論の話になる。
{0} と {非0} の二つの集合が有り、
if の条件式では、前者が偽、後者が真と評価される。
TRUEはどんな処理系であれ、必ず後者の集合の要素(元)になっていることだけは
保障されている。
なので、if ( b != 0 ) や、if (b) は正しいが、
if (b == TRUE) は絶対駄目、ということになる。 >>543
BOOLなのに
1と2を区別したい事があるんだってさ if ( b == TRUE ) は、この条件式自体の動作は問題ないが、
b が TRUE ではないが、真である何らかの値を持っていたときに破綻してしまう。
BOOL b と書いた場合、本人が書いたプログラムでは b は、必ず
TRUE か FALSE の二値に限って書くことになろうが、往々にして、
APIなどでは、「真」の意味で「非0」の値を返してくること関数が含まれて
しまっている。
だから、勘違いや混乱が起き易い。
そのため、if ( b == TRUE ) というのは、絶対にやめておいたほうが良い書き方
となる。 TRUE/FALSE以外を想定するなら
時と場合による
TRUE/FALSEしか想定しないなら
if (b) / if (!b)
と書くべき 昔VB6からWinAPI呼ぶときの注意点として本で読んだ気がする
それboolじゃないよね？とは思った >>545
じゃあ聞いてみよう。
bがTRUEと一致するかどうか判断する必要がある場合はどう書く？ >>546
排中律が成り立たないからFALSEでないことはTRUEを意味しない。
成功した場合にTRUE、失敗した場合にFALSEを返すという関数がある場合、成功したかどうかは
FALSEでないことではなくTRUEと一致するかどうかで判断しなければならない。 >>548
架空のケースについてのお答えは差し控える
つか糞コードかどうかはともかく>>509の方はMSDNの記述に準拠したコードという意味では
非の打ち所が無い（何かあってもMSDNのせいにできる >>539
> bがTRUEと一致するかどうか判断する
それ自体がまずい（ことが多い）と指摘されてることにそろそろ気づこうよ… >>552
>>514見ているのにいまだにそんなこと言っているのはなんでだろう intの取り得る値の集合に対し、TRUEの定義が-93でありかつそれ以外は偽と解釈をせよと仕様に書いてあったら
さすがに(b == TRUE)とか(b != TRUE)書くことを現実の選択肢として考慮せざるおえない
もちろんそんな仕様が糞だが、仕様なのだからしようが無い
数学の本質は自由性にある、 FALSEは定数
TRUEは範囲で観測によって収束する
適性に乏しいやつには厳しいよな 集合B={FALSE=0,TRUE=1} の場合 !FALSE=TRUE だが
B'={FALSE=0,TRUE1=1,TRUE2=2,TRUE3=3} の場合
!FALSE={TRUE1,TRUE2,TRUE3} となる
しかし TRUE={TRUE1,TRUE2,TRUE3} と定義すると
B''={FALSE=0,TRUE} となり、同型B≡B'が示されるため、B'をboolとみなすことは可能である
ただし、比較演算子は集合として同値であるのか、集合に含まれるのかを示さなければならない
b⊂B'(≡B) のとき、 b=FALSE は一意だが、b=TRUE は b=1∩b=2∩b=3 を示す 数学関係ないのに数学ネタでひっぱってるヤツがいるな
IDは違うけど同じ人？
数学関係ないから >>553
>>514の話なら>> 509だし、そうでないAPIもたくさんあるから
> それ自体がまずい（ことが多い）と指摘
されてるんだが、まじでわかってないのか？
引っ込みつかなくなってるだけだと思ってたが… 訂正
b=1∩b=2∩b=3
→b=1∪b=2∪b=3 グローバル領域にインスタンスを作って、初期化はmain()の中でしたいとします。
で、初期化に必要な情報はmain()の中で初めて分かるとします。
こういうときってそのクラスのコンストラクタとしては何もしないものを作っておいて、初期化用の関数を別途用意するというのが普通ですか？
インスタンスの宣言だけしておいてコンストラクタは後で呼ぶなんてできないですよね？ >>561
逆に不思議だわ。
「成功時に0以外の値を返す」と「成功時にTRUEを返す」は違うということがなんで理解できないのか。 >>566
どこから違うことを理解してないと思った？
思い込み激しすぎw GetGlyphOutline などで文字画像を取り出そうとすると、フォントが持ってない文字は代わりの文字を出力してくる。
（例えば、昔の毛筆フォントでは「髙（はしご高）」などはMSゴシックになる。）
これを抑制したいので、そのフォントがグリフデータを持っているかどうか、調べる方法はありますでしょうか？ >>571
違いを理解しているなら>>566の後者はまさに>>539だということも理解できそうなもんだが。 >>574
ここよりwindows apiのスレのがいいんじゃないかな >>576
もしかして（ことが多い）っていう意味もわかってないのか？ win32は変な仕様多いからAPIの仕様確認しないと罠にはまる 多い方に合わせろって話でもないだろう。
>>568の通りそれぞれの仕様に合わせて適切に扱えってこと。 GetModuleFileNameとか仕様作った奴のセンスを疑う >>580
誰も多い方に合わせろなんて言ってないのに…
単にそういうケースが多いって言うだけの話であることも説明しないとわからんのかな？w なら問題ないケースもあることを理解してるわけだ。だとすると>>552で指摘してたのはなんだろうと。 >>584
えっ？
まだ（ことが多い）ってわざわざ書いてる意味がわからんのか？
まともな奴と会話してる時ならいちいち書かないんだが、ネット掲示板なのでわけわからん奴に絡まれないようにわざわざ書いたのに想定外の低能さんなの？ >>585
つまり>>552は、まずい場合もあるしそうでない場合もあるという意味のない指摘なわけだ。
ようやく>>539に戻れたな。
>>537
マシとか言う以前にそもそも動作が違うんだが。
bがTRUEと一致するかどうか判断するのに他にどういう書き方をするというんだろう？ bがTRUEと一致する条件の話はしてなくて
boolに対するif文をどう書くかの話だろ
APIの使い方なら他スレでやって 余所でやれって、APIと言語仕様のズレの話だろ
正しい理解はどのようなものかという興味は
スレ違いじゃねえぞ APIの正しい理解ならAPIのドキュメントを見れば良いのでは？
もともとのboolの話とは全く関係ないですね >>586
> つまり>>552は、まずい場合もあるしそうでない場合もあるという意味のない指摘なわけだ。
お前には意味ないのかもな…
必死になりすぎw >>533に書いたが、boolじゃなくてBOOLの話をしているのになぜかboolと混同する人が boolの話題でbool以外を語るのはこんな感じ
内部的に固定小数点なfloatライブラリもあるぞ
内部的にvectorなmapライブラリもあるぞ BOOLも同じ
意味的なBOOLが前提
それ以外は特殊事情 ■ このスレッドは過去ログ倉庫に格納されています
