"David Brown" <david.brown@hesbynett.no> wrote in message news:nb7l4g$5m3$1@dont-email.me...> On 02/03/16 18:58, tim... wrote: >> >> "Tim Wescott" <tim@seemywebsite.com> wrote in message >> news:OaidnQaVUvYumEvLnZ2dnUU7-UmdnZ2d@giganews.com... >>> On Tue, 01 Mar 2016 21:02:46 +0000, tim... wrote: >>> >>>> Today, I discovered that if you use: >>>> >>>> const unsigned int xxx = value; (which in this case happens to be = 0) >>>> >>>> and then in the code try and compare it with a signed int yyy >>>> >>>> the compiler ignores your signed int and does an unsigned compare. >>>> >>>> Up until now this hadn't been a problem as I've (quite by chance) >>>> always >>>> looked for equality with the const. >>>> >>>> But today I counted yyy down to -1 wishing to stop when yyy < xxx but >>>> the sodding compiler decided that I now had a very large positive >>>> number >>>> and refused to break from my loop. >>>> >>>> Took me flipping ages to work out what was wrong :-( >>>> >>>> The compiler does give me a warning - that I am comparing a signed with >>>> an unsigned but as I was sure that the unsigned int was the zero value >>>> const I didn't give it a second thought. >>>> >>>> But I did get rid of it by using a c-style cast to make the unsigned >>>> int >>>> a signed one when comparing, and that suppressed the warning, but it >>>> still didn't work. - not until I redefined my const as signed! >>>> >>>> I'm not hugely experienced with C++ [1], is it meant to work like this >>>> or do I have a broken compiler? >>>> >>>> We're using GCC >>>> >>>> TIA >>>> >>>> Tim >>>> >>>> [1] nor are any of my co-workers, finding good ones who will work for >>>> the pittance that embedded work now pays in my neck of the woods is >>>> tres >>>> difficult :-) >>> >>> 1: Yes, it's supposed to work like that. Google "automatic type >>> conversions". >>> >>> 2: I'm pretty sure that C is supposed to work like that, too. If it >>> isn't, then the behavior is implementation defined -- meaning that it >>> won't be predictable at all. >> >> If I was working in C I wouldn't have the a typed const variable at all >> I'd be using an untyped define > > Why?I dunno But I've only ever come across the rule to do it this way in C++ No C shop I have ever worked in has said "never used defines for constant (numeric) values", all of the C++ ones have tim
C++ problem
Started by ●March 1, 2016
Reply by ●March 3, 20162016-03-03
Reply by ●March 3, 20162016-03-03
"David Brown" <david.brown@hesbynett.no> wrote in message news:nb7lbg$5m3$3@dont-email.me...> On 02/03/16 19:03, tim... wrote: >> >> "rickman" <gnuarm@gmail.com> wrote in message >> news:nb59m8$9qc$1@dont-email.me... >>> On 3/1/2016 5:20 PM, Hans-Bernhard Br�ker wrote: >>>> Am 01.03.2016 um 22:02 schrieb tim...: >>>>> The compiler does give me a warning - that I am comparing a signed >>>>> with >>>>> an unsigned but as I was sure that the unsigned int was the zero value >>>>> const I didn't give it a second thought. >>>> >>>> That reasoning was just wrong. The thing you were sure about is >>>> correct. It doesn't support the conclusion you drew, though. >>>> >>>>> But I did get rid of it by using a c-style cast to make the unsigned >>>>> int a signed one when comparing, and that suppressed the warning, but >>>>> it still didn't work. - not until I redefined my const as signed! >>>> >>>> That attempt most probably failed in some other, unrelated way. Which >>>> way it was can only be found out if you show an actual, essentially >>>> complete (as in: compilable) example case. >>> >>> That's easy. He said he was counting down to -1 which won't work if >>> the value is cast to an unsigned. >> >> It wasn't cast to an unsigned, it was compared to an unsigned (the cast >> was an attempt to make the unsigned signed - but that didn't work either) >> >> tim >> > > Again, if you really want help,I don't need "help". I have solved it now. I just wanted to know if it was my mistake, or the compliers. As I said, my C++ experience is limited - and all self taught (for that matter the second part apples to my C experience) But in 25 years of C programming I have never come across this issue before. That could be because I have never tried to do the same thing (as I said earlier, if I was writing the exact same solution in C my zero cionstant comparison value would have been a define - and in upper case.) But that still leaves the possibility that I might have used a comparison between a signed and an unsigned variable. tim
Reply by ●March 3, 20162016-03-03
"Robert Wessel" <robertwessel2@yahoo.com> wrote in message news:qvaedblbi865f99v89n7h5hco7ilp6mgsf@4ax.com...> On Wed, 2 Mar 2016 17:55:20 -0000, "tim..." <tims_new_home@yahoo.com> > wrote: > >> >>"Phil Hobbs" <pcdhSpamMeSenseless@electrooptical.net> wrote in message >>news:1vmdnTElaNo_lUrLnZ2dnUU7-RHNnZ2d@supernews.com... >>> On 03/01/2016 04:12 PM, Tim Wescott wrote: >>>> On Tue, 01 Mar 2016 21:02:46 +0000, tim... wrote: >>>> >>>>> Today, I discovered that if you use: >>>>> >>>>> const unsigned int xxx = value; (which in this case happens to be >>>>> = 0) >>>>> >>>>> and then in the code try and compare it with a signed int yyy >>>>> >>>>> the compiler ignores your signed int and does an unsigned compare. >>>>> >>>>> Up until now this hadn't been a problem as I've (quite by chance) >>>>> always looked for equality with the const. >>>>> >>>>> But today I counted yyy down to -1 wishing to stop when yyy < xxx >>>>> but the sodding compiler decided that I now had a very large >>>>> positive number and refused to break from my loop. >>>>> >>>>> Took me flipping ages to work out what was wrong :-( >>>>> >>>>> The compiler does give me a warning - that I am comparing a signed >>>>> with an unsigned but as I was sure that the unsigned int was the >>>>> zero value const I didn't give it a second thought. >>>>> >>>>> But I did get rid of it by using a c-style cast to make the >>>>> unsigned int a signed one when comparing, and that suppressed the >>>>> warning, but it still didn't work. - not until I redefined my >>>>> const as signed! >>>>> >>>>> I'm not hugely experienced with C++ [1], is it meant to work like >>>>> this or do I have a broken compiler? >>>>> >>>>> We're using GCC >>>>> >>>>> TIA >>>>> >>>>> Tim >>>>> >>>>> [1] nor are any of my co-workers, finding good ones who will work >>>>> for the pittance that embedded work now pays in my neck of the >>>>> woods is tres difficult :-) >>>> >>>> 1: Yes, it's supposed to work like that. Google "automatic type >>>> conversions". >>> >>> Yup, downcounting loops with unsigned loop counters is a classic bug. >>> The OP will remember next time. ;) >> >>The counter IS (was) signed, it is the const value being compared against >>that is not > > > Either way - the usual promotions cause to conversion to unsigned if > either argument is unsigned.I am not disagreeing with you (as I don't know.) But the point is, the first mistake makes me an idiot, the second just lacking in knowledge tim
Reply by ●March 3, 20162016-03-03
"rickman" <gnuarm@gmail.com> wrote in message news:nb9pj9$a3l$2@dont-email.me...> On 3/3/2016 12:32 AM, Philip Lantz wrote: >> rickman wrote: >>> >>> On 3/2/2016 4:18 PM, Hans-Bernhard Br�ker wrote: >>>> Am 02.03.2016 um 00:50 schrieb rickman: >>>>> On 3/1/2016 5:20 PM, Hans-Bernhard Br�ker wrote: >>>>>> Am 01.03.2016 um 22:02 schrieb tim...: >>>> >>>>>>> But I did get rid of it by using a c-style cast to make the unsigned >>>>>>> int a signed one when comparing, and that suppressed the warning, >>>>>>> but >>>>>>> it still didn't work. - not until I redefined my const as signed! >>>> >>>>>> That attempt most probably failed in some other, unrelated way. >>>>>> Which >>>>>> way it was can only be found out if you show an actual, essentially >>>>>> complete (as in: compilable) example case. >>>>> >>>>> That's easy. He said he was counting down to -1 which won't work if >>>>> the >>>>> value is cast to an unsigned. >>>> >>>> No, it's not that easy, because per his actual statement (see above) he >>>> did _not_ cast the signed -1 to unsigned in this try; he said he cast >>>> the const unsigned 0 to signed, instead. That should have worked. >>> >>> Yes, I have it backwards. So why didn't that work? >> >> I'm sure we could easily figure it out, but only if he shows us the code. > > The OP has responded at least once, but no code. Funny...cos I access usenet at home and the code is at work (I'm on GMT, so I'm now at home) :-( tim
Reply by ●March 3, 20162016-03-03
On 3/3/2016 2:01 PM, tim... wrote:> > "David Brown" <david.brown@hesbynett.no> wrote in message > news:nb7lbg$5m3$3@dont-email.me... >> On 02/03/16 19:03, tim... wrote: >>> >>> "rickman" <gnuarm@gmail.com> wrote in message >>> news:nb59m8$9qc$1@dont-email.me... >>>> On 3/1/2016 5:20 PM, Hans-Bernhard Br�ker wrote: >>>>> Am 01.03.2016 um 22:02 schrieb tim...: >>>>>> The compiler does give me a warning - that I am comparing a signed >>>>>> with >>>>>> an unsigned but as I was sure that the unsigned int was the zero >>>>>> value >>>>>> const I didn't give it a second thought. >>>>> >>>>> That reasoning was just wrong. The thing you were sure about is >>>>> correct. It doesn't support the conclusion you drew, though. >>>>> >>>>>> But I did get rid of it by using a c-style cast to make the unsigned >>>>>> int a signed one when comparing, and that suppressed the warning, but >>>>>> it still didn't work. - not until I redefined my const as signed! >>>>> >>>>> That attempt most probably failed in some other, unrelated way. Which >>>>> way it was can only be found out if you show an actual, essentially >>>>> complete (as in: compilable) example case. >>>> >>>> That's easy. He said he was counting down to -1 which won't work if >>>> the value is cast to an unsigned. >>> >>> It wasn't cast to an unsigned, it was compared to an unsigned (the cast >>> was an attempt to make the unsigned signed - but that didn't work >>> either) >>> >>> tim >>> >> >> Again, if you really want help, > > I don't need "help". > > I have solved it now. > > I just wanted to know if it was my mistake, or the compliers. As I > said, my C++ experience is limited - and all self taught (for that > matter the second part apples to my C experience)So was it your mistake or the compiler's? I still don't know what you did so the type cast didn't work.> But in 25 years of C programming I have never come across this issue > before. > > That could be because I have never tried to do the same thing (as I said > earlier, if I was writing the exact same solution in C my zero cionstant > comparison value would have been a define - and in upper case.) But > that still leaves the possibility that I might have used a comparison > between a signed and an unsigned variable.I worked at a place that wouldn't let me access usenet and it was an issue. I liked getting advice from the many which included company representatives at that time. My bosses attitude was, "ask people here" which was his typical short sightedness. -- Rick
Reply by ●March 3, 20162016-03-03
"rickman" <gnuarm@gmail.com> wrote in message news:nba2lt$g4d$2@dont-email.me...> On 3/3/2016 2:01 PM, tim... wrote: >> >> "David Brown" <david.brown@hesbynett.no> wrote in message >> news:nb7lbg$5m3$3@dont-email.me... >>> On 02/03/16 19:03, tim... wrote: >>>> >>>> "rickman" <gnuarm@gmail.com> wrote in message >>>> news:nb59m8$9qc$1@dont-email.me... >>>>> On 3/1/2016 5:20 PM, Hans-Bernhard Br�ker wrote: >>>>>> Am 01.03.2016 um 22:02 schrieb tim...: >>>>>>> The compiler does give me a warning - that I am comparing a signed >>>>>>> with >>>>>>> an unsigned but as I was sure that the unsigned int was the zero >>>>>>> value >>>>>>> const I didn't give it a second thought. >>>>>> >>>>>> That reasoning was just wrong. The thing you were sure about is >>>>>> correct. It doesn't support the conclusion you drew, though. >>>>>> >>>>>>> But I did get rid of it by using a c-style cast to make the unsigned >>>>>>> int a signed one when comparing, and that suppressed the warning, >>>>>>> but >>>>>>> it still didn't work. - not until I redefined my const as signed! >>>>>> >>>>>> That attempt most probably failed in some other, unrelated way. >>>>>> Which >>>>>> way it was can only be found out if you show an actual, essentially >>>>>> complete (as in: compilable) example case. >>>>> >>>>> That's easy. He said he was counting down to -1 which won't work if >>>>> the value is cast to an unsigned. >>>> >>>> It wasn't cast to an unsigned, it was compared to an unsigned (the cast >>>> was an attempt to make the unsigned signed - but that didn't work >>>> either) >>>> >>>> tim >>>> >>> >>> Again, if you really want help, >> >> I don't need "help". >> >> I have solved it now. >> >> I just wanted to know if it was my mistake, or the compliers. As I >> said, my C++ experience is limited - and all self taught (for that >> matter the second part apples to my C experience) > > So was it your mistake or the compiler's? I still don't know what you did > so the type cast didn't work.OK I'll try that again tomorrow. I'll try the C++ cast as well and if it still doesn't work I'll cut a copy of the code for you> > >> But in 25 years of C programming I have never come across this issue >> before. >> >> That could be because I have never tried to do the same thing (as I said >> earlier, if I was writing the exact same solution in C my zero cionstant >> comparison value would have been a define - and in upper case.) But >> that still leaves the possibility that I might have used a comparison >> between a signed and an unsigned variable. > > I worked at a place that wouldn't let me access usenet and it was an > issue.It's not really forbidden (as far as I can tell), just that I haven't taken the time to set up a newsreader> I liked getting advice from the many which included company > representatives at that time. My bosses attitude was, "ask people here" > which was his typical short sightedness.the last place that I worked it was normal to put queries on stackoverflow.com tim> > -- > > Rick
Reply by ●March 3, 20162016-03-03
On 03/03/16 19:53, tim... wrote:> > "David Brown" <david.brown@hesbynett.no> wrote in message > news:nb7l4g$5m3$1@dont-email.me... >> On 02/03/16 18:58, tim... wrote:>>> >>> If I was working in C I wouldn't have the a typed const variable at all >>> I'd be using an untyped define >> >> Why? > > I dunno >The first step to progress is to question conventional wisdom!> But I've only ever come across the rule to do it this way in C++ > > No C shop I have ever worked in has said "never used defines for > constant (numeric) values", all of the C++ ones have >A good many "rules" for C, or coding standards, have a long heritage - stretching back to when ANSI C was new, and "const" was a strange, newfangled concept with poor compiler support. And for a long time, many embedded C compilers have been rather limited or inefficient - if you made your fixed values as "static const int" the compiler would put that value into flash (or even ram) and read it from there, rather than optimising the value at compile time. Needless to say, this could be very inefficient. While most compilers these days are better than that, the myth lives on. There is also the issue that in C, unlike in C++, a "static const" is not a constant expression - you can't use it as a switch label, or for giving the size of an array. So while I fully agree with you that C++ guidelines commonly emphasis const's over #define's, and C guidelines commonly do not, I recommend using static const in C code too.
Reply by ●March 3, 20162016-03-03
On 03/03/16 20:12, tim... wrote:> > "rickman" <gnuarm@gmail.com> wrote in message > news:nb9pj9$a3l$2@dont-email.me... >> On 3/3/2016 12:32 AM, Philip Lantz wrote: >>> rickman wrote: >>>> >>>> On 3/2/2016 4:18 PM, Hans-Bernhard Br�ker wrote: >>>>> Am 02.03.2016 um 00:50 schrieb rickman: >>>>>> On 3/1/2016 5:20 PM, Hans-Bernhard Br�ker wrote: >>>>>>> Am 01.03.2016 um 22:02 schrieb tim...: >>>>> >>>>>>>> But I did get rid of it by using a c-style cast to make the >>>>>>>> unsigned >>>>>>>> int a signed one when comparing, and that suppressed the >>>>>>>> warning, but >>>>>>>> it still didn't work. - not until I redefined my const as signed! >>>>> >>>>>>> That attempt most probably failed in some other, unrelated way. >>>>>>> Which >>>>>>> way it was can only be found out if you show an actual, essentially >>>>>>> complete (as in: compilable) example case. >>>>>> >>>>>> That's easy. He said he was counting down to -1 which won't work >>>>>> if the >>>>>> value is cast to an unsigned. >>>>> >>>>> No, it's not that easy, because per his actual statement (see >>>>> above) he >>>>> did _not_ cast the signed -1 to unsigned in this try; he said he cast >>>>> the const unsigned 0 to signed, instead. That should have worked. >>>> >>>> Yes, I have it backwards. So why didn't that work? >>> >>> I'm sure we could easily figure it out, but only if he shows us the >>> code. >> >> The OP has responded at least once, but no code. Funny... > > cos I access usenet at home and the code is at work > > (I'm on GMT, so I'm now at home) >We are only looking for a snippet that demonstrates the problem. At work tomorrow, figure out a minimal code example that shows the issue, using fake names to protect the innocent (and guilty), then copy it to a post-it note and smuggle it home and post it here tomorrow night. We should be able to figure out where the misunderstanding lies - escalating to comp.lang.c or compiler mailing lists if necessary.
Reply by ●March 3, 20162016-03-03
On 3/3/2016 3:22 PM, David Brown wrote:> On 03/03/16 20:12, tim... wrote: >> >> "rickman" <gnuarm@gmail.com> wrote in message >> news:nb9pj9$a3l$2@dont-email.me... >>> On 3/3/2016 12:32 AM, Philip Lantz wrote: >>>> rickman wrote: >>>>> >>>>> On 3/2/2016 4:18 PM, Hans-Bernhard Br�ker wrote: >>>>>> Am 02.03.2016 um 00:50 schrieb rickman: >>>>>>> On 3/1/2016 5:20 PM, Hans-Bernhard Br�ker wrote: >>>>>>>> Am 01.03.2016 um 22:02 schrieb tim...: >>>>>> >>>>>>>>> But I did get rid of it by using a c-style cast to make the >>>>>>>>> unsigned >>>>>>>>> int a signed one when comparing, and that suppressed the >>>>>>>>> warning, but >>>>>>>>> it still didn't work. - not until I redefined my const as signed! >>>>>> >>>>>>>> That attempt most probably failed in some other, unrelated way. >>>>>>>> Which >>>>>>>> way it was can only be found out if you show an actual, essentially >>>>>>>> complete (as in: compilable) example case. >>>>>>> >>>>>>> That's easy. He said he was counting down to -1 which won't work >>>>>>> if the >>>>>>> value is cast to an unsigned. >>>>>> >>>>>> No, it's not that easy, because per his actual statement (see >>>>>> above) he >>>>>> did _not_ cast the signed -1 to unsigned in this try; he said he cast >>>>>> the const unsigned 0 to signed, instead. That should have worked. >>>>> >>>>> Yes, I have it backwards. So why didn't that work? >>>> >>>> I'm sure we could easily figure it out, but only if he shows us the >>>> code. >>> >>> The OP has responded at least once, but no code. Funny... >> >> cos I access usenet at home and the code is at work >> >> (I'm on GMT, so I'm now at home) >> > > We are only looking for a snippet that demonstrates the problem. At > work tomorrow, figure out a minimal code example that shows the issue, > using fake names to protect the innocent (and guilty), then copy it to a > post-it note and smuggle it home and post it here tomorrow night. We > should be able to figure out where the misunderstanding lies - > escalating to comp.lang.c or compiler mailing lists if necessary.Isn't this group accessible by Google groups? Certainly that would work ok to make one post of the code from work. Or you can do like was done with the DeCSS program and print it on a tshirt and wear it home. lol Is there a word for searching on the Internet for one thing and 15 minutes later coming up with a dozen other interesting topics? I know that was featured in an XKCD cartoon. Seems like there should be a word... I was looking for the name of the group that spread the word about the DeCSS program and ended up learning about Martha Payne, a 9 year old who started a blog about the school lunches and ended up collecting �143,000 for charities. -- Rick
Reply by ●March 4, 20162016-03-04
"David Brown" <david.brown@hesbynett.no> wrote in message news:nba61c$vc5$1@dont-email.me...> On 03/03/16 19:53, tim... wrote: >> >> "David Brown" <david.brown@hesbynett.no> wrote in message >> news:nb7l4g$5m3$1@dont-email.me... >>> On 02/03/16 18:58, tim... wrote: > >>>> >>>> If I was working in C I wouldn't have the a typed const variable at all >>>> I'd be using an untyped define >>> >>> Why? >> >> I dunno >> > > The first step to progress is to question conventional wisdom!I have: I like the "C" rule. I like that fact that consts are identified by them being in Caps, it is useful. I hate the fact that in C++ they look like normal variables, so I questioned the C++ rule, and because I am less experienced in C++ than the person who oversees the rules I get told to "take a hike". You may think that the stronger typing helps you get to working code. My experience is different. In 35 years of (mostly) embedded development, a type mismatch has never ever caused a problem which (once discovered) took more than a little thought to find the source and fix. OTOH there have been multiple occasions when some different type of error that the compiler didn't spot has taken weeks to resolve.> >> But I've only ever come across the rule to do it this way in C++ >> >> No C shop I have ever worked in has said "never used defines for >> constant (numeric) values", all of the C++ ones have >> > > A good many "rules" for C, or coding standards, have a long heritage - > stretching back to when ANSI C was new, and "const" was a strange, > newfangled concept with poor compiler support. And for a long time, many > embedded C compilers have been rather limited or inefficient - if you made > your fixed values as "static const int" the compiler would put that value > into flash (or even ram) and read it from there, rather than optimising > the value at compile time. Needless to say, this could be very > inefficient. While most compilers these days are better than that, the > myth lives on. > > There is also the issue that in C, unlike in C++, a "static const" is not > a constant expression - you can't use it as a switch label, or for giving > the size of an array. > > So while I fully agree with you that C++ guidelines commonly emphasis > const's over #define's, and C guidelines commonly do not, I recommend > using static const in C code too.I shall feel free to ignore that advice tim>
