Static_assert in 2017 C++

[woodb...@gmail.com]

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

[Mr Flibble]

On 31/08/2019 23:55, woodb...@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.

Would you like us to train you on how to use the toilet too or do you
prefer wearing diapers? Do you still require a bib when eating? When are
you going to big school?

/Flibble

--
"Snakes didn't evolve, instead talking snakes with legs changed into
snakes." - Rick C. Hodgin

“You won’t burn in hell. But be nice anyway.” – Ricky Gervais

“I see Atheists are fighting and killing each other again, over who
doesn’t believe in any God the most. Oh, no..wait.. that never happens.” –
Ricky Gervais

"Suppose it's all true, and you walk up to the pearly gates, and are
confronted by God," Bryne asked on his show The Meaning of Life. "What
will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery
that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates a
world that is so full of injustice and pain. That's what I would say."

[Bonita Montero]

> I have this line
> static_assert(::std::numeric_limits<float>::is_iec559,"Only IEEE754 supported");

That's not necessary because no one will write a C++17-conformant
compiler for an ancient architecture without IEEE-754-floating-points
and is realistic to expect that there will be never any future CPU
that implements floats differently.
Its just one of those compulsive nerd-assessments.

[rick.c...@gmail.com]

On Sunday, September 1, 2019 at 6:43:59 AM UTC-4, Mr Flibble wrote:
> "Snakes didn't evolve, instead talking snakes with legs changed into
> snakes." - Rick C. Hodgin

https://www.youtube.com/watch?v=k5wknazzz9w

Every post. Every time you read your signature with or without that part:

Jesus is calling you to repent.
Jesus is calling you to be saved.
Jesus is calling you to be a part of His eternal Kingdom of love
and peace and joy unspeakable.

"I stand at the door and knock," He says.

Knock knock.

--
Rick C. Hodgin

[Mr Flibble]

No, every time I read that signature I think, oh yeah, Rick the fucktard
who thinks Satan invented fossils.

/Flibble

--

"Snakes didn't evolve, instead talking snakes with legs changed into
snakes." - Rick C. Hodgin

[Bonita Montero]

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

> Would you like us to train you on how to use the toilet too or
> do you prefer wearing diapers? Do you still require a bib when
> eating? When are you going to big school?

The issue he is talking about might be a bit nerdish,
but your comment is rather childish.

[Mr Flibble]

Virtually all of his posts (including this one) are feeble attempts at
disguised advertising for his library that serves no purpose other than to
add some bulk to his website that promotes misogyny and homophobia.

[Bonita Montero]

>>> Would you like us to train you on how to use the toilet too or
>>> do you  prefer wearing diapers? Do you still require a bib when
>>> eating? When are you going to big school?

>> The issue he is talking about might be a bit nerdish,
>> but your comment is rather childish.

> Virtually all of his posts (including this one) are feeble attempts at
> disguised advertising for his library that serves no purpose other than
> to add some bulk to his website that promotes misogyny and homophobia.

Maybe, but your style of response isn't mature.

[Robert Wessel]

While IBM has not yet released a C++17 version of XL C/C++ for z/OS,
they are widely expected to, and for it, like the C++11 version, to
support both IEEE and IBM S/360 hex style floats via a compiler
option. In any event, numeric_limits::is_iec559 is C++11, and
supported on that compiler as you expect for both hex and binary FP.

[woodb...@gmail.com]

On Sunday, September 1, 2019 at 9:21:08 AM UTC-5, robert...@yahoo.com wrote:
>
> While IBM has not yet released a C++17 version of XL C/C++ for z/OS,
> they are widely expected to, and for it, like the C++11 version, to
> support both IEEE and IBM S/360 hex style floats via a compiler
> option. In any event, numeric_limits::is_iec559 is C++11, and

I'm not sure what that last part means. For now I've changed the
line to option b:

static_assert(::std::numeric_limits<float>::is_iec559,"IEEE754");

To rephrase my original question, do you use comments at
all with static_assert if you are using 2017 C++?



Brian
Ebenezer Enterprises - In G-d we trust.
https://github.com/Ebenezer-group/onwards

[Ian Collins]

Neither is deliberately snipping attributions...

--
Ian.

[Richard Damon]

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.

[woodb...@gmail.com]

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.

[Robert Wessel]

On Sun, 1 Sep 2019 09:53:53 -0700 (PDT), woodb...@gmail.com wrote:

>On Sunday, September 1, 2019 at 9:21:08 AM UTC-5, robert...@yahoo.com wrote:
>>
>> While IBM has not yet released a C++17 version of XL C/C++ for z/OS,
>> they are widely expected to, and for it, like the C++11 version, to
>> support both IEEE and IBM S/360 hex style floats via a compiler
>> option. In any event, numeric_limits::is_iec559 is C++11, and
>
>I'm not sure what that last part means.

It was asserted that no non-IEEE FP C++17 implementations are likely
to ever exist, since such architectures largely no longer exist.

I pointed out that the C++ compiler for IBM mainframes in the S/360
line, while not yet C++17, supports both the traditional S/360 hex
floating point format (which is decidedly *not* IEEE FP), as well as
IEEE-style FP. And that a C++17 version of that compiler is generally
expected, and that it's expected that it will continue to support both
FP formats.

When hex FP is selected, numeric_limits::is_iec559, as expected, will
be false.

>For now I've changed the
>line to option b:
>
>static_assert(::std::numeric_limits<float>::is_iec559,"IEEE754");
>
>To rephrase my original question, do you use comments at
>all with static_assert if you are using 2017 C++?

Certainly I see little that a comment could add to the above
assertion.

[Robert Wessel]

OK, you meant should a *message* be used (not a comment) in the static
assertion (at least in C++17, where the message is now optional).
Obviously it depends on the context.

[Chris M. Thomasson]

I want to see the DWCAS impl for z/OS. It should be able to handle the
normal lock-free lifo:

Appendix 48 : A-48 in, Free Pool Manipulation:

https://www-01.ibm.com/support/docview.wss?aid=1&uid=isg26480faec85f44e2385256d5200627dee

[Keith Thompson]

woodb...@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) ks...@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

[Robert Wessel]

You need to find a newer PoOp. That one is 15 years out of date.
Search for "SA22-7832-11".

I'm also not quite sure what you're asking. The ISA implements CAS
and DWCAS (CSxx and CDxx instructions) as well as some other
compare-and-swap variations in both 32 and 64-bit sizes. A number of
additional atomic operations exist under the Perform Locked Operation
instruction.

[Chris M. Thomasson]

Right. So C++11 on the zArch can support 64-bit double width
compare-and-swap atomics with 32 bit words. And 128 DWCAS with 64 bit
words, right?

[Chris M. Thomasson]

On 9/1/2019 8:50 PM, Robert Wessel wrote:
> On Sun, 1 Sep 2019 20:35:27 -0700, "Chris M. Thomasson"
> <chris.m.t...@gmail.com> wrote:
>
>> On 9/1/2019 7:21 AM, Robert Wessel wrote:
>>> On Sun, 1 Sep 2019 12:48:07 +0200, Bonita Montero
>>> <Bonita....@gmail.com> wrote:
>>>
>>>>> I have this line
>>>>> static_assert(::std::numeric_limits<float>::is_iec559,"Only IEEE754 supported");
>>>>
>>>> That's not necessary because no one will write a C++17-conformant
>>>> compiler for an ancient architecture without IEEE-754-floating-points
>>>> and is realistic to expect that there will be never any future CPU
>>>> that implements floats differently.
>>>> Its just one of those compulsive nerd-assessments.
>>>
>>>
>>> While IBM has not yet released a C++17 version of XL C/C++ for z/OS,
>>> they are widely expected to, and for it, like the C++11 version, to
>>> support both IEEE and IBM S/360 hex style floats via a compiler
>>> option. In any event, numeric_limits::is_iec559 is C++11, and
>>> supported on that compiler as you expect for both hex and binary FP.
>>>
>>
>> I want to see the DWCAS impl for z/OS. It should be able to handle the
>> normal lock-free lifo:
>>
>> Appendix 48 : A-48 in, Free Pool Manipulation:
>>
>> https://www-01.ibm.com/support/docview.wss?aid=1&uid=isg26480faec85f44e2385256d5200627dee
>
>
> You need to find a newer PoOp. That one is 15 years out of date.
> Search for "SA22-7832-11".

Afaict, this is still there in appendix A on the most recent version.

[Robert Wessel]

On Sun, 1 Sep 2019 21:12:08 -0700, "Chris M. Thomasson"

Yes. CDSG does a compare and swap on a 128-bit value stored in a pair
of (64-bit) registers with a quadword in memory.

Compare and Swap and Store is something of enhancement, and allows for
the miscompared value to update another structure in the same atomic
operation.

Perform Locked Operation can do a variety of atomic operation
including DCAS, and CAS with multiple updates.

[Bonita Montero]

> I want to see the DWCAS impl for z/OS.

> ...

Why? Do you have bought such a system?

[Bonita Montero]

>>>> The issue he is talking about might be a bit nerdish,
>>>> but your comment is rather childish.

>>> Virtually all of his posts (including this one) are feeble attempts at
>>> disguised advertising for his library that serves no purpose other than
>>> to add some bulk to his website that promotes misogyny and homophobia.

>> Maybe, but your style of response isn't mature.

> Neither is deliberately snipping attributions...

You're right. I will go to the psychotherapist because of that !!!!!!!!!

[Robert Wessel]

On Sun, 1 Sep 2019 21:13:02 -0700, "Chris M. Thomasson"

<chris.m.t...@gmail.com> wrote:

>On 9/1/2019 8:50 PM, Robert Wessel wrote:
>> On Sun, 1 Sep 2019 20:35:27 -0700, "Chris M. Thomasson"
>> <chris.m.t...@gmail.com> wrote:
>>> I want to see the DWCAS impl for z/OS. It should be able to handle the
>>> normal lock-free lifo:
>>>
>>> Appendix 48 : A-48 in, Free Pool Manipulation:
>>>
>>> https://www-01.ibm.com/support/docview.wss?aid=1&uid=isg26480faec85f44e2385256d5200627dee
>>
>>
>> You need to find a newer PoOp. That one is 15 years out of date.
>> Search for "SA22-7832-11".
>
>Afaict, this is still there in appendix A on the most recent version.

It is, although that's not saying much - a non-trivial portion of the
content of Appendix A has been only minimally changed since 1964.
Although not the examples for CS/CDS, those only date back to S/370.

See page 122 of:

http://bitsavers.trailing-edge.com/pdf/ibm/360/princOps/A22-6821-0_360PrincOps.pdf

[Chris M. Thomasson]

Ohhh, yeah. The PLO instruction is very interesting indeed!

[Chris M. Thomasson]

On 9/1/2019 10:20 PM, Robert Wessel wrote:
> On Sun, 1 Sep 2019 21:13:02 -0700, "Chris M. Thomasson"
> <chris.m.t...@gmail.com> wrote:
>
>> On 9/1/2019 8:50 PM, Robert Wessel wrote:
>>> On Sun, 1 Sep 2019 20:35:27 -0700, "Chris M. Thomasson"
>>> <chris.m.t...@gmail.com> wrote:
>>>> I want to see the DWCAS impl for z/OS. It should be able to handle the
>>>> normal lock-free lifo:
>>>>
>>>> Appendix 48 : A-48 in, Free Pool Manipulation:
>>>>
>>>> https://www-01.ibm.com/support/docview.wss?aid=1&uid=isg26480faec85f44e2385256d5200627dee
>>>
>>>
>>> You need to find a newer PoOp. That one is 15 years out of date.
>>> Search for "SA22-7832-11".
>>
>> Afaict, this is still there in appendix A on the most recent version.
>
>
> It is, although that's not saying much - a non-trivial portion of the
> content of Appendix A has been only minimally changed since 1964.
> Although not the examples for CS/CDS, those only date back to S/370.

The lock-free lifo is there to stay.

>
> See page 122 of:
>
> http://bitsavers.trailing-edge.com/pdf/ibm/360/princOps/A22-6821-0_360PrincOps.pdf
>

Will do.

[Chris M. Thomasson]

No. Just want to see the generated asm. Lock-Free and Appendix A have
been around for a long time. Btw, did you know that CAS is actually the
initials for the person who invented it?

[Bonita Montero]

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

[Chris M. Thomasson]

Stack Overflow wrt a Lock-Free Lifo? How did you manage to get that?

Ohhh... The C in CAS stands for Charlie.

[Chris M. Thomasson]

On 9/1/2019 10:55 PM, Bonita Montero wrote:

Myth!? No. Its real.

[Chris M. Thomasson]

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

[Bonita Montero]

>> Thiy might be a myth. I can only get a single Stack Overflow
>> reference on that where only his first name is remembered.

> Stack Overflow wrt a Lock-Free Lifo? How did you manage to get that?

https://bit.ly/2kinTqE

> Ohhh... The C in CAS stands for Charlie.

As soon as I can find his full name with fits so C.A.S.
and I can find something referencing him as a researcher
or whatever I don't belive this.

[Chris M. Thomasson]

Ask over on comp.arch. You might be lucky enough to talk to another
IBM guy that knew him.

[Chris M. Thomasson]

Think of Anne & Lynn Wheeler.... ;^)

[Chris M. Thomasson]

read all...

https://groups.google.com/forum/?hl=en#!original/comp.arch/JkcTGC9X3lo/M4Vo_cXKEwAJ

Still, create a new post over on comp.arch

[Bonita Montero]

>> Think of Anne & Lynn Wheeler.... ;^)

> read all...
> https://groups.google.com/forum/?hl=en#!original/comp.arch/JkcTGC9X3lo/M4Vo_cXKEwAJ
> Still, create a new post over on comp.arch

I further don't believe this; check this: https://bit.ly/2lprsvC
You won't find his full name this. I'm pretty sure that his full
name would be known you would easily google it; but you can't.

You have a very impulsive kind of thinking or you are very
impulsive at at all according to your posting-behaviour.

[Chris M. Thomasson]

Post over on comp.arch. Anne & Lynn Wheeler might still be watching it.

[Bonita Montero]

>> You have a very impulsive kind of thinking or you are very
>> impulsive at at all according to your posting-behaviour.

> Post over on comp.arch. Anne & Lynn Wheeler might still be watching it.

That's not necessary.
If there would be a definite name you could easily google it.
--
http://facebook.com/bonita.montero/

[Chris M. Thomasson]

On 9/2/2019 12:23 AM, Bonita Montero wrote:
>>> You have a very impulsive kind of thinking or you are very
>>> impulsive at at all according to your posting-behaviour.
>
>> Post over on comp.arch. Anne & Lynn Wheeler might still be watching it.
>
> That's not necessary.
> If there would be a definite name you could easily google it.

I cannot do it.

[David Brown]

No, you won't. You will just be ignored.

[Bonita Montero]

>> You're right. I will go to the psychotherapist because of that !!!!!!!!!

> No, you won't. You will just be ignored.

That's your hope because you want this to be sanctioned.
But this won't fulfill.

[woodb...@gmail.com]

On Sunday, September 1, 2019 at 10:34:45 PM UTC-5, robert...@yahoo.com wrote:
> On Sun, 01 Sep 2019 22:29:42 -0500, Robert Wessel
> <robert...@yahoo.com> wrote:
>
> >On Sun, 1 Sep 2019 09:53:53 -0700 (PDT), woodb...@gmail.com wrote:

> >
> >>On Sunday, September 1, 2019 at 9:21:08 AM UTC-5, robert...@yahoo.com wrote:
> >>>
> >>> While IBM has not yet released a C++17 version of XL C/C++ for z/OS,
> >>> they are widely expected to, and for it, like the C++11 version, to
> >>> support both IEEE and IBM S/360 hex style floats via a compiler
> >>> option. In any event, numeric_limits::is_iec559 is C++11, and
> >>

> >>I'm not sure what that last part means.
> >
> >
> >It was asserted that no non-IEEE FP C++17 implementations are likely
> >to ever exist, since such architectures largely no longer exist.
> >
> >I pointed out that the C++ compiler for IBM mainframes in the S/360
> >line, while not yet C++17, supports both the traditional S/360 hex
> >floating point format (which is decidedly *not* IEEE FP), as well as
> >IEEE-style FP. And that a C++17 version of that compiler is generally
> >expected, and that it's expected that it will continue to support both
> >FP formats.
> >
> >When hex FP is selected, numeric_limits::is_iec559, as expected, will
> >be false.
> >
> >
> >>For now I've changed the
> >>line to option b:
> >>
> >>static_assert(::std::numeric_limits<float>::is_iec559,"IEEE754");
> >>
> >>To rephrase my original question, do you use comments at
> >>all with static_assert if you are using 2017 C++?
> >
> >
> >Certainly I see little that a comment could add to the above
> >assertion.
>
>
> OK, you meant should a *message* be used (not a comment) in the static
> assertion (at least in C++17, where the message is now optional).
> Obviously it depends on the context.

OK. Thanks for the correction.

[Jorgen Grahn]

On Sun, 2019-09-01, Richard Damon wrote:
> On 8/31/19 6:55 PM, woodb...@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 .

[David Brown]

My hope is that you will understand the point of following the
conventions of whatever type of discussion group, forum, etc., you are
in - and start using proper Usenet quotations and attributions. It
would be better for you, better for the group, and better for the
threads you engage in. It won't make me agree with much of what you
write, but it would make the threads more pleasant.

[Richard Damon]

On 9/1/19 9:58 PM, woodb...@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.

[James Kuyper]

On 9/2/19 5:40 PM, Richard Damon wrote:
> On 9/1/19 9:58 PM, woodb...@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."

[David Brown]

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

[David Brown]

On 01/09/2019 00:55, woodb...@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?).

[Keith Thompson]

David Brown <david...@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) ks...@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

[David Brown]

On 03/09/2019 09:35, Keith Thompson wrote:
> David Brown <david...@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".

[Chris M. Thomasson]

On 9/1/2019 10:09 PM, Robert Wessel wrote:
> On Sun, 1 Sep 2019 21:12:08 -0700, "Chris M. Thomasson"

> <chris.m.t...@gmail.com> wrote:
>
>> On 9/1/2019 8:50 PM, Robert Wessel wrote:
>>> On Sun, 1 Sep 2019 20:35:27 -0700, "Chris M. Thomasson"
>>> <chris.m.t...@gmail.com> wrote:
>>>

>>>> On 9/1/2019 7:21 AM, Robert Wessel wrote:

>>>>> On Sun, 1 Sep 2019 12:48:07 +0200, Bonita Montero
>>>>> <Bonita....@gmail.com> wrote:
>>>>>
>>>>>>> I have this line
>>>>>>> static_assert(::std::numeric_limits<float>::is_iec559,"Only IEEE754 supported");
>>>>>>

>>>>>> That's not necessary because no one will write a C++17-conformant
>>>>>> compiler for an ancient architecture without IEEE-754-floating-points
>>>>>> and is realistic to expect that there will be never any future CPU
>>>>>> that implements floats differently.
>>>>>> Its just one of those compulsive nerd-assessments.

>>>>>
>>>>>
>>>>> While IBM has not yet released a C++17 version of XL C/C++ for z/OS,
>>>>> they are widely expected to, and for it, like the C++11 version, to
>>>>> support both IEEE and IBM S/360 hex style floats via a compiler
>>>>> option. In any event, numeric_limits::is_iec559 is C++11, and

>>>>> supported on that compiler as you expect for both hex and binary FP.

>>>>>
>>>>
>>>> I want to see the DWCAS impl for z/OS. It should be able to handle the
>>>> normal lock-free lifo:
>>>>
>>>> Appendix 48 : A-48 in, Free Pool Manipulation:
>>>>
>>>> https://www-01.ibm.com/support/docview.wss?aid=1&uid=isg26480faec85f44e2385256d5200627dee
>>>
>>>
>>> You need to find a newer PoOp. That one is 15 years out of date.
>>> Search for "SA22-7832-11".
>>>

>>> I'm also not quite sure what you're asking. The ISA implements CAS
>>> and DWCAS (CSxx and CDxx instructions) as well as some other
>>> compare-and-swap variations in both 32 and 64-bit sizes. A number of
>>> additional atomic operations exist under the Perform Locked Operation
>>> instruction.
>>>
>>
>> Right. So C++11 on the zArch can support 64-bit double width
>> compare-and-swap atomics with 32 bit words. And 128 DWCAS with 64 bit
>> words, right?
>
>
> Yes. CDSG does a compare and swap on a 128-bit value stored in a pair
> of (64-bit) registers with a quadword in memory.

Ohhhh nice! Was not aware of the CDSG. Is it like CMPXCHG16B on an x64
system, sounds identical? Well, what about the hyper strange:

cmp8xchg16 on the Itanium/ Itanic? Wow. This is a odd ball...


>
> Compare and Swap and Store is something of enhancement, and allows for
> the miscompared value to update another structure in the same atomic
> operation.
>
> Perform Locked Operation can do a variety of atomic operation
> including DCAS, and CAS with multiple updates.
>

[Chris M. Thomasson]

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

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