C++相談室 part143

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/06/15(土) 13:51:53.57

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

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

このスレもよろしくね。
【初心者歓迎】C/C++室 Ver.105【環境依存OK】
https://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/ (日本語)

----- テンプレここまで -----

VIPQ2_EXTDAT: default:vvv:1000:512:----: EXT was configured

**蟻人間** ◆T6xkBnTXz7B0 (ﾜｯﾁｮｲ) · 2019/07/03(水) 21:55:07.11

中学レベルの問題が直感で分かるような自称天才は、問題を見るとすぐ答えがわかるから、自分が天才・神童だと思い込む。
しかし、複数の変数が絡む数式になると直感は外れるようになる。だから、考える努力をしない自称天才は高校くらいで落ちぶれる。

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/03(水) 22:05:55.22

>>372
リスト・配列の特性、真ん中あたりの要素の削除の計算量などは、情報処理資格の内容にある

C++ は最高難易度の複雑さだから、さすがに資格を持っていない香具師は、門前払い！

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/03(水) 22:07:27.64

>>559
まあよくあることだわ。
扱いには困るが。

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/03(水) 22:11:09.39

std array使わないで生配列推奨する意味がわからない

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/03(水) 22:26:30.32

どのようにプログラミングしても、vector には勝てない！
真ん中あたりの要素の追加・削除で、大量の要素がズレても、それでもvector が有利！

だから素人は、vector を使っておけばよい

リストは、ランダムアクセスできない。
常に線形探索だから、O(n)

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/03(水) 22:29:53.07

>>564
お前はRubyだけ弄ってればいいよ

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/03(水) 22:30:37.31

>>563
記述が少ない

**蟻人間** ◆T6xkBnTXz7B0 (ﾜｯﾁｮｲ) · 2019/07/03(水) 22:32:11.35

allocaもいいぞ。

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/03(水) 22:43:27.14

Rubyのしくみ、2014
Rubyの実装系、Ruby1.9のRuby仮想マシンの本に書いてあるけど、

Rubyでは、Hashの要素数が増えていくと、再編成される

バケット数は、2の累乗付近の素数を使う。
つまり、倍々に増やしていく
8+3, 16+3, 32+5, 64+3, 128+3, 256+27, 512+9...

1つのバケットには、平均して5つの要素を入れる(衝突)。
11*5=55, 19*5=95, 37*5=185...

つまり要素数が、56, 96, 186...個になると、
バケット数を増やして、再編成する

普段、1万個の要素を追加するのに、8msかかるが、
再編成するタイミングでは、20msかかる。
要素数が増えていけば、もっとかかる

10万個なら200ms、100万個なら2秒と、再編成があるたび、ドンドン増えていく

**デフォルトの名無しさん** (ﾌﾞｰｲﾓ) · 2019/07/03(水) 22:47:35.04

>>563
std::arrayはサイズで型変わるから
そこが面倒なこともある

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/03(水) 23:06:06.02

>>558
違う。
vector は、最悪、a*N*sizeof(TYPE) + (制御情報サイズ) だ。
listは、常に、N * ( sizeof(TYPE) + ポインタサイズ * b ) + (制御情報サイズ) だ。
aは、実装依存で、典型的には2。vectorを確保した直後を除いて1であることはない。
b は、1または2。

あなたのやったテストでは、vector を確保した直後だから、a=1になっていただけ。

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/03(水) 23:08:20.45

bが1ですむ可能性があるとかw

**デフォルトの名無しさん** (ﾌﾞｰｲﾓ) · 2019/07/03(水) 23:18:47.11

vectorとかlistとか初心者向けの話題いつまでやんの？
まさにパーキンソンの凡俗法則だな
天才様が主導してるわけだがw

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/03(水) 23:22:56.33

使用メモリって観点だと、realloc時は要素数の1+a倍だから、最悪値もそれになる
まあ、要素数の見積もりが全くできない状況でもaは容易に制御可能でcapacity見ながらreallocが起こる直前のpush_back前にreserveかけりゃ済む
最悪1要素ずつ拡張すればa~1
性能は最悪だがw

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/03(水) 23:26:03.86

参考書に答え書いてあるものを永久に語り続けるのおもろ

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/03(水) 23:42:03.45

std::list<std::string> lines;
std::string l;
while(std::getline(std::cin,l)){
lines.push_back(l); //(1)
//lines.push_back(std::move(l)); //(2)
}
だと(1)の方がいいよね
特に行内の文字数、行数が大きくなると速度差はかなり大きくなる。
stringじゃなく同様のvectorでも同じ
listだと(2)が速いだろうけど

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/03(水) 23:42:46.34

>>549
あなたの誘導に沿って説明しよう。
要素の型をTYPEとすると、要素の1つのバイト数を、E=sizeof(TYPE)であり、
それが、x 個ある場合を考える。
L(x) = H1 + x * (E + P * 2)　　// list に必要なバイト数
V(x) = H2 + x * E * 1.5　　　　// vector に必要なバイト数
となっている。
P は、ポインタ1つ当りのバイト数であり、Windows の 32BIT モードの時は、4 である。

これらの関数は、どちらも n に対する1次関数で、
グラフにすると、傾きはそれぞれ、
a_L = E + P * 2　　　// list の必要バイト数の傾き
　　= E + 8
a_V = 1.5 * E　　　　// vector の必要バイト数の傾き
だ。

要素1つ辺りのサイズ E が十分大きい場合、たとえば、100バイトの時を考えれば、

a_L = 100 + 8 = 108
a_V = 1.5 * 100 = 150

となる。

だから、V(x)の傾きの方が、L(x) の傾きのよりも大きい。
だから明らかに V(x) の方が効率が悪い事になる。H1, H2 がどんな
値であれ、要素数 x が十分大きい場合にはメモリ効率の良さは
xに対するグラフの傾きで決まる。H1, H2 は、いわゆる「y切片」
を決めるだけで、x が大きい時には影響はなくなっていくから。

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/03(水) 23:43:59.85

>>576
[続き]
>>549 の最後の方は：

『listよりvectorの方がサイズが小さい』・・・・☆
と同値な条件は、
H1 + n * (E + P * 2) > H2 + n * E * 1.5　　・・・・(1)
⇔
n * (P * 2 - E * 0.5) > H2 - H1　　・・・・(2)

である、というところまでは正しい。ところが、中学校で習ったように、
不等式では、両辺を負の数で割るると、不等号の向きが逆になってしまう。
だから、割る数が正か負かを気をつけないといけない。
今、E = 100, P = 4 だから、
(P * 2 - E * 0.5) = 4 * 2 - 100 * 0.5 = 8 - 50 = -42
となり、負の値である。E が1000や10000の場合は、どちらも
もっと絶対値の大きな負の値となる。だから、この部分は要素のサイズ
が十分大きいと必ず負の値である。ゆえに、(2) をこの数で割ると、
n < (H2 - H1) / (P * 2 - E * 0.5)　　・・・・(3)
となり、あなたの書いた式とは不等号の向きが逆となる。

さて、この(3)の意味は、右辺の値は、Eの値が100の場合は、分母は負の値であるが、
分子の H2-H1 の値は実装依存なので、右辺全体としては、正か負かも定まらない。
そこで、右辺の値を R とおくと、n < R という式になる。
この意味は、ある値 R よりも要素数 n が小さいと、この式が成立する、
ということである。この式は、あなたが書いたように、
☆と同値な式である。だから、ある値 R よりも要素数 n が小さいと、
☆が成立することを意味している。つまり、要素数が十分小さいときに
のみ「list より vector のサイズが小さい」のである。逆に、
要素数が十分大きければ、「list より vector のサイズが大きい」
ことが言える。

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/03(水) 23:44:44.32

もういいってしょうもない話

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/03(水) 23:45:33.05

数学得意とか言うわりに内容が中学生レベルなのをわざわざ説明するとか

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/03(水) 23:45:34.35

>>576
誤：これらの関数は、どちらも n に対する1次関数で、
正：これらの関数は、どちらも x に対する1次関数で、

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/03(水) 23:48:05.25

>>579
ここにいる人たちが、懇切丁寧に説明しないと分かってくれないからだよ。

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/03(水) 23:50:03.60

3行以下にできないなら説明しなくていいです・・・

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/03(水) 23:53:56.60

メモリ容量が厳しいときにreserveしないなんてあり得ないし、Typeがでかく、要素数不明なときにそのままvectorに放り込むとかも普通しないよね

それこそスマポとか使ってでもlist使わない方がましな場合が殆んど

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/03(水) 23:54:04.68

>>582
数学や科学の世界は、簡潔に説明なんか出来ないんだよ。
だから、簡潔を望む人は科学や数学には向いてない。

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/03(水) 23:54:50.78

（自分が知っている部分だけ）懇切丁寧に説明しないと
＝知らない部分は無視して天才どうのこうので議論を拒否する

説明した部分に疑問持ってるレスどれ？

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/03(水) 23:55:01.46

ヒント：ここは5ch

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/03(水) 23:58:40.02

大体が生配列とvectorの比較だったわけだが、なんで可変長でのメモリ使用でlistと比較しているんだ？

vectorじゃなく生配列使うべき有意な優位性を説明しろと

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/03(水) 23:59:40.90

>>583
要素数と要素のサイズが大きいとき reserve()するのに時間がかかる。
昔から知られているが、リンクリストだとその手の作業が必要ないので、
速度とメモリの両方の効率がバランスが良い。

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/04(木) 00:04:14.98

そもそも、最大限使えるメモリ容量から計算してreserveしておけば、listよりより多くの要素数格納できるんだな。

listの場合malloc的なものの管理領域も大きくなるってのも、メモリ厳しい場合には無視できない

**デフォルトの名無しさん** (ﾌﾞｰｲﾓ) · 2019/07/04(木) 00:04:37.74

>>560
行列がわからない自称上級者の蟻さん、ﾁｰｯｽ

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/04(木) 00:05:06.10

>>587
生配列に必要なバイト数：
A(x)=E * x
vector に必要なバイト数
V1(x) = H2 + 1.5 * E * x　　　// 平均時
V2(x) = H2 + 2 * E * x　　　　// 最悪時

これらをみるだけでも、生配列の方が効率がいい事が分かる。
要素を書き込む時にも、生配列は典型的には1クロック。
vectorだと、境界チェックが入るので5クロックくらいは必要となる。
境界チェックは条件 jump なので、パイプライン類の乱れが生じ
だいぶ遅くなることが有る。

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/04(木) 00:05:27.97

listとvectorの違いなんて皆わかった上で議論しているのに天才さんはバカなの？
最近アルゴリズム入門書でも読んで語りたいだけなの？

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/04(木) 00:08:18.15

>>589
それもあるが、reserve()は時間がかかるので、扱うデータが巨大な場合には、
無駄が多くなるのと、reserve()するまでの最悪時には2倍の領域が必要となる事が
メモリ用件が厳しいときには問題となることも有る。
ただし、listにもデメリットは有る。それは、1要素を追加するときに new されるので、
典型的には150クロック程度の時間がかかってしまうことだ。

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/04(木) 00:08:37.45

容量既知なら配列との差は管理領域とヒープが別になるオーバヘッドだけ

ヒープが別になるってのを責めて来るならまあ分かるが、容量既知なのに全くその情報使わない最悪値で比較とかセンス無さすぎ

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/04(木) 00:10:31.88

>>592
このスレの99%の人が分かってない。

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/04(木) 00:11:56.58

size 0でのreserveは別に時間かからんだろ
それこそlistで要素追加でnewされるの1回分と大差ない

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/04(木) 00:15:07.03

MATLABで演算するときforループを使って一つずつ計算するよりもsumやmeanなどの関数を行列に対して行う方が圧倒的に速いのですが
C++にもMATLABのように一括で高速に行う方法がありますか？

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/04(木) 00:17:08.19

>>593
なお、要素が、サイズが小さくて、かつコンストラクタを持たないような
単純なデータだとreserve()の時間が list の (150 * 要素数) (クロック)
よりも短いことも少なくて済む事もあるが、サイズが600バイトを超えたり、
要素の中に、newして持っているデータがあるような場合があったりする
場合や、要素のコンストラクタが重い作業を行うには、reserve()は、
listよりも遅くなる。

だから、要素が今後のプログラミングの過程でどんなものになるか分からない場合には、
listは安定した速度が維持できるが、vectorはだんだん遅くなっていく恐れが有る。

**デフォルトの名無しさん** (ﾌﾞｰｲﾓ) · 2019/07/04(木) 00:19:04.81

クロックとか言ってるやつもロートルだな
全く世の技術についていけてない

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/04(木) 00:19:14.34

>>597
ない

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/04(木) 00:19:40.29

>>596
「>>598」にも書いたが、要素のサイズが大きい場合や、要素のコンストラクタの
重い場合には、reserve()はとても遅くなる。要素のコンストラクタの中で
メンバの確保やコピーのためにnewが1つでも行われる場合には、listよりもほぼ必ず
遅くなる。コンストラクタ内のnewがN個だとlistのN倍遅くなる。

**デフォルトの名無しさん** (ﾌﾞｰｲﾓ) · 2019/07/04(木) 00:21:13.94

ハイパフォーマンス必要なとこでlistなんか使わないからど素人さん

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/04(木) 00:25:40.63

>>601
それに、reserve()のためには、一般的には、要素は、コピー・コンストラクタを
持つ必要がある。一方、listの場合には、コピ・コンを省略できる。
C++を使っていると分かるが、デフォルト・コンストラクタを作ることはほぼ必須
だが、コピ・コンはめんどくさいので書きたくないことが多い。その場合に、
listの方が楽。

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/04(木) 00:26:45.21

>>602
vectorとreserve()の組み合わせはもっと駄目だ。

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/04(木) 00:27:30.60

forward_list
とか知らないんだろうな
バカそうだし

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/04(木) 00:31:07.37

>>601
要素既知の配列と同様の用途の場合、まともなスキルのあるプログラマなら、サイズ指定constructor、empty状態でのresize、empty状態でのreserve
のいずれかを使う。
そうするとmalloc一回と、前者二つは要素数分の要素型の配置newデフォルトもしくはコピーconstructorが呼ばれる。

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/04(木) 00:31:14.53

>>604
お前の頭中、vectorかlistしかないのなw
もとの生ポ押しはどうしたの？w

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/04(木) 00:36:08.58

vector相当にcapaciry()+xなreserve相当をするCArrayってのがあってだな
MS自身がどうしてもこれじゃなきゃ駄目な場合以外使うなと言うくらいの糞

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/04(木) 00:36:47.68

>>606
要素数既知なら、最速が TYPE aaa[N] で次が new TYPE[N]。
逢えて vector を使う意味がない。

empty状態の reserve() とかしてまで vector にこだわる意味が分からない。

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/04(木) 00:38:37.52

>>607
むしろ逆で、生配列使えばいい場面で、何故か vector に固執する人がいるんだよ。

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/04(木) 00:39:15.33

どこにそんな人居たの？
レス番あげてよ

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/04(木) 00:48:01.35

サイズ完全固定ならstd::array
最大サイズが既知なら少し無駄だがvector
格納領域内包する最大サイズ指定のvector擬きがあればベストなんだが

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/04(木) 00:51:39.87

後はサイズが大きくてスタック上に確保したくない時もvector使うだろ。

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/04(木) 00:53:59.44

>>613
その場合は、TYPE *pAaa = new TYPE[N];

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/04(木) 00:56:53.06

まだやってるのかw

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/04(木) 01:00:33.98

>>614
それ最悪
例外安全性放棄ほぼ確定

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/04(木) 01:02:18.21

自称天才すげーな
自分が何かいてるのか分かってないんだろうな
規格も読んでなさそう

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/04(木) 01:05:54.39

>>614
てか今時こんなコード書く奴いたら、できうる限り関り合いにならないようにするね。

こんなのが先輩面して新人に教育してたらもう最悪

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/04(木) 01:21:19.34

>>618
あなたは、C++とC#の速度が変わらないと思ってる系統の人だよね。

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/04(木) 01:21:50.22

>>597
ベクトル演算とか、並列処理とか

OpenCL, CUDA とか

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/04(木) 01:52:09.26

shared_array はまだ標準化されてないんだね。

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/04(木) 02:32:03.47

たぶんこのおっさん例外安全って何かわかってないw

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/04(木) 02:56:32.67

>>622
std::array を使うと例外安全が確保されて、
TYPE *pArr = new TYPE[N];
だと確保されないと思うのはなぜ？

絶対に確保できないと言い切れる根拠でもあるの？

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/04(木) 02:58:14.89

>>623
誰がヒープ回収するねん...

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/04(木) 03:00:26.38

とりあえずnewとかmake_sharedとかIDEがなくても型が明らかな場合はauto使おう

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/04(木) 03:00:52.24

>>624
「ヒープを回収する」
とはどういう意味か分からない。

メモリ確保の失敗は大体回復不可能なはずなんだけど、どうするつもりなの。

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/04(木) 03:01:53.76

「メモリ確保に失敗したこと」のメッセージを出す以外に対処法はないと
思うんだけど。

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/04(木) 03:16:52.36

なんでnewで例外起こる話しているんだか
本当に全くわかっていないのね

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/04(木) 03:47:53.77

どうでもいい話はやめて今までにない新しい画期的なテクニックの話をしてくれ
頼む
一生のお願い

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/04(木) 05:48:37.09

>>549
> n * (P * 2 - E * 0.5) > H2 - H1.
> n > (H2 - H1) / (P * 2 - E * 0.5).
> となる。
(P * 2 - E * 0.5)がマイナスだと不等号が逆転するのを忘れている
3 > 2 の両辺を-1で割ると -3 < -2

2019/07/04(木) 07:22:01.27

>>629
そんなテクニックはここに書かない

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/04(木) 08:41:24.64

>>626
newの例外の話なんてしてしてません。
本当にレベル低いやっちゃな

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/04(木) 08:52:16.87

TYPE *pArr = new TYPE[N];
と同じスコープ内(のdelete pArrの前)で例外が発生した場合に
>>624
>誰がヒープ回収するねん...
という話ですな

**デフォルトの名無しさん** (ｽｯｯﾌﾟ) · 2019/07/04(木) 09:10:15.58

また話それたのかｗ
ポインタもコンテナも結局都合の悪いレスはスルーしてるからこうなる

**デフォルトの名無しさん** (ﾌﾞｰｲﾓ) · 2019/07/04(木) 09:34:14.60

こいつC++98で時間止まってるからな
20年かけてSTLコンテナの使い方学んで
その結果がvectorよりlist、それ以上に生ポインタが最強って結論
どうせ40代おっさん低収入だろうけど、自分を天才と呼び、
数学ががどうのこうの言うわり、単なる足し算掛け算をどや顔でさらすし、
本当読んでて可哀想になってくる

**デフォルトの名無しさん** (ﾌﾞｰｲﾓ) · 2019/07/04(木) 10:15:53.90

要素数固定ってコンパイル時に固定の意味と実行時にある値に決まるって意味があると思うけど
前者では T Arr[N]
後者では　std::unique_ptr<T[ ],>
を使ってしまう。
それ自体をreturnしないときは std::array を使うのがかったるく感じてしまう

**デフォルトの名無しさん** (ﾌﾞｰｲﾓ) · 2019/07/04(木) 10:35:11.99

>>636
arrayはもうひと頑張りしないとだめだな。
宣言時に値を初期化するとき、値の数をテンプレートパラメータに手打ちとか
要素数省略できるCスタイル配列に負けてる

**デフォルトの名無しさん** (ｱｳｱｳｳｰ) · 2019/07/04(木) 11:36:25.81

>>637
c++17から推論補助が出たので要素数指定不要です。
c++14以前はmake_arrayとか作ればいける

**デフォルトの名無しさん** (ﾌﾞｰｲﾓ) · 2019/07/04(木) 11:42:55.77

でも std::begin std::end があるからスコープ内の単純な配列に std::arrayを使う
メリットがいまいちわからないんだよねー

**デフォルトの名無しさん** (ﾌﾞｰｲﾓ) · 2019/07/04(木) 11:55:46.77

begin endは普通の配列にも使えるだろ

**デフォルトの名無しさん** (ﾌﾞｰｲﾓ) · 2019/07/04(木) 11:56:48.16

>>638
おお、ほんまや。
かゆいところに手が届いて行くのぅ

**デフォルトの名無しさん** (ｽﾌｯ) · 2019/07/04(木) 12:06:11.23

template関数で受けたときにポインターにならないからauto lambdaで受けてもsizeがとれる

**デフォルトの名無しさん** (ﾌﾞｰｲﾓ) · 2019/07/04(木) 12:17:57.65

>>640
だから普通の配列を使ってしまうという話なんだが

**デフォルトの名無しさん** (ﾌﾞｰｲﾓ) · 2019/07/04(木) 12:19:43.85

>>642
その場合にはそうだね
でも関数に渡すとき大抵 begin end だからなあ

**デフォルトの名無しさん** (ｻｻｸｯﾃﾛ) · 2019/07/04(木) 12:49:15.77

>>642の言ってるのは配列の参照にキャストされないからだと思うんだけど(自分もそれが不便だと思う)
そのキャストを実装しない理由あるんかね？
中身ただの配列なんやろ？

**デフォルトの名無しさん** (ﾌﾞｰｲﾓ) · 2019/07/04(木) 12:50:55.35

>>643
変なところで改行するなよ

**デフォルトの名無しさん** (ﾌﾞｰｲﾓ) · 2019/07/04(木) 15:52:29.03

>>646
なるほどすまん
100人中98人位が誤解する改行だた

**デフォルトの名無しさん** (ｱｳｱｳｳｰ) · 2019/07/04(木) 17:29:10.64

構造体をchar配列にシリアライズする方法を教えてください

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/04(木) 17:31:04.99

memcpy

**デフォルトの名無しさん** (ﾜﾝﾄﾝｷﾝ) · 2019/07/04(木) 17:32:23.03

キャストしてぶっ込め
なお環境とアドレスによってはバスエラーが発生したりするよ

**デフォルトの名無しさん** (ｽﾌｯ) · 2019/07/04(木) 17:41:18.95

>>645
cとの互換性に起因した過去コードとの互換性保つために、配列を引数で渡そうとするとpointer渡しになるのだろう。
受け側でtemplate使ってT (&arr)[N]みたいに明示的に引き取らない限りは

c++20でstd::spanが使えるようになれば楽になるな。
それでも完全転送は通らないけど

**デフォルトの名無しさん** (ｱｳｱｳｳｰ) · 2019/07/04(木) 17:42:05.56

配置newで出来たりしますか？

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/04(木) 20:00:03.82

>>651
いや、受け側でそう書いても、普通の配列はいけても
arrayは通らないんだわ・・自分の書き方が間違ってるのかもしれんけど
https://wandbox.org/permlink/LBzgUfB6MRtk9P12

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/04(木) 20:05:01.64

使ってるコンパイラのArrayヘッダの実装見てそのメンバ変数名をしらべてそれを指定すれば通る

**デフォルトの名無しさん** (ｽﾌｯ) · 2019/07/04(木) 20:12:08.06

reinterpret_castならいけたけど未定義かどうかは知らん

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/04(木) 20:40:50.48

別に無理に通そうとしてるわけじゃないんだぜ
arrayの不備のひとつではないかな、ってだけ

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/04(木) 20:53:10.33

暗黙変換定義すれば出来るんだろうけど、出来ない方が自然な気がする

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/04(木) 20:54:01.06

>>636
以下コードがちゃんと動くの今知った。サンクス。
std::unique_ptr<Test[]> test(new Test[5]);

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2019/07/04(木) 21:48:13.92

確かに内部配列の参照を取得する手段はあってもいい気がする
先頭のポインタはdata()で取れるけど、配列型そのものへと読み替える手段って標準の範囲にはないんだな
ちょっと意外