EmbeddedRelated.com
Forums
The 2026 Embedded Online Conference

C++ problem

Started by tim... March 1, 2016
rickman wrote:

> Is there a word for searching on the Internet for one thing and 15 > minutes later coming up with a dozen other interesting topics?
The 21st century version of taking an hour to look up a word in a dictionary... But I don't know of a word for it.
On 3/4/2016 4:04 AM, Philip Lantz wrote:
> rickman wrote: > >> Is there a word for searching on the Internet for one thing and 15 >> minutes later coming up with a dozen other interesting topics? > > The 21st century version of taking an hour to look up a word in a > dictionary... But I don't know of a word for it.
I should try to look that up... -- Rick
"rickman" <gnuarm@gmail.com> wrote in message 
news:nba9ku$e74$1@dont-email.me...
> 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&#4294967295;ker wrote: >>>>>>> Am 02.03.2016 um 00:50 schrieb rickman: >>>>>>>> On 3/1/2016 5:20 PM, Hans-Bernhard Br&#4294967295;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
Firstly. I stupidly forgot that it is Friday today [1], and I am not at work, so it will have to wait until Monday. and secondly I don't need clever ways to smuggle it home. I don't work in a place that has any rules about taking code home (that's not to say that they "like" it, just that they trust staff to be "professional" - which in the main, they are!). I can simply email it from my work email to my home email tim [1] Last night I mean, obviously I remember this morning not to go to work
"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
>
rickman wrote:

> Is there a word for searching on the Internet for one thing and 15 > minutes later coming up with a dozen other interesting topics?
The 21st century version of taking an hour to look up a word in a dictionary... But I don't know of a word for it.
On 3/4/2016 4:04 AM, Philip Lantz wrote:
> rickman wrote: > >> Is there a word for searching on the Internet for one thing and 15 >> minutes later coming up with a dozen other interesting topics? > > The 21st century version of taking an hour to look up a word in a > dictionary... But I don't know of a word for it.
I should try to look that up... -- Rick
"rickman" <gnuarm@gmail.com> wrote in message 
news:nba9ku$e74$1@dont-email.me...
> 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&#4294967295;ker wrote: >>>>>>> Am 02.03.2016 um 00:50 schrieb rickman: >>>>>>>> On 3/1/2016 5:20 PM, Hans-Bernhard Br&#4294967295;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
Firstly. I stupidly forgot that it is Friday today [1], and I am not at work, so it will have to wait until Monday. and secondly I don't need clever ways to smuggle it home. I don't work in a place that has any rules about taking code home (that's not to say that they "like" it, just that they trust staff to be "professional" - which in the main, they are!). I can simply email it from my work email to my home email tim [1] Last night I mean, obviously I remember this morning not to go to work
Dimiter_Popoff wrote:
> > On 03.3.2016 ?. 11:26, Paul Rubin wrote: > > Dimiter_Popoff <dp@tgi-sci.com> writes: > >> The product of SIGNED multiplication (as you repeatedly repeated) is > >> a SIGNED number and $ffff0001 being a SIGNED number is -65535. > > > > You can't multiply a positive number by a positive number and get a > > negative number, except through overflow. And in C, overflow on signed > > ints results in UB. > > > >> Then in NO working compiler would the product of a signed 16 bit > >> being -1 ($ffff) and an unsigned $ffff (65535) - being converted to > >> signed prior to multiplication > > > > Where did signed $ffff come from? I thought we were talking about > > unsigned $ffff being multiplied by itself. > > It was there from the very start of the thread and is present > throughout. > > Dimiter
I think you'll find that no one but you has mentioned a signed 16 bit number in this thread. This is the reason everyone has been disagreeing with your comments.
Dimiter_Popoff wrote:
> Paul Rubin wrote: > > Regarding "no working compiler": we're discussing the dark corners of C, > > and you have to define C as "what the standard says" rather than "what > > compilers you've looked at happen to do". If the standard says UB then > > the code is invalid. Real world C programs are full of such bugs by > > the way: > > I know programs are full of bugs and I know legacy may keep wrong > operations alive for decades but I would be seriously stunned if > it turns out that in C (which I do not use, I use my vpa > obviously) multiplying these two constants, 16 bit $ffff representing > a signed number (i.e. being -1) and 16 bit $ffff unsigned (i.e. > 65535) into a 32 bit result would not work. Then may be it would > not work indeed if they do not extend the operands to 32 bit prior > to the multiplication, a compiler writer beginners error ...
In C, assuming int is 32 bits, as it has been throughout this thread, the compiler is *required* to extend the 16-bit numbers to 32 bits before the multiplication. (Of course, the "as-if" rule allows it to avoid actually doing that in the generated code, as long as it gets the same result.)
Dimiter_Popoff wrote:

> HOWEVER, your statement that $ffff*$ffff - both unsigned - results in > a 32 bit overflow is wrong - the result is $fffe0001, a perfectly > well 32 bit representable unsigned number. > Expecting a signed result from the multiplication of two unsigned > operands would be a laughable idea but in that case it would > overflow indeed. I leave it to you to clarify how the C language > would do this by default(unsigned16*unsigned16 -> ???32), I just > don't know (nor am I particularly interested in). > > Dimiter
Since you clearly don't know how C works, I suggest you stop responding. Funny how you were advising someone to stop digging earlier.
The 2026 Embedded Online Conference