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/26(水) 20:16:07.55

>>758
>何行超えたらでかいだろとか何行なんてクラスとしては小さすぎるだろみたいなラインってありますかね
ないよ
機能で分けれ

>例えばシートに書き出す共通部を親クラスにして、
>それを継承した各シート毎に書き出すクラスを作るみたいなこと考えてます。
「書く内容を決める」機能が「シートに書く」機能を継承するなんてナンセンス
どのシートに書くかなんて「シートに書く」機能に引数で渡せばいいだけ

2018/09/26(水) 20:55:21.65

>>762
あってるよ
50行でも粗大ゴミは作れちゃうんだよ

2018/09/27(木) 00:26:48.70

さすがに一万行でまとまってるクラスってのはないわ。。

2018/09/27(木) 00:28:50.85

もしかして知恵遅れは
なんか書くために毎度毎度ofstreamを継承すんの

もしかして知恵遅れは
なんか読むために毎度毎度ifstreamを継承すんの

さすが

2018/09/27(木) 00:36:33.47

例えば、基本クラスに出力クラスを作って、
派生クラスに、プリンター・PDF など、機能が異なるならオブジェクト指向だけど、

機能が同じなら、派生クラスではない。
単に、属性・メンバ変数が変わるだけ

2018/09/27(木) 00:50:27.91

void aho::write(ostream& aho) const {
aho << "aho" << endl;
aho << "baka" << endl;
aho << "manuke" << endl;
}

こんな感じで作っとけば
いろんなもんに書ける可能性がある

抽象化をうまく利用するというのは
こういうことだからな

**デフォルトの名無しさん** (JP 0H2b-tojA) · 2018/09/27(木) 05:39:28.23

江添亮に匿名で質問ができて、高確率で答えが帰ってくる空間ってもうないのでしょうか

2018/09/27(木) 07:33:12.06

本人のtwitterにでも投げれば？
高確率で「質問ではない」が帰ってくるが。

2018/09/27(木) 07:58:37.31

>>750
シェルスクリプトだけではシェルスクリプトを解釈実行することはできない
C++からならできる
つまりシェルスクリプトだけでは金輪際できない仕事というのは少なくとも1つある

もっともこの宇宙自体がシェルスクリプト上で走っているシミュレーションなら話は別やが…

2018/09/27(木) 08:51:58.83

c++はコンパイラいるやろが

2018/09/27(木) 09:07:42.86

そんな規約あったっけ？
Cling とか CINT はパチモノ？

2018/09/27(木) 13:29:28.75

>>768
そういうのは、templateのほうがいい。ostreamに依存せずにすむ。

2018/09/27(木) 16:27:38.79

766からの流れでそうなっただけだろ

2018/09/27(木) 16:47:26.94

俺には誰一人として標準のstreamクラスを継承する話はしてなかったように思えてならないんだが
(最初の>>758も書き出す処理を継承で共通部分と個別部分に分ける案を問うているだけ)
なんでそういう話になってるんだっけ

2018/09/27(木) 20:48:20.83

>>776

>>758
＞全体で1000行ほどなんですけど、例えばシートに書き出す共通部を親クラスにして、
＞それを継承した各シート毎に書き出すクラスを作るみたいなこと考えてます。

書き出す共通部をまとめたクラスというのは
ファイルで言えば ofstream みたいなものなのであろうと皆疑ってるんだろう。
「みたいなものではない」という、結論が違ってくるような違いも提示されないし。

2018/09/27(木) 20:54:25.22

関数にすると不味いことある？

2018/09/27(木) 21:00:15.42

>>777
そうなのか……ありがとう
俺はostreamを引数に取る関数オブジェクトを多態やprotectedを使って実装するみたいなイメージで読んでた

2018/09/27(木) 21:09:44.86

最初にクラスを設計し始めるのは筋が悪いと思ってる。そんな3流プログラマ。

2018/09/27(木) 23:22:58.17

訂正；
△：シェルスクリプトだけではシェルスクリプトを解釈実行することはできない
○：シェルスクリプトがあるだけではシェルスクリプトの解釈実行を開始することはできない

シェルスクリプトはもちろんシェルスクリプトから呼ばれるシステムコールその他の
一切合財をシェルスクリプト上だけでシミュレートする能力がある（と思う）が
全ての始まりを起こすのにC/C++で書かれたOSを要する

>>780
つまりクラスの設計はおくらすのが正しい

2018/09/27(木) 23:59:38.23

来たよ、暇なので

2018/09/28(金) 09:32:22.81

最新のC++コンパイラが使えないので質問。
右辺値参照が仮引数になっている以下のような関数があった場合、

aaa(左辺値の変数);

とすると、ちゃんと、aaa() は呼び出される？
それともエラーになる？

void aaa(T&& a)
{
　　・・・
}

2018/09/28(金) 09:39:47.21

>>1のオンラインコンパイラを使おう

2018/09/28(金) 09:40:07.87

>>783
呼び出される。
lvalue は rvalue にもなる。

2018/09/28(金) 09:48:18.84

>>784
どこにあるの？

2018/09/28(金) 09:53:42.38

では、aaa()に次のようなoverloadがある場合は、「2」の方が呼び出されて、
#if の部分を 0 にすると、「1」が呼び出される？
だとすると、昔のC++では無かったような overloadの仕様かも？

T b;
aaa(b); // bは左辺値のつもり

void aaa(T&& a)
{
　　puts("1, 右辺値参照、T&& に来たよ。");
}

#if 1
void aaa(T& a)
{
　　puts("2, 左辺値参照、T& に来たよ。");
}
#endif

2018/09/28(金) 10:13:48.61

>>787
>>784

2018/09/28(金) 10:23:34.25

>>783
呼び出されない
右辺値参照は左辺値を受け取らない（原則）

ただしTがテンプレート仮引数の場合と、auto&&の場合は、
右辺値参照で左辺値を受け取れる（特例）

型を推定させた場合に限り、右辺値参照は、
左辺値参照への左辺値参照に変形できる

2018/09/28(金) 10:32:29.28

[Compile and Execute C++11 Online (GNU GCC v7.1.1)]
https://www.tutorialspoint.com/compile_cpp11_online.php
で下の方のコードを試したら、

$g++ -std=c++11 -o main *.cpp
main.cpp: In function ‘int main()’:
main.cpp:18:10: error: cannot bind rvalue reference of type ‘TPerson&&’ to lvalue of type ‘TPerson’
　　 aaa(b); // bは左辺値のつもり
　　　　　^
main.cpp:8:6: note:　 initializing argument 1 of ‘void aaa(TPerson&&)’
void aaa(TPerson && a)
　　　^~~

というエラーになった。gcc 7.1.1 では、>>785 の言ってくれたことと合ってない？？？

2018/09/28(金) 10:33:03.33

>>790
[続き]

#include <stdio.h>

struct TPerson {
　int m_age;
};

void aaa(TPerson && a)
{
　　puts("1, 右辺値参照、T&& に来たよ。");
}

int main()
{
　　printf("Hello, World!\n");
　　
　　TPerson b;
　　aaa(b); // bは左辺値のつもり

　　return 0;
}

2018/09/28(金) 10:35:31.98

あれ？ごめん。
確かめたら呼び出されなかった。

勘違いしてたかも

2018/09/28(金) 10:39:58.90

あ、逆の場合と混同してた。
const T& に rvalue がマッチするんだった。

このあたりのルール、なんか一貫性がない感じがする。

2018/09/28(金) 10:40:42.82

>>792
でも、以下の std::move() の実装の説明だとあなたの言ってる方が正しい気がする。

https://stackoverflow.com/questions/36206764/understanding-the-code-for-stdmove
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2027.html#Move_Semantics

The move function really does very little work. All move does is accept
either an lvalue or rvalue argument, and return it as an rvalue
without triggering a copy construction:

template <class T>
typename remove_reference<T>::type &&move(T &&a)
{
　　return a;
}
It is now up to client code to overload key functions on whether
their argument is an lvalue or rvalue (e.g. copy constructor and
assignment operator). When the argument is an lvalue,
the argument must be copied from.
When it is an rvalue, it can safely be moved from.

2018/09/28(金) 10:44:16.75

>>789
なるほど、std::move() は、あなたの言ってくれた、template の場合に当たるから
こその動作だったんだ・・・。

2018/09/28(金) 10:49:49.55

>>793
template の場合と、auto の場合は、まさに、一貫性が無いということらしい。

こういう一貫性の無さのことを「直交性が低い」と言って、言語が分かりにくい
指標になるらしい。

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のアドレスを得なければならない