C++相談室 part155

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

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

テンプレここまで

**デフォルトの名無しさん** · 2021/04/22(木) 17:41:40.96

>>354
もう少し深く考えて見ると、ptr2 - ptr1 は、どちらが若いアドレスかが
わからない時でも結果を理解するためには、結果は符号付き整数である
ことには合理性がある。つまり、ptr2 < ptr1 なら、負、ptr2 > ptr1 なら
正と。
ところが、32BITマシンで、2GBを越えるデータを扱うと、この解釈では
問題が出る。
結論的には、sizeof()や ptr2 - ptr1 の結果の型に対してどんな場合にでも
上手く行く定義は存在しないようだ。

**デフォルトの名無しさん** · 2021/04/22(木) 17:41:51.85

K&R1にはsize_tなんか出てこない
strlenの戻り型はintとすら書いておらず
省略時の解釈で暗黙にintとなっている

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

std::string::size_typeは？

**はちみつ餃子** ◆8X2XSCHEME · 2021/04/23(金) 02:30:22.88

>>351
「伝統的」っていつの話だよ。
C89 が制定されて以降、 strlen の返却値や sizeof の評価結果の型は size_t だろ。
念のためにちょっと確認してみたら
Turbo C 1.0 なんて 1987 年の日付 (C89 制定前) だが strlen の返却値は size_t になってるぞ。

**デフォルトの名無しさん** · 2021/04/23(金) 02:54:05.85

>>358
当時の本でも、
int a;
a = strlen(ptr);
と書いてあったと記憶してるので、指導的立場の人も含めてほとんどすべての人が
unsigned int の戻り値を int の変数に入れていたということだね。

**デフォルトの名無しさん** · 2021/04/23(金) 03:11:41.40

https://stackoverflow.com/questions/32985119/strlen-to-int-c-why-cant-i-do-this
↑こんなにC++に詳しそうな人達も、なぜか、符合無しの size_t を
intと比較している：
std::size_t length = s.size();
for (int i = 0; i < length; ++i)

どこかでC/C++の長さは、intであると刷り込まれているようだ。
しかし、35年以上前のTurbo C ですら、unsigned intであったのに。

**デフォルトの名無しさん** · 2021/04/23(金) 03:13:55.04

質問者は、
for (int i = 0; int n = (int)strlen(s); i < n, i++)
がエラーになることの理由を聞いているようだが、これは単純に
for文の書き間違いで、少なくとも、
int i, n;
for (i = 0, n = (int)strlen(s); i < n, i++)
と書けばコンパイルは通るはずだ。

**デフォルトの名無しさん** · 2021/04/23(金) 03:25:18.34

スマン:
誤: for (i = 0, n = (int)strlen(s); i < n, i++)
正: for (i = 0, n = (int)strlen(s); i < n; i++)

**デフォルトの名無しさん** · 2021/04/23(金) 05:23:38.34

> どこかでC/C++の長さは、intであると刷り込まれているようだ。

これは違う
double a = 0;
と書いたからって0がdoubleと思っているのと違うようなものだ

**デフォルトの名無しさん** · 2021/04/23(金) 08:03:05.37

>>353
> 全世界的に事実を改竄している。

世界で自分だけ正しい、あとの70億人はすべて間違っていると考える病人

**デフォルトの名無しさん** · 2021/04/23(金) 09:14:12.81

>>364
現代のガリレオかもしれない

**デフォルトの名無しさん** · 2021/04/23(金) 14:58:50.01

>>365
ガリレオの時代にガリレオ以外に地動説を考えてた奴が他にいなかったと思い込む馬鹿。

**はちみつ餃子** ◆8X2XSCHEME · 2021/04/23(金) 19:32:09.65

>>360
その場合に int で表現可能な範囲内の値である限り暗黙の型変換で不整合は生じない。
strlen の返却値が size_t なのは、最大でそこまで対応可能ではあるが、
扱うデータの大きさが int の範囲内にあるという「想定」をしてもすぐさま誤りではないし、
int の範囲を超えるほど長大な文字列を想定しなきゃならない機会はそう多くもないだろ。
常識的な想定と言語仕様を混同するべきではない。

◆QZaw55cn4c · 2021/04/23(金) 19:56:01.09

>>365
私も、ある意見について「世界で自分だけ正しい、あとの70億人はすべて間違っている」という実感を持っています
問題はそれを世の中に知らしめす方法ですが、今の私はリアルで打撃につぐ打撃、その上におまけの打撃まで食らう状態で、いわば瀕死の状態‥‥

さてこんなボロボロな私はどうすればいいのでしょうか？

**デフォルトの名無しさん** · 2021/04/23(金) 21:03:11.51

その意見とは？

**デフォルトの名無しさん** · 2021/04/23(金) 22:13:51.83

>>368
氏ね

**蟻人間** ◆T6xkBnTXz7B0 · 2021/04/23(金) 22:32:09.50

>>368
短期目標と長期目標を立てて、目標に達成したら、自分を褒める。これを繰り返す。

**デフォルトの名無しさん** · 2021/04/23(金) 23:05:33.67

>>368
ビッグバンからやり直せ

**デフォルトの名無しさん** · 2021/04/23(金) 23:26:25.47

>>368
あんたはビョーキだから何をしても無駄
「自分は間違っている」という実感を持てたら少しは回復した証拠

**デフォルトの名無しさん** · 2021/04/23(金) 23:40:13.99

>>368
つ聖遷・聖戦

お大事に

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

.hファイルと.hppファイルって何が違うんスかね
includeするならincludeしたがわの拡張子でコンパイル方法？が決まるわけで
ヘッダの拡張子の違いとは？

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

.hには宣言だけ書いて.hppには実装を書くという使い分けをしている人が多い
宣言と実装を同時に行うときも .hpp

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

STLコンテナに機能を追加したい (たとえば vector の要素の順番を自分のルールで並び替えるメンバ関数を追加したい) ときってどう書くのですか？
この場合はメンバ関数じゃなくてフリー関数として実装した方が良いとしても、メンバ関数を追加する方法を知りたいです
(それとも、STL コンテナの継承が忌避されるのと同じ理由で、こういうのはやらない方が良い話ですか？)

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

>>377 継承すれば追加できるよ。

**はちみつ餃子** ◆8X2XSCHEME · 2021/04/24(土) 01:45:45.85

>>375
仕様上の違いはない。
習慣的にもそれほどはっきりした使い分けが確立しているわけでもなくて
確かに >>376 もひとつの例として納得はできるけども
多いっていうほど多くもないような印象。

どういう意味で使い分けているのかは人 (組織) によるので、
違いがどういう意味を持つのかを一律には言えない。

個人的には、 C のヘッダとしても使えるように配慮した場合は h にするかな。

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

>>376
>>379
なるほど
そういや自分もCのヘッダを意識する場合は.hにしてるかもですね
どうもです

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

>>378
でも STL コンテナの継承って凄い忌避されてる印象を持ってます
罠が多いって

やっぱり引数で取って引数で返す方が良いのかな、、、

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

>>381
STLはソース(ヘッダだけど)を見ると物凄く解読に時間が掛かる書き方になって
いて、正しく現状どうなって実装されているかを理解するのがとても難しいが、
継承するとなるとちゃんと理解出来てないと危険なので継承したがらない人が
多いのだと思う。

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

>>382
あと、テンプレートを普通のクラスの基本クラスにすることは容易だけど、
テンプレートを継承したテンプレートを作るのは、C++をかなり深く理解して無いと
色々と危険かも知れない。
また、ややこしくしてるのは、perfect forwarding や reference collapsing、
右辺値参照、moveセマンティクスが多用されていることに加えて、
余りドキュメント化されて無い解釈の難しい独自関数を使用して書かれている
ことが多いこと。

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

>>383
それ以外にも、template引数に「...」があったり、それを使う場所でも「...」
があったりして、それぞれの意味や展開のされ方を正しく理解するのは難しい。
コンパイラがどういう解釈をするのか途方にくれることが有った。まるで
魔法のように見えることすら。結果的な意味は何とか分かっても、コンパイラが
どういう原理や順序で理解したりコンパイルしているのか深く理解できないこと
が多かった。
最新のSTLのソースをちゃんと理解できるまでC++を理解するのは、C++を
本格的に勉強する必要がある。

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

>>384
古いC++にも「initializer list」という言葉はあったが、C++11以降は
独特の概念が追加され、それに関連したオブジェクトを関数の引数にとったり
できるようになったりして、それの働きを深く理解するのがまた難しい。
また、全体的に lvalue, rvalue に加えて、xvalue, prvalue, glvalueを正確に
理解し、何がどれに属するかを徹底的に理解してなければ、STLのソースコードを
正確に理解することはままなら無い。
僅かでも理解してないことがある状態でSTLのコンテナを独自に継承した
テンプレートを作った場合、思わぬ不具合やメモリー関連の原因が特定しにくい
バグをアプリ開発で忙しい時に遭遇してしまうかも知れない。

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

間違ってるかも知れないが、
initializer_list<T> は、「list initializer」に関係したテンプレートで、
登場したのはC++11移行なはず。
一方、member initializer listや、class initializer listは、名前が同じだが
全く別の概念なはずで、コンストラクタを関数定義する時に、
: MyBase(0), m_x(x), m_y(y)
のように書く部分。

initilizer list と list initializer はかなり異なった概念なハズだが、
後者に関係したオブジェクトの型は、initializer_list<T>と書くようだ。

間違っていれば指摘して欲しい。

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

間違ってるかも知れないが、
initializer_list<T> は、「list initializer」に関係したテンプレートで、
登場したのはC++11移行なはず。
一方、member initializer listや、class initializer listは、名前が同じだが
全く別の概念なはずで、コンストラクタを関数定義する時に、
: MyBase(0), m_x(x), m_y(y)
のように書く部分。

initilizer list と list initializer はかなり異なった概念なハズだが、
後者に関係したオブジェクトの型は、initializer_list<T>と書くようだ。

間違っていれば指摘して欲しい。

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

クラス A の中で他のクラス B のインスタンスをメンバとして持ちたいとき、B のコンストラクタに引数を渡す方法が初期化リストくらいしかない
つまり後でわかる情報を使って B のコンストラクタを呼ぶ方法がない

B じゃなくて B のポインタを持てば良いって思うかもしれないが、こんなどーでも良いところでポインタの使用を強制する言語仕様ってゴミだろ
もーちょい頑張んなよ、C++クン

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

>>388
バカ？w

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

疑問符はいらないね

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

using namespace std をヘッダファイル内で使いたいです。なんせ短くなるので
でも、そうすることでリスクを負うというのもわかります
どう折り合いをつけるべきでしょうか
皆さんはどうされていますか

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

>>381
メンバ関数追加するだけならまぁ問題は思いつかないけど(スライシングや非仮想のデストラクタはメンバ変数追加が無ければOK

ただ素のvectorからの代入やコピー、ムーブコンストラクトは出来ないので追加で書いてやらないといけない
さらにそのメンバ関数を呼ぶには派生型にキャスト(コピーとか防止のために参照でキャスト)をいちいち書かないといけない
まぁそんな面倒な派生クラス使うくらいならフリー関数にしといた方が楽だよね
そんなこんなで安易な機能追加のための継承(まして継承される前提でないクラスを)ってのは普通避ける

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

>>491
そんなの自分で決断すれば

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

すまん>>391だった

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

>>391
ARM C++のコンパイラ使ったら？
#include <iostream.h>
これならstd空間が元々ないよ

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

コンテナは継承するまでもないほど完成されていること、
コンテナを継承するくらいならコンテナをメンバ変数にもつクラスを定義したほうが機能拡張や仕様変更に対応しやすい
などなどでしょ

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

>>393-394
でも例えば公開するとかなってくると当然 using namespace std; は問答無用で除くべきですよね？

あと近い話で、マクロってどこに書いたら良いんでしょうか
REPマクロ等を多用するんですが、同じマクロをいろんなヘッダファイルの冒頭に書くのって変ですか？
共通するマクロは、親に該当する utility.hpp みたいなヘッダファイルを作ってそこに書く等するべきですか？

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

>>397
ああ、それなら俺もやる
開発初期はusing namespace std;で色々試していて
公開がちらついてきたあたりで律儀にstd::を書くスタイルに変えていく

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

同じものはまとめるのがプログラミングの鉄則

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

自分はC++17でusingディレクティブでなくusing宣言のパック展開使ってるけど、(using std::cout, std::endl, std::string; とか)
これも好ましくないのかな

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

using std::* したいスコープを独自の名前空間で囲めば他人に迷惑かけずに済む
マクロは名前空間を超えるので他人に迷惑かけやすい

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

>>401
その理屈だと、公開するプログラムにおいてはマクロはよほどユニークな名前じゃない限り使うべきじゃないってことですか？

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

ヘッダーファイルでマクロを定義するなら名前衝突を警戒すべきであって理屈とかじゃなくてマナー

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

>>397
ユーザーにincludeされるヘッダじゃなくてcppでだけusingすればいいやろどうせ実装書かないんだから
(テンプレートとかでヘッダに実装書くならすでに出てる通り名前空間に隠すとか

>>402
まず被らない名前ならいんじゃね
それかundefするヘッダも作って使い終わった段階でそれをインクルード

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

Windowsのmin,maxとかAppleのcheckとか
考えなしの公開マクロ名は使う側に大迷惑だから慎重にしないといけない

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

minとmaxが関数型マクロなのはやさしさ
#include <Windows.h>
#include <stdio.h>
#include <algorithm>
int main() {
　int a = 3, b = 4;
　//int x = std::max(a, b);　　// NG! ビルドエラー
　int x = (std::max)(a, b);　　　// OK
　printf("x=%d\n", x);
}

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

#include <windows.h>
#undef max
#undef min

**デフォルトの名無しさん** · 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やってりゃ問題はないが。