C++相談室 part137

2018/08/27(月) 16:02:00.94

次スレを立てる時は本文の1行目に以下を追加して下さい。
!extend:on:vvvvv:1000:512

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

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

このスレもよろしくね。
【初心者歓迎】C/C++室 Ver.103【環境依存OK】
https://mevius.5ch.net/test/read.cgi/tech/1530384293/

■長いソースを貼るときはここへ。■
　http://codepad.org/
　https://ideone.com/

[C++ FAQ]
https://isocpp.org/wiki/faq/
http://www.bohyoh.com/CandCPP/FAQ/ (日本語)

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

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

2018/09/28(金) 11:07:41.28

>>796
一貫性は無いけど、仮引数の rvalue reference に lvalue がマッチ「してほしくない」というのはわかるので、
まあしょうがない。

2018/09/28(金) 11:11:50.31

>>789
ちょっと確認なんだけど、
テンプレート仮引数 T に対して T&& に lvalue がマッチするっていうのは、
実際には lvalue reference として機能するという意味でいいんよね？
(変形できるというのはそういう意味だよね？)

2018/09/28(金) 11:58:59.36

>>798
それ以外の何だと思うの？

2018/09/28(金) 12:26:11.67

>>797
あまのじゃく？

2018/09/28(金) 12:29:12.61

>>799
「変形される」だったら勝手にやってくれるんだなーと思うんだけど、
「変形できる」という言い回しにちょっと引っかかりを感じたというふんわりした疑問なので、
具体的に別の可能性を思い浮かべたわけではないです。

2018/09/28(金) 14:07:40.60

江添とお前らどっちがC++に詳しい

2018/09/28(金) 14:45:05.48

>>802
その人もここに来るかも知れないから。

2018/09/28(金) 14:53:59.72

江添で言えばまさにわかりやすくその辺の事情解説してくれてるだろ
今の話で江添より詳しいとかありえねー

2018/09/28(金) 17:00:34.02

>>802
江添氏は C++ を使うプログラマというよりは、
C++ の規格の専門家として C++ の知識を持ってるんだから、
かなり詳しいよ。

2018/09/28(金) 17:18:49.52

>>805
いずれにせよ、気持ちはうれしかったよ。

2018/09/28(金) 17:49:54.67

>>804
そのへんの事情って？
>>805
それは本人も自負してるようだけど

2018/09/28(金) 18:34:51.41

>>789, >>793あたりの仕様の事情な

2018/09/28(金) 21:21:09.15

もし非テンプレート関数かつ非インライン関数なvoid bar(Foo&& a)に左辺値xを渡してビルドが通る言語規格だとしたら、
　tmp = xのコピー
　barのビルド結果←(tmpのアドレス)
ということになってxのコピコンが呼ばれてしまうま
つまり右辺値参照がコピコン削減になるかどうかというのは関数を右辺値参照にしただけでは決まらず、
呼び出し元の条件次第なので、bar()を作る人/使う人双方の慢心を避けるためにエラーにするんだろＪＫ

一方テンプレート関数またはインライン展開される関数なら、上のようなへタレコードに一時的になっても
すぐさまコピコン削減ができるから実質弊害が無い
ただし、そういった関数でも再帰呼び出ししたりアドレスをとったりすると上と同じ議論になるので、
再帰呼び出し/アドレスを取る操作　両方ともありえるインライン関数は>>789の例外の適用外とされ、
テンプレート関数は再帰呼び出しが有り得ないし、アドレスを取る奇特な人間も居ないだろうということで>>789の例外が設けられた

2018/09/28(金) 21:24:43.89

訂正；
△：　すぐさまコピコン削減ができる
○：　コンパイラがすぐさまコピコン呼び出し削減最適化をかけられる

コピコン呼び出し削減最適化はこの場合データフロー解析の結果を流用したらできる
C++はgotoが使われたとき、コンストラクタが呼ばれずに使われるオブジェクトが生じないか否か確かめるために
データフロー解析はもともと必須なので、コピコン呼び出し削減最適化はC++コンパイラ書きなら誰でも出来る（多分

2018/09/28(金) 21:34:28.86

>>793
>const T& に rvalue がマッチするんだった。
それはある意味当然すぐる
const T& x = r; // rは右辺値
...
y = x // (*)
としたときに、コンパイラは(*)みたいな文が現れるまでは、
xへのアクセスを機械的にrへのアクセスに置き換えれば良いわけでゼロコスト
rが所有権を失ったらxのアクセスも不正となるが、これは書き換え可能なオブジェクトを
const参照をとってから書き換えた場合も似たようなもの（身からでたサビ
なのでコンパイラはやっぱ何もしなくて良い

2018/09/28(金) 21:36:22.95

（30分前にこのスレを読んで初めて右辺値とか右辺値参照といったﾌﾞﾂを知った初心者なので語ってみた

2018/09/28(金) 22:13:49.14

>>811
y = x
の後もxへのアクセスはrへのアクセスで良くないの？

2018/09/28(金) 22:40:22.15

どんな文が現れようとずっとrでいいんじゃね？

2018/09/28(金) 22:45:46.54

>>813 >>814
ﾎﾝﾏや！(；ﾟДﾟ)天才か！

2018/09/28(金) 22:50:40.02

>>815
ｳｯｻｲ､ﾁﾈ

2018/09/28(金) 23:48:18.05

>>809
再帰だろうがアドレスとろうがオンラインだろうが例外は適用されるだろ。
やっぱ30分で理解するのは無理じゃね？

2018/09/28(金) 23:50:49.06

auto a = funcA(funcB(funcC(input)));
みたいな感じの関数の入れ子ってさ、ある関数が終わる度にその都度インスタンスを作ってコピーして次の関数に渡すということを繰り返すんだよね？

つまり、関数たちの返り値が巨大なオブジェクトだったら、このように書くことで余計に時間がかかるよね？

2018/09/29(土) 00:09:10.14

>>818
いんや。
オブジェクトにムーブコンストラクタがあって戻り値が右辺値ならコピー回避されるし、戻り値最適化で一切何も起こらない可能性すらある。

て、はちみつが言ってた。

2018/09/29(土) 00:13:53.80

>>819
へぇ

> 一切何も起こらない
というのは、一切余計なオーバーヘッドがない、ということですか？

2018/09/29(土) 00:22:35.94

単純なコピーよりは早くなる可能性があるってだけでは？

2018/09/29(土) 00:30:08.48

ちょっと誇張しすぎた。
正しくは「コピーもムーブも起らない可能性すらある」

コピーもムーブも起こらなければ、その分のオーバーヘッドは当然ないよ

2018/09/29(土) 00:36:40.21

へぇ～～～
ありがとうございます

まぁそこがボトルネックじゃない限り余計なこと考えない方が身のためなのかもしれませんが

2018/09/29(土) 02:25:18.76

>>818-823
コピーもムーブも省略される可能性ってのは、左辺の場所でオブジェクトを直接に構築するっていう意味。
構築してからそのままコピーしてる (そして元のオブジェクトが一時的である) 場合は実際には直接構築したって同じよねという話。

2018/09/29(土) 14:26:47.44

>>819
＞オブジェクトにムーブコンストラクタがあって戻り値が右辺値ならコピー回避されるし
なんかムーブコンストラクタを魔法か何かと勘違いしてないか？
ムーブコンストラクタの方が重い処理してたら当然重くなるんだぞ

2018/09/29(土) 14:32:22.06

>>825
ええ…
コピーより重いムーブコンストラクタの存在を前提に話す必要ある？

2018/09/29(土) 14:44:27.90

むしろムーブで軽くなるのは大抵の場合ムーブによってヒープの確保、解放を
避けられるクラスだけ、だろ
ある意味そっちの方が限定して話をしてると思うが

基本をすっ飛ばすからはちみつその他誤解するやつが出てくる

2018/09/29(土) 14:49:31.13

この機能が必要になった背景・経緯

ムーブセマンティクスは、C++03でもNRVO（特定の文脈でのコンストラクタの省略）や、 C++11で非推奨となったstd::auto_ptrで実現されていた。
しかし、NRVOがいつでも機能するわけではなかった。
また、std::auto_ptrにはコピーと同じ文法でムーブしていることなど、問題が多かった。
そのため、コピーと区別でき、統一的にムーブを表す文法が言語機能として必要とされた。

つまりこんなあぶなっかしい
unique_ptr、shared_ptr、weak_ptrとか使ってるﾔﾂﾗも
ｸﾙｸﾙﾊﾟｰしかいない

この程度の簡単な制御も自分で簡単に制御しきれないﾜｹだからな

2018/09/29(土) 14:56:25.79

しかしｱﾎのあたらしもの好きは半端ない
頭悪いｼﾛﾓﾉでも新しいものができたら使わないといけない病になってるからな
ｼﾛｳﾄに多い

2018/09/29(土) 14:58:40.21

いや、autoはともかくshared, unique, weakは危なっかしくないと思うが・・
ムーブが使えるようになってからだし
あと個人的にはcpprefjpは規格寄り過ぎてユーザー寄りじゃないと思う
cppreference.comを使うべき

2018/09/29(土) 14:59:08.11

で、こんなしょうもないことより
ﾎﾝﾄに理解しないといけない部分がすっぽりと抜けてる

2018/09/29(土) 16:42:03.70

C++ の (というかプログラミング言語の) ほとんどの機能は抽象化の道具。
ムーブもまた、見かけ上は代入っぽい抽象で扱えるものであっても
実態はもうちょっと速いコードにも出来る (可能性がある)。

>>828
そういう簡単な制御すら抽象化層に押し込められない方がよっぽど駄目。
クルクルパーだと思ってるならなおさら、
簡単な制御なら (いつも間違いなく) 出来ると期待すべきでない。
そんでもって大抵の人間はクソザコで、しょうもない間違いをする。
問題は道具で解決すべき。

2018/09/29(土) 17:03:15.96

スマポは言語の機能じゃねーよボケ

2018/09/29(土) 18:38:13.57

>>832
>問題は道具で解決すべき。
ネ申は確かＬＬ言語を創造された

2018/09/29(土) 18:45:43.26

ムーブはゼロの発見に次ぐ、人類史上における大発見と言われてるけどな。
ノーベル賞候補の一つにもなってるし。

2018/09/29(土) 18:51:41.19

std::auto_ptr<T>はもともとオブジェクトをムーブしたくて生まれたわけでは無いと思う…
確実な解放の実現が先
ムーブする仕様はあと

あとstd::auto_ptr<T>（unique_ptr<T>でも良いが）でも使わないとやってられないｼﾁｭがC++には少なくとも1つある

2018/09/29(土) 18:56:52.23

move元のオブジェクトに対するアクセスがコンパイルエラーになるんならわかるけど、そうじゃないんなら
大層な仕組みを入れなくても単に unique_ptr を言語組み込みで実装すれば済む話だったのでは？

2018/09/29(土) 19:32:03.30

お前ら江添に負けて恥ずかしくないの？

2018/09/29(土) 20:26:30.14

全然？

2018/09/29(土) 21:00:53.02

>>837
それ何が嬉しいんだ？
vector とかどうすんだよ

2018/09/29(土) 22:03:09.07

>>840
moveするのが分かってるんなら最初からvectorごとヒープに作って unique_ptr で持てばいいでしょ
中途半端にガワだけスタックに置く意味がない

2018/09/29(土) 23:45:25.50

move後の元オブジェクトを破壊っていうか破棄しようって提案もあったよ。ちょっと早くなるのだとさ。

2018/09/30(日) 00:04:13.06

>>841
ポインターならそもそも copy のコスト安いから move 要らないじゃん

2018/09/30(日) 00:20:38.65

それだったら最初から普通にﾎﾟｲﾝﾀでかけよ

2018/09/30(日) 00:57:02.37

この3冊が、神の書！

Linux プログラミング・インタフェース、Michael Kerrisk、2012

C++11/14 コア言語、江添亮、2015

組込み開発者におくるMISRA‐C:2004―C言語利用の高信頼化ガイド、MISRA‐C研究会、2006

2018/09/30(日) 01:40:28.47

>>843
だからmoveいらないって話でしょ
C++のムーブセマンティクスがああなったのは中途半端にスタックを使うスタイルが定着してしまっていて今更ポインタ使えというのは無理があるからで、
本来は所有権の管理さえ適切に行えるようになってさえいればムーブなんか要らんよ

2018/09/30(日) 06:43:45.01

C++ Coding Standards って新品で買えないけど代わりになる書籍ありますか？

2018/09/30(日) 06:48:23.20

>>846
ポインタ使え思想はすでにC#とかなクラスが参照型な言語で実現されているが
オブジェクトの解放にガベージコレクタが要る言語になった

これはガベージコレクタ無し・所有権の無条件移動だけだと、次のようなケースで早速話が破綻するから仕方が無い
void bar(int n) {
　std::unique_ptr<Foo> a(new Foo());
　for (int i = 0; i < n; i++) {
　　func1(a, i);　　// func1(a, 0);で所有権がgone　以降のfunc(a, i)はaの不正アクセス
　}
}

不正アクセスにならないように、実際にはこのようなfunc1()にはa.get()でポインタを渡す書き方をする
するとfunc1()以下の呼び出しは全部>>844になる

人類に逃げ場は無い

2018/09/30(日) 06:53:57.08

それにポインタ使え思想だと次のようなケースでBaz::m_c[i]のBar:m_b[j]の:Foo::m_aのアクセスに藻前らどんだけ間接参照するんですかと、
class Foo {
　SomeClass m_a;
};
class Bar {
　Foo m_b[100];
};
class Baz {
　Bar m_c[100];
};

2018/09/30(日) 07:13:40.02

ちな>>849はm_bやm_cが配列であるため、配列アクセス時の添え字が定数なｼﾁｭでもない限り、JITでも間接参照回数を3以下にはできん

2018/09/30(日) 09:10:22.74

>>848
よくわからんな
848の問題はそれmoveでも一緒だよね
単にデフォルトの挙動がmoveかborrowかだけの話で、unique_ptrがたまたま前者なだけ
スマポ使えば間接参照はどうしても増えるけど、実際>>849のようなケースで特定の要素だけ所有権捨てたりしないでしょ
所有権を移動するかどうかはほぼ例外なくオブジェクト生成時点で予め分かってるんだから、その場合に限ってスマポを使えばよい
コーナーケースのために全てを複雑にする必要はない

2018/09/30(日) 09:21:04.80

>>851
>所有権を移動するかどうかはほぼ例外なくオブジェクト生成時点で予め分かってるんだから、
有り得ない仮定すぐる…
>>848なケースにおいて、オブジェクトaの生成時点というのは、
ライブラリー制作者がfunc1()を設計してビルドまで完了した後やがな…

2018/09/30(日) 09:39:54.40

>>852
自分でも分かってて揚げ足取ろうとしてるんだろうけど、コーディング時に、プログラマがオブジェクトを生成することを意図したコードを記述した時点で、な

2018/09/30(日) 09:46:24.24

>>853
いやｽﾏﾝ言い方がまずかったそういう意味ではない
確かに
>所有権を移動するかどうかはほぼ例外なくオブジェクト生成時点で予め分かってるんだから、
というのは真だが、ライブラリのインターフェースに解放が必要なオブジェクトのmoveなど認めたら有り得ないコストが生じるという話

func1()の制作者が所有権を寄越すことを強制した（そういうインターフェース仕様にしてしまった）場合、
func1()を使う人はfunc1()に所有権を渡さねばならない。この結果、
　1. 呼び出し元（func1()を使う人）がaをコピーしてコピーをfunc1()に渡さねばならない
　2. func1()は呼び出しの度に、aを解放する
というのが>>848のコードでn回無駄に繰り返される

これを避ける方法はあるっていやーあるが、結局func1()以下の呼び出しは全部>>844になる（か、ガベージコレクタの出番となる

人類に逃げ場は無い

2018/09/30(日) 09:52:25.65

>>854
だからそれmoveでも同じことだよね？
ユニバーサル参照のことを言ってるんだとしたら、あれただの型推論だぞ

2018/09/30(日) 10:03:48.10

>>855
解放が不要なオブジェクトのmoveは話がちげう
この場合、単に生ポインタ（オブジェクトのアドレス）をfunc1()に渡すのと変わらん
これはライブラリのインターフェースに現れてもコスト的には問題は無い

元レスのアンカー先>>846は>>854のコストが避けられない主張

2018/09/30(日) 10:07:31.97

いやすまん解放が不要なオブジェクトでも、所有権を移動した場合は>>854の1のコストは避けられないorz
ここは訂正

2018/09/30(日) 10:11:13.08

>>856
スマポのmoveも本体のmoveも一段間接参照が入る以外は何も変わらないって言ってるんだけど、そんなに難しい話かなあ

2018/09/30(日) 10:45:39.58

>>858
>>848、>>849は、現行C++におけるスマポのmoveと本体のmoveの優劣は問題にしていない

848を現行C++のコード風に書いたから誤解を招いたのかもしれないが、比較はあくまで現行C++と846思想の比較であって、
846の次の思想を実行に移したら>>854のコストが避けられませんよという話
　1. スタックを使うスタイルはやめるべき（全部スマポであるべき）
　2. 所有権の管理さえ適切に行えるようになってさえいれば（現行C++のムーブセマンティクスみたいな）ムーブなんか要らん

1は現行C++との比較において、間接参照回数に響く
2は現行C++との比較において、現行C++では避けられるコスト（>>854またはガベージコレクション）を無駄に背負い込むことになる

2018/09/30(日) 10:52:02.74

>>858
本体のムーブも、ムーブ出来るように書いたらカスタムなスマートポインタみたいになるから、
間接参照が入っちゃうので、なおさら同じではあると思う。

でもまあ、ムーブは抽象化の方法であって、
最終的に実行されることが同じだからなくても良いってのは暴論よね。

2018/09/30(日) 11:10:34.99

アンダースコアとドットをこの順で必ず含む string があったとして、アンダースコアからドットまでの部分文字列を切り出す処理って一行で書ける？

substr と find_first_of と find_last_of を組み合わせる方法を考えたんだが、
アンダースコアの前を削る;
ドットの後を削る;
という2行に渡るやり方しか思い付かない

2018/09/30(日) 11:15:56.30

ちな
>スマポのmoveも本体のmoveも一段間接参照が入る以外は何も変わらないって
これは現行C++においても違う違いがﾜｶﾙ男ならﾜｶﾙ

func1()からfunc2()にfunc1()の自動変数aをmoveするとして、かつfunc2()はインライン展開されるとすると、
func2()におけるaのメンバへのアクセスはfunc1()呼び出し時点でのスタックポインタ相対で一発でやれる
一方、aがスマポだったりすると、aのメンバへのアクセスの前に、func1()呼び出しの都度1回はスタックポインタ相対でaのアドレスを得なければならない

2018/09/30(日) 11:27:40.54

オブジェクト本体のメモリのコピーにかかるコストを考慮すればどっちもどっち

2018/09/30(日) 11:54:22.15

>>861
substr じゃなくて、コンストラクタ使えばいいんじゃね
string t(s.begin() + s.find_first_of('_') + 1, s.begin() + s.find_last_of('.'));

2018/09/30(日) 12:29:37.73

>>864
なるほど、ためになります

2018/09/30(日) 12:35:17.89

>>864
ふと気になったのですが、このコンストラクタの挙動って他の名前の関数で実装されてないんでしょうか？

2018/09/30(日) 12:48:58.63

>>866
assign

2018/09/30(日) 13:18:31.87

>>867
何から何までありがとうございます

2018/09/30(日) 14:15:51.90

「rustにもあるし俺らも入れなきゃ」くらいの感覚で
今までのシステムとの統合性の難しさなんかほぼ考えないで入れちゃった機能だから。
c++らしいといえばらしい感覚だけど。

2018/09/30(日) 14:22:42.56

std::basic_string::find()もイテレータを返すように他のコレクションとの統合性を尊重して欲しいよな

2018/09/30(日) 22:56:12.57

findを実行した対象とは別のstringの同じ位置に何かしたいとき
イテレータで返されるとちょっとだけ面倒
まあ大した問題でもないんだけど

2018/10/01(月) 17:20:37.02

moveセマンテックが必要になった理由を理解してないのが多くて驚くばかりだな
破壊して良い中間オブジェクトとそうじゃないのとを区別するために必要なのだよ
ポインタ使えばmove必要ないとかそういう問題じゃない

2018/10/01(月) 17:40:58.61

元はといえば禿が左辺値参照でもconstつければ右辺値を指せるという曲がった話を始めたのが
評判悪くてC++11でやっとやっとやっとやっとメスが入ったのが本当の理由

2018/10/01(月) 18:05:01.87

>>872
色んな話題が出てるので混乱してるが、ムーブ不要論を出してる側の *元々の* 主張は >>846 の通り
「ちゃんとした所有権の管理 (たぶん Rust みたいなやつのこと？) が有りさえすれば」
であって、でもそれは C++ ではもはや無理でしょということもわかった上だと思う。

2018/10/01(月) 18:05:54.55

Cにも欲しいわ
Cは参照ないから右辺値指示ポインタで

2018/10/01(月) 18:09:04.02

それを言うなら、右辺値の概念を撤廃すべきでしょ

どんな値もポインタで指すことができ、
ポインタで指すことでregister指定を解除されるという変更

2018/10/01(月) 18:12:32.93

テンポラリーオブジェクトなくすと、一回必ず厳密に生成してから仕様になるので、手間増えると思う。

2018/10/01(月) 18:40:21.84

右辺値がないと int i = 0; すら書けなくなるんだが

2018/10/01(月) 18:50:50.76

なんで？

int j;
j ^= j;
int i = j;
左辺値でも問題ないじゃん

2018/10/01(月) 18:54:00.22

>>879
苦しいねーw

2018/10/01(月) 19:00:24.21

0 以外はどうすんの。

2018/10/01(月) 19:02:25.38

> j ^= j;
はい未初期化値を使ったから未定義動作で鼻から悪魔

2018/10/01(月) 19:04:34.50

char buf[1];

int i = (int)(buf[10] - buf[0]);

で、i = 10 に初期化される。

2018/10/01(月) 19:05:56.72

NaNのときはxorは未定義か、そこまで考えなかったな

2018/10/01(月) 19:06:32.55

>>883
間違った。正しくは：

char buf[1];

int i = (int)(&buf[10] - &buf[0]); // i = 10 と等価。

2018/10/01(月) 19:11:01.98

そもそも=の無理やりなオーバーロードや引数に対する暗黙的なattainが問題なんだろう。
しかし元々のcのシンタックスを引き継ぎつつ、上記の問題を解決するのは不可能。

2018/10/01(月) 19:14:47.64

>>885
10
0
&buf[10]
&buf[0]
&buf[10] - &buf[0]
(int)(&buf[10] - &buf[0])

右辺値だらけ
やりなおし

2018/10/01(月) 19:19:47.07

>>881
別に？

int *j;
j = &10;
int i = *j;
てだけじゃん

10が左辺値だったらって話ね

char *j;
j = "\n";
int i = *j;
て話と何か違うの？

2018/10/01(月) 19:23:45.27

10が左辺値ならこれ認めるの？
10 = 42;

2018/10/01(月) 21:57:05.81

お前らがC++で作ったことあるものリスト化して

2018/10/01(月) 22:37:33.40

>>889
全然かまわん
int a = 10;
int b = 10;
a = 42;
こう言っているに過ぎない

2018/10/01(月) 22:42:30.92

>>878
そろそろ答えてもらおうか
なぜ右辺値がないと int i = 0; が書けないのか

2018/10/01(月) 23:15:35.29

>>874
ていうか所有権などという中途半端な概念にオブジェクトの解放を担わせるのは危険か無意味かのどっちかにしかならない
最後までオブジェクトを使いたい人と、そのオブジェクトを所有する人を
コードに所有権を明示するスタイルで一致させられるケースは少ない

希ガス

2018/10/01(月) 23:21:45.86

しかしながら右辺値参照を使うとコードを書く人がオブジェクトの所有権を意識せざるを得ない
これを抽象化といわれるとかなり違和感

※ 個人の感想です

2018/10/01(月) 23:31:19.12

結局ネストしたオブジェクトってのはどう扱おうと楽な扱いなんてできんってことなんだわ。
同期と効率と安全性を全て容易にするってのは不可能なんじゃないかね。

2018/10/01(月) 23:41:31.83

>>895
>結局ネストしたオブジェクトってのはどう扱おうと楽な扱いなんてできんってことなんだわ。
いや？
オブジェクトの所有権は最初のcallerががっちり掴んでオブジェクトを使うcallee以下は生ポでおk

全てが調和する