C++相談室 part155

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

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

テンプレここまで

**デフォルトの名無しさん** · 2021/04/24(土) 10:18:48.27

>>398
>>401-403
namespace hoge {
using namespace std;
プログラム本体
}

って書いておけば他と干渉しないんじゃないの

◆QZaw55cn4c · 2021/04/24(土) 11:03:59.20

>>307
あなたの粘着力には、ほとほとあきれかえりますね‥‥それって何年前の話？

http://toro.2ch.net/tech/1369350072/171
171 ◆QZaw55cn4c [sage] 投稿日2013/07/11(木) 01:45:29.07
ラプラスは練習中
けれどもどうせ資格試験用だし、むずかしいことははなからやるつもりもないのです、複素関数論なんて一生縁がないとおもう留数とかもう忘れた‥‥

なお、実は 8　年たった今でも私はラプラスは練習中だったりするのです‥‥資格試験の方は諦めていますが
いま詰まっている箇所は以下の定理、証明がわからない、誰か教えて‥‥
https://ja.wikibooks.org/wiki/%E5%88%B6%E5%BE%A1%E3%81%A8%E6%8C%AF%E5%8B%95%E3%81%AE%E6%95%B0%E5%AD%A6/%E7%AC%AC%E4%B8%80%E9%A1%9E/%E9%80%A3%E7%AB%8B%E5%BE%AE%E5%88%86%E6%96%B9%E7%A8%8B%E5%BC%8F%E3%81%AE%E8%A7%A3%E6%B3%95/%E9%80%A3%E7%AB%8B%E5%BE%AE%E5%88%86%E6%96%B9%E7%A8%8B%E5%BC%8F%E3%81%AE%E8%A7%A3%E6%B3%95/%28%73%49%2D%41%29%5E-1%E3%81%AE%E5%8E%9F%E5%83%8F/%E8%A1%8C%E5%88%97%E3%81%AE%E3%83%88%E3%83%AC%E3%83%BC%E3%82%B9%E3%81%A8%E4%BD%99%E5%9B%A0%E5%AD%90

**デフォルトの名無しさん** · 2021/04/24(土) 11:32:30.02

>>409
×留数とかもう忘れた・・・
◎留数なんて勉強してません高卒てすから

**デフォルトの名無しさん** · 2021/04/24(土) 11:40:13.58

学歴コンプレックスって醜いよね～
ところでラプラスって何ですか？
ラプラシアンなら知ってるんですけど
Lhaplusのことですか？

**デフォルトの名無しさん** · 2021/04/24(土) 11:53:07.06

>>409
そういうのは小さい次元,2x2あたりで計算してみて、大きい次元でも成り立ちそうだなと納得するのが早いかもですな

**デフォルトの名無しさん** · 2021/04/24(土) 12:43:43.67

つか人生相談は板違い、
一生虐げられ続ける弱キャラとしての宿命がC++の規格書に書かれているなら話は別だが

**デフォルトの名無しさん** · 2021/04/24(土) 12:44:49.58

>>407
天才か！

**デフォルトの名無しさん** · 2021/04/24(土) 12:47:38.37

ヘッダオンリーライブラリの体で自作のプログラム配布するときって、全体を namespace でくるむのがマナーなんですかね
普通な名前の関数を定義したりして衝突したら不味いから？

**デフォルトの名無しさん** · 2021/04/24(土) 12:56:34.70

ヘッダオンリーに限った話じゃない

**デフォルトの名無しさん** · 2021/04/24(土) 13:00:31.18

>>414
それならNOMINMAXでいいのでは

**デフォルトの名無しさん** · 2021/04/24(土) 13:05:05.35

>>417
もしプリコンパイルヘッダーに
#define NOMINMAX
#include <Windows.h>
と書いてしまった暁には、マクロ版のmin()やmax()を使いたい人は
どうやって生きていくんじゃ……

**デフォルトの名無しさん** · 2021/04/24(土) 13:16:46.63

なるほど（´･ω･`）

**デフォルトの名無しさん** · 2021/04/24(土) 13:33:18.27

boost の多次元配列ライブラリ multi_array を使ってるんだが、両辺の shape が違うときに = で代入できないのがストレスなので、引数の shape が違うときには左辺を右辺と同じようにリサイズしてから代入するように = の定義を変えたい
演算子のオーバーロードってテクを使えば良いらしいが、これは諸刃の剣で注意が必要みたいな記事を見て戦々恐々としてる、、、

代入演算子のオーバーロードで最低限気をつけるべきことってどういうものですかね

**デフォルトの名無しさん** · 2021/04/24(土) 14:01:29.71

気をつけるべきこと
代入演算子を一時的なストレスでオーバーロードしない

**デフォルトの名無しさん** · 2021/04/24(土) 14:04:54.62

代入はグローバルに書けないはず
メンバとして書くしかない->multi_arrayのヘッダを書き換えるしかない

**デフォルトの名無しさん** · 2021/04/24(土) 14:18:13.19

new して確保するわけじゃない、既存の変数のアドレスを格納するだけのポインタって別にスマートポインタじゃなくて生ポで持てば十分だよね？

**デフォルトの名無しさん** · 2021/04/24(土) 14:33:50.86

生ポでいい用途を自信を持って判断できず「念のため」スマポ使うやつでも見かけた？

**デフォルトの名無しさん** · 2021/04/24(土) 14:39:12.20

いや自分が不安なだけ

**デフォルトの名無しさん** · 2021/04/24(土) 15:34:17.33

用途次第だけどnullにならない分参照の方がいいかもしれない
もしくはshared_ptrと一緒に使うならweak_ptr

**デフォルトの名無しさん** · 2021/04/24(土) 15:39:23.77

>>426
後出しですみませんが、vector の各要素へのポインタを vector で持つ事も考えてます
参照の vector は普通には持てないので、その意味でももう生ポインタの vector で良いかって気になっていました

**デフォルトの名無しさん** · 2021/04/24(土) 15:46:35.43

reference_wrapperなら参照vector作れるけど、そこまでしたくないってことならポインタでいいんじゃない
気をつけてな

**デフォルトの名無しさん** · 2021/04/24(土) 17:56:54.49

考えるべき所がズレてる

既存の変数はポインタを保持してる期間に必ず存在しているか
別スレッドから既存の変数へのアクセスが発生するか

表記方法を考えるのはその後

**はちみつ餃子** ◆8X2XSCHEME · 2021/04/24(土) 18:25:12.58

>>423
こういう場面では生ポインタでいいよね？っていう意味？

#include <memory>

int main(void) {
int a;
std::unique_ptr<int> b(&a);
}

むしろ不必要に解放しようとしてワヤになるんで、生ポインタである必要がある。
デリータが何もしないようにすればスマートポインタでも大丈夫ではあるけど、
あえてそうする必要もないし。

>>427
std::vector は要素を追加するなどしたときに再配置が起こる可能性があるから
要素へのポインタ (または参照) を持つのはあまりオススメできない。
(インデックスで持ったほうがいい。)
適切に管理できるならポインタでもそれほど問題でもないんだけど、
質問の雰囲気を見る限り十分な理解があるような感じでもないので……。

**デフォルトの名無しさん** · 2021/04/24(土) 18:40:32.67

vectorの中身なら
要素の参照やポインタ
vectorの参照やポインタと要素のインデックス
イテレター

色々と持ち方があるから
場面場面において適切なのを選ぶ

メモリ管理をしてないのにスマポで保持は無い

**デフォルトの名無しさん** · 2021/04/24(土) 22:02:18.72

>>234
あ
った
>3-5-1. 逆数を精度よく求めれば割り算できる
https://qiita.com/square1001/items/1aa12e04934b6e749962

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

>>430
> std::vector は要素を追加するなどしたときに再配置が起こる可能性があるから
> 要素へのポインタ (または参照) を持つのはあまりオススメできない。
> (インデックスで持ったほうがいい。)

再配置が起きたとして、ポインタが指してる先が危険にさらされることなんてあるんですか？

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

newした新しいメモリにコピーして古いのをdeleteしたら古いのを指してるポインタはもう使えんだろ
ほら最近初心者への教え方がおかしい&最初からスマポ押し付けるからこういうのが出てくる・・

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

いや new や delete はしないって書いてあるよ
よく読んでおじいちゃん

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

>>435
本気で言ってんのか？

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

最近のC++が難しく感じる原因は、cppreferenceに頼ってる人が多いから
ではないか。あそこはドキュメントの品質が悪くて混乱の原因になる。

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

C++は、代入/コンストラクタがmove系とcopy系で原理的には好き勝手にプログラム
できるので、バグが出た時にプログラムの流れを追うためにはmoveとcopyのどちらが
呼び出されているかプログラマがコードから明確に区別ができないと困るね。
その点、デフォルトmoveで、xxx.clone()としない限りは複製されないRustの
設計思想はそれはそれで便利と言えるかな。
どちらが優れているかは一概には分からないかも知れないけれども、デバッグ
時の追いやすさの観点からすればRust流の方が良いかな。

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

>>438
C++の場合は、x=std::move(y);と書けば明示的にmove系が呼び出されるので
その場合、混乱は生じないが、右辺が関数の戻り値が構造体型/クラス型の場合、
RVO(Return Value Optimization)が働いたり、右辺が「クラス名(引数列)」
のようなテンポラリオブジェクト作成の場合にはmove系が選択される
という「自動振り分け機能」があり、自分が知らないだけでそれ以外にも
特殊なパターンがまだあるかもしれないことが、不安や予想しづらい
原因になっていると思う。
Rustの場合は、自動化されているかと思いきや、実際には、代入などが
move/copyのどちらになるかに関しては、自動ではなく、
デフォルトmoveで、x.clone()とした場合にのみcopyという明示的に
区別する方式なんだと思う。

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

std::vector<int> v((size_t)3);
printf("&(v[2])=0x%p\n", &(v[2]));
v.resize((size_t)5000);
printf("&(v[2])=0x%p\n", &(v[2]));

↓実行結果（例）

&(v[2])=0x000002376EF91658
&(v[2])=0x000002376EF93A08

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

new,deleteが起きないとかいうトンデモ理論はshared_ptr<T>のstd::vectorと混同した感じ？

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

数値計算畑の人間だけど、numpy with MKL が C++ より速くてワロス
もうホントにニッチな領域でしか使わなくなっていくな C++

◆QZaw55cn4c · 2021/04/25(日) 05:44:12.98

>>442
それはシングルユーザーライセンスであっても 500千円からという価格のインテル製コンパイラやライブラリを使うからなのでは？

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

多次元配列の添字を入れ替える関数を実装したいのですが、任意の次元に対応するものをどう作れば良いのかわかりません。
たとえば v[a][b][c] を v[c][b][a] と入れ替えるのを全ての a, b, c について行ないたいです。
次元が 3 と決まっていれば、整数 a, b, c についてループを回して
v_[c][b][a] = v[a][b][c]
のようにコピーすれば良いのですが、次元が任意だと鉤括弧 [][][] を用いた要素アクセスをどうすれば良いのか分かりません。
不可能ですかね？
その場合、多次元配列を 1 次元で持つことにして、各次元の長さを la, lb, lc,... として、整数 x を 0 から la*lb*lc... -1 まで回して、その都度 x の各桁を取り出して要素をコピーする、みたいなことしかやりようがないですか？
そうなると各桁を取り出すのに割り算とか剰余演算を駆使しないと駄目なのでパフォーマンスが落ちるのが懸念です。
あるいは、3 次元に対応した関数、4 次元に対応した関数、…… といった感じで各次元に特殊化した関数を実装するべきでしょうか？
できれば一般的というか汎用の関数を作りたいのですが。。。

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

シングルユーザーライセンスであっても 500千円からという価格のインテル製コンパイラやライブラリ
を使ってもnumpy with MKL が C++ より速いとかこの世は暗黒だな

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

v[0]やv[i][0]が配列なのか単一の型なのかは判定できるから
enable_ifで分けてオーバーロード(再帰するかしないか)とか出来るはず

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

>>435
>>435

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

>>433
>>427で「vector の各要素へのポインタ」って書いてるからそっちの話だろう

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

>>445
MKLがIntel製で、
「Intel Math Kernel Library (MKL) というのは, Intel 製の高速な数値計算ライブラリ」
だよ。
つまり、Pythonでは、Intel製の高速なライブラリを使っているが、C++では
使って無い場合の速度比較。

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

>>446
なるほど……
勉強してみますが大変そうですね

外部ライブラリに頼るか迷いますが、多次元配列は非常に基本的な機能だと思ってるので最低限度で取り回しの良いものを自分で持っておきたいという思いがあります……

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

自分で作った方が融通がきく

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

作るなら[x] [y] [z]の形にしない方が良い
[]の中にベクトルを入れる方が融通がきく

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

>>452
v[ {x, y, z} ] みたいに要素アクセスするってことですか？

**デフォルトの名無しさん** · 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) を作るしかない？