C++相談室 part153

**デフォルトの名無しさん** · 2020/10/10(土) 23:18:20.00

https://mevius.5ch.net/test/read.cgi/tech/1589424805/
※前スレ
C++相談室 part152
https://mevius.5ch.net/test/read.cgi/tech/1594528940/

テンプレおしまい

**デフォルトの名無しさん** · 2020/12/23(水) 23:43:55.33

いや指定した数だけループしろよ
何勝手に回数10倍に増やしとんじゃい

**デフォルトの名無しさん** · 2020/12/24(木) 06:19:28.22

サムソンを守るためのHuawei潰しという側面もある。

**デフォルトの名無しさん** · 2020/12/24(木) 06:55:00.49

んあ？

**デフォルトの名無しさん** · 2020/12/24(木) 06:58:51.74

文大統領がトランプ大統領に、Huaweiを潰すよう勧めたそうです。

**デフォルトの名無しさん** · 2020/12/24(木) 07:53:25.30

>>863
C++ならはじめから秒2000万回ループできるコードになる

**デフォルトの名無しさん** · 2020/12/24(木) 08:12:44.86

このプログラムは応答していないためシステムによって閉じられますって出るんじゃないの。

**はちみつ餃子** ◆8X2XSCHEME · 2020/12/24(木) 10:18:24.14

>>860
OK
https://timsong-cpp.github.io/cppwp/n3337/dcl.typedef#3

**デフォルトの名無しさん** · 2020/12/24(木) 11:16:41.02

>>854
手元の32bitマイコン（除算器なし）だと
uint16_t v; に値入ってたとして、
if(v >= 100 && v < 1000) よりは ((v >= 100) & (v < 100p

**デフォルトの名無しさん** · 2020/12/24(木) 11:27:11.76

>>871
途中で送ってもうたorz

((v >= 100) && (v < 1000))のが気休め速い感じだったな。
あとLUTもほぼ変わらん。LUTはもう少し複雑な計算で、
かつキャッシュにテーブルが入ってくると鬼速だろうけど。

単純な比較のみだからあまり速い方法ないのかもね～
ダメ元で掛け算とビットシフトで/100する処理も試したけど
ちょっと遅くなったorz

つか、32bitマイコンだと100us周期程度の割り込みハンドラで
この水準まで自分は気にしないだす。
あとC++ならinline化とかその辺をまずチェックでしょうさ。

**デフォルトの名無しさん** · 2020/12/24(木) 17:12:04.54

>>872
if ((unsigned)v - 100u < 900u)
のが早くない？

テーブルは論外だ
アドレス計算コストの方が高そうだし
ROMサイズやキャッシュ汚染などの悪影響がある

**デフォルトの名無しさん** · 2020/12/24(木) 19:53:19.25

if ((unsigned)v - 100u < 900u)
こういうのは減算とコンペア(実質減算)の2回の演算が常に走るから必ずしも速くないんじゃないかな。
&&で繋ぐ方がショートサーキットが働いて1回で済む場合がある。
演算で0との比較に落とせるなら別だけど。

**デフォルトの名無しさん** · 2020/12/24(木) 19:56:18.95

そのくらいなら最適化に任せた方がいい気がするが……

**デフォルトの名無しさん** · 2020/12/24(木) 21:38:01.43

比較がボトルネックってのは本当だろうかとは思わなくもない
まあ、データ転送とか切り詰めまくって残すは比較のみ、ってのもありうるけど

**デフォルトの名無しさん** · 2020/12/24(木) 21:38:20.67

整数の減算は非常に高速
条件分岐は遅いし分岐予測を汚染する

コンパイラの最適化を見てると良い
範囲判定は大抵>>873のようなコードになる

**デフォルトの名無しさん** · 2020/12/24(木) 21:41:03.65

コード的には普通に
if (100 <= x && x < 1000)
と書いておけば良い

コンパイラが最適化するから

x/100を比較するのは
意味的にも意味不明だし
速くなることもない

**デフォルトの名無しさん** · 2020/12/24(木) 21:51:18.77

ISRの最適化なら

レジスタを節約して待避する数を減らすとか
レジスタバンクを使ってレジスタを切り替えるとか
RAM上で実行するとか
割り込みを許可せずに高速化とか(MIPSの場合)
まあ色々とチューニング出来る余地がある

小規模DSPなんかだと
いまだにISRをアセンブラで書いたりする

**デフォルトの名無しさん** · 2020/12/25(金) 14:04:51.84

バンク切り替えテクニックですか。
むかしのインターフェース誌っぽいですね。

**デフォルトの名無しさん** · 2020/12/25(金) 17:40:14.36

昔のテクニックが今でも有効

**デフォルトの名無しさん** · 2020/12/25(金) 20:23:57.32

template<size_t A, size_t B>
class tmp{};

template<size_t N>
void test(tmp<N, N>&){
std::cout << “A”;
}

template<size_t A, size_t B>
void test(tmp<A, B>&){
std::cout << “B”;
}

上のような関数があったときにtest(tmp<1,1>{});がどちらを呼ぶか規格で決まってる？

**デフォルトの名無しさん** · 2020/12/25(金) 22:18:37.12

テンプレート引数が少ないtmp<N, N>の勝ち

**デフォルトの名無しさん** · 2020/12/26(土) 00:14:55.00

using FunctorType = std::function<void()>;
struct RecursiveMapperType;
using InternalMapperType = std::map<std::string, RecursiveMapperType>;
struct RecursiveMapperType : public InternalMapperType
{
RecursiveMapperType(){}
};

こういうコードをネットで見かけたんだけど
RecursiveMapperTypeを前方宣言してInternalMapperTypeを宣言
RecursiveMapperTypeをInternalMapperTypeを継承して作成していることのメリットがよくわからない。

struct RecursiveMapperType : public InternalMapperType
{
RecursiveMapperType(){}
};
using RecursiveMap = std::map<std::string, RecursiveMapperType>

だとだめなのだろうか？
誰か教えて下しあ

**デフォルトの名無しさん** · 2020/12/26(土) 00:40:10.65

>>884
上のコードと下のコードの RecursiveMapperType の定義はまったく同じに見えるんだけど、何が違うの？

**デフォルトの名無しさん** · 2020/12/26(土) 00:50:04.37

>>885 さん
すみません。
下の方のRecursiveMapperTypeですが継承元消し忘れてました。
下のようなkたちです
struct RecursiveMapperType
{
RecursiveMapperType(){}
};
using RecursiveMap = std::map<std::string, RecursiveMapperType>

**デフォルトの名無しさん** · 2020/12/26(土) 03:46:58.69

ttps://ideone.com/Ou2BZq

**デフォルトの名無しさん** · 2020/12/26(土) 15:10:58.71

>>886
それじゃ全然機能が違うっていうかその RecursiveMap 何の役にも立たないでしょ。
元の RecursiveMapperType の機能が理解できてないだけか。

**デフォルトの名無しさん** · 2020/12/26(土) 16:40:20.18

再帰的な構造を定義したくて自分自身の型を含めたものを継承してるわけで
それを実現するには前方宣言するしかない
というね

**デフォルトの名無しさん** · 2020/12/26(土) 17:13:57.40

再帰的なコンテナは、フィールドが出来た時点で破綻するのでは？

**デフォルトの名無しさん** · 2020/12/26(土) 18:07:48.30

https://cpprefjp.github.io/reference/vector/vector.html
>不完全型を要素にする例 (C++17)

これの亜種

**デフォルトの名無しさん** · 2020/12/27(日) 06:31:05.42

C++23に持ち越された契約は何が変わるんだろね。

**デフォルトの名無しさん** · 2020/12/27(日) 17:59:23.18

ありがとうございます。なんとなくイメージできました。

コードの設計ってまだよくわからないのですが、
再帰処理のためにこうするのって比較的普通なことなんですか？

**デフォルトの名無しさん** · 2020/12/27(日) 18:23:25.49

>>893
知らんよ。
普通かどうかなんて気にしてどうするの？ここで名無しの誰かに yes/no 答えてもらって何か意味ある？

**デフォルトの名無しさん** · 2020/12/27(日) 18:33:52.26

>>893
STLのクラスを継承して階層構造を実現するテクは応用編って感じがする
もっと基本的なやり方をするならデザパタのcompositeパターンを使う
とかかね

**デフォルトの名無しさん** · 2020/12/27(日) 18:47:54.32

設計を学ぶならデザパタはひと通り見ておいて損はないぞ

**デフォルトの名無しさん** · 2020/12/27(日) 18:49:43.74

ヘネパタ、パタヘネ、デザパタ。

**デフォルトの名無しさん** · 2020/12/27(日) 22:11:00.35

newのコストは気にされますが、deleteのコストは見逃されがちです。

**デフォルトの名無しさん** · 2020/12/28(月) 02:23:23.12

あるクラスのコンストラクタのデフォルト引数を変更するときってどうしたらいいの？
オーバーロードすれば良い？

**デフォルトの名無しさん** · 2020/12/28(月) 07:27:12.64

単純に変更じゃダメな理由は？
他のライブラリ？

**デフォルトの名無しさん** · 2020/12/28(月) 07:33:40.98

stlコンテナを継承するのはアウトだろ。
うまくやらないとデストラクタが呼ばれなくなっちゃうぞ

**デフォルトの名無しさん** · 2020/12/28(月) 09:00:44.26

じゃあうまくやりましょうや。

**デフォルトの名無しさん** · 2020/12/28(月) 09:44:51.94

そもそもC++ではデストラクタを仮想にしてないってことは「継承すんなよ」って宣言だからなぁ

**デフォルトの名無しさん** · 2020/12/28(月) 09:55:45.06

なんで継承しないようにしたか意見表明文みたいなモンはどっかにあるのか？

**デフォルトの名無しさん** · 2020/12/28(月) 10:20:49.88

仮想関数化するとしない場合に比べて余分なコストがかかるから、必要な理由がない限り基本的にそれは避けるということじゃないかな

**デフォルトの名無しさん** · 2020/12/28(月) 10:32:20.80

C++は1クロックでも速く動作させるために非仮想関数をデフォルトにしたのは理解できる
Javaは動作速度よりもオブジェクト指向の継承動作の一貫性を重視してすべて仮想関数にした、これも時代を考えれば理解できる
C#もJavaと同じくデフォルトを仮想関数にしておいて欲しかったのだが、C#はC++を尊重してデフォルト非仮想関数なんだよね
これはちょっと残念

**デフォルトの名無しさん** · 2020/12/28(月) 11:33:10.90

継承して機能追加っていうのがオブジェクト指向的にもどうかと思うね

**デフォルトの名無しさん** · 2020/12/28(月) 12:34:23.27

finalキーワードがこの時代にあれば間違いなく付けただろうな
文句言ってる奴はガイジ

**デフォルトの名無しさん** · 2020/12/28(月) 12:42:44.62

>>903
継承すんな、は言いすぎ。
private継承なら問題ないと思うけど。実際たまに使われているし。

**はちみつ餃子** ◆8X2XSCHEME · 2020/12/28(月) 13:19:25.85

デストラクタが仮想ではないものを継承したときの具体的な問題は
スライシングが起こりうるということと、
起こってもコンパイラが (少なくともコンパイル時には) 捕捉できないことが多いということにあって、
スライシングが起こらないように使う分には問題はない。

設計的に綺麗かどうかはまた別の話だけど。

shared_ptr が (デストラクタが仮想でなくても) 元の型のデストラクタを呼んでくれたりするんで、
場合によってはそういう設計もアリということなんだと思う。

**デフォルトの名無しさん** · 2020/12/28(月) 14:12:57.70

>>910
デストラクタが仮想なものを継承してもスライシングは起こりうるよね？そこは関係なくね？
https://en.wikipedia.org/wiki/Object_slicing
> In C++ programming, object slicing occurs when an object of a subclass type
> is copied to an object of superclass type: the superclass copy will not have
> any of the member variables defined in the subclass. ...

**デフォルトの名無しさん** · 2020/12/28(月) 17:31:09.93

C++自由すぎてしんどいな
後方互換性と引き換えに払った代償か

**はちみつ餃子** ◆8X2XSCHEME · 2020/12/28(月) 17:46:19.93

>>911
スライシング自体は起こるけど、それで予想外のことやメモリ管理の矛盾は起こり難い。

**デフォルトの名無しさん** · 2020/12/28(月) 17:50:37.04

自由に羽ばたける翼。

**デフォルトの名無しさん** · 2020/12/28(月) 18:06:08.49

自由すぎて困る部分はLinterを併用することで勝手に回避しろってことかな

**デフォルトの名無しさん** · 2020/12/28(月) 18:37:15.29

だってCの設計思想が「人間を信用する」だもん
セキュリティが重視される現代的な言語のベースとしては致命的に合ってないんだよね

**デフォルトの名無しさん** · 2020/12/28(月) 18:40:02.12

>>913
やっぱり関係がわからない。
デストラクタが仮想ではないものを継承したときに限ってスライシングが予想外のことや
メモリ管理の矛盾につがなる例をひとつでいいから見えてもらえない？

**デフォルトの名無しさん** · 2020/12/28(月) 18:40:41.01

s/見えてもらえない？/見せてもらえない？/

**デフォルトの名無しさん** · 2020/12/28(月) 19:07:39.46

A <|- B, C みたいなときにB, CをnewしてA*として管理しようとすると破棄の時にAのデストラクタしか呼ばれない

**デフォルトの名無しさん** · 2020/12/28(月) 19:09:58.26

>>911
仮想でないデストラクタが話題のスコープなのに、スライシングにスコープを移したら議論にならないでしょ。

911) デストラクタが仮想なものを継承する→スライシングになるものが存在する
という命題は
910) デストラクタが仮想ではないものを継承する→スライシングになるものが存在する
という命題と矛盾するわけではない（両立する）ので、その議論はあんまり意味がない。

**デフォルトの名無しさん** · 2020/12/28(月) 19:14:08.97

スライシング・オプティマイザーとかどうよ？

**デフォルトの名無しさん** · 2020/12/28(月) 19:36:49.42

>>910
> スライシングが起こらないように使う分には問題はない。
ここもおかしいんだよね。

デストラクタが仮想ではないものを継承して派生クラスのオブジェクトを new で作って
基底クラスのポインタを通して delete したら未定義動作になるわけだけど、
これはスライシングを起こしていなくても問題になる。

「派生クラスのオブジェクトを new で作って基底クラスのポインタを通して delete」のことを
「スライシング」と呼んでる気配もあるんだけど、それは明らかに誤りだろうし。

**デフォルトの名無しさん** · 2020/12/28(月) 19:43:43.44

>>900
変更ってどうやるの？
毎回好きな引数を与えよってこと？
面倒なので、自分の好きな引数を自分のコードの中ではデフォルトにできれば良いのにと思ったのだが、こういう考えは間違っていますか

**デフォルトの名無しさん** · 2020/12/28(月) 19:51:33.62

>>923
make関数作るのはダメなん？

**デフォルトの名無しさん** · 2020/12/28(月) 19:59:11.40

デストラクタはpublic仮想かprotected非仮想かpublic非仮想finalのどれかにしろ
っていう一般的結論でよくね

**デフォルトの名無しさん** · 2020/12/28(月) 21:21:17.65

>>925
自分で書くときはそう
標準のコンテナのように既存のクラスがそうでなかったら？が発端だからなぁ

個人的には仮想デストラクタがなければ継承はしない
(一部のイディオムを除けば)private継承にするくらいなら委譲する。

**デフォルトの名無しさん** · 2020/12/28(月) 21:54:56.73

デストラクタがprotected:であっても非仮想なら継承したらアウトなんじゃ…
派生クラスの破棄時に基底クラスのデストラクタが呼ばれない
的な意味で

**デフォルトの名無しさん** · 2020/12/28(月) 21:57:44.66

>>924
オブジェクトを作るための関数を作ってはどうかという意味ですか？
確かにそれで良いのでそうします

**デフォルトの名無しさん** · 2020/12/29(火) 07:11:18.52

相称型プログラミング。

**デフォルトの名無しさん** · 2020/12/29(火) 07:28:15.94

いま私大事なこと言いましたよ。

**デフォルトの名無しさん** · 2020/12/29(火) 07:37:07.18

プログラミング学びには来ないだろ
こんな途上国に

**デフォルトの名無しさん** · 2020/12/29(火) 07:38:50.44

【CSS規格、読書感想文】
CSSがアイデアであった段階からスクリプト言語で実装され、初の大規模採用であったネットスケープにおいてもJavascriptによって実装されていたため、規格そのものがC/C++で効率的になるよう設計されていない。※
現行の規格に対して効率的な実装を施したとしても、将来の規格バージョンで維持できると限らないため、結局、スクリプト言語と同様の非効率を許容することになる。
これはつまり、ほとんどのシンボルを動的に確保することを意味する。

※HTML5規格は、C/C++で効率的に実装できるように仕組まれている。

**デフォルトの名無しさん** · 2020/12/29(火) 07:48:03.75

なるほどねー
そもそもCSSのCって要る？
もはやスタイルシートってサイト作成者が決めるものになっているよね
ユーザースタイルシートをカスケード適用できる機能もなくせばさらに効率よくできそう

**デフォルトの名無しさん** · 2020/12/29(火) 07:49:27.20

>>927
なんで？~Derived()が~Base()を呼ばない場合なんて存在しないぞvirtualの有無関係なく

**デフォルトの名無しさん** · 2020/12/29(火) 08:05:44.29

>>927
型消去とsmart ptr実装で調べるよろし。

**デフォルトの名無しさん** · 2020/12/29(火) 09:18:16.16

定期的に話題になるけど、基底のデストラクタにvirtualが必要なのは
基底型のポインタでdeleteするときだけな
末端のデストラクタさえ呼べれば、次に呼ぶ基底の型は分かりきってるからね

別の言い方をすれば、常に末端の型のポインタをdeleteする分には、virtualなデストラクタなんか要らんということ

**デフォルトの名無しさん** · 2020/12/29(火) 11:55:36.33

ポリモーフィズムの旨味が消えるｗ

**デフォルトの名無しさん** · 2020/12/29(火) 12:13:46.12

ポリリズムから出汁をとったみたいないい方しますね。

**デフォルトの名無しさん** · 2020/12/29(火) 13:15:00.89

まあ普通は末端の型を意識しなくて済むからこそ派生の旨味がある訳で

**デフォルトの名無しさん** · 2020/12/29(火) 14:33:08.60

>>936
その点については誰もが一度は通る勘違いだよなｗ
最初はわけも分からず機械的にvirtualつけて回ってたわ

**デフォルトの名無しさん** · 2020/12/29(火) 20:19:15.83

うっせえ知っとったわ素でまちがえただけじゃわ！ヽ(`Д´)ﾉｳﾜｰﾝ

**デフォルトの名無しさん** · 2020/12/31(木) 05:29:21.52

struct A { virtual void Delete() { delete this; } };
struct B : A { void Delete() { delete this; } };
こうなってりゃ別にいらんな

**デフォルトの名無しさん** · 2020/12/31(木) 11:50:06.55

>>795 の同期とか奇妙な質問に思うけど、Javaからくるとそうなるんだな。

**デフォルトの名無しさん** · 2020/12/31(木) 12:23:37.15

javaにだって非同期でメモリ確保するコンテナなんてないでしょ

**デフォルトの名無しさん** · 2020/12/31(木) 13:41:11.66

>>942
おとなしく virtual ~A() とするのにくらべて何のメリットも無いな。

**デフォルトの名無しさん** · 2020/12/31(木) 13:43:11.73

deleteのコストは、ほんと気にされないな。

**デフォルトの名無しさん** · 2020/12/31(木) 15:24:44.84

「a=1 かつ b=1 以外なら実行」って条件式はどう書くの？

**デフォルトの名無しさん** · 2020/12/31(木) 15:31:08.20

>>947
母語で曖昧さの無い表記ができますか？

**蟻人間** ◆T6xkBnTXz7B0 · 2020/12/31(木) 15:40:19.22

>>950

> 「a=1 かつ b=1 以外なら実行」って条件式はどう書くの？

「「a=1 かつ b=1」以外なら実行」なら、
if (!(a == 1 && b == 1)) { 実行(); }

「a=1 かつ「b=1以外」なら実行」なら、
if (a == 1 && b != 1) { 実行(); }

**デフォルトの名無しさん** · 2020/12/31(木) 15:47:49.87

>>949
THX
「a=1 かつ b=1」以外なら実行、でした。
私が950でレスするのもお見通しですか？ｗ

**デフォルトの名無しさん** · 2020/12/31(木) 18:57:49.39

>>945
ただの押しつけだな
うるせーバカ

**デフォルトの名無しさん** · 2021/01/01(金) 05:08:27.95

CSSは規格の著者がサンプル実装してるというので見に行ったら、Javascriptだった。
あからさまに動的言語向けに規格が書かれているのは、そういうことでしたか。
これは辛い。

◆QZaw55cn4c · 2021/01/01(金) 18:05:25.39

>>792
それはちょっと古臭いお馬鹿な手法でしょう

正しいやりかたは、
・呼び出し側が呼び出され側に格納エリアを提供する‥‥①
・呼び出し側が確保するべきサイズは①の前に別途問い合わせする

**デフォルトの名無しさん** · 2021/01/01(金) 18:33:17.97

いずれにしろ面倒

**デフォルトの名無しさん** · 2021/01/02(土) 00:08:04.41

CにはCで
#define APPBUFSZ (十分でかい整数値)
void foo() {
　　char buf[APPBUFSZ];　　　　　// buf[]はスタック上にとられる配列（重要
　　if (!func(buf, sizeof(buf))) {　　// 第2引数は要素数の意味とするならsizeof(buf) / sizeof([0])
　　　　バッファサイズ不足等のエラー
　　}
}
という黄金パターンあるんじゃー
これは原始的な見かけほど不合理というわけではない

**デフォルトの名無しさん** · 2021/01/02(土) 00:11:12.76

CSSはDOMの一部でありかつ意味と表記の分離の必要からCSSになった
DOMはWebページのあらゆる要素へのコントロールの実現を目的としている
という印象

◆QZaw55cn4c · 2021/01/02(土) 00:53:58.35

>>955
kwsk
ちょっとよくわからない‥

**デフォルトの名無しさん** · 2021/01/02(土) 02:21:09.41

>>955
Cってこのパターンでクソほど無駄なバッファ取るから全然効率的じゃないよな

**デフォルトの名無しさん** · 2021/01/02(土) 09:15:42.80

>>955
何が黄金なのかさっぱりわからんが…
どこでそれが黄金パターンとされているかの出典だけでも頼む

**デフォルトの名無しさん** · 2021/01/02(土) 09:25:20.55

定番は>>953だろう。
事前にサイズを求めるコストがバカにならないという場合だけ別案を検討するくらいで。

**デフォルトの名無しさん** · 2021/01/02(土) 10:59:35.93

大抵の場合は「事前にサイズを求める」＝やり直しになりそうなんだけど

**デフォルトの名無しさん** · 2021/01/02(土) 11:29:31.77

>>958
左様よほど意図しない事象でも起きない限りエラー処理に行かないぐらい大き目にとる
スタック上に領域をとる場合、時間コストも空間コストもゼロとみなせるからそれで構わない
再帰呼び出しのようなきわめて深い関数呼び出し階層になるときぐらいしか問題は生じない
というわけで、プログラミングしたいこと/すべきことに対するちょっとした洞察と
アーキテクチャーに関する理解さえあれば、言うほど非効率でも不合理でもないことがわかるはず…

**デフォルトの名無しさん** · 2021/01/02(土) 11:39:10.82

>953
確保すべきサイズを問い合わせたときと確保して呼び出した時に必要サイズが変わっていないか気になって夜しか眠れない
(リトライしてもリトライ回数が適切かどうか気になって布団以外で眠れない)