C++相談室 part149

■ このスレッドは過去ログ倉庫に格納されています
1デフォルトの名無しさん
垢版 |
2020/02/18(火) 06:19:41.54ID:xvjipUWj
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/29(土) 15:44:30.24ID:ZbPwrBbB
>>298
例えばテキスト・エディタを作っている場合、ある一点Aに50文字を挿入する
というようなことがおきる。
この場合、50文字を挿入する前に、Aの場所のノードのポインタ値を求める。
カーソルの位置に挿入する場合には、最初からポインタ値を持っているようにしていれば「求める」必要は無い。
一度ポインタ値が分かった後は、50文字追加する際に挿入場所として必要なポインタ値は長々と最初から「たどる」ことなく分かる。

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

このような場合、全てのデータをstd::vectorのような動的配列で保持しようとするのは基本的に速度が遅くなることが多いが、リンクリストは速度的に安定する。
2020/02/29(土) 15:44:56.46ID:WzbNfV7+
>>317
vector と同じように考えるなってことを言ってるだけだと思うよ。

逆に vector では要素の追加とかがあった時にイテレータが無効になるので、
あまりイテレータで保持すべきではないという事情がある。
コンテナとして最低限度共通のインターフェイスが付いてるけど、
やっぱり内部の事情は意識しなけりゃなんねぇなぁという話。
2020/02/29(土) 15:45:04.74ID:HY2ZFlSm
スコープ抜けたら当然解放されるよ
c++ならchar*じゃなくてstd::stringでも使った方がいいのでは
2020/02/29(土) 15:48:52.44ID:ZbPwrBbB
>>320
例えばの話、要素数が多いような巨大なデータを動的配列で確保したとする。
この動的配列のトータルバイト数をW(バイト)としよう。
この配列の要素数が、本当の意味で増やす動作が入ったときには、メモリの容量が
一時的に 3*W(バイト)必要になる。
Wが実メモリのぎりぎりに入るくらい大きい場合には、仮想記憶が必要となりとても遅くなる。

一方、リンクリストだとそのようなことがない。
2020/02/29(土) 15:50:57.05ID:ZbPwrBbB
>>321
後半部。
そういえば、vectorの場合、途中にデータを追加した場合、それより後ろのindex番号がずれてしまうので、その部分を指していた今までのイテレータは使えなくなってしまうのだね。
2020/02/29(土) 15:53:18.38ID:ZbPwrBbB
>>318
構造的には存在しない。
リンクリストを使う場合、ノードを指し示すためには出来る限りindex値ではなくポインタ値を使うようにして
「順繰りにたどる」
必要が無いようにする必要がある。
2020/02/29(土) 15:57:30.04ID:WzbNfV7+
>>324
それもあるけど vector は要素が連続しているという強い制約があるから場所が足りなくなったら再配置することがある。
realloc みたいなもん。
2020/02/29(土) 16:02:26.57ID:HY2ZFlSm
いやポインタ使おうが無理でしょ...
リンクリストだとポインタ飛び飛びになるんだから辿らないと無理でしょ
2020/02/29(土) 16:06:46.92ID:WzbNfV7+
>>327
もちろんどこかでは辿るが、辿った結果をインデックスとして保持してたらコストがデカいから
ポインタ (イテレータ) で保持することを心掛けてねっていう意味だと思うよ。
2020/02/29(土) 16:10:08.53ID:HY2ZFlSm
それだと298のいってること理解できるはずなんだけどね
ようわからんわ
2020/02/29(土) 16:11:07.92ID:ZbPwrBbB
>>327
「たどる」と言っても、隣のノードをたどる場合、コンパイル後のマシン語レベルだと、整数に1を足すのと同じか、その2回分程度のクロック数しか消費しない。
だから for 文で巡るときには、動的配列を巡るのと全く同じ程度しか時間が掛からない。
2020/02/29(土) 16:12:14.35ID:ZbPwrBbB
>>329
恐らく、>>298 は、リンクリストの効率の良い使い方を知らないと思われる。
2020/02/29(土) 16:13:48.55ID:VpO1O9GW
この教科書読めレベルの話、いちいち議論する必要なくね？
2020/02/29(土) 16:16:42.57ID:HY2ZFlSm
>>331
どうみても理解してると思うが
どこがおかしいとおもってるの
334デフォルトの名無しさん
垢版 |
2020/02/29(土) 16:17:00.93ID:/L84OmpW
全員が釣り師だと何もつれない。
2020/02/29(土) 16:29:33.32ID:ZbPwrBbB
>>333
「事前に挿入位置のノードのポインタを知っている状況でないといけないことに注意」
この命題自体は正しい。
しかし、「ポインタを知っている状況ではない」という状況自体が、C言語流の
文化では滅多に起き得ないことだからだ。
恐らく >>298 を書いた人は、「ポインタを知っていない状況」が高頻度で起きる
ような書き方をしているからこそそのような注意を促したと感じる。
多分、C言語とは異なる文化に長く親しんだか、少なくともC流の文化に慣れずにいきなりC++から始めたかのどちらかだと思われる。
2020/02/29(土) 16:31:36.11ID:ZbPwrBbB
>>335
または、ポインタが理解できないか、ポインタにアレルギーがあって、避けて通ってきた人かも知れない。
そういう人は多いらしい。
聞いた話だとポインタを全く使わずに配列だけでC言語を使っている人がいるそうだ。
2020/02/29(土) 16:37:43.01ID:MKbmJ2zo
要はlistとvectorの違いは何で、なぜ必要かという文脈でいいのかな
listはfor文にi++入れないための単なる糖衣構文だと思うが
基本的に自分は糖衣構文は必要ない派です
2020/02/29(土) 16:37:52.88ID:VpO1O9GW
リンクリスト万能君も老害リストに追加だね
キャッシュヒット率低いし、64bitポインタの無駄もでかいし
メモリ空間異なるところもっていくときに全部作り直しだし
昨今はむしろ使えないデータ構造扱いされること多いから
c/c++を高速化のために使ってるならなおさら
339デフォルトの名無しさん
垢版 |
2020/02/29(土) 16:38:02.22ID:/L84OmpW
長文書いてる人は全員釣り師。
340デフォルトの名無しさん
垢版 |
2020/02/29(土) 16:40:06.91ID:/L84OmpW
>>338
測定すればすぐわかる事なのにね。
そもそも教科書は挿入に焦点を当ててるけど、検索のほうがよほど問題。
algorithmと極端に相性が悪い。
listを使う理由はイテレータの安定性のみ。
2020/02/29(土) 16:45:07.46ID:ZbPwrBbB
>>340
測定だけでは見落とすことが有る。
測定しただけで std::vector の方が速いと思っている人は、数学的想像力が足りてない。
342デフォルトの名無しさん
垢版 |
2020/02/29(土) 16:47:16.55ID:/L84OmpW
>>341
だってキミ嘘しか書いてないやん。
最初から全部嘘だし。
どう見たって釣り師。
2020/02/29(土) 16:48:55.39ID:ZbPwrBbB
>>342
恐らくIQが高いので一般プログラマはついてこれない。
344デフォルトの名無しさん
垢版 |
2020/02/29(土) 16:49:11.83ID:/L84OmpW
はいもう釣り堀は終わり。
2020/02/29(土) 16:55:50.08ID:ZbPwrBbB
高IQの人と一般の人とは話が通じ合わない。
2020/02/29(土) 17:09:06.31ID:VpO1O9GW
はいこのおじいちゃんの毎度の捨て台詞いただきました
2020/02/29(土) 17:16:14.77ID:usahjc2v
> algorithmと極端に相性が悪い。
> listを使う理由はイテレータの安定性のみ。
とか書くような奴もどうかと思うわ
2020/02/29(土) 18:09:51.88ID:VOzt624K
嘘つくやつって特有の変なプライド持ってるよな。
2020/02/29(土) 19:24:46.81ID:ZbPwrBbB
話者に対してレベルが低過ぎる人には話が嘘か間違いにしか聞こえない。
2020/02/29(土) 19:55:24.32ID:8sbT/wNa
嘘つきがレベル高いってのは
赤軍派の暴力事件が相次いでいた頃の
共産主義＝インテリのステータスだった時代の
今となってはもうみんな気付いている茶番とインテリぶったやつらが
真っ赤な最高学府で安々と洗脳されたバカばっかりだったという
お笑いぐさのやつだね
2020/02/29(土) 19:57:19.47ID:YiDWuwc+
動的配列より全面的に優れているって何かのギャグなの？w
2020/02/29(土) 21:20:16.71ID:GVKyjNMb
>>336
Cに慣れた人間がリンクリストを好む傾向があるのは、
動的配列が一段抽象化層を設けないと扱いづらいのに対してリンクリストはCの自然な構文で生のままで扱いやすいからだよ
君自身も君が馬鹿にしている「癖」に縛られているんだ
2020/02/29(土) 21:49:19.01ID:c0ztbNyQ
>>349
仮に IQ が存在するとして、 IQ に差があるのならば、IQの低い受け手はIQの高い話し手の発する全情報を解釈するのに困難を感じることは確かにあり得るとは思いますが、
「嘘か間違いにしか聞こえない」というのは、IQの差だけでは説明できないと思います
IQの低い私の体験としては「わからない」とはいつでもよく感じていたりするのですが、それでも「嘘だ」「間違っている」とは普通は考えませんね
2020/02/29(土) 22:20:21.84ID:gvjpz0iS
リンクリストって今時のCPUにとって非常に性能上扱いづらいものだからねぇ

順繰りにたどっていく場合に先読みがしづらい
実体を指すポインタの配列なら2つ先、3つ先のアドレスまでキャッシュに載っているから、プリフェッチが効いて必要になる頃にはキャッシュにロードされてる感じになる
2020/02/29(土) 22:36:08.55ID:rCNvcH1c
>>345
ここにはお前と話が通じない一般人しかいないから、お前と話ができる人がいるどこかよそに行った方がお互い生産的だと思うぞw
2020/02/29(土) 22:37:49.26ID:+Y3Jyqj/
>>354
デタラメ書かない
2020/02/29(土) 22:40:10.33ID:tY0zeWw8
>>356
デタラメではないでしょ
キャッシュヒット率意識するのは大事
2020/02/29(土) 22:51:13.30ID:XJV+/FNl
プリフェッチとか色々ごっちゃになってる
断片的な知識で知ったかしようとして失敗してるパターン
2020/02/29(土) 23:22:00.98ID:gvjpz0iS
要素アドレスが連続した領域に書き込まれている場合は、
コンパイラがループアンローリングして次の要素アドレスロードしてその参照先のプリフェッチ命令挿入することが可能
ってのを場合によっていくつか先まで出来る
リンクリストの場合はこうはいかない
次の要素のロードが終わらないと次の次の要素のアドレスが分からんのだから
2020/02/29(土) 23:24:07.69ID:gvjpz0iS
インテルCPUの場合はプリフェッチ入れなくても投機的にプリフェッチされてたからこそ、例の脆弱性が問題になってた
2020/03/01(日) 01:43:44.70ID:3018fiZA
実装法を理解できてないために効率よい使い方を間違っている人は遅さをすぐにキャッシュせいにしてしまう。
2020/03/01(日) 01:49:59.33ID:3018fiZA
>>355
まあそうだが、それだとおまえら一般人はいつまでたってもアホなプログラミングしかできないだろうな。
2020/03/01(日) 01:55:38.98ID:3018fiZA
>>362
俺の人生経験からすると、現実には本当に馬鹿な人にはいくら言っても無駄なようだが。
いくら言っても理解できないし、強く何度も言うと、逆に明らかに絶対やっては駄目なときでもいつもそればっかりやってしまうようになったりする。
なので周りはむしろ困ることになる。
2020/03/01(日) 02:04:09.13ID:3018fiZA
cppreferenceを含めてネットでは std::vector ばかり使われているのは、大部分のプログラマがポインタを理解できないのでリンクリストも理解出来ておらず、使いこなすことが出来ないためと踏んでいる。
正しく理解できないためにstd::listを使うと悪い使い方しかできないため、彼らの実験の仕方ではいつもstd::vectorより遅くなってしまう。
そのような人には、C++を使ってもC#以上の速度を出すことは困難で、だからこそ一般プログラマとそれ以下の人材しか集めることの出来ない多くのプロジェクトでは C#やJava,Rubyなど簡易言語が好まれて使われるようになっていると予想される。
俺とは住む世界が違うので、このことは推定に過ぎないがな。
2020/03/01(日) 02:29:46.23ID:0F9Oehpq
uint64_t　の型から　unsigned char　の型に変換するにはどうすればよいですか？
同じ4バイトなのでどうにかすれば変換できるのではと思っているのですが。
2020/03/01(日) 02:30:41.70ID:0F9Oehpq
間違えました。
unsigned charは4バイト確保すれば同じバイト数になる。ですね。
2020/03/01(日) 03:40:24.38ID:ZtayyY2i
そのマシンのエンディアンの通りに格納したんでいいなら
uint64_t a;
unsigned char b[4];
reinterpret_cast<uint64_t &>(b) = a;
2020/03/01(日) 05:10:36.30ID:lOhQr9G7
std::vectorばかり使われる最大の理由は、C言語における配列と互換性を持つ唯一のコンテナだからでしょ。
2020/03/01(日) 05:48:12.89ID:3N/K+b45
64ビットって4バイトなのか？というつっこみ
2020/03/01(日) 07:40:13.71ID:ZtayyY2i
あ、そういえば・・・w
2020/03/01(日) 10:25:14.04ID:7BIH7/M6
>>367
それはだめでしょ
2020/03/01(日) 10:27:14.27ID:0F9Oehpq
>>367,369
間違えました。
8バイトだからこうなるんですね。
変換後の中身を確認したらエンディアンも問題なさそうです。
ありがとうございました。

uint64_t a;
unsigned char b[8];
reinterpret_cast<uint64_t &>(b) = a;
2020/03/01(日) 11:39:13.66ID:7BIH7/M6
>>372
動くだろうけどよくないやりかた
reinterpretじゃなくてmemcpyを使う
それかアライメントを合わせる
2020/03/01(日) 12:04:58.71ID:0F9Oehpq
>>373

ttps://stackoverflow.com/questions/49648033/c-convert-uint64-t-to-unsigned-char-array

上記を参考に下記でやってみたらこれもうまく行っているようです。
こんな感じでしょうか？

uint64_t a;
unsigned char b[8];
memcpy(b, &a, 8);
2020/03/01(日) 12:12:33.01ID:N+yk7N8j
>>364
あなたが書いてることのレベルが低過ぎて理解できません。
376367
垢版 |
2020/03/01(日) 12:13:34.75ID:1R5iR0i4
ああそうか、アラインメントのこと完全に忘れてたすまん
まぁmemcpy, またはunsigned charにアラインメント指定か、もしくはunsigned charごとに代入した方がいいね
動かす環境が限定されてるならreinterpretでもいいけど
2020/03/01(日) 12:18:16.41ID:7BIH7/M6
それでいいよ
ちなみにmemcpyの呼び出しコストは最適化で消えるから気にしなくていいよ
(コンパイラ依存だけど)
2020/03/01(日) 12:22:08.16ID:0F9Oehpq
>>377
ありがとうございます。
2020/03/01(日) 12:42:53.26ID:0F9Oehpq
追加で質問があります。

http://codepad.org/uN82gnco

この30〜31行目でemplace_back()、back()を使っているのですが
emplace_backを使うときはこうやって使うのであってるのでしょうか？

あと、上記をコンパイルすると下記エラーが出ます。

「エラー: オブジェクト以外がメンバ関数 ‘int Self::xxx(ITEM)’ を呼び出すことは出来ません」

今色々調べているのですが、何が悪くてどのように解決すれば良いかがまだわかりません。
どうすればよいかわかりますでしょうか？
2020/03/01(日) 12:44:04.60ID:GdO9iGlh
>cppreferenceを含めてネットでは std::vector ばかり使われているのは、大部分のプログラマがポインタを理解できないのでリンクリストも理解出来ておらず、使いこなすことが出来ないためと踏んでいる。
よくこんな頭の悪いこと思いつくよなｗ
2020/03/01(日) 12:47:43.45ID:PLnmvtRY
How can you be so certain?
2020/03/01(日) 13:00:27.97ID:2UJE7A6V
Self::xxxをSelfの後に書かないと。
ラムダ内部は別の関数だからthisにはアクセスできない。[&]を使うとか工夫しないと。
2020/03/01(日) 13:19:18.30ID:7BIH7/M6
>>379
emplaceを試したいならまずは余計なものいれずにやるべきだね

struct ITEM {
　　ITEM(const char* p) : name(p) {}
　　std::string name;
};

std::vector<ITEM> items;
items.emplace_back("ABCD");
for (auto& item : items) {
　　printf("FF %s\n", item.name.c_str());
}
2020/03/01(日) 13:44:18.34ID:0F9Oehpq
>>382
"&"を使うということは構造体をポインタ渡しするということでしょうか？
下記でポインタ渡しにしたつもりですが、同じようなメッセージが出ました。
ポインタ渡しのことではないのでしょうか？

http://codepad.org/L0oOc9RF

ほぼ同じエラー　→「エラー: オブジェクト以外がメンバ関数 ‘int Self::xxx(ITEM*)’ を呼び出すことは出来ません」

>>383
サンプルありがとうございます。
emplace_back()の時に直接引数に入れることができるんですね。
参考にさせていただきます。
クラス関数に構造体を渡すとエラーになったので、その質問をしたついでにemplace_back()の使い方の質問もさせていただきました。
2020/03/01(日) 13:50:29.27ID:7BIH7/M6
>>384
> emplace_back()の時に直接引数に入れることができるんですね。

それをやりたいからこそのemplaceだよ
無駄を省きたい上級者用って感じだね
まずは自分でITEMを作ってpush_backで追加するのが基本だと思うよ
2020/03/01(日) 13:52:07.36ID:cF4UfbiQ
違う違う、[](ITEM& item) を[&](ITEM& item)にしろってこと
2020/03/01(日) 14:10:29.25ID:0F9Oehpq
>>385
emplace_backは新しい文法でpush_backの方が従来のもののようですね。

>>386
その対応でエラーが消えました。
[&]が何してるのかまだ理解できていないので調べてみようと思います。
ありがとうございました。
2020/03/01(日) 14:23:08.70ID:cF4UfbiQ
あっと、[&](ITEM& item)より[this](ITEM& item)のほうがよかったか
2020/03/01(日) 15:44:10.68ID:0F9Oehpq
>>388
thisでもいけました。
数値のmemcpyを教えていただいた >>374 の件ですが、下記で確認するとバイト単位で逆になりました。
エンディアンの影響だと思いますが、unsigned charに反転せずに簡単にセットする方法はなにかありますでしょうか？

unsigned short num = 258;
unsigned char temp[2];
memcpy(temp, &num, 2);

printf("A %04X\n", num);
printf("B %02X%02X\n", temp[0], temp[1]);

下記結果になる。

A 0102
B 0201
2020/03/01(日) 16:31:11.59ID:7BIH7/M6
>>389
調子にのりすぎ
原因わかってんなら自分で解決できるだろ
頭使え
2020/03/01(日) 16:36:04.92ID:0F9Oehpq
>>390

すみません。
センスないような気がしますが下記で入れ替えようと思います。

unsigned char temp1[2];
unsigned char temp2[2];
memcpy(temp1, &num, 2);
temp2[0] = temp1[1];
temp2[1] = temp1[0];
2020/03/01(日) 17:16:47.98ID:ZpGOlbch
>>391
htons を使えばいいんじゃね？
言語仕様にあるわけじゃないけど、 POSIX と Windows で使えるからまあおおよそポータブルでしょ。
2020/03/01(日) 18:19:09.36ID:JrOSOdLx
>>391
素直に
temp[0] = (num >> 8) & 0xff;
temp[1] = (num >> 0) & 0xff;
でよくね？
2020/03/01(日) 18:30:07.18ID:wjTinnpB
C++の初心者質問スレってなかったっけ
2020/03/01(日) 18:38:25.85ID:3018fiZA
>>372
コピーも何も必要なくて、
uint64_t a;
BYTE *ptr = (BYTE *)&a;
ptr[0] : 0 バイト目
ptr[1] : 1 バイト目
・・・
ptr[7] : 7 バイト目
でいける。
2020/03/01(日) 18:41:25.44ID:3018fiZA
>>395
さらに、
union UUU {
uint64_t　 m_u64;
BYTE　　　m_b[8];
};
uint64_t　　a;　　　// 入力値
UUU　　u;
u.m_u64 = a;
とすれば、
u.m_b[0] // 0 バイト目
・・・
u.m_b[7] // 7 バイト目
となる。
2020/03/01(日) 19:07:30.68ID:7BIH7/M6
>>396
それc++ではUBだよ
あれ君って天才君だっけ？
2020/03/01(日) 21:11:13.32ID:ZpGOlbch
汎用的に作るならこんな感じかな？

#include <type_traits>

template<class T>
typename std::enable_if<std::is_integral<T>::value && std::is_unsigned<T>::value, void>::type
integral_to_bytes(T n, std::uint8_t* dest) {
for(std::size_t i=sizeof(n)-1; i<sizeof(n); i--, n/=256) dest[i] = n%256;
}
2020/03/01(日) 21:22:32.67ID:qtVJ0qYe
std::array<uint8_t, sizeof(T)>を返す方が親切だぞ
2020/03/01(日) 21:50:36.45ID:ZpGOlbch
>>399
なるほど。
整数型の大きさだからそれほど大きくなることは心配しなくていいもんな。
2020/03/01(日) 22:10:49.73ID:WtPaEung
OMP_STACKSIZEが小さいとセグフォるが1Gとか指定してもいいんか？
2020/03/02(月) 01:26:05.82ID:jXMtMdaQ
>>397
UBという証拠は？
2020/03/02(月) 01:46:27.25ID:jXMtMdaQ
>>397
少なくともちゃんと例としては使われている：
https://aticleworld.com/little-and-big-endian-importance/
2020/03/02(月) 01:47:31.58ID:jXMtMdaQ
>>403
typedef union
{
uint32_t u32RawData;
uint8_t au8DataBuff[4];
} RawData;
uint32_t ChangeEndianness(uint32_t u32Value)
{
RawData uChangeData,uOrginalData;
uOrginalData.u32RawData = u32Value;
//change the value
uChangeData.au8DataBuff[0] = uOrginalData.au8DataBuff[3];
uChangeData.au8DataBuff[1] = uOrginalData.au8DataBuff[2];
uChangeData.au8DataBuff[2] = uOrginalData.au8DataBuff[1];
uChangeData.au8DataBuff[3] = uOrginalData.au8DataBuff[0];
return (uChangeData.u32RawData);
}
2020/03/02(月) 02:13:31.73ID:jXMtMdaQ
C/C++では高速化のためCPUのマシン・アーキテクチャをそのまま使う。
マシン・アーキテクチャによって little endian と big endian の違いが有るのでC++言語仕様としては定義されてないが、「but most compilers define」なっている。
これはつまり、littele endian の CPUなら、そのまま little endian での表現がそのまま読みとられ、big endian の CPUなら、そのまま big endian での表現がそのまま読み取られることを意味している。
たとえば、cppreference では、
「reading from n or c is UB but most compilers define it」
となっており、
32BIT値の 0x12345678の場合に、unionで 16BIT 配列の0要素目に0x0011を代入すると、
0x12340011 or 0x00115678
が読み取られるように書いてある。
undefined behaviour であっても、このどちらかに限定されると言うことであろう。

https://en.cppreference.com/w/cpp/language/union

union S
{
　　std::int32_t n;　　 // occupies 4 bytes
　　std::uint16_t s[2]; // occupies 4 bytes
　　std::uint8_t c;　　 // occupies 1 byte
};　　　　　　　　　　　// the whole union occupies 4 bytes

int main()
{
　　S s = {0x12345678}; // initializes the first member, s.n is now the active member
　　// at this point, reading from s.s or s.c is undefined behavior
　　std::cout << std::hex << "s.n = " << s.n << '\n';
　　s.s[0] = 0x0011; // s.s is now the active member
　　// at this point, reading from n or c is UB but most compilers define it
　　std::cout << "s.c is now " << +s.c << '\n' // 11 or 00, depending on platform
　　　　　　　<< "s.n is now " << s.n << '\n'; // 12340011 or 00115678
}
406デフォルトの名無しさん
垢版 |
2020/03/02(月) 04:24:33.89ID:hM5tZRlI
先月ぼくが通った道だけど、結論が全く違ってて興味深い。
2020/03/02(月) 08:40:39.81ID:vdXXyaaZ
UBの恐ろしさを知らない子の結論だね
若いなあ
2020/03/02(月) 08:56:34.60ID:/NXxliI7
老害なのか子なのかどっちかにしろ
2020/03/02(月) 09:31:30.94ID:TcdIMkwU
>>403
cではOKなんだよ
だからわざわざc++ではって限定したんだから察せよ
cでは定義されてるから多くのコンパイラーはc++でも同様の解釈する
また実際のところ今後ずっとそうだろう(今回のケースに限っては)
でもUBはUB
屁理屈つけて自己正当化しようともそれは変わらない
エンディアンでなくライフタイムの問題でしょ、c++の常識的に
2020/03/02(月) 09:37:25.38ID:x4CDu4GY
くっそしょーもねえ
2020/03/02(月) 10:51:20.25ID:4ZdkwDZZ
>>405
ほとんどの場合に大丈夫だろうという見立ては間違ってないと私も思う。
で、大丈夫でなかったときは？
たぶんコンパイルエラーにも警告にもなることなく黙って未定義動作に突入する。

各処理系・環境での挙動が保証されている (検証が済んでいる) なら別に使ってもいいんじゃないのとは思うけど、
union を使ってすごく良くなるというわけでもないので、あえてやることもないんじゃないのとも思う。
少なくとも最初は選択肢から外すなぁ。
2020/03/02(月) 13:35:46.29ID:kyrXnWYL
本人わかってんだからそんな必死になって噛み付くようなことでもないだろ
だいたいプラットフォーム全く限定せずにC++でソフトが書けるのかと

>>411
＞たぶんコンパイルエラーにも警告にもなることなく黙って未定義動作に突入する。
アホか
普段警告レベル下げてるから気付かねーんだよ
2020/03/02(月) 15:19:49.70ID:AN3bmLPv
v
2020/03/02(月) 15:20:44.34ID:AN3bmLPv
(↑のv はミスしました)
>>409 >>411
実は、union より、>>395 のように単純に書いたほうが良い。
unionの場合は、最初に代入によるコピー動作が入るが、>>395 は、単に 64bit 整数の入っている変数のアドレスを取得しているだけだから、全くコピー動作が入らず、物凄く効率が良いし、未定義動作でもない。
>>395 が未定義動作というなら、Cの根幹が揺るぐ。
2020/03/02(月) 15:23:49.36ID:AN3bmLPv
>>409
little endian と big endian の違いだけで全面的にUBということではないはず。
unionの仕様からいえば、ちゃんと 64BIT 整数をそのままイメージとして投影したものがバイト配列になって取得できるはず。
それがunionの定義なのだから。
sizeof(union型)とsizeof(unionのメンバ)の関係も定義されているので、それ以外の実装は有り得ないはず。
2020/03/02(月) 15:28:47.95ID:LGtCkZFK
>>415
お前は人のレスよく読め
cの話はしてないんだよ
2020/03/02(月) 15:43:11.75ID:x4CDu4GY
private/protectedで隠されているわけでもないPODの
ビット表現に依存するなってのは理に適わない
規格が保証しないなら自己責任というだけの話
そんなんどこにでもいくらでもある
418デフォルトの名無しさん
垢版 |
2020/03/02(月) 16:18:13.98ID:x4CDu4GY
test
2020/03/02(月) 16:23:29.71ID:AN3bmLPv
>>416
>>396 で言えば、m_u64, m_b メンバの先頭アドレスがどちらも offset 0 から始まっている限り、little endian と big endian の違いを除いては、どんな処理系でも、m_64 のメモリ中での表現がそのままバイト配列 m_b[] に投影されて読み出せる。
それがunionの定義。
メンバがすべて「offset 0」に配置されるかは、アラインだけの問題。
2020/03/02(月) 16:39:58.55ID:4ZdkwDZZ
>>415
規格では全面的に UB だよ。
C++11 の 9.5 を確認してみたんだけど、
共用体で保証されているのは

- 直近で入れたのと同じメンバで取りだす場合
- 先頭部分に共通する型を持つ標準レイアウトの型をメンバとして持つ共用体であれば共通部分を使うのはアリ (← 言い回しがややこしくてスマン)

ってことだけで、あくまでも先頭に適合する型が連続する部分に限って許してる。
そんでもってこれは規格の書き方はちょっと違うだけで C でも同じだわ。
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況