ニコニコ大百科

これが無いからC++はDを名乗るのを自粛したとかしないとか

「初期の言語」にLISPは含まないんでしょうか。
それから、世の中には「実時間ごみGC」というものがあります。

>>2
ごみGCってなんだwww
「ごみ集め」と書いた後に「GC」に書き換えようとしたら混ざってしまった。

仕組みとしてはRAIIのほうが優れてると思うんだが、どうなんだろう？

確かにiアプリは驚異的に重いものがあったりするな・・・・・。

あと最近この言葉はSSDの方向から聞こえてきたりするかも。

>メモリの確保を人力で管理するのは大変で面倒。なので、コンピュータにさせよう!という話になる。プログラマは面倒ごとをコンピュータに任せたがる人種なのだ。
これを実現するために更なる面倒を抱え込むことになるんですね、わかります。

メモリ解放ってそんなに敷居高いか？

>>1
おめでとう！新仕様ではスマートポインタとして入るよ！

>>4
どう書いても「とりあえずメモリリークの心配はない」とは言えないからなぁ。
GC無いとコンパイルエラーにならなくても実はメモリリークしてるとかあるじゃん。

>>6
GCは実装自体はめんどいけど
多くの人は処理系を使ってるわけじゃなくすでに在る環境を使うわけで。
無いとそもそも自分でメモリの確保とか大規模なコードなら死ねる。
Google先生がC++のコーディングスタイルで「セキュアにならんのが怖い。いいからshared_ptr使え」って言ってるぐらいだし。

性能重視でGC捨てる
-> チューニングでコード増える
-> 結局GCと同じぐらいの規模に…ついでにバグの量がコード量に比例
いわゆるグリーンスパンの第10規則のパターン

>>4 俺もスマポとか使ったRAIIの方が良いと思うな
もちろん向き不向きはあるだろうけど

ところでニコニコ静画()等アプリが落ちるのはメモリ開放が出来てない事が原因って聞いたことがあるんだが詳しい人居ない？

歴史のところに書いてある文章
>(C++のauto_ptr。現在はshred_ptrとweek_ptrなどでそれなりにまともに扱える)

weak_ptrとshared_ptrの間違いじゃないのか？

>>9
どうして可変長配列があるのに、メモリを動的に割り付けるのかねえ。

>>12
ポリモーフィズム…

ガベージコレクションってソシャゲの名前かと

>>14
ゴミを擬人化して萌えるとは、なかなかの上級者とみた。
それにしても、萌えるゴミと萌えないゴミの分別はどうやるんだろう。

ストロヴストルップさんが 「c++ にはよいガベージコレクション機能があるぞ、なんたってそもそもガベージをほとんど生成しないからな」とか言っていたな
http://www.stroustrup.com/bs_faq.html#really-say-that

ガベージコレクションは「プログラマーの品質が低くても言語レベルでカバーしてくれる」という趣旨の機能
「Trust the programmer」から始まるCの価値観では邪魔なだけ

＞初期の言語はメモリを効率的に使うため、すべてのメモリの確保と解放をプログラマが人力で管理していた。しかし、これはそれなりの技術力を要求するため、プログラマのハードルを上げてしまっていた。
初期の言語って、FORTRANもCOBOLも基本的に静的メモリ確保で済ませる言語だと思うけど……。どうしても主記憶が足りないときはオーバーレイとかするんだと思うけど、あれはmalloc/freeみたいな生易しい代物じゃないぞ。

>>18
「すべてのメモリの確保と解放」でなく「確保したすべてのメモリの解放」が適切だな

C#ならusing使おうな
VSで静的コード分析かけような

unity触る為にC#の言語仕様調べてたんだけどまさかニコニコに飛ぶことになるとは思わなかったわ
しかし個人的には参考になる情報じゃなかった悲しい

Javaはゲーム向きじゃないと言われる所以の一つ

そう思うとCはほんとマニュアルで、JavaやC#といったオートマにはない利点がたくさんあるんだよなぁ、もちろんその分煩わしいけど
プログラマの腕が最も反映される言語かもしれん

>>18
そこまで行くと初期じゃなくて黎明期や

>>21
参考になる情報：
ガベージコレクションはゲーム向きじゃない
C#もそれに依存するUnity も真のゲーム開発環境ではない

そして今は真のゲーム開発環境が求められる時代ではない

最初から順を追って説明するのなら、アセンブラするときの番地指定からだろうな
そもそもメモリとは土地のようなもので、住所を指定しないと当初は使うことが出来なかったが、やがてヒープ領域を持つ事によってCのmalloc/freeに代表される動的メモリ確保が登場して便利になり、しかし今度はメモリ解放の問題が発生する

メモリ確保自体が悪でありstaticおじさんが最終的に勝利する

"ガベージコレクションは手動管理に比べて処理が重いと思われていることが多いが、これは必ずしも正しくない。ガベージコレクション特有のコストがあるのは確かだが、そもそも手動管理用を行う場合でもメモリの確保・解法に掛かる実行コスト自体は同じなのだ。"
同じではないだろ。GCはゴミの探索をしないといけないんだから、その探索のコストを払わなければならない

gc

途中送信しちまった

「コスト自体」がさしてるのは利用者のコストであって、GCのコストはそれと分けて書かれている
この場合、メモリを解放するコストとGCに登録するコストの比較に限ればという話

C++とかも別にガベージ決定がゼロコストではない。sharedなら参照カウントの上げ下げが入るし、フルに手動制御してもあるメモリが必要なのかそうでないのかの制御コードが積み重なればそれなりのサイズになる。
GCはそれらを全部本線システムから独立させて一箇所にまとめてるので、ある程度複雑なものを書くのであればオーバーヘッドの「総量」に関しては意外と許容可能な場合も多い。

C/C++の処理思想に慣れた人がJavaのガレージコレクタに嫌な顔をするのは、まとめてやるから気をつけないとクソ重たいＧＣ爆弾ができるというアクセスの多いWebサイト扱うとたまにあるアレだろうね。
C/C++の処理思想で使った先から明示的に解放していればいかなる確保と開放の無限ループにも耐えられるがJavaだと積もって死ぬ
人によってはJavaの方が面倒だと言って憚らない