C++相談室 part153

**デフォルトの名無しさん** · 2020/10/10(土) 23:18:20.00

https://mevius.5ch.net/test/read.cgi/tech/1589424805/
※前スレ
C++相談室 part152
https://mevius.5ch.net/test/read.cgi/tech/1594528940/

テンプレおしまい

**デフォルトの名無しさん** · 2020/10/23(金) 20:21:43.75

>>377
同一人物なんだが君は何に見えたのかな？？

**デフォルトの名無しさん** · 2020/10/23(金) 20:22:37.35

で、君はK&R Cは使えるのか？

◆QZaw55cn4c · 2020/10/23(金) 20:23:29.32

>>379
K&R1 か K&R2 かを指定してください

**デフォルトの名無しさん** · 2020/10/23(金) 20:32:42.02

もちろん1よ
2なんて馬鹿言うわけねえだろ
何が言いたいの？　おまえさんは

**デフォルトの名無しさん** · 2020/10/24(土) 00:28:14.62

>>341
>nonbuffered しろってか
別に
非同期要素同士のハンドシェークがうまく行っているかは
callerとcallerの呼び出し順序に崩れが無いことをメッセージの中身とともに確認できればほぼほぼ十分なので
printf()を呼んでから出力されるまでの時間はあんま拘る意味は無い

**はちみつ餃子** ◆8X2XSCHEME · 2020/10/24(土) 02:46:57.76

非同期な処理を観察するってのは非同期な処理が「失敗しているかもしれない」のを見つけ出さなきゃいけないってことだよね。
複数のスレッドが競合したりする場合もあるってことだよね。
printf は歳入可能でもないし、問題があるときは printf の処理も信用できないと思うんだけど。

信用できないけどバッファに溜まったまま吐き出されないということはなるべくないようにしたいって話でしょ。

**デフォルトの名無しさん** · 2020/10/24(土) 06:18:58.62

printfが再入可能でないってどゆこと？ strtokみたいに状態を持つのか？

**デフォルトの名無しさん** · 2020/10/24(土) 08:34:42.41

スレッドセーフとリエントラントってどう違うの？

**デフォルトの名無しさん** · 2020/10/24(土) 08:40:39.80

単一スレッドでも再帰なんかで再入は発生しうる
関数内でクリティカルセクションなどを使ってスレッド同期するようにしていても状態を持つ作りだと同一スレッドからの再入で異常になることはある

**デフォルトの名無しさん** · 2020/10/24(土) 08:44:50.93

Cランタイムは通常スレッドセーフだよね
だから複数スレッドでprintfを読んだりerrnoを参照してもよい
Windowsの場合、_beginthreadで作成したスレッドはCランタイム安全、CreateThreadで作成したスレッドはCランタイム安全ではないとかいう話もあった

**デフォルトの名無しさん** · 2020/10/24(土) 11:13:00.25

>>385
今、リエントラント(再入可能)という言葉は余り聞かなくなっているが、
ハードウェアに密着したプログラムを書くときに、ハードウェア割り込みの
割り込みルーチンがまだ終わってないタイミングで、同じ割り込みが生じ、
同じルーチンが再帰的に呼び出されることがあり、そのような呼び出しに
対応しているものを「リエントラント」と呼ぶことがあった。
ただし、そのようなプログラムは複雑になりがちなので、ハードウェア
割り込みが生じ、割り込みルーチンがまだ終わってないタイミングで、
同じ割り込みを発生させる原因がもう一度発生しても、割り込みルーチン自体を
呼び出さないようにする手法が使われることが多かった、というか、
その様にプログラムすることが標準とされ、そのためにプログラマブル割り込み
コントローラなるものが、その役割を果たすモードを持っており、それが通常、
有効な状態にされていた。

**デフォルトの名無しさん** · 2020/10/24(土) 11:21:13.53

>>388
一方、単一スレッドプログラムの場合、mallocの中からmallocが再帰的に呼び出される
ことはそもそもない。printfも同様。
なので、複数スレッドが動作している場合でも、各スレッドにおいては、
mallocやprintfが再帰的に呼び出されることはない。
そして、mallocを作る場合、Heapに関する重要データを読み書きする時、クリティカルセクション
のようなもので囲って、1つのスレッドだけが読み書きできるようにするような手法が使われる。
この場合、その区間を実行しているのは、最大で1スレッドのみであり、複数スレッドが
同時に実行することはない。
もちろん、malloc自体は同時に複数のスレッドが呼び出しても良いが、malloc内部で重要データ
の読み書きが行なわれるのは、必ず1スレッドのみで、それ以外のスレッドは待機させられる。

割り込みハンドラをリエントラントにする場合には、このようなクリティカルセクション的な
やり方は絶対に使えない。
まず、割り込みハンドラは、実際に実行しているのは1スレッドと言えば1スレッド。
割り込み自体が、1コアしかなかったZ80などにおいても有った概念でもあるし、それは当然であるが。

**デフォルトの名無しさん** · 2020/10/24(土) 12:26:35.65

おじいちゃん
スレタイ読もうか

**デフォルトの名無しさん** · 2020/10/24(土) 12:29:55.83

coutデバッグと言うべきってか

**デフォルトの名無しさん** · 2020/10/24(土) 12:34:34.81

>>388
多重割り込みの話と勘違いしてねーか？
同一割り込みなんて起きなくてもメインルーチンで使ってる関数を割り込みルーチンで使う可能性があるならリエントラントでないとおかしくなるよ
そもそもシングルスレッドで割り込み使ってなくてもある関数内で直接的もしくは間接的に自分自身が呼ばれる場合もリエントラントでないとおかしくなる
最近の言語だとグローバル変数とか静的変数使ってなきゃ（例外はあると思うが）リエントラントになるのであまりに気にする必要はなくなった

**デフォルトの名無しさん** · 2020/10/24(土) 14:30:45.75

ちゅうことはスレッドセーフなloggerが全部同じファイルにログを書き込むんだろ
これもうそのまんま出力に逐一印字させた方がいいんじゃね

**デフォルトの名無しさん** · 2020/10/24(土) 15:33:28.19

>>391
いや、厳密にはstd::coutデバッグというべき（ドヤ

**デフォルトの名無しさん** · 2020/10/24(土) 15:35:14.21

printf()はスレッドセーフ
複数スレッドから呼べる
規格のどこに書いてあるかは示せないが探せばあるはず
なぜなら、ファイルI/Oやからなあれ

もちろんこれは、printf(("ABC")とprintf("CDE")をそれぞれ別スレッドで呼んだ場合、
ABC、CDEという表示になるという保障にはならないが
実際にはたいていのケースで行単位で分かれてくれるからデバッグには困らない
行が頻繁に混じってしまってデバッグにならないようなら初めて行単位の排他の追加を検討する
みたいな

**デフォルトの名無しさん** · 2020/10/24(土) 15:37:01.80

ただしもちろん割り込みルーチンからprintf()を呼ぼうとするような猛者は知らん
火の粉がこっちに降りかからない限り
放っておいて差し上げなさい

**デフォルトの名無しさん** · 2020/10/24(土) 15:38:11.89

保障にはならないが～
実際にはたいていのケースで～

こういうの一番困る

**デフォルトの名無しさん** · 2020/10/24(土) 17:06:18.74

printf使ってヘンになってるならまだ許せるが自前のクソloggerが全般的にクソ動作してると排除したくなる

**デフォルトの名無しさん** · 2020/10/24(土) 17:47:23.40

非同期シグナル安全な関数のリストにprintfがない・・・
https://docs.oracle.com/cd/E19683-01/816-3976/gen-26/index.html

**デフォルトの名無しさん** · 2020/10/24(土) 17:57:44.41

自前でロックすりゃいいだろ

**デフォルトの名無しさん** · 2020/10/24(土) 18:01:02.56

printf実行中に割り込みが発生して、なおかつそのhandlerでprintf使ってると
デッドロックが発生する（？）
※printfは内部でmallocを使ってるので、>>389に書いてあるようにheapの
操作時にロックを取得しようとするため
という感じかな？

**デフォルトの名無しさん** · 2020/10/24(土) 18:10:47.63

なら自前のprintf作ればいいだろ
標準に頼りきるバカが

◆QZaw55cn4c · 2020/10/24(土) 18:13:44.58

>>402
＞自前のprintf作ればいい
こういう台詞は、その能力の欠けたものが得てして言いがちなことだよなあ‥‥と

**デフォルトの名無しさん** · 2020/10/24(土) 18:32:15.74

己の道は己で切り開くものだ
貴様らジャップどもは文句たらたらと言ってるだけで行動に移そうとはしない
猿に退化する課程の獸だな

**デフォルトの名無しさん** · 2020/10/24(土) 18:55:26.18

>>404
ワイらがジャップだとしたら
お前はいったい何なんだよ

**デフォルトの名無しさん** · 2020/10/24(土) 19:34:38.35

>>404
無関係な問題まで何でもかんでも民族や国籍に結びつけて的外れな非難をしようとするとは、怒りに囚われて論理的思考力が壊滅的にダメージを受けてるんだろう。プログラマとしては致命的だなw

**デフォルトの名無しさん** · 2020/10/24(土) 19:40:13.77

割り込みルーチンの中からprintfを読んだら危険なのは
一般にOS機能のうちクリティカルセクション（ロック）みたいな高級な機能が
ユーザーが勝手に定義した割り込みルーチンのコンテキストでは使えないからじゃわ；

OSはOSで割り込みを受けてスレッドのコンテキストを管理しているので、
それとは非同期に起きたOSのあずかり知らない割り込みで
OSの高級な機能が呼ばれたらOSの管理情報の排他が崩れる

**デフォルトの名無しさん** · 2020/10/24(土) 19:44:20.88

割り込みルーチンから呼んでも安全なprintf()を自力で実装するとしたら
メインのOSとコードベースをまったく異にする必要があるのでOSの自力実装に近くなってくる
やっぱ割り込みルーチンからはprintf()呼ばないというのが一番スマート

**384** · 2020/10/25(日) 08:15:28.48

聞くんじゃなかった
printf( → fprintf(stdout,
みたいなもんでstdoutが静的記憶域期間とか
そういう説明が聞けるのかと思いきや
なんだこりゃ・・・

**デフォルトの名無しさん** · 2020/10/25(日) 08:36:53.97

stdoutが静的記憶だとして（大概のOSではIOBで管理しておりそうなっているはずだが
printf()をユーザー定義な割り込みルーチンから呼ぶと
それの排他を安全に行える人がだれも居なくなる、

**デフォルトの名無しさん** · 2020/10/25(日) 10:46:14.61

printfデバッグでダメならputデバッグでいいじゃん

**デフォルトの名無しさん** · 2020/10/25(日) 11:40:46.63

printfごときでいちいちケチつけやがって陰気なヤロウどもだぜ

**デフォルトの名無しさん** · 2020/10/27(火) 20:01:20.88

こいつらは屁理屈言いたいだけでデバッグする気なんて少しもない。

**デフォルトの名無しさん** · 2020/10/27(火) 23:03:02.20

お金払われればやるよ

**デフォルトの名無しさん** · 2020/10/27(火) 23:23:32.01

金もらわないとデバッグしないの？
つまらない人生だね

**デフォルトの名無しさん** · 2020/10/27(火) 23:25:33.33

そんなに楽しい事ならお前がやれば？

**デフォルトの名無しさん** · 2020/10/28(水) 13:38:51.49

やらないならクソみたいなこと言ってないで黙ってりゃいいのに

**デフォルトの名無しさん** · 2020/10/28(水) 14:00:21.64

普通は成果物に対して報酬を得るよね
バグを出したら潰すのは当たり前

お金払わなきゃデバッグしないとか言ってる人は客先常駐のような労働時間に対して賃金を得る労務提供型なんだろうか
労働者から脱却しないとソフトウェア開発の本当の楽しさを知ることはできない

**デフォルトの名無しさん** · 2020/10/28(水) 14:20:56.34

1レスの中で矛盾していくスタイル嫌いじゃない

成果に対して報酬があるならお金のためにバグ潰す

時間給なら貰えるお金は変わらないから「バグ潰すのは当たり前」と洗脳したり脅したりしないとバグは潰されない

**デフォルトの名無しさん** · 2020/10/28(水) 14:50:59.10

いや、いるんだよ
他人が書いたコードを有料で引き継ぐ人
414がそうとは見えないけどね

**デフォルトの名無しさん** · 2020/10/28(水) 21:57:28.94

つーか普通に仕事してたらちょいちょい
前任者が逃げた、とか潰れた、とか逮捕された、とかで
クソみたいなゴミクソウンコのコードをわたされて
これ保守してねー、みたいなクソみたいな仕事
おしつけられることなんてまれによくあることだろ
そんでなぜかそいつのクソゴミコードのバグを
まるでおれが出したかのように責められる、までがセット

**デフォルトの名無しさん** · 2020/10/28(水) 22:56:44.64

ここってサラリーマンが多いのね

**デフォルトの名無しさん** · 2020/10/28(水) 23:22:28.00

そんなん公然と拒否するか
0から作り直すかの二択だろ

**デフォルトの名無しさん** · 2020/10/29(木) 05:18:26.87

>>421
そういう状況はママあるけど
> お金払われればやるよ
って言う状況とは違うだろ

**デフォルトの名無しさん** · 2020/10/29(木) 08:31:38.61

>>421
担当を引き受けたのなら、過去の潜在バグであってもお前の責務だろ

**デフォルトの名無しさん** · 2020/10/29(木) 15:25:24.71

>>423
こういう人間はソフトウェアなんかやらんでコンビニバイトでもやってた方が向いてるよ。

**デフォルトの名無しさん** · 2020/10/30(金) 00:03:30.35

C++でもPythonの内包表記みたいにVectorの要素舐めていって
全ての要素に特定の処理をしたものを別のVectorに代入することってできますか？

**デフォルトの名無しさん** · 2020/10/30(金) 00:17:54.24

まずPython処理系を書きます

**デフォルトの名無しさん** · 2020/10/30(金) 00:26:39.96

内包表記に近いことは無理じゃない？
initialize listでもしかして？って思ったけどうまくできそうにない

**デフォルトの名無しさん** · 2020/10/30(金) 08:18:43.66

つtransform & lambda

**デフォルトの名無しさん** · 2020/10/30(金) 09:52:48.93

std::transform(s.begin(), s.end(), t.begin(), [](int e) -> int { return e * 2 });

きっとforのほうが読みやすくて速いと思う

**デフォルトの名無しさん** · 2020/10/30(金) 10:04:53.11

あとはvalarrayとかな

**デフォルトの名無しさん** · 2020/10/30(金) 10:06:43.70

表現上はあたかもラムダ式使った華麗なことやってるように見えるけど
マジでそう見えてるだけで、コンパイルするとfor文とそんなに変わらなくなるんじゃね

むしろどっかの時点でただのfor文に置き代わったりしてるんじゃないの

**デフォルトの名無しさん** · 2020/10/30(金) 10:22:13.62

インタープリターよりは速いよ

**デフォルトの名無しさん** · 2020/10/30(金) 11:34:39.85

https://cpprefjp.github.io/reference/tuple/apply.html

**デフォルトの名無しさん** · 2020/10/30(金) 11:37:53.83

https://www.fluentcpp.com/2020/02/07/transform-adaptor-equivalent-in-cpp/

**デフォルトの名無しさん** · 2020/10/30(金) 11:41:09.18

>>433
ループ分解されて要素分コード増えてる可能性もあるな

**デフォルトの名無しさん** · 2020/10/30(金) 13:24:53.40

forよりも関数的に書いた方が順序は気にせんでいいってメッセージを込めることはできるわけだが、
まあそういう風にかける場合って大抵forで書いても可読性下がらんほど簡易な内容のことが多い。

**デフォルトの名無しさん** · 2020/10/31(土) 00:26:11.33

ﾋｴｯ…、、OpenMPし放題…！

**デフォルトの名無しさん** · 2020/11/01(日) 15:21:18.11

競プロで使いたいのですが
if i = 0 then return 0
elif i > 0 then return i - 1
を出来るだけ早く求めるには何かいい方法ありますかね？
ビット演算とかでなんとかなりませんかね？

**デフォルトの名無しさん** · 2020/11/01(日) 15:26:15.37

>>440
それの速度が競プロで問題になることなんてないだろう。
そんなこと気にするよりアルゴリズムの計算量のオーダーを小さくするとか枝刈りをしっかりするとか有意義な方に頭を使った方がいい。

**デフォルトの名無しさん** · 2020/11/01(日) 15:26:18.66

unsignedですか？

**デフォルトの名無しさん** · 2020/11/01(日) 15:36:25.10

simdの比較使えば結果がビットマスクで取得できるのでそれを使うのが定石
両方計算してビット演算で選択
c++関係ない

**デフォルトの名無しさん** · 2020/11/01(日) 15:38:18.92

>>440
数値のビット数が解っているなら高速化できる

**デフォルトの名無しさん** · 2020/11/01(日) 15:49:40.49

>>440
ていうか比較は一回でいいだろコレ
なんで2回も余計に比較してんだ？
return i>1?i-1:0;

**デフォルトの名無しさん** · 2020/11/01(日) 15:50:59.41

>>440
ていうか比較は一回でいいだろコレ
なんで2回も余計に比較してんだ？
ちょっと間違えた
return i>0?i-1:0;

**デフォルトの名無しさん** · 2020/11/01(日) 16:00:31.30

>>440
elifのあとはなにを返すんだや？
モロに中途半端やないかいワレ

**デフォルトの名無しさん** · 2020/11/01(日) 17:02:44.45

つか>>440はelseが何かわからんが、
iがi≧0でやってくるのならデクリメントの飽和演算に見える件について：

**デフォルトの名無しさん** · 2020/11/01(日) 17:10:40.93

SIMD使うと飽和演算は楽勝かもしれんが、4個とか同時に並列に計算するんでなければ
かえって遅いんじゃ…

**デフォルトの名無しさん** · 2020/11/01(日) 19:21:41.23

>>440
アセンブラだったら、
　sub eax,1
　jnb lab1
　xor eax,eax
lab1:
　ret
でおしまい。最大で4クロック。
jmp命令は1つだけ。同じことをCで書くなら、
if (--i < 0) {
　i = 0;
}
return i;
とか。

**デフォルトの名無しさん** · 2020/11/01(日) 21:20:20.31

クロック数は蛇足でしょ

**デフォルトの名無しさん** · 2020/11/01(日) 23:07:30.49

減算が必ず実行されるのはもったいない

... and eax,eax
... jz f＠
... dec eax
＠＠:
... ret

**デフォルトの名無しさん** · 2020/11/01(日) 23:12:12.57

test ってあったかな...

**デフォルトの名無しさん** · 2020/11/01(日) 23:32:16.35

and eax,eaxも同じようなものなのでは…
どっちも多分パイプライン1段消費

ていうか投機的実行から戻す際のペナルティーは
常にデクリメントする>450の方が小さい可能性が微ﾚ存
知らんけど

**デフォルトの名無しさん** · 2020/11/02(月) 00:26:45.06

そっかー
投機的実行はまったく念頭にありませんでした
i が 0 である確率が小さいと考えるのかしら

**デフォルトの名無しさん** · 2020/11/02(月) 01:48:22.41

sub eax,1
adc eax,0
でなんとかなんないの？

**デフォルトの名無しさん** · 2020/11/02(月) 14:18:33.78

>>450
一瞬でも < 0 になったらまずい環境なら
if(--i < 0) はダメ

**デフォルトの名無しさん** · 2020/11/02(月) 15:41:23.80

>>452
減算を行う場合の方が頻度が高いと予想されるので、>>450の方がその場合に
命令数が少なくなるので平均速度は速い。

**デフォルトの名無しさん** · 2020/11/02(月) 15:44:36.12

>>456
そのコードは凄い。

**デフォルトの名無しさん** · 2020/11/02(月) 16:02:50.72

>>456
キャリーちゃんか

**デフォルトの名無しさん** · 2020/11/04(水) 00:22:15.96

Macで環境構築どうすればいいですか
適当に記事あさればいいですか

**デフォルトの名無しさん** · 2020/11/04(水) 00:32:44.91

yes

**デフォルトの名無しさん** · 2020/11/04(水) 08:22:43.71

>>461
新し目のC++使うならhomebrewでg++-9でも入れるのがベターかも。
たとえばstd::filesystemとかcatalinaのXCode(clang++)でも対応したんだが、
バイナリを古いmacに持ってったら予想通り動かんかった。

**デフォルトの名無しさん** · 2020/11/04(水) 20:11:40.32

自クラスの終了時のコールバックメソッドで…delete this;すると…うまく消えるんだけど…。
コールバックメソッドは…boolを返す…delete this;した後も…メソッドは動き続けて…るんだよ…。
std::coutも反応してる…メインスレッドとかで…処理されているからですか？何故かが…解らない…。

**デフォルトの名無しさん** · 2020/11/04(水) 20:26:01.44

464です…。いろいろ調べたら…できるみたいですが…なんでできるのかは…解りません…。

**蟻人間** ◆T6xkBnTXz7B0 · 2020/11/04(水) 20:30:16.22

thisインスタンスに影響しない関数のコードは多分、C言語の関数みたいに生成される。
関数のコードは不変な実体だと思う。

**デフォルトの名無しさん** · 2020/11/04(水) 20:50:15.92

難しく考えすぎ
extern "C" void the_call_back(struct obj_ptr* This)
{
free(This);
}
こうなってるだけだよ
*Thisを殺しても関数から戻るためのスタック情報はどうもせんだろ

**デフォルトの名無しさん** · 2020/11/04(水) 21:35:20.66

struct S1;

using V1 = std::variant<S1>;

struct S1
{
　　std::vector<V1> m_v;
};

これ合法？

**デフォルトの名無しさん** · 2020/11/04(水) 21:39:36.00

ダメ

**デフォルトの名無しさん** · 2020/11/04(水) 21:44:35.56

主要3コンパイラでコンパイル出来るうえ
https://python5.com/q/djlpoyyw
紹介してる人が居る。

**デフォルトの名無しさん** · 2020/11/04(水) 22:56:42.61

駄目な根拠わかりませんか？

**デフォルトの名無しさん** · 2020/11/05(木) 00:49:04.74

>>468
https://timsong-cpp.github.io/cppwp/n4659/res.on.functions#2
> In particular, the effects are undefined in the following cases:
> ...
> - if an incomplete type is used as a template argument when instantiating a template component, unless specifically allowed for that component.

**デフォルトの名無しさん** · 2020/11/05(木) 01:14:10.93

C++17以降、std::vectorは不完全型を許容していて、std::variantは
using V1 = std::variant<S1>;
の時点でインスタン化されていない。

これはどう解釈すればいいのかな？

**デフォルトの名無しさん** · 2020/11/05(木) 01:20:36.91

これが合法なら良かったんだけど、どうも無理っぽいな。

**デフォルトの名無しさん** · 2020/11/05(木) 01:46:23.37

using V1 = std::variant<S1>;
の時点では、テンプレートの明示的なインスタンス化はしていないし、使用していないので暗黙的なインスタンス化もされていない。

ってことでいいよね？

**デフォルトの名無しさん** · 2020/11/05(木) 01:54:08.91

boost::make_recursive_variantやstd::anyを知らないわけじゃないんだけど、オブジェクトが必要になるたびにnewするならC#やJavaで十分なわけで、C++のうまみ成分はこういうところにあると思うんですよね。
何とかなりませんかね？

**デフォルトの名無しさん** · 2020/11/05(木) 02:27:49.98

>>463
ありがとうございます。
Mojaveあたりです。