C++相談室 part149

**デフォルトの名無しさん** · 2020/02/18(火) 06:19:41.54

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

前スレ
C++相談室 part148
https://mevius.5ch.net/test/read.cgi/tech/1580471646/
このスレもよろしくね。
【初心者歓迎】C/C++室 Ver.105【環境依存OK】
http://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/ (日本語)

**デフォルトの名無しさん** · 2020/02/28(金) 01:16:02.14

for(size_t i=0,l=0;i<全体の長さ;i+=l){
l=data[i]<<8 + data[i+1];
for(size_t j=0;j<l;++j) {
printf("%02.2X ",data[i+j]);
}
printf("¥n");
}

**デフォルトの名無しさん** · 2020/02/28(金) 01:21:12.05

l=... + ...
じゃなく... | ...

**デフォルトの名無しさん** · 2020/02/28(金) 01:25:11.44

ありがとうございます。
bit演算させて%02Xで表示させるんですね。

%02.2X　は　%02X　になりますか？

**デフォルトの名無しさん** · 2020/02/28(金) 01:28:52.77

.2はいらなかった

**デフォルトの名無しさん** · 2020/02/28(金) 01:31:26.71

うまく表示できました！
今勉強中で助かりました。
ありがとうございました。

**デフォルトの名無しさん** · 2020/02/28(金) 08:17:52.68

>>275
いえいえ、お礼なんか要りませんよ

**デフォルトの名無しさん** · 2020/02/28(金) 14:55:15.47

また行き詰ったので教えてください。。
http://codepad.org/YzpjTJeN

上記コードで3つわからないことがあります。
(1)itemsリストを作り、構造体のITEM_A, ITEM_B, を追加していく
そもそも構造体の中身が違うものを一つのリストに追加できるのか不明。
(2) itemsに動的にリスト追加
(3) itemsのリストをfor()で1要素づつ表示させる
※(1)(2)がわかれば(3)は自分でもわかるとは思いますが。

どのように書けばよいかわかりますでしょうか？

**デフォルトの名無しさん** · 2020/02/28(金) 15:06:55.04

itemの数が膨大にあり速度がほしいので、リストに追加するところは先に個数を確保したいのですが、0xEEまで精査しないと何itemあるのかわからないので、vectorで動的追加しかないかなと思っています。
emplace_backだとpush_backよりは多少速い？

**デフォルトの名無しさん** · 2020/02/28(金) 15:56:05.44

>>277
ITEM_AとITEM_Bってtypeの値が違うだけで同じ構造体で良いような気がするが…

**デフォルトの名無しさん** · 2020/02/28(金) 16:36:45.32

>>268
ダンプするだけか。

**デフォルトの名無しさん** · 2020/02/28(金) 17:40:47.76

vector使うかどうかよりも、毎回raw領域確保するほうがよっぽど問題と思うよ。
dataは何処かにおいておいて、rawにコピーせずに場所だけ指し示すようにしたほうがいい。
いずれにしても、計測なき最適化は害悪。

**はちみつ餃子** ◆8X2XSCHEME · 2020/02/28(金) 17:47:29.10

>>277
データの塊はどこかに置いたままにしておいて
イテレータで切り分けるスタイルで書いてみた。
https://wandbox.org/permlink/4D5XbHG7S1cw3fAL

**デフォルトの名無しさん** · 2020/02/28(金) 18:14:07.42

新型肺炎COVID-19は人工的に作られたともそうでないとも言われている。
プログラマの意図しないバグを含むプログラムを公開してしまったとしたら、そのプログラムは人工的ではないと言えるのか？

**デフォルトの名無しさん** · 2020/02/28(金) 18:17:18.92

人工の定義は？

**はちみつ餃子** ◆8X2XSCHEME · 2020/02/28(金) 19:23:47.33

>>277
少しだけ >>282 を改良。
僅かに速度も速くなってるかもね？
https://wandbox.org/permlink/7AuMCemoXRudfFmt

**デフォルトの名無しさん** · 2020/02/28(金) 19:55:10.54

このプログラムの最終目的はなんなんだろう
作ったitemsリストは表示するだけじゃなくて後で別の目的に利用するのかな

**デフォルトの名無しさん** · 2020/02/28(金) 20:34:59.53

std::stringをkeyにして作成されたstd::mapからfind関数を用いて検索する際に、
std::string_viewを利用して検索をかけたいのですが可能でしょうか？
もしくはstd::string_viewを利用して検索する方法等はあるのでしょうか？

**デフォルトの名無しさん** · 2020/02/28(金) 21:36:33.76

色々ご意見ありがとうございます。

>>279,280,281
後出し情報で申し訳ありませんが、バイナリファイルを読み込んで
そのバイナリデータの途中に別のレコードを追加したり、
削除したり、文字列置換したり、
といったことを行い、最後にファイルに書き出そうと考えています。

>>286
ご推察の通り、データを読み込んで一部を加工したファイルを出力しようとしていました。

>>282,285
サンプルコードありがとうございます。
ふんだんにc++の文法が使われているので、作っていただいたサンプルコードを今調べているところです。。
まだc言語レベルの記述しか理解できていないので。
とりあえずイテレータ部分を調べています。

加工しやすいように一度内部で数値や文字列に変換したdatabaseを作り、それに対し追加、削除、文字列置換などの加工をしてファイルに出力する。
というフローを考えていましたが、みなさんのご意見を参考にファイル出力するときに加工しながら出力する方式で検討してみようと思います。

**デフォルトの名無しさん** · 2020/02/28(金) 21:40:11.81

>>287
型をmap<K,M>の代わりに
map<K,M,std::less<>>にしておく

**デフォルトの名無しさん** · 2020/02/28(金) 22:23:20.74

>>288
> そのバイナリデータの途中に別のレコードを追加したり、
> 削除したり
と言うことならvectorよりlistの方がいいと思う

**デフォルトの名無しさん** · 2020/02/28(金) 23:38:48.68

>>290
ご意見ありがとうございます。
listがいいと思うのは任意の位置に挿入したりできるから。
ということでしょうか？

**はちみつ餃子** ◆8X2XSCHEME · 2020/02/29(土) 01:31:35.79

C++ は C と互換性があって C の延長線上でも使えるのが利点だとは C++ の設計者自身も言ってるけど、
C の延長線上で使ってたらやっぱり C の延長線上な設計になっちゃうと思うんだよなー。
その延長線を伸ばしていっていずれ C++ の習得に至る (あるいは至らなくてもよい) 、みたいな想定らしいんだけど、
今となっては C から C++ の距離がデカすぎる気がしてる。

だからどうするのが良いという意見はないのでぼんやりした感想でしかないけど。

**デフォルトの名無しさん** · 2020/02/29(土) 01:51:00.65

今や互換性があるというよりも使いやすいFFIがあるって認識のがメジャーだろう。

**デフォルトの名無しさん** · 2020/02/29(土) 04:10:54.37

>>277
codepadはC++03だったと思うが、03では構造体のメンバの=によるデフォルト初期化は
（static constな、配列でない組み込み型を除いて？）許可されてない
ので14が使えるideoneになるけどとりあえず最低限動くようにした
https://ideone.com/1RUIfn

どうしても03じゃないと困るなら直す
あとRuntime Errorって出るのは単にmainで1を返してるから（0にしたら直る）
特に関数の戻り値を使いもしないのに常にintにしてreturn (1)って書くのやめたほうがいいよ

>>292
＞今となっては C から C++ の距離がデカすぎる
そう思うなら余計な改変はしないでやれよ

**デフォルトの名無しさん** · 2020/02/29(土) 04:27:18.26

あ、そういえばバイト列全部持ってるから別にサイズ入れる必要無かった

**デフォルトの名無しさん** · 2020/02/29(土) 08:31:09.13

>>291
そう、
> itemの数が膨大にあり
の状況でvectorに挿入/削除したら死ぬ
> 速度がほしい
のに対してlistが最適かはわからんけどvectorより100倍マシ

**デフォルトの名無しさん** · 2020/02/29(土) 09:47:01.15

>>296

vectorについて調べてみました。

＞ttp://vivi.dyndns.org/tech/cpp/vector.html

上記に下記がありました。

＞insert() の処理時間は O(N) 。O(N) とは配列要素数に比例して処理時間を要するという意味。データ数が100倍になると、処理時間も100倍になる。
＞それに対して push_back() は O(1) なので、データ数がいくら増えても常に一定時間で処理が終わる。

大量のリストで先頭の方に挿入するとやばそうですね。
これは気にしていませんでした。
ありがとうございます。

**デフォルトの名無しさん** · 2020/02/29(土) 11:08:38.27

listは要素を手繰るのがクッソ遅いから、事前に挿入位置のノードのポインタを知っている状況でないといけないことに注意
毎回前からスキャンして挿入なんてやってたら結局O(N)でメモリアクセス効率がゲロ悪い分だけvectorより遥かに遅い

**デフォルトの名無しさん** · 2020/02/29(土) 11:23:57.34

C89とC2xの距離も大きくなってるけどな
あっちがこっちに寄ってきてるから

**デフォルトの名無しさん** · 2020/02/29(土) 12:12:18.31

>>298はなぜかvectorだと瞬時に検索できると思ってるw

**デフォルトの名無しさん** · 2020/02/29(土) 12:18:08.81

検索とかどこから出て来たんだ

**デフォルトの名無しさん** · 2020/02/29(土) 12:20:17.33

ていうかとりあえず組み上げてから実測した方がいいよ、似たようなことはすでに言われてるけど

**デフォルトの名無しさん** · 2020/02/29(土) 12:48:35.09

dequeにしてみれば

**はちみつ餃子** ◆8X2XSCHEME · 2020/02/29(土) 12:54:52.89

>>297
vector の方が先頭に追加するのが速いこともあるという観測データが有る。
https://cpplover.blogspot.com/2017/02/c-p0550r0-p0601r0.html
今時の機械は事情が複雑すぎて予想できない。
まず実測しろってよく言われているのはこういうこと。
やってみてからどこが効いてるのか調べた方がいい。

**デフォルトの名無しさん** · 2020/02/29(土) 13:18:08.51

>>300
少なくともlistに比べたら瞬時だね
さすがに挿入位置まで毎回スキャンしてたらlistに勝ち目はほぼ無いから、そこで突っかかるのはさすがに無理筋
listを擁護したいなら先頭への挿入か挿入位置のノードのポインタが既知のケースに話を限定しなさい

**デフォルトの名無しさん** · 2020/02/29(土) 13:53:20.08

>>305
> 少なくともlistに比べたら瞬時だね
えっ、何その魔法w

**デフォルトの名無しさん** · 2020/02/29(土) 14:00:40.18

挿入が主な目的な場合って普通はheap使うんじゃねーの？
あんまり任意の位置に挿入するってシチュエーションはないように思う。

**デフォルトの名無しさん** · 2020/02/29(土) 14:13:58.78

>>304
そういうこともあるんですね。
プログラムは難しい。

**デフォルトの名無しさん** · 2020/02/29(土) 14:38:39.67

>>307
heapからのメモリを繋ぎ合わせた集合体がリンクリストで、それがSTLでは
std::listになっている。

**デフォルトの名無しさん** · 2020/02/29(土) 14:41:54.28

>>298
Cでは、リンクリストを使って、ノードの位置を保持するためには、index値ではなく、ポインタ値を用いる。
STLでは、index値を前面に使う設計になっているのが問題。
元々、リンクリストは、ノードを巡るのは非常に高速。
ノードの位置をポインタで維持している限り「検索」作業は入らない。

**デフォルトの名無しさん** · 2020/02/29(土) 14:44:16.50

std::listには問題が有るかもしれないが、リンクリストというデータ構造自体は、文字列(string, CStringなど)のクラスを作るためなどをの一部の例外を除いては、動的配列よりもほぼ全面的に優れていると言っても過言ではない。

**デフォルトの名無しさん** · 2020/02/29(土) 14:45:35.17

本来は、Cの最も優れている点を言えといえば、そのリンクリスト一点と言っても過言ではない。

**デフォルトの名無しさん** · 2020/02/29(土) 14:49:01.60

>>310
stlでは、ノードの位置を維持するために、先頭を0として、0,1,2,... というような「連番」で管理しようとしてしまう。
そのために、リンクリストである所の std::listを使う場合、先頭から順番に「たどる」作業が必要になってしまい、>>298が言うような「クッソ遅い」現象が起きる。
しかし、それは、stlの設計のクソさによるものである。

**はちみつ餃子** ◆8X2XSCHEME · 2020/02/29(土) 14:59:22.48

>>313
> 「連番」で管理しようとしてしまう。

なんで？
std::list のイテレータは実質的にポインタだしそれで記憶しておくもんじゃないの？

**デフォルトの名無しさん** · 2020/02/29(土) 15:05:36.96

この前からヒープヒープ言う小僧がいるけど
普通ヒープといえば
- 木構造のヒープ
- ヒープメモリのヒープ
どっちだと思う？
おれは後者だけど

**デフォルトの名無しさん** · 2020/02/29(土) 15:11:14.78

文脈によらない「普通」なんてないだろ。
「ヒープ」と出てきたらどっちの意味で使っているのか注意しなきゃならない。

**デフォルトの名無しさん** · 2020/02/29(土) 15:32:56.54

>>314
そうなのか。
だとしたら >>298 が言っていたのはなんなんだ？

**デフォルトの名無しさん** · 2020/02/29(土) 15:34:53.49

順繰りたどらなくていいリンクリストってあるの

**デフォルトの名無しさん** · 2020/02/29(土) 15:40:33.93

下記のようにすると、最後にprintfしているときにはnameに値が入っていません。
set()を抜けたときに開放されてしまうのではと思うのですが、どうすれば保持出来ますか？
char* name;　のところを　char name;　にはしたくないと思っています。
mallocとかを使うのでしょうか？

class AAA{
public:
char* name;
};

int AAA::set(){
char temp_name[5];　　←ここで確保した変数がset()が終わると開放されてしまう？？
temp_name = "NAMAE";
name = temp_name;
return(1);
}

void main(){
AAA aaa;
aaa.set();
printf("NAME %s\n", aaa.name);
}

**デフォルトの名無しさん** · 2020/02/29(土) 15:44:30.24

>>298
例えばテキスト・エディタを作っている場合、ある一点Aに50文字を挿入する
というようなことがおきる。
この場合、50文字を挿入する前に、Aの場所のノードのポインタ値を求める。
カーソルの位置に挿入する場合には、最初からポインタ値を持っているようにしていれば「求める」必要は無い。
一度ポインタ値が分かった後は、50文字追加する際に挿入場所として必要なポインタ値は長々と最初から「たどる」ことなく分かる。

たどる場合も、各行の先頭のポインタ値をすべて保持するようにしておけば、まず行Yの先頭のポインタ値を見つけて、あとは、そこから列Xのポイント値を求めるための計算量は余り多くは無い。

このような場合、全てのデータをstd::vectorのような動的配列で保持しようとするのは基本的に速度が遅くなることが多いが、リンクリストは速度的に安定する。

**はちみつ餃子** ◆8X2XSCHEME · 2020/02/29(土) 15:44:56.46

>>317
vector と同じように考えるなってことを言ってるだけだと思うよ。

逆に vector では要素の追加とかがあった時にイテレータが無効になるので、
あまりイテレータで保持すべきではないという事情がある。
コンテナとして最低限度共通のインターフェイスが付いてるけど、
やっぱり内部の事情は意識しなけりゃなんねぇなぁという話。

**デフォルトの名無しさん** · 2020/02/29(土) 15:45:04.74

スコープ抜けたら当然解放されるよ
c++ならchar*じゃなくてstd::stringでも使った方がいいのでは

**デフォルトの名無しさん** · 2020/02/29(土) 15:48:52.44

>>320
例えばの話、要素数が多いような巨大なデータを動的配列で確保したとする。
この動的配列のトータルバイト数をW(バイト)としよう。
この配列の要素数が、本当の意味で増やす動作が入ったときには、メモリの容量が
一時的に 3*W(バイト)必要になる。
Wが実メモリのぎりぎりに入るくらい大きい場合には、仮想記憶が必要となりとても遅くなる。

一方、リンクリストだとそのようなことがない。

**デフォルトの名無しさん** · 2020/02/29(土) 15:50:57.05

>>321
後半部。
そういえば、vectorの場合、途中にデータを追加した場合、それより後ろのindex番号がずれてしまうので、その部分を指していた今までのイテレータは使えなくなってしまうのだね。

**デフォルトの名無しさん** · 2020/02/29(土) 15:53:18.38

>>318
構造的には存在しない。
リンクリストを使う場合、ノードを指し示すためには出来る限りindex値ではなくポインタ値を使うようにして
「順繰りにたどる」
必要が無いようにする必要がある。

**はちみつ餃子** ◆8X2XSCHEME · 2020/02/29(土) 15:57:30.04

>>324
それもあるけど vector は要素が連続しているという強い制約があるから場所が足りなくなったら再配置することがある。
realloc みたいなもん。

**デフォルトの名無しさん** · 2020/02/29(土) 16:02:26.57

いやポインタ使おうが無理でしょ...
リンクリストだとポインタ飛び飛びになるんだから辿らないと無理でしょ

**はちみつ餃子** ◆8X2XSCHEME · 2020/02/29(土) 16:06:46.92

>>327
もちろんどこかでは辿るが、辿った結果をインデックスとして保持してたらコストがデカいから
ポインタ (イテレータ) で保持することを心掛けてねっていう意味だと思うよ。

**デフォルトの名無しさん** · 2020/02/29(土) 16:10:08.53

それだと298のいってること理解できるはずなんだけどね
ようわからんわ

**デフォルトの名無しさん** · 2020/02/29(土) 16:11:07.92

>>327
「たどる」と言っても、隣のノードをたどる場合、コンパイル後のマシン語レベルだと、整数に1を足すのと同じか、その2回分程度のクロック数しか消費しない。
だから for 文で巡るときには、動的配列を巡るのと全く同じ程度しか時間が掛からない。

**デフォルトの名無しさん** · 2020/02/29(土) 16:12:14.35

>>329
恐らく、>>298 は、リンクリストの効率の良い使い方を知らないと思われる。

**デフォルトの名無しさん** · 2020/02/29(土) 16:13:48.55

この教科書読めレベルの話、いちいち議論する必要なくね？

**デフォルトの名無しさん** · 2020/02/29(土) 16:16:42.57

>>331
どうみても理解してると思うが
どこがおかしいとおもってるの

**デフォルトの名無しさん** · 2020/02/29(土) 16:17:00.93

全員が釣り師だと何もつれない。

**デフォルトの名無しさん** · 2020/02/29(土) 16:29:33.32

>>333
「事前に挿入位置のノードのポインタを知っている状況でないといけないことに注意」
この命題自体は正しい。
しかし、「ポインタを知っている状況ではない」という状況自体が、C言語流の
文化では滅多に起き得ないことだからだ。
恐らく >>298 を書いた人は、「ポインタを知っていない状況」が高頻度で起きる
ような書き方をしているからこそそのような注意を促したと感じる。
多分、C言語とは異なる文化に長く親しんだか、少なくともC流の文化に慣れずにいきなりC++から始めたかのどちらかだと思われる。

**デフォルトの名無しさん** · 2020/02/29(土) 16:31:36.11

>>335
または、ポインタが理解できないか、ポインタにアレルギーがあって、避けて通ってきた人かも知れない。
そういう人は多いらしい。
聞いた話だとポインタを全く使わずに配列だけでC言語を使っている人がいるそうだ。

**デフォルトの名無しさん** · 2020/02/29(土) 16:37:43.01

要はlistとvectorの違いは何で、なぜ必要かという文脈でいいのかな
listはfor文にi++入れないための単なる糖衣構文だと思うが
基本的に自分は糖衣構文は必要ない派です

**デフォルトの名無しさん** · 2020/02/29(土) 16:37:52.88

リンクリスト万能君も老害リストに追加だね
キャッシュヒット率低いし、64bitポインタの無駄もでかいし
メモリ空間異なるところもっていくときに全部作り直しだし
昨今はむしろ使えないデータ構造扱いされること多いから
c/c++を高速化のために使ってるならなおさら

**デフォルトの名無しさん** · 2020/02/29(土) 16:38:02.22

長文書いてる人は全員釣り師。

**デフォルトの名無しさん** · 2020/02/29(土) 16:40:06.91

>>338
測定すればすぐわかる事なのにね。
そもそも教科書は挿入に焦点を当ててるけど、検索のほうがよほど問題。
algorithmと極端に相性が悪い。
listを使う理由はイテレータの安定性のみ。

**デフォルトの名無しさん** · 2020/02/29(土) 16:45:07.46

>>340
測定だけでは見落とすことが有る。
測定しただけで std::vector の方が速いと思っている人は、数学的想像力が足りてない。

**デフォルトの名無しさん** · 2020/02/29(土) 16:47:16.55

>>341
だってキミ嘘しか書いてないやん。
最初から全部嘘だし。
どう見たって釣り師。

**デフォルトの名無しさん** · 2020/02/29(土) 16:48:55.39

>>342
恐らくIQが高いので一般プログラマはついてこれない。

**デフォルトの名無しさん** · 2020/02/29(土) 16:49:11.83

はいもう釣り堀は終わり。

**デフォルトの名無しさん** · 2020/02/29(土) 16:55:50.08

高IQの人と一般の人とは話が通じ合わない。

**デフォルトの名無しさん** · 2020/02/29(土) 17:09:06.31

はいこのおじいちゃんの毎度の捨て台詞いただきました

**デフォルトの名無しさん** · 2020/02/29(土) 17:16:14.77

> algorithmと極端に相性が悪い。
> listを使う理由はイテレータの安定性のみ。
とか書くような奴もどうかと思うわ

**デフォルトの名無しさん** · 2020/02/29(土) 18:09:51.88

嘘つくやつって特有の変なプライド持ってるよな。

**デフォルトの名無しさん** · 2020/02/29(土) 19:24:46.81

話者に対してレベルが低過ぎる人には話が嘘か間違いにしか聞こえない。

**デフォルトの名無しさん** · 2020/02/29(土) 19:55:24.32

嘘つきがレベル高いってのは
赤軍派の暴力事件が相次いでいた頃の
共産主義＝インテリのステータスだった時代の
今となってはもうみんな気付いている茶番とインテリぶったやつらが
真っ赤な最高学府で安々と洗脳されたバカばっかりだったという
お笑いぐさのやつだね

**デフォルトの名無しさん** · 2020/02/29(土) 19:57:19.47

動的配列より全面的に優れているって何かのギャグなの？w

**デフォルトの名無しさん** · 2020/02/29(土) 21:20:16.71

>>336
Cに慣れた人間がリンクリストを好む傾向があるのは、
動的配列が一段抽象化層を設けないと扱いづらいのに対してリンクリストはCの自然な構文で生のままで扱いやすいからだよ
君自身も君が馬鹿にしている「癖」に縛られているんだ

◆QZaw55cn4c · 2020/02/29(土) 21:49:19.01

>>349
仮に IQ が存在するとして、 IQ に差があるのならば、IQの低い受け手はIQの高い話し手の発する全情報を解釈するのに困難を感じることは確かにあり得るとは思いますが、
「嘘か間違いにしか聞こえない」というのは、IQの差だけでは説明できないと思います
IQの低い私の体験としては「わからない」とはいつでもよく感じていたりするのですが、それでも「嘘だ」「間違っている」とは普通は考えませんね

**デフォルトの名無しさん** · 2020/02/29(土) 22:20:21.84

リンクリストって今時のCPUにとって非常に性能上扱いづらいものだからねぇ

順繰りにたどっていく場合に先読みがしづらい
実体を指すポインタの配列なら2つ先、3つ先のアドレスまでキャッシュに載っているから、プリフェッチが効いて必要になる頃にはキャッシュにロードされてる感じになる

**デフォルトの名無しさん** · 2020/02/29(土) 22:36:08.55

>>345
ここにはお前と話が通じない一般人しかいないから、お前と話ができる人がいるどこかよそに行った方がお互い生産的だと思うぞw

**デフォルトの名無しさん** · 2020/02/29(土) 22:37:49.26

>>354
デタラメ書かない

**デフォルトの名無しさん** · 2020/02/29(土) 22:40:10.33

>>356
デタラメではないでしょ
キャッシュヒット率意識するのは大事

**デフォルトの名無しさん** · 2020/02/29(土) 22:51:13.30

プリフェッチとか色々ごっちゃになってる
断片的な知識で知ったかしようとして失敗してるパターン

**デフォルトの名無しさん** · 2020/02/29(土) 23:22:00.98

要素アドレスが連続した領域に書き込まれている場合は、
コンパイラがループアンローリングして次の要素アドレスロードしてその参照先のプリフェッチ命令挿入することが可能
ってのを場合によっていくつか先まで出来る
リンクリストの場合はこうはいかない
次の要素のロードが終わらないと次の次の要素のアドレスが分からんのだから

**デフォルトの名無しさん** · 2020/02/29(土) 23:24:07.69

インテルCPUの場合はプリフェッチ入れなくても投機的にプリフェッチされてたからこそ、例の脆弱性が問題になってた

**デフォルトの名無しさん** · 2020/03/01(日) 01:43:44.70

実装法を理解できてないために効率よい使い方を間違っている人は遅さをすぐにキャッシュせいにしてしまう。

**デフォルトの名無しさん** · 2020/03/01(日) 01:49:59.33

>>355
まあそうだが、それだとおまえら一般人はいつまでたってもアホなプログラミングしかできないだろうな。

**デフォルトの名無しさん** · 2020/03/01(日) 01:55:38.98

>>362
俺の人生経験からすると、現実には本当に馬鹿な人にはいくら言っても無駄なようだが。
いくら言っても理解できないし、強く何度も言うと、逆に明らかに絶対やっては駄目なときでもいつもそればっかりやってしまうようになったりする。
なので周りはむしろ困ることになる。

**デフォルトの名無しさん** · 2020/03/01(日) 02:04:09.13

cppreferenceを含めてネットでは std::vector ばかり使われているのは、大部分のプログラマがポインタを理解できないのでリンクリストも理解出来ておらず、使いこなすことが出来ないためと踏んでいる。
正しく理解できないためにstd::listを使うと悪い使い方しかできないため、彼らの実験の仕方ではいつもstd::vectorより遅くなってしまう。
そのような人には、C++を使ってもC#以上の速度を出すことは困難で、だからこそ一般プログラマとそれ以下の人材しか集めることの出来ない多くのプロジェクトでは C#やJava,Rubyなど簡易言語が好まれて使われるようになっていると予想される。
俺とは住む世界が違うので、このことは推定に過ぎないがな。

**デフォルトの名無しさん** · 2020/03/01(日) 02:29:46.23

uint64_t　の型から　unsigned char　の型に変換するにはどうすればよいですか？
同じ4バイトなのでどうにかすれば変換できるのではと思っているのですが。

**デフォルトの名無しさん** · 2020/03/01(日) 02:30:41.70

間違えました。
unsigned charは4バイト確保すれば同じバイト数になる。ですね。

**デフォルトの名無しさん** · 2020/03/01(日) 03:40:24.38

そのマシンのエンディアンの通りに格納したんでいいなら
uint64_t a;
unsigned char b[4];
reinterpret_cast<uint64_t &>(b) = a;

**デフォルトの名無しさん** · 2020/03/01(日) 05:10:36.30

std::vectorばかり使われる最大の理由は、C言語における配列と互換性を持つ唯一のコンテナだからでしょ。

**デフォルトの名無しさん** · 2020/03/01(日) 05:48:12.89

64ビットって4バイトなのか？というつっこみ

**デフォルトの名無しさん** · 2020/03/01(日) 07:40:13.71

あ、そういえば・・・w