Tuesday, May 5, 2020

Digest for comp.lang.c++@googlegroups.com - 25 updates in 5 topics

Tim Rentsch <tr.17687@z991.linuxsc.com>: May 05 02:12AM -0700

> different in C++.
 
> You would need some kind of interoperatibility syntax between C data
> types and C++ data types and code.
 
I see now what it is you're trying to get at. Right now the C++
"understanding" of this struct definition matches how C interprets
it (to be explicit, as one example). In the future that might
(conceivably) change. What do we do about that potential problem?
At least that's what I think you're getting at.
 
To answer this question in full generality deserves more thought
than I have previously given it. Let me clarify what I said
earlier: my suggestion was meant to address incompatibilities as
they exist today, not as they might exist in the future. So for
the time being I agree with you that there should be some level of
assured compatibility, with an addendum that at some point in the
future I may have more to say about that. Does that make sense?
 
> inserted into your C++ code if you use those macros. Obviously if
> C++ syntax were wildly different from C syntax, it would completely
> exclude the possibility of using such macros in such headers.
 
The preprocessor is a whole other kettle of fish. For now I think
we should just punt on the preprocessor question (although, I
should add, it is already the case that the C++ preprocessor is
not completely compatible with the C preprocessor, so this too
may be more of an issue in the future).
Tim Rentsch <tr.17687@z991.linuxsc.com>: May 05 08:42AM -0700


> extern "C" {
> int class = sizeof 'A';
> }
 
To be clear, this example would be allowed under the rule I
described. Weighing the cost of implementing against the costs
of thousands of developers who use the two languages, probably
it's a net win to be fully general and allow even cases like this
one. I don't mind being pragmatic and ruling out funny corner
cases, if they really cause too many headaches in implementation,
but I don't think this example is one of those. Probably there
are such cases, and it seems reasonable to consider making
allowances for them. The main thing is not to throw out the baby
with the bathwater. Code that is valid C code, but not valid C++
code, should be accepted, provided of course that the C code is
something somone would normally write and not some sort of
contrived mess designed to break things. Also, what may be more
important, code that is valid C and also valid C++, _but has a
different meaning in the two languages_, should take the C
meaning when inside the extern "C" { ... } brackets. Otherwise
we have programs that look like they do the right thing but in
actuality may do something else entirely. The cost of dealing
with such cases (and they will happen) can be very high.
Daniel P <danielaparker@gmail.com>: May 04 07:53PM -0700

Suppose we have a signed integral value, and wish to assign it to an unsigned
integral value as follows:
 
-value if value is negative,
value otherwise
 
Now consider
 
int64_t n = std::numeric_limits<int64_t>::min();
 
uint64_t u = n < 0 ? static_cast<uint64_t>(-n) :
static_cast<uint64_t>(n); // (*)
 
The problem is that negation of std::numeric_limits<int64_t>::min() cannot
be represented in type 'int64_t',
 
min: -9223372036854775808
max: 9223372036854775807
 
Which makes sanitizers unhappy.
 
So, how to express (*)?
 
Thanks,
Daniel
Barry Schwarz <schwarzb@delq.com>: May 04 08:39PM -0700

There are specific rules for assigning a negative value to an unsigned
object. Your issue is trivially resolved with a simple
u = n;
 
On Mon, 4 May 2020 19:53:26 -0700 (PDT), Daniel P
 
--
Remove del for email
James Kuyper <jameskuyper@alumni.caltech.edu>: May 04 11:58PM -0400

On 5/4/20 11:39 PM, Barry Schwarz wrote:
>> integral value as follows:
 
>> -value if value is negative,
>> value otherwise
 
If the value of n is negative, then the statement
 
u = n;
 
Assigns a value to u of std::numeric_limits<uint64_t>::max()+1+n (see
6.3.1.3p2). Daniel Parker specified that it should have the value of -n.
James Kuyper <jameskuyper@alumni.caltech.edu>: May 05 12:11AM -0400

On 5/4/20 10:53 PM, Daniel P wrote:
> max: 9223372036854775807
 
> Which makes sanitizers unhappy.
 
> So, how to express (*)?
 
uint64_t u = n < 0 ? -static_cast<uint64_t>(n) :
static_cast<uint64_t>(n);
Daniel P <danielaparker@gmail.com>: May 04 09:21PM -0700

On Tuesday, May 5, 2020 at 12:11:38 AM UTC-4, James Kuyper wrote:
 
> > So, how to express (*)?
 
> uint64_t u = n < 0 ? -static_cast<uint64_t>(n) :
> static_cast<uint64_t>(n);
 
Tried that, but in vs2019, C++17, that gives
 
Error unary minus operator applied to unsigned type, result still unsigned
Daniel P <danielaparker@gmail.com>: May 04 09:23PM -0700

On Tuesday, May 5, 2020 at 12:21:28 AM UTC-4, Daniel P wrote:
> > static_cast<uint64_t>(n);
 
> Tried that, but in vs2019, C++17, that gives
 
> Error unary minus operator applied to unsigned type, result still unsigned
 
But this compiles:
 
uint64_t u = n < 0 ? uint64_t(0)-static_cast<uint64_t>(n) :
static_cast<uint64_t>(n);
Keith Thompson <Keith.S.Thompson+u@gmail.com>: May 04 09:32PM -0700

> On Tuesday, May 5, 2020 at 12:11:38 AM UTC-4, James Kuyper wrote:
[...]
>> static_cast<uint64_t>(n);
 
> Tried that, but in vs2019, C++17, that gives
 
> Error unary minus operator applied to unsigned type, result still unsigned
 
Applying a unary minus operator to an unsigned type is not an error.
It has well defined semantics. That might be a reasonable warning,
but there should be a way to tell VS2019 to shut up about it.
 
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
Daniel P <danielaparker@gmail.com>: May 04 09:46PM -0700

On Tuesday, May 5, 2020 at 12:32:30 AM UTC-4, Keith Thompson wrote:
 
> Applying a unary minus operator to an unsigned type is not an error.
> It has well defined semantics. That might be a reasonable warning,
> but there should be a way to tell VS2019 to shut up about it.
 
Doesn't seem to be, it's reported as an error, not a warning. Anyway,
"uint64_t()-static_cast<uint64_t>(n)" compiles.
 
Thanks for your help, appreciated.
Daniel
Keith Thompson <Keith.S.Thompson+u@gmail.com>: May 04 11:13PM -0700

>> but there should be a way to tell VS2019 to shut up about it.
 
> Doesn't seem to be, it's reported as an error, not a warning. Anyway,
> "uint64_t()-static_cast<uint64_t>(n)" compiles.
 
I'm using VS2015. I tried this as an experiment:
unsigned int n = 42;
n = -n;
and got this:
5>main.cpp(36): error C2220: warning treated as error - no 'object' file generated
5>main.cpp(36): warning C4146: unary minus operator applied to unsigned type, result still unsigned
 
After a quick web search, this worked around it:
unsigned int n = 42;
#pragma warning(push)
#pragma warning(disable: 4146)
n = -n;
#pragma warning(pop)
 
(Of course this is specific to Visual Studio.)
 
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
Bonita Montero <Bonita.Montero@gmail.com>: May 05 08:13AM +0200

> int64_t n = std::numeric_limits<int64_t>::min();
> uint64_t u = n < 0 ? static_cast<uint64_t>(-n) :
> static_cast<uint64_t>(n); // (*)
 
Use:
uint64_t u = n < 0 ? ~n : n;
You won't get an exact result, but the result is
_________symmetrical_________ .
Hrhr. ;-)
Juha Nieminen <nospam@thanks.invalid>: May 05 06:34AM

>> static_cast<uint64_t>(n);
 
> Tried that, but in vs2019, C++17, that gives
 
> Error unary minus operator applied to unsigned type, result still unsigned
 
Note that in 2's complement representation negation is the same as inverting
all the bits and adding 1. (Inverting all the bits can be done by xorring with
a value with all the bits set.) All target systems you care about will use
2's complement representation.
 
Of course unless the compiler is quite clever with its optimizations (which
some compilers might well be, ie. they recognize the pattern), that's two
operations instead of one. Not that it matters in most practical situations.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: May 05 08:35AM +0200

On 05.05.2020 08:13, Keith Thompson wrote:
> n = -n;
> #pragma warning(pop)
 
> (Of course this is specific to Visual Studio.)
 
Now the Visual C++ compiler phones home, generates executables that also
phone Microsoft, and emits diagnostics like that that are only useful
for idiots, if any, and that for everybody else are counter-productive.
 
One possible explanation is that they have let loose their horde of
idiot "programmers", the same ones that sprinkle "void main" all over
the MS documentation, on the Visual C++ compiler.
 
Another possible explanation is that in usual Microsoft fashion they're
sabotaging a "technology" that they want to discontinue. That's a bit
scary, if it's what happened. No Microsoft C++ compiler...
 
However, at the same time the compiler has become faster and more
standard-conforming.
 
I don't know any resolution of that paradox other than possibly the MS
left hand doesn't know what the MS right hand is doing, and vice versa.
 
 
- Alf
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: May 05 08:54AM +0200

On 05.05.2020 04:53, Daniel P wrote:
> integral value as follows:
 
> -value if value is negative,
> value otherwise
 
Except for the problem you note below, that's the `std::abs` function.
 
In C++03 the integer argument overload was available via `<stdlib.h>`.
 
In C++11 and later it's also available via `<math.h>`.
 
 
> max: 9223372036854775807
 
> Which makes sanitizers unhappy.
 
> So, how to express (*)?
 
Off the cuff,
 
const uint64_t u = (n < 0? 1 + ~uint64_t( n ) : n);
 
Which assumes two's complement form, which is guaranteed in C++20 and later.
 
However, you really should be able to just use negation. The standard
guarantees the result. E.g. in C++17 §8.3.1/8:
 
"The negative of an unsigned quantity is computed by subtracting its
value from 2^n , where n is the number of bits in the promoted operand."
 
No matter that the C++17 wording is incorrect: it should be number of
value representation bits. But the intent is clear.
 
The practical resolution of that sillywarning problem is to disable it,
and hopefully Visual C++ compiler option "/wd4146" will do the trick.
 
 
- Alf
"Öö Tiib" <ootiib@hot.ee>: May 04 11:57PM -0700

On Tuesday, 5 May 2020 05:53:42 UTC+3, Daniel P wrote:
> max: 9223372036854775807
 
> Which makes sanitizers unhappy.
 
> So, how to express (*)?
 
To silence your sanitizers use something like:
 
uint64_t u = n < 0 ? static_cast<uint64_t>(1 - n) + 1 :
static_cast<uint64_t>(n);
 
The compiler will optimize those pointless additions away
anyway.
"Öö Tiib" <ootiib@hot.ee>: May 05 12:07AM -0700

On Tuesday, 5 May 2020 09:57:23 UTC+3, Öö Tiib wrote:
 
> To silence your sanitizers use something like:
 
> uint64_t u = n < 0 ? static_cast<uint64_t>(1 - n) + 1 :
> static_cast<uint64_t>(n);
 
I wrote a typo ... what I meant was
 
uint64_t u = n < 0 ? static_cast<uint64_t>(-(n + 1)) + 1 :
static_cast<uint64_t>(n);
jacobnavia <jacob@jacob.remcomp.fr>: May 05 11:08AM +0200

Le 05/05/2020 à 08:35, Alf P. Steinbach a écrit :
> Now the Visual C++ compiler phones home, generates executables that also
> phone Microsoft,
 
WHAT?
 
Can you specify a little bit more? A reference? Some proof?
 
Thanks in advance
Tim Rentsch <tr.17687@z991.linuxsc.com>: May 05 02:15AM -0700

> max: 9223372036854775807
 
> Which makes sanitizers unhappy.
 
> So, how to express (*)?
 
I suggest
 
uint64_t u = n < 0 ? 0ULL - n : n;
James Kuyper <jameskuyper@alumni.caltech.edu>: May 05 09:35AM -0400

On 5/5/20 2:13 AM, Keith Thompson wrote:
> and got this:
> 5>main.cpp(36): error C2220: warning treated as error - no 'object' file generated
> 5>main.cpp(36): warning C4146: unary minus operator applied to unsigned type, result still unsigned
 
This is a prime example of the stupid warnings that are the reason I
don't like the policy which says "Must compile without warnings", and
the corresponding compiler option of treating warnings as errors. My
coding style shouldn't be determined by the vagaries of implementor's
warnings.
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: May 05 01:13PM +0100

The demise of Qt is inevitable which is great news for neoGFX! \o/
 
https://mail.kde.org/pipermail/kde-community/2020q2/006098.html
 
/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," Byrne 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."
Christian Gollwitzer <auriocus@gmx.de>: May 05 02:48PM +0200

Am 05.05.20 um 14:13 schrieb Mr Flibble:
> The demise of Qt is inevitable which is great news for neoGFX! \o/
 
> https://mail.kde.org/pipermail/kde-community/2020q2/006098.html
 
How's your Linux port doing? And the transpiler from moc-C++ to neoGFX-C++?
Christian
gazelle@shell.xmission.com (Kenny McCormack): May 05 01:43AM

In article <333d3964-7f46-4594-a953-36c25d344565@googlegroups.com>,
ร รถ Tiib <ootiib@hot.ee> wrote:
...
>At least you admit that you like noise.
 
Yes, I view CLC/CLC++ as like a sitcom. Funny to watch. I don't mind
admitting that I like watching comedy shows.
 
I don't see how that is a problem.
 
--
Just for a change of pace, this sig is *not* an obscure reference to
comp.lang.c...
"Öö Tiib" <ootiib@hot.ee>: May 04 11:46PM -0700

On Tuesday, 5 May 2020 04:43:36 UTC+3, Kenny McCormack wrote:
 
> Yes, I view CLC/CLC++ as like a sitcom. Funny to watch. I don't mind
> admitting that I like watching comedy shows.
 
> I don't see how that is a problem.
 
For me there are no problem. Everybody involved knows 100% what to expect
under topic "[Jesus Loves You] The soon catastrophe on Earth" anyway. So
responding to such topics is kind of game I guess.
Juha Nieminen <nospam@thanks.invalid>: May 05 06:29AM

> In one way this is good, in the sense that a game app's available time
> won't be used up in rendering, or (hopefully) shuffling data to GPU.
 
> However, do you actually have a monitor with 450 Hz or better refresh rate?
 
For benchmarking purposes uncapped framerates are used to see how fast the
hardware (or software) is. It's not supposed to be played like that.
 
As for refresh rates, most people can tell the difference between a 60Hz
display and a 120Hz display. Especially experienced gamers are able to
tell which is which with 100% accuracy, even in a "blind" test ("blind"
in the sense that they don't know in advance which one they will be
presented). For most regular gamers, while they may be able to tell
the difference, it won't make much difference in terms of gameplay.
For more professional online first-person shooter players it can make
quite a difference.
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)