C++相談室 part155

**デフォルトの名無しさん** · 2021/03/24(水) 12:07:15.39

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

テンプレここまで

**デフォルトの名無しさん** · 2021/04/25(日) 17:26:07.51

MKLが元々c/c++のライブラリってことも知らん輩がおるのか。。
まあ確かにnumpyやってりゃ問題はないが。

**デフォルトの名無しさん** · 2021/04/25(日) 17:43:00.50

MKLが元々c/c++のライブラリってことは知ってたが
Pythonでシングルユーザーライセンスであっても 500千円からという価格とは思わなかった
、

**デフォルトの名無しさん** · 2021/04/25(日) 17:59:18.91

>>448
生ポインタのvectorってだめなんだ
やってたかも
まあpush_backとかしなければいいんかしらんけど

**デフォルトの名無しさん** · 2021/04/25(日) 18:15:22.48

>>454
でも
「numpy with MKL が C++ より速くて」
という言葉からすれば、Pythonの時だけそれを使い、C++の時にはそれを使ってない
としか思えない。
PythonでもC++でも同じMKLを使ってて、Pythonの方がC++より
速いなんて事は有り得ないだろうし。

**デフォルトの名無しさん** · 2021/04/25(日) 18:56:01.14

>>456 だれも生ポインタのvectorがだめなんて言ってないから何か勘違いしてそう。

**デフォルトの名無しさん** · 2021/04/25(日) 19:04:09.59

>>456
ん？ダメなのはvector要素へのポインタだぞ？

**デフォルトの名無しさん** · 2021/04/25(日) 19:17:31.67

>>459
だめなのであれば、std::vectorの存在意義を否定することになりかねない。
C互換の配列およびポインタを実現するコンテナはstd::vectorだけ。
危険性を分かったうえで使う、というのが正しいかと。

**デフォルトの名無しさん** · 2021/04/25(日) 19:26:38.89

>>460
どういう意味で存在意義を否定することになると言っているんだろうか。
必要に応じて再配置してくれるのもvectorの存在意義だと思っているが？

**デフォルトの名無しさん** · 2021/04/25(日) 20:19:11.49

昔のstd::vectorは先頭アドレスを取得するメンバ関数data()がなかったのでポインタとして使うことに多少の背徳感があった

**デフォルトの名無しさん** · 2021/04/25(日) 21:16:54.88

>>453
そう

**デフォルトの名無しさん** · 2021/04/25(日) 21:20:17.62

>>459
ポインタ保持中にvectorがresizeしないなら
ポインタ保持で何の問題もない

**デフォルトの名無しさん** · 2021/04/25(日) 22:15:04.13

要素の再配置ができない場合や要素のポインタを扱う場合は、多少効率は落ちるがstd::dequeつかえば良いと思う

**デフォルトの名無しさん** · 2021/04/25(日) 22:40:08.86

>>465

> vector とは異なる欠点として deque は連続した位置のストレージに全ての要素を持つことを保証していないため、ポインタ演算を介しての安全なアクセスの可能性を排除する。
https://cpprefjp.github.io/reference/deque/deque.html

**デフォルトの名無しさん** · 2021/04/25(日) 22:44:46.90

>>466
あぁ、連続要素アクセスは確かにだめだなw

**デフォルトの名無しさん** · 2021/04/25(日) 22:50:09.53

でも、連続要素アクセスならポインタなんか使わずに範囲for分なりiteretor使った方が楽だよね

**デフォルトの名無しさん** · 2021/04/25(日) 22:51:31.52

なるべくキャッシュに入れたいって率でメモリ連続性を求めてる人たちはたぶんそれだとキツい

**デフォルトの名無しさん** · 2021/04/25(日) 22:54:28.47

Win32APIなどOS固有のシステムコールはC言語を前提に作られているので、C++でその恩恵を得たいならメモリ連続性が保証されたコンテナが必要不可欠

**デフォルトの名無しさん** · 2021/04/25(日) 23:17:48.67

APIがらみだとstd::arrayのheap使用版みたいなのが欲しくなることがあるな
vectorだと初期化が若干面倒なんだよね

**デフォルトの名無しさん** · 2021/04/26(月) 04:02:46.84

>>450
ごめんさらっと言ったけど、現在の各次元のインデックスも実行時の数値として渡す必要あるし再帰と相性悪いかも

ただ文法上、次元数に関わらず同じコードで、ってなるとテンプレートと再帰は必須だと思う

けどそこまでしても、君が書いてた一次元で除算と剰余使うのと比べてそんな速くなるとも思えんので無理せず一次元でいいと思うw

**デフォルトの名無しさん** · 2021/04/26(月) 11:25:57.38

https://wandbox.org/permlink/XpJkS3veZNwNOlaQ
気になったのでやってみた、実測(一次元、および要素数決め打ちとの)はめんどいので頼む・・

**デフォルトの名無しさん** · 2021/04/26(月) 14:15:12.52

numpy のAPIを C/C++ から使うのがお薦め

**デフォルトの名無しさん** · 2021/04/26(月) 14:59:17.98

>>473
ありがとうございます
正直 beyond me って感じですが、勉強になります
こういう再帰的な定義って STL の [] も同じなんですかね？

**デフォルトの名無しさん** · 2021/04/26(月) 15:04:19.62

>>474
これって、numpy の記法で C++ の配列を操るというわけではなく、Python (numpy) を C++ から操るということですよね？
全ての処理を numpy の機能で行なうことにすれば、全ての計算が事実上 C++ で動くことになるから速いって感じなんですかね

**デフォルトの名無しさん** · 2021/04/26(月) 16:39:19.86

>>475
いや再帰してるのは単にint[I][J][K]をint[J][K]のループ、さらにint[K]のループに(配列の参照で)分解するためにやってるだけ
(そうすればどの階層でもt[i]で書けるから

ただこれ、コンパイル時に要素数も次元数もわかってる固定長の配列でしか使えないんだよね
ポインタを要素数決め打ちで多次元配列の参照にキャストして渡すのは出来るかもしれんけど・・

まぁ要素数が実行時にしか分からなくても使える一次元での計算のが汎用性高いと思う

**デフォルトの名無しさん** · 2021/04/26(月) 17:57:15.41

C++なんだし
多次元コンテナ使おうよ

**デフォルトの名無しさん** · 2021/04/26(月) 18:43:48.56

皆さまコロナ禍いかがお過ごしでしょうか
ちょっと質問させてください

特定のクラス内部で自身の型を格納するコンテナを実体として確保し、そのコンテナから入れ子状？のような形で使用しています
私の環境では動くのですが、これを動かしても安全なのでしょうか？
クラス内部には自身の型を確保できないと聞いたことがあります……
問題が起きそうな気配がしなくもない感じがしますが
当方素人です

class hoge{
Int a;
bool b;
vector<hoge> hoge_vec;
};
このクラスを
hoge Tochigi;
Tochigi.hoge_vec[0].a=315;
というように使っているのですが……

**デフォルトの名無しさん** · 2021/04/26(月) 19:13:39.09

ビルド通る？

**はちみつ餃子** ◆8X2XSCHEME · 2021/04/26(月) 19:25:06.15

>>479
問題ない。クラスは自分自身を内包できないが、
それは自分を内包した自分というものが可能だとすると
大きさが無限になってしまって確定できないからで、
参照やポインタとして持つ分にはそういった問題にならない。

std::vector の実体としてはヒープに確保した配列に要素を入れていく形になるので、
この場合に hoge が hoge を内包しているわけではない。

**デフォルトの名無しさん** · 2021/04/26(月) 19:35:48.39

>>481
ありがとうございます
アロケーターがコンテナ用の領域を確保してくれるので確保可能と言うことでしょうか？
クラス内部で要素数ゼロのvector領域を確保してメモリを予約してるのかな？
vectorの型がvector分の領域を計算できないから見た感じ不可能だと思って
どういう処理してるのか

**はちみつ餃子** ◆8X2XSCHEME · 2021/04/26(月) 19:37:27.97

>>482
std::vector が適当な大きさの配列へのポインタを持つ構造だと思ったらだいたい正しい。

**デフォルトの名無しさん** · 2021/04/26(月) 19:57:41.54

>>483
その言い方でなんとなくわかった気分になりました
連続で確保できる適当な長さの配列の先頭へのアドレスを確保してるってこと？
自身の大きさは除外してほかのメンバ変数の大きさだけを配列0番目に確保すればいいのかな

**デフォルトの名無しさん** · 2021/04/26(月) 19:58:27.26

前回も餃子さんに答えていただいた記憶
どうもありがとうございました

**デフォルトの名無しさん** · 2021/04/26(月) 20:26:32.67

いずれ共有ポインタのvectorを使いたくなるはず
GW期間中に循環参照の罠を思う存分楽しむといい

**デフォルトの名無しさん** · 2021/04/26(月) 20:32:09.29

やはりノードシステムこそ至高

**デフォルトの名無しさん** · 2021/04/26(月) 20:51:21.16

共有ポインタのvectorって何だろう？
sheared_ptrの事ですか？

**デフォルトの名無しさん** · 2021/04/27(火) 00:45:26.56

>>478
標準ライブラリは遅いから、使いたくないです

**デフォルトの名無しさん** · 2021/04/27(火) 01:07:31.65

別に標準ライブラリじゃなくて良いんだよ

**デフォルトの名無しさん** · 2021/04/27(火) 03:14:22.91

>>478
mdspan？

**デフォルトの名無しさん** · 2021/04/27(火) 08:10:53.39

多次元コンテナってもう標準ライブラリ入ってるんですか？

**デフォルトの名無しさん** · 2021/04/27(火) 08:23:06.09

なきゃ作れ

**デフォルトの名無しさん** · 2021/04/27(火) 08:28:06.32

>>493
や、>>478さんはどういう意味で仰ってるのかなと思った次第です

**デフォルトの名無しさん** · 2021/04/27(火) 08:34:35.77

良いのがあったら使えば良いし
無きゃ作れば良い

っていう感じ

多次元コンテナなんて
使い方によって最適な実装はいくらでも変わるんで
汎用性を追及するのは時間の無駄

**デフォルトの名無しさん** · 2021/04/27(火) 10:24:53.85

左辺には置けないものがある、その一覧とか例とかありますかね・・・

**デフォルトの名無しさん** · 2021/04/27(火) 10:39:34.03

例？
整数リテラル

**デフォルトの名無しさん** · 2021/04/27(火) 12:29:20.94

関数

**デフォルトの名無しさん** · 2021/04/27(火) 12:34:12.25

const

**デフォルトの名無しさん** · 2021/04/27(火) 14:47:15.34

>>496
・定数リテラル、const属性が付くもの、は置けない。
・関数呼び出しの関数()は、戻り値は、伝統的に右辺値扱いになるので左辺に置くとエラー
　になる様になっている。
　戻り値は、構造体型(クラス型/union型含む)/整数型/浮動小数点型/ポインタ型/列挙型の場合
　を想定した。
・*ptr のようなものは左辺値になるので置ける。
・変数名はconst 修飾されていないなら置ける。
・構造体変数名.データメンバ名は const 修飾されていないなら置ける。
・「関数名」は置けない。これは関数呼び出しの関数()とは別の話。
・&x は置けない。理由としては右辺値であるから。constでもあるが。
・x + y は、組み込み演算子の場合でも、関数呼び出しに置き換わった場合でも
置けない。後者の場合は、関数の戻り値が置いてあるということになるが右辺値だから。
　前者の場合は、右辺値だからだと思う。

**デフォルトの名無しさん** · 2021/04/27(火) 14:48:40.00

>>500
>・構造体変数名.データメンバ名は const 修飾されていないなら置ける。
これについては、構造体変数名が、右辺値の場合は、
構造体変数名.データメンバ名も右辺値になるため、置けない。

**デフォルトの名無しさん** · 2021/04/27(火) 15:10:33.44

[続き]
・(cast)x は置けない。理由は、右辺値になるから。
なので、int i; (char)i = 5; はエラーになる。
　そうしたい場合は、*(char *)&i = 5; と書く。

**デフォルトの名無しさん** · 2021/04/27(火) 17:53:11.42

配列を要素展開して、可変長引数の関数に渡したいんですけど、どうかけばいいか分かりません

template<typename... Ts>
void g(Ts... ts){}

template<typename T,size_t N>
void f(T (&a)[N])
{
g(a[0],a[1],a[2]/* なんて書くのか*/);
}

**デフォルトの名無しさん** · 2021/04/27(火) 18:30:39.66

>>502
(char &)iでええやん...

>>503
index_sequence

**デフォルトの名無しさん** · 2021/04/27(火) 19:37:01.40

>>504
ありがとう出来ました

**デフォルトの名無しさん** · 2021/04/27(火) 19:58:19.96

通常クラスのコンストラクタにテンプレート引数がある場合ってどう呼び出したらよいでしょう？

class Test{
public:
template<class T>
Test() {}
};

Test test = Test::Test<int>();
で呼び出せるかと思ったのですが出来ず...

class Test{
public:
template<class T>
Test(T dummy) {}
};

コンストラクタに引数を持たせると、msvcでは一応できました。
Test test(0);

**デフォルトの名無しさん** · 2021/04/27(火) 20:39:05.42

代入演算子ってメンバ関数じゃないとだめなんだな
thisを返すから当たり前だが、オーバーロードしたいとき困る
a = b を意味する assign(a, b) を作るしかない？

**デフォルトの名無しさん** · 2021/04/27(火) 21:47:32.08

別にthisを返す必要もないけど

**デフォルトの名無しさん** · 2021/04/28(水) 00:01:05.47

thisがどうのじゃなくてコピー代入演算子とムーブ代入演算子が特別扱いだから

**デフォルトの名無しさん** · 2021/04/28(水) 02:07:16.16

>>506 https://timsong-cpp.github.io/cppwp/n4861/temp.arg.explicit#8
> [Note: Because the explicit template argument list follows the function template name, and because constructor templates ([class.ctor]) are named
> without using a function name ([class.qual]), there is no way to provide an explicit template argument list for these function templates. - end note]

**デフォルトの名無しさん** · 2021/04/28(水) 03:41:16.44

unique_ptrって、unique_ptr<T>とuniqu_ptr<T[]>が、1つのテンプレートではなく、
テンプレート自体が別に用意されてるんだよね？
そもそも前者の規則と後者は使う時の記号としても違っていて、前者は、
unique_ptr<int> a = new int;
*a = 5;
と書くのだから、a は、int*、つまり、intへのポインタのように振舞う。
この規則のままであるなら、
unique_ptr<int[]> b = new int[10];
と書いた場合、b は、int[10] へのポインタ、つまり、int (*b)[10] のように
振舞わなければならない。
となると、
b[idx] = value;
とは書けずに、(*b)[idx] = value; と書かねば成らないが、実際にはそうではない。

**はちみつ餃子** ◆8X2XSCHEME · 2021/04/28(水) 05:20:55.28

>>511
> テンプレート自体が別に用意されてるんだよね？

特殊化で配列の場合は特別に用意されている。

> unique_ptr<int[]> b = new int[10];
> と書いた場合、b は、int[10] へのポインタ、つまり、int (*b)[10] のように
> 振舞わなければならない。

(そのように b を初期化することは出来ない (生ポインタを受け取るコンストラクタには explicit が付いてる) が、意図はわかるのでとりあえずわきに置く。)
new int[10]; という式の型は int* なので、この時点で配列の大きさに関する情報は失われている。
(配列の先頭要素を指す生ポインタではなく) 配列を指す生ポインタのようにスマートポインタを抽象化する意味がない。
どうしてもやりたければ std::array と組み合わせればいいし。

**デフォルトの名無しさん** · 2021/04/28(水) 12:25:48.23

>>512
すまん。正しい書き方は：
unique_ptr<int[]> b(new int[10]);　//(1)
だったようだ。
ちょっと意図が伝わらなかったのか、言いたかったのは、
unique_ptr<T> a;　　//(2)
の場合、a の型は、T* のようになるのに、
unique_ptr<U[]> b;
の型は、U* のようになるので、数学の様に最初のT=U[]

**デフォルトの名無しさん** · 2021/04/28(水) 12:39:35.77

すまん、まちがって送信してしまった。
>>512
正しい書き方は：
unique_ptr<int[]> b(new int[10]);　//(1)
だったようだ。それはともかく、ちょっと意図が伝わらなかったのか、言いたかったのは、
unique_ptr<T> a;　　//(2)
の場合、a の型は T * であるかのように振舞う(T *a と宣言していたかのように振舞う)のに、
unique_ptr<U[]> b;　　//(3)
の場合、b の型は U* のように振舞うが、数学の様に(2)にT=U[]を代入してみると、
b の型は本来、T *b とした場合のように振舞うはずなので、数学的には U (*b) [] とした
場合の型になっていなければならないはずなのに、実際には、U *b のようにした場合
の型になっているということで、(3)は数学的には (2)の特殊形とはみなせないということ。

なので、unique_ptr<U[]>のテンプレートは、unique_ptr<T>のテンプレートとは別に人間が
意図的に専用のコードを書いて「特殊化」していることの証拠となるということ。
もちろんそれが「テンプレート特殊化」という仕組みで行われていることは知っているが、
数学的な意味で(2)を一般形とみなした場合の自動的な特殊形にはなってないということ
(だからこそ「テンプレート特殊化」で特殊な場合だけを例外的に特記するのではあるが)。
これは、unique_ptr<T>は、Tが配列型の場合は、Tがその他の場合と比べて
「一般性を失っている」と言える。
一般性を失っていることは、言語として分かりにくくなってしまうと俺は思うんだ。

**デフォルトの名無しさん** · 2021/04/28(水) 12:44:49.64

「数学的に」
数学を知らないヤツがよく使う言葉

類義語
「物理的に」

**デフォルトの名無しさん** · 2021/04/28(水) 12:56:00.95

規格的にってのも仕事ができない言語厨がよく使ってるw

**デフォルトの名無しさん** · 2021/04/28(水) 12:57:27.64

>>515
「数学的に」と書いたのは、法則に従った「規則変化」しているということだ。
言語仕様で決まっているとかではなく、記号パターンで「導出」されるというか。
「代入」の概念というか。
優先順位のために、U (*b)[] のような記号になっているが、これも数学的に
演算子が演算される順序に従って「平坦」に書くと
b --> * --> [] --> U
となる。読み方は、一番左の b の部分以外が右から順に
bの型は「Uの配列へのポインタ」
となる。ちなみに、
T b の場合は、
b --> T
となり、読み方は、
bの型は「T」
となる。

**デフォルトの名無しさん** · 2021/04/28(水) 12:58:27.74

>>515
ちなみに、俺は数学記号に関するIQは200を越えている。
トータルでも150以上。

**デフォルトの名無しさん** · 2021/04/28(水) 13:01:24.71

>>517
もう少し噛み砕いて書くと、コンパイラ内部では、
U (*b)[];
という宣言は、優先順位に従って、
b --> * --> [] --> U
となり、コンパイラ内部では左から順に
「bは、ポインタ(*)であり、その元の型は、配列([])であり、その元の型は、
　U である」
と理解している。

**デフォルトの名無しさん** · 2021/04/28(水) 13:04:48.90

>>519
b --> * --> [] --> U
は、英語で読むと、左から順に、
「b is a pointer(*) to array([]) to type U.」
と読めて、言葉と記号の順序が一致する。

**デフォルトの名無しさん** · 2021/04/28(水) 14:25:22.22

void hoge(){
　vector<int> a(10);
　vector<int*> p(10);
　for(int i=0; i<10; i++) p[i] = &a[i];
　// play with a and p
}

っていう関数で a とか p に対してやったらやばい操作ってどんなんですかね

**デフォルトの名無しさん** · 2021/04/28(水) 14:41:21.61

数学記号に関するIQて何？

**デフォルトの名無しさん** · 2021/04/28(水) 15:09:55.27

>>521
理屈を理解してない状態なら何やったってやばいよ
まあ、みんなやらかしながら覚えるもんだから心配せずどんどんコード書いて地雷踏んで地獄に嵌まれ
ただしプロダクションのコードだけは書くなよ

**デフォルトの名無しさん** · 2021/04/28(水) 15:12:59.93

すごい
クソゲボゴミ老害の意見
頼まれたことはできない、自分なりに行動しても何も産まない、家族と職場の全員から疎まれてるバカ
天晴

**デフォルトの名無しさん** · 2021/04/28(水) 15:14:07.47

>>510
ありがとうございます！できないんですね…

**デフォルトの名無しさん** · 2021/04/28(水) 15:21:22.38

ああなるほど、最近多い>>521みたいなのは、中で何が起こるか想像できてない(基本すら出来てない)から
いちいちこんなこと訊いてるのか・・・
何度も言ってるけど教える順番おかしいんだよマジで

>>524
自己紹介？

**デフォルトの名無しさん** · 2021/04/28(水) 15:26:21.46

>>521
pのサイズが変わるような操作はアドレスが変わる可能性があるので全てアウト

**デフォルトの名無しさん** · 2021/04/28(水) 15:27:17.73

>>527
おっと、aのサイズが～の間違い

**デフォルトの名無しさん** · 2021/04/28(水) 15:51:27.64

>>515
そうか、禿Stroustrupは数学を知らないのか

**デフォルトの名無しさん** · 2021/04/28(水) 15:52:12.82

pのサイズ変わるのもまずいよね？
勝手に new/delete されて使用不能になりえるので

**デフォルトの名無しさん** · 2021/04/28(水) 16:03:18.23

>>529
どこからそういう結論になった？

**デフォルトの名無しさん** · 2021/04/28(水) 16:04:05.01

>>530
何がまずい？
勝手にnew/deleteとは？

**デフォルトの名無しさん** · 2021/04/28(水) 16:06:25.57

>>530
晒しage

**デフォルトの名無しさん** · 2021/04/28(水) 16:18:30.85

>>530
ダメな例をコードで示してくれ

**デフォルトの名無しさん** · 2021/04/28(水) 16:28:13.84

自作クラスや構造体に対して範囲forを使うための条件って、そのクラスや構造体が
・メンバ関数としてbegin()、end()を持つ
・begin()、end()が間接参照演算子、インクリメント演算子、不等価演算子を持つクラスか構造体を返す
で合ってますか？
cpprefjp見てたら一個目の条件しか書いてなかったんですが、二個目の条件要りますよね？

**はちみつ餃子** ◆8X2XSCHEME · 2021/04/28(水) 16:35:30.69

>>535
前者の条件はコンテナの要件として書かれているが、
後者はイテレータの要件として定義されているはずだぞ。

**デフォルトの名無しさん** · 2021/04/28(水) 18:23:34.44

もう一個質問させてください
範囲for文ってfor文スコープ外の変数を使えないんですか？
int i;
vector<int> v;
// v を初期化
for(i: v){
...
}
みたいなことをしたいです

**デフォルトの名無しさん** · 2021/04/28(水) 18:36:49.45

>>535
なぜ不要だと思った？

int begin();
じゃダメだろ？

**デフォルトの名無しさん** · 2021/04/29(木) 06:49:31.89

>>531
ISBN4-7561-1895のP.500 16.1.1 設計上の制約

**デフォルトの名無しさん** · 2021/04/29(木) 06:50:25.72

>>538
最近こういうゴミ返しするバカめっちゃ増えたね、このスレ
「intじゃダメ」は「間接参照演算子、インクリメント演算子、不等価演算子を持つクラスか構造体である必要がある」を全く意味しないだろ……
一方で、ではイテレータを返せば良いのかというとそこまで条件が厳しいわけでもなくて、イテレータ「らしき」性質を持ったクラスを返せば良いということなので、この話はそこまで単純じゃない

そういうこと全く分かってないバカが場当たり的な回答をしてるのは甚だ不快ですね

**デフォルトの名無しさん** · 2021/04/29(木) 07:36:35.34

えっっ
Tをイテレータ様のふるまいを示す型として
T begin()だけではダメで
T end()も最低限定義いないといけないんじゃ……

**デフォルトの名無しさん** · 2021/04/29(木) 07:50:14.64

>>537
できない

int i;
vector<decltype(i)> v;
// vを初期化
for (auto&& j : v)
{
i = j;
// iを使用
}
のようなことになる

**デフォルトの名無しさん** · 2021/04/29(木) 08:34:23.25

>>540
反例を1個あげれば十分
あとは自分でかんがえろってこと

お前は何か役立つ回答をしたか？

**デフォルトの名無しさん** · 2021/04/29(木) 08:51:08.82

質問者がbegin()とend()の定義の必要性を把握しているのに対して
begin()のみではNGだとレスするのがそんなにﾄﾞﾔるほどのことなのかどうか……

**デフォルトの名無しさん** · 2021/04/29(木) 08:55:45.00

>>544
前者ってbeginのことだと思っちゃった？
お前日本人じゃないだろ

**デフォルトの名無しさん** · 2021/04/29(木) 09:04:34.25

>>542
ありがとうございます
v は必ずしも vector<int> ではなく vector<vector<int>> とかで、かついっぱい回るループを想定してるのでできるだけ定数倍を軽くしたいのですが、j を右辺値参照にすればコピーは起きないので相当マシと思って良いですかね

**デフォルトの名無しさん** · 2021/04/29(木) 09:07:08.51

右辺値参照つってもauto&&は左辺値参照も兼ねるぞ

**デフォルトの名無しさん** · 2021/04/29(木) 09:16:30.33

>>545
ちょっじゃあ>>538のレスのどこが反例だったの？？

**デフォルトの名無しさん** · 2021/04/29(木) 09:22:13.70

二個目の条件に反してる

**デフォルトの名無しさん** · 2021/04/29(木) 09:41:24.58

>>549
別に
https://ideone.com/VLjCjO

**デフォルトの名無しさん** · 2021/04/29(木) 10:20:12.63

https://ideone.com/bERbqr

**デフォルトの名無しさん** · 2021/04/29(木) 10:26:57.88

>>547
for()のカッコの中でiをjの参照として定義できたらそれでも良いんですが、そういうことはできるんでしたっけ？

**デフォルトの名無しさん** · 2021/04/29(木) 10:28:45.87

すみません「定義」というよりは、forのスコープの外にiの宣言はあって、for(ここ)でiがjの参照であることにできたら良いってことです