C++相談室 part158

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

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

**はちみつ餃子** ◆8X2XSCHEME · 2022/02/05(土) 20:31:08.99

>>785
#if の条件の部分ではマクロ展開できるものを全部展開したあとに知らない識別子が残ったら 0 と解釈する。

**デフォルトの名無しさん** · 2022/02/05(土) 20:32:57.42

>>785
FOO に () が無いことで展開されず、マクロ展開後に残った識別子として 0 に置き換わってる。
https://timsong-cpp.github.io/cppwp/n4868/cpp.cond#11.sentence-1
> After all replacements ..., all remaining identifiers and keywords,
> except for true and false, are replaced with the pp-number 0, ...

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

>>785
バカですか？

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

#if defined(FOO)
...
#endif

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

Cの基本が出来てないくせにC++を使いこなせると思うなよ

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

横からだけど知らなかった

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

>>786
>>787
ありがとうございます
このルールは知りませんでした

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

こういう馬鹿のためにコンパイラに無駄なルールが必要になるんだなと実感

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

エラーにならないのは理不尽だな

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

馬鹿のためにわざわざプリプロセスで構文解析エラーを要求するとか馬鹿の極み

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

FOOが0になる根拠を与えていないだろ
関連付けられていないものが出てくるのがおかしいと思わないとしたらPG適性低いぞ

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

唐突に0がどうとか言い出すのはセンス無いわ

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

初めて知った

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

>>797
>>786

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

馬鹿は当たり前のように英語も読めない

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

なんじゃそりゃ>>799はC++規格委員会が死ね言うたら死ぬんか、

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

規格書にはなんでそうなっているのか（置換されずに残ったFOOをエラーではなく0にするのか）の理由が書かれていないが
#ifdef defined(FOO) && FOO
として現れる論理式「defined(FOO) && FOO」の解釈を簡単にやりたい（FOOが未定義の場合でも通常の式の解釈ルーチンで処理したい
的なしょーもない理由だったりして……

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

まつがえたorz
×： #ifdef defined(FOO) && FOO
○： #if defined(FOO) && FOO

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

>>801
唐突じゃないことを示したまで
事実関係をよく確認してからセンス無いとかドヤれってこと

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

理由はたぶん、規格化以前に存在した実装の動作を規格違反とするのはマズいとか、
その動作に依存して #if FOO としてる既存ソースをエラーとするわけにはいかなかったとか、
そんなところだろうと思う。

マズい動作として検出したければ警告は出せるんだし。

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

馬鹿がまだ騒いでるのかｗ
こういう変なコードとの対比ｗ
$ g++ -x c++ - <<EOF
auto f = [](){return 2;};
#define f() 1
int main() {
auto i = f();
auto j = f;
return i + j();
}
EOF
$ ./a.out
$ echo $?
3
$

**はちみつ餃子** ◆8X2XSCHEME · 2022/02/06(日) 12:12:45.00

残った識別子を 0 に解釈する挙動は C89 からの仕様だから C89 の Rationale (根拠) を見たんだけど直接的な言及は見つからない。
https://docs.google.com/viewer?a=v&;pid=explorer&chrome=true&srcid=0BxVCLS4f8Sg5NWZmM2NjZWEtYmExMS00Y2EzLWE3ZTMtNzFmYjYwYzBiOTIw&hl=en_US
ただ、既存のコードに差し障りがないようにということは明記してある (3.8.3) ので、
その時点でそういう挙動が支配的 (かつそれに依存するコードが多かった) のだろうとは察せられる。

規格ってのは統一を図るってのが第一の目的だけど無理な仕様でまとめちゃうと誰もその規格に従わないだけなんで、
現実にそれでやっているってのも (たとえ不格好でも) 十分な理由になるんだよ。

**デフォルトの名無しさん** · 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

周期と値域は別では