[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 1001- 2ch.scのread.cgiへ]
Update time : 02/22 21:10 / Filesize : 275 KB / Number-of Response : 1017
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

C++相談室 part158



1 名前:デフォルトの名無しさん mailto:sage [2021/11/15(月) 18:49:18.44 ID:I69rZ/Of.net]
前スレ
C++相談室 part157
https://mevius.5ch.net/test/read.cgi/tech/1628474251/

820 名前:デフォルトの名無しさん mailto:sage [2022/02/06(日) 12:53:10.29 ID:FF40fIFl.net]
CとC++の規格は既存コードへの忖度の塊で出来てるからな
万人の敵だったgets()を削除するのにどんだけ苦労してるのやら

821 名前:デフォルトの名無しさん mailto:sage [2022/02/06(日) 13:16:26.39 ID:vWDceL4H.net]
>>806>>808
スレに乗っかったつもりにしては
#if f

#endif
というのが含まれて無いようだが?

822 名前:デフォルトの名無しさん mailto:sage [2022/02/06(日) 13:22:45.35 ID:vWDceL4H.net]
>>807
C++規格委員会は無罪なのかもしれんがじゃあなんでC89以前からそうで
そういう挙動が支配的になってしまう事態になってしまったのか、と考えると
やっぱプリプロセッサの最初の設計者がサボって
プリプロセッサ式の途中でのFOOの定義/未定義判定を
define(FOO)を導入する代わりに仕様の方を弄って簡単ハックしてしまったから
のでは……

823 名前:デフォルトの名無しさん mailto:sage [2022/02/06(日) 13:33:49.71 ID:qvD4QsX7.net]
コードを示しても馬鹿には伝わらない悲しみw

824 名前:デフォルトの名無しさん mailto:sage [2022/02/06(日) 13:37:12.22 ID:vWDceL4H.net]
>>812
天才にもわかるようにkwsk

825 名前:デフォルトの名無しさん mailto:sage [2022/02/06(日) 13:39:17.55 ID:qvD4QsX7.net]
天才は自力でなんとか出来るし、他人を信用しないことも多いから、基本的に質問とかする機会がない
アイデアレベルの話のみ

826 名前:デフォルトの名無しさん mailto:sage [2022/02/06(日) 14:11:31.07 ID:Yc7Iwiyd.net]
(σ゚ω゚)σゲッツ
stdioのバッファ使うヤツ殆ど失敗作

827 名前:デフォルトの名無しさん mailto:sage [2022/02/06(日) 14:22:31.03 ID:yFNvdNoT.net]
#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 とか書けとでも?

828 名前:デフォルトの名無しさん mailto:sage [2022/02/06(日) 15:06:24.27 ID:qvD4QsX7.net]
俺のコードのg++やgccをcppに変えればプリプロセスの結果が出るよw オプション引数に-Eを付けても可w
別に不思議でも何でもない結果が表示されるw
$ 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;
$



829 名前:デフォルトの名無しさん mailto:sage [2022/02/06(日) 16:46:37.28 ID:XnD7OQcd.net]
インクルードガード書くときも単に
#define FOO_HPP
とするのと
#define FOO_HPP 1
と1にするのがあるがどちらが良いとかあるんだろうか

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

830 名前:デフォルトの名無しさん mailto:sage [2022/02/06(日) 16:54:43.06 ID:W01LuusE.net]
今から新規に書くなら #pragma once 一択

831 名前:はちみつ餃子 mailto:sage [2022/02/06(日) 17:09:14.27 ID:u7K67HUJ.net]
>>818
私自身は前者にしてる。
インクルードしたことを示すためのフラグとしてのマクロが必要なら
(そういう事例に遭遇したことはないが) ガード用とは別にマクロ定義すると思う。

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

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

832 名前:デフォルトの名無しさん mailto:sage [2022/02/06(日) 17:25:15.43 ID:XnD7OQcd.net]
>>820
ありがとう
納得できる理由です

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

833 名前:はちみつ餃子 mailto:sage [2022/02/06(日) 17:46:04.51 ID:u7K67HUJ.net]
>>821
NDEBUG は「デバッグモードとそうでないモードを切り替える」というのがその用途なので
それに沿うと思ったら分けずに NDEBUG を使うことはあるよ。
でも「NDEBUG の用途は assert の有効・無効の切り替えなので他に使うべきでない」と認識している人がいてもおかしくない。

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

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

834 名前:デフォルトの名無しさん mailto:sage [2022/02/06(日) 19:09:51.99 ID:qvD4QsX7.net]
MS発祥のモノが嫌われてるだけとも思うw

835 名前:デフォルトの名無しさん mailto:sage [2022/02/06(日) 19:46:48.16 ID:XnD7OQcd.net]
>>822
質問の意図がわかりにくくてすみません
自前でフラグ書くなら
>>818の前者と後者どちらを使うのかが知りたかった

836 名前:はちみつ餃子 mailto:sage [2022/02/06(日) 20:08:36.06 ID:u7K67HUJ.net]
>>824
基本的には前者。
フラグとしてのマクロで分岐するときは #if よりも #ifdef (または defined) を使うようにしてる。
マクロは型を付けられないからそうすることで ON/OFF のどちらかであって内容に意味はない
ことを明示してる感じを出したいと思ってる。

837 名前:デフォルトの名無しさん mailto:sage [2022/02/06(日) 20:55:43.12 ID:XnD7OQcd.net]
>>825
改めての回答ありがとうございます

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

838 名前:デフォルトの名無しさん mailto:sage [2022/02/07(月) 06:01:51.26 ID:a2THiWt1.net]
#pragma onceを標準に採用すればええのに
これだけ需要あるのに長年ずっと放置状態
何がそん



839 名前:なに問題なんだろう []
[ここ壊れてます]

840 名前:はちみつ餃子 mailto:sage [2022/02/07(月) 09:54:39.71 ID:T4nofIq4.net]
現行仕様での理屈の立て方としては #include の効果でコードに一体化してから内容の解釈が始まるので
インクルードに干渉する余地がない。
現実にやってるんだから出来るのは間違いないんだけど理屈を根本から変えることになるし、
モジュールが上手くいけばどうでもよくなることに手間をかけたくないんじゃないかな。

841 名前:デフォルトの名無しさん mailto:sage [2022/02/07(月) 11:19:39.20 ID:3u4X3WRg.net]
シンボリックリンクで別のパスになってたりとか、同じ内容の別ファイルとか、ファイル名違う中身同じファイルとか、日付だけ違う別ディレクトリの同じ内容のファイルとか
そんなの考えたくないよなーw

842 名前:はちみつ餃子 mailto:sage [2022/02/07(月) 11:53:54.22 ID:T4nofIq4.net]
名前と実体をどう対応付けるかは今でも処理系定義なのでそこらへんはあまり問題にならないと思う。

843 名前:デフォルトの名無しさん mailto:sage [2022/02/07(月) 11:56:53.41 ID:XrnUHtPA.net]
そこで#pragma onceはヘッダファイルそのものをインクルード済とみなすのではなくて
定義されている内容を定義済みと記憶するのが妥当な動作
なんだけど以下のような場合に困るという、
"a.h"
struct Foo {

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

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

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

844 名前:デフォルトの名無しさん mailto:sage [2022/02/07(月) 12:22:03.46 ID:XrnUHtPA.net]
現行の
#ifdef _FOO_H_
#define _FOO_H_
....
#endif
はヘッダファイルをインクルード済みか否かではなく
マクロ_FOO_H_が定義済みか否かを問題にしているのである意味モジュールに近い
#pragma onceは現行のマイクロソフトのやつはヘッダファイルをインクルード済みか否かを問題にしているので
何をもって同一のヘッダファイルとみなすのかという解釈の揺らぎの影響を受けてしまうまインクルードの挙動が、

845 名前:デフォルトの名無しさん mailto:sage [2022/02/07(月) 12:25:19.77 ID:3u4X3WRg.net]
>>830
だからどう転ぼうと中身で決められる昔ながらの方法の方が結果が明確ということw

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

846 名前:デフォルトの名無しさん mailto:sage [2022/02/07(月) 12:42:43.58 ID:OoGLA1C8.net]
MSの手抜き仕様まで合わせる必要なし

847 名前:デフォルトの名無しさん mailto:sage [2022/02/07(月) 12:56:32.61 ID:3qCWHTEM.net]
でもCに代わってC++が広まったのはMSのおかげじゃん

848 名前:デフォルトの名無しさん mailto:sage [2022/02/07(月) 13:10:46.99 ID:a2THiWt1.net]
ビット数多めのハッシュにしとけば
例えば衝突確率340澗分の1とかにできるよな



849 名前:デフォルトの名無しさん mailto:sage [2022/02/09(水) 12:59:20.15 ID:ioLTStxt.net]
64bit osでポインタ型を4byteにするにはどうすればいいんですか?
8byteだとちょっと大きすぎる気がします

850 名前:デフォルトの名無しさん mailto:sage [2022/02/09(水) 13:03:37.90 ID:IwR5waiE.net]
なぜ大きすぎると思ったのかが分からないが、64bitのアドレス空間を表すのに8 byteは必要だよ

851 名前:デフォルトの名無しさん mailto:sage [2022/02/09(水) 13:08:06.15 ID:PzVUb2uc.net]
>>837
貧乏くさすぎ

852 名前:デフォルトの名無しさん mailto:sage [2022/02/09(水) 13:19:23.53 ID:eAgudC7+.net]
64bit WindowsOSなら32bitアプリにすればok

853 名前:デフォルトの名無しさん mailto:sage [2022/02/09(水) 13:40:55.45 ID:ioLTStxt.net]
例えば64bitの場合アドレスの上位4byteを一意に決めといて下位4byteを4byteの変数に格納しておくってやり方なんてはどうですか?
それで復元時には
(上位4byte << 32) & 下位4byteっていうふうに変換するってふうになると思うんですが
まず最初に上位4byteが一致した連続したメモリ領域から決まってメモリを確保するなんてことはできるのでしょうか?

854 名前:デフォルトの名無しさん mailto:sage [2022/02/09(水) 13:52:00.55 ID:USCqmiY8.net]
必要なメモリをvector<X>で確保しておいて32bit以下のindex値でアクセスすることにすれば?

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

855 名前:デフォルトの名無しさん mailto:sage [2022/02/09(水) 13:52:47.57 ID:E/6u1YW1.net]
long long ago... タイニー、スモール、コンパクト、ミディアム、ラージ、ヒュージつーのがあってだな

856 名前:デフォルトの名無しさん mailto:sage [2022/02/09(水) 14:26:32.14 ID:ioLTStxt.net]
>>842
そうすることにします
ありがとうございました

857 名前:デフォルトの名無しさん mailto:sage [2022/02/09(水) 14:34:15.15 ID:PzVUb2uc.net]
関数ポインタかなんかが8バイトに収まってなくて混乱したことがあったっけ

858 名前:デフォルトの名無しさん mailto:sage [2022/02/09(水) 14:37:12.22 ID:Jq7h8mT9.net]
昔は16bitポインタと32bitポインタをLPとPで使い分けてたって戦争で死んだおじいちゃんに聞いた



859 名前:デフォルトの名無しさん mailto:sage [2022/02/09(水) 17:17:57.87 ID:SS+/CtsS.net]
segment:offset時代か・・・

860 名前:デフォルトの名無しさん mailto:sage [2022/02/09(水) 18:17:45.02 ID:t2vkJvVR.net]
アセンブラの相対ショートジャンプは8ビット

861 名前:デフォルトの名無しさん mailto:sage [2022/02/09(水) 22:34:51.11 ID:9agulkW+.net]
ウィンドーズならINT_PTR使っとけばおkオール無問題
C++の標準規格でどうなっているのかわ知らん

862 名前:はちみつ餃子 mailto:sage [2022/02/09(水) 23:19:57.51 ID:9Cj+df9g.net]
規格上は std::intptr_t というものがある。
ただし関数ポインタやメンバ関数ポインタを格納できるとは限らない。
また、省略可能 (optional) であると明記されているので無くても規格準拠たりうる。

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

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

863 名前:デフォルトの名無しさん mailto:sage [2022/02/10(木) 02:00:13.27 ID:vaE+JZMI.net]
>>843
far/near を直接指定すれはすむ話、メモリモデルなんてどうでもいい

864 名前:デフォルトの名無しさん mailto:sage [2022/02/10(木) 19:32:52.48 ID:OsDlZl05.net]
effective C++って現行のC++と比べてどのあたりが古いんですか?
代表的なところとかだけでも教えてくれると嬉しいです

865 名前:デフォルトの名無しさん mailto:sage [2022/02/10(木) 19:38:59.22 ID:NUzD8R/O.net]
全て

866 名前:デフォルトの名無しさん mailto:sage [2022/02/10(木) 20:00:39.81 ID:qtJUe0L+.net]
出版1998年やんけ
こんなもん使うぐらいならC言語やった方がマシなレベル

867 名前:デフォルトの名無しさん mailto:sage [2022/02/10(木) 20:11:39.77 ID:OsDlZl05.net]
>>854
一応第3版は原書が2005年に書かれています…

868 名前:デフォルトの名無しさん mailto:sage [2022/02/10(木) 20:20:25.92 ID:ZkLGowhi.net]
続編のeffective modern c++も古いけど、
こっちは隕石落下後の本だから読んでおいたほうがいいよ



869 名前:デフォルトの名無しさん mailto:sage [2022/02/10(木) 21:18:10.31 ID:OsDlZl05.net]
隕石落下後ってなんすか?
あとC++の勉強するならこの本読め、みたいなのって他にもありますか?

870 名前:デフォルトの名無しさん mailto:sage [2022/02/10(木) 21:38:32.90 ID:ty8Wss5J.net]
2005年でも古いなあ
C++98, 03, 11(0x), 14, 17, 20 と5回バージョンアップあるし
そのたびに標準ライブラリが更新されてる

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

871 名前:デフォルトの名無しさん mailto:sage [2022/02/10(木) 21:44:00.87 ID:Qcxer4Pv.net]
今更auto_ptr使うなとか言われても何の役にも立たないからな

872 名前:デフォルトの名無しさん mailto:sage [2022/02/10(木) 23:48:22.57 ID:jkDJeeU1.net]
べつに使ってもいいんだよ
使い方さえ間違えなければ

873 名前:デフォルトの名無しさん mailto:sage [2022/02/11(金) 00:26:40.18 ID:3fYQCkDW.net]
使うことが間違いでは?

874 名前:デフォルトの名無しさん mailto:sage [2022/02/11(金) 04:33:24.42 ID:ajov4Ad8.net]
左辺値参照で無理やりムーブ作ったやつね

875 名前:デフォルトの名無しさん mailto:sage [2022/02/11(金) 06:13:41.97 ID:ycfpInN1.net]
仕様のバージョンは普通自分で選ぶもんじゃないので、古いことを知るのだって意味はある
逆にどの辺が古い、というのが分かってもあまり意味ない

876 名前:デフォルトの名無しさん mailto:sage [2022/02/13(日) 06:29:47.80 ID:DI/GcuLa.net]
いろんな範囲で一様乱数を次々と生成したいときってどうしますか?
uniform_int_distribution の範囲を次々と param で変える?
あるいは、妥協して剰余をとる形で範囲を変える?

877 名前:デフォルトの名無しさん mailto:sage [2022/02/13(日) 06:32:11.91 ID:DI/GcuLa.net]
あるいは、uniform_int_distribution を次々と生成して使い捨てる?

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

878 名前:デフォルトの名無しさん mailto:sage [2022/02/13(日) 06:51:44.09 ID:rfXE6dHR.net]
色々手はあるね
「いろんな範囲」の個数が決まっているならuniform_int_distributionの配列にするもよし
ランダムならparamもよし

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



879 名前:デフォルトの名無しさん mailto:sage [2022/02/13(日) 07:21:47.95 ID:JnTPIF3C.net]
>>865
同じ範囲を何回も使うならその分distributionを用意する、そうでないならparamを変えていくのが良さそうに思います。が、たぶん実行時の差はほぼ無いです。
いちおう関数の定数を書き換えていくかメモリ上に予めたくさん用意するかの違いとして判断しました。
計算重いのは大抵は乱数生成の方だと思うので、速くしたいならそっちをとりかえたほうがいいと思います。

880 名前:デフォルトの名無しさん mailto:sage [2022/02/13(日) 07:48:28.31 ID:rfXE6dHR.net]
メルセンヌツイスターの売りの1つが速度がそんなに遅くない点だね

881 名前:デフォルトの名無しさん mailto:sage [2022/02/13(日) 10:06:40.11 ID:+NRIy/Ul.net]
なんで剰余を取るのが妥協なん?

882 名前:デフォルトの名無しさん mailto:sage [2022/02/13(日) 10:33:38.50 ID:SeV3jiEK.net]
一様性が一般に崩れるから

883 名前:デフォルトの名無しさん mailto:sage [2022/02/13(日) 10:37:30.83 ID:SeV3jiEK.net]
個人的にはこうやってみたりしてゐる、

/// 閉区間[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();
//print

884 名前:f("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;
}
[]
[ここ壊れてます]

885 名前:デフォルトの名無しさん mailto:sage [2022/02/13(日) 10:52:20.14 ID:cIrOgCom.net]
標準ライブラリ使わんの?

886 名前:はちみつ餃子 mailto:sage [2022/02/13(日) 11:12:52.07 ID:nD0XyBZB.net]
>>869
分かり易い例として 0 から 9 の一様な乱数列を生成するものを考えてみればいい。
このとき 0 から 7 の値が必要だからといって 8 の余剰を取ったらどうなる?
8, 9 が 0, 1 になるから 0 と 1 の出現確率が他の倍になってしまうだろ。

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

887 名前:はちみつ餃子 mailto:sage [2022/02/13(日) 11:15:35.52 ID:nD0XyBZB.net]
>>872
呼出しのたびに必要な範囲が違うような Distribution が標準に無いという文脈

888 名前:ハノン mailto:sage [2022/02/13(日) 12:39:58.09 ID:1UprWsoO.net]
>>873
それもあるけれども、昔の擬似乱数列は絶望的なまでに下位桁がランダムではない、という事情をひきずっているのでは?まあ MT はそうじゃないけどね



889 名前:デフォルトの名無しさん mailto:sage [2022/02/13(日) 13:09:41.79 ID:+NRIy/Ul.net]
>>873
そらもちろん、元がそんな狭い範囲ならだめでしょ
あとまあ昔のrand的には割ってかけるのが正しいというのはあるけどそれは別の話で

890 名前:デフォルトの名無しさん mailto:sage [2022/02/13(日) 13:37:58.02 ID:PyRRUUG6.net]
C++何の関係もない話で草
検証が必要ならすればいいだけ
要件すら不明で何もしてないのに質問するやつが馬鹿

891 名前:はちみつ餃子 mailto:sage [2022/02/13(日) 14:27:27.60 ID:nD0XyBZB.net]
>>876
> 元がそんな狭い範囲ならだめでしょ

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

892 名前:デフォルトの名無しさん mailto:sage [2022/02/13(日) 15:14:31.28 ID:GfZrXG+U.net]
任意の区間の乱数って、どうせはみ出した分をちょん切るんでしょ?

893 名前:はちみつ餃子 mailto:sage [2022/02/13(日) 15:18:24.06 ID:nD0XyBZB.net]
せやで。

894 名前:デフォルトの名無しさん mailto:sage [2022/02/13(日) 15:25:43.89 ID:CS3pmCmc.net]
そんな短い周期の疑似乱数使ってないんじゃない?
端っこは気にしないと思うなあ

895 名前:デフォルトの名無しさん mailto:sage [2022/02/13(日) 16:00:39.64 ID:yoBtg/nD.net]
>>876
> そらもちろん、元がそんな狭い範囲ならだめでしょ
「分かり易い例」って書いてあるのも理解できないの?

896 名前:デフォルトの名無しさん mailto:sage [2022/02/13(日) 16:06:17.09 ID:CS3pmCmc.net]
一般論でいうと周期に余裕がない様な疑似乱数使うのが間違いなんだと思うけどね

897 名前:デフォルトの名無しさん mailto:sage [2022/02/13(日) 16:19:57.08 ID:kSk9XozZ.net]
そういうのを乱数知識ない奴が触らずに済むようにパッケージにしたのが<random>のdistributionなんだから素直に頼っとけよ

898 名前:デフォルトの名無しさん mailto:sage [2022/02/13(日) 16:42:35.21 ID:JnTPIF3C.net]
周期と値域は別では



899 名前:デフォルトの名無しさん mailto:sage [2022/02/13(日) 16:56:02.36 ID:KditTIA5.net]
>>885
内部的にはおおむね同じです

900 名前:はちみつ餃子 mailto:sage [2022/02/13(日) 17:04:20.08 ID:nD0XyBZB.net]
線形合同法とかなら値の範囲と周期が一致することもあるが、乱数の一般的性質というわけではない。

901 名前:デフォルトの名無しさん mailto:sage [2022/02/13(日) 17:59:20.78 ID:av/6iEu7.net]
周期と値域は別だろ
たとえばマイナス一億と、プラス一億の2値をとる乱数とか

902 名前:デフォルトの名無しさん mailto:sage [2022/02/13(日) 18:15:27.44 ID:AOBvb97v.net]
疑似乱数なんて今の値で次の値が決まるんだから周期も値も同じだろう
その値の一部を使ったらまあ見た目は減るだろうけど

903 名前:デフォルトの名無しさん mailto:sage [2022/02/13(日) 18:32:37.88 ID:3OIdnfKh.net]
値域: 出力される値の範囲
周期: そのまんま乱数の出力が1周するステップ数

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

904 名前:はちみつ餃子 mailto:sage [2022/02/13(日) 18:34:40.46 ID:nD0XyBZB.net]
>>889
内部状態と結果を分離する方式だって当然あるよ。
メルセンヌツイスタのどでかい内部状態を毎回値として利用するわけないし、
乱数として利用できる性質になってない。

905 名前:デフォルトの名無しさん mailto:sage [2022/02/13(日) 18:34:49.25 ID:AOBvb97v.net]
さすがにマジの最大値と最小値なんて誰も問題にしとらんやろ

906 名前:デフォルトの名無しさん mailto:sage [2022/02/13(日) 18:38:19.35 ID:mUIDTArd.net]
>>892
その思い込みで「値域」と「内部状態の大きさ」をごっちゃにしてるから話がこじれてたんでしょ。
区別して。

907 名前:デフォルトの名無しさん mailto:sage [2022/02/13(日) 18:55:00.53 ID:RJAwRgrO.net]
端っこにゴミがあるよりは歯抜けが散らばってる方がいいというのは一理あるね

908 名前:デフォルトの名無しさん mailto:sage [2022/02/14(月) 10:33:59.04 ID:14KvXXq2.net]
メンバー関数をテンプレートに出来たりしませんかね?

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 ホゲホゲって感じですが



909 名前:デフォルトの名無しさん mailto:sage [2022/02/14(月) 10:38:23.09 ID:14KvXXq2.net]
書き込んでから思いつきましたが直接やらずに
struct Caller1{void operator()(Sample& sample, int i){sample.func1(int i);}};
...
みたいなのを挟むべきですかねぇ

910 名前:デフォルトの名無しさん mailto:sage [2022/02/14(月) 10:52:52.11 ID:Z549+Tcq.net]
structの{}内にテンプレートの文全部入れてみ?

911 名前:デフォルトの名無しさん mailto:sage [2022/02/14(月) 11:13:25.35 ID:o9A3FVGP.net]
毎回 uniform_int_distribution のインスタンスを一時的に生成しては破壊するのを繰り返すのだけはありえんだろ
無意味なメモリのアロケーションありすぎ

912 名前:デフォルトの名無しさん mailto:sage [2022/02/14(月) 11:16:30.38 ID:lu0CYRrt.net]
#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;
}

913 名前:デフォルトの名無しさん mailto:sage [2022/02/14(月) 11:28:15.31 ID:s3l2ZTMb.net]
doubleとfloatの配列を同じように関数の引数に渡して扱う方法ってありますか?
・処理部が複雑なので引数の型が違う関数2個は作りたくない
・IF関数として両方版を作ってそこから処理部を呼び出すみたいな構造は可能、ただし別型版の実体コピー配列などは作りたくない(配列が巨大な為)

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

914 名前:デフォルトの名無しさん mailto:sage [2022/02/14(月) 11:34:29.03 ID:lu0CYRrt.net]
コードがないので0点

915 名前:デフォルトの名無しさん mailto:sage [2022/02/14(月) 11:51:48.64 ID:MNwZvUCy.net]
テンプレートでいいだろ

916 名前:デフォルトの名無しさん mailto:sage [2022/02/14(月) 11:54:11.63 ID:L8LvhIeL.net]
>>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)) { }
}

917 名前:デフォルトの名無しさん mailto:sage [2022/02/14(月) 11:57:58.78 ID:81yRYH7R.net]
>>900
template<typename T, size_t size>
void f(T(&a)[size]){
}

918 名前:デフォルトの名無しさん mailto:sage [2022/02/14(月) 12:04:39.18 ID:Z549+Tcq.net]
>>903に便乗してC++20で以下のような書き方も
#include <concept>
template<std::floating_point T>
void func(T && a){}



919 名前:デフォルトの名無しさん mailto:sage [2022/02/14(月) 12:12:47.83 ID:L8LvhIeL.net]
>>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);
こんな基本はわかるんだよな?

920 名前:デフォルトの名無しさん mailto:sage [2022/02/14(月) 13:46:37.17 ID:nlxkZZlr.net]
>>899
ありがとう、採用します 895






[ 続きを読む ] / [ 携帯版 ]

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<275KB

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef