- Signed unsigned mismatch? - 3 Updates
- "My CppCon 2018 talk title and abstract" 2018-09-14 by Herb Sutter - 7 Updates
- Conservative employees "don't feel safe" - 12 Updates
- wxWidgets argh - 1 Update
- int8_t and char - 2 Updates
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:
Post a Comment