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/03(木) 14:07:05.91

低レベルなことを舐めるなよ

**デフォルトの名無しさん** · 2015/12/03(木) 16:32:54.69

>>134
mallocでOSから確保したメモリはfreeで解放されないんだが、

「ここで解放」はどうやって書くんでしょう?

**デフォルトの名無しさん** · 2015/12/03(木) 19:43:25.89

>>137や>>139みたいのが知識や技術に溺れて本質を見失い、
人と会話ができなくなった人の見本なんだろうか

**デフォルトの名無しさん** · 2015/12/03(木) 19:47:17.15

>>140
今まで正しいと信じきってた鰯の頭が迷信だと指摘され発狂中

**デフォルトの名無しさん** · 2015/12/03(木) 19:53:39.75

>>141おｗ　おまえ会社で孤立してるだろ派遣ｗ

**デフォルトの名無しさん** · 2015/12/03(木) 20:32:35.32

確保したやつが解放するんだぞ。大丈夫か？

**デフォルトの名無しさん** · 2015/12/03(木) 20:33:46.24

想像を絶するアホは居るもんだよ
if (cond) exp; の場合も中カッコを必ず付ける流派ってのがあって
理由を聞くと
if (cond) {exp1; exp2;}とするはずが
if (cond) exp1; exp2;としてしまうのを防ぐための常に中カッコらしい

中カッコを書き忘れるくらいの意識レベルで書かれたコードって
他のとこももう全部ダメだろそれは

**デフォルトの名無しさん** · 2015/12/03(木) 20:52:03.75

>>144
お前がアホなｗｗｗ

**デフォルトの名無しさん** · 2015/12/03(木) 21:25:03.70

カッコ先につけといたほうが　後々、都合がいいことも

**デフォルトの名無しさん** · 2015/12/03(木) 21:30:08.65

アホな書き方といえば
　if ( 1 == a ) {
って比較元と先を逆にしてる奴

**デフォルトの名無しさん** · 2015/12/03(木) 21:41:57.39

別におかしくない
基準値が先にあって、それと比べてaがどうなのか、と考えるか
aが先にあって、基準値と比べてどうなのか、と考えるかの違いでしか無いから
どっちでも良い

**デフォルトの名無しさん** · 2015/12/03(木) 21:59:47.07

>>147
知ってて言ってると思うが、定数を==の左辺にするのは
if (a=1) { ...
と書き間違うのを恐れているらしい

>>139
free()から設計し直す、
まあfree()の度OSにメモリを律儀に返していたらパフォーマンスが多少落ちるがGCに精神を汚染されるよりはマシ

>>135
スレッド安全に書かない奴が悪いていうかそれは別の話
シングルスレッド状況（またはそれと等価な状況）では>>134の言っていることは全く正しい

**デフォルトの名無しさん** · 2015/12/03(木) 22:27:47.14

ここ数日一気にレベルが下がったなw
ＧＣの話しろよw

**デフォルトの名無しさん** · 2015/12/03(木) 22:46:13.76

つーか前スレと同じこと書いてる人多数
頼むから前スレ読んできて

**デフォルトの名無しさん** · 2015/12/04(金) 04:37:18.54

【　オンラインTCGエディター　】　>>1

デュエル・マスターズ的な非電源TCGの　《　オンライン化ツクール系ソフト　》　制作の企画。

例えば、ガチンコ・ジャッジを直ぐにでも導入できる機能を持っておりながら、
当面それを扱わず単純化させておいて、事後的に導入拡張する際に当該システムを
ブロック構造の組み合わせで後付け挿入できるように予めシステム化してあるソフト（エディター）。
既存の非電源TCGを劣らずに再現できるならば大概のニーズに応えられる筈。
バトスピ、ヴァンガ、ウィクロス、ポケカ、デジモン、ゼクス、モンコレ、ガンダム・ウォー、ライブオン、ディメンション・ゼロ、カードヒーロー、シャーマン・キングなど
のシステムを完全再現できるように設計するけど、他に此のTCGの此のシステムは再現希望とか有ったら書いて。
マジック：ザ・ギャザリングの全システムを完全に再現するのは無理だから、此れだけは必用だ！って部分のみリクエストして。
WEB通信での対戦は、個vs個、多数乱戦、チームvsチーム、個vsチームを可能な仕様とする方針。

設計思想は　《　RPGツクール　》　が良いかな？　　他に、優れたエディター有ったら挙げてみて。

個人や企業などのベンダーが提示する開発費（見積もり）で折り合えば、発注する。
↓
エディター群から基本コンセプトを絞り込む（もちろんオリジナルで優れた新ネタが有れば導入する）。
↓
遊戯王OCGに関しては、タッグフォース、ADS、デュエルオンラインを発注先ベンダーに研究させる。
なるべく前述３つで可能な再現は全て実装させる方向を目指す。　まぁ努力する・・・
バトスピ、ヴァンガ、バディ、デュエマなど発売済みゲームソフトが存在してるケースはベンダーに研究させる。
↓
各社TCGを再現するテストプレイ　⇒　更に改良や修正。
↓
機能制限した下位版を５万円以上で発売　＋　デュエリ－グ用に改造した上位版でサーバー稼動＝営業開始。
↑
下位版の改造および商用利用には、別途で当社との契約が必要。

さ～て、製作ベンダー見つけよっと！ｗｗ（ｸｽ
http://wc2014.2ch.net/test/read.cgi/entrance2/1449039272/-18

**デフォルトの名無しさん** · 2015/12/04(金) 12:21:13.29

>>149
>free()から設計し直す、
>まあfree()の度OSにメモリを律儀に返していたらパフォーマンスが多少落ちるがGCに精神を汚染されるよりはマシ

じゃ>>134は設計し直してから言うんだな。坊や。
って、事でオッケーね。

**デフォルトの名無しさん** · 2015/12/04(金) 20:05:33.81

>>137これって何が言いたいの？OSやライブラリ自体にミスがあるって言いたいの？
wikiより
>メモリリーク (Memory leak) とは、プログラミングにおけるバグの一種。
>プログラムが確保したメモリの一部、または全部を解放するのを忘れ、確保したままになってしまうことを言う。
>プログラマによる単純なミスやプログラムの論理的欠陥によって発生することが多い。

>>137みたいなこと言う奴って、電磁波からデータが盗まれる！対応しないと！とか言い出すタイプ？

**デフォルトの名無しさん** · 2015/12/04(金) 21:16:45.71

>>151
そもそも１５年ぐらい前から延々繰り返されてるんだが…

**デフォルトの名無しさん** · 2015/12/04(金) 23:45:19.53

>>154
開放コードを忘れずに書いたのに開放されないという怪奇現象がマルチスレッド状況ではしばしばあるんじゃー！
マルチコア時代になってこれはますます危険になった
見ただけで正しさがわかる系のスレッド安全策はクロックサイクルを糞のごとく消費するし…

こういうのは専門家が徹底的にデバッグしたGCで面倒を見て欲しいと思う反面、
やっぱプロセス全体のごみ処理を選任モジュールにやらせるのはクロックサイクルをドブに捨てるがごとき
センス無い設計なｷﾓｽ、、

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

それ単にメモリバリアの問題じゃ…

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

>>154
入門書に書いてるコードしか見たことないんだね。
スレッドプールみたいなテクニックは高速化のためにみな普通に使うんだよ。
OSやライブラリにもメモリリークなんてよくあることだし、それらのバグも開放忘れて起きてるイージーなバグじゃないよ。
他のバグやトラブルがメモリリークという形で表面化してるにすぎない。

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

>>158
具体的にいつのどのバージョンのライブラリで起きてるの？
使い終わったらメモリを開放しろ。使い終わってないなら開放する必要はない。これとスレッドプールとどこに関連性があるの？

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

>>159詰めても無意味。
こういう連中は、まず自分の考えややり方が絶対正しく絶対に曲げない。曲げないために無理やり理由を当てはめようとしている。
で、さもそれを自分はやってるように言っているが、実際は単に本に載ってることを言ってるだけ。
実装もできない。面前で詰めてやれば発狂して勝敗がハッキリつくけどネット上では無理だね。

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

メモリの話とスレッドの話を混ぜ込んでしまうタイプは
問題の切り分けがそもそも出来ないタイプ
だからメモリリーク（）に悩まされる

スレッド間の協調と、メモリのケアは直交する別の話題

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

>>158
ちょっ漏れが作ったわけでも漏れの使い方に問題があるわけでもない階層で起きるメモリリークの責任を漏れに負わされても困る…
それに他人が作ったモジュール内でのメモリリークも結局は開放が書かれていなかったか、書かれていても正しくなかったからリークしているはず…

>>161
全面同意だが同意したからと言ってメモリリークがゼロになるかっていうと以下略
単純にクリティカルセクションとかキューによるシリアライズ（Active Objectパターン）で排他して
マルチコアを活かさずパフォーマンスをドブに捨てて良ければ平和なんだが…

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

だからメモリを自動開放してほしいときはスマートポインタを使えばよいだろ
循環参照が無い限りshared_ptrで問題ないだろ
循環参照がある場合はどちらかをweak_ptrにすれば済む話だろ

現実にshared_ptrの様な物が存在して無いなら、そういう議論も意味があるが
実際にはshared_ptrは現実に有るのだから、自動管理したい場合は使えばよいだけの話でしかない

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

むしろ議論すべきはshared_ptrのような参照カウンタ方式のスマポと
言語ビルドインのマークスイープ系のGCとで
どちらが良いか、だろう

参照カウンタ方式は循環参照で問題を起こすし
マークスイープ系のGCはいつ実行されるか分からない

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

つまり、完璧なGCは無いということだ

完璧なGCが無い以上、使う側が状況に合わせて選べた方が良いわけだが
そうなるとC++/CLIのような変体言語しかないのが残念だ

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

普通に言語を選べば良いだけの話では

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

このスレ論点が一致してないよね。
　freeやdeleteを記述すべきという論点で話をしている人
　freeやdeleteしたところでメモリが解放されてるわけではないですがという論点の人
　freeやdeleteは当然、さらにnull等を記述すべきという論点で話をしている人
　GCの実装そのものを論点にしている人
論点がばらっばらだから咬み合わない

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

>>158
> OSやライブラリにもメモリリークなんてよくあることだし

よくあると言うなら１０個ぐらいすぐにあげられるよな
もちろん最新版でリークする奴ね

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

MSのサイトにfix分と調査中のものが全部公開されてる。他のOSもlog、mlみれば腐るほど出てくる。

10個上げろとか、ほんと幼稚園児かよ、おまえらは。頭悪すぎw

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

C++でRAIIを徹底しておくのが一番いいよ
解放タイミングのコントロールが必要になったら後からでも柔軟に対応できるし
GCは解放に係る少し変わった条件が発生した時に滅茶汚いことをしなきゃならなくなる

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

shareed_ptrはC++で比較的効率よくやれることと、GCしたい人が真にやりたいことの妥協の産物であって
どんなシチュでもベストにフィットするような一押しの決定版ってほどでも無い…

参照カウンタの排他が不要で循環参照が無いことも保証できるまで設計が詰められているなら
スレッドごとに、メモリを確保して使って返す処理を直に書くのが一番良い

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

確保／解放を直に書くのはスピード的には一番速いだろうけど解放漏れバグの温床過ぎてネ
特に例外が絡むとやってられない状況になる

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

>>167
null云々は別言語だ馬鹿

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

>>169
> もちろん最新版でリークする奴ね

早くあげてよね w

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

>>172
>特に例外が絡むとやってられない状況になる
そこだけはstd::unique_ptr<T>の一押し
これで例外状況でのRAIIが完成するので真にGCが要らんところまで逝く

ていうか大概のアプリなら、例外を生じたらFatal errorなことをユーザーに知らせて終了、でいいんじゃ…

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

>>175
いやーリソース獲得した状態でファイルI/Oとかネットワークとかが絡む場合は終了じゃすまん場合が多いでしょ

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

昔C言語で数珠繋ぎの独自スコープとしてblock_enter/block_leaveというのを作って

{
block_handle h = block_enter(b)

object = block_create_object(h)

block_leave(h)
}

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

書き損じた
昔C言語で数珠繋ぎの独自スコープとしてblock_enter/block_leaveというのを作って

func(b){
block_handle h = block_enter(b)

object = block_create_object(h)

block_leave(b, h)
}
というので例外にも対応したリソースマネージャ作った
block_leave(b, h)せずにスコープ抜けても上位のblock_leaveで開放が保証されたり
block_leave(b, 0)で全開放とかそんなの

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

デメリットはblock_create～で作成するものは全部ヒープに確保されること
結局C言語でここまで必要な案件てのが回ってこなくてあんま使ってないけどリーク予防法の参考程度に

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

例外にも対応って？

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

C#でアンマネージドなメモリを扱えるのはわかった
確保したメモリ領域にオブジェクトを配置する事は出来ない？
C++で言うところの配置newを再現したいんだ
メモリの確保解放はプログラマが特別に管理してその間は普通のオブジェクトと同じように透過的に扱いたい

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

>>180
例外つってるのは具体的にはSEHの話
どっかで止めた時点のblock_leave(b, h)でそれまでの開放が保証されるってこと

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

C++にfinallyが無いのが気に食わない
今はラムダが有るのでマクロでそれっぽいものを自作したが
標準で用意しておいてほしい
C++はリソースを自分で管理する傾向のある言語なのに
finallyが無いのは本来おかしいよな
ラッパー作ってRAIIを徹底しろってことなんだろうけど
すべてのリソースに対してラッパーを用意するのは面倒だよ
fainallyが有ったって邪魔になるわけでもないのに
最終的に使うかどうかは利用者が選べばよいことだし
C++ってそういう言語だろ

**デフォルトの名無しさん** · 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のファイナライザに全てを任せてメモリと同様にリソースを完全に透過的に扱うべきだ

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

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