C言語って設計が悪いから難しく感じるだけ

>>800
やっぱ意味わかってなかったか
データアドレスに書き込んだデータ型と違うデータ型に切り替えて使う場合があるから
こういう機能がC言語でも禁止されずに残されてんだよ

それはポインタの型がデータアドレスのデータ型に縛られないことを示す
で、それは勝手にコロコロするんじゃなくて、使う側が明確に決めて使うものだ

ワード単位でアドレスが振られるワードマシンで8ビットや9ビットのcharを指すポインタを実現するにはアドレス格納するだけじゃ無理って分かりそうなもんだがな、馬鹿なのかな。
https://ja.wikipedia.org/wiki/%E3%83%AF%E3%83%BC%E3%83%89%E3%83%9E%E3%82%B7%E3%83%B3

最近はメタデータもポインタ内にあるしねぇ。
（仮想）アドレスというよりハンドルという認識が正しいのだとか。

806だけど今までスレに書いてる人とは別人で
コロコロ変わるの「対象」が型の話なのか環境によるbit数の違いの話なのかがよくわからんって意味で
型の話ならint*からchar*に変えれないし、void*で使うにも「自分で行う」事だから勝手にコロコロではないし
bit数の話ならコンパイル時決まる事だし
何が「勝手にコロコロ変わる」のかがよくわからん

>>798
そういえばnearポインタでは届かないとfarポインタを使うアーキテクチャが普及していたな
もちろんそのfarポインタをnearポインタに変換は無理だから2種類のポインタがあることになる

>>809
未定義動作が放置されてるのはコンパイラの実装都合であって、禁止されてないからそれを使っていいというお許しではないぞ
というかお前また

途中送信してしまった、以下続き

f9fa-K2DKじゃないよな？

仕様通りに実装できていない（バグがある）コンパイラもある
↓
だからコンパイラにかかわらずたまたま動くコードしか書けない
↓
だから仕様に意味はないし、未定義動作をいくら書いてもいい

みたいなトンデモ理論を展開する気なら勘弁してくれよ

>>809は知識が決定的に足りてない

> ポインタの型がデータアドレスのデータ型に縛られないことを示す

もうこれだけではっきりしている

> ポインタの型

これはまだわかる
int* や void* のようなポインタ全般とみなして、「整数型」みたいな集合体と解釈できる

> データアドレスのデータ型

そんなものはない
データ型があるのはあくまでポインタであって、データアドレスはデータを格納したメモリ領域の先頭アドレスのことに過ぎない

メモリアドレスにはデータ型は存在せず、そのアーキテクチャで扱える表現法だけが存在する
その表現法が1つであることをC言語は保証しないし、アーキテクチャの設計において複数用意されることは珍しくない

これをポインタではデータ型によって使い分ける
なぜならデータ型によって指しているデータの大きさが異なるために、アラインメントが変わることになるから
アーキテクチャによっては、アラインメントによって表現手法を使い分ける必要に迫られるためである

根本的に君は、C言語の抽象であり実装は機能の提供を実現するコンパイラに委ねられる「型」と、メモリアドレスというその実装がマイクロアーキテクチャに委ねられる「アドレスの表現手法」を混同しているために、この議論に必要な前提を共有できていない

>>816
データアドレスって表現初めて見たけど、メモリアドレスのうちデータを指すものをデータアドレスって言うのね
逆にコードを指すものはコードアドレスと
まあ、知識をひけらかす時くらいしか使えなそうな表現だが

>>817
で、結局何が「コロコロ変わる」と言ってるんだっけ？

C言語の抽象であり実装は機能の提供を実現するコンパイラに委ねられる「型」?
メモリアドレスというその実装がマイクロアーキテクチャに委ねられる「アドレスの表現手法」 ?
どっち？

>>819
話をまぜっかえして自分の失点を隠したいのはわかるけど、あからさますぎてバレているよ

で、アドレスの表現手法は型によってコロコロ変わるってどう見ても書いてるんだよね、元の文を見ると
だから型が同じでも変わるのかとバカにしたり、実行するたびに変わるのかとバカにしたり、型は勝手に変わらないなどと講釈を垂れ出したりした君は、ずっとバカにしか見えていなかったよ

結局Cの仕様も理解できないほどコンピュータの基礎的な知識が足りないから、どうでもいい擬音にこだわるようなバカげたことになる
そんな文章を1文字でも書いてる暇があるなら、Cの使用を読んでこいやアホンダラ

悪態つきたいだけのスレに成り下がってて草

つまり、最初にコロコロ変わるって言ったやつが必死に論点変えたり造語駆使して掻きまわしてんだよ

意図せずコロコロ変わるのはバグって言うんだ
そんなのは仕様ではない
void*ってのを完全に履き違えて解釈しちゃった恥ずかしい馬鹿

>>823
> 意図せずコロコロ変わる
複おじはずっとこの自分で作った言葉を相手が言ったと主張して藁人形してるけど、そんなこと複おじしか言ってないんだよな

>>823
> 必死に論点変えたり造語駆使して掻きまわしてんだよ
それやってるのはいつもお前だよｗｗ

>>要するに、文脈や構造を見ず文中の単語だけをつまみ食いして、「〜って言ってる！」と脳内変換してしまう、いわゆる**機能的文脈文盲**（単語は読めても構造が理解できない状態）ですね。

>>823
自分で作った妄言に自分で反論して楽しい？ｗ

C言語が難しいと思う理由がわからない

確かに
小学生の頃に覚えたくらいだから簡単な方だと思う

言語自体はかんたんな部類よな
プリミティブすぎてなにやるにも積み重ねが必要なだけで

>>820
>で、アドレスの表現手法は型によってコロコロ変わるってどう見ても書いてるんだよね、元の文を見ると

それなら普通はコロコロは変わらないよね
型の違いによってアドレスの表現手法が変わるのは特殊なアーキテクチャで特殊な型変換を行った場合だけ
例えばnearポインタをfarポインタに変換すれば変わる

でも今のメジャーなアーキテクチャでint*をchar*に変換したりint*をvoid*に変換したところで内部のアドレスの表現手法は変わらない
変わるような実装があったとしてもCの仕様に反するわけじゃないが無駄なので誰もやらない

「アドレスの表現手法は型によって変わる場合がある」くらいのなら納得してくれる人はいると思うが普通は変わらないものを「コロコロ変わる」と言われて納得する人は少ないんじゃないかな
それこそ現役でnearポインタをfarポインタに変換してる人くらいには少ないと思う

>>828
strict aliasing ruleをそらで説明してみ？

複おじって頭が悪いからC言語を難しく感じるだけ

>>831
お前がたまたま変わらないアーキテクチャを触ってきたことを「普通は変わらない」とは言わないんだぜｗ

>>832
異なる型を通して同じメモリにアクセスしてはいけないってやつ
これやると未定義動作だからよくコンパイラに消される
ちょうど>>831がそれわかってない好例

>>831
> 変わるような実装があったとしてもCの仕様に反するわけじゃないが無駄なので誰もやらない
お前の頭が足りないから思いつかないだけ
アドレスを分割することで指す場所を変えるようなアーキテクチャであれば、その表現を変えることで効率よく異なるサイズのデータ型を扱える

>>832
その現象の通称がわかってるかどうかは重要じゃなくて、中身が重要なんだぞ
しかもその中身を知らない前提で話しかけているのが、もうこいつC言語初心者なんだなという感じしかないわけだが

コンピューターがどう動いているかを知らずにC言語を理解しようとしているのが間違い。

>>837
はい雑魚

アドレスの表現方法ってハードで決まってるじゃん
16進数16桁とか8桁とか

型がどうのこうの関係ない
型はその中身のデータに関係あるだけよ

>>835
それは高級言語の都合でしかない
アセンブラでは自由だ
その自由を残したのがvoid*

>>840
ポインタのデータ型はポインタが指しているアドレスから始まる連続するデータを指定したデータ型として扱うという意味がわからないんだろうな。

配列とごっちゃになってるんだろう。

>>835
それはそのコンパイラの警告にすぎない。

何この無意味なのの知り合い
お前らもっと有益なことに時間使いなよ
盆栽育てるとか

>>843
それ致命的な失言ね
カスCプログラマーであることを自白したのと同じ

>>840
>>842
お前らの知識が足りないだけなｗ
アドレスの表現方法は一意じゃないってもう100回言われてる
バカには日本語が通じないだけ

>>837
君は通称を知って威張れれば中身は知らなくても立派なCプログラマだと思うんだね！
頭の悪い人の考えることは面白いなあ！ｗ

>>843
なんでコンパイラが警告するか考えたことないんだろうな
頭を使わない知性の欠片もない奴がC言語書くなよｗ

>>839-842
複おじの自演だということがあまりにも見え透いてる
全部とんでもバカ発言で、ここまでの内容をまともに読んでいない

スレタイが悪いからアレるだけw

バカにはアドレスの表現手法が複数あり得るという事実だけでも理解できないらしい

>>839-842
知性欠乏症

>>839
君は通称を知って威張れれば中身は知らなくても立派なCプログラマだと思うんだね！
頭の悪い人の考えることは面白いなあ！ｗ

以下、コロコロ禁句な
意味が曖昧になるから

('ω')三( ε: )三(.ω.)三( :3 )三('ω')ｺﾛｺﾛ

なんか　>>839-842　が人気だが
よほどこのレスが刺さったようだなｗ

>>811
いわゆるfatポインタはアドレス以外の情報も含むもんな
色んな言語にあるスライスポインタは対象アドレスと対象サイズを含んでたり
この種のポインタを持たない言語は対象サイズを自分で管理することになってリスクが高い

サイズ情報を伴わないアドレスだけのポインタでアクセスする駄目なプログラミング言語はCだけ

初心者とか頭がちょっと弱い人はお断り言語なんだよ

そういう今時のスマートポインタを使いこなせない頭の弱い人がC言語に取り残された

>>857
メモリ領域を自分が何に使っているのかわからずにアクセスするのが間違い

C言語の構造体なんてアドレスでアクセスするのが前提みたいなもんだしな。
言語仕様で決まっていることをわかりにくいというのはおかしい。

>>860
それは無知なだけではないかい

まともな言語の場合
固定サイズの型ならアドレスのみのポインタでアクセスして安全
可変サイズの型ならアドレスとサイズによるポインタでアクセスして安全

ただポインタの中身を参照するだけなのに速度的な問題で毎回サイズチェックしたくない時ってあるだろ

>>862
既に確認されてれば、あるいは、静的に確認されてれば、サイズやインデックスのチェックは最適化で消えるんだよ
だから速さと安全性を両立できる

静的解析する周辺ツールはごまんとあるから
C自体はこのままでいい

Cの言語仕様だと静的解析だけでは限界があることが判明している
焼け石に水

>>863
「最適化で消える」じゃなくて「消える場合もある」じゃね？

「チェックしなくても明らかだからそこはチェックを略してもいい」
これはC言語でプログラマーがよくやる形
であるとともに
他の言語のコンパイル最適化シーンで行なわれる形
つまり実は同じなのだ！

プログラマーがやると稀に判断ミスをしてバグやセキュリティホール
だからコンパイラの最適化に任せた方が良いとの結論になった

>>867
「最適化で消える」じゃなくて「消える場合もある」じゃね？

Cプログラマとコンピュータどちらがミスせずに安全に省略/最適化できるかの勝負
これまでCプログラマが敗北してきた歴史

void*使わなきゃ済むだけの話なのに、それだけでC言語を悪にしたがるアホ

そもそもアクセス不可エリアなんて今時のOSが勝手に監視してるだけだからな
昔はそんなものなかったから、通り過ぎたコードエリアをデータエリアとして再利用したり自己書き換えプログラムなんていうテクニックが使えた
余計なお世話チェックが増えたことで危険なことにされたプログラムが増えてしまうという皮肉

>>871
CPUレベルでもやっている。
しかし、自分のプロセス内でやらかすダメプログラマーはいまも存在する。

>>871
セキュリティ的にもパイプラインを効率的に流すために必須
余計とか脳みそ16ビットかよ

* C言語は言語仕様に欠陥があるから危ない ←仕様を理解してないバカ
* C言語は言語仕様を守らずに書いていいから価値がある ←迷惑無能バカ

> 通り過ぎたコードエリアをデータエリアとして再利用したり自己書き換えプログラムなんていうテクニックが使えた

↑UBをテクニックと称するアホｗ

JITコンパイラ「・・・

JITが自己書き換えしてると思ってるバカ発見

JITは自己書換えというより、読み込んだ中間コードからネイティブコードを生成だよ
その分野でCは今でも主戦力だろう

>>878
じゃあ876の意図を説明してみろカス

どんだけ罵り合っても情報量が全く増えない老人ホームスレ

>>874-875
結局これ

そのとおりだな
C言語なんて出来て当たり前だが
今どき使うのは問題山積みかつ非効率すぎて使うべきでない言語

まあ使えるひとだっているんだしその辺は断定せずともひとはひと、自分は自分でいいじゃない

>>882
まあ使ってないとそう感じるやろな
Cが必要ない分野しかやってないんだから

>>884
Cが必要な分野ってCコンパイラしか動かない環境くらいだろ
それ以外の普通の環境でC言語は必要ない

なんだかんだなくはないんじゃない
データベースとか圧縮ライブラリみたいのはC多いでしょ
映像コーデックなんかもリファレンス実装はCが多いんじゃない
あとOpenSSLはCだったと思うよ違ったかな

>>885
保守性が必要で実装の高速性が必要なプログラムはCでないといけない場合も多い
特にGCでの停止が許されない、ハードウェアの制御やリアルタイム性が必要ならその傾向が強くなる
組み込みやドライバはCでないと難しいことが多いし、重厚なライブラリも同様

>>887
それら全てRustでいい
既にRustが使われている分野

>>888
現実的にはRustでいいということにはならない
なぜならRustはLLVMに依存するからで、LLVMの移植コストはとてつもなく高いからだ

>>889
このスレにいる時点でおそらく9割の人はまだ業務でC使ってると思うよ
俺もそうだが組み込みの世界は絶対にCのまま
俺も趣味だと色々5種類ぐらい別言語使うけど、、、Cは不滅だわ

余計な構文増やしてもらわなくていいんだよな
新たな機能はdllで増やして、それらをわかりやすくUIで表示してほしい

えっ

>>890
むしろ組み込みのしかもその中の一部でしかCは生き残れなかった敗北言語

CPUの命令は変わってないくせに、構文だけ俺様が考えた最強の～って増やしまくるから糞化すんだよ

男は俺含めて古い言語使って細部までコード最適化してこだわり持って仕事してる
女は新しい言語に飛びついてすぐにマスターして乗り換えてしまう、、、

こういうのはよく見るけどやっぱ男の方が正しいスタイルだと思う。レガシーでさぁ

男はCしか使えないところはCで
Rust使えるところは効率いいRust使ってるよ

すぐマスターできるなら素養がある
男と同じことしないのは最適解じゃない判断では
仮に品質同じでもモダンな開発してると営業も有利だし
業務なら男がダメ

Cって、ホンバンのコトだったっけ？

>>891 >>893
流石にイチャモンが意味不明

Cをディスってる奴はだいたいバカ
頭が悪いとうまく書けないからな

Aがチウ、Bがモミ、Cがセクース、Dがオギャー、だっけ？

C++は2人？3人？

Cはカミソリであるから
安全カミソリと違って
使っていて問題が無い間は問題が無い

無意味な言葉遊び

機械語に近かろうが遠かろうが、機械語の塊であるAIには関係ないんだよなぁ
仕事取られてオシマイなのさ

log off と log out は似たような意味なのに take off と take out は全然違うのはなぜ？

にゃー

何だかんだ言われているが、C言語は生き残っている。

C言語が生まれた'70年代初頭、並び立つ低級言語・・・言い換えると高級アセンブラって他の選択肢、あったの？
使った事無いのだけど、PASCALって低級言語だったの？

米ホワイトハウス「ソフトウェアはメモリ安全でなければならない」との声明を発表：「C」「C++」よりも「Rust」などのプログラミング言語を推奨
https://atmarkit.itmedia.co.jp/ait/articles/2403/18/news045.html

むしろC言語はポインタが使えたから流行ったんだ
ユルい型も良かった、中身知ってる人だけが使えた便利なハックツールだった

それならRustがさらに便利

Cはプログラマの責任において何でもできるっていうのが基本思想だしね

Node-RED的なインスタンスの並列動作+データ駆動みたいなやり方も好きだけど、GUI化せずに結合関係を文字だけで表すとなるとちと書きにくいかな

>>910
アセンブラよりマシだったから流行った

組み込みでアセンブラ以外が普通に使われるようになるまでは結構時間かかったけどね
インテルがPL/Mとかやってたけどなかなか…

アセンブラで条件分岐をマクロ化して不等号で記述出来る様になったから
それだけで充分だったんだよなぁ

もはや言語の善し悪しを語る意味もなくなった
AIがすべてを過去にした

「言語」って表現がおかしいわな
「ツール」でよい

言語ってさまざまあっても、とりあえず翻訳可能であって
言語によって得手不得手が発生するわけがないのが当たり前

得手不得手を敢えて設けて作るならそりゃツールというべきよ

>>915
別に条件分岐が不等号になっても嬉しくないぞ

>>918
実際に使った事あれば便利だと思うはずだ

リンク　ここにねむる

よくプログラムリストにコメント記載されてるじゃん
ってことは、コメントに書かれるような記述でプログラムを書ければ
そのプログラムリストにはコメントを書く必要性が無くなるということだ

プログラム言語ってのはそうあるべきよ

自然言語にゃ曖昧さがあるから無理

なんか言いたいことがあるのは分かったがそういうのはこの業界ではただバカにされるだけなのよ
そうあるべきよ、だからこれこれこういう言語を作ったからお前ら見ろ落とせ使え、まで出来て正義なわけです

>>921
Rubyをdisるのはよせ

わざわざ人間のために高級言語ってあるんでしょ？
それがコメント入れなきゃ理解できないなら欠陥でしかねーじゃん

プログラマーがみんな頭良いわけじゃ無いからなぁw

頭いい悪いの話ではなく、コメント入れなきゃならんってのは言語としてどうよ？ってこと
マシン語やアセンブリ言語にコメント付くのはいいよ
でも人間様のために作られたプログラム言語で、コメントを要するって目的に達してないじゃん

夏休み終わったのにキッズみたいな質問しとるな
御託並べる前に作れ

「何をやってるか」はコードをみれば分かるけど、「何でこう書いてるか」とかコメントしておかないと、他人や将来の自分にも分かりにくいことがあるよ
コードを修正したらコメントも修正するとか、面倒だけどね

「何でこう書いてるか」だけ書けばプログラムは自動生成で良い
「何でこう書いてるか」がプログラミングであってコーディングはプログラミングじゃない
って話では

実際に書くコードは部分を実現するものだから、やってる事が直接大局を表していないからね
システムが森なら一つ一つのコードが枝であり葉っぱであり、それを見て森全体を把握する事は出来ないのと同じ

部分的に見て正しいコーディングだけど全体から見て正しくないこともあるよね
また、全体を見ないとなぜこうなっているのか分からない場合もある

すべての作業者がシステム全体を把握できているとは限らない

>>927
だから不満があるなら作ればいいじゃん
他の人が作ったものに文句たれてるだけなら口先だけのガキと変わらんよ

>>927
そういうのは理想だけど現実的ではない
0が1にならなくても0.5になるだけでかなり扱いやすくなる

>>918
8086のアセンブリはよく知らないんだけど、アセンブリでif文を書こうとすると、if文の条件式が真のとき該当ブロックの処理へ移る、ではなく、条件式が偽のときjmpで該当ブロックを回避するように書くから、頭の中で論理的に否定しなくてはならなくて、高級言語やってた人にはキツイよ
高級言語では >= でよいところをアセンブリでは < のように変換したり

ごめんなさい、肝心なところにミスが

誤)
条件式が偽のときjmpで該当ブロックを回避するように書くから、

正)
条件式が真のときjmpで該当ブロックを回避するように書くから、

分かりづらくなってスマヌ

あー、
元の文章でもよかったのかな…
スレ汚しスマヌ

大して読んでる人いないと思うからそんな影響ないと思うよ大丈夫

人間工学的には末尾まで正確に聞き取らなくても返答できる英語のほうが合理的

>>941
ではなぜプログラムの真偽では、日本語式なんだね？
ロジックとしては日本語の方が正しいのだよ

>>940
そだね、サンキウ!
でもそれくらい論理の否定って苦手だワ
昔、
if not expr then
〜
else
〜
fi

みたいの叱られたワ

>>942
はい、いいえのプログラミング言語ってなんだよ
頭の中整理してから書けよ

>>944
頭悪そう

>>937
お前がアホ
英語の場合はそれぞれ完璧な対応が常に成り立つ
「XXXである」＝「XXXは真」→Yes　
「XXXでない」＝「XXXは偽」→No

Yes/Noは曖昧になるのでTrue/Falseで

ていうか、英語がどうのって言いながら>>937にある質問の文って日本語の文だよね？w
アタマ大丈夫かね？

結局英語って質問の文章の内容に関係なく
「自分はやってない」「それではない」って感じで「No」「No」主張してるだけだよね

質問内容から論理的に答えてるわけではない
相手の話も何も聞かず、一方的に答えてるだけよ
そんなんでよく条件分岐で間違えないね
実は盛大に間違えてんのかね

>>949
それは思い込みの日本語脳
中立的に見るとどちらがシンプルかわかる
英語はシンプルでわかりやすい
「XXXである」＝「XXXは真」＝Yes　
「XXXでない」＝「XXXは偽」＝No

英語は結論がセンテンスの前方に出てきて後方で補う
肯定文なのか否定文なのかも早い段階で相手に伝わる
これ、関係あるのかな

英語脳になると人の話を聞かないようになるのかな。

にゃー

>>936
x 高級言語やってた人にはキツイよ
o うましかにはキツイよ

>>955
>= を < に脳内変換しなくていいだけでも、ケアレスミスも減るしいいじゃない
人間だもの

バカでもアホでもチョンでも関係ない
どうせAIに全部もってかれるんだから

>956
あなたにお薦めの動画があります
https://www.youtube.com/watch?v=E8xdD33HaSs

fortranやcobolのgotoが機械語の名残なんだよ。だからc系のgotoを使わない言語とは勝手が違う。
それでもandやorが入った条件を正しく理解できる知能があれば問題ないんだよな。

>>951
お前英語知らんでしょ

英語ではどっち聞かれてもNoって言わないと自白したことになって有罪よｗ

お前がやったのか？　いいえ
お前じゃないってのか？　はい
↑　これが日本語で、論理的にも合ってる

お前がやったのか？　No
お前じゃないってのか？　No
↑英語だとこう答えないといけない

違うときはNo！といえばいい英語がわかりやすい

Cは、アセンブラでの規模の小さな定型文を書かなくていい程度の便利さが良い。規模の大きな定型文は関数に逃がす。
高級言語では当たり前のエラーチェックをしないのも良い。おかげで他に見ないトップスピードを得られる。
まあ、代償は大きいけど。
必要な手間が甚大な上に、設計がどんなに素晴らしくとも実装の不味さが特に出やすくあっさり瓦解もする。

Cはアセンブラほど低級ではないけどやはり抽象アセンブラ的な低級言語だし、高級と呼ばれるほど明快とは到底言えないけれど(アセンブラ基準で)簡潔に記述が出来る。
意図せずにPDP-11アセンブラに命令形態が似たそうですが、誰か86アセンブラからCに似た言語にまとめてくれませんかね。
噂に聞けば86アセンブラは文字列も扱えるそうで多分Cほど明瞭簡潔な言語にはならないだろうけど、気軽に低級記述出来るようになれば需要はかなり望めるんじゃないかなあ。
インタプリタとしてエラーチェック付き、コンパイラとしてエラーチェック無しでトップスピードぶん回しが出来れば、なお嬉しい。我欲垂れ流しです、はい。

Rustでいいだろ
Cでできることは全てできる

AI時代になってrustの意義急速に下がってるよな

AIにRustで作らせたものは大量に増えているが
Cで作らせるバカは少ない

apacheもfirefoxもRust製ωωωωωωωωω

最近の開発コミュニティではRust導入運動してるやつらは要注意扱いされてるから気をつけろよ
お前ら手段が目的化してんだよ

試しにマシン語で作らせてみ？
どうせデバッグも全部AI任せでいいんだし、人間が読む必要ゼロ

開発してる人?
AIが作っても、最後OK出すのは人間でしょ

だから数万回テストして結果が良ければOKでしょ
プログラムコードを人間が読んで理解してデバッグする必要はない
超速で数万回試行できるのもAIならではであって、人間では二桁数回がやっとよ　

>>971
テスト内容による
条件が不十分なら幾らテスト回しても無駄

>>972
だったら人がやっても無駄だな

テストは回数じゃなく質の問題だからなぁ

その質だって人間よりAIが上でしょｊｋ

中身見ないお前は何もわからない
ただの承認マシーン

>>976
本質を突いてワロタwwww