C++相談室 part158

**デフォルトの名無しさん** · 2021/11/15(月) 18:49:18.44

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

**デフォルトの名無しさん** · 2022/02/06(日) 12:26:28.98

そう書かれるとC89っぽく書かないといかんのか？ｗ
変更部分のみｗ
$ gcc -x c -std=c89 - <<EOF
int f(void){return 2;}
#define f() 1
int main(void) {
int i;
int (*j)();
i = f();
j = &f;
return i + (*j)();
}
EOF

**デフォルトの名無しさん** · 2022/02/06(日) 12:53:10.29

CとC++の規格は既存コードへの忖度の塊で出来てるからな
万人の敵だったgets()を削除するのにどんだけ苦労してるのやら

**デフォルトの名無しさん** · 2022/02/06(日) 13:16:26.39

>>806>>808
スレに乗っかったつもりにしては
#if f
～
#endif
というのが含まれて無いようだが？

**デフォルトの名無しさん** · 2022/02/06(日) 13:22:45.35

>>807
C++規格委員会は無罪なのかもしれんがじゃあなんでC89以前からそうで
そういう挙動が支配的になってしまう事態になってしまったのか、と考えると
やっぱプリプロセッサの最初の設計者がサボって
プリプロセッサ式の途中でのFOOの定義/未定義判定を
define(FOO)を導入する代わりに仕様の方を弄って簡単ハックしてしまったから
のでは……

**デフォルトの名無しさん** · 2022/02/06(日) 13:33:49.71

コードを示しても馬鹿には伝わらない悲しみｗ

**デフォルトの名無しさん** · 2022/02/06(日) 13:37:12.22

>>812
天才にもわかるようにkwsk

**デフォルトの名無しさん** · 2022/02/06(日) 13:39:17.55

天才は自力でなんとか出来るし、他人を信用しないことも多いから、基本的に質問とかする機会がない
アイデアレベルの話のみ

**デフォルトの名無しさん** · 2022/02/06(日) 14:11:31.07

(σﾟωﾟ)σｹﾞｯﾂ
stdioのバッファ使うヤツ殆ど失敗作

**デフォルトの名無しさん** · 2022/02/06(日) 14:22:31.03

#define マクロは単純置換のやつと関数形式のやつがある

#define A(a,b)
A();A(1);A(1,2,3);A(1,);A(,2);A;

結構めちゃくちゃなことやってもプリプロセスはエラー吐かない

引数足りないとか関数形式マクロの括弧がないのは意図しない使い方だろうからエラーにしてもらいたい気持ちはわかるが

というか<<802で言及されてるけど#if UNDEFINEDも非推奨にしてほしいわ
#define DEBUG
#define DEBUG 1
#define DEBUG 0
//#define DEBUG (undefined)
これらの全部のケースに対応できてねーし
#if DEBUG+0 とか書けとでも？

**デフォルトの名無しさん** · 2022/02/06(日) 15:06:24.27

俺のコードのg++やgccをcppに変えればプリプロセスの結果が出るよｗオプション引数に-Eを付けても可ｗ
別に不思議でも何でもない結果が表示されるｗ
$ cpp -x c++ - <<EOF
#define A(a,b) expanded
A();
A(1);
A(1,2,3);
A(1,);
A(,2);
A;
EOF
# 1 "<stdin>"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 1 "<command-line>" 2
# 1 "<stdin>"

<stdin>:2:3: error: macro "A" requires 2 arguments, but only 1 given
<stdin>:1: note: macro "A" defined here
A;
<stdin>:3:4: error: macro "A" requires 2 arguments, but only 1 given
<stdin>:1: note: macro "A" defined here
A;
<stdin>:4:8: error: macro "A" passed 3 arguments, but takes just 2
<stdin>:1: note: macro "A" defined here
A;
expanded;
expanded;
A;
$

**デフォルトの名無しさん** · 2022/02/06(日) 16:46:37.28

インクルードガード書くときも単に
#define FOO_HPP
とするのと
#define FOO_HPP 1
と1にするのがあるがどちらが良いとかあるんだろうか

後者の方がconstexpr if文などのC++の言語機能と組み合わせて使えるというメリットがありそうだが

**デフォルトの名無しさん** · 2022/02/06(日) 16:54:43.06

今から新規に書くなら #pragma once 一択

**はちみつ餃子** ◆8X2XSCHEME · 2022/02/06(日) 17:09:14.27

>>818
私自身は前者にしてる。
インクルードしたことを示すためのフラグとしてのマクロが必要なら
(そういう事例に遭遇したことはないが) ガード用とは別にマクロ定義すると思う。

ガードのために定義したものをガード以外の目的で使うというのがちょっと汚く感じるから。
だけど分けちゃうと管理が二重になるのが嫌だと思う人もいるだろうし、
思想によるんじゃないの。

私は規格厨なので #pragma once は使わない。
まあ gcc と clang と msvc で使えるから事実上は問題にならないけど。

**デフォルトの名無しさん** · 2022/02/06(日) 17:25:15.43

>>820
ありがとう
納得できる理由です

インクルードガード以外のフラグも同様にしてますか？
標準のNDEBUGのように

**はちみつ餃子** ◆8X2XSCHEME · 2022/02/06(日) 17:46:04.51

>>821
NDEBUG は「デバッグモードとそうでないモードを切り替える」というのがその用途なので
それに沿うと思ったら分けずに NDEBUG を使うことはあるよ。
でも「NDEBUG の用途は assert の有効・無効の切り替えなので他に使うべきでない」と認識している人がいてもおかしくない。

規格に書いてあるのはこの場合はこうだという規則だけなので
抽象的な部分での意味の捉え方は人によってかなり幅がある。
そのあたりは文脈を察して常識的判断でやっていくしかないし、
チームでやってるなら話し合うしかしょうがない。

このへんはそんなにスッパリと判断基準を設けられるようなもんではないと思う。

**デフォルトの名無しさん** · 2022/02/06(日) 19:09:51.99

MS発祥のモノが嫌われてるだけとも思うｗ

**デフォルトの名無しさん** · 2022/02/06(日) 19:46:48.16

>>822
質問の意図がわかりにくくてすみません
自前でフラグ書くなら
>>818の前者と後者どちらを使うのかが知りたかった

**はちみつ餃子** ◆8X2XSCHEME · 2022/02/06(日) 20:08:36.06

>>824
基本的には前者。
フラグとしてのマクロで分岐するときは #if よりも #ifdef (または defined) を使うようにしてる。
マクロは型を付けられないからそうすることで ON/OFF のどちらかであって内容に意味はない
ことを明示してる感じを出したいと思ってる。

**デフォルトの名無しさん** · 2022/02/06(日) 20:55:43.12

>>825
改めての回答ありがとうございます

こういう一見どちらでも良いものであっても裏の考えや意図が聞けて面白かったです

**デフォルトの名無しさん** · 2022/02/07(月) 06:01:51.26

#pragma onceを標準に採用すればええのに
これだけ需要あるのに長年ずっと放置状態
何がそんなに問題なんだろう

**はちみつ餃子** ◆8X2XSCHEME · 2022/02/07(月) 09:54:39.71

現行仕様での理屈の立て方としては #include の効果でコードに一体化してから内容の解釈が始まるので
インクルードに干渉する余地がない。
現実にやってるんだから出来るのは間違いないんだけど理屈を根本から変えることになるし、
モジュールが上手くいけばどうでもよくなることに手間をかけたくないんじゃないかな。

**デフォルトの名無しさん** · 2022/02/07(月) 11:19:39.20

シンボリックリンクで別のパスになってたりとか、同じ内容の別ファイルとか、ファイル名違う中身同じファイルとか、日付だけ違う別ディレクトリの同じ内容のファイルとか
そんなの考えたくないよなーｗ

**はちみつ餃子** ◆8X2XSCHEME · 2022/02/07(月) 11:53:54.22

名前と実体をどう対応付けるかは今でも処理系定義なのでそこらへんはあまり問題にならないと思う。

**デフォルトの名無しさん** · 2022/02/07(月) 11:56:53.41

そこで#pragma onceはヘッダファイルそのものをインクルード済とみなすのではなくて
定義されている内容を定義済みと記憶するのが妥当な動作
なんだけど以下のような場合に困るという、
"a.h"
struct Foo {

"b.h"
　　int m_x;
　　double m_y;
};

"c.cpp"
#include "a.h"
#include "b.h"

やっぱモジュールにしたら同じような実装で完全な解決になるのだから待った方が、

**デフォルトの名無しさん** · 2022/02/07(月) 12:22:03.46

現行の
#ifdef _FOO_H_
#define _FOO_H_
....
#endif
はヘッダファイルをインクルード済みか否かではなく
マクロ_FOO_H_が定義済みか否かを問題にしているのである意味モジュールに近い
#pragma onceは現行のマイクロソフトのやつはヘッダファイルをインクルード済みか否かを問題にしているので
何をもって同一のヘッダファイルとみなすのかという解釈の揺らぎの影響を受けてしまうまインクルードの挙動が、

**デフォルトの名無しさん** · 2022/02/07(月) 12:25:19.77

>>830
だからどう転ぼうと中身で決められる昔ながらの方法の方が結果が明確ということｗ

ちなみにgccは
シンボリックリンク→ガード
同じ内容・日付・名前、別ディレクトリの別ファイル→ガード
同じ内容・名前、別日付、ディレクトリの別ファイル→インクルード
同じ内容・日付、別名前、ディレクトリの別ファイル→インクルード
みたい

**デフォルトの名無しさん** · 2022/02/07(月) 12:42:43.58

MSの手抜き仕様まで合わせる必要なし

**デフォルトの名無しさん** · 2022/02/07(月) 12:56:32.61

でもCに代わってC++が広まったのはMSのおかげじゃん

**デフォルトの名無しさん** · 2022/02/07(月) 13:10:46.99

ビット数多めのハッシュにしとけば
例えば衝突確率340澗分の１とかにできるよな

**デフォルトの名無しさん** · 2022/02/09(水) 12:59:20.15

64bit osでポインタ型を4byteにするにはどうすればいいんですか？
8byteだとちょっと大きすぎる気がします

**デフォルトの名無しさん** · 2022/02/09(水) 13:03:37.90

なぜ大きすぎると思ったのかが分からないが、64bitのアドレス空間を表すのに8 byteは必要だよ

**デフォルトの名無しさん** · 2022/02/09(水) 13:08:06.15

>>837
貧乏くさすぎ

**デフォルトの名無しさん** · 2022/02/09(水) 13:19:23.53

64bit WindowsOSなら32bitアプリにすればok

**デフォルトの名無しさん** · 2022/02/09(水) 13:40:55.45

例えば64bitの場合アドレスの上位4byteを一意に決めといて下位4byteを4byteの変数に格納しておくってやり方なんてはどうですか？
それで復元時には
(上位4byte << 32) & 下位4byteっていうふうに変換するってふうになると思うんですが
まず最初に上位4byteが一致した連続したメモリ領域から決まってメモリを確保するなんてことはできるのでしょうか？

**デフォルトの名無しさん** · 2022/02/09(水) 13:52:00.55

必要なメモリをvector<X>で確保しておいて32bit以下のindex値でアクセスすることにすれば？

ポインタのサイズが大きすぎるなんて理由でやる人はいないと思うけど

**デフォルトの名無しさん** · 2022/02/09(水) 13:52:47.57

long long ago... タイニー、スモール、コンパクト、ミディアム、ラージ、ヒュージつーのがあってだな

**デフォルトの名無しさん** · 2022/02/09(水) 14:26:32.14

>>842
そうすることにします
ありがとうございました

**デフォルトの名無しさん** · 2022/02/09(水) 14:34:15.15

関数ポインタかなんかが8バイトに収まってなくて混乱したことがあったっけ

**デフォルトの名無しさん** · 2022/02/09(水) 14:37:12.22

昔は16bitポインタと32bitポインタをLPとPで使い分けてたって戦争で死んだおじいちゃんに聞いた

**デフォルトの名無しさん** · 2022/02/09(水) 17:17:57.87

segment:offset時代か・・・

**デフォルトの名無しさん** · 2022/02/09(水) 18:17:45.02

アセンブラの相対ショートジャンプは8ビット

**デフォルトの名無しさん** · 2022/02/09(水) 22:34:51.11

ウィンドーズならINT_PTR使っとけばおkオール無問題
C++の標準規格でどうなっているのかわ知らん

**はちみつ餃子** ◆8X2XSCHEME · 2022/02/09(水) 23:19:57.51

規格上は std::intptr_t というものがある。
ただし関数ポインタやメンバ関数ポインタを格納できるとは限らない。
また、省略可能 (optional) であると明記されているので無くても規格準拠たりうる。

関数ポインタ同士 (メンバ関数ポインタは含まない) はお互いに変換可能であり
元の型にキャストしたら元の値と等しくなることは保証されるので
任意の型の関数ポインタを格納したいのであれば void* や intptr_t を使うよりは
適当な型の関数ポインタに入れるほうが規格に沿う。

メンバ関数ポインタは型通りに扱う以外はほとんど何の保証もないのだけれど
無理に変換して扱いたい場合も特に思いつかないのでどうでもいい。

**デフォルトの名無しさん** · 2022/02/10(木) 02:00:13.27

>>843
far/near を直接指定すれはすむ話、メモリモデルなんてどうでもいい

**デフォルトの名無しさん** · 2022/02/10(木) 19:32:52.48

effective C++って現行のC++と比べてどのあたりが古いんですか？
代表的なところとかだけでも教えてくれると嬉しいです

**デフォルトの名無しさん** · 2022/02/10(木) 19:38:59.22

全て

**デフォルトの名無しさん** · 2022/02/10(木) 20:00:39.81

出版1998年やんけ
こんなもん使うぐらいならC言語やった方がマシなレベル

**デフォルトの名無しさん** · 2022/02/10(木) 20:11:39.77

>>854
一応第3版は原書が2005年に書かれています…

**デフォルトの名無しさん** · 2022/02/10(木) 20:20:25.92

続編のeffective modern c++も古いけど、
こっちは隕石落下後の本だから読んでおいたほうがいいよ

**デフォルトの名無しさん** · 2022/02/10(木) 21:18:10.31

隕石落下後ってなんすか？
あとC++の勉強するならこの本読め、みたいなのって他にもありますか？

**デフォルトの名無しさん** · 2022/02/10(木) 21:38:32.90

2005年でも古いなあ
C++98, 03, 11(0x), 14, 17, 20 と5回バージョンアップあるし
そのたびに標準ライブラリが更新されてる

古い本で古い書き方しか知らないと慣れてきたころにイラつくことになるから最低でもC++11対応のやつがいい

**デフォルトの名無しさん** · 2022/02/10(木) 21:44:00.87

今更auto_ptr使うなとか言われても何の役にも立たないからな

**デフォルトの名無しさん** · 2022/02/10(木) 23:48:22.57

べつに使ってもいいんだよ
使い方さえ間違えなければ

**デフォルトの名無しさん** · 2022/02/11(金) 00:26:40.18

使うことが間違いでは？

**デフォルトの名無しさん** · 2022/02/11(金) 04:33:24.42

左辺値参照で無理やりムーブ作ったやつね

**デフォルトの名無しさん** · 2022/02/11(金) 06:13:41.97

仕様のバージョンは普通自分で選ぶもんじゃないので、古いことを知るのだって意味はある
逆にどの辺が古い、というのが分かってもあまり意味ない

**デフォルトの名無しさん** · 2022/02/13(日) 06:29:47.80

いろんな範囲で一様乱数を次々と生成したいときってどうしますか？
uniform_int_distribution の範囲を次々と param で変える？
あるいは、妥協して剰余をとる形で範囲を変える？

**デフォルトの名無しさん** · 2022/02/13(日) 06:32:11.91

あるいは、uniform_int_distribution を次々と生成して使い捨てる？

実測するべきなんでしょうが、どれがオーバーヘッドが少ないかというカンがありません

**デフォルトの名無しさん** · 2022/02/13(日) 06:51:44.09

色々手はあるね
「いろんな範囲」の個数が決まっているならuniform_int_distributionの配列にするもよし
ランダムならparamもよし

次々と生成して使い捨て、つまりコンストラクタとデストラクタを都度実行するのは
俺はあんまりやりたくないが止めもしない

**デフォルトの名無しさん** · 2022/02/13(日) 07:21:47.95

>>865
同じ範囲を何回も使うならその分distributionを用意する、そうでないならparamを変えていくのが良さそうに思います。が、たぶん実行時の差はほぼ無いです。
いちおう関数の定数を書き換えていくかメモリ上に予めたくさん用意するかの違いとして判断しました。
計算重いのは大抵は乱数生成の方だと思うので、速くしたいならそっちをとりかえたほうがいいと思います。

**デフォルトの名無しさん** · 2022/02/13(日) 07:48:28.31

メルセンヌツイスターの売りの１つが速度がそんなに遅くない点だね

**デフォルトの名無しさん** · 2022/02/13(日) 10:06:40.11

なんで剰余を取るのが妥協なん？

**デフォルトの名無しさん** · 2022/02/13(日) 10:33:38.50

一様性が一般に崩れるから

**デフォルトの名無しさん** · 2022/02/13(日) 10:37:30.83

個人的にはこうやってみたりしてゐる、

/// 閉区間[0, ub]を値域とする一様乱数を生成する。
unsigned long genrand_int32_with_ub(unsigned long ub)
{
assert(0 < ub && ub < (unsigned long)UINT32_MAX);
const uint64_t F = (uint64_t)UINT32_MAX;
const uint64_t W = (uint64_t)ub + (uint64_t)1;
const uint64_t Q = F / W;
#ifndef NDEBUG
const uint64_t R = F - W * Q;
assert(Q > 0 && 0 <= R && R < W);
#endif
// 半開区間[0, (W+1)*Q)を値域とする一様乱数取得
const uint64_t WQ = W * Q;
uint64_t rndLTWQ;
do {
rndLTWQ = (uint64_t)genrand_int32();
//printf("rndLTWQ=0x%08x, Q=0x%016llu\n", rndLTWQ, Q);
} while (rndLTWQ >= WQ);

// Qで割る。
const uint64_t r = rndLTWQ / Q;
assert(0 <= r && r <= ub);
return (unsigned long)r;
}

**デフォルトの名無しさん** · 2022/02/13(日) 10:52:20.14

標準ライブラリ使わんの？

**はちみつ餃子** ◆8X2XSCHEME · 2022/02/13(日) 11:12:52.07

>>869
分かり易い例として 0 から 9 の一様な乱数列を生成するものを考えてみればいい。
このとき 0 から 7 の値が必要だからといって 8 の余剰を取ったらどうなる？
8, 9 が 0, 1 になるから 0 と 1 の出現確率が他の倍になってしまうだろ。

生成される値の幅が必要な値の幅よりも十分に大きいなら
許容可能な誤差として無視できる場合も多いとは思うが
様々なパラメータが有りうる状況では検証しづらい。

**はちみつ餃子** ◆8X2XSCHEME · 2022/02/13(日) 11:15:35.52

>>872
呼出しのたびに必要な範囲が違うような Distribution が標準に無いという文脈

**ハノン** ◆QZaw55cn4c · 2022/02/13(日) 12:39:58.09

>>873
それもあるけれども、昔の擬似乱数列は絶望的なまでに下位桁がランダムではない、という事情をひきずっているのでは？まあ MT はそうじゃないけどね

**デフォルトの名無しさん** · 2022/02/13(日) 13:09:41.79

>>873
そらもちろん、元がそんな狭い範囲ならだめでしょ
あとまあ昔のrand的には割ってかけるのが正しいというのはあるけどそれは別の話で

**デフォルトの名無しさん** · 2022/02/13(日) 13:37:58.02

C++何の関係もない話で草
検証が必要ならすればいいだけ
要件すら不明で何もしてないのに質問するやつが馬鹿

**はちみつ餃子** ◆8X2XSCHEME · 2022/02/13(日) 14:27:27.60

>>876
> 元がそんな狭い範囲ならだめでしょ

逆に欲しい範囲が大きい場合でも同様。
この場合は様々な範囲が有りうるという想定なので、都合の悪い状況も考慮する必要がある。

**デフォルトの名無しさん** · 2022/02/13(日) 15:14:31.28

任意の区間の乱数って、どうせはみ出した分をちょん切るんでしょ？

**はちみつ餃子** ◆8X2XSCHEME · 2022/02/13(日) 15:18:24.06

せやで。

**デフォルトの名無しさん** · 2022/02/13(日) 15:25:43.89

そんな短い周期の疑似乱数使ってないんじゃない？
端っこは気にしないと思うなあ

**デフォルトの名無しさん** · 2022/02/13(日) 16:00:39.64

>>876
> そらもちろん、元がそんな狭い範囲ならだめでしょ
「分かり易い例」って書いてあるのも理解できないの？

**デフォルトの名無しさん** · 2022/02/13(日) 16:06:17.09

一般論でいうと周期に余裕がない様な疑似乱数使うのが間違いなんだと思うけどね

**デフォルトの名無しさん** · 2022/02/13(日) 16:19:57.08

そういうのを乱数知識ない奴が触らずに済むようにパッケージにしたのが<random>のdistributionなんだから素直に頼っとけよ

**デフォルトの名無しさん** · 2022/02/13(日) 16:42:35.21

周期と値域は別では

**デフォルトの名無しさん** · 2022/02/13(日) 16:56:02.36

>>885
内部的にはおおむね同じです

**はちみつ餃子** ◆8X2XSCHEME · 2022/02/13(日) 17:04:20.08

線形合同法とかなら値の範囲と周期が一致することもあるが、乱数の一般的性質というわけではない。

**デフォルトの名無しさん** · 2022/02/13(日) 17:59:20.78

周期と値域は別だろ
たとえばマイナス一億と、プラス一億の2値をとる乱数とか

**デフォルトの名無しさん** · 2022/02/13(日) 18:15:27.44

疑似乱数なんて今の値で次の値が決まるんだから周期も値も同じだろう
その値の一部を使ったらまあ見た目は減るだろうけど

**デフォルトの名無しさん** · 2022/02/13(日) 18:32:37.88

値域: 出力される値の範囲
周期: そのまんま乱数の出力が1周するステップ数

内部状態かなんかとごちゃ混ぜになってない？

**はちみつ餃子** ◆8X2XSCHEME · 2022/02/13(日) 18:34:40.46

>>889
内部状態と結果を分離する方式だって当然あるよ。
メルセンヌツイスタのどでかい内部状態を毎回値として利用するわけないし、
乱数として利用できる性質になってない。

**デフォルトの名無しさん** · 2022/02/13(日) 18:34:49.25

さすがにマジの最大値と最小値なんて誰も問題にしとらんやろ

**デフォルトの名無しさん** · 2022/02/13(日) 18:38:19.35

>>892
その思い込みで「値域」と「内部状態の大きさ」をごっちゃにしてるから話がこじれてたんでしょ。
区別して。

**デフォルトの名無しさん** · 2022/02/13(日) 18:55:00.53

端っこにゴミがあるよりは歯抜けが散らばってる方がいいというのは一理あるね

**デフォルトの名無しさん** · 2022/02/14(月) 10:33:59.04

メンバー関数をテンプレートに出来たりしませんかね?

struct Sample{void func1(int i); void func2(int i);...}
template<typename T> void SampFunc(Sample& sample, int i){sample.T(i);}

みたいな

エラーはNo member named 'T' in ホゲホゲって感じですが

**デフォルトの名無しさん** · 2022/02/14(月) 10:38:23.09

書き込んでから思いつきましたが直接やらずに
struct Caller1{void operator()(Sample& sample, int i){sample.func1(int i);}};
...
みたいなのを挟むべきですかねぇ

**デフォルトの名無しさん** · 2022/02/14(月) 10:52:52.11

structの{}内にテンプレートの文全部入れてみ？

**デフォルトの名無しさん** · 2022/02/14(月) 11:13:25.35

毎回 uniform_int_distribution のインスタンスを一時的に生成しては破壊するのを繰り返すのだけはありえんだろ
無意味なメモリのアロケーションありすぎ

**デフォルトの名無しさん** · 2022/02/14(月) 11:16:30.38

#include <iostream>
using namespace std;
struct Sample{
void func1(int i) {cout << i << "," << __PRETTY_FUNCTION__ << endl;}
void func2(int i) {cout << i << "," << __PRETTY_FUNCTION__ << endl;}
};
template<typename T> void SampFunc(Sample& sample, int i, T member_func){
(sample.*member_func)(i);
}
int main() {
Sample s;
SampFunc(s, 1, &Sample::func1);
SampFunc(s, 2, &Sample::func2);
return 0;
}

**デフォルトの名無しさん** · 2022/02/14(月) 11:28:15.31

doubleとfloatの配列を同じように関数の引数に渡して扱う方法ってありますか？
・処理部が複雑なので引数の型が違う関数2個は作りたくない
・IF関数として両方版を作ってそこから処理部を呼び出すみたいな構造は可能、ただし別型版の実体コピー配列などは作りたくない(配列が巨大な為)

考えてみたのが、
配列の値部分をvoid*配列で指したものと、type_infoを持ったクラスなり構造体なりを用意して、
処理部でtype_infoに応じてvoid*をキャスティング、という方法ですが、
どうにも汚いのでもっと綺麗なやり方あれば教えてください。

**デフォルトの名無しさん** · 2022/02/14(月) 11:34:29.03

コードがないので0点

**デフォルトの名無しさん** · 2022/02/14(月) 11:51:48.64

テンプレートでいいだろ

**デフォルトの名無しさん** · 2022/02/14(月) 11:54:11.63

>>900
ふつーにテンプレートじゃね？
template <typename T> requires std::is_floating_point_v<T>
void func(T&& arg)
{
}

あとanyなんて手もあるけど
void func(std::any arg)
{
if(arg.type() == typeid(double)) { }
if(arg.type() == typeid(float)) { }
}

**デフォルトの名無しさん** · 2022/02/14(月) 11:57:58.78

>>900
template<typename T, size_t size>
void f(T(&a)[size]){
}

**デフォルトの名無しさん** · 2022/02/14(月) 12:04:39.18

>>903に便乗してC++20で以下のような書き方も
#include <concept>
template<std::floating_point T>
void func(T && a){}

**デフォルトの名無しさん** · 2022/02/14(月) 12:12:47.83

>>900
まさかとは思うが
float f[2];
std::fill(std::begin(f), std::end(f), 0);

double d[2];
std::fill(std::begin(d), std::end(d), 0);
こんな基本はわかるんだよな？

**デフォルトの名無しさん** · 2022/02/14(月) 13:46:37.17

>>899
ありがとう、採用します 895