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/07(水) 15:34:18.88

ハゲの上塗り

2022/12/07(水) 15:34:20.23

いいから相手にしない
もう飽きたよ

2022/12/07(水) 15:42:19.49

>>579
じゃあParlスレでは適切だったねでもいいよ
皆お前さんの言ってることぐらい分かってる

2022/12/07(水) 17:13:38.78

謝るのに>>313のような態度で許されるとでも思っているのか

2022/12/07(水) 19:28:34.64

まーだやってるw

2022/12/07(水) 20:15:26.67

病気だよ

2022/12/07(水) 20:48:27.45

そもそも >>313 は Perl での呼び方の話で配列 ≠ ハッシュの話じゃないから謝罪なんてしてない
わざとなのか混乱してるのか知らんけど病的なのは間違いない

2022/12/08(木) 08:19:28.46

>>576
そこにPerl界隈でも使ってないとか言う奴が現れて無駄に反論を呼んだ。

2022/12/08(木) 08:34:20.66

今日はParl Harbor攻撃から81年目に当たるらしい

2022/12/08(木) 10:11:41.48

>>590
とりあえずそれはなんとか収まったけどその後配列 ≠ ハッシュ君が粘着しだした

2022/12/08(木) 10:26:23.30

煽り耐性なさすぎなハッシュ君
ちょっとカマかけると元気にお返事しやがんのｗ

終わりにしたいなら反応しなきゃいいのに
わざわざ出てくるマゾ野郎ｗ

2022/12/08(木) 12:19:06.63

ハッシュの話をするやつはコテハン付けろ。NGするから。

コテハン無しでハッシュを話題にするのは禁止な。

2022/12/08(木) 12:45:20.88

カマなんてかけてもないのに頓珍漢レスしてるキチに言われてもねw

2022/12/08(木) 13:41:50.14

反応してる時点でおまえ悔しさがにじみ出てるからｗ
こっちは誰が何と言おうと絶対に揺るがない基礎理論に基づいているから安心してアホにできてオモロイだけ

2022/12/08(木) 14:56:30.96

「C++」が「Java」を抜いて3位に--12月のTIOBEプログラミング言語ランキング - ZDNet Japan
https://japan.zdnet.com/article/35197053/
Liam Tung （Special to ZDNet.com）翻訳校正：編集部 2022-12-07 11:32

2022/12/08(木) 15:02:28.31

今更流行る理由があるのか
AI?

2022/12/08(木) 16:44:45.46

多次元配列クラスのSTL入りもまだなのにAIｗｗｗｗｗｗｗｗｗｗｗｗｗ

2022/12/08(木) 16:45:49.30

＞C++の人気が高まる一方で、Javaの人気は低下している

2022/12/08(木) 18:04:41.79

今更メモリー管理したくないよぉ

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 でたどれる順番