GCは失敗。メモリは自分で管理せよ！その2©2ch.net

**デフォルトの名無しさん転載ダメ©2ch.net** · 2015/11/18(水) 23:24:59.79

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

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

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

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

前スレ
GCは失敗。メモリは自分で管理せよ！
http://peace.2ch.net/test/read.cgi/tech/1412986420/

**デフォルトの名無しさん** · 2015/12/05(土) 15:50:01.56

>>183
C++にはテンプレートがあるからリソースの型をテンプレート引数とするラッパーを作るのは
そんなに面倒なことじゃないと思う
あとC++でRAIIを徹底してればfainallyの必要性を感じたことはない
fainallyを書かなければいけない時点で危なっかしいコードだと思う

**デフォルトの名無しさん** · 2015/12/05(土) 16:34:34.82

むしろfinallyってデストラクタがない言語だから
必要なものなんじゃ…
どうしても必要ならデストラクタで任意のラムダ呼ぶ
ユーティリティクラス作れば同じこと出来るし

**デフォルトの名無しさん** · 2015/12/05(土) 16:50:13.74

98以前でもローカルクラス定義できるんだからすこし冗長なだけで同じだし

**デフォルトの名無しさん** · 2015/12/05(土) 16:59:06.52

例外発生はバグ、というプログラミングしかしたことないからよくは知らんが、
try {
　try {
　　/*...*/
　} catch (std::badalloc()) {
　　/*...*/
} catch (UserException e) {
　　/*...*/
}
} catch (...) { // fainally節の代わり
　/*...*/
}
じゃあいかんの？実行時コストは知らん

**デフォルトの名無しさん** · 2015/12/05(土) 17:00:08.66

ｽﾏﾝ
誤： } catch (std::badalloc()) {
正： } catch (std::badalloc e) {

**デフォルトの名無しさん** · 2015/12/05(土) 17:32:52.06

違う。そんぐらいググれ

**デフォルトの名無しさん** · 2015/12/05(土) 17:37:26.87

デストラクタの問題点は不可視なところだな
usingやfinallyは目に見えるから安心する

**デフォルトの名無しさん** · 2015/12/05(土) 18:00:14.20

>>189
内側のtry～catchから再throwするのを忘れたorz
内側のtry～catchから再throwして外側ので再捕捉したらいいんじゃ…

**デフォルトの名無しさん** · 2015/12/05(土) 18:22:16.37

例外をロジックとして使うなってばっちゃんが言ってた

**デフォルトの名無しさん** · 2015/12/05(土) 19:38:41.80

>>191
throwせずにreturnするパスが有ったらどうするんだよ
そういうのを防ぐためのfinallyやRAIIなのに
まったくちんぷんかんぷん
結局returnする前に手動で忘れないようにthrowすることを強制するんなら
goto文とか開放用ラムダ呼び出すのとかと替わらないだろ

**デフォルトの名無しさん** · 2015/12/05(土) 20:44:27.97

だから忘れる忘れないレベルをぶち込んでくるのは止めようやｗ
これをぶち込むから全ての議論が池沼レベルになってる

**デフォルトの名無しさん** · 2015/12/06(日) 06:02:02.37

異常系で例外返す仕様のライブラリが失敗。

**デフォルトの名無しさん** · 2015/12/06(日) 08:06:42.75

>>194
GCなんて池沼のために生まれたようなものだし・・・
NULLったりfreeったりすることすらまともに把握、指示しきれない

**デフォルトの名無しさん** · 2015/12/06(日) 11:36:02.06

c++のデストラクタって後処理に失敗しても
例外投げられないからウンコ
結果的にエラーを握り潰すゴミコードを量産する原因になってる

**デフォルトの名無しさん** · 2015/12/06(日) 11:40:47.08

そのクラスが管理してる範囲で後処理の失敗って何が起こるの？

**デフォルトの名無しさん** · 2015/12/06(日) 12:05:41.69

どうしてもやりたいなら対処法はあるしなぁ。

**デフォルトの名無しさん** · 2015/12/06(日) 12:23:19.67

現実的な確率で発生して無視出来ないリスクが有る解放処理はデストラクタでやるべきじゃない
そういうリソースに対してデストラクタがやる事はプログラマに対しいて未解放のリソースを通知する事だけでよい

**デフォルトの名無しさん** · 2015/12/06(日) 12:30:12.96

具体的に何があるん？？？
クラス内で使っているリソースで解放に失敗（失敗し続ける）するって。

**デフォルトの名無しさん** · 2015/12/06(日) 13:14:17.95

どっか他のオブジェクトと共有してるものを解放しようとして失敗するとか？
それはそもそもの設計に問題ありすぎだが。。

**デフォルトの名無しさん** · 2015/12/06(日) 15:01:28.77

>>202
だよね。
否定しようとして無理やり現象を創りだそうとしているとしか・・・。
でもその無理やりつくった現象は、そもそも論理設計のミスが大前提だったりする。
論理設計のミスまで言われたらなんにも組めないわ。

**デフォルトの名無しさん** · 2015/12/06(日) 15:42:32.97

>>200
デストラクタの中で起きた例外については
try { } catch (...) { }で囲った上で、リカバリ処理（何とかしてリソース解法漏れをなくす）を行えばいいじゃない？

もし例外発生後に行うべき適切なリカバリ処理が書けない（存在しない）んだとすると、
もはやデストラクタ内に限った話ではなくなって、例外を発生させた時点で設計か実装にバグが居たとしか…

**デフォルトの名無しさん** · 2015/12/06(日) 16:03:58.23

バグ（リソースへのポインタやハンドルを壊しちゃったとか）以外で
リソース解放に失敗するケースなんて１つも思いつかない

◆QZaw55cn4c · 2015/12/06(日) 16:19:39.63

fclose() にも失敗があるじゃないか？

**デフォルトの名無しさん** · 2015/12/06(日) 16:54:30.29

fflush() しとけばＯＫ

**デフォルトの名無しさん** · 2015/12/06(日) 16:59:21.77

>>206
fcloseの失敗はハンドルが正しい限りflush時のI/Oエラーの通知であって、その場合でもリソースは解放されるよ

**デフォルトの名無しさん** · 2015/12/06(日) 17:35:51.31

c++信者ってアホだなー
みんなこんなんなの？

http://cpplover.blogspot.jp/2011/01/fclose.html?m=1

**デフォルトの名無しさん** · 2015/12/06(日) 17:44:16.50

fcloseに失敗してファイルに正常に書き込みされなくてもシカトしてるんだよね？
それともerrnoとかチェックしちゃってるの？

**デフォルトの名無しさん** · 2015/12/06(日) 19:05:12.47

まあC++の例外を援護するつもりはないがそういう場合は
普通にフラッシュしろよ
そもそもC++が二重例外時にstd::terminate呼ぶのはGCのあるなしに
関係ないからスレ違いだお前ら。よそでやれ

**デフォルトの名無しさん** · 2015/12/06(日) 19:24:21.60

GCというよりライブラリとの関係だな
.net framework libraryのいくつかのクラスは中で自分自身をロックするから
プログラマ側で参照が切れてもGCされない

**デフォルトの名無しさん** · 2015/12/06(日) 19:25:02.74

今日一日なんでFormがGCされないのか調べてて大変な思いしたわ

**デフォルトの名無しさん** · 2015/12/06(日) 19:31:56.53

>>213
よくそこまで調べたな。( ・∀・)つ旦　お茶ﾄﾞｿﾞｰ

**デフォルトの名無しさん** · 2015/12/06(日) 19:37:02.30

いまだにプログラマはアセンブリ言語を使えるべきだ派？

**デフォルトの名無しさん** · 2015/12/06(日) 19:40:49.58

アセンブラ知ってると知らないとじゃスキルレベル全然違うからな。話にならないぐらいのレベル差。

**デフォルトの名無しさん** · 2015/12/06(日) 20:22:00.43

まあ実際Java屋とかってコンパイラやメモリ意識できない奴多いよね
以前2chで↓みたいなコードが勝手に最適化されると思って
StringBuilder使う奴は馬鹿！とか言い出す奴いて目眩したわ
String s;
for(int i = 0; i < strarray.length; ++i){ s += strarray[i]; }

**デフォルトの名無しさん** · 2015/12/06(日) 20:58:14.61

>>217
それはStringの+=の実装次第ではあんまり差が付かないケースなんじゃ…
（左辺と右辺が別の実体である（アドレスが違う）ケースでは多分右辺を左辺の末尾に1回コピーするだけという実装が有り得る
真に糞なのは
StringBuilder sb;
String s = "Hello";
sb.Append("[" + s + "]");
が遅いからStringBuilderは糞、と結論付けるニンゲンであってコードではない、
みたいな？

**デフォルトの名無しさん** · 2015/12/06(日) 21:26:17.35

>>217みたいにループ中で一個づつくっつける場合は別にして
s = a + b + c + d; // このように、高々数個をくっつけてる場合は
Javaだと無駄にStringBufferが作られてダメと言うのが定説だったが
C#の場合は内部的にString#Concatに置き換えられて
それによって
StringBuilder b = 略
s = a.Append(b)中略.Append(d).ToString()
するより早い、という話題があってそれと勘違いしたのかもね

**デフォルトの名無しさん** · 2015/12/06(日) 21:28:20.04

いちおう訂正しとこｗ

StringBuilder sb = 略
s = sb.Append(a)中略.Append(d).ToString()

**デフォルトの名無しさん** · 2015/12/06(日) 21:50:20.98

そもそもその最適化は仕様なのか

**デフォルトの名無しさん** · 2015/12/06(日) 22:27:08.91

>>218
？？、これJavaだぞ。演算子オーバーロードなんて出来ないから
>>219
違う違う。+の連結がStringじゃなくてStringBufferに
最適化されるらしいって話だけで、StringBulderって
必要ないでしょ？レガプロ？(笑)、って認識レベル

しかもそいつ一人ならまだしもスレに同じレベルの
認識の奴結構多かったよ。レベルの低さ舐めたらあかんで

**デフォルトの名無しさん** · 2015/12/07(月) 01:50:02.58

>>222
実装云々でなんで演算子オーバーロードがでてくるんだ？

**デフォルトの名無しさん** · 2015/12/07(月) 05:22:13.32

逆だろ？
C#との勘違いでないなら、その最適化されるJVM実装とやらを示さないと

**デフォルトの名無しさん** · 2015/12/07(月) 07:11:57.22

>>219
全く逆の認識してないか？
classファイル解析したら分かるけど、ループ中の+=の方が問題で毎回newされるから遅い

s = a + b + c + d の方は一つしかStringBuilderのインスタンスは作られない

**デフォルトの名無しさん** · 2015/12/07(月) 08:02:18.14

こうやって、比較的プログラミングという行為を好きでいる・好きでやっている・興味を持っているという人ですらまともに言語仕様を理解出来ていない。
malloc、freeで管理、GCで管理だと、機構の複雑さは後者。
結局GCもその機構を正しく理解しないと参照が切れてない、参照が切れていても別のリソースが・・・と。
機構を正しく理解していることが前提なら、機構はシンプルなほうがいい。
その点を誤ったから
>プログラマをメモリ管理から開放する！
>といいつつ、メモリリーク問題の文献が大量にある。
>これすなわち、メモリリーク問題が全然解決していないということ。
>さらに、メモリ解放のタイミングの文献まで大量に生み出した。
>これすなわち、新たなるメモリ管理に関する問題を生み出したということ。
なんてことになったんだろうね

**デフォルトの名無しさん** · 2015/12/07(月) 08:12:44.70

そもそもプログラマの大半にマネージリソース、アンマネージリソースとはなに？
って質問してまともに回答できる割合がどんなもんになるのか
始めたら終わらせる
これワンセットね
にしたほうがミスはなくなるかと
ファイル開いたら閉じる
メモリ確保したら解放する
通信接続したら切断する

**デフォルトの名無しさん** · 2015/12/07(月) 09:22:45.43

やっぱりARC最強だな

**デフォルトの名無しさん** · 2015/12/07(月) 15:38:30.00

結局いつ開放されるか分からないってのが曲者で
使い終わったら確実にリソースを開放してほしいときは
別の仕組みが必要になってしまったってのが問題だろう
その別の仕組も、C++のデストラクタのようにクラスのメンバに関して
芋づる式に呼び出す仕組みがないから
C++のデストラクタがやっていることを手動で再現しなければならない始末

一方でC++のスマポなどの参照カウンタ方式は循環参照だけが問題だが
それ以外の問題が一切発生しない、デメリットは循環参照だけ
しかも循環参照が発生する場合は片方をweak_ptrにすれば良い
ということが分かりきっているし、循環参照が発生する箇所も
設計段階でわかる

循環参照に気を配れる知能が有るのであれば、参照カウンタ方式のほうがスマート

**デフォルトの名無しさん** · 2015/12/07(月) 17:29:26.60

>>229
処理速度やタイミングがシビアな組み込みや科学技術計算系とかならいざしらず、
ソレ以外は、実際の解放のタイミング自体は問題にならんでしょ。(膨大なメモリの使用も別だけど)
問題は、使い終わったよーって明示しないで良い。という運用が結局、悪い結果をもたらしているという点。
メモリの管理をしっかり最後までやるクセのないプログラマは、
平然と参照が途切れている可能性のあるポイントで参照しに行こうとする。
結局は、そいつがバカだからに集約されてしまうんだけど、使い終わりの明示をしない文化がバカを生む土壌となっている

**デフォルトの名無しさん** · 2015/12/07(月) 18:21:02.44

そういう事になる原因ってさ、構造がぐちゃぐちゃでオブジェクト間も依存しまくって、
いつ解放していいのかわかんねえーというヘボいプログラミングなんだろうなと思う。

**デフォルトの名無しさん** · 2015/12/07(月) 18:23:12.12

と馬鹿なSEやPGはそう思うだろうなとも思う。

**デフォルトの名無しさん** · 2015/12/07(月) 19:54:31.23

ある意味メモリなんて一番扱いやすいリソースだからな。
メモリの管理すら適当なプログラマが、他のリソースを適切に扱える訳がないのに、GC前提の言語ではそちらのケアが言語側でやりづらくなってしまっている。

**デフォルトの名無しさん** · 2015/12/07(月) 20:05:22.53

メモリ意識した時点で雑魚プログラマ決定だろ。
JavaScriptもPascalも使えないんじゃ話にならないよ。
おちんぽ見られることを意識しすぎて温泉に入れないようなもの。
癒やしのない人生に刺激なんてない。←これ名言

**デフォルトの名無しさん** · 2015/12/07(月) 20:07:43.02

>>231
そう。そういう状態にしちゃう原因が、いい加減なメモリの管理で教育された結果にあるのではないか？ということで。

**デフォルトの名無しさん** · 2015/12/07(月) 20:09:47.14

>>234
だれの名言かしらんが、

刺激のない人生に癒やしはない。

ならなんかしっくりくる。まぁ逆とっても同じ意味だからいいんだけど・・・。

**デフォルトの名無しさん** · 2015/12/07(月) 20:16:31.05

メモリ意識しないプログラマとかカスだろ。

**デフォルトの名無しさん** · 2015/12/07(月) 20:42:25.43

JavaやC#ではリソースをプログラマが管理してはいけない
せっかくメモリ管理を透過的にしたのにリソース管理でコードをより複雑化させては意味がない
真っ当な教育を受けた少数のプログラマがSafeHandleを作成する
末端のプログラマはSafeHandleのファイナライザに全てを任せてメモリと同様にリソースを完全に透過的に扱うべきだ

**デフォルトの名無しさん** · 2015/12/07(月) 23:25:36.31

>>230
JavaのGCでサーバー応答が止まるなんてザラにある話だよ
それを聞いたことがないなら文系SEと同レベルだね

>>238
管理放棄して開くだけ開いて計算資源を食い潰す玄人気取りプログラマ

**デフォルトの名無しさん** · 2015/12/08(火) 00:48:22.00

full GCが頻繁に生じちゃうのは明らかに設計ミスやな
immutableな短命objectを使いまくるのだ。。
つかimmutableなオブジェクト使いまくるとGCないときつくね？

**デフォルトの名無しさん** · 2015/12/08(火) 02:05:45.39

RAIIで事足りる
immutableかどうかとＧＣは無関係

**デフォルトの名無しさん** · 2015/12/08(火) 02:21:53.95

むしろ短命なオブジェクトなんてスタックで十分だし
管理するならshared_ptrのが優れてる

**デフォルトの名無しさん** · 2015/12/08(火) 03:41:28.67

ライブラリ、アプリ、ユーザの三者で考えないと
一部リソースはユーザがを閉じることができる。
そのときアプリの参照を消す仕組みがどのライブラリにもない

**デフォルトの名無しさん** · 2015/12/08(火) 08:07:46.77

>>243
よくわからんが、それは階層的におかしいのでは？
ユーザーがアプリを通さずにリソースを閉じる事ができるって事？

**デフォルトの名無しさん** · 2015/12/08(火) 12:16:07.11

Manager.Execute((res) => ...);

これが終着点
短命なリソースは全てこの形式で事足りし長命なリソースはファイナライザにでも任せればよい
ユーザーが管理しちゃ絶対にダメ

**デフォルトの名無しさん** · 2015/12/08(火) 15:11:36.25

このスレでGCいらんて言ってる人たちは環境に恵まれてるんだなぁって思う

**デフォルトの名無しさん** · 2015/12/08(火) 15:20:06.88

GC
タモリが昔宣伝してやつ？

**デフォルトの名無しさん** · 2015/12/08(火) 15:28:54.90

むしろGCなんて環境良くないと使えないだろ

**デフォルトの名無しさん** · 2015/12/08(火) 16:16:30.38

参照がなくなったタイミングで必ず開放してくれて
かつ
循環参照でも問題ない
パーフェクトなGCが有れば最高なわけだが
実際にはそんなGCは無い

となれば、通常であれば言語側は性質の異なる複数のGCを用意しておいて
使う側はシチュエーションに合わせて選べるようにしておくのが自然な発想
しかしそういう言語は殆ど無い、これが問題

といってもマークスイープ系GCが前提のC#やJavaのような言語に
RAIIの発想を持ち込もうとしても
C++のデストラクタのように自身のメンバのデストラクタを自動で芋づる式に呼び出す仕組みが
元々無いので、手動で芋づる式に解放関数を呼び出すコードを書かなければならなく
うまく行っていない

**デフォルトの名無しさん** · 2015/12/08(火) 16:25:08.60

>>246
JavaでPhantomReferenceも使ったこと無い人って恵まれてるんだなあって思う

>>249
無いのでってもろにAutoCloseableとかあるやん

**デフォルトの名無しさん** · 2015/12/08(火) 16:37:24.80

>>250
自分のクラスがファイルなんかのcloseを持つリソースをメンバに持っていたとする
そうすると、それらのメンバのリソースを明示的にcloseできるようにするために
自身もcloseを実装することになるだろう
それで、自身のcloseが呼ばれた時、勝手にメンバのcloseが呼ばれるか？
結局手動でメンバのcloseを呼び出しまわるコードを書かなければならない

C++のデストラクタならメンバのデストラクタが芋づる式に勝手に呼び出されるから
気にしなくて良い

**デフォルトの名無しさん** · 2015/12/08(火) 17:08:50.17

強参照、ソフト参照、弱参照、ファントム参照
この字面だけで糞言語って察せられるから凄い

**デフォルトの名無しさん** · 2015/12/08(火) 19:22:21.31

Rustはどう？
明文化されたmoveセマンティクスと、オブジェクトの寿命と参照のチェッカを型システムに組み込んでるおかげで、
リソース管理の実行時コストをゼロにしつつ、メモリリークが発生しないプログラムが書ける。
shared_ptrに相当するRcもあるから、所有者を複数にしたい場合のコストもそれなりに抑えられる。

**デフォルトの名無しさん** · 2015/12/08(火) 19:35:14.32

>>253
すげえ難しいらしいじゃん

**デフォルトの名無しさん** · 2015/12/08(火) 19:52:40.51

rustの清貧さは好みだけどまだ触った事ないな
同期処理を省略するためかshared_ptr相当がタスク間跨げないらしいけど
そこら辺の使い勝手ってどうなんだろう

**デフォルトの名無しさん** · 2015/12/08(火) 21:00:06.21

>>254 難しいのは難しいが、低レベルの世界に相応な難易度であって、理不尽さはあまり無いと思う。
自分が遭遇した理不尽というか不便は、トレイト(型クラスみたいなの)を戻り値にした、ジェネリックな関数の型注釈の煩雑さで、
そのworkaroundが、その関数の返り値専用の型を定義する、ってのがカルチャーショックだった。
https://doc.rust-lang.org/std/iter/trait.Iterator.html
↑はIteratorトレイト(Listインターフェイスみたいなもの)のドキュメントだけど、mapとかfoldとかよくある高階関数の戻り値が、それ専用の型(MapとかFold)になってる。
だから、よくある関数型言語のイメージで、何か高階関数を利用したアダプタ関数を試しに定義してみよう！ってやると、
型注釈のエラー、ライフタイムのエラー等が一辺に出てきてわけが分からなくなる。

その関数の戻り値専用の型、なんて贅沢に見えるけど、返り値のサイズを見る限り、余計なデータで膨れているわけでもなかった。
Cでstruct wrap_int { int c; };とやったときにsizeof(wrap_int)がsizeof(int)と等しいけど、それと同じことをやっていた。
型情報なんてコンパイル時に全部消えちゃうから、実行コストも無いんじゃないかと今では思う。

メモリ/リソースの所有権を意識してコードを書くこと、が身について面白いよ。
ヒープを贅沢に使ってコピーしまくりなコードを書くと汚いし遅いしなんで、ちょっとダイエットする気分も出てくる。

**デフォルトの名無しさん** · 2015/12/08(火) 22:39:35.60

>>251
C++もヒープ相手は自分で呼ぶので、実装は必要だよ
Javaでもメンバの特定メソッド呼び出しはやろうと思えばできる
現実に横断的な呼び出しをやる場合はある

結局要求される物と実装の問題

**デフォルトの名無しさん** · 2015/12/08(火) 22:59:22.32

>>255 shared_ptrと恒等なものは無いけど、ポインタ的に使える型がBox, Rc, Cell(あるいはRefCell)とあって、
Boxはヒープ領域であること、Rcは複数の所有者がいる(つまり所有者全員が死ぬまでは生きている)こと、Cellは複数の書き込みが作れること、
とか機能とコストが別れているから、これらを組み合わせて使う。

で、Thread Safetyを実現させる機構は上記には無いので、Atomicityを導入させるRcの類似形であるArcと、
書き込みもしたいならMutexっていう型も合わせて使う。
すると、例えば整数のベクトルをスレッド間で共有したい、とかになるとArc<Mutex<Vec<i32>>>という目が滑るような型表記をすることになる。
あんま詳しくないので、ケース毎にもっと簡単なやり方があるとは思うんだけどね。

**デフォルトの名無しさん** · 2015/12/08(火) 23:55:28.64

>>258
ああ、Arcってのが別にいるのね。納得
個人的にもう一点気になる所があるから聞いてしまう
BoxやDropを使ってるとコピー禁止になるらしいけど
これ面倒な場合ない？
最初はコピー可能な型としてガンガンコピーしてたけど
途中から終了処理を書きたくなったらコピーしてる箇所
全部直すって事？

ちなみにググってたらRWArcっての見つけたんだけど
これ読み書き可能なArcなんじゃね

**デフォルトの名無しさん** · 2015/12/09(水) 00:46:02.26

>>249
javaは世代別管理でGCの種類は色々選べるはずでは

**デフォルトの名無しさん** · 2015/12/09(水) 01:14:15.85

>>260
起動時に切り替えられるだけであって
オブジェクトごとには切り替えられないのでは

**デフォルトの名無しさん** · 2015/12/09(水) 01:50:08.36

>>259 コピーしまくっているような変数の型をTからBox<T>に変えた場合、確かに面倒なことになる。
けど、基本的に単純な代入(let x = y)はコピーじゃなくてmoveになるし、
Box<T>の値をコピーしてBox<T>の値を生成するっていうのは、同じヒープ領域を指すポインタを作るんじゃなく、
新しいヒープ領域を確保して中身をコピーし、そのポインタを返すという意味なんで、
変数の型を後でTをBox<T>に変える、という場面はあまり無い(少なくとも自分は学んでいる最中にそういうことをしたくなったことがない)

値をコピーする場面では、元の変数の型がBox<T>であってもTであっても、参照型&Tを受け取ってTを生成、ということをするのが定石。
&Tはほぼ無制限に安全に作ることができるし、安全じゃない可能性があったらコンパイルが通らない。
で、コピーした型Tの値は呼び出し元がBoxに包んでヒープ領域に置いたりするのが定石

Dropも別にコピーを禁止することは無いよ。後からつけたらエラーまみれ、ということにはならない。

あと、自作じゃない型に自作じゃないトレイト(インターフェイスみたいなもの)をつけることができないので、
例えば標準ライブラリのFileやTcpStreamはCopyできるようには決してできない。メモリ以外の資源管理も安全だよ。

**デフォルトの名無しさん** · 2015/12/12(土) 10:36:13.53

freeし忘れるとか、そんな超ウルトラ素人ミスを大前提に議論するのは間違いだよなｗ
freeしきれないとかｗｗｗｗ

**デフォルトの名無しさん** · 2015/12/12(土) 11:52:29.69

>>263
規模が大きくなれば管理が難しくなるのは普通のことだよ。
ライフサイクルはオブジェクトごとに異なるものだし、
人間に頼らずにGCにメモリ管理を任せるっていうのは良いやり方だよ。

**デフォルトの名無しさん** · 2015/12/12(土) 12:05:07.06

shared_ptrって参照カウント式のGCじゃないの？

**デフォルトの名無しさん** · 2015/12/12(土) 12:44:09.71

循環を綺麗に扱えるなら参照カウントの方が良いと思うけど
VB6は循環参照の扱いどうやってるんだろう

**デフォルトの名無しさん** · 2015/12/12(土) 14:25:51.97

>>265
RAIIじゃろ

**デフォルトの名無しさん** · 2015/12/12(土) 15:20:38.55

>>265
GCの一種だけど、文脈的にはプログラマが
管理が非局所的で明確な型宣言もなしに使えるのをGCと言ってるわけで
議論で揚げ足にしかならない野暮な突っ込みはやめようぜ

**名無しさん＠そうだ選挙に行こう** · 2015/12/14(月) 08:16:09.53

>>264
いや、下手って一言で片付けられるよ。
よっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっぽど、出ない限り

**名無しさん＠そうだ選挙に行こう** · 2015/12/14(月) 08:38:44.84

片付ける奴が馬鹿なのだ。素人ほど簡単だと言いたがり、上級者ほど簡単ではないとはっきり言うものだ。
どの分野でもな。

**名無しさん＠そうだ選挙に行こう** · 2015/12/14(月) 09:09:02.89

freeとか言ってる奴はC++使えよ。いつまでＣ使ってんだ。

**名無しさん＠そうだ選挙に行こう** · 2015/12/14(月) 09:20:53.11

>>270
東大生が人に教えるとき、何がわからないのかわからないというのがわからない。
上級者になればなるほど自分がやってることなんて簡単に見えてくる

**名無しさん＠そうだ選挙に行こう** · 2015/12/14(月) 09:35:23.70

>>272
何が分らないか分らない、つまり東大生も生徒がどういう思考をしてるか分析できず分らないと言ってるのだ。
低学歴ほど、分らないのはおまえが馬鹿だからと簡単に片付けるものだ。

**名無しさん＠そうだ選挙に行こう** · 2015/12/14(月) 09:37:05.77

それ中級者
あと、東大生は教えるの上手いのもいるから想像で話すな馬鹿

**名無しさん＠そうだ選挙に行こう** · 2015/12/14(月) 09:41:37.74

このようにおまえのようなコンテキストすらまともに読めないPGは五万といる。
スレッドがデッドロックしてメモリを開放できないなんてよくあることだ。

**名無しさん＠そうだ選挙に行こう** · 2015/12/14(月) 10:59:16.82

>>275
。。。。。完全な設計ミスじゃん

**名無しさん＠そうだ選挙に行こう** · 2015/12/14(月) 11:15:19.23

>>275
俺は272に向けてたんだが
そりゃコンテキスト読めてないように見えるよなw

**名無しさん＠そうだ選挙に行こう** · 2015/12/14(月) 11:40:27.14

スレッドがデッドロックしたらメモリリークどころじゃないじゃないかwww

**名無しさん＠そうだ選挙に行こう** · 2015/12/14(月) 14:48:51.74

スレッドがデッドロックしちゃってメモリ解放できない（泣）
っていうPGが五万といるのかよｗ

**名無しさん＠そうだ選挙に行こう** · 2015/12/14(月) 15:51:19.55

まぁfreeやdeleteやnullやらすらできないPGに、「僕はそんなこと管理しきれる脳みそ持ってない！」って言われたらソレは真実なんだろうけど・・・。
そんな脳みそPGに「もっと複雑な業務使用」を理解できるとは思えないんだ。

そんなPGにプログラミングの場を与えるのが間違い。

**名無しさん＠そうだ選挙に行こう** · 2015/12/14(月) 15:58:21.86

そもそも実務でスレッド使うＰＧなんてゴマンもいない

**名無しさん＠そうだ選挙に行こう** · 2015/12/14(月) 17:06:58.52

Javaのプロジェクトだとほぼ使ってるけどな隠蔽してるだけで
そのせいで共有リソース壊したり、逆に個人情報の領域が共有されたりして、とんでもないインシデントが発生する
そんな奴等にメモリ管理なんて任せられんし、共有リソースも触らせたくないから
更に隠蔽したフレームワークもどきが出来上がる

**名無しさん＠そうだ選挙に行こう** · 2015/12/14(月) 17:59:33.07

>>282
勝手に使うな。勝手にトリッキーコードにすんな。
素直に、設計書通りに作れ。
勝手なことやって勝手に自爆してるだけじゃねーか。

GCは失敗。メモリは自分で管理せよ！ その2©2ch.net

GCは失敗。メモリは自分で管理せよ！その2©2ch.net