C++相談室 part156

**デフォルトの名無しさん** · 2021/05/19(水) 10:55:13.24

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

**デフォルトの名無しさん** · 2021/06/24(木) 21:10:55.26

>>495
メモリ確保するようなクラスの場合、メモリ確保の手間省ける。
それ以外でムーブにコピー以上の利点知らない

**デフォルトの名無しさん** · 2021/06/25(金) 00:44:09.12

んまー（通常の関数呼び出しと違って）コピコンは放っといても勝手に呼び出しが削減される（副作用がある可能性ガン無視で）からな
昔から

**デフォルトの名無しさん** · 2021/06/25(金) 00:55:10.74

コピコン呼び出し最適化に頼らねばにっちもさっちも行かないシチュエーションは多々あるから
右辺値参照はﾏｼﾞ不完全
例えば
Foo operator+(const Foo& lhs, const Foo& rhs) {
　Foo x(lhs); // 馬鹿正直にやったらコピー1回
　x += rhs; // Foo& Foo::operator+=()が定義済みとする
　return x; // 馬鹿正直にやったらコピーがもう一回
}
みたいな、
とこの前思いました
※ 個人の感想です

◆QZaw55cn4c · 2021/06/25(金) 01:03:22.61

>>496
要はクラスC のオブジェクトA の中にポインタがあった場合、オブジェクトA を今後一切つかわない前提でオブジェクトA の持つポインタの値をオブジェクトB にコピーするやりかた、ということですよね
言われるほど凄い機能にも革新的な機能にも思えないので来ているのですが、クラスを返すときには、もしかしたら使えるかもしれませんね

でも、すでに RVO があるのでしょう？

**デフォルトの名無しさん** · 2021/06/25(金) 01:11:32.66

>>498
それは左辺値参照だよ。

**はちみつ餃子** ◆8X2XSCHEME · 2021/06/25(金) 01:12:27.64

>>499
それが出来るということは重要じゃなくて文脈によって勝手に使い分けられるということに意味があるんだよ。

**デフォルトの名無しさん** · 2021/06/25(金) 04:23:14.07

move対応してないデカいクラスはマジ迷惑だろ

**デフォルトの名無しさん** · 2021/06/25(金) 06:23:42.07

ポインタ、参照、this、スマポ、[&]
いくらでもどうにでもなる

**デフォルトの名無しさん** · 2021/06/25(金) 06:38:22.69

えっ老害？？

**デフォルトの名無しさん** · 2021/06/25(金) 06:40:16.50

>>499
RVOはC++17で保証されたけどNRVOは保証されてない

**デフォルトの名無しさん** · 2021/06/25(金) 07:44:44.86

C++03時代を生きてないやつからはそう見えるのか

**デフォルトの名無しさん** · 2021/06/25(金) 08:48:57.50

{a, b, c,...} が a, b, c,... という要素からなるリストを表すとき、
{a, {b, {c, d}, e}, f, g, {h, i},...}
みたいな構造は a, b, c,... が全部同じ型だとしても tuple としてしか表せませんよね？

**デフォルトの名無しさん** · 2021/06/25(金) 10:23:01.70

json
yaml
listのtree
なんでも

**デフォルトの名無しさん** · 2021/06/25(金) 10:45:58.24

>>508
ありがとうございます
そうですね。STLとかboostのコンテナに囚われ過ぎてました

**デフォルトの名無しさん** · 2021/06/25(金) 10:52:18.80

老害はC++スレに書き込むなよ
昔の話ばっかだよおじいちゃん

**デフォルトの名無しさん** · 2021/06/25(金) 13:12:18.39

後から入ってきたくせに図々しいやつだな
先住権てやつでこっちが偉いんだよ
気に入らねえんなら他当たるか自分でサーバー立てな

**デフォルトの名無しさん** · 2021/06/25(金) 13:16:46.30

C++03の話なんてもうすんなよ
C++11からはもう別言語やんか

**デフォルトの名無しさん** · 2021/06/25(金) 13:27:35.28

おまえの主観は関係ない

**はちみつ餃子** ◆8X2XSCHEME · 2021/06/25(金) 13:41:54.77

>>506
C++03 時代を知ってるからそれが (少なくとも C++11 に比べれば) クソだってこともよく知ってるよ。

**デフォルトの名無しさん** · 2021/06/25(金) 13:43:28.90

本気で別言語だと思ってるやつって大抵何も作ってないゴミガキだと思うけどなぁ・・
STL的なアルゴリズムや新要素と親和性が高いのは、基本的に標準ライブラリだけなんだが

最近各種コンストラクタ(ムーブ込み)、代入等だけ長々と書いて「実質ほぼ何もしないクラス」を書いてドヤってるアホとかよく見かける

便利になってるのは確かだけどね・・

**デフォルトの名無しさん** · 2021/06/25(金) 13:45:10.88

>>514
俺も必要もなく03以前で書きたいとはまず思わんが、クソとか貶すのはやめた方がいいと思うよ

**デフォルトの名無しさん** · 2021/06/25(金) 18:07:04.42

gets()とか好きそう

**デフォルトの名無しさん** · 2021/06/25(金) 18:33:58.19

(σ・∀・)σｹﾞｯﾂ!!

**デフォルトの名無しさん** · 2021/06/26(土) 00:08:46.09

ゲッツって初めて聞いた
ゲットエスって読んでたんだが

**デフォルトの名無しさん** · 2021/06/26(土) 07:06:09.54

こことCスレでは古くからあるネッスラだよ

**デフォルトの名無しさん** · 2021/06/26(土) 07:21:39.68

scanf()をスキャンフと呼ぶけどprintf()をプリントエフと呼ぶ感じ

**デフォルトの名無しさん** · 2021/06/26(土) 08:05:40.57

プリンテフ

**デフォルトの名無しさん** · 2021/06/26(土) 08:08:29.30

ifndef イフンデフ

**デフォルトの名無しさん** · 2021/06/26(土) 11:51:24.28

アとイ

**デフォルトの名無しさん** · 2021/06/26(土) 13:16:45.08

C++20でもバイナリファイルからdoubleとかの値を読み出す時って未だにreinterpret_cast使う感じ？

**デフォルトの名無しさん** · 2021/06/26(土) 16:37:39.40

HTML★ふとまる

**デフォルトの名無しさん** · 2021/06/27(日) 10:16:13.68

basic_istream::readの引数がvoid*なら何も悩まずに済むのにな

**デフォルトの名無しさん** · 2021/06/27(日) 11:20:36.11

ファイルに書いている時点でアラインメントの保証が難しいから結局memcpyになる気がする

**デフォルトの名無しさん** · 2021/06/27(日) 12:53:25.35

アライメントの問題はファイル関係なくね↑？

**デフォルトの名無しさん** · 2021/06/27(日) 13:14:05.28

エンディアン変換が関係しない場合
C++20でもバイナリファイルからdoubleとかの値を読み出す時はfread()
書き込むときはfwrite()
何の問題も無いし速い……

**デフォルトの名無しさん** · 2021/06/27(日) 13:16:25.37

ていうかエンディアン変換が関係する場合でも
fread()してからメモリ上でエンディアン変換しても良いし
メモリ上でエンディアン変換してからfwrite()したら良い
特にファイル内容全体がメモリ上に収まるケースとかは上記だけでほとんど何も考えなくてもよい

**デフォルトの名無しさん** · 2021/06/27(日) 13:48:27.15

P言語、Ruby、Java、C#などでファイルを読んだり書いたりしなければならなくなることを想定したファイル仕様にしたほうがいいと思うけどどうかな

**はちみつ餃子** ◆8X2XSCHEME · 2021/06/27(日) 13:55:06.53

スタンダードレイアウトな型はバイナリレベルでコピーしてかまわないし
結果的に fwrite して fread できることは保証されるが、
具体的なレイアウトについての保証はない (他の処理系では同じレイアウトにならないかもしれない)
ということも合わせて考えると適当なシリアライザは挟んだほうが良いな。

多言語を意識しつつ高速なバイナリフォーマットというと MessagePack あたりかな？

**デフォルトの名無しさん** · 2021/06/27(日) 13:57:17.27

PerlやPythonでバイナリ読み書きするのに何の支障もないだろ。

**はちみつ餃子** ◆8X2XSCHEME · 2021/06/27(日) 14:00:08.24

>>534
読み書きに支障はないが、言語上の型とバイナリの対応付けについて明確な保証がないと困る。

**デフォルトの名無しさん** · 2021/06/27(日) 14:16:00.40

バイナリなんだからどう扱おうが自由だろ
言語のせいにするのは本人の技術が無いから
言い訳するな

◆QZaw55cn4c · 2021/06/27(日) 14:25:54.48

今時数値をバイナリで読み書きするとか、あり得ないのでは？

**デフォルトの名無しさん** · 2021/06/27(日) 14:30:38.43

Comparison of data-serialization formats - Wikipedia
https://en.wikipedia.org/wiki/Comparison_of_data-serialization_formats

**デフォルトの名無しさん** · 2021/06/27(日) 15:19:43.80

>>537
バイナリでないと実用的でないデータなんていくらでもあるし。画像、動画、アーカイブ、db、ip...
qzはもうエロ画像見るなよ。

◆QZaw55cn4c · 2021/06/27(日) 15:44:56.12

>>539
ごめんなさい誤りましたので謝りますからその刑だけは平にご容赦を‥‥

**デフォルトの名無しさん** · 2021/06/27(日) 15:47:12.10

>>535
保証されてるから支障はない。エンディアンが違うデータだって読み書きできる。

**はちみつ餃子** ◆8X2XSCHEME · 2021/06/27(日) 15:54:09.98

>>541
データがリトルエンディアンなのかビッグエンディアンなのかわかっていればね。
C++ が単にメモリ上のデータを書き出したときに、それがどっちなのか、
(言語としては) 保証してないって話をしてるんだよ。

**デフォルトの名無しさん** · 2021/06/27(日) 16:14:20.16

C++20でstd::endianが使えるようになるけど

◆QZaw55cn4c · 2021/06/27(日) 16:39:33.97

シェアの高かった 68 系かインテルザイログ系か、の二分図がここにも残っているのですか
もう UTF-8 のようなエンディアンに依存しないバイナリが優秀だ、という価値観にするべきかと

**デフォルトの名無しさん** · 2021/06/27(日) 17:01:10.06

インターネットのプロトコルはビックエンディアン
USB等のPC系発祥のデバイスはリトルエンディアン
この辺はもう変更しようが無いだろ

**はちみつ餃子** ◆8X2XSCHEME · 2021/06/27(日) 18:13:48.48

>>544
ここでのトピックは >>530 に対しての反論。
メモリ上にあるバイト列には保証がないからなんらかの明確な
データ交換用フォーマットに変換する処理が必要という話で、
出力先のデータ交換用フォーマットが BE か LE かなんていう以前の段階。

**はちみつ餃子** ◆8X2XSCHEME · 2021/06/27(日) 18:17:55.59

ファイルに書き出すにあたって「エンディアンの変換が不要なら」という前提を置きたくねぇなぁという話だな。
パディングとかも入るかもわからんし。

◆QZaw55cn4c · 2021/06/27(日) 19:47:44.56

>>546
であれば、私はどちらかというと >>530 の味方側ですね、>>530 がそう意図しているかどうかは不明ですが、処理系のエンディアンを仮定することなくコードを書くことは可能だったと記憶しています。‥‥①

ただ同時に、確かにパフォーマンスの点で過剰な不利を承知で >>537 を再提示するべきかな
つまり、>>537 みたいな画像フォーマットはありました PPM/PGM/PBM
https://mevius.5ch.net/test/read.cgi/tech/1434079972/73　
このコードは①を検証したものだったかと遠い記憶に残っていますね

あ、罰ゲームは勘弁ね、私だってエロ画像は見たい‥‥https://www.youtube.com/watch?v=TvDWJif1sSI

**はちみつ餃子** ◆8X2XSCHEME · 2021/06/27(日) 20:29:20.98

>>548
だからそういうコードが書けるかどうかという話じゃなくて
書かなきゃなんない (書くべき) ねという話なんだってば。

◆QZaw55cn4c · 2021/06/27(日) 20:58:56.14

>>549
それは失礼しました

**デフォルトの名無しさん** · 2021/06/27(日) 22:44:17.18

>>542
C++だって読もうとするバイナリデータのエンディアンを事前に知らなきゃならんのは変わらんだろ。
自分で書いたものを読むならエンディアンが一致するのはあたりまえ。

**はちみつ餃子** ◆8X2XSCHEME · 2021/06/27(日) 23:46:30.32

>>551
> エンディアンを事前に知らなきゃならんのは

知らなきゃならないがわからん (保証されてない) のだという話をしている。
C++ で書いてメモリをそのまま書き出したらそれのエンディアンは保証されてない。

言語が何であれデータフォーマットが固定されてないとどうにもならん。

**デフォルトの名無しさん** · 2021/06/27(日) 23:53:27.71

>>552
それは言語関係ない話だろ。

**はちみつ餃子** ◆8X2XSCHEME · 2021/06/28(月) 00:31:47.85

>>553
言語に関係あるという話はしてないよ。

**デフォルトの名無しさん** · 2021/06/28(月) 00:34:04.32

Javaはメモリモデルも明確に決まってたんじゃないかな

**デフォルトの名無しさん** · 2021/06/28(月) 02:47:25.75

多言語間でポータブルにしたくば
XMLとかyamlとかjsonにしたら良いんじゃーあ！

**デフォルトの名無しさん** · 2021/06/28(月) 03:12:57.95

どうしてもバイナリファイルが良いという向きは、
パディングとかもfwrite()とfread()で取り扱い得る
といっても単に適当なサイズのバイトの配列として読み書きして
メモリ上でご使用のアーキテクチャーに合わせることになるが
fwrite()とfread()を使わなければもっとﾏｼになるという類の話ではない

**デフォルトの名無しさん** · 2021/06/28(月) 03:44:20.73

別にバイナリ吐き出すときは必ずポータブルにする必要ないだろうに
なんで勝手に条件追加して批判してんだか

◆QZaw55cn4c · 2021/06/28(月) 07:17:27.29

>>556
お手軽な XML/yaml/json 読み書きライブラリを紹介してください、よろしくお願いいたします

**デフォルトの名無しさん** · 2021/06/28(月) 07:48:39.66

>>554
PerlでもPythonでもC++と変わりなくバイナリの読み書きはできるという話をしてるんだが。
エンディアンがわからなければC++でも読めないというのは当たり前。
フォーマットを知らないバイナリファイルってことだからな。

**デフォルトの名無しさん** · 2021/06/28(月) 08:30:45.47

これ以上、バイナリ読み書きの話をする前にとりあえず>>538に目を通せ
車輪の再発明をしたいのか、既存の車輪を利用したいのかをはっきりさせてから話を進めたほうがいい

**デフォルトの名無しさん** · 2021/06/28(月) 09:09:23.58

僕はノンバイナリーだから読みたくないです

**デフォルトの名無しさん** · 2021/06/28(月) 09:56:34.91

こんどはバイナリに噛み付いてるキチガイがいるな

**デフォルトの名無しさん** · 2021/06/28(月) 11:09:48.91

標準ライブラリのみであれば車輪の再発明しか手段がない？

**デフォルトの名無しさん** · 2021/06/28(月) 12:52:58.19

MsgPack は json と同じで無駄が多い

**デフォルトの名無しさん** · 2021/06/28(月) 12:59:22.39

>>558
温暖化詐欺SDG詐欺と手口が一緒だな

**デフォルトの名無しさん** · 2021/06/28(月) 13:35:34.04

>>559
WSL2, Ubuntu 18.04 では、

apt list --installed libxml2

libxml2/bionic-updates,bionic-security,bionic-updates,bionic-security,
now 2.9.4+dfsg1-6.1ubuntu1.4 amd64 [インストール済み、自動]

**デフォルトの名無しさん** · 2021/06/28(月) 13:52:30.89

Comparisonて何て読むの？
コンパリソン？

**デフォルトの名無しさん** · 2021/06/28(月) 14:55:11.19

msgpackはクソやね
バイナリの扱いに慣れないスクリプト坊がバイナリを扱わざるを得なくなった場合を除いては全く価値のないフォーマット

**デフォルトの名無しさん** · 2021/06/28(月) 14:56:29.69

>>568 こんｐぇぁりｚん https://www.google.com/search?q=comparison

**デフォルトの名無しさん** · 2021/06/28(月) 15:26:12.03

>バイナリの扱いに慣れないスクリプト坊がバイナリを扱わざるを得なくなった場合

この表現すき💛

**デフォルトの名無しさん** · 2021/06/28(月) 15:26:13.01

>バイナリの扱いに慣れないスクリプト坊がバイナリを扱わざるを得なくなった場合

この表現すき💛

**デフォルトの名無しさん** · 2021/06/28(月) 16:13:11.20

>>569のお勧めは何？
理由もセットで教えて頂戴。

**デフォルトの名無しさん** · 2021/06/28(月) 16:32:50.30

「モジュール」はC++で作られたパッケージを配布しやすくしますか？

**はちみつ餃子** ◆8X2XSCHEME · 2021/06/29(火) 00:03:30.47

>>560
そうだよ。その当たり前の話をしてるんだよ……。

互換性の問題というのは内部的なものなら問題が起きたときに修正すればいいが、
外部に出ているデータはそれに皆が合わせなければならない仕様と化すので
特定の C++ 処理系 (実行環境) でなら処理できるけど
出力されたデータフォーマットの詳細はわからんし処理系のバージョンがちょっと変わったら変わるかもしれん
というのでは困るやんというごく普通の話。
(もちろん普通の処理系はちょっとバージョンが更新されたくらいでは
バイナリ互換性をあまり壊さないように配慮するのが普通ではあるけど。)

**デフォルトの名無しさん** · 2021/06/29(火) 00:15:58.47

>>575
いつのまにか話ずらしてんな。

>>535
>読み書きに支障はないが、言語上の型とバイナリの対応付けについて明確な保証がないと困る。

言語上の型とバイナリの対応付けはPerlでもPythonでも保証されてるんだよ。

**はちみつ餃子** ◆8X2XSCHEME · 2021/06/29(火) 00:20:30.40

>>576
されないよ。
ファイルのバイナリが BE か LE かわかっていない状況の話なんだから。

**デフォルトの名無しさん** · 2021/06/29(火) 08:12:22.23

>BE か LE かわかっていない状況

これの意味だが

・全く何の情報もない状況
→どんな言語を使おうが正しく読める保証がないし論ずるだけ無駄。

・>>552の「C++ で書いてメモリをそのまま書き出したらそれのエンディアンは保証されてない。」状況
→「自環境のエンディアン」で読めるのはC++でもPerlでもPythonでも同じ。

**デフォルトの名無しさん** · 2021/06/29(火) 08:29:00.28

>>573
方法はともかく、普通にビット列かバイト列のレベルで仕様を決めてその通りに読み書きすりゃいいんじゃない
C++プログラマなら生データの扱いは得意でしょ
とはいえ手間がかかるしミスを生じやすいのも事実なので、めんどくせえ今すぐ読み書きしたいってだけならprotobufとかavroとか他にも色々あるよ
msgpackとの大きな違いはスキーマの有無で、スクリプト言語じゃなきゃスキーマはあったほうが便利だし、一般に実装が高速になりやすくデータサイズも小さくできる

**デフォルトの名無しさん** · 2021/06/29(火) 08:38:20.49

>>579
「他人含めた仕様の強要」という観点が抜けてない？
それに、何回車輪の再開発させるつもりだよ。

**デフォルトの名無しさん** · 2021/06/29(火) 08:57:28.61

>>580
強要したいならちゃんと仕様書書いて押し付けるだけの話
実装が面倒ってんならそれこそprotobufのようなスキーマのある汎用フォーマットならスキーマさえ書いとけば大抵の言語でserde用の型の自動生成までやってくれるよ
その点で言えばmsgpackは所詮mapなんで、仕様を強要したいなら別途仕様書が必要になるよ

**デフォルトの名無しさん** · 2021/06/29(火) 10:54:24.87

実の無い話はすぐ切り上げるのが大事だぞ
お互いの時間を無駄にしあってはいけない

**デフォルトの名無しさん** · 2021/06/29(火) 12:00:43.57

他人に構ってもらわなければ生きて行けないかまってちゃん人種は救いようがない

**デフォルトの名無しさん** · 2021/06/29(火) 13:20:29.38

>>560
Perlでバイナリを扱うのは物凄く大変だった。
さまざまな自動変換がかかってしまうので、結局どうなるのかが分からない事が
多かったから。
例えば、数値なのか、文字なのかの区別が曖昧な感じで、たままた数値が入った
文字が、勝手に数値になって、'0' + 1 が、0x30 + 1 のつもりが、0 + 1に
なってしまったり、物凄く難しかった。
ASCIIコードの数値番号を取得したいと思っても、結果が数値の入った文字列に
なったりとか、よく分からない事が多かった。
何を何に変換しているのか、めちゃくちゃ難しかった。
それがRubyになって、素直な感じになった。

**デフォルトの名無しさん** · 2021/06/29(火) 13:23:14.00

>>584
16進数も複雑だった。
単に表示したいために16進数の文字列に直したら、どこかで勝手に数値として
解釈されていつの間にか思いもよらぬ「もの」に変化したりとか。
それで、バイナリや文字を細かく扱い際には、如何にCが楽であるかを思い知った。

**デフォルトの名無しさん** · 2021/06/29(火) 14:44:15.68

Cというか、それは最早動的型付けか静的型付けかとかの話では

**デフォルトの名無しさん** · 2021/06/29(火) 15:11:46.24

>>586
JSやRubyは、動的型付けだけど、Perlのように文字と数値の相互変換が勝手に
起きたりはしない。

**デフォルトの名無しさん** · 2021/06/29(火) 15:25:41.01

pack/unpack使えばそんな変なことにはならんぞ。
perlでバイナリ扱うなら常識。

**デフォルトの名無しさん** · 2021/06/29(火) 15:37:31.39

>>588
それ自体はそうでも、その後いろいろなことが起きてややこしかったな。

**デフォルトの名無しさん** · 2021/06/29(火) 18:21:23.30

強気なこと書き込む人はだいたい経験浅い

**デフォルトの名無しさん** · 2021/06/29(火) 18:35:19.68

ボカァもうOOPは捨てた！ｗ

◆QZaw55cn4c · 2021/06/29(火) 18:54:36.80

>>578
あなたはちょっと残念な人ですね

実際には C/C++ ならば、処理系が LE/BE どちらに依存かにもかかわらず処理系に独立して LE なら LE用, BE なら BE用に書きわけることができる‥‥①
①の証拠は >>548
ことほど左様に、処理系に独立して LE/BE を書き分けることができるのなら「～するべき」とかいう「べき論」は無意味でしょう
多分、はちみつ氏は①を失念していたのでしょう、べき論なんて振り回しても無駄なのに、あいかわらずべき論に拘泥するところなどは「ダメリカ様が守ってくださる！」的な馬鹿左翼並の振る舞いですから、そろそろあきらめるべきでしょうね

**デフォルトの名無しさん** · 2021/06/29(火) 21:05:01.01

>>592
？
なにか別の話とごっちゃにしてないか？べき論って？？？

>実際には C/C++ ならば、処理系が LE/BE どちらに依存かにもかかわらず処理系に独立して LE なら LE用, BE なら BE用に書きわけることができる‥‥①

C/C++じゃなくてもPerlやPythonだってLE/BE書き分けられる手段は用意されているって話をしていただけなんだがな。

**デフォルトの名無しさん** · 2021/06/29(火) 21:08:28.05

>>589
pack/unpackの後の話ならバイナリファイルとか関係なくて、ようは「Perlがややこしかった」というだけだろ。

>例えば、数値なのか、文字なのかの区別が曖昧な感じで、たままた数値が入った
>文字が、勝手に数値になって、'0' + 1 が、0x30 + 1 のつもりが、0 + 1に
>なってしまったり、物凄く難しかった。

これなんかまさにそうだな。

**デフォルトの名無しさん** · 2021/06/29(火) 23:39:33.94

この話のゴールどこ？