C++相談室 part138

**デフォルトの名無しさん** (ｽﾌｯ Sd9f-fGne) · 2018/08/05(日) 18:02:36.57

次スレを立てる時は本文の1行目に以下を追加して下さい。
!extend:on:vvvvv:1000:512

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

前スレ
C++相談室 part137
http://mevius.5ch.net/test/read.cgi/tech/1531558382/

このスレもよろしくね。
【初心者歓迎】C/C++室 Ver.103【環境依存OK】
http://mevius.5ch.net/test/read.cgi/tech/1530384293/

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

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

VIPQ2_EXTDAT: default:vvvvv:1000:512:----: EXT was configured

2019/09/07(土) 10:23:19.57

>>350
動機なんかなくて、ただ我慢ができないだけだと思う。

>>351
打つのが速いのはいいが、思考を整理せずに垂れ流すのはいかがなものか。

2019/09/07(土) 10:35:54.93

>>348
それくらいのスタンスが現実的に無難だと思う。
そもそもコンテナに入れる要素のrequirementsどこに書いてるんだよ？と思って探したが、ググッてもスパッとは出てこない。
> T は CopyAssignable および CopyConstructible の要件を満たさなければなりません。
> 要素に課される要件はコンテナに対して実際に行われる操作によります。
> 一般的には、要素型は完全型であることが要求され、 Erasable の要件を満たさなければなりませんが、
> 使用するメンバ関数によってはさらに厳しい要件が課されます。
> https://ja.cppreference.com/w/cpp/container/vector
だからその「さらに厳しい条件」の詳細はどこに書いてあるんだよ？と。

2019/09/07(土) 10:37:07.52

>>353
>打つのが速いのはいいが、思考を整理せずに垂れ流すのはいかがなものか。
もっとたくさんの思考を整理した結果、あの程度の量に縮まった可能性がある。
難しい本なんかはあれの数百倍くらいあるし。

2019/09/07(土) 10:50:30.97

>>352
>ただいずれにしても、言語が死なない、ということに過度に拘るのはどうかと思うよ。
>プログラミングは死なないよ。

Cやアセンブラが好きだったからその延長線上のC++も使っていた。
STLはRubyやPythonやJSのような分かりやすさも無いし、旧来のC++ native
に比べてそんなに優れているとは思わない。

2019/09/07(土) 11:10:27.84

>>352
理由はともかくとして、コンピュータに関するいろいろなことが Unix風に
なって来てる気がするんだよ。理由は分からない。

2019/09/07(土) 11:58:19.80

>>356
ただ逆に、生き残っている＝言うほどボロボロでもない、のも事実なんだよ。

LL言語のアプローチが好きなら、
・vectorしか使わない
・値は入れず、ポインタしか入れない。つまり全面的に vector<T*> で行く
・indexOf/filter/map/reduce/slice/concat等の配列メソッドは自前で用意してしまう
事をすれば同じ使用感にはなる。
ただそれなら最初からLL言語を使った方がいいが。
なおググれば実装例/コードはちらほら出てくるが、まだboostには入ってなさそうだ。

あと、StreamsライブラリというのがC++14から入っているらしい。
これについては俺より他の人の方が詳しいと思うが。
http://www.convertstring.com/ja/StringFunction/ReverseString
lmth.133-yrtne-golb/moc.2cf.golb.yihshoy//:ptth

ただまあ、C++は何も諦めてないので、
上記のように「やれば出来る」のは事実だが、無駄に煩雑になっているのも事実。
そこら辺はLinusもボロカスに言ってる。

2019/09/07(土) 12:07:36.88

LL風にって動機でVector使うなんて筋が悪すぎ
Dequeueやろ

2019/09/07(土) 12:26:52.91

delコマンドをCreateProcessで実行するとファイル削除できないが、
そのコマンドをファイル出力させてそのままコピーして張り付けるとファイル削除できるって現象に見回れているのだけど、
delコマンドって実行できない？？
ファイルが存在するかのチェックはしたのちに、そのファイルパスを利用しているからファイルパスに関しての間違いはない模様

2019/09/07(土) 12:28:59.10

built in

2019/09/07(土) 13:37:29.58

>>360
ＣＭＤ.ＥＸＥ／Ｃｄｅｌファイル名
を CreateProcess で実行するようにすると del コマンドが使えます。

2019/09/07(土) 13:42:24.25

>>362
なお、コマンド部分を半角英数字で入れると投稿時にブロックされるため
全角に直した。なので実際に行う時は(当然ながら)半角にする必要がある。

2019/09/07(土) 15:44:50.48

>>360
作った途端に消すとかしたりしてない？
ファイルが実際にはあっても処理が早いと確認できなかったりすることあるよ

2019/09/07(土) 16:09:20.07

del コマンドは内部コマンドで、del.exe というプログラムがある
わけではないため、CreateProcess() で直接実行することは出来ない。
実行したければ、>>362 のように、ＣＭＤ．ＥＸＥを介して
使用する。

2019/09/10(火) 16:37:51.83

> 9割以上の箇所で全走査するんだから、
> 常にイテレータを指定しろというインタフェースがそもそもナンセンスだ。

あれ？　コイツrange-based-for知らねえの？ｗ

2019/09/10(火) 18:41:13.43

横からだが
それforだけじゃん
それforだけじゃん

2019/09/18(水) 02:11:49.04

祈れ！Unified Call Syntaxが導入される日まで！！！

2019/09/19(木) 00:07:42.51

C++の糞な部分が修正されるのならよいことだ。（使うか使わないかは別）
ただ俺はググって出てきた以下記事で、

> ドワンゴは本物のC++プログラマーを募集しています
https://cpplover.blogspot.com/2014/11/cunified-call-syntax-n4165-n4174.html

ってことの方に興味が行った。「本物のC++プログラマ」って何ぞ？
同様に引っかかった奴も居たようだが、ドワンゴの基準は分からない。
この点、googleなら自社有名プロジェクト、例えばchromeで
「このコードを将来にわたりメンテナンス出来る人を募集しています」
と出来るので、差が埋まらないのだな、とも思った。

プログラミングなんて手段でしかないのだから、本来は、
・将来的にもメンテナンスする価値のあるプロジェクトを --- (A)
・ずっとメンテナンスしていける能力 --- (B)
を実力とすべきで、つまり、
・OSSで生き残っているプロジェクト(A)をメンテ出来る能力(B)
というのは素晴らしく分かりやすい。
社員なら(A)は会社が指定するので(B)だけ出来ればよく、
ドワンゴ内で非プロプライエタリに出来るソースがあれば積極的に出して世に問うべきだと思うんだがな。
プログラミングの実力を面接で見抜ける奴なんて居るとは思えないし、
ドワンゴ社員が気に入るスタイルで書ける能力は、プログラミングの実力ではないし。

いずれにしてもアマチュアC++erは文法に過度にこだわるのを止めた方がいい。
文法で修正出来るのは精々数行の範囲での複雑さでしかなく、
「そもそも何でこんな構造にしたんだよ？」みたいな大域の複雑さには文法は関係ない。
そして問題になるのは常に大域の方だ。
というより小域のは大概は「書き方が気に入らない」だけであって、
必要であればラップ関数一つで大体収まることでしかないからだが。
勉強するのが目的になってるのなら本末転倒だ。
さっさと実現したい何かを書くべきだ。

2019/09/19(木) 06:23:39.88

上から目線だがてめー自身は何なんだ

2019/09/19(木) 10:52:43.71

川上さんに聴け

2019/09/19(木) 11:49:33.66

本物のC++ とは、数年以上、山籠もりすべし！

C++テンプレートテクニック第2版、επιστημη(えぴすてーめー)・高橋晶、2014
C++11/14 コア言語、江添亮、2015
組込み開発者におくるMISRA‐C:2004―C言語利用の高信頼化ガイド、MISRA‐C研究会、2006
Linux プログラミング・インタフェース、Michael Kerrisk、2012

Go, Rust, Ruby → Elixir, Python → Julia

2019/09/19(木) 13:29:31.02

>>369
言語文法で保守性が変わらないならCOBOLやPASCALで書かれた遺物システムはモダン言語に即効置き換えられるべきでしょ

◆QZaw55cn4c (ﾜｯﾁｮｲ e247-TpwJ) · 2019/09/19(木) 18:36:09.39

>>372
MISRA とかいう聳え立つ糞ルールの山を挙げられても…（困惑）

2019/09/21(土) 01:16:25.90

>>371
その通りだが、例題くらい用意してくれた方がお互いに助かるだろ。
それが解けない奴は最初から受験するなでいい。
有料化もありだとは思うが。
ハフィントンポストの/yuuya-adachi/post_7054_b_4928430.html
.ネーバー纏めの/odai/2142728139568393601
(URLはNG->自動BBXになるようだ）

>>373
コミュ障はプログラマを止めろ。
何が言いたいのか分からん。

どうせ発狂するのだろうが、その前に
・具体的に俺の書き込みのどの部分から
・俺がどう具体的に考えていると読みとれ、
・それに対して>>373がどう繋がるのか
を答えてからにしてくれ。
それが出来ないなら、お前は企業が嫌がるコミュ障そのものだ。
とはいえ当の企業もこれを認識出来てないのも事実だが。

2019/09/22(日) 21:28:03.17

凄いのが現れたな
何拗らせたらこうなるんだろうな、知りたくもないが

2019/09/23(月) 11:09:00.39

これが朝鮮半島メンタルか

2019/09/23(月) 11:13:35.70

発狂してるのはてめーなのに
自分を客観的に捉えることができないやつだな

2019/09/23(月) 22:10:13.16

設計レベルになるのだけどクラス分けが苦手でなにかおすすめのほんない？？

2019/09/24(火) 02:16:04.56

>>379
本買わなくてもネットで調べればいろいろ出てくるじゃん

初心者にありがちなよくない実装としては、
・１万ステップとかの神クラスを作る（ほとんどの主要な処理がこのクラス内）
・クラス同士が密結合だったり、依存関係が複雑すぎてデバッグ不能
・機能を追加するために継承使う（そのため継承レベルが深すぎ）
とか、他にもいろいろ

2019/09/24(火) 08:18:16.34

>>379
つGoF本

2019/09/24(火) 12:12:38.05

>>380
うちの会社にそういう実装する人、結構いるわ～
１０年以上の経験者でもｗ

2019/09/24(火) 15:03:21.53

>>380
一つ目はともかく、後の２つは場合によるだろ

2019/09/24(火) 15:07:49.06

iostreamですね判ります

2019/09/24(火) 15:08:02.64

最近はクラス設計とかじゃなくて名前の付け方が一番大事だと思うようになったわ。

2019/09/24(火) 19:37:13.28

>>379
まず関数を短く切り出せ。
その次に共通の引数を構造体にまとめろ。
そしたらその構造体をクラス化してみるとよい。

2019/09/24(火) 19:45:54.32

>>383
> 後の２つは場合によるだろ

>> 依存関係が複雑すぎてデバッグ不能
>> 継承レベルが深すぎ
って言う「場合」の話だろ

2019/09/24(火) 20:20:10.21

>>383
継承はis-a関係のときだけ使ったほうがいよくね？
機能継承使う奴のコードは大概汚い

2019/09/24(火) 20:25:02.77

自分を大きく見せようとするやつが殺到するのがオブジェクト指向
つーか新しいプログラミングパラダイム

ところでオブジェクト指向って新しいか？

**383** (ﾜｯﾁｮｲ 6101-XEoH) · 2019/09/24(火) 22:20:17.01

>>388
has-aで継承とか一言も言ってないけど
多分>>380の一つ目を完全に前提にしちゃってるんだろうな
クラス同士の依存関係が強くなるのも、is-aの継承で機能追加するのも
そうすべくしてそうする事もあるだろ、ってこと

2019/09/24(火) 22:56:30.06

逆に is-a の時にしか継承しないことにこだわりすぎると、それ以外の場合
でも敬称を使えばせっかく便利になる場合があっても機を逃してしまう事
がある。個人的には、普段使いする部分においての記述量が減ることが
大切だと思っている。ライブラリや基礎部分の記述量を多くしてでも、
普段使いする部分（応用部分）の記述量を減らした方がバグが減り易いから。
なぜなら、基礎部分については予め徹底的にバグを取ればよいが、
応用部分はテストをするのが難しかったりして事情が異なるから。

2019/09/24(火) 23:43:18.61

>>379
本でプログラミングを学ぶのは、止めた方がいい。
理由は、入門書を書いている奴はほぼ「本を書くこと」に特化しており、ろくなコードが書けないゴミだからだ。
江添は認めているだけかなりまし。
> 残念ながら、今仕事用のコードを書くといっても、未経験者とそれほど変わらない程度の能力しかない。
> https://cpplover.blogspot.com/2014/02/blog-post_13.html

入門書ではない本は、それなりの人が書いたものもあるが、例えば禿本4部には、
禿のプログラミング思想とそれに対するC++での解が書いてあるが、
それじゃ分からないんだろ。
(俺が初めて読んだときには感動したが)

ネット記事は「初心者上がりのイキった奴」が書く傾向があるが、
それでも彼等はコードを日々書いている分、本しか書いてない奴よりいい。
実際、ググって上から数個読んでみたけど、悪くないと思ったが。

クラス分けを学びたいのなら、C++ではなくLL言語を使った方がいい。
C++は体感3倍ほど手間がかかるから、
逆に言えば、LL言語を使えば3倍の量を同じ手間でこなせ、当然、上達も3倍速になる。

2019/09/24(火) 23:43:56.88

駄目なクラス分け＝保守出来ないクラス分け、なのだが、これに関しては、
・とにかくそれなりの規模のプロジェクトを立ち上げる(3000行以上）
・そしてそれをひたすら保守する
事をやれば自然に上達する。ありがちな間違いは
・全部書き直す
事を安易に選択してしまうことで、
これをやっている限り（書けるようにはなるが、良いクラス分けという意味では)上達はしない。
・何でこんな事になってしまったのか
・その原因はどこにあり、どのコードがどこにあるべきなのか
考えながら修正すれば自然と上達する。結局のところ、あれは、現実で言う、
・動線を考えて配置しろ
・道具は使う順に纏めて、並べておけ、
程度のことでしかないからだ。
間違ったクラス分けをしているとやりにくいだけであり、それは自然と気づける範囲だ。
書いてないことを実行してくれるはずもないので、「クラス分け」だけで差が発生するとしたら、
・どのコードがどこにあるか
の配置の違いでしかなく、これは、例えば
・車のパンク対応用のスペアタイヤを、車内ではなく、家の冷蔵庫の中に保管する
みたいな意味不明なことをやっていれば当然気づく範囲だからだ。

ただし最低限の規模は必要で、俺が思うに3000行がクラス分けが有効に機能し始める最低の規模だ。
それ以下ではベタで転がしていた方がましな場合も多く、
そこに初心者は無駄にクラス分けを持ち込んで余計に複雑にしてしまう事も多い。
https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition

2019/09/24(火) 23:44:32.80

だから、まずは、3000行の規模のコードを書けるようになるまで上達しないといけない。
それ以下なら、クラス分けなんて考えずに、ひたすら書いてまずは修行することだ。
クラス分けは、その後で学んでも全く問題ない。
そもそもOOPは大規模コードの整理術であって、
のべ1000時間もプログラミングをしてない初心者が理解出来る物でも、また、すべき物でもない。
「OOPはCみたいな手続き型とは別物だ」みたいな事を言う奴もちらほらいるが、これは老害の間違いで、
Cでも大規模になるとどうしてもstructが増え、何となくOOP化してくるのも事実で、
CのstructとC++のOOPは完全に連続的に繋がっている。
その証拠にstructとclassの区別がほぼ無いだろ。
「OOPは手続き型とは別物だ」というのはOOPを学びたくない老害か、
OOP本を売りたい糞ライタが嘘を言っているだけだから、そんな連中は無視でいい。

なお、「クラス分けが苦手」というのが本当にそうなのか？というのも少し疑問で、
「初心者上がりのイキった奴」がデタラメ言ってるのが多い昨今だから、
勘違いさせられている可能性もある。
いわゆる「コードを綺麗に」というのはつまり「長期保守可能なコード」にする為であって、
「正しいクラス分け」もその一端でしかない。
逆に言えば、それなりの規模で長期保守可能なら、「綺麗なコード」には出来ている、と言っていい。
具体的に言うと、10,000行以上で数年保守して来れており、本人もさほど問題を感じてないのなら、
少なくともそれなり以上の水準であることは保証出来ている。
結局のところ、Linuxのコードもこれに該当し、CにはOOP文法こそ無いが、
それなりにモジュール分割出来ている筈なんだよ。

そして余談だが、これがCや、或いはC++が今後も死にきらない理由でもある。
保守されてきているOSSは、それなりに「綺麗なコード」になっている。
だから、Rustみたいな「駄目な書き方が出来ないC++」ではOSSのC++プロジェクトを殺せない。
同様に、Cで「綺麗なコード」になってしまっているLinuxはC++では殺せない。

2019/09/24(火) 23:45:12.48

俺はネット記事を勧めるが、クレクレ君は死ねという思想なので、良い記事を探してやることはしない。
ただ、お前に学ぶ意志があり、その上でネット記事を数本読み、
・この記事のこの部分に疑問がある。俺はこう思う。
という具体的な議論なら受け付ける。
3,000行のコードも書けない初心者なら、まずは何でもいいからガシガシ書くことだ。
クラス分けなんてその後でいい。

ただし仕事場でこれをやられると困るのは事実なので、結果、
新人(≒初心者プログラマ）に対してもOOPを徹底させる必要があり、
その辺が歪みの発生原因になっていることは認める。
ただ、ここで尋ねてくるのはほぼアマチュアだろうから、これに囚われずに、
まずは3,000行規模を書けるようになることを目指すべきだ。
なお、プロ(新人）なら上司に聞いたほうが早いからそうすべきだし、逆に、わざわざここで聞くなら、
「上司はこう言っているが、俺は違うと思う」という具体例をコードと共に出すべきだ。
その場合、俺らがどっちが正しいか判断してやるよ。
https://mevius.5ch.net/test/read.cgi/tech/1467992113/10-

2019/09/25(水) 00:22:07.28

>>391
個人的には～以降の後半部分は同意。

前半部分は、反対でもないが賛成でもない。
理由は評価軸が異なるから。
俺はhas-a/is-aという形式論よりは、最終的にコードが目的に沿うかが重要だとしている。
それは大半の場合に於いて「長期的保守の為の可読性」だが、場合によっては「速度」だったりする。
(速度が必要なアプリなら遅いと存在価値がなくなり、長期的保守する意味がないから）
そして疎結合化には大抵の場合間接参照を一度噛まして当該コードを集めることになるので、
どこまで疎結合化するかも判断の一つだと思っている。
（というより疎結合化して問題がない場合は当然疎結合化するので、
残った物は速度等何かトレードオフがある物になるだけだが)

なおC++はクラス単位でしか継承出来なくてその辺不便だが、
JavaScriptは関数単位で継承出来る。
(というか、親クラスを自前で組み立てるだけで、その時に関数単位で引っ張ってこれるだけだが。
おそらくこれは動的言語の特性で、知らないがPythonやRubyも同様の筈。
Goが継承を廃止したと聞いたので俺は当然この機能がGoにもあると思っていたのだが、
無かったので愕然とした。
そしてもやもや考えているうちに、多分これは動的言語の特性なのだと（今のところは）結論づけている。
ただ、そうならGoって継承出来ないだけの糞でしかないのだが)

そしてこれがよいかどうかはまた別なのだが、
いろんな構造を試すという試行錯誤が簡単に出来るのは上達にはいいと思っている。
だからクラス配置を学びたい場合は、C++ではなくてLL言語を勧める。

2019/09/25(水) 00:41:02.91

Ruby は、デザインパターン・疎結合の宝庫！

is-a/has-a, Duck Typing, Page Object, Test Double(依存性の注入), TDD/BDD(RSpec)など

2019/09/25(水) 08:48:48.39

ruby書いてる奴、言うほどまともにテストしてねーじゃん。

2019/09/25(水) 10:44:33.62

>>396
>なおC++はクラス単位でしか継承出来なくてその辺不便だが、
>JavaScriptは関数単位で継承出来る。
具体的に詳しく紹介してもらえませんか。

2019/09/25(水) 12:00:37.34

プロトタイプのことだろう
継承とは言わない

2019/09/25(水) 12:37:26.12

あれ？　こいつインターフェイス知らねえの？ｗ

2019/09/25(水) 13:48:34.57

あーでもこれあれだな
長文はキモイな、やっぱ
OOは整理整頓術ってのはその通りだけど、長々と書かずにそれだけ書き込めばよい
あとは、プログラムにはデータ構造と制御構造の二つがあるんだけど
この別々のものを一纏めにするのがOOの悲劇の始まり、ってのを教えといてあげればよい
この辺ベテランでも割とモゴモゴする

2019/09/25(水) 14:02:26.76

データ構造と制御構造を対応づけようなんて話は
ジャクソン法やワーニエ法、つまり構造化プログラミングの時代に
もう出てきてた話なんだが

2019/09/25(水) 14:32:32.56

それを構文で取り入れたのがOO

2019/09/25(水) 14:43:06.95

結局、「作る側（実装）」と「使う側（関数を呼び出す側）」を分けて、
前者を後者から隠すという事が class の概念の最も重要な部分で、
それによってさまざまなメリットを受けられる。
「オブジェクト指向」という概念は、実は、それとはかなり違うもので、
参考にするのはいいがそっちを重視しすぎるとそれはそれで問題を来たす
気がする。

2019/09/25(水) 14:57:19.16

メッセージングがどうとかの話だと思うけど
あれは確かにC++では忘れた方がいいだろうね(そういう風にわざと実装する場合はともかく)
Objective-Cなんかだと言語レベルでメッセージ送る形になってるけど

2019/09/25(水) 15:06:40.03

メッセージと名が付いてるから送り合ってるように見えるだけ
スレッド分けすらされてないシロモノ

2019/09/25(水) 16:57:24.56

>>406
ん？
>>405 は、「カプセル化」と呼ばれる考え方で、メッセージとは
直接関係ない。

2019/09/25(水) 17:01:27.68

classが入って便利になったもう1つのことと言えば、同じ種類のオブジェクトを
簡単にいくつでも作れるようになったこと。pure Cのグローバル変数と
ローカル変数だけを使ってそのようなことをしようとするとなかなか大変だったが、
C++ の場合、new CMissile のようにするだけで、ミサイルがいくつでも
追加できて、しかも、それぞれの位置や速度などがオブジェクト・インスタンス
の中にきっちり分けて入ってくれるのでとても便利。

2019/09/25(水) 17:04:42.69

いやすまん、C++のクラスがいわゆる本来のオブジェクト指向には沿ってないって話だと思って
メッセージングなんかには全く沿ってないよねと言いたかっただけw
他にも色々あるんだろうけど、C++のクラスと本来のOOとは切り分けた方がいいのは同意

2019/09/25(水) 20:02:30.30

オブジェクト指向にこだわるよりかはSOLIDにこだわる方がまだまともだわ。
あんな用語にこだわらなくてもできてるやつはできてるし、
理解しないでこだわる奴は糞押し付け始めるし害悪でしかない。

2019/09/25(水) 20:20:38.86

SOLIDよりYAGNIだな
オブジェクト脳のやつはありもしない拡張性を考えて無駄に複雑にする
それif分岐で十分だから

2019/09/25(水) 20:54:49.21

>>404
で、ベテランがモゴモゴって何のことだ？

2019/09/25(水) 22:33:49.67

OOPにおけるSOLIDという言葉は初めて聞いたけど、何を言ってるのかよく分から
ない部分が多くて、すぐには理解できそうに無い。

2019/09/26(木) 06:40:00.74

>>398
言語設計者が一時期ソースコード＝仕様書、という思想を公言していた記憶
ソースコードにはバグも含めて全てか書かれている（のだからその存在自体が正しいい
、みたいな

2019/09/26(木) 06:41:14.19

OOは継承と多態性のしくみに夢を抱きすぎた
継承は当初差分プログラミングによる省力化がやたらと喧伝されたが、
多くの人がやったら効果など無く混沌が広がるだけだったので
結局>>402な見解に戦線が縮小して現代に至る

データ構造と制御構造（振る舞い）を(オブジェクトの名前).(メソッドの名前)という
単純な表記で呼び出せるように一緒くたにあえてまとめたために、
テンプレートによるメタプログラミングの道が開けた
結果さらなる破壊と混乱がもたらされた

2019/09/26(木) 07:10:46.20

バカが使うと混乱して仕組みが良くないとわめき出す
って言ういつもの流れw

2019/09/26(木) 08:46:10.69

何回言っても言い過ぎでないくらいまた馬鹿が出てくるからな。

2019/09/26(木) 11:18:51.43

OOの根本的な思想的な問題点は凝り固まったカプセル化の考え方にあるかもしれない
カプセル化って自分の仕事しかしない頭の悪いアスペみたいな存在で
そんなのだけが寄せ集まっても集団として何もできないという
人間でも同じでアスペだけの会社なんて無理だろうに
電気回路でも電子部品はコンポーネントかもしれないけど回路が無いと動かない
回路はどこに書くんだっていうね
だからC++はマルチパラダイム言語になってて
無論OOもあるが、非OOな部分が存在することも許容している
1+1は1に"+1"というメッセージを送る、とか解釈するどこかのアホの言語とは違う

2019/09/26(木) 11:21:52.79

これはあくまで思想的な話で、ものすごく大まかに言えばOOは左翼的な思想に属してて
本当にこれでよいのか？という疑問は常に付きまとう
こんなものを使っていると頭がおかしくなるんじゃないかという
実際プログラマは精神病になりやすいイメージがあるし
OOに染まったプログラマの言うことは回りくどくて聞いてられない
実際頭おかしいでしょ

2019/09/26(木) 12:51:41.19

すっこんでろ

2019/09/26(木) 14:06:22.33

https://ideone.com/pMPcFp
これはOOといえるか？
ベースコード80行も書いてるのに、メインロジック一つもないわ。

2019/09/26(木) 17:00:36.25

まぁ部品作るのには向いてると思うよOOは
ただ、部品なんてものは会社で言えば非正社員みたいなもので
そんなところに注力してもな
大事なのはそこじゃないからな
簡単なことをより簡単に出来るようにして
それ以外の難しいことに集中できるのがOOの利点か

2019/09/26(木) 18:55:11.69

>>423
カプセル化してユーティリティ作るにはクラス構造はかなり良い。

2019/09/26(木) 21:06:32.34

クラス分けはやっぱりデザインパターン見とけって感じなのね
どういうときに使えば便利かってのがいまだによくわからんのよなぁ

2019/09/26(木) 22:35:47.43

>>425
デザインパターンはゴミ。
ところでお前は何万行のコードを書いていてクラス分けが分からないの？

知りもしないのに嘘情報を垂れ流すのは止めろ。何の得にもならない。
お前はデザインパターンの有効性を判定出来るレベルではないだろ。
なら、その点については黙っておけ。
結果的に、お前らが知ったかぶりで嘘情報を流すからお前ら自身が迷惑を被るループになってる。
いい加減これに気づいてわきまえろ。

2019/09/27(金) 11:53:00.94

>>デザインパターンはゴミ。
同意はするが

>知りもしないのに嘘情報を垂れ流すのは止めろ。何の得にもならない。
>お前はデザインパターンの有効性を判定出来るレベルではないだろ。
>なら、その点については黙っておけ。
>結果的に、お前らが知ったかぶりで嘘

ここまで言うならお前がクソ言う理由も書くべき

2019/09/27(金) 18:46:28.25

>>427
何についてだ？
425についてなら、糞だと自明でないお前も糞でしかないだろ。
むしろお前が425みたいなゴミを擁護する価値があると認めた理由を先に聞こうか。
それが妥当と判断したら、俺が425がゴミな理由を述べてやる。それでフェアだろ。

2019/09/27(金) 21:02:00.04

>クラス分けはやっぱりデザインパターン見とけって感じなのね
>どういうときに使えば便利かってのがいまだによくわからんのよなぁ
さすがにこれだけ読んでこいつがデザインパターンを過剰に持ち上げてるとは
ふつう思わんだろ。
普通に考えればよくわからんやつがよくわからんがやってみるかって言ってるだけの文章だろ。

2019/09/27(金) 21:35:59.08

>>429
そもそもデザインパターンはクラス分けについての話ではない。
よって425は知らない癖にそれがさも「クラス分けに役立つ」と取れるような嘘情報を述べている。
もっとも、本人が積極的に嘘をついていると言うよりは、
過去誰かが425と同じようなことを書いたのを読んでいて、それを再度垂れ流しただけだと思うが、
それが425自身も既に嘘情報の垂れ流しループに組み込まれている証明となっている。
そして結果、自身も勘違いさせられ、また、勘違いした馬鹿を再生産して行っているわけだ。
そんなことは止めろ、と言っている。

過剰に持ち上げている事を咎めているのではない。
（というよりそもそも俺は過剰に持ち上げているとは捉えていない）
（結果的であれ、回避出来る）嘘情報を垂れ流すな、と言っている。

クラス分けについては、分からないのではなく、クラス分けが必要になる規模のコードを書いたことがないだけだ。
初心者は全員これだ。だから何度も規模を聞いている。
10行しか書けないのにクラス分けなんて分かるわけがない。全く必要ないからだ。
逆に、10,000行フラットに転がしてみろ。いやでもクラス分けが分かるようになる。

ただ最近の傾向として、425みたいな奴は増えている。
これは単純に、「ネットに書く」ということに関して前世代よりは若者世代の方が抵抗がないからだ。
だから知りもしないことをボソッとつぶやいたりしてしまう。そして本人に悪気があるわけでもない。
ただ、それでも間違った情報が拡散され、結果、それを読んだ奴が被害被るのもまた事実だ。
だから、知りもしない事柄についてはもうちょっと慎重に書け、ということでしかない。
同じ事はDeNAのキュレーションサイトでも起こったろ。
医者がうんちくや意見を（それなりに注意しながら）語るのはいいが、
医療知識が全くない奴がそれをコピペして適当に編集するからおかしな事になる。だから禁止された。
https://www.itmedia.co.jp/news/articles/1703/13/news114.html
同様に、プログラミングについての知識がない/まだまだ初心者の奴が知ったかぶって書くな、ということだ。
そして結果的にお前ら自身が被害を被っていることにも気づけ、ということ。

2019/09/27(金) 21:36:17.08

何度も言っているが、OOPは初心者が分かるものではないし、分かるべき物でもない。
それは単に、大規模コードを扱ったことがないからだ。
だから、その程度の奴らがOOPに対して何か書くこと自体が不適切なんだよ。
>>402みたいな糞も含めてな。理解出来てないのなら語るな、でしかない。

2019/09/27(金) 22:25:57.89

>10行しか書けないのにクラス分けなんて分かるわけがない。全く必要ないからだ。
>逆に、10,000行フラットに転がしてみろ。いやでもクラス分けが分かるようになる。
これはまったくその通りだとは思うが、しかしその機会のない連中が
とりあえずデザインパターンやってみっかってのがそんな悪いこととも思わんがな。
過剰な反応に思う。
医療問題のような致命的な問題がデザインパターンやることで生じるとは思わん。
確かにデザインパターン魔がシングルトン振り回してグダグダにしてったという歴史はあるが
そういうアンチパターンも最近は紹介されとる。
それでもカスな知識を振り回す輩は結局何やってもカスなことをやる。

2019/09/27(金) 22:28:30.87

>>427
> >>デザインパターンはゴミ。
> 同意はするが
同意するならその理由を書けって言われてるだけ
まあ書けないからグダグダ中身のない長文でごまかそうと必死なんだろうけどw

2019/09/27(金) 23:03:44.15

>>432
> しかしその機会のない連中が
だからこれがナンセンスだと言ってるんだよ。

OOPは大規模コードの整理術なのだから、
コードが大規模になったときにやればいいのであって、
逆に、大規模になったら、やる以外の選択肢はないんだよ。
(OOP文法を使うかどうかは別だが、「分割」はやるしかない。だからみんなやってる)

逆に、コードが精々500行程度、
つまり一般的なスクリプトの用途なら、OOPなんて一生必要ない。
だから知る必要もないし、また、この規模で適切に学ぶ方法もない。
つまり初心者レベルだとどうあがいても空回りする。

だから俺はグダグダ言わずにコードを書け、と言っている。
それがOOPが有効に機能する規模になれば、
余程馬鹿でない限り、自然に分かるようになる。それだけだ。

それはさておき、お前がサポートしたいのなら勝手にやればいい。
お前がデザインパターンを極めているつもりなら、422に講評つけてやれよ。
俺はお前らとは違う評価を付けている自信があるから、後出ししてやる。
もし俺と同じ評価をしている奴がいて、俺が何も言うことが無くなれば、俺の負けでいい。
（なお一応言っておくが、俺が賢いからではなく、
お前らが馬鹿（＝下手)だから俺と同じ評価を付けられないだろう、と見ている。
つまり俺はお前らを技術的には数段下だと見ている。それを「負け」たら見直す、ということ。）
我こそは、と思う奴は422に講評付けてみろ。
俺を伸したがっている馬鹿共もかかって来いよ。チャンスだぜ。

2019/09/27(金) 23:55:19.48

72行程度の長文でさえしどろもどろなアホが
何がOOPの必要性だｗ

2019/09/28(土) 00:07:57.26

デザインパターンは掃き溜めの鶴ではないか
何を言っているんだ

2019/09/28(土) 00:19:01.32

>>419
左様アスペを組織するにはタイピング量が半端無いことになりがち
アランケイが豪語したようなステップ数の削減は常人がOOPしたらまるで逆になる

>>417>>419
バカでも安全にプログラミングができるようにする、というのがソフトウェアー工学の主要なお題目
だっ
たはず

2019/09/28(土) 00:21:20.58

目的が不明なコードに講評だってさ

2019/09/28(土) 00:51:32.95

一応言っておくと、24時間は待つ。
状況によってはこの土日全部＝48時間待ってもいい。
イキってるだけの馬鹿共はいい機会だから講評付けてみろ。
匿名なんだから失う物はないだろ。それが匿名掲示板の良さだ。

イキるだけだからお前らは馬鹿なままなんだよ。
イキる元気さをちゃんとプラスの方向に転化しろ。
イキっているのにここで参戦しないのはチキン過ぎるぜ。

デザインパターンを「言葉で」擁護するのではなく、「コードで」擁護してみせろ。
つまり、デザインパターンを極めたお前だからこそ書ける素晴らしいコードを提示し、
俺みたいにデザインパターンを馬鹿にしている奴との差を見せつけてみせろ。

>>438
ぼくはあのこーどがなにをするのかさっぱりわかりません、か。
はい、お前は負け決定。
そのレベルでイキってるからお前は馬鹿のままなんだよ。少しは自覚しろ。

2019/09/28(土) 01:24:50.38

422ってメッセージパッシングをやりたいような気がするけど
それってOO設計じゃなくてOO自身の設計じゃん
スレの流れ的にそういう趣旨でいいんだっけ？w
とにかく >>439 の講評が楽しみだわ

2019/09/28(土) 01:28:35.64

イキってるって言いたいだけやん…
てか本人が一番イキってるしw

2019/09/28(土) 05:58:28.49

>>439
匿名掲示板で失うものと言えば、時間だな。
持論垂れ流して気持ち良くなってるだけの相手に議論しても、得るものはない。

2019/09/28(土) 07:59:27.08

酔っ払いの独り言は誰も面白いと思っていない
駅前で不特定多数を叱り飛ばしている危ないオヤジと同じだ

2019/09/28(土) 10:11:46.22

>>419
それは一理ある。実際、
自分の場合、1つのアプリの場合、ほとんどのclass メンバをpublicにしてる
場合がある。
しかし、class 分けすることで new CXxxx としただけで同じ種類のオブジェクトが
簡単に作成できる事や、似た働きを基礎に持っているが、基礎を発展させた応用的な
オブジェクトや同じ系統だが少しずつ働きの違うオブジェクトを、共通の基礎部分を
CBase クラスで書いておいて、それを継承したクラスで書ける事が便利になる。

だから、内部データにはアクセス禁止という意味でのカプセル化は達成したくても
なかなか達成できない事があるが、上記の様な意味で便利に使えてる。

2019/09/28(土) 10:16:07.55

>>435
それは思う。

2019/09/28(土) 10:22:21.06

>>444
補足しておくと、protected に出来るメンバはできるだけ protectedにしている。
例えば、ポインタで保持している何らかのデータなどは、ちょっとしたことで
間違って削除してしまう可能性があるので、そこにデータを書いたり、
ポインタが指す先を付け替えたりする関数は出来る限り protected にしてる。
そして、それはなるべく基本クラスの方にくくり出す。もし、別の関数でも
これと同じような処理が必要になったら、既にある関数を組み合わせてなんとか
ならないかを考える。そうすることで、ポインタのつけ間違いや誤ったオブジェクトの
削除を防ぐことが出来る。

ポインタ以外でも、データの整合性に関して慎重さが必要な場合は、上記と
同じようなことをやっている。

2019/09/28(土) 11:00:36.13

>>444
structで良いじゃん

2019/09/28(土) 11:38:05.06

>>447
純粋な構造体なら struct にして、名称も TXxxx にしている。
一方、メンバ関数があるものについては、原則的に必ず classにしている。
理由は、クラス定義を grep 検索する祭、必ず class CXxxx をキーワード
にすればよくなるから。これがもし、一部でも struct CXxxx というものが
混じっているなら class CXxxx では見落としてしまうことになる。
型名の頭文字が T の場合は、struct TXxxx と検索する。

2019/09/28(土) 11:40:37.11

>>448
それから、その時はたまたま public: 属性ばかりなだけで、
後から protected: 属性のメンバもできてくる可能性も有るから、
純粋なデータ構造体以外は、必ず class に統一することにしている。

2019/09/28(土) 11:50:17.24

システムハンガリアンにしがみついてる化石ｗ

2019/09/28(土) 12:22:40.96

MSVCはstructとclassの扱いが違う糞

2019/09/28(土) 14:13:38.93

>>451
どう違う？