On 05.3.2016 г. 17:44, David Brown wrote:> 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. >David, I don't need you to moderate my posts, thank you very much. You'd be better advised to pay more attention reading what you reply to while in your not so infrequent "know better mode" instead of posting nonsense and then pretending to have made a typo. Dimiter
C++ problem
Started by ●March 1, 2016
Reply by ●March 5, 20162016-03-05
Reply by ●March 5, 20162016-03-05
On Fri, 4 Mar 2016 11:51:25 +0200, Dimiter_Popoff <dp@tgi-sci.com> wrote:>On 03.3.2016 ?. 14:09, George Neuner wrote: >> On Thu, 3 Mar 2016 11:39:16 +0200, Dimiter_Popoff <dp@tgi-sci.com> >> wrote: >> >>> ... 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. >> >> It's not just a question of whether it works ... it's also a question >> of _why_ it works. This behavior works de facto due to a quirk[*] of >> implementation, not because the C standard says it should work. >> >> [*] a ubiquitous quirk, but a quirk nonetheless. >> >> George >> > >Well I would expect it to work, why a quirk? (If I understand "quirk" >correctly here it means some weird circumstances leading to the >result?).Apologies for using slang - I forget sometimes the international aspect. "quirk" doesn't necessarily imply "weird" ... often it means only that the circumstances are not applicable elsewhere.>I would expect 32 bit signed multiply to work on any values fitting >within 16 bits in two 32 bit registers. Now say on the 68K one just >cannot do 16 signed * 16 unsigned -> 32 whatever, it is either > smul.w or umul.w, must be the same on other processors under >similar circumstances, may be it has to do with that?What I meant by "quirk" in this case is that the reason the example works is due to to overflow wrap-around. Although wrap-around is the norm on most [but not all] machines, you would get a different answer if the implementation, e.g., saturated rather than wrapping. With only a few exceptions the C standard does not specify any particular machine architecture: it does not recognize that arithmetic can overflow, and it does not specify how to handle that eventuality. Relying on wrap-around for a correct answer means the program is relying on implementation dependent behavior which is outside the scope of C. That's really all I meant to say. The example works, but it works due to circumstance rather than because it somehow must work in that way.>DimiterGeorge
Reply by ●March 5, 20162016-03-05
On 05.3.2016 г. 18:59, George Neuner wrote:> On Fri, 4 Mar 2016 11:51:25 +0200, Dimiter_Popoff <dp@tgi-sci.com> > wrote: > >> On 03.3.2016 ?. 14:09, George Neuner wrote: >>> On Thu, 3 Mar 2016 11:39:16 +0200, Dimiter_Popoff <dp@tgi-sci.com> >>> wrote: >>> >>>> ... 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. >>> >>> It's not just a question of whether it works ... it's also a question >>> of _why_ it works. This behavior works de facto due to a quirk[*] of >>> implementation, not because the C standard says it should work. >>> >>> [*] a ubiquitous quirk, but a quirk nonetheless. >>> >>> George >>> >> >> Well I would expect it to work, why a quirk? (If I understand "quirk" >> correctly here it means some weird circumstances leading to the >> result?). > > Apologies for using slang - I forget sometimes the international > aspect. > > "quirk" doesn't necessarily imply "weird" ... often it means only that > the circumstances are not applicable elsewhere.No need to apologize at all, I see such posts as an opportunity to improve my language. Then there is no point adapting to other people's ignorance, this is their problem (in this case mine). Dimiter
Reply by ●March 5, 20162016-03-05
"David Brown" <david.brown@hesbynett.no> wrote in message news:nbeu4v$t8s$1@dont-email.me...> 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.but there is something odd going on here there's a textual replacement being undertaken, not a function call. This may result in odd behaviour if the author hasn't defined their macro properly tim
Reply by ●March 6, 20162016-03-06
"David Brown" <david.brown@hesbynett.no> wrote in message news:nbeu4v$t8s$1@dont-email.me...> 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.but there is something odd going on here there's a textual replacement being undertaken, not a function call. This may result in odd behaviour if the author hasn't defined their macro properly tim
Reply by ●March 6, 20162016-03-06
Op 06-Mar-16 om 9:17 AM schreef tim...:> > "David Brown" <david.brown@hesbynett.no> wrote in message > news:nbeu4v$t8s$1@dont-email.me... >> 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. > > but there is something odd going on here > > there's a textual replacement being undertaken, not a function call. > This may result in odd behaviour if the author hasn't defined their > macro properlyIf something hasn't been designed properly all bets are off. The point is that a straightforward macro or constant doesn't need special attention from the reader. What does warrant special attention is something that doesn't behave as a constant or function call. SUCH a macro (if used at all!) deserves CAPITALS. Wouter "object? No thanks!" van Ooijen
Reply by ●March 6, 20162016-03-06
On 06/03/16 09:17, tim... wrote:> > "David Brown" <david.brown@hesbynett.no> wrote in message>> 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. > > but there is something odd going on here > > there's a textual replacement being undertaken, not a function call.That's not "odd", it is a common part of the language.> This may result in odd behaviour if the author hasn't defined their > macro properly >If the author has done something silly, like write #define noOfWotsits = 123; (probably everyone has done that at least once) then the compiler will complain. You don't need to use all-caps to warn the reader about things that the compiler will warn about anyway.
Reply by ●March 6, 20162016-03-06
"David Brown" <david.brown@hesbynett.no> wrote in message news:nbh270$gk9$1@dont-email.me...> On 06/03/16 09:17, tim... wrote: >> >> "David Brown" <david.brown@hesbynett.no> wrote in message > >>> 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. >> >> but there is something odd going on here >> >> there's a textual replacement being undertaken, not a function call. > > That's not "odd", it is a common part of the language. > >> This may result in odd behaviour if the author hasn't defined their >> macro properly >> > > If the author has done something silly, like write > > noOfWotsits = 123;I was more thinking of: #define noOfWotsitsB noOfWotsitsA + 1 and then doing: x = noOfWotsitsB * 2; tim
Reply by ●March 6, 20162016-03-06
On 06/03/16 12:01, tim... wrote:> > "David Brown" <david.brown@hesbynett.no> wrote in message > news:nbh270$gk9$1@dont-email.me... >> On 06/03/16 09:17, tim... wrote: >>> >>> "David Brown" <david.brown@hesbynett.no> wrote in message >> >>>> 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. >>> >>> but there is something odd going on here >>> >>> there's a textual replacement being undertaken, not a function call. >> >> That's not "odd", it is a common part of the language. >> >>> This may result in odd behaviour if the author hasn't defined their >>> macro properly >>> >> >> If the author has done something silly, like write >> >> noOfWotsits = 123; > > I was more thinking of: > > #define noOfWotsitsB noOfWotsitsA + 1 > > and then doing: > > x = noOfWotsitsB * 2; >That is a mistake in the definition of noOfWotsitsB, not a mistake in its use. You don't need to have all-caps to warn about using noOfWotsitsB - you need to understand how to define such macros properly: #define noOfWotsitsB (noOfWotsitsA + 1) Using all-caps puts the emphasis and warning about possible mistakes in the wrong place.
Reply by ●March 6, 20162016-03-06
> Using all-caps puts the emphasis and warning about possible mistakes in > the wrong place.I don't use all-caps to warn me about possible mistakes (!?) in my code. I use all-caps to clearly show in the source that the thing is not what it seems to be (regular variable or function call) but something different (may be just a simple constant but may be as well A LOT of code behind). This is what I want to know when seeing all-caps, this is what I intend when using all-caps.
