GCは失敗。メモリは自分で管理せよ！

0001デフォルトの名無しさん

2014/10/11(土) 09:13:40.71ID:mzO+gdRv

GC、ガベージコレクション、ガベージコレクタ、ガーベジコレクション、ガーベジコレクタは使えない。
以下GCと記す

プログラマをメモリ管理から開放する！
といいつつ、メモリリーク問題の文献が大量にある。
これすなわち、メモリリーク問題が全然解決していないということ。
さらに、メモリ解放のタイミングの文献まで大量に生み出した。
これすなわち、新たなるメモリ管理に関する問題を生み出したということ。

malloc、freeじゃないが
結局のところ、メモリを管理するという技術は、今しばらくは、身につける・教える・学ぶべきではないだろうか？
使って、そのまま放置しても、基本的にはGCがなんとかしてくれている。
ランジョブからジョブ終了までさほどの時間を要さない。メモリも大して使わないならいいだろう。
しかし、規模が大きくなり常駐ジョブやメモリ大量使用のジョブになってくると、そんなメモリ管理の方法でやっていると、
上記「文献」を生み出されてしまう。

入門時は、メモリに無頓着でもいいだろう。それよりも、目的を達成することが先決だ。
しかし、慣れてきたら、やはりメモリの管理まで余裕を持って自分で行うべきだろう。

0002デフォルトの名無しさん

2014/10/11(土) 09:26:04.88ID:/AOb9xWD

メモリの断片化対策でコンパクションを自力で作ってみたぞ！？
ただ、メモリ取得にあわせてメモリの配置をうごかしてるから、
処理としては重くなってるけど

0003デフォルトの名無しさん

2014/10/11(土) 09:28:04.43ID:mzO+gdRv

激しく自作自演による、同意age!

0004デフォルトの名無しさん

2014/10/11(土) 09:31:36.41ID:FTKCoifo

>>1
まぁ君の言う通りだとは思うわ
ただ、時の流れを変えるのはなかなか難しいよ

0005デフォルトの名無しさん

2014/10/11(土) 10:00:31.15ID:4uYM2ueX

結局GCとかいっても、参照握ってるとそれがリークするから
名前が変わっただけなんだよな

0006デフォルトの名無しさん

2014/10/11(土) 10:02:00.16ID:7SO6QsHv

gcc最高

0007デフォルトの名無しさん

2014/10/11(土) 10:07:53.81ID:RJKjicrV

デストラクタは意図的に呼べるようにしてほしい

0008デフォルトの名無しさん

2014/10/11(土) 10:15:19.31ID:C84ryw+n

>>1
何言ってんだよアホ
Javaがメモリリークするのはずっと前から知られてる事だし、それはプログラマが
「リークするようなプログラム」を書くからだろうが

0009デフォルトの名無しさん

2014/10/11(土) 10:34:35.80ID:mzO+gdRv

（T。T)なんだよぉ～反対しろよぉ～。盛り上がらないだろぉ～。

0010デフォルトの名無しさん

2014/10/11(土) 10:53:41.89ID:5HiTQGOf

結局バカにつける薬はないという事

GCはバカにつける薬を目指したけど中途半端で、
他のリソースの管理を楽にするRAIIとも相性が悪く
余計な手間を増やすだけに

0011デフォルトの名無しさん

2014/10/11(土) 11:19:13.65ID:vaox7Njv

これGCもそうだけど、

OOでも同じことが言えるんだよね
結局、分割せずに一つのクラスにグダグダと何でもかんでも機能書き込みまくりやがる
んで再利用もされない

馬鹿にプログラミングさせないのが正しい処方

0012デフォルトの名無しさん

2014/10/11(土) 11:24:21.18ID:5SSzSkT3

肉体労働系にするための餌だったんでしょ

0013デフォルトの名無しさん

2014/10/11(土) 12:12:50.56ID:cpMaL1hK

リークしてる箇所を容易に特定できないのがクソだわ

0014デフォルトの名無しさん

2014/10/11(土) 12:40:04.63ID:gz4lvABW

そりゃ技術力の問題だわ

0015デフォルトの名無しさん

2014/10/11(土) 12:56:22.77ID:8yVA6sZ1

バカが勝手に生成する循環参照を検出してやる義理はないってことだな。

0016デフォルトの名無しさん

2014/10/11(土) 13:16:23.99ID:XZu+KoKv

GCってなんかメリットもたらしたのだろうか？

0017デフォルトの名無しさん

2014/10/11(土) 14:21:55.07ID:cDJhBayo

>>16
ダングリングポインタによるやっかいなバグが発生しない

0018デフォルトの名無しさん

2014/10/11(土) 16:06:07.68ID:5SSzSkT3

ゴミを一箇所に集めると
早くなる
とか
広大なメモリ空間でゴミ集めしてもね

0019デフォルトの名無しさん

2014/10/11(土) 16:22:03.92ID:0tst77Z4

GC使う言語って何があったっけ？

C++ぐらいでしょ？

0020デフォルトの名無しさん

2014/10/11(土) 17:01:29.09ID:gz4lvABW

C++は使わない

0021デフォルトの名無しさん

2014/10/11(土) 17:03:09.93ID:gz4lvABW

メモリリークより循環参照のが怖いな。検出のしようもないし

0022デフォルトの名無しさん

2014/10/11(土) 17:35:30.35ID:eOQAHjvH

循環参照が問題になるような単純なリファレンスカウント方式って
今じゃほとんど使われていないんじゃないか？
メジャーなところでGC搭載前のObjective-Cくらい？

0023デフォルトの名無しさん

2014/10/11(土) 17:41:38.78ID:Qk2dzUbv

しょっぱいGCといえば D

0024デフォルトの名無しさん

2014/10/11(土) 18:24:06.71ID:Sxw1t6Y7

Objective-CはもうGC使うのやめたんじゃね？

0025デフォルトの名無しさん

2014/10/11(土) 18:31:05.39ID:0tst77Z4

>>21
循環参照自体は怖くないでしょｗ

怖いのはそれを原因にしておきるメモリリーク。
そっちは検出できる。

それに循環参照ごときじゃメモリリークは起きないのが
ほとんどだし。

0026デフォルトの名無しさん

2014/10/11(土) 19:04:06.70ID:h48KXGlz

昔のIEとか循環参照でよくリークしてたよね

0027デフォルトの名無しさん

2014/10/11(土) 19:14:27.18ID:P1IOX8Um

自分で管理するとしても、finally句が使える言語なら割と楽そうな気がする

0028デフォルトの名無しさん

2014/10/11(土) 19:15:00.75ID:0tst77Z4

あれは循環参照がリークの原因ではないんだがな。

0029デフォルトの名無しさん

2014/10/12(日) 05:43:17.17ID:Du/HgjiN

え、Javaは相変わらず循環参照でメモりリークというかメモリキープしたままになるじゃん。

0030デフォルトの名無しさん

2014/10/12(日) 07:08:38.14ID:jwvcB2bY

激しく同意！（自演）

0031デフォルトの名無しさん

2014/10/12(日) 07:16:45.94ID:jjrAIsW+

参照カウンタ方式でないガベージコレクタを
採用したのはJavaが最初なんだけどな。

0032デフォルトの名無しさん

2014/10/12(日) 07:24:12.59ID:Du/HgjiN

そもそも参照カウントで自動解放するのをGCと呼ぶのに未だに違和感がある。
そして参照カウンタ方式でも循環参照は解決できないよねえ。
objcは少なくとも今でもそうだな。
swiftでは改善されてるの？

0033デフォルトの名無しさん

2014/10/12(日) 07:25:36.74ID:yWo9u0cs

>>29
リークじゃなくてキープなら循環参照関係なくね？

0034デフォルトの名無しさん

2014/10/12(日) 07:25:38.03ID:jjrAIsW+

> そして参照カウンタ方式でも循環参照は解決できないよねえ。

参照カウンタ ”だから" 循環参照でメモリリークするんだけど？

0035デフォルトの名無しさん

2014/10/12(日) 07:35:30.36ID:Du/HgjiN

>>33
プログラマがもう使ってない認識なのにキープしたままになるのは、広義のメモリリークではありますわね。
>>34
いや、原理的にはもう一層上のとこで各オブジェクトの参照カウンタを監視できれば、一応解決はできる。
Delphiのカスタムメモリマネージャでそういうのやろうとしてたプロジェクトあった記憶があるんだけど、どうなったのかなあれ。

0036デフォルトの名無しさん

2014/10/12(日) 09:45:05.81ID:6t43fLEu

使ってない認識でいいのですか？
開放忘れですよね

0037デフォルトの名無しさん

2014/10/12(日) 10:01:07.24ID:Rdz70+uR

使ってなくても参照可能な状態ならnull突っ込んどけよ

0038デフォルトの名無しさん

2014/10/12(日) 10:06:02.46ID:PS2RkwMW

null突っ込むとか考えないといけないならもう気持よく開放させてください

0039デフォルトの名無しさん

2014/10/12(日) 11:06:29.68ID:jwvcB2bY

>>38
NULLになってなければ最後に解放。
NULLなら使ってない。解放済み。とかやってたころと結局変わってないよね。
むしろ、解放のタイミングとか考えなきゃいけない。やること増えたような気がする。

char *data = NULL;

略
data = (char *)malloc(.........)
if(!data)
goto 最後
else
略

略略略複雑な動き略略略略略

最後
if(NULL == data)
free(data);

0040デフォルトの名無しさん

2014/10/12(日) 11:11:22.69ID:cL8Hj/o5

>>31
もっとずっと大昔からあるだろ。

>>32
perlも参照カウントだな。
perlのはGCでobjcのはGCではないと思うけど、
何が違うんだろうな。

0041デフォルトの名無しさん

2014/10/12(日) 11:17:35.70ID:Du/HgjiN

objcはスクリプト言語じゃないから、吐き出されたバイナリ自身にメモリ管理コードが入ってるところじゃないかな。

0042デフォルトの名無しさん

2014/10/12(日) 11:20:10.87ID:Du/HgjiN

当時GCという言葉は無かったが、オブジェクトパスカルの文字列は唯一自動解放されてたな。
一方Cはnullパディングなメモリを自分で確保して解放して…

0043デフォルトの名無しさん

2014/10/12(日) 11:32:15.06ID:cL8Hj/o5

>>41
なるほど。
あとobjcのは自動だけどあんまり透過的ではないね。

0044デフォルトの名無しさん

2014/10/12(日) 11:42:15.44ID:yWo9u0cs

>>40
参照カウントを明示的にデクリメントするのは普通GCと呼ばれないと思う。
C++のスマートポインタは微妙なとこだが。
個人的には、実際の回収のタイミングをプログラマが制御できるかどうかが
分かれ目かな。

0045デフォルトの名無しさん

2014/10/12(日) 11:45:40.46ID:cL8Hj/o5

>>44
いや、今のobjcはそこは自動。
参照カウントを操作するコードはコンパイラが勝手に入れて、プログラマは触れない。

0046デフォルトの名無しさん

2014/10/12(日) 11:46:08.06ID:oZdnSd4X

GCがあってもメモリリークは起きる ← うんうん
だからGCは失敗 ← は？

0047デフォルトの名無しさん

2014/10/12(日) 12:16:18.39ID:K67PydJN

リソース掴むオブジェクトを扱う場面での
auto_ptr/unique_ptrと同じことをするのに
javaのtry with resourcesや
c#のusing,dのscope

どれも笑えるほど間抜けで間違いやすく
リソース掴むかどうかプログラマが
知っている必要があるとか
色々破綻しすぎ

0048デフォルトの名無しさん

2014/10/12(日) 12:27:00.92ID:XUhdfZSs

>>46
GCの目的を達せられてないなら、そう評価されても仕方ないやろ

0049デフォルトの名無しさん

2014/10/12(日) 12:37:01.74ID:9H44j9Kw

ストップザ・ワールドさえなければGC歓迎なんだけどなー

0050デフォルトの名無しさん

2014/10/12(日) 12:37:50.50ID:hLdPYKPK

>>45
GCじゃなくてARCだろ

0051デフォルトの名無しさん

2014/10/12(日) 13:01:26.29ID:sv4A2Uaz

>>48
> GCの目的を達せられてない

ちゃんと使えてないだけだろ
それを GC のせいにするなよ w

0052デフォルトの名無しさん

2014/10/12(日) 13:25:42.92ID:aqGemz9O

明示的に消すのはまあ良いとしてnullされたら芋ツルに循環追跡して断
ち切る仕組みはあって良いと思うまあ手抜きしたいだけだが

0053デフォルトの名無しさん

2014/10/12(日) 13:29:57.54ID:oZdnSd4X

GCがあってもメモリリークは起きるが
GCがあれば起きないメモリリークもあるんだから
それを理由にGC抜きでメモリを管理すべきという主張はおかしい

0054デフォルトの名無しさん

2014/10/12(日) 13:47:40.68ID:PS2RkwMW

重い、開放されるまでメモリ食う、GCがあってもGC無い時と同じくらい気を使わないとリークするっていう
デメリットがキツすぎてメリットはないようなもの

0055デフォルトの名無しさん

2014/10/12(日) 13:52:35.33ID:9H44j9Kw

リークしても自分で管理してれば解消できるんだけど
GCだとどこでリークしてるかわからないからいらない

0056デフォルトの名無しさん

2014/10/12(日) 13:59:06.09ID:Du/HgjiN

んなもん、ヒープダンプすればだいたい予想つくべよ

0057デフォルトの名無しさん

2014/10/12(日) 14:01:17.81ID:9H44j9Kw

まじかよ
すげーな

0058デフォルトの名無しさん

2014/10/12(日) 16:33:59.45ID:ZNdZQbYT

どーもWEBの所為で、というか今までPGに向いていなかった人にも良い仕事が出来るようになったようで
旧タイプというか本来タイプの技術者と壁があるようだな

0059デフォルトの名無しさん

2014/10/12(日) 16:38:08.31ID:jjrAIsW+

本来タイプの技術者とはOSを一から作るものよ。

他人が作った技術なんて信用してないからな。
全て自分で管理するのが一流の技術者

0060デフォルトの名無しさん

2014/10/12(日) 16:42:45.90ID:ZNdZQbYT

>>59
それが理想だが、仕事だと環境を選べない。石を直接叩いた時は素直でやりやすかったものよ

0061デフォルトの名無しさん

2014/10/12(日) 16:50:59.96ID:b192FRFU

GCの無いHaskellを想像したら鳥肌が立った。

0062デフォルトの名無しさん

2014/10/12(日) 17:10:56.08ID:uNtO2YXD

>>60
> それが理想だが、仕事だと環境を選べない。

じゃあ趣味の話をしてくれよ。

sqrt(a * 2 + b * 3)

を「素直でやりやすい方法」で書いたらどうなるの？

0063デフォルトの名無しさん

2014/10/12(日) 17:14:52.08ID:WHilwmxs

石を直接叩いた時代は単に要求が
今よりもはるかに小さかっただけだよ。
簡単な事しかしてない。

いや、コード自体は難しいんでしょ？
簡単なことっていうのは、コードの話ではなくて
作る機能のこと。

0064デフォルトの名無しさん

2014/10/12(日) 17:48:09.49ID:ZNdZQbYT

>>63
多用途コンピュータではない物や独自のデバイスを制御する時に石を叩く。見慣れたアプリとは
違った物を作るときに必要になる。

>>62
お前はその程度のコードに設計が必要なのか？

0065デフォルトの名無しさん

2014/10/12(日) 18:04:01.60ID:WHilwmxs

> お前はその程度のコードに設計が必要なのか？

設計？どこからでてきたの？

いや、石を直接叩いていたら
難しいだろって話。

これが難しく感じるならダイアログボックスを
出すコードでもいいよ。

JavaScriptなら

alert("あほ");

0066デフォルトの名無しさん

2014/10/12(日) 18:15:24.76ID:aqGemz9O

上の誰かさんが自分で全部書いた物より長い間保守されたライブラリの方が
信頼出来ると思うのは気のせいか

0067デフォルトの名無しさん

2014/10/12(日) 18:21:08.51ID:6hSJbmJs

プログラマの仕事っていうのは、前にやった同じことを
何度もやることではないんだよね。

一回やったことと同じようなことは
二度とやらないぐらいの気持ちでやらないといけない。

同じことを何度も繰り返すのはコンピュータが得意とするところなので
人間がやってる「同じようなこと」はコンピュータにやらせるもの。

メモリ管理なんてのも、人間がやることじゃないんだよ。
何度も同じことをやるなんてサルのオナニーと一緒だよ。

0068デフォルトの名無しさん

2014/10/12(日) 18:24:13.59ID:ZNdZQbYT

>>65
このスレでは実行環境の話をしてるんだ。それを理解して失せろ
>>67
その理屈だと一度使ったライブラリは二度と使うなという事になるな

0069デフォルトの名無しさん

2014/10/12(日) 18:28:09.44ID:6hSJbmJs

>>68
> その理屈だと一度使ったライブラリは二度と使うなという事になるな

意味不明。同じことができるならコードを書くなって話。

同じコードを書かないで出来るなら、ライブラリを使ったコードも書かなくていいよｗ

0070デフォルトの名無しさん

2014/10/12(日) 19:46:54.20ID:im4AGP4w

「ガーベジ」コレクションって書いてる奴いると叩き殴りたくなる

0071デフォルトの名無しさん

2014/10/12(日) 19:51:27.69ID:ZNdZQbYT

GC派はコンピュータの仕組みを知らないからかな？メモリを確保できなきゃプログラムをロードする事も
リソースを扱う事もファイルの読み書きも出来ない。その用途は毎回違う。
それを同じ処理で出来ると思ってるのが凄い

0072デフォルトの名無しさん

2014/10/12(日) 20:16:48.31ID:FZ1mZF0A

>>71
> GC派はコンピュータの仕組みを知らないからかな？

まるで、何かの仕組みを知った人は、その仕組みを
使わないことを選ぶみたいな言い方じゃないか？
ポンプの仕組みを知った人は、ポンプを使わずに自分で吸い上げるようになるみたいな。

仕組みを知った上で、その仕組が便利だから使うんだよ。

> それを同じ処理で出来ると思ってるのが凄い
今、GCの話だったよね？メモリ確保する時の話じゃなくて
メモリを解放する時の話。

お前の書くコードは、同じメモリを使ってるのに、
毎回違う方法でメモリを解放してるのか？

ばかじゃね？

0073デフォルトの名無しさん

2014/10/12(日) 20:18:00.19ID:FZ1mZF0A

用途ごとに違う方法でメモリ解放するって

freeForFile とかfreeForConfigFileとか
そういう関数作ってんの？

0074デフォルトの名無しさん

2014/10/12(日) 20:21:04.63ID:vwmhZXgg

なんでこいつら仲悪いの？

0075デフォルトの名無しさん

2014/10/12(日) 20:23:19.99ID:cL8Hj/o5

>>70
正しくは？

0076デフォルトの名無しさん

2014/10/12(日) 20:23:46.40ID:FZ1mZF0A

>>74
２ちゃんねるはじめてか？

これが普通なんだよ。

0077デフォルトの名無しさん

2014/10/12(日) 21:18:05.03ID:ZNdZQbYT

それもあるが、コンピュータに対する考え方が真逆でありながら同じ仕事をしてるからだろうな

0078デフォルトの名無しさん

2014/10/12(日) 21:27:56.88ID:jwvcB2bY

GC自体、メモリ管理がちゃんとできない人対策だったわけで
そんなやつが、メモリリークが発生して、それを調査できるスキルがあるわけもなし

ちゃんとメモリ管理できてる人からすると、よけい複雑になっただけ

0079デフォルトの名無しさん

2014/10/12(日) 21:34:54.47ID:uoArxlQJ

>GC自体、メモリ管理がちゃんとできない人対策だったわけで

あぁ、この中でfree書き忘れたことがない人だけ
石を投げなさいってやつだな（大爆笑）

0080デフォルトの名無しさん

2014/10/12(日) 21:45:20.46ID:K67PydJN

今時c++でdeleteを昔の意味で使う人間は
忘れるとかそれ以前の問題で
終わっているような。

0081デフォルトの名無しさん

2014/10/12(日) 21:52:54.07ID:uoArxlQJ

>>80

仕組みを知った人は、面倒でも効率が悪くて
ミスを誘発しそうでも、

自分でやるのが自称プロだそうですよｗｗｗｗ

0082デフォルトの名無しさん

2014/10/12(日) 22:01:17.22ID:K67PydJN

c++でdelete freeでプログラム書けるし
全く同じやり方で、他のリソースの
解放も勝手にやってくれるようになる。

怖いのは循環参照だけ。
この場合GC言語だとメモリのリークは防げても、循環参照しているオブジェクトに
保持されているリソースの解放タイミングは
全く保証されない。

で、それの対策も考えたら結局
c++で弱参照、単なるポインタなど
駆使するのが一番効率的

0083デフォルトの名無しさん

2014/10/12(日) 22:05:26.88ID:uoArxlQJ

この場合GC言語だとメモリのリークは防げても、循環参照しているオブジェクトに
保持されているリソースの解放タイミングは
全く保証されない。

その反対で、GCではない言語だとメモリリークするわ、循環参照しているオブジェクトは
解放できないわで、もっと問題が起きる。

0084デフォルトの名無しさん

2014/10/12(日) 22:08:58.07ID:jwvcB2bY

>>79
だれ？誰と戦ってるの？

0085デフォルトの名無しさん

2014/10/12(日) 22:09:56.49ID:uoArxlQJ

>>84
知らぬが仏だよ（笑）

0086デフォルトの名無しさん

2014/10/12(日) 22:27:26.00ID:6t43fLEu

GCのやり方？が悪いわけではないでしょ
GCでパフォーマンス上がることもあるし

0087デフォルトの名無しさん

2014/10/12(日) 23:01:07.26ID:yWo9u0cs

>>82
GC言語でリソースの解放タイミングが保証されないのは、別に
循環参照に限った話じゃないと思うが。

0088デフォルトの名無しさん

2014/10/12(日) 23:05:39.92ID:sv4A2Uaz

まあ、適材適所なんだけどね
GC は勝手にやらせとくと色々予測できないし、ちゃんと制御しようとすると面倒なことになって本末転倒だったりする
結局スクリプトとか C# で作るツールとかの小規模なプログラムでしか使ってないや

0089デフォルトの名無しさん

2014/10/12(日) 23:19:48.88ID:K67PydJN

>>87
いやまあ言いたいことは同じなんだけど。
ヒープみたいに、lazyに解放すればいい
リソースなんて少数派な位なのに
ヒープだけを特別扱いしてリークしづらく
しているのがGCで、逆に他のリソースの
解放に関しては糞の役にも立たない。

頑張って使いやすくしても
try with resourcesみたいなのが精々

0090デフォルトの名無しさん

2014/10/12(日) 23:20:37.56ID:Du/HgjiN

単純に速度が必要でメモり欲しいループの前でsystem.gc()すりゃいい

0091デフォルトの名無しさん

2014/10/13(月) 00:36:28.02ID:XlHNUUuP

>>89
> 頑張って使いやすくしても
> try with resourcesみたいなのが精々

言い方がひねくれてるだけで、
使いやすくなってるんだろ？

100% じゃなくても90%なら0％よりもはるかにいいし。
君、完璧主義かい？完璧じゃなければ0の方がいい。
命を完全に守れないなら、安全装置はいらない。

0092デフォルトの名無しさん

2014/10/13(月) 01:50:00.34ID:qVWnI3+v

シートベルト装着義務違反　減点１

0093デフォルトの名無しさん

2014/10/13(月) 02:14:43.55ID:Sk2z4NAD

そもそも管理の観点が違うものをリソースとかそういう言葉で一括りにしていいもんなのかなぁ
別にGCとRAIIが必ずしも互いに排他的なものでも無いだろうし

0094デフォルトの名無しさん

2014/10/13(月) 02:52:33.01ID:Y+iyP5NT

参照してるから解放されないのであって、使ってない物は
参照しないようにする＝null入れるだけの話だろ。

0095デフォルトの名無しさん

2014/10/13(月) 02:57:40.58ID:2n2KRb08

>>93
Unixなんか、リソースは何でもファイルですよ？

これが抽象化というもの。

0096デフォルトの名無しさん

2014/10/13(月) 03:02:03.17ID:jfB1gY05

>>94
OS側から勝手に参照し続けるKindleという機種がありましてな…。

0097デフォルトの名無しさん

2014/10/13(月) 05:51:50.99ID:Y+iyP5NT

それはOSの設計ミスであってGCのせいではない。

0098デフォルトの名無しさん

2014/10/13(月) 09:29:14.75ID:ammU0rqh

disposeしないとnull入れても解放されないよー

0099デフォルトの名無しさん

2014/10/13(月) 09:48:47.95ID:jZxRKtQH

IDisposableはGCに頼らず手動で解放するためのものだろ
DBのコネクションとかファイルハンドルとか

0100デフォルトの名無しさん

2014/10/13(月) 14:38:15.95ID:yJLU3TGp

>>99
それは「解放する方法」であって
手動か自動かは関係ないよ。

0101デフォルトの名無しさん

2014/10/13(月) 15:01:00.74ID:iUH6VxYJ

mallocしたらfree
newしたらdelete
それでよかったのに
GCになって、null入れなきゃだめ、disposeしなきゃだめ、さらに世代云々・・・。

0102デフォルトの名無しさん

2014/10/13(月) 15:10:40.21ID:ysc5yoNU

楽しようとすると苦しむこと（人）が。。。

0103デフォルトの名無しさん

2014/10/13(月) 16:19:06.94ID:plGQaU3/

環境によってGCから逃げられないというのは困る。進化の袋小路という気がしないでもない

0104デフォルトの名無しさん

2014/10/13(月) 16:38:33.91ID:yJLU3TGp

>>101
> それでよかったのに

よくなかっただろ？

クラス内部でメモリが確保されている場合（つまりオブジェクトを返す関数）
誰が解放するのかわからない。

クラスに解放してもらうのが一般的だがそうすると、malloc / free だけじゃなく

> GetWindowDC 関数を呼び出してウィンドウデバイスコンテキストを取得した場合や、
> GetDC 関数を呼び出して共通デバイスコンテキストを取得した場合は、
> その後、ReleaseDC 関数を呼び出してデバイスコンテキストを解放しなければなりません。

みたいなルールがクラスごとに大量にできることになる。

0105デフォルトの名無しさん

2014/10/13(月) 16:56:47.75ID:plGQaU3/

別に普通だが？

ポインタでつまずく奴が多いと聞いたが、できるだけ早く戦力に育てたいのと熟練技術者が欲しいという
双反する要求が問題かもな

0106デフォルトの名無しさん

2014/10/13(月) 17:45:42.07ID:R5t/GNKU

メモリリークしたことがない人なんていないからな。

コンピュータが自動化できることを
人間がちまちまやるのはマヌケなことで
そんなことに時間を使うのはプロじゃない。

素人は何も考えずに言われたことしかしないから
それが普通と思ってずっと同じことをする。
働いている時間が長いだけのエセ技術者が多い。

何度も同じことをやってると思ったら
それをなくそうという発想が大事

0107デフォルトの名無しさん

2014/10/13(月) 17:55:40.57ID:iUH6VxYJ

メモリ管理からの解放！
といいつつ、これだけ議論が出てくるってことは、解放されてないってことだ。

0108デフォルトの名無しさん

2014/10/13(月) 18:10:19.75ID:ammU0rqh

バックグランドGCが実用になってくれないとゲームが作れん

0109デフォルトの名無しさん

2014/10/13(月) 18:22:55.35ID:R5t/GNKU

>>107
議論が出てくれば、解放されていないことになるという
理屈がわからんよ。

論理的じゃないね。

議論の内容はメモリ管理から解放されたかどうかじゃなくて、

俺は自分で管理しても出来る！
メモリは自分で管理せよ！って
喚いてるだけじゃんか。
その理由すら述べられていない。

0110デフォルトの名無しさん

2014/10/13(月) 18:28:57.57ID:Okyxmr/t

>>106
STL使えばメモリリークからは解放されるんでね？
そして今度はメモリのフラグメンテーション問題に捕まるとｗ

0111デフォルトの名無しさん

2014/10/13(月) 18:32:51.44ID:I6MRDE10

>>99
どう使おうが自由だが、MSさんはアンマネージドメモリーを開放するために用意したと言っている
マネージドはあくまでGC使えってことなのかな？

0112デフォルトの名無しさん

2014/10/13(月) 18:34:33.46ID:jZxRKtQH

>>100
C#の話ですまんが、IDisposable.Dispose()を実行すれば、DBコネクションなら即閉じられるようになってるじゃん
これって手動って言わない？

もちろん放置すればGC時にファイナライザで閉じられるけど

0113デフォルトの名無しさん

2014/10/13(月) 18:37:06.45ID:R5t/GNKU

>>110
> そして今度はメモリのフラグメンテーション問題に捕まるとｗ

メモリのフラグメンテーション問題は
GCを使わなくても起きることだから
別問題だな。

0114デフォルトの名無しさん

2014/10/13(月) 18:40:18.91ID:jZxRKtQH

>>111
ヒープに関してはGCしかない…
シビアなメモリ管理が必要ならGCのない言語使うしかない

0115デフォルトの名無しさん

2014/10/13(月) 18:41:53.43ID:R5t/GNKU

> シビアなメモリ管理が必要なら

それは具体的にはどんなものかって話がしたいですね。

0116デフォルトの名無しさん

2014/10/13(月) 18:54:23.74ID:I6MRDE10

数日とか数ヶ月単位で動き続けるデーモン系はたしかにシビアだろうが
それほど作る人も沢山居ないよね

0117デフォルトの名無しさん

2014/10/13(月) 19:36:50.37ID:Okyxmr/t

>>114
自力でコンパクション作っとかないとフラグメンテーションでメモリ取得に失敗するわな
というか、フリーのGCやコンパクションって無いの？？

0118デフォルトの名無しさん

2014/10/13(月) 19:54:12.82ID:Okyxmr/t

>>115
メモリのフラグメンテーションで調べればどんな状況が発生するかは理解できると思う
要するにメモリ取得や解放の繰り返しでメモリが虫食い状態になる

0119デフォルトの名無しさん

2014/10/13(月) 20:26:24.03ID:qIojKSBE

今時のメモリアロケータはフラグメントが起きにくいような工夫がされてんじゃないの？
それで追いつかないほどシビアな世界はそもそも動的にメモリ確保するの禁止だったりしそう。

0120デフォルトの名無しさん

2014/10/13(月) 20:48:29.24ID:plGQaU3/

GCでも循環参照起こしてちゃダメじゃん。
メモリ一つ管理できないで何を管理するプログラムを組み気かと

0121デフォルトの名無しさん

2014/10/13(月) 20:50:47.42ID:Okyxmr/t

大きめのメモリと小さなメモリで距離を離してメモリを配置する事で
フラグメンテーションが発生しにくくはなってるが、全く起きないわけじゃない
大きめのメモリ同士を扱う場合は、どうやっても配置に無理が生じる

これを回避するには動的メモリ確保を禁止するか、コンパクションを作るしかない！

というか、コンパクションは作るの面倒だったな

0122デフォルトの名無しさん

2014/10/13(月) 20:55:22.39ID:jfB1gY05

よしメモリもFATで管理しようぜ！

0123デフォルトの名無しさん

2014/10/13(月) 20:57:44.08ID:iOywxQpx

メモリのフラグメンテーションってページング方式を採用しているOSでも気にする必要あるんだっけ？

0124デフォルトの名無しさん

2014/10/13(月) 21:06:21.12ID:yDwfk/q+

>>123
32bitプロセスなら仮想メモリ空間
食い潰すこともあるんでね？

64bitなら今のところどころか
かなり遠い将来まで大丈夫だろうが。

0125デフォルトの名無しさん

2014/10/13(月) 21:08:06.85ID:vSlytRGO

8G、16Gとか普通に積んでるのに、ちまちましたこと気にすんなよ。

アプリの本質とは関係ないメモリ管理に悩まなくて済むのなら、
1G程度のメモリリークなんてどうでもいい。
GC様々だ。

0126デフォルトの名無しさん

2014/10/13(月) 21:09:33.61ID:Okyxmr/t

>>123
メモリをポインタで管理している以上、メモリ配置に問題が起きる可能性は避けられない
32bitで管理してるなら、ポインタで管理できるメモリは2Gバイトを超える事はない
64bitだともうちょい楽なんだけどな

0127デフォルトの名無しさん

2014/10/13(月) 21:14:48.07ID:plGQaU3/

メモリ管理を放棄するならGCの余計な挙動で遅くなるだけだが

0128デフォルトの名無しさん

2014/10/13(月) 21:16:45.07ID:Okyxmr/t

>>124-125
しかしたいていの場合は、コンパイラは64bit設定ではなく、32bitの設定になっているけどな
まあ、世の中のディスクトップPCから32bitが死滅しない限りはこのまんまの状態が続くんだろうな

0129デフォルトの名無しさん

2014/10/13(月) 21:28:01.09ID:QgIQdsn/

「GCでも循環参照起こしてちゃダメじゃん。
AがBを参照して、BがAを参照したらメモリが解放されなくなるんだぞ！
GCを使わなければほら、Aをdelete、Bをdeleteするだけでいいんだ！」

「そうか。Aだけnullを代入すれば循環参照は解放されるから
GCの方が手間が半分になると思っていたよ。」

「・・・（くやしい！言い返せない！）」

0130デフォルトの名無しさん

2014/10/13(月) 21:38:25.84ID:+oHLinSc

>>128
CやC++の場合はな
C#やVBの場合は関係無いな

0131デフォルトの名無しさん

2014/10/13(月) 21:42:35.91ID:6Jt59JIp

>>130
64bitのC#と32bitのC/C++では、どっちの方が早いんだろ？

0132デフォルトの名無しさん

2014/10/13(月) 21:47:48.63ID:6Jt59JIp

>>130-131
C/C++でGC使って64bitでコンパイルすれば良いんじゃね？

0133デフォルトの名無しさん

2014/10/13(月) 22:42:28.43ID:Y+iyP5NT

不要になったらdeleteするのと不要になったらnull入れるのと
どう違うんだって話はあるが、そこらへんを自動で判断できる
ほどコンピュータは賢くない。

0134デフォルトの名無しさん

2014/10/13(月) 22:47:19.03ID:zulUt3IX

循環参照でかつ、循環参照で問題になる場合にだけ、nullを入れるのと
毎回deleteしなきゃならなんのでは

毎回deleteするほうが、プロっぽいじゃん？

0135デフォルトの名無しさん

2014/10/13(月) 22:48:45.33ID:yDwfk/q+

今時c++で昔の意味でのdeleteを
使うとか正気を疑われかねない。

0136デフォルトの名無しさん

2014/10/13(月) 22:58:21.29ID:zulUt3IX

try-catchなるものがはいってから
メモリ管理が難しくなった。

エラーになったら呼び出しもとどころか
その上の上の上にまでジャンプしたりする。

あんな機能は使うな。

0137デフォルトの名無しさん

2014/10/13(月) 23:07:33.55ID:qIojKSBE

大昔はlongjmpで似たような事やってたじゃん。

0138デフォルトの名無しさん

2014/10/13(月) 23:09:42.85ID:jZxRKtQH

GCの循環参照って、ルートから参照できなくすればいいだけだからそんなに大した問題じゃない
※参照カウント方式のGCは知らん

0139デフォルトの名無しさん

2014/10/13(月) 23:10:09.02ID:zulUt3IX

>>137
だから使うの禁止だ。

0140デフォルトの名無しさん

2014/10/13(月) 23:30:11.08ID:Y+iyP5NT

まあ解放がどうのこうのって言うよりプログラムの構造的な設計を
どうするかって話だな。

0141デフォルトの名無しさん

2014/10/14(火) 00:12:20.52ID:a1k8REF8

>>128
＞ディスクトップPC
帰れ

0142デフォルトの名無しさん

2014/10/14(火) 00:47:57.82ID:3uqy4Mr/

GCがあるとプログラムの可視性が悪くなるし言語仕様による手間という一番倦厭する状態になる。
ポインタを理解できない人への仕様としか思えん。巻き添えになる可能性も随分高くなってきた

0143デフォルトの名無しさん

2014/10/14(火) 00:59:16.64ID:3uqy4Mr/

>>129
どこかに代入してる可能性無いと言い張るんだね？

0144デフォルトの名無しさん

2014/10/14(火) 00:59:24.56ID:zdidno2b

なんか抽象レベルの違うものをごっちゃにしてるような気がする

0145デフォルトの名無しさん

2014/10/14(火) 07:11:04.73ID:EvQWtZZX

C/C++でもGCを使える事が、話をややこしくしている気がする
まあ、使わなけりゃ良いだけなんだが

0146デフォルトの名無しさん

2014/10/14(火) 14:47:26.76ID:ehQP27NF

実装の話と仕様の話と概念理念の話をごっちゃにして、「俺の理想」の話をするのが流行りだからなw

0147デフォルトの名無しさん

2014/10/14(火) 22:07:35.48ID:F0kchRkJ

GCがないとメモリ解放のためのコードががあちこちにできて
可読性落ちるし、エラーの時ちゃんと解放されるよな？って考えていくと
どんどんごちゃごちゃしてくる。

GCがない言語は例外もないので、いちいち値をチェックしてエラーなら
全部解放って書かないといけない。

例外のためのコードとメモリ解放で、関数の半分を占めることもある。

0148デフォルトの名無しさん

2014/10/14(火) 22:20:33.25ID:KA+Nt7Wt

はへほ
肉体労働、ご苦労様です

0149デフォルトの名無しさん

2014/10/14(火) 22:26:34.50ID:YomBVz//

>>147
そういうことを考えると長期記憶、中期記憶、短期記憶、容量別の
管理ポリシーなんかが必要になってくる。そのへんを自動でやって
くれるのがGCなわけで。

短期小容量なら自動変数（スタック）、中容量ならクラス内でnewと
delete（null）まで管理。複数クラスにまたがる長期大容量記憶なら
管理クラスを作ってそこで一元管理とかね。

0150デフォルトの名無しさん

2014/10/14(火) 23:28:26.53ID:KrwLefD2

>>147
> GCがない言語は例外もないので、

C++ 君可哀想

0151デフォルトの名無しさん

2014/10/14(火) 23:35:21.44ID:KA+Nt7Wt

例外があれば何でも出来るんですね
ないときはお手上げですか？

0152デフォルトの名無しさん

2014/10/14(火) 23:47:04.42ID:F0kchRkJ

>>151
ん？一般的に、ないときは「面倒」だよ。

0153デフォルトの名無しさん

2014/10/15(水) 00:03:02.62ID:M/QL++I9

GC言語はデストラクタを有効活用できないからな。利用法について思いもよるまい

0154デフォルトの名無しさん

2014/10/15(水) 00:18:10.82ID:9n9kVUvH

利用法 = メモリ解放（笑）

0155デフォルトの名無しさん

2014/10/15(水) 00:38:31.37ID:M/QL++I9

自分の好きな言語しか勉強しない奴は職場の癌
基礎から勉強できない奴が「技術者」になられちゃ現場が地獄だ
ま、どうせポインタも理解できないバカだからな。メンテナンスする方はたまったもんじゃない

0156デフォルトの名無しさん

2014/10/15(水) 00:45:19.17ID:M/QL++I9

そもそもGCに面倒ばかり押し付けられているCPU、メモリを知り尽くした技術者が参ってるというのに
javaで仕事した（つもり）だぜ！C#で一人前（と思い込んでる）アプリ組んでんだぜって餓鬼が何か
言おうってんだから滑稽だな。井の中の蛙の生きた見本だ。

GCに頼り切って給料貰ってるのに満足してその先を勉強しないんだから技術者に向いてないよ

0157デフォルトの名無しさん

2014/10/15(水) 00:48:33.89ID:9n9kVUvH

要約すると、GC使ってる奴は勉強しないに違いない！
俺はGC使ってないから偉い（実際は勉強してないが）

0158デフォルトの名無しさん

2014/10/15(水) 00:53:01.51ID:7y/wTrfK

基礎的なことをわからずにやってるって言ってるだけでしょ

0159デフォルトの名無しさん

2014/10/15(水) 01:11:42.77ID:M/QL++I9

>>157
都合のいい解釈乙
勉強しないのに身の程わきまえず威張ってスレ汚ししてるってのが読めないようだな。
日本語も読めないのにソースコードが読める筈はないわな
お前はCPUの仕様書なんか見たこと無いだろ？

0160デフォルトの名無しさん

2014/10/15(水) 01:19:19.45ID:DJKkUczC

C/C++はCPUとメモリの世界でプログラムを書く道具だけど、
何もかもがオブジェクトみたいな言語はなんかよくわからん抽象的な世界の物語なんだから、
やっぱGCなりなんなりで処理系の実装を隠さないとやってられんだろ。

0161デフォルトの名無しさん

2014/10/15(水) 01:20:12.78ID:9n9kVUvH

>>159
都合のいい解釈しているのはお前では？

なんで勉強してないことにしたいの？

0162デフォルトの名無しさん

2014/10/15(水) 01:20:50.46ID:M/QL++I9

>>161
メモリ管理も出来ない奴が勉強してるわけがなかろう。自明だ

0163デフォルトの名無しさん

2014/10/15(水) 01:23:53.48ID:9n9kVUvH

> 要約すると、GC使ってる奴は勉強しないに違いない！

やっぱりこの解釈で合ってるじゃんｗ
まったく幼稚だな。

0164デフォルトの名無しさん

2014/10/15(水) 01:24:13.77ID:M/QL++I9

GC信者にネトウヨの匂いがする。理論性は皆無だし悪口しか能が無い

0165デフォルトの名無しさん

2014/10/15(水) 01:26:35.67ID:LxQxwXzT

夜中になんか暑苦しい奴がいるな

0166デフォルトの名無しさん

2014/10/15(水) 01:26:36.83ID:M/QL++I9

>>163
本当にプログラマーやめたほうがいいよ。他の奴が迷惑だ。GCに頼り切っているやつは他の言語は使えない。
GCを利用する技術者は言語にとらわれない。
頼り切るのと利用するのじゃ大違いだ。その差が勉強にあるんだよ

0167デフォルトの名無しさん

2014/10/15(水) 01:28:31.43ID:9n9kVUvH

>>166
だから勉強してるってｗ

何を根拠に勉強してないことにしたいの？

0168デフォルトの名無しさん

2014/10/15(水) 01:29:42.90ID:DJKkUczC

ちなみに俺は勉強してない。

0169デフォルトの名無しさん

2014/10/15(水) 01:30:37.67ID:M/QL++I9

>>167
本当に文盲だな。日本人じゃない可能性もある。政治的な問題だがな。
常にGC亡者の荒らしがいるってのがおかしい。

0170デフォルトの名無しさん

2014/10/15(水) 01:38:55.57ID:M/QL++I9

たとえば>>154ｗｗデストラクタはスコープ…余計な知恵を授けるのはよそう

0171デフォルトの名無しさん

2014/10/15(水) 01:39:55.75ID:7y/wTrfK

日本語で解釈できる勉強ですか？

0172デフォルトの名無しさん

2014/10/15(水) 01:40:22.25ID:9n9kVUvH

凄いなｗ都合のいい解釈（勉強していないはず！）を
していて、それを指摘してるのに
都合のいい解釈をしていないって言い張ってる。
どんだけ自分に都合のいい人間なんだ？ｗ

0173デフォルトの名無しさん

2014/10/15(水) 01:43:52.31ID:M/QL++I9

ネトウヨじゃないのか？行動がそっくりだ。２４時間体制でスタンバイしてるのもな

>>170見れば分かる奴はすぐ分かるんだよねｗｗ

0174デフォルトの名無しさん

2014/10/15(水) 01:49:42.18ID:9n9kVUvH

こんどはネトウヨとか言い出したｗｗｗ

0175デフォルトの名無しさん

2014/10/15(水) 02:25:18.34ID:M/QL++I9

CFRのやり方そっくりだな

0176デフォルトの名無しさん

2014/10/15(水) 07:12:20.38ID:lYOq6uAB

RAIIと相性悪いのはGCというよりは参照型（ポインタ）だと思うんだがな
まあ参照型使いまくるためにGCがあるわけだが

0177デフォルトの名無しさん

2014/10/15(水) 15:27:03.25ID:v6NXSltG

ID:M/QL++I9 はGCされたようだ

0178デフォルトの名無しさん

2014/10/15(水) 20:12:41.76ID:jfSV6itR

GC使わないプログラマって病んでる人多そう

0179デフォルトの名無しさん

2014/10/15(水) 20:41:27.45ID:77ff/EQS

ID:mzO+gdRvには「汚れた」フラグが立ってる（笑）

0180デフォルトの名無しさん

2014/10/15(水) 21:04:42.89ID:9n9kVUvH

Java、JavaScript、CoffeeScript、TypeScript、
C#、VB、Ruby、Python、Perl、PHP、
Lisp、SmallTalk、Haskell、Go、Swiftz

思いつくままに言語を並べてみたが、
比較的最近生まれたよく使われている言語はすべてGC

GCじゃないのは、C (1972年)、C++ (1983年)、Objective-C (1983年)
ぐらいか

0181デフォルトの名無しさん

2014/10/15(水) 21:25:25.77ID:++xXjZNS

スクリプト系言語は性質的にGC必須だからしかたないね

0182デフォルトの名無しさん

2014/10/15(水) 22:37:56.89ID:vri764sz

.Netのもっさり具合は何が原因なんだろ？
原理的にはスタックフレームはメモリのローカリティが高くてキャッシュの効率が高いはず
GCは実装がどうなってるか知らんが、DRAMのrow addressからのアクセスだと
CPUの100クロックは掛かるからローカリティが低いとボトルネックになる可能性があるだろうな

0183デフォルトの名無しさん

2014/10/15(水) 22:48:01.07ID:9n9kVUvH

もうとっくにもっさりじゃなくなったよ。

0184デフォルトの名無しさん

2014/10/15(水) 23:02:38.03ID:DJKkUczC

Objective-Cは一度GC導入したけどわりとすぐにやめちゃったな。

0185デフォルトの名無しさん

2014/10/15(水) 23:26:50.97ID:tcLFVAdr

もっさりなのってXPだからだろ
７だとさくさく

0186デフォルトの名無しさん

2014/10/16(木) 01:25:53.53ID:lkDPugef

4770KとWin8.1 x64の組み合わせでも少しもっさりしてるけどな
デスクトップコンポジションはちらつきを抑えるから気になりにくいだけだよ
つか、Win8が登場した時に7よりキビキビしてるとか言ってたのもいるんだから
当然もっさりにも気付くだろ？

エクスプローラーでsystem32みたいにファイル数の多いフォルダで
スクロールバーをつまんで高速で動かすとCPU負荷が12%（ほぼ1コア占有）になるし、
Catalystも設定項目を切り替えた時に一瞬遅れて切り替わってるのが見える

0187デフォルトの名無しさん

2014/10/16(木) 02:25:19.55ID:g1v1AuWY

Visual C++でGC使う？正気か？？コードが混乱するだけじゃね！？

0188デフォルトの名無しさん

2014/10/16(木) 04:04:38.03ID:fYyW3P4N

>>186
HDDなどデバイスのアクセス速度は、CPUの千倍以上遅いので、
I/Oなどファイル情報を取得する機能は、
ほとんどがデバイスからの応答待ちとなり、
CPUはスリープしている

CPUを使うのは、エアロのような3D演算とか、
TrueTypeFontのような、VectorGraphicsの演算など

0189デフォルトの名無しさん

2014/10/16(木) 04:12:27.65ID:7g6vpmsm

>>182
そういう細かいことなんか吹っ飛ばすのがJITコンパイラってもんなんじゃね？

0190デフォルトの名無しさん

2014/10/16(木) 05:43:37.86ID:ZT6Rz/OP

馬鹿なオッサンは未だにN88-BASICでプログラムは組めても
最新windosで旧winsowsのアプリを互換させる方法が分からない

0191デフォルトの名無しさん

2014/10/16(木) 08:48:34.98ID:5VQWQXAV

どういう意味？
古いプログラムも最新のWindowsでうごくんでしょ？
それがMicrosoftのよいところだよ

0192デフォルトの名無しさん

2014/10/16(木) 08:59:19.11ID:dA0hMT5r

それで、あなたのいいところは？

0193デフォルトの名無しさん

2014/10/16(木) 09:23:45.89ID:cBEAmW2f

C++11になると、GCは必要悪だったことに気付くね。

0194デフォルトの名無しさん

2014/10/16(木) 11:16:01.19ID:xa87SxtN

おれが、おれたちが Win s ows だ

0195デフォルトの名無しさん

2014/10/16(木) 12:35:27.75ID:1m8Z67kI

.　　　　　　　∧＿∧　／￣￣￣￣￣￣￣
　　　　　　　（；´Д｀）＜　スンマセン、直ぐに片付けます
　　-=≡ 　/　　　ヽ　＼＿＿＿＿＿＿＿
.　　　　　 /|　|ＧＣ|. |
　-=≡　/.　＼ヽ／＼＼_
　　　　/　　　ヽ⌒)==ヽ_）=　∧＿∧
-= 　 /　/⌒＼.＼　||　　|| 　(´･ω･`)
　　／／　　　 >　） || 　 ||　( つ旦O >>194
　/　/ 　　　　/ ／＿||＿ ||　と＿)＿) ＿.
　し'　　　　　（＿つ￣(_））￣ (.)）￣ (_））￣(.)）

0196デフォルトの名無しさん

2014/10/16(木) 14:12:44.84ID:3gVHJ/2i

Javaでvoid exec(Object object)みたいなインターフェースを使った場合に
Object型のキャスト周りでヒープを使うみたいなんだけど気のせい？
（リークって訳じゃなくて、一時領域としての使用）

0197デフォルトの名無しさん

2014/10/16(木) 14:39:04.40ID:oAnktbh4

SwiftはGCじゃなくARCだね

0198デフォルトの名無しさん

2014/10/16(木) 18:07:49.29ID:Jdhw7SI+

GCと自前のメモリ管理の両方が使える言語を使え、で終了じゃないの？

0199デフォルトの名無しさん

2014/10/16(木) 18:27:24.82ID:cBEAmW2f

>>198
GCはオマケなんじゃないかな。

メソッド呼び出しの引数などで、オブジェクトがコピーされず参照で渡されると
効率が良い。
では、戻り値として返されるオブジェクトの生存期間をどうするか？など考えると
GCを搭載するとこに行きつく。

C++は右辺値参照という形でうまいこと解決してる。

RAIIを考えると、C++方式のほうが良いと思う。

0200デフォルトの名無しさん

2014/10/16(木) 18:53:02.70ID:cBEAmW2f

「gotoって便利だよね＾＾」スレはいつできるの？

0201デフォルトの名無しさん

2014/10/16(木) 18:55:53.59ID:7O3aHiya

>>1
どうでもいい。

0202デフォルトの名無しさん

2014/10/16(木) 23:45:09.16ID:Ve1wANVM

>>201
なら見なければいい。

0203デフォルトの名無しさん

2014/10/16(木) 23:50:48.25ID:LCz8LFpV

そういえば、C++のスマポはC++11で改善されたけど、なんでああいうふうになったのかね？
単一の所有権を持つスマポとそれに対する弱参照の組み合わせで使えればよかったのに。
C++11のはなんか、shared_ptrが基本でunique_ptr/weak_ptrは特殊用途、って感じる。

0204デフォルトの名無しさん

2014/10/17(金) 00:55:39.72ID:cTXFEv42

unique_ptr<>が基本だろね。

0205デフォルトの名無しさん

2014/10/17(金) 01:16:09.81ID:lRK5wm2m

GC内蔵言語だとRAIIが崩れがちだな
using (resource) {} とか try (resource) {} とか無理やりサポートしてるのもあるが

0206デフォルトの名無しさん

2014/10/17(金) 01:52:27.79ID:C7DOShFL

>>188
姫野ベンチをC#に移植して64ビット最適化ありでビルドして4770K,3.4GHz,TB OFFで実行してみた
C# LARGEサイズ
MFLOPS measured : 392.31 cpu : 57.03
Score based on Pentium III 600MHz : 45.874677

VS2013の/O3だと
MFLOPS measured : 3761.723474 cpu : 57.694098

インテルのコンパイラでAVX2ベクトル化したのだと
MFLOPS measured : 7190.181795 cpu : 51.188518

まあ、こんなもんでしょ

0207デフォルトの名無しさん

2014/10/17(金) 01:59:21.60ID:C7DOShFL

VS2013じゃなくてVC2013だった

移植したC#のコードはここにupしたよ
http://pastebin.com/vm0KbCyK

0208デフォルトの名無しさん

2014/10/17(金) 15:02:41.30ID:uU5Nj9qh

>>206
犬板ではベンチの読み方が違う。

「CPU58%も使うのか、VSは遅いんだな」ってなる。

0209デフォルトの名無しさん

2014/10/17(金) 15:09:35.78ID:qPP0na7I

Win9xは使用率の計算が？だったんですけど

0210デフォルトの名無しさん

2014/10/17(金) 17:50:17.94ID:daE1z7VZ

GCに全部まかせるのではなく、GCは保険！
と考えて、基本全部動的に確保したメモリは自分で解放。
というのじゃダメなの？

0211デフォルトの名無しさん

2014/10/17(金) 18:04:15.29ID:bxyVopED

それは多分両者の悪いところを集めたような結果になる

0212デフォルトの名無しさん

2014/10/17(金) 18:04:21.78ID:O3Ha9Xaq

>>1 は、綺麗にプログラミングをしたつもりになるだけで、正しいプログラムができる教、という
宗教の信者なので、と、考えるのが最も合理的。

0213デフォルトの名無しさん

2014/10/17(金) 18:39:08.95ID:uU5Nj9qh

取得と解放が必要なものが有る限り、オブジェクトの生存期間を相変わらず
把握しなければならないので、GCにすべてを押し付けるのは無理だと思うよ。

すると、Javaの割り切ったアイデア全てが否定される。

良いアイデアだと思ったけれど、実際にはそうでもなかったって感じ。

std::unique_ptr<>が基本だと考えるとすべてがうまく回り始める。
人類には、どこに実体が有るかわからないとか、違う次元にもう一つの
実態が存在出来るとか、わかりにくすぎて使えないんだよ。
実体は一つ、他はすべて参照、これで良いんだよ。

人類を超えた超天才ならJava方式を使いこなせるかもしれない。
C/C++の20倍の速さで。←20倍速いベンチとったページが有る。

0214デフォルトの名無しさん

2014/10/17(金) 18:56:55.01ID:O3Ha9Xaq

そこでHaskell使わないでC++とか言ってるのが嘘くさ過ぎるんだよなw

0215デフォルトの名無しさん

2014/10/17(金) 18:59:03.38ID:NBlGniFl

>>1はおもしろいねたを提供したつもりの馬鹿

0216デフォルトの名無しさん

2014/10/17(金) 19:00:31.99ID:uU5Nj9qh

>>214
関数型は適用範囲が狭すぎるんだよ。
いずれ関数型の時代が来る可能性はある。
でも、今はまだその時代じゃない。

0217デフォルトの名無しさん

2014/10/17(金) 19:06:36.89ID:O3Ha9Xaq

気付いた時には手遅れになる典型例だなw

0218デフォルトの名無しさん

2014/10/17(金) 19:37:28.15ID:uNzVvXKG

>>208
姫野ベンチはメモリアクセスが大きく影響するベンチだよ
C#のスコアが低いのはGCはメモリアクセスが遅いからだと思う
配列の初期化の段階でも２、３秒は掛かってる

0219デフォルトの名無しさん

2014/10/17(金) 20:42:27.58ID:uU5Nj9qh

>>218
犬板ではCPU使用率が指標になるから、C#の方が速いんだよ。
VCが一番遅い。
CPU使用率が一番高いからな。

0220デフォルトの名無しさん

2014/10/17(金) 21:16:50.24ID:lRK5wm2m

アプリケーションサーバークラスになるとJavaは優秀なんだけどね

0221デフォルトの名無しさん

2014/10/17(金) 21:21:55.89ID:uU5Nj9qh

>>220
ウェブページの表示速度に関して、二秒以内、できれば1秒という指標が有る。

二秒もあれば、C/C++なら地球一周しておつりがくる。

0222デフォルトの名無しさん

2014/10/17(金) 21:52:58.27ID:uNzVvXKG

さっきから、犬板って何のことなんだ？

0223デフォルトの名無しさん

2014/10/17(金) 21:56:54.85ID:aWL1PEKf

ぃぬｘ板

0224デフォルトの名無しさん

2014/10/17(金) 22:16:48.92ID:uNzVvXKG

>>219
MFLOPSだけ見れりゃいいと思ったからループ回数の部分端折ったけど、
測定時のループ回数が１０倍以上違うんだぞ
実行ファイルが違うんだから、そっちは参考にならないよ

0225デフォルトの名無しさん

2014/10/17(金) 23:05:01.81ID:uU5Nj9qh

>>224
そんな時はsleep入れればCPU使用率が下がって速くなるぞ。

0226デフォルトの名無しさん

2014/10/17(金) 23:30:43.95ID:uNzVvXKG

>>225
ベンチ結果の見方勘違いしてない？
使用率は理研の公式バイナリで相対比較するためのものじゃないの？

0227デフォルトの名無しさん

2014/10/18(土) 00:05:45.09ID:2d9yKbqY

犬板は、Linux板のこと

でもそこで、「犬」という文字を書き込んだらダメだよ
「犬」という文字に異常に反応する、
基地外がすぐに飛んできて、変なコピペを貼り付けるから

可哀そうにそいつは、いつの頃からか狂ってしまったらしい

0228デフォルトの名無しさん

2014/10/18(土) 00:11:18.71ID:7xxbXr1V

>>227
> 基地外がすぐに飛んできて、変なコピペを貼り付けるから

それが本当か試してみよう。

犬
http://hayabusa6.2ch.net/test/read.cgi/linux/1413558649/

0229デフォルトの名無しさん

2014/10/18(土) 01:28:56.16ID:fR9c0Td8

>>227
なんか怖い話みたいだｗ

0230デフォルトの名無しさん

2014/10/18(土) 15:40:40.04ID:0CGj8uG/

http://hayabusa6.2ch.net/test/read.cgi/linux/1411224674/

0231デフォルトの名無しさん

2014/10/18(土) 16:08:47.23ID:xyIEV5M1

ダマされるなよ
アラスカ速報板＝エスキモー＝イヌイットのことだぞ

0232デフォルトの名無しさん

2014/10/18(土) 16:09:58.26ID:yDqaZQ3r

>>277
全然来ないじゃない。
嘘つき

0233デフォルトの名無しさん

2014/10/18(土) 17:03:38.78ID:0CGj8uG/

gccは失敗、Clangを使うべき。

0234デフォルトの名無しさん

2014/10/18(土) 23:54:33.21ID:xo2uWsa8

C++のRAIIはデストラクタが例外投げられないせいで
殆どのリソースを管理できない欠陥仕様だけど
メモリくらいなら大丈夫だね

0235デフォルトの名無しさん

2014/10/19(日) 00:03:35.73ID:BmB5xxVy

投げるなよ
内部で投げるのがあるなら
キャッチして処理しろと

0236デフォルトの名無しさん

2014/10/19(日) 00:04:28.20ID:GulnFHAj

デストラクタで例外投げるのが
なんでリソース管理の話になるんだ？

リソース管理するならむしろ
デストラクタで例外をなげちゃだめだろ

0237デフォルトの名無しさん

2014/10/19(日) 00:45:26.47ID:g8fFX5o5

趣味で組んでる奴が多そうだが、デストラクタが使えないGC言語は不便

0238デフォルトの名無しさん

2014/10/19(日) 00:45:41.18ID:0BIe0LWV

>>235-236
リソース解放に失敗したとき、例外も投げられず戻り値も無いデストラクタで
どうやって失敗を適切に処置してるの？

それとも、man page で「深刻なプログラミングエラー」って書かれてるような
プログラミングスタイルで良しとしてるわけ？

> http://linuxjm.sourceforge.jp/html/LDP_man-pages/man2/close.2.html

> 注意
> close() の返り値のチェックはよく省略されるが、これは深刻なプログラミングエラーである。
> 前の write(2) 処理に関するエラーが最後の close() のときになって初めて通知される場合がありうる。
> ファイルクローズの際に返り値をチェックしないと、気付かないうちにデータを失ってしまうかもしれない。
> これは特に NFS やディスククォータを使用した場合に見られる。

0239デフォルトの名無しさん

2014/10/19(日) 01:08:30.38ID:BmB5xxVy

>>238
unique_ptrのdeleterにlambda渡して
外部スコープの変数にでも
状態を書き込めばいい

まさにraiiの仕組みを使うことになるが

0240デフォルトの名無しさん

2014/10/19(日) 01:17:34.05ID:0BIe0LWV

>>239
で、あとで状態を一々チェックしてエラーがないか確認すると
古のerrnoと一緒じゃん

0241デフォルトの名無しさん

2014/10/19(日) 01:18:54.48ID:GulnFHAj

>>238
リソース管理の話だだったよね？

デストラクタで例外を投げられたら、
どういうリソースが管理できるっていうのさ？

エラーメッセージが表示できないって
話ならわかるけどさ

0242デフォルトの名無しさん

2014/10/19(日) 01:23:50.83ID:0BIe0LWV

>>241
NFSを使っててファイルのcloseに失敗した場合、
その例外をキャッチして、とりあえずローカルファイルに書き出す処理に移行して
最悪データが失われるのを防ぐとか

0243デフォルトの名無しさん

2014/10/19(日) 01:28:44.77ID:BmB5xxVy

つっても結局やることは同じ
後はベリファイすりゃそんな処理は
要らないって話にもできるし

そもそも読み込みの場合は必要ない

0244デフォルトの名無しさん

2014/10/19(日) 01:39:13.48ID:GulnFHAj

デストラクタではリソース解放を確実にやる。
それはエラーメッセージの表示とは別の話でエラーメッセージを表示したいと
思うならば、その場所でclose()メソッドを呼び出だすもの。

close()メソッドを呼び出すということは
その場所で例外が発生した時に何かの処理をしたいということ。

オブジェクトへの参照を複数持つことを考えればわかるんじゃないかな？
参照が複数ある時、一体いつデストラクタが発生するか？
最後の参照カウンタが無くなった時だ。オブジェクトの参照が複数ある場合
どこにデストラクタの例外処理を書かないといけないのかがわからなくなる。

デストラクタでリソースの解放をするのはいいが、
それは解放忘れが起きないように書くという意味合いが強く
例外が起きるようなリソースの解放はcloseで行うもの。

0245デフォルトの名無しさん

2014/10/19(日) 01:42:22.61ID:GulnFHAj

>>242
delete objした時に
デストラクタで例外が発生して
それをキャッチしたいって話をしてるんだよね？

デストラクタで例外が発生した時、
objインスタンスは消えたらダメってことでいいの？

こんなコードを書きたいの？

try {
　delete obj;
} catch() {
　objからデータ取ってくる
　try {
　　delete obj
　} catch() {
　　どうすりゃいいの？ｗ
　}
}

0246デフォルトの名無しさん

2014/10/19(日) 01:57:22.50ID:GulnFHAj

GCありなしの両方でデストラクタで例外が起きることを前提にした
コードを脳内でシミュレートしてみたが、
オブジェクトで使ってるリソースどころか
オブジェクト自身のメモリリーク対策だけで大変なことになりそうだｗ

0247デフォルトの名無しさん

2014/10/19(日) 02:06:08.59ID:BmB5xxVy

まあエラー発生が遅延するって
closeの仕様自体が酷いというのが
正直なところ

他にこんな仕様のリソースってあるの？

0248デフォルトの名無しさん

2014/10/19(日) 02:11:32.13ID:BmB5xxVy

で、こんな仕様が放置されているってのは
みんながエラー対策が万全だからってんじゃなく
あまり対策がされてないのにそれで許されているからというのが実態

まあ本当に大事なデータなら、書き込み正常終了だけでなくベリファイまでするだろうしね。

0249デフォルトの名無しさん

2014/10/19(日) 02:19:56.02ID:GulnFHAj

closeの仕様というのは結局のところ
カーネルの仕様であり、
そこまで来るとUnixの基本設計の問題だよ。

Unixはいろんなものをファイルとして
扱えるように設計されている。

0250デフォルトの名無しさん

2014/10/19(日) 02:37:59.59ID:GulnFHAj

>>247
> closeの仕様自体が酷いというのが

closeの仕様は全然問題ないでしょ。今回の話はリソースの
解放とクローズ処理をごっちゃにしたからいけないのであって。

リソース解放というのはいかなる状態であってもリソースが解放されていればいい。
たとえばリセットもリソース解放の手段の一つ。
それによってデータの書き込みが中途半端なって
データが壊れたとしても、リソースは解放されている。

クローズはクローズ処理。クローズ時には何かの操作を行うものが
あるかも知れない。たとえばCD-Rなんか書き込み完了時に
ファイナライズという処理が必要だったよね。そんな感じ。

クローズしたいならcloseメソッドを呼び出すべきだし、例外はそこでキャッチできる。
デストラクタでクローズしてもいいが、それは念の為に行っているに過ぎない。
デストラクタではリソースの解放さえできればいい。

0251デフォルトの名無しさん

2014/10/19(日) 02:44:59.04ID:5JPwKBvc

バッファ付きのリソースなら遅延リードライトは必ずやってるだろ
何のためのバッファだよ

0252デフォルトの名無しさん

2014/10/19(日) 11:24:57.62ID:U9zncy/O

ストリームなら遅延・キャッシュは当然だが
ファイルなら毎回flushしる

0253デフォルトの名無しさん

2014/10/19(日) 11:34:13.06ID:XjMCqegx

デストラクタで例外をスローするとはまってしまうC++が失敗作という結論でよろしいか?

0254デフォルトの名無しさん

2014/10/19(日) 11:52:24.25ID:pRVsX1zF

C++のRAIIが失敗作という見方も。

0255デフォルトの名無しさん

2014/10/19(日) 12:00:48.30ID:WiNHWyAn

デストラクタで例外を投げるのは、RAIIが出来ていないってこと。

0256デフォルトの名無しさん

2014/10/19(日) 12:06:42.71ID:GulnFHAj

>>253
他の言語でもデストラクタで例外をだしたらハマるだろうさ。

デストラクタにはこういう問題があるため
デストラクタ自体をなくしている言語が多い。

0257デフォルトの名無しさん

2014/10/19(日) 12:09:02.61ID:BmB5xxVy

デストラクタで例外出すようなコード書く
のが無茶なだけ

javaその他でもファイナライザで
例外出すのは糞だろうに
死ぬか握り潰すかしかない

0258デフォルトの名無しさん

2014/10/19(日) 12:10:50.07ID:WiNHWyAn

RAIIというのは、リソースの有効期間とオブジェクトの生存期間を一致させる
手法なので、デストラクタで例外を送出するようでは、実現できていないと
考えて良い。

0259デフォルトの名無しさん

2014/10/19(日) 12:12:03.77ID:WiNHWyAn

ここら辺は、C++がよく考えられている部分だよね。

0260デフォルトの名無しさん

2014/10/19(日) 12:12:18.58ID:BmB5xxVy

>>256
そのわりには例外機構的に
もっと都合の悪いファイナライザが
あるのは何故

0261デフォルトの名無しさん

2014/10/19(日) 12:12:51.25ID:GulnFHAj

>>259は、理由が何も書いてなくて、しかもあげて書いてるから
ネタでわざと書いてるのがバレバレだなぁｗ

0262デフォルトの名無しさん

2014/10/19(日) 12:16:38.93ID:GulnFHAj

>>260
いや、だからファイナライザもだめなんだって、
都合がわるいだろう？

デストラクタ（もファイナライザ）にはこういう問題があるため
デストラクタ（もファイナライザ）をなくている言語が多い

って書けばよかった？

0263デフォルトの名無しさん

2014/10/19(日) 12:17:56.51ID:XjMCqegx

リソースの解放時に例外が発生する可能性は避けられない。となると死ぬしかないな。
exitの直前でもfreeすべしとか言ってるバカはどうすんだ?

0264デフォルトの名無しさん

2014/10/19(日) 12:18:03.35ID:gVYUQ+UZ

RAIIであらゆるリソースが管理出来ないんならRAIIは失敗だよな

0265デフォルトの名無しさん

2014/10/19(日) 12:18:57.83ID:GulnFHAj

Java セキュアコーディングスタンダード > 05. メソッド (MET)
MET12-J. ファイナライザは使わない
https://www.jpcert.or.jp/java-rules/met12-j.html

こんなドキュメントもあるよ。これはJavaの解決だから
ファイナライザになってるけど、処理の実行タイミング以外の
殆どはデストラクタにも当てはまる話。

0266デフォルトの名無しさん

2014/10/19(日) 12:19:48.49ID:WiNHWyAn

>>261
事実を書いてるだけだよ。

俺はGCは必要ないと考えてる。
RAII的にGCは無茶だよ。
目標の設定が高すぎて人類に実現できない。

C++的なやり方が、人類の脳みそにとって妥当で、しかも既にRAIIを実現できてる。
今使えるRAII。
それがC++のやり方。

あと、std::unique_ptr<>が基本だと考えると良い。
オブジェクトの実体は必ず一か所に有ると考える。
これで、物事が驚くほど単純になる。

0267デフォルトの名無しさん

2014/10/19(日) 12:20:08.77ID:GulnFHAj

>>263
死ぬしか無い例外は、当然例外。
これはOSからkillされたのと同じと考える。
だから自分でfreeする必要はない（できないと考える）

0268デフォルトの名無しさん

2014/10/19(日) 12:22:12.96ID:GulnFHAj

>>266
えっと、今まで話していたのは、
C++でデストラクタでリソース管理するのは
間違いって話なんだけど。

なぜ1980年代後半に登場した言語はすべてGCになったか
わかってる？ 30年以上もGCでRAIIできてるのに
今どき無茶とかお前が理解してないだけだってｗ

0269デフォルトの名無しさん

2014/10/19(日) 12:28:33.48ID:BmB5xxVy

gcでraii出来ているとか
異次元での話かなにか？

0270デフォルトの名無しさん

2014/10/19(日) 12:28:41.46ID:WiNHWyAn

>>268
C++は、オブジェクトが実際に解放される瞬間を自分でコントロールする。
だからこそ、RAIIが可能になる。

Javaの崇高な目標は達成できていない。
「Write once, Runaway.」
実現できてたわ。

0271デフォルトの名無しさん

2014/10/19(日) 12:29:43.39ID:XjMCqegx

>>267
死ぬしかないのはRAIIという手法の下での制約
free教信者は解放出来ない可能性のあるRAIIを使うべきでは
ないという立場をとらなければいけない

0272デフォルトの名無しさん

2014/10/19(日) 12:32:50.01ID:WiNHWyAn

RAIIは実に優れた手法である。

OSによる制限からRAIIが実現できないのであれば、OSから制限を取り除いていくべき。
そういう方向性。

「OSによる制限から実現できないので、RAIIするべきでない」
↑　これバカの考え方。

0273デフォルトの名無しさん

2014/10/19(日) 12:34:31.72ID:WiNHWyAn

「言語による制限から実現できないので、Javaを使うべきではない」
↑　これは妥当な考え方。

0274デフォルトの名無しさん

2014/10/19(日) 12:35:28.62ID:BmB5xxVy

raiiの仕組みを利用して
デストラクタが例外投げる状況を
回避して安全にエラー処理可能だと
いうことを>>239で書いたんだが。
errnoみたいなのが嫌なら
中で一時オブジェクトに
例外オブジェクト代入して、
外で例外としてthrowしてしまえばいい話

0275デフォルトの名無しさん

2014/10/19(日) 12:37:32.37ID:GulnFHAj

>>271
正確に書きなよ。

free教信者は解放出来ない可能性のあるRAIIを使うべきでは
ないという立場をとらなければいけない
と俺（>>271）は考えてる！

0276デフォルトの名無しさん

2014/10/19(日) 12:37:38.15ID:gVYUQ+UZ

「RAIIのためにメモリリークの危険を増やしてでもGC抜きで管理しよう」
↑ これ賢いの？

0277デフォルトの名無しさん

2014/10/19(日) 12:38:35.61ID:WiNHWyAn

C++が優れすぎていて困る。

今日も糞言語に勝ってしまった。

0278デフォルトの名無しさん

2014/10/19(日) 12:39:18.86ID:GulnFHAj

>>270
> C++は、オブジェクトが実際に解放される瞬間を自分でコントロールする。
> だからこそ、RAIIが可能になる。

自分でコントロールするからミスしやすく、
そして自分でコントロールしなくてもRAIIが可能だから
GCが普及したんだよ。

C++で頑張ればRAIIできる！ではなくて、GCある言語ではRAIIは不可能だ。
なぜなら～という説明をしないと反論にはならないよ。
やり直し。

0279デフォルトの名無しさん

2014/10/19(日) 12:39:41.42ID:WiNHWyAn

>>276
メモリーはリークしない。
なぜなら、std::unique_ptr<>が基本だから。

0280デフォルトの名無しさん

2014/10/19(日) 12:52:11.38ID:GulnFHAj

C++も2011年になってstd::unique_ptrができると
メモリの管理がやっとGCに追いついたみたいねｗ

0281デフォルトの名無しさん

2014/10/19(日) 12:54:23.56ID:XjMCqegx

>>275
free教信者のこれまでの発言からそのように演繹される

0282デフォルトの名無しさん

2014/10/19(日) 13:00:05.42ID:GulnFHAj

訂正しておくね。

○ free教信者のこれまでの発言からそのように俺は演繹した。俺が間違っているわけがない。

0283デフォルトの名無しさん

2014/10/19(日) 13:11:36.20ID:XjMCqegx

free教原典では「メモリはいかなる場合もfreeされなければいけない」というものだっ
たらしいが、異常系はどうすんだよという批判を受けて、「free出来る場合はfreeしな
ければいけない」と教義を修正したらしい。
この教義に従うならばfree出来ない可能性を作り出すRAIIは異端の技法。

また教義の再修正で逃げるのだろうか?

0284デフォルトの名無しさん

2014/10/19(日) 13:36:41.57ID:GulnFHAj

>>283
何を言ってるんだ？

その理屈ならでデストラクタが呼ばれない強制終了は
すべて異端の技法ってことになるぞ。

ああ、そうかお前RAII教信者だな。
いかなる場合でもRAIIを満たしていなければならないって
考えてるでしょ？ｗ

0285デフォルトの名無しさん

2014/10/19(日) 15:06:16.67ID:WiNHWyAn

いかなる場合でもRAIIを満たせるようにしていくべき。

0286デフォルトの名無しさん

2014/10/19(日) 17:22:06.23ID:/icP5T1k

>>283
ソフトからどうにもできないものをソフトで解決しようと思うのが間違い。
そのケースだと、解放しない派も解放できず解決になってないから。

0287デフォルトの名無しさん

2014/10/19(日) 18:01:39.56ID:/f9ejQX4

ちわっす、ゴミ回収に来ました

ゴミありませんか？

0288デフォルトの名無しさん

2014/10/19(日) 18:08:37.15ID:WiNHWyAn

RAIIは多くの問題をシンプルに解決する。

RAIIによってスラッシングが起こる　→　そんなLinuxは捨てなさい。

RAIIによってリソース管理がうまくいかない　→　そんなJavaは捨てなさい。

0289デフォルトの名無しさん

2014/10/19(日) 18:27:08.55ID:WiNHWyAn

右辺値参照のおかげで、GC自体がGになってしまった。

Gとは何か？ゴミ、あるいはゴキブリである。

0290デフォルトの名無しさん

2014/10/19(日) 19:11:45.71ID:U9zncy/O

>>287
いつも悪いわね
庭中に落ちてるゴミ全部持ってって

0291デフォルトの名無しさん

2014/10/19(日) 19:29:19.04ID:GulnFHAj

>>287
いつも悪いわね
庭中に落ちてるゴキブリを全部手動で回収してもらって。

0292デフォルトの名無しさん

2014/10/19(日) 19:40:21.16ID:8XPMKtnt

まあGCでデメリットと思われるのはコンパクションで止まるとか
そんなもんだろ。実装にもよるけどnull入れとくだけで再利用して
くれるってのは賢いと思うよ。相互参照なんてGC関係ないしね。

0293デフォルトの名無しさん

2014/10/19(日) 19:42:58.28ID:I8zMPvcx

> ちわっす、ゴミ回収に来ました
> ゴミありませんか？

いつもご苦労様、そこの >>287 を持っていってちょうだい

0294デフォルトの名無しさん

2014/10/19(日) 19:47:46.94ID:WiNHWyAn

>>292
ユーザーを説得できればいいですね。
Javaと聞いただけで敬遠するユーザーが多いですから。

0295デフォルトの名無しさん

2014/10/19(日) 21:13:16.20ID:gVYUQ+UZ

組込み業界か何かか？

0296デフォルトの名無しさん

2014/10/19(日) 22:52:48.25ID:bsmU9avN

Web系以外のすべてじゃね

0297デフォルトの名無しさん

2014/10/20(月) 00:04:19.51ID:S36xvtyo

javaランタイムを入れるのも面倒だが
ランタイムに穴が見つかって新しいの入れろってなるとそれのテストも必要になる
javaが嫌われる理由の1つ

0298デフォルトの名無しさん

2014/10/20(月) 05:16:03.26ID:xAo8P4O1

この手の出来た気になってる出来損ないの為の機能だろ
身の程わきまえてろ掃いて捨てられるゴミクズが

0299デフォルトの名無しさん

2014/10/20(月) 07:55:13.01ID:6fVQz6mC

GCが失敗かどうかと、javaが糞であるという事実はあまり関係がない

0300デフォルトの名無しさん

2014/10/20(月) 08:55:32.17ID:jBlrymD4

>>293
参照が残ってるんで無理っす

0301デフォルトの名無しさん

2014/10/20(月) 09:40:43.49ID:6/LNQkyp

C言語にしがみつく以外に何もできないプログラマの断末魔か...

0302デフォルトの名無しさん

2014/10/20(月) 10:25:26.65ID:GgWymHXm

言語にこだわる低能

0303デフォルトの名無しさん

2014/10/20(月) 11:24:54.16ID:F23WCq0o

>>300
クソグラマーに作らせるとこれだから...

0304デフォルトの名無しさん

2014/10/20(月) 12:22:10.19ID:OXU+d6cz

参照を切る手順があってnullするだけじゃダメらしいがデストラクタは不用とする風潮があるjavaここらはケースバイケースなんだろう

0305デフォルトの名無しさん

2014/10/20(月) 12:28:32.27ID:OXU+d6cz

ああ代わりにファイナライザがあるのね入門系のページしか見てないから知らんかったわ

0306デフォルトの名無しさん

2014/10/20(月) 13:06:55.57ID:cRmJ92uN

ついでにファイナライザ使うなって書いてあるページも見た方がよい

0307デフォルトの名無しさん

2014/10/20(月) 13:10:18.35ID:cRmJ92uN

まあ過信が見られるうちは自分で管理するとか言い出さないことだ
背伸びした厨房のようだよ
省みられるようになって初めて言語を選びたまえ

0308デフォルトの名無しさん

2014/10/20(月) 17:55:33.82ID:OXU+d6cz

使うなは小規模個人開発には関係無さそうですね心置きなく使わせていただきます

0309デフォルトの名無しさん

2014/10/20(月) 18:20:00.83ID:4bxYYw/L

いつファイナライズされるか保証されてないというのが使ってはいけない理由。
ファイナライズされずにプログラム終了してしまうこともある。

0310デフォルトの名無しさん

2014/10/20(月) 18:21:30.93ID:4bxYYw/L

例えばソケットのclose処理をfinalizerに書くと、必ずしも開放されないためにサーバーはタイムアウトまで待つなんて無駄なことになりかねない。

0311デフォルトの名無しさん

2014/10/20(月) 18:22:49.41ID:4bxYYw/L

訂正:　サーバー　→　相手

0312デフォルトの名無しさん

2014/10/20(月) 19:23:32.39ID:eIVQLy/d

とりあえず、C++は標準ライブラリですらデストラクタ内で
closeのエラーを握り潰して無かったことにする実装になってるんだから、
エラーなんて無視すりゃいいんだよ

0313デフォルトの名無しさん

2014/10/20(月) 19:43:44.01ID:4QGk34Ml

>>309-310
だから、"閉じる"処理とオブジェクト削除処理は
分けて考えないとダメなんだよ。

閉じるにかからわず、処理ってのはエラーを返すことがある。
そのエラーに対応するためにC++であってもデストラクタは使えない。

オブジェクト削除処理はエラーにならない。もう使わないとされたものを
削除するだけだからね。

オブジェクト削除時（つまりC++のデストラクタやファイナライズ）で閉じる処理を
するのは構わないし、その処理に依存しても構わないんだが、
それは、オブジェクト削除時のエラーを無視してもいい時だけ。

閉じる処理のエラーやその他、ユーザーへのレスポンスが必要なときは
明示的に閉じるを行うのが常識。

オブジェクトっていうのは閉じている（リソースは解放されている）が
インスタンスは生きているという状態を持たないといけないんだよ。

0314デフォルトの名無しさん

2014/10/20(月) 19:55:19.46ID:4bxYYw/L

この人はデストラクタでエラー処理できないとでも思ってるのだろうか。

0315デフォルトの名無しさん

2014/10/20(月) 20:26:13.01ID:6fVQz6mC

議論がかみ合ってないな
わざとやってるのかしら

0316デフォルトの名無しさん

2014/10/20(月) 20:26:51.72ID:eIVQLy/d

デストラクタで出来るエラー処理なんて
例外が発生しないか、例外を無視できるものに限られる

0317デフォルトの名無しさん

2014/10/20(月) 20:38:30.66ID:4bxYYw/L

外部へスローすることができないというのを
エラー処理や例外処理できないと短絡する脳は大丈夫ですか？

0318デフォルトの名無しさん

2014/10/20(月) 20:47:24.08ID:4bxYYw/L

あと一つ付け加えると、
例外処理で例外が発生した場合それに対する例外処理を作ればいい、そうやって永遠にネストしつづける心配なんてない。

0319デフォルトの名無しさん

2014/10/20(月) 20:50:43.61ID:KGoWPJoA

例外処理なんてもんがあるからみんな苦しむんや
幻のメリットと引き換えに機械的catchの地獄がまっとるんや

0320デフォルトの名無しさん

2014/10/20(月) 21:27:46.95ID:/fOSUrUD

>>317-318
その素晴らしい方法でC++標準ライブラリを救ってやれよ
closeを華麗に握り潰すクソ仕様になってんぞ

0321デフォルトの名無しさん

2014/10/20(月) 22:07:03.10ID:XrE7a2ru

C#のTaskは例外放置してるとファイナライザで例外吐くよ
GC時に発生するので通常の方法だとcatch不可

0322デフォルトの名無しさん

2014/10/21(火) 20:16:50.04ID:pjN8ZUY+

右辺値参照のおかげで、GCが意味なくなった。

0323デフォルトの名無しさん

2014/10/21(火) 20:25:58.63ID:GzwA6HkO

クロージャ書きまくる言語はGC欲しい
一方で非同期プログラミングは例外との相性がウンコ

0324デフォルトの名無しさん

2014/10/21(火) 20:29:08.25ID:52vVR+8/

GCいれないせいで右辺値参照とか
ぶくぶく仕様が太っていくのがC++なんだな

0325デフォルトの名無しさん

2014/10/21(火) 20:32:42.62ID:UehLHyCh

たったこれだけのことを知っていれば、初心者でも
C++でGCなくても大丈夫だってわかるんだよ。

taro-nishinoの日記：右辺値参照の簡単入門
http://slashdot.jp/~taro-nishino/journal/506859

右辺値参照の簡単入門
2008年3月10日 Howard E. Hinnant, Bjarne Stroustrup, Bronek Kozicki

要約
右辺値参照はC++言語の小さな拡張である。右辺値参照はプログラマに、論理的に不必要なコピーの回避及び完全転送関数を与える。
それらは、何よりも高パフォーマンスでより強靭なライブラリの設計を支援することを意味する。

始めに
このドキュメントは、新しいC++言語のフィーチャー、右辺値参照の簡単なツアーを与える。完全な論及と言うより、
簡単なチュートリアルである。詳細は、参考文献を見られたい。

右辺値参照
右辺値参照は、C++の従来の参照と非常によく似た合成型である。これらの2つの型をよく区別するために、
C++の従来の参照を左辺値参照と呼ぶ。参照という言葉が使用される時、両方の参照を言及する。つまり、左辺値参照と右辺値参照。

左辺値参照は、ある型の後に&を置くことによって形成される。

A a;
A& a_ref1 = a; // 左辺値参照

右辺値参照は、テンポラリ（右辺値）にバインド出来ることを除いて、左辺値参照と全く同様に振舞う一方で、
（非コンスト）左辺値参照は右辺値にバインド出来ない。

A& a_ref3 = A(); // Error!
A&& a_ref4 = A(); // Ok

0326デフォルトの名無しさん

2014/10/21(火) 20:33:18.13ID:UehLHyCh

質問：一体何故、これをしたいのか?!

右辺値参照と左辺値参照の組合せが、容易にmoveセマンティクスをコードするために必要なことが判明する。
右辺値参照はまた、C++で未だ未解決の問題、完全転送を成就するために使用出来る。
偉くないプログラマの観点から言えば、右辺値参照から得るものは、より一般的で良い実行速度のライブラリである。

Moveセマンティクス
まがい物のコピーを削減する
コピーは高価になり得る。例えば、std::vectorに対してv2=v1は典型的に関数呼出し、
メモリアロケーション、そしてループを伴なう。vectorの2つのコピーを必要とする処では勿論容認出来るが、
多くの場合そうではない。私達はよくvectorを或所から別の場所へとコピーするが、それは古いコピーを上書きするために行う。以下を考えよう。

template <class T> swap(T& a, T& b)
{
T tmp(a); // 今や二つのaコピーを持つ
a = b; // 今や二つのbコピーを持つ
b = tmp; // 今や二つのtmp(aでもある)コピーを持つ
}

しかし、私達はa又はbの何のコピーも欲しくなかったし、それらを交換したかったのだ。やり直し。

template <class T> swap(T& a, T& b)
{
T tmp(std::move(a));
a = std::move(b);
b = std::move(tmp);
}

0327デフォルトの名無しさん

2014/10/21(火) 20:33:54.27ID:UehLHyCh

このmove()は引数の値をターゲットに与えるが、そのソースの値を保持する必要がない
。そして、vectorに対しては、すべての要素をコピーする必要を避けるように、
move()はその引数をゼロ容量のvectorにすることが当然期待される。言い換えれば、移動（move）は潜在的に破壊的読込みである。

この特別な場合においては、私達は特化によってswapを最適化出来たであろう。
しかし、削除又は更新の直前に、大きなオブジェクトをコピーするすべての関数を特化出来ない。それは手の施しようがないのだ。

右辺値参照の最初の仕事は、冗長性又はランタイムオーバヘッド無しでmove()を実装させることである。

move
move関数は実際は殆ど何もしない。moveがすることは、左辺値又は右辺値の参照を受けて、
コピーコンストラクタを走らせずに右辺値を戻すことだ。

template <class T>
typename remove_reference<T>::type&&
move(T&& a)
{
return a;
}

それらの引数が左辺値か右辺値かどうかについて、主要関数をオーバロードすることはユーザコードの責任である
（例えば、コピーコンストラクタと代入演算子）。引数が左辺値である時、その引数はコピーされなくてはならない。引数が右辺値である時、安全に移動されるであろう。

左辺値/右辺値におけるオーバロード
リソースを所有し、コピーセマンティクス（コピーコンストラクタと代入）を与える簡単なハンドルクラスを考えよう。
例えば、clone_ptrはポインターを所有し、コピー目的のためclone()を呼出してよい。

0328デフォルトの名無しさん

2014/10/21(火) 20:34:28.66ID:UehLHyCh

以下省略。

たったこれだけのことを知っていれば
初心者でもGCがなくても大丈夫だって
理解できるだろう。

0329デフォルトの名無しさん

2014/10/21(火) 20:38:22.37ID:GzwA6HkO

お疲れ様
豆腐の角に頭ぶつけて死ねよ

0330デフォルトの名無しさん

2014/10/21(火) 20:48:48.64ID:M5Ku/KlJ

>>324
それでエンドユーザーが
コード書くのが楽になって
しかもより速度が出るのだから
良いことじゃないの？

それに、gcあるjavaやc#も言語仕様が
肥大化しているのは同じようなものじゃね。

javaなんて他の言語でありがちな新機能を加えてみようとするけど、初期の設計思想からのしがらみで、不完全な形のウンコになるのが恒例になってきている。
genericsとか、try with resourcesとか
lambdaも微妙だし

0331デフォルトの名無しさん

2014/10/21(火) 20:56:11.60ID:zIk7KIVl

C++の言語仕様の肥大化は他の言語の非じゃないだろｗ

他の言語が1レスで説明できる程度ならば
C++だと説明に100レスはかかるからな。

>>325-327みろよ。
これでまだ一部だからな。
しかも基礎知識が十分にある人用。

人間に負担をかけるようなものは
時代の流れに逆行してるよ。

0332デフォルトの名無しさん

2014/10/21(火) 20:57:01.24ID:zIk7KIVl

> genericsとか、try with resourcesとか lambda

これらはじつにシンプルな機能ですね。
簡単に理解できる。

0333デフォルトの名無しさん

2014/10/21(火) 21:05:07.41ID:TjhYfBl9

シンプルな糞は複雑怪奇な糞よりマシ…なのかね

0334デフォルトの名無しさん

2014/10/21(火) 21:12:12.60ID:pjN8ZUY+

むしろ、右辺値参照に慣れてしまうと、GCなんてどこのバカが考えたの？
って感じになってくる。

0335デフォルトの名無しさん

2014/10/21(火) 21:12:54.53ID:lvwLlp6z

みんなもこれをよんで右辺値参照に慣れましょう。

taro-nishinoの日記：右辺値参照の簡単入門
http://slashdot.jp/~taro-nishino/journal/506859

右辺値参照の簡単入門
2008年3月10日 Howard E. Hinnant, Bjarne Stroustrup, Bronek Kozicki

要約
右辺値参照はC++言語の小さな拡張である。右辺値参照はプログラマに、論理的に不必要なコピーの回避及び完全転送関数を与える。
それらは、何よりも高パフォーマンスでより強靭なライブラリの設計を支援することを意味する。

始めに
このドキュメントは、新しいC++言語のフィーチャー、右辺値参照の簡単なツアーを与える。完全な論及と言うより、
簡単なチュートリアルである。詳細は、参考文献を見られたい。

右辺値参照
右辺値参照は、C++の従来の参照と非常によく似た合成型である。これらの2つの型をよく区別するために、
C++の従来の参照を左辺値参照と呼ぶ。参照という言葉が使用される時、両方の参照を言及する。つまり、左辺値参照と右辺値参照。

左辺値参照は、ある型の後に&を置くことによって形成される。

A a;
A& a_ref1 = a; // 左辺値参照

右辺値参照は、テンポラリ（右辺値）にバインド出来ることを除いて、左辺値参照と全く同様に振舞う一方で、
（非コンスト）左辺値参照は右辺値にバインド出来ない。

A& a_ref3 = A(); // Error!
A&& a_ref4 = A(); // Ok

0336デフォルトの名無しさん

2014/10/21(火) 21:14:55.91ID:pjN8ZUY+

GCに慣れてる人は、オブジェクトの寿命をどこで管理するんだろう？
そんなことすらわからなくなってしまったわ。
慣れって怖いね。

まあ、右辺値参照はすごいわ。
std::shared_ptr<>すら、どう使えばいいのかわからんくなってきた。

0337デフォルトの名無しさん

2014/10/21(火) 21:18:14.60ID:M5Ku/KlJ

>>332
まあシンプルと言えばそうだな。
すぐにダメさ加減が理解できるところが。

try with resourcesは単なるスコープ変数+デストラクタで出来る程度のことを
面倒くさく書くだけの機能だし
genericsはあるだけマシな程度の
玩具みたいなものだものね。

lamdaの外側スコープの変数参照に対する
制限もギャグかなにかか？
finalつけなくてもokだけど事実上final
仮引数名が外の変数名と被っちゃダメとか

0338デフォルトの名無しさん

2014/10/21(火) 21:18:51.67ID:pjN8ZUY+

JavaでGCが必要になったのは、C/C++でオブジェクトのコピーにコストがかかるのを見て、
全部参照渡しにしたら速くなり、しかも単純になるってアイデアじゃないかと思うんだよ。
プリミティブはコピーするのも良い考えだよね。
参照渡しになると、じゃあ実体はどこに有るの？ってなってGC必須になるよね。

でも右辺値参照のおかげで、Javaが一気に陳腐に見えてきた。

0339デフォルトの名無しさん

2014/10/21(火) 21:21:01.69ID:pjN8ZUY+

Boost.Asioでエラーハンドラを引数で渡すのをやってるけど、あれも良い考えかも
しれないね。
相変わらずコストは気になるけど。

0340デフォルトの名無しさん

2014/10/21(火) 21:22:33.78ID:pjN8ZUY+

C++は一皮むけた感じだわ。
これはかなり使える。
C++11イイネ！

0341デフォルトの名無しさん

2014/10/21(火) 21:34:44.72ID:txf2w5nH

これよんで。まあ、右辺値参照はすごいわ。

taro-nishinoの日記：右辺値参照の簡単入門
http://slashdot.jp/~taro-nishino/journal/506859

右辺値参照の簡単入門
2008年3月10日 Howard E. Hinnant, Bjarne Stroustrup, Bronek Kozicki

要約
右辺値参照はC++言語の小さな拡張である。右辺値参照はプログラマに、論理的に不必要なコピーの回避及び完全転送関数を与える。
それらは、何よりも高パフォーマンスでより強靭なライブラリの設計を支援することを意味する。

始めに
このドキュメントは、新しいC++言語のフィーチャー、右辺値参照の簡単なツアーを与える。完全な論及と言うより、
簡単なチュートリアルである。詳細は、参考文献を見られたい。

右辺値参照
右辺値参照は、C++の従来の参照と非常によく似た合成型である。これらの2つの型をよく区別するために、
C++の従来の参照を左辺値参照と呼ぶ。参照という言葉が使用される時、両方の参照を言及する。つまり、左辺値参照と右辺値参照。

左辺値参照は、ある型の後に&を置くことによって形成される。

A a;
A& a_ref1 = a; // 左辺値参照

右辺値参照は、テンポラリ（右辺値）にバインド出来ることを除いて、左辺値参照と全く同様に振舞う一方で、
（非コンスト）左辺値参照は右辺値にバインド出来ない。

A& a_ref3 = A(); // Error!
A&& a_ref4 = A(); // Ok

0342デフォルトの名無しさん

2014/10/21(火) 22:15:43.39ID:oEWCieDh

参照が一つで済む場合はunique_ptrを使い
複数の参照が必要な場合はshared_ptrを使い
循環参照になってしまう場合はweak_ptrを使い
ライブラリやAPI等が生ポインタを要求している場合は仕方なく生ポインタを使う

うん、GCでいいや

0343デフォルトの名無しさん

2014/10/21(火) 22:22:52.19ID:M5Ku/KlJ

javaって特にobjectの所有権の概念が薄いよね。
objectは全部参照渡しでconstもつけられないから、ちょっと貸しただけのつもりでも
中身を書きかえられてしまうとか
完全にジャイアンされてしまうとかあり得る。

0344デフォルトの名無しさん

2014/10/21(火) 22:34:33.95ID:pjN8ZUY+

>>342
右辺値参照を基本にしたらいいよ。

0345デフォルトの名無しさん

2014/10/21(火) 22:45:29.46ID:pjN8ZUY+

>>342
右辺値参照が良いですよ？

0346デフォルトの名無しさん

2014/10/21(火) 23:02:13.54ID:n/XE5pFT

なんか宗教の勧誘みたいでキモチワルイ

0347デフォルトの名無しさん

2014/10/21(火) 23:31:40.40ID:txf2w5nH

>>343
> javaって特にobjectの所有権の概念が薄いよね。

所有権の概念を持ってる言語って
他に何がありますかね？

多数派だと思っていた常識が
実は少数派どころかC++にしかないと
知ったらびっくりするかな？

GCが無いせいで、そういう必要性が限りなく
少ない概念が必要になるんだよ。

0348デフォルトの名無しさん

2014/10/21(火) 23:35:47.65ID:n/XE5pFT

最近のObjective-Cも所有権の概念があるんでは。
一旦はGC導入したけどARCの方が気に入ってやめちゃった感じ。

0349デフォルトの名無しさん

2014/10/21(火) 23:40:34.55ID:HewQOdOv

英文和訳のような下手糞な説明だな。これで初心者用とかおもって書いてんのか？

0350デフォルトの名無しさん

2014/10/21(火) 23:45:03.36ID:ZF7bMXxc

特定の言語に依存した主張ばかりだなぁ
世の中には右辺値参照とGCを併せ持つ言語もあるし、constな参照型のオブジェクトを扱える言語もあるよ

0351デフォルトの名無しさん

2014/10/21(火) 23:50:08.01ID:0vfesyL/

所有権の概念と言った場合、共有不可のもの(≒破棄責任)のみを指すか共有可能なもの
(すべての所有者が手放した場合に破棄される)も含めるかで話が違うと思うが、Objective-Cは
Javaと同じだな。

0352デフォルトの名無しさん

2014/10/22(水) 00:21:22.85ID:Oth616Wk

Objective-Cは最後の所有者が手放したら破棄されるけど、
Javaは最後の所有者が手放したらそのうち破棄される。

0353デフォルトの名無しさん

2014/10/22(水) 00:27:42.51ID:LPL6SAIs

かもしれないだろ

0354デフォルトの名無しさん

2014/10/22(水) 00:28:36.04ID:wBkRpUr8

所有権はそれを持っている間は破棄されないってのがポイントであって、
実際にいつ破棄されるかってのはあんま関係ない。

0355デフォルトの名無しさん

2014/10/22(水) 00:34:29.19ID:LPL6SAIs

そら、掴んでいるリソースがヒープだけなら
それで良いけど

0356デフォルトの名無しさん

2014/10/22(水) 00:52:57.74ID:OtEE3/Y/

右辺値参照があればGCの必要が無くなる。

0357デフォルトの名無しさん

2014/10/22(水) 00:56:10.48ID:Oth616Wk

じゃあ例えばJavaに右辺値参照があったらどんな風に使えるの

0358デフォルトの名無しさん

2014/10/22(水) 00:59:41.65ID:OtEE3/Y/

>>357
Javaには有りません。

0359デフォルトの名無しさん

2014/10/22(水) 01:01:07.63ID:Oth616Wk

>>358
おまえアホだろ

0360デフォルトの名無しさん

2014/10/22(水) 01:03:20.78ID:OtEE3/Y/

>>359
作れば有ると言いたいのかもしれませんが、作ってもありません。
勉強しましょう。

0361デフォルトの名無しさん

2014/10/22(水) 01:05:42.55ID:Oth616Wk

>>360
世の中の全員がC++で右辺参照を使えっていう主張なの？

0362デフォルトの名無しさん

2014/10/22(水) 01:11:21.42ID:iNJY0L1E

なんで今頃出てきたんだろ２０年前にすでに同等のポインタラッパーは作った経験がある。

0363デフォルトの名無しさん

2014/10/22(水) 01:13:51.01ID:OtEE3/Y/

>>361
OOPは実はスコープが非常に重要だったってことですかね。
寿命のハッキリしないオブジェクトは実はとても邪悪なものだったのです。
これは実際に使ってみるまで判りませんでした。

GCはとても良いもののように思えるかもしれませんが、実は本質的に間違ったもの、
邪悪なものです。
C#は、構造体とクラスが有るので、もしかすると右辺値参照を取り入れることが
出来るのかもしれません。
Javaは絶望的です。
おそらく、右辺値参照の概念が広まるとともに、GCがJavaの欠点と知られるように
なるでしょう。
使ってみるとわかる種類の問題です。

0364デフォルトの名無しさん

2014/10/22(水) 01:17:06.54ID:/tqtsn/0

メモリ管理しない人には分からんよ。
せっかくのスタックをほとんど使わないとかスコープを超えて存在しないオブジェクトが無いとか
凄い話だ。

0365デフォルトの名無しさん

2014/10/22(水) 01:18:30.96ID:/tqtsn/0

しかしGC無しに飯が食えない奴がいるようだし、目障りという理由だけで排斥する訳にもいかんだろうし
長い年月祟られそうだ

0366デフォルトの名無しさん

2014/10/22(水) 01:22:58.14ID:zNS2c65g

生活のためにやってるだけで
動かす気ない人たちはどう...

0367デフォルトの名無しさん

2014/10/22(水) 01:36:44.78ID:OtEE3/Y/

これは在る種のパラダイムシフトを引き起こすかもしれません。
設計のマナーが変わると思います。

「Javaを使うやつは設計ができない」と言われる日が来るかもしれません。
Javaを使っていたというと「is a」「has a」と言われるようになるかもしれません。
OOPの基本中の基本だったはずのことが、なぜかできていなかったのです。
自分でも驚きです。
相互参照のほとんどすべては、設計上引き起こされるのではなく、パフォーマンス上
起きていたのです。
本当に驚きです。

もちろん、すべての事象がOOPで片付くわけではありません。
しかし、適用範囲は意外と広く、基本に忠実に設計できるのです。
そう、右辺値参照が有れば。

0368デフォルトの名無しさん

2014/10/22(水) 01:39:03.48ID:iNJY0L1E

きみら経験が浅いからわからないだろうけど、あんまり大したもんじゃないと思うw

0369デフォルトの名無しさん

2014/10/22(水) 01:48:52.63ID:/tqtsn/0

GC最初に見たときは、「これが何の役に立つの？」というのが第一印象
C++ではポインタにNULLを渡すのとdeleteするのでは全く意味が違う。
GC派はこれを無視して議論しろと迫る。
「小さな親切大きなお世話」がGCなのは良いとしてGCから逃れられない言語仕様てのは怖い

0370デフォルトの名無しさん

2014/10/22(水) 01:55:08.30ID:OtEE3/Y/

右辺値参照は目から鱗でした。

0371デフォルトの名無しさん

2014/10/22(水) 02:04:29.48ID:iNJY0L1E

１００年後には、GCもスマポもうへんちさんしょうも完全消滅してるのでよろしこ！

0372デフォルトの名無しさん

2014/10/22(水) 02:31:44.13ID:iNJY0L1E

しかし、ガウスとかオイラーってすげーよな時代を３００年くらい先取りしてたんだもんな。

0373デフォルトの名無しさん

2014/10/22(水) 02:33:39.24ID:iNJY0L1E

ガロアもリーマンもすげーよな。やつらの頭はどうなってんだよ。

0374デフォルトの名無しさん

2014/10/22(水) 02:47:20.92ID:iNJY0L1E

何考えてるかわからないといえばラマヌジャンか。

0375デフォルトの名無しさん

2014/10/22(水) 02:49:41.66ID:iNJY0L1E

だがひきこもりのペレルマンの気持ちはよくわかる。

0376デフォルトの名無しさん

2014/10/22(水) 07:33:21.00ID:8DqHr0em

やっぱキチガイが立てたスレだけあるぜ

0377デフォルトの名無しさん

2014/10/22(水) 08:01:42.49ID:4UXHaNsm

そして　いま　またひとり…

0378デフォルトの名無しさん

2014/10/22(水) 08:56:42.16ID:iNJY0L1E

30mはあるやつとか
大小様々な骸骨兵の蠕く神殿の石柱の上になりゆきで潜んでいたら
ついに発見されて石柱の下に骸骨兵や骸骨隊長みたいなのが
うようよ集まってきた夢みた。恐かった。

0379デフォルトの名無しさん

2014/10/22(水) 09:17:42.77ID:iNJY0L1E

幸い５体ほどの巨大骸骨兵はのしのし歩いて神殿外にいってしまった
しかしあれに自分の居る石柱を倒されたら終わり。
巨大骸骨兵は水色でおしりが妙に筋肉質だったのが変だった。

0380デフォルトの名無しさん

2014/10/22(水) 12:09:30.08ID:TEpqRTO4

実用十分なレベルにしておけば簡単で分かりやすく
間違える可能性が低い人間にとって易しい言語になる。

妥協を知らないといろんなことが出来る代わりに
いろんな知識が必要とされ、あれ使うときには
これに気をつけろ！みたいな罠だらけのC++という言語になる。

0381デフォルトの名無しさん

2014/10/22(水) 20:20:20.07ID:/tqtsn/0

高級言語が多機能になればなるほど方言がキツくなってく方が問題じゃ？

0382デフォルトの名無しさん

2014/10/22(水) 20:21:41.88ID:MSiUWjkH

&hearts;

0383デフォルトの名無しさん

2014/10/22(水) 20:25:31.50ID:MSiUWjkH

♥

0384デフォルトの名無しさん

2014/10/22(水) 22:53:08.64ID:OtEE3/Y/

一太郎Arkが実行できなかった時、すべてを悟った。

0385デフォルトの名無しさん

2014/10/23(木) 08:41:03.22ID:TE8bWo7Y

PCの筐体のような構造をしたプレハブ造りの王家の墓から金銀財宝を持ち出し帰る途中
集落を挟んで谷のように切り立った崖の上を歩いていたら、いつのまにか
手にもっているのが、書類の入った東北大学と印字されている紙袋に変わっていた夢をみた。
細い道は峰を続いており、落ちそうな崖にさしかかったとき突風が書類をまき散らした。
一部崖の下に舞っていってしまった。残りを拾おうとしたとき６０～７０歳くらいのおじさん達が
やってきて拾うのを手伝ってくれた。気を付けるんだよ、さっき学生さんが滑落したんだ
これがその遺品だと手渡された紙袋には名古屋大と印字されてあった。

0386デフォルトの名無しさん

2014/10/23(木) 08:44:01.07ID:TE8bWo7Y

峰というか尾根だな。

0387デフォルトの名無しさん

2014/10/23(木) 09:45:40.75ID:eDVkHXcG

きさまにひつようなのは collection ではなく correction だ

0388デフォルトの名無しさん

2014/10/23(木) 10:02:39.25ID:trygFlOB

一緒に滑落すればいいのに

0389デフォルトの名無しさん

2014/10/23(木) 12:51:47.53ID:aKdUNZYR

おまえのなくしたキイボードは、金か銀かプラスティックか？

0390デフォルトの名無しさん

2014/10/23(木) 15:43:05.74ID:eDVkHXcG

King in Perl

0391デフォルトの名無しさん

2014/10/25(土) 12:59:26.62ID:Hk50cfI1

>>1
並列処理にGCは向かん
瞬間高負荷を捌くバックエンドでGCとか爆弾を抱えて運用するようなもの
システムなら帯域を制限、負荷を分散、リクエストを遅延させる回避もあるが、GCを保護する目的にやることじゃない
だが世はJava大好きばかり
大学教授は、ベンダー依存が大嫌いだから

0392デフォルトの名無しさん

2014/10/25(土) 17:23:52.81ID:OnPOpk6v

システム全体の設計に関わる問題だな。GCだけの原因ではない。
コンパクションが必要なほどメモリを使うのなら、メモリプールの
割り当てを増やすとか64bit化するとか全体を見渡した対策が必要。

0393デフォルトの名無しさん

2014/10/25(土) 19:45:41.19ID:dnEj8ZnL

それだと使えない環境が出てくるじゃん
PCなんて今はそうそう買い替える代物じゃないし

0394デフォルトの名無しさん

2014/10/25(土) 22:36:33.73ID:2ar+1gMh

GCは失敗だった。

推奨してた奴は反省するべき。

反省文を提出すること。
↓

0395デフォルトの名無しさん

2014/10/25(土) 23:09:58.00ID:YSa1/4oe

メモリ管理手法に自尊心を乗せるの

0396デフォルトの名無しさん

2014/10/25(土) 23:39:48.32ID:baN3kQAe

>>394

GCは失敗だった。
やはりメモリ管理を自分でさせた方がいい。

そうすれば「お前こんなことともできんの？」って
初心者をいびり倒せる。

最近のものは軟弱だ。機械に頼って楽をしようとする。
俺が若い頃はな。って自慢できる。

自動化に頼る奴は馬鹿だ。
世の中からソフトウェアなんて無くなってしまえ。

0397デフォルトの名無しさん

2014/10/25(土) 23:40:59.74ID:NNwyd4kS

なんかGC＝自動解放みたいな意見が多いけど
GCの主目的ってコンパクションじゃないの？

0398デフォルトの名無しさん

2014/10/26(日) 00:02:08.63ID:1DpED48u

>>397
その程度の理解しかないからおまえは馬鹿なんだ。

0399デフォルトの名無しさん

2014/10/26(日) 00:19:13.15ID:ZGigf69p

>>398
なんで？deleteの代替としての自動解放と比べたらコンパクションの方が複雑な問題だと思うけど

0400デフォルトの名無しさん

2014/10/26(日) 00:27:35.56ID:USY7r1W5

そもそもコンパクションって
そんなに必要か？
余程汚いメモリの使い方しない限り
動き続けるプロセスでも
コンパクションが必要なくらいフラグメンテーションが進むなんて起こらないだろ

例え仮想アドレスが32bitだったとしても

0401デフォルトの名無しさん

2014/10/26(日) 00:38:00.18ID:ZGigf69p

まあ必要かと言われれると困るけど
汚いメモリの使い方しても断片化を解消してくれるのが有用なんじゃない？
こういう便利機能って学習コストの低減が支持されてるんだと思うし

0402デフォルトの名無しさん

2014/10/26(日) 00:46:18.18ID:GM7L1Zbe

>>393
PCの方は実はそんなに問題にならんのよ。経験則としてマメにプログラムを
終了して、帰宅時にはPC落としてというのが習慣づいているから。

問題なのがサーバー側のプログラムでweb系がカジュアルになりすぎて、
とりあえず動けばいいやっていうのと、書いているのが考えている以上に
プログラムが生存し続けてというのが2000年辺りから今まで続いてる。

それとは別に最近だとモバイル系のアプリも再起動どころかアプリを終了
するような使い方がされないから生存し続けて問題になる。モバイルは
CPU強化やメモリ盛ったりという回避策も使えない。

次はウェアラブルだのIoTだのさらにリソースが限られたものの上に作る
必要が出てくるわけで、どうなるんだろうねえって楽しみな部分でもある。

0403デフォルトの名無しさん

2014/10/26(日) 02:17:45.98ID:xfzAwmqm

ゲーム作る場合はコンパクション必要だったり
メモリ使いすぎで突然メモリ取得出来なくなってアプリが落ちるから

0404デフォルトの名無しさん

2014/10/26(日) 03:52:18.54ID:wpPYehVd

右辺値参照が有ればGC必要ないでしょ。

0405デフォルトの名無しさん

2014/10/26(日) 05:08:24.04ID:Fr1ghew1

「システムリソースが不足しています」

0406デフォルトの名無しさん

2014/10/26(日) 10:48:24.15ID:8S4QBfQC

>>402
モバイルアプリってそんなんなのか
素人に毛が生えたようなのが群がってるようだがそれで常駐する奴つくってるのか
こわいわ

0407デフォルトの名無しさん

2014/10/26(日) 10:58:16.34ID:cDCVTwSz

GCがあればメモリコンパクションは実現可能だけど、
GCがないとメモリコンパクションは不可能なんだよな。

ポインタというメモリアドレスを直接参照しているから
移動できない。

0408デフォルトの名無しさん

2014/10/26(日) 11:11:48.86ID:qbiJxD8n

コンパクションというとMacのハンドルを思い出すな。
少ないメモリを効率的に利用する工夫だったが、今じゃ移動コストが見合わんだろうな。
コピーGCと比べてどうなのかはわからんが。

0409デフォルトの名無しさん

2014/10/26(日) 11:15:49.62ID:ZGigf69p

>>407
不可能って事はないが
そもそもGCのある言語のランタイムもGCのない言語で作られてるわけで
CにもGCのライブラリあるし

0410デフォルトの名無しさん

2014/10/26(日) 11:18:01.23ID:7f0LCvPS

そもそもさ、メモリコンパクションってOSがメモリ管理しているから
不要なんじゃないの？

仮想メモリ使ってるわけで、ページ単位（4KBかな？）で
OSが物理メモリを再配置しているわけだから
コンパクションなんかしなくても適当に再配置してくれるでしょ？

もちろん4KBの範囲内はごちゃごちゃするだろうけどさ。

0411デフォルトの名無しさん

2014/10/26(日) 11:20:53.20ID:e3VIJFo+

>>409
そうだね。不可能じゃないね。
GCがなくてもメモリアドレスをハンドルで扱っているならば可能。
C/C++のようにポインタがメモリアドレスになってる場合は不可能。

0412デフォルトの名無しさん

2014/10/26(日) 11:30:10.36ID:wm4FrzeJ

>>410
キミ、議論に参加できるだけの知識を蓄えてから出直しなさい。

0413デフォルトの名無しさん

2014/10/26(日) 11:31:19.95ID:eAcs35DC

おまえもなー

0414デフォルトの名無しさん

2014/10/26(日) 11:31:43.48ID:e3VIJFo+

>>412
なにか言い返したいなら、言い返しなよ（笑）

0415デフォルトの名無しさん

2014/10/26(日) 12:18:21.71ID:CRv5XK0J

そういえば大昔のMacOSのメモリマネージャはコンパクションやってたな。

0416デフォルトの名無しさん

2014/10/26(日) 12:33:43.41ID:8S4QBfQC

>>410
OSが手を出せるのはプロセス単位でザックリ扱う時だけ

0417デフォルトの名無しさん

2014/10/26(日) 12:36:39.76ID:xfzAwmqm

>>410
細かくメモリ取得しまくるとページが足りなくなるんだが？

0418デフォルトの名無しさん

2014/10/26(日) 12:53:59.59ID:xfzAwmqm

>>415
Windowsも昔はGlobalAllocで移動可能メモリやってたね
64k個しかハンドル使えなかったが

0419デフォルトの名無しさん

2014/10/26(日) 13:02:05.04ID:wm4FrzeJ

>>414
意味わからないなら引っ込んでなよ。

0420デフォルトの名無しさん

2014/10/26(日) 13:04:44.29ID:eoLX8RNk

>>408
win16 でも globalAlloc() ではまずハンドルget だったね

0421デフォルトの名無しさん

2014/10/26(日) 13:05:55.62ID:eoLX8RNk

>>410
アプリのメモリ空間上で断片化が進むとどうしようもない

0422デフォルトの名無しさん

2014/10/26(日) 13:19:18.40ID:xfzAwmqm

>>420
win16なんてあったのか。Visual C++のバージョンはいくつだ？？

0423デフォルトの名無しさん

2014/10/26(日) 13:22:34.04ID:e3VIJFo+

>>419
言い返したいなら言い返しなよｗ

0424デフォルトの名無しさん

2014/10/26(日) 13:23:09.26ID:eAcs35DC

>>419
全く議論に参加できてないおまえが滑稽なんだけどなw

0425デフォルトの名無しさん

2014/10/26(日) 13:26:57.29ID:q8gyx8FD

>>410
そんな適当な性格で、よくプログラマーなんてやってられるなｗｗｗ

0426デフォルトの名無しさん

2014/10/26(日) 13:32:33.78ID:wm4FrzeJ

>>423
意味わからないなら引っ込んでなよ。

>>424
園児の議論に参加しろと。ｗ

0427デフォルトの名無しさん

2014/10/26(日) 13:43:51.72ID:eoLX8RNk

>>422
MS-VC++ なら 1.5 か‥
Windows3.1 の世界だね

0428デフォルトの名無しさん

2014/10/26(日) 13:51:53.99ID:xfzAwmqm

>>427
Windows3.1の頃か……ウチのマシンではまだ重かったから使って無かったな
ちなみに使い出したのはWindows95からで、Visual C++4.0だ

0429デフォルトの名無しさん

2014/10/26(日) 13:53:58.12ID:8S4QBfQC

MSVC3.0 のことも思い出してあげてください

0430デフォルトの名無しさん

2014/10/26(日) 14:07:57.66ID:xfzAwmqm

>>429
その頃はまだ大学生で、学校のTurbo C++を使ってた

0431デフォルトの名無しさん

2014/10/26(日) 14:23:21.52ID:P2vb82Ou

Win32s とか懐かしいな

0432デフォルトの名無しさん

2014/10/26(日) 14:33:57.93ID:uXBn6mUw

コンパイラは失敗。アセンブリを手で書かないとパフォーマンスが出ない！
とは言われないようになったしGCもそうなるだろ

0433デフォルトの名無しさん

2014/10/26(日) 14:48:36.61ID:xfzAwmqm

>>432
PCも進化が止まったし、まだ十年以上は大丈夫かと

0434デフォルトの名無しさん

2014/10/26(日) 15:05:00.62ID:q8gyx8FD

十年どころか、まだ三十年ぐらいは大丈夫じゃね？
画期的な概念すらまだ出てきてない事だし

0435デフォルトの名無しさん

2014/10/26(日) 15:11:16.97ID:xfzAwmqm

３０年以上か……じゃ、まだまだC++は現役だなｗｗｗ

0436デフォルトの名無しさん

2014/10/26(日) 16:01:26.94ID:eoLX8RNk

おいおい、スマートフォーンの世界を忘れちゃ困るね、いまやこっちが主戦場

0437デフォルトの名無しさん

2014/10/26(日) 16:51:35.62ID:1Oyy5cGI

WinはLFHでフラグメント起きにくくなった
そして意外と解放できないメモリはヒープじゃなく肥大化したスレッドスタックだったり

0438デフォルトの名無しさん

2014/10/26(日) 18:08:28.34ID:xfzAwmqm

えー！？自分で言語作ったりしてるけど、相変わらず断片化は起きてるよ！！
コンパイラをメモリ上だけで作り上げる場合には、未だにコンパクションは必要だ

0439デフォルトの名無しさん

2014/10/26(日) 18:11:50.30ID:xfzAwmqm

>>436
単にMicrosoftや任天堂が自爆し倒してるだけじゃん、フツーに作ればいいのにフツーに作らないから

0440デフォルトの名無しさん

2014/10/26(日) 18:33:18.76ID:xfzAwmqm

そしてフツーに作り続けられているガラケーは生き残った
数は削られたけどな！

0441デフォルトの名無しさん

2014/10/27(月) 00:07:28.86ID:26DZENrG

>>426
お前のほうが園児じゃねーかｗ

レスした以上で参加したことになる。
参加した以上、なにも言い返せないということは
他の人には、こいつ何も言い返せねーなとしか思われない。

0442デフォルトの名無しさん

2014/10/27(月) 14:22:02.63ID:ZMK2MaLm

園児と園児が必死なスレ

0443デフォルトの名無しさん

2014/10/27(月) 14:34:25.27ID:40zHC+/0

>>442
お前も参戦したのかｗ

0444デフォルトの名無しさん

2014/10/27(月) 17:01:24.37ID:JXLo76qt

ゲームならC++でnew使ってもフラグメント一切起こさない書き方あるけどな

0445デフォルトの名無しさん

2014/10/27(月) 17:21:33.63ID:LftTpzNV

べつにゲームに限らず、メモリの使い方のパターンが自分でわかってるなら色々と書きようはあるでしょ。

0446デフォルトの名無しさん

2014/10/27(月) 20:42:58.32ID:m/3fqmB1

>>444
念の為に言っておくと、フラグメントを起こす原因は
deleteであってnewじゃないぞ。

0447デフォルトの名無しさん

2014/10/27(月) 21:04:58.71ID:LftTpzNV

newが先かdeleteが先か、それが問題だ！

0448デフォルトの名無しさん

2014/10/27(月) 22:04:34.12ID:Ciot4KaL

>>441
誤他の人には、こいつ何も言い返せねーなとしか思われない。
正園児は、こいつ何も言い返せねーなと思う。

0449デフォルトの名無しさん

2014/10/28(火) 02:12:35.58ID:3/HAAYc3

園児は何も言い返せねーなｗ

0450デフォルトの名無しさん

2014/10/28(火) 02:35:26.24ID:s9KkoS5h

>>446
ばかだろお前

0451デフォルトの名無しさん

2014/10/28(火) 03:17:45.48ID:Z7Ne2Ojx

ゲームに限らず、確保した順番の逆から解放するのが基本だろ。

0452デフォルトの名無しさん

2014/10/28(火) 03:19:16.73ID:3/HAAYc3

>>450
どう見ても馬鹿はお前。
論理的に考えろよ。

0453デフォルトの名無しさん

2014/10/28(火) 06:00:06.29ID:M6wc9Z1l

一般的に言ってC++で外部断片化を気にする必要はない。

特殊な用途で外部断片化を気にする必要が有る場合、記憶管理を自分で
行えば良い。
こういった特殊な用途でGCが役に立つかといえば、それもない。
外部断片化を気にかける必要が有る用途では、GCそのものが避けられる。
なぜなら、外部断片化が気になるのは、大きな領域を頻繁にしかも大量に
取得解放する場合だから。
この用途でGCは、まさに嫌われる。

右辺値参照が一般化するとGCは時代遅れになる。

0454デフォルトの名無しさん

2014/10/28(火) 06:08:58.71ID:M6wc9Z1l

反論に対して予め答えておく。

「コピーGCでは、コンパクションが行われるので有利」

イイエ、外部断片化を避けるためにコピーを行うのはAUTOです。
外部断片化を避けなければならないのは、大きな領域を頻繁に大量に取得解放するからです。
この時コピーによるGCを行えばどうなるか想像してください。

「マークアンドスイープならコピーを行わないですむ」

その通りですが、コンパクションは行われないので、余計な仕事が増えた分、GCを
行わないほうが有利です。

「すでに両方の利点を合わせた世代別GCが主流になっている」

イイエ、この場合、両方の欠点を併せ持つことになってしまいます。
良く考えてみてください。

0455デフォルトの名無しさん

2014/10/28(火) 06:23:47.76ID:kbKKW2zh

悲鳴が心地よい

0456デフォルトの名無しさん

2014/10/28(火) 06:42:13.22ID:Ao3oXbnD

>>454
でもさ、一番重要なのはGCを使わないと
コンパクションすらできないってことだと思うんだが。

工夫すれば断片がないように出来るんです
という反論にしいする反論は
GCでも同じことをすればば断片がないように出来るんです。

0457デフォルトの名無しさん

2014/10/28(火) 06:45:07.67ID:Ao3oXbnD

×という反論にしいする反論は
○という反論にたいする反論は

まあ、一番効率がいいのは、アルゴリズムを工夫して
断片化しないようにする + それでも断片化してしまった場合に備えて
"断片化がひどい場合のみ" 断片化を解消するアルゴリズムを取り入れる。

断片化っていうのは、全部一度にする必要はないから
少しづつ移動すればいいだけだし。デフラグと一緒だね。

これが出来るのはGCがある言語だけだろう。

0458デフォルトの名無しさん

2014/10/28(火) 06:47:57.55ID:7RgMAP3p

>外部断片化を避けなければならないのは、大きな領域を頻繁に大量に取得解放するからです。

解説plz

0459デフォルトの名無しさん

2014/10/28(火) 06:51:19.60ID:M6wc9Z1l

コンパクションによって性能が上がるなら良いんだけど、現在は大幅に下がるので
ダメなんだよね。

キミが言う、コンパクションが必要な状態というのは、コンパクションを行うと
大変なことになる状態なんだよ。

GCが一番苦手とする状態を、キミは得意な状態と言っているわけ。

本を読んでるだけじゃダメってこと。

0460デフォルトの名無しさん

2014/10/28(火) 06:51:34.45ID:Ao3oXbnD

あと、OS自体もメモリコンパクション機能は持っているわけで、
大きい領域はOSに処理させればいいんじゃないかな。

http://e-words.jp/w/E383A1E383A2E383AAE382B3E383B3E38391E382AFE382B7E383A7E383B3.html
> OSや言語処理系などが持つ機能の一つで、メモリ(メインメモリ、主記憶装置)上の
> 空き領域の断片化を解消し、連続した広い空き領域に再編すること。

ようするに、32bitアプリの1プロセス4GB（2GB？）のメモリ空間で
断片化して使われない領域は、未割り当てにしてしまえばいいのよ。
あ、大きい領域の話ね。

そうすれば見かけ上は断片化してはいるけど、物理メモリは使用しておらず、
新しく確保するメモリは、後方部分を使うようにすれば何も問題なくなる。

俺程度が思いつくことなんだから、これぐらいやってると思うけどね。

0461デフォルトの名無しさん

2014/10/28(火) 06:53:19.24ID:Ao3oXbnD

>>459
いや、だから君がGCが一番苦手といっていることは、
GCじゃなくても苦手でしょって話なんだが？

どちらにしろ苦手な問題であり、
GCは解決法が存在するが
GCじゃないと解決法すら存在しない
ってことを言ってるんだが。

0462デフォルトの名無しさん

2014/10/28(火) 06:54:00.18ID:M6wc9Z1l

>>460
そうだよ。
だからGCはすでに時代遅れで、負債になってる。
一般的な常識としてそういう認識になってるよ。

0463デフォルトの名無しさん

2014/10/28(火) 06:55:06.31ID:Ao3oXbnD

>>462
GCの話関係ないじゃん？

コンパクションが時代遅れだっていうのならわかるけどさ。

どうもGCが大嫌いで、GCをたたければ
いいみたいな考え方してるな。

0464デフォルトの名無しさん

2014/10/28(火) 06:55:58.00ID:M6wc9Z1l

>>461
コンパクションがどうしても必要ならコンパクションを行えば良いんだよ。
本当にどうしても必要ならね。
GCは必要ない。

そして、C++はそこまで考えられている。

0465書き込み過ぎって出たからID変更

2014/10/28(火) 06:57:46.05ID:ToB9HJEu

>>464
繰り返すけど、GC関係ないよね？

C++だってメモリの断片化は起きる。

断片化を極力しない方法をとっていると言うのなら
それはGCを使っていても同じ方法が取り入れられる。

0466デフォルトの名無しさん

2014/10/28(火) 06:59:06.98ID:M6wc9Z1l

>>463
GCが嫌いじゃなくて、必要ないと考えてるんだよ。

そもそも、JavaなどにGCが付いてるのは、GCが素晴らしいからではないんだよ。
オブジェクトのコピー回避のために無駄を承知で付けてる。

ところが右辺値参照で解決してしまった。

それでGCは無駄と考えてる。
いずれなくなるだろね。

0467デフォルトの名無しさん

2014/10/28(火) 07:00:45.88ID:ToB9HJEu

C++は断片化しないように

・あらかじめメモリを大量に確保し・・・それGCでもできるよね？
・なるべくメモリ領域を解放しな・・・それGCでもできるよね？
・独自の高度なメモリ管理アルゴ・・・それGCでもできるよね？
・OSに一部のコンパクションをゆだね・・・それGCでもできるよね？
・超スーパーミラクルなてくに・・・それGCでもできるよね？

こういう話なんだが。

0468デフォルトの名無しさん

2014/10/28(火) 07:01:00.77ID:M6wc9Z1l

>>465
コンパクションは絶対に必要だからGCは絶対必要という人が多かったので
コンパクションについて説明してる。

俺は、GCが時代遅れと主張してる。
GC関係ないどころか、コンパクションの方がおまけ。

0469デフォルトの名無しさん

2014/10/28(火) 07:03:23.40ID:ToB9HJEu

>>466
必要ないの理由がおかしい。

メモリコンパクションというのは今となって
は無駄だっていうのはまあいいよ。
そんなに反論しない。

でもGCの目的はメモリコンパクションのためではなく
プログラマの負担を減らすため。

あんたの論理は、元から必要ないものを持ってきて
GCは必要ないと言っているだけ。
まったくもって的はずれなんだよ。

0470デフォルトの名無しさん

2014/10/28(火) 07:03:40.81ID:M6wc9Z1l

>>467

ぜんぶ、「その結果どうなりますか？」と言われたら、合理的な答えが無いでしょう。

「GCに頼らないほうが合理的だよね」って話。

「時間はかかるけどGCでもできる」→「じゃあ何のためにGC使うの？」

0471デフォルトの名無しさん

2014/10/28(火) 07:03:43.04ID:4+xiP14a

>>451
ならスタックでいいじゃん
そういうことできないからヒープ使うんだし

0472デフォルトの名無しさん

2014/10/28(火) 07:04:09.05ID:ToB9HJEu

>>468
じゃあプログラマの負担を減らすためにGCは必要って
話に変えようか？

それなら反論できそうもなさそうだしねｗ

0473デフォルトの名無しさん

2014/10/28(火) 07:04:39.42ID:ToB9HJEu

>>470
> 「時間はかかるけどGCでもできる」→「じゃあ何のためにGC使うの？」

プログラマの負担を減らすために決まってるじゃんｗ

0474デフォルトの名無しさん

2014/10/28(火) 07:06:52.17ID:M6wc9Z1l

>>469
理由は、本来GCが必要になった理由が、右辺値参照によって無くなったから。

もうGCの出番なくなった。
ホントにGCの必要性を全く感じない。

GCが無い言語と言えばC/C++が代表的だけど、Javaに出来てC/C++に出来ないことが
無いんだよね。
これ、GC必要ないってことでしょ。
逆にC/C++に出来てJavaに出来ないことは沢山あるでしょ。

0475ID略

2014/10/28(火) 07:07:00.51ID:9gCJT/mD

だいたいソフトウェアの進化って
遅くなる方法を取りながら（例低級言語 → 高級言語、手続き型 → オブジェクト指向）
プログラマの負担をコンピュータに肩代わりさせることで
進化してるんだけどね。

0476デフォルトの名無しさん

2014/10/28(火) 07:07:48.72ID:6AxRmH6y

>>474
> 理由は、本来GCが必要になった理由が、右辺値参照によって無くなったから。

無くなっていない。
一部の問題を解決したに過ぎない。

0477デフォルトの名無しさん

2014/10/28(火) 07:08:54.87ID:M6wc9Z1l

>>473
右辺値参照ができたおかげで、プログラマの負担も変わらないどころか、
GCのせいで増えてるよ。
たとえばRAIIで不利になるとか。

RAIIに忠実に、右辺値参照を使う。
これでずいぶん楽になる。

0478デフォルトの名無しさん

2014/10/28(火) 07:10:10.95ID:Il6Rm78K

右辺値参照ができたおかげで、プログラマの脳内負担は
ますます増えてしまってるからな。

右辺値参照はC++の最悪な機能の一つだわｗ

0479デフォルトの名無しさん

2014/10/28(火) 07:11:02.84ID:7RgMAP3p

RAIIが一般的な手法として使われる2つの言語のうち、一つはGCを搭載しているのじゃ

0480デフォルトの名無しさん

2014/10/28(火) 07:11:10.86ID:M6wc9Z1l

>>460
やってるどころか、コンパクションが必要になる状態なんてほとんどないよ。

0481デフォルトの名無しさん

2014/10/28(火) 07:14:31.69ID:M6wc9Z1l

右辺値参照は大変簡単な仕組み。
脳内負担なんて全く増えない。

今まで出てこなかったのが不思議なくらい。

実際使ってみれば目から鱗。
こんな簡単な仕組みですべての問題が片付く。

Java作った人も、GC搭載しないで右辺値参照を思いつけば天才だったのにね。

0482デフォルトの名無しさん

2014/10/28(火) 07:21:40.56ID:M6wc9Z1l

Lispのような化石は仕方ないけどね。
だって化石だから。

JavaにGC搭載したのは悔やまれるなあ。

0483デフォルトの名無しさん

2014/10/28(火) 07:22:17.95ID:rq2ADtmO

右辺値参照の一番の問題は概念が難しくて
誰も正しく使えないってことだな。

このせいで新たなバグが増えることになる。
バグを減らすための機能が、余計に複雑な機構を作ってしまい、
更にバグが増えることになるなるわけさアハハハ

0484デフォルトの名無しさん

2014/10/28(火) 07:25:07.81ID:xnfqHYph

生産性という点で見れば、GCなんかよりも
ずっと大きな問題をC++は含んでいるからね。

誰がどう見てもC++はシンプルな言語じゃない。
プログラマに負担をかける言語。
そのせいで生産性が大きく下がってしまっている。

0485デフォルトの名無しさん

2014/10/28(火) 07:27:34.40ID:M6wc9Z1l

>>484
C++11、14でずいぶん楽になった。
これもうスクリプト言語とかいらないっしょ。

スクリプト言語の欲しかったあの機能。
全部入ったから。

Lispの欲しかった機能？ないよ？
だって化石だし。

0486デフォルトの名無しさん

2014/10/28(火) 07:35:13.84ID:xnfqHYph

C++は生産性が低い。これは100人、人がいたら99人は同意するだろう。

C++はほんの僅かなメモリや速度を追求するために生産性を下げてる。
GCも生産性を上げるための機能の一つである、GCがない言語は生産性が低い。

GCがなくても出来る。ただし生産性は下がるけどね。
この考え方はもはや世の中には不要なものなんだよ。
メモリコンパクションと同じようにね。

0487デフォルトの名無しさん

2014/10/28(火) 07:35:36.46ID:M6wc9Z1l

GC搭載の言語は先見の明が無かったんだろね。

安易な方向に走った。
そのツケをこれから支払う。

0488デフォルトの名無しさん

2014/10/28(火) 07:41:34.64ID:M6wc9Z1l

>>486
C/C++は生産性が高い。

GC搭載言語のユーザーはC/C++で書かれたライブラリやAPIを呼び出してるだけ。
それを生産性が高いと勘違いしてはいけない。

C/C++は、C/C++で書かれたAPIやライブラリの呼び出しが難しいか？
否！
楽勝である。

GC搭載言語は、C/C++が使われるような複雑なコードを書くのに向いていないのである。
たしかに、C/C++は複雑で難解なアルゴリズムのために使われる。
だからといって、簡単なものしか書けないことを生産性が高いと勘違いしてはいけない。

0489デフォルトの名無しさん

2014/10/28(火) 07:42:30.24ID:xnfqHYph

http://postd.cc/the-best-programming-language-or-how-to-stop-worrying-and-love-the-code/

モンスターです。私が初めて習得した言語だったので、他の多くの言語を試してみるまで、
C++を使うと開発者の生産性が下がり、能力が制限されるという事実に気がつきませんでした。
C++の悪評は有名なプログラマたちによって広まっていますが、私もまったく同感です。
まるでビャーネ・ストロヴストルップが思いつくままに一つまた一つと機能をC言語に追加していったら
できあがってしまった代物のように見えます。C++に課されたコードの読みにくさは、
開発者の生産性を80パーセント以上低下させると言っていいでしょう。次のように考えてみてください。
あなたは容量Xの脳を持っています。どのくらいの容量かということは別にして容量には限りがあるため、
あなたはできる限り多くの容量を重要な事柄のために使いたいと思っています。こうした場合、
言語“それ自体”のために消費するエネルギーを減らし、問題解決やアルゴリズムのエンコードに
脳の大部分を使うのが賢明でしょう。言語が複雑な場合、あなたがどんなに賢くても、言語のシンタックスや
セマンティクスに多くの容量を使うことになり、自分の考えを効率的に反映するための容量は少なくなります。

C++は、得るものが少ない割に複雑すぎる言語の典型です。確かにC言語で大規模なプログラムを構築するのは
難しいと思います（ただし間違いなく選択肢の一つではあります。Linuxカーネルを見てください）。
C++が実際に世界中で使われているという事実を除けば、GoやRust、Dの方があらゆる点で優れています。

0490デフォルトの名無しさん

2014/10/28(火) 07:44:56.88ID:M6wc9Z1l

Lispは仕方ないと思います。
化石には化石の生き方が有るから。

0491デフォルトの名無しさん

2014/10/28(火) 07:48:18.73ID:M6wc9Z1l

例えば「UIはJSで書けばいいじゃん？」

イイエ、そのJSが走るブラウザはC/C++で書かれています。
JSの実力と勘違いしないでください。

すべてこの調子。

簡単なものしか書けないことを「簡単に使える言語」とか言わないでください。
バカだと思われますよ？

0492デフォルトの名無しさん

2014/10/28(火) 09:04:42.48ID:RUl4+6uO

ID:M6wc9Z1lはすごく正しい

0493デフォルトの名無しさん

2014/10/28(火) 09:08:05.97ID:RUl4+6uO

いやまてよ
簡単なものを書くなら簡単に書ける言語で書いたほうがいい
ID:M6wc9Z1lは間違ってる。騙されるところだった。

0494デフォルトの名無しさん

2014/10/28(火) 09:28:20.08ID:bWqS4im1

結局、GCで書こうが使わずに書こうがその道を選択したことでそれぞれコストはかかる、それを許容できるかどうか
って話を…なぜお前らはこんなに時間をかけるんだｗｗｗ

0495デフォルトの名無しさん

2014/10/28(火) 09:40:16.28ID:Vwqyi7SI

メモリ管理が重要な目的ならC++なり使って最高の効率を目指せばいいし、
そうじゃないならメモリ管理の事は処理系にまかせて忘れちゃえばいいのだ。

0496デフォルトの名無しさん

2014/10/28(火) 12:18:24.54ID:TlJSw6K8

メモリ管理は遅いマシンでも処理速度を維持するための重要なキーだからな～

0497デフォルトの名無しさん

2014/10/28(火) 13:06:43.85ID:/Y9XnqU0

>>485
shebang

0498デフォルトの名無しさん

2014/10/28(火) 13:24:12.62ID:7D4H9npv

アプリから見て無限に見えるメモリがあれば良いんだよ

0499デフォルトの名無しさん

2014/10/28(火) 13:24:36.45ID:Vwqyi7SI

それはおかしい

0500デフォルトの名無しさん

2014/10/28(火) 13:25:18.17ID:Vwqyi7SI

ごめん>>497に対して

0501デフォルトの名無しさん

2014/10/28(火) 14:54:03.32ID:Z7Ne2Ojx

>>471
スタック領域の利用用途しってての発言か？
全部pushしろと？

0502デフォルトの名無しさん

2014/10/28(火) 17:35:23.93ID:s98vcxYO

>>501
> 確保した順番の逆から解放する

なら、スタックで充分だろ。
なにか、問題あるのか？

0503デフォルトの名無しさん

2014/10/28(火) 18:19:51.14ID:ZFLQwBg+

スタックと言われてESPでポイントされるアレしか連想できない園児なんだろ。ｗ

0504デフォルトの名無しさん

2014/10/28(火) 19:03:33.25ID:uvfLqTRT

>>460
アプリケーションのメモリ空間のコンパクションはOSではできない

0505デフォルトの名無しさん

2014/10/28(火) 19:05:22.52ID:uvfLqTRT

>>474
残念ながら move semantics で解決できる問題はごくわずか

0506デフォルトの名無しさん

2014/10/28(火) 19:06:24.78ID:uvfLqTRT

>>482
GC 搭載で OO がやさしくなった

0507デフォルトの名無しさん

2014/10/28(火) 20:39:36.85ID:XjbWXaTq

コンパクションだのヒープ不足だのはGC以前にシステム全体の
設計が悪いって話だから。

0508デフォルトの名無しさん

2014/10/28(火) 20:56:49.18ID:vS3GoyWK

GC「なんでもかんでも僕のせいにするんだから」

0509デフォルトの名無しさん

2014/10/28(火) 21:08:37.92ID:uEWDfUej

つまりGCそのものは素晴らしくないが、GCがあるということは素晴らしい

0510デフォルトの名無しさん

2014/10/28(火) 22:04:00.08ID:uvfLqTRT

>>507
「システム」って具体的にどんな要素のこと？
単にメモリが足りないとか物量の問題か？
スマフォ、ときどき再起動せないかへんのは、やっぱり根本的にメモリまわりがまずいんじゃない？

0511デフォルトの名無しさん

2014/10/28(火) 22:12:32.64ID:s98vcxYO

>>505
解決できない問題ってなに？

0512デフォルトの名無しさん

2014/10/28(火) 22:13:31.68ID:Vwqyi7SI

スマホってときどき再起動が必要になるもんなのか。知らんかった...

0513デフォルトの名無しさん

2014/10/28(火) 22:58:45.72ID:uvfLqTRT

>>511
循環参照

0514デフォルトの名無しさん

2014/10/28(火) 23:10:00.30ID:4+xiP14a

>>513
なるほど、それだけ？

0515デフォルトの名無しさん

2014/10/28(火) 23:15:37.40ID:uvfLqTRT

>>514
これはでかいよ

0516デフォルトの名無しさん

2014/10/29(水) 00:06:54.03ID:xqvbqTHV

>>515
いや、解決できる問題はごくわずか = 問題たくさん残ってるよーじゃないのかと

0517デフォルトの名無しさん

2014/10/29(水) 00:31:47.75ID:ITcKex6d

>>516
だから循環参照はでかい問題かと

0518デフォルトの名無しさん

2014/10/29(水) 07:08:27.89ID:ITcKex6d

>>512
カメラ用途で使いまくっていると特にね

0519デフォルトの名無しさん

2014/10/29(水) 08:35:44.27ID:dRVXcUto

>>512
俺のスマホなんて、自動再起動機能付きだぜ

まともなスマホが欲しいわ w
2chMate 0.8.6.16 dev/PANASONIC/P-01D/2.3.4/LT

0520デフォルトの名無しさん

2014/10/29(水) 13:04:45.01ID:V4b3gVoX

staticに参照渡すだけの簡単なテロ

0521デフォルトの名無しさん

2014/10/29(水) 14:16:22.97ID:+dOdWCkt

循環参照で問題になるならリンクリスト方式のスマートポインタ使えばいいじゃない。遅いらしいけど。

>>500
どこがおかしいんだよ。

0522デフォルトの名無しさん

2014/10/29(水) 14:59:43.12ID:HBXTyN9+

>>521
shebangてスクリプト言語の機能じゃないもの

0523デフォルトの名無しさん

2014/10/29(水) 18:49:35.61ID:ITcKex6d

>>521
＞リンクリスト方式のスマートポインタ
なにそれ？

0524デフォルトの名無しさん

2014/10/30(木) 07:23:06.33ID:Yy7uGwo0

>>522
うん、あれ実はUnix系OSに組み込まれてる機能なんだよねw
環境によっちゃ処理系やシェルでシミュレートしてるかも知れんが

0525デフォルトの名無しさん

2014/10/30(木) 07:26:21.79ID:Yy7uGwo0

『右辺値参照』さんはC++以外にどんな言語を使ってるんですか？

0526デフォルトの名無しさん

2014/10/30(木) 22:02:47.37ID:sL615/A1

501 名前：デフォルトの名無しさん投稿日：2014/10/28(火) 14:54:03.32 ID:Z7Ne2Ojx
>>471
スタック領域の利用用途しってての発言か？
全部pushしろと？

まとまった領域を確保したい場合はSP(ESP)レジスタを直接いじる
SP(スタックポインタ)レジスタはその名の通りポインタなんだけど
このレジスタだけ変更してもそのまま使ってしてしまうとページフォルト例外が発生する
それを避けるために最小ページサイズ(Win32だと4KB)毎にアクセスして
OSに使用ページサイズを申告する処理を入れていく
ヒープとして確保する領域も内部的には同様の処理が入る

0527デフォルトの名無しさん

2014/10/30(木) 22:06:05.80ID:sL615/A1

んで、この辺の事情って64bitでも同じなのかな
スタックに置けるならそれが一番良いよ

0528デフォルトの名無しさん

2014/10/30(木) 22:44:20.26ID:7fc6WtHX

>>526
>>503 の意味理解できてるか？
ソフトウェアスタックとか聞いたことないかな？

それはさておき、ネタで書いてるならいいけど
> それを避けるために最小ページサイズ(Win32だと4KB)毎にアクセスして
を、マジで書いてるなら、仮想記憶の仕組みについてちゃんと勉強した方がいいぞ
そもそも避けるための 4KB の最初のアクセスで例外が発生するだろうし w

0529デフォルトの名無しさん

2014/10/30(木) 23:03:05.76ID:sL615/A1

ソフトウェアスタックって何？ヒープの話？
そんなん想定してなかったから退散するよ
続けてどうぞ

0530デフォルトの名無しさん

2014/10/31(金) 00:02:07.95ID:v3TvpUXW

>>528
スタックの自動拡張知ってるオレってスゲーだろと言いたい園児なんだろ。

>>529
>>471はデータ構造としてのスタック(FIFO)の事だ。

0531デフォルトの名無しさん

2014/10/31(金) 00:17:25.08ID:H/kqMfAT

スタックと聞いて ESP とかのハードウェアしか思い付かないのもどうかと思うし、>>471 はソフトスタック/ハードスタック関係ないんだけどな
まあ、退散するやつを追いかけてもしょうがないやね

0532デフォルトの名無しさん

2014/10/31(金) 00:20:41.87ID:ZMC8RAdu

>>530
スタックはLIFOかと…

0533デフォルトの名無しさん

2014/10/31(金) 00:21:33.04ID:v3TvpUXW

>>532
そうだね。

0534デフォルトの名無しさん

2014/10/31(金) 01:44:34.60ID:fvAGO10b

ふつうに alloca() 使うのはだめなのか？

0535デフォルトの名無しさん

2014/10/31(金) 02:14:46.46ID:v3TvpUXW

うん、ダメ。引っ込んでなよ。

0536デフォルトの名無しさん

2014/10/31(金) 08:54:45.93ID:0bCoK9DA

スタック論者はデータのライフサイクルを想定できない情弱

0537デフォルトの名無しさん

2014/10/31(金) 10:13:07.22ID:L7CxOLNK

スタックは凄く強力だがどのような制約になるか理解できない人間が多い

0538デフォルトの名無しさん

2014/10/31(金) 12:27:44.04ID:ugmQtoGq

>>537
貴様とはいい酒が呑めそうだ。///

0539デフォルトの名無しさん

2014/10/31(金) 12:54:13.95ID:oTQQqA0M

>>537
お前だけじゃね？

0540デフォルトの名無しさん

2014/10/31(金) 13:00:54.88ID:yvXaR7Ss

なにを議論してるのか誰かまとめてw

0541デフォルトの名無しさん

2014/10/31(金) 13:04:33.32ID:9+j1ATQW

うまい酒の話だろ。

0542デフォルトの名無しさん

2014/10/31(金) 13:40:17.20ID:v3TvpUXW

スタック使えば良いは↓をからかっただけだろ。

>>451
>ゲームに限らず、確保した順番の逆から解放するのが基本だろ。

0543デフォルトの名無しさん

2014/10/31(金) 14:04:07.93ID:MCSU0wv9

は？

0544デフォルトの名無しさん

2014/10/31(金) 16:36:35.18ID:lZPBQQs6

>>522
あっそう。じゃインタプリタ。

0545デフォルトの名無しさん

2014/10/31(金) 16:43:28.62ID:yvXaR7Ss

>>544
OSがプログラムを起動する機能の一部だよ。

0546デフォルトの名無しさん

2014/10/31(金) 18:28:13.64ID:Qf4uHoUl

GCなんてメモリ管理が出来る人には必要ないって事だろ

0547デフォルトの名無しさん

2014/10/31(金) 18:40:57.50ID:fvAGO10b

>>535
なんでだめなんだよーFIFO（爆笑）じゃないからかよー

0548デフォルトの名無しさん

2014/10/31(金) 19:55:07.03ID:oTQQqA0M

>>542
からかったつーか、それができるならヒープなんざ使わなくてもいいから、GC なんかも要らんだろ？
って言う意味で書いたら、全部 Push しろとか、4KB 毎に云々とかワケわからん話になっただけ

0549デフォルトの名無しさん

2014/10/31(金) 21:58:25.90ID:2rsPywEm

windowsのメモリ空間の状態にはnot usedとreservedとcommitがあって
スタック内の離れたところはreservedになってるから
使うためには一旦(致命的でない)page faultを発生させて
reservedからcommitに変えてやる必要があるって話

0550デフォルトの名無しさん

2014/10/31(金) 22:29:55.87ID:H1o0XsxM

そんなことユーザのAPができんのかよ

0551デフォルトの名無しさん

2014/10/31(金) 23:27:03.40ID:mPjKzzHZ

できる。
もう少しlibcやcrt嫁

0552デフォルトの名無しさん

2014/10/31(金) 23:55:39.62ID:BnCuqoHL

それってx86の…仮想記憶回りのなんとかかんとか

0553デフォルトの名無しさん

2014/11/01(土) 01:47:44.14ID:xo0hFZXQ

>>549

>>530
>スタックの自動拡張知ってるオレってスゲーだろと言いたい園児なんだろ。

0554デフォルトの名無しさん

2014/11/01(土) 07:48:11.12ID:yfMW+WpF

そもそも Windows ってスタック自動拡張しないし
中途半端に理解した気になってるアホとしか思えない

0555デフォルトの名無しさん

2014/11/01(土) 09:26:31.81ID:8KfJEHPC

ttp://mag.matrix.jp/mag/queen/log/soft/eid81.html

>Windowsではスレッドのスタックは最初２ページだけメモリが確保されて，その後はガードページに当たるたびに自動拡張されて最大サイズまで広がるようになっている．

>Windows 2000までは最大スタックサイズはプロセスで全て同じ．
>XPではCreateThreadでスレッド毎に最大サイズを設定できるようになっている．

0556デフォルトの名無しさん

2014/11/01(土) 13:40:45.17ID:zs4Qkwfw

スタックは便利だし食い潰すほど使うものでもない

0557デフォルトの名無しさん

2014/11/01(土) 13:47:42.98ID:hdcrWs+g

GCは失敗だって言ってる奴が
GCいらない。スタック使えばいい
スタックなんてメインメモリがあるかぎり使えるって流れ

0558デフォルトの名無しさん

2014/11/01(土) 14:03:22.97ID:EqQEUY92

じゃあforth使えばいいんじゃね

0559デフォルトの名無しさん

2014/11/01(土) 14:14:54.54ID:iHNVy8d7

ばかばっか

0560デフォルトの名無しさん

2014/11/01(土) 14:22:43.32ID:G6fogZA9

スタックなんて不要になった変数領域でも
関数を抜けるまで解放されないから
ある意味GCよりガバガバやんけ

0561デフォルトの名無しさん

2014/11/01(土) 16:46:34.16ID:TgOtBrGZ

>>560
そんなことは無いけどね。

0562デフォルトの名無しさん

2014/11/01(土) 16:52:18.72ID:D3G7iSJM

Cだとブロックを跨いで戻ってくる可能性が無ければ消せるし、データフロー解析でレジスタにしか
存在しない変数とかもありうるけど、まぁ何を言っても無駄な奴には無駄だな。

0563デフォルトの名無しさん

2014/11/01(土) 18:36:35.79ID:zs4Qkwfw

スコープを抜けるまで開放されないのであって、関数ではない。関数も一つのスコープだが

0564デフォルトの名無しさん

2014/11/01(土) 18:56:56.91ID:yfMW+WpF

>>563
実際に解放するかどうかはコンパイラとか設定によるけどな

0565デフォルトの名無しさん

2014/11/01(土) 19:45:29.81ID:BL3FCvnE

自動変数は確保とか解放って概念ではないと思うんだけど。

0566デフォルトの名無しさん

2014/11/01(土) 19:57:37.83ID:kdzKFYUV

スコープって、｛｝で囲っておくと｛｝の外にでる時に寿命がくる事？

0567デフォルトの名無しさん

2014/11/01(土) 19:58:16.62ID:TgOtBrGZ

デストラクタの動作が有るのでスコープは重要だけどね。

GCに依存する言語使ってると意識することが無いので>>560のような誤解が生まれる。
まあそれは良いと思う。
動けば良いジャンルもあるから。

とはいえ、上から目線で「お前らはGCより雑魚なんだじぇじぇじぇ」とか
言ってくるのがなんだかなあて感じ。

GCは既に過去の技術だよ。

0568デフォルトの名無しさん

2014/11/01(土) 20:04:46.36ID:TgOtBrGZ

GCはソフトウェアの構造化について、決定的な弱点があると思う。

これはもうちょっと議論したほうが良い。

将来はGCを完全に無くすべきだと思う。

0569デフォルトの名無しさん

2014/11/01(土) 20:08:05.55ID:hs3boz8Y

GCをなくして、GCありと同じコードで
動くようになるならな。

複雑なコードを書いて、ほらGCいらないんです。
って言っても何の説得力もない。

0570デフォルトの名無しさん

2014/11/01(土) 20:10:04.62ID:n3qiU1JI

GCを使わない技術があったとして
でもそれは内部の話だから、
言語仕様は全く同じまま実現できるはずだよ。

0571デフォルトの名無しさん

2014/11/01(土) 20:20:38.73ID:etXlBO/A

開放したつもりのオブジェクトをその気になれば参照できちゃう仕組みが残ってるのはまずい
アプリケーションエラーで落ちまくるのは大抵中身がC++
リソースを掴みっぱなしでシステムごと落とすのは大抵GC使用言語
どっちがいいかな

0572デフォルトの名無しさん

2014/11/01(土) 20:36:37.55ID:g3m3cPJS

>>498

そもそもGCって見かけ上 >>498 みたいな世界をしようとするものであって、
後始末が必要なリソースの管理をさせようってのが間違ってるんじゃないの？

0573デフォルトの名無しさん

2014/11/01(土) 20:36:59.72ID:n3qiU1JI

>>571
GCありでリソースを掴みっぱなしにするようなコードを
同じようにC++で書いたら同じ用にリソース掴みっぱなしになると思うけど？

それ以上にアプリケーションエラーで落ちまくるのが
頻発しているから、あまり話題にならないんだろうね。

0574デフォルトの名無しさん

2014/11/01(土) 20:37:35.82ID:g3m3cPJS

あ、余計なアンカーが入ったw

0575デフォルトの名無しさん

2014/11/01(土) 20:40:36.00ID:etXlBO/A

>>573
そうだね
じゃあGCは成功でいいんじゃない？

0576デフォルトの名無しさん

2014/11/01(土) 20:44:19.65ID:n3qiU1JI

「GCの成功」っていう意味を勘違いしている人が多い気がする。
メモリ管理から人間が解放されたっていう意味もあるけど、

もう一つ重要なのは「シンプルかつ直感的なコードで」
メモリ管理から解放されたことがとても重要な事なんだよ。

メモリ管理から解放されるためにいろんなことを考えなきゃいけない言語はダメ。

0577デフォルトの名無しさん

2014/11/01(土) 20:46:09.79ID:4gtQH+KV

>>551
>もう少しlibcやcrt嫁
windows（大爆笑）

0578デフォルトの名無しさん

2014/11/01(土) 20:55:07.98ID:qo22BqRg

>>577
？

0579デフォルトの名無しさん

2014/11/01(土) 20:57:50.03ID:mUvqqgtr

システムプログラミングではC++のデストラクタや例外はゴミ過ぎて論外だし、
アプリケーションプログラミングではGCのある言語を使うべきって言ったのは
Linusだっけ？

0580デフォルトの名無しさん

2014/11/01(土) 21:06:23.49ID:n3qiU1JI

C++は3Dゲーム用途だろ？

あと何年かは、ハードウェア性能を極限まで
引き出すことが3Dゲームの魅力につながる時代が続くだろうし。

0581デフォルトの名無しさん

2014/11/01(土) 21:24:13.04ID:TgOtBrGZ

>>570
それは勉強したほうが良いんじゃないかな。
もうちょっと理解を深めてから議論に参加しないと、ただの荒らしになってる。

0582デフォルトの名無しさん

2014/11/01(土) 21:26:03.49ID:n3qiU1JI

>>581
つまり、言語仕様を変えないとGCは使えないってことだよね？

それじゃだめだろう。
GCありの言語はシンプルだよ。

function foo() {
　var obj = new Object;
}

これだけのシンプルな言語仕様でGCは発動する。

これを変えないと実現できないということは
今よりも言語仕様が複雑になるということ。

それじゃ人間にとってやさしくない。

0583デフォルトの名無しさん

2014/11/01(土) 21:33:18.47ID:TgOtBrGZ

>>582
GCを前提にした言語では、例えば右辺値参照などは実現できない。

0584デフォルトの名無しさん

2014/11/01(土) 21:36:02.69ID:n3qiU1JI

>>583
考え方がコンピュータよりになってないか？

まず、人間にとって優しいかどうか？
現代のプログラム言語はこれを第一に考えないとだめだ。

ここまではわかるよね？

右辺値参照が目的じゃないんだ。
どんな技術を使うかは関係ない。

その技術を直感的でシンプルに書ける言語が素晴らしい言語。
ちょっと前までは速い言語が素晴らしい言語という定義だったが
その時代はもう終わったんだよ。一部（3Dゲームぐらい）しか生き残ってない。

0585デフォルトの名無しさん

2014/11/01(土) 21:39:03.51ID:TgOtBrGZ

>>584
右辺値参照は設計をシンプルにする。

GCはOOPと決定的に親和性を欠く。

0586デフォルトの名無しさん

2014/11/01(土) 21:43:20.36ID:n3qiU1JI

>>585
それじゃ、右辺値参照を使ったコードと
右辺値参照が使えるクラスの両方を
ここに書いてくれない？

同じようにGCがある言語（JavaScript）で書くからさ

GCが使えるクラス

function Klass() {
　　this.value = 1;
}
Klass.prototype.bar = function() {}

GCを使ったコード
function foo() {
　var obj = new Klass;
}

0587デフォルトの名無しさん

2014/11/01(土) 21:48:49.07ID:TgOtBrGZ

>>586
右辺値と左辺値は別のものである。
ここがわかっていない。

これを区別できないなら、右辺値参照を実装しているとは言えない。

もうちょっと勉強してから書き込まないと、ただの荒らしにしかならない。

0588デフォルトの名無しさん

2014/11/01(土) 21:50:14.65ID:TgOtBrGZ

もう一つ議論の前提として言いたいのは、JavaがGCを使っているのは性能のためだと思う。

ここら辺もわかっていないと議論にならない。

0589デフォルトの名無しさん

2014/11/01(土) 21:56:25.26ID:n3qiU1JI

>>587
能書きはいいからコードを書けよ。

あんたが今やることはコードを書くことだけだ。

0590デフォルトの名無しさん

2014/11/01(土) 21:58:15.27ID:n3qiU1JI

>>587
俺は右辺値参照を実現しているコードを書いてるって言ってないんだよ。

スレタイ見ろ。GCの話だ。

だからGCが使われるシンプルなコードを書いた。
GCを使わないで同じことが実現できると
主張したいなら、

それを見事、右辺値参照でも使って
書いてみせろって言ってるだけ。

0591デフォルトの名無しさん

2014/11/01(土) 22:03:34.80ID:TgOtBrGZ

>>590
右辺値参照を実装している言語はC++だけど、C++では見かけ上、何も変わらない。

もうちょっと勉強しないと議論にならないと思う。
タダの荒らしにしかなっていない。

0592デフォルトの名無しさん

2014/11/01(土) 22:07:18.95ID:yfMW+WpF

>>586
そのコード何ら意味のあることしてないから、コードなんてイランやろ w

0593デフォルトの名無しさん

2014/11/01(土) 22:09:59.59ID:TgOtBrGZ

GCは完全に時代遅れ。

0594デフォルトの名無しさん

2014/11/01(土) 22:11:33.52ID:n3qiU1JI

>>591
だからコードを書けって。
何度も言わせるな。

0595デフォルトの名無しさん

2014/11/01(土) 22:17:47.93ID:TgOtBrGZ

プリミティブをメンバに持つシンプルなクラスにとってGCは完全にオーバースペック。

この例で何を示したいのかが良くわからない。

右辺値参照以前に、コピーでまったく問題が起こらないので、この例は
GCがいかにダメかを示すものになるはず。

実のところ、GC前提の言語もろくに使ったことが無いのではないだろうか。

0596デフォルトの名無しさん

2014/11/01(土) 22:19:26.67ID:n3qiU1JI

コード書かないで言い訳ばかり。
さあ、いつまでにげるのかｗ

0597デフォルトの名無しさん

2014/11/01(土) 22:23:51.62ID:TgOtBrGZ

>>594
書くのは良いのだけど、この例では、デフォルトのコピーコンストラクタを
使うことになるはず。
つまり、コンストラクタを書かない。

右辺値参照以前に、GCがなぜ必要とされたのかも、わかっていないのではなかろうか。

もうちょっと勉強してから書きこまないと、荒らしにしかならない。

0598デフォルトの名無しさん

2014/11/01(土) 22:25:28.73ID:n3qiU1JI

> 書くのは良いのだけど

じゃあ書けよ。

ほんと言い訳がましいやつだな。

0599デフォルトの名無しさん

2014/11/01(土) 22:27:27.21ID:TgOtBrGZ

>>596

struct A
{
　　val = 1;
};

A a;

これに何の意味が有る？

0600デフォルトの名無しさん

2014/11/01(土) 22:29:08.69ID:n3qiU1JI

>>599
うん、やっと話がスタートしたね。

じゃあ、それを君が意味があると思うコードにしてみて。

右辺値参照があればーと言っているわけだから
右辺値参照を使うコードにするということ。

0601デフォルトの名無しさん

2014/11/01(土) 22:33:00.87ID:TgOtBrGZ

>>600
これは既に右辺値参照を扱えるのだけど。

ホントにキミ、荒らしにしかなっていない。

0602デフォルトの名無しさん

2014/11/01(土) 22:40:38.98ID:QNLi3TDU

スレ伸びてると思ったら右辺値参照くんきてるのか。
個人的には右辺値参照くんの病的で狂信的に右辺値参照押ししてくるところがいいと思う、
ぶっちゃけ、私は右辺値参照くんのファンになってしまった。
D:n3qiU1JI の人も右辺値参照くんにしっかりくいついて盛り上げていってほしい。
あと、右辺値参照くんはもうちょっと丁寧に右辺値参照について説明して上げてほしい。

0603デフォルトの名無しさん

2014/11/01(土) 22:44:05.14ID:n3qiU1JI

>>601
「扱えるのだけど」じゃなくて
扱うコードを書けって。
何度言わせるんだ？

0604デフォルトの名無しさん

2014/11/01(土) 22:46:02.05ID:n3qiU1JI

右辺値参照は複雑な概念だから
こんなスレで収まるほど簡単に説明はできないって
C++に慣れた人でもかなり勉強しないと
正しく使えるようにならないんだから。

0605デフォルトの名無しさん

2014/11/01(土) 22:46:50.79ID:TgOtBrGZ

>>603
A b(std::move(a));

これだけ。
で、何が言いたいの？

0606604

2014/11/01(土) 22:46:52.44ID:n3qiU1JI

>>602あて

0607デフォルトの名無しさん

2014/11/01(土) 22:47:41.39ID:n3qiU1JI

>>605
そのstd::move(a)); とは何か？

それを説明するとどんどん難しくなるだろう？

0608デフォルトの名無しさん

2014/11/01(土) 22:48:13.41ID:TgOtBrGZ

>>604
何言ってんの？

右辺値参照とは、右辺値への参照。

一言で説明できる。

0609デフォルトの名無しさん

2014/11/01(土) 22:48:59.95ID:TgOtBrGZ

>>607
左辺値を右辺値にキャストする。

何も難しくないだろ。

0610デフォルトの名無しさん

2014/11/01(土) 22:49:06.18ID:n3qiU1JI

> 右辺値参照とは、右辺値への参照。
>
> 一言で説明できる。

これ、何も説明してない（笑）

0611デフォルトの名無しさん

2014/11/01(土) 22:50:18.56ID:TgOtBrGZ

>>610
完全に説明しきってるだろ。

0612デフォルトの名無しさん

2014/11/01(土) 22:50:25.37ID:n3qiU1JI

>>609
> 左辺値を右辺値にキャストする。

なんのために？
それをするとどうなる？
なぜそんなのが必要なのか？

それに答えるのが説明するってことだよ。

0613デフォルトの名無しさん

2014/11/01(土) 22:53:07.68ID:yfMW+WpF

>>600
使う必要ないものを使えと？ w

0614デフォルトの名無しさん

2014/11/01(土) 22:55:42.27ID:TgOtBrGZ

>>612
必要なければコピーすれば？

必要を感じたら使えばいいだけでしょ。
そもそも意識しなくても使ってるんだよ。

勉強したいなら、自分で勉強すればいいよ。
先生は忙しいから、もうちょっと勉強してからおいでよ。

0615デフォルトの名無しさん

2014/11/01(土) 22:58:05.54ID:n3qiU1JI

また逃げたｗ
説明が大変だから仕方ないね。

0616デフォルトの名無しさん

2014/11/01(土) 22:58:13.14ID:TgOtBrGZ

>>613
そうなんだよな。
あの例で何をしたかったのかがさっぱりわからん。

おそらくGC自体良くわかってないんだろな。

予想だけど、GC導入の動機がパフォーマンスの改善に有るということが
理解できていないんじゃないだろうか。

0617デフォルトの名無しさん

2014/11/01(土) 23:00:27.80ID:TgOtBrGZ

>>615
そもそも何を説明しろと言ってるのかがわからない。

右辺値参照を利用するには何かをしなければならないと思ってるのかもしれない。
しかしそうではない。

何もしなくても、右辺値参照は使われてる。

0618デフォルトの名無しさん

2014/11/01(土) 23:01:49.64ID:tJ+ySesM

> 予想だけど、GC導入の動機がパフォーマンスの改善に有るということが
> 理解できていないんじゃないだろうか。

違うぞ。GCの目的はプログラマの負担とミスを減らすため。
お前こそわかっとらんじゃないか。

0619デフォルトの名無しさん

2014/11/01(土) 23:03:11.10ID:TgOtBrGZ

>>618
負担を減らすだけなら、コピーで良いでしょ。
そっちの方がずっとわかりやすい。

0620デフォルトの名無しさん

2014/11/01(土) 23:06:35.46ID:tJ+ySesM

>>619
なんでオブジェクト作成→破棄の話で
コピーが出てくるんだよ？

0621デフォルトの名無しさん

2014/11/01(土) 23:06:57.56ID:TgOtBrGZ

俺の考えでは、ミスを減らすには、どこかから参照されている限り破棄されないのが邪悪。

これがスコープの限定を難しくし、ミスの発生につながる。

これがGCが良くない理由。
原理的にはコピーが一番良い。

0622デフォルトの名無しさん

2014/11/01(土) 23:08:48.60ID:tJ+ySesM

コピーしたら、その二つは別々のものになるだろ？
なんか根本的に話がずれてないか？

0623デフォルトの名無しさん

2014/11/01(土) 23:08:56.99ID:bp3MCKN/

コピーでいいってのはマジでその通りだよな
しかしパフォーマンス重視するとalignで確保するからgcなんぞ使えんけどな

0624デフォルトの名無しさん

2014/11/01(土) 23:09:17.91ID:etXlBO/A

それよりHaskellみたいな純粋関数型が売りの言語でGCが必要なのが何かイメージと合わない
LISP派生だからと言われるとそうなんだが
言語であれだけふくざつなことやってるなら変数の生存期間ぐらい面倒見れそうな気がするんだけどなあ

0625デフォルトの名無しさん

2014/11/01(土) 23:10:25.28ID:yfMW+WpF

>>618
> GCの目的は（メモリー管理について）プログラマの負担とミスを減らすため。

だろ？
メモリー管理が必要ないコードで何を言いたいのかさっぱりわからん

0626デフォルトの名無しさん

2014/11/01(土) 23:13:48.03ID:tJ+ySesM

あたりまえだけどさ、
コピーとインスタンス作成は別々の概念だよ。
それはわかってるのかな？

GCは必要なくなったインスタンスを
自動的に回収する技術で、コピーとは全く無関係。

もしかして一つのオブジェクトを複数の変数から
参照したいことがあるってわかってないとか？

複数の変数から、同じオブジェクトを参照したいなら、
そのオブジェクトをコピーしたほうがいいと考えてるのかな？

コピーしちゃったら別々のインスタンスになるから、
片方が修正しても、もう一方は変わらない。

0627デフォルトの名無しさん

2014/11/01(土) 23:15:31.78ID:TgOtBrGZ

>>626
それは参照すればいいだけ。
何が言いたいのかがさっぱりわからん。

0628デフォルトの名無しさん

2014/11/01(土) 23:16:57.62ID:yfMW+WpF

>>626
> もしかして一つのオブジェクトを複数の変数から
> 参照したいことがあるってわかってないとか？

std::shared_ptr

0629デフォルトの名無しさん

2014/11/01(土) 23:26:13.99ID:bp3MCKN/

コピーでいいってのは
かなりの部分すっとばして生存期間とスコープ考えてある程度設計頭に描きながら
考えで言ってる事なんじゃねーのと俺は思ってたんだが

そりゃ内部的な動作は全く違うし、使い方も異なるよ

0630デフォルトの名無しさん

2014/11/01(土) 23:27:04.85ID:R8grbRHL

>>621
参照できるものを勝手に破棄されるの恐くね？

0631デフォルトの名無しさん

2014/11/01(土) 23:28:58.11ID:TgOtBrGZ

>>629
そういう意味で言ってる。

基本的にコピーするべき。
設計の基本だと思う。
しかしそれではパフォーマンスの問題がある。
そこで、右辺値参照。

0632デフォルトの名無しさん

2014/11/01(土) 23:34:09.83ID:qo22BqRg

例えばJavaとC++の両方に精通しておかないとただの罵りあいになりますな。
オブジェクトは全て参照のJavaにコピーコンストラクタの話は？？？だろうに。

0633デフォルトの名無しさん

2014/11/01(土) 23:36:42.63ID:TgOtBrGZ

>>632
そうなんだよね。
もう少し勉強してから書き込まないと荒らしになると何度も言ってるんだけどね。

0634デフォルトの名無しさん

2014/11/01(土) 23:42:23.46ID:TgOtBrGZ

Javaがなぜプリミティブをコピー、クラスのインスタンスを参照と分けたのか。
それはパフォーマンス上のアイデアに違いない。

ここからまずわかっていなさそうなので、もう少し勉強したほうが良いと言ってる。

0635デフォルトの名無しさん

2014/11/01(土) 23:50:05.54ID:qo22BqRg

>>633
「言語が思考を規定する」だったかな。
もっと敵をよく知らないとな。

0636デフォルトの名無しさん

2014/11/01(土) 23:56:45.48ID:qo22BqRg

勿論、己をよく知るのも重要だがね。

0637デフォルトの名無しさん

2014/11/01(土) 23:59:33.20ID:OtA6KIlR

右辺値参照ってようは弱参照でしょ
暗黙変換されるからarcよりバグの元になりそう

0638デフォルトの名無しさん

2014/11/02(日) 00:05:14.22ID:8S1WeHay

そこはPHPがよく出来ているよね。
オブジェクトを修正した時にコピーが作られる。
Copy-on-Writeを言語レベルで実現している。

0639デフォルトの名無しさん

2014/11/02(日) 00:08:58.11ID:MZH26PPR

>>637
C++のweak_ptrの立場がなくなる

0640デフォルトの名無しさん

2014/11/02(日) 00:21:02.58ID:Hoa1ulm8

>>626
右辺値くんは「javaがgc採用したのは引数をコピー渡しすると遅くなるから」
と思ってるあほだからインスタンスと構造体の区別もつかないと思うよ

0641デフォルトの名無しさん

2014/11/02(日) 00:33:02.44ID:u/SB4U3Z

> GCを前提にした言語では、例えば右辺値参照などは実現できない。
なかなか名言よね

0642デフォルトの名無しさん

2014/11/02(日) 01:28:11.75ID:L/9+J0W5

javaとC#はnewがバンバン飛び交って怖い
ゆとりかつ臆病な若者としてはC++使ってnewも、STLも可能な限り使わないで、代わりにスタックメモリたっぷり使うのが１番安心できる
事なかれ主義な若いプログラマには結構いそう

0643デフォルトの名無しさん

2014/11/02(日) 01:39:26.08ID:pOi6viHj

ＧＣ依存はエライ乱暴なコードになるからな

0644デフォルトの名無しさん

2014/11/02(日) 01:46:52.03ID:Lqm+QUe+

で、結局右辺参照ってなに？

0645デフォルトの名無しさん

2014/11/02(日) 01:53:09.42ID:MZH26PPR

C++は不得手だが…間違っていたら訂正して欲しい。
仕様と実装を混ぜて書くので、そこもご了承ください。
>>612
言語仕様上は右辺値参照に左辺値を代入できないから。

左辺値は大雑把にいって変数でスタックの中程にある。多分ポインタ。
右辺値は大雑把にいってスタックトップにある。これも多分ポインタ。
右辺値参照の参照先は破壊されるかもしれない。
スタックトップなら関数を抜けた後は不定だからこれは妥当。
処理系によってはnullにするかもしれない。
さて、std::move(a)だが、大雑把にいって左辺値をスタックトップに積みなおしている。
これで左辺値を破壊する可能性がなくなり、右辺値参照にはスタックトップの左辺値(のコピー)が代入される。
代入後はスタックトップの左辺値は捨てて良い。

オブジェクトをスタックに割り当てる際、実体をヒープにポインタをスタックに積む実装はよく目にする。
だから右辺値の参照を得るのは難しくはないと思う。

0646デフォルトの名無しさん

2014/11/02(日) 02:01:24.77ID:Lqm+QUe+

計算途中とか関数の値を受け取るときに出来る一時オブジェクトへの参照を普通の参照と区別して、
前者の時はどうせ一時オブジェクトだから、コピーしないで参照のまま渡しちゃえば効率よくね？
っていう考えなんだと思ったんだけど違ってる？

0647デフォルトの名無しさん

2014/11/02(日) 02:12:58.43ID:MZH26PPR

作ってはすぐにGCによって消える一時Stringオブジェクト。
String s = "a" + "b" +…+ "z";
大抵の奴らは気にしない。

0648デフォルトの名無しさん

2014/11/02(日) 02:32:23.54ID:MZH26PPR

>>646
あってんじゃね

0649デフォルトの名無しさん

2014/11/02(日) 02:55:38.79ID:6JfF1xXY

>>647
あー、なるほど。
そういう時に早く処理するために
GCが作られたとか勘違いしてんのか。

だから速度勝負をしてるわけねｗ

0650デフォルトの名無しさん

2014/11/02(日) 03:09:15.75ID:Lqm+QUe+

C++の右辺参照てのがコピーのコストをなくそうとするのが目的なら、
GCの対象になるオブジェクトは普通はみんな参照で暗黙にコピーされたりしないんだから、
比べても意味ないんじゃね？

0651デフォルトの名無しさん

2014/11/02(日) 04:11:29.99ID:MZH26PPR

>>650
Javaなら右辺値はプリミティブでなければ常にオブジェクトの参照なので、
左辺値は常に右辺値参照と言えなくもないっぽい。

LispやBoehmライブラリとかGCがあるけど参照じゃないかもしれないのは、普通じゃないからいいか…

0652デフォルトの名無しさん

2014/11/02(日) 04:39:08.11ID:Lqm+QUe+

lispは全部参照だし、boehmはmallocとかnewを置き換えるんだから参照でしょ。
C#の構造体みたいな値型のやつが普通じゃないやつのつもりだったんだけど。

0653デフォルトの名無しさん

2014/11/02(日) 04:52:09.85ID:MZH26PPR

>>651
と書いたが違うかも。
std::move(a)≒a.clone()みたいな感じ、まだまだ勉強不足だな。
右辺値参照はコピー回避だけじゃないっぽい。

0654デフォルトの名無しさん

2014/11/02(日) 04:55:25.20ID:6JfF1xXY

> std::move(a)≒a.clone()みたいな感じ、

正解。右辺値参照はクローン。
だからクローンがあればGCはいらないみたいな話をしているので
意味不明なんだよ。まるでGCをクローンの代わりに使用する
高速なコピーのための機能と勘違いしているかのよう

0655デフォルトの名無しさん

2014/11/02(日) 05:01:59.13ID:MZH26PPR

ありがとう。
また一つ勉強させてもらった。
今度、Boehmライブラリをつぶさに読んでみるあるよ。

0656デフォルトの名無しさん

2014/11/02(日) 05:09:53.13ID:/XH1yScC

GCと比較するとしたら、値型だろうね。
スコープを抜けると自動的に消える値型

0657デフォルトの名無しさん

2014/11/02(日) 05:41:02.93ID:t2EpQ33q

なんかおかしな方向に行ってないか
大丈夫なのこれ

0658デフォルトの名無しさん

2014/11/02(日) 05:45:37.49ID:Lqm+QUe+

a.clone()てaのコピー作って返すんじゃない...の...?

0659デフォルトの名無しさん

2014/11/02(日) 05:54:53.62ID:MZH26PPR

GCとの比較なら参照カウンターじゃね？

0660デフォルトの名無しさん

2014/11/02(日) 06:59:02.74ID:rN0PF8rZ

>>657
な？GCは失敗だろ？

0661デフォルトの名無しさん

2014/11/02(日) 07:37:30.06ID:vxEoPS2x

>>585 ID:TgOtBrGZ
右辺値参照／move semantics は小さな技術で、これで大勢がかわるわけではないんだよ
GC は巨大技術、完全に行われるのであればソフトウェアの進歩に貢献する

＞GCはOOPと決定的に親和性を欠く。
Java や C# を調べてみたほうがよい

0662デフォルトの名無しさん

2014/11/02(日) 08:54:42.61ID:67KOBBIP

C++とJavaしか知らずに物事を語る、彼のようなプログラマーが世の中の標準だと考えると憂鬱になる
ぶっちゃけGCじゃなくてJavaが嫌いっぽいしね

0663デフォルトの名無しさん

2014/11/02(日) 09:22:29.84ID:aOhxai0O

>>660
お前がGCを叩きたいだけってのがよくわかった。

0664デフォルトの名無しさん

2014/11/02(日) 09:53:14.06ID:TOrV8LyY

C++ と Java 比べたら最終的には C++ が勝つに決まってる
Java は CG 無くすことはできないけど、C++ は CG 実装することできるからね
まあ、アセンブラさいこーって言ってるのと同じだけどな

0665デフォルトの名無しさん

2014/11/02(日) 10:11:05.75ID:iKbwWXgv

C++は最高の言語だと思う
しかし、糞が書いたC++を読むハメになると発狂できる

0666デフォルトの名無しさん

2014/11/02(日) 10:12:45.35ID:aXSCE3ny

ライブラリ使ってもいいんだから意味が違う

0667デフォルトの名無しさん

2014/11/02(日) 10:35:50.47ID:0u/vIpbI

*Automatic Reference Counting
　objective-c
　利点
　　メモリ管理が楽になる
　欠点
　　循環参照を開放できない
　　参照カウントはアトミックな操作を必要とするので意外と重い(特にマルチスレッドマルチコアな今は)

*Garbage Collection
　java/C#
　利点
　　メモリ管理が楽になる
　欠点
　　GCが動くと処理が止まる

*右辺値参照
　C++
　利点
　　値渡しを内部的に参照渡しと同じコストで書ける
　欠点
　　shared_ptr,uniq_ptrをプログラマが使い分ける必要がある
　　循環参照を開放できない
　　RAIIでもnewで生成してdelete忘れれば当然メモリリーク
　　IDesposable/Closableのようなマーカーが無いのでオブジェクトがリソースつかむかどうかはコードを見なくてはならない。とするとRAIIの利点無いよね？
　　shared_ptr使えば良い？参照カウントは重いんだってば
　　右辺値参照があればGC不要(←？？？www)

0668デフォルトの名無しさん

2014/11/02(日) 10:43:05.04ID:aXSCE3ny

総合的にスタック最強
関数スタックだけじゃないけど

0669デフォルトの名無しさん

2014/11/02(日) 11:11:40.10ID:5ZVCU8dy

Firefoxって世代別GCしてなかったのか
どうりで遅いわけだ
https://hacks.mozilla.org/2014/09/generational-garbage-collection-in-firefox/

0670デフォルトの名無しさん

2014/11/02(日) 11:38:12.82ID:vxEoPS2x

>>667
＞欠点
＞　　GCが動くと処理が止まる
これはMark&Sweep とか古典的なGCでの話、今は GC で止まることはそんなにないと思う
まあ、決め手がなく、複合技で凌いでいる状況のようだが‥

0671デフォルトの名無しさん

2014/11/02(日) 11:39:29.66ID:vxEoPS2x

>>668
現実の問題でスタックのみでやっていけるのか？

0672デフォルトの名無しさん

2014/11/02(日) 11:44:42.38ID:7FNYbovr

>>667
IDisposable/Closableって、
派生クラスでリソース掴む可能性を見越して
基本クラスでinterface作っておかなきゃ
いけない欠陥品だよね。

基本クラスの機能とその派生がリソースを掴みうるかなんて殆ど相関無いのに。

0673デフォルトの名無しさん

2014/11/02(日) 11:51:12.95ID:J3FCyBvm

>>671
50万行のアプリ開発したよ

0674デフォルトの名無しさん

2014/11/02(日) 12:13:11.39ID:aOhxai0O

基本クラスでinterface作るって何言ってんだ？
なんで基本クラスで持たせないといけないと考えているのか
さっぱりわからん。

0675デフォルトの名無しさん

2014/11/02(日) 12:21:22.89ID:vxEoPS2x

>>664
たしかに、なんでもかんでも GC、ではなく採用範囲を狭めたりできればもっとよくなると思うんだ

0676デフォルトの名無しさん

2014/11/02(日) 12:21:35.98ID:FPvqJpqA

>>673
スタックじゃなければ２０万行で済んだよ

0677デフォルトの名無しさん

2014/11/02(日) 12:28:39.22ID:dzrrxKH0

なんらかのプロパティを返すだけのリソースをつかまないclass Aのオブジェクトを保有して処理をする処理クラスを作る。

処理クラスはコンストラクタにclass Aのオブジェクトのインスタンスを渡して生成する。

class AAはAの派生クラスだが、リソースを掴む実装として作る。例えばDBのコネクションとか。

class AAのインスタンスはOO的にはAと同様に使いたいところだが、disposeが適切に呼ばれるようになっていないから、Aと処理クラスにIDisposableを追加して、処理クラスの使用後にdisposeを呼ぶように修正しなきゃいけない。

0678デフォルトの名無しさん

2014/11/02(日) 12:38:13.75ID:MZH26PPR

参照カウントの循環参照についてはカウントを上げ下げしない弱
参照weak_ptrをプログラマが意図的に使うことで回避できるっぽ
い。
shared_ptr,uniq_ptrに加えてweak_ptrをプログラマが使い分け
る必要がある。
プログラマが四六時中気を付けなければならないわけでもない。

0679デフォルトの名無しさん

2014/11/02(日) 12:40:31.23ID:ueW82dqI

>>677
そもそも設計が間違ってそうだが、class AAにIDisposableでいいじゃん

0680デフォルトの名無しさん

2014/11/02(日) 12:43:07.35ID:vxEoPS2x

>>678
めんどくさすぎる‥

0681デフォルトの名無しさん

2014/11/02(日) 12:48:45.08ID:jU0EmFN8

>>676
それは絶対ないルールだったから
BTSチケットも1/10,工数も70%程度だった

0682デフォルトの名無しさん

2014/11/02(日) 12:55:08.27ID:jgUgVjBv

>>678
っぽい、というかもともとそう。
ただ、重要なのは各オブジェクトの所有権を持つ参照が常に一つだけであることなんだが、
なぜかweak_ptrはunique_ptrじゃなくshared_ptrからしか作れないんだよな。

0683デフォルトの名無しさん

2014/11/02(日) 12:55:44.15ID:e1EY+Kds

>>679
うん。俺もそう思った
派生クラスから継承元メソッドを呼びたいなら、そう書けばいいだけに見える
派生クラスのインスタンスは軽重元を内包しているんだし

ファクトリーでオブジェクトのライフタイムを管理したいなら、派生じゃなく、それじたいを
メンバーに持てばいいような気がします

0684デフォルトの名無しさん

2014/11/02(日) 12:58:56.96ID:7FNYbovr

>>679
処理クラスの寿命がAAのインスタンスを作るところで把握できている場合はそれで済むが、それって要は処理クラスやAAの寿命が特定のスコープ内で閉じていると言うことで。
スタック上に直接インスタンス作れば
面倒なメモリ管理要らない状況と同じ

0685デフォルトの名無しさん

2014/11/02(日) 12:59:31.02ID:rN0PF8rZ

>>682
そこは問題だよね。

本来このスレでは、こういう議論をするべきなんだけどね。

0686デフォルトの名無しさん

2014/11/02(日) 13:05:21.31ID:MZH26PPR

>>670
G1GCとか止まっている時間を分散しているようにも見える。
実用上はそれで大抵問題ない。
full GCを起こしにくくするGC内外のあの手この手もあるし。

>>680
些細なことでもプログラマの負担が増えるのは実は嫌いなんだ。

0687デフォルトの名無しさん

2014/11/02(日) 13:12:30.42ID:rN0PF8rZ

>>686は、まだこのスレに来るのは無理なんじゃないかな。

0688デフォルトの名無しさん

2014/11/02(日) 13:14:35.97ID:iKbwWXgv

GCって単純な設計のものにしか使えないと思う
単純な設計に落とし込めなくて
弱参照で頑張ったりするなら手作業で管理するほうがずっと楽だ

GC使う必要があって設計が難しくなるものもあるけど
それってかなり特殊だろう

0689デフォルトの名無しさん

2014/11/02(日) 13:16:14.45ID:MZH26PPR

>>687
はーい(_´Д｀)ノ~~さいならぁ

0690デフォルトの名無しさん

2014/11/02(日) 13:18:47.23ID:aOhxai0O

>>688
単純な設計という曖昧な言葉じゃなくて
99.9%の設計にしか使えないって使えないって具体的に言ってよ。

残り0.1%の超複雑な設計には使えないかもね。
それがどんなものか、わからないけど。
多分君にも。

0691デフォルトの名無しさん

2014/11/02(日) 14:34:59.57ID:UQ+cnApO

>>684
それで何か問題あるか？

0692デフォルトの名無しさん

2014/11/02(日) 14:44:41.28ID:u/SB4U3Z

>>682
unique_ptrを弱参照して何がしたいの？

0693デフォルトの名無しさん

2014/11/02(日) 15:27:31.05ID:jgUgVjBv

>>692
そのまんま、unique_ptrの指すリソースへの弱参照が欲しいってことなんだが、何か疑問かなぁ？
リソース管理にunique_ptrを使う分には、基本的に(自身から繋がるチェインの先に自身の所有権を
移動することのないことだけ注意すれば)、循環参照の問題は起こらない。
ただしそれだけではネットワーク構造等を表現できないので、アプリケーションが要求するデータ
構造の表現としてweak_ptrを使いたい。

0694デフォルトの名無しさん

2014/11/02(日) 15:42:41.08ID:UQ+cnApO

生ポインタでいいんじゃない？

0695デフォルトの名無しさん

2014/11/02(日) 16:01:05.04ID:Jjs/RmF2

>>693
先頭を指すshared_ptrにweak_ptrを入れることで循環しつつ先頭を指す強参照
がなくなったときに先頭から連鎖的に開放できるのが味噌なんでは？
だからshared_ptrから継承されると

0696デフォルトの名無しさん

2014/11/02(日) 16:16:20.35ID:fZ+YqMpY

生ポインタだと強参照が消えてたときに不正な参照が残っちゃわない？

0697デフォルトの名無しさん

2014/11/02(日) 16:21:37.58ID:jgUgVjBv

>>695
その連鎖的な解放ってのはunique_ptrでも同じことでしょ。
で、どっちにしろ強参照のループが存在していたらまずいわけだが、unique_ptrなら根元だけ押えて
おけばよい。shared_ptrだと、他に強参照が存在しないかあるいはいずれ確実に破壊されることを
プログラム側で保証しなければならない。

0698デフォルトの名無しさん

2014/11/02(日) 16:38:49.01ID:u/SB4U3Z

>>693
どんなタイミングで死ぬかも判らない物でも参照していたいと…
その発想はなかった

0699デフォルトの名無しさん

2014/11/02(日) 16:42:19.56ID:jgUgVjBv

弱参照を何だと思っていたんだ

0700デフォルトの名無しさん

2014/11/02(日) 16:50:00.78ID:Jjs/RmF2

>>697
根元を押さえているのがunique_ptrなら、そもそもどうやって循環するの？

0701デフォルトの名無しさん

2014/11/02(日) 17:00:42.98ID:jgUgVjBv

>>700
>>693の括弧書きのようなことをしなければ循環はしないね。
そのうえで、弱参照で循環構造を含むデータ構造の表現ができればよかったのに、という話。

0702デフォルトの名無しさん

2014/11/02(日) 18:28:43.29ID:UQ+cnApO

weak_ptrは参照カウント式の循環参照の問題を解決するために作られた
unique_ptrは参照カウント式じゃないからweak_ptrは作られなかった
くらいの理由だと思うが
弱参照側でunique_ptrが破棄された事を監視する仕組みをちゃんと作るとオーバーヘッドありそうだしなぁ

0703デフォルトの名無しさん

2014/11/02(日) 18:49:28.70ID:rN0PF8rZ

>>702
オーバーヘッドは無い。
unique_ptr<>にweak_ptr<>が欲しい理由は、assert入れる程度の理由が
殆どだと思うけど、有ったほうが良いのは確か。

0704デフォルトの名無しさん

2014/11/02(日) 18:53:03.61ID:rN0PF8rZ

所有権ベースの考え方だと、shared_ptr<>自体、邪悪なものなんだよね。
そこら辺から、shared_ptr<>が優遇されているように見えて、なんで無いんだ？
となってくるんだよ。

0705デフォルトの名無しさん

2014/11/02(日) 19:21:43.75ID:7FNYbovr

てか、unique_ptrでweak_ptrってどうやって実装するの？
結局shared_ptrと同様の構造にするしかなくて、オーバーヘッドが生じるけど許容できるの？

0706デフォルトの名無しさん

2014/11/02(日) 19:25:59.50ID:rN0PF8rZ

>>705
削除子の絡みで元から実装できる構造になってる。

0707デフォルトの名無しさん

2014/11/02(日) 20:18:57.15ID:7FNYbovr

custom deleterの対応とweak_ptrヘの対応じゃやること違うだろ。

weak_ptrは参照先のobject instanceとも
shared_ptrとも寿命が違うobjectで管理しないといけないのだから。
そのobjectの寿命管理のためにそのobject自身のweak_ptrからの参照カウント管理も必要だし。

0708デフォルトの名無しさん

2014/11/02(日) 20:25:49.12ID:rN0PF8rZ

>>707
もう少し勉強してから書き込まないと荒らしになる。

0709デフォルトの名無しさん

2014/11/02(日) 20:49:13.94ID:jgUgVjBv

>>705
実装としては別に、「所有権を共有できないshared_ptr」でいいんだがなぁ。

0710デフォルトの名無しさん

2014/11/02(日) 20:57:34.40ID:7FNYbovr

>>708
いや、現実に実装されていないものが
簡単に実装できるといったのに、
挙げてきたものが的はずれ過ぎるだろ。

shared_ptrのweak_ptr実装知っているのか。
なぜunique_ptrやboost::intrusive_ptrにweak_ptr相当のものが
実装されていないのか考えてみたか？

0711デフォルトの名無しさん

2014/11/02(日) 21:17:45.92ID:rN0PF8rZ

>>710
削除子をカスタムデリータと読み替えるからそう思うんじゃないの？

0712デフォルトの名無しさん

2014/11/02(日) 21:20:07.27ID:mACG5wDA

Swift移行でGCを再導入しそう。そうなるとprotocol(javaでいうInterface)
のメソッドシグネチャーも手を入れそうだけど。自分的にはGC自体はどうでも
いいけど、さすがに、循環参照対策で第一引数に移譲元のクラスを渡すのは古
臭く感じる

0713デフォルトの名無しさん

2014/11/02(日) 22:29:55.80ID:IyW8WEC0

>>709
なら shared_ptr を継承してインターフェースを絞ったクラスを作ればいいんじゃね？

0714デフォルトの名無しさん

2014/11/03(月) 02:14:06.66ID:id4CCXJ8

要約するとGCは勝ち組。

0715デフォルトの名無しさん

2014/11/03(月) 22:32:57.90ID:/tG/79z7

このスレで語られているようなことの歴史を学びたいのですが、どこかに良いサイトや書籍ってありますか？

0716デフォルトの名無しさん

2014/11/03(月) 22:37:49.77ID:v6YDSaif

>>715
http://tatsu-zine.com/books/gcbook

0717デフォルトの名無しさん

2014/11/03(月) 22:46:35.04ID:/tG/79z7

>>716
どうもです。Javaでの実装は入ってないみたいだけど、買ってみるわ

0718デフォルトの名無しさん

2014/11/04(火) 02:40:24.65ID:KSMLMRdV

>>717
筆者のwiki
http://seesaawiki.jp/w/author_nari/d/GC

0719デフォルトの名無しさん

2014/11/04(火) 14:02:38.45ID:OXvDS9Yh

ATS!! ATS!!

0720222

2014/11/04(火) 17:22:03.66ID:6g/0xydT

ats?
言語仕様ざっと見したけど無駄に複雑な仕様だとしかおもえん
メリットなにさ

0721デフォルトの名無しさん

2014/11/04(火) 21:46:56.28ID:GrqJXM5/

>>718
ありがたい。じっくり読みます！！

0722デフォルトの名無しさん

2014/11/11(火) 00:17:04.72ID:JD7Ik4Uf

時代はpascalか。

0723デフォルトの名無しさん

2014/11/11(火) 10:16:31.61ID:jfV1CRrh

ボケなんだろうけどどう反応していいか迷うな

0724デフォルトの名無しさん

2014/11/11(火) 21:21:07.74ID:tLYldMk+

いいえ、ソクラテスです。

0725デフォルトの名無しさん

2014/11/11(火) 22:55:03.16ID:DpN/sAby

>>723
素人乙でいいだろ w
http://www.pbm.com/~lindahl/real.programmers.html

0726デフォルトの名無しさん

2014/11/13(木) 06:33:15.09ID:zPEEZtXf

結局まとめると、
解放処理まで全部入れる

バグで解放漏れしたら、GCさんすまんがよろしく方式がただしいわけだ

0727デフォルトの名無しさん

2014/11/13(木) 06:38:37.51ID:zPEEZtXf

メモリの解放まで適切にできるようになる

これは

ソースを綺麗に書くことができるようになった証拠の一つ

よって解放までやる癖をつけよう

0728デフォルトの名無しさん

2014/11/13(木) 08:01:21.90ID:Doj5jcuD

解放しちゃいけないのを解放したらどうすんだよ。w

0729デフォルトの名無しさん

2014/11/13(木) 08:29:08.50ID:mNvWhrE9

それは適切じゃないだろ

0730デフォルトの名無しさん

2014/11/13(木) 09:12:50.42ID:Doj5jcuD

適切にできるならGC不要

振出しに戻る

0731デフォルトの名無しさん

2014/11/13(木) 09:13:48.91ID:7EI8L7kd

>>728
テストが足りん

0732デフォルトの名無しさん

2014/11/13(木) 10:50:15.82ID:DYELcWQQ

解雇

0733デフォルトの名無しさん

2014/11/13(木) 10:55:04.64ID:5Oh59ksY

自由の身になった>>728

0734デフォルトの名無しさん

2014/11/13(木) 10:56:51.80ID:a0S0K7Sl

LLや動的型言語の時代ｷﾀ━━━━(ﾟ∀ﾟ)━━━━!!とレミングスのように集団自殺したり
メモリ管理などオワコンなどと主張したり、
それで結局老害扱いしてたC++erやJava勢やC#勢の逆襲食らってたり

例外はないこともないが、最近の若いプログラマってアホばっかなのでは？
とりわけJavaScriptとRubyしか触ってないみたいな連中はやばすぎる

幼稚園の頃からBASIC→マシン語→C言語→C++→Java→LLと順当に触ってきて
きちんと計算機科学も修めている俺からすると、実にチャラいというか、
基礎がなってないためにしでかしてる勘違いの数々にまるで自覚がないというか

CPUの息吹を肌で感じてないんだよな・・・

0735デフォルトの名無しさん

2014/11/13(木) 11:16:49.11ID:7ZjHj42h

釣れますかー？

0736デフォルトの名無しさん

2014/11/13(木) 12:10:00.51ID:4SjIbFGA

メモリの息吹を感じていればリークは起こらないからな

0737デフォルトの名無しさん

2014/11/13(木) 13:22:55.62ID:UimbrwPY

Rubyっつーか、その枠に入るのはRailsな気がする

0738デフォルトの名無しさん

2014/11/13(木) 15:40:25.56ID:yPJZ4FD8

CPUの歓声に耳を傾けていれば…

0739デフォルトの名無しさん

2014/11/13(木) 15:53:58.24ID:iet/U29a

メモリの奥底で解放されずに苦しむオブジェクト達の声が聞こえます・・・

0740デフォルトの名無しさん

2014/11/13(木) 17:31:16.12ID:s/YjhiVe

HDDの金切音が聞こえる
Raid組んでるからいいけどRaid0

0741デフォルトの名無しさん

2014/11/13(木) 17:42:39.39ID:s/YjhiVe

メモリを凡人が把握しきれる範囲に止める。
それすなわち、グダグダプログラムを書かず、適切な部品化につながる

やっぱりGCはないものと考え、プログラミングする。

それでも、人間だものミスはする。
それはGCさんうまいこと拾ってちょと。

これが正しそうだね

0742デフォルトの名無しさん

2014/11/13(木) 20:59:49.37ID:4SjIbFGA

freeしたら他で使ってたというのもよくある話で
GC使うか使わないかの二択なんだよな

0743デフォルトの名無しさん

2014/11/13(木) 21:49:24.00ID:6mw95AhO

んだんだ

0744デフォルトの名無しさん

2014/11/13(木) 21:52:01.83ID:6mw95AhO

>>741
んだんだ。これが正解だと思う。メモリ管理だけじゃない。プログラミングは。でも、どれも軽視できない。

結果として、読みやすい・保守しやすい・修正しやすいプログラムは、すべてのプログラミング技法・作法・マナーから生まれる。

0745デフォルトの名無しさん

2014/11/13(木) 22:24:17.01ID:Doj5jcuD

出た、マナー

異端は滅すべし

0746デフォルトの名無しさん

2014/11/13(木) 22:32:27.16ID:7ZjHj42h

マナー違反とかいう言葉があるが、「違反」とか言うならそりゃあもうルールだろってな。
ルールという言葉には強制するという意味があるけど、無自覚に他人に物事を強制する
べく「マナー」って言葉を便利に使ってる奴が多過ぎる。

0747デフォルトの名無しさん

2014/11/13(木) 22:49:05.91ID:uOTGwQ1c

ルールと書くと「それは誰が決めたの？」といわれるからね、「マナー」は主体がないからお気楽に使う奴らが多いね、
で、プログラミングのマナーってたとえばどのようなもの？>>744

0748デフォルトの名無しさん

2014/11/13(木) 23:12:00.88ID:UimbrwPY

>>742
ダングリングポインタ問題、C++で生ポ縛り(あくまで勉強用の、ミニゲームのコードね)してたら出くわしたな
んで結局、shared_ptrやweak_ptrモドキを作るところに落ち着くっていうね
普段はスマポべったりだったから便利ポインタぐらいの認識だったが、あのとき「ああこれ必須機能なんだな」って思った

0749デフォルトの名無しさん

2014/11/13(木) 23:25:10.56ID:uOTGwQ1c

そういうのはオレオレアロケータでラップすれば解決できる話

0750デフォルトの名無しさん

2014/11/13(木) 23:51:15.27ID:Doj5jcuD

>>747
狂信者がマナーを語るとは片腹痛いわ

0751デフォルトの名無しさん

2014/11/14(金) 00:47:29.71ID:0NdzO4Gj

いや、おまえがだろw

0752デフォルトの名無しさん

2014/11/14(金) 06:31:30.00ID:k3X6Z6em

マナーとは気づかい

どうすれば自分以外が読んでも理解しやすいかを考えること

0753デフォルトの名無しさん

2014/11/14(金) 07:03:25.40ID:f85sxZ2s

JAPらしいマナーの定義だな

0754デフォルトの名無しさん

2014/11/14(金) 08:04:36.77ID:sDSR2Iuo

トンスラーにマナーはありません、ウリナラウリナラー

0755デフォルトの名無しさん

2014/11/14(金) 08:20:05.94ID:I/Kn10CW

C++でスマートポインタとスマートアレイを使ってればGCなど要らないわ
長時間走らせるC#アプリだってメモリーリークの監視検証しないといけないのは同じだし

0756デフォルトの名無しさん

2014/11/14(金) 10:15:31.34ID:+CsfViMM

意外と難しい、スマートポインター

0757デフォルトの名無しさん

2014/11/14(金) 10:31:42.14ID:0NdzO4Gj

>>754 死ねよ、自分はマナーもルールも無いバカウヨは

0758デフォルトの名無しさん

2014/11/14(金) 10:41:38.76ID:IAbvV61j

チョン最高っす

0759デフォルトの名無しさん

2014/11/14(金) 11:38:08.99ID:HTFWgUOI

>>757
"JAP"呼ばわりにマナーがあるのかよ、遺伝子障害のトンスラー

0760デフォルトの名無しさん

2014/11/14(金) 11:59:56.20ID:bBfVN72A

めんどくさいしキモチワルイからなんにでも朝鮮からめてくるなよハゲ

0761デフォルトの名無しさん

2014/11/14(金) 16:51:51.19ID:9h3dP9ft

>>750
俺様を誰だと？ｗ

0762デフォルトの名無しさん

2014/11/14(金) 16:53:33.92ID:pj9oji6u

>>761

推薦図書/必読書のためのスレッド 74
588 ： ◆QZaw55cn4c [sage]：2014/11/13(木) 21:11:12.54 ID:uOTGwQ1c
>>585
C/C++ はなんといっても「ポインタ」の存在が重要
C/C++ は変数の格納領域（スタックかヒープか）を常に意識しなければならない
C/C++ にはGC はなく、new したものは自分で delete しなければならない、というか、delete を適切に置けなければ C/C++ の意味がない
【初心者歓迎】C/C++室 Ver.93【環境依存OK】
618 ：デフォルトの名無しさん[sage]：2014/11/13(木) 21:39:30.68 ID:uOTGwQ1c
>>616
GCは強力だからね‥
ATL/WTL Part7
272 ：デフォルトの名無しさん[sage]：2014/11/13(木) 22:44:06.22 ID:uOTGwQ1c
MFCもただの時代か？
GCは失敗。メモリは自分で管理せよ！
747 ：デフォルトの名無しさん[sage]：2014/11/13(木) 22:49:05.91 ID:uOTGwQ1c
ルールと書くと「それは誰が決めたの？」といわれるからね、「マナー」は主体がないからお気楽に使う奴らが多いね、
で、プログラミングのマナーってたとえばどのようなもの？>>744
GCは失敗。メモリは自分で管理せよ！
749 ：デフォルトの名無しさん[sage]：2014/11/13(木) 23:25:10.56 ID:uOTGwQ1c
そういうのはオレオレアロケータでラップすれば解決できる話

0763デフォルトの名無しさん

2014/11/14(金) 19:33:54.10ID:ZvhoBJvC

犬＝デル男＝無職Winは、やっぱり朝鮮人だったの？

0764デフォルトの名無しさん

2014/11/14(金) 22:43:01.55ID:0NdzO4Gj

巣に帰れ

0765デフォルトの名無しさん

2014/11/19(水) 00:22:30.96ID:XpwFg3dD

医療プログラマーが超高難易度の免許制に　／　フリーソフトやオープンソースの無作為配布も全面禁止
http://fox.2ch.net/test/read.cgi/poverty/1416286592/

0766デフォルトの名無しさん

2014/11/28(金) 05:58:50.67ID:NEjj49Dw

>>765
？

0767デフォルトの名無しさん

2014/11/29(土) 00:04:22.19ID:+lO93JWx

>>756
スマートポインタ型同士で内包する生のポインタを共有したり譲りあったりすると一気に破綻する
ヒープオブジェクトの所有権とか解放責任を細かく管理したいときは生のポインタの方が楽かもね

0768デフォルトの名無しさん

2014/11/29(土) 01:18:01.93ID:LkFcK9EV

>>767
所有者以外がウィークポインタ使えば済む話じゃね？

0769デフォルトの名無しさん

2014/12/16(火) 09:39:36.73ID:7mh816Ug

ウイークポインタは甘え

0770デフォルトの名無しさん

2014/12/16(火) 11:31:37.70ID:sfpQIcv2

freeしないのは甘え

0771デフォルトの名無しさん

2014/12/16(火) 12:03:39.06ID:7mh816Ug

やはりgcは甘えだったようだな
boehmとか不要だった

0772デフォルトの名無しさん

2014/12/16(火) 12:40:19.81ID:e7BH2hjc

ということにしたいのですね

0773デフォルトの名無しさん

2014/12/17(水) 16:49:30.80ID:Q6JaUBJU

ヒープ管理実装技術はあくさんあるけど
ヒープ利用技術は宗教ばかりなのはなぜ？

0774デフォルトの名無しさん

2014/12/17(水) 18:13:18.99ID:HHNVnNJE

.NET自体が宗教

0775デフォルトの名無しさん

2014/12/19(金) 06:36:24.08ID:VhJmm+7E

GC環境でも、自分で解放処理を入れる
が正しいわけか

0776デフォルトの名無しさん

2014/12/19(金) 19:07:33.27ID:NKhHFSHt

そんな GC があるのか？

0777デフォルトの名無しさん

2014/12/19(金) 19:09:46.47ID:WeOUNQD7

別にGcnewして確保したものでもDeleteすればえぇんやで

0778デフォルトの名無しさん

2014/12/19(金) 19:37:18.70ID:l1Xa7EUK

GCライブラリを2重解放や解放忘れチェッカーとして使う？

0779デフォルトの名無しさん

2014/12/19(金) 19:57:54.17ID:NKhHFSHt

C++/CLI でしかつかえないんでしょ？

0780デフォルトの名無しさん

2014/12/19(金) 21:43:56.82ID:rAA+xYtY

GCと非GCメモリ管理を混在出来ないのってスクリプト言語ぐらいじゃねーの

0781デフォルトの名無しさん

2014/12/20(土) 00:36:54.87ID:XQnyrT4E

本当に自前でdeleteを呼ぶ必要があるんでしょうか
gcメソッドを呼ぶんじゃ駄目なんでしょうか

0782デフォルトの名無しさん

2014/12/20(土) 06:12:41.60ID:K1XVQPE7

>>776
boehmちゃん！

0783デフォルトの名無しさん

2014/12/20(土) 11:56:28.60ID:NHI2U8yT

混在させて混乱無く管理できるプログラマ様、流石ですわ、とかいう流れ？

0784デフォルトの名無しさん

2014/12/20(土) 19:08:06.41ID:n7PPC6JL

ヤバそうなのから開放していけばいい

0785デフォルトの名無しさん

2014/12/21(日) 14:21:35.70ID:vbD8hcbj

ヤバそうなのは開放しない

0786デフォルトの名無しさん

2014/12/21(日) 15:38:56.53ID:qczjiP1Y

GCとdeleteを両立しても結局ダングリングポインタとか怖いから基本GCに任せようって事になりそう

0787デフォルトの名無しさん

2014/12/21(日) 16:05:40.72ID:optiUlKX

ネット上サンプル見ると参照は一時変数で持たして勝手に開放
コア部分じゃなければそれが正解だろう

0788デフォルトの名無しさん

2014/12/21(日) 16:50:14.63ID:2iwIfbgZ

gcnewしたオブジェクトをメッセージに乗せて他のスレッドへ投げた場合、GCは正しくオブジェクトの寿命を把握できるの

0789デフォルトの名無しさん

2014/12/21(日) 16:51:20.06ID:e2fIb+kJ

その「参照」という言葉だけれども、いいかげんにもうそういう使い方はやめないか？

>>786
要らなくなったら初期化、を徹底すればいい、多少無駄だがしかたがない

0790デフォルトの名無しさん

2014/12/21(日) 19:18:20.08ID:qczjiP1Y

>>789
ポインタと参照先が1対1ならそれで十分なんだろうけど
複数のポインタが同じアドレスを参照してる場合だと全部初期化するの面倒だしミスが起こりそう

0791デフォルトの名無しさん

2014/12/21(日) 23:27:04.03ID:UQ1FARTY

>>787
そもそも確保・解放がenter・leaveに単純に対応してるならmallocなどせず、
ローカル変数で直接、値で作ればいい。

スタックが足りなくなるとか混ぜっ返す組込み屋には、ハイハイ組込み組込みと
返しときゃいいんだよ。

0792デフォルトの名無しさん

2014/12/21(日) 23:27:55.55ID:UQ1FARTY

> その「参照」という言葉だけれども、いいかげんにもうそういう使い方はやめないか？

そうだね。特に C++ にはテクニカルタームとして「参照」があるから。

0793デフォルトの名無しさん

2014/12/22(月) 00:30:52.55ID:VRBNRD9f

だけど、代替になる表現ってあるのかな
ポイント、だと逆にポインタが前提の感じがしてしまうし

0794デフォルトの名無しさん

2014/12/22(月) 01:04:52.22ID:+BOkQn0H

>>791
スタック足りなくなるような組込RTOS案件にはGCなんか出てこないから心配ない

0795デフォルトの名無しさん

2014/12/22(月) 07:14:04.27ID:t6bC3Afj

GCってヒープ上に参照を持たせておくと勝手に途切れたと判断されそ

0796デフォルトの名無しさん

2014/12/22(月) 11:14:21.13ID:vmBo1gPk

だからコンサバGCの実装は苦労しとるんじゃないか

0797デフォルトの名無しさん

2014/12/22(月) 15:08:39.33ID:3ldau/FD

ばかばっか

0798デフォルトの名無しさん

2014/12/22(月) 22:23:28.06ID:3C7mXd7r

>>792
C++ だけではない、教育用途言語 pascal にもあるくらいだ‥

0799デフォルトの名無しさん

2014/12/22(月) 22:52:39.45ID:ChKJ/CvN

pascalは死んでpythonは流行った
なんでdelphiにgcつけなかったんだろ

0800デフォルトの名無しさん

2014/12/22(月) 22:57:06.11ID:7s6/x5ix

いらないから

0801デフォルトの名無しさん

2014/12/22(月) 23:02:34.56ID:+BOkQn0H

>>799
GCなんて無駄な物付けて全体の実行速度落とすかしないでしょ、それに.NETとはもう決別したんでしょ

0802デフォルトの名無しさん

2014/12/22(月) 23:05:15.85ID:18uotQck

gcの付けなかったdelphiは死んでgcのあるjavaやC#は生き残った

0803デフォルトの名無しさん

2014/12/22(月) 23:12:00.05ID:jgCJLzel

>>802
C/C++「」

0804デフォルトの名無しさん

2014/12/22(月) 23:12:10.07ID:+BOkQn0H

DelphiはBorland Pascalから生まれ変わった直後は勢いがあったが、使えないインテリセンスの糞IDEとホームラン級のぼんくらオンラインヘルプのせいで一気に人気が失せた

0805デフォルトの名無しさん

2014/12/22(月) 23:50:21.66ID:vmBo1gPk

>>798
同じ言葉を使ってるからといって同じものじゃないが。

0806デフォルトの名無しさん

2014/12/23(火) 10:32:32.83ID:xE/EZEvs

>>804
あれは無駄に機能増やして鈍重化したのもあると思う

…と言うか一番は、個人開発者に人気だったのに
エンタープライズメインに切り替えて個人開発者軽視したことじゃないかな

0807デフォルトの名無しさん

2014/12/23(火) 10:36:15.47ID:XytUgotQ

懐かしいな。
当時Delphiって聞くとなんというか、ときめきのようなものを感じてた。
C++Builderとかコードウォーリアーとかなつい。

0808デフォルトの名無しさん

2014/12/23(火) 11:29:30.67ID:S/HWfghB

>>807
C++Builder は頑張れば C# の地位になれたと思う

0809デフォルトの名無しさん

2014/12/23(火) 11:35:28.11ID:h/pRl+lt

c#てmsアプリ作成用ツールのスクリプトやん

0810デフォルトの名無しさん

2014/12/23(火) 12:40:52.69ID:BmzYTsD1

Win3~3.1当時MSはまだQuickC For Windowsだった時に、Turbo PascalとTurbo C++のWin版をいち早く導入しのがBorland

その頃のアプリ開発環境はBorlandの方が進んでた

VBの登場とMSDNでの囲い込みで徐々に形成逆転したのかな

0811デフォルトの名無しさん

2014/12/23(火) 14:32:44.54ID:egk/n0nz

>>809
c言語って組込み用アセンブリ出力させるためのスクリプトじゃん

0812デフォルトの名無しさん

2014/12/23(火) 14:53:25.17ID:t58aH8JT

C#てunityなんかでも使われてるし、今やMS専用っていう感じでもないかも

0813デフォルトの名無しさん

2014/12/23(火) 21:42:05.30ID:vkaSmtMb

win鯖が嫌じゃなければwebでも十分使える
MVCとかEFとかフレームワークも充実してるし

0814デフォルトの名無しさん

2014/12/24(水) 01:00:29.67ID:+eSW33ht

きも

0815デフォルトの名無しさん

2015/01/30(金) 11:04:08.94ID:Tg9FBOLX

.netもC#コンパイラもとっくにOSSになってるのに
なんでそんなに毛嫌いするんだ？

0816デフォルトの名無しさん

2015/01/30(金) 14:03:24.80ID:7u+Ygwkn

ストップ座ワールドがなくなればGCマンセー

0817デフォルトの名無しさん

2015/01/30(金) 19:18:19.16ID:2guE8F7N

RubyとかPHPって実質Win鯖で使えないからLinux専用だろ
こんなんでC#がクロスプラットフォームじゃないとか批判してるのはお笑い

0818デフォルトの名無しさん

2015/01/31(土) 06:23:21.40ID:nEfu9fTE

え、つかえますけど

0819デフォルトの名無しさん

2015/01/31(土) 20:29:07.26ID:3AAhUm85

コンパクションで固まるのは単にリソースが足りてないからでしょ。
32bit CPUでもメモリさえ潤沢ならよほどのことがないと固まらない。
それでも不足なら64bit CPUと大量のメモリで解決できる。

0820デフォルトの名無しさん

2015/02/01(日) 14:00:44.74ID:sjXjc1T+

よほどのことがあっても固まらないようにして下さいお願いします

0821デフォルトの名無しさん

2015/02/01(日) 16:03:02.87ID:aI2n/lTk

そういやARCってApple以外やってないよな
GCの諸問題のうち、特に停止問題を重視するならARCってけっこう手軽な現実解だと思うんだけども

0822デフォルトの名無しさん

2015/02/01(日) 16:34:50.09ID:MVlYWEMF

たまたまobjcに向いてるだけじゃないのかなあ。
ARCが全部を管理してるわけじゃないし、
全部を管理するなら参照カウント型のGCそのものだよね。

0823デフォルトの名無しさん

2015/02/01(日) 16:51:21.20ID:Fr1bqegO

ARCというかautoreleaseはGUIのように明確なイベントループが存在するような
プログラム構造じゃないと使いにくいからだろう。
CocoaフレームワークあってのARC/autoreleaseなわけで。

0824デフォルトの名無しさん

2015/02/01(日) 21:31:23.15ID:ZIbzlngg

>>821
Delphi/C++Builderのモバイル用コンパイラもARC。iOSだけじゃなくてAndroidでもARC。

0825デフォルトの名無しさん

2015/02/02(月) 00:35:02.66ID:VwUQhlCU

>>824
寡聞でしたすみません勉強になります

0826デフォルトの名無しさん

2015/02/10(火) 14:25:51.02ID:NjPy1BDR

>>821
参照カウンタ式はプログラマが循環参照の問題を
意識してコーディングしなきゃならない。
新言語やGCの無かった言語への追加機能ならともかく、
循環参照なにそれweakなんて知らんよでやってきた言語に
ぽいっと追加するわけにはいかないんだろうな。

循環参照はマズイから必要なら weak 参照使えその代わり
GC で止まらないぞ、っていう Java も Google あたりが出せば
普及する気もするけど…

0827デフォルトの名無しさん

2015/02/16(月) 23:54:59.92ID:dr44zIpp

確かに、GameCubeは失敗だった。

0828デフォルトの名無しさん

2015/02/17(火) 01:45:26.73ID:ICEN75ja

つまんね！絶対ハゲてるわお前！

0829デフォルトの名無しさん

2015/03/18(水) 00:04:55.11ID:kd3iUKLL

>>826
Xcode付属のメモリモニターツールが強力で循環参照しているオブジェクトを
一発で見つけられる。そういうのがないとC言語のMalloc/Free張りに嵌るかもね。
昔、OmniWebとかよく落ちていたし。

0830デフォルトの名無しさん

2015/04/08(水) 20:23:11.17ID:2PDo66DT

GCがないhaskellとかやってみたい

0831デフォルトの名無しさん

2015/04/08(水) 20:26:31.03ID:Q0GkT+QT

GCで変な技術者が増えたような気がする

0832デフォルトの名無しさん

2015/04/09(木) 14:12:21.41ID:DeN9c2ta

C#で頑張ってリソース管理してるけど、終了時のフィナライザでエクセプション起こしてメモリー確保して解放済みの処理呼び出しっておい。

0833デフォルトの名無しさん

2015/05/19(火) 21:59:26.30ID:X2H7PVvq

http://blogs.msdn.com/b/visualstudio_jpn/archive/2015/04/29/net-announcements-at-build-2015.aspx

ガベージコレクターの更新

ガベージコレクターの新しいモードでは、
メモリに関連した特定の状況下ではガベージコレクションを行いません。
この新しいモードは、少なくとも
GC CPU の使用に関連する連続した計算が必要なワークロードで重要です。

新しいモードでは、No GC Region に入る前提条件として
使用可能な特定のメモリ容量を指定することができます。
No GC Region では、ガベージコレクションは行われません。
GC.Collect などでコレクションが明示的に要求された場合や、
最初に指定したメモリ容量が不足した場合にガベージコレクションが開始されます。

新しいモードには複数の構成ポイントがあり、No GC Region 内で使用して小さなオブジェクトヒープと
大きなオブジェクトヒープに別々に使用できるメモリを指定することもできます。

0834デフォルトの名無しさん

2015/06/08(月) 22:17:10.53ID:WDSTv9CT

メモリ管理のためのコードを入れると、業務ロジックが読みにくくなっちゃうからGCにお任せでいーや。

0835デフォルトの名無しさん

2015/06/09(火) 05:13:26.11ID:GoGfc5xm

確保して解放するだけじゃん。
参照カウンタとかレベルになるともうGCでいいやってなるけど

0836デフォルトの名無しさん

2015/06/10(水) 20:09:12.46ID:H0fWrTpT

>>834
ラップしたクラスでえぇやないの、一回は経験した方がいい

0837デフォルトの名無しさん

2015/06/14(日) 00:00:44.30ID:mJCRiql2

高級言語だけじゃ手に負えずC++使った結果メモリリークだらけになってたプロジェクトがあった。
C++使用は不可避だが、技術者のほとんどがメモリを面倒見切れなかった。
仕事なんだから勉強しようよ

0838デフォルトの名無しさん

2015/06/14(日) 12:29:02.48ID:Iu9IjEax

C++使うとCよりメモリリークしそう

0839デフォルトの名無しさん

2015/06/14(日) 17:42:43.85ID:IljfXwE2

>>838
ちゃんとデストラクタ・RAII使えばそんなことにはならない。

0840デフォルトの名無しさん

2015/06/14(日) 21:39:41.12ID:kYk1Egwl

解放忘れとかそういうコードは絶対他にも必要な宣言なりを忘れてるから危険だよなw

0841デフォルトの名無しさん

2015/06/18(木) 16:51:28.49ID:z2QMHecM

不要になったら強い参照が切れるようにしないとGC意味ないやん

0842デフォルトの名無しさん

2015/08/16(日) 10:48:06.69ID:GM3HFxJz

C/C++みたいにメモリ解放を明記できる言語って他に何が有るだろう
スマホアプリ開発でそれができる言語はあるのだろうか

0843デフォルトの名無しさん

2015/08/16(日) 11:01:46.23ID:dOWpBwV8

全部NDKで作れば？

0844デフォルトの名無しさん

2015/08/16(日) 16:38:33.96ID:n3y5gwZb

>>842
Delphi「…。」

0845デフォルトの名無しさん

2015/09/16(水) 10:58:10.00ID:kzJo4y5o

C++の20倍速いJavaでさえモッサリなのはGCのせいだろ。

0846デフォルトの名無しさん

2015/09/23(水) 19:20:36.84ID:OG7e8mvp

Flashのゲームが遅くなるんだけど
これ関係ある？

0847デフォルトの名無しさん

2015/09/26(土) 20:21:02.25ID:ah/jTrX4

Flashは元から処理効率悪い感じ
CPUパワーでゴリ押しするしかない

0848デフォルトの名無しさん

2015/10/01(木) 19:08:03.50ID:TrZJtSkW

flashのscript部分は似非javascriptだったような

0849デフォルトの名無しさん

2015/10/30(金) 16:44:42.54ID:JduWWFlH

ActionScriptだね。静的型付けとクラス拡張されたあたりで似非ともJavaScript風とも言えなくなったけど

Flashの重さって言語やGCよりレンダリング周りだと思う。ブラウザ上というOSのサポート受けにくいところでマルチ環境サポートしてるから無理もないけどね

0850デフォルトの名無しさん

2015/10/30(金) 18:43:36.28ID:l8pLYr5T

このスレみてしばらく考えてたけど…
LLぐらいならGCもありだと思うけどJavaやC#でGC導入したのは
確かに失敗だったと感じた
特にJavaはサーバーサイドでもよく使われるしGCのせいで安全性を失い不安定になってたら本末転倒
JavaがGCを導入して、所有権の概念を放棄したことで失ったものとして
スコープに閉じられたファイナライザ(RAII)、
値型とオブジェクト型に対する一様な操作性、
自動かつ一様なコピー、メモリ安定性…などなど色々あって、
逆にややこしくしてる上に安全性も低くなってる
特にスコープが活用できないというのは安全性の面で致命的
C++のせいでメモリ管理は難解で危険という風潮が強いけど
それはC++の、Cとの互換性やゼロオーバーヘッドの方針が
大きく影響してて、最初からunique, share, weak, rvalue refに絞っていれば難しいものではないしより安全

0851デフォルトの名無しさん

2015/10/30(金) 20:30:59.91ID:I9q36634

GCじゃないけど、
VBAで、オブジェクトを使ったプログラミングするとき
　Set 変数 = オブジェクト
でやると最後に必ず
　Set 変数 = Nothing
をやらないと気がすまないｗｗｗ

0852デフォルトの名無しさん

2015/10/30(金) 20:49:06.93ID:zUZa21Gd

Setとかいう糞構文をなんで作ったんだろ

0853デフォルトの名無しさん

2015/10/30(金) 20:55:59.72ID:I9q36634

オブジェクト扱っちゃうぜ～
ハイカラだろ～？って感じなんでしょ。

0854デフォルトの名無しさん

2015/10/30(金) 21:06:55.81ID:KZ39TxmE

変数の型宣言があいまいなので

0855デフォルトの名無しさん

2015/10/30(金) 21:34:23.77ID:7o442mgO

結局自分で管理しるものとしなくてもいいものの峻別が必要になったな
すき放題やってると終了処理がひどい感じ

0856デフォルトの名無しさん

2015/10/30(金) 22:47:38.78ID:S9hryATs

>>854
曖昧？

0857デフォルトの名無しさん

2015/10/30(金) 22:50:03.52ID:KZ39TxmE

型宣言してるとうるさいけどね

0858デフォルトの名無しさん

2015/10/31(土) 05:16:01.52ID:VXrj8Wc8

>>857
それ Set の話と関係ないでしょ

0859デフォルトの名無しさん

2015/10/31(土) 10:58:39.37ID:1wsIrmuV

エライ方のやられることは凡人にはわかりませんがな

0860デフォルトの名無しさん

2015/10/31(土) 12:36:13.44ID:f8Ij0rc/

自分で解放処理まで入れてる人は、古い人なのかもしれないけど、総じてソース自体は非常に読みやすいし、エラーチェックもきちっとやっている。
解放処理してない人は、エラーチェックまで雑な感じがする。
根拠となる統計があるわけではないが。

0861デフォルトの名無しさん

2015/10/31(土) 13:31:15.59ID:1wsIrmuV

そんなことより数字だけのエラーメッセージを
なんとかしてくれんかな
初心者にやさしくない
どこぞの糞言語

0862デフォルトの名無しさん

2015/10/31(土) 18:35:48.73ID:YhCpXg1E

>>861
それ言語と関係ないでしょ

0863デフォルトの名無しさん

2015/10/31(土) 19:49:55.89ID:Xr/OK5J5

>>31
Lispだろ

0864デフォルトの名無しさん

2015/10/31(土) 19:55:37.90ID:Xr/OK5J5

>>78
ロジックに集中できるように
管理しないでいいようにしたんだよ。
consセルを管理しながらLispのコードを書けるか?
Javascriptの主要ライブラリを自前メモリ管理で書き直してみてくれ。

0865デフォルトの名無しさん

2015/10/31(土) 20:20:16.61ID:A2a2AvME

>>864
linked list管理しながらCのプログラム書いてますが、何か?

0866デフォルトの名無しさん

2015/10/31(土) 20:45:22.20ID:1wsIrmuV

エラーメッセージが言語と関係ない？

0867デフォルトの名無しさん

2015/10/31(土) 23:37:30.34ID:ELtLmf7b

エラーメッセージは言語仕様じゃないって事だろ

0868デフォルトの名無しさん

2015/11/01(日) 06:11:45.31ID:1jUBhaIT

GCは結局のところ問題を増やしただけだよな、、、
いや、GCが増やしたというよりメモリは参照切れたら勝手に解放やってくれるから考えなくていい。
という風にしてしまったのが間違いだったんだろう。

0869デフォルトの名無しさん

2015/11/01(日) 08:51:32.70ID:mbCEcc3w

GCにすると早くなるとか言われてましたが
先に必要なメモリを大きく確保したから．．．．

0870デフォルトの名無しさん

2015/11/01(日) 10:50:32.39ID:Q3B65vhl

メモリの解放漏れって処理を複雑に書いた時がほとんど
メモリの管理から解放されるには
　プログラムの構造をとにかくシンプルにすること
　プログラムの可読性をとにかく上げること
に尽きるような気がしてきた

0871デフォルトの名無しさん

2015/11/01(日) 10:53:00.29ID:mbCEcc3w

メモリ管理もできない人がやってるのが不思議なんですが

0872デフォルトの名無しさん

2015/11/01(日) 11:29:33.13ID:CO8H7P/Q

>>1
GC(ガベージコレクション)と同じように
PGC(ページメモリガページコレクション)も問題である

ページメモリはHDDやSSDを意味する

0873デフォルトの名無しさん

2015/11/01(日) 11:31:55.35ID:CO8H7P/Q

ゾンビスパイウェア・・・終了してもタスクマネージャーに
いつまでもプロセスが残ってゾンビ化するブラウザがあるらしい。
ゾンビ化はメモリ開放しないから再起動でメモリを食いつぶす。
http://18tv.x.fc2.com/?v=4V90AmXnguw&;UUulYu1HEIa7f70L2lYZWHOw/18TV
http://i1.ytimg.com/vi/4V90AmXnguw/mqdefault.jpg

0874デフォルトの名無しさん

2015/11/01(日) 12:03:13.03ID:CO8H7P/Q

ゾンビ化するブラウザのユーザー達を特にスリラー(Thriller)と呼んでいる

0875デフォルトの名無しさん

2015/11/01(日) 12:11:03.54ID:CO8H7P/Q

https://www.google.co.jp/search?q=%E3%82%BE%E3%83%B3%E3%83%93%E5%8C%96%E3%83%96%E3%83%A9%E3%82%A6%E3%82%B6&;num=100&ie=utf-8

0876デフォルトの名無しさん

2015/11/01(日) 15:15:46.75ID:VSkAtBKL

ブラウザクラッシャー
http://www.ammanu.edu.jo/wiki1/ja/articles/%E3%83%96/%E3%83%A9/%E3%82%A6/%E3%83%96%E3%83%A9%E3%82%A6%E3%82%B6%E3%82%AF%E3%83%A9%E3%83%83%E3%82%B7%E3%83%A3%E3%83%BC.html

0877デフォルトの名無しさん

2015/11/01(日) 15:46:56.88ID:VSkAtBKL

ゾンビウィンドウズ
https://www.google.co.jp/search?q=%E3%82%BE%E3%83%B3%E3%83%93%E3%82%A6%E3%82%A3%E3%83%B3%E3%83%89%E3%82%A6%E3%82%BA&;num=100&ie=utf-8

0878デフォルトの名無しさん

2015/11/01(日) 15:49:09.88ID:VSkAtBKL

ゾンビウイルスWERDLOD!? 添付ファイル付き迷惑メールとエメンタル作戦
http://blogs.yahoo.co.jp/fireflyframer/33432553.html

0879デフォルトの名無しさん

2015/11/01(日) 17:13:37.01ID:mbCEcc3w

なんちゃってOS限定の話？ゾンビ？

0880デフォルトの名無しさん

2015/11/01(日) 21:12:16.73ID:Q3B65vhl

この手の話題に対して
nullセットしたりしてもスグにメモリが解放されるわけではない。
って言い出す人いるけど、根本的に論点がズレてるよなぁといつも思う

0881デフォルトの名無しさん

2015/11/02(月) 04:13:15.63ID:lTmbmRfG

>>1
GC(ガベージコレクション)と同じように
PGC(ページメモリガページコレクション)も問題である

ページメモリはHDDやSSDを意味する

0882デフォルトの名無しさん

2015/11/02(月) 04:18:08.53ID:lTmbmRfG

・ISO 25000
https://nl.wikipedia.org/wiki/ISO_25010
http://iso25000.com/index.php/en/iso-25000-standards/iso-25010
http://iso25000.com/images/header-en.png
ISO/IEC25010 品質モデル　長らくソフトウェア品質モデルとして親しまれてきた ISO/IEC9126 が
ISO/IEC25010(ISO/IEC 25000 SQuaRE シリーズの一部) として補強、改訂されました
http://snsk.hateblo.jp/entry/20130422/p1
http://cdn-ak.f.st-hatena.com/images/fotolife/s/shinsuku/20130422/20130422070549.png http://cdn-ak.f.st-hatena.com/images/fotolife/s/shinsuku/20150821/20150821114857.png http://cdn-ak.f.st-hatena.com/images/fotolife/s/shinsuku/20130422/20130422070550.png

0883デフォルトの名無しさん

2015/11/02(月) 07:20:19.25ID:lVVXa7jt

>>880ほんこれ。
ココで使うのやめますよ。
というのを明示してわかりやすくする。
というが目的でやってるのに。

0884デフォルトの名無しさん

2015/11/02(月) 11:36:06.56ID:xHrq3TrF

Windows7からWindows10へアップグレードしてみた（その1）
http://www.youtube.com/watch?v=sqrYK4_55IY&;list=RDsqrYK4_55IY
Windows7からWindows10へアップグレードしてみた（その2）
http://www.youtube.com/watch?v=jIcJ3DnBtCQ&;list=RDjIcJ3DnBtCQ
windows10無償アップグレードしたら既存ソフトも問題なく動いた。互換性は？
http://www.youtube.com/watch?v=G5QblMTRoSQ&;list=RDG5QblMTRoSQ

0885デフォルトの名無しさん

2015/11/02(月) 11:36:45.06ID:xHrq3TrF

WINDOWS10はプライバシー丸取りスパイウエア＃TPP ＃ITmedia ＃NHK ＃ニコ動＃リナックス＃ウインドウズ
http://aurorawave.atspace.tv/?sop:v/ZBwEmgdqB1c&;RDZBwEmgdqB1c http://i1.ytimg.com/vi/ZBwEmgdqB1c/mqdefault.jpg #AuroraWaveTV

0886デフォルトの名無しさん

2015/11/02(月) 13:42:54.15ID:0X8mwavh

なんちゃってクラウドOS
覗かれまくり？

0887デフォルトの名無しさん

2015/11/03(火) 18:54:10.92ID:UaU3DexI

>>883
下手くそはそこまで思考は回らない

0888デフォルトの名無しさん

2015/11/03(火) 19:06:56.99ID:cqWeRJO4

>>850だけどRustのメモリ管理がイメージにかなり近いな
メモリセーフかつ、同期が必要なもののみ識別できる仕様なのでC++より速くなるおまけつき
Rustいいわこれ

0889デフォルトの名無しさん

2015/11/03(火) 19:40:05.40ID:BP9FbeAH

スマートポインタ自作するの楽しいです(^ ^)

0890デフォルトの名無しさん

2015/11/06(金) 09:12:46.09ID:elYX0nut

deleteで意図的にデストラクタが発動するC++/CLIが最強ってことで

0891デフォルトの名無しさん

2015/11/06(金) 19:14:19.26ID:XATvt4ap

GCが失敗というより、GCが登場してから「メモリ管理をしなくていい」というふうに広めてしまったのが大失敗だったんではないだろうか？

0892デフォルトの名無しさん

2015/11/06(金) 19:45:29.43ID:dYcAh74V

GCという名付けが失敗
ゴミ集めなんてまず社会の最低辺の職業？を連想してしまうし
ゴミ集めは結果的に起こるものであって、それが目的ではないのに
手段としてのGCばかりが注目されてしまった

0893デフォルトの名無しさん

2015/11/06(金) 21:27:35.02ID:KbACg+rI

>>1
malloc / free の問題を別の問題にすり替えただけかもね
GCのおかげでコーディングは楽になったんだけど

0894デフォルトの名無しさん

2015/11/07(土) 00:08:44.08ID:4rC6rLR0

沢山の言語を使ってきたけど、C/C++は使っていなかった。
だから殆どの言語でGCがあるのが普通であり、C/C++だけ特異な言語という印象。

0895デフォルトの名無しさん

2015/11/07(土) 00:45:30.50ID:5oXh6/d1

まあおっしゃる通りかと
ネイティブ寄りでGC使ってないところで有名どころというとARCやってるAppleくらいかな？obj-cとswift
obj-cはMac開発環境では一時期GC試してたけどね

0896デフォルトの名無しさん

2015/11/07(土) 11:25:53.08ID:D4Pma+c4

mallocしたらfreeしなさい。

こっちの意見のほうが正しかったと遠く時は流れて証明されたということなんだろうね。

0897デフォルトの名無しさん

2015/11/07(土) 11:32:16.48ID:Lam93S6q

javaってcore2とかcoreiになっても糞遅いんだが
どういう事だよ…オラクル！

0898デフォルトの名無しさん

2015/11/07(土) 18:00:07.40ID:D4Pma+c4

プログラミング入門として始める人にマネージドとかアンマネージドとか意識させるGCって一体なんだろう・・・。

0899デフォルトの名無しさん

2015/11/08(日) 00:26:03.18ID:QYMRsb+2

どっちにしろソケットだったり重要な資源は管理せにゃならんのだから
メモリもついでにやったらいいさ。

0900デフォルトの名無しさん

2015/11/08(日) 00:28:30.61ID:ZvdbGqm7

むしろメモリーを１００ペタバイトくらい積めばメモリー管理なんていらんのではないだろうか？

0901デフォルトの名無しさん

2015/11/08(日) 01:12:31.37ID:hMKFsgJi

>>900
そんな中途半端な数字じゃなくて
メモリが無限にあればって言えばいいじゃんｗ

0902デフォルトの名無しさん

2015/11/08(日) 01:16:43.93ID:ddjlcS4O

ゲイツが「メモリは640kbもあれば充分だ」と言った話を思い出すなあ
無論そりゃ当面足りるだろうけどさ、現時点で技術的にもコスト的にも無理な話されても困るよ

100ペタ使える時代が来たとして、その時代のプログラマー達は、640kbで足りてない我々のように「100ペタじゃ足りねー」って言ってる気がするなあ
そんときGCがあるのか知らんが

0903デフォルトの名無しさん

2015/11/08(日) 01:33:34.82ID:RsBJWU9a

Ｄ使え。ＣＧもＲＡＩＩも両方ある。

0904デフォルトの名無しさん

2015/11/08(日) 02:08:20.95ID:hMKFsgJi

>>902
> ゲイツが「メモリは640kbもあれば充分だ」と言った話を思い出すなあ

それ言ってないらしいよｗ

0905デフォルトの名無しさん

2015/11/08(日) 02:19:05.00ID:ddjlcS4O

まじかよw

0906デフォルトの名無しさん

2015/11/08(日) 02:22:06.24ID:hMKFsgJi

http://pc.watch.impress.co.jp/docs/2005/0427/hot367.htm

　「640KBのメモリがあれば十分なはずだ」なんてことを言った覚えはないんだけど。

　2005年のWinHECは、ビル・ゲイツ会長のこんなジョークともボヤキとも受け取れる言葉で始まった。

0907デフォルトの名無しさん

2015/11/08(日) 02:24:29.04ID:hMKFsgJi

http://mobile.srad.jp/comments.pl?sid=585321&;cid=2276416

> 実際に彼がそう発言したというソースは一度も示されたことがない。
> どころか、1980年代からの彼の発言 (例えば以下のスピーチ) は一貫して「もっとメモリを」と言い続けてる。
> http://csclub.uwaterloo.ca/media/1989%20Bill%20Gates%20Talk%20on%20Mic... [uwaterloo.ca]
>
> まあ、一度も彼の発言なんか聴いたことないんだろうけどね。

0908デフォルトの名無しさん

2015/11/08(日) 02:27:20.34ID:ddjlcS4O

あらまさかの本人の弁明があったんですねw
興味深い。覚えときますthx
関係ないけどLonghorn当時のの記事内容も感慨深いなぁ

0909デフォルトの名無しさん

2015/11/08(日) 07:33:41.97ID:QfP+cajQ

GCできてからほんとにメモリの管理が異常に複雑になったよね・・・
なんだよ世代って

0910デフォルトの名無しさん

2015/11/08(日) 07:44:18.27ID:hMKFsgJi

>>909
お前はなにか勘違いしてるぞ。

たしかに一部のプログラム言語開発者にとっては複雑になったよ。

でも、その他大勢のプログラム言語利用者にとっては
凄くシンプルになった。

世代とか考える必要があるのは一部の人間だけだ。

0911デフォルトの名無しさん

2015/11/08(日) 07:52:51.14ID:QfP+cajQ

>>910
考える必要があるのか考えないといけない。
ということを入門者にも教えないといけない。

0912デフォルトの名無しさん

2015/11/08(日) 07:56:36.28ID:hMKFsgJi

>>911
でもさ、mallocの実装のことを
お前何も考えてないだろ？

都合がいい解釈すんなよ。最初から悪く言おうしてるから
考えなきゃいけないと言ってるんだよお前は。

なんでも考えなきゃいけないと思ってるなら
mallocの実装も考えろや。

0913デフォルトの名無しさん

2015/11/08(日) 09:33:56.19ID:QfP+cajQ

>>912
mallocで確保したらfreeしろ。
シンプルだろ。

0914デフォルトの名無しさん

2015/11/08(日) 12:02:23.40ID:3P/yTrZ9

>>909
GCのせいじゃない
GCに頼りきった設計やライブラリのせいだ

0915デフォルトの名無しさん

2015/11/08(日) 12:54:20.40ID:bAE0co8c

GCってfreeしなくていいじゃん

たまに循環参照が解放できない糞GCがあったりするけど

0916デフォルトの名無しさん

2015/11/08(日) 13:45:11.50ID:FmnDkrXh

手動でやるべきものを自動でやるからおかしくなるわけで
ただそれだけのことであろう

0917デフォルトの名無しさん

2015/11/08(日) 14:30:26.34ID:QYMRsb+2

GC で管理するオブジェクトにはGC するオブジェクトをコンストラクト時に明示的に引数で
与えるようなインターフェイスならどうなのかね。
暗黙的に使うから問題あるわけで意識的な使い方すればそこまで問題にはならんでしょ。

0918デフォルトの名無しさん

2015/11/08(日) 17:41:16.43ID:ROw1VB+l

GCを利用するか否かで、設計はもちろん在るべき言語仕様も大きく変わるので
共存させるのは無駄に煩雑な言語になると思う

0919デフォルトの名無しさん

2015/11/08(日) 19:47:48.08ID:hMKFsgJi

>>913
> mallocで確保したらfreeしろ。

それは使う側の話だろｗ

GCの場合だったら、
何もする必要はない
で終わりだｗ

> たまに循環参照が解放できない糞GCがあったりするけど
mallocで循環参照してると悲惨ですよ。
freeしてるところにアクセスしたりする。

0920デフォルトの名無しさん

2015/11/08(日) 19:52:51.52ID:hMKFsgJi

mallocって複雑だよ。なんでこんな複雑な管理が必要なんだ？
http://radlon.github.io/blog/2014/08/25/krmalloc/

0921デフォルトの名無しさん

2015/11/08(日) 21:42:32.79ID:ROw1VB+l

そりゃなるべく断片化を避けつつ高速に確保するように考え尽くされてるからな

0922デフォルトの名無しさん

2015/11/08(日) 21:45:17.45ID:QYMRsb+2

>>918
確かに。。ちょっと自分で書いてあほだなと思った。

0923デフォルトの名無しさん

2015/11/08(日) 22:03:29.93ID:ROw1VB+l

>>922
C++CLIという先駆者がいるから安心していいぞ

0924デフォルトの名無しさん

2015/11/08(日) 22:36:50.70ID:HlEs+VqN

MSがC++/CLIをフェードアウトさせようとしているのがつくづくもったいない。
「無駄に煩雑」なのは否定しないが。

0925uy ◆Qawu9.2l1E

2015/11/09(月) 12:40:10.71ID:VP0GkkkJ

C++にスクリプト言語を乗っける手法から
スクリプト言語からC++で書かれたライブラリを使用して開発、それで速度が十分過ぎる

0926デフォルトの名無しさん

2015/11/09(月) 15:20:43.01ID:xsh7xTs1

JavaScriptのGCはどうなの？　Chromeとか　Firefoxとか

0927デフォルトの名無しさん

2015/11/09(月) 15:39:32.58ID:xsh7xTs1

Illuminati
http://www.amazon.com/dp/1556343744
http://ecx.images-amazon.com/images/I/91%2BnrxMSj9L._SL1500_.jpg
http://ecx.images-amazon.com/images/I/81ztOxENYcS._SL1500_.jpg
http://ecx.images-amazon.com/images/I/91M0809E%2B2L._SL1500_.jpg
http://ecx.images-amazon.com/images/I/919cSwq%2BZGL._SL1500_.jpg
http://ecx.images-amazon.com/images/I/61-slOQ1QEL.jpg

0928デフォルトの名無しさん

2015/11/09(月) 16:24:21.08ID:xsh7xTs1

フェーズ
http://aurorawave.atspace.tv/?sop:v/EfVSvrKkoWM&;RDEfVSvrKkoWM http://i1.ytimg.com/vi/EfVSvrKkoWM/mqdefault.jpg #AuroraWaveTV

0929デフォルトの名無しさん

2015/11/09(月) 17:49:03.09ID:jDVf3Lh4

>>917
次にお前は
オブジェクト ngc がオブジェクト gc への参照を持てない！　クソすぎる！
と言い出す

0930デフォルトの名無しさん

2015/11/09(月) 22:00:03.15ID:xsh7xTs1

Chrono Cross - Radical Dreamers / クロノ・クロス盗めない宝石
http://aurorawave.atspace.tv/?sop:v/HIri1484iQ0&;RDiEGniXc7Xtc http://i1.ytimg.com/vi/HIri1484iQ0/mqdefault.jpg #AuroraWaveTV

0931デフォルトの名無しさん

2015/11/11(水) 21:12:56.53ID:0UF1mzoB

>>919
何もする必要がないのに、なぜメモリリークの文献が新しく生まれてるの？と>>1が言ってる

0932デフォルトの名無しさん

2015/11/11(水) 21:32:16.69ID:FCPmsKYk

>>931
昔はどこからも参照されていないのにメモリが
使われてる状態をメモリリークって言ってたんだけど、

今は、意図せずどこからか参照されてしまっている
メモリまでメモリリークと言い出したから。

0933デフォルトの名無しさん

2015/11/11(水) 21:57:55.18ID:yiYjUqQw

>>932
循環参照してりゃ、不用になってもメモリーリークじゃないと言う主張か
斬新だな

0934デフォルトの名無しさん

2015/11/12(木) 16:38:49.33ID:+fz8NmqL

GCは、メインメモリしか、面倒を見てくれない
それ以外のリソースは自分でcloseなり
オブジェクトの生存期間を考えて色々しなければならない
殆どのオブジェクトはメモリだけのリソースということは少なく
色々なものをコンポジションしまくってるから
クラスを使うときも自作するときも開放処理に気を遣わなければならない
C++のデストラクタ方式は良くできている

0935デフォルトの名無しさん

2015/11/12(木) 16:44:45.32ID:+fz8NmqL

とにかく、メモリの管理だけに限ればGCは良くできている
最近のコンピュータはメモリを沢山積んでいるし
オブジェクトが要らなくなってからGCが発動して開放されるまで
多少のタイムラグがあっても問題ない
しかし、メモリ以外のリソースについては
必ずしもそうではないので、そういう場合は
C++のデストラクタ方式の方が便利だったりする
GCがいつ発動するかわからないという不安要素は
処理の実行順番が何より重要な手続き型言語と
相性が悪い

0936デフォルトの名無しさん

2015/11/12(木) 19:00:06.71ID:ZBkPHyAT

どちらでも使えるC++のCLIが最強ってことです

0937デフォルトの名無しさん

2015/11/12(木) 19:57:40.83ID:cV52juFM

使ってる人いるんだそれ(ﾟдﾟ)

0938デフォルトの名無しさん

2015/11/12(木) 21:07:14.95ID:WDhKVAtb

普通のポインタの他にgcポインタがあったりデストラクタの他にファイナライザがあったり
ごちゃごちゃした言語だと思ってたけど、C++11見てたら気にならなくなったｗ

0939デフォルトの名無しさん

2015/11/12(木) 22:02:53.38ID:GaR/agwA

それはそれでどこか病んでる。

0940デフォルトの名無しさん

2015/11/12(木) 22:48:04.06ID:WDhKVAtb

そういう人間じゃないと今のC++にはついていけんだろう

0941デフォルトの名無しさん

2015/11/12(木) 22:59:09.59ID:+fz8NmqL

後個人的にGCについて思う事は
GCはメモリ管理が主だから、メモリ使用量は常に監視していて
足りなくなったらGCが発動したりと完全に管理してくれているわけだが
現実にはメモリより先にメモリ以外のリソースが足りなくなるケースの方が
ありえるわけで、メモリ以外のリソース使用量も監視してくれなくては
本当に安心しては使えないといえる

0942デフォルトの名無しさん

2015/11/12(木) 23:00:02.31ID:+fz8NmqL

実際には問題になるケースは殆どないんだろうが
メモリ使用量だけを監視するというのは完璧じゃない

0943デフォルトの名無しさん

2015/11/12(木) 23:47:00.19ID:UQPi/g2N

今は適切にプロセスを分ければリソースごとOSが管理してくれるでしょうに

0944デフォルトの名無しさん

2015/11/12(木) 23:58:58.37ID:FwVQMCtV

メモリ使用量なんて気にしてないGCもあるぞ
pythonなんかインスタンス数で判定してるし

0945デフォルトの名無しさん

2015/11/13(金) 09:57:22.27ID:qBXsv8h8

>>932
プログラムは意図したとおりには動かない。書いたとおりに動く。の法則は昔からかわってないはずだが？

0946デフォルトの名無しさん

2015/11/13(金) 11:54:45.16ID:zBmTWyFy

JavaとともにGCが主流に飛び出たのは
32bitCPUが一般化してメモリ64MBのオモチャPCが売られてた頃

64kBの専用領域を使い切ると「メモリが足りません」とぬかす
オモチャＯＳが主流だった頃

0947デフォルトの名無しさん

2015/11/13(金) 14:06:20.59ID:b0J0ZgfW

だからなに？

0948デフォルトの名無しさん

2015/11/13(金) 20:51:38.53ID:sHuRt5Cq

>>1が言いたいのは、GCそのものを批判しているのではなく、
メモリやらファイルやら使ったら解放や後片付けまできちっとやる教育をしないから
結局、参照が途切れてない。意図したタイミングで参照を維持できていないなどのバカなことをしてしまう
プログラマを育成してしまう。
そんな状態を作るくらいならGCはやめちまえ。ってことを言いたいんじゃないの？

0949デフォルトの名無しさん

2015/11/13(金) 21:09:40.11ID:+1eGYaPq

そんなことは一言もかかれてないのに
どうしてそういう妄想ができるの？

0950デフォルトの名無しさん

2015/11/13(金) 22:13:58.50ID:sHuRt5Cq

普通にそう読み取れるけど？

0951デフォルトの名無しさん

2015/11/13(金) 22:30:12.90ID:+1eGYaPq

国語の点数悪かったでしょ

0952デフォルトの名無しさん

2015/11/13(金) 23:13:07.98ID:BL0hnrCW

そう読み取る奴が多い方が良い世の中になりそうだけど。

0953デフォルトの名無しさん

2015/11/14(土) 02:54:21.32ID:LqujN7Od

最初にGCは使えないって思いっきり批判してるんですがそれは…

0954デフォルトの名無しさん

2015/11/14(土) 03:19:17.98ID:7BriiQEY

GCがない言語で一時的にオブジェクトを使用する時ってどうするの？

例えば、foo(new Bar())　みたいなコード

いちいち変数に入れて、それからdeleteしないといかんの？

0955uy ◆Qawu9.2l1E

2015/11/14(土) 04:22:27.97ID:shhU0jvc

GC作るんだよ
スマートポインタ程度も作れないならさっさと死ぬべき

0956uy ◆Qawu9.2l1E

2015/11/14(土) 04:29:02.95ID:shhU0jvc

ちなみにC言語（ｗ）は

for文の構造的にマクロでラップすれば

OBJECT_A_GC_( 初期化 ) {
　実装
}

　
これなんか余裕だけど

社畜PGはマクロ禁止されてる（爆笑）から無縁な構文

みんな死ぬべき

0957デフォルトの名無しさん

2015/11/14(土) 04:54:09.79ID:ed8zuO1l

>>954
Bar bar; foo(&bar);
foo(&*unique_ptr<Bar>(new Bar()));

0958デフォルトの名無しさん

2015/11/14(土) 05:01:10.32ID:7BriiQEY

>>957
ひどいな。

コードの量も明らかに増えてるし
可読性も悪くなってる。

0959デフォルトの名無しさん

2015/11/14(土) 05:03:24.70ID:LqujN7Od

>>958
サイズちっちゃいならfoo(Bar())でいいよ
コード量減ったな。良かった良かった

0960デフォルトの名無しさん

2015/11/14(土) 05:13:59.02ID:7BriiQEY

>>959
良かったと思ってるよ。これもGCがあるおかげだね。

ソフトウェアの進化っていうのは、
多少遅くなることを許容して開発効率を上げる事で
大きなものを作れるようになってきたわけだからね。

GCは正常進化の流れの一つだってこと。

0961デフォルトの名無しさん

2015/11/14(土) 05:19:40.19ID:LqujN7Od

>>960
なにいってんの？
>>959はC++の例なんだけど

0962デフォルトの名無しさん

2015/11/14(土) 05:23:21.21ID:7BriiQEY

>>961
あ、だからnewが無いんですねｗ
ぐっちゃぐちゃな冗長なコードを
関数の中に押し込んでるわけですかー。

0963デフォルトの名無しさん

2015/11/14(土) 05:26:04.46ID:LqujN7Od

>>962
想像を絶する馬鹿だな
スタックに置いてるだけだぞ

0964デフォルトの名無しさん

2015/11/14(土) 05:31:00.07ID:7BriiQEY

>>963
Bar()のどこがスタック何ですか？ｗ
関数呼び出しでしょうが。

それにnewじゃないから、要求を満たしていません。

再掲しておきますね。　>>954
> 例えば、foo(new Bar())　みたいなコード

0965デフォルトの名無しさん

2015/11/14(土) 05:36:14.57ID:LqujN7Od

>>964
そう解釈したのかﾜﾛﾀ
ごめんBarは関数じゃなくてクラスなんだ
C++はヒープに置くかスタックに置くか選択できるんだよ

0966デフォルトの名無しさん

2015/11/14(土) 05:45:48.73ID:7BriiQEY

選択できるというならば、
選択する部分まで含めないとダメです。

冗長な部分までしっかりと書きましょうｗ

0967デフォルトの名無しさん

2015/11/14(土) 05:49:59.60ID:LqujN7Od

>>966
なんでそこまで自信満々で恥の上塗りをするんだ…
new Bar()ならヒープに、Bar()ならスタックになるんだよ

0968デフォルトの名無しさん

2015/11/14(土) 06:21:33.07ID:LqujN7Od

>>966
興味本意で聞くんだけど使える言語なに？Java？

0969デフォルトの名無しさん

2015/11/14(土) 08:14:52.13ID:ed8zuO1l

foo(&*make_unique<Bar>());
もすこし短く書けたわ。ただしC++14。

0970デフォルトの名無しさん

2015/11/14(土) 15:39:26.13ID:Wquzevs4

ttp://www.narinari.com/Nd/20081210747.html

これのお返事ですか？７位

0971デフォルトの名無しさん

2015/11/14(土) 15:51:04.80ID:Wquzevs4

さすが、門s様２つランクインされてますね

0972デフォルトの名無しさん

2015/11/14(土) 17:19:32.33ID:cDeM3hPE

ほったらかしプログラミングはんたーーーーーーーーーーい
そういうプログラミングしてるやつほど、参照が切れてなかったり、切れてたりひどい

0973デフォルトの名無しさん

2015/11/14(土) 17:29:07.32ID:5MMaz5Qo

ビデモメモリとかのリソースを使うオブジェクトをGC任せにするのってどうなの？
メインメモリはまだ空いてるけどビデオメモリは足りないってシチュありえるんじゃないの？
ビデオメモリが足りなくなったことをGCが検出してGC発動してくれるの？

0974デフォルトの名無しさん

2015/11/14(土) 18:11:10.79ID:lGLm+XNP

>>973
おまえ、ビデオメモリをmallocで確保するとか
newで確保するとか思ってるのか・・・？

0975デフォルトの名無しさん

2015/11/14(土) 21:29:33.53ID:5MMaz5Qo

そりゃ最下部のAPIは
CreateTexture的な何かとか
CreateSwapChain的な何かだろうけど
それをラップしたオブジェクトはnewで作るし
そのラッパーオブジェクトの開放をGCに任せたら
>>973にならない？

0976デフォルトの名無しさん

2015/11/14(土) 22:02:19.63ID:Wquzevs4

ならないような
PC側のメモリ管理の問題では

0977デフォルトの名無しさん

2015/11/14(土) 22:22:12.67ID:T7cDyZTE

ビデオメモリは動的に確保し続けるケース自体が珍しいよね。ローディング時に足りなければ、小さいリソースで再試行するなどの初期化再試行をやるか、例外終了するしかない。
で、ラッパー自体は初期化が終わったらリソース確保し続ける必要ないよね。GPUに渡ってるんならあとはAPI叩くだけなんだし
なので心配不要だと思う

0978デフォルトの名無しさん

2015/11/14(土) 22:30:58.55ID:LqujN7Od

基本的にビデオメモリが足りなければメインメモリから確保するから足りないということはない
ただテクスチャハンドルの解放とかをファイナライザに書くと
GC発動までビデオメモリを圧迫してパフォーマンスは劣化するよ

ちなみにGPGPUを行うときはmallocもfreeもしないといけないのが多くて
メモリ足りないこともあるしリークもする。当然GCはなにもしないよ

0979デフォルトの名無しさん

2015/11/14(土) 22:33:52.53ID:5MMaz5Qo

例えばゲームなんかでステージ1からステージ2に移行するとき
まずはステージ1のテクスチャなどを破棄するわけだけど
これをGC任せにするといつ破棄されるか分らないよね
GCが発動しなくてステージ1のテクスチャなどがビデオメモリに残っている状態で
ステージ2のロードを開始してビデオメモリが足りなくなった場合はどうするの？
GCがビデオメモリが足りなくなった事を検出してGCを発動してくれれば良いけど・・・

これは極端な例だけど

0980デフォルトの名無しさん

2015/11/14(土) 22:39:12.89ID:5MMaz5Qo

それと、C#のDisposeパターンってどうなのよ
あの一連のコード
IDisposableなオブジェクトをコンポジションすると
必ず書かなければならないし、漏れがあってはならない
大変慎重に実装しなければならない、ような気がする

一方でC++だとメンバ変数のデストラクタは勝手に呼ばれるし
ポインタの場合もスマートポインタを使えば勝手に開放される
結局どっちが楽か分らないのでは？

0981デフォルトの名無しさん

2015/11/14(土) 22:42:06.47ID:LVzdgTaY

そもそもプログラミング自体がそうお気楽な行為じゃないんだという事を忘れがちだけど、
メモリー管理もそうそうお気楽なもんじゃないんだよ。

0982デフォルトの名無しさん

2015/11/14(土) 22:43:59.47ID:LqujN7Od

>>979
GCはメインメモリしか考慮しないからなにもしないよ
俺はゲームエンジンのグラフィクス開発やってるから信用してくれていい
更に言うとコンシューマとかだと専用のmalloc, freeがあって
自分で全部管理しないといけなかったりする

0983デフォルトの名無しさん

2015/11/14(土) 22:56:13.54ID:5MMaz5Qo

IDisposableなオブジェクトをコンポジションしたクラスにもIDisposableが必要で
そのオブジェクトをコンポジションしたクラスもまたIDisposableが必要・・・
IDisposableはどんどん伝染していくわけでしょ
IDisposableがどんどん増えていく
そんであの一連のDisposeイディオムを書いて
自身がコンポジションしたIDisposableなオブジェクトを調べ上げて
Disposeをコールするコードを手動で書かなければならない
漏れがあってはならない
これってもう手動でmalloc、freeしているのと変わらなくない？

C++ならこんな事は起こらないよね
何か内部でmalloc、free的なことをしているクラスがあったとしても
それはそのクラスだけで閉じている話で、必ずデストラクタで開放されるように作ってあるし、
クラスのメンバのデストラクタは勝手に呼ばれるから、Disposeみたいに伝染しないしコードも必要ない
newする場合でもスマポ使っとけば勝手に開放される
だからオブジェクトをコンポジションしても、な～んにも気にする必要ない

0984デフォルトの名無しさん

2015/11/14(土) 22:59:19.56ID:ruIj37Ej

rustみたいな言語ならポインタ関連のバグはなくなりそうだけど

0985デフォルトの名無しさん

2015/11/14(土) 23:16:38.67ID:5MMaz5Qo

C++のデストラクタとスマポ方式で問題になるのは循環参照があった場合だけじゃね？
それすらweak_ptrが用意されているから上手く活用すればよい話

メモリが断片化するとか言うけど、MMUが付いているから問題なし
物理じゃなくて論理アドレス空間の方が断片化するのは嫌だが
64bitプロセスであればどんなに無茶をしたからといって使い切ることは現状ありえない

C#はGCを導入した事で
DisposeとかDispose(bool)とかデストラクタとかFinalizeとかusingとかマジ不毛なことになっている
C++はデストラクタ一本だから集中できるし、しかもクラスのメンバのデストラクタは勝手に呼ばれるから
C#のIDispose見たいに伝染しないし、Disposeにまつわる一連のイディオムも必要ない
いつデストラクタの処理が走るかも明確で、いつも同じタイミングだからデバッグもしやすい

GCなんか本当に必要か？
いつ実行されるか分らないからDisposeとかが必要になるし、メインメモリに関してしか上手く機能しないから
それ以外のリソースのことも考えたら結局デストラクタがほしくなる

0986デフォルトの名無しさん

2015/11/14(土) 23:16:48.58ID:7qU/f9+6

どっちかというと、メモリ管理とポインタに関してはシステム記述言語にルーツを持つC言語族が特殊かと。

0987デフォルトの名無しさん

2015/11/14(土) 23:26:02.05ID:T7cDyZTE

C#のIDisporsableについて、もうちょいなんとかならんかったのかとは思うし同意なんだけどね

これはC#がアンマネージドという機構を用意した故の泥臭さだよね
ネイティヴが絡むことをなんとかできるようにしてくれた、と考えたほうが建設的かも
できないよりは有難いことだし、ネイティヴそのままよりややこしくなるのも当然といえば当然のこと。仕方ないのでは。

0988デフォルトの名無しさん

2015/11/14(土) 23:42:17.72ID:0kN6s8T8

IDisposableなクラスは継承したりメンバに含めたりせずに単品で使うのがオススメ

こんな感じ
using( var context = new DbContext() ){
クエリ実行処理(context);
}

0989デフォルトの名無しさん

2015/11/14(土) 23:45:01.14ID:5MMaz5Qo

C#の開放周りは本当に複雑怪奇だ
デストラクタとFinalizeとDisposeとDispose(bool)を適切に理解し
マネッジドリソースとアンマネッジドリソースを適切に区別し
例のDisposeのイディオムを書かなければならない

C++はもっと簡単で、自分の使ったりソースはデストラクタで開放しましょう、これだけ
しかも殆どのリソースは勝手にデストラクタが呼ばれるので、殆ど何も書く必要はない
スマートポインタも有るので本当に自動
しかも、このシンプルさで何も破綻していない、実用上問題ない
GCを入れるとC#のDisposeイディオムみたいに、とたんに複雑になる
複雑になるとミスも増えるし、IDisposableの実装って結局手動じゃねーかって言うね

0990デフォルトの名無しさん

2015/11/14(土) 23:53:31.80ID:5MMaz5Qo

>>987
せめてDisposeがC++のデストラクタみたいに
芋づる式に勝手に呼ばれるような、なにかそういう仕組みが用意されていれば
もう少しマシだったと思うんだが、どうよ

0991デフォルトの名無しさん

2015/11/15(日) 00:01:58.94ID:5wcT3tcL

なんかずれてる気がするけど、Disposeは主に外部リソースを解放するためのものだぞ
DBとかファイルとかネットワークとか

usingの範囲＝外部リソースが有効ってことで分かり易いと思うが

0992デフォルトの名無しさん

2015/11/15(日) 00:12:18.39ID:SwaoEtt5

でもそのDBやらファイルやらネットワークやらをコンポジションして自クラス作ったら
自クラスにもDisposeが必要でしょ
てことは例のイディオムを書いて、コンポジションしたメンバのDisposeを
手動で呼ばなければならない
これってどうよ

0993デフォルトの名無しさん

2015/11/15(日) 00:18:09.95ID:SwaoEtt5

自分がコンポジションしたオブジェクトがIDisposableを持っているか一々調べなければならないし
持っていた場合は自身もIDisposableにする必要が有るし
その上手動でそのオブジェクトのDisposeを呼ばなければならない
調べ忘れてもアウト、呼び忘れるとアウト

これはもはや手動でメモリ管理しているのとかわらないではないか
C++のデストラクタ方式の方がよほどシンプルでは？
デストラクタは芋づる式に呼ばれるからコードを書く必要はないし
呼び忘れるという事もない
もちろんスマートポインタも有る

0994デフォルトの名無しさん

2015/11/15(日) 00:22:55.00ID:5wcT3tcL

>>988のようにメンバに持たずローカル変数で持っとけ
外部リソースの管理は呼び出し元で行えばいい

0995デフォルトの名無しさん

2015/11/15(日) 01:22:55.68ID:6d3FFbb6

IDisposableを用意した時点で、言語仕様の欠陥と言わざるをえない。
delete or スコープから外れた時点でデストラクタ呼ばれないと不便で仕方がない。

0996uy ◆Qawu9.2l1E

2015/11/15(日) 06:04:01.24ID:BtG1eDoL

http://peace.2ch.net/test/read.cgi/tech/1447298537/l50

0997デフォルトの名無しさん

2015/11/15(日) 08:24:18.89ID:JV6qYeNy

おまえらわかったような口で語るが。わかっているなら、わらからないのか？

こんな論争が起きる仕様を素人さんやプログラミングに興味無い大半のプログラマが学び取れるわけがないということを。

シンプルにメモリー使ったら自分で後片付けまでする。
それを標準にしておけば、結果としてみんな幸せになる。

0998デフォルトの名無しさん

2015/11/15(日) 10:55:43.22ID:q/hba8+k

Presto → Vivaldi
Prestoもう更新されない？機能はVivaldi に盛り込まれて行くだろう！
VivaldiにPrestoなサムネイルやタブスタッキングなど搭載が暗示させている

0999デフォルトの名無しさん

2015/11/15(日) 11:06:09.06ID:mMtidkZ5

楽すること考えるより
まともに動かすことをやったほうが

1000デフォルトの名無しさん

2015/11/15(日) 21:14:50.90ID:JV6qYeNy

mallocしたらfreeしろ
Insert やら Appendやらでデータ突っ込んだら、DisposeやらClearやらDeleteやらで全部消せ
new して使い終わったら、 nullしろ

ロジックとして無駄だとしても後から読むプログラマにとっては有益だ。あぁ。ここでデータを捨ててるんだな。とわかる。

1001１００１

Over 1000Thread

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。

1002１００２

Over 1000Thread

２ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。

───────────────────
《プレミアム会員の主な特典》
★ ２ちゃんねる専用ブラウザからの広告除去
★ ２ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────

会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。

▼ プレミアム会員登録はこちら ▼
http://premium.2ch.net/
http://pink-chan-store.myshopify.com/