C++相談室 part157

[過去ﾛｸﾞ] C++相談室 part157 (1002ﾚｽ)
上下前次 1-新

このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索歴削→次ｽﾚ栞削→次ｽﾚ過去ﾛｸﾞﾒﾆｭｰ

353: 2021/09/13(月)07:13 ID:PttYpQoG(3/4) AAS
>>351
思うだけならあなたの自由だから好きにしなさい

354: 2021/09/13(月)07:15 ID:OJvNe7+i(1) AAS
>>351
世の中には移調楽器って言うものがあって、例えば普通によく見かけるトランペットはドの音はB♭だったりする

355: 2021/09/13(月)07:16 ID:PttYpQoG(4/4) AAS
Windowsの標準システムドライブがCであることの経緯を知らないでPGやってる人、どのくらいいる？

356: 2021/09/13(月)07:50 ID:B8QV0Pmm(2/3) AAS
UNIXから一歩も離れたくない人とか？

357: 2021/09/13(月)07:56 ID:9W3p606T(1) AAS
aとbドライブがフロッピー

358: 2021/09/13(月)07:59 ID:B8QV0Pmm(3/3) AAS
かつて日本ではAがHDDだった

359: 2021/09/13(月)09:28 ID:Kz73eSbE(1) AAS
>>350
SWFreaderのこと？
SoftwareSynthesizerのこと？

360: 2021/09/13(月)12:01 ID:DUyA86Uv(1) AAS
MIDIなんてPC-98以前のFM音源搭載機でしかいじらなかった
MIDIドライバとかならともかくMIDIエンジンが何なのかよく分からない

361(1): ハノン ◆QZaw55cn4c 2021/09/13(月)13:47 AAS
>>348
スレチガイも大概だからここで終わりましょうか
バッハコンクール　外部ﾘﾝｸ[html]:www.bach-concours.org　
趣旨「J.Sバッハの作品はクラシック音楽の真髄、導入期からポリフォニー音楽や舞曲に親しみ、ピアノの学習の中に取り入れて、そしてレパートリーにしていただきたい」、おっしゃるとおり誰でも参加可能です
2chｽﾚ:piano

バッハはこんな曲を作った人：動画ﾘﾝｸ[YouTube]
確かアニメ監督の押井守は若い頃バッハの合唱団にいたと聞いています

362: 2021/09/13(月)19:44 ID:O/wDGHc8(1) AAS
>>361
スレ違いはお前一人なんだが・・・

363(4): 2021/09/15(水)11:32 ID:0GWRKP/3(1/3) AAS
関数のポインタを引数で受け取る関数に
予め定義した関数のポインタの代わりに
lambda関数のポインタを渡したいとき
どう書けばよいですか？

364: 2021/09/15(水)11:43 ID:KsZNjWDc(1) AAS
>>363
ラムダ式を呼び出すラッパー関数を作って、その関数ポインタを渡す

365(1): 2021/09/15(水)11:57 ID:tjq2eHQi(1) AAS
std::functionでええやろか？

366(2): 2021/09/15(水)12:01 ID:+suq2kti(1/2) AAS
>>363
こういうこと？
void func1(void (*arg)())
{
arg();
}

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

367: 2021/09/15(水)12:57 ID:gM7DTPzC(1) AAS
>>363
違うかも知れんけど、関数ポインタとラムダと型推論でなんかハマってこの記述に落ち着いた。
外部ﾘﾝｸ:ideone.com

368(1): はちみつ餃子 ◆8X2XSCHEME 2021/09/15(水)13:01 ID:/JHaU2Oz(1) AAS
>>363
クロージャ (ラムダ式によって作られた関数オブジェクト) は周囲の変数をキャプチャしないときに限り関数ポインタに変換可能。
外部ﾘﾝｸ:timsong-cpp.github.io
逆に言えばそうでないときは関数ポインタと互換性はない。

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

369(1): 2021/09/15(水)13:05 ID:0GWRKP/3(2/3) AAS
>>366
template<typename F> void func2(F arg) { arg(); }
int main() { func2([]{}); }
↑
これだと動いています

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

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

370: 2021/09/15(水)13:05 ID:0GWRKP/3(3/3) AAS
>>368
ああなるほど
[&] してたのが原因かも知れません
ありがとうございます

371: 2021/09/15(水)13:22 ID:+suq2kti(2/2) AAS
そういうオチか

372: 2021/09/15(水)16:27 ID:46YA8/2z(1) AAS
>>369
ヒント: コンセプト

373: 2021/09/16(木)21:11 ID:wgmfJty/(1) AAS
単項+が意味を持つ例のやつか

374: 2021/09/17(金)16:40 ID:J/w/zJeW(1) AAS
仕事が生きがい？会社員の分際で？そろそろ認めなさい…あなたたちは単なる駒です
⇒赤羽の父ひろゆきが教える仕事の本質とやりたいことの違いが凄過ぎて感動が止まらない…
動画ﾘﾝｸ[YouTube]
【ひろゆき/切り抜き】サラリーマンって資本主義の奴隷なの？
動画ﾘﾝｸ[YouTube]
【ひろゆき】社会人語っちゃうサラリーマンについて語りました
動画ﾘﾝｸ[YouTube]
奴隷は身近にある？日本の奴隷について【ひろゆき　切り抜き】
動画ﾘﾝｸ[YouTube]
【ひろゆき】会社員なんて楽しくない?⇒楽しいしラクな仕事の仕方とは※サラリーマン必見！
省7

375(5): 2021/09/18(土)12:55 ID:fzYJNrfO(1/4) AAS
聞いてくれウィンドーズ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
は当然成立しているが、
省5

376: 2021/09/18(土)12:57 ID:fzYJNrfO(2/4) AAS
処理系はMSVC2019でつ、
duration_cast<T>はTで指定した時間単位未満は切り捨てとC++の規格で決まっているはず……

377(3): 2021/09/18(土)13:05 ID:fzYJNrfO(3/4) AAS
ちなみにst1 ＜ st2 でありかつ (now ≦ st2) が非成立、というケースも発生するあるから
おかしいのは明らかにstd::chronoの方、

378(1): 2021/09/18(土)13:23 ID:I+biH5jK(1/2) AAS
>>377
これだけじゃどっちがおかしいかは分からんでしょ
GetLocalTimeが正しいと思うからGetLocalTimeでsystem_clock::nowを挟んだんじゃないかい

379: 2021/09/18(土)13:43 ID:fzYJNrfO(4/4) AAS
>>378
>>377のは時刻のキャッシングみたいなことをしており呼び出した瞬間の時刻を返していないとしたらそれはGetLocalTime()の方ではない、という証左

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

380: 2021/09/18(土)13:48 ID:vjp4M7Ow(1) AAS
windowsのAPI同士で比較しろ
一般に違うAPIを使ってるなら一貫した結果にならなくてもおかしくない

381: 2021/09/18(土)13:53 ID:I+biH5jK(2/2) AAS
ちゃんと知りたいならsystem_clock::nowが内部でどのAPIを呼んでいるのか調べてみては

382: 2021/09/18(土)13:58 ID:EqZgRVmV(1/2) AAS
変数tpはなにものですか

383: 2021/09/18(土)14:01 ID:EqZgRVmV(2/2) AAS
というか% 1000っておかしくね？？？

384: 2021/09/19(日)00:12 ID:EWVuImUN(1) AAS
>>375
お前の頭がおかしいんだよ

385: 2021/09/19(日)00:47 ID:hcp/HEe5(1) AAS
不等号≦への理解、間違ってないか

386(1): 2021/09/19(日)07:30 ID:CNUd2o2A(1) AAS
unsignedとintを比較してるとかどうせそういうオチだろ

387(1): 2021/09/19(日)13:12 ID:/yxUr6Cy(1) AAS
中途半端なコードだけチラ見せされてもな
再現する完全なコードを出せとしか

388(4): 2021/09/19(日)15:50 ID:neurUQ4a(1/6) AAS
>>386
天才なのでそんなヘマはしますしません、

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

ウィンドーズでの実行結果：
i=---: st1, chrono, st2: ORDER CHECK
i= 0: 1632034143228, 1632034143228, 1632034143228: OK.
i= 1: 1632034143229, 1632034143229, 1632034143229: OK.
省9

389: 2021/09/19(日)15:57 ID:neurUQ4a(2/6) AAS
こっそり訂正するが、>>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)
省3

390(1): 2021/09/19(日)16:10 ID:HwX1dH8g(1) AAS
まともに読んでないがバリアの使い方がおかしくて実行順序入れ替わってるとかじゃね？？

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

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

392(1): 2021/09/19(日)16:39 ID:k8GedCcQ(1/3) AAS
外部ﾘﾝｸ:gist.github.com

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

393(4): はちみつ餃子 ◆8X2XSCHEME 2021/09/19(日)17:02 ID:nkVr2ypq(1) AAS
>>375
GetLocalTime の分解能は 10ms くらいっぽいぞ。
system_clock::now がもっと精度の高い API を使っていたら
そんくらいの前後はあってもおかしくないんじゃね。

394: 2021/09/19(日)17:17 ID:k8GedCcQ(2/3) AAS
外部ﾘﾝｸ:ideone.com
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やめたら？

395(1): 2021/09/19(日)17:28 ID:UeoKc9fZ(1/4) AAS
時刻取得用のAPIをパフォーマンス計測用に使っちゃったんだね
WIN32では大昔からQueryPerformanceFrequencyとQueryPerformanceCounterを使うよ
外部ﾘﾝｸ:docs.microsoft.com

396: 2021/09/19(日)17:59 ID:UeoKc9fZ(2/4) AAS
時刻取得でそのまま精度を上げるAPIとしては
GetSystemTimePreciseAsFileTime
外部ﾘﾝｸ:docs.microsoft.com
ただしWindows 8以降。それ以前だと以下を使うしかないっぽいね。
GetSystemTimeAsFileTime

std::system_time::nowの実装としては、_Xtime_get_ticksを使用している(2021年9月21日17:57JST現在)
外部ﾘﾝｸ:github.com

これが使用しているAPIについて聞いたStackoverflowの質問
外部ﾘﾝｸ:stackoverflow.com

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

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

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

398(1): 2021/09/19(日)20:05 ID:neurUQ4a(5/6) AAS
というわけでms単位のUNIX timeを得るにあたってstd::chronoとGetFileTimeAsSystemTime()が同じ精度であり互換であることを
直接検証すた、
外部ﾘﾝｸ:ideone.com

実行結果（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.
省7

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

400(1): 2021/09/19(日)21:46 ID:UeoKc9fZ(3/4) AAS
古いWIN32開発者には常識的な話で検証の必要もなく、実際に検証用のプログラムは昔から大量に作られてるからだと思う

取得時間の間隔が15.6 msの倍数にならないのは「主に16ビット Windows との下位互換性のため」
外部ﾘﾝｸ:docs.microsoft.com

401(1): 2021/09/19(日)22:17 ID:k8GedCcQ(3/3) AAS
>>400
後半って「Windows時刻」の説明だよね？
GetSystemTimeで得られるのは「システム時刻」であって、また別の時刻体系だと読んだけど間違ってる？
外部ﾘﾝｸ:docs.microsoft.com

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

402(1): 2021/09/19(日)22:38 ID:UeoKc9fZ(4/4) AAS
>>401
大元はWindows3.1時代からあったGetTickCountだと思うんだけど、説明的にそこしかなかったから書いた
WinAPIスレで聞きたければどうぞ

403: 2021/09/20(月)00:06 ID:luBeUSFz(1/4) AAS
周期15.6 msを下位互換性のために新しいWindowsがエミュレートしているというのはありえない

1スレッドへの最大割り当て時間としての15.6 msはPCによって変わり得るデフォルト値にすぎないし、
外部ﾘﾝｸ[html]:hp.vector.co.jp

だいたい設定でも変わるし、
外部ﾘﾝｸ[html]:atmarkit.itmedia.co.jp
（スレッドのクォンタムタイム）

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

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

405: 2021/09/20(月)00:25 ID:luBeUSFz(3/4) AAS
AA省

406: 2021/09/20(月)00:26 ID:luBeUSFz(4/4) AAS
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)
省3

407: 2021/09/20(月)06:12 ID:DnvAIBnA(1/5) AAS
>>402
自己レスです

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

PS C:\> .\ConsoleApplication8.exe
15614998
1003946
1000238
PS C:\> .\ConsoleApplication8.exe
省6

408: 2021/09/20(月)07:46 ID:Pqsh6MJQ(1) AAS
ここはWindowsAPIスレになったのか

409: 2021/09/20(月)07:51 ID:l/aXhlvm(1) AAS
スレタイも読めない、検索できないやつがまともなプログラム書けるはずもなく・・・

410: 2021/09/20(月)07:52 ID:Mm5TpRqo(1) AAS
windows API使いたがるひとがいてめんどくさい
こっちはなるべく標準のc++使いたいのに

411: 2021/09/20(月)08:19 ID:VgAULHWI(1/4) AAS
POSIXと比べるとクソ過ぎて話にならんよな

412: 2021/09/20(月)10:01 ID:LqQpPYvk(1) AAS
プラットフォーム固有の話も参考になる
今回の流れは Win32 API と std::chrono の違いが端緒だしスレ違いというほどではない

413: 2021/09/20(月)10:48 ID:T+6xg0LJ(1) AAS
そのクソがなんで一番利用者多いのか考えてみろ

414: 2021/09/20(月)11:24 ID:VgAULHWI(2/4) AAS
バカに合わせてるからだろ
言わせんなよ恥ずかしい

415: ハノン ◆QZaw55cn4c 2021/09/20(月)11:26 ID:+hQanlE4(1) AAS
私馬鹿よねーお馬鹿さんよねー今日も win32api

416(1): 2021/09/20(月)11:30 ID:DnvAIBnA(2/5) AAS
とりあえず動かないから面白くないということなのかもなということで、Linuxのclock_gettimeにも対応しといた。
BSDとmac組は知らん。
外部ﾘﾝｸ:ideone.com

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

417(1): 2021/09/20(月)12:15 ID:rmuhdvcF(1) AAS
timeBeginPeriod
木屋さん元気かな

418(1): 2021/09/20(月)12:28 ID:26DwFCZj(1) AAS
元の質問見てないけどQPCでええんちゃうの

419: 2021/09/20(月)12:45 ID:DnvAIBnA(3/5) AAS
>>417
スレッドのスケジューリングも変化するので注意です。
tickとはそもそもそういうものでしたが。
外部ﾘﾝｸ[html]:archive.linux.or.jp

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

420(1): 2021/09/20(月)12:51 ID:VgAULHWI(3/4) AAS
CreateWaitableTimerEx(NULL,NULL,CREATE_WAITABLE_TIMER_HIGH_RESOLUTION,TIMER_ALL_ACCESS)

421: 2021/09/20(月)13:22 ID:DnvAIBnA(4/5) AAS
>>420
そのタイマは同期待ち合わせに使用するタイマリソースですね
時間計測用に使うのは勿体ないのでやめましょう
また無言でAPIだけ書かれても困ります

422(1): 2021/09/20(月)13:58 ID:VgAULHWI(4/4) AAS
バカか
計測するなら精度高めないと意味ないだろ

423(1): 2021/09/20(月)14:31 ID:LO5PkHvF(1) AAS
そもそもパフォーマンスの計測に使うなんて言ってなくない？

424(1): 2021/09/20(月)16:05 ID:DnvAIBnA(5/5) AAS
>>422
この例はExついてないけど、こういう使い方をするものなんだよ。
待機可能タイマーオブジェクトの使用 - Win32 apps | Microsoft Docs
外部ﾘﾝｸ:docs.microsoft.com

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

425(1): 2021/09/25(土)05:50 ID:B+D0wTVh(1/4) AAS
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な未来が見える見えまくり

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

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

427: 2021/09/25(土)06:02 ID:B+D0wTVh(3/4) AAS
ごめ、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もプリエンプションの機会にならない保証が無いのでビジーループはｶﾞﾁでビジーループで作る必要があり、
省1

428: 2021/09/25(土)07:18 ID:B+D0wTVh(4/4) AAS
といいつつAPIに頼らずに10 ms規模のビジーループ（ビジーウェイト）させるのはやや技巧を要すると思ったので漏れが自らやってやった、
外部ﾘﾝｸ:ideone.com
※ 計測の実行は要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()のふるまいが一方的に謎杉

429: 2021/09/25(土)08:12 ID:HzR9ZlyY(1/2) AAS
WinAPIスレに持っていってくれますか？
結局<chrono>に固有の問題（？）ではなくて背後のAPI関数に関することって分かったはずなんで

430(1): 2021/09/25(土)08:44 ID:HzR9ZlyY(2/2) AAS
とか言いつつ自分で探してきたので貼っちゃう……
GetSystemTimeの分解能が15.6msというのはXPまでの話らしい

外部ﾘﾝｸ[html]:www.thedelphigeek.com

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

432: 2021/09/25(土)17:45 ID:+JZgAVsh(1/2) AAS
> プリエンプションの機会

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

433: 2021/09/25(土)18:35 ID:8CcFj4Yb(1) AAS
今だって邪魔できるよ
消極的ではあるけど

434: 2021/09/25(土)18:44 ID:+JZgAVsh(2/2) AAS
割り込み禁止命令が実行できたり
割り込みコントローラにコマンド出せたりする
デバドラかMODESETみたいのないと無理だよ

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

436: 2021/09/26(日)13:03 ID:4UIlewCz(1/3) AAS
ompのAPI仕様書を読むと対象はスカラー型のみって書いてあるから対象外なんじゃないの？

437: 2021/09/26(日)13:04 ID:4UIlewCz(2/3) AAS
ここのx and vってとこ
外部ﾘﾝｸ[html]:www.openmp.org

438(2): 2021/09/26(日)13:07 ID:9lvhFgGq(2/3) AAS
数学とか物理の用語としては複素数はスカラーですが、コンピューター用語としては違うんでしたっけ？

439: 2021/09/26(日)13:18 ID:loHIOGgF(1) AAS
確かモルダーを疲れさせる女のこと

440: 2021/09/26(日)13:28 ID:pztAGZv/(1) AAS
対象外
ぷりみ恥部とPOD以外だめ

441(1): 2021/09/26(日)14:59 ID:4UIlewCz(3/3) AAS
>>438
std::complexはclass型だよ。c++では

442: 2021/09/26(日)15:02 ID:9lvhFgGq(3/3) AAS
>>441
つまりatomicはプリミティブ型だけ想定してるってことですかね
ありがとうございます
おとなしくクリティカルセクションにします

443: はちみつ餃子 ◆8X2XSCHEME 2021/09/27(月)00:54 ID:vtQXnC4F(1) AAS
>>438
C++ におけるスカラ型の定義
・算術型 (整数型と浮動小数点数型)
・列挙型
・ポインタ型
・メンバへのポインタ型
・ std::nullptr_t
・以上を cv 修飾 (const や volatile で修飾) したもの

外部ﾘﾝｸ:timsong-cpp.github.io

言語によって定義は異なっている (または定義を持たない) ので
省1

444: 2021/09/27(月)06:07 ID:vzE92GBt(1) AAS
ここはC++スレだからC++用語で必要充分だ
無理に一般化する必要はない

445: 2021/09/27(月)08:56 ID:P6ytpwfT(1) AAS
複素数が「算術型」じゃないのって冷静に考えるの結構奇妙だな

446: 2021/09/27(月)19:18 ID:LR1S7vXs(1) AAS
複素数を直接扱う命令がないCPUが多い以上、小数2個で表される複素数がスカラではないのは自然だと思うけど

それを言い出すと、一般線形群と呼ばれる行列はなんでも算術型になるのではないか？と思えてくるし

447(1): 2021/09/27(月)19:25 ID:n9hc+rIL(1) AAS
arithmeticを「算術」とか仰々しく訳すからおかしくなる
要は小学生がさんすうで習うような単純な数のことよ

448: 2021/09/27(月)22:16 ID:D7AKGDxr(1) AAS
そもそも数学でも複素数はスカラじゃないよな

449: 2021/09/27(月)22:19 ID:sGjfmd1K(1) AAS
ベクトルの係数になるんだから基本的にスカラじゃねえの

450: 2021/09/27(月)22:43 ID:PI7czi9F(1) AAS
スカラーだったりベクトルだったりするらしい
外部ﾘﾝｸ[htm]:izumi-math.jp

451: 2021/09/27(月)22:51 ID:GPisoDJi(1) AAS
複素ベクトル空間の係数体の元として見ればスカラだし複素数体を実ベクトル空間と見れば複素数は実ベクトル

452(1): 2021/09/28(火)07:58 ID:ZoUlFxaV(1) AAS
除算が定義できる体なので普通はスカラーとして扱うと思うけどな。
2要素の実ベクトルや2自由度の行列に適切な演算を導入することによって同一視することはできる。

上下前次 1-新書関写板覧索設栞歴

あと 550 ﾚｽあります
ｽﾚ情報赤ﾚｽ抽出画像ﾚｽ抽出歴の未読ｽﾚ AAｻﾑﾈｲﾙ

ぬこの手ぬこTOP 0.052s