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/19(日) 20:39:55.02

>>292
printf(
R"(hhhh
jjjj
kkkk
llll)");

**デフォルトの名無しさん** · 2020/04/19(日) 23:27:06.24

>>293,294

どちらも出来ました！
ありがとうございます。

**デフォルトの名無しさん** · 2020/04/20(月) 10:40:59.97

複数行ってそういう意味か？ω
出力は改行せんでええんか？ωωω

**sage** · 2020/04/20(月) 14:01:38.37

絶対に大丈夫なやり方は、こう :
printf(
　"xxxx\n"
　"xxxx\n"
);

**デフォルトの名無しさん** · 2020/04/20(月) 14:31:21.88

絶対に大丈夫とは？

**デフォルトの名無しさん** · 2020/04/20(月) 23:26:51.20

��ドキュメント

**デフォルトの名無しさん** · 2020/04/22(水) 13:20:56.58

https://ideone.com/rhcxbJ

g++とclで結果が違う
ideoneではエラー

どれが正しい？

**デフォルトの名無しさん** · 2020/04/22(水) 13:21:38.64

あ、ideoneじゃないcodepad
すまん

**デフォルトの名無しさん** · 2020/04/22(水) 13:45:29.47

https://ideone.com/wlTuyP
https://stackoverflow.com/questions/37293059/enum-size-in-practice

**はちみつ餃子** ◆8X2XSCHEME · 2020/04/22(水) 14:11:59.93

>>300-301
スコープ無し列挙定数は全ての列挙子の値を表せる整数型が基底になる。
ただし、全ての列挙子の値が int か unsigned int に収まるならば int より大きくなることはない。
この場合は int で表せないのでもっと大きい型にしたいけど最大の整数型である long でも
表せないのでお手上げって言ってる。

codepad は gcc 4.1.2 を使ってる。
つまりその時点での最新仕様は C++03 で、C++03 には long long なんていう型はない。
long 型が最大の整数。
(実際には処理系の拡張として __int64_t という名前で 64bit 整数も使えたりはするんだけど、
enum 関連で使用されるようにはなってないっぽい。)

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

>>303
レスthx

clはデフォC++14なのでlong longがあるはずなのに
何でtest2がlong止まりなのって話

std::cout << typeid(test2).name() << std::endl;
とやってみても
enum `int __cdecl main(void)'::`2'::<unnamed-enum-test2>
となるだけでlongかどうかは確認できない

さらに
void func(int) { std::cout << "int" << std::endl; }
void func(long) { std::cout << "long" << std::endl; }
これだと出力がintになる

**はちみつ餃子** ◆8X2XSCHEME · 2020/04/22(水) 17:35:14.20

>>304
> clはデフォC++14なので
cl っていうと Common Lisp を連想してまう……というのは余談として、
それは動作環境を用意できてないからこっちで実行できへんのや。
結果が違うってのはどうなるの？
実行結果も示してくれへん？
あと 64bit 版か 32bit 版かも明示してや。

> longかどうかは確認できない
列挙型はあくまでも個別の列挙型であって整数ではないので、
基底型が何かというのは std::underlying_type で調べる必要がある。

**はちみつ餃子** ◆8X2XSCHEME · 2020/04/22(水) 17:39:14.29

godbolt で確認しようとしたら

LINK : fatal error LNK1104: cannot open file 'libcpmt.lib'

と出るんやが……

**デフォルトの名無しさん** · 2020/04/22(水) 17:47:08.07

>>305
Visual Studioと言えば通じる？

underlying_typeか、こいつは情報ごっつぁん
std::cout << typeid(typename std::underlying_type<decltype(test2)>::type).name() << std::endl;
これの出力もintだった

**はちみつ餃子** ◆8X2XSCHEME · 2020/04/22(水) 18:05:31.28

>>307
> Visual Studioと言えば通じる？

コマンドが cl というのは知ってはいるんだけど、コンパイラの名前として cl っていうのは伝わり難いと思う。
マイクロソフトのドキュメントでは Microsoft C++ か MSVC という書き方をしていることが多いようなので、
たぶんそれが公式な呼び方なんじゃないかな。

> これの出力もintだった

値は何になってる？

**デフォルトの名無しさん** · 2020/04/22(水) 18:08:15.75

値はもうあんまり興味なかったが
一応試したらやっぱり0だった

**はちみつ餃子** ◆8X2XSCHEME · 2020/04/22(水) 18:26:25.82

>>309
バグとして報告が出てたわ。
https://developercommunity.visualstudio.com/content/problem/524018/underlying-type-of-an-unscoped-enum.html

結論： MSVCのバグ。 gcc や clang が正しい。

**デフォルトの名無しさん** · 2020/04/22(水) 23:26:04.67

き、君子危うきに近寄らず…！

**デフォルトの名無しさん** · 2020/04/22(水) 23:37:02.23

キミコってボトムズの主人公いたね

**デフォルトの名無しさん** · 2020/04/22(水) 23:46:36.87

キミコ・ビューティフルだったか

**デフォルトの名無しさん** · 2020/04/23(木) 11:30:41.04

>>310
よくこんなの見つけたな
指摘からもう１年経つのにまだ放置か

**デフォルトの名無しさん** · 2020/04/23(木) 12:32:25.65

>>314
VS2013だし放置じゃね？

**デフォルトの名無しさん** · 2020/04/23(木) 13:12:45.41

300で言ってたclは2019だよ
もち更新ちゃんとやってるやつ

**はちみつ餃子** ◆8X2XSCHEME · 2020/04/23(木) 13:27:01.39

>>315
最新のコメントに `_MSC_FULL_VER` が `192328105` の環境で再現すると書いてある。
これは Visual Studio 2019 version 16.3.2 のことだそうな。
https://cpprefjp.github.io/implementation.html#visual_cpp_ver

**デフォルトの名無しさん** · 2020/04/23(木) 14:02:24.26

あーすまん、ちゃんと見てなかった
2019でも起きるのに一年放置は長いな

型指定使えば済むやろ、で後回しにされてるのかも？

**デフォルトの名無しさん** · 2020/04/23(木) 17:39:32.10

だいたい出尽くした？
餃子さん情報２つもありがとう
リアルならバーでおごるところだ

**デフォルトの名無しさん** · 2020/04/23(木) 17:56:49.02

本当は、64bit型が追加されたことはコンパイラ作者泣かせなんだ。
C++コンパイラはとても複雑になってしまっている上に新しい仕様が入ったことで組み合わせ爆発が起きて細かなバグが入り易い。

**デフォルトの名無しさん** · 2020/04/23(木) 18:03:51.55

型の「昇格」や、2項演算子における型の「統一」も、64bit型が入ったことで複雑さが増した。
普段当たり前すぎて気にしないことだが、
unsigned char ch = 1;
と書いた場合でも、右辺は最初 int 型整数と解釈されるが、型にうるさいC++においても、それよりバイト数の少ない ch に警告も無く代入できてしまう。
他にも、
ch += 2;
とした場合、2は、最初int型と解釈されるのに、それよりバイト数の小さい ch に何の警告も無く足せてしまう。
これらで警告が出たらコーディングの手間がかかり過ぎるためそうなっているとは分かるが、型安全なC++においては背後にどういう仕組みがあるのかと思ってしまう。

**デフォルトの名無しさん** · 2020/04/23(木) 18:07:51.10

>>321
unsigned char ch = 1 + 2;
と書いたとする。
右辺は、C言語の使用によれば、1も2もint型だとみなされてから計算され、
結果の3もint型である。普通、int i; に対して、
ch = i;
とすると当然エラーか警告が出るのに、
この場合には何もメッセージが出ずにコンパイラが通るはずだ。
これも背後にどの仕様が働いているのだろうか？

**デフォルトの名無しさん** · 2020/04/23(木) 18:18:19.96

char a = 0;
a += (char)0;

これも代入時にintから型変換

**デフォルトの名無しさん** · 2020/04/23(木) 18:19:27.29

簡単な定数畳み込みして安全かどうか調べてるだけでしょ

gccの場合

char i = 255+1; # warningでる

char i = 1;
char j = 255+j; # warningでない

**デフォルトの名無しさん** · 2020/04/23(木) 18:20:26.60

1+2*3
は警告が出ないのに

1<<2+3
は警告が出るとか

色々と恣意的

**デフォルトの名無しさん** · 2020/04/23(木) 18:27:20.31

そりゃwarningだもの
コンパイラーごとに親切心でやってるだけじゃん

**デフォルトの名無しさん** · 2020/04/23(木) 18:33:48.11

>>324
自己初期化？

**デフォルトの名無しさん** · 2020/04/23(木) 18:34:10.45

親切心じゃなくて趣味の押し付けみたいな物も多い

**デフォルトの名無しさん** · 2020/04/23(木) 18:35:02.85

ch = 1;
がどうしてエラーにならないのか、CやC++の古い仕様仕様書からは見つけることが出来なかった。

**デフォルトの名無しさん** · 2020/04/23(木) 18:35:11.36

>>327
すまん

char j = 255+i; # warningでない

だった

**デフォルトの名無しさん** · 2020/04/23(木) 18:35:53.67

>>329
c++が型安全だとなぜ思った？

**はちみつ餃子** ◆8X2XSCHEME · 2020/04/23(木) 20:49:08.20

>>329
古い仕様っていつのやつ？
とりあえず JISX3010:2003 (C99 に相当) を見る限りでは規定はある。
関連しそうなところを抜粋したので細かいことは周辺を確認してね。

> 6.7.8 初期化
> 型の制限及び型変換は、単純代入と同じとする。

> 6.5.16.1 単純代入
> 右オペランドの値を代入式の型に型変換し、左オペランドで指し示される
> オブジェクトに格納されている値をこの値で置き換える。

> 6.3.1.3
> 整数型の値を _Bool 型以外の他の整数型に変換する場合、
> その値が新しい型で表現可能なとき、値は変化しない。
> 新しい型で表現できない場合、新しい型が符号無し整数型であれば、
> 新しい型で表現しうる最大の数に 1 加えた数を加えることまたは
> 減じることを、新しい型の範囲に入るまで繰り返すことによって得られる
> 値に変換する。
> そうでない場合、すなわち、新しい型が符号付き整数型であって、
> 値がその型で表現できない場合は、結果が処理系定義の値となるか、
> 又は処理系定義のシグナルを生成するかのいずれかとする。

そんなわけで、変換後が unsigned の場合はどんな値に変化するか既定があるし、
signed の場合は表現できる範囲内では値は変化しないから問題ない。
表現できない値になってるかどうかは基本的に実行時までわからんから
コンパイル時には黙って通す (わかるときは警告する) って感じ。

**デフォルトの名無しさん** · 2020/04/24(金) 02:20:09.80

>>332
> 右オペランドの値を代入式の型に型変換し、左オペランドで指し示される
> オブジェクトに格納されている値をこの値で置き換える。
C++において、
char ch;
int i;
に対し、
ch = i;
はエラーになるけど、それは左辺と右辺で型が違っているから。
つまり、C++では、単純代入演算子 x = y において、「型変換」は自動的には行われない。

**デフォルトの名無しさん** · 2020/04/24(金) 02:23:37.80

>>333
pure Cにおいても、
int x;
char *ptr;
x = ptr;
や
int *pInt;
char *ptr;
pInt = ptr;
は
どちらもエラーになる。
だから、pure C の代入演算子に置いても、型変換がエラーも出ずに自動的に行われるわけではない。

**デフォルトの名無しさん** · 2020/04/24(金) 05:55:11.40

>>333,334
「エラーになる」って言ってるけど、警告の間違いじゃない？
CでもC++でも代入で暗黙の型変換は発生するよ。

**デフォルトの名無しさん** · 2020/04/24(金) 07:54:02.46

>>333
なんでそんな自信満々なん？これコンパイル通るぞ
int main(){
　　char ch = 0;
　　int i = 1;
　　ch = i;
　　std::cout << +ch << std::endl;
　　return 0;
}

**デフォルトの名無しさん** · 2020/04/24(金) 10:31:54.61

unsigned char のときだな

**はちみつ餃子** ◆8X2XSCHEME · 2020/04/24(金) 10:33:37.57

>>333
初期化・代入のどちらにおいても int から char へは暗黙に型変換される。
https://timsong-cpp.github.io/cppwp/n3337/expr.ass#3
https://timsong-cpp.github.io/cppwp/n3337/dcl.init#16.8
https://timsong-cpp.github.io/cppwp/n3337/conv.integral

**デフォルトの名無しさん** · 2020/04/24(金) 11:53:55.91

エラーじゃなくてワーニングなんだろ多分
しっかりラーニングしておけよ

**デフォルトの名無しさん** · 2020/04/24(金) 11:59:13.94

c++は型安全おじさん誕生

**デフォルトの名無しさん** · 2020/04/24(金) 12:36:28.71

今月のインターフェースでC++は型なし言語と紹介されていた。
種なしって言われたみたいで悲しい…

**デフォルトの名無しさん** · 2020/04/24(金) 14:00:39.93

型があることにも、ないことにもできるのがC/C++の良いところ
まあしかし世の中には反りの合わない人がいるもので
そういうところを酷評する意見も当然出てくる

**デフォルトの名無しさん** · 2020/04/24(金) 14:05:22.39

c++が悪いんやない！cの型システムが壊れてるからや！
みたいな主張は聞いたことある。
まあしかし互換性がウリですからね。。

**デフォルトの名無しさん** · 2020/04/24(金) 15:11:32.57

むしろ、型を壊したのは C++ の方だと思うが。
autoとかで。

**デフォルトの名無しさん** · 2020/04/24(金) 15:14:13.63

>>335
C++では、
void *ptr;
CPerson *pPerson;
に対して、
pPerson = ptr;
はエラーになるはず。
だから、C++では
CPerson *pPerson = malloc(sizeof(CPerson));
がエラーになるのだから。
pure Cではならなかったが。

また、
CBase *pBase;
CDerived *pDerived;
に対して、
pDerived = pBase;
もエラーになるはずだ。

**デフォルトの名無しさん** · 2020/04/24(金) 15:15:40.17

>>343
何か勘違いしているようだが、人気が有ったのはpure Cの方だからね。
今のC++の人気は、pure Cの人気を引き継いだだけ。
そしてC++が変な拡張を繰り返したからこそ、人気にかげりが見えてきている。

**デフォルトの名無しさん** · 2020/04/24(金) 15:16:31.43

>>344
autoは型をきちんと理解して使うもので
アホが使うと謎の動きに翻弄されることになる

**デフォルトの名無しさん** · 2020/04/24(金) 15:19:58.74

>>346
そのコメント343宛でよいの？

**デフォルトの名無しさん** · 2020/04/24(金) 16:02:04.89

autoは要らない子

**デフォルトの名無しさん** · 2020/04/24(金) 16:06:41.58

auto使ってない人なんて実在するのか？

**デフォルトの名無しさん** · 2020/04/24(金) 16:22:47.89

>>341
どう書いてあったか詳しく聞いてみたい。

**デフォルトの名無しさん** · 2020/04/24(金) 17:35:30.22

>>345
何で別の話を始めたの？
ちゃんと質問には答えてくれないかな？

**はちみつ餃子** ◆8X2XSCHEME · 2020/04/24(金) 17:42:51.85

>>344
型検査の厳しさは型を陽に書くかどうかとは関係ない。

>>345
何をいいたいのかわからん。

**デフォルトの名無しさん** · 2020/04/24(金) 18:14:30.78

>>353
馬鹿ですか？

**デフォルトの名無しさん** · 2020/04/24(金) 18:22:23.35

>>354
何で>>345で別の話を始めたの？
ちゃんと人の質問には答えようね

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

>>351
コンパイル時にすべての変数の型が確定しないc++は弱い型付けだから型無し言語に分類だって。

**341** · 2020/04/25(土) 09:43:58.40

>>356
そこは動的型付けの説明だよ。
ちゃんと読んで

**デフォルトの名無しさん** · 2020/04/25(土) 11:27:52.58

5月号のこと？

**デフォルトの名無しさん** · 2020/04/25(土) 11:29:47.36

トラ枝？

**デフォルトの名無しさん** · 2020/04/25(土) 11:29:54.96

>>357
その雑誌には、
静的型付け言語であるところの C++ が「型無し言語」であると書いてあるの？

**デフォルトの名無しさん** · 2020/04/25(土) 19:17:45.69

アムウェイで地味に成功してた僕が業界の裏側を暴露してみた
https://www.youtube.com/watch?v=98udsqJihkA
年間300万円稼げてたのにアムウェイをやめた理由
https://www.youtube.com/watch?v=-H_dBzeJeUM
【体験談】元DDがAmwayで稼ぐのが難しい理由を解説してみた【元ガチ勢】
https://www.youtube.com/watch?v=SpzJEddQOdE
【借金地獄】マルチ商法で死の淵から生還して得たもの失ったもの【ビジネス論】
https://www.youtube.com/watch?v=UxriU-TOrMY
あの頃アムウェイはじめちゃったきっかけ【元ガチ勢】
https://www.youtube.com/watch?v=H9C4n4pL03U
私がネットワークビジネスを勧めない理由とは？
https://www.youtube.com/watch?v=hQNkcfhzv18

**デフォルトの名無しさん** · 2020/04/25(土) 19:26:23.55

>>361
グロ

**デフォルトの名無しさん** · 2020/04/25(土) 19:45:42.98

auto it = unique(
vecVisibilityPolygonPoints.begin(),
vecVisibilityPolygonPoints.end(),
[&](const tuple<float, float, float> &t1, const tuple<float, float, float> &t2)
{
return fabs(get<1>(t1) - get<1>(t2)) < 0.1f && fabs(get<2>(t1) - get<2>(t2)) < 0.1f;
});

vecVisibilityPolygonPoints.resize(distance(vecVisibilityPolygonPoints.begin(), it));
のresize()から意味がよくわからないのですが、
{0.1, 0.11, 0.2, 0.21, 0.4, 0.41}
↓
{0.1, 0.2, 0.4}
なことでしょうか？

**デフォルトの名無しさん** · 2020/04/25(土) 20:03:25.46

>vecVisibilityPolygonPoints
std::vector<T>のハンガリアン記法での接頭辞vecで良いんだっけ…
Tの情報はどう埋め込めば良いんじゃ…
毎回悩むのでJISか何かで決めてﾎｽｲ

**デフォルトの名無しさん** · 2020/04/25(土) 20:32:53.50

erase使わずにresize使う人始めてみたわ

**デフォルトの名無しさん** · 2020/04/25(土) 22:11:42.84

>erase使わずにresize使う人始めてみたわ
ﾊｱ?(ﾟДﾟ)ﾊｧ?

**デフォルトの名無しさん** · 2020/04/25(土) 22:34:29.10

>>364
vecなんて付けずにvisibilityPolygonPoints でいいんじゃね。システムハンガリアンは不要または有害だと言われるようになって久しいだろう。
処理の都合上、別のコンテナからvectorに詰め替えたとかでvectorであることに強い意味がある状況なら、vecをつけて元の変数と区別する意味はあると思うけど。

**デフォルトの名無しさん** · 2020/04/25(土) 22:56:50.00

auto使ってハンガリアンとかなんか間違ってるわな。

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

確かにvectorだと処理量変わらんな

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

>>363
3要素のvectorでyzの値が近いものを同一と見なして削除する処理なのかね
unique前のsortどうしてんのか謎だけど

uniqueは重複したものは一つだけ残して前にuniqueなデータを集め、後半にゴミを集める
戻り値はゴミの開始iterator
resize部分はゴミを消す処理
一般的にはerase使ったerase-remove_ifイディオムの変形だな

**デフォルトの名無しさん** · 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

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