Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #82684 > unrolled thread

1.0 / 0.0

Back to article view | Back to comp.lang.c++

Contents

  1.0 / 0.0 Bonita Montero <Bonita.Montero@gmail.com> - 2021-12-29 20:00 +0100
    Re: 1.0 / 0.0 Jack Lemmon <invalid@invalid.net> - 2021-12-29 19:15 +0000
      Re: 1.0 / 0.0 Bonita Montero <Bonita.Montero@gmail.com> - 2021-12-29 21:20 +0100
    Re: 1.0 / 0.0 "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2021-12-29 13:08 -0800
      Re: 1.0 / 0.0 "daniel...@gmail.com" <danielaparker@gmail.com> - 2021-12-29 20:37 -0800
    Re: 1.0 / 0.0 Paavo Helde <eesnimi@osa.pri.ee> - 2021-12-30 17:25 +0200
      Re: 1.0 / 0.0 "daniel...@gmail.com" <danielaparker@gmail.com> - 2021-12-30 08:55 -0800
    Re: 1.0 / 0.0 Manfred <noname@add.invalid> - 2021-12-30 18:48 +0100
      Re: 1.0 / 0.0 "daniel...@gmail.com" <danielaparker@gmail.com> - 2021-12-30 10:16 -0800
        Re: 1.0 / 0.0 Manfred <noname@add.invalid> - 2021-12-30 20:02 +0100
          Re: 1.0 / 0.0 Muttley@dastardlyhq.com - 2021-12-31 10:25 +0000
            Re: 1.0 / 0.0 Manfred <noname@add.invalid> - 2021-12-31 18:34 +0100
              Re: 1.0 / 0.0 Juha Nieminen <nospam@thanks.invalid> - 2022-01-03 06:21 +0000
                Re: 1.0 / 0.0 red floyd <no.spam.here@its.invalid> - 2022-01-03 00:11 -0800
                  Re: 1.0 / 0.0 "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-01-03 09:28 +0100
                    Re: 1.0 / 0.0 Juha Nieminen <nospam@thanks.invalid> - 2022-01-03 08:36 +0000
                    Re: 1.0 / 0.0 Muttley@dastardlyhq.com - 2022-01-03 09:24 +0000
                      Re: 1.0 / 0.0 David Brown <david.brown@hesbynett.no> - 2022-01-03 17:14 +0100
                        Re: 1.0 / 0.0 Muttley@dastardlyhq.com - 2022-01-03 16:22 +0000
                        Re: 1.0 / 0.0 scott@slp53.sl.home (Scott Lurndal) - 2022-01-03 17:40 +0000
                          Re: 1.0 / 0.0 Muttley@dastardlyhq.com - 2022-01-04 09:15 +0000
                            Re: 1.0 / 0.0 scott@slp53.sl.home (Scott Lurndal) - 2022-01-04 15:24 +0000
                              Re: 1.0 / 0.0 Muttley@dastardlyhq.com - 2022-01-04 16:06 +0000
                      Re: 1.0 / 0.0 Juha Nieminen <nospam@thanks.invalid> - 2022-01-04 07:58 +0000
                        Re: 1.0 / 0.0 Muttley@dastardlyhq.com - 2022-01-04 09:17 +0000
                  Re: 1.0 / 0.0 Manfred <noname@add.invalid> - 2022-01-03 23:14 +0100
                    Re: 1.0 / 0.0 Öö Tiib <ootiib@hot.ee> - 2022-01-03 23:50 -0800
                      Re: 1.0 / 0.0 Manfred <noname@add.invalid> - 2022-01-04 10:42 +0100
                        Re: 1.0 / 0.0 Öö Tiib <ootiib@hot.ee> - 2022-01-04 10:15 -0800
                          Re: 1.0 / 0.0 Manfred <noname@invalid.add> - 2022-01-04 20:49 +0100
                            Re: 1.0 / 0.0 Öö Tiib <ootiib@hot.ee> - 2022-01-04 15:40 -0800
                    Re: 1.0 / 0.0 Juha Nieminen <nospam@thanks.invalid> - 2022-01-04 08:34 +0000
                      Re: 1.0 / 0.0 Manfred <noname@add.invalid> - 2022-01-04 10:47 +0100
                      Re: 1.0 / 0.0 Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-01-16 12:40 -0800

Page 1 of 2  [1] 2  Next page →

#82684 — 1.0 / 0.0

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 ?

[toc] | [next] | [standalone]

#82685

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>.

[toc] | [prev] | [next] | [standalone]

#82686

Am 29.12.2021 um 20:15 schrieb Jack Lemmon:
> 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>.

No, it's infinity. 0.0 / 0.0 is NaN.

[toc] | [prev] | [next] | [standalone]

#82687

On Wednesday, December 29, 2021 at 2:00:21 PM UTC-5, 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 ?

Both are right. "If the second operand of / or % is zero the behavior
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.

[toc] | [prev] | [next] | [standalone]

#82688

On Wednesday, December 29, 2021 at 4:09:09 PM UTC-5, james...@alumni.caltech.edu wrote:
> On Wednesday, December 29, 2021 at 2:00:21 PM UTC-5, Bonita Montero wrote: 
> > So I just wrote 
> > 1.0f / 0.0f ... MSVC took this as an error but clang++ and 
> > clang-cl accepted the code. Which compiler is right ?
> Both are right. "If the second operand of / or % is zero the behavior 
> 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.

It does.

I believe for all of these compilers, on popular OS's including Ubuntu,  
Windows 10, MacOS,

std::numeric_limits<double>::is_iec559
  
returns true by default, which means they should support IEEE 754 standard.
Microsoft vs returns true on Windows,  but errors on 1.0/0. So I think
vs is wrong.

Daniel  

[toc] | [prev] | [next] | [standalone]

#82690

29.12.2021 21:00 Bonita Montero kirjutas:
> 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 ?

Not sure which one is right, but here is a workaround;-) It's shorter 
than std::numeric_limits<float>::infinity(), isn't it?

float x = 1.f/[](){return 0.f;}();

[toc] | [prev] | [next] | [standalone]

#82691

On Thursday, December 30, 2021 at 10:25:42 AM UTC-5, Paavo Helde wrote:
> 29.12.2021 21:00 Bonita Montero kirjutas: 
> > 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 ?
> Not sure which one is right, but here is a workaround;-) It's shorter 
> than std::numeric_limits<float>::infinity(), isn't it? 
> 
> float x = 1.f/[](){return 0.f;}();

Yes, but I think that's division by a non constant expression. Surprisingly 
(to me), this (still shorter!)

float x = 1.f/[]() constexpr {return 0.f;}();    

also works with MSVC C++ 17 and greater, but

constexpr float zero = 0;
float x = 1.f / 1.f / zero;

does not (compile time error, "div or mod by zero".) 

Daniel
   

[toc] | [prev] | [next] | [standalone]

#82692

On 12/29/2021 8:00 PM, 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 ?

If all you want is a compact expression, why not HUGE_VAL, HUGE_VALF, 
HUGE_VALL from <cmath> (aka <math.h>)?

These are standardized by reference from C, and guaranteed to work.
1.0f/0.0f is just an unportable hack.

[toc] | [prev] | [next] | [standalone]

#82693

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?

[toc] | [prev] | [next] | [standalone]

#82694

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.
BTW the standard lists it both under <float.h> and <math.h>

[toc] | [prev] | [next] | [standalone]

#82695

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.

[toc] | [prev] | [next] | [standalone]

#82696

On 12/31/2021 11:25 AM, Muttley@dastardlyhq.com wrote:
> 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.
> 

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 */

[toc] | [prev] | [next] | [standalone]

#82697

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'.

[toc] | [prev] | [next] | [standalone]

#82698

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?

[toc] | [prev] | [next] | [standalone]

#82699

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 
`constexpr` for data should also have implied static storage duration. 
It's gut-wrenching that it does not.

- Alf

[toc] | [prev] | [next] | [standalone]

#82700

Alf P. Steinbach <alf.p.steinbach@gmail.com> wrote:
> 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.

I haven't tried it, but couldn't a (non-static) constexpr member
variable be usable in classes that are intended for constexpr
evaluation only?

Or is it semantically just not possible to have a non-static
constexpr member variable?

[toc] | [prev] | [next] | [standalone]

#82701

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.

[toc] | [prev] | [next] | [standalone]

#82702

On 03/01/2022 10:24, Muttley@dastardlyhq.com wrote:
> 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.
> 
> 

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!)

<https://en.cppreference.com/w/cpp/language/static#Static_data_members>

[toc] | [prev] | [next] | [standalone]

#82703

On Mon, 3 Jan 2022 17:14:51 +0100
David Brown <david.brown@hesbynett.no> wrote:
>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!)

Thanks for that, didn't know. Hope the inline doesn't throw up wierd 
optimisation issues. Why its taken over 3 decades to do this simple obvious
change when they've been busy throwing in a lot of syntatic nonsense no one 
asked for (user literals being the best example IMO) instead is also a good 
question.

[toc] | [prev] | [next] | [standalone]

#82704

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.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c++

csiph-web