C++相談室 part145

**デフォルトの名無しさん** · 2019/09/13(金) 17:13:24.60

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

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

このスレもよろしくね。
【初心者歓迎】C/C++室 Ver.105【環境依存OK】
https://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/ (日本語)

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

**デフォルトの名無しさん** · 2019/10/19(土) 01:28:27.26

mingw使わずに標準のwindowsの環境で使えるようになってから出直してきて

**デフォルトの名無しさん** · 2019/10/19(土) 01:36:12.28

mesonいいぞー

**デフォルトの名無しさん** · 2019/10/19(土) 01:37:16.21

makeとかのビルドツールって超重要なはずなのにおざなりな状況になってるのは不思議だ
なんとかしてくれ

**デフォルトの名無しさん** · 2019/10/19(土) 01:49:35.75

クロスプラットフォームなソフト作るにしても、成果物が対象の環境で動けば良い訳で、ビルドをどの環境でも出来ることにそれほど意味はないからね
てかunix系でgccやclang使って開発しているものをVCに入れても謎の独自仕様でコンパイルできないとかザラだしね

**デフォルトの名無しさん** · 2019/10/19(土) 04:05:50.65

>>500
そう言って立ち上がった人は100億人くらいいたが誰一人として帰ってくる者はいなかった

**デフォルトの名無しさん** · 2019/10/19(土) 04:25:19.36

>>502
ほんとこれw

**デフォルトの名無しさん** · 2019/10/19(土) 07:26:21.05

>>498
wslでmingwクロス環境はマクソ提供だけど

**デフォルトの名無しさん** · 2019/10/19(土) 09:24:58.31

あらゆるビルドツールは怪獣化して、怪獣を飼いならすためのラッパーが必要になり、そしてそのラッパーももれなく怪獣化する
歴史が証明しており例外はない

**デフォルトの名無しさん** · 2019/10/19(土) 09:25:25.42

会社でifstreamのファイルオープンがエラーになるのはなぜなのか不明。assert()で引っかかる。
Visual Studio 2008コマンドプロンプトでコンパイルしたプログラムで、コードは単純化
して示したものが下記のようなもの。
std::ifstream ifs1;
for (n = 0; n < 8; ++n) {
ifs1.open(s[n].c_str());
assert(ifs1); // もしくはassert(ifs1.is_open());
関数(ifs1);
ifs1.close();
ifs1.clear();
}
コーディング上に間違いがあるのかいな。ファイルが使用中のためにエラー
でもないようだし。
よくわからんからCのFILE *に変更して対処したけどコンパイラの欠陥か。
ifstreamを宣言した後に ifs1.clear(); が必要なのか。

**デフォルトの名無しさん** · 2019/10/19(土) 09:50:39.86

ifsreamってcloseの後に再使用できる保証あったっけ？
ifs1の宣言をfor文の中に入れて毎回オブジェクト作り直す方が無難に見える

**デフォルトの名無しさん** · 2019/10/19(土) 09:51:32.93

宣言じゃないや定義

**デフォルトの名無しさん** · 2019/10/19(土) 09:54:59.18

makeが複雑なんじゃなくて
多様な環境すべてに対応するように書くことが複雑なわけで。
だったらdockerなり使って一つの環境だけでの提供を考える方が楽。

**デフォルトの名無しさん** · 2019/10/19(土) 11:50:11.90

>>506
まずファイル開く権限あるのかな
最近それで引っかかった

**デフォルトの名無しさん** · 2019/10/19(土) 12:33:25.60

>>484
あれ、Winの構造化例外ってそもそもtry..catchには引っかからなかったような……

**デフォルトの名無しさん** · 2019/10/19(土) 12:41:43.65

Rakefileを使っている俺は小数派。

>>506
古いVCの場合ifstreamのclear()後再使用はできなかった記憶がある。

**デフォルトの名無しさん** · 2019/10/19(土) 13:51:45.42

C++でv8のjavascriptを使うために
インストールしようと色々やってるんだけどどうにもうまく行かない。

https://qiita.com/mofumonta/items/ef3d890e13a7c1701748
このサイトを参考にしながら進めてるんだけど
「depot-toolsインストール」の環境変数を通す項目で
C:\v8\depot_tools\win_tools-2_7_6_bin\python\bin
このパスがダウンロードしてきたdepot-toolsにはないんだけど、
どこにあるか誰か知りませんか？

スレチだったらごめんなさい。

**デフォルトの名無しさん** · 2019/10/19(土) 14:48:33.14

おま環
何をダウソしたかくらいは書け

**デフォルトの名無しさん** · 2019/10/19(土) 15:03:15.21

python2.7 が既に入ってるなら
その bin に path 通しとけば良いんかな

**デフォルトの名無しさん** · 2019/10/19(土) 15:14:23.88

>>483
C の関数が呼び出すコールバックを C++ で書いた場合、環境によってはコールバックからの例外が
C の関数を通過してくる。環境によっては通過できずに terminate() するけど。
厳密に「Cの関数」じゃなくなるけど qsort(), bsearch() については例外が通過できるものと規定されている。
あとは未定義動作となる場合の反応として例外が飛んでくることはあるかもしれない。

**デフォルトの名無しさん** · 2019/10/19(土) 15:22:29.09

>>514
忘れてた。スマヌ。
Windows10 X64
Visual Studio Community 2019
Python 3.7.4(64-bit)
Git version 2.23.0.windows.1

ダウンロードしたのは
https://chromium.googlesource.com/chromium/tools/depot_tools.git
ここから「x64 Native Tools Command Prompt for VS 2019」
で「git clone」を使ってダウンロードしました。

>>515
python自体のbinフォルダは試してませんでした。
ちょっとやってみます。

**デフォルトの名無しさん** · 2019/10/19(土) 15:27:23.69

OS とかツールは全部違うけど
https://chromium.googlesource.com/chromium/tools/depot_tools.git
これ clone しても確かに win_tools-2_7_6_bin は無かった

**デフォルトの名無しさん** · 2019/10/19(土) 15:29:04.62

何故公式のインストール手順を読まないのか

**デフォルトの名無しさん** · 2019/10/19(土) 19:15:58.17

Node.js じゃ、ダメなのか？

**デフォルトの名無しさん** · 2019/10/19(土) 20:05:28.35

>>511
なんか設定次第で引っかかるようにならなかったっけ・・・

**517です** · 2019/10/20(日) 17:45:24.74

>>519
インストール手順自体は試したんだけど、
あまりに訳わからんちんで途中で断念して
他のサイトを見ながら入れようとしています。

>>520
Node.jsってv8の上に乗っかったjavascriptというイメージなんだけど、
C++から呼び出せるのでしょうか？

**蟻人間** ◆T6xkBnTXz7B0 · 2019/10/20(日) 20:19:16.97

今、YappyCamという録画ソフトを作っています。以下のソースをご覧下さい。

https://github.com/katahiromz/YappyCam/blob/master/sound.hpp
https://github.com/katahiromz/YappyCam/blob/master/sound.hpp#L125
https://github.com/katahiromz/YappyCam/blob/master/sound.cpp#L154

このSoundが音声を扱うクラスになっております。
スレッド関数Sound::ThreadProcで録音処理を行っています。
std::vector<BYTE> m_wave_dataがサウンドバッファです。
Sound::FlushDataがバッファを吐き出す関数です。

現在、SSDが主流になりつつありますが、ハードディスクでもトラブルなく使えるようにしたいです。いくつか質問します。

１．m_wave_dataをstaticな固定バッファにすべきか。するとすればどれぐらいの容量か。
２．もっといいバッファリングの方法はないか。

お願いします。

**蟻人間** ◆T6xkBnTXz7B0 · 2019/10/20(日) 21:02:47.12

スピード命です。フレーム落ちは絶対にダメだそうです。

**デフォルトの名無しさん** · 2019/10/20(日) 21:06:32.98

古臭いスタイルはさておき・・・
(別にそれでいいと思うよ)

なぜバッファリングしてる？
vectorにためずにwriteしたらいいじゃん
readとwriteの単位が合わないとか？
バッファリングするならreader/writerで別スレッドにした方がいいかもね

オーディオの処理なんだからおれなら動的メモリ確保の走るvectorは使わないね
最悪システムコールだから音が途切れる可能性が高まる
一瞬かもしれないが音は少しでも途切れるとノイズになる

最適なバッファ量はそのルーチンがどれぐらいのジッターで駆動してか計測して決めればいい
あとバッファリングすればそれだけ遅延が発生するから注意
本来ビデオ側と同期をとる必要あるけどPCだと適当だよな
CE機器だと完璧に合わせるけど

**デフォルトの名無しさん** · 2019/10/20(日) 21:15:47.21

COBOLのWRITE命令みたいに非同期書き込み＆バッファローテーションてか？
あの当時のアホOSならともかく今どきアプリでそんなことせにゃならんか？
ベアメタルなら面白そうだけど

**デフォルトの名無しさん** · 2019/10/20(日) 21:16:42.61

遅延の原因は、vector::insert()でしょ。

**デフォルトの名無しさん** · 2019/10/20(日) 21:24:56.14

ズらすの？

**デフォルトの名無しさん** · 2019/10/20(日) 21:27:13.38

誰がハゲやねん

**蟻人間** ◆T6xkBnTXz7B0 · 2019/10/20(日) 22:12:11.93

ああそうか。std::FILE/CreateFileそのものがバッファリングしてるんだ。ならば下手なバッファリングは必要ないと。

普通にI/Oすることにします。ありがとうございます。

**蟻人間** ◆T6xkBnTXz7B0 · 2019/10/20(日) 22:21:50.50

std::vectorのメモリー動的確保は音声処理では不味いと。

ハードディスク環境でジッターを測定して見ないと。わかりました。

**デフォルトの名無しさん** · 2019/10/20(日) 22:32:55.48

>>530
ただそのスレッドでwriteするのが問題ないかはよく確認した方がいいよ
writeでブロックされることで音声のソース側の処理が滞る可能性がある
その場合はやっぱり別スレッドにすべきだね

**蟻人間** ◆T6xkBnTXz7B0 · 2019/10/20(日) 22:59:16.11

プログラム高速化の禁術
https://qiita.com/kotauchisunsun/items/84e01c6fb621fcc1a647

**蟻人間** ◆T6xkBnTXz7B0 · 2019/10/20(日) 23:12:22.20

setvbufって便利な関数を見つけた。これ使うか。

**デフォルトの名無しさん** · 2019/10/20(日) 23:13:52.92

音声のバッファリングには普通はリングバッファを使う

**蟻人間** ◆T6xkBnTXz7B0 · 2019/10/20(日) 23:28:56.20

ここまでのまとめ。

リングバッファを使う。
十分大きなバッファサイズでsetvbufを使う。
リングバッファへの読み書きは別スレッドにする。
バッファが空のときはイベント待ちで休ませる。

**デフォルトの名無しさん** · 2019/10/20(日) 23:44:50.34

別スレッドにキューイングするのに適したC++標準クラスは何かな？

**デフォルトの名無しさん** · 2019/10/21(月) 06:50:33.92

ゴチャゴチャ言うならビルトイン配列使っとけ

**デフォルトの名無しさん** · 2019/10/21(月) 15:01:03.56

C++から呼べるし
C++を呼べる

**デフォルトの名無しさん** · 2019/10/21(月) 15:43:44.16

>>537
Queue への読み書きは、1要素当たりは短時間で済むことが多いので、
Queueを読み書きする場所で、必ず Critical Section などで囲むと良い。
一度に沢山の要素をまとめて書き込みたい場合は、原則的には、
1要素を書き込む処理をこまめに、Critical Section で囲むようにする。
必ずしも1要素ずつ囲む必要は無いが、こまめに囲った方が、
別スレッドの待ち時間が減ることが期待できるが、その意味が有る場合と
無い場合とが有る。
Critical Section の代わりに、Mutex や Semaphore などを使うことも出来る。

**デフォルトの名無しさん** · 2019/10/21(月) 17:20:19.00

キャッシュに配列を置けばいいじゃねえか
かんたんだろ

APUの近くに配列でOK
複雑なデータ構造なんて考える必要ナシ

**デフォルトの名無しさん** · 2019/10/21(月) 18:19:39.76

タイミングで問題が出てるのにvectorにこだわるのはアホだよな

**デフォルトの名無しさん** · 2019/10/21(月) 18:33:52.73

実行時のパラメータでバッファサイズ可変にするならvectorで始めにresizeしておくのが楽
size使える分配列のunique_ptrより取り回しも楽だし

**デフォルトの名無しさん** · 2019/10/21(月) 18:43:04.52

boostにリングバッファのクラスあるよ

**蟻人間** ◆T6xkBnTXz7B0 · 2019/10/21(月) 18:50:23.92

天才だから自分でリングバッファ作った。
https://github.com/katahiromz/YappyCam/blob/master/ring.hpp

**蟻人間** ◆T6xkBnTXz7B0 · 2019/10/21(月) 19:22:51.62

バッファがいっぱいになったらどうしよう？

**537** · 2019/10/21(月) 19:27:27.31

>>540
それらの同期機能って標準C++のクラスだけで実現できるもんなの？

**デフォルトの名無しさん** · 2019/10/21(月) 19:30:51.93

>>546
捨てるしかないだろ

**デフォルトの名無しさん** · 2019/10/21(月) 20:56:31.15

>>547
どこまでを標準と言ってるのか知らんけどお前の考える標準でスレッドをサポートしてるならたいてい同期機構もあるはず

**蟻人間** ◆T6xkBnTXz7B0 · 2019/10/21(月) 21:02:21.32

>>547
WindowsではCriticalSection, CreateMutexなどがあったからC++11以前でも使えた。
C++11からstd::mutex, std::lock_guardなどが使えるぞ。

**デフォルトの名無しさん** · 2019/10/22(火) 00:25:01.95

ロックフリー的ななんか無かったっけ？

**蟻人間** ◆T6xkBnTXz7B0 · 2019/10/22(火) 16:18:00.26

リングバッファの排他制御どうするか？

push/popごとにロックかけたら遅くなりそう。

**デフォルトの名無しさん** · 2019/10/22(火) 16:36:38.23

>>545
stlライクにしてる割にコピーやムーブが内部の値ベースなのおかしくない？

**デフォルトの名無しさん** · 2019/10/22(火) 17:03:31.86

用途的に
reader 1
wrtier 1
だと思うけどそれならwait freeな実装が可能
read pointer/writer pointerで制御するやつね
かつかつに最適化するならこれ

しかしその前にどれだけの頻度と長さで排他の衝突するか見た方がいい
リアルタイムのオーディオなら短くても5msec周期とかじゃないか
かつlock中に多少のメモリの読み書きやってるだけなら排他が必要な時間は短い
なら素朴にmutex1個でのロックで十分な可能性も高い
同期のミスはデバッグがつらいから不用意に難しいことしない方がいい

もしくはある程度のバッファリング(遅延)が許容できるとか、固定長の処理であるなら
ならバッファを複数用意してダブル、トリプルバッファ的な制御でもいいだろう
つまりwriter側でバッファに全部書き終わったらそのバッファをreader側のキューにいれる
reader側は全部読み終わったらwriter側のキューに戻す
っての

とにかく原則どおりまずシンプルにミスなく作って計測して最適化ね

**デフォルトの名無しさん** · 2019/10/22(火) 17:19:01.36

ringのソース見たけど
おれはm_full なしでやるのが好みだな
つまりm_front_indexとm_back_indexが一致するのはemptyのときのみ
full時には実際は1個空きがある状態

これを推し進めればwait freeの実装に近づけるぞ
車輪の再発明だが勉強にはなる

**デフォルトの名無しさん** · 2019/10/22(火) 17:21:45.79

>>551
std::atomicとかあるね
原理的に競合が起きないやつ

**蟻人間** ◆T6xkBnTXz7B0 · 2019/10/22(火) 17:29:01.30

まずは記憶媒体の性能を計測してみた。
https://github.com/katahiromz/YappyCam/blob/master/tests/diskrate/diskrate.cpp
https://twitter.com/katahiromz/status/1186558848393285633
これはSSDの場合だ。HDDでも同様に計測しないといけない。
https://twitter.com/5chan_nel (5ch newer account)

**蟻人間** ◆T6xkBnTXz7B0 · 2019/10/22(火) 17:43:23.84

static DWORD s_dwTick;
printf("write: %ld, %ld\n", cbToWrite, GetTickCount() - s_dwTick);
s_dwTick = GetTickCount();

// 最高の音質での出力。
write: 3900, 15
write: 3900, 0
write: 3900, 16
write: 3904, 16
write: 3900, 0

10msecごとに音声データがおよそ3900バイトあるようだ。

**デフォルトの名無しさん** · 2019/10/22(火) 18:28:33.04

>>558
Win32APIや音声仕様はC++じゃないのでよそでどうぞ。>蟻人間

**蟻人間** ◆T6xkBnTXz7B0 · 2019/10/22(火) 19:41:50.02

>>553
具体的にどうやればいい？

**蟻人間** ◆T6xkBnTXz7B0 · 2019/10/22(火) 20:08:29.90

【初心者歓迎】C/C++室 Ver.105【環境依存OK】
https://mevius.5ch.net/test/read.cgi/tech/1556142878/

こっちに移動します。回答者に感謝します。

**デフォルトの名無しさん** · 2019/10/22(火) 21:35:58.70

Win32APIって何だよ
20年前からタイムスリップでもしてきたか？

◆QZaw55cn4c · 2019/10/22(火) 21:43:35.88

>>562
win32api(64bit版）で書くのが正義、という価値観もまだまだ存在するようです

**デフォルトの名無しさん** · 2019/10/22(火) 23:33:30.81

C++11からできた属性構文あるけどこの属性は宣言にだけつければOK?
定義にも同じ属性を記載するべき？

**デフォルトの名無しさん** · 2019/10/23(水) 00:34:15.61

>>563
それはお前だけの価値観だろハゲ

**デフォルトの名無しさん** · 2019/10/23(水) 00:50:12.41

>>563,565
Mozilla Firefoxなどサードパーティ大手は今もWin32APIをネイティブに使っており.NETを使ってない。

**はちみつ餃子** ◆8X2XSCHEME · 2019/10/23(水) 01:51:47.45

>>562 は .NET より WinRT とかを想定している気がするが。

**デフォルトの名無しさん** · 2019/10/23(水) 02:03:48.66

単に64bitのWindows APIもなぜかwin32と呼ばれ続けてること知らないんだろ

**デフォルトの名無しさん** · 2019/10/23(水) 06:28:47.24

それこそ２０年前からタイムスリップしたのかって話だなｗ

**デフォルトの名無しさん** · 2019/10/23(水) 18:08:41.93

速度重視な場面ならWin32APIは今でも普通に使う

**デフォルトの名無しさん** · 2019/10/23(水) 20:43:18.87

うわぁ・・・

**デフォルトの名無しさん** · 2019/10/23(水) 21:15:01.42

正直なところWin32APIで速度でるの？

**デフォルトの名無しさん** · 2019/10/23(水) 21:30:55.10

>>572
「Linuxシステムコールで速度でるの？」という質問と同じくらい矛盾に満ちた質問。
Win32APIも含めシステムコールはOSが提供するAPIなので、プログラマは他の手段で代替しようない。

**デフォルトの名無しさん** · 2019/10/23(水) 21:35:56.58

Native APIがあるじゃろ

**デフォルトの名無しさん** · 2019/10/23(水) 22:12:26.70

Visual C++ 2015なんですが、
goto文でERRORというラベルに飛ばそうとしたら、コンパイルエラーが出ました。
ERRにしたらコンパイルできるようになったんですが、
なぜERRORのラベルはダメなんでしょうか？

**蟻人間** ◆T6xkBnTXz7B0 · 2019/10/23(水) 22:22:13.25

>>575
<wingdi.h>に#define ERROR 0がある。

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

#undef ERROR

**デフォルトの名無しさん** · 2019/10/23(水) 22:24:20.08

単語1つのラベルなんか使うなってこった

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

いやC++ではマクロが悪だ

**575** · 2019/10/23(水) 22:32:44.87

ERRORのdefineがあるんですね･･･！
ありがとうございました！

**デフォルトの名無しさん** · 2019/10/24(木) 09:12:01.73

クソみたいなマクロにsmallもある
他にもwindows.hには地雷が入念に仕込まれてる

普通の神経の人間が爆死して厭らしい人間だけが生き残るように整えられている厭らしい環境がwindows.hだよ
マトモな人間にはまず耐えられない
頭のオカシイ厭らしい人間だけが残るように設計されているのがwindows.h
このヘッダは頭がおかしい

**デフォルトの名無しさん** · 2019/10/24(木) 13:45:08.38

>>581
お前の頭がおかしいだけだと思う

**デフォルトの名無しさん** · 2019/10/24(木) 13:57:45.03

林檎だってcheckマクロでBoostに大迷惑かけてるしお互い様

**デフォルトの名無しさん** · 2019/10/24(木) 17:59:23.36

>>582
そこは
ヘッダだけにな
と言ってやるところだろ

**デフォルトの名無しさん** · 2019/10/24(木) 18:05:45.17

ヘッダ「嫌ならincludeするな」

**デフォルトの名無しさん** · 2019/10/24(木) 19:57:40.06

このスレはみんなWindows嫌いなのかな

**デフォルトの名無しさん** · 2019/10/24(木) 20:17:56.94

んなわけない

**デフォルトの名無しさん** · 2019/10/24(木) 21:28:21.53

たしかmaxとかもマクロ定義されてたよね
初心者のころはどハマリして殺意がわいたわ

**デフォルトの名無しさん** · 2019/10/24(木) 21:49:18.24

いまはIDEが色変えてくれるからすぐわかるから別にいいけどね

**デフォルトの名無しさん** · 2019/10/24(木) 23:20:19.58

マクロがあればなんでもできる

**デフォルトの名無しさん** · 2019/10/24(木) 23:40:29.47

最近ちょいちょい思うことだが、ある言語のここがどうであーだこうだと議論する場合
テキストエディタでコーディング作業してる連中と IDE でコーディング作業してる連中では
わりと大きな認識の違いがあることが多い

**デフォルトの名無しさん** · 2019/10/24(木) 23:44:34.75

windows.hのマクロ回りでトラブル起こしているのは、殆んどvisual studio使用者だと思うのだが

**デフォルトの名無しさん** · 2019/10/25(金) 00:24:04.41

認識の違いはコンパイラによるものであってコードエディタは関係ない。

**デフォルトの名無しさん** · 2019/10/25(金) 00:39:26.61

モジュールでマクロとか気にしなくて良くなる（なるといいなぁ...）

**デフォルトの名無しさん** · 2019/10/25(金) 07:52:28.01

コンパイラ変えてもマクロは変わらんでしょ
せいぜいエラーメッセージ変わるぐらいじゃ

**デフォルトの名無しさん** · 2019/10/25(金) 09:14:30.39

>>595
何言ってるのか意味がわかりにくいエラーメッセージを吐くのはコンパイラでしょ。

**デフォルトの名無しさん** · 2019/10/25(金) 12:19:38.16

マクロは影響範囲わからんからなんとも

vcでマクロがテンプレートに影響したらマジでわからん
clangはテンプレートのエラーメッセージわかりやすいとかみたな