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/02(月) 07:12:36.17

>>253
長文の人は知的な人が多い。短文の人は女子高生の略語みたいに馬鹿な人が多い。

2019/09/02(月) 07:17:14.85

>>245
STLを使うより似たようなものを自作したほうが何かと修正しやすいと
いうようなこともあって、もし自作するならC++98位でも余り問題にならない
こととかあるんだよ。

2019/09/02(月) 07:25:53.20

>>256
自己紹介乙

0xffなんぞ驚愕の不勉強ぶりが炸裂してるなｗ

2019/09/02(月) 07:26:46.74

>>258
ちなみに俺は現実世界では天才と言われている。

2019/09/02(月) 07:26:49.57

こっちでやれよ
https://mevius.5ch.net/test/read.cgi/tech/1427572389/

2019/09/02(月) 08:35:59.22

知的な人は2ちゃんで3行以上書かない

2019/09/02(月) 10:03:26.80

そもそも5chに・・・

2019/09/02(月) 12:17:50.58

>>261 >>262
そうでもないだろうて。

2019/09/02(月) 12:37:08.37

>>255
なんか包丁は殺人にも使えるから包丁を使うのはNGみたいな議論
dump()のようなデバッグを容易にする関数は任意の変数を突っ込みたいし、その場合templateだけでは限界があるだろう

2019/09/02(月) 16:40:42.89

>>264
ケース・バイ・ケースだが、例えばの話、dump(int a)が呼び出されていると
思っていたら、dump(char c)が呼び出されていてせっかくのデバッグ情報
すら混乱してしまう可能性も有るかもしれない。入れ替わっても特に問題ない
場合も有るが、それは作り方による。余り変化が大きいようなものを
overloadだけで済ますと無駄な悩み事を増やしてしまうかもしれない。

2019/09/02(月) 17:06:35.32

だからC++はバカには使えないんだってば

2019/09/02(月) 17:26:28.34

明示的にするためにcastがあるんだろ

2019/09/02(月) 20:05:16.70

理性をもって使えば重火器も問題ないわけで銃解禁
というのは明らかに間違ってるわけで
メリットデメリットをちゃんと考えてんのかよって話なんだよ。

2019/09/02(月) 20:22:15.08

>>265

256デフォルトの名無しさん (ﾜｯﾁｮｲ 6961-hioB)2019/09/02(月) 07:12:36.17ID:CuenWXUR0
>>253
長文の人は知的な人が多い。短文の人は女子高生の略語みたいに馬鹿な人が多い。

259デフォルトの名無しさん (ﾜｯﾁｮｲ 6961-hioB)2019/09/02(月) 07:26:46.74ID:CuenWXUR0
>>258
ちなみに俺は現実世界では天才と言われている。

2019/09/02(月) 22:54:18.80

>>248
リンク先のは多分、綺麗なOOP（意識高い系OOP)を目指しすぎた結果だと思う。
ソースコードの品質『だけ』を目指した場合、そりゃそうなる、というのをやっている。

ソースコードの品質は一般的に

・長期的保守性（つまり可読性）
・仕様変更に対する強さ（というより不感度）
・ソースコードの流用性
　（他に持って行っても使える度合い≒自身内部で流用出来ればコード削減に繋がる）

が重要だとされるはずだけど、これには、

・値配列ではなく、ポインタ配列
・インスタンスは纏めて取るなんてやらず、一つ一つnewする
・配列は固定長なんて止めて全部自動可変長にする
・全部virtual

みたいに、JavaやLL言語の方向性で行った方が断然いい。
ただ、こういう無駄をいちいち外す事によりC++の高速性は成り立っているのだから、
ソースコードの品質『だけ』を目指した「綺麗なOOP」をやりすぎるとそれはゲームには向かない。
30年後に赤の他人が読む可能性もあるJavaと同じ土俵で議論するのが馬鹿げてる。

2019/09/02(月) 22:55:33.55

>>249
> 学習コストまたは開発コストの増大を危惧する人を「不勉強」と貶すアマチュアの声が一番大きい言語だったら
> C++に未来は無いだろうな（すでに無いという声もあるけど）
多分これはない。
おそらくC++は積み上げ型の学習(=ここまで出来た！)をしたい奴にとっては
「項目がやたらある」という意味で居心地がいいんだ。
だからここ5ch（数の上での主力はモチベーションの高いアマチュア）には妙な奴が集まることになる。
K&Rはあっさりしすぎてて、読んでも彼等は何をすればいいのか全くピンと来ない。
だから彼等はCを貶す。
とはいえ、現実のゲームプログラマの大半は休日はのびてるだろうし、ここの動向とは全く別だと思う。

が、まあ、これはさておき、
現実的にC++が提供している「ゴリゴリにマニュアルチューニング可能」が出来る言語が他にない。
よってゲームプログラマをはじめとして最高速が求められる領域、今ならMLとかもそうだと思うが、
これらにはC/C++しかない。
ところがCは全くやる気がなく、現実的にはC++しかない。

現状C++の代替となる可能性の最有力はRustだが、
C++が全部入りを目指す以上、Rustが出来ることは「C++とゴリゴリのリンター」で出来る範囲でしかなく、
結果的にRustコンパイラ自体が「C++のリンター」になって終わるのではないかと俺は見ている。

なお学習コストも考えて取捨選別して生産性を高めようとしているのはC#だが、
結果的にJavaとダダ被りすぎ、そしてJavaが死ぬことは今のところあり得ないから、
死ぬならC#になってしまっている。これも残念なことだ。

2019/09/02(月) 22:59:12.97

長文書くなボケカス死ね

2019/09/02(月) 23:11:25.28

>>272
お前はプログラミングを止めた方がいい。

マジな話、ドキュメントを読む能力の必要性は以前よりもどんどん高まっていて、
今時の若者プログラマは英語もある程度読めないと付いていけないと思う。
母国語すら3行しか読めないようならどうあがいても未来はない。

2019/09/02(月) 23:21:59.72

>>273
死ぬならC#とか情勢見誤りすぎだろw
WindowsでUnityはC#一択だ

お前はもうすこし纏める努力しろw
それか自分のブログでやれ

2019/09/02(月) 23:46:36.21

>>273
マジモンなのか・・・？

2019/09/02(月) 23:54:40.82

昔はドキュメント読まなくて良かったってマジ？
もちろん分野によるけど、公式のリファレンス等に目を通さなくてもなんとでもなる分野は圧倒的に昨今のほうが多いと思う
英語に関しても同じ
何やるかに大きく左右されるけど英語圏にしか情報がほとんど転がってないような分野も昔からある
というかCPU回りとかハードよりなとことかは特にそうじゃない？

2019/09/02(月) 23:57:32.31

妄言の落書きがドキュメントとかもう病院行った方が良いよ

2019/09/02(月) 23:57:36.60

>>273
必要十分にまとまったドキュメントなら長かろうが難解だろうが苦にはならないよ。
纏まりがない持論をだらだら垂れ流されたら鬱陶しいというだけのことだろ。

2019/09/02(月) 23:58:10.92

分かるように書くなら
main関数を1000行書くヤツをどう思うか
だな

2019/09/03(火) 08:57:09.79

いやたった２０～３０行じゃねーか。。
まあjavaとc#に対する見方はかなり怪しげな感じではあるが。

2019/09/03(火) 10:58:46.39

>>279
+1

.h に本体書く馬鹿もな

2019/09/03(火) 12:30:24.49

>>278
マイクロソフトを筆頭とするアメリカのIT企業のドキュメントの密度の
低さから比べれば格段にまし。

2019/09/03(火) 15:08:11.09

テンプレートとインラインは.hに本体書くぞ

2019/09/03(火) 15:11:02.11

テンプレートのいいところは、関数実体化しない限り、インクルードヘッダーを要求されないこと。

2019/09/03(火) 15:30:37.58

意味がわからん

2019/09/03(火) 15:37:28.53

真相はCMのあとで！

2019/09/03(火) 20:13:37.38

.hppとhを実装の有無で使い分けてるのっておかしいですか？
>>283みたいに実装をヘッダに書く必要があるときにhppにしてるんですが

2019/09/03(火) 21:55:23.31

>>287
俺は実装のあるなしではなくC/C++の両方から呼ぶときには.hを、C++からのみ呼ばないときは.hppにしてる
このルールだと確かにheader only libraryは.hppだし、実装を含む場合は.hppと言えなくもない

2019/09/03(火) 21:56:24.15

>>288
日本語おかしかった
C++からしか呼ばない場合は.hppを使ってる

2019/09/04(水) 07:01:17.49

最初プロタイプだけだったヘッダにテンプレートが入ったら拡張子を変更して
そいつをインクルードしているソースを変更して回るのか？

2019/09/04(水) 08:45:55.78

実装を含む場合は hpp てのは結構いいな。
まあ pimple はどうするとか言い始めるとめんどくさい話が出てきそうだが。

2019/09/04(水) 08:48:49.00

何がいいの？めんどくさい話しかなくね？

2019/09/04(水) 09:02:40.51

俺も最初から実装を含む前提のheader only libraryとただのプロトタイプに分けてるな。
後からテンプレートを追加する場合といっても、ライブラリじゃなけりゃたいてい明示的
インスタンス化で片付くしな。

2019/09/04(水) 09:59:34.00

明示的具現なんかやだよ
そんなことするくらいなら非テンプレートで多重定義しておいて
実装を作るときに無名名前空間の中で使ったほうがマシだ

2019/09/04(水) 15:49:54.63

今北産業

2019/09/04(水) 16:50:58.11

>>294
個人的には、明示的具現化というか、
class TZzz : public TXxx<TYyy> {
};
のようにしておいて、TZzz を使うようにしている。

2019/09/04(水) 17:06:17.24

>>296
なんかtypedefみたいな使い方だ
今時はusingか

2019/09/04(水) 17:16:50.20

うん、usingだね

2019/09/04(水) 19:19:08.36

3行しか読めない馬鹿はちゃんと本スレに行け。
C++相談室 part144
https://mevius.5ch.net/test/read.cgi/tech/1563769115/
「その話何度目よ？」な馬鹿共も同様。

おまえらは真面目に議論しているつもりなのだろうけど、
インクルードファイルをどうするかなんてC++固有案件だし、
「プログラミング」の腕前の向上には全く繋がらないことをちゃんと認識した方がいい。
そして、様々な対処法があるということは、逆に言えば、ろくな対処法がないことを意味する。
なら、どうあがいても糞なのだから、さっさと諦めてgoogleなりMSなりの対処法に乗っかった方がいい。
それで問題があるならそこで改めて考え直せばいいだけだ。

当たり前だがGoogleやMSの規模なら社内にツール担当の専属が居て、
そいつらが日々どうするか無駄に議論して、結果をルールとして定めてる。
それらはツールチェインを考慮しているから多少制約が厳しかったりもするが、
(よほど詳しいつもりでなければ)彼等の方が詳しいのも事実だし、
オレオレ流より結果的にかなりましだと思うが。

一般的に社内ルールなんてガチガチで大体ブーイングの荒らしだが、
それに比べてgoogleのルールはかなり緩く、参考にするには悪くないと思うぞ。
(もっともgoogle社内でもプロジェクト毎にさらにルールを課しているとは思うが）

テンプレートガー、インクルードファイルガー、なんて話は、
JavaScriptの連中がやってる「セミコロンを打つべきか否か、打つならどこに打つか」と変わらない。
「プログラミングの達人」を目指すならそんなところに無駄にこだわらず本質に急ぐべきだ。
「C++の達人」を目指すなら合点がいくまでやればいいが、
どのみち初心者/アマチュアではgoogleやMS以上の解決策を得られることは無い。時間の無駄だ。
そこで空回りした分、空回りしなかった連中とは差を付けられていることを認識した方がいい。

2019/09/04(水) 19:27:02.82

キチガイ来たー

2019/09/04(水) 19:43:52.84

2ちゃん(5ちゃん)で油売ってる口でな

2019/09/04(水) 20:09:24.05

俺が気に入らないのなら、まずは本スレに行くべきだ。

俺は「このスレが存在する限り、他のC++本スレには書かない」の宣言を今も守っている。
俺はお前らがやってる糞みたいな文法話には興味ないし、
お前らは俺の文なんて読みたくもないんだろ。Win-Winだ。
お前らが何故棲み分けしようとしないのか俺には分からん。

さっさと以下に行け。
C++相談室 part144
https://mevius.5ch.net/test/read.cgi/tech/1563769115/

（棲み分けしてればその必要もないはずだが）
それとは別に、俺を5chから追い出したいのなら、
俺に似合いそうな別のコミュニティを紹介してくれたら、そっちに行って居なくなるかもしれん。
よさげな所があればよろしく。

2019/09/04(水) 20:14:09.56

スレを私物化する奴はこの世から出て行ってくれたら嬉しいなあ

2019/09/04(水) 20:36:59.91

>>303
スレを私物化しているのはお前だ。
お前の意見が大勢だとでも思っているのか？

いずれにしても、俺（または長文）を嫌いな奴が
ずいぶん前に分離してゴミカス化してるこのスレに書く必然性はないはずだ。
また、俺は今後とも上記宣言を守るつもりで居るのだから、
わざわざ今更このスレに文句を言う必要もないはずだ。

結局のところ、スレはここで喚いている>>303のような、
「ぼくのみとめたすれしかみとめないゴミ」が潰していく。
それは全体の利益にはならないから、俺は棲み分けを提案してる。

このスレが嫌いならこのスレを読まなければいいだけ、
そしてそれが正しければ過疎って落ちるだけだ。
単純にお前がこのスレを読まなければ済む話だ。
何故それが出来ない？

さっさと以下に行け。
C++相談室 part144
https://mevius.5ch.net/test/read.cgi/tech/1563769115/

2019/09/04(水) 20:55:19.20

> 「プログラミング」の腕前の向上には全く繋がらないことをちゃんと認識した方がいい。

腕前が向上してない低脳に言われる筋合いはねえ
おととい来い、クズが！

2019/09/04(水) 21:00:18.23

ここはマジキチvoid君の専用スレです。
void君は本スレには二度と書き込まないと言っているのだから、彼の言うとおり本スレに移動しましょう。

2019/09/04(水) 21:11:41.56

もったいないので私にください

2019/09/04(水) 22:42:54.05

>>297
typedefにしていないのは継承クラス TZzz に機能を後々追加することを想定しての事。
必ずこのスタイルにしておけば、その時に修正しなくて済むので、
後々機能追加するかどうか分からなくても必ずこの形式で書くようになった。

2019/09/04(水) 22:49:23.32

>>308
追伸：本当は、T ではなく C を使って
class CZzz : public CXxx<CYyy> {　　// 1
};
としている。typedef ではないので、CZzz をさらに継承して
class CZzz2 : public CZzz {　　// 2
　・・・
};
のようにすることもできる。もし、
typedf Cxxx<Cyyy> Czzz;　　// 3
としてしまっていたら、2のようには書けないはず。
この形式だと全て class で統一されるので何かと安定感がある。

2019/09/04(水) 23:52:59.90

>>305
ならお前が本スレを引っ張れ。
お前のレスが素晴らしくて俺のレスがどうしようもなくゴミなら、
ほっといても誰もこのスレには寄りつかなくなる。
まあ頑張れ。
そうやってプラス方向の競争をしないと駄目なんだよ。

それはさておき、C++スレのアマチュアは本当によく考えた方がいい。
インクルードファイル等の問題はC/C++では避けられないが、こだわりすぎだ。
それはエディタのフォントや色に異常にこだわる奴と同じだ。
最初はこだわる必要があるが、一度自分のスタイルを決めたら、後はガシガシ書くべきだ。
そしてアマチュアがgoogleやMSのツール専属の連中以上に
適切な方法を選択出来ることはほぼあり得ないのだから、有り難くさっさと丸パクすべきだ。
つまり、初心者がそこにこだわっていること自体が間違いだ。

2019/09/05(木) 00:40:19.95

>>299
長文書いてる間、長文書いていないヤツに差をつけられているわけだ
5chで高説垂れても聞く奴なんてほとんどいないのに無駄なことをしているわけだ
無駄なことをしている間、無駄なことをいていないヤツに差をつけられているわけだ
周回遅れを10回くらいしてそうなほど無駄なことしてそうだよね
君の人生だから時間をどう使おうと勝ってだけど、しっかりと認識することが大事だよね

2019/09/05(木) 01:32:59.27

>>311
それはその通り。
だから俺も馬鹿がいない方が助かるから、
長文が読めない馬鹿はさっさと以下に移動してくれ。

C++相談室 part144
https://mevius.5ch.net/test/read.cgi/tech/1563769115/

それとは別に、俺と話したい奴がここに投稿するのはそいつの自由だし、
それ以前にこのスレに何を投稿しようが、そもそも投稿する奴の自由だ。
ただ、このスレに投稿された場合、俺が反応するかもしれないというだけ。

これについて、俺は俺が勝手に行った「棲み分け宣言」を守っており、
今現在の本スレは上記として別にあるのだから、無視するならともかく、
わざわざここに来て俺に文句を言うのは単なる当たり屋でしかない。
それはお互いに益がないから止めてくれ、というだけ。

まあついでに何度でも言っておくが、C++のアマチュアは自己満足が過ぎると思うよ。
どの言語の初心者もそれなりに空回りしてるとは240で言ったとおりだが、C++もだ。
ただこれについては防ぐのは難しいのだろう。

だから実際「C++なんて死ねばいいのに」と思っている奴も多いと思うよ。
原因はお前らが無駄に勘違いして威張っているのと、C++言語が糞過ぎるのが半々だと思うが。
といってもまあ、どの言語もそれなりに糞な部分はあるし、
C++は積極的に糞仕様を破棄している分、頑張っている方だと言える。
RustがC++をきっちり殺してくれれば割とみんな幸せになれると思うけど、
今のところその可能性は薄そうだし、もうしばらくC++はのさばりそうなのがなあ。

2019/09/05(木) 01:41:25.16

>>312
>今のところその可能性は薄そうだし、もうしばらくC++はのさばりそうなのがなあ。

世界最古級レベルのOSであるところのUnix系が台頭しているようにも思える昨今、
同じく最古級ではないにしても古くあるCを引き継ぐC++はしばらくどころか
ずっと残っていくかもしれない。

2019/09/05(木) 01:51:58.75

>>311
自分の場合、文書を短くしようとすると推敲(?)するのに時間がかかるので
深く考えずに長文で書いたほうがむしろ速く書けることがある。

2019/09/05(木) 02:05:25.81

>>31
>だから実際「C++なんて死ねばいいのに」と思っている奴も多いと思うよ。
>原因はお前らが無駄に勘違いして威張っているのと、C++言語が糞過ぎるのが半々だと思うが。

既に言語としては C++98くらいの段階でもかなりのことは出来ていたので、その後は
だんだんと好みの分かれる仕様となって言ってるのかもしれない。絵画などの
芸術作品で好みが分かれて、どの作品が良いのかを議論しても決して結論には
達しないように、ある人はC++98くらいの仕様が好きで、またある人は最新の
仕様の方が好きと言うような現象も起き得ると思う。

「C++言語が糞過ぎる」という件、多くの人が認めてはいるようですが、人によって
正反対の方向性を向いていたりします。ある人は古い部分が好きで新しい部分が嫌い、
ある人は逆に新しい部分が好きで古い部分が嫌いなのです。低級言語が好きな人と
高級言語の好きな人の違いかも知れませんが、単に学んだ時期の違いかも知れません。

使いこなせる人数からすれば、低級言語に比べてスクリプト言語の方が圧倒的に
多いとされていますので、単純に多数決で決めれば後者風が勝つことになってしまうでしょう。
しかしそれではC++の良さも失われてしまう可能性が高いのですね。

2019/09/05(木) 02:15:54.65

>>315
【追伸】
プログラミングの効率面で考えれば、標準のライブラリで用意されているものは
使った方が有利ですので、std::xxxx のように書かれる STLを使って方が
当然良い面も多いですが、それは本当はC++言語そのものではなく、あくまでも
ライブラリですので極論すれば MFCやWin32 APIを覚えるのと似たような
立ち位置にあるとも言えなくも有りません。この板の人たちは、
積極的にそのような最新のライブラリを使って自分でコーディングをする部分を
少なくするほうが「賢い」という価値観を持っている人が多いようですが、
昔にC++を覚えた人から見れば、カチンと来るところはありますね。
新しい機能を付けた人の技術を使っているだけで、使っている人の能力でも
努力でもなんでもない訳ですから。当然、後から生まれてきて今学び始めれば、
そういう最新の機能を身につけるのは当たり前ですが、昔にC++を学んだ人が
無能であるわけではないのに馬鹿だとか老害だと言ってしまう人が多いのが
この板の特徴なのです。

2019/09/05(木) 02:47:53.24

Wikipedia には、STLに「難解さ」がある例として、以下のようなものが
書かれていた。ここで使われている STL を十分に知らない場合には
「一見何をやっているのか全く分からないソースコード」になってしまっている：

size_t N = 0;
int *pdata = NULL;
GetData(&pdata, &N); // データとデータ数を得る

typedef std::deque<int> Cont;
Cont deq(pdata, pdata + N);
FreeData(&pdata, &N); // データを解放

// 典型的なSTLコード
deq.erase(
　　　　std::partition(
　　　　　　　　deq.begin(),
　　　　　　　　deq.end(),
　　　　　　　　std::bind1st(std::less<Cont::value_type>(), 20)
　　　　),
　　　　deq.end()
);

2019/09/05(木) 06:56:09.21

>>310
腕前が向上してない低脳を認めやがったｗ

2019/09/05(木) 08:03:44.02

インクルードファイルに関してはむしろもっとこだわれと思うことのが多いがな。
c/c++においては本質だよ。

2019/09/05(木) 08:08:02.98

長文が読めないやつがどうたらとぬかす前に
読んでみたくなるような文章を書けっての

駄文書いといて読んで貰えないのを人のせいにしてんじゃねえ

2019/09/05(木) 23:43:58.32

>>313
> ずっと残っていくかもしれない。
それはないね。
当たり前だがどの言語も利用価値があれば使われ続けるし、無くなれば廃れる。
現状、C++の利用価値は、EASTL等のページも参考にして、

・大規模コードでの高速性
・細部までいじれること（特にアロケータ周り）

位か。
一応Rustは両方目指しているので刺客の筆頭だが、
「Rust文法で書けばC++より速い」てなことはなさそうなので、C++を殺しきれない。
となると余程C++が嫌われない限り、エコシステムのないRustの方が先細って死ぬ。
つまりC++は、他に代替がない、という消極的理由でしばらくは生き続けるのはほぼ確定だ。
しかしそれは当面であって、永遠ではない。

Linusの目が黒いうちはLinuxにC++が入ることはない。
そして今更LinuxをC++で書き直したところで
「遅くて枯れてない劣化版Linuxモドキ」しか出来ないことが分かり切っているから誰もやらない。
Linux等をC++の生存理由と見るのは明確な間違いだ。
俺は2000年代中盤のOOP全盛時に「OOPで安全なOSを」みたいなのを聞いた覚えがあるが、
続報が全くないので完全にポシャったんだと思う。
それ以前にもC++でUNIXを、というのは失敗している。
http://hoshi.air-nifty.com/diary/2012/06/unixcosbill-joy.html
SymbianがC++だったようだが、Symbian自体が死んでしまったし。
https://monoist.atmarkit.co.jp/mn/articles/0703/22/news124.html

2019/09/05(木) 23:44:48.07

>>315
単に仕様が欲張り過ぎなだけ。
「何でも出来る」を目指している分、「普段は使わない」仕様ばかりになっている。
ただまあ、そういう言語も1つは必要だから、この意味では存在価値はあるのだが。

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

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

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

ただし関数型風の場合、ショートカット時に最速を得ることは難しい。
だからC++流のグダグダ記述も一定の妥当性はある。（ただし今回は全走査の為該当しない）
そして「分からない」と「使わない」はまた別の話だ。
そのコードはLinusの言う「C++erが糞な理由」の典型的な例だと思うが。

2019/09/05(木) 23:48:10.42

>>319
結局「どこに記述するか」でしかなく、C/C++ソースコードの編集術でしかない。
それは当初は「上手い人の真似」で全く問題ない。
(それ以前に俺は2パスにしてその辺の糞仕様を全部消滅させるべきだと思っているが）

お前の下で若者がミスリードされないことを願う。
そしてもし上司がこのタイプなら、俺みたいな考えの奴も居ることを知っておいて欲しい。
上司は選べないが、上司は君の人生に責任を持ってはくれない。
間違ったアドバイスはスルーするのが妥当だ。

2019/09/06(金) 00:22:43.08

>>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.97

>>324
ちょっと訂正。後半部分は的外れかもしれません。
探せば STL でも filter 文に似たものがあるかも知れず、それを使うと
LL言語同様に短く書けるかも知れませんので。

2019/09/06(金) 00:47:47.72

ですます変えてIP変えれば別人になれると思っているのが愚かしい
それ以外のところが全く変わっていない

俺が推奨する自作自演方法は、一旦Google翻訳にかけて別の言語にして日本語に戻すことだ
これで自作自演テクも幾分マシになるだろう

2019/09/06(金) 00:49:22.44

>>322
>単に仕様が欲張り過ぎなだけ。
>「何でも出来る」を目指している分、「普段は使わない」仕様ばかりになっている。

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

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

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

他の LL 言語では、高機能さと記述の簡潔さを同時に実現できるのと対照的です。
高機能でも長くしか書けないのであれば意味が無いとも言えます。

2019/09/06(金) 00:50:17.77

>>326
別人です。

2019/09/06(金) 01:19:07.29

ID変え忘れてるぞ

2019/09/06(金) 01:35:11.72

今時はrangeで書くんじゃね？

2019/09/06(金) 09:12:18.12

>>327
確かに素朴に書いた方が可読性が高いというのはある。
しかし同時に配列のメモリ管理を自然にしてくれるっていうメリットもかなり大きい。
まあSTLの仕様がわかってなくてユーザー定義のクラスをSTLに突っ込んだときは
さらに危険な気もするが。
メモリ管理をガベージコレクションも使わず、明示的な解放処理も使わないようにしようと思えば
c++かrustのような複雑さを伴うのはしょうがない。

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