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/07/26(金) 07:12:48.67

>>131
実は、>>133が指摘してる通り JavaやC#は言語仕様そのものが native binary
に直してもC++ほどの速度にはなりにくい。例えば遅くなる理由として
1. GC(Garbage Collection)によって自動的にfreeやdeleteさせようとする仕様。
2. 標準的にはポインタを使わない仕様。
3. オブジェクトが構造体やスタックに埋め込まれずにheapからnewされ易い仕様。
4. 二次元以上の配列がJaggyタイプに成り易い仕様。
5. バッファオーバーランの防止のため、配列の境界チェックが行われやすい仕様。
6. ライブラリが巨大なため起動時に大量のコードがディスクから読み出されるため、
　起動が遅く成り易いこと。巨大になる理由の一つはリフレクションや型に
　#includeによる静的コンパイルをせずにすますためののクラスの型情報などが
　(Javaの場合は*.classや*.jarなどの)ライブラリに入っているためだろうか。

例えば、C#も予めnative binaryに直してしまう方法も有るが、それでも起動速度は
余り早くならないらしい。起動後も1.～5.の理由のためC++程の速度にはなりにくい。

2019/07/26(金) 07:28:28.01

>>134
7. C#のリンクリストの場合、要素を削除する場合、文字列などの要素の中身か、
　要素番号を指定する必要が有る。要素Bを有る要素Aの後ろに追加する場合、
　Aの要素番号を指定する必要が有る。これが遅くなる。C/C++本来のリンクリストは
　削除や追加の場所の指定をポインタ(アドレス)で指定できることが速度上の大きな
　優位性であったのにそれが出来ない。なお、詳しくはないがC++のSTLのstd::listの場合は、
　同様の「不具合」があるためリンクリストの本来の性能が出ないかもしれない。
　しかし、それはSTLがC/C++の昔から使われていた本来のリンクリストの実装の仕方を
　していないからであると思われる。

2019/07/26(金) 12:04:17.56

Javaってランタイムがプリミティブなってるクラスを実行することがあったと思うけど、
ネーティブではそのプリミティブ型のクラスを分解してマシン語にしないといけなかった気がする。

2019/07/26(金) 12:42:19.26

vs2019なんだけどさ

void f(path&& pt)
{
auto date = last_write_time(pt);
auto val = decltype(date)::clock::to_time_t(date); //C2039
}

これどうやってtime_tもらうの？

2019/07/26(金) 16:10:27.37

decltype(ftime)::clock::to_time_t()
は、decltype(ftime) が std::filesystem::file_time_type なので、
意味的には長く書けば、
std::filesystem::file_time_type::clock::to_time_t()
となるとは思う。短くすれば、
file_time_type::clock::to_time_t()
となるけど、clock という名前空間は見つからなかったが、
std::chrono::system_clock::to_time_t()
という関数ならば存在しており、
static std::time_t to_time_t( const time_point& t ) noexcept;
という宣言にはなっているところまでは見つけた。
clock というキーワードが何なのかは不明。

2019/07/26(金) 16:16:35.83

last_write_time() の型は：
std::filesystem::file_time_type last_write_time(const std::filesystem::path& p);
file_time_type の型(?)は：
using file_time_type = std::chrono::time_point<>;
なので、
decltype(date)::clock::to_time_t() の部分は、decltype()部分を展開(?)すれば
std::chrono::time_point<>::clock::to_time_t()
と書けることは書ける。この部分は、存在することが分かっている：
std::chrono::system_clock::to_time_t()
ととてもよく似ている。

2019/07/26(金) 16:23:26.92

https://cpprefjp.github.io/reference/chrono/time_point.html
↑によれば、time_pointは
namespace std {
namespace chrono {
template <class Clock, class Duration = typename Clock::duration>
class time_point;
}}
というテンプレート・クラス。
file_time_typeは、C++20では、
using file_time_type = std::chrono::time_point<std::chrono::file_clock>;
と定義されているので、Clock=std::chrono::file_clock とされてテンプレートが具現化される
らしい。time_point<Clock,Duration>クラスには
Clock clock;
というメンバが存在するらしい。ゆえに、
decltype(date)::clock::to_time_t()は、
std::chrono::time_point<std::chrono::file_clock>::clock::to_time_t()
となり、clock=std::chrono::file_clock という意味になり、結局、
std::chrono::file_clock::to_time_t()
ということになるようだ。

2019/07/26(金) 17:00:25.26

>>140
file_clock は、仕様がまだ決まって無いらしい。

2019/07/26(金) 17:02:19.32

うん、俺もそう読んでる

auto sdat = time_point_cast<time_point<system_clock, system_clock::duration>>(date);
・・・これもうまくいかんなあ

2019/07/26(金) 17:20:06.81

autoやめるか、autoで得たものをTYPEIDに物故むか。
好きな方をえらぶのじゃ。

2019/07/26(金) 17:47:30.45

>>134-135
動的にコンテナサイズが変わるものは、遅くなる

それと、C++ でも仮想関数を使うと、関数のアドレスが静的に決まらないから、
その都度、計算するから、オーバーヘッドになる

2019/07/26(金) 20:50:40.59

void f(path&& pt)
{
auto date = last_write_time(pt);
using dt = typename decltype(date)::clock;
auto val = dt::to_time_t(date); //C2039
}

くっそー、もうAPI呼ぶしかねえのか

2019/07/27(土) 00:58:05.06

clock_castが実装されるまで待つしかなかろう

2019/07/27(土) 07:04:30.58

>>145
単純に
void f(path&& pt)
{
　auto　　date1 = last_write_time(pt);
　time_t　val1 = std::chrono::system_clock::to_time_t(date1);
}
とすればいいだけのような気がする。

2019/07/27(土) 07:52:56.55

C2664
残念。。。

2019/07/27(土) 08:21:00.74

>>148
https://code.woboq.org/llvm/libcxx/include/chrono.html
↑によれば、以下の様になっており、time_point は、一般的な
template の time_point<・・・>とsystem_clock::time_pointは
厳密には「別」で、後者は前者を特殊化したものを typedef宣言
している。そのため、 std::chrono::system_clock::to_time_t()の
(メンバ)関数宣言の
static time_t to_time_t(const time_point& t) noexcept;
のtime_pointは、chrono::time_point<system_clock>という
system_clock専用になっている。それが原因で>>147は
エラーを出すらしい。

class system_clock {
public:
　・・・
　 typedef chrono::time_point<system_clock> time_point;
　・・・
}

2019/07/27(土) 08:58:26.59

そう思ってtime_point_castしてみたんだが、それすら通らない。。。

2019/07/27(土) 09:20:37.82

>>150
time_point_cast() は根本的な「Clock」の部分は変換前後で共通の場合のみが
実装されているようです。なのでどこまでの細かい時間を表現できるかの
「時間精度」は変更できても、表現の違いのようなものまでは対応できないのかも
知れません：

namespace std {
namespace chrono {
template <class ToDuration, class Clock, class Duration>
time_point<Clock, ToDuration>
time_point_cast(const time_point<Clock, Duration>& t); // C++11

template <class ToDuration, class Clock, class Duration>
constexpr time_point<Clock, ToDuration>
time_point_cast(const time_point<Clock, Duration>& t); // C++14
}}

2019/08/16(金) 13:02:16.52

テンプレートとマクロのメリットデメリットって他にありますか？
またテンプレートとマクロの使い分けで悩んでいます

マクロのメリット
・一括置換ができる
・文字列も使用できる
・定数式にも使える（配列の要素数）

マクロのデメリット
・数式が複雑なときにミスをしやすい（＋＋を渡してはいけない、演算優先順位がミスしやすい）
・型の識別ができない
・一行記述なので大規模なのには不向き

テンプレートのメリット
・名前空間を定義できるので影響範囲をとどめやすい
・型の識別ができる
・関数なので大規模なのも書ける

テンプレートのデメリット
・定数式にしようできない
・ユーザー定義と標準定義が混ざったときのエラーを判別しにくい

こんなメリットデメリットだと思っています。
他にありますか？？

これを踏まえた上で使い分けとしては、
マクロは文字列などの簡単な定義に向いていて、テンプレートは処理（演算）を含むものと考えているのですが、
他に観点あるでしょうか

2019/08/16(金) 13:05:39.63

宿題は宿題スレで

2019/08/16(金) 13:11:19.36

マクロのデメリット
・スコープに従わない　←致命傷
・デバッガとの相性が極悪

2019/08/16(金) 13:12:45.69

>>152
「他にありますか？」の答えにはならないんだけど・・・

> テンプレートのデメリット
> ・定数式にしようできない

そんなことなくね？

> ・ユーザー定義と標準定義が混ざったときのエラーを判別しにくい

どういう状況のこと言ってるのかよくわからないけど、マクロにすればわかりやすくなる状況なのか
怪しい気がする。

ってことで、使い分けとしてはマクロでしかできないこと（トークン連結・文字列化）以外は
テンプレート使うとしたほうが簡単だと思うし、よく聞く話。

2019/08/16(金) 13:31:46.08

マクロはコンパイラが展開後のコードを見せてくれるけどテンプレートは見せてくれない

2019/08/16(金) 13:58:42.46

展開じゃないからな
typename Tに何が来ているかなんてのはcout << typeid(T).name()で監視できるんで
iocccなみに解読困難なプリプロセッサ出力がないからって困りゃせん

2019/08/29(木) 21:44:48.85

その無駄な監視についてなんも思わんてすごいね。

2019/08/29(木) 22:37:52.13

その監視というか確認の煩雑さは、マクロの方が面倒だろに。

2019/08/29(木) 23:08:09.91

>>152
マクロは、テンプレートのメタ側に位置する機能なので、テンプレートに出来ない事や、テンプレート自体のコードに変更を入れる場合につかうと良い。
まあ、リテラルレベルの置換と、プリプロセッサの入力に使えるってくらいかな。

よく使うのは、コンパイルスイッチくらいじゃないかな。
極稀にリテラルを文字列化したり、リテラルレベルでトークン連結処理したりするくらいかな。

定数はぶっちゃけどっちでも良いけど、式を含むならconstexpr を使うのが c++11の流儀。

2019/08/29(木) 23:40:06.16

>>159
こんなクソみたいな記述入れて一旦ビルドして確かめるとか正気の沙汰じゃねーわ。
cout << typeid(T).name()
マクロもたいがいダメだろうがこれをやらせるって歪んでるとしか思えん。

2019/08/30(金) 05:18:18.83

一旦ビルドしてって、テンプレートはコンパイルしないと何が来るかなんて分からんだろ
＞マクロもたいがいダメだろうが
とか雑な切り捨てしてる辺りからしても、めっちゃ初心者とみた

2019/08/30(金) 06:50:47.21

>>161
何がどうクソなんだ？
おまえさんのルールの何条に違反しているんだ？

2019/08/30(金) 08:57:04.22

>一旦ビルドしてって、テンプレートはコンパイルしないと何が来るかなんて分からんだろ
だからこれがしょうもないってことを言ってるんだが。
静的にコード見て判断しずらい仕組みをなぜ疑問なく使えるのか、そっちのがよっぽど素人感丸出しだよ。

2019/08/30(金) 11:57:51.85

へー、判断しづらいのかｗ

おまえさ、C++に向いてないよ
もうやめたら？

2019/08/30(金) 12:39:58.20

横からすまんが

cout << typeid(T).name()

はくそださいと思う

2019/08/30(金) 12:54:22.69

そもそも cout がダサいですし

2019/08/30(金) 13:01:52.10

宣言だけのテンプレートを使ってエラー吐かせてクラス名確認するのはわりとやる

2019/08/30(金) 16:22:43.35

ダサいと言っているその姿がダサいことにくらい気がつけよ
技術板で客観性を全く欠いた戯れ言ぬかしやがって

2019/08/30(金) 17:52:02.06

>>164
＞静的にコード見て判断しずらい仕組みをなぜ疑問なく使えるのか
これにはテンプレートも含むってこと？
それならまぁ言いたいことはわかる

2019/08/30(金) 20:08:16.72

>>161
言ってることは当たってる。C++は、というか、正確に言うと、C++のスレは歪んでる。

C++ってのは結局のところ、何でも出来るように設計されている。
だから、ユーザーがその機能を使うか使わないか、よくよく考えないと逆に色々面倒なことになる。
マクロもテンプレートも上手く使えば素晴らしいが、濫用すると余計に酷くなる。
○○を使えばいい、とか、逆に、○○は禁止、とか、（本来は）単純に切り分けられるものでもない。

この辺は他LL言語やJava/C#等は最初から使える範囲が決まっており、
C++から見ればかなり制限されているから、濫用は出来ない。
結果、「C++の酷いコード」よりは「C#の酷いコード」の方が数段ましなものにはなる。
逆に言えば、C++はプロ仕様で、
自身でコーディングルールをそれなりに決められる人じゃないと適切には使いこなせない。

実際の職場では大概はがんじがらめのルールが決められているはずで、
C++でコーディングルール無しのところなんてないのではないかと思う。
ところがC++のスレは勘違いした素人が多いのか、
C++の新しい文法や小手先テクニックを使って書くことが目的になっている奴が多い。
そして「長期的な保守」を全く考慮してないレスも散見される。
だからここではそういう雑音もきちんと峻別する能力が求められてしまう。
といってもそれもC++の範疇で、つまり「自分で判断しろ」でしかない。
無理ならC#等そういう「馬鹿が使ったらどうしようもなくなる機能」が最初から用意されてない言語を使え、でしかない。

ここで素人相手にマウント合戦なんて意味無いから止めとけ。
> 静的にコード見て判断しずらい仕組みをなぜ疑問なく使えるのか (>>164)
この基準は正しい。
テンプレートに問題があると認識されているのは昔からだ。
ただ、テンプレート以外に上手く同等のコードを得る方法がないから、それでもテンプレートは使われている。
いずれにしても、その機能をどこまで使うかは君が判定するしかない。
実際に動かさないと何が当たっているか分からないテンプレートなんて事実として糞だが、
それでもその方がましならそういう書き方をするときもあるだろう。
全体を見ず、個々の末端の事例でグダグダ言い争っても意味はない。

2019/08/30(金) 20:31:22.35

上っ面しか見てねえやつだな
長期的な保守性という要求から色んな仕様が発明されているのに
ついていけねえ低脳が被害者面しやがる

2019/08/30(金) 20:33:11.27

おまえらもういいから、ずーっとC++98使い続けてろよ
それで食っていける仕事があるなら俺たち別に非難しねえ
非難てのも変だけどな

2019/08/30(金) 21:07:28.93

中身のない長文書く奴はもれなくバカ

2019/08/30(金) 21:20:59.36

>>172
お前最低限メタプログラミングは出来てて言ってるんだよな？
stlとか新機能使ってるだけとか自分で人様に使われるライブラリ書いたことない、とかじゃないよな？

2019/08/30(金) 21:27:42.86

>>175
stlが新機能って・・・・おまえいつから更新停止してんだ？

2019/08/30(金) 21:28:58.36

stlを新機能とは書いてないんだが

2019/08/30(金) 21:29:35.34

いなして、それで？

2019/08/30(金) 21:31:02.26

>>175に答えろアホ

2019/08/30(金) 21:32:55.34

>>171
だいたい納得。
別にstl使うなとかそこまで無茶は言わんよ。
unique_ptr なんかも使っていくのは良いと思うし。
ただおれおれ糞テンプレートライブラリは使いたくねーわという話。

2019/08/30(金) 22:22:53.64

アンチテンプレート厨はenable_ifになぜ_tがあるのかとかわからんだろ

2019/08/30(金) 22:23:58.82

そこだけ泥縄で調べて何かぬかすんだろうけど
言ってることの全体的な薄っぺらさはどうにもならねえぜ

2019/08/30(金) 22:26:42.82

それもcoutデバッグして理解したん？

2019/08/30(金) 22:30:48.94

>>157, >>181は別人だと思ってたんだが違うのか

＞enable_ifになぜ_tがあるのか
別にアンチじゃないけどそれはある程度基礎が出来てる人には常識だとおも

2019/08/30(金) 22:59:01.01

>>180
まあそうなんだが、unique_ptrとstlで大体いけるならPython/Ruby/Java/C#で全く問題ないし、
それらを使う方が断然生産性が高い。
だから逆に、C++を使うのならそれなりの理由が必要で、
通常それは速度、つまりゴリゴリに手動チューニングしてでも最速を得たい、ということなのだが、
C++のスレは「ナマポは撲滅されるべき、今時スマポ使わないなんて話にならない」だから終わってる。
ナマポを混在させられることがC++のメリットだし、それを使わなければC++使う意味ないと思うが。

あと、C++が導入したのは「オブジェクト指向」と「テンプレート」だが、
オブジェクト指向の方はほぼ全部のメジャー言語に採用されたのに対し、
テンプレートの採用は皆無だろ。出来も推して知るべし。
生産性を追求するC#、安全性を追求するJavaからは要らない子扱いされてるのが現実だ。

個人的に思うのは、超最速を目指さない限りC++で全部組むのはナンセンスで、
GUI部分とかはPython等で楽に組んで、演算部分だけCのDLLを呼ぶのがいいと思う。
Cは大規模コードを組む為の仕組みがないので次第に大きくなってくるとなかなか厳しくなるが、
この方法だと各DLLは1k行程度で済むのでCでも問題になることはない。
なお手動チューニングするならCの方が楽だ。
C++はコンパイラが最適化する前提でテンプレートを重ねがけする事が常態化しており、
ソースコードからどんなオブジェクトコードが生成されるかが読みづらい。
といってもこれはCはあんまり最適化しないからであって、
糞コードであっても速いオブジェクトが出る可能性のあるC++の方が断然いいのも事実だが。
（Cは糞コードなら糞オブジェクトしか出ないが、C++はコンパイラでの最適化がかなり期待できる局面もある）

なお今から学ぶならRustもありだと思うぞ。
unique_ptr基本で組むようにデザインされている。（らしい）
問題はRustは本当に立ち上がるか微妙なことだが。
C++が悪い点は多々あるが、それらって結局、そういう書き方をしなければいいだけでしかなく、
結局のところこれがCもC++も(Rustが立ち上がったとしても）死にきらない理由でもある。

2019/08/31(土) 00:35:23.33

>enable_ifになぜ_tがあるのか
こういうのを知ってウキウキするのはよくわかるよw
https://www.fluentcpp.com/2018/05/18/make-sfinae-pretty-2-hidden-beauty-sfinae/

でもいらん機能を無理やり現場に持ち込んで他人に迷惑かけるのは筋違いだから。

2019/08/31(土) 07:35:53.29

典型的な老害だな

2019/08/31(土) 08:32:04.06

はいはい
テンプレート(もちろん自作の)バリバリのコード書いて
それがどれだけ開発効率に影響与えたか、コスト掛けた価値がどれだけあったか
客観的に言えるようになってからほざいてね

2019/08/31(土) 08:46:15.20

本末転倒もいいとこだな
いいか、最も肝心なことは何を実現したかと成果物の質だ
開発効率だのコストだのはその次に考えることで
そこに振り回されて本分を投げちゃいけねえ

2019/08/31(土) 08:59:51.31

都合のいい抜き出し方をするな
その成果物の質のために、どれだけの時間と労力を掛けて
それが質の向上に見合ったものかを客観的に見れるようになってから言えといってんの

2019/08/31(土) 09:07:43.53

別にテンプレート使うなって言ってんじゃないよ
使ってごちゃごちゃ作るからにはそれが本当に後々まで使える便利なもので、
ゆくゆくは長い開発期間を償却できるレベルなのかどうか、そこまで考えると、普通は判断は難しい
テンプレート使う奴が実力あるやつで、やめとけと言うのは老害とかそんなアホな話は有り得ない

2019/08/31(土) 09:07:54.38

経営者目線ならこっちは自営で
ニートのご高説は無用だ

2019/08/31(土) 09:12:10.39

ははは、自らの主張を引っ込めたな
そうなるしかないんだけどな

2019/08/31(土) 09:15:43.69

?俺>>184だよ
テンプレートバリバリ使ってコストのバランスに毎日悩んどるわ
ちな俺も自営、元は会社でチームでやってたが

2019/08/31(土) 09:53:34.66

>>189
アウトプットを最大化するために効率をあげるんだが

2019/08/31(土) 11:12:47.33

そういって腐ったテンプレートを残していった老害を何人も見てるからな。
下の世代がまた同じことを繰り返そうとしてたらそりゃ文句の一つも言っとかなきゃあかんだろ。

2019/08/31(土) 11:29:08.15

>176 みたいな文盲ってホントに居るんだな

2019/08/31(土) 12:05:29.37

今ここで為されている議論ももう何回目だ？だし、積極的に続ける意味はないと思うが。

そんなに気になるなら他人のコーディングルールを確認してみればいい。
例えばgoogleのテンプレートについての記述は以下。
https://ttsuki.github.io/styleguide/cppguide.ja.html#Template_metaprogramming
まあそうだよね、程度だが。

個人的にはリファクタの障害になるのが致命的だと感じる。
max_fやmax_iなんてやるのは馬鹿みたいではあるが、
しかし検索は簡単で、変更時の影響範囲も明確に分かる。
これはLinusも同じ事を言っている。

C++は若干コードに執着しすぎている。
泥臭くも書けるところを無理矢理綺麗にしようとして、余計に複雑になっている。
具体的に言うと、記述を１ヶ所に絞る為にテンプレートを3回重ねがけ、なんてのは割とある話で、
それなら数ヶ所ならベタで書いてしまって「同じ記述が○○にもあるから変更するときは注意しろ」と
コメントに書いてしまうというドベタな解決策も採れるわけだが、C++はこれをよしとしない。
(Cの場合はこの場合はマクロにしてしまって１ヶ所に纏めたりする。
これはこれで問題はあるが、それ以前に意識高い系C++erではマクロは禁止だし）

ただ現実的には、C++は上記「コメントで対応」「マクロで対応」「テンプレートで対応」のどれも出来る。
だからユーザーが適切に選べばいいだけであって、
より本質的な問題は、「こう書くべき、じゃないと認めない！」
みたいな意識高い系馬鹿がC++にも進出してきたことではある。
色々な書き方が無駄に出来てしまうC++は彼等にとってはそれなりに居心地がいいのかもしれない。
だからそういう馬鹿に流されず、「俺流のC++はこう」みたいなのが出来るのならそれでいいと思うが。

同じ話はconstや例外にもあって、それらも結局煮え切らない議論になってるだろ。
googleはconstは推奨、例外は禁止、のようであるが。
https://ttsuki.github.io/styleguide/cppguide.ja.html#Use_of_const
https://ttsuki.github.io/styleguide/cppguide.ja.html#Exceptions

2019/08/31(土) 12:15:18.43

googleの例外禁止は古いコードが例外対応していないため、改修が辛いと言う消極的理由だけどね

2019/08/31(土) 12:55:35.82

>>199
しかし例外が素性が悪いのも事実だろ。
そして現在のソフトウェア工学はこれに対する解をまだ提供できてない。

オブジェクト指向は各オブジェクトを基底側のクラスで抽象化して統一的に扱えるからいいのであって、
例外は基本的に派生クラスでの対処が必要だから全く馴染まない。
そしてこれがJavaで繰り返されてる
「例外でコケるの止めてくれない？」「えっと？握りつぶせばいいですか？」
の根元だろ。
かといってC流のエラー番号＆毎回いちいちチェック方式がいいというわけではないが。

C++流のオブジェクト指向はほぼ全てのメジャー言語に広まった。これは出来がいいからだ。
同様に、ラムダも出来がいいから最近採用されまくってる。
C++が当初これを持ってなかったのは結果的には単にC++が馬鹿だったからでしかない。
テンプレートも同様で、広まらないのは出来が悪いからでしかない。

例外がイマイチなのは、そもそも出来が悪いからだ。
そして本質的に、例外方式では非同期/ベクタ(SIMD)には対応できない。
同期で済むところを非同期で書かされるJavaScriptも相当ウザイが、
今後のプログラミングのトレンドが
マルチスレッドによる非同期やGPU活用の為のベクタライズ(SIMD)に進むとしたら、
今現在の『旧式』の例外をコードに含まないようにしておくことはかなり意味がある。
googleが過去にこだわっているだけだと見るのは勘違いだと思うよ。

まあいずれにしろ、C++は今後とも「全部入り、使うかどうかはおまえら次第」を目指すようではあるし、
そういう言語が一つくらいあってもいい。
だからこそ、各自でその機能をどこまで使うべきか考えないといけないし、
それを適切に出来ない人は、
誰かのコーディングルールに乗っかるか、C++を使うのを止めるかした方がいいと思うが。

2019/08/31(土) 16:18:43.52

またvoidくん暴れてるの？

2019/08/31(土) 17:59:23.48

>>194
おまえさ、そんなすぐ目先の損得に頭を占領されてんの？
同じ「コスト」って言葉を使ってるけど、なんか全然意味違いそうだな
５年１０年単位の長い波長を持つ金の津波をどう起こすかって話と
ずいぶんズレて聞こえるんだが

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