C++相談室 part146

**デフォルトの名無しさん** · 2019/11/07(木) 11:35:36.76

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

前スレ
C++相談室 part145
http://mevius.5ch.net/test/read.cgi/tech/1568362404/

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

■長いソースを貼るときはここへ。■
　http://codepad.org/
　https://ideone.com/

[C++ FAQ]
https://isocpp.org/wiki/faq/
http://www.bohyoh.com/CandCPP/FAQ/ (日本語)

**デフォルトの名無しさん** · 2019/12/04(水) 22:15:09.71

> 思ったよりC++erて数いたんだなぁ、というのが素朴な感想

C++erというよりここは単に無職と学生サンのすくつでしょｗ

**デフォルトの名無しさん** · 2019/12/04(水) 22:19:24.66

とりあえず>>593は無職だと思う

**デフォルトの名無しさん** · 2019/12/04(水) 22:27:51.85

c++11以降みたいなああいうコード書きたいなら変な見栄はらずにpythonでもrubyでもやってたらいいんだよ。

**デフォルトの名無しさん** · 2019/12/04(水) 22:31:45.53

C++コンパイラやSTL準拠ライブラリを作る仕事に関わってたら規格書を読まないとどうにもならないと思うけど、
そうじゃない人は市販のC++入門で十分じゃないかな。

**デフォルトの名無しさん** · 2019/12/04(水) 22:33:17.56

>>596
金型の会社に出向いて定期的に講座やってるらしいね
金型の演算ってそんなC++が効くものなんだ
CGALみたいに幾何分野でバリバリ使われるのは知ってるけど、設計の分野も同じなんかな

**デフォルトの名無しさん** · 2019/12/04(水) 22:33:57.92

てか規格通りにまともに動くなんてのは例外ってことは
普通にc++を仕事で使ってりゃ分かるもんだがな。
その時点で江添みたいに実際の仕事で使ってないのが丸分かりになる。

**デフォルトの名無しさん** · 2019/12/04(水) 22:58:37.27

今時MSVCでも大部分は規格通り動くぞ

**デフォルトの名無しさん** · 2019/12/04(水) 23:08:27.56

>>598
どこからそんなアホな決めつけしてるんだよ…
もしかして会社からセミナーとかにも行かせてもらえないような底辺なのか？w

**デフォルトの名無しさん** · 2019/12/04(水) 23:22:31.61

式を教えてもいいけど、理解できるかどうか。

**はちみつ餃子** ◆8X2XSCHEME · 2019/12/05(木) 00:23:37.10

必要なら読むし必要じゃないならないなら読まないってだけのことだろ。
そんなん場合によるっつーつまらん結論しかないと思うが。

**デフォルトの名無しさん** · 2019/12/05(木) 00:28:04.37

はいいつものクソ正論いただきました

**デフォルトの名無しさん** · 2019/12/05(木) 00:35:44.19

実の無い（楽しそうでもない）話をつづけられるよりはクソ正論で鎮火してくれたほうがマシに思う。
件の人たちはそれで鎮火するような人でもないんだろうけど。

**デフォルトの名無しさん** · 2019/12/05(木) 00:43:36.10

互いに見下しあい罵倒しあってこそC++er
ここは不毛なマウント取り合戦の場C++スレ
鎮火する必要なし

**デフォルトの名無しさん** · 2019/12/05(木) 01:15:42.96

また髪の話をしてる

**デフォルトの名無しさん** · 2019/12/05(木) 02:59:31.66

すまんが、レベルの低い人から見ると、レベルの高い人が気軽に話した
内容が「マウントをとられた」と思ってしまうんだと思う。
そういうつもりで言ってなくても。
これは、公立の小学校でよく起きる現象で、問題になっている。

**デフォルトの名無しさん** · 2019/12/05(木) 03:04:36.20

>>611
蛇足だが、これは欧米諸国でよく知られた現象。
アメリカで記名製掲示板が流行るのは、匿名性掲示板ではどうしても
それが起きてしまうので、それをよく分かった上でやっているのかも
知れない。それだけの理由ではないだろうけど。

**デフォルトの名無しさん** · 2019/12/05(木) 06:18:49.18

>>609-610
この流れを評するのに「不毛」って言葉を選ぶのはC++らしいね。
「マウント」も落語「頭山」を想起させる。

**デフォルトの名無しさん** · 2019/12/05(木) 08:26:15.95

しかしあれだな、C++ほどハゲがよく似合う言語を知らない

**デフォルトの名無しさん** · 2019/12/05(木) 11:35:47.86

江添亮のC++入門 (webドラフト版? https://ezoeryou.github.io/cpp-intro/#再帰関数 )
を読んでます。

>例えば以下は階乗を計算する再帰で書かれたループだ。
> int factorial( int n ) { ...
> return n * factorial(n-1) ;
> ...
>このコードは末尾再帰になっている。
>末尾再帰は非再帰のループに機械的に変換できる特徴を持っている

これ factorial(n-1) が返ってきたらスタックに積んである n を掛けないといけませんよね。
厳密には末尾再帰とは言えない気がします。
そういうの無しに「直帰でコール元に値を渡せる場合」に末尾再帰と言えるのだと思ってたんですが、
私の理解が間違っているのでしょうか？

まあ今のコンパイラーは賢いので細かい事気にする必要ないのかもしれませんが。

**デフォルトの名無しさん** · 2019/12/05(木) 11:37:52.20

>>611
馬鹿ほどそれを気にするよな
判らなかったら調べれば良いのに
調べずに反論し始めるω

**デフォルトの名無しさん** · 2019/12/05(木) 12:32:19.12

>>615
末尾再帰じゃないよ

**デフォルトの名無しさん** · 2019/12/05(木) 13:51:16.60

>>617 ですよね。
ちょっと気になってたのでスッキリしました。

**デフォルトの名無しさん** · 2019/12/05(木) 18:12:34.01

簡単にループに出来るものはループで記述した方が良いよ
末尾再帰の場合もそうじゃない場合も

実行速度、使用リソース、
デバッグしやすさ、
スタック計算ツールなどツール類の使用、
などなどいろんな要素で

**デフォルトの名無しさん** · 2019/12/05(木) 18:50:53.78

>>619
本当は、再帰呼び出しだとスタックサイズの制限により呼び出しの深さ(階数)
に制限が付いてしまう。ローカル変数を沢山使っている関数で、
1000万個のオブジェクトを再帰的に処理すると、スタックオーバーフロー
が出てもおかしくない。しかも、最近のマルチスレッド環境だと、
スタックのサイズはどうしても制限が強くなり勝ち。

**デフォルトの名無しさん** · 2019/12/05(木) 18:58:39.27

一言で言うと｢使用リソース｣だね

**デフォルトの名無しさん** · 2019/12/05(木) 19:02:32.74

｢最近のマルチスレッド環境｣はあまり関係ない
固定スタックサイズの組み込みCPUの方がヤバい
PICみたいなハードウェアスタックだともっとヤバい

**デフォルトの名無しさん** · 2019/12/05(木) 19:28:34.51

検討事項が増えるから仕事で再帰は使わんね。
理解できない人も多いし。

**デフォルトの名無しさん** · 2019/12/05(木) 19:42:30.55

>>622
シングルスレッドだと、スタックは自動伸張することが可能だった。
ところが、32BIT のマルチスレッド環境だと仮想メモリ空間のアドレス
空間自体が不足してしまうので、それは難しい。
ただし、64BIT 環境だと仮想メモリ空間が大きいので余り問題にならない
かも知れない。

**デフォルトの名無しさん** · 2019/12/05(木) 19:54:34.15

再帰の例でよくでてくるフィボナッチ数列の計算なら
再帰より for で二変数保持しながら計算した方が性能でも可読性でも上だろうな。

**デフォルトの名無しさん** · 2019/12/05(木) 20:04:07.94

>>624
Windowsだとスタックサイズは32bitでも64bitでもデフォルト1MBだぞ

適当な事を言わないように

**デフォルトの名無しさん** · 2019/12/05(木) 20:10:23.46

>>625
組み込み型サイズ程度だと普通にexpを使って計算する方が速い

多倍長の巨体な値でも
素直に1個ずつ計算すると非常に遅い
もっとずっと高速な方法がある

**デフォルトの名無しさん** · 2019/12/05(木) 20:16:10.38

再帰をループに置き換えるので面倒なのは
いろんな箇所でたくさん分岐するヤツ

まあでも面倒ってだけで、
必ず再帰を使わずに記述出来る

**デフォルトの名無しさん** · 2019/12/05(木) 20:21:10.87

treeを辿るコードなんかは再帰のが書きやすいわな。

**デフォルトの名無しさん** · 2019/12/05(木) 20:23:50.71

treeをたどるコードは再帰コールするのが1箇所だからまだ楽な方

**デフォルトの名無しさん** · 2019/12/05(木) 20:24:01.37

>>629
Tree は再帰でやるべきものの一つ。
スタックの制限も、Treeの「段数(階数)」自体が余り深くなりにくいので
問題が生じにくく、再帰でやっても問題ないものの一つでもある。
ただし、親子関係の深さ方向だけを再帰にし、兄弟方向は、単純な
ループを使うべき。

**デフォルトの名無しさん** · 2019/12/05(木) 20:28:30.76

再帰にすべきかどうかはものによる
例えばstd::setの検索は普通ループを使う

**デフォルトの名無しさん** · 2019/12/05(木) 20:38:37.36

フィボナッチとかで再帰
末尾再帰を捨てる(性能とスタック無駄遣いに目を瞑る)と可読性はかなりいいと思うんです。
int fibo(int n) {
if (n<=2) return 1;
else return fibo(n-1) + fino(n-2);
}
その場で使い捨てるようなプログラムにはアリだと思います。

でも末尾再帰を目指すと.. . .
int fibo(int n, int a=1, int b=1){
if (n<=2) return b;
else return fibo(n-1, b, a+b);
}
どうなんですかね. . .。Lisp脳だと forループより好まれるかもしれません。
ちゃんと末尾再帰最適化が効けば性能は良いのでしょう。

**デフォルトの名無しさん** · 2019/12/05(木) 20:48:58.05

>>633
前半
見やすさはそれが一番だね
記述が定義通りなので

後半
それなら普通のループの方が分かりやすくないか？

**デフォルトの名無しさん** · 2019/12/05(木) 21:03:01.64

あちら(Lisp)の世界ではそうでもないみたいですよ。

**デフォルトの名無しさん** · 2019/12/05(木) 21:09:55.69

へ～

**デフォルトの名無しさん** · 2019/12/05(木) 21:23:00.63

C++てparallel_forとか未だにないんだな、まぁTBB使えばあるけど標準規格には用意されてない
仕方がないんでPartitionerは自前で作ったが、そんな付け焼き刃用意したところで、
いちいち明示的に各スレッドの終了の待ちあわせせにゃならん。
挙げ句の果てに
mtx.lock()
----
mtx.unlock()
て orz
クリティカルセクションはブロックで囲って
lock(mtx){
}
とでも書かせろや
オートunlockとかしょーもないもんは用意してバカじゃねーのか
しかも、未だにasync/await はなくて、C++20で実装て。
何が必要かわかってないのかC++規格作ってるアホ共
死ね

**デフォルトの名無しさん** · 2019/12/05(木) 21:36:40.64

つstd::lock_guard

**デフォルトの名無しさん** · 2019/12/05(木) 21:51:24.38

adync awaitなんてネイティブで実装しようとしたら面倒なのわかるだろうに

それでもぶっこんでくるのだからc++11以降は完全にポリシー変更しているよね

**デフォルトの名無しさん** · 2019/12/05(木) 21:57:53.51

>>637 std::for_each(std::execution::par, ...) じゃダメだったの？

**デフォルトの名無しさん** · 2019/12/05(木) 22:07:45.52

ツリーの巡回はイテレータにするとスタックとキューを入れ替えるだけで深さ優先と幅優先を切り替えられますよ。
STLのスタックとキューはインターフェースが違うのでひと工夫必要ですが。
algorithmも使えてウマウマです。

◆QZaw55cn4c · 2019/12/05(木) 22:28:33.56

>>615
末尾再帰ならこう書くかと
https://ideone.com/GG1x2O

**デフォルトの名無しさん** · 2019/12/05(木) 22:53:24.80

おいおい
そこはcpsで書いてマウント取るところだろ

**デフォルトの名無しさん** · 2019/12/05(木) 23:00:13.77

>>637
お前のそのクソコードlockとunlockの間で例外投げたらあっという間にデッドロックだぞ
すぐにlock_guardに書き換えるか死ぬかどっちか選べ

**デフォルトの名無しさん** · 2019/12/05(木) 23:44:19.10

状況説明：
Visual Studio 2019 Version 16.4.0 で std::exception::what() の戻り値を無視すると以下のようなC4834の警告が出るようになった。
> warning C4834: 'nodiscard' 属性を持つ関数の戻り値を破棄しています

なお、catchスコープでeについて何か書かないと以下の警告が出てしまう。
> warning C4101: 'e': ローカル変数は 1 度も使われていません。

今は以下のように記述して警告C4101が出ないようにしている。
try
{
// do something.
}
catch(std::exception& e)
{
e.what();
}

質問：
C4101とC4834の両方とも出ないようにするにはどうしたらいい？

**デフォルトの名無しさん** · 2019/12/05(木) 23:57:51.72

>>645
(void)e.what();

**645** · 2019/12/05(木) 23:58:13.71

自己解決しました。
try
{
// do something.
}
catch(std::exception& e)
{
(void)e;
}

**645** · 2019/12/05(木) 23:59:17.57

>>646
回答ありがとうございます。

**デフォルトの名無しさん** · 2019/12/05(木) 23:59:36.77

catch(std::exception&)
でええやん

**デフォルトの名無しさん** · 2019/12/06(金) 00:01:11.04

>>645 ほんとうに例外を何も処理せず握りつぶしたいの？どんな状況？

**645** · 2019/12/06(金) 00:12:07.73

>>650
スレッドの安全な終了。

**645** · 2019/12/06(金) 00:19:17.77

>>649
マクロ切り替えでeを使うコードも使えるようにしておきたいので無名変数だと都合が悪い、という感じです。

**デフォルトの名無しさん** · 2019/12/06(金) 00:24:27.98

VCは2019から返り値を捨てるコードに警告出すようになって鬱陶しい

**デフォルトの名無しさん** · 2019/12/06(金) 00:27:04.95

[[nodiscard]]を確認せずに捨てる奴が悪い

**デフォルトの名無しさん** · 2019/12/06(金) 00:30:55.24

>>651
std::exception& で受けると bad_alloc とか関係ない例外もまとめて無視しちゃいそうで、
それは「安全」なのか疑問。

**デフォルトの名無しさん** · 2019/12/06(金) 00:51:39.38

終了させるにしてもちゃんとやれ

**645** · 2019/12/06(金) 00:54:05.25

>>655
どうせなにもできない事には変わりないので無視でいいかなと。
スレッド終了時にプログラム固有のリソース解放処理を確実にやりたい目的でのthrow&catchなのでC++標準ライブラリ自身の出す例外は無視、的な。

**デフォルトの名無しさん** · 2019/12/06(金) 01:06:58.12

ログ出力という大事な仕事があるだろ

**デフォルトの名無しさん** · 2019/12/06(金) 02:04:04.00

>>657
それだとほんとに何か問題があって例外が飛んでるときに気づけなくて危なさ沿う、という話。
struct thread_exit {} とか専用の例外をthrow&catchしとけば、目的を達成しながら問題検出もできそうな。

**デフォルトの名無しさん** · 2019/12/06(金) 06:39:31.51

>>654
正論

**デフォルトの名無しさん** · 2019/12/06(金) 07:31:29.17

>>637
for_each(parあんじゃん
いちいち待ち合わせなんて
まだやってんの？

**デフォルトの名無しさん** · 2019/12/06(金) 09:21:05.01

寒い

http://34vv.net/8d8/

**デフォルトの名無しさん** · 2019/12/06(金) 12:56:29.50

>>644
てめえの糞おつむでは未だにlock_guardなんか使ってんのかよww
んな互換性のためだけに残ってるコード人様に勧めてどーするつもりだ。

**はちみつ餃子** ◆8X2XSCHEME · 2019/12/06(金) 14:04:15.50

>>635
LISP では再帰で書くなどという俗説を信じるな。

**デフォルトの名無しさん** · 2019/12/06(金) 14:28:22.22

もしかしてメンバ関数の定義で引数や戻り値に不完全型を使っても許されるようになりましたか？
autoが許されるのだから、許されて良いような気がするのですが。

**デフォルトの名無しさん** · 2019/12/06(金) 14:55:34.36

厳密にはわからんけど、クラステンプレートやメンバ関数テンプレートだと
それらが実体化されるより前であれば不完全型は使えるはず（コンパイラによっても変わることあるけど
autoも似たような理屈だと思う、宣言だけして関数定義より前で使うとエラーになるはず

**デフォルトの名無しさん** · 2019/12/06(金) 15:04:26.66

https://ja.cppreference.com/w/cpp/language/function
> 関数の引数の型および戻り値の型は、削除された関数を除き (C++11以上)不完全クラス型にできません。完全性のチェックは関数の本体の文脈で行われます。
これはそういうことを言ってるんですかね。

**デフォルトの名無しさん** · 2019/12/06(金) 15:08:45.40

関数本体内のコンテキストで完全型になっていれば良いのであれば、いろいろできるような気がする。
あんなことやこんなことが。

**デフォルトの名無しさん** · 2019/12/06(金) 15:14:03.21

あーそういうことだね
関数定義前なら不完全でもいいってことだと思う
すまんテンプレートには限らないぽいな

**デフォルトの名無しさん** · 2019/12/06(金) 15:29:10.59

どうもありがとう。

**デフォルトの名無しさん** · 2019/12/06(金) 15:45:43.96

>>661
step =1000000;
for( double r2 = R2 - dev2; r2 < R2 + dev2; r2 += dev2 / step ){
}
こいつを並列化したいんだが、ループカウンタをintに変更するとしても、
2M ノードのvector確保するわけ？
ループカウンタ設定するために並列化要るがなw
単にループ回したいだけなのに巨大なメモリ要るてww
調べてみてもC#やtbbのparallel_for相当がないんだが
これら見ながら企画作ったC++規格策定メンバーってお前と同じパープリンじゃないのか？

**デフォルトの名無しさん** · 2019/12/06(金) 16:13:34.34

>>671
おい、真面目に情報提供している者に対してパープリンとは何だ
俺だけじゃなく640もパープリン呼ばわりか

後出しという自分の落ち度を棚に上げて
そういう発言は5chのフランクさでは済まんぞ

**デフォルトの名無しさん** · 2019/12/06(金) 16:14:35.15

初手人格否定はC++erのセオリー

**デフォルトの名無しさん** · 2019/12/06(金) 16:14:40.19

>>671
お前が生きてる価値の無いゴミなだけ

**デフォルトの名無しさん** · 2019/12/06(金) 16:39:35.59

>>661もたいがい無意味に煽ってる書き込みだと思うがｗ

**デフォルトの名無しさん** · 2019/12/06(金) 17:15:36.33

https://news.livedoor.com/article/detail/17486025/

**デフォルトの名無しさん** · 2019/12/06(金) 18:34:35.34

>>671
OpenMP & SIMD intrinsics

**デフォルトの名無しさん** · 2019/12/06(金) 19:25:13.77

lock_guard使わずになに使うの？

**デフォルトの名無しさん** · 2019/12/06(金) 19:35:24.69

ひのきのぼうとかわのふく

**デフォルトの名無しさん** · 2019/12/06(金) 22:24:12.87

ヒノキの棒でぶっ叩けば人は死ぬし、皮の服は火焔や刃物を弾く。
どちらかというと上級者向けの装備だと思います。

**デフォルトの名無しさん** · 2019/12/06(金) 23:38:17.10

operator[]で読み書きって毎回調べないとできず
set()、val()とか関数で読み書きしてすますことが多いのだが
新文法などで簡単にやる方法わかりますか

**デフォルトの名無しさん** · 2019/12/07(土) 01:06:30.72

なにいうとるのかわからん
operator[]をどう実装してどこで使えばいいのか理解できてないという話なのか

**デフォルトの名無しさん** · 2019/12/07(土) 01:08:17.23

>>615
余再帰だな
江添やっちまったなあ！

**デフォルトの名無しさん** · 2019/12/07(土) 01:59:52.93

>>682
ふつうの実装では、A[n]は参照しかできず
A[n] = の代入ができないという事

**デフォルトの名無しさん** · 2019/12/07(土) 05:36:21.30

>>684
｢参照｣を返せばいいだけだが、そういうことではない？
まさか｢参照｣を知らないと言うわけではないよね。

**デフォルトの名無しさん** · 2019/12/07(土) 06:10:47.12

ちょくちょく初心者質問スレに行った方が良い人までここに堂々と書き込むのが
スレを妙な雰囲気にしてる

**デフォルトの名無しさん** · 2019/12/07(土) 06:56:32.11

>>615 >>683
「余再帰」 corecursion って呼ぶのか。勉強になるわ。

江添さんのページを見てみたんだけど、
「このコードは末尾再帰になっている。」の行の前に
最初の return n * factorial(n-1) を返す関数を
末尾再帰に書き換えたコードの引用があるべきなのを
挿入し忘れたように思えるね。

・末尾再帰でないコード例を示す
・末尾再帰にするとこうなる ... コード欠落
・末尾再帰はループに書き換えられるよ
・ループにしたコード例
っていう流れで自然に読めるでしょ。

**デフォルトの名無しさん** · 2019/12/07(土) 09:42:39.92

でもこのシグネチャのfactorialのままだと末尾再帰できなくね？>>642みたいになるかと。

**デフォルトの名無しさん** · 2019/12/07(土) 11:49:45.97

>>685
たとえばbitsetを実装しようして、内部では32や64bitの整数へ保存するとして
参照だけではB[i]=1はできないかと

**デフォルトの名無しさん** · 2019/12/07(土) 11:56:48.08

最初からそうかけよ

**デフォルトの名無しさん** · 2019/12/07(土) 11:57:37.74

これのこと、毎回調べ直さないと作れない

プロキシ
実は、C++ でも、かなり無理やりですが、（見た目だけは）プロパティのようなことができたりします。とりあえず、百聞は一見にしかずということで、以下の例を見てください。

利用側、すなわち、main の中では、まるで普通の変数に対する代入・参照であるかのようなコードになっています。

このからくりは、 age の読み書きに、AgeProxy という名前の別のクラスを介することで実現します。 Age は AgeProxy 型の変数です。
AgeProxy の代入演算子（operator =）と int 型へのキャスト（operator int）を通して、 Person クラスの age 変数の読み書きをします。

ちなみに、こういう例のように、いったん別のクラスを通して値を読み書きしたりする方法を、プロキシ（proxy: 代理）と呼びます。

まあ、このパターンは、利用側の見た目は綺麗になりますが、実装は面倒ですし、実行効率もあまりよいとはいえません。
さらに言うと、プロパティを virtual 化しようとすると、この例よりもさらに複雑な実装が必要になります。

こういう感じの話を振り返った上で、改めて C# の「プロパティ」機能を見ると、便利な機能だなぁとつくづく思います。
https://ufcpp.net/study/miscprog/accessor.html

**デフォルトの名無しさん** · 2019/12/07(土) 12:00:39.08

相談じゃないなら他へ

**デフォルトの名無しさん** · 2019/12/07(土) 12:02:24.40

プロパティはコード上でフィールドのように扱えることよりもメンバとしてIDEが認識できるところに意味がある
最近はC#でもデザイナに頼らずに何でもコード上で済ませるスタイルが主流になりつつあり、プロパティの必要性は薄れている
初期化時にパラメータを纏めて渡したりするだけなら生フィールドで十分なわけだしな

**デフォルトの名無しさん** · 2019/12/07(土) 12:11:07.35

proxyで別に実行効率は下がらんよね
てかstd::vector<bool>は大昔から存在するし

**デフォルトの名無しさん** · 2019/12/07(土) 12:25:43.42

C++Builder使えばよいのでは。

**デフォルトの名無しさん** · 2019/12/07(土) 12:42:26.89

>>684, >>684
他言語での getter/setter メソッド的な事をやりたいのだろうなあと考えてみました。

例えば a[i] と書かれたら、内部データ(typename T) への参照(T&) を返すのではなく
新たに内部クラス(fields: owner, index)を用意して、そのオブジェクトを作って返すようにします。
これに代入演算子(operator =) とキャスト演算子(operator T()) を実装すれば...
・a[7] = 99; //setter
・cout << a[7]; //getter
こうやって普通にアクセスできます。メソッドを分離したお陰で、
添え字アクセスによるデータベースのupdate / select みたいな事が可能になります。

代入演算子は最低二種類必要で
Inner& operator =(const T& value); // a[i] = value
Inner& operator =(const Inner& rhs); // a[i] = a[j]
二つ目を実装しないと暗黙のコピー代入演算子が作られてしまい
a[i] = a[j]; のような代入操作は実質空文化します。(owner/indexがコピーされるだけ )

素人の思いつきですがサクっと試したら機能しました。
もっとスマートなやりかたもあるでしょう。