Wednesday, September 19, 2018

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

David Brown <david.brown@hesbynett.no>: Sep 19 09:36AM +0200

On 18/09/18 23:49, Bart wrote:
 
> So unsigned 16+16 bits is signed, but unsigned 32+32 is unsigned. When
> int is 32 bits, with probably different results on a different size of int.
 
> These are not even of mixed sign. (See chart I posted in clc.)
 
No matter what rules the C committee picked for integer promotion
(including having no promotion), and for mixed sign operations, there
would be expressions that gave the wrong answer or worked in a
counter-intuitive way. This is inevitable due to the limited size of
the types.
 
For example, if "u" and "v" are "unsigned short" and were promoted to
"unsigned int" rather than "int", then the expression "u + v - 10 >= 0"
would always be true - which is clearly nonsense mathematically.
 
The C committee were /not/ trying to figure out which rules would be
"right", or make most sense, or give the correct answer. They were
figuring out rules that would have the least chance of leading to errors
or surprising results. That's a different target.
 
Looking with modern eyes on the C promotion rules, I personally think
that signed preserving would have been better than promoting to "int".
But key to that is /modern/ eyes. When these rules were laid down,
there are three important points that the C committee had to consider
that do not apply when judging with modern eyes:
 
1. Existing C source code of the time should, as far as possible,
continue to work in the same way.
 
2. Existing C compilers of the time should continue to be usable where
possible (noting that some compilers promoted to "int", others preserved
signedness).
 
3. Existing C of the time was "int everywhere". Everything was "int" by
default - variables, expressions, function returns, function parameters.
Such "implicit int" is now gone from the language (or at least
obsolescent), but that was not the case when the integer promotion rules
were determined.
David Brown <david.brown@hesbynett.no>: Sep 19 09:44AM +0200

On 18/09/18 23:29, Rick C. Hodgin wrote:
> was the decision they made. And I stated I disagree with it. I
> was surprised by your reply to me, James. I think any person would
> think the C committee got it wrong (especially in hindsight).
 
Clearly /not/ everyone thinks the C committee got it wrong. The
committee did not pick their rules by tossing a coin - they thought long
and hard about it before reaching a decision. And these were people
with long experience of C programming, C compiler writing, and
programming in general, and with an eye to the future of C. You can be
very sure they put a lot more thought and research into the matter than
either you or I have done. And they reached the conclusion they did,
based on the C world of the time. (See my reply to Bart for a few more
points - there is no need to repeat them here.)
 
With hindsight, in the modern C world, signedness preserving promotion
would be better for many people - I would prefer it myself. Actually, I
would prefer there to be /no/ promotion other than to a minimum common
type that spanned both value ranges. (Thus u8 + u8 would be done as u8,
but u16 + i8 would be done as i32.)
 
This does not mean that signedness preserving promotion would be better
for everyone - other people may, as the C committee did back then, give
more weighting to the argument that promoting to int reduces the risk of
having mixed sign operations.
 
When programming in C - as always - you need to know the rules of C,
even when you think they are sub-optimal. It is not hard to get the
effects you want in this case. You just use casts, or temporary
variables of the types you want, in order to get the results. And you
can often use compiler warnings to help catch cases where you got it wrong.
Bart <bc@freeuk.com>: Sep 19 10:57AM +0100

On 19/09/2018 08:36, David Brown wrote:
> would be expressions that gave the wrong answer or worked in a
> counter-intuitive way. This is inevitable due to the limited size of
> the types.
 
By using signed for mixed arithmetic instead of unsigned (more of a beef
for me than sign change on promotion, which is a new quirk I wasn't
really aware of), then the cases where it goes wrong will be pushed out
to the extreme ranges of possible values (well, half-way to those
extremes, instead of clustered around zero).
 
 
> For example, if "u" and "v" are "unsigned short" and were promoted to
> "unsigned int" rather than "int", then the expression "u + v - 10 >= 0"
> would always be true - which is clearly nonsense mathematically.
 
It already creates nonsense:
 
uint64_t u=3,v=4;
 
printf("u = %llu, v = %llu\n",u,v);
printf("signed(u+v-10) = %lld\n",u+v-10);
printf("unsigned(u+v-10) = %llu\n",u+v-10);
 
if (u+v-10 >= 0) puts("u+v-10 >= 0"); else puts("u+v-10 < 0");
 
This tells me that u+v-10 (which has a mathematical value of -3) is
greater than zero. Due to using unsigned for the "-" operation. If I
force that to be signed:
 
if ((int64_t)(u+v)-10 >= 0) puts("u+v-10 >= 0");
else puts("u+v-10 < 0");
 
Then I get the mathematically correct answer. It will only start to go
wrong when u+v is greater than about 2**63.
 
Of course, if you do: 'v = u-10;' when u<10, then you will always end
up with a very large unsigned value. There will always be such problems,
but C as it is makes it worse I think.
 
--
bart
Paavo Helde <myfirstname@osa.pri.ee>: Sep 19 08:11AM +0300

On 19.09.2018 2:56, Alf P. Steinbach wrote:
> way to have a not-so-unsafe implicit conversion to bool so as to be able
> to write terse but unclear code, e.g. `if( stream )` instead of the more
> verbose but more clear `if( not stream.in_fail_mode() )`.
 
Operator bool helps to limit the scope of variables which is a good thing:
 
if (auto stream = std::ifstream("c:/tmp/foo.bar")) { //...
 
if (auto ptr = someWeakPtr.lock()) { // ...
 
Conversion operators in general are not so useful, but sometimes they
are handy, e.g. for wrapping primitive types like ints for special
behavior. For example, one might use a simple mod 8 int type for
considering the possible 8 directions in some 2D pixel level algorithm.
Instead of declaring a bunch of arithmetic operations on the type one
can just use int for arithmetic and normalize the result into 0..7 range
in the ctor:
 
Direction dir1 = 0; // north
Direction dir2 = dir1 + 2; // east
Direction dir3 = dir1 - 2*dir2; // west
 
With named conversion functions the last line would become too verbose
for my taste, considering that the low-level algorithm would be littered
with those conversions:
 
Direction dir3 = dir1.to_int() - 2*dir2.to_int();
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Sep 19 08:29AM +0200

On 19.09.2018 07:11, Paavo Helde wrote:
>> verbose but more clear `if( not stream.in_fail_mode() )`.
 
> Operator bool helps to limit the scope of variables which is a good thing:
 
> if (auto stream = std::ifstream("c:/tmp/foo.bar")) { //...
 
For comparisons with the following examples, the way I format it it
would look like
 
if( auto stream = ifstream( filepath ) )
{
//...
}
 
So many programmers are confused about stream.good() and stream.fail(),
which are not opposites. With an explicit call of .fail() they know
what's checked. An explicit call to .fail() adds more source code,
that's a cost, but it's not a prohibitive cost.
 
One way to write out that call:
 
if( auto stream = ifstream( filepath ); not stream.fail() )
{
//...
}
 
Well, that's C++17 syntax that may not be available in every corporate
setting. But.
 
Another way:
 
do {
auto stream = ifstream( filepath );
if( stream.fail() ) { break; }
 
//...
} while( 0 );
 
A third way, which I would probably choose:
 
void do_stuff( const string& filepath )
{
auto stream = ifstream( filepath );
if( stream.fail() ) { return; }
 
//...
}
 
//...
do_stuff( filepath );
 
 
 
> if (auto ptr = someWeakPtr.lock()) { // ...
 
Using a raw or smart pointer as a boolean condition is so common that I
think this one's justified. Unlike with the stream there is no doubt
about what the implicit conversion to bool does. And the work done by
the `if` body is probably not so extensive as with something that
accesses a file, and is probably more tightly coupled to the context.
 
 
> for my taste, considering that the low-level algorithm would be littered
> with those conversions:
 
> Direction dir3 = dir1.to_int() - 2*dir2.to_int();
 
Not sure about this one.
 
I think when I've done this I've just used `int` directly. :)
 
 
Cheers!,
 
- Alf
David Brown <david.brown@hesbynett.no>: Sep 19 08:56AM +0200

>> narrow air passage in the upper nose (this is an inheritable trait).
 
> Or because a lot of dumb people have a tendency to have their mouth open when
> thinking. Or just when chewing gum.
 
Eh, no.
 
>> Having narrow nasal air passages, leading to mouth breathing, is a
 
> Yeah, I'm sure its that.
 
I'm glad you now understand. It really isn't difficult.
 
 
>> A little googling showed me that some American's think "mouth breathing"
>> is an insult suggesting someone is stupid. It's a bit like calling
 
> Well I'm not american so its somewhat more widespread.
 
I have no idea where you are from - all I said was that I found some
Americans use the phrase "mouth breather" to mean "stupid person".
 
It is much like the kind of ignorant, thoughtless and prejudice jokes
and bullying that was common in the schoolyard when I was a kid in the
70's and 80's. I am very glad I have moved on since those days, and as
far as I can see, so have schoolyards. Maybe such progress has not
reached you yet.
 
>> human being that you give yourself out to be.
 
> If being an unpleasant turd means I won't roll over and mea culpa for your
> self righteous virtue signalling bullshit then guilty as charged.
 
So if the idiotic name-calling was /not/ your fault, whose was it?
David Brown <david.brown@hesbynett.no>: Sep 19 09:01AM +0200

On 19/09/18 08:29, Alf P. Steinbach wrote:
 
>> Direction dir3 = dir1.to_int() - 2*dir2.to_int();
 
> Not sure about this one.
 
> I think when I've done this I've just used `int` directly. :)
 
I think that all boils down to "conversion operators are occasionally,
but not often, useful to me". And I expect that applies to many people,
with the degree of usefulness depending on the sort of class you are
making. "explicit" conversion operators just means you can make them a
little safer and more convenient without going through the hoops of the
"safe boolean idiom".
boltar@cylonHQ.com: Sep 19 08:51AM

On Tue, 18 Sep 2018 22:03:12 +0200
 
>I would never be able to convince you - you have already decided that
>you don't like C++, and in particular you don't like the newer features
>that you don't understand.
 
You certainly won't convince me if you're unable to provide an example to
back up your assertions which seems to be the case. If this new syntax is
as useful as you claim then this shouldn't be a problem surely.
boltar@cylonHQ.com: Sep 19 08:58AM

On Wed, 19 Sep 2018 08:56:42 +0200
>70's and 80's. I am very glad I have moved on since those days, and as
>far as I can see, so have schoolyards. Maybe such progress has not
>reached you yet.
 
If only I had my violin with me....
 
I bet you were the sort of kid who burst into tears and ran to teacher as
soon as anyone called you a name.
 
 
>> If being an unpleasant turd means I won't roll over and mea culpa for your
>> self righteous virtue signalling bullshit then guilty as charged.
 
>So if the idiotic name-calling was /not/ your fault, whose was it?
 
You're assuming I was at fault in the first place. Sometimes insults are
required.
Ian Collins <ian-news@hotmail.com>: Sep 19 09:02PM +1200

On 19/09/18 01:29, David Brown wrote:
> breaths through their mouths a lot, rather than through their nose.
> There can be many reasons for this, such as simply having a physically
> narrow air passage in the upper nose (this is an inheritable trait).
 
Or my my case, due to spring hay fever :)
 
--
Ian.
"Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Sep 18 02:57PM -0700

On 9/18/2018 5:38 AM, Rick C. Hodgin wrote:
 
> Yes.
 
>> and all sorts of attractions.
 
> No.
 
Are you attracted to programming? I am.
 
 
> even in their professed ignorance against God, yet did they know the
> truth in their core.  They rejected that truth and stood in full-on
> rebellion against God.
[...]
"Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Sep 18 02:58PM -0700

On 9/18/2018 2:55 PM, Rick C. Hodgin wrote:
 
> I told you:  "tool of the enemy"
 
> You're falling for his trap:  "Come to me on my terms, or I'm
> outta here, sucka!"
 
You are 100% with me, or 100% against me: Okay?
 
 
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Sep 18 06:07PM -0400

On 9/18/2018 5:57 PM, Chris M. Thomasson wrote:
 
>>> and all sorts of attractions.
>> No.
 
> Are you attracted to programming? I am.
 
David was talking about physical attractions between people.
 
And to answer your questions: some days less than others. :-)
 
--
Rick C. Hodgin
"Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Sep 18 03:07PM -0700

On 9/17/2018 3:06 PM, Rick C. Hodgin wrote:
>> A noiseless patient Spider? ;^)
 
> I think Eternal September adds that to the posts.  Either that or
> a default setting in Thunderbird.
[...]
 
Does it show up on my posts? I use Thunderbird and Eternal September as
well. Humm... Cannot remember if it put a default name in the
Organization field. Afaict, did you write the phrase:
 
"A noiseless patient Spider"
 
?
 
I notice it in several places, for instance: in the following post:
 
http://mathforum.org/kb/thread.jspa?threadID=2708374
"Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Sep 18 03:10PM -0700

On 9/18/2018 3:07 PM, Chris M. Thomasson wrote:
 
> ?
 
> I notice it in several places, for instance: in the following post:
 
> http://mathforum.org/kb/thread.jspa?threadID=2708374
 
It must be a default.
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Sep 18 06:12PM -0400

On 9/18/2018 6:07 PM, Chris M. Thomasson wrote:
> Afaict, did you write the phrase:
 
> "A noiseless patient Spider"
 
> ?
 
My Organization field is blank in Thunderbird. I see your headers:
 
Path: eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>
Newsgroups: comp.lang.c++
Subject: Re: Conservative employees "don't feel safe"
Date: Tue, 18 Sep 2018 15:07:34 -0700
Organization: n/a
[snip]
 
You have n/a in there. Is that what it shows up when you right-click
on your Eternal September grouping and choose "Settings"?
 
I'll do a test and put in n/a after this and see what happens.
 
--
Rick C. Hodgin
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Sep 18 06:13PM -0400

On 9/18/2018 6:10 PM, Chris M. Thomasson wrote:
> It must be a default.
 
On this one I put in "Liberty Software Foundation".
 
--
Rick C. Hodgin
"Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Sep 18 03:17PM -0700

On 9/18/2018 3:13 PM, Rick C. Hodgin wrote:
> On 9/18/2018 6:10 PM, Chris M. Thomasson wrote:
>> It must be a default.
 
> On this one I put in "Liberty Software Foundation".
 
Yes, I see it. Thanks Rick.
"Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Sep 18 03:18PM -0700

On 9/18/2018 3:12 PM, Rick C. Hodgin wrote:
> [snip]
 
> You have n/a in there.  Is that what it shows up when you right-click
> on your Eternal September grouping and choose "Settings"?
 
Yes.
 
 
> I'll do a test and put in n/a after this and see what happens.
 
Yeah. This "A noiseless patient Spider" phrase simply has to be a default.
Ian Collins <ian-news@hotmail.com>: Sep 19 04:45PM +1200

On 19/09/18 09:55, Rick C. Hodgin wrote:
 
> I told you: "tool of the enemy"
 
> You're falling for his trap: "Come to me on my terms, or I'm
> outta here, sucka!
Seeing as we we can't get past dogma, here's a couple of questions for you:
 
If you get sick, do you visit a doctor or do you reject the science
based research that gives us medicines?
 
If a family member suffered from a mental illness, would you reject the
peer reviewed studies that lead to a treatment?
 
You use a computer, do you reject the scientific processes that enabled
it to be built?
 
--
Ian
David Brown <david.brown@hesbynett.no>: Sep 19 09:08AM +0200

On 18/09/18 23:27, Rick C. Hodgin wrote:
 
> The truth doesn't work like that. The truth exists as it is, and it
> must be you who gets up to move to where the truth is, rather than
> demanding that the truth come to you on your terms.
 
So you have no evidence of any sort, no examples, no proof - just blind
faith.
 
I have news for you - evidence and examples /is/ how truth works. If
any of your beliefs were real, we'd see them in the /real/ world - real
cases, real evidence, real proof. There is no more evidence for your
god than there is for Harry Potter - it's all just in a book.
 
(I fully appreciate that your god and beliefs are real to /you/ - that's
fine. It's when you use them to judge or attempt to control others that
there is a problem.)
David Brown <david.brown@hesbynett.no>: Sep 19 09:17AM +0200

On 19/09/18 00:07, Rick C. Hodgin wrote:
>>> No.
 
>> Are you attracted to programming? I am.
 
> David was talking about physical attractions between people.
 
I was, yes. There are all sorts of physical and sexual attractions that
people have, and they are all part of who we are - and therefore normal.
 
(There are lots of kinds of attractions that should not be acted upon,
of course. Between adults who know what they are doing and are
consenting, there is no problem. When one side has some kind of power
over the other and uses it to force their way, it is immoral - the
genders of the people involved is irrelevant.)
 
#8 of the "I'd Really Rather You Didn'ts" is relevant here, especially
since this is International Talk Like a Pirate Day today.
 
"Öö Tiib" <ootiib@hot.ee>: Sep 18 11:34PM -0700

On Wednesday, 19 September 2018 03:05:44 UTC+3, Alf P. Steinbach wrote:
> that creation fails with more than that meager amount of text, so that
> the wxWidgets control silently creates with an invalid state, which some
> other part of wxWidgets detects LATER ON. :(
 
It is worth attention that wxWindows architecture was established (and
most of the core framework was written) before standardization of C++.
Code of that era assumed that exceptions and threads do not exist
and safety that is added later is doomed to fit not too well.
bitrex <user@example.net>: Sep 18 11:18PM -0400

On 09/18/2018 07:08 AM, David Brown wrote:
> specific sizes. You won't save space by using uint8_t or int8_t in
> locals (unless you are working on an 8-bit microcontroller - in which
> case cin and cout are your problem).
 
Hey man, it's the 21st century! I use output streams on 8 bit. the
"terminal" such as it is, is sometimes 4 segment alphanumeric LED
display. If you stream more than 4 characters it scrolls it like a
message board.
 
If you want a different "terminal" device then you inject the
appropriate behavior to the display
program-to-the-interface-not-the-implementation calls via
templates/static polymorphism.
 
Juha Nieminen <nospam@thanks.invalid>: Sep 19 06:21AM

> However, I
> had the impression that those [u]intX_t types were there so that I can
> do math with them, not to deal with characters.
 
You can do math with them. There is essentially no difference between the
char types and the other integral types (other than their size in bits).
 
It's just that std::istream and std::ostream have an overload for char
types specifically, which treats them differently. Whether that's a good
or a bad thing is up to opinion (and probably way too late to change),
but it's something limited to them.
 
If you want to output a char type with std::ostream, you have to do a cast.
With std::istream it becomes a bit more complicated.
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.

No comments: