C++相談室 part150

**デフォルトの名無しさん** · 2020/03/24(火) 00:04:33.93

C++に関する質問やら話題やらはこちらへどうぞ。
ただし質問の前にはFAQに一通り目を通してください。
IDE (VC++など)などの使い方の質問はその開発環境のスレにお願いします。

前スレ
C++相談室 part149
https://mevius.5ch.net/test/read.cgi/tech/1581974381/
このスレもよろしくね。
【初心者歓迎】C/C++室 Ver.105【環境依存OK】
http://mevius.5ch.net/test/read.cgi/tech/1556142878/

■長いソースを貼るときはここへ。■
　http://codepad.org/
　https://ideone.com/

[C++ FAQ]
https://isocpp.org/wiki/faq/
http://www.bohyoh.com/CandCPP/FAQ/ (日本語)

テンプレここまで

**デフォルトの名無しさん** · 2020/04/25(土) 23:12:19.03

ポリゴンだからソートする必要ないのか

**デフォルトの名無しさん** · 2020/04/26(日) 00:08:03.75

使ったこと無いから知らんがstd::unique<T>()は
>削除は、消去される要素が上書きされるように、範囲内の要素をずらすことによって行われます。
とのことなので、callerがstd::unique<T>()を呼ぶ前にソートしておく必要があるのでは…

**デフォルトの名無しさん** · 2020/04/26(日) 00:15:41.29

>>370
unique前にソートで昇順にしているみたいです。

**デフォルトの名無しさん** · 2020/04/26(日) 00:30:35.80

結局メモリーポインタ関連わかってない奴はガベコレなんかで隠ぺいした言語使っててもバグる

**デフォルトの名無しさん** · 2020/04/26(日) 05:15:56.17

vecVisibilityPolygonPoints が「1枚のポリゴンの各頂点の座標(頂点数は任意)」で
座標値は画面に表示すべき値に変換済み(透視投影が完了している)、
<float, float, float> が (x, y, z) を表すと仮定すると…

隣合う頂点のx座標同士、y座標同士がそれぞれ十分に近ければ
その「極端に短い一辺」を1つの頂点とみなして表示処理を軽減、って感じかな。

resize() の結果 size() が 1 か 2 になったらポリゴン全体が
「見えないポリゴン」になるので丸ごと省略、までやるかも。

**375** · 2020/04/26(日) 05:26:01.50

tupple::get<> は 0 始まりだから y, z 座標だね(>>370 さんの言う通り)。
すると少々怪しいか、素朴な仮定だとスッキリ辻褄が合わない。

**デフォルトの名無しさん** · 2020/04/26(日) 06:57:42.91

申し訳ありません。
>>363のコードは
ttps://github.com/OneLoneCoder/olcPixelGameEngine/blob/master/Videos/OneLoneCoder_PGE_ShadowCasting2D.cpp
の416行からです。

**デフォルトの名無しさん** · 2020/04/26(日) 08:53:55.40

>374
確かにGCあり言語でのリークなんかは逆にデバッグがかなり難しい。
理解してないやつはまず無理。

**デフォルトの名無しさん** · 2020/04/26(日) 10:44:13.53

そういうのはシステムのバグで
自分の落ち度じゃねえだろ

**デフォルトの名無しさん** · 2020/04/26(日) 11:12:47.10

システムのバグ以外にリークが起きないとでも思ってるの？

**デフォルトの名無しさん** · 2020/04/26(日) 11:14:07.90

起きるとでも思っているのか？

**デフォルトの名無しさん** · 2020/04/26(日) 11:15:58.89

当たり前

**デフォルトの名無しさん** · 2020/04/26(日) 11:24:00.41

えらく無口だな

**デフォルトの名無しさん** · 2020/04/26(日) 11:28:31.53

プログラムの開始から終わりまで存在するオブジェクトがリストを所有しており、
そのリストに要素数制限もエラーチェックも無く無制限に増える場合とか、
オブジェクトAとオブジェクトBが互いを参照し合っている場合（循環参照）とか
いろいろ

つかオブジェクトをいつ使い終わったかを機械的に判定する難しさを考えたらﾜｶﾙ

**デフォルトの名無しさん** · 2020/04/26(日) 11:42:05.69

使わないのに参照しっぱなしで放置＝リークともとれるからね

GCはあるとちょっとは便利でしょって程度のものでヒープ管理の全体像はプログラマが把握しておくべきだと思うわ
頻繁なGCが必要なくらいにヒープ使うのであれば設計から考え直す必要あるんじゃないかと

**デフォルトの名無しさん** · 2020/04/26(日) 11:50:09.63

リークじゃねえじゃん
参照元の寿命が尽きてないんなら

**デフォルトの名無しさん** · 2020/04/26(日) 11:54:22.98

>>386
参照元の寿命が尽きていなくても使いもしないのであれば現象としてはリ～クに他ならない
違うというならメモリ消費量が際限なく増え続けるプログラムを客先に納めて
リ～クではないんですよと仕様ですよ説明して見せると良い

**デフォルトの名無しさん** · 2020/04/26(日) 12:08:46.85

>>387
参照元が生きているのをリークとは言わない
その状態で意図しない動作になるのはリーク以外のバグってだけだ
おまえさん自身がそれを仕様ですよと説明できないと言っているように

**デフォルトの名無しさん** · 2020/04/26(日) 12:13:43.92

リークですね

**デフォルトの名無しさん** · 2020/04/26(日) 12:15:41.10

狭い狭い定義しか知らないと恥ずかしいよ

**デフォルトの名無しさん** · 2020/04/26(日) 12:30:26.50

リークの字義的には微妙
プロセス外部から見える挙動はリークと同様だけど

**デフォルトの名無しさん** · 2020/04/26(日) 12:31:51.69

>>390
自分が間違って憶えているのを正当化するために定義を広くしようたって誰も協力せんぞ

**デフォルトの名無しさん** · 2020/04/26(日) 12:33:29.76

いや普通に文脈で何を問題にしてるかわかるだろ。。
勝手に自分ルールで解釈狭めてリークはないとか言い出してる奴が頭おかしいわ。

**デフォルトの名無しさん** · 2020/04/26(日) 12:43:33.17

明確な定義なんてないだろ
リークに見える挙動はリークだよ

◆QZaw55cn4c · 2020/04/26(日) 12:48:55.78

リークの定義は複数あっていいと思いますが、「①自分の定義はこれで、だから②これはリークである／ない」の①②二点を明示するべきだと思いますね

**デフォルトの名無しさん** · 2020/04/26(日) 12:49:09.81

>>393
何を問題にしているかと、それをリークと呼ぶか否かは別な話だぜ

**デフォルトの名無しさん** · 2020/04/26(日) 12:49:37.61

リークに見える？
実際リークしてるわけで

**デフォルトの名無しさん** · 2020/04/26(日) 12:50:39.33

それこそ「理解してないやつ」がテキトーこいてリークだリークだ言うのと同じだ

**デフォルトの名無しさん** · 2020/04/26(日) 12:51:44.94

まあ何から漏れているか明確じゃないのまで、リークと呼び始めた人が悪いんだな
内部的な原因も対処法も全く違うのに、外見だけで同じ名前つけられても混乱するだろうに

**デフォルトの名無しさん** · 2020/04/26(日) 12:52:48.59

リークによって起きる現象とリークは分けて考えた方がいい
本質的には未使用メモリーの蓄積だが名称がないから混乱が起きる
蓄積を処理しないのもバグ
リークは蓄積をコントロールできなくなっていて、結果的に処理していない点が違うがこれもバグ

**デフォルトの名無しさん** · 2020/04/26(日) 12:54:00.99

少なくとも>>384の巨大リストを抱えてる方はリークとは言わない
データ管理がなってないだけ

**デフォルトの名無しさん** · 2020/04/26(日) 12:55:18.24

原因は？
メモリリークによりメモリが不足してました

これだけで終わる会話を

**デフォルトの名無しさん** · 2020/04/26(日) 12:57:19.34

>>401は確かに違う

循環参照は普通検出すると思ってるけど
そうでもないシステムがある？

**デフォルトの名無しさん** · 2020/04/26(日) 12:58:55.24

循環参照で問題になるのはカウント方式の場合
C++のスマポくらいでは？

**デフォルトの名無しさん** · 2020/04/26(日) 12:59:35.20

>>401じゃなくて>>384

**デフォルトの名無しさん** · 2020/04/26(日) 13:01:31.99

int main(void)
{
void *p = malloc(1);

int x;
while(scanf("%d", x) != EOF) { //タイプミスで永久ループ
//...
}

free(p); //到達しなくなる
}
参照元pが生きているのはリークではない

**デフォルトの名無しさん** · 2020/04/26(日) 13:18:14.23

使ってないメモリ領域が増え続けるのはメモリリーク
参照があろうがなかろうが

**デフォルトの名無しさん** · 2020/04/26(日) 13:23:22.33

使ってないと言っても使うかもしれないから無限にリストが長くなっているんじゃね

純粋なインメモリデータベースだとそれはリークではないよね
問題が起きたのだとしたら、用途に対してメモリが少なかったのが悪いだけで

**デフォルトの名無しさん** · 2020/04/26(日) 13:23:31.29

管理手段が残っているのはリークではない
無駄に多く割り付けたり解放のタイミングがまずいというだけ

**デフォルトの名無しさん** · 2020/04/26(日) 13:30:11.65

WikipediaだとGCあってもメモリリークすることになってる
https://ja.wikipedia.org/wiki/%E3%83%A1%E3%83%A2%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%AF#%E3%82%AC%E3%83%99%E3%83%BC%E3%82%B8%E3%82%B3%E3%83%AC%E3%82%AF%E3%82%B7%E3%83%A7%E3%83%B3%E3%81%AE%E9%99%90%E7%95%8C

◆QZaw55cn4c · 2020/04/26(日) 13:46:44.42

>>410
それは GC の種類によるんじゃないでしょうか？
参照カウンタ方式のGC（私は、参照カウンタ方式はGCと呼ばない人ですが）ならGCがあってもリークするでしょうし、
GCの元祖マークアンドスウィープ式や、これも昔からあるコピーGCならば、リークはしないでしょうね

**デフォルトの名無しさん** · 2020/04/26(日) 14:07:55.73

どんな方式だってリークする

**デフォルトの名無しさん** · 2020/04/26(日) 14:09:19.26

使わないメモリが増え続ければリーク

**デフォルトの名無しさん** · 2020/04/26(日) 14:10:46.96

上のリンクのガベージコレクションの限界
に書いてある

**デフォルトの名無しさん** · 2020/04/26(日) 14:18:17.62

C#とかだと、イベント購読の解除忘れなどでリークすることがあるそうです。
その対策で弱参照が使われることがあるそうです。
https://ufcpp.net/study/csharp/RmWeakReference.html#weak-event

**デフォルトの名無しさん** · 2020/04/26(日) 14:19:26.91

無限に増えるキャッシュ
->使っているからリークじゃない

ログ的なデータを延々と追加するだけ->
リーク
終了時にファイル出力->リークじゃない

つまり、ファイル出力機能を後から追加することでリークじゃなくなるんだな
それでメモリ足りなくなったらなんて呼ぶんだろう

**デフォルトの名無しさん** · 2020/04/26(日) 14:37:42.83

リークかどうかじゃなくて使ってるか使ってないかだな
プログラマー的には使ってないけどプログラム的には使ってるものをリークと呼ぶのが適切とは思えんけど

**デフォルトの名無しさん** · 2020/04/26(日) 14:42:49.35

プログラマー的には使ってないけどプログラム的には使ってるものをリーク
プログラマー的には使ってるけどプログラム的には使ってないものをリーク
プログラマー的には使ってないけどプログラム的には使っないものをリーク
プログラマー的には使ってるけどプログラム的には使ってるものをリーク

**デフォルトの名無しさん** · 2020/04/26(日) 14:44:35.43

どの立場で見るかでしょ
言語のランタイムシステムの立場では参照が残ってるんだったらリークではないといえる
人間の立場では無限にメモリ使ってるつもりがないのにメモリが枯渇するのでリークしてる
現実問題は人間の立場で見るのだから後者でよい

**デフォルトの名無しさん** · 2020/04/26(日) 15:07:57.54

枯渇したらリークってのもおかしいぜ
必要容量のRAMを実装していないのがリークになっちまう

**デフォルトの名無しさん** · 2020/04/26(日) 15:17:14.94

>>420
典型的にそうやってメモリリークに気づくからそう書いただけ
gc言語でもリークに気を付ける必要があるというのは
20年前ぐらい前から言われている
組み込みJavaが流行った時とか特にね

**デフォルトの名無しさん** · 2020/04/26(日) 15:23:22.13

明示的に解放できないシステムでどうやって気をつけるんだよ
さっきからシステムのバグつってんだろ

**デフォルトの名無しさん** · 2020/04/26(日) 15:25:40.91

そもそもGCが解放してくれないのはリークではないからだろうが

◆QZaw55cn4c · 2020/04/26(日) 15:35:50.39

>>412
元祖マークアンドスィープ法やコピーGC ではリークしませんね、これは断言できるでしょう

◆QZaw55cn4c · 2020/04/26(日) 15:36:43.62

>>414
リンクのwiki には、参照カウンタ方式のリークは書いてあっても、マークアンドスウィープ法やコピーGC についてはリークするとは書いていませんね

◆QZaw55cn4c · 2020/04/26(日) 15:38:02.75

>>416
あなたはまず、あなたのリークの定義を正確に記述する必要がありますね、現状、あいまいなのでは？>>395

◆QZaw55cn4c · 2020/04/26(日) 15:39:27.90

>>419
＞人間の立場では無限にメモリ使ってるつもりがないのにメモリが枯渇するのでリークしてる
それはメモリ不足であって、リーク（「漏れる」）ではないのでは？

**デフォルトの名無しさん** · 2020/04/26(日) 15:42:28.68

>>425
なぜ、リンク先が参照カウンタ方式のことしか述べていないと思ったのですか。
参照カウントではないC#でも弱い参照が存在することは
>>415のリンクで説明したはずですが。

◆QZaw55cn4c · 2020/04/26(日) 15:47:18.06

>>428
＞参照カウントではないC#でも弱い参照が存在することは

①強い参照、弱い参照を使い分ける方式は、参照カウント法の一種だと認識しています
②元祖マークアンドスウィープ法、コピーGC法では原理的にリークは発生しませんし、発生し得ません

**デフォルトの名無しさん** · 2020/04/26(日) 15:55:37.10

>>410
おまえさんWikipediaってどんな所だか知ってるか？

ちなみに俺もとあるページを執筆したことがあるが
俺はどこの馬の骨か聞かれもしなかったし
アホなミスをしでかしてもあんまり指摘されないし
悪意のある文面をやめさせるのにも手間取るぞ

査読できる人でないと鵜呑みは危険だぞ

**デフォルトの名無しさん** · 2020/04/26(日) 15:57:08.52

一方、マーク・アンド・スイープ方式やコピーGC方式では循環参照によるメモリリークは
発生しないが、非意図的オブジェクト保持（unintentional object retention）が引き起こす
メモリリークを強参照のみによる実装で解消することは難しく煩雑であり、
実装を簡略化するために弱参照が用いられることがある。

https://ja.wikipedia.org/wiki/%E5%BC%B1%E3%81%84%E5%8F%82%E7%85%A7

◆QZaw55cn4c · 2020/04/26(日) 16:08:55.70

>>431
>>429
①強い参照、弱い参照を使い分ける方式は、参照カウント法の一種だと認識しています

**デフォルトの名無しさん** · 2020/04/26(日) 16:10:32.96

使ってる言葉の意味が異なる人を説得するのは無理だと悟った

**デフォルトの名無しさん** · 2020/04/26(日) 16:21:48.25

また面倒なのが出てきたな
wikipediaのリンクで終わったかと思ったのに
QZは頭が弱いから

**デフォルトの名無しさん** · 2020/04/26(日) 16:22:02.20

>>426
407の定義だと曖昧すぎて気持ち悪くなるって例出しただけ

確保したメモリを使用しなくなったのに解放しないまま管理外にするのが狭義のメモリリーク
それ以外の現象もメモリリークと呼ぶのは知っているが、その呼び方は混乱招くから好きじゃないって立場

**デフォルトの名無しさん** · 2020/04/26(日) 16:26:58.57

使わない、使うつもりもない、プログラマが意図しないメモリ
これらが増え続ければリーク

定義じゃなくて十分条件の例

**デフォルトの名無しさん** · 2020/04/26(日) 16:28:11.48

>>422
> 明示的に解放できないシステムでどうやって気をつけるんだよ

gc言語で本格的な開発したことないって白状してるようなもんだね
メモリプロファイラで地道に調べるんだよ
あと不要になったらgc任せにせずに即null代入しておけとかよく言われるだろ

> さっきからシステムのバグつってんだろ

システムって何だよ？意味広すぎるから説明になってない
gc言語においては言語レベルではリークしない(循環参照はさておき）
が依然人間の不注意によって実質的なリークは起るわけ
それをお前はリークと呼ばなんだろうけど一般的にそれもリークと呼ばれてる
それだけの話
理解しようぜ

**デフォルトの名無しさん** · 2020/04/26(日) 16:28:26.47

管理外っていうのは何を示してるかよく分からない

**デフォルトの名無しさん** · 2020/04/26(日) 16:29:38.80

>>430
wikipediaは
歴史系は特に悪意のある文面多いですね
特に日本史

**デフォルトの名無しさん** · 2020/04/26(日) 16:43:46.17

>>423
昔から言われてることだけに昔の記事あったからこれでも読んでみ
ttps://www.atmarkit.co.jp/fjava/rensai3/debug02/debug02_1.html

単に何をリークと呼ぶかというだけの話
Javaの開発元のサンの人もこういうんだからそれにあわせようぜ

**デフォルトの名無しさん** · 2020/04/26(日) 16:45:39.03

>>438
GCが解放してくれるとプログラマが信じているが事実はそうでないケース

**デフォルトの名無しさん** · 2020/04/26(日) 16:49:23.41

プログラマーが自分で作ったつもりのスレッドで資源を確保して、
スレッドの最初の関数からreturnしたら全部解放されると思いきや！
実はスレッドプールの1要素としてシステムが握りっぱなしだった、
みたいなテクノロジーホラーが
あるのかも
しれませんね
知らんけど

**デフォルトの名無しさん** · 2020/04/26(日) 16:58:02.62

MSVCのstd::asyncでは

**375** · 2020/04/26(日) 17:17:04.65

>>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 が正しい。
(ここを訂正しておきたかった)。

**デフォルトの名無しさん** · 2020/04/26(日) 17:35:47.46

ちゅか循環参照するオブジェクトの解放のための正しい方策はマーク＆スイープ方式であって
普通の言語においては弱参照はあんま助けにならないﾊｽﾞ
（普通の言語では、一旦解放したオブジェクトを復活させることはプログラマがそのような復活コードを書かない限り不可能なため、
　使用予定があるオブジェクトを単に弱参照にしてGCに好きなタイミングで解放させるだけだとプログラムがロシアンルーレットになる

実際のところ弱参照を用いてﾋﾔﾋﾔしながら辻褄合わせする（結局何がしかのコードが必要）なぐらいなら、
最初からGCに頼らずに確保と解放をコード上で明示的に計画した方がﾏｼ

で、マーク＆スイープ方式はマークのための空間と時間の計算量（探索！）が必要な上に、
その挙動をユーザーが書くプログラムコードから隠しおおせる言語でないと適用できない

**デフォルトの名無しさん** · 2020/04/26(日) 17:38:44.84

C++でマーク&スイープしようとすると、オブジェクトaを所有するオブジェクトbの確保、が単に構造体をnewするだけでは済まなくなってしまうま
（所有関係をGCに教えるための呼び出しを書かねばならない。プログラムが小汚くなっていき、ぜってー忘れたり間違える

**デフォルトの名無しさん** · 2020/04/26(日) 17:47:22.05

>>437
GCが本当に機能しているか点検せにゃならんオンボロ環境での話を一般化するな

> 不要になったらgc任せにせずに即null代入しておけ
クルマに例えるとすぐエンコするから人力で押せだな

**デフォルトの名無しさん** · 2020/04/26(日) 17:52:01.79

>>429
>>432
弱参照は参照カウントなんて珍説はない
マーク·アンド·スイープアルゴリズムで弱参照の経路は辿らず、他からの経路がなければ到達不能と判断することで参照数を数えてるわけではない

**デフォルトの名無しさん** · 2020/04/26(日) 17:58:01.59

>>446
Boehm GCとか

**デフォルトの名無しさん** · 2020/04/26(日) 18:06:28.71

>>437

> gc言語で本格的な開発したことないって白状してるようなもんだね

おまえさんこそ、相手の経歴や人格を攻撃せねばならんほど窮しているのが露呈してるぜ
頭の中で問題が整理できていれば冷静かつアカデミックに指摘ができるはず
そんなに頭に血が昇るのは問題が整理できていないか沸点の低いアレなやつか又は両方だな

**デフォルトの名無しさん** · 2020/04/26(日) 18:08:38.19

>>440
大企業のやつに合わせるなら
おまえさんもシステムハンガリアンやれよ

**はちみつ餃子** ◆8X2XSCHEME · 2020/04/26(日) 18:28:15.91

>>422
・ GC のない言語でうっかりメモリの解放を忘れる
・ GC のある言語でうっかりもう使わないオブジェクトの参照を残してしまう (GC の回収対象にならない)

リークと呼ぶかどうかはともかくとして、
前者で気を付けなきゃならないのと同様に後者にも気を付けないといけないというのは普通のことだと思うよ。

**デフォルトの名無しさん** · 2020/04/26(日) 18:59:47.51

>>388
> >>387
> 参照元が生きているのをリークとは言わない
> その状態で意図しない動作になるのはリーク以外のバグってだけだ

一般的にそれが意図しないものなら現象としてリークと呼ぶというだけの話
これを認めたら死ぬのかお前は

**デフォルトの名無しさん** · 2020/04/26(日) 20:36:09.72

QZアホやｗ
Javaのメモリリークを見つけるのがどんだけ面倒なのか全く分からないようだ
こいつプログラマじゃないな

**デフォルトの名無しさん** · 2020/04/26(日) 20:55:44.38

>>452
> ・ GC のある言語でうっかりもう使わないオブジェクトの参照を残してしまう (GC の回収対象にならない)

じゃあ、そもそもGCって何のためにあるんだってことだね
私見ながら、馬鹿馬鹿しいぜ

**デフォルトの名無しさん** · 2020/04/26(日) 20:57:06.36

資源を解放すべき盤面で、自動化されてるんだから手を出しちゃダメ
あげく解放されませんでした、解放されてるかどうか確認をせよ

何なのコレ？

**はちみつ餃子** ◆8X2XSCHEME · 2020/04/26(日) 21:11:50.20

>>455-456
事例としては

例1：使い捨てスクリプト
　　その程度の管理で良い。
　　ガッと動かしてそのまま終わるので管理もクソもない。

例2：サービスの変更が多いウェブサービス
　　まずは早期に動かすことが大事。
　　細けぇことは後でプロファイラを見ながらなんとかする。

**デフォルトの名無しさん** · 2020/04/26(日) 21:14:39.85

>自動化されてるんだから手を出しちゃダメ
ﾊｱｗｗｗｗ？
コードで明示的にマークも出来ますが何かｗｗｗｗｗｗｗｗ

>あげく解放されませんでした、解放されてるかどうか確認をせよ
ﾊｱｗｗｗｗｗｗｗｗｗ？
>>456は不具合を発見してから不具合がないか確認するタイプ？ｗｗｗｗｗｗｗｗｗｗｗｗ

**デフォルトの名無しさん** · 2020/04/26(日) 21:31:08.35

>>457
テキトーこきたいって正直に言ってくれれば
こっちもあっそーで済む

>>458
明示的にマークという時点でGCの敗北なんだよ
仕事でもそうだろ、引き受けたことをやってくれないやつは
もう信用されない　できねえことは端っから引き受けるな

おまえさん、ぬるま湯に浸かってる人かい？

**デフォルトの名無しさん** · 2020/04/26(日) 21:38:26.82

「資源の解放はお任せくださいっ！！(ｷﾘｯ
「あのー循環参照が・・・
「メモリーだけです！！（汗
「資源じゃなかったんですか？
「そのくらい察して下さい！！（滝汗
「もういいです

**デフォルトの名無しさん** · 2020/04/26(日) 22:53:28.79

仕事でしゃーなしに使う言語あるいは
知ったかしたいアマチュアが使う言語、それがC++

**デフォルトの名無しさん** · 2020/04/26(日) 23:02:01.07

仕事で喜んで使う言語だな
c#とかjavaとかだと嫌になる

◆QZaw55cn4c · 2020/04/27(月) 00:44:23.98

>>462
java は、少なくとも昔の java は、厳しく抑制のきいた文法と豊富なクラスライブラリでいい感じだと思いますよ、文法は意味があっての簡素なほうが好みですね
c# は、クラスライブラリの全容を把握していないので、まだ評価にとりかかれないのですが、これからじっくり調べたいと思っています

**デフォルトの名無しさん** · 2020/04/27(月) 00:49:16.60

Javaは新しいCOBOLになってしまった
当初の理想は良かったと思うけどままならんもんだね

**デフォルトの名無しさん** · 2020/04/27(月) 07:25:21.81

>>461
シッタカにいつもマウント取られる水準のやつからは、そう見えるだろうな

**デフォルトの名無しさん** · 2020/04/27(月) 07:39:21.53

まともにコンパイルも通してないで知ったかしてるバカに言えることなんてないけどね。

**デフォルトの名無しさん** · 2020/04/27(月) 10:24:31.10

>>459
gcの勝ち負けなんか論じてないだろ
話すり替えて誤魔化すな
お前態度でかいわりに理解が周回遅れなんだよ

**デフォルトの名無しさん** · 2020/04/27(月) 10:53:01.86

>>467
俺も論じてないんだがｗ
何が怪物に見えたのかな？　病院行ったほうがいいと思うぞ

**デフォルトの名無しさん** · 2020/04/27(月) 15:48:22.92

なんで
long long abs(long long x)
なんだろうか
負の数の方が絶対値の大きい値が表せちゃうのに

**デフォルトの名無しさん** · 2020/04/27(月) 15:59:47.26

0x8000000000000000 代入してみろ