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/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できないと困るんでない？

2017/12/30(土) 20:03:16.25

たとえばprivateデストラクタを呼べる状態なら
friendにすればいいかと考えています。
それができなければ単に新しいvirtual del()メンバー関数を新設するつもりです。
領域自体はfree()で解放するのでデストラクタがなくてもクラス自体は削除できます。

2017/12/30(土) 20:07:42.93

だとしたら普通newをオーバーロードするけどね

2017/12/30(土) 20:10:14.52

newは既にオーバーロードされていて
ヘッダ取り付けmallocするようになっています。
問題はnewしてAのコンストラクタが動きGCの管理化であるにもかかわらず、
deleteされたりそもそもスタック上に造られてしまうことです。

2017/12/30(土) 20:14:25.11

いまのところの案は
A のdeleteをオーバーライドして
deleteされても領域は解放されないようにすることです。
しかしこれでもスタック上に配置することはできますが。
連投失礼しました。

2017/12/30(土) 20:47:53.74

てか、C++使うな

2017/12/30(土) 21:30:00.75

GCしか使わせたくないのなら、普通にGC言語使った方がいいと思うが。
オレオレＧＣ実装とか、全くの無駄だし。
なおVC++/CLIでよければGC専用クラスを明示的に作ることは出来る。

2017/12/30(土) 21:54:06.25

おそらくid変わってます

インタプリタ作っているんです
でインタプリタでgcをサポートするためにc++でgcを書いています
ですのでなんとかc++で解決したいわけです

2017/12/30(土) 22:09:40.34

それならnew/deleteでGCしようとするのが悪手

2017/12/30(土) 22:20:41.53

どうしよう

2017/12/30(土) 22:31:11.72

インタプリタの空間からは直接deleteにはアクセスできないんだろ？
だったらstd::shared_ptr使いなよ。

2017/12/30(土) 22:53:42.57

>>766
循環参照をインタプリタで考えたくないんです

2017/12/30(土) 23:08:46.89

某書籍の問題をC++で解いています。

格子状の道路を、同じ辺を通らずに（同じ格子点ではないです）
直進と左折のみで、左下から右上まで行く道は何通りあるか求めよ。

それに対して以下のコードを書きましたが、うまくいきません。
https://ideone.com/0JMvWz

MigiDame::CanGo関数の中での挙動が、こちらが期待しているようにならないのです。
＞全部trueが返る。
＞また、releaseとdebugで挙動が違う。

どなたかご助言をお願い致します。

2017/12/30(土) 23:13:41.03

>>767
論理的に矛盾している。GCは動的に確保・解放するが、C++のスマートポインターは基本的に静的にする。
それをインタプリタ側でしたくないのであれば、外部GCエンジンをインタプリタに接続するインターフェースが必要。

2017/12/30(土) 23:29:34.53

https://qiita.com/GachiNyanNyan/items/77401f60a1ded61b3952

2017/12/30(土) 23:30:58.79

http://www.nminoru.jp/~nminoru/programming/boehm-gc3.html
こちらを参考に。

2017/12/30(土) 23:33:17.06

後はクラス内部のoperator new/deleteを定義する。

2017/12/30(土) 23:46:28.29

>>763
> でインタプリタでgcをサポートするためにc++でgcを書いています
意味不明。

例えば、JavaやC#でインタプリタ書けば全く問題ないだろ。
一般的にはシステムとユーザで別ヒープ空間にしてサンドボックス化したいけど、
GC言語って一般的にGCヒープが壊れるようなアクセス方法を提供してないから、
別空間に分けなくてもそんなに酷いことにはならないぞ。
オレオレインタプリタ程度なら問題ないはず。

2017/12/31(日) 00:00:04.48

ヒープにしか置けないオブジェクトというのは、
More Effective C++ の項目27にあったな。
>>746で既に触れられている方法だけど。

2017/12/31(日) 00:16:40.38

インタプリタのメモリー管理はインタプリタ側かGCエンジン側でしないといけない。
インタプリタでは自動的にデストラクタは呼ばれないので、インタプリタ側が引き金を引かないといけない。

2017/12/31(日) 00:19:34.27

Boehm GCというGCエンジンをそのまま使えばいいからさ。

2017/12/31(日) 00:38:38.33

>>768
255行目は「return false;」じゃないの?

2017/12/31(日) 00:49:49.20

ありがとうございます。

仰る通りでした。

お恥ずかしい。

2017/12/31(日) 01:14:19.19

>>774
継承元のコンストラクタを呼べないのでそれはできないです

2017/12/31(日) 01:33:30.83

>>763
作ろうとしているインタプリタってc++の？
それなら、自分で入力のc++のソースを解析する際に問題のクラスがdeleteされたりスタック上に生成されたりするのは検知すれば良いのでは。

2017/12/31(日) 01:34:01.16

>>773
それは嫌です
既存の処理系がcで書かれている以上なんとかなるはずです
これは好みの問題かもしれませんが

2017/12/31(日) 01:57:19.48

>>781
C で書かれてても完全に C の仕様の範囲内で書いてるとは限らんのだぞ。
アーキテクチャ依存の部分を適当に #ifdef で分岐して configure でなんとかしたりする (できる) のが C/C++

2017/12/31(日) 02:23:20.14

>>780
いいえ
c++の文法は自分の手におえません

2017/12/31(日) 07:16:38.47

>>779
コンストラクターが呼べない？
GC管理の範囲の切り分けができてないんじゃないの？
何から何までGCで管理する必要は無いはず。
Boehm GCの使い方を勉強しい。

2017/12/31(日) 07:28:36.53

もう言ってることもちぐはぐだしレス古事記としか思えない
スルー推奨

2017/12/31(日) 07:32:05.37

インタプリタで扱う、GC管理するクラスの基底クラスObjectBaseを定義して、そこでBoehm GCを使ってoperator new/deleteを定義する。
インタプリタ側でObjectBaseの派生クラスを必要に応じてnew/deleteすればGC管理ができる。

2017/12/31(日) 09:17:47.39

まだ自分では難しいですね
一旦中断して勉強し直します
ありがとうございました

2017/12/31(日) 10:57:38.40

>>781
そういう意味ではない。

>>787
まあ、根本的に分かってないというのは同意する。
今の君では無理だ。

君は「既存のインタプリタにGC機能を付け加えようとしている」、ここまではいいか？

インタプリタの場合、両端の柱は2つで、
A. evalラッパ
B. フルエミュ
で、結局の所これらの折衷案となる。どのポイントを目指すかは君が決めればいい。
ただし、君はここまですら到達できていない。

君はGCを自前で実装することにこだわっている。
これはGCをフルエミュすることを意味しているが、
この場合、delete等は常に自前パーサを逐一通すことになるので、その段階で弾けばいいだけだ。
君が言っているように「禁止する」必要は全くない。（ここが矛盾している。
GC管理変数をdeleteしようとしているかは、当然分かるし、分からないようではフルエミュできない)

だから俺たちはevalラッパ実装だという前提で話をしている。
こちらの場合は、システム側が持っている機能を使って相乗りになる。
混ざらないようにさえ出来ればとりあえずは動く。

コードを書く以前に、まず、仕様を固めないと駄目だ。君はここが出来ていない。
もっと上位の、エミュレーション戦略を固めないと話にならない。

2017/12/31(日) 12:02:46.05

＞この場合、delete等は常に自前パーサを逐一通すことになるので、その段階で弾けばいいだけだ
というのはインタプリタからは直接deleteが見えないことをさしていると思いますが（合っていますか？
>君が言っているように「禁止する」必要は全くない。
の理由がわかりません。
インタプリタ上のオブジェクトもC＋＋上ではただのポインタであり
delete hogehoge //このhogehogeはGCの管理下
することは文法上は可能なはずです。
これを禁止することは処理系の保守性／安全性のために必要だと考えています（というのが初めの質問につながります

そしてevalラッパというのはやらないです。
今回はメモリ管理まで実装することでその"Java"や"C#"での管理の仕組みを実装レベルで学ぶことが目的の一つだからです。
動けばいいとうわけではありません。当然出荷するわけでもありませんので大丈夫です。

＞コードを書く以前に、まず、仕様を固めないと駄目だ。君はここが出来ていない。
＞もっと上位の、エミュレーション戦略を固めないと話にならない。
ええ全くその通りでした。楽観的すぎたか単に実力不足です。

2017/12/31(日) 13:30:39.82

>>789
君が想定しているのは明らかにフルエミュ寄りだから、それで話をすると、
A *a = new A(); でまず、
自前の変数管理用ハッシュ内に valuesHash["a"] = {type: A*, value: ptr};　することになるだろ。
そして delete a; が来ると、
if (valuesHash["a"].type.canDelete) delete valuesHash["a"].value;
で対応することになる。だから、

> することは文法上は可能なはずです。
> これを禁止することは処理系の保守性／安全性のために必要だと考えています
ということ自体が間違いなんだよ。
文法的に禁止とか、全く意味が無くて、
実行時に自然に弾けるし、弾けないようなフルエミュは実装不能だから。

君はインタプリタ自体がどう動いているのか理解できていない。
インタプリタの場合は、生きている変数を全て自分で把握してないと話にならないんだよ。
俺たちはこれは「常識」として、その先の ptr の配置先をどうするか、の話をしていた。
だから完全に空回りすることになる。

> 楽観的すぎたか単に実力不足です。
どっちもだ。
君は車を作ろうとしているが、車にエンジンとタイヤが必要なことすら理解できてない。
このレベルの馬鹿だ。自覚してくれ。