C++相談室 part158

**デフォルトの名無しさん** · 2021/11/15(月) 18:49:18.44

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

**デフォルトの名無しさん** · 2021/12/07(火) 00:15:41.50

>>219
今から考えれば NECのPC-8801 のBASIC言語は数学好きに合っていた。
当時のNECの社長は、東大物理の大学院出の人だったらしい。
その人がTOPにいる間はNECのパソコンは日本で一斉を風靡していたが、
その人が降りてからは、嘘の様に勢いがなくなった。

**デフォルトの名無しさん** · 2021/12/07(火) 13:20:30.29

みんなコルーチン使ってる？

**デフォルトの名無しさん** · 2021/12/07(火) 13:44:30.14

コルーチンはいろいろ制限が多くてな、最近はfiberの方を使ってる
機種依存APIを使う必要がある、実行効率が若干落ちる、スタック用のメモリを大量消費する、トレースデバッグがやりづらい等のデメリットはあるが、
本物のyieldはやっぱ便利よ

**デフォルトの名無しさん** · 2021/12/07(火) 14:37:49.13

c+のvectorって無限に要素追加したらどうなりますか？
例えばwhile (1) でemplace_back()し続けた時の挙動です。javaみたいにちゃんとoutofmemoryエラー吐くようにできてますか？

**デフォルトの名無しさん** · 2021/12/07(火) 14:52:13.72

「ちゃんとout of memoryエラーを吐く」というのは突き詰めるとものすごく難しい概念なので、どこまでを求めるかによる
Javaにしても本当にどのレベルまで正しくやれてるのかは知らん
まあ「なんかあったらstd::bad_alloc投げて来るやろ」で99％のケースは事足りると思うけど

**デフォルトの名無しさん** · 2021/12/07(火) 14:57:50.91

例えば普通のアプリだと、C++とか関係なく最近のOSのメモリ確保は仮想メモリの確保なので、実際にそのアドレスが使われて初めて物理アドレスが確保され、スワップ領域が足りない場合もそのとき検出される。

**デフォルトの名無しさん** · 2021/12/07(火) 14:57:56.04

mallocに失敗すればbad_allocが投げられるが
実際のところmallocが失敗するときにできることは殆ど無いと認識している

**デフォルトの名無しさん** · 2021/12/07(火) 15:01:16.11

>>179
そもそも C++ から Fortran で書かれてるオリジナルの BLAS とか LAPACK を呼ぶこともできるのだから、その辺は別に何でも良い

そんなことよりも多次元配列をどう持つかの方が C++ にとっては難しい課題だ
Cの多次元配列や一次元配列として持つのはユーザ側の負担が大き過ぎる
boost の multi_array は放置されている (move セマンティクスに対応してすらない)
xtensor みたいなサードパーティのものをわざわざ使うのも…… (つーかどれもパッとしない)
早く多次元配列くらい公式で用意してほしい

**デフォルトの名無しさん** · 2021/12/07(火) 15:42:17.22

多次元といっても中身掛け算の一次元だしな

**デフォルトの名無しさん** · 2021/12/07(火) 16:20:01.36

class foo : vector<mystruct>
みたいなクラスを作っているんだけど
クラス内の関数で自身の配列の構造体の関数を呼ぶにはどうしたらいいんだろう？

this[a]->set(0);
と書いてもメンバーがありませんと出て困ってます😭

**デフォルトの名無しさん** · 2021/12/07(火) 16:24:10.42

(*this)[a]->set(0);

**デフォルトの名無しさん** · 2021/12/07(火) 16:32:15.84

>>252
ありがとう！ちょっと直したけど
(*this)[a].set(0);
でできました、超助かりました！チュッ！

**デフォルトの名無しさん** · 2021/12/07(火) 17:48:46.48

そういうときはat()使ってる

**デフォルトの名無しさん** · 2021/12/07(火) 18:03:51.96

atは範囲チェック分鈍くなるの我慢出来るなら有
あと例外飛ばすからtry～catch節必須

**デフォルトの名無しさん** · 2021/12/07(火) 20:03:22.82

>>248
bad_alloc is not out-of-memory!
https://wg21.link/P1401

**デフォルトの名無しさん** · 2021/12/07(火) 21:29:05.30

std::vectorのデストラクタはvirtualじゃないから気を付けてね、念のため

**デフォルトの名無しさん** · 2021/12/07(火) 22:45:19.35

abort()したら生きている自動オブジェクトは
どうなってし
まいますの？

**デフォルトの名無しさん** · 2021/12/08(水) 00:17:43.36

#include <iostream>
#include <cstdlib>
using namespace std;
struct s {
~s() {cout << "called." << endl;}
};
int main() {
s a;
abort();
return 0;
}
https://ideone.com/YDdO5O
https://cpprefjp.github.io/reference/cstdlib/abort.html

**デフォルトの名無しさん** · 2021/12/08(水) 00:51:11.41

abortより例外飛ばした方が確実だな(VC++6.0を除く

**デフォルトの名無しさん** · 2021/12/08(水) 07:27:41.53

>>258
デストラクタは実行されない
問答無用で強制終了
電源ぶっちするようなもん

**デフォルトの名無しさん** · 2021/12/08(水) 07:58:51.26

多次元配列 (mdspanだっけ) ってまだSTLに入らんの？
線形代数アルゴリズムはBLAS、LAPACKはじめ外部のライブラリに頼らざるを得ないんだから、最小限の機能だけ備えた取り回しの良いライブラリをさっさと入れちゃえば良いのに

この機械学習全盛の時代に置いてかれるよね

**デフォルトの名無しさん** · 2021/12/08(水) 10:00:58.02

機械学習全盛なの？

**デフォルトの名無しさん** · 2021/12/08(水) 13:49:53.98

ああいうライブラリってプラットフォームにべったり依存してるんじゃないの

**デフォルトの名無しさん** · 2021/12/08(水) 13:51:20.15

GoogleのGPUがオンラインで無料でつかえるぞ
Python言語だが

**デフォルトの名無しさん** · 2021/12/08(水) 13:56:11.42

C言語とかローカルの言語からGoogleのGPUを操作できれば
ローカルで実行してるのと大差なくできると今おもったが
探せばすでにそういったAPIとかある気はしたが

**デフォルトの名無しさん** · 2021/12/08(水) 14:21:17.05

スレ違い。
Google Colaboratoryはjupyter notebook使えればいいだけ。
!や%%で大抵のことは出来る。

**デフォルトの名無しさん** · 2021/12/08(水) 16:19:48.22

>>264
どういうライブラリ？

**デフォルトの名無しさん** · 2021/12/09(木) 00:00:00.18

>>260
例外飛ばしたら今度はCの関数が処理の途中でぶっちされるやん……？
次のような場合：
foo() // C++で記述、例外をスロー
↑
bar() // Cで記述、ループ内とかでfoo()を呼ぶ
↑
baz() // C/C++で書かれた呼び出し元

**デフォルトの名無しさん** · 2021/12/09(木) 01:16:56.11

構造体を関数の中で宣言して戻り値に入れたら
呼び出した側が受け取った値はどこかで開放しないといけないですか？

**デフォルトの名無しさん** · 2021/12/09(木) 01:43:46.28

なんで最近こんな無茶苦茶なの？
>>269
質問は「生きている自動オブジェクト」がどうなるかであり、例外でスコープから抜ければC/C++だろうと破棄される
>>270
「関数の中で宣言」とはどういうこと？
「受け取った値」はどうやって確保されたの？
ちゃんと伝えられないならコードで質問しないと伝わらない

**デフォルトの名無しさん** · 2021/12/09(木) 07:16:10.87

>>270
要らない
構造体はintなんかと同じでコピーされるから

**デフォルトの名無しさん** · 2021/12/09(木) 09:45:40.72

>>272 >>271
ありがとう！助かりました

C#でGC慣れしているので
正直この辺はなかなか理解が進まなくて…
ESP32が面白くてC++を始めたんだけど
いざ自分であれこれ作ろうとすると
わからない部分が多すぎて申し訳ない

**はちみつ餃子** ◆8X2XSCHEME · 2021/12/09(木) 10:43:53.70

そこらへんのメカニズムはどんな入門書にでも書いてあるはずだよ。
C# の経験があると C++ の入門書では重複する考え方も多くて馬鹿らしく思うかもしれないけど、
似て非なる機能や用語で混乱しないためには基礎から学んだほうがいい。

**デフォルトの名無しさん** · 2021/12/09(木) 11:33:51.67

newを知っててもdelete知らなかったりするからな

**デフォルトの名無しさん** · 2021/12/09(木) 11:45:45.22

そこらじゅうにうんこをばらまいておいて誰かが始末してくれると信じているというわけか

**デフォルトの名無しさん** · 2021/12/09(木) 12:14:01.37

やつらメモリーリークという言葉自体知らなかったりするから

**デフォルトの名無しさん** · 2021/12/09(木) 17:58:28.95

GC言語でもファイルのcloseはあるから
C++はメモリもあれと同じでnewした物は全部責任持ってdeleteしなきゃならないんだよって教えるんだけど
みんなこの世の終わりみたいな顔する

**デフォルトの名無しさん** · 2021/12/09(木) 18:13:01.83

>>275
w

**デフォルトの名無しさん** · 2021/12/09(木) 20:34:39.79

おまいら「よう、うんこ掃除屋」
unique_ptr「…」

10年後、人類はAIの反乱で滅亡するのでした

**デフォルトの名無しさん** · 2021/12/09(木) 21:19:33.80

コンピューターの計算だから正しいっ！！

**デフォルトの名無しさん** · 2021/12/09(木) 23:56:02.90

>>271
Cのは
破棄されない

**デフォルトの名無しさん** · 2021/12/09(木) 23:59:22.21

>>282
Cで書かれてるならデストラクタなどはないのでメモリ解放で破棄

**デフォルトの名無しさん** · 2021/12/09(木) 23:59:43.06

Cの構造体はunwindされずただぶっちされるだけ
コードの実行がぶっちされるのはC/C++共通う

**デフォルトの名無しさん** · 2021/12/10(金) 00:07:01.17

自身を適切に開放なり後始末なりするデストラクタを持たないオブジェクトは例外でほぼ等しく致命傷を負う
そういうデストラクタを持っているつもりでも、コードの実行順がぶっちされることにより、
プログラマーの不注意ですぐ致命傷を負う

**デフォルトの名無しさん** · 2021/12/10(金) 00:28:44.05

cat >sample_cpp.cpp <<EOF
#include <iostream>
using namespace std;
struct s {
~s() {cout << "called." << endl;}
};
void func1() {
s a;
throw "hoge";
}
extern "C" void func2(void(*)());
int main() {
s a;
try {
func2(func1);
}
catch(const char* m) {
cout << m << endl;
}
return 0;
}
EOF
cat >sample_c.c <<EOF
struct s {
int dummy;
};
void func2(void (*f)()) {
struct s a;
f();
}
EOF

**デフォルトの名無しさん** · 2021/12/10(金) 00:29:59.22

gcc -g -c sample_c.c
g++ -Wall -g -c sample_cpp.cpp
g++ sample_c.o sample_cpp.o -o sample
./sample

実行結果
called.
hoge
called.

>>284-285
Cにはデストラクタがないので、メモリが開放されればOKであり、自動的に開放される
C++ではスコープから外れればデストラクタが呼ばれた後にメモリが開放される

**はちみつ餃子** ◆8X2XSCHEME · 2021/12/10(金) 01:18:14.66

JavaScript でリソースを解放 (GC で回収) するために
変数に false を代入して参照を切っているのを見たことが有って、
GC があってもこの手のバッドノウハウは要るんだなと思いました。 (小並感)

**デフォルトの名無しさん** · 2021/12/10(金) 01:52:31.83

GCが正常に機能しているという保証がそもそもないから
そもそも何が正常な動作なのかを誰も責任とらない架空の権威によって成り立っている

**はちみつ餃子** ◆8X2XSCHEME · 2021/12/10(金) 01:58:44.76

メモリ回収のタイミングが保証されないのは大した問題ではない
(プロセスが終了すればどうせ回収されるので)
のだが、外部のリソースを掴んでいるときに後始末されないかもしれないのは困るな。

**デフォルトの名無しさん** · 2021/12/10(金) 02:33:47.50

Windows10でコマンドプロンプトのGUIを提供するconhost.exeはナウくてヤングなC++のstd::basic_string_viewを使っている
Windows2000以来のconhost.exeが古いコードのままメンテ放置されているわけではないことがわかり少しだけほっこりする
以下、それらしきシンボル
TextBuffer::InsertCharacter(class std::basic_string_view<unsigned short,struct std::char_traits<unsigned short> >,class DbcsAttribute,class TextAttribute)

ま、本当はなにをしたかったというとpwsh.exeとconhost.exeが道連れクラッシュして困ってるってだけなんだが

**デフォルトの名無しさん** · 2021/12/10(金) 05:50:56.28

多人数のプロジェクトほどuniqueではなくshard_ptrが増えるのはトラブった時に誰も責任取らなくていいからって事？

**デフォルトの名無しさん** · 2021/12/10(金) 07:04:02.57

shared_ptrを乱用する職業PGよりもweak_ptrを使いこなせる厨二PGたれ
主従関係がある場合、主が従のｼｪｱﾎﾟを持ち、従が主のｳｲﾎﾟを持て

**デフォルトの名無しさん** · 2021/12/10(金) 07:11:56.68

多くの職業PGは依存関係を親子関係で騙りたがるが、
生物学上、親は子より先に生まれ先に死ぬのだから、FIFOは成り立つがLIFOは成り立たない
ポリコレ的にはマスター/スレーブではなくプライマリ/セカンダリが望ましいとされる
ルー語の乱用をさけるならばプライマリ/セカンダリではなく主/従がなお良い
よって依存関係を主従関係で騙るのが正しい
織豊政権のように、主君の死後に従者が取って代わった例もあるから完全ではないが

**デフォルトの名無しさん** · 2021/12/10(金) 07:15:52.21

秀吉は主君信長のweak_ptrを持っていたので本能寺の変での主君の横死を的確に知ることができた

**デフォルトの名無しさん** · 2021/12/10(金) 07:35:10.03

くだらねえ
喩え話なのはみんなわかってんのに
覚えたての日本語ひけらかしてドヤるな

**デフォルトの名無しさん** · 2021/12/10(金) 08:04:47.84

ルー語の乱用を避けるのが礼儀だぞ

**デフォルトの名無しさん** · 2021/12/10(金) 08:16:32.12

>>290
そうなんだよね
リソース解放のタイミングが保証されないのは言語設計のミスだった
JavaではファイルやソケットなどのリソースはGCのときに呼ばれるfinalizeで解放すればいいよって思想だったけど
いつfinalizeが呼ばれるのか予測できないことに起因するバグが多発
ついにfinalizeが廃止されることになった

リソースは自前で廃棄してねというスタンス
GCも当初の期待ほどうまくいってない

**デフォルトの名無しさん** · 2021/12/10(金) 09:48:13.03

ファイルやソケットの開放はcloseないしデストラクタでやるのだから保証されてるぞ？
保証されないのはメモリリソースだけ

あとjavaも当初からfinalizeが呼ばれることは保証されてなかったからfinalizeで開放しなさいなんていう慣習はなかったと思うが

**デフォルトの名無しさん** · 2021/12/10(金) 10:14:08.92

JavaはJDBC周りのGCの挙動が厄介だYO
GC性善説に立つと痛い目にあう

**デフォルトの名無しさん** · 2021/12/10(金) 11:20:58.79

>>299
JavaやC#にはデストラクタないからね
C++経験者がJavaやC#ではファイナライザーを使ったりしてたんだよ
C#ではマイクロソフト謹製標準ライブラリでさえファイナライザーでファイルを閉じるクソコードがある

**デフォルトの名無しさん** · 2021/12/10(金) 11:32:06.75

いつまでスレ違いの話続けんの？間違いの指摘すら面倒

**デフォルトの名無しさん** · 2021/12/10(金) 11:49:22.35

C#はファイナライザで解放でいいんだよ
Disposeパターンがそういうスタイルだから

**デフォルトの名無しさん** · 2021/12/10(金) 11:51:44.78

>>301
それはその個人が不勉強なだけだろ…
finalizeが呼ばれないことがあるのはあまりに初歩的なチップスで、初級でない一般的なJavaプログラマがfinalizeだけでリソース開放するとかありえない。
思想って誰の思想？

メモリ解放に気を使わないC/C++プログラマがいないのと同じ

**デフォルトの名無しさん** · 2021/12/10(金) 12:27:48.66

>>304
その不勉強な個人が多すぎたんでしょ
デストラクタの代わりにファイナライザーを使う誤用が多かった
finalize廃止を決断しなければならないほどにね

**デフォルトの名無しさん** · 2021/12/10(金) 12:36:42.08

C++の轍を踏まないはずが
ざまあねえな

**デフォルトの名無しさん** · 2021/12/10(金) 12:43:00.40

>>ID:Qqc0ky4z
>>298
>JavaではファイルやソケットなどのリソースはGCのときに呼ばれるfinalizeで解放すればいいよって思想だったけど
>>301
>C#ではマイクロソフト謹製標準ライブラリでさえファイナライザーでファイルを閉じるクソコードがある
>>305
>その不勉強な個人が多すぎたんでしょ
上記発言を見ればあなたが不勉強なのはわかったよ

**デフォルトの名無しさん** · 2021/12/10(金) 16:09:36.14

vectorのaが空じゃないと思い込んでて実は空の状態で
for (int i =0; i < a.size()-1; i++)
これやると一瞬でオワるのなんとかならないかな
まあ普通はa.sizeをintやらでキャスりましょーって話だとは思うけど
そもそもsizeの型がuなのが悪いと思うんだが
uじゃなきゃ足りないくらいの要素数確保することなんてあんのか？ぁん？

**デフォルトの名無しさん** · 2021/12/10(金) 16:21:05.76

i+1<a.size()

**デフォルトの名無しさん** · 2021/12/10(金) 16:24:59.62

または、if(!a.empty()) for(...)

**デフォルトの名無しさん** · 2021/12/10(金) 16:26:11.66

>>309
てんさいかよ

**デフォルトの名無しさん** · 2021/12/10(金) 16:40:04.25

C++20にはstd::ssize()もあるぞ

**デフォルトの名無しさん** · 2021/12/10(金) 16:46:05.19

i <= a.size()-1じゃなくて i < a.size()-1？

**デフォルトの名無しさん** · 2021/12/10(金) 16:54:00.86

以下のような直感的でベタな条件式のほうがいいと思うよ
for (int i =0; a.size() > 0 && i < a.size()-1; i++)

**デフォルトの名無しさん** · 2021/12/10(金) 16:56:40.50

一見すると小学生の書いた作文っぽく見えるコードが結局のところ一番良い
厨二を拗らせたような難解なコードは避けよう

**デフォルトの名無しさん** · 2021/12/10(金) 16:58:49.17

このループ内でa[i]とa[i+1]を使ってなんかするんだろ
a[i+1]が有効なインデックスか？という条件がi+1<a.size()でこれは自然

**デフォルトの名無しさん** · 2021/12/10(金) 17:19:52.62

ああ、それなら納得

**デフォルトの名無しさん** · 2021/12/10(金) 17:20:02.15

なんで-1してるの？

**デフォルトの名無しさん** · 2021/12/10(金) 18:23:30.43

出典忘れたけどsizeが符号無しなのは標準委員会も失敗だったと考えてるらしい（？）

**デフォルトの名無しさん** · 2021/12/10(金) 20:12:16.24

まあ、そうでなきゃssize_tなんて恥ずかしいもの後付けしたりしないし

**デフォルトの名無しさん** · 2021/12/10(金) 20:26:39.77

>>314
二回余計な比較にクロックを喰われる

**デフォルトの名無しさん** · 2021/12/10(金) 21:01:58.48

最近このスレやばない？
intじゃなくてstd::vector<...>::size_typeでいい
>>310は明らかに間違ってる
1引くケースは大抵サイズ2以上がよくある事前条件なので普通事前に弾く
ループ内や別スレッドでvectorが変更されないケースならループの外で1引いた方が速い
今回ssize_tは無関係

**デフォルトの名無しさん** · 2021/12/10(金) 21:13:20.54

>>322
どこがヤバイの？
普通に動くし

**デフォルトの名無しさん** · 2021/12/10(金) 21:27:52.13

>>323
列挙したところ。普通にレベルがやばい。
>>310はwhile(!a.empty())と書いてるのかと思ってたので俺の勘違い。
何が普通に動くの？

**デフォルトの名無しさん** · 2021/12/10(金) 21:33:24.42

>>324
いや、間違えてるとか言われてたからな
頭の中で動かしてみて問題なく普通に動くだろうと
ってなんでお前そんなにエラそうなの？エラが張ってる民族か？

**デフォルトの名無しさん** · 2021/12/10(金) 22:00:02.92

>>325
聞かれたから答えたけど会話にならんな・・・この辺で

**デフォルトの名無しさん** · 2021/12/10(金) 22:00:16.81

どうしたらいいかご意見を聞かせてください！٩( ᐛ )و

class hogeにおいてメンバ変数unique_ptr<toge>toge1を所有しております。
vector<hoge> vHogeを運用するとき、hogeのインスタンスをプッシュバックしようとすると、削除された関数ですというエラーメッセージが帰ってまいります。
おそらくtoge1がユニークポインタであり、ムーブ以外の移動が不可能だからだと思うのですが……このままプッシュバックさせるのに何か方法はありますでしょうか？

健作でtoge1にshared_ptrを使う、hogeのコピーコンストラクタにmemcpyを使う等の解を見つけました。
私ごとですが、shared_ptrは循環参照で失敗した哀しい過去があり、恐怖感があります。
またmemcpyでユニークポインタをメモリコピーする場合の機序がイマイチわかりません……
ムーブを経由させずにどうやってユニークポインタを再確保出来る証拠でしょうか……？

どちらの方法でも、実行する場合の注意点があればなんでも教えていただければ幸いです(^O^)/
また上記以外の方法も、もし存在するならば教えていただけると嬉しいです(´；ω；`)

先にお礼申し上げます。ありがとうございます。

**デフォルトの名無しさん** · 2021/12/10(金) 22:05:57.88

>>326
もとはといえオメェが勘違いしたからだろこのヒトモドキが

**デフォルトの名無しさん** · 2021/12/10(金) 22:09:42.92

>>327
再現コードをどこかに貼って。伝わらない。
>>328
煽ってるだけじゃんｗだから会話にならないんだよｗ

**デフォルトの名無しさん** · 2021/12/10(金) 22:20:49.71

>>322
普通事前に弾くとかドヤ顔で言われてもそんなの200も承知の助なんだよ
ああいう不測な組み方で死にかねない爆弾抱えるデメリットに比べたら
unsignedなことによるメリットなんて実質ほぼないカスみたいなもんだからsizeがunsignedなのは設計ミスではって話

**デフォルトの名無しさん** · 2021/12/10(金) 22:23:19.44

申し訳ございません( ✌︎'ω')✌︎
遅れましたがこれです。
プッシュバックでエラーががが

struct Toge{
int a=0;
};
struct hoge {
std::unique_ptr<toge> toge1;
};

int main ()
{
std::vector<hoge> vHoge;
hoge hoge001;
vHoge.push_back(hoge001);
}

**デフォルトの名無しさん** · 2021/12/10(金) 22:24:50.14

大文字になってしまった……
struct Toge >>> struct toge
と思っていただければ……

**デフォルトの名無しさん** · 2021/12/10(金) 22:34:31.10

vHoge.push_back(std::move(hoge001));

**デフォルトの名無しさん** · 2021/12/10(金) 22:36:13.76

vectorに突っ込んだらもうhoge001は使わないんだったらvHoge.push_back(std::move(hoge001));

コピーさせたいならhogeにこんなコピコンとコピop=を定義しとけばいい
hoge(const hoge& other) : toge1(new toge(*other.toge1)){}
基本はmoveだけど時々コピーもしたいくらいなら特殊関数じゃなくてclone()みたいな関数にしておく
どれがいいかは本当の用途と目的で選んで

**デフォルトの名無しさん** · 2021/12/10(金) 22:37:31.61

>>332
コンパイルエラーを直してください
https://ideone.com/RxQYii

>>330
承知してるなら弾け
今回の用件はsize_type使えばいいだけなのでunsignedかどうかは関係ない

**はちみつ餃子** ◆8X2XSCHEME · 2021/12/10(金) 22:52:51.98

>>327
> hogeのコピーコンストラクタにmemcpyを使う等の解

これについてはダメ。
設計上の話ではなく言語仕様での保証がない。
そんなのがまかり通ったらスマートポインタの意味がない。

型が trivially copyable の要件を満たすときだけ memcpy でのコピーが許されている。

**デフォルトの名無しさん** · 2021/12/10(金) 23:02:05.91

>>335
オメェが直して差し上げろよ
本人それで困ってんだからよ

**デフォルトの名無しさん** · 2021/12/10(金) 23:18:01.33

>>337
なんだか煽ってばかりですね。質問内容は明快にしないといけないので。

**デフォルトの名無しさん** · 2021/12/10(金) 23:22:36.91

ああ言えば上裕
オメェそっくり

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

>>335
いや関係大ありだから
ないって言い張るならsizeがunsignedなメリット挙げてみなよ、ないでしょ

**デフォルトの名無しさん** · 2021/12/10(金) 23:41:07.01

>>333
>>334
お風呂に入っており返信が遅くなりました。
なんてお礼を言ったらいいか、std::moveで解決しました。
自分の知識不足ではありますが、素早い返信に感謝でございます(〃ω〃)
生成したユニークポインタはベクターに移せれば使い捨てのでムーブで良さそうです。
std::moveについて調べてみます！

>>336
ありがとうございます。
メモコピーで解決するというページがあったのですが、正直機序がわからず不安でした（笑）
シェアードポインタかムーブで対応したいと思います。
有難うございました。