C++相談室 part137

2018/08/27(月) 16:02:00.94

次スレを立てる時は本文の1行目に以下を追加して下さい。
!extend:on:vvvvv:1000:512

C++に関する質問やら話題やらはこちらへどうぞ。
ただし質問の前にはFAQに一通り目を通してください。
IDE (VC++など)などの使い方の質問はその開発環境のスレにお願いします。

前スレ
C++相談室 part137
https://mevius.5ch.net/test/read.cgi/tech/1531558382/

このスレもよろしくね。
【初心者歓迎】C/C++室 Ver.103【環境依存OK】
https://mevius.5ch.net/test/read.cgi/tech/1530384293/

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

[C++ FAQ]
https://isocpp.org/wiki/faq/
http://www.bohyoh.com/CandCPP/FAQ/ (日本語)

----- テンプレここまで -----

VIPQ2_EXTDAT: default:vvvvv:1000:512:----: EXT was configured

2018/09/08(土) 02:36:49.43

>>353
>これはCPUキャッシュがメインメモリに吐き出されることを保証するものですか？
ちげう
実行したコアのライトコマンドキューかリードコマンドキュー上の命令をその場で全部実行してしまうというもの
キャッシュのinvalidateやfillが起きるかどうかとは別の話（結果的に起きることもあるが常にではない
キャッシュと関係あるみたいな説明のページがあることは承知しているが苦情は漏れに言わないでﾎｽｲ

>これらの命令は Pentiumu2 あたりにはなかったと思います、でも Pen2 とか特に Celeron-BP6(abit) で普通にデュアルプロセッサできていたのはどうしてでしょうか？
古代の話は知らん
OoO（アウトオブオーダー実行）はすでにあったはずなので、ライトコマンドキューやリードコマンドキューもすでにあった
全くの推測だが、キャッシュのinvalidate操作が（invalidateを常に伴うため効率の悪い）メモリバリアと同じ効果があったとかではないかいや知らんけど

2018/09/08(土) 02:52:26.13

ちなIA（Intel Architecture）のうちでも常識的なコア数のやつは
コア間のキャッシュコヒーレンシをハードウェアで勝手に取ってくれるので、
コア間のメモリ参照の不整合はメモリバリアだけ注意したら逝ける（キャッシュの存在は透過的

2018/09/08(土) 02:58:07.14

>>353
こないだ atomic を使ってたけど、
atomic について調べたならそこらへんの話もどこかに書いてなかったか？
C++ 用語ではバリアでなくてフェンスって言ってるけど。

2018/09/08(土) 03:04:22.19

メメリバリアやフェンスの意味を知るにはcpuのメモリモデルの理解が必要

https://yohhoy.hatenablog.jp/entry/2014/12/21/171035

◆QZaw55cn4c (ﾜｯﾁｮｲ da60-Mhaf) · 2018/09/08(土) 03:04:32.58

>>354
＞実行したコアのライトコマンドキューかリードコマンドキュー上の命令をその場で全部実行してしまうというもの
＞キャッシュのinvalidateやfillが起きるかどうかとは別の話（結果的に起きることもあるが常にではない

なるほど…ちょっとだけ理解が進んだかもしれません
「はるか遠くにあるメインメモリに変更が反映されるかどうか」はプログラムの書き手にはあまり関係がなく、
「各コアから見る限りにおいて、各コアが発したライトあるいはリードの結果すべてが反映され、各コアからはみえている」と考えればいいのですね

これらのメモリの可視性について http://www.cs.tsukuba.ac.jp/~yas/cs/csys-2013/2013-10-15/ 等を熟考しています
mutex や cond にその方面での効用があるとは…、pthread のメモリ可視性に関する効果はあまり意識していませんでした

重要なヒントをくださりありがとうございます

◆QZaw55cn4c (ﾜｯﾁｮｲ da60-Mhaf) · 2018/09/08(土) 03:17:34.12

>>356
ええ、atomic に関係する話をいろいろと読んではいたのですが、正直なところ、あまりよくわからなかったことを告白します
acquire とか release とか、いまひとつイメージできなかった…
atomic の各メンバ関数の memory_order は C++デフォルト引数として sequence-consist(ency) を与えていることはわかりましたので「最強にしているから、まあいいか」くらいですましていました

>>354
＞実行したコアのライトコマンドキューかリードコマンドキュー上の命令をその場で全部実行してしまうというもの
この記述が一番しっくりきました

◆QZaw55cn4c (ﾜｯﾁｮｲ da60-Mhaf) · 2018/09/08(土) 04:20:01.69

>>352
＞書き換えレース
ええと、これを読んで reset-set flip-flop の禁止入力「R=S=1」のことを思い出してしまったんですが、それはさておき

複数のコアが同一メモリに対して「同時に書き込み」する、というのは、このフリップフロップ禁止入力と同じ意味あいですか？
つまり「どっちの書き込みが後になるか、予想がつかないから禁止」…①

それとも、「複数のコアが本当に同時に書き込んでしまった場合、結果が不定になる」…②
（昔のフロッピーディスク供給のソフトウェアプロテクトの方法としての「コロコロビット」＝読み出すたびに 0/1 が変わる）という意味なのか

いや、①も②も同じような意味なのかもしれませんが、
>>215 の「CAS 連続スピンロックや CAS 連続スピンロック中に別コアから書き込んだり読み込んだりすること」
が②の意味で危険で、ソフトウェア側で mutex や dirty-bit (>>238) を設けて本当に意図的にコントロールしなければならないのか、と、ちょっと心配になりました
最初から安全側にふっておくとは思いますが

2018/09/08(土) 08:05:39.39

考える前に学んだ方がいい

cas が使い物にならないならなぜそんな物があると思う？
というか mutex の実装にも cas は使用される。

使い方がわからないからcasは使わず mutex を使うという判断は正しいが、
例えば前の例のエラトステネスの篩で実装1ビットセットする毎に
mutex で排他していたらコアがかなり沢山あってもシングルスレッドの方が速い
(mutex api を処理する時間が大半を占めてしまう)

2018/09/08(土) 08:13:01.68

質問する前にスレッドセーフとか排他制御とかレースコンディションとか
弱いメモリモデルとかでググって時間くらいしっかり読んで

2018/09/08(土) 08:13:34.47

>時間くらい
「1時間くらい」のタイプミスでした。

2018/09/08(土) 11:49:10.23

>>360
cpuのメモリモデルの説明読んだら最初の方に書いてあると思うけど
普通ワード単位のアクセスは何もしなくてもハード的にアトミックであることが保証されてる
そこで壊れたらやってられないからな

2018/09/08(土) 13:52:50.37

>>360
> つまり「どっちの書き込みが後になるか、予想がつかないから禁止」…①
順序は予測できないと言うのは正しい

> それとも、「複数のコアが本当に同時に書き込んでしまった場合、結果が不定になる」…②
通常のプロセッサならこれはない
排他制御がなされていてどちらかの結果が最終的に反映される

ただ CAS (Compare And Swap) 命令はそう言う話じゃなくて読出動作 (Compare) と書込動作 (Swap) がアトミック（つまりその間には他のアクセスは無いように制御されてる）ってこと
ソフトでどうのこうのできる話じゃないからシステムから提供されてるAPIを素直に使いなさい

>>364
中途半端な知識で語るなよ

2018/09/08(土) 16:38:24.58

>>364
だよな
同一のCS, WE/OEをファンアウトさせるわけで
配線遅延があってもクロック同期で関係なくなるし

2018/09/08(土) 20:07:53.81

このスレは荒れる…！

マルチスレッド、マルチコア、アウトオブオーダー実行（OoO）にまつわる3つの問題は分けて考えられねばならない；
　(A) 書き換えレースの問題（>>352）
　(B) アドレスxに対する読み書きのatomic性（>>364）
　(C) メモリバリア（>>354）

(A)はマルチスレッドすればシングルCPUでも起きる問題
(B)はこれは何ビット幅までの読み書きを他コアが割り込み不可能なバスサイクルで行えるかという話。マルチコア固有
(C)はマルチコア状況化でのアウトオブオーダー（OoO）実行の影響をソフトで制御して無問題にするテクの話で、マルチコア×OoO固有の話

>>364は(B)のことを言っており、だいたい合っているんじゃ
（IAの場合、4バイト境界に整列した32ビットまでは(B)の意味でatomicに読み書きできる
　整列していないデータの読み書きは16 bitであっても(B)の意味でatomicではない
　インテルのマニュアルに書いてある
　自尊心だけは高い低学歴知恵遅れなのでいちいちソースは示さないが

2018/09/08(土) 20:29:14.34

とはいえ、読み書きをミューテックスなりロックなりでガードする、…(D)
これだけを遵守すれば>>367の問題は全部忘れて良い（>>351の後段にも書いた）
メモリモデルとかまともに勉強する必要は無い
さらに言うと、まともなコンパイラなら（中でどんな副作用やメモリバリアを行うかわからない）システムコールを跨いだ
変数のレジスタ割り当てとかしないから、(D)を守れば実際のところ（ほとんどのケースで）volatileも要らん

メモリモデルを勉強する必要があるのは、(D)の速度に不満が生じて改善する必要に迫られたとき、
例えばdouble-checked lockingテクがちゃんと動くのかとか不安になったりロックレスハッシュを作らねばならなくなったときだけ！

2018/09/08(土) 22:09:03.01

>>367
マルチプロセッサとかNUMAの事は考慮しなくても良いのけ？

2018/09/08(土) 23:30:32.50

バスサイクルと言ったりミューテックスって言ったり話のレベルがぐちゃぐちゃすぎる…

2018/09/09(日) 01:33:18.67

なんせC++は生ポが使える低水準言語ですし・・・

2018/09/09(日) 03:24:55.55

要するにあらゆる左辺値をatomicにして更にミューテックスでガードしとけば（これはキチガイ）
ハード系の知識を学ぶ必要はない（ハードソフトという名の蛸壺）という無茶苦茶な主張だな
勉強嫌いにもほどがあるだろ、何が低学歴だ

2018/09/09(日) 08:36:42.55

周辺チップからのメモリ書換をミューテックスでガード出来るのか

2018/09/09(日) 08:59:15.50

実際プログラミングする上でハードの知識はいらんだろ

2018/09/09(日) 09:25:43.25

ハードの知識無しでデバドラ書けるのけ？

2018/09/09(日) 10:19:49.00

>>374
メモリのゴーストとか普通に出てくるだろ
PCという狭い牧場から出たことのない家畜は知らんだろうけど

2018/09/09(日) 10:31:54.13

>>375
は？プログラミングが書けると言っただけでデバドラのプログラミングするなんて言ってねえよ
じゃあお前は信号処理を知らずに音声合成のプログラミング書けるのか？
>>376
だからそんなの考慮知らなくもソフトウェアは作れるんですが

2018/09/09(日) 10:37:46.17

作文したら推敲しろ、って小学校で習うはずなんだけどな

2018/09/09(日) 10:39:04.08

>>378
え？
お金も払われないのに推敲？
時間の無駄じゃん

2018/09/09(日) 11:01:35.79

>>377
ああ家畜か
人間よばわりして悪かったな

2018/09/09(日) 11:25:28.91

ハードウェア部分を隠すためのOSによるアクセスの抽象化とか、
標準ライブラリがあるわけだし、ハードウェアの知識が絶対に必要でもないでしょ。

デバイスドライバを書くプログラマが優れているとか、その反対に
高レベルな(抽象度の高い)ソフトを作る人ほど偉いってものでもない。

2018/09/09(日) 11:26:29.90

>>380
逆に家畜はお前じゃね？
ハードウェアを意識しないとプログラミング出来ないなんて可哀相

2018/09/09(日) 14:43:15.61

何これ？

2018/09/09(日) 15:02:39.54

いつものマウントごっこだろ

2018/09/09(日) 16:27:56.67

for i in {0..15}; do
mount /dev/dm-$i /mnt
done

2018/09/09(日) 17:06:11.77

捕食される側の人類最底辺同士で争ってる

2018/09/09(日) 17:19:50.37

低レベルプログラミングって言う面白そうな本が出てたなあ

2018/09/09(日) 18:06:25.87

そういえば、さいきんの低レベルいじる時ってどうするんやろね。
BIOSなくなってきてるし、作法かわってきてるのかなぁ・・・。

2018/09/09(日) 18:53:37.14

古き良きシリアルポートが普通のPCではほぼ絶滅してるからなあ
USBきらい

2018/09/09(日) 19:01:40.42

USB制御のノウハウってあんまり周知されてない感じがする。

2018/09/09(日) 19:09:08.66

アイソクロナス？

2018/09/09(日) 19:38:22.19

>>382
高級ってのを誤解しているアホがここにもいたわw

2018/09/09(日) 21:21:28.72

>>390
LINE EYEで見てるとエラー出まくったりしてるね

2018/09/10(月) 22:46:19.98

dllからexeをCreateProcessで起動するとメモリリークするとかある？
debugging tool forなんたらみたいなやつでメモリリークチェックしてるのだけど
exeから呼んだやつはリークなし
dllから呼んだやつはリークありとなっている
監視開始ポイントと終了ポイント及び呼び出しソースコードに差分がなく
その他にも差分がないんだ

2018/09/10(月) 23:03:06.10

dllから呼びだす場合
dllは呼びだした側のﾌﾟﾛｾｽと同じｱﾄﾞﾚｽ空間にﾏｯﾋﾟﾝｸﾞされ
dll側の関数を呼び出して生成されたﾋｰﾌﾟも
呼びだした側のﾌﾟﾛｾｽと同じｱﾄﾞﾚｽ空間にﾏｯﾋﾟﾝｸﾞされる

ﾌﾟﾛｾｽから呼び出した場合、
呼び出した側のﾌﾟﾛｾｽと関係ない呼び出された側のﾌﾟﾛｾｽのｱﾄﾞﾚｽ空間に
ﾋｰﾌﾟは生成されるから
呼び出した側のﾌﾟﾛｾｽを監視してもそのﾘｰｸについて検出されることはない

分かった？

2018/09/11(火) 05:56:49.25

質問と回答が違う

2018/09/11(火) 09:46:04.97

そのツールでもうちょっと情報とれないんかいって思うが、
ランタイムライブラリの指定とか見直してみたら？
というかexe起動を繰り返したら繰り返すだけリークする？
最初の一度だけならあんまり気にしなくていいんじゃない？しらんけど

2018/09/11(火) 22:07:19.41

質問通りの
ｺﾚ以上ないｴﾚｶﾞﾝﾄなﾚｽになってる

2018/09/11(火) 22:09:50.93

あかねちゃん。

2018/09/12(水) 00:18:15.71

>>394
umdhじゃないかと思うが、スタックトレースは見てみたの？
プロセスの標準入出力に名前付きパイプが指定されてるとdllの明示的なアンロードのタイミングでApplication verifierでリーク検出されたことはあった。

2018/09/12(水) 09:57:57.91

>>394
dll ってことは何かの exe の中で動いてるんだろ
そっちのコードが他スレッドで何かアロケートしてるとか

単に dll の問題で CreateProcess しなくてもリークしてるとか

2018/09/12(水) 19:18:39.87

>>397
>>395
>>400
>>401
色々とありがとう。UMDHです
色々と試してみたところ繰り返し行ってもリーク量は増えなかったので、自分が作成したロジック以外でのリークみたいでした
UMDHは増えず、タスクマネージャー上のプライベートメモリとかが増えてくのは気になったけども....

2018/09/14(金) 01:05:55.69

>>402
メモリはコミットサイズを確認。
あとはハンドルをクローズしてないとかはないよね。

2018/09/14(金) 01:26:50.31

>>402
UMDH は増えずにタスクマネージャー上のプライベートメモリが増えるということは必ずしも問題があるわけではない。
(もちろん問題がある場合もある。)
malloc や new で割り当てるメモリは、
OS からある程度のメモリを融通してもらった塊をアプリケーションのレイヤ (ランタイムライブラリ) で切り分けて提供することになる。
足りなくなったらまた OS に要求する。
しかしその要求というのも、メモリ空間を予約するだけで物理メモリはまだ割り当てないかもしれない。

「プライベートメモリ」というのは予約したメモリ空間のサイズを表すらしく、
実際のメモリ使用量を表さないので、
基本的には UMDH をあてにした方が良いと思う。

2018/09/14(金) 04:46:07.61

gflagsで対象exeのメモリ割り当てをコンパチブルモードにしてみたら

2018/09/14(金) 07:55:52.78

>>403
コミットサイズを確認すれば良いんですね
ハンドルクローズもしてますね
ありがとうございます

>>404
分かりやすくありがとうございます
差分が出ることもあり得るのですね
丁寧でとても助かりました

2018/09/14(金) 20:22:01.09

プログラム全体で使いたい変数を宣言する際は
グローバル変数として宣言するのと#defineするのって何か違います？
どっちを使えばいいんですかね？

2018/09/14(金) 20:34:55.91

#define という事は定数だと思われるのでconstexprな変数に一票。

2018/09/14(金) 20:44:10.13

グローバル変数だとコンパイルのときにエラーを出してくれる
#defineは値がヘンでもエラーを出さない

2018/09/14(金) 20:54:15.35

どっちとか言う前にもう少し言語仕様を理解してこいよ…

2018/09/14(金) 21:06:34.91

>>407
そのレベルならいったんdefineは忘れるべき。
defineはほとんどの場合ただの置換に過ぎない。

2018/09/14(金) 21:31:46.88

C++なら値変更不可な参照のみのｼﾝｸﾞﾙﾄﾝにしとけばいい
ｼﾝｸﾞﾙﾄﾝを動的にｲﾆｼｬﾗｽﾞできるようにすれば起動時に設定の変更ができたりするようにできる

めんどくさかったらdefineでいい
defineかえてｺﾝﾊﾟｲﾙしなおせばしまいだからな
そういうdefineはｶﾃｺﾞﾘｰ毎にまとめてぜんぶ一か所に書いときなさい

ｼﾝｸﾞﾙﾄﾝでも裸の外部変数はやめておいたほうがいい
それさえしなければどうでもいい

2018/09/14(金) 21:53:36.47

し、シングルトン？
この話題でまさかのsingleton笑
さすがにこれはネタだよね？

2018/09/14(金) 21:55:11.25

外部変数はｼﾝｸﾞﾙﾄﾝの変数だからな
なにもおかしくない

2018/09/14(金) 21:56:25.39

ここで言ってるsingletonって所謂GoFデザインパターンのsingletonだよね？

2018/09/14(金) 21:58:26.14

そもそも池沼のID:YK4Q2JFR0はdefineがなにかすらわかってないからな

> defineはほとんどの場合ただの置換に過ぎない。

ほとんどもへったくれもなく
defineはただの置換だからな

頭悪い

2018/09/14(金) 21:59:24.65

頭悪いやつはﾑﾘしてﾚｽしなくていい
なにもわかってないんだからな

2018/09/14(金) 22:01:10.88

>>416
結合と文字列化もあるから「ほとんど」であってるが

2018/09/14(金) 22:01:20.46

いつもの半角くん病が発症したらしいw
毎度毎度、燃料投下、お疲れ様ですm(_ _)m

2018/09/14(金) 22:02:21.10

defineか外部変数にしたいとかいう質問だからな
普通にｸﾞﾛｰﾊﾞﾙを定数値をもたせたいという質問内容なのに
このｽﾚの低学歴知恵遅れたちがどう解釈したかはしらない

2018/09/14(金) 22:02:53.11

結合も文字列かもただの置き換え

2018/09/14(金) 22:05:22.67

まず低学歴知恵遅れは日本語を読解する能力がない
ものごとも抽象的にみる能力もない
つまり認知機能に著しい欠陥がある

2018/09/14(金) 22:05:58.57

ID真っ赤にして火病起こしたか

2018/09/14(金) 22:06:56.64

静的にどう置換されるかｺﾝﾊﾟｲﾙ時に決定されてるからな
このｽﾚに池沼たちは、いつもなにをいってるか意味不明なﾜｹ

2018/09/14(金) 22:07:36.57

>>420
こういうtypoをツッコむのは本来嫌いなんだが、せっかく燃料投下してくれたお礼に一応指摘。
「ｸﾞﾛｰﾊﾞﾙを定数値をもたせたい」
毎回言うけど、C言語の前に日本語勉強したほうがええで。

2018/09/14(金) 22:09:30.41

低学歴知恵遅れが指摘できるのはこの程度
自分の著しい頭の悪さを棚にあげるからな

ｸﾞﾛｰﾊﾞﾙに定数値をもたせたい

とまともな日本語読解能力があれば
普通に読めるからな

2018/09/14(金) 22:10:14.11

ともかくとてつもなく頭悪い
しかもとてつもなく頭悪いという自覚がない

2018/09/14(金) 22:10:23.49

>>426
よしよし、今日は素直でよろしい。

2018/09/14(金) 22:11:29.39

で、ｵﾏｴは自分の頭が
とてつもなく頭悪いのは自覚してんか

ｺﾞﾐでｸｽﾞな人間であることも自覚できてんのか

2018/09/14(金) 22:12:33.95

さすがにもうワンパターンで飽きてきた。
もっと違う煽り方考えてよ。
ツンデレ的なのはどう？

2018/09/14(金) 22:14:52.54

煽り？
まず事実だからな

ﾊﾞｶは自分がﾊﾞｶである自覚がない
だからﾊﾞｶが直らない

すべてｺﾞﾐでｸｽﾞな人間性の問題
ｺﾞﾐｸｽﾞには内省というもんがない

2018/09/14(金) 22:18:12.66

最初は褒めて褒めて褒めちぎった上でミスリードを誘い、その上でボロクソに貶すとかどう？
さすがに皆そのやり方は飽き飽きしてるよ。

2018/09/14(金) 22:34:27.68

子猫がかわいくて甘噛みされたらちょっと叩いたあとで頭なでなでしてたら
大人になっても強くかむようになって困ったのを思い出した

なんだかなあ

2018/09/15(土) 00:40:17.11

ｵﾚはこんなことはしてないからな

　　　　　　　　　　　　　　　　　　　　　　　ﾀｶｲ
　　　　　　　　　　　　　　　　　　　　∧_∧　ﾀｶｰｲ
　　　　　　　　　　　　　　　　　 m⊂(´・ω・)⊃
　　　　　　　　　　　　　　　⊂c 　ﾉ__　　ノ
　　　　　　　　　　　　／⌒ヽ　 | .|　 | .|　　　　　　　　　　　　　　　　／⌒ヽ
　　　　　　　　　　　　（　＾ω＾） i　i二 .ﾉ　　　　　　　　　　　　　　_（　＾ω＾） il| 　　死ね
　　　　　　　　　　（´　　二二二ﾉ　　　　　　　　　　　　　　　　（´ ＼　　　＼|il　|il il|
　　　　　　　　　／　　　　/:　　　　　　　　　　　　　　　　　／　＼. ＼ノ＼. ＼il|　|il|
　　　　　　　　i===ﾛ==／　　　　　　　　　　　　　　　　　　i===ﾛ== ヘ. ＼.　i|!l !l＼il|
　　　　　　　ノ:::::::::::::::::ヽ　　　　　　　　　　　　　　　　　　ノ:::::::::::::::::ヽ　＼ヽη /'）/'）
　　　　　／:::::::::::へ:::::::::ヽ　　　　　　　　　　　　　　　／:::::::::::へ:::::::::ヽ　ヽ_,,..)　　/
　　　　　/::::::_/　　　＼:::::::)　　　　　　　　　　　　　　/::::::_/　　　＼:::::::)　　　）　　（ / ／
　　　／::_　'´　　　　　　|::::|　　　　　　　　　　　　／::_　'´　　　　　　|::::|　⊂（v　　　）⊃
　　レ　　　　　　　　　　しつ　　　　　　　　　　レ　　　　　　　　　　しつ｀)　＼　〆　(´￣　　　　　　　　　　　
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　／⌒Ｙ⌒ヽ
ただの被害妄想
ｵﾚは事実を書き込んでるだけだからな
まず事実が事実であることを自覚するところから

2018/09/15(土) 01:10:27.96

バイナリファイルの読み書きはfstreamとFILEどちらがオススメですか？

2018/09/15(土) 01:53:04.57

#include <iostream> is Forbidden

2018/09/15(土) 04:03:10.64

FILE

2018/09/15(土) 06:14:52.60

>>407 を虚心坦懐に読めば
「#defineじゃ定数値しか作れんのだから変数にする以外ない」
という身も蓋もない答えもありうるわな。
さすがにそんな揚げ足取りをする人はいないみたいだけど。

プログラム全体で参照する定数値をconstのグローバル変数にするか
#defineにするか、なら一般的にはconst変数の方が好まれるかな。
const変数の利点と言うより、#defineの弊害を避けるためって理由で。

その定数が整数値なら enum class も候補に入れてくれ。
static_castが面倒臭いかも知れんけど。

2018/09/15(土) 08:40:54.56

ここまでconstexpr1つもなしなのはみんな意図的？

2018/09/15(土) 09:11:50.04

>>439
つ 408

2018/09/15(土) 09:12:10.24

>>439 >>408

2018/09/15(土) 09:39:05.72

整数の定数くらいならconstexpr付けても付けてなくても大して変わらなくない？
const int n = 42; と constexpr const int n = 42; って何が違うの
どっちも定数式文脈で使えるでしょ

2018/09/15(土) 10:09:16.49

>>440
>>441
節穴だった申し訳

2018/09/15(土) 10:28:10.96

constexpってクソださい仕様だよな
勝手に推論して最適化しとけや

2018/09/15(土) 11:23:26.53

>>438
関連性のある定数群をまとめる為にはスコープがあるenum classはいいんだけど、
フラグとして使うのが難しいのがちょっと難点

enum class PNG_COLOR_MASK: uint8_t{
GRAY = 0b000,
PALETTE = 0b001,
RGB = 0b010,
ALPHA = 0b100
}
enum class PNG_COLOR_TYPE: uint8_t{
GRAYSCALE = PNG_COLOR_MASK::GRAY,//できない
RGBA = PNG_COLOR_MASK::RGB | PNG_COLOR_MASK::ALPHA//できない
}

2018/09/15(土) 14:56:24.44

フラグとして使うならoperator|と&をオーバーロードするのが良いけど面倒だね

PNG_COLOR_MASK operator|(PNG_COLOR_MASK e1, PNG_COLOR_MASK e2)
{

　using u_t = typename std::underlying_type<PNG_COLOR_MASK>::type;

　return PNG_COLOR_MASK((u_t)e1 | (u_t)e2);

}

2018/09/15(土) 15:34:42.86

ここまでやって更にstatic_castも必要となるという。

2018/09/15(土) 16:32:07.11

>>444
むしろ俺はコンパイラでやらずビルドシステムで対応すべきことだと思っているが。
なんでもコンパイラに押し込もうとする悪しき風習に思う。

2018/09/15(土) 19:18:14.78

fstreamでも結局writeするのでFILEと比較して都合のいい方を選べばいいよ。

**438** (ﾜｯﾁｮｲ 5793-mIvp) · 2018/09/15(土) 19:36:37.14

enum class はスコープを限定できる代わりに、個別の型として
ガチガチに保護されるせいで数値として使いにくい欠点はあるね。

namespace PNG_COLOR_MASK {
　enum {
　　GRAY = 0b000,
　　PALETTE = 0b001,
　　RGB = 0b010,
　　ALPHA = 0b100,
　};
}

　int grayscale = PNG_COLOR_MASK::GRAY;
　int rgba = PNG_COLOR_MASK::RGB | PNG_COLOR_MASK::ALPHA;

こんな感じにnamespaceで名前なしのenumを囲むか。
素直にconstexprを使えばいいんだけど、C++11以前でも可というニッチな提案。

2018/09/15(土) 20:20:12.42

その場合structで囲むのもありだね。二進数リテラルはC++11以前では拡張だけど。

2018/09/15(土) 21:04:37.66

>>446の案を利用（C++17以降？)
https://wandbox.org/permlink/yIJAkUN2Rm3h7Ldb

2018/09/15(土) 21:10:11.77

少し修正
https://wandbox.org/permlink/WtrS5XFoh0knc1W7