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/01(日) 20:33:49.80

途中まで、何かもっともらしく聞こえるが
結局、C++の特定の機能を否定したいだけな下心が隠せてないな

2019/09/01(日) 20:49:51.00

そりゃ無駄なことで労力使うことになる機能なんてなくなりゃいいと思うわ。
バカは他の人間が苦労してるのがうれしいのだろうが。

2019/09/01(日) 22:09:50.79

C++から入れば他言語で当たり前に使われてるRTTIやリフレクションがおかしなものか分かる

2019/09/01(日) 23:08:41.79

>>241
君がどこを目指すかは君の自由だが、「プログラミングの達人」のつもりなら、
君らが馬鹿にする「C限定」「C++98限定」縛りでも他の凡人とは明確に差を付けられなければいけない。
それが出来ないのなら、君は「プログラミングの達人」ではない。

ただ、新しい記述は古い記述の問題点を修正したものであるのは事実なので、
その問題に直面しているのに新しい記述を拒絶するのは、老害だと馬鹿にしていい。

といっても、当然だが基本/必要不可欠な部分から整備するので、
最近のC++に入っている仕様はかなり屋上屋を架す状態になっているのも事実だろ。
googleのルールがC++11を基本としているのもこれが遠因にある。

C++のスレが歪んでいるのは、住人がこの辺の「ちょっと考えれば分かること」を認めないからだ。
はちみつ餃子（コテ名）なんて、リアルの友人に職業マ（ゲーム）が居て色々聞いてみて、
「プロでも最近の仕様には疎いんだよなー」とか愚痴ってたろ。
そこでアマチュアであるはちみつ餃子が正しくプロが間違っている、と認識する点が狂ってる。
そしてこのタイプの人間がC++スレには割と多い。

C++が一番使われているのはゲーム業界だと思うが、これは単純に速度が速いからだ。
そしてゲーム業界が直面している問題は（ちと古いが）例えば以下であり、要するにOOPの限界とかだ。
OOPはコードを綺麗にまとめる手段ではあるが、速度は大概遅くなる方向だからだ。
https://sites.google.com/site/shunichisnote/translations/data-oriented-design
そして当たり前だがC++の新機能なんてこれに対する解を提供するものでは全くない。
結果、C++のゲームプログラマはC++の新機能なんて知る意味がないから、無視または受動的となる。
これもちょっと考えれば分かることだと思うんだがな。

プログラマ＝料理人に対して、包丁職人＝C++の達人も必要であり、
それを目指すなら、新機能を使えること＝上達だと考えるのは正しい。
でもそうでない場合、早い段階でこの認識は改めた方がいい。

2019/09/01(日) 23:27:53.27

ある機能を使わない理由が知らないからで、結果無駄な労力かけている
知らない理由を正当化しようと、知る前から役に立たないとか抽象的な理屈で断定するのは逃げでしかないんだよね
まあ言語仕様なんてアセンブラがあればなんでもできる
色々な言語があって、それぞれ独自に進化しているのは、結局みんな楽をしたいからなんだよ
手を動かす方で楽をするためには知識と知恵が必要で、知識を得るためには勉強が必要
まあ知識だけ入れても使いこなす知恵がないと無意味なのだけど

2019/09/01(日) 23:28:14.32

ゲームなんて子供のおもちゃとかどうでもよくて草

2019/09/02(月) 00:21:05.86

>>243
リフレクションは動的→静的変換には必要ではある。
ただし動は動で組む、というのがC流ではある。(リフレクションがない世界だったから当然ではあるが)
といってもリフレクションありならだいぶ楽に書けるのも事実で、
.NET(WPF)はこの部分だけはフレームワークが自動的にリフレクションしてくれることになっている。

RTTIはgoogleは「必要になるのは設計ミスだ」という見解であり、確かにこれは事実だが、
https://ttsuki.github.io/styleguide/cppguide.ja.html#Run-Time_Type_Information__RTTI_
RTTIを使っていいのなら手抜きなパッチをサクッと当てられるのもまた事実だ。
(RTTIありなら1行で済むのが、無しでvirtualで対応なら新規クラス追加になってしまう）

ここら辺は結局のところ、どのコード品質まで許容するか、であり、
当然体面は「常に今現在の仕様で最高のコードにしておけ」な訳だが、
現実的に「そんなん出来るかバカヤロー」である程度デタラメなパッチも許容するのなら話は変わってくる。
だからこの辺は「無くても実装は出来るし、困らない」のを認識した上で、
どこまで手抜きを許容するか、だと思う。

>>245
それは俺に向けたものではないと思うから補足になるが、
俺はそれに関してはC++ではなく他言語をやった方がいいと思ってる。
現状、手抜きに関してはLL言語の方が数段上で、C++は完全に周回遅れだ。
クロージャ採用も今更だし、リフレクション等も他言語で普通に学べる。
（それを使うかどうかはまた別として）

今現在、C++でしか学べない事って、
C++固有案件(テンプレートをこねくり回すこと等)以外にはないよね？
C++が先頭切って導入しようとしている事ってあったっけ？

2019/09/02(月) 01:57:52.96

>>244
業界経験者としても概ね同意
ただリンク先読むと、さすがにOOPとデータ主導（と速度）を両立できないのは
さすがに設計力不足だと思う（実際日本のゲーム会社は海外と比べてOOPの浸透率が低い）
枝葉末節にこだわって大局が見れてないんだろうな（このスレ見ててもわかるように）

>>245
＞ある機能を使わない理由が知らないからで、結果無駄な労力かけている
＞知らない理由を正当化しようと、知る前から役に立たないとか抽象的な理屈で断定するのは逃げでしかないんだよね
過去レス読む限り総称的なプログラミングには精通してる人のようだけど
さすがに↑の2行は思い上がりすぎだと思うよ、自分で読み直してみ

＞手を動かす方で楽をするためには知識と知恵が必要で、知識を得るためには勉強が必要
人の時間は有限だよ
あとここでよく挙げられるEASTLの開発動機の和訳
ttp://i-saint.hatenabl○g.com/entry/20101012/1286822888
の、Game software issuesの項を読め

2019/09/02(月) 02:25:50.18

ただまぁ、正直コンセプトが導入されたり他の理由で
総称的プログラミングが浸透する可能性は否定しないけどね
しかし自分の払った学習コストを正当化したいがために
学習コストまたは開発コストの増大を危惧する人を「不勉強」と貶すアマチュアの声が一番大きい言語だったら
C++に未来は無いだろうな（すでに無いという声もあるけど）

2019/09/02(月) 02:58:32.09

自演すんなゴミ

2019/09/02(月) 03:37:36.21

俺も自演と思ったw
文の長さ、漢字と平仮名のバランス、使う単語、全部似てるんだよね
自演と分かってないなら何かの病気を疑うレベル
それともC++使うとこうなってしまうのか？
長すぎるエラーばっかり見てるのも困りもんだな

2019/09/02(月) 04:56:02.57

>>240
ここまで読みました

2019/09/02(月) 06:35:03.03

長文で必死こくやつは余裕のなさが丸見えだ
それこそ言語に振り回されて及び腰になっている自分を恥じるあまり
防衛反射で攻撃的になっているだけだろ馬鹿馬鹿しい

2019/09/02(月) 06:54:39.30

何言ってるか全くわからんが
とりあえずいつもの基地外が一人でファビョってんのは伝わってきた

2019/09/02(月) 07:11:23.77

>>239
func(const char *)とfunc(int)のようなものが10種類くらい有った場合、
func という名前で検索するだけでは目的のものが検索できない。

さらに、どの関数が呼び出されているかが分かりにくくなりバグの原因に成り易い。
例えば、func(int)とfunc(char)が有った場合、
func('A'+1)と書いた場合に、intとcharのどちらが呼び出されるかが混乱を
招きやすい。例えばの話、もっと複雑になって、+演算子が　operator+()
によってオーバーライド(オーバーロードではない)されていた場合、
どうなるかとか。

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メソッドのユニットテストってするものなの？