C++相談室 part131 [無断転載禁止]©2ch.net

2017/07/29(土) 11:28:28.97

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

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

前スレ
C++相談室 part130
http://mevius.2ch.net/test/read.cgi/tech/1490917669/

このスレもよろしくね。
【初心者歓迎】C/C++室 Ver.100【環境依存OK】
http://echo.2ch.net/test/read.cgi/tech/1478440682/

■長いソースを貼るときはここへ。■
　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

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

2017/10/07(土) 08:31:55.56

あ、すまんちょいミスった
指摘できるやついる？解説頼むわ

2017/10/07(土) 08:41:11.20

>>906
unique_ptrあんまりしらんから想像で書くけど
そいつがデストラクタまで管理したいからvoidじゃなくてちゃんと型渡せってことじゃね

2017/10/07(土) 09:00:22.02

>>906
> エラーになる理由を教えて下さい
void 型の変数なんてないから
そもそも何をしたいんだよ...

2017/10/07(土) 09:03:55.62

unique_ptr<void>という型なので、
中にtypeというメンバーがあることがコンパイラからはわからない。

static_cast<Structure*>(structure.get())->type = "HogeHoge";
のように明示すればコンパイルだけは通るかと思ったんだが、
こっちだと>>911の問題に引っかかって、その前の行でエラーになる。

2017/10/07(土) 09:27:45.88

>>913の最後の行は勘違いだった。
こちらの環境だと、unique_ptr<void>の時点でエラーになる。

◆QZaw55cn4c (ﾜｯﾁｮｲ 3a60-GAVN) · 2017/10/07(土) 11:35:23.13

unique_ptr<void *> だとどうなる？

2017/10/07(土) 11:58:47.95

>>913
delete できないからね
voidを渡すんならカスタムデリータもセットにしなきゃならない。

template <typename T>
struct vp_deleter {
void operator ()(void *p)const
{
delete static_cast<T*>(p);
}
};

std::unique_ptr<void, vp_deleter<int>> a(new int(8));

なら通った。

2017/10/07(土) 12:19:56.83

void型なんて定義もなければサイズもないから
素で使うがそもそもNG

2017/10/07(土) 12:36:08.56

>>907
anyは知りませんでした
stdじゃなくてboostにあるんですね　つかってみます
>>909
つまり void*->type は void.type になるってことですね
voidポインタは使ったことなくて、あれから調べたのですが
アクセスする前にキャストが必要だと知りました・・
無知ゆえの初歩的なミスです　指摘ありがとうございます
>>911, >>913, >>916
スマートポインタなのでデストラクタを呼び出せるようにしないといけないんですね
カスタムデリータは知りませんでした　コード参考になります

void型なのはStructureの他にもプリミティブ型とかも入れたかったからです
boost::any使うやり方とカスタムデリータ渡すやり方両方やってみます
皆さんレスありがとうございました

2017/10/07(土) 13:41:40.48

ひとつのカスタムデリータでいろんな型をdeleteするってなら無理

2017/10/07(土) 14:16:25.95

いまだにforkとthreadの動作の違いがわからない

2017/10/07(土) 14:17:50.50

ある配列がありそれを指定した順番で並び替えしたい

std::vector< any_struct_t > array; //これを並び替えたい
std::vector< unsigned int > index_list = { 3,8,6,0,2...}; //この順番にしたい

探しているんだけど適当なライブラリが見つからない
標準ライブラリに入ってたりする？
またはアルゴリズムが知りたい
出来ればswap回数が少ない方法が知りたい

2017/10/07(土) 15:34:33.81

配列もう一個用意してその添え字に移動するんじゃだめなん

2017/10/07(土) 16:00:10.47

>>922
それが一番速そうだよね

2017/10/07(土) 16:14:50.00

std::vector<any_struct_t> ret(index_list);
std::transform(index_list.cbegin(), index_list.cend(), ret.begin(), [&array](auto i){ return array[i]; });

2017/10/07(土) 16:25:34.07

>>924
それタイプミスあります？
でももう一つ配列を用意してコピーする点では
他の方と一緒ですね

別配列を用意せず全てswapで済ます方法も作ってみましたが
これにはindex_listが更に2本必要になり
効率は別配列と変わらないと予想される結果でした

参考になりました
ありがとうございました

2017/10/07(土) 16:38:58.22

一行目初期化はsizeだった
すまん

2017/10/07(土) 16:55:14.57

>>925
別領域を全く使わずin-placeでかつ汎用性のあるやり方ってすごく難しそう。
でも不可能性の証明も難しそうなんだよな。

2017/10/07(土) 17:23:03.40

index_list に含まれる値がそれぞれ重複なく1回だけ出現とか、
いかにも破られそうな条件を暗黙に期待するライブラリ、
てのも変な感じだしねぇ。

2017/10/07(土) 17:39:38.90

任意の置換は互換の積で表せるので、swap繰り返せばin-placeで可能。
http://rikei-index.blue.coocan.jp/senkei/teigi4senkei.html

2017/10/07(土) 17:47:14.55

>>906
https://ideone.com/j7lHlZ
こういうことでしょ？

2017/10/07(土) 18:00:13.73

>>929
まだやってない場所どこだっけ？

2017/10/07(土) 18:14:41.26

>>927
「別領域を全く使わず」を見落としてたすまぬ

2017/10/07(土) 18:35:30.53

「別領域を全く使わず」とはいっても、テンポラリの変数を１個とか２個の固定数だけ使うのは除く。

2017/10/07(土) 19:11:01.43

屁理屈を言うと、index_listを壊していいなら、
以下の手順で別領域を使わない置換は可能。遅いけど。
for( size_t i = 0; i < array.size() - 1; ++i )
{
std::swap( array[i], array[index_list[i]] );
std::swap( index_list[i], *std::find( index_list.begin()+i+1, index_list.end(), i ) );
}

2017/10/07(土) 19:26:56.50

おっと、index_list.begin()+i+1の「+1」は消してくれ

2017/10/07(土) 19:44:23.58

この話をきっかけに、std::next_permutation　の仕様を見てみたが、どういう時に使うのかよくわからない。

2017/10/07(土) 20:14:16.81

流石にO(n)は維持しないと
厳しいと思います

**片山博文MZ** ◆T6xkBnTXz7B0 (ｽﾌｯ Sdfa-yc5c) · 2017/10/07(土) 20:23:01.47

お前ら、プログラム書くとき、普通にnoexceptを何回も書いてるの？

**片山博文MZ** ◆T6xkBnTXz7B0 (ｽﾌｯ Sdfa-yc5c) · 2017/10/07(土) 20:25:42.72

>>936
permutation を実装するときに決まってんだろ？

2017/10/07(土) 20:53:48.18

>>938
今までthrow()と書いてた場所には書いてるよ
むしろ、書いてないの？

**片山博文MZ** ◆T6xkBnTXz7B0 (ｽﾌｯ Sdfa-yc5c) · 2017/10/07(土) 21:02:34.40

>>940
コンパイラーのバカ。

2017/10/07(土) 21:05:19.53

>>918
any は C++17 で標準に入ったよ。

2017/10/07(土) 21:13:10.52

規格と規格じゃないものの区別も付かない低能はすっこんでて

**900** (ﾜｯﾁｮｲ 76b3-yS8h) · 2017/10/07(土) 21:13:19.89

>>908
ありがとうございます。

いくら検索しても出て来ないので、困ってました。

2017/10/07(土) 21:17:07.24

>>939
わからんがな

2017/10/07(土) 23:13:09.50

>>934
別領域を使わない置換に再挑戦。今回はO(n)のはず。
for( size_t i = 0; i < array.size() - 1; ++i )
{
size_t j = i, k = index_list[i];
while( k != i )
{
std::swap( array[j], array[k] );
index_list[j] = j; j = k; k = index_list[k];
}
index_list[j] = j;
}

2017/10/08(日) 00:16:09.42

>>946
二重ループなのにO(n)なの？

2017/10/08(日) 00:28:37.42

後出しのようで心苦しいけどindex_listを壊すのはダメだと思う。
const参照で渡すインタフェースにできないという意味で汎用性条件を満たしていない。

2017/10/08(日) 06:22:19.14

>>947
以下の2つの理由により、外側のループがn回まわる間に
内側のループの中身はたかだかn回しか実行されない。
1. 内側のループ内で処理済みのインデックスjに対し index_list[j]=j が実行される。
2. index_list[i]==i の条件が最初から満たされていた場合、内側のループは実行されない
要するに、内側のループを実行済みかのフラグとしてindex_listを使ってるだけ。
>>948
index_listを壊している時点で屁理屈なのは自覚しているんで、仕方ない。
一応、別配列にムーブする場合と比べると、
最初から正しい位置にある要素への処理が不要になるというメリットは有る。

2017/10/08(日) 11:20:44.83

>>928, >>948
ライブラリに対するオレオレ定義をいちいち開陳しなくていいよ、チラ裏にでも書いとけ

2017/10/08(日) 11:34:33.36

駄目な理由が引数を壊すってことだけなら、引数を値渡しにしてやれば、
呼び出し時に勝手にコピーされるので問題ないはず。
壊していい引数を渡す時はstd::move()すればいいし。

2017/10/08(日) 13:39:35.60

引数がconst参照＝引数の状態を変更しない(てか、できない)という意思表示
に対して
引数が右辺値参照＝引数の状態を変更する(しても文句言うな)という意思表示
というのはアリ？

右辺値参照に対する理解が曖昧なんで漠然とよく分からない(何が分かって
ないかも分からないｗ)んだが、もっと別な意思表示方法もある？

2017/10/08(日) 16:07:31.29

ほ～ん>>946の奴はちゃんと動いたわ；
ttps://ideone.com/6lwMOn

2017/10/08(日) 16:11:39.00

>>946の奴は要素[i]が内側のwhile()ループからは1回以上アクセスされないから確かにO(N)な気配、

2017/10/08(日) 23:25:19.93

右辺値参照はさっぱり意味わからんわ。

2017/10/09(月) 09:00:03.09

右辺値参照というのは、関数f()へのT型データの値渡し時に暗黙のうちに行われる（C++03までは無条件に行われていた）
　(左辺値) = (右辺値)
という代入処理において、
当該代入処理後、右辺値が関数呼び出し元によって使われなくなることが明白なとき、
　左辺値へのコピー後、右辺値をデストラクトする
という処理に暗黙のうちになっていたものを、
　右辺値から左辺値への移動
と「も」書けるようにするためのしくみ

Tに効率の良いムーブコンストラクタ（か右辺値参照を引数とする代入演算子）を定義しないとメリットが生じない
ポインタに__restrictを付けるべきかどうか悩まねばならないレベルの人用
C++03でもコンストラ・デストラ呼び出し回数削減の最適化がかかって同じような効果になるケースが多々あるから
そういうのが信用できない神経質な人向け

※ 個人の感想です

2017/10/09(月) 09:09:56.49

それで>>952の質問の答えはどうなるんだ？

2017/10/09(月) 09:20:15.73

>>957
右辺値参照には一時オブジェクトしか代入できない縛りがあるから㍉
関数fooを
　voiid foo(int&& x)
というバージョンしか定義していないとすると、
　int g_x = 10;
　foo(g_x);
がビルドが通らないのではないか；
一般的な使用を想定すれば、結局foo(const int& x)も定義必要

C++03までしか使ったこと無いから知らんけど；；

2017/10/09(月) 09:37:56.10

>>958
その場合はfoo(int(g_x));が通るから、必須ではないよ
コピーを外側で明示的にやらせることで、こっちのほうが責任が明確になるので好きという人もいる

2017/10/09(月) 10:15:14.60

必然性の無い実装都合のシンクはクソ

2017/10/09(月) 17:26:43.28

オブジェクトのコピーとかムーブのためにここまで言語仕様を複雑にしないといけないのか。おれにはさっぱり理解不能だわ。

2017/10/09(月) 17:57:29.04

俺も右辺値参照はどうかと思う
いらないよね

2017/10/09(月) 18:35:18.07

使わなくてもいいんじゃないか？
使ったことないから複雑に感じるだけで、そこまで複雑でもないよ

2017/10/09(月) 18:45:40.84

>>961
GCをもたない言語の宿命だから嫌なら性能を犠牲にするかGCを持つ言語を使えばいい

2017/10/09(月) 18:56:48.86

いやいやスマポがあるじゃない。
中級が多いプロジェクトならスマポ強制のほうが性能上がるんじゃないかと思う。

2017/10/09(月) 18:58:40.39

個人的にはC++の言語仕様の暗黒面はほとんど「参照」が絡んでいると思う。

2017/10/09(月) 19:50:58.39

ADLとか部分特殊化のマッチとかのほうが、はるかに複雑で暗黒だと思う

2017/10/09(月) 20:54:40.71

>>964
理解してないのでなにを指摘してるかさっぱり分からないが、
つまり、気取ってC++でGCっぽいことしようとして破綻してるわけだな。

2017/10/09(月) 20:56:32.03

>>968
> 理解してないのでなにを指摘してるかさっぱり分からないが、
わからないなら絡んでくるなよ...

> つまり、気取ってC++でGCっぽいことしようとして破綻してるわけだな。
全然違うし

2017/10/09(月) 20:56:47.16

>>967
そう思う。
そのへんは「ルール」でしかないけど、右辺値参照はそれ自体が左辺値参照とは違うひとつの概念だから理解可能

2017/10/09(月) 21:28:57.78

右辺値参照なんか、破壊不可オブジェクトをムーブするときくらいしか使わないような。うにーくぽいんたとか。
それ以外は参照でいいし。

2017/10/09(月) 21:45:04.70

右辺値参照の有用性を理解できない人間にとってはそもそもC++自体が無用だと思う
さっさと退散しなさい

2017/10/09(月) 21:56:43.96

ところでなんでそんなに一時オブジエクトを参照しなきゃいけないコードを書くの？
参照元を管理するのが面倒だから？　そういう人は初めからGC言語使えばよくね？　ということですか？

2017/10/09(月) 22:03:17.69

なんでとか言われても。。。
壊してもいい一時オブジェクトの場合、特別に効率的な扱いをしたくなるケースなんて山ほどある
それが分からないならC++なんて触らずにGC言語専門でやってればいいと思うよ

2017/10/09(月) 22:10:35.64

そのあたりはトレードオフなんだよ。
そりゃあ気にせずに済むなら気にしたくないが、気にしなきゃならないときに出来ることがないのはつらいって話で。

2017/10/09(月) 22:13:59.60

俺もわからん
左辺値参照ではなく右辺値参照を使った方が
良い状況ってどんなの？
あと唐突にガページコレクション出してるけど
何の関係があるの？

2017/10/09(月) 22:24:17.86

もしかしてC++で仕事したことないんですか？

2017/10/09(月) 22:25:07.16

そりゃ右辺値を束縛したくてかつconst左辺値じゃダメな場合だろ

2017/10/09(月) 22:43:46.89

んー？
結局無いんでしょ？
使うべきシチュが
そうならそう言えばいいのに

2017/10/09(月) 22:45:47.51

>>979
classの初期化はどう？

2017/10/09(月) 22:51:16.17

使うシチュエーションがない？
規格決める奴等が無駄にあーだこーだ言ってるだけとか思ってるなら病院に行った方がいいと思う

2017/10/09(月) 22:54:00.89

初期化はどう？って言われても・・
右辺値参照で初期化するのがベターな状況は
浮かびませんけど

2017/10/09(月) 22:55:12.55

>>981
と言いつつも
思い浮かばないんでしょ？
じゃあ君もワイと一緒ですね

2017/10/09(月) 23:09:59.39

んん？
右辺値を束縛したい（一時オブジェクトだから左辺値としての実体はない）
けどconst左辺値じゃダメ（中身を変更したいから）
　↑
これのどこにわかりにくい点があるというのか？
「RVOが保証されるようになったらいらない」という意見なら理解できるが・・・

2017/10/09(月) 23:14:06.35

たとえば swap の実装なんか（素朴には）moveを３回繰り返すんだから
右辺値参照の有用性は明らかだろ

2017/10/09(月) 23:16:20.29

>>973「なんでそんなに一時オブジエクトを参照しなきゃいけないコードを書くの？」
　↓
>>984「右辺値を束縛したい（一時オブジェクトだから左辺値としての実体はない）けどconst左辺値じゃダメ」
　「これのどこにわかりにくい点があるというのか？」

これがアスペというやつか

2017/10/09(月) 23:20:00.09

>>986

は？
>>979に言ってるんだよ

2017/10/09(月) 23:25:56.07

>>985
これを右辺値参照Verに書き換えて
利点を示してもらえますか？

void swap(int& a,int& b)
{
int c = a;
a = b;
b = c;
}

void main()
{
int a = 1;
int b = 2;
swap(a,b);
}

2017/10/09(月) 23:26:35.20

>>986
そっちこそ唐突に>>793と>>984を唐突に矢印で結び付けてるけど大丈夫か？
お前の脳内の連想なんて誰にもわからないぞ

2017/10/09(月) 23:27:28.76

>>988
利点はない
intだもの

2017/10/09(月) 23:31:15.79

なら何なら利点があるの？
long long型ならあるの？
もう訳が分からないよ

2017/10/09(月) 23:32:58.04

>>991
コピーコストの大きいコンテナだったら三回も代入したくないだろ？

2017/10/09(月) 23:34:48.01

>>982
もう使わないなら右辺値参照版のコンストラクタに渡したほうがいいじゃん
そしたら、コピーが起きなくて済むでしょ？

2017/10/09(月) 23:41:18.28

>>986
右辺値を束縛したい文脈ではかわりにconst左辺値で常におkなのでは…（ていうかconstはあってもなくても良い

>>985
T型データのswapは素朴にはT型データのコピー3回＋破棄2回ぐらいが生じる
のでわ…

2017/10/09(月) 23:48:51.82

swapが頻繁に起こるような用途なら、なんではじめからポインタで管理しないんですか？

2017/10/09(月) 23:49:46.71

一時オブジェクトもglvalueなんだから
T &に束縛できればよかった

2017/10/09(月) 23:52:41.96

>>995
ヒープじゃなくてスタックで処理したいから

2017/10/09(月) 23:55:42.49

結局のところ
右辺値参照はコピーコストを削減出来るのが利点で
それぐらいしか使い道がないってことか

かつ、コピーコンストラクタよりムーブコンストラクタの方が
コストを軽く出来るクラスに限られると

struct a{ void* p; }; // これには効果が期待出来るが
struct b{ int p[65536]; }; // これには効果は期待出来ない

結論としては、やっぱいらねーやこんなのってことだな

2017/10/09(月) 23:58:36.68

後者も効果が期待できるよ
そして、コピーコストが削減できるだけってのは正しいが、いるかいらないかは人による

2017/10/10(火) 00:01:39.19

>>998

> struct b{ int p[65536]; }; // これには効果は期待出来ない

それはあんたがそんな構造をよく使うんなら正しい
よかったじゃないか、結論が出てｗ

**1001** · Over 1000

このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 72日 12時間 33分 11秒