C++相談室 part137

2018/08/27(月) 16:02:00.94

次スレを立てる時は本文の1行目に以下を追加して下さい。
!extend:on:vvvvv:1000:512

C++に関する質問やら話題やらはこちらへどうぞ。
ただし質問の前にはFAQに一通り目を通してください。
IDE (VC++など)などの使い方の質問はその開発環境のスレにお願いします。

前スレ
C++相談室 part137
https://mevius.5ch.net/test/read.cgi/tech/1531558382/

このスレもよろしくね。
【初心者歓迎】C/C++室 Ver.103【環境依存OK】
https://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

2018/09/21(金) 19:18:19.30

他人が作ったクラスで勝手にいじれないんでしょ？
protectedやvirtualなメンバがあって、それを使って色々するなら当然継承すればいいけど
そうじゃない継承される前提で作られたクラスじゃないなら継承はオススメできんなあ
svd(m)をm.svd()って書きたいためだけに継承の山のようなトラップ抱え込むのは割に合わないと思うよ
どうせ親クラスのprivateはいじれないんだし

2018/09/21(金) 19:20:28.05

unified call syntax 甦れ。

2018/09/21(金) 19:24:14.64

>>591
使ってるのはuBLASだっけ？調べてないのでわからんけど・・・・
継承を前提にしたクラス（デストラクタがvirtualであり、実際継承してみても使える）なら継承もアリっちゃアリだとは思う
（責任は負わんｗ　あくまで勉強目的でやってみるのはいいと思う）

ただ、特異値分解は知らんのでわからんけど、一般に演算クラスの機能追加は
>>587の言う通り、単純にそのクラスを受け取るグローバル関数にする方がいい
特に
＞掛け算、足し算
こんなのはまさにメンバ関数にしなくても、グローバルに演算子オーバーロードを定義すれば済む
（メンバに書いてもグローバルに書いても利用者側はA * Bって書ける
あとv1.dot(v2)よりdot(v1, v2)のがわかりやすいと思うけどね

2018/09/21(金) 19:48:50.66

>>595
完全に同意。

2018/09/21(金) 19:58:47.83

>>592-596
なるほど。
普通に関数にするのが、必要十分さの面で、良さそうですね。

頭の中にあったのは、自分で作った関数群が全て○○というクラスに対して使用することを想定している、と明示したかったということです。
グローバル関数の用途を明らかにする方法として、メンバ関数化すれば良いのかな、と思いました。

メンバ関数にはしないということにした場合、上のことを実現するにはどうするべきでしょうか。
コメントやノートに書くくらいしか思い付きませんが、それで良いのかな

2018/09/21(金) 20:09:39.68

引数の型が○○やconst ○○&になるでしょ
それ以上のなにが欲しいの？

2018/09/21(金) 20:10:46.02

そういえばBLASとは書いてたけどuBLASとは書いてなかったな
いずれにしても、その扱いたいクラスを受け取る関数だから見たらわかるっしょ
違う型を渡したらエラーになる

2018/09/21(金) 20:12:28.34

>>597
どうでもいいけど最初と大分キャラ変わってるぞw

2018/09/21(金) 20:17:41.28

>>598-599
わかりました。
確かに型を見たら自明ですね。

結局は
> svd(m)をm.svd()って書きたいためだけ
だったのかも知れません。
なんせそういう書き方はいかにも「ぽい」ですから。

ありがとうございます。

2018/09/21(金) 20:19:42.40

>>601
横レスになるかもだけど多相的に関数の集合を規定したいなら[C++ traits]で検索すると幸せになれるよ
今回は不要だと思うけど後々欲しいなって思ったとき役に立つ

2018/09/21(金) 20:43:37.20

>>588
いや、風潮っていうのは確かにあるよ。
かつて上手くいかなかったから今もダメとは限らない。
テンプレートの活用が失敗っていうのは言語そのものとしてのサポートが不充分だったというのがあって、
それは >>602 がいうようにトレイトの活用の知見が蓄積してきたことで風向きが変わってきてる。

今はクソみたいな SFINAE と type_traits で不格好になんとかしてるのも
C++20 でコンセプトが入ったら C++ のパラダイムがそっちに一気に傾くと思う。
Rust や Go の隆盛でプロトコル指向への理解が深まっているというのもある。

2018/09/21(金) 21:06:19.19

・・・・・俺が何を批判したかわかってないな
「ダサい」とか「風潮」じゃなくて、何故それが好ましいか、好ましくないか、
質問者のケースに合った説明をしろっつってんの
なんで当時の「テンプレートで継承の代用」の例を出したかわからんか？
代用にはなり得ないんだよ原理的に
実行時のポリモーフィズムをテンプレートで実現できるのか？
ユーザーの入力やファイルの内容に従って実行時に作るオブジェクトを変え、かつ
それを１つの型でまとめられるのか？？
type erasure(boost::any含む)とかswitchとかif使う、とかは無しでな

自分の頭でその方法が合っているか合っていないか考えずに
流行とかに流された結果が、↑で挙げたソレなんだよ
C++潰したいのかよ

2018/09/21(金) 21:35:12.47

>>604
これも横からだが、C++はもう役割を終えて衰退機だと思う。
今から積極的にC++を採用する分野は限られていて、使えるor使おうと思うエンジニアの絶対数が減るってことは衰退と同義だと思う。
いろんな言語のエッセンスを学べるので悪い言語でないとは思うけど、誰かが言った通り習得のコストに見合ったメリットがない。
盛者必衰。

2018/09/21(金) 21:55:31.46

>>604
> 何故それが好ましいか、好ましくないか、
> 質問者のケースに合った説明をしろっつってんの

それは >>587 の説明で足りないか？
風潮があって、その理由は不要な複雑さが出来るからだという説明で足りないか？
この説明は質問者のケースに合致してないか？

> 代用にはなり得ないんだよ原理的に

違う機能が違う能力を持つのは当たり前だろ？説明するまでもなく。
どちらの機能を中心に活用した「設計」がよいのかっていう話じゃないか。

2018/09/21(金) 22:01:19.22

>>606
ああすまん、確かに言葉尻に反応したところはあったな
でも「風潮」とか「ダサい」って蛇足だよな？ｗ
ダサいって言いたかっただけやろ？

＞違う機能が違う能力を持つのは当たり前だろ？
お前>>603で
＞かつて上手くいかなかったから今もダメとは限らない。
＞テンプレートの活用が失敗っていうのは言語そのものとしてのサポートが不充分だったというのがあって、
テンプレートを盲信してるようだから説明したんだが。
継承をテンプレートで代用せよ、ってのは間違ってない、って言いたかったんだろ？

＞C++20 でコンセプトが入ったら C++ のパラダイムがそっちに一気に傾くと思う。
とか言ってる辺りからも、オブジェクト指向は過去のものだから継承も過去のものなんだぜ、とか
抜かしたかったのがわかる
マルチパラダイムの意味わかってる？

2018/09/21(金) 22:15:11.22

継承をテンプレートで置き換えるって失敗したというよりもすでに当たり前になっただけでは
むしろそっちはそっちで発展してるし、動的でなくてもいいケースは確かに存在している

2018/09/21(金) 22:20:50.92

>>608
静的に解決できるものならそうだろうな
そういうケースを否定はしてないが、当時はあちこちでそういう失敗例がドヤ顔で披露されてたんだぞ
禿も指摘してるようにJavaのせいだが

2018/09/21(金) 22:46:33.24

>>607
> 継承をテンプレートで代用せよ、ってのは間違ってない、って言いたかったんだろ？

違うものは違う。代用品ではない。

継承構造の代用品としてテンプレートを使えというのではなく、
テンプレートも前提のひとつとしたデザインにしろと言ってんの。

「なにもかもをメンバ関数にするな」というのは全て非メンバ関数にしろっていう意味じゃないだろ。

2018/09/21(金) 23:01:04.77

>>610
>>603で
＞かつて上手くいかなかったから今もダメとは限らない。
＞テンプレートの活用が失敗っていうのは言語そのものとしてのサポートが不充分だったというのがあって、
＞それは >>602 がいうようにトレイトの活用の知見が蓄積してきたことで風向きが変わってきてる。
って言ってるよな
「かつて上手くいかなかった」って、
俺の「かつてC++の継承は汚いからテンプレートで代用しろ、みたいな理屈があったが全くの空回りに終わった」
のことだろ？言い逃れしてんじゃねーよ

ちなみに継承をテンプレートで代用、を挙げたのは、それに初心者が惑わされたからだ
ただのテクニックの紹介ではなく「C++の継承は汚い」みたいな暴言を伴ってな
お前が「ダサい」とか「風潮」とか、自分がドヤりたいがために選ぶ言葉と同じだよ

＞「なにもかもをメンバ関数にするな」というのは全て非メンバ関数にしろっていう意味じゃないだろ。
質問者の「関数追加」の方法についてはお前の意見に賛同してるだろうが

2018/09/21(金) 23:02:28.75

質問者を放置してドヤ顔で語るオタクたち

2018/09/21(金) 23:10:39.91

あ、ついでに言うと
＞言語そのものとしてのサポートが不充分だった
ねーよ

C++98～03でも十分メタプログラミング出来てたぞ（11から確かに幅は広がったが
STLしかりModern C++ Designの著者のLokiしかり
Boostだって当時からあったからな

2018/09/21(金) 23:26:46.84

>>605
C++に挫折でもしたの？ w
ネイティブコード吐けるオブジェクト指向言語ってそんなに選択肢ないし

2018/09/21(金) 23:30:11.36

FixedC++であるRustに期待はしているが・・・。

2018/09/21(金) 23:41:33.16

>>611
なんでその結論に納得できるのに前提に色々言ってんだ？

テンプレートについてはそっちが言い始めたことで、別の話題だろ？
代用という言葉の使い方がちょっとずれてるだけじゃないの。
そのまま置き換えれるかという意味では代用できないし、
継承でなんとかしてたデザインをテンプレートを活用したデザインに置き換えられる (こともある)
という意味では代用ともいえる。

言葉については、「ダサい」はともかく、「風潮」に何か問題あるか？それは全くわからんな。
デザインの風潮というものは間違いなくある。

2018/09/22(土) 00:00:10.67

>>613
無理無理。
今だってろくでもない回りくどい仕組みでどうにかこうにか
型の制約を表現できてるってだけだもの。
初心者にそれを元にデザインさせるのは無理。

型の制約についての知見とは別に C++ の言語機能が足りてない。

2018/09/22(土) 00:04:20.29

＞テンプレートについてはそっちが言い始めたことで
ダサいとかイケてるとか風潮とかで設計を語るからだよ
お前の説明はだいぶ甘い、自分でよくわかってないものを押し付けてないか？
そういう傾向を指摘されたって気づいてるだろ？
自分のコーディングの経験が足りてないゆえに、はっきり断言できないから風潮とか出てくるんだろ？
さっさと謝ってりゃここまで言ってないんだがな

＞デザインの風潮というものは間違いなくある。
そう思ってんのはお前らアマチュアだけだから。（特にお前の思ってるようなデザインについては）

>>617
何の話してんの？コンセプト？ｗ
なんで初心者がまだ導入されてないコンセプト前提の設計しなきゃならないの？馬鹿なの？
コンセプト入ったら実行時のポリモーフィズムをテンプレートで出来るの？？？？ｗｗｗｗｗｗ

2018/09/22(土) 00:11:49.56

最初はもてはやされたけど、みんな知ってる前提になったら特に触れられもしなくなった
風潮ってこいうのだろw

2018/09/22(土) 00:12:42.81

すまんちょっと熱くなりすぎた
論破されたことに気付かないアホ（あるいは謝ったら死ぬ病）相手にするとキリが無いわ・・・・
もうやめとく

2018/09/22(土) 01:40:05.82

権限の委譲というと良いものを与えているイメージだが
UML用語の委譲はどうみても仕事の丸投げとかたらい回しな印象であるイメージ
な気がする

**572** (ﾜｯﾁｮｲ 42bd-LgAV) · 2018/09/22(土) 02:14:06.30

昨日のプログラムを改良したったｗｗｗｗｗ
ttps://ideone.com/hkeEp0

データ数N=300のときCore i7-860 (2.8 GHz)で8秒かかる。idoneのやつでも5秒。
N=1000だと宇宙の終わりまでかかる予定。

これで漏れも低学歴知恵遅れに晴れて仲間入りDA☆NE！

2018/09/22(土) 03:45:26.27

https://ideone.com/CYkJfe
高速化する話なのか低速化する話なのかは分からんけど、素直に書いたらこんな感じかなぁとか。
終わった話題かもしれんけど。

どうしても高速化したいんやったら、関数を並列実行できるようにして、
https://cpprefjp.github.io/reference/thread/thread/hardware_concurrency.html
上記の数で分割実行かなぁとか。
フューチャー投げるのはそんなに難しくないと思う。std::async使えば簡単だし。

2018/09/22(土) 03:54:48.35

気が付いたら、absがテンプレート関数じゃなくなってた。

2018/09/22(土) 07:17:07.67

constexprな関数はコンパイル時でも実行時でも使えるが、定数になる文脈とならない文脈で関数を使い分けしたい。そういう使い分けは可能だろうか？

例えばsqrt関数はconstexprになっていないが、
アルゴリズム的には自作関数でconstexpr対応可能

ただし速度的にはcmathのsqrtの方が何倍も早いのでconstexprでない文脈の時にはcmathのsqrtを呼び出したいのです。

2018/09/22(土) 07:58:27.87

is_constexprで検索したらそれっぽいアイデアは出てくるけど

2018/09/22(土) 09:39:59.40

>>625
ビルド過程を見直せば？
バカみたいに何でもかんでもconstexprに頼る理由はない。

2018/09/22(土) 12:24:16.36

>>618
なんで実行時ポリモーフィズムの話なんか出てるんだ？
出来ないもんをやれなんて言ってないだろ。
関係ない要素をどんどん出してくるなよ。

何を言いたいんだ？

2018/09/22(土) 13:05:08.82

templateで躓いてるんですけど皆どうやってテンプレートを勉強したんですか？

2018/09/22(土) 13:06:49.63

車輪の再発明

2018/09/22(土) 13:16:51.91

何を悩んでる？

2018/09/22(土) 13:22:32.93

>>631
Boostのテンプレートを読んでるのですが、理解できない点です

2018/09/22(土) 13:36:27.52

>>632
まずはstlは一通り不自由なく使えるかな？

2018/09/22(土) 13:45:08.87

>>633
はい、STLに関してはそれなりに使えます

2018/09/22(土) 13:53:36.62

>>632
Boost はかなり技巧的で無理やりなこともやるので、
ある程度 C++ をわかっている人でもまともに読めないこともある。

普通に入門書とかを読むところから始めるしかないんじゃね？

2018/09/22(土) 15:05:35.09

boost読んでテンプレート勉強しようとするのは、IOCCCでCを勉強しようとするのと同じくらい無謀

2018/09/22(土) 23:16:14.20

test

2018/09/22(土) 23:16:57.30

アホ

2018/09/23(日) 00:42:54.42

boostのｲﾝﾁｷくさそうなｿｹｯﾄ通信とか使ってるﾔﾂいんの
普通にsocket通信の関数で書いたほうが可読性が高そうで困る

2018/09/23(日) 01:28:26.89

SG4に標準化提案はされてるみたいね

2018/09/23(日) 03:10:01.78

>>639
Boost のことはよう知らんけど、
Boost の他のライブラリと組み合わせやすいとか、
そういう利点はないの？

2018/09/23(日) 09:37:53.48

bool operator<(const T& a, const T& b)は定義されている前提で、
クラスTについてbool operator==(const T& a, const T& b)が定義されていたらそのoperator==()を使い、
定義されていなかったら
　bool operator==(const T& a, const T& b) { return (!operator(a, b) && !operator(b, a)); }
を勝手に補完するようなテンプレート（の特殊化？）ってどうやって書くの？

2018/09/23(日) 11:39:09.69

std::rel_ops空間に == から != を、< から <= > >= を合成するテンプレートならあるけど

2018/09/23(日) 12:14:54.07

これとかに載ってなかったっけ？
https://www.amazon.co.jp/dp/4894714353/?tag=hatena_st1-22&;ascsubtag=d-7dzm

2018/09/23(日) 14:13:03.08

detection idiomで検出してSFINAEで分岐させるだけでできそうだけど

2018/09/23(日) 14:26:07.42

barton nackman trickやな
operator ==が定義されているかどうかの分岐はSFINAEいるんでちょっと複雑になりそうだけど
private継承する基底を選ぶような形にできるはず

2018/09/23(日) 16:41:12.46

そんなことができるざんすか。
めんどくさそうですな。

2018/09/23(日) 16:42:46.60

if constexprつかえばSFINAEいらんな
普段使えない環境だから出てこなかった・・・

2018/09/23(日) 17:06:46.21

スフィ姉たまんねぇ

ていうか>>643見てnamespace rel_opsの定義見て考えたがSFINAE要らなくね？
コンパイラの挙動（関数名の解決規則？）として、
Tについてoperator==(const T& a, const T& b)そのものズバリが定義されていればそれが使われるし、
無ければその次以降にテンプレートを探しに行こうとするから、
そのときstd::rel_ops名前空間が導入されていれば勝手にテンプレートバージョンが使われる
というしくみっぽい？

2018/09/23(日) 17:18:52.49

>>632
バリバリのテンプレート使いいませんか？
テンプレート難し

2018/09/23(日) 17:45:10.35

>>649
あーたしかに
試してみたらいけた

2018/09/23(日) 17:58:10.59

>>648
if constexprほとんど使ったことなかったけど便利だなー
確かに型で分岐する必要なかった
https://wandbox.org/permlink/8CGWlZ5i5JLl33Ws

>>649
その方法だと、>>642で言ってるような特殊な補完を他のクラスにも適用することにならん？
それでもいいならいいけど

2018/09/23(日) 19:13:07.53

>>650
わかんないなら質問すればいいじゃん
何がわからないから分からないと本とかのおススメもできないだろ

2018/09/23(日) 21:04:04.43

>>652
>その方法だと、>>642で言ってるような特殊な補完を他のクラスにも適用することにならん？
ならない。ならずに済ませられることができる
補完する演算子のテンプレートの導入範囲を名前空間で限定すればおk↓↓↓
ttps://ideone.com/p4FS43

21行目のOP_EQ_FOO_ENを定義してもしなくてもビルドが通り、Foo::operator==()の呼び出し回数を除き同じ結果になる。

ただし、operator==()についてはちょっぴり闇が深いことがわかった。
名前空間std::rel_opsにはoperator==()テンプレートが存在しない
上のサンプルではstd::rel_ops名前空間に無理矢理operator==()テンプレートを追加したが、
実際にやるときは独自の名前空間でoperator<()以外の全部（==、!=、>、<=、>=）を用意しておくことになるん
ｼﾞｬﾏｲｶ

2018/09/23(日) 21:30:04.73

あーすまん、目的を誤解してた
クラスのoperator ==の実装を省きたいんじゃなくて使う側で補完できればいいのか

2018/09/24(月) 00:24:52.05

5年くらい前？にテンプレートプログラミングっぽい趣旨の本があったし、基本情報に何故かPrologと同じジャンルにテンプレートが言語として載ってる辺り論理型言語っぽい事ができるみたいだが、基本C++の1機能でしか無いから、知ってる人は少ないんじゃ無い？

俺も知らない。

2018/09/24(月) 00:56:28.11

C++テンプレートテクニック第2版、
επιστημη(えぴすてーめー)・高橋晶、2014

C++ 標準化委員のεπιστημη の本だろ。

ドワンゴ江添亮も、需要があれば、こういう本を書きたいって言ってたけど

2018/09/24(月) 01:06:54.52

それそれ。
出来るっぽいってのは知ってても、実際できてる奴少ないと思われ。

2018/09/24(月) 01:14:19.28

ﾃﾝﾌﾟﾚｰﾄ使うのに
いちいちそんな悩むもんなんか

なにかを参考にしたいようだが
たとえばtraits乱用してるようなのは読む必要もないし
逆にﾏﾈする必要がないわ

2018/09/24(月) 01:21:07.01

俺も気にした事ないけど、気になる奴は気になるんだろう。

俺の場合は整数型をどうやって文字列型にしてるんだ？ってのが疑問でむしろアセンブラに走って頭捻って理解した。

まあ人間そんなもん。

2018/09/24(月) 01:37:53.34

テンプレートはC++の必須教養だと思ってるけど、別になくても困らないしな・・・

2018/09/24(月) 01:47:51.69

>>661
つ vc++ 1.x
こいつのテンプレートは泣ける

2018/09/24(月) 01:54:17.59

>>656->>661
同感

はちみつと言い争ったときに
＞＞デザインの風潮というものは間違いなくある。
＞そう思ってんのはお前らアマチュアだけだから。（特にお前の思ってるようなデザインについては）
とか書いたけど
実践ではなく仕様メインで覚えてる人（趣味でC++の知識を集めるのがメインの人であり、アマチュア）は
「これからの時代はテンプレート使った総称的プログラミングが主流」
みたいなパラダイムの変化を訴えてるけど、それはっきり言って素人が見れるコードでだけだから・・・
（C++標準ライブラリやBoost等）
テンプレート使ってとことん汎用性を高めたライブラリなんか、普通のソフト開発の現場では使われんわ
あまりにも時間がかかりすぎる
そういうごくごく一部の偏ったソースしか読んだことないから誤解するんだろう
で、その誤解した趣味グラマのネット上の言説やライターが書いた本を読んで、
初心者がC++に挫折して去っていくという・・・・・
C++なんか最初はベターCでいいんだよはっきり言って
あと最近ネット見てて（C++の）オブジェクト指向とかC時代の古いノウハウの解説が少ないのは、
単にとっくに出尽くしたからだからな、最近始めたやつは誤解したらだめよ

2018/09/24(月) 02:00:05.34

訂正
Ｘテンプレート使ってとことん汎用性を高めたライブラリなんか
○テンプレート使ってとことん汎用性を高める開発手法なんか

2018/09/24(月) 02:14:19.64

>>663
「何もかもを継承構造で解決しようとするな」の
ひとつとしてテンプレート (を C++ なら利用することになるプロトコル指向的デザイン) が出たんだし、
C++ にコンセプトの概念を持ち込もうとする機運があるほどには活用比率も高まるだろう、という程度の主張なのに、
「とことん汎用性を持たせるべき」とか「主流になる」みたいな拡大解釈はやめてくれよ。
俺はそんなこと主張してないからね！

2018/09/24(月) 02:32:05.77

>>665
しつこいぞ
＞テンプレートの活用が失敗っていうのは言語そのものとしてのサポートが不充分だったというのがあって
「おかしな流行が発生して初心者を惑わした」、に対して反論したんだろ？嘘つくなよ

＞俺はそんなこと主張してないからね！
主流になる、って意味だろ？これ↓
＞C++20 でコンセプトが入ったら C++ のパラダイムがそっちに一気に傾くと思う。

ちなみに
＞コンセプトの概念を持ち込もうとする機運
コンセプトは標準化委員会や禿が言い出したことだぞ
導入されたら素晴らしいとは思うが、元々はテンプレートを使ったコードのエラーメッセージをどうにかすることと
テンプレートパラメータで満たすべき要件をコメントではなくコードで示せるようにすることだ
プロトコル指向は聞いたことないが、それはコンセプトで可能になるおまけ程度だろ
しかもそれを利用するにはテンプレート必須なわけで、コンセプトが入ろうが、
クラスなどが実際どういう仕組みなのか程度のことは把握してないと、初心者が手を出せるようなものではないし
出させるべきでもない

2018/09/24(月) 02:45:26.39

>>666
変な (教え方なり使い方なりが下手くそな) 流行があったということを以て
テンプレートの活用を全否定するような言い分に反論したんだよ。
テンプレートが無くて良いと思ってるわけじゃないんだろ？

> 主流になる、って意味だろ？
今までが継承構造に頼りすぎだったのが是正されるという意味だ。

初心者への教え方については、また別の話。
ベターCからで良いという意味のことは D&E にも書かれてる基礎理念だから
そこは疑ってない。

2018/09/24(月) 02:59:37.96

＞テンプレートの活用を全否定するような言い分に反論したんだよ。
>>587と>>588を100回読み直せボケが
悪いけど、お前まともにメタプログラミングやってないだろ？
まともに活用して利点・欠点をはっきりわかってないやつが何偉そうに語ってんの？
しかもその理由で反論したんなら、なおさらポリモーフィズムの話で論破されただろ、
なんで認めずに自分の主張の意味を途中から変えてまで言い返してんの？
図星突かれて気分が悪いってか？

＞今までが継承構造に頼りすぎだったのが是正される
誰が頼りすぎてたの？？今までっていつまで？

＞初心者への教え方については、また別の話
今まで何度も「こいつ初心者にテンプレート勧めてるよ・・・・何考えてんだ」と思ってたんですが
どの口で言ってんだ

2018/09/24(月) 03:17:34.86

>>668
ポリモーフィズムの話ってなんだ？

初心者へじゃなくて、
君に、テンプレートの話はしてたつもりだが。
(ID 変わってるから他の人だったらスマソ)
他の人にアンカーを付けてテンプレートの話はしてないだろう。

2018/09/24(月) 03:38:10.37

>>668
> 誰が頼りすぎてたの？？

標準ライブラリすら。
その他はまあ、私の実感なので、違うというなら違うのかもしれない。

2018/09/24(月) 03:48:16.31

「美味しんぼには我慢ならん」
「おい、辛抱しろ」

2018/09/24(月) 03:48:58.75

誤爆した。ごめん。

2018/09/24(月) 09:51:46.55

本当にテンプレートが必要なものってだいたいSTLに揃ってる印象。
あとはTBBみたいにある程度低いレイヤーの抽象化ではどうしても必要にはなる。
しかしこの種類のライブラリってのは本当に信用できる奴が作ったもの以外は
使いたくねーんだわ。
めちゃくちゃデバッグコスト高いからね。
そういう意味で一般プログラマーが実装するってのは実践的ではない。

2018/09/24(月) 10:18:16.36

テンプレートは型の定義をすり替えるために使うもの
#ifdefで型切り替える方がもっと糞だからそこはテンプレートにするべき
それ以上の凝った事はしないほうがいいね

2018/09/24(月) 11:22:17.38

頼りすぎつーか逆だと思うぜ
コンテナの要件なんかインターフェイスにすればすっきりするのに
紙マニュアル（pdf含む）でガタガタ書かれた口約束とかすげーイヤ
歴史的に見てもそれをやるのに充分な言語機能がもうあったのに

2018/09/24(月) 11:36:08.69

>>675
現状の C++ では型の制約を表すには意味不明な SFINAE で回りくどくやってて
初心者には使いこなせない (中級者でも不安があったり面倒だったりする)
という話の文脈だから、言語機能が充分だというのはちょっと変な立場だ。

2018/09/24(月) 11:43:09.69

どうーがんばっても停止性問題は機械的に解けないケースを無くせないのだから
プログラミング自体をアルゴリズム化する企てはどこかで行き詰る
藻前らは行き詰まりかたの良し悪しを議論しているにすぎないのだｶﾞﾊﾊﾊﾊﾊﾊ

2018/09/24(月) 11:47:19.43

>>675-676
ひょっとして抽象クラスでやったらいいという話だろうか。
Java とかから来た人はそういうことをやりがちだけど、 C++ の設計理念からすると、
少なくとも標準ライブラリでは仮想関数テーブルを辿る実行コストを許容はしないだろうと思う。

2018/09/24(月) 12:24:10.58

>>678
動的結合のコストは関数ポインタなみにはっきりしてるだろ

2018/09/24(月) 12:28:24.97

インターフェース（＝データメンバーなし抽象クラス）は静的な型の制約を表現できないからダメ

2018/09/24(月) 12:58:55.73

>>678
＞C++ の設計理念からすると、
＞少なくとも標準ライブラリでは仮想関数テーブルを辿る実行コストを許容はしないだろうと思う
滅茶苦茶言うな
https://cpplover.blogspot.com/2015/09/memoryresource.html

>>673
ついでに開発コストも高い
STLが優れてるのは、作者が長年コンテナについて熟考に熟考を重ねたライブラリだからであって
それを実現するためにテンプレートが使われたに過ぎない
テンプレート使ってりゃなんでも有用なライブラリになると勘違いしてるアホが増えた

2018/09/24(月) 13:04:35.46

テンプレートは即席麺的な発想でライブラリのような寝かして熟成させるワイン的な使い方には向いていない

2018/09/24(月) 13:10:53.22

インターフェースはあらゆるメソッドを最初から詰め込まねばならないからｲﾔｿ（特に単一継承の場合
お禿様も自著でそういう傾向（あらゆるメソッドが基底クラスに集中する傾向があることをこっそりカミングアウトしていたはず
テンプレートにはそういう制約がない
型引数Tにadd()メソッドがあるものとしてテンプレートを書いたら、add()メソッドがある既存クラス全部にそのテンプレートが使える
というわけで、インターフェースはそれ自体静的な型の制約のつもりなのかもしれんが、
真にかけたい制約（上の例でいうとadd()メソッドの存在だけを問題にしたいケース）に対して不必要に過剰になることが多いｷﾓｽ

あとインターフェースだとコンテナの実現は具体的にはどうするんじゃ…
仮想関数テーブル参照の実行時コストだけでも許容し難いのに、間接参照がさらに必要になるんじゃ…

2018/09/24(月) 13:22:48.05

インターフェイスを単一継承前提で考えるって、どんな教育を受けるとそうなるのかな
numeric_limits<uintmax_t>::max()歩譲って単一継承ってことにしても
最初から全部詰め込みなんてハメにはあまりならないし

あらゆるメソッドが基底クラスに集中するなんて事例あるか？
俺は空想論だと断言するぞ
Smalltalkのobjectみたいなクラスに何が置けるんだよ

あと、なんか仮想テーブルのコストが云々いってるやつが複数いるようだが
具体的にどのくらいか、せめてオーダーくらいわかっているのか

2018/09/24(月) 13:35:23.36

オーダーの問題じゃなくて、C++にはゼロオーバーヘッドの原則があるんだから
ゼロオーバーヘッドに出来るものはゼロオーバーヘッドにするんだよ、標準はその手本なんだから

それにオーダーなんか処理内容でなんぼでも変わるだろ
せいぜい数十万要素のコンテナしか使わないプログラムだから仮想テーブルなんかどうでもいいと主張する奴の言うことは正しいかもしれないが
数兆個の要素を扱う人にはそんなもの慰めにならん

2018/09/24(月) 13:56:47.91

>>684
>インターフェイスを単一継承前提で考えるって、どんな教育を受けるとそうなるのかな
型に対する静的制約を実現するにあたり、多重継承は助けにならないからですだが…

>あらゆるメソッドが基底クラスに集中するなんて事例あるか？
上とまとめて理由を述べる
今、add()メソッドを備えるインターフェースA、sub()メソッドを備えるインターフェースBがあったとして、
加減算ができる具象クラスDやEは、それぞれAとBを多重継承したら一応はできる　・・・(1)
しかし、このバージョンのDやEは「加減算ができるクラス」という静的制約を満たしているとは言えない
なぜなら、DとEは全く別のクラス扱いになるから、DとEを共通に扱える関数を書けないので…
「加減算ができるクラス」という制約の正しい書き方は、AとBを継承するインターフェースCを定義して、
DやEにCを継承させる（単一継承）とらざるおえない　・・・(2)

なおいうまでもないことだがテンプレートにはそんな制限は無い。(1)のバージョンのD、Eに対して
問題なく「加減算ができるクラス」という制約をかけられる（Cにメソッドを集中させる必要が一切ナッシング

2018/09/24(月) 14:02:13.87

ていうか最後の2行で筆が滑ったorz
テンプレートで「加減算ができるクラス」という制約をかけるにはインターフェースA、Bもそもそも要らん
ｽｹﾞｰ便利

2018/09/24(月) 14:25:40.72

templateはダックタイピングだとおもう

2018/09/24(月) 15:09:08.71

どう説明したもんかと思ったけど、 >>683 の説明が分かりやすいな。
(Java でいうところの) インターフェイスは型の性質を事前に網羅しなきゃ
全体のデザインが定まらない。

関数が要求する性質 (インターフェイス) が増えた時に元の定義をいじるか、
mixin のような形で継承関係を作ることになる。
ちょっと機能を増やすだけでいらん継承関係を作るのは良くないという話の延長線上で
考えればインターフェイスを使ったところであまり解決にならない。

型制約 (コンセプト) は関数の側に付加するものなので、後付けが簡単だ。
結果的に型の側はその性質を持たなきゃならないことにはかわりないが、
性質を追加するのに元のクラス定義を弄らなくて済む。

-----------

最初の設計がキッチリしてたら、
クラス指向的なスタイルの方が混乱が少なくて良いかもしれないなと思い始めてきた。

でも、現実にはそうではない後付けだらけじゃん？とも思ってるわけ。

2018/09/24(月) 15:15:20.89

>>686
型に対する性的制約って何？
それと事例あるか？と聞いている質問に何で長文がいるんだよ
具体的なライブラリとクラス名を挙げるだけだろうが
なるべく知名度の高い事例ほど説得力があるぞ

2018/09/24(月) 15:32:49.32

>>689
コンセプトを盲信しすぎだろ
あくまで要件をコードで示せるだけだっての

それこそSTLには必ず導入されるべきものだけど、そのSTLでの不満、
つまりInputIteratorだのなんだのの要件をいちいちリファレンス参照しないとわからなかった(>>675)から
必要とされたわけで

はちみつとかは多分STLべったりで、それ以外のライブラリを読んだり
まともにソフト書いたことないから、STLがほとんど出てこない状況ってのを経験してないんだろ

＞ちょっと機能を増やすだけでいらん継承関係を作るのは良くないという話の延長線上で考えれば
話を広げすぎ。
型の制約という意味でいえば、現状コンセプトを待つしかないが
多分>>684が言ってるのは、Modern C++ Designで言うところのポリシークラスみたいな話じゃね？（違うかもしれんけど
この場合はあくまで要件定義なので当てはまらないと思うけど、
＞いらん継承関係を作るのは良くない
これは暴言。Andrei Alexandrescuに言ってくれば？
ポリシークラスのような、継承によって機能を取り込む設計も非常に便利だし、それこそSTLでもあちこちで使われてるんだがｗｗ

あと後半チラ裏にも程がある。何様だよ

2018/09/24(月) 15:33:05.07

Container<T>のbegin()が返すのはIterator<T>だとか
Matrix<M,N>とVector<K>はN==Kのときだけ掛け算できて結果はVector<M>だとか
Converter<V,W>とQueue<X>とProcessor<Y,Z>を持ってたらWとXとYはコンパチブルじゃなきゃいけないとか
そういうのが型の静的制約