Searching \ for '[OT] another q from the stupid newbie' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: massmind.org/techref/index.htm?key=another+stupid+newbie
Search entire site for: 'another q from the stupid newbie'.

Exact match. Not showing close matches.
PICList Thread
'[OT] another q from the stupid newbie'
1997\10\09@094430 by Ian Cameron

picon face
> 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.

1997\10\09@170148 by Andrew Warren

face
flavicon
face
Ian Cameron <spam_OUTPICLISTTakeThisOuTspamMITVMA.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 - .....fastfwdKILLspamspam@spam@ix.netcom.com
=== Fast Forward Engineering - Vista, California
=== http://www.geocities.com/SiliconValley/2499

1997\10\09@172342 by Martin R. Green

picon face
On Thu, 9 Oct 1997 13:58:07 -0800, Andrew Warren
<fastfwdspamKILLspamIX.NETCOM.COM> wrote:

>Ian Cameron <.....PICLISTKILLspamspam.....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_OUTspamTakeThisOuTbigfoot.com

1997\10\09@185103 by Andrew Warren

face
flavicon
face
Martin R. Green <PICLISTspamspam_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@fastfwdKILLspamspamix.netcom.com
=== Fast Forward Engineering - Vista, California
=== http://www.geocities.com/SiliconValley/2499

1997\10\09@193916 by Clyde Smith-Stubbs
flavicon
face
On Thu, Oct 09, 1997 at 03:48:51PM -0800, Andrew Warren wrote:
> Martin R. Green <KILLspamPICLISTKILLspamspamMITVMA.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: RemoveMEclydeTakeThisOuTspamhtsoft.com          |          Phone            Fax
WWW:   http://www.htsoft.com/    | USA: (408) 490 2885  (408) 490 2885
PGP:   finger spamBeGoneclydespamBeGonespamhtsoft.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.

1997\10\09@215246 by Andrew Warren

face
flavicon
face
Clyde Smith-Stubbs <TakeThisOuTPICLISTEraseMEspamspam_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 - RemoveMEfastfwdspamTakeThisOuTix.netcom.com
=== Fast Forward Engineering - Vista, California
=== http://www.geocities.com/SiliconValley/2499

1997\10\09@224112 by Bob Lunn

flavicon
face
Bob Lunn
10/10/97 12:45 PM


>     if(fred = 1)
>
> .... is legal C, but almost certainly was meant to be
>
>     if(fred == 1)
    For another perspective on the joys of 'C' see:

         http://reality.sgi.com/csp/ioccc/

___Bob

1997\10\09@225142 by Clyde Smith-Stubbs

flavicon
face
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: clydeEraseMEspam.....htsoft.com          |          Phone            Fax
WWW:   http://www.htsoft.com/    | USA: (408) 490 2885  (408) 490 2885
PGP:   finger EraseMEclydespamhtsoft.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.

1997\10\10@070825 by Mike Smith

flavicon
face
-----Original Message-----
From: Andrew Warren <RemoveMEfastfwdEraseMEspamEraseMEIX.NETCOM.COM>
To: RemoveMEPICLISTspam_OUTspamKILLspamMITVMA.MIT.EDU <RemoveMEPICLISTTakeThisOuTspamspamMITVMA.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_ozspamspamspamBeGonerelaymail.net>

1997\10\10@095202 by Martin R. Green

picon face
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
RemoveMEelimarKILLspamspambigfoot.com

On Thu, 9 Oct 1997 15:48:51 -0800, Andrew Warren
<fastfwdSTOPspamspamspam_OUTIX.NETCOM.COM> wrote:

{Quote hidden}

1997\10\10@095608 by Martin R. Green

picon face
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
EraseMEelimarspamEraseMEbigfoot.com

On Fri, 10 Oct 1997 09:33:26 +1000, Clyde Smith-Stubbs
<@spam@clyde@spam@spamspam_OUTHTSOFT.COM> wrote:

{Quote hidden}

1997\10\11@110422 by Mike Smith

flavicon
face
-----Original Message-----
From: Clyde Smith-Stubbs <.....clydespam_OUTspamHTSOFT.COM>
To: TakeThisOuTPICLIST.....spamTakeThisOuTMITVMA.MIT.EDU <TakeThisOuTPICLISTKILLspamspamspamMITVMA.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_ozspamRemoveMErelaymail.net>

1997\10\12@104446 by jorgegf

flavicon
face
Hi folks


...
Martin R. Green wrote:
{Quote hidden}

...

       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
> TakeThisOuTelimarspamspambigfoot.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

1997\10\12@104448 by jorgegf

flavicon
face
Hi


Mike Smith wrote:
{Quote hidden}

       OK Mike, now you are skiding from 'C' to 'C++'.


       best regards

       Jorge F

1997\10\14@182053 by Eric van Es

flavicon
face
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_OUTspam.....ilink.nis.za | http://www.nis.za/~vanes
LOOKING FOR TEMPORARY / HOLIDAY ACCOMODATION?
http://www.nis.za/~vanes/accom.htm

More... (looser matching)
- Last day of these posts
- In 1997 , 1998 only
- Today
- New search...