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/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

全てが調和する

2018/10/01(月) 23:46:11.02

ｱﾎどもはやっと気付いたか。。。

ｺﾀｴ：最初から普通にﾎﾟｲﾝﾀで書きなさい
　　　unique_ptr、shared_ptr、weak_ptrなんか使ってるﾔﾂﾗは
　　　ｸﾙｸﾙﾊﾟｰしかいない

2018/10/01(月) 23:49:34.85

>>894
右辺値参照周りを抽象化とか言ってるアホははちみつだけだろ

2018/10/02(火) 00:39:52.22

https://ideone.com/BBhHn8

上のコードで教えて欲しい。

templateでデフォルト引数で関数を指定する場合、わざわざテンプレートパラメーターFuncにdecltype(...)しなきゃいけないのは何故？

2018/10/02(火) 01:21:04.00

https://ideone.com/JKTYpf

testは関数名だから型じゃない

2018/10/02(火) 02:10:18.78

>>894
ムーブだのなんだの言ってても、
C++ の言語機能として直接的に有るのは rvalue 参照を区別して受け取れるってだけで、
所有権の管理をキッチリやってくれるわけではない C++ の限界なんだよね。

だけど、なるべくクラス・関数の実装の中に区別を押し込めて隠す道具のひとつにはなるって話。
でも、中途半端にやるなら隠さないで見せた方がマシという論はわかる。

2018/10/02(火) 05:46:40.59

受取る関数の側を上手く作っておけば
それを使う側では所有権の移動とかそんなに気にしなくない？
rvalue だったら勝手にちょっと効率的になる (こともある) ねってだけで。

使うときに気にしなくて良いように押し込められるならやっぱり抽象化の道具って言えると思うよ。

2018/10/02(火) 06:04:33.19

>>900
ありがとう。

template<typename Func = int (int)>
を
template<typename Func>

にするとエラーになるのは何故？

2018/10/02(火) 06:50:19.11

>>903
デフォルト引数からはテンプレート引数を推定できない制限がある。

2018/10/02(火) 07:00:39.49

なるほどです。

2018/10/02(火) 07:46:51.87

時々、イラつかされる制限だ

2018/10/02(火) 08:15:45.67

>>890
C++が得意なことを教えてください

2018/10/02(火) 10:26:10.74

>>902
いや呼び出す側に意識させるのが右辺値参照の目的だろ
意識しなくていいようなケースならconst参照で十分

2018/10/02(火) 10:31:03.15

冗談は顔だけにしろよ
たとえばstd::threadの右辺値参照なんぞ意識してるか？

2018/10/02(火) 13:13:32.45

一行目に何の意味があるのかわからん

**デフォルトの名無しさん** (JP 0H4f-ZVm4) · 2018/10/02(火) 15:51:55.37

割と昔からあるプログラムを見てるんですけど一つのメソッド内で
for(int i = 0; ……）{……}
for(i = 0;……）{……}

って書き方してるのをちらほら見ます
要は宣言してるんだから使い回せるだろみたいな理屈なんでしょうがビルドしようとすると当然未定義だとエラーが出ます
昔のC++だとこれがオッケーだったりしたんでしょうか？

2018/10/02(火) 15:56:06.09

そうだよ

2018/10/02(火) 16:33:18.83

c++で初心者が作れるものを教えてください

2018/10/02(火) 16:37:39.73

rogueとか作って見てはどうよ
SetConsoleCursorPositionとGetKeyStateがあれば何とかなるだろ

2018/10/02(火) 16:39:28.61

>>911
むしろ古い仕様だと後者の i を宣言しようとすると、
ひとつのスコープ内で同じ名前の変数を定義しようとした扱いになってエラーになったりした。

2018/10/02(火) 17:18:00.03

今のコンパイラでも当時の仕様に合わせるオプションはある

2018/10/02(火) 18:04:17.03

>>914
ありがとう

2018/10/02(火) 19:05:29.79

C++.でバッチ処理やbashのsedの様な機能はありますか？

2018/10/02(火) 19:11:57.50

システムコマンドを実行したいのならsystem関数
正規表現ならstd::regexクラス
ファイル名に関する様々なことはstd::filesystem::pathクラス

2018/10/02(火) 20:37:48.16

>>919
ありがとうございます
とても便利です

2018/10/03(水) 01:07:54.12

std::array を自作関数の引数に渡したいときって、サイズはハードコードしないとダメなの？

2018/10/03(水) 01:11:26.75

>>921
template <size_t t_n>
void my_func(std::array<data_t, t_n>& a)
{
...
}

2018/10/03(水) 01:18:33.15

>>922
なるほ
ありがとうございます

2018/10/03(水) 01:18:50.70

>>922
なるほ
ありがとうございます

2018/10/03(水) 03:04:58.67

>>912 >>915
ありがとうございました。やっぱそうだったんですね
しかし検索しても全然出てこないというかどう検索したら良いものか。C++98とかの時代になるんですかねぇ

2018/10/03(水) 05:02:16.81

>>925
たぶんそれより更に前の話だったと思う。

「c++ for文宣言スコープ」でググったらこういうのとかヒットした。
http://www.ksky.ne.jp/~seahorse/cpp/loopvar.html

D&E でも言及があって、 if 文でのルールと合わせる形で修正したという話が載ってる。

2018/10/03(水) 05:31:10.20

>>916
VC++ですら廃止予定だけど
https://msdn.microsoft.com/ja-jp/library/84wcsx8x.aspx

2018/10/03(水) 05:33:04.20

ARM (The Annotated C++ Reference Manual; http://amzn.asia/d/53K2HrA ) を確認してみたら、
「初期設定文が宣言ならば、宣言された変数のスコープは for 文を囲むブロックの終わりまでである」
というような記述がある。 (要するに古い仕様)

このあたりから C++98 になるまでの間に修正したってことなんじゃないかと。

2018/10/03(水) 07:01:52.10

>>926

キーワードと完全に同じ綴りのマクロがあると
標準ヘッダが動作保証外になる

ISO/IEC9899:2011 7.1.2 Standard headers の段落4

2018/10/03(水) 11:00:28.82

>>925
最初期の処理系、AT&T cfront の頃からの仕様だから 1980年台だと思う
ちなみに有名な Annotated C++ Reference Manual (ARM) は
この cfront のリファレンスマニュアルに注を付けたもの。

Mac II が出た頃の Mac のソフト開発者は Apple の MPW という開発環境の上で
AT&T のリファレンスマニュアル見ながら cfront で開発していた。

2018/10/03(水) 11:03:08.53

>>925
＞しかし検索しても全然出てこないというかどう検索したら良いものか。

当時まだ処理系と独立して言語仕様を策定/記述したものは存在していなくて、
上記の cfront のリファレンスマニュアルと cfront の実際の動作が c++ の仕様でした。

2018/10/03(水) 12:23:08.82

>>929
そんなもん古い環境で使うなら標準ヘッダのインクルード後に定義するに決まってるだろ
現行の標準に合わせたいけど仕方なく古い環境でも動くようにしたい場合のテクニックなんだから

2018/10/03(水) 13:10:09.63

>>932
俺だったらこう書くぜ
{ for(int i = 0; i < 1; i++) ; }
{ for(int i = 0; i < 1; i++) ; }
前提にしている環境を誤解させかねない変態コードには反対だ

2018/10/03(水) 13:21:21.77

ヘタレな俺は c 同様直近のブロックの頭で宣言してました

2018/10/03(水) 17:25:53.30

>>934
今では C でもブロックの頭という縛りは無いやで。

2018/10/03(水) 22:30:16.11

std::array ってコンパイル時にサイズが決まっていることを想定して作られてるんだよね？

だったら、「可変長ではないがサイズは実行時に決まる」というメモリが連続な配列がほしいなら生配列を使え、というのが C++ を作った人の気持ちなの？

2018/10/03(水) 23:04:38.92

それこそvectorじゃないの

2018/10/03(水) 23:19:51.08

>>936
いや、昔はイニシャライザーリストがなかったので、初期化式が使えるオブジェクトの立ち位置だった。
イニシャライザーリストが入ったのでほぼ産廃。constexprの対応もなく死んでいる。
基本的に配列っぽいものがほしかったらベクター使ってっていう趣旨だったと思う。

2018/10/03(水) 23:26:50.16

>>937-938
vector ってメモリ空間連続ですか？
だったら迷わずこれ使うんですが

2018/10/03(水) 23:29:56.10

>>939
&V[0]すると一本のメモリの先頭が取れると規格書に書いてあると聞いた。
これは、サイズを拡張するなどのメモリ変更があるまで同じものを指してると思う。

2018/10/04(木) 00:07:58.65

>>939
迷わず使っていいですよ

2018/10/04(木) 00:35:06.85

C++11からvectorのメモリ空間は連続でなければならないと規格で決められた
安心していいよ

2018/10/04(木) 00:40:31.88

>>940-942
ありがとうございます
しかしメモリが連続じゃないといけない外部ライブラリに vector 渡すの結構緊張しますね

少し飛躍するのですが、vector の入れ子は流石に連続とは限りませんよね？

2018/10/04(木) 00:58:43.11

メモリ連続させたいならvectorの入れ子はよして。

最初arrayで考えてたなら画像とか行列とかそんな感じかな？

2018/10/04(木) 01:32:01.20

>>942
太古から実際には連続だし規格として明記されたのは C++03 から。
C++11 で連続と規格化されたのは string (basic_string) の方。

2018/10/04(木) 01:57:52.21

>>944
いえ、もともとは生の一次元配列を使ってて、array の方が取り回しが良いのかなと考えただけです
実際は vector が最強ということですね

入れ子云々は本当に気になっただけです

多次元配列は、色々諦めて Boost を使っています

2018/10/04(木) 03:00:41.82

変数名とかクラス名にめちゃくちゃ毎回悩む
従業員の名前、社員番号、階級みたいなクラスを作るときのクラス名とかって普段どうしてる？
Employeeだけで良いのだろうか
DataとかInfoとか意味のあるようでないような命名が頭をよぎってしまう

仮に従業員をEmployeeとしたときに会社名と従業員リストのDictionary<string, List<Employee>>の変数名とかどうすりゃええねんってなる
CompanyではないしCompanyDataだとそれっぽいが的確でもなさそうだし...

2018/10/04(木) 03:38:58.82

emproyees でいいだろ
for (consy auto& emproyee : emproyees["Microsoft"]) ...

2018/10/04(木) 03:39:14.21

rじゃなくてlか

2018/10/04(木) 04:00:10.87

MapCompanyNameToEmployees

2018/10/04(木) 04:12:55.17

>>939
vector が連続と明記されたのは C++03 だが、
C++ 標準の体制としては仕様の「欠陥」と認められた項目については過去の版にさかのぼって適用されることがあり、
vector が連続であるというのもそのひとつのはず。

つまり、 C++98 を名乗る処理系でも vector は連続であるべきで、実際にほとんどそうなっていると思う。