C++相談室 part138

■ このスレッドは過去ログ倉庫に格納されています
1デフォルトの名無しさん (ｽﾌｯ Sd9f-fGne)
垢版 |
2018/08/05(日) 18:02:36.57ID:DigzqJtZd
次スレを立てる時は本文の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/05(木) 23:44:48.07ID:tAsuenN+0
>>315
単に仕様が欲張り過ぎなだけ。
「何でも出来る」を目指している分、「普段は使わない」仕様ばかりになっている。
ただまあ、そういう言語も1つは必要だから、この意味では存在価値はあるのだが。

>>316-317
そのコードが「分からない」のなら老害でいいと思うけど。
君は結局、「俺のスタイルで書け」を強制する連中を擁護しているだけだろ。
俺はそうではなくて、例えばLL言語(JavaScript)では

deq.filter(v => v>=20);

で済む内容をグダグダやっていることに疑問を持たないのは老害だ、という考え。
当たり前だがC++より新しい言語はC++の欠点も見た上で改善内容を盛り込んでる。
それを学ぶ気もなく、古いスタイルにこだわり、結果的に効率が悪いなら、老害だ。

ただし関数型風の場合、ショートカット時に最速を得ることは難しい。
だからC++流のグダグダ記述も一定の妥当性はある。（ただし今回は全走査の為該当しない）
そして「分からない」と「使わない」はまた別の話だ。
そのコードはLinusの言う「C++erが糞な理由」の典型的な例だと思うが。
2019/09/05(木) 23:48:10.42ID:tAsuenN+0
>>319
結局「どこに記述するか」でしかなく、C/C++ソースコードの編集術でしかない。
それは当初は「上手い人の真似」で全く問題ない。
(それ以前に俺は2パスにしてその辺の糞仕様を全部消滅させるべきだと思っているが）

お前の下で若者がミスリードされないことを願う。
そしてもし上司がこのタイプなら、俺みたいな考えの奴も居ることを知っておいて欲しい。
上司は選べないが、上司は君の人生に責任を持ってはくれない。
間違ったアドバイスはスルーするのが妥当だ。
2019/09/06(金) 00:22:43.08ID:gaFoLiHv0
>>321
>つまりC++は、他に代替がない、という消極的理由でしばらくは生き続ける
>のはほぼ確定だ。
>しかしそれは当面であって、永遠ではない。

Unixが出来たのは1970年位らしいのですが、パソコンの世界では非力さのために
しばらく使うことが出来ず、BASIC言語、MS-DOSやWin95などが台頭しました。
しかし、LinuxやFreeBSD、cygwinなどの登場と共に台頭し始め、最近では
Win10の方がLinuxを使えるようにしてしまいました。2019年現在において、
Unix系は衰えるどころかどんどん勢力を伸ばしているようにも見えます。
実に50年です。50年続いただけではなく、50年後にもまだ勢力を伸ばして
おり、ネットの世界ではWindowsではなくUnix系が標準となっているようです。
安いレンタルサーバーなどではUnix系全盛ですし、古いと言われそうですが、
cgiも、perl、rubyなどもUnixと相性がいいようですし。
後から歴史を振り返って見るとWindowsが台頭したのは短期間で、Unix系が
非常に長い間使われていく可能性があります。

それと似たことがC/C++にも起きるかも知れません。ただし、STLなどを
多用しようとするような今風のC++というよりC++98位のCをベースとした部分です。

例えば、STLの >>317 のコードより、あなたが指定したように、
deq.filter(v => v>=20);
のコードの方がずっと分かり易いということは、STLには欠陥があるとも言えるのです。
ところが、CやC++98位の基礎の部分は違います。Unixと同じで今後もかなり長く
残っていく可能性があるように思えます。
2019/09/06(金) 00:25:15.97ID:gaFoLiHv0
>>324
ちょっと訂正。後半部分は的外れかもしれません。
探せば STL でも filter 文に似たものがあるかも知れず、それを使うと
LL言語同様に短く書けるかも知れませんので。
2019/09/06(金) 00:47:47.72ID:wEOaGISh0
ですます変えてIP変えれば別人になれると思っているのが愚かしい
それ以外のところが全く変わっていない

俺が推奨する自作自演方法は、一旦Google翻訳にかけて別の言語にして日本語に戻すことだ
これで自作自演テクも幾分マシになるだろう
2019/09/06(金) 00:49:22.44ID:O0tySfYQ0
>>322
>単に仕様が欲張り過ぎなだけ。
>「何でも出来る」を目指している分、「普段は使わない」仕様ばかりになっている。

誰かが指摘していましたが、C++は「一般化」にこだわりすぎているという
見方がありますが、一方で、

C++ では >>317のようにも書けてしまうという一般性は持っていますが、
JS や Ruby、Python などでもfilter文1つで済まさず、それ相当のものを
良く似た工程や順序で作れる一般性もあります。と同時に、それが
>>317 よりは遥かに短く分かりやすいコードに掛けるでしょう。

>>317のように書くくらいならば、deque, erase, partition などを使わずに
素朴に書いたほうが分かりやすて、かつ、短く書ける可能性が高いという
意味において、今の C++ の STL は予めある機能を使って楽しようとすると
逆に記述が長くなる傾向が有る気がします。

他の LL 言語では、高機能さと記述の簡潔さを同時に実現できるのと対照的です。
高機能でも長くしか書けないのであれば意味が無いとも言えます。
2019/09/06(金) 00:50:17.77ID:O0tySfYQ0
>>326
別人です。
2019/09/06(金) 01:19:07.29ID:4aqaCDmh0
ID変え忘れてるぞ
2019/09/06(金) 01:35:11.72ID:RbsTZIPr0
今時はrangeで書くんじゃね？
2019/09/06(金) 09:12:18.12ID:/xfj8nPF0
>>327
確かに素朴に書いた方が可読性が高いというのはある。
しかし同時に配列のメモリ管理を自然にしてくれるっていうメリットもかなり大きい。
まあSTLの仕様がわかってなくてユーザー定義のクラスをSTLに突っ込んだときは
さらに危険な気もするが。
メモリ管理をガベージコレクションも使わず、明示的な解放処理も使わないようにしようと思えば
c++かrustのような複雑さを伴うのはしょうがない。
2019/09/06(金) 11:25:53.62ID:O0tySfYQ0
配列一つとっても、Perl, Ruby, Python, JavaScript などでは典型的な書き方が1つ
に定まるが、今の C++ ではさまざまな書き方が出来てしまい、C風の伝統的な書き方
をすると老害扱いされてしまうのは困るな。
2019/09/06(金) 11:44:27.43ID:etGSUdSea
>>332
ですます調はやめたの？
2019/09/06(金) 12:28:04.61ID:h7oJ0UUz0
>>332
くだらん難癖つけてくるカスの言いなりかよ
2019/09/06(金) 12:43:52.92ID:T4bG70AI0
古いと言われても、配列はC++でも言語定義としては、伝統的なCと同じ
TYPE a[N1][N2];
の形式。

この板の人たちが薦めるような
std::array<TYPE, N> a;
の形式は言語定義ではなくあくまで STL というライブラリによる拡張
なのでSTLとの相性は良いが、記述が長くなるし良いことばかりではない。
ところがSTLを積極的に使いたい人はこっちでないと困ることもあって、論争に
成り易い。
2019/09/06(金) 15:55:55.24ID:w2Tc9TX10
静的配列と動的配列で書き方違うとか言われてもなぁ
そもそもスクリプト言語は静的配列ないやつ多いから書き方が一意になってるだけだし
2019/09/06(金) 16:04:54.25ID:h7oJ0UUz0
ビルトイン配列用のbegin/endとかrankなんてのがC++11で追加になったり
shared_ptrの配列バージョンもそうだし、ビルトイン配列はまだまだ現役だろ
arrayにしろなんて金切り声あげるやつこそ新しいものに対応するのが精一杯で
冷静に状況判断する余裕がなくなってるだけだと俺は見ている
2019/09/06(金) 22:37:56.43ID:/xfj8nPF0
>新しいものに対応するのが精一杯で冷静に状況判断する余裕がなくなってるだけ
これな。それをごまかすために必死に老外言いまくってる輩とかな。
どっちも使えるようにしとけが正解。
2019/09/06(金) 23:38:53.11ID:T4bG70AI0
ネット検索すると新しいものが上位に出がちなのでそれだけを見ていると
C++を知らない人が見ればスクリプト言語と似た書き方が出来てしまいそう
なのでそればっかり使ってしまいがちなのかもしれないが、
本当は古いものを学んでからでないとC++はまともには使いこなせないだろう。
2019/09/06(金) 23:49:29.02ID:k0Yv6u2hM
privateメソッドのユニットテストってするものなの？
2019/09/06(金) 23:49:52.74ID:46uMjIci0
>>324その他
何が言いたいのかよく分からんが、お前はテクニカルライタか何かか？
なら、プログラミングを知らずにプログラミングのことを書くことは止めろ。
誤情報が拡散されて迷惑なだけだし、それを読んだ若者が勘違いするだけだ。

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

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

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

というかそもそも発想が逆で、○○が残る、ではなくて、使えるものが結果的に残るだけだ。
それは言語でも同じ。
最近の若者は自身の選択を正当化する為に俺が選んだ言語スゲー＝俺スゲーする傾向があるが、
これ自体に意味はないし、そもそも「言語」ではなく「プログラミング」を学べばこんな事をする必要もない。
だから俺はちゃんと「プログラミング」を学べ、と言っているだけ。
初心者にも分かる基準で言えば、その言語限定か、他言語でも必要なものか、で判定すればいい。
2019/09/06(金) 23:53:49.38ID:46uMjIci0
>>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.55ID:46uMjIci0
>>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.64ID:46uMjIci0
γは意識高い系の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.88ID:46uMjIci0
※余談
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) としてくくり出されていれば俺は良しとする。
そしてインクルードヘッダみたいなソースコード整形にこだわる位なら、俺はこういう
「抽象度が不揃いな部分を積極的に括りだして関数毎の抽象度を揃える」整形にこだわった方がいいと思う。
そのうち、同じような括り出しが多くて、
それらを纏めるにはどうしても関数型のインタフェースになるのも納得出来るようになる。
ただしこれも所詮は「整形」であって、あまりこだわりすぎるのもよろしくないが。
346デフォルトの名無しさん (ｱｳｱｳｴｰ Sa4a-p7Vf)
垢版 |
2019/09/07(土) 00:35:19.13ID:lrUhBd6ha
boost賛美しすぎ
2019/09/07(土) 04:50:15.17ID:8jsw3qQup
長文を書く→ 情報量が増える → スレ番だけでは正確に返信できない → 引用する →さらに長文になる
2019/09/07(土) 05:55:52.45ID:+K1SeSv+0
>逆にゲーム開発現場のように、
>STLを使い倒すと決めて、チーム全員にその知識を要求するのもありだと思う。
いや、EASTLがあるから使い倒してるイメージになるかもしれんけど、そこまで浸透してはないと思うよ
自社でSTLの独自仕様作ってまで活用しよう、なんて
たかだかコンテナごときにエネルギー注げる会社はそうそうない
世界最大のゲーム会社だからそこまでやってられるだけ

簡単な使い方に限れば(&マルチプラットフォーム対応のためのアロケーションの問題に対するきちっとした解があれば)別に難しいもんでもないからそれなりに使っていこう、って程度かと
2019/09/07(土) 08:06:38.11ID:d7CxuB710
>>341
>× Cが残る
>○ C流のプログラミング手法が残る
>であって、つまり「変数、代入、条件分岐、ループ、関数でプログラミングする」手>法が残るだけだ。

OSに話を移して考えてみれば、
その程度の意味における「Unix流のOS手法」は、Winodwsに受け継がれているの
にも関わらずUnix自体が台頭している現実を説明できない。
コンピュータの世界では初期の頃に人気があったものが長く残るのだ。
2019/09/07(土) 08:47:21.11ID:YE8e0K3pM
不必要に長文を書く人の動機が謎だ
謎だが、かといって、知りたくもない
2019/09/07(土) 08:54:34.74ID:d7CxuB710
プログラマだからキーボードを打つのが速いからでは。
2019/09/07(土) 09:48:27.72ID:2rvwUuKs0
>>349
× > Unix自体が台頭している
○ Linuxが台頭している

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

ただいずれにしても、言語が死なない、ということに過度に拘るのはどうかと思うよ。
プログラミングは死なないよ。
2019/09/07(土) 10:23:19.57ID:rAOLkxY40
>>350
動機なんかなくて、ただ我慢ができないだけだと思う。

>>351
打つのが速いのはいいが、思考を整理せずに垂れ流すのはいかがなものか。
2019/09/07(土) 10:35:54.93ID:2rvwUuKs0
>>348
それくらいのスタンスが現実的に無難だと思う。
そもそもコンテナに入れる要素のrequirementsどこに書いてるんだよ？と思って探したが、ググッてもスパッとは出てこない。
> T は CopyAssignable および CopyConstructible の要件を満たさなければなりません。
> 要素に課される要件はコンテナに対して実際に行われる操作によります。
> 一般的には、要素型は完全型であることが要求され、 Erasable の要件を満たさなければなりませんが、
> 使用するメンバ関数によってはさらに厳しい要件が課されます。
> https://ja.cppreference.com/w/cpp/container/vector
だからその「さらに厳しい条件」の詳細はどこに書いてあるんだよ？と。
2019/09/07(土) 10:37:07.52ID:d7CxuB710
>>353
>打つのが速いのはいいが、思考を整理せずに垂れ流すのはいかがなものか。
もっとたくさんの思考を整理した結果、あの程度の量に縮まった可能性がある。
難しい本なんかはあれの数百倍くらいあるし。
2019/09/07(土) 10:50:30.97ID:d7CxuB710
>>352
>ただいずれにしても、言語が死なない、ということに過度に拘るのはどうかと思うよ。
>プログラミングは死なないよ。

Cやアセンブラが好きだったからその延長線上のC++も使っていた。
STLはRubyやPythonやJSのような分かりやすさも無いし、旧来のC++ native
に比べてそんなに優れているとは思わない。
2019/09/07(土) 11:10:27.84ID:SVPBVucP0
>>352
理由はともかくとして、コンピュータに関するいろいろなことが Unix風に
なって来てる気がするんだよ。理由は分からない。
2019/09/07(土) 11:58:19.80ID:2rvwUuKs0
>>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もボロカスに言ってる。
359デフォルトの名無しさん (ﾜｯﾁｮｲ be7c-p7Vf)
垢版 |
2019/09/07(土) 12:07:36.88ID:Xl8GtuMF0
LL風にって動機でVector使うなんて筋が悪すぎ
Dequeueやろ
2019/09/07(土) 12:26:52.91ID:hOghDJasp
delコマンドをCreateProcessで実行するとファイル削除できないが、
そのコマンドをファイル出力させてそのままコピーして張り付けるとファイル削除できるって現象に見回れているのだけど、
delコマンドって実行できない？？
ファイルが存在するかのチェックはしたのちに、そのファイルパスを利用しているからファイルパスに関しての間違いはない模様
361デフォルトの名無しさん (ﾜｯﾁｮｲ be7c-p7Vf)
垢版 |
2019/09/07(土) 12:28:59.10ID:Xl8GtuMF0
built in
2019/09/07(土) 13:37:29.58ID:d7CxuB710
>>360
ＣＭＤ.ＥＸＥ ／Ｃ ｄｅｌ ファイル名
を CreateProcess で実行するようにすると del コマンドが使えます。
2019/09/07(土) 13:42:24.25ID:SVPBVucP0
>>362
なお、コマンド部分を半角英数字で入れると投稿時にブロックされるため
全角に直した。なので実際に行う時は(当然ながら)半角にする必要がある。
2019/09/07(土) 15:44:50.48ID:iCWAqY8Wd
>>360
作った途端に消すとかしたりしてない？
ファイルが実際にはあっても処理が早いと確認できなかったりすることあるよ
2019/09/07(土) 16:09:20.07ID:d7CxuB710
del コマンドは内部コマンドで、del.exe というプログラムがある
わけではないため、CreateProcess() で直接実行することは出来ない。
実行したければ、>>362 のように、ＣＭＤ．ＥＸＥ を介して
使用する。
2019/09/10(火) 16:37:51.83ID:2ev/aWUC0
> 9割以上の箇所で全走査するんだから、
> 常にイテレータを指定しろというインタフェースがそもそもナンセンスだ。

あれ？　コイツrange-based-for知らねえの？ｗ
2019/09/10(火) 18:41:13.43ID:YAPHBQMFM
横からだが
それforだけじゃん
それforだけじゃん
2019/09/18(水) 02:11:49.04ID:GIOjMe2C0
祈れ！Unified Call Syntaxが導入される日まで！！！
2019/09/19(木) 00:07:42.51ID:T2nYB1sZ0
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.88ID:1k0/HGmS0
上から目線だがてめー自身は何なんだ
371デフォルトの名無しさん (ﾜｯﾁｮｲ 3d5f-9GzD)
垢版 |
2019/09/19(木) 10:52:43.71ID:nEj2AKuG0
川上さんに聴け
2019/09/19(木) 11:49:33.66ID:RkndgPZq0
本物の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.02ID:Pj1IM8vga
>>369
言語文法で保守性が変わらないならCOBOLやPASCALで書かれた遺物システムはモダン言語に即効置き換えられるべきでしょ
2019/09/19(木) 18:36:09.39ID:l/Pi8QO80
>>372
MISRA とかいう聳え立つ糞ルールの山を挙げられても…（困惑）
2019/09/21(土) 01:16:25.90ID:56SH7QzZ0
>>371
その通りだが、例題くらい用意してくれた方がお互いに助かるだろ。
それが解けない奴は最初から受験するなでいい。
有料化もありだとは思うが。
ハフィントンポストの/yuuya-adachi/post_7054_b_4928430.html
.ネーバー纏めの/odai/2142728139568393601
(URLはNG->自動BBXになるようだ）


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

どうせ発狂するのだろうが、その前に
・具体的に俺の書き込みのどの部分から
・俺がどう具体的に考えていると読みとれ、
・それに対して>>373がどう繋がるのか
を答えてからにしてくれ。
それが出来ないなら、お前は企業が嫌がるコミュ障そのものだ。
とはいえ当の企業もこれを認識出来てないのも事実だが。
2019/09/22(日) 21:28:03.17ID:UNI5np6A0
凄いのが現れたな
何拗らせたらこうなるんだろうな、知りたくもないが
377デフォルトの名無しさん (ｱｳｳｨﾌ FF85-9GzD)
垢版 |
2019/09/23(月) 11:09:00.39ID:3qdqqJ07F
これが朝鮮半島メンタルか
2019/09/23(月) 11:13:35.70ID:f1jovMGd0
発狂してるのはてめーなのに
自分を客観的に捉えることができないやつだな
2019/09/23(月) 22:10:13.16ID:DlI41VV80
設計レベルになるのだけどクラス分けが苦手でなにかおすすめのほんない？？
2019/09/24(火) 02:16:04.56ID:50WmMSgT0
>>379
本買わなくてもネットで調べればいろいろ出てくるじゃん

初心者にありがちなよくない実装としては、
・１万ステップとかの神クラスを作る（ほとんどの主要な処理がこのクラス内）
・クラス同士が密結合だったり、依存関係が複雑すぎてデバッグ不能
・機能を追加するために継承使う（そのため継承レベルが深すぎ）
とか、他にもいろいろ
2019/09/24(火) 08:18:16.34ID:svO4/0B3M
>>379
つGoF本
2019/09/24(火) 12:12:38.05ID:LAj+4L0e0
>>380
うちの会社にそういう実装する人、結構いるわ〜
１０年以上の経験者でもｗ
2019/09/24(火) 15:03:21.53ID:XC0ntArnp
>>380
一つ目はともかく、後の２つは場合によるだろ
384デフォルトの名無しさん (ｴﾑｿﾞﾈ FF22-9GzD)
垢版 |
2019/09/24(火) 15:07:49.06ID:oiN+60axF
iostreamですね判ります
2019/09/24(火) 15:08:02.64ID:otzwnRmY0
最近はクラス設計とかじゃなくて名前の付け方が一番大事だと思うようになったわ。
2019/09/24(火) 19:37:13.28ID:bRBDEgqh0
>>379
まず関数を短く切り出せ。
その次に共通の引数を構造体にまとめろ。
そしたらその構造体をクラス化してみるとよい。
2019/09/24(火) 19:45:54.32ID:AjZ3Ahz8M
>>383
> 後の２つは場合によるだろ

>> 依存関係が複雑すぎてデバッグ不能
>> 継承レベルが深すぎ
って言う「場合」の話だろ
2019/09/24(火) 20:20:10.21ID:LAj+4L0e0
>>383
継承はis-a関係のときだけ使ったほうがいよくね？
機能継承使う奴のコードは大概汚い
2019/09/24(火) 20:25:02.77ID:3E9gAKbz0
自分を大きく見せようとするやつが殺到するのがオブジェクト指向
つーか新しいプログラミングパラダイム

ところでオブジェクト指向って新しいか？
2019/09/24(火) 22:20:17.01ID:GLFX8H/60
>>388
has-aで継承とか一言も言ってないけど
多分>>380の一つ目を完全に前提にしちゃってるんだろうな
クラス同士の依存関係が強くなるのも、is-aの継承で機能追加するのも
そうすべくしてそうする事もあるだろ、ってこと
2019/09/24(火) 22:56:30.06ID:6JlrKQx10
逆に is-a の時にしか継承しないことにこだわりすぎると、それ以外の場合
でも敬称を使えばせっかく便利になる場合があっても機を逃してしまう事
がある。個人的には、普段使いする部分においての記述量が減ることが
大切だと思っている。ライブラリや基礎部分の記述量を多くしてでも、
普段使いする部分（応用部分）の記述量を減らした方がバグが減り易いから。
なぜなら、基礎部分については予め徹底的にバグを取ればよいが、
応用部分はテストをするのが難しかったりして事情が異なるから。
2019/09/24(火) 23:43:18.61ID:WQDKNZdM0
>>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.88ID:WQDKNZdM0
駄目なクラス分け＝保守出来ないクラス分け、なのだが、これに関しては、
・とにかくそれなりの規模のプロジェクトを立ち上げる(3000行以上）
・そしてそれをひたすら保守する
事をやれば自然に上達する。ありがちな間違いは
・全部書き直す
事を安易に選択してしまうことで、
これをやっている限り（書けるようにはなるが、良いクラス分けという意味では)上達はしない。
・何でこんな事になってしまったのか
・その原因はどこにあり、どのコードがどこにあるべきなのか
考えながら修正すれば自然と上達する。結局のところ、あれは、現実で言う、
・動線を考えて配置しろ
・道具は使う順に纏めて、並べておけ、
程度のことでしかないからだ。
間違ったクラス分けをしているとやりにくいだけであり、それは自然と気づける範囲だ。
書いてないことを実行してくれるはずもないので、「クラス分け」だけで差が発生するとしたら、
・どのコードがどこにあるか
の配置の違いでしかなく、これは、例えば
・車のパンク対応用のスペアタイヤを、車内ではなく、家の冷蔵庫の中に保管する
みたいな意味不明なことをやっていれば当然気づく範囲だからだ。

ただし最低限の規模は必要で、俺が思うに3000行がクラス分けが有効に機能し始める最低の規模だ。
それ以下ではベタで転がしていた方がましな場合も多く、
そこに初心者は無駄にクラス分けを持ち込んで余計に複雑にしてしまう事も多い。
https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition
2019/09/24(火) 23:44:32.80ID:WQDKNZdM0
だから、まずは、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.48ID:WQDKNZdM0
俺はネット記事を勧めるが、クレクレ君は死ねという思想なので、良い記事を探してやることはしない。
ただ、お前に学ぶ意志があり、その上でネット記事を数本読み、
・この記事のこの部分に疑問がある。俺はこう思う。
という具体的な議論なら受け付ける。
3,000行のコードも書けない初心者なら、まずは何でもいいからガシガシ書くことだ。
クラス分けなんてその後でいい。

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

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

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

そしてこれがよいかどうかはまた別なのだが、
いろんな構造を試すという試行錯誤が簡単に出来るのは上達にはいいと思っている。
だからクラス配置を学びたい場合は、C++ではなくてLL言語を勧める。
2019/09/25(水) 00:41:02.91ID:JEZ9mBal0
Ruby は、デザインパターン・疎結合の宝庫！

is-a/has-a, Duck Typing, Page Object, Test Double(依存性の注入), TDD/BDD(RSpec)など
2019/09/25(水) 08:48:48.39ID:J2adDr870
ruby書いてる奴、言うほどまともにテストしてねーじゃん。
2019/09/25(水) 10:44:33.62ID:ekILy0SR0
>>396
>なおC++はクラス単位でしか継承出来なくてその辺不便だが、
>JavaScriptは関数単位で継承出来る。
具体的に詳しく紹介してもらえませんか。
2019/09/25(水) 12:00:37.34ID:SmUxqnJ3M
プロトタイプのことだろう
継承とは言わない
2019/09/25(水) 12:37:26.12ID:p0DVbWLo0
あれ？　こいつインターフェイス知らねえの？ｗ
2019/09/25(水) 13:48:34.57ID:dXN3nOmu0
あーでもこれあれだな
長文はキモイな、やっぱ
OOは整理整頓術ってのはその通りだけど、長々と書かずにそれだけ書き込めばよい
あとは、プログラムにはデータ構造と制御構造の二つがあるんだけど
この別々のものを一纏めにするのがOOの悲劇の始まり、ってのを教えといてあげればよい
この辺ベテランでも割とモゴモゴする
2019/09/25(水) 14:02:26.76ID:p0DVbWLo0
データ構造と制御構造を対応づけようなんて話は
ジャクソン法やワーニエ法、つまり構造化プログラミングの時代に
もう出てきてた話なんだが
2019/09/25(水) 14:32:32.56ID:dXN3nOmu0
それを構文で取り入れたのがOO
2019/09/25(水) 14:43:06.95ID:wIawdvpd0
結局、「作る側（実装）」と「使う側（関数を呼び出す側）」を分けて、
前者を後者から隠すという事が class の概念の最も重要な部分で、
それによってさまざまなメリットを受けられる。
「オブジェクト指向」という概念は、実は、それとはかなり違うもので、
参考にするのはいいがそっちを重視しすぎるとそれはそれで問題を来たす
気がする。
2019/09/25(水) 14:57:19.16ID:5aP+8CuP0
メッセージングがどうとかの話だと思うけど
あれは確かにC++では忘れた方がいいだろうね(そういう風にわざと実装する場合はともかく)
Objective-Cなんかだと言語レベルでメッセージ送る形になってるけど
407デフォルトの名無しさん (ｱｳｳｨﾌ FF85-9GzD)
垢版 |
2019/09/25(水) 15:06:40.03ID:sdHp2tVCF
メッセージと名が付いてるから送り合ってるように見えるだけ
スレッド分けすらされてないシロモノ
2019/09/25(水) 16:57:24.56ID:wIawdvpd0
>>406
ん？
>>405 は、「カプセル化」と呼ばれる考え方で、メッセージとは
直接関係ない。
2019/09/25(水) 17:01:27.68ID:wIawdvpd0
classが入って便利になったもう1つのことと言えば、同じ種類のオブジェクトを
簡単にいくつでも作れるようになったこと。pure Cのグローバル変数と
ローカル変数だけを使ってそのようなことをしようとするとなかなか大変だったが、
C++ の場合、new CMissile のようにするだけで、ミサイルがいくつでも
追加できて、しかも、それぞれの位置や速度などがオブジェクト・インスタンス
の中にきっちり分けて入ってくれるのでとても便利。
2019/09/25(水) 17:04:42.69ID:fQKyMrFpp
いやすまん、C++のクラスがいわゆる本来のオブジェクト指向には沿ってないって話だと思って
メッセージングなんかには全く沿ってないよねと言いたかっただけw
他にも色々あるんだろうけど、C++のクラスと本来のOOとは切り分けた方がいいのは同意
2019/09/25(水) 20:02:30.30ID:J2adDr870
オブジェクト指向にこだわるよりかはSOLIDにこだわる方がまだまともだわ。
あんな用語にこだわらなくてもできてるやつはできてるし、
理解しないでこだわる奴は糞押し付け始めるし害悪でしかない。
2019/09/25(水) 20:20:38.86ID:SmUxqnJ3M
SOLIDよりYAGNIだな
オブジェクト脳のやつはありもしない拡張性を考えて無駄に複雑にする
それif分岐で十分だから
2019/09/25(水) 20:54:49.21ID:p0DVbWLo0
>>404
で、ベテランがモゴモゴって何のことだ？
2019/09/25(水) 22:33:49.67ID:wIawdvpd0
OOPにおけるSOLIDという言葉は初めて聞いたけど、何を言ってるのかよく分から
ない部分が多くて、すぐには理解できそうに無い。
2019/09/26(木) 06:40:00.74ID:HRGKiBoF0
>>398
言語設計者が一時期ソースコード＝仕様書、という思想を公言していた記憶
ソースコードにはバグも含めて全てか書かれている（のだからその存在自体が正しいい
、みたいな
2019/09/26(木) 06:41:14.19ID:HRGKiBoF0
OOは継承と多態性のしくみに夢を抱きすぎた
継承は当初差分プログラミングによる省力化がやたらと喧伝されたが、
多くの人がやったら効果など無く混沌が広がるだけだったので
結局>>402な見解に戦線が縮小して現代に至る

データ構造と制御構造（振る舞い）を(オブジェクトの名前).(メソッドの名前)という
単純な表記で呼び出せるように一緒くたにあえてまとめたために、
テンプレートによるメタプログラミングの道が開けた
結果さらなる破壊と混乱がもたらされた
2019/09/26(木) 07:10:46.20ID:++EmWszpM
バカが使うと混乱して仕組みが良くないとわめき出す
って言ういつもの流れw
2019/09/26(木) 08:46:10.69ID:XJFd2dlx0
何回言っても言い過ぎでないくらいまた馬鹿が出てくるからな。
2019/09/26(木) 11:18:51.43ID:jZpo+Xv90
OOの根本的な思想的な問題点は凝り固まったカプセル化の考え方にあるかもしれない
カプセル化って自分の仕事しかしない頭の悪いアスペみたいな存在で
そんなのだけが寄せ集まっても集団として何もできないという
人間でも同じでアスペだけの会社なんて無理だろうに
電気回路でも電子部品はコンポーネントかもしれないけど回路が無いと動かない
回路はどこに書くんだっていうね
だからC++はマルチパラダイム言語になってて
無論OOもあるが、非OOな部分が存在することも許容している
1+1は1に"+1"というメッセージを送る、とか解釈するどこかのアホの言語とは違う
2019/09/26(木) 11:21:52.79ID:jZpo+Xv90
これはあくまで思想的な話で、ものすごく大まかに言えばOOは左翼的な思想に属してて
本当にこれでよいのか？という疑問は常に付きまとう
こんなものを使っていると頭がおかしくなるんじゃないかという
実際プログラマは精神病になりやすいイメージがあるし
OOに染まったプログラマの言うことは回りくどくて聞いてられない
実際頭おかしいでしょ
2019/09/26(木) 12:51:41.19ID:GNqrTsXZM
すっこんでろ
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況