C++相談室 part162

**sage** (ﾜｯﾁｮｲ fbf0-ofdD) · 2022/10/31(月) 14:29:35.57

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

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

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

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

2022/12/08(木) 18:10:36.30

>>600
Objective-C（29位から19位に）
みたいな不思議ランキングなんだから、あんまり意味無いんじゃない？

2022/12/08(木) 18:26:03.92

>>601
したくないけどする必要があるときには C++ くらいの機構があるとやりやすいんじゃろ。知らんけど。

2022/12/08(木) 18:33:45.11

デストラクタが無い言語とか論外じゃね？

2022/12/08(木) 19:14:03.24

基礎理論w

2022/12/08(木) 19:42:03.83

欧米の知的な人たちの間でC++が流行ってるんだろ。

2022/12/08(木) 19:43:41.79

したくないというポイントはだいたい稼げるところだな

2022/12/08(木) 20:48:03.13

インテリ
ジェンス

2022/12/10(土) 04:54:52.93

まぁゲーム開発はいつまでもC++だからなぁ。ついでC#

2022/12/10(土) 12:17:36.89

UIはその時の流行りの言語で書くけど戦術ロジックだけは絶対にC++で書きたい

2022/12/10(土) 12:26:15.44

C#って、むしろ大規模になって来ると意味不明なエラーが出て破綻しないか？

2022/12/10(土) 14:59:01.80

C#が悪いわけではないけど、メモリー解放とかルーズにしたままある程度コード書けちゃうからね、、、
大規模になってくると無頓着だったメモリー解放が火を吹く感じはある

C++はそんなルーズな書き方してたらすぐ破綻するから、そういうコードは多くないけど初期の実装には多くの時間がかかる感じ

2022/12/10(土) 15:38:10.95

c#のプロジェクトはなんか疎結合になっとらんこと多いわ

2022/12/10(土) 17:52:23.34

プロジェクトを分割しようとしてもどうにも分離しきれない絡み合った部分ってあると思うんよ。
そういうときは機能別に分割するというだけではなく絡み合った部分は絡み合ったものとしてレイヤとして切り分けると上手くいく。
面倒くさいところは一か所に押し込めて横に切る感じ。

C# のプロジェクトはレイヤで分ける意識が希薄で縦割りばかりするので分離しきれない結合が全体にうっすらと残ってる感じ。
密結合というほどではないけど全体にうっすらなので、面倒くさい箇所が一か所にまとまってるよりしんどい。

というのが私の印象。 C# のことはあんまり知らんけど。

2022/12/10(土) 18:06:38.22

https://ideone.com/gopFXn
なんか100回転してから落とすコード書いたはずがヘンな事になってる。
間違ってたかな？向こうのバグかな？？

2022/12/10(土) 20:25:28.70

DのUpdateみると1000ms待たないと終わらないように見えるけどそれはいいの？

**ハノン** ◆QZaw55cn4c (US 0H9b-JdnI) · 2022/12/10(土) 20:33:03.87

>>614
トップダウン、ボトムアップ、両面から書いていったとき、それが出会うところでグダグダなその場しのぎのコードに書かざるを得ない経験はありますね

2022/12/10(土) 20:33:20.22

#include <iostream>

int main() {
const int i = 1;
++*const_cast<int*>(&i);
std::cout << i;
}

何が表示されると思う？
違法？合法？

https://wandbox.org/permlink/57h9V6JX7fJes663

2022/12/10(土) 20:55:46.09

>>618
const なオブジェクトに書き込むのは許されない (未定義) が型の上で const を外すだけならアリ。つまり ++ を除けば合法だが ++ のせいで違法。

2022/12/10(土) 21:19:19.36

int main() {
const int i = 1;
int*j =const_cast<int*>(&i);
*j=2;
std::cout << &i<<" "<< j<<std::endl;
std::cout<<i <<" "<< *j;
}

https://wandbox.org/permlink/DC1E3ycea3UtdBAI

0x7ffc53e76e1c 0x7ffc53e76e1c
1 2

上のやつちょっといじってみた
アドレスの値同じなのに値違うんだけどなんでなんだろ

2022/12/10(土) 21:23:07.71

そりゃ未定義動作だもの
鼻から悪魔が出なかっただけありがたいと思え

2022/12/10(土) 21:57:24.92

その処理系ではconst_castはコンパイラをごまかす宣言ではなく&iというオブジェクトを作ってるんだろう

2022/12/10(土) 22:07:20.11

コンパイル時にiが1に置き換えられてるだけだろう

2022/12/10(土) 22:23:55.76

それだけじゃ&iの動作について言及が足りない感じ

2022/12/10(土) 22:36:19.38

多分
　const int i = 1;
を受けた最適化の結果、
　std::cout<<i
が
　std::cout<<1
という意味のコードになったとかじゃないの
逆アセして調べると良い

2022/12/10(土) 22:38:11.75

あるいは真にiの値を見たいのなら
　...（前半は同じ)...
　auto *p = (volatile int*)&i;
　cout << i << " " << j << endl;
みたいにするとか？
※ 個人の感想です

2022/12/10(土) 22:38:50.72

まつがえたorz
あるいは真にiの値を見たいのなら
　...（前半は同じ)...
　auto *p = (volatile int*)&i;
　cout << *p << " " << j << endl;
みたいにするとか？
※ 個人の感想です

2022/12/10(土) 23:00:40.51

未定義動作をどうしようとコンパイラの自由なんだからそんなもの調べたってしょうがない
ちゃんと書けばいいだけのこと

2022/12/10(土) 23:01:50.82

既に
std::cout << &i<<" "<< j<<std::endl;
により&iとjが同じ値であることは示されてる

auto *p = (volatile int*)&i;
これでも同じアドレスとして解釈されている（試した）

きっとconst_castに限らずconst領域のアドレスを解釈する時点で
ここのコンパイラは別領域を確保するんだな

2022/12/10(土) 23:07:18.20

そのcoutに出してるコードも含めて未定義動作なんだから出力されるゴミ文字列には何の保証も意味もないぞ
だからちゃんとやれ

2022/12/10(土) 23:07:19.81

>>629
↓の間違いなのでは……
std::cout << &i<<" "<< &j<<std::endl
これが同じ値になるのなら、iとjが別の実体という仮説はむしろ棄却され、
鼻から悪魔が出たか、さもなくば>>625の説明ぐらいしか残らない

2022/12/10(土) 23:34:26.52

>>631
jの型はアドレスint*やで

iと&iが別実体と解釈されてないとこの処理系の挙動は説明できないよ

2022/12/11(日) 00:20:42.40

>>632
左様かｽﾏﾝｶｯﾀorz

今神のお告げがあったが多分
>iと&iが別実体と解釈されてないとこの処理系の挙動は説明できないよ
というのは
>変数iとcout << の引数としての定数1が別実体と解釈されてないとこの処理系の挙動は説明できないよ
と考えたら>>625と同じ……

2022/12/11(日) 00:25:27.26

>>633
iが最適化後定数だろうとconst変数だろうと&iについての説明が必要だし
>>625を否定してるわけじゃないよ
>>625のうえで&iがどう処理系で実装されているのかという話

2022/12/11(日) 00:29:21.03

あーごめん>>634は取り消し

2022/12/11(日) 16:42:27.87

未定義動作ではいおしまいは思考停止では？
コンパイラの実装を考えてみるのも面白い

2022/12/11(日) 17:18:36.24

ゴミ捨て場の汚物の配置を面白がる趣味もいいけどそれで宇宙の真理を読み取ったとか言い出されても困るんだわ

2022/12/11(日) 17:28:44.13

特定のコンパイラの挙動が知りたいなら逆アセしろ
仕様が知りたいなら未定義動作

と言うだけの事だろ

2022/12/11(日) 19:27:20.67

未定義踏んで、たまたま望む動作だった場合に、それを放置するのは危険すぎる

2022/12/11(日) 19:44:01.28

前後の状況との組み合わせでも結果が変わったりするから短いコードで試しても
そのコンパイラでの挙動を知れたとは言えんし……。

2022/12/12(月) 02:44:59.90

挙動を考えるというか思想とか背景を考えるのが面白いんだよ
組み込みじゃconst領域は物理的に変えられない場合があるからって
余計な事考えちゃったけどたしかに>>625だろうなって

2022/12/12(月) 14:55:49.27

vector<string> v; の vを辞書順でソートした場合、string自体はメモリ上に
連続して並ぶが、肝心の文字列バッファは free store 上でバラバラに離れた
位置になるからキャッシュ・ミスし易くなるね。
stroustrup氏はリンクリストがキャッシュミスし易いと言って馬鹿にしていたが、
実際には動的配列(vector)でも大差は無い。
なお、リンクリストでキャッシュミスし易い典型例がソート後の全巡回ループ。
そしてその場合、vectorでもstringのようなメモリ資源ハンドルの場合は
キャッシュミスが免れない。

2022/12/12(月) 15:09:17.26

>>642
[補足]
そもそも、C++はcopyの代わりのmoveによる高速化を自慢しているが、
それが意味を持つのはstringのようにfree storeのメモリをポインタで持っている
ようなクラスである。
このご自慢のmoveが良く効くクラスTのvector<T>をソートした場合、
free storeの本当の中味のアドレスはソートされないまま。
なので、vectorを全巡回する時には、アドレスが飛びとびになり、キャッシュミス
が起き易い。

2022/12/12(月) 15:14:58.58

>>642 うんうん。リンクリストにするとキャッスミスし易さがもう少し悪化するね。

2022/12/12(月) 15:21:22.44

>>644
この例の場合、vectorをlistに変えてもあまり悪化しない。
なぜなら、stringとその文字列バッファが近接したアドレスのfree store
上にallocateされていると期待できるから。

2022/12/12(月) 15:26:03.32

>>645
[補足]
list<string> v2; の場合、push_back すると、
p1 = new string;
相当の事が実行されるが、p1 の内部の文字列バッファも、string のコンストラクタ
の中で
p2 = new char[N];
のようにして free store から確保される。
確率的には、p1 と p2 は非常に隣接したアドレスになっている可能性が非常に
高い。
その結果として、p1をアクセスした直後にp2にアクセスしてもキャッシュミスは起きない。
その結果、vector<string>とlist<string>のソート後の全巡回でのキャッシュミス回数は、
ほぼ同じ。

2022/12/12(月) 15:33:08.04

>>645 そうだね。悪化するのは少しだけだね。
おや？ >>642 ではバラバラに離れてキャッシュミスしやすいと言っていた文字列バッファが
リンクリストの話になると近接するのかい？不思議だねぇ。

2022/12/12(月) 15:34:37.69

典型的な用途ではsmall-string optimizationで大部分が連続になるでしょ
リンクリストにその恩恵はない

2022/12/12(月) 15:37:07.44

>>647
>おや？ >>642 ではバラバラに離れてキャッシュミスしやすいと言っていた文字列バッファが
>リンクリストの話になると近接するのかい？不思議だねぇ。
ソートしたときには、stringと対応する文字列バッファは意味論的には
くっついている。だから、「対応している」両者は隣接しているんだ。

2022/12/12(月) 15:39:41.84

>>649
[補足]
vector<string>をソートすると、stringの「箱」が新しく確保されてしまうので、
中身だけがmoveされるので、stringと対応する文字列バッファは「離れ離れになる」
list<string>をソートすると、stringはアドレスは全く変化せず、string同士の
リンクのされ方だけが変化するだけだから、stringと対応する文字列バッファは、
メモリー空間上でのアドレスの隣接を維持する。

2022/12/12(月) 15:40:54.03

>>648
それはstringだけの話。
今回はstringを例にとって話しただけで、一般のTではそんな現象は起きない。

2022/12/12(月) 15:49:40.91

>>650
[補足]
vector<string>のソート後の様子:
アドレス
0x0000: st100 ---> buf100 (st100とbuf100のアドレスは離れ離れ)
0x0010: st5 ---> buf5 (st5とbuf5のアドレスは離れ離れ)
st100とst5は隣接する。
ソート時に中身のアドレスだけがmove。

list<string>のソート後の様子:
st100 ---> buf100 (st100とbuf100は隣接したまま)
st5 ---> buf5 (st5とbuf5は隣接したまま)
st100とst5は隣接しない(但し、元のアドレスを維持したまま)。
ソート時には、一切のmoveもcopyも全く発生せず。

2022/12/12(月) 22:25:35.59

いちいちキャッシュのことまで考えて書いたことなんかないですねえ

2022/12/12(月) 22:29:51.34

天才ですから

2022/12/12(月) 22:53:10.09

ソート済みならソートの利点を生かしたデータアクセスが主だろうからなあ
まあ最悪値を考えるかアベレージを考えるかはプログラム次第か

2022/12/12(月) 23:33:02.97

キャッシュミスが起きるとか
キャッシュに収まりきらない要素数のリンクリストを
全要素まんべんなくアクセスし続ける場合とかの話であって
そうなれば区々たるデータ構造などあんま意味を成さなさげ

2022/12/13(火) 06:29:45.20

>>656
だからお前のコードは遅いんだな

2022/12/13(火) 07:27:28.93

配列とハッシュの話を蒸し返すけど、キャッシュに退避したデータを取り出す仕組みはハッシュなので、配列も無意識・無自覚のハッシュといえる

2022/12/13(火) 07:49:45.53

トホホｗ

2022/12/13(火) 09:16:15.65

プログラムのフェッチもハッシュ、ライトもハッシュ、全てはハッシュに収束するのだ

2022/12/13(火) 09:37:04.67

ありていにいえば、他のレイヤーのデータを参照する時にハッシュを使わないと処理速度が落ちてしまうので、いたるところに速度対策でハッシュ参照が実装されているってのがFA

2022/12/13(火) 09:54:38.28

仮にunordered_vectorなるものがあったにしても、それはハッシュではない

2022/12/13(火) 10:16:13.34

それunordered_setじゃね

2022/12/13(火) 10:32:20.10

vectorはそもそもunorderdだろ
setは同じ値を格納できないのだからvectorとは違う

2022/12/13(火) 11:27:12.09

全文字列を結合したものを一括で確保して string_view を操作するのが1番パフォーマンス良さそう

2022/12/13(火) 11:41:42.04

>>665
失礼な言い方になるかもしれませんが、あなた初心者ですね
“パフォーマンス”を気にする人はそもそもC++なんて使いませんよ

2022/12/13(火) 11:47:57.08

>>666
そんなに苦手だったんか
まあこれから練習したらええよ

2022/12/13(火) 12:02:52.82

パフォーマンスを気にする人は何を使うんでしょうか

2022/12/13(火) 12:10:16.41

>>664
意味わからん
気がふれた？

2022/12/13(火) 14:54:36.88

>>669
え？w

2022/12/13(火) 16:20:37.61

>>670
vectorがunorderedとが頭おかしいのかって

2022/12/13(火) 16:36:06.63

えっ？？？

2022/12/13(火) 16:50:01.90

>>669
c++のunorderd_は挿入時に挿入要素のキーによるソートが行われず要素の格納順が実装依存なコレクションに付けられている名称だから、vectorがunoreded_かどうかと言えばyesじゃない？

2022/12/13(火) 16:51:40.89

vectorがorder性持ってたら逆に困る

2022/12/13(火) 17:09:14.84

intkeyのorderedmapってことか

2022/12/13(火) 17:26:33.26

>>675
そういう考え方もあるか
でもiteratorで途中指定してinsertしたらそれ以降のキーと要素の対応全部ずれるしmapと考えるのはどうなんだ

2022/12/13(火) 17:27:23.47

ランダムアクセスできるデータ構造でordered_だのunordered_だの定義してもこじつけでしかないし意味薄いんでは

2022/12/13(火) 18:15:32.74

てす

2022/12/13(火) 18:20:36.37

そんな事を言い出したらページアウトされてるデータの読出しになるかもしれないからディスクアクセスかもしれないだろ

2022/12/13(火) 18:25:37.11

>>673
格納順を定義しろ

2022/12/13(火) 18:29:09.49

ふざけたオレ定義はトコトン馬鹿にしてやんよ

2022/12/13(火) 18:32:26.52

>>680
iterator でたどれる順番

2022/12/13(火) 18:35:45.77

>>680
ところでこの話の発端のhashでないunorderd vector ってどんなものをイメージしてたの？

2022/12/13(火) 18:46:51.67

>>681
まずはお前の定義を書け

2022/12/13(火) 18:50:59.76

>>682
今、屋台で酒飲んでるから後でな

2022/12/13(火) 18:55:09.41

>>673
vectorは連続したメモリ領域に要素を保存し、順番に並ぶことを保証する。

そうやってc配列との互換性を保っているのは常識かと思っていたけど、仕様変わったの？

2022/12/13(火) 19:04:10.54

>>686
それで正しいと思うよ
c++のunorderd_/(ordered_)は要素をキーにしてコレクションがソート済みになるかどうかを意味してると考えれば>>673とも矛盾してないでしょ？

2022/12/13(火) 19:20:14.84

ordered_配列 ==> 勝手に中身がソートされる配列
が思い浮かぶ

2022/12/13(火) 19:23:38.37

>>688
std::multiset なんてのがあるんだな

2022/12/13(火) 19:24:14.15

そもそも、ordered かどうかは定義の問題。
まず、mapは、(key,value)を持っていて、keyで検索できる。setは、keyだけでvalueが無いが、
keyで検索できる。setは、mapでvalueをkeyにしたようなもの。だから、以下ではmapだけ
の話をする。
mapやunorderd_mapは、「検索」機能とbegin(),end() を利用した「巡回機能」の
両方を持っていて、巡回を key の大小関係順に巡れるかどうかで、
ordered かどうかが決まる。
バランス木(赤黒木など)を使う方が接頭辞なしの map、ハッシュ法を使う方が
unorderd_map
前者の場合は、常に自動的に並び替えられた状態で格納される。
一方、そもそも vector は、好きな順序で入れられて決まったキーもなければ
自動的に並び替える機能も持ってないし、orderedかどうかを定義しても
特に意味が無い。そもそも、orderdのvectorが存在し無い。
また、故意に作ってもしょうがない。

2022/12/13(火) 19:26:29.60

ordered, unordered
が書けないヤツが多すぎ問題

2022/12/13(火) 19:27:00.39

実は全部同じ人？

2022/12/13(火) 19:28:42.74

>>688
それが大体、「set」や「multiset」に相当する。

2022/12/13(火) 19:28:56.13

巡回機能って何

2022/12/13(火) 19:37:41.71

>>694
まだ使ったことが無いので書き方が間違ってるかも知れないが、
map<T,V> m;
に対して、
for ( auto &r : m ) {
　cout << r.first << ":" << r.second << "\n";
}
で巡ることができる機能の事を言ったつもり。
for ( auto i = m.begin(); i != m.end(); ++i ) {
　cout << m[i].first << ":" << m[i].second << "\n";
}
と等価だと思う。
ただし、一度も使ったことが無い。

2022/12/13(火) 20:16:44.72

>>693
全然処理量のオーダーが違う
0点

2022/12/13(火) 21:45:11.86

keyとしてpointerを指定したmapがpointeeで正しくソートできるように
3番目のテンプレート引数にpointerを剥がして比較するless演算子を
以下のように渡します
g++ではm1は-std=c++17では不可ですが-std=c++20だと通ります
m1にはcomparatorの型しか情報を渡しておらず
m1は実装に関しては何も知らないはずなのですが
正しくpointeeでソートしますなぜ?

#include <iostream>
#include <memory>
#include <map>
using namespace std;
int main ()
{
using Ptr = shared_ptr <int>;
auto comparator ([] (const Ptr &lhs, const Ptr &rhs) {return *lhs < *rhs;});
using Map = map <Ptr, int, decltype (comparator)>;
// Map m0 (comparator); // -std=c++17と-std=c++20で可
Map m1; // -std=c++17で不可, -std=c++20で可
m1.insert (make_pair (make_shared <int> (2), 2));
m1.insert (make_pair (make_shared <int> (1), 1));
m1.insert (make_pair (make_shared <int> (3), 3));
for (const Map::value_type &key_value: m1)
cout << key_value.first << ' ' << key_value.second << '\n';
return 0;
}

2022/12/13(火) 22:04:34.09

>>697
C++20でキャプチャ指定のないラムダ式がデフォルトコンストラクタを持つようになったからかな
https://ja.cppreference.com/w/cpp/language/lambda

2022/12/13(火) 22:11:52.14

>>698
なるほどー!

2022/12/13(火) 22:27:14.40

納得しちゃダメだった
ラムダ式の型は実装ごとに異なるみたいですね
以下__cxa_demangleがg++依存だけども
#include <iostream>
#include <memory>
using namespace std;
namespace abi {
extern "C" {char *__cxa_demangle (const char* __mangled_name, char* __output_buffer, size_t* __length, int* __status);}
}
string name_of (const type_info &p)
{
int status (0);
char *tmp (abi::__cxa_demangle (p.name (), 0, 0, &status));
string result (tmp);
free (tmp);
return result;
}
int main ()
{
using Ptr = shared_ptr <int>;
auto c0 ([] (const Ptr &lhs, const Ptr &rhs) {return *lhs < *rhs;});
auto c1 ([] (const Ptr &lhs, const Ptr &rhs) {return *lhs > *rhs;});
cout << (typeid (c0) == typeid (c1)) << '\n';
cout << name_of (typeid (c0)) << '\n'
<< name_of (typeid (c1)) << '\n';
return 0;
}
$ g++ -std=c++20 test.cpp
$ ./a.out
0
main::{lambda(std::shared_ptr<int> const&, std::shared_ptr<int> const&)#1}
main::{lambda(std::shared_ptr<int> const&, std::shared_ptr<int> const&)#2}

2022/12/13(火) 23:32:00.27

>>697
> m1にはcomparatorの型しか情報を渡しておらず
> m1は実装に関しては何も知らないはずなのですが
ここが思い込みかと。
ラムダ式のクラス型に比較関数が含まれてて、その内容もインスタンスに依存しないし、
比較方法は十分伝わってるから問題ないということで何も不思議じゃないと思う。