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/25(火) 13:48:52.76

そういえば以前ここで似たようなこと言ったら
「愚者は経験に学び、賢者は歴史に学ぶ」とか言われたなw
ああいうアホになるんだよ、言語の知識だけに閉じこもって何も開発せずにいると

2018/09/25(火) 20:49:31.31

人は繰り返し、神は再帰する

2018/09/25(火) 21:21:29.13

>>743
＞MISRA-C++
そんなものがあるのですか？

2018/09/25(火) 21:28:11.49

>>746
ggrks

2018/09/25(火) 22:53:16.70

>>689
>(Java でいうところの) インターフェイスは型の性質を事前に網羅しなきゃ
>全体のデザインが定まらない。
無いメソッドを呼べる言語は存在しないからこれは仕方が無い（ジャバに限らん
ジャバに限らずインターフェースには利用者が絶対呼ぶメソッドだけではなく、
呼ぶかもしれないメソッドも全部packing listに入れねばならない点が無駄が大きい

その代わり、インターフェースのメソッドはビルド単位内で一意な名前（インターフェース名）で
（直接的あるいは間接的に）修飾されるから、同じメソッド名で違う機能のやつがあっても
衝突せず、安全性が保たれる
テンプレートはこの点だけがちょっと劣る
これ以外にテンプレートに欠点など無i

2018/09/26(水) 00:16:16.58

バイナリインターフェースが重要なシステムもあるわけで

2018/09/26(水) 13:25:47.21

C++とシェルスクリプトの違いって何ですか？
シェルスクリプトで出来ることでC++ができないこと
C++が出来てシェルスクリプトで出来ないこととかそういう具体例を教えてほしいです。

2018/09/26(水) 13:28:14.24

>>750
個人的に上げるとしたら、webのフロントエンド分野はインタプリタに勝てないと思います

2018/09/26(水) 13:35:28.26

比較の対象が違い杉

2018/09/26(水) 13:35:54.34

>>750
C++はコンパイルしないと動かない。シェルスクリプトはファイルの操作やバッチ処理が得意。

2018/09/26(水) 14:01:36.87

>>750
デバドラをスクリプトで書いてみてくれ

2018/09/26(水) 14:29:30.26

>>750
桃白白とラウチェン、マジンガーＺとテコンVぐらい違う。

2018/09/26(水) 14:43:50.80

>>750
GUI使ったアプリはシェルスクリプトでは無理

2018/09/26(水) 14:51:55.15

>>753
確かにファイルの操作はそうですね
>>754
確かにそういう分野はCですね
>>755
例えが古くてパッとしませんでした‥
>>756
確かにOSにインストールするものはそうですね

**デフォルトの名無しさん** (JP 0Hd6-Y82R) · 2018/09/26(水) 15:12:38.31

C++というかオブジェクト指向の質問かもしれないんですけど
エクセルにデータを書き出すためのクラスがありましてメソッドがざっとこんな感じ

・データをファイルから読み込む
・シート作成（ここで以下のメソッドを呼び出す）
・シートAに書き出す
・シートBに書き出す
︙
・シートEに書き出す

全体で1000行ほどなんですけど、例えばシートに書き出す共通部を親クラスにして、
それを継承した各シート毎に書き出すクラスを作るみたいなこと考えてます。
ただ正直あまり意味が無いような気もするんですよ。クラスと言うには小さすぎるものになりそうですし。
何行超えたらでかいだろとか何行なんてクラスとしては小さすぎるだろみたいなラインってありますかね

2018/09/26(水) 15:23:36.10

それは単に

メソッドシート作成（）{
シートAに書き出す
シートBに書き出す
︙
シートEに書き出す
}

ということ？それとも

class A {
メソッドシート作成（）{
シートAに書き出す
}

class B {
メソッドシート作成（）{
シートBに書き出す
}

ということ？
前者ならクラス分ける意味がないと思うが。

2018/09/26(水) 15:33:15.98

>>756
Tcl/Tk の立場は？

2018/09/26(水) 19:56:11.35

クラスは行数じゃなくて意味的にまとまってるかどうかだからな
意味のあるメンバがまとまってれば1万行の単一クラスがあってもいいし
デタラメに寄り集められた50行の粗大ゴミクラスもある
そういうもの

2018/09/26(水) 20:09:57.19

>>761
数字が逆じゃないか？

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 要らないじゃん