C++相談室 part163

2022/12/30(金) 23:16:31.37

!extend:checked:vvvvv:1000:512
!extend:checked:vvvvv:1000:512
↑同じ内容を3行貼り付けること

次スレは>>980が立てること
無理なら細かく安価指定

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

VIPQ2_EXTDAT: checked:vvvvv:1000:512:: EXT was configured

2023/04/13(木) 01:23:34.33

>>846
あと、printfはメインスレッドからコールしないと遮断されること普通にあるぞ
ファイルにfprintfで書いてみれよ

2023/04/13(木) 01:28:55.79

あと考えられる問題は、スレッドのスタックが足りなくてprintfがコールできていない可能性だな
いろいろと洗ってみれ

2023/04/13(木) 02:30:15.77

>>847
以下のようにprintというかcoutを挟むと、接続前はずっと"1"が出力されるのに、接続後は何も出力されなくなります。
エラーも出ず、プログラムは動き続けます。

int sockNum = select(socket + 1, &readFd, &writeFd, &errFd, &timeout);
if(0 == sockNum)
{
//timeout
std::cout << "1" << std::endl;
return -1;
}
else if(FD_ISSET(socket, &readFd) || FD_ISSET(socket, &writeFd) )
{
std::cout << "2" << std::endl;
}
else
{
//error
std::cout << "3" << std::endl;
return -1;
}
std::cout << "4" << std::endl;

2023/04/13(木) 02:46:49.32

そこ、コードが間違ってるな
selectのエラーは負の値返したときだよ

2023/04/13(木) 06:22:49.75

だがしかし、エラーじゃなくてタイムアウト検査して0と比較しているからこのままでも問題はないか
timevalのタイムアウト値がまちがってんじゃねーの？とは思う

2023/04/13(木) 07:23:10.38

socket + 1って何だっけ
おかしい原因これじゃないの？こういうもんだっけ？

2023/04/13(木) 08:05:52.88

VisualStudio使ってるんならステップ実行したほうがはやいんじゃね

1行ずつ実行してどこでクラッシュ/待たされてるかすぐにわかるぞ

2023/04/13(木) 10:00:54.60

接続後にConnect呼んでないだけでしょ

2023/04/13(木) 10:36:58.20

>>855
コード内のどこでconnectを呼べば良いですか？

2023/04/13(木) 15:55:39.85

>>856
ソースをうｐは無理？

2023/04/13(木) 17:56:14.36

初心者なのですが、find()で結果がないときnposの場合と.hoge.end()の場合、
イテレータで hoge.begin()とする場合と begin(hoge)とする場合(end()も同様）、等
混乱しております。これは...

2023/04/13(木) 18:12:14.03

nposってstd::basic_stringのか？
#include <algorithm>のfindとは別物だぞ

メンバ関数でfindを持っているオブジェクトならhoge.begin()
持っていないオブジェクトにはbegin(hoge)

2023/04/13(木) 18:22:14.89

>>858
algorithm にある std::find と string にある std::string::find の違いのことかな？
それはまあ名前が同じだけの別物なんでそういうものと思うしか仕方がない。

begin については、
異なるものが共通のインターフェイスで扱えるとテンプレート内で扱いやすいだろうというのが基本的な事情。
でも配列とかポインタがメンバを持つことは出来ないからこれらも含めて共通の扱いをしたい場合は
メンバ関数の begin よりも非メンバ関数の std::begin を使う必要がある。
メンバに begin を持っている場合はそれを直接に呼んでも std::begin を使っても結果は同じだよ。

C++ には ADL という仕組みがあって引数に関連する名前空間も関数を探す探索対象になるというルールがある。
std::begin は ADL の仕組みと相性が悪いところがあって扱いづらいので
新しい仕様は std::ranges::begin が導入された。

ややこしいんだが全部を一貫して説明できるような統制された理屈があるわけではなくて
細々とした歴史的事情の積み重ねでグダグダになってるだけ。

2023/04/15(土) 01:20:02.46

intとsize_tって足し算したらsize_tになるんか・・・？

2023/04/15(土) 02:11:09.11

bit数の大きい側に拡張してから演算するんやっけ

2023/04/15(土) 02:27:21.46

不安ならキャストせい

2023/04/15(土) 02:33:26.00

改めて書くと
std::vector<...> vec;
int neg = -15;
for(int x = neg ; x < neg + vec.size() ; x++){ ...
こんな感じのfor文の中になぜか入ってこず
for(int x = neg ; x < neg + (int)vec.size() ; x++){ ...
こう書き換えたらfor文の中にちゃんと入ってきたので
何事かと

2023/04/15(土) 02:57:32.14

そりゃビット数の多いsize_tに自動的にキャストされるからな

2023/04/15(土) 09:19:08.06

コンパイラの警告出てるでしょそれ

2023/04/15(土) 12:55:47.51

32bit intが表現できる範囲(-21億～+21億)と
size_tが表現できる範囲(32bit環境なら0～42億、64bit環境なら1800京)が違うんだよね

直接キャストしたり比較演算した結果が一目で分からないし、
未規定の動作も紛れてるから
コンパイラによって結果が変わったりする

2023/04/15(土) 15:43:33.34

ちなみに更に厳密なことを言うと std::vector::size() の返却値の型は std::vector::size_type であって、
一般的な実装では size_t の別名として定義されることが多いけどそうでないこともありうる。

2023/04/15(土) 17:41:19.21

移植性を気にする人ってtypename std::vector<hoge>::size_typeとか書いてるの？

2023/04/15(土) 18:32:47.38

こんなかなあ
不用意にsize_t決め打ちはなるべくしない（せざるをえない場合もある）

auto N = v.size();

for(decltype(N) i = 0; i < N; ++i) {　/**/ }

2023/04/15(土) 20:20:15.05

単にsize_tの型とイコールじゃなかったらエラーではねとけばいいんじゃね
想定外環境でも何でもかんでも通そううなんて思考はバグの元になるし

2023/04/15(土) 20:53:24.33

NAXDE

2023/04/15(土) 20:58:21.87

なんでsize_tをunsigned にしたんだろうな…

2023/04/15(土) 21:05:21.11

そりゃサイズに負数はあり得ないからでは？
-12バイトのファイルなんてありえないですし

2023/04/15(土) 21:41:39.88

奥さん! そこでssize_tですよ!

2023/04/15(土) 22:41:45.51

数の概念が生まれた当初は負の数なんて想像つかなかったしな。
マイナス3個のリンゴとか存在しないし。

2023/04/15(土) 22:44:53.66

つまりマイナスの概念が存在しない時からsize_tは存在していた！？

2023/04/15(土) 23:18:30.96

負数があるならssize_tやptrdiff_tと使い分けなよ…

2023/04/16(日) 09:49:57.27

for (size_t k = 999; k >= 0; k--) {
　...

2023/04/16(日) 12:17:04.86

for (size_t k = 999; k+1 > 0; k--) {
　...

2023/04/16(日) 17:59:44.79

k > -1

2023/04/16(日) 21:30:04.86

k < -1

2023/04/16(日) 23:08:58.58

くノ一

2023/04/17(月) 20:58:44.15

size_t の変数を 0 との大小で比較しても
常に >= 0 だから変なことになる
for で -- してるときは特に注意な

2023/04/18(火) 07:58:45.20

負の数、虚の数

2023/04/18(火) 09:29:12.70

符号無しループはグーグルだとコーディング規約違反だからな

2023/04/19(水) 11:20:40.34

コーディング基準はあくまで特定案件での決めごとに過ぎず
井の外で何かを批判する根拠に使っても説得力はない

2023/04/19(水) 11:50:42.02

符号ありしかない言語もあるから、それなりに一般性あるかと

2023/04/19(水) 12:06:58.70

特定案件つーてるのに他の言語？
話通じないやつだな

2023/04/19(水) 12:12:27.61

あれ？話広げたいんじゃなかったのか　こりゃ失礼

2023/04/21(金) 06:54:24.86

std::vector<T>::size()やstrlen()が符号無しで返してくるからそれらを使った汎用ライブラリ的なものを書く場合に仕方なくsize_tを使うこともあるだけでループ変数については符号有りで大して困らない希ガスだいたいOS記述言語であるところのC言語がアセンブラでは常識的に利用されるゼロフラグやキャリーフラグの概念を捨て去った設計した点をかみしめるべきや整数表現のMSBまで符号以外の意味で使わねばならないｼﾁｭｴｰｼｮﾝはﾏｼﾞ少ない多倍長演算であってさえ2のべき乗範囲に拘るのを捨てたらゼロフラグやキャリーフラグを駆使してビット幅全部使う記述と同等以上の効率にできうる

2023/04/21(金) 07:19:21.58

句読点を入れろ

2023/04/21(金) 08:49:31.32

江戸時代かよ。

2023/04/21(金) 11:52:07.81

スレチだと思うけどx86intrinsicsに詳しい人がいたらNonTemporal命令について教えてもらいたい
_mm_stream_load_si128や_mm_stream_si32はCPUキャッシュに対象範囲が無い場合はキャッシュスルーして確実にメモリを読み書きするということは分かったけど、
CPUキャッシュにある場合の挙動は一般的な命令同様にCPU内だけで完結してしまう？

2023/04/26(水) 10:00:37.79

>>891
読める・・・
読めるぞ！！

2023/04/26(水) 12:19:22.01

>>894
パフォーマンスを気にしてるなら実験、測定するべきだし
同期ならメモリバリア命令など適切な措置を取るべき

2023/04/26(水) 19:26:58.67

素人考えで悪いけどメモリへの書き込みがされずCPU内だけで終わると困ると思うけど

勝手なイメージ

書き込むアドレス内容がキャッシュに
ある
キャッシュのデータも書き換える　→　通常の動作

ない
_mm_stream_si32の場合　キャッシュへデータを読み込まない　→　速い
その他の場合　キャッシュへデータを読み込む　→　遅い

2023/04/26(水) 20:14:03.72

avx2でnon temporay　loadの方を比較したけどほぼ変わらない
サイズが小さすぎたせいかもしれないけど

2023/04/26(水) 22:05:00.98

>>896
目的はDMAとの整合性で既存の実装は勿論同期処理していたが
数日稼働させてみてTemporal命令混ぜた後にstreamストアしても今のところ不整合発生してないからもうちょい様子見てみる

2023/04/26(水) 22:12:18.77

>>898
本来のnon temporal命令の利点はその命令自体の速度ではなくキャッシュ汚染防止だね
例えば離れたアドレスにあるであろうstatic変数にアクセスするとき、その付近のデータには一定期間内に一度しかアクセスしないと分かりきっているなら、CPUの親切心による近隣メモリのキャッシュへの先読みはどうせ使われないのでむしろペナルティでしかなく不要となる

あとはmemcpyにおいてキャッシュはソース側に集中させてディスト側へは_mm_streamでキャッシュ汚染を抑えてコピーをするというテクニックもあって多分メジャーどころのコンパイラ実装は大体そうなってる
IvyBridge以降であればsimdより強化版rep movsbの方が早いケースも多くて分岐によってそっちに行くこともあるだろうけど

2023/04/26(水) 22:46:41.52

>>900
それなら納得

AMDでも試したけど変わらないな

2023/04/26(水) 22:54:06.40

それとx86intrinsicsと書かれてるのはSystem.Runtime.Intrinsics.X86 名前空間で.netなんだ
コンパイラがキャッシュを気にしたIL吐いたりそこから最適化されたネイティブコードを吐くようにはできてないと思う

2023/04/30(日) 10:58:06.37

これまでなんとなくinitializer_listを使ってきたのですが
このクラスって他のクラスと異なりコンパイラによって特別な解釈をされるのでしょうか?
以下のhoge::initializer_listはstdからコピペしてpublicメンバ以外を除外したものです
hoge::initializer_listを実体化するとコンパイルエラーとなります
コンパイラは g++ (Debian 10.2.1-6) 10.2.1 20210110 です
#include <initializer_list>
#include <cstddef>
namespace hoge {
template<class _E>
class initializer_list {
private: // 割愛
public:
typedef _E value_type;
typedef const _E& reference;
typedef const _E& const_reference;
typedef size_t size_type;
typedef const _E* iterator;
typedef const _E* const_iterator;
constexpr initializer_list() noexcept;
constexpr size_type size() const noexcept;
constexpr const_iterator begin() const noexcept;
constexpr const_iterator end() const noexcept;
};
}
int main () {
std::initializer_list <int> il0 = {10, 100, 1000};
hoge::initializer_list <int> il1 = {10, 100, 1000}; // <- コンパイルエラー
return 0;
}
エラーメッセージは
error: could not convert ‘{10, 100, 1000}’from ‘<brace-enclosed initializer list>’ to ‘hoge::initializer_list<int>’

2023/04/30(日) 11:09:10.55

エラーメッセージから考えると
1. { ..., ..., ..., }はstd::initializer_listと解釈される
2. std::initializer_listをhoge::initializer_listに変換しようとしてエラー
ということだと予想しますが
上記の1がstd::initializer_listを特殊なクラスとしている言語仕様と考えれば良い?

2023/04/30(日) 11:20:07.93

>>903
constexpr initializer_list(std::initializer_list<_E> const&) noexcept { }
これを追加すると通る

コンパイラは { } で std::initializer_list を生じる、という意味で「特別な解釈」をする
似たような話で typeid() で std::type_info を生じるのと同様

2023/04/30(日) 11:20:11.94

継承も何もしてないのにhoge::で上手く行くワケないだろ

2023/04/30(日) 11:25:59.75

せめて>>985みたいにstd::initializer_listを何かしらの形で受け入れ口としてコンストラクタに実装してやらないと通らないだろ

2023/04/30(日) 11:31:13.64

一般にstd名前空間のものは全部言語仕様と一体のものとしてあらゆる特別扱いが許されてるので
ヘッダからコピペして作った自作クラスが標準と同じように振る舞ってくれない可能性は常にある

2023/04/30(日) 11:36:13.87

>>905-908
みなさん有難うございます

>>908
>一般にstd名前空間のものは全部言語仕様と一体のものとしてあらゆる特別扱いが許されてるので
これは最小限にして欲しいものですね

>>905
>似たような話で typeid() で std::type_info を生じるのと同様
なるほどー! 言われてみればこれも気持ち悪かったです
同種の気持ち悪さ

2023/04/30(日) 11:38:03.98

初期化リストは式ではない

**デフォルトの名無しさん** (JP 0H6b-zzYQ) · 2023/04/30(日) 18:30:04.58

低レベルな質問ですが、よろしくお願いします

char str[10] = {0};

char str[10] = {0,};

この二つって違うんですか？

2023/04/30(日) 18:59:49.81

>>911
下は0,0と同じ意味じゃないかな

2023/04/30(日) 19:05:00.57

どっちも10個とも0になる

2023/04/30(日) 19:21:03.63

最後のカンマの次に項目を書かなくてもエラーにならなくなった名残だな

2023/04/30(日) 19:25:11.20

>>911
最後のカンマに文法上の機能はなく、単に余計なカンマを許容するだけ。
どちらも 0 がひとつ与えられる初期化子であるという扱いになる。
コードジェネレータで生成するときに余計なカンマを許容したほうが便利だからそうなってる。

初期化子の数が配列の大きさに足りない場合は >>913 の解説の通り 0 が補われるので10個の要素全部がゼロになる。
なので全部をゼロにしたいときは char str[10] = {}; というように書いてもよい。
(新しい規格では改定されているが) C では波括弧の中に 1 個以上の値を必要としたので
それに合わせて必ずひとつは 0 を書くというスタイルで書く人もいる。

**デフォルトの名無しさん** (JP 0H6b-zzYQ) · 2023/04/30(日) 19:26:34.51

丁寧な解説ありがとうございました。
どちらとも10個ともに０になるんですね

2023/05/01(月) 10:47:39.75

STLにある、k番目の要素を見つけるnth_element()は計算量がO(n）だそうですが、
これの中身が何をやっているかの日本語の（できるだけむずかしくない）解説ってどこかに
ありますかね?

2023/05/01(月) 11:27:54.04

選択アルゴリズムとかクイックセレクトでググれ

2023/05/01(月) 12:10:58.53

GPT-4の説明が分かりやすかった
std::nth_elementの説明として正しいかは分からんが
うまく動きそうではある
GPT-4に知らないことを聞くのはかなり危険だなぁ...

**青木康善** (ｱｳｱｳｳｰ Sa1b-zK5j) · 2023/05/03(水) 13:17:48.41

Javaより断然速いんでしょプラプラは。

2023/05/03(水) 13:57:16.79

チンチンプラプラ

2023/05/04(木) 05:42:07.54

>>920
C++で書きさえすれば速いとかは幻想
高速化のためのアイディアを考え甲斐があるのがC++

2023/05/04(木) 07:42:34.11

状況によってはJavaのほうが速いこともあるね

2023/05/05(金) 11:15:11.08

サブルーチン単位で見たらJavaやC#の方が早いこともあるけどそれはC++側のコードが糞なときだからな
マネージド言語はループ回すにしても強制的に一々長さチェック入ったりするので本気出したC++にはいずれにせよ敵わない

2023/05/05(金) 11:37:06.46

昔、JavaでもC++同等性能出せます(ただしメモリ使用量は10倍)
みたいなネット記事を見たのを思い出したわ

2023/05/05(金) 11:57:14.32

そんなの実際はほぼないだろ
ありうるとしたらC++のコードは最適化がかからないでC#は最適化掛かってsimd使ってましたとかじゃないのか？

2023/05/05(金) 12:23:29.18

メモリの管理やチェックもしてくれた上で条件によっては C++ を超えることもあるってくらいなら充分以上に速くはあるけどな。

2023/05/05(金) 12:44:08.47

>>926
C#の場合はコードジェネレーターが発達してきてるからC++はprintfで動的フォーマット、C#はprintfをジェネレーターで静的展開みたいなパターンで後者の方が早いという事があり得る
jsonのパースやシリアライズとか特に

2023/05/05(金) 13:09:57.48

そこら辺は自作すればどうとでもなる

2023/05/05(金) 14:28:48.55

x86ターゲットでビルドしたC/C++プログラムをARMでx86エミュレーション実行すると遅い
Java/.NETは中間コードだからランタイムさえARM版になっていれば性能が出せるね

2023/05/05(金) 15:39:52.77

それはエミュレータの性能では?

2023/05/05(金) 15:46:51.10

C/C++はコンパイル時に命令が決まるから中間コードよりビルド済バイナリの長期運用では不利になるよね
ソースコードからリビルドできる環境があれば問題ないんだけどさ

2023/05/05(金) 15:52:51.36

ARMをリビルト出来ない環境とは？

2023/05/05(金) 15:55:40.50

環境なんて開発者それぞれでしょ
Macbook使ってるけどx86エミュレーションで動いてるアプリがいくつかあるんだよ
開発者さんがまだM1/M2を持ってなくてARMビルドがリリースできてないんだと思う（もしくは飽きて開発放棄してるのか）

2023/05/05(金) 16:00:19.83

とにかく既存バイナリを異なるCPUアーキテクチャで動かす状況が現実にあるわけ
Macに限らずWindowsでもね
そのような状況では.NETアプリは軽快にどうさするのにC/C++アプリは遅いということになる

2023/05/05(金) 16:10:23.07

めちやくちゃだな
C++の開発環境にハンデ付けたらそうなるわ

2023/05/05(金) 16:16:39.25

Javaや.NETの中間コードにしてCPU命令セットに依存させないアプローチはポータビリティだけでなくランタイムごとの最適化を可能にするメリットがあるの
これC/C++では無理でしょ

2023/05/05(金) 16:22:19.51

ランタイムが対応していない環境ではC++の勝ちだな

2023/05/05(金) 16:47:17.33

C++のスレで「ネイティブなバイナリはエミュレータ上で遅い」って主張して何の意味があるのか？
場違いなこと言ってないか少し考えような

2023/05/05(金) 17:09:02.02

>>935
Apple文化ではCPUが変更されるが、Windows/Intel文化ではデスクトップでは
変更されたことが無い。PC/AT互換機はずっとx86系。

2023/05/05(金) 17:10:06.81

「C++は速い」って盲目的に信じてるキッズの目を覚ます意味がある

2023/05/05(金) 17:10:53.16

ターゲットを限定できる組み込み系開発ならともかく
一般消費者向けのアプリではC/C++が最速とは限らないという話だよ

2023/05/05(金) 17:15:38.26

仮想化やエミュレーションを何重にも重ねて実行するのが当たり前の現代的コンピューティングでは
「ネイティブで速い」なんて限定的な状況での一つの特長にすぎないんだよね

2023/05/05(金) 17:20:08.41

>>940
マイクロソフトは異なるCPUアーキテクチャに挑戦し続けてきたよ
そもそもNTのマイクロカーネルアプローチは様々なCPUアーキテクチャに対応するためのものだった
Alpha、PowerPC、IA-64で動作するWindowsが過去には存在した
既存のx86バイナリを動かせなかったことから失敗してしまったけどね
今はARM Windowsに挑戦中
これはMac同様にx86エミュレーションで既存バイナリを動かせるようにしてる

アプリ開発者としてターゲット環境を1つに限定すると不利になっていく思うよ

2023/05/05(金) 17:27:05.17

>>942
C言語はUnixをマルチターゲットで実現するするために作られた言語である件について：

プログラム作成にいくら手間がかかっても良いという話なら
#ifdef / #else　/ #endifの山でマルチターゲットに配慮しつつ高級アセンブラ的に使用したときのC言語が
中間言語実行または中間言語からのJITで巻けるシチュがわからん
説明できるんならkwsk、

2023/05/05(金) 17:31:37.61

そうではなくてプログラム作成の手間も込みの話なら
特定の応用においてErlangがC言語に勝った話は有名な話
https://ipsj.ixsq.nii.ac.jp/ej/?action=repository_uri&item_id=12&file_id=1&file_no=1

やが、C言語で書かれたオープンなErlanｇのVMでそのパフォーマンスをたたき出した場合、
何の言語が勝ったことになるんじゃ……

2023/05/05(金) 17:33:05.29

>>945
それは既に説明したよ
C/C++が想定したターゲットに対して最適なバイナリを出力できるのは事実
でも既存バイナリの長期運用では最適な速度を出せない状況に遭遇することがあるんだ
実際にM1/M2 MacやARM Windowsでそういう状況が生まれてる

2023/05/05(金) 17:38:21.35

>>947
>C/C++が想定したターゲットに対して最適なバイナリを出力できるのは事実
>でも既存バイナリの長期運用では最適な速度を出せない状況に遭遇することがあるんだ
話が矛盾している
既存のVM（これも既存バイナリのうち）がなんで常に最適な速度を出せることになるんdai？