Post by thread:[OT] another q from the stupid newbie

> Perhaps you are approaching it with the wrong mindset. > I like C because I can still think with the same braincells I use with > assembler. > Unlike Pascal and Modula-2, where I approach a problem differently. > Stop thinking of C as a high level language and treat it as assembler with > curly braces. > If you understand indirect addressing, jump tables and all those other > assembler things, you can mentally translate the C statements into what is > actually happening. I guess that could be some of the problem, I must admit I do tend to think of C as a high level language, and not in terms of assembler. > For example. All the books make out that beginners can't understand > pointers but if you > think of > char *TEXT > as > TEXT: DB 'My string', 0 > > then TEXT has some meaning. You know that TEXT is the address of the 'M' > and that if you increment it, it will be the address of (point to) the 'y'. This is an interesting thing in my case. I *think* I understand the idea of pointers better than the implementation in C. I tend to liken a pointer to a form of indexed addressing, although I believe pointers vary in word size according to their type, and not forgetting other odd things in C, like being able to cast things. I guess there's also the difference that with pointers, byte boundary differences are taken care of as well (as I understand it). What can get confusing is the syntax of pointers in C, like pointers to pointers and pointers into structures. It can also get confusing where you have complicated assignments with no parenthesis, and then end up having to work through it all based of the precedence of the operators, although perhaps you could also call that bad coding (obvious is better right ?). I guess I have to admit that I do know how to use a reasonable amount of C's syntax, but just don't have a lot of familiarity with the common functions and using them. Trying to understand other peoples code is where I often have difficulty, but perhaps I'm trying to run before I can walk ? Anyway, that's enough rambling for the moment :-) Thanks for the reply. Cheers, Ian.

Ian Cameron <spam_OUTPICLISTTakeThisOuTMITVMA.MIT.EDU> wrote: > I tend to liken a pointer to a form of indexed addressing, although > I believe pointers vary in word size according to their type Ian: Yeah; if you increment a pointer, it doesn't necessarily increment by 1... Instead, it increments by the size of the type of object to which it points. > What can get confusing is the syntax of pointers in C, like pointers > to pointers and pointers into structures. It can also get confusing > where you have complicated assignments with no parenthesis, and then > end up having to work through it all based of the precedence of the > operators, although perhaps you could also call that bad coding > (obvious is better right ?). Right. > I guess I have to admit that I do know how to use a reasonable > amount of C's syntax, but just don't have a lot of familiarity with > the common functions and using them. Trying to understand other > peoples code is where I often have difficulty, but perhaps I'm > trying to run before I can walk ? Perhaps. I think you'll find that, as you see more and more C code, you'll become increasingly familiar with the common idioms. For instance, the following line is likely to be inscrutable to novice C programmers, but they soon start to recognize it as a string copy whenever they see it: while (*dest++ = *source++); Of course, there are plenty of bad C programmers out there, so your difficulty understanding their code may not be your fault at all. -Andy === Andrew Warren - .....fastfwdKILLspam@spam@ix.netcom.com === Fast Forward Engineering - Vista, California === http://www.geocities.com/SiliconValley/2499

On Thu, 9 Oct 1997 13:58:07 -0800, Andrew Warren <fastfwdKILLspamIX.NETCOM.COM> wrote: >Ian Cameron <.....PICLISTKILLspam.....MITVMA.MIT.EDU> wrote: > <SNIP> > > For instance, the following line is likely to be inscrutable to > novice C programmers, but they soon start to recognize it as a > string copy whenever they see it: > > while (*dest++ = *source++); > <SNIP> > Just wanted to comment, this is about as hairy as it usually gets, because you have two of the least understood (by novices) C concepts here, pointers and postfix operators. For you non-C programmers out there, a rough English translation is: Copy the thing pointed to by the source pointer to the location pointed to by the dest pointer, and increment the source and dest pointers AFTER the thing has been copied, ready for the next thing. Pointers are not that tough really, once you get used to them, unless you have to mentally handle lots ot dereferencing in your head (dereferencing is figuring out exactly what a series of pointers and addresses is actually pointing to). Something like this can be a headache, even for an expert C developer: x = *(thing *)( &myarry[ 5 ] ) CIAO - Martin R. Green EraseMEelimarspam_OUTTakeThisOuTbigfoot.com

Martin R. Green <PICLISTspam_OUTMITVMA.MIT.EDU> wrote: > > For instance, the following line is likely to be inscrutable to > > novice C programmers, but they soon start to recognize it as a > > string copy whenever they see it: > > > > while (*dest++ = *source++); > > Just wanted to comment, this is about as hairy as it usually gets, > because you have two of the least understood (by novices) C concepts > here, pointers and postfix operators. For you non-C programmers out > there, a rough English translation is: > > Copy the thing pointed to by the source pointer to the location > pointed to by the dest pointer, and increment the source and dest > pointers AFTER the thing has been copied, ready for the next thing. Good explanation, Martin, but you left out one important thing: After every copy from source to destination, the "while" examines the value that was copied. If the value isn't equal to 0, the next thing is copied; if it IS equal to 0 (as it will be after the last value in the zero-terminated string is copied), the loop terminates and execution continues to the next instruction. -Andy === Andrew Warren - @spam@fastfwdKILLspamix.netcom.com === Fast Forward Engineering - Vista, California === http://www.geocities.com/SiliconValley/2499

On Thu, Oct 09, 1997 at 03:48:51PM -0800, Andrew Warren wrote: > Martin R. Green <KILLspamPICLISTKILLspamMITVMA.MIT.EDU> wrote: > > > > > > while (*dest++ = *source++); > > > > Copy the thing pointed to by the source pointer to the location > > pointed to by the dest pointer, and increment the source and dest > > pointers AFTER the thing has been copied, ready for the next thing. > > After every copy from source to destination, the "while" examines > the value that was copied. If the value isn't equal to 0, the Just to expand further, this is really equivalent to while((*dest++ = *source++) != 0) continue; And it's actually not a bad idea to write it like that. It should generate exactly the same code as the original (if it doesn't, get a new compiler) and it makes it clear what you're doing. In Java, using the explicit != test is mandatory - Java does not allow arbitrary expressions to be used as boolean values, to avoid errors like: if(fred = 1) which is legal C, but almost certainly was meant to be if(fred == 1) Then there's the hoary old trap that I still fall into occasionally: if(fred & 0x60 == 0x20) which should have been if((fred & 0x60) == 0x20) becuz & has a lower precedence than ==. -- Clyde Smith-Stubbs | HI-TECH Software Email: RemoveMEclydeTakeThisOuThtsoft.com | Phone Fax WWW: http://www.htsoft.com/ | USA: (408) 490 2885 (408) 490 2885 PGP: finger spamBeGoneclydespamBeGonehtsoft.com | AUS: +61 7 3354 2411 +61 7 3354 2422 --------------------------------------------------------------------------- ANSI C for the PIC! Now shipping! See http://www.htsoft.com for more info.

Clyde Smith-Stubbs <TakeThisOuTPICLISTEraseMEspam_OUTMITVMA.MIT.EDU> wrote: > if(fred = 1) > > .... is legal C, but almost certainly was meant to be > > if(fred == 1) Clyde: I'm sure you already know this, but others might not: If your compiler doesn't have an option to generate warnings when it sees simple assignments within "if" expressions (or an option to disable such assignments), you can prevent the bug by reordering the expression thusly: if (1 == fred) If you write your expressions this way, they'll still work fine, but if you make a mistake and accidentally write: if (1 = fred) the compiler will generate an error, since you can't assign anything to a constant. This doesn't work for "if" expressions that contain two variables rather than a variable and a constant, but it's a start. Reordering the operands is also useful in "for" and "while" expressions, and around "&&" and "||" operations. > Then there's the hoary old trap that I still fall into occasionally: > > if(fred & 0x60 == 0x20) > > which should have been > > if((fred & 0x60) == 0x20) > > becuz & has a lower precedence than ==. Kim Otten (nee Cooper) and I have THIS favorite precedence bug: *ip++ which, of course, should be: (*ip)++ since unary operators associate right-to-left. -Andy === Andrew Warren - RemoveMEfastfwdTakeThisOuTix.netcom.com === Fast Forward Engineering - Vista, California === http://www.geocities.com/SiliconValley/2499

Andy, > I'm sure you already know this, but others might not: If your > compiler doesn't have an option to generate warnings when it > sees simple assignments within "if" expressions (or an option to It does that by default. I didn't want to mention that lest I be seen as opportunistic, self-serving and crass. But it's probably too late anyway... > disable such assignments), you can prevent the bug by reordering > the expression thusly: > > if (1 == fred) Indeed, I have come across this. I personally have never adopted this style, not because I can find any particular fault with it, but it just looks unnatural to me. I'm just used to having the variable on the left. Clyde -- Clyde Smith-Stubbs | HI-TECH Software Email: clydeEraseME.....htsoft.com | Phone Fax WWW: http://www.htsoft.com/ | USA: (408) 490 2885 (408) 490 2885 PGP: finger EraseMEclydehtsoft.com | AUS: +61 7 3354 2411 +61 7 3354 2422 --------------------------------------------------------------------------- ANSI C for the PIC! Now shipping! See http://www.htsoft.com for more info.

-----Original Message----- From: Andrew Warren <RemoveMEfastfwdEraseMEEraseMEIX.NETCOM.COM> To: RemoveMEPICLISTspam_OUTKILLspamMITVMA.MIT.EDU <RemoveMEPICLISTTakeThisOuTspamMITVMA.MIT.EDU> Date: Friday, 10 October 1997 8:21 Subject: Re: [OT] another q from the stupid newbie > Good explanation, Martin, but you left out one important thing: > After every copy from source to destination, the "while" examines > the value that was copied. If the value isn't equal to 0, the > next thing is copied; if it IS equal to 0 (as it will be after > the last value in the zero-terminated string is copied), the loop > terminates and execution continues to the next instruction. And if it's not zero-terminated, god help you. It'll copy till it finds one, writing merrily away into who knows where. One reason I prefer a string class. (one of many!) MikeS <EraseMEmikesmith_ozspamspamBeGonerelaymail.net>

You got me. I was so busy describing the dereferencing and postfix incrementing _inside_ the parenthesis, I forgot the whole thing was in a while loop. Thanks for your amplification. Martin R. Green RemoveMEelimarKILLspambigfoot.com On Thu, 9 Oct 1997 15:48:51 -0800, Andrew Warren <fastfwdSTOPspamspam_OUTIX.NETCOM.COM> wrote: {Quote hidden}>Martin R. Green <spamBeGonePICLISTSTOPspamEraseMEMITVMA.MIT.EDU> wrote: > >> > For instance, the following line is likely to be inscrutable to >> > novice C programmers, but they soon start to recognize it as a >> > string copy whenever they see it: >> > >> > while (*dest++ = *source++); >> >> Just wanted to comment, this is about as hairy as it usually gets, >> because you have two of the least understood (by novices) C concepts >> here, pointers and postfix operators. For you non-C programmers out >> there, a rough English translation is: >> >> Copy the thing pointed to by the source pointer to the location >> pointed to by the dest pointer, and increment the source and dest >> pointers AFTER the thing has been copied, ready for the next thing. > > Good explanation, Martin, but you left out one important thing: > > After every copy from source to destination, the "while" examines > the value that was copied. If the value isn't equal to 0, the > next thing is copied; if it IS equal to 0 (as it will be after > the last value in the zero-terminated string is copied), the loop > terminates and execution continues to the next instruction. > > -Andy > >=== Andrew Warren - KILLspamfastfwdspamBeGoneix.netcom.com >=== Fast Forward Engineering - Vista, California >=== http://www.geocities.com/SiliconValley/2499

Actually, most modern compilers warn you if you do... while (*dest++ = *source++); ...with a message like "Possibly incorrect assignment", so I usually include the explicit comparison. I'm a big believer in readability, I hate going back to some of my own old code and not being able to figure out what I did, or why. Martin R. Green EraseMEelimarEraseMEbigfoot.com On Fri, 10 Oct 1997 09:33:26 +1000, Clyde Smith-Stubbs <@spam@clyde@spam@spam_OUTHTSOFT.COM> wrote: {Quote hidden}>On Thu, Oct 09, 1997 at 03:48:51PM -0800, Andrew Warren wrote: >> Martin R. Green <spamBeGonePICLISTKILLspamMITVMA.MIT.EDU> wrote: >> > > >> > > while (*dest++ = *source++); >> > >> > Copy the thing pointed to by the source pointer to the location >> > pointed to by the dest pointer, and increment the source and dest >> > pointers AFTER the thing has been copied, ready for the next thing. >> >> After every copy from source to destination, the "while" examines >> the value that was copied. If the value isn't equal to 0, the > >Just to expand further, this is really equivalent to > > while((*dest++ = *source++) != 0) > continue; > >And it's actually not a bad idea to write it like that. It should generate >exactly the same code as the original (if it doesn't, get a new compiler) >and it makes it clear what you're doing. In Java, using the explicit != >test is mandatory - Java does not allow arbitrary expressions to be used as >boolean values, to avoid errors like: > > if(fred = 1) > >which is legal C, but almost certainly was meant to be > > if(fred == 1) > >Then there's the hoary old trap that I still fall into occasionally: > > if(fred & 0x60 == 0x20) > >which should have been > > if((fred & 0x60) == 0x20) > >becuz & has a lower precedence than ==.

-----Original Message----- From: Clyde Smith-Stubbs <.....clydespam_OUTHTSOFT.COM> To: TakeThisOuTPICLIST.....TakeThisOuTMITVMA.MIT.EDU <TakeThisOuTPICLISTKILLspamspamMITVMA.MIT.EDU> Date: Friday, 10 October 1997 12:22 Subject: Re: [OT] another q from the stupid newbie >> if (1 == fred) > >Indeed, I have come across this. I personally have never adopted this style, >not because I can find any particular fault with it, but it just looks >unnatural to me. I'm just used to having the variable on the left. > Makes me squirm too Clyde. Wish it didn't - its a good idea. MikeS <.....mikesmith_ozRemoveMErelaymail.net>

Hi folks ... Martin R. Green wrote: {Quote hidden}> > On Thu, 9 Oct 1997 13:58:07 -0800, Andrew Warren > <RemoveMEfastfwdspamBeGoneIX.NETCOM.COM> wrote: > > >Ian Cameron <spamBeGonePICLIST@spam@spam_OUTMITVMA.MIT.EDU> wrote: > > > <SNIP> > > > > For instance, the following line is likely to be inscrutable to > > novice C programmers, but they soon start to recognize it as a > > string copy whenever they see it: > > > > while (*dest++ = *source++); > > > <SNIP> > > > > Just wanted to comment, this is about as hairy as it usually gets, > because you have two of the least understood (by novices) C concepts > here, pointers and postfix operators. For you non-C programmers out > there, a rough English translation is: > > Copy the thing pointed to by the source pointer to the location > pointed to by the dest pointer, and increment the source and dest > pointers AFTER the thing has been copied, ready for the next thing. ... You forget that each time you acomplish one copy, the thing gets tested and the while loop exits when it is FALSE (meaning zero). So it exits at the end of string '\0' (provided its an asciiz string). ... > > Pointers are not that tough really, once you get used to them, unless > you have to mentally handle lots ot dereferencing in your head > (dereferencing is figuring out exactly what a series of pointers and > addresses is actually pointing to). Something like this can be a > headache, even for an expert C developer: > > x = *(thing *)( &myarry[ 5 ] ) ... you can always had more two or three levels of indirection and type casting to make things interesting... ... > > CIAO - Martin R. Green > TakeThisOuTelimarspambigfoot.com ... I really think someone here is triyng to scare people away from 'C' programming (or simply showing of 1/2 KD ;-) ). 'C' is really a very good programming language that adds the simplicity of high-level languages with the ability to directly manipulate the hardware of ASM. But this kind of criptical examples tend to scare newcommers away. I'm, myself a newcommer to PICs and I wouldn't have liked this kind of welcome to a strange environment. Trying to figure out the logic behind the Microship ASM mnemonics (after almost 15 years of Intel microprocessors) is hard enought. best regards Jorge F

Hi Mike Smith wrote: {Quote hidden}> > -----Original Message----- > From: Andrew Warren <fastfwdEraseMEIX.NETCOM.COM> > To: RemoveMEPICLISTEraseMEspam_OUTMITVMA.MIT.EDU <@spam@PICLISTRemoveMEEraseMEMITVMA.MIT.EDU> > Date: Friday, 10 October 1997 8:21 > Subject: Re: [OT] another q from the stupid newbie > > > Good explanation, Martin, but you left out one important thing: > > > After every copy from source to destination, the "while" examines > > the value that was copied. If the value isn't equal to 0, the > > next thing is copied; if it IS equal to 0 (as it will be after > > the last value in the zero-terminated string is copied), the loop > > terminates and execution continues to the next instruction. > > And if it's not zero-terminated, god help you. It'll copy till it finds > one, writing merrily away into who knows where. > One reason I prefer a string class. (one of many!) > > MikeS > <EraseMEmikesmith_oz@spam@relaymail.net> OK Mike, now you are skiding from 'C' to 'C++'. best regards Jorge F

Jorge Ferreira wrote: > I really think someone here is triyng to scare people away from 'C' > programming (or simply showing of 1/2 KD ;-) ). > 'C' is really a very good programming language that adds the > simplicity of high-level languages with the ability to directly > manipulate the hardware of ASM. But this kind of criptical examples tend > to scare newcommers away. > > I'm, myself a newcommer to PICs and I wouldn't have liked this kind of > welcome to a strange environment. Trying to figure out the logic behind > the Microship ASM mnemonics (after almost 15 years of Intel > microprocessors) is hard enought. > > best regards > > Jorge F True - but I agree that learning assembly first is the best way. That way you'd know what the compiler is doing. Maybe you could explain something to me (since you seem to know your C's) A friend had trouble with the c-compiler we have at tech (I think MCHIP/Bytecraft?) >From the listing file it seems that the compiler keeps on clearing the RP0 bit! Not so nice when the next instruction sets the tris regs! Cheers! -- Eric van Es | Cape Town, South Africa @spam@vanesspam_OUT.....ilink.nis.za | http://www.nis.za/~vanes LOOKING FOR TEMPORARY / HOLIDAY ACCOMODATION? http://www.nis.za/~vanes/accom.htm