C++相談室 part146

**デフォルトの名無しさん** · 2019/11/07(木) 11:35:36.76

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

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

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

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

[C++ FAQ]
https://isocpp.org/wiki/faq/
http://www.bohyoh.com/CandCPP/FAQ/ (日本語)

**デフォルトの名無しさん** · 2019/12/01(日) 11:15:38.03

ダブルアレイを変形させて木を表現できないでしょうか。
子は親のIDを知っていれば良く、親は子の個数を知っていれば良いので、出来そうな気がするのですが。

**デフォルトの名無しさん** · 2019/12/01(日) 11:16:42.54

>>387
うん。だから遅いよ。

**デフォルトの名無しさん** · 2019/12/01(日) 11:29:39.61

だから形容詞には比較や数値をつけろってば
それじゃ健康産業で不安を煽る悪徳業者そっくりだろうが

**デフォルトの名無しさん** · 2019/12/01(日) 11:50:38.89

遅いlistやsetがstlに入っていて使われ続けてるんだから
stlに入れない理由にはならないってことだよあほ

**デフォルトの名無しさん** · 2019/12/01(日) 11:53:33.72

いやそんなもん使うやつらがそもそもc++使う必要がねーって話だわ

**デフォルトの名無しさん** · 2019/12/01(日) 11:55:51.88

それはお前の個人的な意見？
それとも何かデータでもあるの？

**デフォルトの名無しさん** · 2019/12/01(日) 12:11:13.07

listやsetが適した用途があるから存在してるんだけどね
使いどころ間違ってるんじゃない？

**デフォルトの名無しさん** · 2019/12/01(日) 12:14:27.64

同じ用途なら
newやdeleteを使わなかったとしても
結局ノード作成時に空きエリアを探すことになるわけで

**デフォルトの名無しさん** · 2019/12/01(日) 12:17:14.00

ノード追加専用のスペシャルlistやsetなら速くなるけど
それはもはやlistやsetじゃない

**デフォルトの名無しさん** · 2019/12/01(日) 12:21:44.69

プログラムのすべての部分で最速の選択をする必要なんて全く無いのに>>392みたいなことを言うやつはCかFortranで書けばいいんじゃないかな

**デフォルトの名無しさん** · 2019/12/01(日) 12:29:30.42

>>394
残念ながら、setはともかくlistが適しているシーンは実際にはほとんどない
途中への少数の要素の挿入削除が頻繁にあって事前にその位置が分かっている状況などどれほどあるというのか

**デフォルトの名無しさん** · 2019/12/01(日) 12:32:06.35

>>398
使いどころがわからないなら無理して使わなくて良いんだよ

**デフォルトの名無しさん** · 2019/12/01(日) 12:33:53.83

>>399
具体例を示そうね

**デフォルトの名無しさん** · 2019/12/01(日) 12:34:14.31

>>397
10%の高速化なら無視すればいいけど
1000倍とかなら考えるだろ？
vectorとlistとsetの選択を間違えると
そのくらいの差が出る
データ数が多ければ

**デフォルトの名無しさん** · 2019/12/01(日) 12:41:44.01

ソートが早い

**デフォルトの名無しさん** · 2019/12/01(日) 12:47:37.78

イテレータの安定性が。

**デフォルトの名無しさん** · 2019/12/01(日) 12:53:47.75

>>397
最速のものを使う必要はないがそもそもアルゴリズムオーダーが間違ってるようなものを
使うってのは頭悪すぎるし、なぜc++使ってんの？バカなの？ファッション？
って気にしかならん。

**デフォルトの名無しさん** · 2019/12/01(日) 12:57:04.85

「そんなもん使う」なんて全面否定しといて
今さらアルゴリズムオーダーとか言い出すのは見苦しい

**デフォルトの名無しさん** · 2019/12/01(日) 12:58:17.95

木とグラフが足りないと思います。

**デフォルトの名無しさん** · 2019/12/01(日) 12:58:25.43

イニシャルコストとランニングコストがあるだろ
数か月～数年間止まらないようなソフトウェアだと初回起動時のデータ読み込み１０億件・数分程度は誤差で済む

**デフォルトの名無しさん** · 2019/12/01(日) 13:00:02.95

現存するあらゆるコンテナを実装してくれ

**デフォルトの名無しさん** · 2019/12/01(日) 13:00:34.69

>>401
> 1000倍とかなら考えるだろ？

いや？ 0.0001ミリ秒が0.1ミリ秒になったところで
大した問題じゃないからね

**デフォルトの名無しさん** · 2019/12/01(日) 13:02:56.20

実害が出るかどうかはケースによるのに
全てお見通しの仏様か何かになったつもりのやつが変なことぬかすんだよな

**デフォルトの名無しさん** · 2019/12/01(日) 13:08:14.41

>>409
1分と1000分なら大違い
トータル0.1ミリ秒なら何でも良いよ気にするな

データが多い時の話
オーダーが効いてくる

newの時間なんてオーダーの差に比べれば誤差
毎回newだから遅いとかトンチンカン

**デフォルトの名無しさん** · 2019/12/01(日) 13:09:03.33

Boostにイテレータが安定なvectorがありますが、速度はlistに劣る場合があると但し書きがありますよ。

**デフォルトの名無しさん** · 2019/12/01(日) 13:16:11.26

データ構造は
list, set, リニア(vectorやdeque) で揃ってる
これでオーダー的には大抵は問題ない

微妙な高速化が必要なら専用を自作すれば良いが
組み込みでもなければ必要となることはあまりない

複雑なデータ構造は、
標準のデータ構造を組み合わせて作る
複雑なリンク構造はSLAMの世界だとよく使う

**デフォルトの名無しさん** · 2019/12/01(日) 13:20:19.28

いや明らかにsetのオーダーに問題あるだろ。

**デフォルトの名無しさん** · 2019/12/01(日) 13:23:43.76

えっ？

**デフォルトの名無しさん** · 2019/12/01(日) 13:25:41.03

思考停止してないでこれくらいは読んでくれよ。。
https://cpprefjp.github.io/reference/set/set.html

**デフォルトの名無しさん** · 2019/12/01(日) 13:31:07.65

読みました。

**デフォルトの名無しさん** · 2019/12/01(日) 13:31:36.80

メモリの再配置が起こると都合が（あるいは効率が）悪いオブジェクトを比較的頻繁にnew/deleteしつつ、
一覧を保持しておく用途にはlistが適していると思う。
あ、でも、本体をdequeに、ポインタをvectorに入れて管理する方が速いかな？　バグりそうで恐いけどw

◆QZaw55cn4c · 2019/12/01(日) 13:51:31.01

>>386
木をそこまで悪くいう人を初めて見かけました、大概のデータ構造は木だと思うのですけど…

**デフォルトの名無しさん** · 2019/12/01(日) 13:56:38.18

下手くそが巨体な木を作るとひどいって話だろ
下手に作らなきゃ良いだけ

**デフォルトの名無しさん** · 2019/12/01(日) 14:14:45.54

>>414
問題にならない用途、条件のもとで使う分には問題ない。

**デフォルトの名無しさん** · 2019/12/01(日) 14:32:23.94

きみはあれか
「ライトバンはセダンにくらべると速度も遅いし馬力もないしとてもあんなもの使えない!」
とかいっちゃうタイプ？

**デフォルトの名無しさん** · 2019/12/01(日) 14:47:10.92

>>419
お前は頭が悪いけどな

**デフォルトの名無しさん** · 2019/12/01(日) 15:33:24.99

一般的には、適切な二分木等で実装されたSetは、メモリ効率が悪いことはあっても速度のオーダーがひどいってことは無いだろ

**蟻人間** ◆T6xkBnTXz7B0 · 2019/12/01(日) 15:40:09.97

C++11のstd::unordered_setに負けてる。

**デフォルトの名無しさん** · 2019/12/01(日) 15:45:18.33

それはまた別な話だ

**デフォルトの名無しさん** · 2019/12/01(日) 16:25:31.35

二分木がSTLにない理由は簡単。冗長だから。

**デフォルトの名無しさん** · 2019/12/01(日) 16:26:58.04

setは内部2分木だって言ってるのに

**デフォルトの名無しさん** · 2019/12/01(日) 17:09:51.64

>>422
うまい喩えだなｗ

**デフォルトの名無しさん** · 2019/12/01(日) 17:18:14.34

>>428
もしかして二分探索と二分木を混同してる？

**デフォルトの名無しさん** · 2019/12/01(日) 17:33:23.47

木の枝を回廊にしたらグラフになります。
グラフはスパコンのベンチマークにされるくらいにメジャーな構造です。

**デフォルトの名無しさん** · 2019/12/01(日) 17:36:46.35

>>411
自分で言ってるやん？

データが少ないときなら気にする必要はないので、
データが少ないとき用のアルゴリズムとして
「遅いけど便利」はあったほうが良いだろ

**デフォルトの名無しさん** · 2019/12/01(日) 18:14:48.13

普通ハッシュ使うよね？とかそういう発想が皆無なのが、
ここは馬鹿しかいないってことを示してるよな。。

**デフォルトの名無しさん** · 2019/12/01(日) 18:19:34.55

>>430
多分混同してるのはお前だけかと

**デフォルトの名無しさん** · 2019/12/01(日) 18:22:27.22

>>433
バカはお前

set は一般的に、二分木として実装される。
https://cpprefjp.github.io/reference/set/set.html

**デフォルトの名無しさん** · 2019/12/01(日) 18:36:45.84

ハッシュを使うんじゃねえな
ハッシュをどう作るか？になる

perl5/hv.h at blead ・ Perl/perl5 ・ GitHub
https://github.com/Perl/perl5/blob/blead/hv.h

cpython/dict-common.h at master ・ python/cpython ・ GitHub
https://github.com/python/cpython/blob/master/Objects/dict-common.h

**デフォルトの名無しさん** · 2019/12/01(日) 18:53:22.71

木やグラフがほしいって言ってる人が、ハッシュマップや内部実装だけが木構造のコレクションなんていらんだろ。。

**デフォルトの名無しさん** · 2019/12/01(日) 19:11:19.73

うんち

**デフォルトの名無しさん** · 2019/12/01(日) 19:20:12.56

「木が欲しい」という要件に対して確認もなく二分木渡すような奴はダメ
ディレクトリ構造表したい奴に二分木渡してどうすんだ

**デフォルトの名無しさん** · 2019/12/01(日) 19:25:06.56

二分木って規格で決めてるの？

**デフォルトの名無しさん** · 2019/12/01(日) 19:36:32.68

うんち

**デフォルトの名無しさん** · 2019/12/01(日) 20:13:00.99

｢木が欲しい｣なんていう人には
とりあえず何でもいいから木を渡しておけばいいんだよ

**デフォルトの名無しさん** · 2019/12/01(日) 20:31:05.42

木は用途や使い方次第で適する作り方が異なるので
標準コンテナを組み合わせたカスタムで良いと思うよ

**デフォルトの名無しさん** · 2019/12/01(日) 20:51:16.81

https://ideone.com/u8DxeY
ほら～。あそこに見えるのがN分木のさんぷるだよ～。
デバッグしてないから酒の肴にぴったりだよ～。

**デフォルトの名無しさん** · 2019/12/01(日) 21:01:15.36

C++11以降なら子ノードをweak_ptrの配列で持つとか？

**デフォルトの名無しさん** · 2019/12/01(日) 21:09:55.37

>>444
言い忘れていたが、このスレから取得したN分木のコード(>>444)はMITライセンスです。
改造して変な構造を作ろう！

**デフォルトの名無しさん** · 2019/12/01(日) 21:31:39.82

著作権表示なしにMITライセンスにできたっけ

**デフォルトの名無しさん** · 2019/12/01(日) 22:14:07.56

サンプルとかライセンスとか頭沸いてんのかこいつ
下痢便を神棚に飾って人に配るような所業

**デフォルトの名無しさん** · 2019/12/01(日) 22:32:33.44

著作権表示は、

2019　Yakitori

が必要なら使って。

**デフォルトの名無しさん** · 2019/12/01(日) 22:32:48.31

>>449
日本語不自由だな

**デフォルトの名無しさん** · 2019/12/01(日) 22:38:20.61

？

**デフォルトの名無しさん** · 2019/12/01(日) 22:41:32.80

うんち漏れそう

**デフォルトの名無しさん** · 2019/12/02(月) 00:33:17.14

>>448
だな

**デフォルトの名無しさん** · 2019/12/02(月) 02:45:23.23

オランダのTIOBEの調査でも、C#よりJavaやC/C++が人気で、
他の会社による日本での求人数もJavaやC/C++の方がC#より上だそうだ。
JavaScript、PythonやRubyは、求人数では大したことが無いらしい。
Webページを製作している人がネットでは多いので、JS、Python、Ruby
などが人気であるかのように見えるだけかもしれない。

**デフォルトの名無しさん** · 2019/12/02(月) 03:22:15.51

>>454
すまん。日本での求人数は、
Java, PHP, Ruby, C#, JS, Python, Objective-C/Swift, C/C++,
HTML, Android, Unity, VB.NET, Scala
だそうだ。ただし、C#から、C/C++ までは横並びでどれが上とも
いえない僅差。そして、Java, Python, Ruby は伸びているが、
PHP, C#, JS, HTML は減っている。
ところが、プログラマ側からの「希望言語」としては、JSがTOP
らしい。アメリカでの今後学びたい言語としては、Java, Pyhtho,
C++ は上位に来るが、C#, Ruby はかなり下の方。

**デフォルトの名無しさん** · 2019/12/02(月) 03:29:10.52

>>455
個人的見解としては、VS code が 5ch で評価が高かったのは、言語が
TypeScript や JavaScript と HTML で記述されているので、JSで
プログラムすることを希望するプログラマが、JSの求人を増やすために
JS製の成果物を高く評価していたからかもしれない。
また、Javaの伸び率はかなり高い。Rubyの求人は日本では多いようだが、
アメリカでは少ない。C#の人気は、ある時期までは延びたが、今は停滞期
に入ったようだ。しかも今後学びたい言語としては、C よりも低い。

**デフォルトの名無しさん** · 2019/12/02(月) 03:36:47.51

TIOBEの調査では、Java と Cの人気が同列で高く、Python がそれに続く。
また、CとC++を合計すると、Javaよりもだいぶ高い人気となる。

Java 16.2% (-0.50)
C 16.0% (+1.64)
Python 9.84% (+2.16)
C++ 5.60% (-2.68)
C# 4.31% (+0.36)
VB.NET 4.22% (-2.26)
JS 1.93% (-0.73)
PHP 1.72% (-0.66)
SQL 1.69% (-.15)
Swift 1.65% (+0.20)
Ruby 1.26% (+0.17)
Objective-C 1.20% (-0.28)
・・・
D 0.927% (-0.64)
Go 0.853% (-0.64)

**デフォルトの名無しさん** · 2019/12/02(月) 03:57:59.67

CとC++とC#の区別ができる営業いないんだよな

**デフォルトの名無しさん** · 2019/12/02(月) 04:06:59.74

営業って年取った技術者がやるもんだろ

**デフォルトの名無しさん** · 2019/12/02(月) 06:49:53.19

今はもう戦力外技術者なんて即解雇だよ
そもそも大手だと営業と技術者は別会社

**デフォルトの名無しさん** · 2019/12/02(月) 07:41:42.15

なんで大手条件が勝手に加わるのか

**デフォルトの名無しさん** · 2019/12/02(月) 08:23:03.95

零細中小なんて誰も興味ない

**デフォルトの名無しさん** · 2019/12/02(月) 08:42:45.44

比較するもんじゃないだろ
C++は好きだが、在庫管理システムをC++で書けと言われたら全力で拒否してC#を推すぞ俺は

**デフォルトの名無しさん** · 2019/12/02(月) 11:06:47.45

ほんとそれだな
きみらはいつになったらライトバンとセダンの使い分けができるようになるのか・・

**デフォルトの名無しさん** · 2019/12/02(月) 11:42:23.75

>>464
君「ら」？
お前のことだろ

**デフォルトの名無しさん** · 2019/12/02(月) 13:15:55.16

でもJavaはベンチとると速いんだけど、実際は遅い。
これ、リソースを食いすぎるのが原因なので、本当はサーバーよりクライアントに向いているんじゃないのかな。

**デフォルトの名無しさん** · 2019/12/02(月) 13:16:09.89

ライトバンとセダン？

スリッパと自転車と乗用車と飛行機とロケット
くらい使い分けないとダメ

**デフォルトの名無しさん** · 2019/12/02(月) 13:19:02.21

C++はメモリーの分断化があるので、長時間起動し続けるサーバーには向いていないと言われてるんだけど、実際にやってみたら全く問題なかった。
考えてみると、JavaプログラムをホストするシステムがC/C++で書かれてるんだから、本当に問題になるなら、Javaも無理なはず。

**デフォルトの名無しさん** · 2019/12/02(月) 13:20:28.22

Androidは特に不満もなく動くので、Javaはクライアントでこそ力を発揮するような気がします。

**デフォルトの名無しさん** · 2019/12/02(月) 13:21:19.03

メモリは潤沢にあるし
アドレス変換もあるので
よほど下手に作らなければ
PCでフラグメントは問題にはならない
そんな事を心配する時代じゃない

組み込みだと話は別

**デフォルトの名無しさん** · 2019/12/02(月) 13:21:57.37

機種ごとの差を言語が吸収してくれるなら、こんな楽なことないし。
一方、サーバーは、サービス提供側が機種を自由に選べるのでJavaである必要が無いと思う。

**デフォルトの名無しさん** · 2019/12/02(月) 13:23:17.46

>>469
比較的最近追加された
リアルタイム系オーディオAPIは
C/C++での提供ですね

用途によってはいまだにC/C++が必要

**デフォルトの名無しさん** · 2019/12/02(月) 13:23:19.93

>>470
でも、フラグメントが・・・と言われると、なるほどと思うじゃないですか。
僕もいずれ別の言語で書き換えるつもりだった。
でも問題なかった。

**デフォルトの名無しさん** · 2019/12/02(月) 13:30:11.70

>>468
それは完全に理解不足
Javaや.NETのVMはC++で静的に確保した大きなメモリ領域をヒープと呼んでいる
でアプリ内でnewするとオブジェクトとしてその中の領域が割り当てられ、ハンドル(生ポではない!)をアプリがオブジェクト参照として受け取る
C++のオブジェクトとの大きな違いはオブジェクトを再配置できることであり、
GCが必要に応じてヒープ上のオブジェクトを移動して詰めるため断片化が生じにくい
C++でも生ポを使わなければ再配置できるんだけどね

**デフォルトの名無しさん** · 2019/12/02(月) 13:31:49.39

メモリ激増のお陰じゃねえの

**デフォルトの名無しさん** · 2019/12/02(月) 13:41:55.06

その辺はOSの仕事であるべきやと思うわ

**デフォルトの名無しさん** · 2019/12/02(月) 13:49:06.39

やってることがさほど変わらず100MB確保から1GB確保にするだけで
断片化率が1/10になる

プログラミングの技量が全く変化しないのにも関わらず安全性が10倍になる
つまりマシンの搭載メモリが1GBから10GBになるだけで安全係数が10倍になる
これぞ大富豪プログラミング

**デフォルトの名無しさん** · 2019/12/02(月) 15:06:09.31

>>474
windows3.1のGlobalAllocみたいのを今さらドヤられても…

**デフォルトの名無しさん** · 2019/12/02(月) 15:20:31.50

>>468
実はかなり古くから、C/C++ の malloc(), new のヒープメモリから確保したメモリの
断片化は、実際に問題になるようなことはとても少ないといわれています。
というのは、断片化というのは、確保したメモリを開放したときに出来た
「隙間にある空きメモリ」が再利用されにくい場合に起きるものなんですが、
実際には、再利用されることが多いためです。なぜなら、おなじサイズの
オブジェクトを new することが多いためです。この場合、完全に再利用されるので
断片化の問題と言うものは全く起きないと言っても過言では有りません。
それから、通常、1つのオブジェクトのサイズは小さく、それが多数集まって
データをなしていることが多いのです。このことから、異なるサイズのオブジェクト
であっても、1つ1つのオブジェクトのサイズが小さいため、断片化したとしても、
再利用される確率が高いのです。まず、同じサイズのオブジェクトであれば再利用されます。
異なるサイズであっても、昔開放されたオブジェクトよりも、小さいサイズのオブジェクトを
新しく確保する場合であれば再利用されます。
このようなことから現実の例では、断片化しても、使われないメモリの量はある程度の比率
に収まると言われており、それは GarbageCollection を行うためのオーバーヘッドの
メモリのサイズと比べても余り大きいものではないのです。

ゲームはメモリー効率も求められますが、それでも C/C++ が使われているのは、
メモリー断片化の量が一定比率より多くなら無い事が経験的に知られているためです。

**デフォルトの名無しさん** · 2019/12/02(月) 15:28:19.20

フェイスブックがPHPのコードを翻訳機でC++コードに変換して配備してるそうですが。
そんなことするなら最初からC++で書けばいいのに。

**デフォルトの名無しさん** · 2019/12/02(月) 15:33:38.42

>>474
C/C++ では、配列ではなくリンクリストを積極的に使うようにすることに
よって、メモリーが断片化しても再利用される確率を高くすることができます。
というのは、データの基本となっている要素のオブジェクトのサイズが
小さいため、さまざまなサイズのデータを new しても、結果的に、
断片化された空きメモリも高い確率で再利用されるためです。
new、delete するオブジェクトのサイズがランダムな場合で、
断片化空きメモリが残っている場合、確率論的には、おおよそ 2回に1回は
断片化空きメモリが再利用されることになるでしょう。もちろん、
delete された回数が少な過ぎる場合、そもそも断片化空きメモリの個数が少なすぎる
ので、再利用できる確率は低くなります。それは、初期化時やファイルからデータ
読み込み時などにどんどんメモリを new していくよう場合ですので、そもそも
断片化が起きる余地も有りません。

なお、ポインタとリンクリストを組み合わせると、よくある場合には、他の
集合アルゴリズムよりも、効率が高くなりやすいことが知られています。
ただし、文字を集合させて文字列を作るような場合は例外です。

**デフォルトの名無しさん** · 2019/12/02(月) 15:39:04.52

>>481
配列の場合、delete するとメモリー上に大きな空き領域が出来ますが、
それより大きなサイズの配列を new しようとすると、そこが再利用できません。
なぜなら、配列の場合、連続したメモリ領域が固まって必要になるため、
要素の個数が N だとすると、N 個全てが一度にまとまって入りきる領域を探す
必要になるためです。

ところが、リンクリストの場合、要素数 N が大きくなっても、バラバラな
領域に分散して格納することが出来ます。すると、とても高い確率で、
分断化された空きメモリが再利用されることになります。

**デフォルトの名無しさん** · 2019/12/02(月) 15:50:07.84

>>481
「2回に1回」と書きましたが、実際にはもっと確率は高いです。
リンクリストを使っている場合、要素を全部 delete したような場合は、開放された
空きブロックは、余り断片化せずに、比較的高い確率で結合され、大きな空きブロックに
なるためです。空きメモリは、元の要素のサイズの複数個分以上になっている確率が
高くなります（複雑ですが、管理領域のサイズもこれに加わります。）。
この性質があるため、現実には、小さいサイズのオブジェクトを要素とする集合
が多種類有った場合、それを好きに new, delete した場合、50% よりずっと高い確率で
断片化空きメモリーは再利用されます。

**デフォルトの名無しさん** · 2019/12/02(月) 16:10:33.93

>>483
誤解無きように細くしておくと、「50% より大きい」というのは、
「断片化された空き領域が再利用される確率」
のことで、「断片化率」ではありません、。断片化率はもっと
小さな値になり、条件によりますが、例えば、数%～10%程度
が目安になります。最悪のケースだともっと大きいのですが、
ケースバイケースで適切なデータ構造（集合アルゴリズム）を
使っているとこの程度に収まります。また、適切なデータ構造を
選択することはそんなに難しいわけではありません、。

**デフォルトの名無しさん** · 2019/12/02(月) 16:15:53.26

>>475
既に、Windows95くらいの時期のメモリ容量で、C/C++のメモリ断片化は
問題が無い程度になっていました。実際には、MS-DOSの時代でも既に
問題なかったのですが。

とにかく、今の若い人の目線で言えば、古代ともいえるくらい古い時代に
既に C/C++ のメモリー断片化問題は問題が無い程度にハードウェアが
発達済みなのです。PC-8801 の 8BIT 時代には問題があったので、
N88-BASIC を筆頭に、GarbageCollection 方式をとっていましたが、
それは、若い人には「超古代文明」時代でしょう。

**デフォルトの名無しさん** · 2019/12/02(月) 16:34:28.08

>>485
また誤解が入りそうなので細くしておきます。
N88-BASIC などが GarbageCollection を使っていたのは、本当に
マシンのメモリが少ないのでデータをぎゅーぎゅー詰めに隙間無く
入れることが重要だったためです。
一方、JavaやC#がGarbageCollection を使っているのは、どちらかと
いうと、「メモリー開放の自動化」のためです。参照カウンタだけで
は、循環参照問題が生じるため、時々、広い範囲のメモリブロックを
巡回して、循環参照していても本当に使って無い場合を厳密に見つけ出して、
徹底的に開放することを行います。
そのため、メモリーの断片化問題とはまた違う意味で、メモリー開放の
自動化には、GarbageCollection が必要となっています。

N88-BASIC 時代と、現在の Java, C# とでは、同じ GarbageCollection
でも主な役割が違うと考えられます。もちろん、断片化を防ぐ役割も同時に
果たしてくれますが。

**デフォルトの名無しさん** · 2019/12/02(月) 16:40:43.00

>>486
誤字訂正：細く ---> 補足

・BASIC言語にはポインタが無かったので、循環参照問題は有りませんでした。
・BASIC言語における GarbageCollection は、主に文字列領域の開放のためです。
　A$="HELLO WORLD" と入れた後、A$="" とした時、元の文字列に使っていた
　領域は、しばらく経った後に GarbageCollection で開放される仕組みでした。
　ですので、文字列を余り使わなければ GarbageCollection も余りおきませんでした。
　なお、DIM A(100) のように確保した配列は、余り開放することは有りませんでしたが、
　開放した場合も、しばらく後に GarbageCollection の対象になっていたと思われます。