C++ problem

On 3/4/2016 4:09 AM, tim... wrote:
>
> "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

Then you aren't a true engineer... <grin>

-- 

Rick

Dimiter_Popoff wrote:
> Philip Lantz wrote:
> > Dimiter_Popoff wrote:
> >> Paul Rubin wrote:
> >>> Dimiter_Popoff 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.
> >
> 
>  From the post initiating the thread:
> 
> "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 "

But those are not signed 16 bit numbers. No one but you ever
mentioned a signed 16 bit number in this thread.

Dimiter_Popoff wrote:

> I got into the thread when there was a talk exactly about
> 16 bit integers, one signed and one unsigned, no misunderstanding
> about this (to your other post).

There was never any talk about that by anyone but you.

Dimiter_Popoff wrote:
> Philip Lantz wrote:
> > Dimiter_Popoff wrote:
> >> Paul Rubin wrote:
> >>> Dimiter_Popoff 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.
> >
> 
>  From the post initiating the thread:
> 
> "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 "

But those are not signed 16 bit numbers. No one but you ever
mentioned a signed 16 bit number in this thread.

Dimiter_Popoff wrote:

> I got into the thread when there was a talk exactly about
> 16 bit integers, one signed and one unsigned, no misunderstanding
> about this (to your other post).

There was never any talk about that by anyone but you.

On 05.3.2016 г. 10:32, Philip Lantz wrote:
> Dimiter_Popoff wrote:
>
>> I got into the thread when there was a talk exactly about
>> 16 bit integers, one signed and one unsigned, no misunderstanding
>> about this (to your other post).
>
> There was never any talk about that by anyone but you.
>
>

Wrong - again.

Here is how I joined the discussion:

https://groups.google.com/forum/#!original/comp.arch.embedded/9gpJx4pOFTM/JB5maJsaEQAJ

I guess we have to welcome yet another always know better genius
to the group, just the one or two were too few to have enough
fun I suppose. Then those we already had were not always wrong.

Dimiter

Am 04.03.2016 um 16:28 schrieb Wouter van Ooijen:
> Op 04-Mar-16 om 12:35 PM schreef David Brown:

>> That's interesting.  Personally, I hate the fact that people often use
>> all caps for constants (whether it be #define, const, or enum values).
>> I can accept all-caps for "dangerous" macros, but using them for simple
>> constants is just ugly and unnecessary IMHO.

> That is exactly my rule: ALL_CAPS_FOR_AN_IDENTIFIER is an alarm flag
> that indicates something special. If it behaves just like a normal
> object it should look like one, even_if_it_is_implemented_as_a_macro.

The thing is: it really doesn't behave like a normal object.  C has four 
or five types of "constants", depending on how far you're willing to 
stretch the concept.

1) literal numbers in the source
2) preprocessor macros expanding to literal numbers
3) enum values
4) object flagged "const"
5) addresses of statically located objects (including functions)

Of these, three really do not behave like normal objects.  For starters, 
you can't take their address, nor query their size.  And not 
coincidentally, you can use only those three in every place C requires a 
constant, most prominently to dimension a statically allocated array.

And only types 2 and 3 are usually recommended to be spelled in ALL_CAPS.

> Whether something is a constant is a limitation on the use of that
> thing: it can't be changed by *that part of the code*.

That's not true for the majority of types of constants; it only is for 
type 4 above, and then only if you're writing C.  And nobody I know 
writes type 4 constant in ALL_CAPS --- nor have I ever seen anyone 
advocate doing so.

C++ changed this, partly in an effort to reduce the use of the 
preprocessor for things that C++ has supposedly better means for.  So in 
C++ statically allocated, "const" flagged numericals are full constants, 
not just variables that code is forbidden to manipulate.  This 
combination of features is new, so it's a new stylistic decision whether 
to spell them like C constants, or like C const variables.

Am 04.03.2016 um 16:28 schrieb Wouter van Ooijen:
> Op 04-Mar-16 om 12:35 PM schreef David Brown:

>> That's interesting.  Personally, I hate the fact that people often use
>> all caps for constants (whether it be #define, const, or enum values).
>> I can accept all-caps for "dangerous" macros, but using them for simple
>> constants is just ugly and unnecessary IMHO.

> That is exactly my rule: ALL_CAPS_FOR_AN_IDENTIFIER is an alarm flag
> that indicates something special. If it behaves just like a normal
> object it should look like one, even_if_it_is_implemented_as_a_macro.

The thing is: it really doesn't behave like a normal object.  C has four 
or five types of "constants", depending on how far you're willing to 
stretch the concept.

1) literal numbers in the source
2) preprocessor macros expanding to literal numbers
3) enum values
4) object flagged "const"
5) addresses of statically located objects (including functions)

Of these, three really do not behave like normal objects.  For starters, 
you can't take their address, nor query their size.  And not 
coincidentally, you can use only those three in every place C requires a 
constant, most prominently to dimension a statically allocated array.

And only types 2 and 3 are usually recommended to be spelled in ALL_CAPS.

> Whether something is a constant is a limitation on the use of that
> thing: it can't be changed by *that part of the code*.

That's not true for the majority of types of constants; it only is for 
type 4 above, and then only if you're writing C.  And nobody I know 
writes type 4 constant in ALL_CAPS --- nor have I ever seen anyone 
advocate doing so.

C++ changed this, partly in an effort to reduce the use of the 
preprocessor for things that C++ has supposedly better means for.  So in 
C++ statically allocated, "const" flagged numericals are full constants, 
not just variables that code is forbidden to manipulate.  This 
combination of features is new, so it's a new stylistic decision whether 
to spell them like C constants, or like C const variables.

On 05/03/16 16:01, Hans-Bernhard Bröker wrote:
> Am 04.03.2016 um 16:28 schrieb Wouter van Ooijen:
>> Op 04-Mar-16 om 12:35 PM schreef David Brown:
>
>>> That's interesting.  Personally, I hate the fact that people often use
>>> all caps for constants (whether it be #define, const, or enum values).
>>> I can accept all-caps for "dangerous" macros, but using them for simple
>>> constants is just ugly and unnecessary IMHO.
>
>> That is exactly my rule: ALL_CAPS_FOR_AN_IDENTIFIER is an alarm flag
>> that indicates something special. If it behaves just like a normal
>> object it should look like one, even_if_it_is_implemented_as_a_macro.
>
> The thing is: it really doesn't behave like a normal object.  C has four
> or five types of "constants", depending on how far you're willing to
> stretch the concept.
>
> 1) literal numbers in the source
> 2) preprocessor macros expanding to literal numbers
> 3) enum values
> 4) object flagged "const"
> 5) addresses of statically located objects (including functions)
>
> Of these, three really do not behave like normal objects.  For starters,
> you can't take their address, nor query their size.  And not
> coincidentally, you can use only those three in every place C requires a
> constant, most prominently to dimension a statically allocated array.
>
> And only types 2 and 3 are usually recommended to be spelled in ALL_CAPS.

I know many people use all caps for preprocessor macros, and some (far 
fewer) do so for enum values.  But what is the point?  /Why/ use all 
caps for these?

To me, "all caps" is shouting - it is a warning that there is something 
odd going on here.  That makes sense if you have, for example, a macro 
that is defined on the command line rather than in the source code.  Or 
if you have a macro that /looks/ like a function, but does not behave 
properly - perhaps it evaluates its arguments twice, so you need to be 
careful in using it.

But what is special about a literal value macro?  If you write

	#define noOfWotsits 23

why should you worry about using noOfWotsits in code?  It has no need of 
a warning.  It is true that you can't take its address, or assign a new 
value to it - but that would not make logical sense in the program, and 
the compiler will tell you that it can't be done.  You don't need to 
shout at the reader or programmer to let them know.  All you do is make 
it harder to read the rest of the program, and make /really/ dangerous 
macros harder to spot in the noise.

>
>> Whether something is a constant is a limitation on the use of that
>> thing: it can't be changed by *that part of the code*.

Exactly correct.  For some types of "constants", you can't change them 
in /any/ part of the code - but the relevant point in the code you are 
working on here and now, is that they cannot change here and now.

>
> That's not true for the majority of types of constants; it only is for
> type 4 above, and then only if you're writing C.  And nobody I know
> writes type 4 constant in ALL_CAPS --- nor have I ever seen anyone
> advocate doing so.
>
> C++ changed this, partly in an effort to reduce the use of the
> preprocessor for things that C++ has supposedly better means for.  So in
> C++ statically allocated, "const" flagged numericals are full constants,
> not just variables that code is forbidden to manipulate.  This
> combination of features is new, so it's a new stylistic decision whether
> to spell them like C constants, or like C const variables.

Note that in both C and C++, if an object is /defined/ as const, then 
code cannot change them - they are not variables.  The compiler can 
assume they will never change, and optimise accordingly - just like any 
of the other types of constants mentioned above.  (This is distinct from 
casting something to const, or using a pointer-to-const, where you are 
just promising not to change them through the const version.)

The only difference between C++ and C here is that in C++, objects of 
literal types (including POD types) that are defined as const are 
considered constant expressions and can be used in things like array 
sizes, switch expressions, and templates.

On 05/03/16 09:55, Dimiter_Popoff wrote:
> On 05.3.2016 г. 10:32, Philip Lantz wrote:
>> Dimiter_Popoff wrote:
>>
>>> I got into the thread when there was a talk exactly about
>>> 16 bit integers, one signed and one unsigned, no misunderstanding
>>> about this (to your other post).
>>
>> There was never any talk about that by anyone but you.
>>
>>
>
> Wrong - again.
>
> Here is how I joined the discussion:
>
> https://groups.google.com/forum/#!original/comp.arch.embedded/9gpJx4pOFTM/JB5maJsaEQAJ
>
>
> I guess we have to welcome yet another always know better genius
> to the group, just the one or two were too few to have enough
> fun I suppose. Then those we already had were not always wrong.
>
> Dimiter
>

Perhaps, Dimiter and Philip, we can be done with the insults and 
blame-game for now?  There was a mixup with posters talking at 
cross-purposes.  It happens, and now it's finished.  Snide remarks, 
accusations and blames are not going to help anyone - they won't help 
the OP, they won't help us figure out the OP's problem, they won't teach 
anyone anything new, and they are not interesting or enjoyable in the 
thread.

So please, lets just end it there.

If there are more technical points, such as questions about how C works, 
that's fine.  And if and when there the OP manages to post a snippet 
illustrating his problem, we will take up the technical discussion from 
there.