C++相談室 part148

■ このスレッドは過去ログ倉庫に格納されています
2020/01/31(金) 20:54:06.26ID:Nt0XFA2s
C++に関する質問やら話題やらはこちらへどうぞ。
ただし質問の前にはFAQに一通り目を通してください。
IDE (VC++など)などの使い方の質問はその開発環境のスレにお願いします。

前スレ
C++相談室 part147
https://mevius.5ch.net/test/read.cgi/tech/1576659413/
このスレもよろしくね。
【初心者歓迎】C/C++室 Ver.105【環境依存OK】
http://mevius.5ch.net/test/read.cgi/tech/1556142878/

■長いソースを貼るときはここへ。■
　http://codepad.org/
　https://ideone.com/

[C++ FAQ]
https://isocpp.org/wiki/faq/
http://www.bohyoh.com/CandCPP/FAQ/ (日本語)
2020/02/07(金) 23:24:42.60ID:jtk/IwGo
協業できない人があれこれC++について論じるのは害でしかない。
2020/02/07(金) 23:31:57.60ID:Uosz/SQM
まずプログラム言語っての読み書きする人間のためにあるって大前提忘れてるか自覚してないやつ多いな
2020/02/07(金) 23:34:58.95ID:NUR9HIfz
>>399
マイナスが混ざっているならわからんでもないが、>>393で言っている優先順位の話とは関係ないように思うが？
2020/02/07(金) 23:36:27.96ID:Fqx20dQ+
>>397のようなコードを見てどう思う？
2020/02/07(金) 23:39:04.16ID:jtk/IwGo
見やすいかどうかは主観なので、他人や未来の自分が読んで誤解しないようにすることが肝でしょ。
まさか、「数値リテラルの桁区切り文字」にまでかみついたりしないよね？
https://cpprefjp.github.io/lang/cpp14/digit_separators.html
2020/02/07(金) 23:41:49.81ID:yMJLmx4v
主観で見やすい表記にする
その為にコンパイラの警告を無視したり切ったりする

何も問題無い
406い
垢版 |
2020/02/08(土) 00:06:08.38ID:Wxs8WSK9
>>374
> >>371
> 変な作法が追加されることなんて良くあるんだぞ。
> 今じゃ gcc や clang で -Wall オプションを付けたら
> a || b && c
> みたいな式にすら警告が出る。
> 優先順位を間違えやすいとこだから括弧で明示した方が良いんだと！
> 演算子の優先順位くらい把握しとるわ！

把握してても間違えやすいからだと思うね
実際にはa,b,cには比較演算子を使った式が入ることが多いだろう
そうするとけっこうな長さになったりする
で全体の構造が見えにくくなる

そりゃ書いてる真っ最中は問題ないさ
しかし後から読んだときにすぐ理解できなかったり、手を加えるときに間違えたりする
warningを出すべきかは議論の余地があると思うけど、
出すべきと考える理由はわかる
407デフォルトの名無しさん
垢版 |
2020/02/08(土) 00:38:17.76ID:RKzyJDHj
それはエディタの機能でかっこを表示したら良いのでは。
2020/02/08(土) 00:57:11.32ID:GuOhFnKw
主観は重要だろう。
重要でないなら全部アセンブラで書けや。
客観的には最も性能の出る言語だぞ。
2020/02/08(土) 01:23:28.05ID:Mdfh1mSi
&,|とか&&,||は*,+の関係と同じだから括弧つける方が冗長で分かりづらくなると思うんだが
2020/02/08(土) 01:29:21.53ID:zzucbZgG
一度書いた四則演算の数式を書き換えることはほとんどないけど、bool論理演算は頻繁に書き換えるでしょ。
2020/02/08(土) 01:30:14.91ID:zzucbZgG
素人多いね、このスレ。
412デフォルトの名無しさん
垢版 |
2020/02/08(土) 01:45:08.63ID:RKzyJDHj
>>411
プロの意見だとどうなりますか？
2020/02/08(土) 01:52:50.03ID:JKzazDKJ
数式を遅延評価するオブジェクトを作れば
演算子のオーバーロードで演算子の優先順位を変えられるも同然
2020/02/08(土) 01:53:57.02ID:JKzazDKJ
テクニックの限りを尽くしてbetter C++を実現したら良い
2020/02/08(土) 01:54:26.60ID:zzucbZgG
プロなら抽象的な質問には回答しないでしょ。時間泥棒にあう。
「もっと具体的に書いてくれ」と逆質問する義理がないならなおのこと。
416デフォルトの名無しさん
垢版 |
2020/02/08(土) 02:00:57.81ID:RKzyJDHj
自分の職業の板には一切いかないから、ここも職業プログラマはいないと思う。
ここに書き込む意味が無いと思うんだよな。
2020/02/08(土) 02:02:06.13ID:uvgcwZ2m
>>395
グロ
2020/02/08(土) 02:06:09.28ID:Mdfh1mSi
職業プログラマって？
仕事でソフト作るし、客先に納入したりもするけどプログラマではないな
419デフォルトの名無しさん
垢版 |
2020/02/08(土) 02:08:10.84ID:RKzyJDHj
たとえば、外科医が匿名の掲示板で効果的な治療法について話し合ったりしないでしょ。
治療法について話し合ってる人は患者だ。
だから、ここにもプログラマはいないはず。
2020/02/08(土) 02:28:45.19ID:zzucbZgG
プロの対義語はアマ。素人の対義語は玄人。
今時点のこのスレの回答者が素人同然の低いレベルであることは、否定できない。
例えば一週間後は違うかもしれない。もっともまともな回答者がこのスレに常駐するようになるかもしれない。
2020/02/08(土) 06:55:22.73ID:ARbKbNEu
>>374
-Wallとは別に「お節介は一切禁止」というオプション欲しいね
2020/02/08(土) 07:15:13.17ID:N5LmiSOJ
特定の警告だけ無効に出来るのが普通だよ
2020/02/08(土) 07:33:56.27ID:gtTyaGQ0
警告は全ておせっかい
2020/02/08(土) 07:53:55.28ID:+X9VZvVK
>>374はわかるけど
>>393, >>397で警告出すコンパイラとか見たこと無い
2020/02/08(土) 08:04:33.44ID:gtTyaGQ0
私も見たことは無い
でも他の演算子でも同じこと

1u << n+1

こんなのは良く使う
いちいちカッコを付けた方が分かりにくい
2020/02/08(土) 08:11:34.30ID:gtTyaGQ0
カッコを付けろって結局警告が出るから付けろってことで
見やすさとか無視した意見が多い

if ((a==(b + 1))||(a==(b + 2)))

こんな感じに書くヤツがいるんだよ実際
2020/02/08(土) 08:14:44.94ID:ARbKbNEu
警告の出方がコンパイラによって違うわけで
特定のコンパイラの警告に対応するということなら
#pragma使うのと同じだね
2020/02/08(土) 08:26:00.28ID:GuOhFnKw
>>426
それはつけた方がいいだろ。
見づらいのはスペースの使い方に問題がある。
2020/02/08(土) 08:42:00.85ID:gtTyaGQ0
えっ？
まじで言ってる？

if (a == b+1 || a == b+2)

これだと一瞬で理読める
俺が特殊？
2020/02/08(土) 09:05:35.53ID:LleYumKd
>>428
演算子の優先順位くらい勉強しておけよ
手間かけさせんな
2020/02/08(土) 09:08:26.73ID:LleYumKd
>>408
やはりアホだったかコイツw
2020/02/08(土) 09:10:24.21ID:ktYbgjbO
>>366
手抜きがどうこうと最もらしいこと言ってるけど
>>359で言ってるのは「警告に対処するのが面倒くさい」ってことだろ？
仕事で手を抜くべき場所とそうでない場所、みたいな次元の話じゃない

あと警告レベルは最大にしたりすると標準ライブラリにすら警告出るけど、標準より下げるのは良くない
そういうこと平気でやってると必ず後で本格的に面倒くさい原因不明のバグが頻発する
2020/02/08(土) 09:29:30.06ID:JKzazDKJ
256倍バグを出しても256倍早く潰したら
問題無くね？
2020/02/08(土) 09:30:03.39ID:GuOhFnKw
if( a == (b+1) || a == (b+2) )
これくらい書いてもバチ当たらんだろ。
しょうもないことでドヤってる馬鹿が開発では一番有害。
2020/02/08(土) 09:32:02.56ID:pUDxcHmc
>>433
256倍もバグ出すような奴と仕事したくない
2020/02/08(土) 09:39:01.42ID:JKzazDKJ
>>435
先方も256倍遅い奴と仕事したくないと思うてはるで
2020/02/08(土) 10:08:44.51ID:Di3wk8ih
>>433
全部潰せるならね
2020/02/08(土) 10:24:14.91ID:YOfaZC8k
じゃあ次は

bool b;
// 略
if (b == true)

の話でもする？ｗ
俺はこれが一番のキチガイ記法だと思ってる
2020/02/08(土) 10:29:50.84ID:yr4lhGWD
勢いあまってこれも否定しちゃう

BOOL b;

if (b == TRUE)
2020/02/08(土) 10:33:51.20ID:JKzazDKJ
>>439
b==-1が成立することが有るのはウィンドーズのバグ
2020/02/08(土) 10:39:25.53ID:yaVA2/v3
if (a = b+1 || a == b+2)
こう書いたとき気づきづらい
手間をかけるのはそれ自体だけでなくいろいろ見る機会になる
2020/02/08(土) 11:00:58.51ID:Di3wk8ih
>>438
if(a != true){
return true;
} else {
return false;
}
みたいなコード見たときは流石に絶句したわw
2020/02/08(土) 11:05:13.10ID:Di3wk8ih
>>441
それはまた別な話
ところで>>374は
if(a = b){
みたいなコードに対する警告も不要と言うんだろうか？
2020/02/08(土) 11:09:08.44ID:LleYumKd
>>441
学習が足りてないだけ
括弧なんて要らん
理解できるレベルまで進化しろ原始人
2020/02/08(土) 11:17:32.81ID:yr4lhGWD
>>440
で、 if (b) と書いちゃっても自分のバグじゃなくてWindowsのバグと主張する
2020/02/08(土) 11:39:54.89ID:pjdiRHlo
>>445
C/C++ では、b が「非0」、つまり「0 以外」だとすべて真(true) と考えるのが伝統。

なお、余計に混乱を招くだけかもしれないが、
数学的には、b == true とは、単なる数として完全一致であることを調べる演算子ではなく、集合的に、b ∈ {非0} であるかどうかを調べる演算子だとみなすことも出来る。
ところが、C/C++ では、== 演算子は単なる数としての一致を調べる演算子で、
かつ、TRUE は通常 1 にマクロ定義されているので、
b == true が、b が完全に 1 に一致しているかどうかを調べる演算子になっている。

なので、if (b) と書く方が正しく、if ( b == TRUE ) と書くのは間違い。
2020/02/08(土) 11:53:39.76ID:yr4lhGWD
>C/C++ では、b が「非0」、つまり「0 以外」だとすべて真(true) と考えるのが伝統。

名前が紛らわしいがBOOLは真偽二値じゃないんだからそれは関係ない。
TRUEかどうか判定する必要があるなら if (b) は明らかに間違い。
2020/02/08(土) 12:11:53.25ID:JKzazDKJ
回避して使うかどうかとは無関係にバグはバグじゃわ；
2020/02/08(土) 12:27:48.00ID:yr4lhGWD
>>439はジョークのつもりだったが、実際に勢い余った人が2人も現れるとはｗ
2020/02/08(土) 12:47:51.09ID:YOfaZC8k
>>442
なにその想像を超えたキチガイ

>>449
アンタの親切心が何人かの明日を救ったねｗ
2020/02/08(土) 12:53:53.46ID:JKzazDKJ
プログラミングはアートやからな
狂気もまた創造の源泉、
2020/02/08(土) 12:56:37.29ID:zzucbZgG
>>442,450
対話デバッグでaに応じて実行をブレークしたかった人が残したデバッグの痕跡だろうね。
ソースを他人に公開する際にはブレークポイントの情報はなくなるから、他人には意味不明だけど。
2020/02/08(土) 12:58:48.67ID:zzucbZgG
>>451
狂気じゃなくて修正の積み重ね。少しづつ修正していると大ポカに気づけない。
だからこそ親切なコンパイラの警告に従う謙虚さが大切になる。
2020/02/08(土) 13:32:28.54ID:gtTyaGQ0
>>452
そっち？

a != true
じゃなくて？
2020/02/08(土) 14:33:50.82ID:pjdiRHlo
BOOL b に対して、正しくはこう :
if ( b ) 　　　　// 良い
if ( b != 0 ) 　 // 良い
if ( b == TRUE )　// 駄目
456デフォルトの名無しさん
垢版 |
2020/02/08(土) 14:48:48.31ID:v1IBJgnW
>>383
graphviz / python
2020/02/08(土) 14:51:43.97ID:P2cF6ghb
graphvizは主要なLinuxの標準リポジトリに入ってるから助かる
458デフォルトの名無しさん
垢版 |
2020/02/08(土) 14:52:17.78ID:v1IBJgnW
>>403
浮動小数点数なら桁落ちとか気にしてんのかなーとか勘繰る
2020/02/08(土) 15:10:32.80ID:pjdiRHlo
>>403
整数の場合だと、括弧を付けてある部分に何らかのまとまった意味があるのかも知れない。

数学や物理学では、計算を減らすために式変形していくが、最終的な式は元々の意味が分からなくなってしまうことがある。

その場合には括弧で囲ったくらいで意味が分かり易くなることは少ない。

しかし、そのケースの場合は、括弧で括ると何か意味が分かり易くなると考えた間ロウ製がある。
2020/02/08(土) 15:11:02.15ID:pjdiRHlo
>>459
間ロウ製 ---> 可能性
2020/02/08(土) 15:12:02.03ID:JKzazDKJ
>>455
>if ( b == TRUE )　// 駄目
-1をTRUE扱いしたくないのであればこれが唯一正しい
2020/02/08(土) 15:45:10.44ID:yr4lhGWD
MSDNの書き間違いかもしれないが、Win32 APIの一部にも「成功時はTRUEを返す」という
仕様の関数があるんだよな。
2020/02/08(土) 15:54:04.38ID:pjdiRHlo
>>461
そもそも、-1 は TRUE 扱いすると言うのが C/C++ の伝統や文化。
-1 と TRUE を分けて扱うのは、特殊な独自仕様。

>>462
Win32 API の一部どころか、ハンドル値を返す以外のほとんど全ての関数が、
成功すれば TRUE を返す。
2020/02/08(土) 16:07:20.11ID:yr4lhGWD
おいおい、#define TRUE 1のTRUEと真(true)の区別がぐちゃぐちゃだぞ。

BOOLを返すWin32 APIの多くは「成功時はFALSE(0)以外の値を返す」という仕様になっている。
2020/02/08(土) 16:16:01.81ID:24Q9Tmjg
宗派論争だな
466デフォルトの名無しさん
垢版 |
2020/02/08(土) 16:19:44.70ID:RKzyJDHj
C++にはtrueがあるので積極的に使っていこうと思います。
2020/02/08(土) 16:36:41.39ID:pjdiRHlo
>>464
なるほど確かに Win32 の BOOL LineTo(HDC hdc, int nXEnd, int nYEnd)の 戻り値は、

If the function succeeds, the return value is nonzero.
If the function fails, the return value is zero.

のように、成功時には 1 や TRUE ではなく、「非0」を返すと書いてある。
468デフォルトの名無しさん
垢版 |
2020/02/08(土) 16:45:19.38ID:RKzyJDHj
キャッシュかキャッシュでないかで速度が変わる。
これは驚き。
2020/02/08(土) 16:50:34.75ID:LleYumKd
バカ==TRUE
2020/02/08(土) 17:21:59.80ID:+a4Pmd4C
○ if(b) if(!b)
○ if(b == FALSE) if(b != FALSE)
× if(b == TRUE) if(b != TRUE)

WinAPI使いには常識だと思ってたんだが
471デフォルトの名無しさん
垢版 |
2020/02/08(土) 17:32:20.19ID:RKzyJDHj
そういうのをみんなで共有しましょうって事で、たらこさんが2chを作ったんですよ。
2020/02/08(土) 17:40:43.90ID:yr4lhGWD
>>470
常識というか思い込み。
大半のFALSE/FALSE以外を返す関数なら上で良いが、>>462のようにTRUEを返すなら当然
TRUEと比較しなきゃ正しくない。
2020/02/08(土) 17:57:14.84ID:+a4Pmd4C
本当にそんなのあるの？
戻り値BOOLでFALSE(0)とTRUE(1)以外の値をTRUEと違う意味を表現するために意図的に返す奴があるってこと？
具体例どうぞ
2020/02/08(土) 18:25:19.22ID:JRIqyhqH
>>446
＞C/C++ では、b が「非0」、つまり「0 以外」だとすべて真(true) と考えるのが伝統。
＞if ( b == TRUE ) と書くのは間違い。

それは b の型が int だったら、そのとおりだけれども、>>438 をみるかぎり bool b なんでしょう？

はっ！これが老害というやつですか…
2020/02/08(土) 18:26:30.54ID:2SU4KPt5
>>473
GetMessage という基本的な API からして変則的だから……
2020/02/08(土) 18:31:14.43ID:yr4lhGWD
>>462に書いたMSDNのは単にドキュメントの間違いという可能性もあるけどね。
それとは別に、TRUE/FALSe以外に-1を返すAPIがあるのは有名だろう。
いずれにしても仕様をちゃんと確認してそれに従った扱いをすべきで、思い込みは禁物ってこと。
2020/02/08(土) 18:33:32.51ID:2SU4KPt5
>>475
GetMessage の返却値の場合は一応は TRUE の特殊な場合として -1 の状況もある
って感じだから TRUE とは別の場合を意味する第三の状況というわけではないな。
478デフォルトの名無しさん
垢版 |
2020/02/08(土) 18:34:27.09ID:RKzyJDHj
判定マクロないの。
2020/02/08(土) 18:44:49.18ID:2SU4KPt5
>>466
bool も式にまざるといつのまにか int に暗黙に型変換されちゃったりして、
やっぱりこう、あまりしっかり区別されてる気がしねぇなあと思うことも多いよ。
Windows API で使われている BOOL よりはかなりマシではあるけど。
2020/02/08(土) 18:46:46.57ID:JKzazDKJ
GetMessage()が-1を返したときはエラーなんじゃわ；
2020/02/08(土) 18:51:51.40ID:+a4Pmd4C
「WM_QUITでない」という条件における真（0以外）の中の特殊な場合（エラー）に-1ってことなのね
理屈はわからんでもないけど変なの
本当はそんなのの戻り値に「BOOL」なんていうtypedefを使うのがそもそもおかしいんだけどWinAPIだから仕方ないな
482デフォルトの名無しさん
垢版 |
2020/02/08(土) 18:52:06.88ID:RKzyJDHj
>>480
行末の；イイね。
483デフォルトの名無しさん
垢版 |
2020/02/08(土) 18:52:56.77ID:RKzyJDHj
30年前のAPIだしね。
2020/02/08(土) 18:55:20.75ID:2SU4KPt5
今なら適当なフレームワークをかぶせて使うもんだと思う。
素でメッセージの処理とか面倒くさすぎるし。
2020/02/08(土) 19:15:43.34ID:mZtPBS5R
klocworkがboolメンバ変数にportingがどうのって言ってくるのがうざい
486デフォルトの名無しさん
垢版 |
2020/02/08(土) 20:18:51.44ID:RKzyJDHj
>>485
これ何億円するの？
2020/02/08(土) 21:17:13.95ID:24Q9Tmjg
>>474
やっぱQZってとんでもなくバカだな
>>439からの流れ読めよ。BOOLについて会話されてるぜ
488デフォルトの名無しさん
垢版 |
2020/02/08(土) 21:25:19.61ID:RKzyJDHj
正の型の値と負の型の値を比較する場合、ビット幅の大きいほうの型に変換されてから比較されるんですかね？
2020/02/08(土) 21:30:32.47ID:uvgcwZ2m
汎整数拡張でググれ
490デフォルトの名無しさん
垢版 |
2020/02/08(土) 21:35:32.85ID:RKzyJDHj
>>489
ググってみたんだけど。
https://kumikomiya.com/implicit-conversion/
これを見ると変換は起きないって事なのかな？
2020/02/08(土) 23:34:23.41ID:jnRyPLnj
>>472
いや。TRUE は、必ず if 式で真と判定されるので、if (b == TRUE) としなくても
if (b) で絶対十分であることは補償されている。
むしろ、if (b == TRUE) と書くのはバグの原因になるので駄目だと言われている。
2020/02/08(土) 23:51:17.72ID:jnRyPLnj
なんというか、TRUE は、処理系ごとに変化する値ではなく、C/C++ においては、標準的には必ず 1 に #define されている。
一応分かり易さのために TRUE と書いているだけで、TRUEが2になったりする事は考える必要はない。

ただし、逆に、高速化のために 1 ではなく、非0の値を返してたまたまの値、
例えば、12 とかを返してくる関数が有りえる。
その場合、うっかり間違って if ( b == TRUE ) などと書いてしまっていたら
大変なことになるので、意味的に TRUE を返す場合には、
if ( b ) または、if ( b != 0 ) と書く方が安全だと考えられている。
2020/02/08(土) 23:53:58.53ID:jnRyPLnj
非常に古い時代に、TRUE を -1 と定義していた処理系もあったかもしれないが、
現在の C/C++ では、1 に定義するのが基本とされている。
b == TRUE という判定の仕方は、C/C++ の言語仕様から考えれば推奨されない。
2020/02/09(日) 00:57:27.97ID:OoesT11A
>>492-493
言語仕様にある true を避けているのだから、
その環境においては標準と異なる事情があるのだと察するべきじゃないの。
まあそういうことがあったらもっと別の名前を付けるべきだとは思うけど。

C/C++ はその性質上、様々なシステムの仲立ちをする機会があるし、
いろんな事情に左右される。
TRUE を 1 と定義する機会が多いのは確かだろうし、
そのときの習慣が確立されてもいるのもわかってるけど、
それが当たり前かっつーとそうとも言えんのじゃないかな。
2020/02/09(日) 01:17:16.75ID:J5M0tDgl
趣味人だとかいってるがハチミツ餃子はたまに良い事いうから困る
2020/02/09(日) 01:23:08.88ID:e66sowWB
>>494
TRUE が 1 以外に定義されていても、TRUE の値は、if 文では真と解釈されることだけは保障されているので、if (b) は問題ない。
逆に BOOL b の場合、b が非0であるが、TRUE のマクロ値とは異なった値になっている場合がないとは保障はされない。
なので、if ( b == TRUE ) だと、TRUE ではないが b に真とみなせる値が入っている場合にすり抜けてしまう恐れがあり、重大バグの原因となる。
2020/02/09(日) 01:23:18.79ID:bHnzUNQO
>>494
避けるもクソもそもそも昔なかったし
2020/02/09(日) 01:33:30.02ID:Jw8Rx7z0
あったぞ
MSが実装サボっただけで
2020/02/09(日) 01:58:53.21ID:bHnzUNQO
当時のc言語には仕様に無くない？
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。