I just wanted to give a set a load-factor of +Inf. So I just wrote
1.0f / 0.0f to prevent numeric_limits<float>::infinity() because
the first is shorter. MSVC took this as an error but clang++ and
clang-cl accepted the code. Which compiler is right ?
On 29/12/2021 19:00, Bonita Montero wrote:
I just wanted to give a set a load-factor of +Inf. So I just wrote
1.0f / 0.0f to prevent numeric_limits<float>::infinity() because
the first is shorter. MSVC took this as an error but clang++ and
clang-cl accepted the code. Which compiler is right ?
In mathematics, a number divided by zero is undefined.
So I would say MSVC is correct though it should have simply said <Nan>.
I just wanted to give a set a load-factor of +Inf. So I just wrote
1.0f / 0.0f to prevent numeric_limits<float>::infinity() because
the first is shorter. MSVC took this as an error but clang++ and
clang-cl accepted the code. Which compiler is right ?
On Wednesday, December 29, 2021 at 2:00:21 PM UTC-5, Bonita Montero wrote:
So I just wroteBoth are right. "If the second operand of / or % is zero the behavior
1.0f / 0.0f ... MSVC took this as an error but clang++ and
clang-cl accepted the code. Which compiler is right ?
is undefined." (7.6.5p4). When the behavior is undefined, there's
no wrong way to handle it. In particular, it's permitted to implement
ISO/IEC 60559 (== IEEE 754) semantics. I won't be able to check
my copy of that standard until Monday, but off the top of my head,
I think it specifies that division by 0 results in an infinity with the
same sign as the numerator.
I just wanted to give a set a load-factor of +Inf. So I just wrote
1.0f / 0.0f to prevent numeric_limits<float>::infinity() because
the first is shorter. MSVC took this as an error but clang++ and
clang-cl accepted the code. Which compiler is right ?
29.12.2021 21:00 Bonita Montero kirjutas:
I just wanted to give a set a load-factor of +Inf. So I just wroteNot sure which one is right, but here is a workaround;-) It's shorter
1.0f / 0.0f to prevent numeric_limits<float>::infinity() because
the first is shorter. MSVC took this as an error but clang++ and
clang-cl accepted the code. Which compiler is right ?
than std::numeric_limits<float>::infinity(), isn't it?
float x = 1.f/[](){return 0.f;}();
I just wanted to give a set a load-factor of +Inf. So I just wrote
1.0f / 0.0f to prevent numeric_limits<float>::infinity() because
the first is shorter. MSVC took this as an error but clang++ and
clang-cl accepted the code. Which compiler is right ?
If all you want is a compact expression, why not HUGE_VAL, HUGE_VALF, HUGE_VALL from <cmath> (aka <math.h>)?
On Thursday, December 30, 2021 at 12:48:26 PM UTC-5, Manfred wrote:
If all you want is a compact expression, why not HUGE_VAL, HUGE_VALF,
HUGE_VALL from <cmath> (aka <math.h>)?
Why not INFINITY from math.h?
On 12/30/2021 7:16 PM, daniel...@gmail.com wrote:
On Thursday, December 30, 2021 at 12:48:26 PM UTC-5, Manfred wrote:
If all you want is a compact expression, why not HUGE_VAL, HUGE_VALF,
HUGE_VALL from <cmath> (aka <math.h>)?
Why not INFINITY from math.h?
Also possible, yes.
On Thu, 30 Dec 2021 20:02:21 +0100
Manfred <noname@add.invalid> wrote:
On 12/30/2021 7:16 PM, daniel...@gmail.com wrote:
On Thursday, December 30, 2021 at 12:48:26 PM UTC-5, Manfred wrote:
If all you want is a compact expression, why not HUGE_VAL, HUGE_VALF,
HUGE_VALL from <cmath> (aka <math.h>)?
Why not INFINITY from math.h?
Also possible, yes.
Certainly all better than some ugly divide by zero hack.
namespace my
{
static constexpr float inf = std::numeric_limits<float>::infinity();
}
Manfred <noname@add.invalid> wrote:
namespace my
{
static constexpr float inf = std::numeric_limits<float>::infinity();
}
I don't think a constexpr variable needs to be 'static'.
On 1/2/2022 10:21 PM, Juha Nieminen wrote:
Manfred <noname@add.invalid> wrote:
namespace my
{
static constexpr float inf = std::numeric_limits<float>::infinity(); >>> }
I don't think a constexpr variable needs to be 'static'.
Yeah, don't they have internal linkage by default, like const does?
Still, in a class definition `static` means something else than above,
and can't be omitted for a `constexpr` data member.
That's unreasonable to me: the language /requiring/ you to write a meaningless filler word, a word that can't be omitted but carries no
extra meaning and doesn't help the compiler's parsing. As I see it `constexpr` for data should also have implied static storage duration.
It's gut-wrenching that it does not.
On 3 Jan 2022 09:11, red floyd wrote:
On 1/2/2022 10:21 PM, Juha Nieminen wrote:
Manfred <noname@add.invalid> wrote:
namespace my
{
static constexpr float inf = std::numeric_limits<float>::infinity(); >>>> }
I don't think a constexpr variable needs to be 'static'.
Yeah, don't they have internal linkage by default, like const does?
Yes, `constexpr` implies (drags in) `inline` and `const`.
Still, in a class definition `static` means something else than above,
and can't be omitted for a `constexpr` data member.
That's unreasonable to me: the language /requiring/ you to write a >meaningless filler word, a word that can't be omitted but carries no
extra meaning and doesn't help the compiler's parsing. As I see it
On Mon, 3 Jan 2022 09:28:25 +0100
"Alf P. Steinbach" <alf.p.steinbach@gmail.com> wrote:
On 3 Jan 2022 09:11, red floyd wrote:
On 1/2/2022 10:21 PM, Juha Nieminen wrote:
Manfred <noname@add.invalid> wrote:
namespace my
{
static constexpr float inf = std::numeric_limits<float>::infinity(); >>>>> }
I don't think a constexpr variable needs to be 'static'.
Yeah, don't they have internal linkage by default, like const does?
Yes, `constexpr` implies (drags in) `inline` and `const`.
Still, in a class definition `static` means something else than above,
and can't be omitted for a `constexpr` data member.
That's unreasonable to me: the language /requiring/ you to write a
meaningless filler word, a word that can't be omitted but carries no
extra meaning and doesn't help the compiler's parsing. As I see it
In a similar vein, why does C++ still insist on class static values being set outside of the class? eg:
struct myclass
{
static int i;
};
int myclass::i = 123;
Why on earth can't I just do:
struct myclass
{
static int i = 123;
};
in the same way that const members are initialised? I've never seen a good reason why it must be this way and it makes for messy header files.
On 03/01/2022 10:24, Muttley@dastardlyhq.com wrote:
in the same way that const members are initialised? I've never seen a good >> reason why it must be this way and it makes for messy header files.
struct myclass
{
inline static int i = 123;
};
This has been valid since C++17, along with inline variables. (Why do
you need "inline" here? Good question, and I hope someone else can
geive a good answer!)
On 03/01/2022 10:24, Muttley@dastardlyhq.com wrote:
Why on earth can't I just do:
struct myclass
{
static int i = 123;
};
in the same way that const members are initialised? I've never seen a good >> reason why it must be this way and it makes for messy header files.
struct myclass
{
inline static int i = 123;
};
This has been valid since C++17, along with inline variables. (Why do
you need "inline" here? Good question, and I hope someone else can
give a good answer!)
On 1/2/2022 10:21 PM, Juha Nieminen wrote:
Manfred <noname@add.invalid> wrote:
namespace my
{
static constexpr float inf = std::numeric_limits<float>::infinity(); >>> }
I don't think a constexpr variable needs to be 'static'.
Yeah, don't they have internal linkage by default, like const does?
In a similar vein, why does C++ still insist on class static values being set outside of the class? eg:
struct myclass
{
static int i;
};
int myclass::i = 123;
Why on earth can't I just do:
struct myclass
{
static int i = 123;
};
in the same way that const members are initialised? I've never seen a good reason why it must be this way and it makes for messy header files.
On 1/3/2022 9:11 AM, red floyd wrote:
On 1/2/2022 10:21 PM, Juha Nieminen wrote:
Manfred <non...@add.invalid> wrote:
namespace my
{
static constexpr float inf = std::numeric_limits<float>::infinity(); >>> }
I don't think a constexpr variable needs to be 'static'.
Yeah, don't they have internal linkage by default, like const does?That's true, but I still like to be explicit, since 'static' and 'const'
mean different things.
The irony is that this is probably one of those examples where C beats
C++ - good ol' HUGE_VALF or INFINITE would raise no question at all!
David Brown <david.brown@hesbynett.no> writes:
On 03/01/2022 10:24, Muttley@dastardlyhq.com wrote:
Why on earth can't I just do:
struct myclass
{
static int i = 123;
};
in the same way that const members are initialised? I've never seen a good >>> reason why it must be this way and it makes for messy header files.
struct myclass
{
inline static int i = 123;
};
This has been valid since C++17, along with inline variables. (Why do
you need "inline" here? Good question, and I hope someone else can
give a good answer!)
Probably for backward compatability. Note that historically C++ was >translated to C then compiled (e.g. cfront). Trying to do the static >initialization in the class definition would result in linker errors
due to duplicate definitions of the static variable when the class
definition is include by multiple compilation units. Hence the requirement >to declare it in a single compilation unit.
The irony is that this is probably one of those examples where C beats
C++ - good ol' HUGE_VALF or INFINITE would raise no question at all!
Manfred <noname@add.invalid> wrote:
The irony is that this is probably one of those examples where C beats
C++ - good ol' HUGE_VALF or INFINITE would raise no question at all!
What is the type of INFINITE? What if you want it as one of the other two floating point types? (Is casting defined in this case?)
Muttley@dastardlyhq.com wrote:
In a similar vein, why does C++ still insist on class static values being set
outside of the class? eg:
struct myclass
{
static int i;
};
int myclass::i = 123;
Why on earth can't I just do:
struct myclass
{
static int i = 123;
};
As you probably know, 'static' variables declared inside a class aren't >actually member variables, but free-floating variables which visibility
scope is inside that class (the term "class variable" is often used for
these types of variables, in many OO languages, as opposed to "member >variable").
The 'static int i;' in the class definition is just a declaration, and
it needs to be actually defined, ie. instantiated somewhere, in one
(and only one) compilation unit. If you don't instantiate it somewhere
the compiler will be unable to decide where to instantiate it and you'll
get a linker error because it has only been declared but not instantiated
in any compilation unit.
C++17 extended the 'inline' functionality, which does that automatically
for you (so that you don't have to instantiate the variable by hand),
but prior to it you had to do it yourself.
I suppose that when C++98 was standardized it was decided that it's
better to specify the initial value of that 'static' variable where
it's instantiated rather than where it's declared. (I suppose that
technically speaking it wouldn't be hard for compilers to look up
the initial value from either one, because to instantiate the variable
it needs to see the declaration.) Perhaps it was thought that it causes
less confusion because if it's initialized in the declaration it may
look like it will be initialized to that value every time the class
is instantiated (which, of course, is not the case).
I don't think const member variables can be initialized in the class >definition in C++98. That syntax was only introduced in C++11.
On Tuesday, 4 January 2022 at 00:15:10 UTC+2, Manfred wrote:No, I'm talking about these questions about 'static', 'const',
On 1/3/2022 9:11 AM, red floyd wrote:
On 1/2/2022 10:21 PM, Juha Nieminen wrote:That's true, but I still like to be explicit, since 'static' and 'const'
Manfred <non...@add.invalid> wrote:
namespace my
{
static constexpr float inf = std::numeric_limits<float>::infinity(); >>>>> }
I don't think a constexpr variable needs to be 'static'.
Yeah, don't they have internal linkage by default, like const does?
mean different things.
The irony is that this is probably one of those examples where C beats
C++ - good ol' HUGE_VALF or INFINITE would raise no question at all!
The std::numeric_limits<float>::infinity() does not raise questions
in actual programs either. It is infinity of float, very explicitly.
Issues of BM with it are pseudo-issues. Too lot of characters?
WTF? Did the hard drive get full? Name some local constant
like "beyond_horizon" or something. Next BM needs to output it to
json as number and then what? Runs away crying?
Muttley@dastardlyhq.com writes:
On Mon, 03 Jan 2022 17:40:28 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
David Brown <david.brown@hesbynett.no> writes:
On 03/01/2022 10:24, Muttley@dastardlyhq.com wrote:
Why on earth can't I just do:
struct myclass
{
static int i = 123;
};
in the same way that const members are initialised? I've never seen a good
reason why it must be this way and it makes for messy header files.
struct myclass
{
inline static int i = 123;
};
This has been valid since C++17, along with inline variables. (Why do >>>>you need "inline" here? Good question, and I hope someone else can >>>>give a good answer!)
Probably for backward compatability. Note that historically C++ was >>>translated to C then compiled (e.g. cfront). Trying to do the static >>>initialization in the class definition would result in linker errors
due to duplicate definitions of the static variable when the class >>>definition is include by multiple compilation units. Hence the requirement >>>to declare it in a single compilation unit.
C++ hasn't been translated into C for 25 years at least. Keeping this >syntatic
quirk for so long rather demonstrates the C++ committee are more interested >in
adding shiny shiny "fun" stuff to the language that they find interesting >>rather than improving it for normal developers.
Of course, they did "fix" it - in a backward compatible way - in C++17, right?
On Mon, 03 Jan 2022 17:40:28 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
David Brown <david.brown@hesbynett.no> writes:
On 03/01/2022 10:24, Muttley@dastardlyhq.com wrote:
Why on earth can't I just do:
struct myclass
{
static int i = 123;
};
in the same way that const members are initialised? I've never seen a good >>>> reason why it must be this way and it makes for messy header files.
struct myclass
{
inline static int i = 123;
};
This has been valid since C++17, along with inline variables. (Why do >>>you need "inline" here? Good question, and I hope someone else can
give a good answer!)
Probably for backward compatability. Note that historically C++ was >>translated to C then compiled (e.g. cfront). Trying to do the static >>initialization in the class definition would result in linker errors
due to duplicate definitions of the static variable when the class >>definition is include by multiple compilation units. Hence the requirement >>to declare it in a single compilation unit.
C++ hasn't been translated into C for 25 years at least. Keeping this syntatic >quirk for so long rather demonstrates the C++ committee are more interested in >adding shiny shiny "fun" stuff to the language that they find interesting >rather than improving it for normal developers.
On 1/4/2022 8:50 AM, Öö Tiib wrote:
On Tuesday, 4 January 2022 at 00:15:10 UTC+2, Manfred wrote:
On 1/3/2022 9:11 AM, red floyd wrote:
On 1/2/2022 10:21 PM, Juha Nieminen wrote:That's true, but I still like to be explicit, since 'static' and 'const' >> mean different things.
Manfred <non...@add.invalid> wrote:
namespace my
{
static constexpr float inf = std::numeric_limits<float>::infinity(); >>>>> }
I don't think a constexpr variable needs to be 'static'.
Yeah, don't they have internal linkage by default, like const does?
The irony is that this is probably one of those examples where C beats
C++ - good ol' HUGE_VALF or INFINITE would raise no question at all!
The std::numeric_limits<float>::infinity() does not raise questionsNo, I'm talking about these questions about 'static', 'const',
in actual programs either. It is infinity of float, very explicitly.
'constexpr' and similar entertainment. In C INFINITE and HUGE_VAL are "constant expressions", and that is it - good for any purpose.
Issues of BM with it are pseudo-issues. Too lot of characters?
WTF? Did the hard drive get full? Name some local constant
like "beyond_horizon" or something. Next BM needs to output it to
json as number and then what? Runs away crying?
On Tuesday, 4 January 2022 at 11:43:12 UTC+2, Manfred wrote:
On 1/4/2022 8:50 AM, Öö Tiib wrote:
On Tuesday, 4 January 2022 at 00:15:10 UTC+2, Manfred wrote:No, I'm talking about these questions about 'static', 'const',
On 1/3/2022 9:11 AM, red floyd wrote:
On 1/2/2022 10:21 PM, Juha Nieminen wrote:That's true, but I still like to be explicit, since 'static' and 'const' >>>> mean different things.
Manfred <non...@add.invalid> wrote:
namespace my
{
static constexpr float inf = std::numeric_limits<float>::infinity(); >>>>>>> }
I don't think a constexpr variable needs to be 'static'.
Yeah, don't they have internal linkage by default, like const does?
The irony is that this is probably one of those examples where C beats >>>> C++ - good ol' HUGE_VALF or INFINITE would raise no question at all!
The std::numeric_limits<float>::infinity() does not raise questions
in actual programs either. It is infinity of float, very explicitly.
'constexpr' and similar entertainment. In C INFINITE and HUGE_VAL are
"constant expressions", and that is it - good for any purpose.
Then I'm lost ... std::numeric_limits<float>::infinity() IS constant expression
and that is it, good for any purpose.
And obviously, if you really want it C++ish
namespace my
{
static constexpr float inf = std::numeric_limits<float>::infinity();
}
/* use my::inf wherever you like */
Issues of BM with it are pseudo-issues. Too lot of characters?
WTF? Did the hard drive get full? Name some local constant
like "beyond_horizon" or something. Next BM needs to output it to
json as number and then what? Runs away crying?
On 1/4/22 7:15 PM, Öö Tiib wrote:
On Tuesday, 4 January 2022 at 11:43:12 UTC+2, Manfred wrote:
On 1/4/2022 8:50 AM, Öö Tiib wrote:
On Tuesday, 4 January 2022 at 00:15:10 UTC+2, Manfred wrote:No, I'm talking about these questions about 'static', 'const',
On 1/3/2022 9:11 AM, red floyd wrote:The std::numeric_limits<float>::infinity() does not raise questions
On 1/2/2022 10:21 PM, Juha Nieminen wrote:mean different things.
Manfred <non...@add.invalid> wrote:
namespace my
{
static constexpr float inf = std::numeric_limits<float>::infinity(); >>>>>>> }
I don't think a constexpr variable needs to be 'static'.
Yeah, don't they have internal linkage by default, like const does? >>>> That's true, but I still like to be explicit, since 'static' and 'const'
The irony is that this is probably one of those examples where C beats >>>> C++ - good ol' HUGE_VALF or INFINITE would raise no question at all! >>>
in actual programs either. It is infinity of float, very explicitly.
'constexpr' and similar entertainment. In C INFINITE and HUGE_VAL are
"constant expressions", and that is it - good for any purpose.
Then I'm lost ... std::numeric_limits<float>::infinity() IS constant expressionI'll try and lend you a compass:
and that is it, good for any purpose.
Manfred wrote:
And obviously, if you really want it C++ish
namespace my
{
static constexpr float inf = std::numeric_limits<float>::infinity();
}
/* use my::inf wherever you like */The reason for it was to try and please C++ purists (we're in c.l.c++
after all), and get a compact representation of INF - I can see the
issue with using std::numeric_limits<float>::infinity() embedded in some application expression, which serves totally different purposes than inspecting the details of numeric representation of the implementation.
So, suppose you want compact, but you don't like <math.h>, the above is
an answer - note that obviously you want my::inf to be a constant expression. Also, you want it local (as you say below), and along
similar lines I made it 'static', to make it clear - even if 'constexpr' defaults to it.
BUT, then people started whirling around the use of 'static' in
combination with 'const' and 'constexpr' and all that fuzz - again, good
ol' C wouldn't do that - you'd just use INFINITY or one of the HUGE_VAL variants, and be done with it.
Issues of BM with it are pseudo-issues. Too lot of characters?
WTF? Did the hard drive get full? Name some local constant
like "beyond_horizon" or something. Next BM needs to output it to
json as number and then what? Runs away crying?
Manfred <noname@add.invalid> wrote:
The irony is that this is probably one of those examples where C beats
C++ - good ol' HUGE_VALF or INFINITE would raise no question at all!
What is the type of INFINITE? What if you want it as one of the other two floating point types? (Is casting defined in this case?)
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 113 |
| Nodes: | 8 (1 / 7) |
| Uptime: | 45:36:51 |
| Calls: | 2,499 |
| Calls today: | 1 |
| Files: | 8,655 |
| Messages: | 1,908,734 |