C++相談室 part156

**デフォルトの名無しさん** · 2021/05/19(水) 10:55:13.24

前スレ
C++相談室 part155
https://mevius.5ch.net/test/read.cgi/tech/1616555235/

**デフォルトの名無しさん** · 2021/05/29(土) 16:59:07.85

>>132
クラスのメンバ変数は定義に書かれた順に初期化されるから、その例についてはokなんじゃないかな

**はちみつ餃子** ◆8X2XSCHEME · 2021/05/29(土) 17:29:48.88

メンバ初期化子として書いた順ではなくクラス定義内のデータメンバ宣言順に従うというのが重要ポイントで、
勘違いを防ぐために宣言順とメンバ初期化子の順序は一致させるのが一般的な習慣になってる。
(一致させなくてもそれ自体は規格違反ではない。)

C++20 から入る指示付初期化 (Designated initialization) で順序を一致させるのが必須に
なっているのはこのへんの反省があったんだと思う。

**デフォルトの名無しさん** · 2021/05/29(土) 19:10:01.56

各位　ありがとう

>>134
後半はへーって感じなので調べてみる

**デフォルトの名無しさん** · 2021/05/31(月) 20:14:45.42

構造化束縛とか範囲for文が必ず新規にオブジェクトを宣言しないといけない仕様になってるのが何気に解せないのだが
既存のオブジェクトを使い回せた方が都合良いだろうに、なぜこういうことになったの？

**デフォルトの名無しさん** · 2021/05/31(月) 20:47:21.20

構造化束縛の方はtieで行けるだろ

int a, b;
std::tie(a, b) = std::make_pair(1, 2);

**デフォルトの名無しさん** · 2021/05/31(月) 20:48:51.74

参照じゃダメ？

**デフォルトの名無しさん** · 2021/05/31(月) 21:28:28.96

c++11やり始めた頃、for(auto& e:～やfor(const auto& e:～と出来るのを知らず、酷いコードを大量に垂れ流してしまったよ

**デフォルトの名無しさん** · 2021/05/31(月) 22:31:51.93

>>138
参照にしてもfor文のスコープ外で宣言できた方が都合が良いことがままある

**デフォルトの名無しさん** · 2021/06/01(火) 01:12:38.27

ループの最後の値を使いたいという事？

**デフォルトの名無しさん** · 2021/06/01(火) 09:11:18.08

>>140
言っても「稀に」程度だろうし、やりたければスコープ外で宣言した変数に代入すれば済む。
何を問題としているのかわからない。

**デフォルトの名無しさん** · 2021/06/01(火) 12:18:45.46

お漏らし推奨

**デフォルトの名無しさん** · 2021/06/01(火) 12:20:20.23

自作関数の引数を initializer_list にするのってなんか使い道あるんですか？
参照の組を渡せる？

**デフォルトの名無しさん** · 2021/06/01(火) 18:21:02.43

MyVector v{1,2,3,4,5};
とかできる

**デフォルトの名無しさん** · 2021/06/01(火) 20:14:13.74

ま、まいべくたーｗ

**デフォルトの名無しさん** · 2021/06/02(水) 06:27:13.91

>>145
コンストラクタの引数にするくらいしかメリットないの？
前スレ掘ってたら、同じ型の参照の組なら initializer_list で関数に投げれるってのを見つけたんだがそれはどうやんの
initializer_listを引数にとる関数 hoge を
hoge({fuga, var, aaa})
って呼び出したら実体を渡してることになるよね？

**デフォルトの名無しさん** · 2021/06/02(水) 06:48:10.69

MyVector(initializer_list<reference_wrapper<int>>) { }

**デフォルトの名無しさん** · 2021/06/02(水) 07:01:45.97

>>148
それって vector< reference_wrapper<T> > とは違うんけ？

**デフォルトの名無しさん** · 2021/06/02(水) 07:55:44.63

template <class T>をつけるならね

**デフォルトの名無しさん** · 2021/06/02(水) 07:57:13.92

reference_wrapperはC++11からでC++03にはないから> >にする意味ないぞ

**デフォルトの名無しさん** · 2021/06/02(水) 08:15:03.57

初期化のときに登場する｛｝が初期化子リストだと言うことがつい最近判明した
概念を区分して分離したのが一番大きいので、用途についてはあまり考えられていない

**デフォルトの名無しさん** · 2021/06/02(水) 08:44:42.49

>>151
いや自分の可読性のためにそうしてるだけ
他の人にとってはそっちの方が見づらかったらすみません

それはそうと、関数に参照の組を渡すなら、initializer_list 云々というよりは reference_wrapper の組として渡すってことですね

もう一点、関数に initializer_list を渡すときって
・関数の引数の型が initializer_list である
よりも
・関数の引数のコンテナを initializer_list で初期化している
の方がしっくりくるんですが、前者で設計するメリットってありますか

**デフォルトの名無しさん** · 2021/06/02(水) 10:14:59.83

overloadに弱くなる

**デフォルトの名無しさん** · 2021/06/02(水) 10:21:56.66

>>153
長かったC++03時代でそういうクセが染みついちまった、ならわかる

**デフォルトの名無しさん** · 2021/06/02(水) 10:48:08.32

気狂いいてワロ
(a, b, c) と ( a, b, c ) さえどちらが良いかなんて誰にも決められないのに、なぜ < <> > と <<>> なら後者の方が問答無用で良いと思い込んでるのだろうか
こういう、一概には言えないことを押し付けるタチの異常者が回答側に回ってるのイタ過ぎだろ

**デフォルトの名無しさん** · 2021/06/02(水) 10:51:36.57

同和ンゴ

**はちみつ餃子** ◆8X2XSCHEME · 2021/06/02(水) 11:11:42.37

トークン分割の段階では >> というひとつのトークンとして切り出された上で
構文解析の側で辻褄を合わせるという変な解釈が不格好だから好きじゃないな。
構文が複雑になる分には仕方がないと割り切れるんだが、
異なるレイヤをまたいで辻褄合わせするのってなんか嫌じゃない？

でもまあ > > よりは >> のほうが見やすい気がするからそう書いてるんだけど、
割とモヤモヤしがち。

**デフォルトの名無しさん** · 2021/06/02(水) 11:13:17.27

何で押しつけたことになるんだ？
被害妄想で攻撃的になるやつこそ病んでるぞ

スタイルは案件ごとにある
そこでいらぬ波風立てるやつは叩き出される
仕事は成果で語るものなのに勘違いして
つまらんことに気を取られるやつは使い物にならん

**デフォルトの名無しさん** · 2021/06/02(水) 11:41:07.35

>>149
おそらく初期化子リスト版の方が高速に動作する
まぁ、今時のコンパイラの最適化は変態レベルに進化してるから結局同じようなコードに落ち着くかもしれないけど

**デフォルトの名無しさん** · 2021/06/02(水) 11:54:53.84

>>154
initializer_list をとることにしておけばコンテナの種類を決めておく必要がないから得ってことですか？

**デフォルトの名無しさん** · 2021/06/02(水) 12:01:59.24

>>159
> スタイルは案件ごとにある
元質問はスタイルが指定された案件では全くないので、自分が頓珍漢なこと言ってたって認めるわけね

> そこでいらぬ波風立てるやつは叩き出される
> つまらんことに気を取られるやつは使い物にならん
狂おしいまでに己のことだな

**デフォルトの名無しさん** · 2021/06/02(水) 12:11:17.92

>>162
元質問には特定の案件か否かはどちらとも書いていないね
さらに俺は特定の案件の話だともそうでないとも言ってない

次から次へと勝手に決めつける軽率なやつが
他人に向かって頓珍漢とか天に唾するってやつだぜ

**デフォルトの名無しさん** · 2021/06/02(水) 12:24:56.03

恥ずかしくなってネタっぽくしてるが隠しきれてない同和ンゴ

**デフォルトの名無しさん** · 2021/06/04(金) 15:31:20.39

cout と cerr に同じもん流し込みたいときって
cout << hoge;
cerr << hoge;
ってやるしかない？
一行というか一文で書けたら楽だが

**デフォルトの名無しさん** · 2021/06/04(金) 15:57:51.35

>>165
すなおに以下のようなマクロにしとけばどうかな
#define HOGE(x) std::cout << x; std::cerr << x;
例えば以下のように使う
HOGE(hoge << endl);

**デフォルトの名無しさん** · 2021/06/04(金) 17:29:57.12

random_device{}();
の中括弧って何なん
デフォルトコンストラクタで構築するってこと？
なんで丸括弧じゃないん

**デフォルトの名無しさん** · 2021/06/04(金) 18:26:04.60

別に中()でも問題なくない？

**デフォルトの名無しさん** · 2021/06/05(土) 05:37:22.25

ラムダ式のキャプチャ構文の個別コピーとか個別参照がなんで存在するのかイミフなんだが
引数で良いじゃん

**デフォルトの名無しさん** · 2021/06/05(土) 07:13:07.04

キャプチャにもコストは掛かるから必要なものだけ最小限キャプチャしたい時に必要なんだよ
なぜ引数でいいと思うのかはイミフ

**デフォルトの名無しさん** · 2021/06/05(土) 07:24:52.28

既存の関数ポインタや関数オブジェクトと整合性を取るには、寿命やスコープの異なる変数を使うための仕組み(キャプチャ)が必要だったからでしょ

**デフォルトの名無しさん** · 2021/06/05(土) 07:29:08.22

とあるラムダ式を読みづらいと感じるならそこでは使わないほうがいい
煽っているわけではなくて、ラムダ式の存在意義は可読性の改善なので、ラムダ式を読みづらいのは本末転倒だからね

**デフォルトの名無しさん** · 2021/06/05(土) 07:39:00.13

>>170
キャプチャデフォルトにしても使わなかったやつはキャプチャされないから
あえて個別にするのは何か理由があるときだね

**デフォルトの名無しさん** · 2021/06/05(土) 08:28:34.32

>>170
キャプチャできるオブジェクトってみんな引数としても渡せるじゃん
参照、const参照、コピーも自由自在だし
コストって言うけど、参照キャプチャと参照渡し、コピーキャプチャとコピー渡しってコスト違うの？

一応断っておくと[&]と[=]の存在意義は分かる
オブジェクトを個別にキャプチャするのがイミフってだけ
「こういうときに使う。引数渡しではできない」という例があったら教えていただきたいです

**デフォルトの名無しさん** · 2021/06/05(土) 08:43:36.40

ラムダ式がキャプチャするタイミングと呼び出すタイミングは違ってもいい

**デフォルトの名無しさん** · 2021/06/05(土) 08:53:12.54

呼び出し時にキャプチャ元の存在は保証されない自己責任

**デフォルトの名無しさん** · 2021/06/05(土) 09:10:01.93

>>174
これを引数渡しではどう書く？

random_device dev;
int ary[256];
generate(begin(ary), end(ary), [&]{ return dev(); });

**デフォルトの名無しさん** · 2021/06/05(土) 09:10:44.09

>>175
なるほど
コピーしたいけど呼び出しの度には嫌だ、というときに役立つのか
神機能だな

**デフォルトの名無しさん** · 2021/06/05(土) 09:11:42.81

>>177
もう解決しました

**デフォルトの名無しさん** · 2021/06/05(土) 09:21:58.27

>>176
コピーならHOSYOUされる

>>178
つか新しい関数を作る機能

>>169
カリー化

**デフォルトの名無しさん** · 2021/06/05(土) 09:28:59.14

普通のｷｬﾌﾟﾁｬ（コピー）ではなくて
異常なｷｬﾌﾟﾁｬ（参照のｷｬﾌﾟﾁｬ）なら呼び出し時にキャプチャ元（参照されているオブジェクト）
の存在はＨＯＳＹＯＵされないから注意しないとＫＩＫＥＮだが
なんでそんな機能があるのかというとオブジェクトをカリー化（？）する場合にあったら便利だねえ、ぐらいの勢いの話
普通のｷｬﾌﾟﾁｬだけでもポインタをｷｬﾌﾟﾁｬしたら同じことができる

**デフォルトの名無しさん** · 2021/06/05(土) 09:37:27.71

もっとも、自動変数として作られたオブジェクトxをｷｬﾌﾟﾁｬする場合、
xを参照のキャプチャする代わりに&xを普通のキャプチャしてしまうと
（「＆」演算子が使われたことにより）微
妙に最適化に響きかねない問題というのは微妙にあるが微妙なので普通は気にするほどではないはず……

**デフォルトの名無しさん** · 2021/06/05(土) 09:53:54.69

元のデータをFUCKYUできないような書き方はAUTO

**デフォルトの名無しさん** · 2021/06/05(土) 10:05:44.68

キモい言葉遣いヤメレ

◆QZaw55cn4c · 2021/06/05(土) 15:25:47.75

ヒドロキシクルルキン
イベルメクチン

◆QZaw55cn4c · 2021/06/05(土) 15:26:27.50

ヒドロキシクロロキン
イベルメクチン

**デフォルトの名無しさん** · 2021/06/05(土) 16:15:28.53

C++において関数は第一級オブジェクト
なのに C++ が関数型プログラミングを全く想定していない仕様に思えるのはなぜ

**デフォルトの名無しさん** · 2021/06/05(土) 16:15:54.58

関数型のパラダイムもうまく取り込んでほしい

**デフォルトの名無しさん** · 2021/06/05(土) 16:34:45.82

>>187 古いから。
>>188 提案するのは自由だから、がんばって。

**デフォルトの名無しさん** · 2021/06/05(土) 16:53:27.35

>>187
c++の関数は第一級オブジェクトじゃないだろ。
高階プログラムはテンプレートという別の仕組みでサポートしている。

**デフォルトの名無しさん** · 2021/06/05(土) 18:54:44.68

関数型プログラミングは別に古くないはず……
ＧＥＮＪＩＴＳＵ世界が状態を持ち破壊的代入を伴うから
まだチューリングマシン的な計算モデルの方が対応がとりやすい（気がする）だけ
C/C++が関数型プログラミング一本鎗にならないのはそれが根本原因

**デフォルトの名無しさん** · 2021/06/05(土) 20:10:51.62

・弱体化された関数型の機能
・構造化プログラミング
・GOTO文
これがCだよ

で、多分70年代当時は関数型プログラミングはおそらく過去の遺物になってた
でないとこの頃のlispの失速が説明つかない

**デフォルトの名無しさん** · 2021/06/05(土) 20:22:19.29

当時生まれてないけど
あのマシン性能が貧相な時代によくLISPなんて流行ってたな

**デフォルトの名無しさん** · 2021/06/05(土) 20:31:42.60

むしろマシンリソースが少ない時代だからこそ流行したといえる
LISPマシンはすなわちスタックマシンだ
複雑な語句パーサーとツリー構造の構築がなくても、ストリームから
はいってきたキーワードを順繰りに解釈してスタックにつんでいき
かっこが閉じたらスタックからひっぱればちゃんと動くものがつくれる

**デフォルトの名無しさん** · 2021/06/05(土) 20:53:06.54

>>190
禿は「第一級オブジェクト」をテンポラリでないオブジェクトと言っているようだが

**デフォルトの名無しさん** · 2021/06/05(土) 21:21:58.41

権威者がこれこれと言ってたからこれこれであるという話の持って行き方は
今日の世界では小学生レベルの人間しかしない

中世ヨーロッパでは過去の偉人の言葉をいかにうまく引くかが議論の上手下手を左右したらしいが

**デフォルトの名無しさん** · 2021/06/05(土) 21:28:06.29

その世界の教祖のような人でも一切、言葉を引いてはいけないのか
小学生で年収1000越えそうな人ってジュジュちゃんとかいるけど
自分の年収を棚に上げてわかったようなことをｗ

**デフォルトの名無しさん** · 2021/06/05(土) 22:00:37.95

>>194
それForthじゃね？

**はちみつ餃子** ◆8X2XSCHEME · 2021/06/05(土) 22:00:51.75

>>196
ここで必要なのは範例ではなく定義。
何が正しいのかを議論したいわけじゃなくてどの定義を使う「ことにする」という擦り合わせ。
C++ における定義を決めるなら設計者の言を元にするのは妥当だろ。

それはそれとして >>195 はなんかおかしいこと言っていると思うし、
なんか勘違いしてそうな気がするが。

**デフォルトの名無しさん** · 2021/06/05(土) 22:49:20.33

関数型プログラミングが古いと主張する香具師は
MVCとかなMと表示等が分離した設計モデルでありかつ
Mがマルチスレッド（UIスレッドとは別）なケースのプログラミングを
ラムダ式を使わずにして見られれば宜しい
すっきり収拾をつけるにはコールバック関数として関数オブジェクトを渡すか、
コールバック関数をvoid*引数の関数にするという前近代的な設計にするかしかなく、
classを使って手で書く関数オブジェクトはラムダ式を見たコンパイラが生成するコードと大差ないから
前者は関数型プログラミングに他ならない
という印象、
※ 個人の感想です

それはそれとして>>192も相当おかしいことを言っていると思うし以下略

**デフォルトの名無しさん** · 2021/06/05(土) 23:04:19.70

Promiseを使っても同じことで、
ていうかPromiseこそあるスレッドXを実行後に行うべき処理を行う関数Ｆを
スレッドXの終了後に実行するために（※1）内部で作っておくのだから関数型プログラミングに他ならない
関数型プログラミングパラダイムは全世界をあまねくみそなわしておられる、

※1: 実行する、というといかにも命令型プログラミングな感じだが、
　　　関数型プログラミングパラダイム的には関数Fを展開することで計算を遂行する、と解釈されたい

**デフォルトの名無しさん** · 2021/06/05(土) 23:25:00.00

>>197
年収が人間の価値だと思う人って今でもいるんだね

**デフォルトの名無しさん** · 2021/06/05(土) 23:41:37.67

関数型の実戦で使えるエッセンスは10年前から各種人気の言語で取り込まれ、
具にも付かない思想倒れな部分は取り込まれなかった。それだけ。

**デフォルトの名無しさん** · 2021/06/05(土) 23:54:03.24

>>196
上下を左右するとな。
今日一番心に残った表現だ。

**はちみつ餃子** ◆8X2XSCHEME · 2021/06/06(日) 02:06:47.21

Scheme だとプログラムの流れ (関数を呼出したり戻ってきたり) を継続の起動の連鎖として
定義づけているが、継続の概念の元になったのは並列計算の研究から生まれたアクター。
アクターにメッセージを送るのと関数呼出しが実装上は同じになってしまったという気づきから継続の概念へと整理されていった。

関数型とオブジェクト指向は整理の仕方が違うだけで
(といっても人間が使う以上はどのようなメタファで整理されているかも大事でもあるんだけど)
より抽象的なレベルで見ると同じことをやっている。
そんで並列計算は (理論上は) どっちでも織り込み済みなのでパラダイムによって
どちらのほうが並列計算しやすいということもない。

差があるとしたら単に言語の設計の出来栄えとかライブラリの整備とかのレベルの話なんで、
パラダイムにまで踏み込んで考えるような話じゃないよ。

**デフォルトの名無しさん** · 2021/06/06(日) 07:44:49.65

高所得者「年収が人間の価値だと思う人って今でもいるんだね」
低所得者「年収が人間の価値だと思う人って今でもいるんだね」

**デフォルトの名無しさん** · 2021/06/06(日) 08:33:32.64

>>203
C++に取り込まれた、実践で使える関数型のエッセンスってどんなん

**デフォルトの名無しさん** · 2021/06/06(日) 08:36:03.93

bind

**デフォルトの名無しさん** · 2021/06/06(日) 10:44:07.49

深さが任意の入れ子の vector を一次元 vector に展開したいんですが、良いやり方ありますか
再帰すれば良いと思うんですがどういう条件で分岐すれば良いかわかりません

**デフォルトの名無しさん** · 2021/06/06(日) 11:34:06.74

入れ子を一階層だけ展開する処理を書いて
入れ子がなくなるまで末尾再起するというのはどうだろうか

**デフォルトの名無しさん** · 2021/06/06(日) 11:37:51.02

>>210
今見てる階層の一個下がvectorか値かっていうのはどう判定したら良いですかね？

**デフォルトの名無しさん** · 2021/06/06(日) 11:56:07.70

>>209
これ

flatten - 1.57.0
https://www.boost.org/doc/libs/1_57_0/libs/fusion/doc/html/fusion/algorithm/transformation/functions/flatten.html

**デフォルトの名無しさん** · 2021/06/06(日) 12:00:46.49

大抵の言語でその手の挙動はflattenと呼ばれてる

Yet Another Common Lisp Problems
http://www.nct9.ne.jp/m_hiroi/clisp/yaclp03.html#ans51

**デフォルトの名無しさん** · 2021/06/07(月) 08:16:50.61

>>197
肝心なのは「誰が言ったか」ではなくて、「（言った）意味、中身」。

さもないと「権威に訴える論証」にひっかかるから気をつけな。
わかってやっているなら詐欺師だし。

**デフォルトの名無しさん** · 2021/06/07(月) 09:33:53.85

>>210
ちょっとググった感じだと、vector<T> が vector かどうか判定する is_vector ってないんですね
あと is_array は std::array を array と見なさないみたいな情報もあって、メタ関数は罠というか勘違いが多そうで怖いですね

現状、自分で is_vector を実装するしかないんですかね？
ごく基本的な処理に思えるので、シンプルな解法というかイディオムみたいのがあれば教えていただきたいです

>>212
ありがとうございます。が、今は自分で書くならどうなるかというところに興味があります
boost の flatten のコードはいろんな場合に対応するべく難解になっていそうですが、どうにもならなかったら参照してみます

**デフォルトの名無しさん** · 2021/06/07(月) 09:55:32.64

>>215
正直、まず>209の「深さが任意の入れ子の vector」をどう定義してるのか見せてもらわないと話が見えてこない気がする。
要素型が固定なら要素型のほうで判定すれば is_vector は要らないだろうし、
variant とか使ってる場合もやっぱり is_vector の出番は無いだろうし。

**デフォルトの名無しさん** · 2021/06/07(月) 10:34:55.50

>>216
vector< vector< ... vector<T> > ... > で、T は correction (vector, array 等) じゃない、というのを想定しています
仮定が足りませんでしょうか

**デフォルトの名無しさん** · 2021/06/07(月) 10:44:19.30

>>214
偉そうにキリるなら「第一級オブジェクト」の公式な定義をまず出せ

**デフォルトの名無しさん** · 2021/06/07(月) 10:49:36.03

>>215
作るったって大した話じゃねえべ

template <template<class...> class T> struct is_vector : false_type { };
template <> struct is_vector<vector> : true_type { };

template <template<class...> class T> constexpr bool is_vector_v = is_vector<T>::value;

**デフォルトの名無しさん** · 2021/06/07(月) 10:54:39.46

>>217
numpy の reshape / flatten / ravel みたいなの想定してる？

**デフォルトの名無しさん** · 2021/06/07(月) 11:00:59.34

>>217
それじゃ深さ固定じゃね？・・・深さの違ういくつかのケースを扱うっていうことか。
T を受け取るオーバーロードとそれ以外を受け取るオーバーロード書けばおしまいな気がする。

**デフォルトの名無しさん** · 2021/06/07(月) 11:02:02.86

（要素ごとに深さが異なることもあるのを想定してた。）

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

>>219
ありがとうございます
よく知らない構文も混ざってるので、勉強します

>>220
はい
flatten をしたいです

>>221
template<class T> T flatten(vector<T>)
と
template<class T> T flatten(T)
ってことじゃないですよね？

>>222
>>217ってそれ含みませんっけ？

**デフォルトの名無しさん** · 2021/06/07(月) 11:14:17.08

そもそも厳密な書き方じゃないので、含むか含まないかわかりませんね
今は含まないということにします

**デフォルトの名無しさん** · 2021/06/07(月) 11:59:15.70

>>218
そもそもc++には「第一級オブジェクト」なんて定義されてないだろ。
c++標準に"first-class object" なんて記載あったかね。

一般的な解釈はwikipediaでも勉強しろよ。

**デフォルトの名無しさん** · 2021/06/07(月) 12:01:22.38

>>225
ここはC++スレだ
一般的な解釈なんて頓珍漢なこと言ってんな
そっちへ逃げたければ１人で逃げろ
俺は付き合ってやんね

**デフォルトの名無しさん** · 2021/06/07(月) 12:05:00.74

>>226
だったら「第一級オブジェクト」なんて頓珍漢なこと言ってんな
そっちへ逃げたければ１人で逃げろ
俺は付き合ってやんね

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

>>227
流れくらい読めよ
第一級オブジェクトと言ったのは>>187だぞ
おまえ他人に頓珍漢なんて言う資格ねえぞ

**デフォルトの名無しさん** · 2021/06/07(月) 12:28:32.41

一昨日の曖昧イキリで今さらヒートアップしてんじゃねー

**デフォルトの名無しさん** · 2021/06/07(月) 12:36:56.22

>187、>190 、>195 、>197、>214
の流れくらい読めよ
禿の権威にかこつけて「第一級オブジェクト」を主張しているのは>>195 >>197だぞ。俺はそれに>>214で反論しているだけで「第一級オブジェクト」は肯定していない。

おまえ他人に頓珍漢なんて言う資格ねえぞ

**デフォルトの名無しさん** · 2021/06/07(月) 12:44:36.71

>>230
おまえの定義では斜め上な返事のことを反論というのか

関数は第一級オブジェクトか否かで揉めてるところへ
禿の定義を参考に持ち出したところへ
権威主義がどうたらと人格批判を始めたのが反論とは笑止千万
だから頓珍漢と言ってやったら相手の言葉をオウム返しし初めやがって
いくら寂しいからってプログラム技術板で全然技術的でない絡み方してんなよ

**デフォルトの名無しさん** · 2021/06/07(月) 12:48:56.88

流れ一切読んでないけどFirst-class citizenのことを言いたかったのかなｗ