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/06(金) 11:25:53.62

配列一つとっても、Perl, Ruby, Python, JavaScript などでは典型的な書き方が1つ
に定まるが、今の C++ ではさまざまな書き方が出来てしまい、C風の伝統的な書き方
をすると老害扱いされてしまうのは困るな。

2019/09/06(金) 11:44:27.43

>>332
ですます調はやめたの？

2019/09/06(金) 12:28:04.61

>>332
くだらん難癖つけてくるカスの言いなりかよ

2019/09/06(金) 12:43:52.92

古いと言われても、配列はC++でも言語定義としては、伝統的なCと同じ
TYPE a[N1][N2];
の形式。

この板の人たちが薦めるような
std::array<TYPE, N> a;
の形式は言語定義ではなくあくまで STL というライブラリによる拡張
なのでSTLとの相性は良いが、記述が長くなるし良いことばかりではない。
ところがSTLを積極的に使いたい人はこっちでないと困ることもあって、論争に
成り易い。

2019/09/06(金) 15:55:55.24

静的配列と動的配列で書き方違うとか言われてもなぁ
そもそもスクリプト言語は静的配列ないやつ多いから書き方が一意になってるだけだし

2019/09/06(金) 16:04:54.25

ビルトイン配列用のbegin/endとかrankなんてのがC++11で追加になったり
shared_ptrの配列バージョンもそうだし、ビルトイン配列はまだまだ現役だろ
arrayにしろなんて金切り声あげるやつこそ新しいものに対応するのが精一杯で
冷静に状況判断する余裕がなくなってるだけだと俺は見ている

2019/09/06(金) 22:37:56.43

>新しいものに対応するのが精一杯で冷静に状況判断する余裕がなくなってるだけ
これな。それをごまかすために必死に老外言いまくってる輩とかな。
どっちも使えるようにしとけが正解。

2019/09/06(金) 23:38:53.11

ネット検索すると新しいものが上位に出がちなのでそれだけを見ていると
C++を知らない人が見ればスクリプト言語と似た書き方が出来てしまいそう
なのでそればっかり使ってしまいがちなのかもしれないが、
本当は古いものを学んでからでないとC++はまともには使いこなせないだろう。

2019/09/06(金) 23:49:29.02

privateメソッドのユニットテストってするものなの？

2019/09/06(金) 23:49:52.74

>>324その他
何が言いたいのかよく分からんが、お前はテクニカルライタか何かか？
なら、プログラミングを知らずにプログラミングのことを書くことは止めろ。
誤情報が拡散されて迷惑なだけだし、それを読んだ若者が勘違いするだけだ。

× Cが残る
○ C流のプログラミング手法が残る

であって、つまり「変数、代入、条件分岐、ループ、関数でプログラミングする」手法が残るだけだ。
ただしこれらはアセンブラで既に出来るので、少なくともC発祥ではないが。

STLの「分かりやすさ」について欠陥があるのはみんな認識してる。
ただC++のように最速を目指すならこの方法しかないのも事実だ。だから使われてる。
逆に言えば、最速を達成出来てSTLよりもましなものが無いからSTLが生き残っているだけ。

というかそもそも発想が逆で、○○が残る、ではなくて、使えるものが結果的に残るだけだ。
それは言語でも同じ。
最近の若者は自身の選択を正当化する為に俺が選んだ言語スゲー＝俺スゲーする傾向があるが、
これ自体に意味はないし、そもそも「言語」ではなく「プログラミング」を学べばこんな事をする必要もない。
だから俺はちゃんと「プログラミング」を学べ、と言っているだけ。
初心者にも分かる基準で言えば、その言語限定か、他言語でも必要なものか、で判定すればいい。

2019/09/06(金) 23:53:49.38

>>327
まるで分かってない、と言うか、お前プログラミングやってないだろ、としか思えない内容。
それで何故俺に絡もうとするのか？

> 素朴に書いたほうが分かりやすて、かつ、短く書ける可能性が高いという
> 意味において、今の C++ の STL は予めある機能を使って楽しようとすると
> 逆に記述が長くなる傾向が有る気がします。
これはない。STLは現実的にはフレームワークだが、
フレームワーク等が正しく構成されていれば、それより簡潔に書くことは出来ない。
解決策は簡単で、以下のように書けるようにインタフェースを追加すればいいだけ。

deq.erase([](auto v){return v<20;}); // 条件に合致するものを削除

ラムダも入ったし、これもじきに入るとも思うが。
STLはイテレータで抽象化するという手法が間違っている。
9割以上の箇所で全走査するんだから、
常にイテレータを指定しろというインタフェースがそもそもナンセンスだ。
ただまあこれも、使っている奴は当然気づいていると思うよ。

お前も初心者がよくやる勘違い、
「ぼくがよめるこーどはいいこーど、ぼくがよめないこーどはだめなこーど」をやっている。
良いコードとは「書き手の意図が正確に伝わるコード」であって、
「僕が知っている範囲の手法で書かれたコード」ではない。
この点、マルチパラダイムは読み手側に様々な手法の経験を要求するという意味で悪なのだ。
だからPythonやC#はそれを意図的に制限している。

例えば、この場合の「書き手の意図が正確に伝わるコード」は
deq.erase_less_than(20);
だ。ただこれではあまりにも汎用性がないから、フレームワークとして整備するならその次の階層
deq.erase([](auto v){return v<20;});
になるんだよ。

2019/09/06(金) 23:59:08.55

>>331
× > 素朴に書いた方が可読性が高い
○ 素朴に書いた方が『事前学習のコストが低い』

繰り返すが、可読性が高い＝書き手の意図が正確に伝わる、であって、
『知識のない読み手でも読める』ではない。
双方の手法共に十分な経験があり、STLのインタフェースが糞な部分が直れば、
単純に記述出来る場合は抽象度が上がった記述(例は以下）の方がいいに決まっている。
deq.erase([](auto v){return v<20;});
そして9割以上の局面においてこれは成り立つ。(※余談あり）

ただし現実的にはSTLはフレームワークであり、ゴリゴリ使用するとなると事前学習が必要だ。
だからチームとして使うか使わないか、使うならどこまでか、を決める必要があって、
通常は以下の3通りになる。

α. 全く使わない。
β. そのフレームワークが提供している型でのみ使う。
γ. 汎用コンテナに独自型を突っ込んでバリバリ使う。

Linuxはαで行く、とLinusが決めているのだから、そりゃboostを持ち込もうとする馬鹿は嫌われる。
それを不勉強というなら、Linuxだって例えばプロセス管理でPID等を可変長配列で持つしかなく、
当然vectorモドキをどこかに持っているはずで、それを探すのが面倒だからSTL使います、というのも
目的のプロジェクトに対する不勉強でしかない。
（既存の問題に対するコードは既に実装されており、必要なSTL的コードは既に存在しているはず）

βはLL言語のアプローチで、フレームワークは使うが深入りはしない、というもの。
実はあいつらが馬鹿にしている「スタティックおじさん」もこのスタンスなのだが、
スクリプト言語を使って調子に乗ってる馬鹿共はこのことにも気づけない。
まあこれはさておき、これは現実的なアプローチではある。

2019/09/06(金) 23:59:30.64

γは意識高い系のC++erが推奨しているもので、彼等はβを認めないから嫌われる。
ここまでやると、フレームワークに対する要求知識がかなり高くなってしまい、学習コストが高く付く。
ただし、最速を目指すにはこれしかないし、
ふんだんに使っていいのなら使った方が簡潔/明瞭な書き方は出来る。

だからこれらは学習コストとの兼ね合いであって、
人的リソースは有限なのだから、知識的参入障壁を上げれば、技術的参入障壁は下がってしまう。
（STLを知らないがC言語範囲ならバリバリの人を捨てて、STLを知っているだけの人を入れることになる)
OSSはメンテ出来なければ自動的に死ぬ。
Linusは知識的参入障壁をCレベルで固定し、結果的に技術的参入障壁を上げて上手く行っているのだから、
これに対して文句を言うのは全くの筋違いで、文句があればforkしろ、でしかない。
そしておそらく、意識高い系C++erがフォークしてSTLやboostを使いまくったら、
Linusの予言通り、早々にメンテ出来なくなって死ぬ。それは
「STLは知っているがC言語レベルでは良質なコードを書けないからLinuxにはコミット出来ない、
でもコミットしたいと思っている」意識高い系C++初心者ホイホイになることが目に見えているから。

逆にゲーム開発現場のように、
STLを使い倒すと決めて、チーム全員にその知識を要求するのもありだと思う。
実際にこれが出来るなら、素晴らしい方法ではある。
『素朴』とかの言い訳は、多くの場合、ライブラリ内のコードをそこにコピペしているのと変わらないから。

だからこれらは結局、人的リソースを含めたコード戦略であって、
プロジェクトリーダーがどうするか決めてそれに従い、死ぬも生きるもそいつの責任、で行くしかないと思う。
ここでやってる話も結局、「俺はこう思うから俺に合わせろ」以上のものになってないでしょ。
どうであれ文句を言ってもしょうがないし、また、不勉強を正当化するのも間違いだと思うよ。
（全部知っておけ、と言っているのではなく、「これ以上は立ち入らない」という選択をした、と考えるべき。
そしてそれによる不条理その他も選択の結果の責任として受け取るべき)

2019/09/06(金) 23:59:46.88

※余談
deq.erase([](auto v){return v<20;}); は抽象度が上がっているという点で良だが、
deq.erase_less_than(20); もまた同様に抽象度が上がっているのでありだ。
この2つはMatzの言う「ソースコードがドキュメントである」とも合致する。
駄目なのはその場に for文でしこしこ20以下のインスタンスを消すループを書いてしまうケースであり、
それは「読んでいてそこで引っかかってしまう」という意味で悪だ。
だからこれについての解決策はC++には用意されていて、
・そこには deq.erase_less_than(20); と書いて、メンバ関数 inline erase_less_than(int); を作る
なのだが、inlineは最早効かないし、ユーザー定義型ならさておきSTLをこの方法で拡張するのは悪だ。

だから『素朴な』手法でも deq.erase_less_than(20) としてくくり出されていれば俺は良しとする。
そしてインクルードヘッダみたいなソースコード整形にこだわる位なら、俺はこういう
「抽象度が不揃いな部分を積極的に括りだして関数毎の抽象度を揃える」整形にこだわった方がいいと思う。
そのうち、同じような括り出しが多くて、
それらを纏めるにはどうしても関数型のインタフェースになるのも納得出来るようになる。
ただしこれも所詮は「整形」であって、あまりこだわりすぎるのもよろしくないが。

2019/09/07(土) 00:35:19.13

boost賛美しすぎ

2019/09/07(土) 04:50:15.17

長文を書く→ 情報量が増える → スレ番だけでは正確に返信できない → 引用する →さらに長文になる

2019/09/07(土) 05:55:52.45

>逆にゲーム開発現場のように、
>STLを使い倒すと決めて、チーム全員にその知識を要求するのもありだと思う。
いや、EASTLがあるから使い倒してるイメージになるかもしれんけど、そこまで浸透してはないと思うよ
自社でSTLの独自仕様作ってまで活用しよう、なんて
たかだかコンテナごときにエネルギー注げる会社はそうそうない
世界最大のゲーム会社だからそこまでやってられるだけ

簡単な使い方に限れば(&マルチプラットフォーム対応のためのアロケーションの問題に対するきちっとした解があれば)別に難しいもんでもないからそれなりに使っていこう、って程度かと

2019/09/07(土) 08:06:38.11

>>341
>× Cが残る
>○ C流のプログラミング手法が残る
>であって、つまり「変数、代入、条件分岐、ループ、関数でプログラミングする」手>法が残るだけだ。

OSに話を移して考えてみれば、
その程度の意味における「Unix流のOS手法」は、Winodwsに受け継がれているの
にも関わらずUnix自体が台頭している現実を説明できない。
コンピュータの世界では初期の頃に人気があったものが長く残るのだ。

2019/09/07(土) 08:47:21.11

不必要に長文を書く人の動機が謎だ
謎だが、かといって、知りたくもない

2019/09/07(土) 08:54:34.74

プログラマだからキーボードを打つのが速いからでは。

2019/09/07(土) 09:48:27.72

>>349
× > Unix自体が台頭している
○ Linuxが台頭している

理由は単純に無料だからだろ。
これは「ケチ」な意味での無料の魅力もそうだが、
OSSで無料というのは全然意味合いが異なっていて、
安かろう悪かろう/高くて良い品質が共存出来るのは、値段相応だからであって、
無料で品質の良いものがOSSで出てきた場合、他が瞬殺されて、
結果的に「品質世界一」しか生き残れない超絶レッドオーシャン化する。
そしてそこで生き残り続けてるLinuxを誰も倒せないだけ。
実際、商用Ｕｎｉｘなんて、Linux以降は、昔も今も、死んで、どうぞ、だろ。

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

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みたいな糞も含めてな。理解出来てないのなら語るな、でしかない。