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

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

Static_assert in 2017 C++

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

Contents

  Static_assert in 2017 C++ woodbrian77@gmail.com - 2019-08-31 15:55 -0700
    Re: Static_assert in 2017 C++ Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2019-09-01 11:43 +0100
      Re: Static_assert in 2017 C++ rick.c.hodgin@gmail.com - 2019-09-01 04:16 -0700
        Re: Static_assert in 2017 C++ Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2019-09-01 13:15 +0100
      Re: Static_assert in 2017 C++ Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-01 14:56 +0200
        Re: Static_assert in 2017 C++ Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2019-09-01 14:20 +0100
          Re: Static_assert in 2017 C++ Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-01 15:35 +0200
            Re: Static_assert in 2017 C++ Ian Collins <ian-news@hotmail.com> - 2019-09-02 07:30 +1200
              Re: Static_assert in 2017 C++ Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-02 07:16 +0200
                Re: Static_assert in 2017 C++ David Brown <david.brown@hesbynett.no> - 2019-09-02 13:13 +0200
                  Re: Static_assert in 2017 C++ Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-02 15:55 +0200
                    Re: Static_assert in 2017 C++ David Brown <david.brown@hesbynett.no> - 2019-09-02 22:02 +0200
    Re: Static_assert in 2017 C++ Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-01 12:48 +0200
      Re: Static_assert in 2017 C++ Robert Wessel <robertwessel2@yahoo.com> - 2019-09-01 09:21 -0500
        Re: Static_assert in 2017 C++ woodbrian77@gmail.com - 2019-09-01 09:53 -0700
          Re: Static_assert in 2017 C++ Robert Wessel <robertwessel2@yahoo.com> - 2019-09-01 22:29 -0500
            Re: Static_assert in 2017 C++ Robert Wessel <robertwessel2@yahoo.com> - 2019-09-01 22:34 -0500
              Re: Static_assert in 2017 C++ woodbrian77@gmail.com - 2019-09-02 07:32 -0700
        Re: Static_assert in 2017 C++ "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-09-01 20:35 -0700
          Re: Static_assert in 2017 C++ Robert Wessel <robertwessel2@yahoo.com> - 2019-09-01 22:50 -0500
            Re: Static_assert in 2017 C++ "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-09-01 21:12 -0700
              Re: Static_assert in 2017 C++ Robert Wessel <robertwessel2@yahoo.com> - 2019-09-02 00:09 -0500
                Re: Static_assert in 2017 C++ "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-09-01 22:39 -0700
                Re: Static_assert in 2017 C++ "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-09-04 22:49 -0700
            Re: Static_assert in 2017 C++ "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-09-01 21:13 -0700
              Re: Static_assert in 2017 C++ Robert Wessel <robertwessel2@yahoo.com> - 2019-09-02 00:20 -0500
                Re: Static_assert in 2017 C++ "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-09-01 22:41 -0700
          Re: Static_assert in 2017 C++ Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-02 07:14 +0200
            Re: Static_assert in 2017 C++ "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-09-01 22:46 -0700
              Re: Static_assert in 2017 C++ Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-02 07:55 +0200
                Re: Static_assert in 2017 C++ "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-09-01 22:58 -0700
                  Re: Static_assert in 2017 C++ Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-02 08:20 +0200
                    Re: Static_assert in 2017 C++ "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-09-01 23:24 -0700
                      Re: Static_assert in 2017 C++ "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-09-01 23:25 -0700
                        Re: Static_assert in 2017 C++ "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-09-01 23:26 -0700
                          Re: Static_assert in 2017 C++ Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-02 08:33 +0200
                            Re: Static_assert in 2017 C++ "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-09-02 00:18 -0700
                              Re: Static_assert in 2017 C++ Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-02 09:23 +0200
                                Re: Static_assert in 2017 C++ "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-09-02 00:26 -0700
                Re: Static_assert in 2017 C++ "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-09-01 22:58 -0700
                  Re: Static_assert in 2017 C++ "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-09-01 22:59 -0700
                    Re: Static_assert in 2017 C++ "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-09-04 23:04 -0700
    Re: Static_assert in 2017 C++ Richard Damon <Richard@Damon-Family.org> - 2019-09-01 15:39 -0400
      Re: Static_assert in 2017 C++ woodbrian77@gmail.com - 2019-09-01 18:58 -0700
        Re: Static_assert in 2017 C++ Richard Damon <Richard@Damon-Family.org> - 2019-09-02 17:40 -0400
          Re: Static_assert in 2017 C++ James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-09-02 22:53 -0400
          Re: Static_assert in 2017 C++ David Brown <david.brown@hesbynett.no> - 2019-09-03 08:21 +0200
      Re: Static_assert in 2017 C++ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-09-02 14:43 +0000
    Re: Static_assert in 2017 C++ Keith Thompson <kst-u@mib.org> - 2019-09-01 20:48 -0700
    Re: Static_assert in 2017 C++ David Brown <david.brown@hesbynett.no> - 2019-09-03 08:25 +0200
      Re: Static_assert in 2017 C++ Keith Thompson <kst-u@mib.org> - 2019-09-03 00:35 -0700
        Re: Static_assert in 2017 C++ David Brown <david.brown@hesbynett.no> - 2019-09-03 10:31 +0200

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

#68107

On 9/1/2019 10:58 PM, Chris M. Thomasson wrote:
> On 9/1/2019 10:55 PM, Bonita Montero wrote:
>>> No. Just want to see the generated asm. Lock-Free
>>> and Appendix A have  been around for a long time.
>>
>> Those systems aren't really relevant because they're
>> sold in homeopathic amounts.
>>
>>> A have  been around for a long time. Btw, did you know that
>>> CAS is actually the initials for the person who invented it?
>>
>> Thiy might be a myth. I can only get a single Stack Overflow
>> reference on that where only his first name is remembered.
> 
> Myth!? No. Its real.

Ask over on comp.arch... The CAS is the initials of the person who 
invented it. IBM!

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

#68225

On 9/1/2019 10:59 PM, Chris M. Thomasson wrote:
> On 9/1/2019 10:58 PM, Chris M. Thomasson wrote:
>> On 9/1/2019 10:55 PM, Bonita Montero wrote:
>>>> No. Just want to see the generated asm. Lock-Free
>>>> and Appendix A have  been around for a long time.
>>>
>>> Those systems aren't really relevant because they're
>>> sold in homeopathic amounts.
>>>
>>>> A have  been around for a long time. Btw, did you know that
>>>> CAS is actually the initials for the person who invented it?
>>>
>>> Thiy might be a myth. I can only get a single Stack Overflow
>>> reference on that where only his first name is remembered.
>>
>> Myth!? No. Its real.
> 
> Ask over on comp.arch... The CAS is the initials of the person who 
> invented it. IBM!

For those who are interested, here is a link to some deeper context:

https://groups.google.com/d/topic/comp.arch/1zNPUHo8YoI/discussion

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

#68085

On 8/31/19 6:55 PM, woodbrian77@gmail.com wrote:
>       Shalom
> 
> I have this line
> static_assert(::std::numeric_limits<float>::is_iec559,"Only IEEE754 supported");
> 
> in my library: https://github.com/Ebenezer-group/onwards
> 
> .  I wrote that line when I was using 2011 C++ and the comment
> was required.  Now I require 2017 C++ and am trying to decide between:
> 
> a. remove the comment
> b. reduce the comment to just "IEEE754", or
> c. leave it as it is.
> 
> Thank you.
> 
> 
> Brian
> Ebenezer Enterprises - Enjoying programming again.
> http://webEbenezer.net
> 

Personally, I would be tempted to leave it as is. Making useful error
messages is generally good. Making the Error comment optional might make
some sense if the Error Condition is fully self documenting, but the
linkage between IEC559 and IEEE754 isn't inherently obvious. I might
even extend the error message to something more verbose, like

IEEE754/IEC559 Floating point assumed and needed

After all, a static_assert imposes zero run time costs, just minimal
text space in the file and virtually zero processing time during
compilation. Treat it as file documentation for the requirements of the
system, and make it readable.

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

#68087

On Sunday, September 1, 2019 at 2:39:57 PM UTC-5, Richard Damon wrote:
> 
> Personally, I would be tempted to leave it as is. Making useful error
> messages is generally good. Making the Error comment optional might make
> some sense if the Error Condition is fully self documenting, but the
> linkage between IEC559 and IEEE754 isn't inherently obvious. 

Right.

> I might
> even extend the error message to something more verbose, like
> 
> IEEE754/IEC559 Floating point assumed and needed

I don't like having iec559 in there.  If they want
they can look at the line for more info.  I agree in
principle that that's a better message.  On the other 
hand, some say this isn't likely to assert very often 
so the error message may not be that important.

> 
> After all, a static_assert imposes zero run time costs, just minimal
> text space in the file and virtually zero processing time during
> compilation. Treat it as file documentation for the requirements of the
> system, and make it readable.

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

#68140

On 9/1/19 9:58 PM, woodbrian77@gmail.com wrote:
> On Sunday, September 1, 2019 at 2:39:57 PM UTC-5, Richard Damon wrote:
>>
>> Personally, I would be tempted to leave it as is. Making useful error
>> messages is generally good. Making the Error comment optional might make
>> some sense if the Error Condition is fully self documenting, but the
>> linkage between IEC559 and IEEE754 isn't inherently obvious. 
> 
> Right.
> 
>> I might
>> even extend the error message to something more verbose, like
>>
>> IEEE754/IEC559 Floating point assumed and needed
> 
> I don't like having iec559 in there.  If they want
> they can look at the line for more info.  I agree in
> principle that that's a better message.  On the other 
> hand, some say this isn't likely to assert very often 
> so the error message may not be that important.
> 
>>
>> After all, a static_assert imposes zero run time costs, just minimal
>> text space in the file and virtually zero processing time during
>> compilation. Treat it as file documentation for the requirements of the
>> system, and make it readable.
> 

The one purpose of IEC559 in the message is that that is what the
language calls it, so including it in the message might be useful.

My main thought is why work hard to coming up with a minimal message
when there is NO run time cost to the fuller message. The string
shouldn't even be included in the image, as static_assert generates no
code. Yes, the message may be never seen, but if it IS seen, it would
seem best to make it clear. The expected output (but I don't think
required) is printing the message, and maybe the condition that was
false as part of the error message. My preference would be that the
message be fairly self explanatory by itself.

Yes, they can go to the source code to read a comment near by, and maybe
even that happens somewhat automatically if they are building in an IDE,
but the less you assume about the environment, the better for the user.
If the message is clear, the user might realize without needing to dig
into the code, that they need to invoke the build with a flag to use IEC559.

It would be nice if in the vicinity of the static_assert was some
comments explaining WHY you have such a statement in the code, in case
someone on a machine that doesn't support it tries to use it, so they
can figure out if they want to try to remove the assumptions in the code
or if they need to try to find another package.

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

#68144

On 9/2/19 5:40 PM, Richard Damon wrote:
> On 9/1/19 9:58 PM, woodbrian77@gmail.com wrote:
>> On Sunday, September 1, 2019 at 2:39:57 PM UTC-5, Richard Damon wrote:
...
>>> linkage between IEC559 and IEEE754 isn't inherently obvious. 
...
>>> I might
>>> even extend the error message to something more verbose, like
>>>
>>> IEEE754/IEC559 Floating point assumed and needed
>>
>> I don't like having iec559 in there.  If they want
...
> The one purpose of IEC559 in the message is that that is what the
> language calls it, so including it in the message might be useful.

The language calls it that as an abbreviation for  IEC/ISO/IEEE 60559,
which is what IEC, ISO, and IEEE all call it. I'd normally provide a
message using the unabbreviated name: "IEC/ISO/IEEE 60559 (== IEEE 754)
floating point assumed and needed."

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

#68148

On 02/09/2019 23:40, Richard Damon wrote:
> On 9/1/19 9:58 PM, woodbrian77@gmail.com wrote:
>> On Sunday, September 1, 2019 at 2:39:57 PM UTC-5, Richard Damon wrote:
>>>
>>> Personally, I would be tempted to leave it as is. Making useful error
>>> messages is generally good. Making the Error comment optional might make
>>> some sense if the Error Condition is fully self documenting, but the
>>> linkage between IEC559 and IEEE754 isn't inherently obvious.
>>
>> Right.
>>
>>> I might
>>> even extend the error message to something more verbose, like
>>>
>>> IEEE754/IEC559 Floating point assumed and needed
>>
>> I don't like having iec559 in there.  If they want
>> they can look at the line for more info.  I agree in
>> principle that that's a better message.  On the other
>> hand, some say this isn't likely to assert very often
>> so the error message may not be that important.
>>
>>>
>>> After all, a static_assert imposes zero run time costs, just minimal
>>> text space in the file and virtually zero processing time during
>>> compilation. Treat it as file documentation for the requirements of the
>>> system, and make it readable.
>>
> 
> The one purpose of IEC559 in the message is that that is what the
> language calls it, so including it in the message might be useful.
> 
> My main thought is why work hard to coming up with a minimal message
> when there is NO run time cost to the fuller message. The string
> shouldn't even be included in the image, as static_assert generates no
> code. Yes, the message may be never seen, but if it IS seen, it would
> seem best to make it clear. The expected output (but I don't think
> required) is printing the message, and maybe the condition that was
> false as part of the error message. My preference would be that the
> message be fairly self explanatory by itself.
> 
> Yes, they can go to the source code to read a comment near by, and maybe
> even that happens somewhat automatically if they are building in an IDE,
> but the less you assume about the environment, the better for the user.
> If the message is clear, the user might realize without needing to dig
> into the code, that they need to invoke the build with a flag to use IEC559.
> 
> It would be nice if in the vicinity of the static_assert was some
> comments explaining WHY you have such a statement in the code, in case
> someone on a machine that doesn't support it tries to use it, so they
> can figure out if they want to try to remove the assumptions in the code
> or if they need to try to find another package.
> 

As a follow-on from that, remember that static assertions are free in 
the code, document requirements, and protect from unwarranted 
assumptions.  So it is fine to duplicate them.  If you have a library 
file with twenty mathematical functions, and three of them rely on IEEE 
formats for some reason, put the static assertion at all three 
functions.  And the message can explain /why/ the assertion is there, 
although that could also be left in comments in the code.

static_assert(std::numeric_limits<float>::is_iec559,
	"IEEE format is needed for exponent hack in log_base2");
double log_base2(double x)
{
	...
}

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

#68127

On Sun, 2019-09-01, Richard Damon wrote:
> On 8/31/19 6:55 PM, woodbrian77@gmail.com wrote:
>>       Shalom
>> 
>> I have this line
>> static_assert(::std::numeric_limits<float>::is_iec559,"Only IEEE754 supported");
>> 
>> in my library: https://github.com/Ebenezer-group/onwards
>> 
>> .  I wrote that line when I was using 2011 C++ and the comment
>> was required.  Now I require 2017 C++ and am trying to decide between:
>> 
>> a. remove the comment
>> b. reduce the comment to just "IEEE754", or
>> c. leave it as it is.
>> 
>> Thank you.
>> 
>> 
>> Brian
>> Ebenezer Enterprises - Enjoying programming again.
>> http://webEbenezer.net
>> 
>
> Personally, I would be tempted to leave it as is. Making useful error
> messages is generally good.

I have a thing against assert(condition, message) in general, so I'd
drop it, if

   static_assert(std::numeric_limits<float>::is_iec559);

is likely to be meaningful to the reader, after some googling.

However, in an earlier discussion here, years ago, most didn't feel
that way.

> Making the Error comment optional might make
> some sense if the Error Condition is fully self documenting, but the
> linkage between IEC559 and IEEE754 isn't inherently obvious.

If it's hard to make the condition self-documenting, there should be a
message.  Even I can agree to that.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

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

#68091

woodbrian77@gmail.com writes:
> I have this line
> static_assert(::std::numeric_limits<float>::is_iec559,"Only IEEE754 supported");
>
> in my library: https://github.com/Ebenezer-group/onwards
>
> .  I wrote that line when I was using 2011 C++ and the comment
> was required.  Now I require 2017 C++ and am trying to decide between:
>
> a. remove the comment
> b. reduce the comment to just "IEEE754", or
> c. leave it as it is.

The issue is that in C++11 and earlier, static_assert requires
a second argument (which is *not* a "comment"), and in C++17 and later
it does not.

Given what you have, I can't think of any good reason not to leave it as
it is.

If you do drop the message argument, your code will no longer
compile with a pre-2017 C++. implementation (unless it supports a
single-argument static_assert as an extension).  If it won't anyway
for other reasons, that probably doesn't matter.

What advantage do you see from removing or changing the message
argument?

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

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

#68149

On 01/09/2019 00:55, woodbrian77@gmail.com wrote:
>        Shalom
> 
> I have this line
> static_assert(::std::numeric_limits<float>::is_iec559,"Only IEEE754 supported");
> 
> in my library: https://github.com/Ebenezer-group/onwards
> 
> .  I wrote that line when I was using 2011 C++ and the comment
> was required.  Now I require 2017 C++ and am trying to decide between:
> 
> a. remove the comment
> b. reduce the comment to just "IEEE754", or
> c. leave it as it is.
> 

The static_assert message is what users see when the assertion fails. 
That is your guide.

If the check itself is information enough, you don't need a message.  If 
it is not clear (perhaps users don't know what "is_iec559" means - but 
/would/ know what "IEEE format floating point" means), use a message.

You can also use it to give more detail of /why/ the assertion is there 
- "IEEE floating point required to ensure binary compatibility", or 
"Only tested with IEEE floating point format".  Then the user can get an 
idea of the reasoning for the assertion, and the consequences of 
removing it (will it break something, or is it merely untested?).

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

#68155

David Brown <david.brown@hesbynett.no> writes:
[...]
> The static_assert message is what users see when the assertion fails. 
> That is your guide.

For certain values of "users".  The message is seen when the code is
compiled.  For most software, most end users use precompiled
executables.

[...]

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

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

#68157

On 03/09/2019 09:35, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
> [...]
>> The static_assert message is what users see when the assertion fails. 
>> That is your guide.
> 
> For certain values of "users".  The message is seen when the code is
> compiled.  For most software, most end users use precompiled
> executables.
> 

Yes.  By "users", I mean "users of the source code" rather than "users
of the resulting binaries".

[toc] | [prev] | [standalone]

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

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

csiph-web