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/08/31(土) 18:31:19.48

>>202
俺が言ってんのは開発期間(見積もり含め)とかの話な
お前多分だいぶ規模小さいだろ
だから無条件にテンプレート崇拝できるんだろうな

2019/08/31(土) 18:32:24.26

>>197
別にお前に言ってないけど図星突いちゃったか

2019/08/31(土) 18:37:06.98

規模が大きいって、template使わないから規模が無駄に大きくなっているだけだろ
コピペ改変繰り返したような糞コードの山みたいな

2019/08/31(土) 18:47:19.51

何言ってんだこいつ・・・

2019/08/31(土) 19:05:38.36

>>203
ああ、やっぱりそうか
５年１０年つってんのに規模がどうたらとか
マジその日暮らしなんだな
同情はできるぜ、俺だって死にそうに苦しい時あったからな

2019/08/31(土) 19:08:52.34

うちの会社にもなんでもかんでもテンプレートで定義する奴いるけど、
ほとんどのテンプレートが実際には１つの型でしか使ってなかったりするｗ

2019/08/31(土) 19:11:34.05

は？
まぁ自営歴はそっちのが長いかもしれんが
>>186に対して>>187を書ける根拠が知りたいね
くだらないことでマウントかましてきたからやり返すけど、お前チーム開発の経験はあるんだろうな？
自分が開発したライブラリ(もちろんテンプレート使った)を人様に使わせたこともあって言ってるんだろうな？

2019/08/31(土) 19:12:15.28

>>209は>>207宛

2019/08/31(土) 19:18:05.83

あ、あと>>204は読み間違いだったわ、すまんorz

2019/08/31(土) 20:40:29.29

>５年１０年単位の長い波長を持つ金の津波をどう起こすかって話と
名言ｋｔｋｒｗｗｗ
金の津波ｗｗｗ
それを考える奴がC++のソース書くのは時間が勿体ないよｗｗｗ

2019/08/31(土) 21:17:56.63

なんでも良いだろ。
デバドラ書いてる俺はいまだにCだよ。

2019/08/31(土) 21:59:21.80

理解してないバカがいるかぎりは何度でも言う。
てか google c++ の規約くらい読めばいいと思うよ。
実際、ためになるし、この手の文書にしては相当簡素で物量で圧倒されるようなもんでもないし。

2019/08/31(土) 22:43:32.33

ちょっと悪意ある実例かもしれんけど、
仮にメモリリソースを標準ヒープ限定にしないよう、任意のアロケータを使ったstring, vectorを
受け取る関数を書いたとして（いずれのデータも結構大きい可能性がある）、

https://wandbox.org/permlink/wGxcWDrAvb93ptzD
↑のようにテンプレート化した途端に、簡単なリテラルや初期化子リストからは受け取れなくなる
（もちろんstd::string(), std::vector<hoge, allocator<hoge>>{うんたらかんたら}とすれば通るが）
むやみにテンプレートマンセーして、ちょっと否定的な意見（しかも経験豊富な人からの）を見ただけで火傷起こしてるバカどもは
この程度の（自分でテンプレート使って汎用性求めればすぐわかる）デメリットにすら気付いたことがないんだろう

（こんなんだったらポインタで受け取った方がマシ、この場合は。）

**215=ID:RlpJENj70** (ﾜｯﾁｮｲ d1b3-cRT5) · 2019/08/31(土) 22:50:46.58

ちなみに、こういう任意のリソースを受け取るということについていちいちテンプレート化しなきゃいけなかったという
STL周りの不便さを改善すべく、新しいリソース管理クラスが導入されたけど
Alex Stepanovや標準化委員会も、allocator周りは失敗だったと思ってるんだろうな

あと、>>187も含めテンプレートマンセーしてる初心者は知らんだろうけど
STLは構想から含めて十年以上かけて作られた代物だからな、ある意味優れてて当たり前
そんなライブラリでも改善すべき点は見つかるんであって、ろくにテンプレートライブラリ書いたことも無いやつが権威を笠に着るなと言いたい
その上で「お前らその開発期間を償却できるほどの設計センスと経験、責任感があるんか」と問いたい

>>212
自営業といっても全然関係ない業種の趣味グラマだったりして

2019/08/31(土) 23:33:33.61

それ目的に対してテンプレートの書き方が悪いだけじゃね？

2019/08/31(土) 23:43:13.60

StringTとかArrayTとかもっと雑に受け取れってことやろ？
わかるけど、その先で全部統一した一つの関数テンプレートで処理をまとめられるとは限らない
結局泥臭いコンパイル時分岐を書かなきゃいけなくなることもある

2019/08/31(土) 23:44:19.87

>>215
ちょっと趣旨から脱線して申し訳ないが、
そういえば独自アロケータを与えられるのもC++の特長ではあったか。

となると、C++をどうしても使わなければならない局面は、
・ナマポとスマポの混在
・独自アロケータの使用
とかかな？

ただまあ、責める気はないが、
独自アロケータについては他言語は対応してないと思うので、
この場合はstlやテンプレートがどんだけ糞であろうが頑張ってC++で書くしかない。
勿論、色々改善する余地はあるとしても、
他言語がいわゆるシステムレベルプログラミング（≒OSそのものを作る）に
対応していないのだから選択の余地はない。
まあLinusに言わせればC++もシステムレベルプログラミングには使い物にならない、とのことだが。

2019/08/31(土) 23:48:26.00

>>218
雑というかSFINAEで制限しろという
まあ、conceptくるまで汚くて面倒なのは仕方ない

2019/08/31(土) 23:50:56.76

大体1の方しかなかったら、無駄にヒープ使われるだけで、それこそ望む挙動にならないような

2019/09/01(日) 00:08:04.65

SFINAEで対応とか、c++のオーバーロード、ならびにrvalue周りの仕様を
全部読み、かつ現実のソースをすべて読むのにどれだけの物量かかるか少しも想像してないんだろう。

2019/09/01(日) 00:10:55.48

>>219
いや、悪意ある例と書いたけど
どう確保したかに関数側が興味ないのであれば＆特殊な用途でなければ素直にポインタでいいし
>>216で挙げたPolymorphic Resource使えばテンプレートにする必要すら無いんだけどね（実際めっちゃ便利）

標準ヒープを前提にした設計＆サンプルコードなんかの綺麗な例のようなSTLの使い方しか
したことない初心者には全くそういう問題が想像つかないんだろうなと言いたかった
テンプレート使って設計するのはめっちゃ時間かかるし、そこまでする価値があるのかどうかというのは
今どきのC++でのコーディングには避けられない重要な判断だと思う
（そういう判断放棄して古臭い書き方してる職場が多いのは、決しておかしな話ではない）

>>220
＞SFINAEで制限
まぁその方が理想的なんだろうね（ある程度差異を吸収する関数はあるし）

2019/09/01(日) 00:12:31.04

仕様全てとは言わんが、書くなら関連する仕様くらい押さえておけってだけだろう。

書けない人材でも、そのライブラリを使うのには支障無いだろ

2019/09/01(日) 00:17:20.70

string_view的なもので実装書いて、他のは適当に切り分けてtemplateも必要に応じて使いつつoverloadで変換して実装呼ぶみたいなのはよくやる

そう言うのが多過ぎて面倒なら、パラメーター受け用のクラス作って受けたい元クラスから作るコンストラクタで変換するってのもあるし

2019/09/01(日) 00:24:30.79

>>224
c++の場合、まともにオーバーロードの仕様を抑えてる奴などおらん。
てかコンパイラ作る方も理解が薄いんじゃないかと思うレベルでバグ入れ込む話だぞ。
実際に仕様読むと増築につぐ増築でまともな仕様とは思わなくなる。
簡単だと主張する輩というのは仕様を読んでないか、もしくは江添みたく仕事の関係で後に引けないやつかしかおらんってことだ。

2019/09/01(日) 00:29:27.92

ADL含めたらややこし過ぎるが
そんなの普通は使わんだろ
名前空間指定してその中のオーバーロード使わせるのがまともなやり方

2019/09/01(日) 01:57:39.74

ID:9yJw5XoJ0は逃げたんだろうか・・・・ﾂﾏﾝﾈ

2019/09/01(日) 02:04:06.84

>>200
「全部入り」と言いつつcodecvtを入れた香具師は死刑

2019/09/01(日) 02:25:38.80

便所の落書き見て経験豊富と思うのはさすがに草

2019/09/01(日) 08:56:38.65

実引数依存の名前探索（じつひきすういぞんのなまえたんさく、ADL）とは、
C++において関数呼出時に与えられた引数の型に依存して、
呼び出す関数を探索 (lookup)する仕組みのことである

英語ではKoenig lookup、argument dependent lookup (ADL)、argument dependent name lookupなどと呼ばれる。
なお、Koenig lookupとは、この仕組みをAndrew Koenigが提案したことにちなむ

Koenigは、C Traps and Pitfalls(Ｃプログラミングの落とし穴)を、1989年に書いてる。
ADLは、Koenigが発明したのではないけど、標準委員会を説得したのは彼らしい

たぶん、ここまで詳しいのは、江添の本にしか書いてないだろう

2019/09/01(日) 10:09:22.81

Cは使い続ける意味はあるが
C++には未来はないよ
そういう使い方したい人は
Dを使えば良いんじゃないかな

2019/09/01(日) 11:24:12.52

>>227
それなら関数名なりを変えてるのと変わらんだろ。
オーバーロードなんて無理に使う必要ない。
てかそこまでうまくモジュール分割できないやつに限って使おうとする機能だから
問題なんだよ。

2019/09/01(日) 13:27:19.06

>>233
namespaceのalias作れるから
単純に関数名の接頭付けるのとは
使い勝手が段違い
namespace内でのoverloadは普通に有効だし

2019/09/01(日) 13:30:51.42

>>234
だからネームスペースで区切った時点で話は終わってんだよ。
オーバーロードなんて余計な機能使うのは混乱を生むだけ。
無駄に検索にも弱くなるし。

2019/09/01(日) 13:35:43.01

overloadは使うだろ？
overloadはする側が管理するため空間分けるってのは至極当然な話では？

2019/09/01(日) 16:35:53.77

>>236
関数のoverloadはgrep検索が上手く出来なくなるからなるべく使わないほうが
いいと思ってるよ。ちなみに間違いやすいけど override のほうじゃないよ。

2019/09/01(日) 17:04:46.72

推奨しない理由がgrepっておかしくね？
ちゃんと参照を解析できるIDE使えばいいやん
本質からずれてる

2019/09/01(日) 18:44:20.18

何でgrep上手くできなくなるんだ？

2019/09/01(日) 19:56:31.21

まあ使うも使わないも自由だが、あまり文法的なことばかりにこだわらない方がいい。
言い方を変えれば、「プログラミングの達人」と「C++言語の達人」は別なことを認識した方がいい。

「C++言語特有の機能」を使いこなせれば「C++言語の達人」ではあるだろう。
しかし、それは「プログラミングの達人」ではない。
「プログラミングの達人」なら当然「他言語を使っても達人」であり、
それは「言語非依存部分での圧倒的な巧さ」によるものだ。
単純に言えば、「ああ、こうすればこんなに簡単に実装できるのか」を繰り返してる。
C++特有の機能、つまりテンプレートやオーバーロードをいくら使いこなしてもここには到達できない。
それらは無ければ無いで何とかなる程度のものでしかなく、所詮はソースコードの整形でしかない。
それらをどれだけ使いこなしても本質的な構造の改善には繋がらない。

休日に5chに来てプログラミング談義に参加するような奴は、
モチベーションはあり、これは素晴らしい。上達も(本来は)するだろう。
ただ、最近は脱線している奴を多く見かける。
そして、無駄にやる気だけはあるから、おかしな議論で永久ループしてしまっている。
「言語非依存部分での腕前の差」を認識できないうちは、文法的なことにばかりこだわらない方がいい。
「C++言語の達人」ではなく「プログラミングの達人」を目指すなら、それは完全に空回りでしかない。

俺が見る限り、どの言語で始めてもどうやらそれなりにくだらない議論をやってる。
Javaの初学者は必要もないところでクラスを作って継承をこねくり回してる。
JavaScriptの初学者はセミコロンを打つか打たないかで議論してる。
C++の初学者はC++の無駄に複雑な言語仕様、特にテンプレート周りに惹かれるようだ。
ただ、これらを使いこなしても「プログラミング」そのものの上達はしない。
本来の「プログラミング」、つまり「言語非依存部分」での上達にフォーカスした方がいい。
そうであれば、C++が死んだら死んだで、あっそう、でしかない。
（俺はRustではC++を殺しきれないと見ているが）

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から追い出したいのなら、
俺に似合いそうな別のコミュニティを紹介してくれたら、そっちに行って居なくなるかもしれん。
よさげな所があればよろしく。