C++相談室 part157

**デフォルトの名無しさん** · 2021/08/09(月) 10:57:31.60

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

**デフォルトの名無しさん** · 2021/09/12(日) 17:30:32.90

質問でｓが
std::this_thread名前空間内の関数は、std::thread以外の手段で作ったスレッドで
実行しても大丈夫なんでしょうか、

一部のC標準ライブラリ関数みたいにスレッド起動手段次第でリークしたりすることは無い？
https://cpplover.blogspot.com/2010/10/msvc.html

**デフォルトの名無しさん** · 2021/09/12(日) 18:10:18.89

>>341
やってみないと分からないから自己責任でご自由にどうぞ、というのが正しい回答

**デフォルトの名無しさん** · 2021/09/12(日) 18:54:34.09

>>342
std::thread以外の手段で作ったスレッドで実行したときのふるまいは
規格上非規程ということでおｋ？

**デフォルトの名無しさん** · 2021/09/12(日) 18:58:14.10

未定義動作とか処理系依存とかではなく、規定されていないということ？

**デフォルトの名無しさん** · 2021/09/12(日) 20:27:37.58

大丈夫なんじゃないすかね
mainはstd::thread以外の手段で呼び出されるんだし

**デフォルトの名無しさん** · 2021/09/12(日) 21:31:25.44

どうやってアクセスするん

**ハノン** ◆QZaw55cn4c · 2021/09/13(月) 01:29:14.15

>>326
米国民主党の宣伝＝ロイター・ブルームバーグ＝真実
米国共和党、なかんずくプレジデント・トランプの言ったこと＝フェイクニュース
という理解でいいでしょうか？イヴェルメクチンの話 https://www.youtube.com/watch?v=zhIg_KNfyhQ

>>338
どこがフルボッコか詳しく、ジョークのわからない馬鹿一人だけが騒いでいた、という印象ですが

>>340
バッハコンクール大人の部には出てみたいですね‥‥たぶんよくできる中高生のなかに一人ヨボヨボが混ざるの図になりそうですけれどもね

**デフォルトの名無しさん** · 2021/09/13(月) 02:16:31.80

>>347
コンクールとは無縁の音楽歴だろうがクソバカが
見栄張んなよ
精々弱小音楽教室の発表会止まり

**デフォルトの名無しさん** · 2021/09/13(月) 03:47:26.34

わかるよ
C++とはつまりCから2キー(2半音)上げたDという意味
ピアノならCはドでDはレ

**デフォルトの名無しさん** · 2021/09/13(月) 04:01:44.26

このスレにMIDIエンジンを自分で作ったことある人、どのくらいいる？

**デフォルトの名無しさん** · 2021/09/13(月) 06:59:19.04

ピアノじゃなくても「CはドでDはレ」だと思うが……

**デフォルトの名無しさん** · 2021/09/13(月) 07:04:19.91

MDLを入力してWAVを出力するコンパイラみたいのなら

**デフォルトの名無しさん** · 2021/09/13(月) 07:13:59.03

>>351
思うだけならあなたの自由だから好きにしなさい

**デフォルトの名無しさん** · 2021/09/13(月) 07:15:10.48

>>351
世の中には移調楽器って言うものがあって、例えば普通によく見かけるトランペットはドの音はB♭だったりする

**デフォルトの名無しさん** · 2021/09/13(月) 07:16:20.40

Windowsの標準システムドライブがCであることの経緯を知らないでPGやってる人、どのくらいいる？

**デフォルトの名無しさん** · 2021/09/13(月) 07:50:09.00

UNIXから一歩も離れたくない人とか？

**デフォルトの名無しさん** · 2021/09/13(月) 07:56:33.80

aとbドライブがフロッピー

**デフォルトの名無しさん** · 2021/09/13(月) 07:59:56.78

かつて日本ではAがHDDだった

**デフォルトの名無しさん** · 2021/09/13(月) 09:28:48.75

>>350
SWFreaderのこと？
SoftwareSynthesizerのこと？

**デフォルトの名無しさん** · 2021/09/13(月) 12:01:25.13

MIDIなんてPC-98以前のFM音源搭載機でしかいじらなかった
MIDIドライバとかならともかくMIDIエンジンが何なのかよく分からない

**ハノン** ◆QZaw55cn4c · 2021/09/13(月) 13:47:19.19

>>348
スレチガイも大概だからここで終わりましょうか
バッハコンクール　https://www.bach-concours.org/p/about.html　
趣旨「J.Sバッハの作品はクラシック音楽の真髄、導入期からポリフォニー音楽や舞曲に親しみ、ピアノの学習の中に取り入れて、そしてレパートリーにしていただきたい」、おっしゃるとおり誰でも参加可能です
https://matsuri.5ch.net/test/read.cgi/piano/1488364000/

バッハはこんな曲を作った人：https://www.youtube.com/watch?v=SBWGgwzcjYc
確かアニメ監督の押井守は若い頃バッハの合唱団にいたと聞いています

**デフォルトの名無しさん** · 2021/09/13(月) 19:44:06.04

>>361
スレ違いはお前一人なんだが・・・

**デフォルトの名無しさん** · 2021/09/15(水) 11:32:22.49

関数のポインタを引数で受け取る関数に
予め定義した関数のポインタの代わりに
lambda関数のポインタを渡したいとき
どう書けばよいですか？

**デフォルトの名無しさん** · 2021/09/15(水) 11:43:21.99

>>363
ラムダ式を呼び出すラッパー関数を作って、その関数ポインタを渡す

**デフォルトの名無しさん** · 2021/09/15(水) 11:57:59.21

std::functionでええやろか？

**デフォルトの名無しさん** · 2021/09/15(水) 12:01:19.03

>>363
こういうこと？
void func1(void (*arg)())
{
arg();
}

template <std::invocable F>
void func2(F arg)
{
arg();
}

int main()
{
func1([]{});
func2([]{});
}

**デフォルトの名無しさん** · 2021/09/15(水) 12:57:52.48

>>363
違うかも知れんけど、関数ポインタとラムダと型推論でなんかハマってこの記述に落ち着いた。
ttps://ideone.com/UNUgdi

**はちみつ餃子** ◆8X2XSCHEME · 2021/09/15(水) 13:01:11.97

>>363
クロージャ (ラムダ式によって作られた関数オブジェクト) は周囲の変数をキャプチャしないときに限り関数ポインタに変換可能。
https://timsong-cpp.github.io/cppwp/n3337/expr#prim.lambda-6
逆に言えばそうでないときは関数ポインタと互換性はない。

受け取る側が関数ポインタとして受け取るという前提を動かせないのであれば
渡すラムダ式のほうをキャプチャしない形にしてくださいということになるし、
汎用的にラムダ式を受け取れるようにしたいのだということであれば >>365-366 という方法をとることになる。

**デフォルトの名無しさん** · 2021/09/15(水) 13:05:03.04

>>366
template<typename F> void func2(F arg) { arg(); }
int main() { func2([]{}); }
↑
これだと動いています

void func1(void (*arg)()) { arg(); }
int main() { func1([]{}); }
↑
やりたいのはこっちだったんですがこれはコンパイルエラーになりますた

# invocable は C++20 からみたいですね目的にあってるかどうか判りませんが試す環境が今無いので後回しです

**デフォルトの名無しさん** · 2021/09/15(水) 13:05:45.58

>>368
ああなるほど
[&] してたのが原因かも知れません
ありがとうございます

**デフォルトの名無しさん** · 2021/09/15(水) 13:22:34.75

そういうオチか

**デフォルトの名無しさん** · 2021/09/15(水) 16:27:00.87

>>369
ヒント: コンセプト

**デフォルトの名無しさん** · 2021/09/16(木) 21:11:24.40

単項+が意味を持つ例のやつか

**デフォルトの名無しさん** · 2021/09/17(金) 16:40:49.64

仕事が生きがい？会社員の分際で？そろそろ認めなさい…あなたたちは単なる駒です
⇒赤羽の父ひろゆきが教える仕事の本質とやりたいことの違いが凄過ぎて感動が止まらない…
https://www.youtube.com/watch?v=zkwQOdq17dI
【ひろゆき/切り抜き】サラリーマンって資本主義の奴隷なの？
https://www.youtube.com/watch?v=Vi-dvyd5ksE&;t=74s
【ひろゆき】社会人語っちゃうサラリーマンについて語りました
https://www.youtube.com/watch?v=pX7NHj_rIBg
奴隷は身近にある？日本の奴隷について【ひろゆき　切り抜き】
https://www.youtube.com/watch?v=evQjCUWIHV4
【ひろゆき】会社員なんて楽しくない?⇒楽しいしラクな仕事の仕方とは※サラリーマン必見！
https://www.youtube.com/watch?v=T95-FS8sT3w&;t=390s
【ひろゆき】日本のサラリーマン制度...終わってますよwww
https://www.youtube.com/watch?v=Y-30zk2zDn0
【ひろゆき】視聴者の質問そっちのけで虚言癖アピールするひろゆき
https://www.youtube.com/watch?v=cMjk9B4J2n4
【ひろゆき/切り抜き】虚言癖ってどうやって直せばいい？
https://www.youtube.com/watch?v=5cS7vyb0tfE

**デフォルトの名無しさん** · 2021/09/18(土) 12:55:20.00

聞いてくれウィンドーズ10で
　GetLocalTime(&st1);
　const system_clock::time_point now = system_clock::now();
GetLocalTime&(st2);
とした後に、nowから
　const time_t tt = system_clock::to_time_t(tp);
　auto msec = duration_cast<milliseconds>(tp.time_since_epoch()).count() % 1000;
としてnowのms単位のUNIX Timeを算出したらば、
　st1 ≦ now
は当然成立しているが、
　now ≦ st2
は成立しないことがあり、何か
　now ≦ st2 + 1
なんじゃわ；；；

何で？！

**デフォルトの名無しさん** · 2021/09/18(土) 12:57:50.95

処理系はMSVC2019でつ、
duration_cast<T>はTで指定した時間単位未満は切り捨てとC++の規格で決まっているはず……

**デフォルトの名無しさん** · 2021/09/18(土) 13:05:15.92

ちなみにst1 ＜ st2 でありかつ (now ≦ st2) が非成立、というケースも発生するあるから
おかしいのは明らかにstd::chronoの方、

**デフォルトの名無しさん** · 2021/09/18(土) 13:23:54.83

>>377
これだけじゃどっちがおかしいかは分からんでしょ
GetLocalTimeが正しいと思うからGetLocalTimeでsystem_clock::nowを挟んだんじゃないかい

**デフォルトの名無しさん** · 2021/09/18(土) 13:43:19.07

>>378
>>377のは時刻のキャッシングみたいなことをしており呼び出した瞬間の時刻を返していないとしたらそれはGetLocalTime()の方ではない、という証左

つなみにマルチコアと最適化（いやしくもAPIの呼び出しがあるのであり得ないが）とプリエンプションの合わせ技で
実行順序が変になり得るかも、みたいな被害車妄想で
　　GetLocalTime(&st1);
　　const system_clock::time_point now = system_clock::now();
　　_ReadWriteBarrier();
　　GetLocalTime&(st2);
としてみたが>>377な現象は変わらんかったは、

**デフォルトの名無しさん** · 2021/09/18(土) 13:48:57.22

windowsのAPI同士で比較しろ
一般に違うAPIを使ってるなら一貫した結果にならなくてもおかしくない

**デフォルトの名無しさん** · 2021/09/18(土) 13:53:59.82

ちゃんと知りたいならsystem_clock::nowが内部でどのAPIを呼んでいるのか調べてみては

**デフォルトの名無しさん** · 2021/09/18(土) 13:58:54.14

変数tpはなにものですか

**デフォルトの名無しさん** · 2021/09/18(土) 14:01:55.85

というか% 1000っておかしくね？？？

**デフォルトの名無しさん** · 2021/09/19(日) 00:12:35.69

>>375
お前の頭がおかしいんだよ

**デフォルトの名無しさん** · 2021/09/19(日) 00:47:53.30

不等号≦への理解、間違ってないか

**デフォルトの名無しさん** · 2021/09/19(日) 07:30:37.33

unsignedとintを比較してるとかどうせそういうオチだろ

**デフォルトの名無しさん** · 2021/09/19(日) 13:12:19.06

中途半端なコードだけチラ見せされてもな
再現する完全なコードを出せとしか

**デフォルトの名無しさん** · 2021/09/19(日) 15:50:35.11

>>386
天才なのでそんなヘマはしますしません、

>>387
再現コード貼る、
https://ideone.com/GeMebI
※ 冒頭コメントの通り、非Windows環境では現象再現しないコードなのので注意

ウィンドーズでの実行結果：
i=---: st1, chrono, st2: ORDER CHECK
i= 0: 1632034143228, 1632034143228, 1632034143228: OK.
i= 1: 1632034143229, 1632034143229, 1632034143229: OK.
i= 2: 1632034143229, 1632034143229, 1632034143229: OK.
i= 3: 1632034143229, 1632034143230, 1632034143229: NG!
i= 4: 1632034143229, 1632034143230, 1632034143229: NG!
i= 5: 1632034143230, 1632034143230, 1632034143230: OK.
i= 6: 1632034143230, 1632034143230, 1632034143230: OK.
i= 7: 1632034143230, 1632034143231, 1632034143230: NG!
i= 8: 1632034143230, 1632034143231, 1632034143230: NG!
i= 9: 1632034143230, 1632034143231, 1632034143230: NG!

==> ORDER CHECK 「NG!」のところでchrono > st2 になっており、chronoのtime_pointがSYSTEMTIMEを1 msだけ追い越している

**デフォルトの名無しさん** · 2021/09/19(日) 15:57:36.84

こっそり訂正するが、>>377で
>st1 ＜ st2 でありかつ (now ≦ st2) が非成立、というケースも発生するあるから
と言ったがな、ありゃ誤報だｽﾏﾝｶｯﾀ、

あとちなみに、>>375を書いた時点では、現象再現はFILETIMEを使わずに、以下の方法で、
SYSTEMTIMEと　( (time_point - epochタイム) を tm構造体に変換したもの、の
それぞれからから直接シリアル日時を出して比較すた、
　　year * (12 * 31 * 24 * 60 * 60 * 1000)
　+ month * (31 * 24 * 60 * 60 * 1000) // 一ヵ月の日数を31固定で換算しているが、大小比較目的なのでこれで問題無い。
　+ day * (24 * 60 * 60 * 1000)
　+ hour * (60 * 60 * 1000)
　+ minute * (60 * 1000)
　+ second * (1000)
+ millisecond

**デフォルトの名無しさん** · 2021/09/19(日) 16:10:18.78

まともに読んでないがバリアの使い方がおかしくて実行順序入れ替わってるとかじゃね？？

**デフォルトの名無しさん** · 2021/09/19(日) 16:33:01.30

>>390
(1) _ReadWriteBarrier()は最強のバリアーやぞ；；；
(2) GetLocalTime()がどんな副作用を持つ関数かコンパイラが知るはずは無いのだから
　　最適化でコードの入れ替えや変数のレジスタ割り当てしっぱなしということはあり得ない
(3) ていうかそれ以前に、GetLocalTime()やstd::chronoの呼び出し元がシングルスレッドなのだから
　　それで順序がおかしくなるとかCPUがおかしいか、スレッドをプリエンプトして再びディスパッチする際に
　　別のコアに実行させようとする際にOSがヘマしているかのどちらかという話に……

ちなみに漏れは正常動作しており、本人が言うのだから間違いない

**デフォルトの名無しさん** · 2021/09/19(日) 16:39:43.92

https://gist.github.com/t-mat/3763854

Windows10ならSYSTEMTIMEよりsystem_clockのほうが精度高そうですね

**はちみつ餃子** ◆8X2XSCHEME · 2021/09/19(日) 17:02:40.43

>>375
GetLocalTime の分解能は 10ms くらいっぽいぞ。
system_clock::now がもっと精度の高い API を使っていたら
そんくらいの前後はあってもおかしくないんじゃね。

**デフォルトの名無しさん** · 2021/09/19(日) 17:17:42.61

https://ideone.com/qA5yOL
system_clockの部分を生のFILETIMEで置き換えてみた
実行結果はこんな感じ
i= 0: 132765453416200000, 132765129416213861, 132765453416200000: NG!
i= 1: 132765453416210000, 132765129416218094, 132765453416210000: NG!
i= 2: 132765453416210000, 132765129416218837, 132765453416210000: NG!
i= 3: 132765453416210000, 132765129416219530, 132765453416210000: NG!

GetLocalTimeやめたら？

**デフォルトの名無しさん** · 2021/09/19(日) 17:28:49.56

時刻取得用のAPIをパフォーマンス計測用に使っちゃったんだね
WIN32では大昔からQueryPerformanceFrequencyとQueryPerformanceCounterを使うよ
https://docs.microsoft.com/en-us/windows/win32/api/profileapi/

**デフォルトの名無しさん** · 2021/09/19(日) 17:59:29.70

時刻取得でそのまま精度を上げるAPIとしては
GetSystemTimePreciseAsFileTime
https://docs.microsoft.com/ja-jp/windows/win32/api/sysinfoapi/nf-sysinfoapi-getsystemtimepreciseasfiletime
ただしWindows 8以降。それ以前だと以下を使うしかないっぽいね。
GetSystemTimeAsFileTime

std::system_time::nowの実装としては、_Xtime_get_ticksを使用している(2021年9月21日17:57JST現在)
https://github.com/microsoft/STL/blob/main/stl/inc/chrono#L663-L665

これが使用しているAPIについて聞いたStackoverflowの質問
https://stackoverflow.com/questions/54933940/what-clock-does-the-visual-studio-2017-crt-implementation-of-stdchronosystem

上記によると最初に書いたAPIである模様

**デフォルトの名無しさん** · 2021/09/19(日) 19:46:00.85

>>393
GetLocalTime()の精度が10 ms台だというのは
Windowsのデフォルトのスレッドへの最大ディスパッチ時間15.6 ms（PCによっては10 ms）の影響が混入している可能性、
>>392のリンク先のような計測方法をとった場合、計測中に他のスレッドに実行権を横取りされたりすると、どうしても
期待する時間に対して15.6 msとか（高優先のスレッドが相次いでディスパッチされた場合はあるいはもっと）実際の時間が大きくなる
一方>>375の計測方法は時間の順序にのみ注目しており、プリエンプションの影響を受けない（はずだった
この話に猜疑があるなら後で述べる

>>392
>>392の情報提供は㌧クスやし実際乗り換えようかと考えているが、それはそうとして、std::chronoのふるまいを検証しなくて委員会？

**デフォルトの名無しさん** · 2021/09/19(日) 20:05:49.20

というわけでms単位のUNIX timeを得るにあたってstd::chronoとGetFileTimeAsSystemTime()が同じ精度であり互換であることを
直接検証すた、
https://ideone.com/9Opqj9

実行結果（Windows 10）
i=---: st1, chrono, st2: ORDER CHECK
i= 0: 1632049473157, 1632049473157, 1632049473157: OK.
i= 1: 1632049473158, 1632049473158, 1632049473158: OK.
i= 2: 1632049473159, 1632049473159, 1632049473159: OK.
i= 3: 1632049473159, 1632049473159, 1632049473159: OK.
i= 4: 1632049473159, 1632049473159, 1632049473159: OK.
i= 5: 1632049473159, 1632049473159, 1632049473159: OK.
i= 6: 1632049473159, 1632049473159, 1632049473159: OK.
i= 7: 1632049473159, 1632049473159, 1632049473159: OK.
i= 8: 1632049473160, 1632049473160, 1632049473160: OK.
i= 9: 1632049473160, 1632049473160, 1632049473160: OK.
NG times=0/10

問題無くなったやたー

**デフォルトの名無しさん** · 2021/09/19(日) 20:13:38.40

>>393
GetSystemTime()は確かに根本的に精度悪かったｽﾏﾝｶｯﾀorz
この結果からすると、ウィンドーズのシステム時間のの実装は、
OSがプリエンプトした際に更新し、ディスパッチ中は値が変わらないというしくみな可能性が大きい
※ 取得時間の間隔が15.6 msの倍数にならないのは、15.6 msというのがあくまで1津のスレッドが
　　ディスパッチされてからプリエンプトされるまでの「最大」時間であって実際は高優先のやつに横取りされたり
　　自発的に待ちに入ったりで15.6 msより小さい時間で実行権をOSに返すからだと思う

**デフォルトの名無しさん** · 2021/09/19(日) 21:46:58.47

古いWIN32開発者には常識的な話で検証の必要もなく、実際に検証用のプログラムは昔から大量に作られてるからだと思う

取得時間の間隔が15.6 msの倍数にならないのは「主に16ビット Windows との下位互換性のため」
https://docs.microsoft.com/ja-jp/windows/win32/sysinfo/windows-time

**デフォルトの名無しさん** · 2021/09/19(日) 22:17:24.32

>>400
後半って「Windows時刻」の説明だよね？
GetSystemTimeで得られるのは「システム時刻」であって、また別の時刻体系だと読んだけど間違ってる？
https://docs.microsoft.com/ja-jp/windows/win32/sysinfo/system-time

WinAPIスレに持っていったほうがいいかもな

**デフォルトの名無しさん** · 2021/09/19(日) 22:38:35.16

>>401
大元はWindows3.1時代からあったGetTickCountだと思うんだけど、説明的にそこしかなかったから書いた
WinAPIスレで聞きたければどうぞ

**デフォルトの名無しさん** · 2021/09/20(月) 00:06:39.19

周期15.6 msを下位互換性のために新しいWindowsがエミュレートしているというのはありえない

1スレッドへの最大割り当て時間としての15.6 msはPCによって変わり得るデフォルト値にすぎないし、
http://hp.vector.co.jp/authors/VA007219/rtc_pic.html

だいたい設定でも変わるし、
https://atmarkit.itmedia.co.jp/ait/articles/1410/30/news150_2.html
（スレッドのクォンタムタイム）

取得間隔が15.6 msにならない理由は>>399で説明いしたし

**デフォルトの名無しさん** · 2021/09/20(月) 00:10:20.87

で、GetTickCount()の分解能かきちり1 msであることはビジーループ的に値をとってみたらﾜｶﾙ
分解能に関して後方互換性も糞もなく昔からそいうﾌﾞﾂのはず
多分やけど、ハードウェアのカウンタを読んでるだけやからなあれ

**デフォルトの名無しさん** · 2021/09/20(月) 00:25:55.12

と思って、
　　const int N = 10;
　　std::vector<DWORD> vec;
　　DWORD curTmg = GetTickCount();
　　DWORD prevTmg;
　　while (vec.size() < (size_t)N) {
　　　　prevTmg = curTmg;
　　　　curTmg = GetTickCount();
　　　　if (prevTmg != curTmg) {
　　　　　　vec.push_back(curTmg);
　　　　}
　　}
　　for (int i = 0; i < N; i++) {
　　　　（差分vec[i] - vec[i-1]をprint）
　　}
というのをやったら、

**デフォルトの名無しさん** · 2021/09/20(月) 00:26:50.20

vec[0]=1391507593
vec[1]=1391507609 (diff=16)
vec[2]=1391507625 (diff=16)
vec[3]=1391507640 (diff=15)
vec[4]=1391507656 (diff=16)
vec[5]=1391507671 (diff=15)
vec[6]=1391507687 (diff=16)
vec[7]=1391507703 (diff=16)
vec[8]=1391507718 (diff=15)
vec[9]=1391507734 (diff=16)
やったわorz
まつがえますたすみません；；；
勉強になるなあ、

**デフォルトの名無しさん** · 2021/09/20(月) 06:12:36.98

>>402
自己レスです

GetTickCountとGetLocalTimeとGetSystemTimeの分解能調査
https://ideone.com/wKC8DA
1000回値が変わるのにかかった時間をマイクロ秒で計測した(std::chrono::high_resolution_clock::now()で計測)

PS C:\> .\ConsoleApplication8.exe
15614998
1003946
1000238
PS C:\> .\ConsoleApplication8.exe
15621414
1001066
1001218
PS C:\>

結論: GetLocalTimeは約1秒なのでこの環境(Win10＋ハード)では1ms程度の分解能がある
感想: 誤差大きい

**デフォルトの名無しさん** · 2021/09/20(月) 07:46:32.11

ここはWindowsAPIスレになったのか

**デフォルトの名無しさん** · 2021/09/20(月) 07:51:13.46

スレタイも読めない、検索できないやつがまともなプログラム書けるはずもなく・・・

**デフォルトの名無しさん** · 2021/09/20(月) 07:52:13.05

windows API使いたがるひとがいてめんどくさい
こっちはなるべく標準のc++使いたいのに

**デフォルトの名無しさん** · 2021/09/20(月) 08:19:53.25

POSIXと比べるとクソ過ぎて話にならんよな

**デフォルトの名無しさん** · 2021/09/20(月) 10:01:57.22

プラットフォーム固有の話も参考になる
今回の流れは Win32 API と std::chrono の違いが端緒だしスレ違いというほどではない

**デフォルトの名無しさん** · 2021/09/20(月) 10:48:50.60

そのクソがなんで一番利用者多いのか考えてみろ

**デフォルトの名無しさん** · 2021/09/20(月) 11:24:41.17

バカに合わせてるからだろ
言わせんなよ恥ずかしい

**ハノン** ◆QZaw55cn4c · 2021/09/20(月) 11:26:09.83

私馬鹿よねーお馬鹿さんよねー今日も win32api

**デフォルトの名無しさん** · 2021/09/20(月) 11:30:28.88

とりあえず動かないから面白くないということなのかもなということで、Linuxのclock_gettimeにも対応しといた。
BSDとmac組は知らん。
https://ideone.com/Z9CfOo

一応WIN32はあえて低解像度のを計測してるという点だけは補足しておきます。

**デフォルトの名無しさん** · 2021/09/20(月) 12:15:53.36

timeBeginPeriod
木屋さん元気かな

**デフォルトの名無しさん** · 2021/09/20(月) 12:28:29.25

元の質問見てないけどQPCでええんちゃうの

**デフォルトの名無しさん** · 2021/09/20(月) 12:45:29.78

>>417
スレッドのスケジューリングも変化するので注意です。
tickとはそもそもそういうものでしたが。
http://archive.linux.or.jp/JF/JFdocs/The-Linux-Kernel-20.html

>>418
>>395でそう言ったし、high_resolution_clockで使用されてるのもそれ

**デフォルトの名無しさん** · 2021/09/20(月) 12:51:33.23

CreateWaitableTimerEx(NULL,NULL,CREATE_WAITABLE_TIMER_HIGH_RESOLUTION,TIMER_ALL_ACCESS)

**デフォルトの名無しさん** · 2021/09/20(月) 13:22:11.61

>>420
そのタイマは同期待ち合わせに使用するタイマリソースですね
時間計測用に使うのは勿体ないのでやめましょう
また無言でAPIだけ書かれても困ります

**デフォルトの名無しさん** · 2021/09/20(月) 13:58:28.71

バカか
計測するなら精度高めないと意味ないだろ

**デフォルトの名無しさん** · 2021/09/20(月) 14:31:11.65

そもそもパフォーマンスの計測に使うなんて言ってなくない？

**デフォルトの名無しさん** · 2021/09/20(月) 16:05:39.48

>>422
この例はExついてないけど、こういう使い方をするものなんだよ。
待機可能タイマーオブジェクトの使用 - Win32 apps | Microsoft Docs
https://docs.microsoft.com/ja-jp/windows/win32/sync/using-waitable-timer-objects

>>423
>>388で求めているのは正確には時刻取得だね。つまりsystem_clockの話。
俺がしてるのは時間計測なのでsteady_clockの話。
違いは時刻の修正などにより増減するかしないかという特性の違いと、それを実現するHWタイマの分解能/性能の違い。
GetLocalTimeの分解能は文書にも記述がなく、>>393の指摘だけで事実関係が不明なまま宙に浮いてたので、>>416などでそれを計測した。
ここでは10～15.6msの出元であるGetTickCountもついでに計測した。
steady_clockとsystem_clockをどこかで同時に取得して、steady_clockの分解能のまま時刻っぽいものを得るみたいなことも短期的には現実的な精度でできなくはないけど。

**デフォルトの名無しさん** · 2021/09/25(土) 05:50:44.21

3種類ぐらいのタイマの時刻が1000回変化するのに要するトータル時間Tを測っているらしいが
この計測結果からSYSTEMTIMEの分解能がHWタイマの分解能/性能の違いに起因すると結論づけることはできない

実態は>>375な計り方でst1: SYSTEMTIME、now: nowtime_point、st2: SYSTEMTIME、の順で立て続けに時間をとると
>>388の通り
　　st1 ≦ now && now ≦ st2 + 1 ms
という結果なわけで、この「1 ms（＜15.6 ms）というのは本当にハードウェアタイマの分解能なんかい話が違うぞ？！」と詰問されて
答えに窮する>>424な未来が見える見えまくり

**デフォルトの名無しさん** · 2021/09/25(土) 05:55:32.54

実態は>>399に書いた理由のはずで、
証拠にst1の取得とnowの取得の間にSleep(1000)とか入れたら
>>388の結果はたちどころに
　st1 ≦ now && now ≦ st2 + 1秒
に早変わりする
よってGetSystemTime()で取得するSYSTEMTIMEの分解能はHWタイマの分解能/性能起因ではなく、
GetSystemTime()で取得する時刻がOSのプリエンプションタイミングでのみの更新されるというソフト要因である、
という>>399に述べた理屈が正解ということでｹﾃｰｲ

実際にやってはいないが天才なので以上のことはちょっと考えたらﾜｶﾙ

**デフォルトの名無しさん** · 2021/09/25(土) 06:02:51.16

ごめ、Sleep(1000)を入れたのではOSにプリエンプションの機会を与えてしまうからNG
正しくは
　GetSystemTime(&st1);
　15.6 ms未満のビジーループ　　<== 訂正
　now = system_clock::now();
GetSystemTime(&st2);
とすると、
　st1 ≦ now && now ≦ st2 + 15.6 ms
にnowの精度が劣化する、に訂正

OSのAPIもプリエンプションの機会にならない保証が無いのでビジーループはｶﾞﾁでビジーループで作る必要があり、
面倒なのでやらないがな！

**デフォルトの名無しさん** · 2021/09/25(土) 07:18:10.24

といいつつAPIに頼らずに10 ms規模のビジーループ（ビジーウェイト）させるのはやや技巧を要すると思ったので漏れが自らやってやった、
https://ideone.com/CjXN4X
※ 計測の実行は要Windows

結果、1 ms、8 ms、16 ms、1秒のどれに変えても>>388と同じで、
std::chrono::now()の時刻nowに対し、その直後にGetSystemTime()で得た時刻st2が
1 msだけ追い越されることはあっても決して 1 msより大きく追い越されることは無かったorz
なぜじゃ闇が深いなこれ、

もちろんGetSystemTime()ではなくGetSystemTimePreciseAsFileTime()を使う（↑のソースコードのPRECISE_AS_FILETIMEマクロ定義を有効化する
と>>398の通りドンピシャな時刻順になる点はビジーウェイトがあっても変わらない。
GetSystemTime()のふるまいが一方的に謎杉

**デフォルトの名無しさん** · 2021/09/25(土) 08:12:02.95

WinAPIスレに持っていってくれますか？
結局<chrono>に固有の問題（？）ではなくて背後のAPI関数に関することって分かったはずなんで

**デフォルトの名無しさん** · 2021/09/25(土) 08:44:57.34

とか言いつつ自分で探してきたので貼っちゃう……
GetSystemTimeの分解能が15.6msというのはXPまでの話らしい

https://www.thedelphigeek.com/2007/10/calculating-accurate.html

**デフォルトの名無しさん** · 2021/09/25(土) 09:20:27.88

>>425
HWタイマの分解能/性能の違いと言ってるのはsystem_clockとsteady_clockの違いの話でWindows APIの話はしてないよ。
一応補足しておくとepochも違う(時刻としてそのまま使えるのはsystem_clockということ)。
>>426以降は妄想が迷走してるだけに見えるかな。
>>430は新しい事実で>>393の謎も解けたしもう俺的に不思議な部分はない。

**デフォルトの名無しさん** · 2021/09/25(土) 17:45:16.21

> プリエンプションの機会

機会を与えないことができるのは昔のWindowsだろ

**デフォルトの名無しさん** · 2021/09/25(土) 18:35:43.94

今だって邪魔できるよ
消極的ではあるけど

**デフォルトの名無しさん** · 2021/09/25(土) 18:44:00.64

割り込み禁止命令が実行できたり
割り込みコントローラにコマンド出せたりする
デバドラかMODESETみたいのないと無理だよ

**デフォルトの名無しさん** · 2021/09/26(日) 12:46:15.93

std::complex<double> の変数 a, b について、OpenMP の並列リージョン内での
#pragma omp atomic
a += b;
が
error: invalid expression type for '#pragma omp atomic'
というエラーを出すんですが、std::complex はアトミック演算の対象外ですか？
それとも他の何かを見落としてる可能性がある？

**デフォルトの名無しさん** · 2021/09/26(日) 13:03:13.46

ompのAPI仕様書を読むと対象はスカラー型のみって書いてあるから対象外なんじゃないの？

**デフォルトの名無しさん** · 2021/09/26(日) 13:04:21.25

ここのx and vってとこ
https://www.openmp.org/spec-html/5.0/openmpsu95.html

**デフォルトの名無しさん** · 2021/09/26(日) 13:07:22.68

数学とか物理の用語としては複素数はスカラーですが、コンピューター用語としては違うんでしたっけ？

**デフォルトの名無しさん** · 2021/09/26(日) 13:18:19.13

確かモルダーを疲れさせる女のこと

**デフォルトの名無しさん** · 2021/09/26(日) 13:28:55.11

対象外
ぷりみ恥部とPOD以外だめ