C++相談室 part133

2017/11/24(金) 16:52:50.43

次スレを立てる時は本文の1行目に以下を追加して下さい
!extend:on:vvvvv:1000:512

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

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

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

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

[C++ FAQ]
https://isocpp.org/wiki/faq/
http://www.bohyoh.com/CandCPP/FAQ/ (日本語)
VIPQ2_EXTDAT: default:vvvvv:1000:512:----: EXT was configured

VIPQ2_EXTDAT: default:vvvvv:1000:512:----: EXT was configured

2017/12/23(土) 23:37:21.27

>>651
どうでもいいが知恵袋とのマルチだな

2017/12/23(土) 23:51:11.43

>>656
オススメのツール（ソース)ある？見てみるから。
ＵＲＬあれば助かる。

2017/12/23(土) 23:53:25.60

>>658
横レスだけどgrepとか結構すごいぞ

2017/12/23(土) 23:57:45.94

そこら辺は古すぎるので現在の常識とは異なる場合があると思うけど

2017/12/24(日) 00:00:12.41

std::vector::erase - cppreference.com
http://en.cppreference.com/w/cpp/container/vector/erase

>Invalidates iterators and references at or after the point of the erase, including the end() iterator.

翻訳には肝心のモンが抜けてるんじゃあねえのか？
複数形のsとか

2017/12/24(日) 00:06:07.20

>>659
サンクス。見てみているが、まずGNUはこのコーディングルールがな…
ちなみにこれ、今時ハイライト（色づけ）されないのは何とかならないのかね。
http://git.savannah.gnu.org/cgit/grep.git/tree/src/grep.c

2017/12/24(日) 00:10:15.35

>>660
そう思うなら、今の常識に照らして書き直してあげたら？
パフォーマンスあがるならマージしてもらえるぞ

2017/12/24(日) 00:13:30.13

Linusはプログラマの頂点ではないしGNUは最も優れたプロジェクトではない
既に手本にならない部分は多い

2017/12/24(日) 00:15:10.13

>>655
>元々指していた「削除された要素」ではないことを「無効」と表現している。
そうなの？
規格ではclearとかresizeとかでも無効になる(invalidate)と書いてあるしeraseがそれと何か違うようにも見えないし、無効なiteratorをdereferenceするのは未定義だとも書いてあるように見えるけど。

>つまり、ド頭から密に詰められていることを規定されているので、
>削除すれば当然次の要素が入るに決まっているし、
>（これは君は正しく理解しているが）reallocはなされないし、
>vec[0]についてもアクセス時点での先頭要素が取得できるに決まっている。←多分君はここを勘違いしている
ポインタならそうだろうけどvectorのiteratorでも規格上保証されてるの？

ttps://stackoverflow.com/questions/45758659/does-stdvectorerase-really-invalidate-the-iterator-at-the-point-of-erase

2017/12/24(日) 00:17:58.25

>>661
> including the end() iterator.
いや、これが抜けてる方が大問題だろ。
まあ広い意味では「それ以降の要素を指すイテレータ」に含まれるとも言えなくもないが、
これについては明記されるべきだね。
しかしこれだとイテレート中に削除していいのか？と心配になるが、
直ぐ下のサンプルコードで「偶数番目の要素を削除」してるからいけるんだろうね。

てか初心者なら、この辺のサンプルコードから出発した方がいいよ。いろんな意味で。
ちゃんと公式な使い方してあるし。(当然戻り値をイテレータに代入している)
> // Erase all even numbers (C++11 and later)
> for (auto it = c.begin(); it != c.end(); ) {
> if (*it % 2 == 0) {
> it = c.erase(it);
> } else {
> ++it;
> }
> }
> http://en.cppreference.com/w/cpp/container/vector/erase

2017/12/24(日) 00:17:58.87

>>663
何で興味もないものに時間をかけてやらなきゃならない
ちゃんと動いていれば十分

◆QZaw55cn4c (ﾜｯﾁｮｲ 7f60-IIk+) · 2017/12/24(日) 00:19:42.01

std::vector の場合はこう、std::list の場合はこう、とかいう知識はあまり意味がないのではないか？
erace() したら、erace() したところおよびその後を指していたイテレータ（＝ポインタ）は使えなくなる、くらいで一括するのが妥当だと考える。

2017/12/24(日) 00:23:13.30

細かい場合分けするのはプログラミング的に悪だと思ってる。
統合的に丸っと処理できると気持ちいい。
なのでちょっと粒度を上げてSTLの作法というものを考えた方がイイ。

2017/12/24(日) 00:39:36.50

>>667
無理ならそういえばいいのに

2017/12/24(日) 00:49:18.45

>>665
つか、君は何に文句を言っているのだ？そこにそのまま書いてあるだろ。
> When describing iterator invalidation,
> the C++ standard takes the simplifying assumption that iterators refer to elements,
> and a valid iterator value always refers to same element.
> Invalidating references, pointers or iterators to an element all follow the same rules. (The exception is the end iterator).
>
> Clearly references or pointers to the erased element are invalidated by a call to erase,
> thus under the standard's simple rules so are all iterators.
> It could have described what new element must be moved in place abd substituted what iterators refer to,
> but the writers of the standard chise not to go there. They instead simply dictated the iterator was invalid.

eraseでvecが移動しないことは保証されてるだろ。
当然vec[0]は削除後の先頭要素を指す。
ただしそもそも削除後にイテレータを再代入してないコートについては知るかボケだろ。
それについてもそこにモロに書いてあるし。

そのページは俺の言い分を全く書いてあるような物なんだが、何が言いたいんだ？

2017/12/24(日) 01:05:17.93

そもそもeraseするならvectorなんか使うな。よっぽど小さいvectorじゃない限り
eraseは縮小操作だからリアロケーションは起きないけどその時何が起こるのか理解してるのか？
理解できないならお前はC++を使えないやつ

2017/12/24(日) 01:25:35.46

>>659
こんなもんじゃね？みたいな感じなんだが。
決して理解したわけではなく、雰囲気だけしか見てないが。

C特有のstructの嵐でもなく、
今ならIDEが警告出してくるほどのif文等のネストもなく、
意味不明なマ黒魔術使いまくりでもない。
グローバルが嵐になっているが、これはCUIツールだから大して問題ないし。

色が付いてないのとコーディングルールがアレなので詳しく読む気にならないが、
整形ツール通せば結構読めるコードのような気がする。

2017/12/24(日) 01:43:03.65

>>671
>eraseでvecが移動しないことは保証されてるだろ。
>当然vec[0]は削除後の先頭要素を指す。
誰もそんなことは問題にもしてないんだが大丈夫？
偉そうなことを言ってる割には全然読めてないんだなあ

2017/12/24(日) 01:44:55.52

>>674
日本語でおｋ

2017/12/24(日) 02:04:36.00

>>675
>>634から読み直してこい。俺も言葉を省略したが文脈上まさか読み間違う人がいるとは思わなかったんだ。

2017/12/24(日) 02:08:57.97

>>676
韓国人死ね

2017/12/24(日) 02:11:04.69

ん？これは痛い。

◆QZaw55cn4c (ﾜｯﾁｮｲ 7f60-IIk+) · 2017/12/24(日) 02:15:08.39

>>634
ite = vec.begin()
++ite;
ite = vec.erase(ite);
--ite;
であれば ite == vec.begin(); は保障できるが、

vec.erase(ite)
とした場合の ite の値は、コンテナ vec のどこかを指している保障はないのでは？
したがって、--ite もどこを指しているか保障がないのでは？
典拠を示してほしい

2017/12/24(日) 02:19:46.66

イテレータを削除したときあり得る処置。
一個目。
メモリの再確保相当のことをして再構築する。
二個目。
尻尾の要素をムーブして詰めて最後の要素を開ける。

このどっちかだと思う。
2個目だとイテレータのロストはしないかもしれないが、
1個目だとアドレスが変わっちゃうのでイテレータが保持しているアドレスは無効。
両方あり得るのでeraseの戻り値はちゃんと受け取ろう。

2017/12/24(日) 02:38:56.42

>>680
お前もちゃんと読めよ
> 戻り値
> 削除された要素の次の要素を指すイテレータを返す。
> そのような要素が存在しない場合は、end()を返す。
> さらに、削除された要素以降の要素の数と同じ回数のTのムーブ代入演算子が呼ばれる。
> https://cpprefjp.github.io/reference/vector/erase.html

つかC++にはGCねえんだよ
Java鹿死ね

2017/12/24(日) 02:50:37.41

規格にきっちりかっちり書いてある挙動について
あり得る処置（ｷﾘｯ
とか抜かして適当な憶測垂れ流す奴がいるんだな

2017/12/24(日) 02:59:23.68

なんか話が混ざってる気がするけど、eraseに渡した引数のイテレータの話じゃないの？

2017/12/24(日) 03:05:24.20

>>681
>○ vec.erase(ite)後にiteが指すのは「次の要素」であり、
>元々指していた「削除された要素」ではないことを「無効」と表現している。
とか書いちゃう人が言っても説得力ないけどねw

2017/12/24(日) 05:55:00.21

>>681
GCどっから出てきた。韓国人といい。話が飛躍しすぎ。

2017/12/24(日) 06:05:35.39

>>682
小出しにしないでブッコンで行け。

2017/12/24(日) 09:02:08.85

昔のvectorは同一メモリ上にデータが配置されていることは保障されていなかったから昔の環境でなにか作る場合は注意したほうがいい。
そういう処理系が存在するのかどうか疑問だけど。

2017/12/24(日) 10:15:11.27

>>679
俺の論旨は保証ねえだろなんだが
だからreallocを持ち出した
典拠というのがあるなら631で
俺はそれを変だと言っている

2017/12/24(日) 10:18:18.02

>>687
え？？
昔ってどのくらいのことを言っている？

そもそも連続領域でなければリストと同じ特性になってしまい
配列であることのメリットが完全に失われるだろ
ポインタの配列になっていて実体はばらばらでもよいということならわかるが

2017/12/24(日) 10:26:48.95

>>649
横だが。

ソース見ろとよく言っている奴が居るので偶には、ってやってるんだが、
どこにあるかわかりにくい上に何だかなあ、なコードなんだが。
とりあえずこれでいいのか？
https://gcc.gnu.org/onlinedocs/gcc-4.6.2/libstdc++/api/a01116_source.html
そしてiterator.cがどこにあるか分からないという、、、

同様の奴もいるが、あまりオススメはされてない。
https://stackoverflow.com/questions/4304783/c-vector-source-code

> 00402 iterator
> 00403 erase(iterator __position)
> 00404 {
> 00405 typename _Base::iterator __res = _Base::erase(__position.base());
> 00406 return iterator(__res, this);
> 00407 }
> 上側URL
__position.base()ってのは<T>だから致し方なしかもしれんが、
確かにこれだとC使いにとってはC++は冗長すぎる。
> ｃ原理主義者はそぎ落とされたロジックにしか興味ない
> c++は彼らにとっては冗長なんだろう (>>656)
は当たってる。

2017/12/24(日) 10:56:02.77

>>689
C++は厳密な定義を始めたのはここ最近の話で昔はほぼ実装に丸投げしてた。
これは、きゃするのように仮想コンピュータを定義しないでやってきたツケだな。
ぼんやりとコンピュータっていうものの抽象化イメージだけで進んできた。
あと、C++はわからないけど、Cはとあるコンピュータに依存するものは規格に入れない決まりになってたと思う。

2017/12/24(日) 12:00:47.90

>>691
韓国人2号も死ね

つかお前は>>682が>>680（お前）向けであることをまず理解しろ
日本語が不自由なら死ね

2017/12/24(日) 12:03:39.37

この手のキチガイが湧いてくるまでになったか
このスレももう終わりだな

2017/12/24(日) 12:22:41.71

流れ読んでないけどvec[0]が無効になるって発言したやつがいるから荒れてるの？

2017/12/24(日) 12:29:05.39

真に受けてソース読んでるしw というか読めてないしwww
実装見ても理由なんて分かるわけないだろ
質問者の使ってる実装は動いてしまう実装なんだから

2017/12/24(日) 12:30:40.54

>>694
誰もそんなこと言ってないけどそう言ったと勘違いした人はいたみたいね
荒れてる原因はみんなが少しずつテキトーなことを言ってるからじゃないか？

2017/12/24(日) 12:34:48.10

>>692
俺が死んだら責任とってくれるんだよね？

2017/12/24(日) 12:38:20.58

遺書を書いて死んだら>>692は事情聴取くらいはされるかもね

2017/12/24(日) 12:39:11.17

軽いなぁ。

2017/12/24(日) 12:39:11.70

「>>692に死ねと言われたので死にます」

2017/12/24(日) 12:41:53.58

このスレ頭おかしいのとプログラミングスキルでイキリ散らしたいのしかいねえな

2017/12/24(日) 12:42:40.51

令状出れば家宅捜査とPCの押収くらいはしそう

2017/12/24(日) 12:58:57.63

俺は叩き合いが面倒だから理由つけてしゃべってるのに、問答無用で死ねはひどいよなぁ。
完璧超人じゃないから間違いの一つや二つくらいするよ。
なぁ。完璧超人。鏡見てみたらいいと思うよ。自分ぶっ殺したくなると思うよ。

2017/12/24(日) 13:42:19.40

寝る。

2017/12/24(日) 19:53:35.49

> プログラミングスキルでイキリ散らしたい

ニヤニヤ

2017/12/25(月) 18:50:42.37

文献に書いてあることが全てだと真信してマニュアル通りに事を進めていくってまぁ受験とかならソレで良いかもしれないけどね。
物事の成り立ちを追っていくと決してその通りではないことも世の中にあるわけできちんとそういう所は汲み取っていかないとただ
の鉄砲玉みたいな一番扱いが厄介な｢無能な働き者｣になってしまうよ。
特にこの業界では型にはまってばかりの柔軟性のない>>692みたいな思想の違うものは徹底的に粛清しようとするワンマン堅物野郎は淘汰されるべきだと思うけどね。

2017/12/25(月) 18:53:10.54

>>694
日本語も英語も読めない不遜鮮人2人(>>674,>>686)が火病してるだけ。
話に脈略が無く、突然火病るのはいつものこと。
だから嫌われる。当然韓国人は排除されるべき。邪魔だから。

話が噛み合ってないのなら噛み合わせる努力をすればいいだけ。
それ以前に知りもしない奴がデタラメに回答する必要もない。

そして状況を知りたければ全部読めばいいだけ。
日本語が読めない馬鹿ゆとり>>694も邪魔なだけ。
つまり、結論は、

韓国人マジで死ね
ゆとりも死ね

お前らが居なければどれだけ2chから雑音が減るか、少しは考えてみろ。

2017/12/25(月) 18:54:43.46

>>706
日本語でおｋ

2017/12/25(月) 20:36:12.13

>>707
急にどうした？
ヘイトはよくないぞ

2017/12/25(月) 22:20:40.14

初心者ですがGC付きの言語しかやったことないのでメモリ管理について質問させてください
例えば下記のようなコードでは、hoge関数で確保したvector用のメモリはGCがないためプログラムが終了するまで解放されないということでしょうか？
少なくともpiyo関数が終了するまでは残ってないと使えないですよね？

vector<string> hoge(){
vector<string> v = {"hoge", "piyo"};
return v;
}

string piyo(){
vector<string> v2 = hoge();
string s = v2[0] + v2[1];
return s;
}

int main(){
cout << piyo();
}

2017/12/25(月) 22:33:37.01

まずはスタックとヒープをググって調べてみるといいかも。

2017/12/25(月) 22:47:27.89

>>711
ヒープってオブジェクトをインスタンス化したときに割り当てられるメモリ領域って認識なんですが合ってますか？

Cは関数内で宣言したローカル変数に配列を代入しても関数外に引き継げないのでまだわかるのですが、C++の考え方が掴めず混乱してます……

2017/12/25(月) 23:11:18.12

>>706
ヘタレか？

お前の喧嘩を買ってやると言っているのだから、
馬鹿パヨク韓国人なりの論理を展開してみろよ。

状況としては、2chは地域の公園のようなもので、
誰でも自由に入って楽しむことは出来るが、
飼い犬のウンコをまき散らして帰るような奴は二度と来るな、と当然思われる。
それを俺は、はっきり言ってやってるだけだ。
お前らは馬鹿すぎて理解できないようだから、直接的に言うしかない。

韓国人死ね

で、それで俺を嫌うのはお前らの自由だが、当然それでは何も解決しない。
お前らが迷惑行為を続け、他の連中に嫌われ続けるのも変わらないからだ。
何でも他人のせいにして被害者ぶるのはマジでムカつかれるから止めた方がいい。
嫌われる原因はお前ら自身にある。特に匿名掲示板ではそうだ。

**片山博文MZ** ◆T6xkBnTXz7B0 (ｽﾌｯ Sd1f-1u/G) · 2017/12/25(月) 23:19:00.09

一秒一秒大切に。 Please don't waste your time.

2017/12/25(月) 23:23:13.44

vector<string>　←これはコピー
vector<string>& ←これは参照

戻り型を参照にしたらプログラムがあぼーんするけどね

2017/12/25(月) 23:31:00.53

>>715
ということは、>>710でいうとpiyoが受け取ったvectorとhogeが返してるvectorは中身が同じだけの別物ということですかね？
いわゆるメモリリークはあくまでfree忘れやdelete忘れさえしなければそんなに心配しなくてもいいということでしょうか

2017/12/25(月) 23:37:09.45

>>716
うん別物
で、hoge内のvectorはRAIIの仕組みによって自動的に開放されているから安心して

2017/12/25(月) 23:40:36.26

>>717
なるほど…やっとモヤモヤが晴れてきました
ありがとうございます
RAIIについても調べてみます

2017/12/26(火) 01:22:10.13

vector<string> hoge(){
vector<string> v = {"hoge", "piyo"};
return v;
}

vector<string> v2 = hoge();

関数スコープを抜けたら、関数内のオブジェクトは、自動的に消滅する。
return した瞬間に、代入演算子で、コンテナ内のデータをすべてコピーするのかも。
2重にデータを作るから、無駄

一方、参照型の言語では、primitive 以外は、すべてオブジェクトで、参照で扱う。
コンテナの参照(アドレス)をコピーするだけだから、オブジェクトは1つだけ

f(ref inout){ ～ }
C/C++ だけ、関数の引数に、更新用の参照を渡して、
関数内部で、そのオブジェクト・コンテナを更新することを、明確にした方が良いかも

2017/12/26(火) 01:29:42.80

>>719
C++11 以降の vector ならそういう場合は最悪でもムーブするんちゃう？
NRVO が効くかもしれんし、全コピーは無いと思うが。

2017/12/26(火) 01:41:08.77

断っておくけど俺はc++は素人なので誰か訂正よろ

>>711
横からだけど
それはこの場合の答えには向いてない気がする

>>717
>>719

そのvectorは関数を出ても破棄されないしコピーされない
そのまま使われる
RVO（RETURN VALUE OPTIMIZATION）という仕組みがあって無駄なオブジェクトの生成が抑制される

c++はこういう所を死ぬほど気にする言語

2017/12/26(火) 02:06:41.75

Rust には、オブジェクトの所有権という概念がある

代入で、所有権がmove する。
オブジェクトはコピーされず、1つだけで、所有権が移動するだけ

こういう概念が、言語ルールにあるから明確

2017/12/26(火) 02:14:08.86

>>721
RVO は C++17 で必須化されたけど、 >>719 の事例はいわゆる NRVO で、やってもやらなくてもよい最適化のはず。
しかしムーブはコピーよりも優先されるので処理系が NRVO を最適化しなかったとしてもムーブが発動する。
故にコピーはしない。

2017/12/26(火) 02:20:19.84

弱いものを踏みつけて偉い事を誇示しないと生きていけないなんてかわいそう。
それだけがやり方だと思ってるんだったら先はない。

2017/12/26(火) 06:35:31.17

>>724
強者が言えば説得力があるが
強くなる努力・精進を惜しむ怠け者の言い訳は見苦しいだけだ

2017/12/26(火) 06:52:36.87

>>691
実装を限定はしていなかったというだけの話か？
だとしたら興醒めだな

確かに昔のC++は実装と提供の分離が論点なので
vectorの実装がリストでも文句をぬかすな、だったが
じゃあ何でvectorの他にlistがあるのかって話

2017/12/26(火) 07:14:27.81

昔は規格書に書いてある通り実装されてないことがよくあったって話だが、これ書けばよかったな。
だから大半のことは実装依存だった。
今頃になってりーぬすに怒られたからメモリの構成の話してるんだぜ。
仮想コンピュータの仕様でも決まってりゃ今頃3D扱っててもおかしくない。
今頃2Dをやっと扱えるようにしようとか言ってるんだから。まぁ、ないよりいいから期待はしてるが。

2017/12/26(火) 09:51:51.57

あほ
vectorの要素アクセス速度が添え字に比例してたら
リーナスでなくてもキレるわ
それで誰も使わなくなったライブラリがあとで改訂なんかされるかよ

# リーナス？　ここC++スレだが

2017/12/26(火) 10:01:52.49

メモリーオーダという話を最近始めた。
http://en.cppreference.com/w/cpp/atomic/memory_order
これだったかな？

valarrayさんが救済される日は来るのか。
ここ10年位で委員会の人が突っ込み入れるようになったけど、それ以前は忖度されてて誰も何も言わなかった。
だから、MSのコンパイラはタコだったんだよ。

2017/12/26(火) 10:12:55.95

ああ、最近こんな話を聞いたと自慢に来ていたのか
気の毒だがその話とvectorの実装はまるで無関係だ

悪いが俺はもう付き合ってらんねえ

2017/12/26(火) 18:46:36.46

unordered_set<valarray>でひどい目に遭ったのは俺だけじゃないはずだ

2017/12/26(火) 19:09:46.14

>>724
僕は韓国人です、ブーメランおいしい、まで読んだ

>>727
>>729
お前は何のためにここに来ているんだ？
全く脈略のない昔語りなんて、老害以外の何者でもない。
しかも内容は間違いだらけだし。

お前みたいな認知バイアス馬鹿には
> 問答無用で死ねはひどいよなぁ (703=お前)
と取れるようだから、俺がわざわざ分かりやすく、
お前が死ななければならい理由707,713を書いてやったんだ。

ちゃんと読んで死ね

> 鏡見てみたらいいと思うよ。自分ぶっ殺したくなると思うよ。 (703=お前）
むしろお前が680を書いていてまだ生きているのが不思議なんだが。
さすがゴキブリといったところか。

韓国人死ね

2017/12/26(火) 20:31:37.65

>>732 時間の無駄だ。life timeを無駄にするな。

2017/12/26(火) 20:39:22.90

>>733
あなたがどう思おうがあなたの自由だが、俺は短期的視野で動いているわけではない。

2017/12/26(火) 21:31:42.92

>>727
仮想マシンどころか現在存在するメジャーなインタプリタ言語の仕様にすら3Dはおろか2Dすら無いんだが。

2017/12/26(火) 22:46:28.20

Pythonには標準でTcl/Tkくっついてるぞ

2017/12/26(火) 22:51:40.52

えっ？

2017/12/26(火) 23:32:54.20

>>735
仮想マシンどころかってjavaとかc#とかのことさしてるの？

2017/12/27(水) 00:16:12.80

>>732
しょうがないなぁ。
じゃぁ、今死んだことにしてやるからあとの責任は取ってね。
じゃーねー。

2017/12/27(水) 10:05:47.36

↓こっちでやれ、てめーら
https://mevius.5ch.net/test/read.cgi/tech/1427572389/

2017/12/30(土) 07:52:44.61

class A {
//...
};
class B : public A {
};

A *a = new B();
delete a; // だめ
B *b = new B();
delete b; // だめ

というようにA, Bのdeleteを禁止することはできますか。
ただしこの制約はAでつくりたいです。

2017/12/30(土) 09:33:10.52

それくらい自分でよく考えろ

2017/12/30(土) 09:45:33.24

バカな考えはやめとけ
充分な知識と経験があるやつがバカな考えと知りつつあえてやるなら勝手だが
具体的なやりかたも分からないレベルのやつが思いつきでやろうとしても
あちこちぐちゃぐちゃになって自滅するだけだ

2017/12/30(土) 11:12:47.92

A&& a{B()};
B&& b{B()};
じゃだめなん？

2017/12/30(土) 12:45:48.79

うーん諦めそう

2017/12/30(土) 13:12:04.93

やりたいことを実現するだけならA::~A()をprivateにすればいい
数多の副作用をどうするかは自分で考えろ

2017/12/30(土) 13:54:05.13

ベクトルの内積を取りたいのですがC++で実装する場合最も高速な方法はなんでしょうか

2017/12/30(土) 13:54:23.97

逆にどういう条件ならdeleteしても良い条件なのか？
コレでは一向にdelete出来ないではないか

2017/12/30(土) 14:12:38.35

事故解決しました

2017/12/30(土) 14:50:42.66

罷り間違ってもdeleteできないインスタンスとなると
核開発か深海探査か宇宙船くらいしか思いつかない

2017/12/30(土) 14:58:28.45

電源を切っても生き残るインスタンス

2017/12/30(土) 15:57:20.60

最近の時事と照らし合わせると人工心肺の回収があったな
電源を切れないデザインの電子機器があるのかもしれない

2017/12/30(土) 16:04:54.13

スタックにしか置けないとか

2017/12/30(土) 19:53:03.01

>>747
詳細は？

2017/12/30(土) 19:54:40.04

逆ですね
つまりヒープにしか置きたくないです。
Aから派生したクラスのメモリサイクルを全てGCで管理します。

2017/12/30(土) 19:58:30.81

だとしたらGCからはdeleteできないと困るんでない？