C++相談室 part145

**デフォルトの名無しさん** · 2019/09/13(金) 17:13:24.60

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

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

このスレもよろしくね。
【初心者歓迎】C/C++室 Ver.105【環境依存OK】
https://mevius.5ch.net/test/read.cgi/tech/1556142878/

■長いソースを貼るときはここへ。■
　http://codepad.org/
　https://ideone.com/

[C++ FAQ]
https://isocpp.org/wiki/faq/
http://www.bohyoh.com/CandCPP/FAQ/ (日本語)

----- テンプレここまで -----

**デフォルトの名無しさん** · 2019/09/29(日) 10:02:14.52

>>192
そのくらいのプログラムでは名前空間は使わない方がいい。
使うべきなのはクラス。

**デフォルトの名無しさん** · 2019/09/29(日) 10:24:44.95

いや同じ識別子を違う意味で使いたいのなら名前空間だ
名前をどうかしたいというだけでクラス化するといらん制限がかかって邪魔なだけ

**デフォルトの名無しさん** · 2019/09/29(日) 10:27:55.39

>>192
その例では明らかにグローバル変数を使う必要はない。
「最小費用流を解くクラス」のメンバに押し込めるのが普通だと思われる。

**デフォルトの名無しさん** · 2019/09/29(日) 12:21:02.27

名前空間は一連の処理や機能をライブラリとしてまとめるときに他のライブラリと名前衝突しないようにするためのものだ
minとmaxの違いだけなら名前空間分けずに変数名や関数名に直接反映させればいいのでは

**デフォルトの名無しさん** · 2019/09/29(日) 15:27:39.30

>>197
個人的には自分もそう理解しています。
自分が作るプログラムでは namespace は基本的に使う必要はほぼ
有りません。古い時代に既に作ってしまったプログラムで名前が衝突して
困るような場合に使うと便利な機能として登場したのではないかと思っています。

**デフォルトの名無しさん** · 2019/09/29(日) 15:31:08.94

せっかくの回避策をマクロでばっちり透過してくれた素敵なマイクロソフトｗ

**デフォルトの名無しさん** · 2019/09/29(日) 16:03:17.31

>>198
昔作ったものに対してだけでなく、いま作ったものが将来使うときに名前の衝突を回避するという目的もあるぞ。

**デフォルトの名無しさん** · 2019/09/29(日) 16:52:41.21

なぜ日本人c++プログラマの99%はstd::vectorもstd::find_ifも見たことすらないのだろう。
c言語風の生ポインタ、生配列、if文、for文のみを使ったプログラムしか読めない。
外国の人でそういう人は見たことがない。

**デフォルトの名無しさん** · 2019/09/29(日) 17:03:09.76

99%は盛り過ぎでは・・・

**デフォルトの名無しさん** · 2019/09/29(日) 17:06:09.85

>>201
ワイド文字知らん人見たことあるわ

**デフォルトの名無しさん** · 2019/09/29(日) 17:28:35.45

体感で8割ぐらいかな
まず規格があって改訂されてるってことも知らないのもいる

これは他の言語にも言えることだが
職場で使ったことのあるJavaやPHPのバージョンと環境がすべてみたいな

**デフォルトの名無しさん** · 2019/09/29(日) 17:37:04.15

>>201
おまえ豚小屋にでも住んでるのか？ｗ

**デフォルトの名無しさん** · 2019/09/29(日) 17:38:36.19

C++20に入るauto変数を使った簡易関数テンプレートは宣言と実装を分割してコンパイルできますか？

**デフォルトの名無しさん** · 2019/09/29(日) 18:02:01.75

全部ヘッダーファイルに書いてしまえ

**デフォルトの名無しさん** · 2019/09/29(日) 18:13:05.80

vector知らんのはいたとしても組み込みマンくらいだろ

**デフォルトの名無しさん** · 2019/09/29(日) 19:02:41.77

>>206
多分戻り値型と同じで、1つの翻訳単位内ならできると思う
宣言だけヘッダに書いたりするとautoのままだと呼び出せない

**デフォルトの名無しさん** · 2019/09/29(日) 19:46:49.92

>>208
組み込みマンはC言語だろ
C++使っててstd::vector知らないのは流石に勉強不足

**デフォルトの名無しさん** · 2019/09/29(日) 19:56:43.66

>>209
ありがとう
やっぱだめか

**デフォルトの名無しさん** · 2019/09/29(日) 21:36:43.15

>>210
組み込みマンだからprinf知りませんみたいなもんだなｗ

**デフォルトの名無しさん** · 2019/09/29(日) 21:44:06.01

vectorの存在は知っていても中身は知らんやつばっかだろ
いまだに生配列の方が速いとか言ってるやついるし

**デフォルトの名無しさん** · 2019/09/29(日) 21:51:00.97

まあ実際計ってる奴はそんなにはいないわな。
てきとうな演算するくらいなら配列だろうとvectorだろうとほとんど変わらん
(ただしコンパイルオプションによる。
O2 ならそんな変わらんが最適化しないとvectorは本当に遅い。)

**デフォルトの名無しさん** · 2019/09/29(日) 21:57:52.25

まあ最適化有効にすれば、すればそこいらの玄人が生配列でごちゃごちゃ書くより速くなることが多いがな

**デフォルトの名無しさん** · 2019/09/29(日) 22:09:42.47

サイズを変えない操作でvectorと生配列の効率に違いなんかないだろ

**デフォルトの名無しさん** · 2019/09/29(日) 22:16:27.22

ただ最近のc++の最適化前提のスタンスはいただけないな
デバッグのためにデバッグビルド使おうとするが一桁二桁遅くなって実用に耐えないとか
問題再現できないとか多々あって困る

**デフォルトの名無しさん** · 2019/09/29(日) 22:58:28.58

>>217
そういうのはコンパイラベンダに言わないと変わらないでしょ。
言語規格としては知ったことではない。

**デフォルトの名無しさん** · 2019/09/29(日) 23:03:53.99

もし最適化の有無で速度の変わらないコードがあったとしたら、まず間違いなく人が読めるものではないだろうな

**デフォルトの名無しさん** · 2019/09/29(日) 23:06:55.39

こういう開き直りのスタンスって何か固有名詞ついてなかったっけ？
マッチポンプではないし・・なんかなかったかな？

**デフォルトの名無しさん** · 2019/09/29(日) 23:10:51.16

>>219
Cはコードはそこまでひどく遅くならないからね

**デフォルトの名無しさん** · 2019/09/29(日) 23:28:02.53

そのおかげで実行時の速度と抽象化した書き方の両立ができるのでまあ仕方ないのでは

**デフォルトの名無しさん** · 2019/09/29(日) 23:34:47.03

仕事でやってるので仕方ないで済まないんですよね
かつ遅いところは自分達では手が入れられないところだったり
こういうところ共感できる人いないのかな

**デフォルトの名無しさん** · 2019/09/29(日) 23:37:19.27

>>217
良いPC買え

**デフォルトの名無しさん** · 2019/09/29(日) 23:39:36.92

>>224
10、100倍遅い問題がPC買い替えてなんとかなると思います？
あと使ってるPC結構いいスペックですよ
開発環境には金かけてくれる会社なんで

**デフォルトの名無しさん** · 2019/09/29(日) 23:53:13.21

仕事でやってようと高水準言語とはそういうものなのだから仕方ないものは仕方ない
仕方ないで済まされないなら仕事をやめるしかない
仕事は不可能を可能にするものではない

そんなに最適化が気に入らないなら最適化なしでリリースすりゃいい
プロダクトとデバッグ環境が同一になる

**デフォルトの名無しさん** · 2019/09/29(日) 23:55:18.86

仕方ないで済まないのでc++使わずc使うっていう話だな。
そこまで無理してc++を使う必然性はない。
結局組み込み系で行われる判断というのはそういったものなんだろう。

**デフォルトの名無しさん** · 2019/09/29(日) 23:56:29.88

じゃあ使わなければいい終わり
苦行を強いられているなら文句を言わずに甘んじて受け入れてくれうざい
デバッグができないくらい時間がかかるのであればデバッグ用にデータを減らすかデバッガを使わずにデバッグすればいいだけ

**デフォルトの名無しさん** · 2019/09/30(月) 00:01:41.09

c++の問題を指摘したら自分が否定されてる気持ちになる人ですね？
こういうのって何か固有名詞ついてましたよね？
心理学かなにかの

**デフォルトの名無しさん** · 2019/09/30(月) 00:07:48.80

自分以外は仕事でC++使ってないと思ってるのかねえ

**デフォルトの名無しさん** · 2019/09/30(月) 00:12:05.55

C++の問題ではなく、トレードオフなものを両取りできないことに腹を立てている馬鹿の頭が問題

**デフォルトの名無しさん** · 2019/09/30(月) 00:29:11.50

debugバージョンでもinline有効にすれば良い

**デフォルトの名無しさん** · 2019/09/30(月) 00:41:06.86

gccなら-Ogとか使えば楽

**デフォルトの名無しさん** · 2019/09/30(月) 08:38:56.00

>>217
問題再現できないのってUB踏んでるんじゃ...

**デフォルトの名無しさん** · 2019/09/30(月) 20:10:40.43

c++ほどサンクコストに引っ張られる輩を作り出す言語はないだろうな。

**デフォルトの名無しさん** · 2019/09/30(月) 20:22:13.77

つまり他の言語は底の浅いオモチャ、と

**デフォルトの名無しさん** · 2019/09/30(月) 20:56:24.52

そんな掘ってもしょうがないところが深くても邪魔なだけなんだよ。

**デフォルトの名無しさん** · 2019/09/30(月) 21:49:42.53

あっさ

**デフォルトの名無しさん** · 2019/09/30(月) 21:53:05.92

速度や効率を度外視すれば実はプログラミングはものすごく簡単になることが多い。
ところがそれだと劇的に遅くなってしまう。うまく工夫して書かれたプログラムの
所要時間を1とすると、何にも考えずに書かれたプログラムの所要時間は、
100兆位になることがある。そこまで極端でないにしても何にも考えなければ
100位にはなる。その意味で高速化を常に意識しながら組むことは結構
大切な事だと思う。特にアルゴリズム的な部分においては。

**デフォルトの名無しさん** · 2019/09/30(月) 22:05:07.81

アルゴリズム的に改善できる話なら言語関係ないじゃん

**デフォルトの名無しさん** · 2019/09/30(月) 22:28:45.63

固定少数が速いとかdoubleよりもfloatが速いとか割算は遅いから掛け算だとか色々な噂聞いたけど・・・

今時ほとんど変わらんよね？

**デフォルトの名無しさん** · 2019/09/30(月) 22:34:03.50

>>241
実際測ってみりゃいいよ

**デフォルトの名無しさん** · 2019/09/30(月) 22:48:36.98

その時のためのtemplateです。

**デフォルトの名無しさん** · 2019/09/30(月) 23:07:55.69

https://ideone.com/p9ISAq
これなんで通らんのやろう？
コード補完で読み切れないのはいいけど、コンパイラさんは読めても良いのでは？

**デフォルトの名無しさん** · 2019/09/30(月) 23:15:32.33

class A :public T...{
にすりゃ通る

**デフォルトの名無しさん** · 2019/09/30(月) 23:19:40.15

もしくは
struct A :T...{
継承元にアクセスできんのが原因

**デフォルトの名無しさん** · 2019/09/30(月) 23:29:43.59

>>245-246
あ、俺環だったか。
マジで通った。。。@vc

https://ideone.com/Eahhnl

**デフォルトの名無しさん** · 2019/09/30(月) 23:42:29.68

>>247
自分で作っておいてあれだが、なにに・・・つか・・・えるん・・・だ・・・。ぐああああ。
考えれば考えるほどもやもやする。

**デフォルトの名無しさん** · 2019/09/30(月) 23:50:49.59

ヴェーダに接続するときに使うんかいな。とかおかしなことしか思い浮かばねー。

**デフォルトの名無しさん** · 2019/10/01(火) 10:39:26.07

>>217
この場合に A<B,C,D>とした場合、public T... の部分は、
public B, public C, public D
と展開されるんでしたっけ？

**デフォルトの名無しさん** · 2019/10/01(火) 15:52:31.87

>>193-194,196
では、Edgeという名前の構造体の定義を問題によって変えたいときはどうすれば良いですか？

**デフォルトの名無しさん** · 2019/10/01(火) 21:48:01.50

>>241
今どきのプロセッサではdoubleは速いよ
doubleは専用チップ積んでるから。floatはdoubleに内部的に変換かけられるから、原理的にdoubleより速くはならない

**デフォルトの名無しさん** · 2019/10/01(火) 21:50:51.00

いや、今時のプロセッサはSIMDで不動小数点演算するからdoubleよりfloatの方が速いよ
演算やプロセッサによるが、大抵2～4倍差が出る

**デフォルトの名無しさん** · 2019/10/01(火) 23:04:08.95

floatが早い今どきのプロセッサってGPUの話か？
ちゃんと区別しろ

**デフォルトの名無しさん** · 2019/10/01(火) 23:06:13.36

直前の計算結果を次の計算で使うようなありがちな状況だと、SIMDじゃ一切早くならないのでは？よく知らんけど

**デフォルトの名無しさん** · 2019/10/01(火) 23:06:54.09

x86とかも典型的だろ
doubleよりfloatの方が倍速いよ
最近はbfloat16の方がさらに速いまである

**デフォルトの名無しさん** · 2019/10/01(火) 23:26:39.35

SIMDで1語で複数のfloat演算を並列にやったら早くなる
しかしコンパイラの最適化が普通はそこまでやってくれない

**デフォルトの名無しさん** · 2019/10/01(火) 23:28:12.34

今はfloatのが速い
amd64出てからsse基本なので
昔とは状況が違う

**デフォルトの名無しさん** · 2019/10/01(火) 23:28:49.51

>>257
やるけど

**デフォルトの名無しさん** · 2019/10/01(火) 23:30:04.90

>>259
やるんか？

◆QZaw55cn4c · 2019/10/01(火) 23:32:20.09

>>253
1個のプログラムの中に一個か二個の float しか使わなくても、 double の場合より速くなるのですか？
そもそもイントリンシックを書かないのに SIMD のコードが出力されるのですか？

私は、コンパイラは fpu のコードしか吐かないじゃないか？って考えています

**デフォルトの名無しさん** · 2019/10/01(火) 23:37:45.74

>>261
それはお前の頭が老害だから

**デフォルトの名無しさん** · 2019/10/01(火) 23:39:09.19

速さ計測すればいいじゃん
逆アセンブル見ればいいじゃん

◆QZaw55cn4c · 2019/10/01(火) 23:40:49.69

>>262
1個のプログラムの中に一個か二個の float しか使わなくても、 double の場合より速くなるのですか？
そもそもイントリンシックを書かないのに SIMD のコードが出力されるのですか？

**デフォルトの名無しさん** · 2019/10/01(火) 23:44:09.36

そもそもx64ではFPUは無かったことにされている
doubleやfloatの計算したかったらSIMDで1レーンだけ使って計算する仕組み

**デフォルトの名無しさん** · 2019/10/01(火) 23:54:05.20

>1個のプログラムの中に一個か二個の float しか使わなくても、 double の場合より速く
その条件だとどっちを使っても良い大して変わらん

やっぱループアンローリングできるぐらいループリッチな課題でないと意味が無い
https://www.isus.jp/products/c-compilers/compiler_part2/
https://cpplover.blogspot.com/2015/03/blog-post_30.html

**デフォルトの名無しさん** · 2019/10/02(水) 00:10:27.89

しかしコンパイラの最適化はｲﾏｲﾁっぽい
https://www.isus.jp/products/c-compilers/compiler_part4/

◆QZaw55cn4c · 2019/10/02(水) 07:48:44.41

>>265
いいえ x64 でも fpu コードは使えますよ、嘘はやめて！

**デフォルトの名無しさん** · 2019/10/02(水) 07:54:44.99

>>228
こういうやつって何かしらソフト完成させたこともない初心者のクセしてイキってるんだろ
マジ邪魔だから消えて欲しい
テンプレート使ったコードで遅くなるというのがわからんならboostのspiritとか使ってみたらいいわ
言ってる意味わかるから

**デフォルトの名無しさん** · 2019/10/02(水) 07:59:03.00

あ、もちろんデバッグビルドの話な
最適化ありならspiritは当然速い

**デフォルトの名無しさん** · 2019/10/02(水) 08:01:33.95

C++を使わないと言っているやつに、どうぞご勝手にということと何の関係が？

**デフォルトの名無しさん** · 2019/10/02(水) 08:22:40.25

>>268
でもアセンブラで直接使わないと無かったことにされるだろ

**デフォルトの名無しさん** · 2019/10/02(水) 08:29:18.29

>>261
amd64でfpuコード吐かせるほうが手間じゃwwww

**デフォルトの名無しさん** · 2019/10/02(水) 08:30:44.39

そもそもプログラム中に一個か二個の浮動小数点演算なんて最適化ポイントちゃうがなwwww
自説を通すためにバカな例を仮定するアホに絡むだけ無駄やなw

**デフォルトの名無しさん** · 2019/10/02(水) 11:21:30.36

>>272
プロジェクトの設定でfpも選べるよ
既定だとsse使われると思うけど

**デフォルトの名無しさん** · 2019/10/02(水) 22:05:22.14

コンパイラの種類変わったら算術演算ぶん回す場合は結構差が出るだろうけど、同じコンパイラでバージョンかわると最適化とかの進化で結構かわるのかな？
gccの3と4、msvcの2005と2017とかそういう違いで

**デフォルトの名無しさん** · 2019/10/03(木) 04:57:05.82

質問です
既にクラスHogeとAがあり
クラスAとは別に新たにクラスBを追加することになった
BはA専用の関数が無く呼び出す必要も無いし逆のことは無い
その場合BにA専用の関数と同じ名前の空の関数を用意するか、呼び出されているHoge内で切り分けるかどちらの方が良いですか？
なおAは絶対に継承しなければならないし改変することもできない

class Hoge : A　か　class Hoge : Bをプリプロセッサかテンプレートで切り分ける

これを
void Hpge::func() {
　　A_func(); //Bは持っていない
}

プリプロセッサで切り分けるのが良いのか
void Hpge::func() {
#if defined(USE_A)
　　A_func();
#endif
}

それとも空の関数を書いた方が良いのか
class Hoge : B {
　　A_func() {}
}

詳しい方がいたら教えていただきたいです
これ以外の賢いやり方があればそれでも大丈夫です

**デフォルトの名無しさん** · 2019/10/03(木) 07:04:32.42

絶対に、の理由が知りたいところだけど、普通はA_funcを仮想関数にしてBは空関数でオーバーライド。

**デフォルトの名無しさん** · 2019/10/03(木) 07:05:22.94

c++17以降ならif constexprとstd::is_sameでできるんじゃない？
template < typename T >
class Hoge : T{
void func() {
　　if constexpr(std::is_same<T,A>){ //基底クラスTがAであればA_func()を実行する
　　　　A_func();
　　}
}
}

**デフォルトの名無しさん** · 2019/10/03(木) 07:12:55.92

std::is_same<T,A>　じゃなくて　std::is_same_v<T,A>　か

**デフォルトの名無しさん** · 2019/10/03(木) 07:31:04.45

>>278
HogeがAかBを継承するんだからそれじゃだめやろ
ただ設計見直したいところだけどそういうわけにもいかんのかね

**デフォルトの名無しさん** · 2019/10/03(木) 07:54:23.64

ｃ++17が使えなくて、Bの定義を関係ないAのために汚染したくないなら一層増やせばいい

template<typename T>
class HogeBase;

template<>
class HogeBase<A> : A {}

template<>
class HogeBase<B> : B { A_func(){} }

template<typename T>
class Hoge : HogeBase<T> { /*...*/ }

**デフォルトの名無しさん** · 2019/10/03(木) 09:13:02.91

>>281
なにか問題起きる？

**デフォルトの名無しさん** · 2019/10/03(木) 11:57:14.92

>>277
基底クラスを切替たいってこと？
しかも片方の基底クラスにしかないメソッドを派生クラス側で呼出すとかどんな状況なんだろう…
まあ、やっつけでやるなら素直にB側に空のメソッド追加しとけばいいと思うよ
どう見てもまともな設計じゃなさそうだし、かと言って設計を見直すこともできなさそうだしね
プリプロセッサなんて愚の骨頂にしかならん

**281** · 2019/10/03(木) 12:22:59.66

>>283
A_funcを持つものを継承するならオーバーライドが理想的だろうけど、基底がAかBってことだから無理っしょ
しかもAは書き換えられないときてる

すでに言われてるようにテンプレートで基底を指定させるか単純に空のA_funcを書くか、プリプロセッサか

でもそもそも利用者側がAを使うのかBを使うのか決めるのなら、クラス側で対処せずに利用者がプリプロセッサで分けた方がいいと思う(でないとぐちゃぐちゃになりそう)

それだと修正箇所が多すぎるのかもしれんけど

**デフォルトの名無しさん** · 2019/10/03(木) 13:00:06.78

こんなマトモじゃないケースに
ベストな解答なんかないわな

**デフォルトの名無しさん** · 2019/10/03(木) 13:00:33.56

>>284
Qtをdisってんの

**デフォルトの名無しさん** · 2019/10/03(木) 15:51:04.04

まさかと思うがQtを盲信してるのか？w

**デフォルトの名無しさん** · 2019/10/03(木) 16:04:15.58

ちょとっ猛進

**デフォルトの名無しさん** · 2019/10/03(木) 16:37:32.38

回答ありがとうございます
プリプロセッサまみれになるより空の関数生やした方が見通しよさそうですね

**デフォルトの名無しさん** · 2019/10/03(木) 18:04:25.67

>>288
え、qt便利じゃん

**デフォルトの名無しさん** · 2019/10/03(木) 19:00:51.01

旧版は知らんけどQt5はかなり良いと思う
不満に思うのはベンチ厨くらいでは

**デフォルトの名無しさん** · 2019/10/03(木) 19:22:01.27

>>291
便利かどうかなんて言ってないのにいきなりどうした？w

**デフォルトの名無しさん** · 2019/10/03(木) 21:53:13.09

コンパイル通らないので助けてください。
メンバテンプレートを持つクラスを継承して、派生先からメソッドが呼べません。
一見問題なさそうにはみえるのですが・・・

template<typename _T1>
class A{

public :

template<typename _T2> _T2 get() { return _T2(); };

};

template<typename _T3>
class B : public A<_T3> {
std::string hogehoge() { return A<_T3>::get<std::string>();}
};