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/06(火) 11:12:56.86

今や絶滅危惧種となったテキトーこくの嫌いな人

2022/12/06(火) 13:12:15.09

そういう人ここは比較的多いでしょ?

2022/12/06(火) 13:47:59.27

配列がハッシュだなんて裏も取らずに信じちまうやつもか？

2022/12/06(火) 14:38:33.85

テーブルのアクセスに使う添字はインデックス？キー？

2022/12/06(火) 14:47:42.28

サブスクリプト

2022/12/06(火) 15:21:19.75

>>554
まだいたのかよ、よほど悔しかったんだなw

2022/12/06(火) 15:50:10.05

信じてたやつが返事してるな
今度こそ別人ではあるまい

2022/12/06(火) 15:56:04.19

HDDを指さしてメモリと言ってたやつのほうがまだマシ
記憶装置という点でそんなに大外れではないからな

配列を指さしてハッシュと言うやつは
アメリカザリガニを指さして飛行機と言うようなもんで
どうやっても擁護不可能

2022/12/06(火) 16:49:16.67

>>496 にレスできないクズ乙w

2022/12/06(火) 17:07:58.34

美味しいという共通点くらいしか

2022/12/06(火) 18:13:06.65

ここは技術板
配列とハッシュを混同すること以上の恥もクズも存在し得ない

2022/12/06(火) 18:23:59.19

本人謝ってるのにしつこく絡むのは技術云々の前に人としてどうなの？

2022/12/06(火) 18:57:26.14

だれも謝罪してないし、配列もメモリマネージャーからみればハッシュだし

2022/12/06(火) 19:27:21.71

>>564
> ただ今勉強中で頓珍漢なこと言ってしまった、すいません
クズにはこれが謝罪に見えないんだな...

2022/12/06(火) 19:41:58.07

EASTLは、unordered_mapに相当するクラスを独自実装しhash_mapと呼んできた経緯がある
Perlの専門用語が他言語に持ち込まれた分りやすい例といえるだろう

2022/12/06(火) 21:47:51.22

>>565
何？　謝罪したらこんなに恥をかかずに済んだってとこに、まだすがりたいの？
そりゃそうだろうね、技術板で最大の恥をさらしたんだからｗｗｗ

おまえ悪態つきすぎたんだよ、こっちも悪意に満ちた対応するからな
もう覚悟するしかねえんだよ、おまえｗ

2022/12/06(火) 21:59:01.18

粘着恥ずかしいw

2022/12/06(火) 22:07:01.02

C++使いは、その程度のことで粘着しない。
なぜなら、C++使いは爺だから。

2022/12/06(火) 22:59:17.33

>>519
あんま細かいこと拘るとハゲるからな

2022/12/06(火) 23:00:17.17

レス誤爆ﾒﾝｺﾞ

2022/12/06(火) 23:03:05.74

爺こそ粘着するのでは？
暇だから

2022/12/06(火) 23:07:03.02

インテリ爺は粘着される方だろ。

2022/12/07(水) 06:03:51.56

unordered_mapはハッシュを使うというだけで、それ自体がハッシュだという主張は誤り
好意的に解釈してもデータメンバと継承を混同するようなもの

2022/12/07(水) 07:45:49.40

>>571
メンゴって…

2022/12/07(水) 11:52:13.93

まだハッシュ言ってるのか
Parl界隈で使ってる言い回しなんだねこのスレで使うなら合ってなかったねで終わる話やろ

2022/12/07(水) 11:59:24.24

経緯を詳細に見る気もしないんだが話は展開していないし
執着の仕方が常軌を逸していると思う
初出は11/24（>>227）だよ! 2週間

2022/12/07(水) 13:47:36.67

粘着自体は無視スルーすれば良いからどうでもいいわ
それより将来鯖ログ開示されたとき
誰と誰が自演だったかの答え合わせはしてみたい

2022/12/07(水) 14:06:40.54

>>576
このスレでじゃねえよ
配列とハッシュは本質が異なるものだ

>>319 >>383で根本的な説明している

2022/12/07(水) 14:09:36.34

病的だな

2022/12/07(水) 14:42:14.43

誰も興味ないわ

2022/12/07(水) 15:26:40.34

>>576
> Parl界隈で使ってる言い回しなんだねこのスレで使うなら合ってなかったねで終わる話やろ
それを言ってるならまだ分からないでもないけど配列 ≠ ハッシュなんて本人謝ってるのにしつこく絡み続けてる
そんなことでしかマウント取れないんだろうけどマジでなんかの病気だと思うわ

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ではそんな現象は起きない。