C++相談室 part150
■ このスレッドは過去ログ倉庫に格納されています
>>410
それは GC の種類によるんじゃないでしょうか？
参照カウンタ方式のGC（私は、参照カウンタ方式はGCと呼ばない人ですが）ならGCがあってもリークするでしょうし、
GCの元祖マークアンドスウィープ式や、これも昔からあるコピーGCならば、リークはしないでしょうね 上のリンクのガベージコレクションの限界
に書いてある 無限に増えるキャッシュ
->使っているからリークじゃない
ログ的なデータを延々と追加するだけ->
リーク
終了時にファイル出力->リークじゃない
つまり、ファイル出力機能を後から追加することでリークじゃなくなるんだな
それでメモリ足りなくなったらなんて呼ぶんだろう リークかどうかじゃなくて使ってるか使ってないかだな
プログラマー的には使ってないけどプログラム的には使ってるものをリークと呼ぶのが適切とは思えんけど プログラマー的には使ってないけどプログラム的には使ってるものをリーク
プログラマー的には使ってるけどプログラム的には使ってないものをリーク
プログラマー的には使ってないけどプログラム的には使っないものをリーク
プログラマー的には使ってるけどプログラム的には使ってるものをリーク どの立場で見るかでしょ
言語のランタイムシステムの立場では参照が残ってるんだったらリークではないといえる
人間の立場では無限にメモリ使ってるつもりがないのにメモリが枯渇するのでリークしてる
現実問題は人間の立場で見るのだから後者でよい 枯渇したらリークってのもおかしいぜ
必要容量のRAMを実装していないのがリークになっちまう >>420
典型的にそうやってメモリリークに気づくからそう書いただけ
gc言語でもリークに気を付ける必要があるというのは
20年前ぐらい前から言われている
組み込みJavaが流行った時とか特にね 明示的に解放できないシステムでどうやって気をつけるんだよ
さっきからシステムのバグつってんだろ そもそもGCが解放してくれないのはリークではないからだろうが >>412
元祖マークアンドスィープ法やコピーGC ではリークしませんね、これは断言できるでしょう >>414
リンクのwiki には、参照カウンタ方式のリークは書いてあっても、マークアンドスウィープ法やコピーGC についてはリークするとは書いていませんね >>416
あなたはまず、あなたのリークの定義を正確に記述する必要がありますね、現状、あいまいなのでは？>>395 >>419
＞人間の立場では無限にメモリ使ってるつもりがないのにメモリが枯渇するのでリークしてる
それはメモリ不足であって、リーク（「漏れる」）ではないのでは？ >>425
なぜ、リンク先が参照カウンタ方式のことしか述べていないと思ったのですか。
参照カウントではないC#でも弱い参照が存在することは
>>415のリンクで説明したはずですが。 >>428
＞参照カウントではないC#でも弱い参照が存在することは
①強い参照、弱い参照を使い分ける方式は、参照カウント法の一種だと認識しています
②元祖マークアンドスウィープ法、コピーGC法では原理的にリークは発生しませんし、発生し得ません >>410
おまえさんWikipediaってどんな所だか知ってるか？
ちなみに俺もとあるページを執筆したことがあるが
俺はどこの馬の骨か聞かれもしなかったし
アホなミスをしでかしてもあんまり指摘されないし
悪意のある文面をやめさせるのにも手間取るぞ
査読できる人でないと鵜呑みは危険だぞ 一方、マーク・アンド・スイープ方式やコピーGC方式では循環参照によるメモリリークは
発生しないが、非意図的オブジェクト保持（unintentional object retention）が引き起こす
メモリリークを強参照のみによる実装で解消することは難しく煩雑であり、
実装を簡略化するために弱参照が用いられることがある。
https://ja.wikipedia.org/wiki/%E5%BC%B1%E3%81%84%E5%8F%82%E7%85%A7 >>431
>>429
①強い参照、弱い参照を使い分ける方式は、参照カウント法の一種だと認識しています 使ってる言葉の意味が異なる人を説得するのは無理だと悟った また面倒なのが出てきたな
wikipediaのリンクで終わったかと思ったのに
QZは頭が弱いから >>426
407の定義だと曖昧すぎて気持ち悪くなるって例出しただけ
確保したメモリを使用しなくなったのに解放しないまま管理外にするのが狭義のメモリリーク
それ以外の現象もメモリリークと呼ぶのは知っているが、その呼び方は混乱招くから好きじゃないって立場 使わない、使うつもりもない、プログラマが意図しないメモリ
これらが増え続ければリーク
定義じゃなくて十分条件の例 >>422
> 明示的に解放できないシステムでどうやって気をつけるんだよ
gc言語で本格的な開発したことないって白状してるようなもんだね
メモリプロファイラで地道に調べるんだよ
あと不要になったらgc任せにせずに即null代入しておけとかよく言われるだろ
> さっきからシステムのバグつってんだろ
システムって何だよ？意味広すぎるから説明になってない
gc言語においては言語レベルではリークしない(循環参照はさておき）
が依然人間の不注意によって実質的なリークは起るわけ
それをお前はリークと呼ばなんだろうけど一般的にそれもリークと呼ばれてる
それだけの話
理解しようぜ >>430
wikipediaは
歴史系は特に悪意のある文面多いですね
特に日本史 >>423
昔から言われてることだけに昔の記事あったからこれでも読んでみ
ttps://www.atmarkit.co.jp/fjava/rensai3/debug02/debug02_1.html
単に何をリークと呼ぶかというだけの話
Javaの開発元のサンの人もこういうんだからそれにあわせようぜ >>438
GCが解放してくれるとプログラマが信じているが事実はそうでないケース プログラマーが自分で作ったつもりのスレッドで資源を確保して、
スレッドの最初の関数からreturnしたら全部解放されると思いきや！
実はスレッドプールの1要素としてシステムが握りっぱなしだった、
みたいなテクノロジーホラーが
あるのかも
しれませんね
知らんけど >>377 のリンク先のソースをすっかり理解できたとは言い難いけど、
この場合の <float, float, float> は (何かの角度, x座標, y座標) みたいね。
vecVisibilityPolygonPoints は最初の要素(角度)でソート済み。
get<1>()でx座標、get<2>()でy座標を取れるから >>375 の第2段落の理屈は有効。
>>363 の質問に戻ると、
{0.1, 0.11, 0.2, 0.21, 0.4, 0.41}
↓
{0.1, 0.2, 0.4}
の理解でだいたい合ってる。単一の値の比較でなく
「x座標同士, y座標同士が両方とも近い値の場合だけまとめる」わけだが。
もうひとつ。376で tupple::get と書いたけど、もちろん tuple::get が正しい。
(ここを訂正しておきたかった)。 ちゅか循環参照するオブジェクトの解放のための正しい方策はマーク＆スイープ方式であって
普通の言語においては弱参照はあんま助けにならないﾊｽﾞ
（普通の言語では、一旦解放したオブジェクトを復活させることはプログラマがそのような復活コードを書かない限り不可能なため、
使用予定があるオブジェクトを単に弱参照にしてGCに好きなタイミングで解放させるだけだとプログラムがロシアンルーレットになる
実際のところ弱参照を用いてﾋﾔﾋﾔしながら辻褄合わせする（結局何がしかのコードが必要）なぐらいなら、
最初からGCに頼らずに確保と解放をコード上で明示的に計画した方がﾏｼ
で、マーク＆スイープ方式はマークのための空間と時間の計算量（探索！）が必要な上に、
その挙動をユーザーが書くプログラムコードから隠しおおせる言語でないと適用できない C++でマーク&スイープしようとすると、オブジェクトaを所有するオブジェクトbの確保、が単に構造体をnewするだけでは済まなくなってしまうま
（所有関係をGCに教えるための呼び出しを書かねばならない。プログラムが小汚くなっていき、ぜってー忘れたり間違える >>437
GCが本当に機能しているか点検せにゃならんオンボロ環境での話を一般化するな
> 不要になったらgc任せにせずに即null代入しておけ
クルマに例えるとすぐエンコするから人力で押せだな >>429
>>432
弱参照は参照カウントなんて珍説はない
マーク·アンド·スイープアルゴリズムで弱参照の経路は辿らず、他からの経路がなければ到達不能と判断することで参照数を数えてるわけではない >>437
> gc言語で本格的な開発したことないって白状してるようなもんだね
おまえさんこそ、相手の経歴や人格を攻撃せねばならんほど窮しているのが露呈してるぜ
頭の中で問題が整理できていれば冷静かつアカデミックに指摘ができるはず
そんなに頭に血が昇るのは問題が整理できていないか沸点の低いアレなやつか又は両方だな >>440
大企業のやつに合わせるなら
おまえさんもシステムハンガリアンやれよ >>422
・ GC のない言語でうっかりメモリの解放を忘れる
・ GC のある言語でうっかりもう使わないオブジェクトの参照を残してしまう (GC の回収対象にならない)
リークと呼ぶかどうかはともかくとして、
前者で気を付けなきゃならないのと同様に後者にも気を付けないといけないというのは普通のことだと思うよ。 >>388
> >>387
> 参照元が生きているのをリークとは言わない
> その状態で意図しない動作になるのはリーク以外のバグってだけだ
一般的にそれが意図しないものなら現象としてリークと呼ぶというだけの話
これを認めたら死ぬのかお前は QZアホやｗ
Javaのメモリリークを見つけるのがどんだけ面倒なのか全く分からないようだ
こいつプログラマじゃないな >>452
> ・ GC のある言語でうっかりもう使わないオブジェクトの参照を残してしまう (GC の回収対象にならない)
じゃあ、そもそもGCって何のためにあるんだってことだね
私見ながら、馬鹿馬鹿しいぜ 資源を解放すべき盤面で、自動化されてるんだから手を出しちゃダメ
あげく解放されませんでした、解放されてるかどうか確認をせよ
何なのコレ？ >>455-456
事例としては
例1： 使い捨てスクリプト
その程度の管理で良い。
ガッと動かしてそのまま終わるので管理もクソもない。
例2： サービスの変更が多いウェブサービス
まずは早期に動かすことが大事。
細けぇことは後でプロファイラを見ながらなんとかする。 >自動化されてるんだから手を出しちゃダメ
ﾊｱｗｗｗｗ？
コードで明示的にマークも出来ますが何かｗｗｗｗｗｗｗｗ
>あげく解放されませんでした、解放されてるかどうか確認をせよ
ﾊｱｗｗｗｗｗｗｗｗｗ？
>>456は不具合を発見してから不具合がないか確認するタイプ？ｗｗｗｗｗｗｗｗｗｗｗｗ >>457
テキトーこきたいって正直に言ってくれれば
こっちもあっそーで済む
>>458
明示的にマークという時点でGCの敗北なんだよ
仕事でもそうだろ、引き受けたことをやってくれないやつは
もう信用されない できねえことは端っから引き受けるな
おまえさん、ぬるま湯に浸かってる人かい？ 「資源の解放はお任せくださいっ！！(ｷﾘｯ
「あのー循環参照が・・・
「メモリーだけです！！（汗
「資源じゃなかったんですか？
「そのくらい察して下さい！！（滝汗
「もういいです 仕事でしゃーなしに使う言語あるいは
知ったかしたいアマチュアが使う言語、それがC++ 仕事で喜んで使う言語だな
c#とかjavaとかだと嫌になる >>462
java は、少なくとも昔の java は、厳しく抑制のきいた文法と豊富なクラスライブラリでいい感じだと思いますよ、文法は意味があっての簡素なほうが好みですね
c# は、クラスライブラリの全容を把握していないので、まだ評価にとりかかれないのですが、これからじっくり調べたいと思っています Javaは新しいCOBOLになってしまった
当初の理想は良かったと思うけどままならんもんだね >>461
シッタカにいつもマウント取られる水準のやつからは、そう見えるだろうな まともにコンパイルも通してないで知ったかしてるバカに言えることなんてないけどね。 >>459
gcの勝ち負けなんか論じてないだろ
話すり替えて誤魔化すな
お前態度でかいわりに理解が周回遅れなんだよ >>467
俺も論じてないんだがｗ
何が怪物に見えたのかな？ 病院行ったほうがいいと思うぞ なんで
long long abs(long long x)
なんだろうか
負の数の方が絶対値の大きい値が表せちゃうのに 0x8000000000000000 代入してみろ long longでないとすると、何型が妥当だと思う？ >>465
このスレで知ったかの相手すると荒れるから、大抵中身の無いマウントカキコはスルーされてるんだが つまり、こういうことか
template <typename T>
auto abs(T val) -> enable_if_t<is_integral_v<T>, make_unsigned_t<T>>; singedとunsigned混在すんなってことだよ
c言語レベルの質問はc言語スレでやれ
というか語りつくされた話題だから適当にググれ 背伸びしたい無職が使う言語は
C++かHaskellと相場が決まっとる C++14(gcc)でUTF8の正規化をする場合、どんなやり方が良いとされているのかご教示ください。
C++ではやったことがないので初歩的なところからご教示いただけるとありがたいです。
・ICU以外の選択肢はあるのか？
・ICUを使う場合、直接APIを使うよりBoost.localeを使った方が良いのか？ >>477
文字コードスレできいたら？
icuで足りるんならicuでいいと思うけど
自分の経験ではicuのでかくて重いのが問題だったらから
必要な機能だけ自作したな
(unicodeがリリースしてるテストデータをパスさせた) 普通はc++だろ
javaとかc#とか環境整えるの面倒くさいじゃん >>476
Cはかつて最大人気言語だった歴史があるのに対し、HaskelやRustはそうではない。
C++もCの人気を受け継いだ言語だし、処理速度が高速でメモリー使用量も少なく、
起動も速いし、Windows以外でもとても広いプラットフォームで簡単に動くのだから、
使うのは自然な流れだし、背伸びとかではない。
例えば、C#をAndroid/iOS/Linux/Macで動かすのは容易ではない。
Wasmで動かすにもネットからのダウンロード量が多くなり起動が遅くなる。
一方、C++ならWasmでも起動が速い。 >>483
C++を動かすのはOS以外に基本的に特殊なランタイムが要らない。
C#やJavaでは.NET環境やJVMが必要となる。
AndroidでもJNIを使えばC/C++は起動も速く動作速度もJava/Kotlin以上に軽快に動く。
同様にiOSでも、Swiftとリンクできるので同様。
逆にC#は、iOSやAndroidで動かすにはダウンロード時間や起動速度に問題があり、
動作速度にも desktop マシン以上に問題がある。
Androidだと、Java/Kotlinの仮想マシンの上に、.NETの仮想マシンを二重に載せる
形となるため、C/C++と比べれば、掛け算の形で遅くなってしまう。 例外やRTTIをイネーブルしてるとでかいスタティックリンクつくけどね CならRAM16バイトのPIC10F200でも使える >>486
ソースコードの見た目とバイナリのサイズがCと違いすぎって意味 Arduinoで使ってること考えたら、十分使える。
RAM2KBしかない。 >>485
スタティックリンクってどのライブラリをリンクするってこと？
そんなのあったっけ？ >>485
.NET環境は、それどころじゃない。
それはWindows Updateを見ていれば分かる。
.NETのUpdateのために、数百MB～数GBダウンロードされる。 >>479
自作はやりたくないのでICUを軸に色々試してみることにします。
ありがとうございました。 >>494
gcc のオプションに -static を加えればいいのでは？ >>498
https://gcc.gnu.org/onlinedocs/gcc-9.3.0/gcc/Link-Options.html#Link-Options
-static
On systems that support dynamic linking, this overrides -pie and prevents linking with the shared libraries. >>499
流れを読め。 >>485 みたいな状況でバイナリがデカくなる→何がスタティックリンクされるんや？ って話題だぞ。 マップファイルを出力させてみれば実際に何がリンクされるかはわかるんちゃう？
試してないけど。 libgccの大きさじゃなくてunwind用のハンドラコードの増加じゃないの？
(間違って別スレに書いてしまった) >>503
RTTI の場合は、仮想テーブルと同様の場所に、実行時型情報へのリンクポインタが
書き込まれるようになる。
それがなかなか複雑な構造をしている。
RTTI情報も、ヘッダファイルの中に構造体が書いてあると、COMDAT形式で
全ての *.obj ファイルの中にいったん書きこまれることがある。
リンク段階で同じデータのsectionがある場合は、単一のsectionだけを残して
他は削除されてしまうが。 >>504
構造化例外もなかなか複雑なコードになる。
そのコードもある程度の大きさになる。 >>484
mono、core、zamarin調べて出直してこい enum class を1オリジンにするスタイルはどの程度使われていますか？ char8_tってどういう経緯で採択されたんですか？
Microsoftを利する提案が受け入れられるのは相当珍しいと思いますが。 >>508
色々と事情はあるみたいなんだけど、
UTF-8 の文字列と従来の文字列を型で区別したいというのが主な理由だと思う。 その要望は昔からあるけど阻止してきたのに、なぜ解禁されたのか事情知りませんか？ ■ このスレッドは過去ログ倉庫に格納されています
