GCは失敗。メモリは自分で管理せよ！ その2©2ch.net
GC、ガベージコレクション、ガベージコレクタ、ガーベジコレクション、ガーベジコレクタは使えない。
以下GCと記す
プログラマをメモリ管理から開放する！
といいつつ、メモリリーク問題の文献が大量にある。
これすなわち、メモリリーク問題が全然解決していないということ。
さらに、メモリ解放のタイミングの文献まで大量に生み出した。
これすなわち、新たなるメモリ管理に関する問題を生み出したということ。
malloc、freeじゃないが
結局のところ、メモリを管理するという技術は、今しばらくは、身につける・教える・学ぶべきではないだろうか？
使って、そのまま放置しても、基本的にはGCがなんとかしてくれている。
ランジョブからジョブ終了までさほどの時間を要さない。メモリも大して使わないならいいだろう。
しかし、規模が大きくなり常駐ジョブやメモリ大量使用のジョブになってくると、そんなメモリ管理の方法でやっていると、
上記「文献」を生み出されてしまう。
入門時は、メモリに無頓着でもいいだろう。それよりも、目的を達成することが先決だ。
しかし、慣れてきたら、やはりメモリの管理まで余裕を持って自分で行うべきだろう。
前スレ
GCは失敗。メモリは自分で管理せよ！
http://peace.2ch.net/test/read.cgi/tech/1412986420/ mallocやnewは
大きなサイズを確保するときと
小さなサイズを確保するときで
アルゴリズムが切り替わる VC++2015での実行結果
auto a = malloc( 10 );
auto b = malloc( 10 );
wchar_t tmp[ 100 ];
::swprintf_s( tmp, 100, L"a = %x, b = %x \n", a, b );
::OutputDebugString( tmp );
----------------------------------------
a = 10a4f0, b = 10a508
残念でしたね MMUは多少以上の処理をすると簡単にフォールト返すのが困りもの
結局初心者レベルのプログラマしか想定してないんだよな 複雑なことをしていると、それがまるで正しいかのように思う点がアフォ
多少複雑なことをしていてもアフォな挙動をする可能性はあると考えるべき malloc,newの挙動の説明ってまんまMMUの説明なんだよな
だから複雑なアルゴリズムを使われていると思うのはMMUが複雑な挙動をしているから
でも、そんなに複雑な挙動してるか？？
単に過去のアプリとの互換性の問題で変な事をしているだけだぞ たいがいのmalloc,newはMMU次第でいくらでも挙動が変化するからな
ちゃんとPC毎に動作確認したか？？ ID:S40DCpdn しったかしすぎ
mallocの挙動はヒープのアルゴリズム次第 malloc,newの挙動はハードとOSによって変化するという記述は見たことあるけどな ヒープの管理しないでなんとかなるレベルのものはgc言語使えばいいんでは？
このスレの趣旨的にそうでしょ？ 自分はメモリ対策プログラムを作って対応したけどな。
メモリサイズを三種類用意して、メモリに対するガードの確実な作りにした。
現在のサイズに使われてるサイズにリミットサイズの三種類のサイズな。
外に出てくるサイズは現在のサイズ、
使われてるサイズはメモリを増やした場合の最大取得サイズで、事実上の取得サイズ、
リミットサイズは取得できるメモリの上限。
で、これらを組み合わせてスーパークラスを作って基本的に対応させてる。 メモリの増減には現在のサイズで対応し、このサイズが必要以上に大きくなると
使われてるサイズを拡張するようにした。リミットサイズは滅多に使わないけれども、
一応対応させた。
メモリに対する読み書きは専用関数を経由して読み書きするようにしたから、
素人が使っても安全なぐらいのプログラムになってる。 あと、動的配列ってのを作って、複数のメモリ取得に対応させた。
メモリにヘッダとフッタを用意して、フッタには複数配列のデータに対応させ、
ヘッダには配列数とメモリサイズを入れてる。フッタには>>682のデータを持たせた。
ある意味では拡張コンパクションみたいなモノになった。 で、アローケートが一回だけになるようにして、あとはリアロークで対応させた。
おかげでメモリの消費効率は異常なまでに効率よく使えるようになったよ。
あと、動的配列使う場合はいったんメモリをフォーマットするようにしたけどね。 それから、動的配列は入れ子構造にすれば色々と応用がきくようになってるけどな。
で、追記式みたいにデータが動くツリー構造とかが使えるようになってる。 アセンブラできない馬鹿がC++使うことを想定するとGCは成功と言わざるをえない。 メモリを動かして処理すれば出来る事なのにな
出来る事を出来ないというのは間違い 誰へのレスかすらわからないというね
誰も何も「出来ない」という趣旨のレスはしてないと思うが
独り言かね 前日に連続して意味不明な独り言してるやつがいるからそれの続きだろ malloc()関数の内部はOSからメモリをまとめて取ってくる処理と、
すでに取ってきたメモリを（free()で空きが生じたとき）やりくりする処理の2本立て
前者の処理（システムコールの呼び出し）は比較的高コストなのでmalloc()の度に呼びはしない
また後者の処理は、連続したアドレス範囲のメモリを確保できている前提で動く
ページングはもっと下のレイヤーで行われるので、
malloc()のコード自体がMMUの有無やOSの違いを関知したりはしない 最近はjavascriptのレイヤーとかまで出来てさらに複雑面倒に 僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』
3682F GCをルンバで例えたらどうだろう
自動
しかしテーブルの上や
冷蔵庫の中は片付けない
日常生活にさしさわりなく動いてほしい それに加えてルンバが動けるように床は片付けておかないといけないとか
自動で上手く機能させるために気にしないといけない事が色々ある もういらないって明示的に書かなきゃならないのなら自前で管理するのと一緒だよな。
アマチュアがサンデープログラムしたり、短時間で終了するアプリならむしろ楽チンだけど、
365日24時間稼働し続けるシステムには致命的な問題になるからなぁ GCがある言語でも、shallow copy と deep copy のどちらにすべきかの判断が難しくて、結局、間違えてバグの原因になる可能性がかなり残る。
また、C/C++ポインタのミスを危険視する人がいるが、多くの場合はプログラム開発時にテストをすれば間違いが発見できる。
C/C++でのバッファオーバーランを気にする人がいるが、逆にGCがある言語でも、間違って1つ右隣の要素にしてしまったり、処理する個数を1つ間違ったりするミスは有り得て、その場合、厳密な意味でのバッファオーバーランは無くても処理内容自体はバグる。 No GC派なんだけど、WebサーバーをC++とかで実装しても結局力持て余す感はあるよな
それだからかなり性能下げてもいいからちょっとでも早く作れるスクリプト言語採用されるってのもありそう GCのメリットは言語の文法が簡単になること。
GCはスクリプト言語のためにある。 (destructor)()
dispose()
destroy()
close()
free()
delete 今やGCのない言語でweb framework書く人間は絶滅危惧種 このスレってガイジ扱いされてたけどRustとか出てきて実は正論だったんじゃね？って見直してるわ おれはGCが最初から分かりづらいなぁと思ってたよ。mallocやnewより GCは停止時間問題を解決できないまま生涯ふわふわした存在で居続けるのだよ >>1は、2014年に問題提起してるのか・・・。
Rustとかは2010年ころ発表だけど、実際に一般に知られるようになったのって2021年頭から
>>1は、それなりに的を射た技術理解・評価をしてるんだな
俺は人気の言語を覚えて、周りが言ってるメリットを、反対派にコピペするだけだけどｗｗ
ま、Pythonのお手軽さを超えることはないと思うけど、どこまでRustは伸びるのかなぁ やはりGCは必要だった
WebAssemblyにガベージコレクション機能が登場、Chrome 111で試験的実装に。Dartなど高級言語のWebAssembly対応へ前進
https://www.publickey1.jp/blog/23/webassemblychrome_111dartwebassembly.html GCを含め、「機械に不慣れな人でも簡単にプログラミングできるようにする」という
これまで高級言語が行ってきたような試みはすべてAIに取って替わられるような気がする
まあ、現時点のAIは使い物にならないかもしれないが、いずれは… AIに「これはゴミか？」を学習させていって人間がゴミ認定される日も近い 
