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

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
一つ目はともかく、後の２つは場合によるだろ