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 2 of 2 — ← Prev page 1 [2]

#82723

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.

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

#82729

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?

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

#82730

On Tue, 04 Jan 2022 15:24:06 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
>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?

How exactly do you have backwards compatible new syntax? 

And waiting until 2017 to (sort of) fix a rather basic syntatic fault doesn't 
exactly suggest they have their finger on the pulse of C++ devs. But we knew 
that anyway.

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

#82720

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

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

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.

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

#82724

On Tue, 4 Jan 2022 07:58:41 -0000 (UTC)
Juha Nieminen <nospam@thanks.invalid> wrote:
>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

I'd love to see their reasoning for that.

>technically speaking it wouldn't be hard for compilers to look up

It wouldn't be hard at all.

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

If someone was new to C++ perhaps, otherwise no.

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

Quite possibly.

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

#82708

On 1/3/2022 9:11 AM, 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?

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!

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

#82719

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

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?

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

#82725

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:
>>>> 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!
> 
> The std::numeric_limits<float>::infinity() does not raise questions
>   in actual programs either. It is infinity of float, very explicitly.
No, I'm talking about these questions about 'static', 'const', 
'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?

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

#82732

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: 
> >> 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! 
> > 
> > The std::numeric_limits<float>::infinity() does not raise questions 
> > in actual programs either. It is infinity of float, very explicitly.
> No, I'm talking about these questions about 'static', 'const', 
> '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.

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

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

#82734

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:
>>>> 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!
>>>
>>> The std::numeric_limits<float>::infinity() does not raise questions
>>> in actual programs either. It is infinity of float, very explicitly.
>> No, I'm talking about these questions about 'static', 'const',
>> '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.

I'll try and lend you a compass:

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?

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

#82737

On Tuesday, 4 January 2022 at 21:49:47 UTC+2, Manfred wrote:
> 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: 
> >>>> 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! 
> >>> 
> >>> The std::numeric_limits<float>::infinity() does not raise questions 
> >>> in actual programs either. It is infinity of float, very explicitly. 
> >> No, I'm talking about these questions about 'static', 'const', 
> >> '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.
> I'll try and lend you a compass:
> 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. 

Yes, and for such cases when the infinity is used to somehow encode
something else I would put it into constant's name (like "beyond_horizon" I
mentioned below), as INFINITY or HUGE_VAL would be as confusing.

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

That fuzz I don't understand. It is perfectly OK to write static 
constexpr, or static const about data member ... maybe I've just
done it too lot over the years. :(

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

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

#82722

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

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

#82726

On 1/4/2022 9:34 AM, Juha Nieminen wrote:
> 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?)

"The macro INFINITY expands to a constant expression of type float 
representing positive or unsigned infinity"
It can't be any clearer than that.
I believe there are automatic conversions to double and long double. 
Others can confirm and give the exact reference for this part.

HUGE_VAL comes in all variants for different types, from float to double 
to decimal.

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

#82787

Juha Nieminen <nospam@thanks.invalid> writes:

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

I haven't checked the C++ standard, but in C (assuming a suitable
infinite value is available) the macro INFINITY expands to a
constant expression of type float, with an infinite value.  Any
value of type float must have corresponding values in type double
and long double, and converting a float value to double or long
double must produce the corresponding value in the target type.
(Converting includes but is not limited to cast operations.)

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web