473,842 Members | 1,837 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

"Mastering C Pointers"....

Hey guys, I'm new here, just a simple question.

I'm learning to Program in C, and I was recommended a book called,
"Mastering C Pointers", just asking if any of you have read it,
and if it's worth the $25USD.

I'm just looking for a book on Pointers, because from what I've
read it's one of the toughest topics to understand.

thanks in advanced.

sincerely ... Andy
Nov 13 '05
388 21968
Richard Heathfield <do******@addre ss.co.uk.invali d> scribbled the following:
Alan Connor wrote:
On Thu, 06 Nov 2003 05:34:07 GMT, nobody <no****@nowhere .non> wrote:
Why do you talk to an obviously knowledgable man as if he was a member of
an inferior species who had never seen a computer before?
It is far from obvious that Roose is knowledgeable, at least in areas of
knowledge that this newsgroup recognises as relevant.


That's a mighty big "at least", Richard. For all we know, Roose could be
the world's leading authority on car engine maintenance or something.
What he clearly is *not* knowledgeable about is C. He knows some C, but
not nearly enough to make the claims that he's making even as we speak.
OTOH, having or not having seen a computer isn't that relevant. It could
be argued that one could become an expert on ISO standard C really
without ever seeing a computer. *Only* in ISO standard C, though, mind
you - not any platform-specific extensions. Understandably, because
there would *be* no platform to speak of. But ISO standard C is all
this newsgroup cares about, and all it should care about.

--
/-- Joona Palaste (pa*****@cc.hel sinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"O pointy birds, O pointy-pointy. Anoint my head, anointy-nointy."
- Dr. Michael Hfuhruhurr
Nov 13 '05 #321

On Thu, 6 Nov 2003, Richard Heathfield wrote:

goose wrote:
Joona I Palaste <pa*****@cc.hel sinki.fi> wrote...
Richard Heathfield scribbled:
> goose wrote:
>> Mark McIntyre wrote:
>>>
>>> And are functions objects?
>>
>> iirc, yes.

> YRI.

TIWITAW.


<all confused>


FWIW, IUWJM


Apparently, it was "That is what I thought as well."
But when I looked at it, I figured

RH: "You recall incorrectly."

JP: "Then I will [something] take a walk."

:-)
-Arthur
Nov 13 '05 #322
Arthur J. O'Dwyer <aj*@nospam.and rew.cmu.edu> scribbled the following:
On Thu, 6 Nov 2003, Richard Heathfield wrote:
goose wrote:
> Joona I Palaste <pa*****@cc.hel sinki.fi> wrote...
>> Richard Heathfield scribbled:
>> > goose wrote:
>> >> Mark McIntyre wrote:
>> >>>
>> >>> And are functions objects?
>> >>
>> >> iirc, yes.
>>
>> > YRI.
>>
>> TIWITAW.
>
> <all confused>
FWIW, IUWJM

Apparently, it was "That is what I thought as well."
But when I looked at it, I figured RH: "You recall incorrectly." JP: "Then I will [something] take a walk." :-)


Whoa! That's certainly possible (although in this case untrue), but it
just so nonsensical I can hardly stop laughing at it. goose recalling
incorrectly causes me to take a walk? Because of what? It's true that
taking a walk can refresh one's memory, but to refresh someone else's
memory...

--
/-- Joona Palaste (pa*****@cc.hel sinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"This is a personnel commuter."
- Train driver in Scientific American
Nov 13 '05 #323
maniac wrote:
Hey guys, I'm new here, just a simple question.

I'm learning to Program in C, and I was recommended a book called,
"Mastering C Pointers", just asking if any of you have read it,
and if it's worth the $25USD.

I'm just looking for a book on Pointers, because from what I've
read it's one of the toughest topics to understand.

thanks in advanced.

sincerely ... Andy

man this thing's still around, holy crap.
oh, well good I guess.
Nov 13 '05 #324
On 05 Nov 2003 15:44:56 -0800, in comp.lang.c , Ben Pfaff
<bl*@cs.stanfor d.edu> wrote:
Mark McIntyre <ma**********@s pamcop.net> writes:
Mornington Crescent.


I have no idea what that means. Is it a breakfast food?


I'm sorry, I haven't a clue.
:-)

(well, ok then, 5th paragraph on this page....
http://news.bbc.co.uk/1/hi/uk/79273.stm
although a 30+ year steeping in British Comedy and a labyrinthine
knowledge of the london underground map is typically required to stand
a chance of winning, never mind understand Graeme's rules at the end
of the article)
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.c om/ms3/bchambless0/welcome_to_clc. html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Nov 13 '05 #325
On 05 Nov 2003 15:44:56 -0800, in comp.lang.c , Ben Pfaff
<bl*@cs.stanfor d.edu> wrote:
Mark McIntyre <ma**********@s pamcop.net> writes:
As far as I'm concerned, a pointer is an object that points to
something else, either another object, or a function, or nothing.


See my post elsethread for why that's a bad definition.


I must have either completely missed that post, or misunderstood it.
Could you paraphrase?
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.c om/ms3/bchambless0/welcome_to_clc. html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Nov 13 '05 #326
On Thu, 6 Nov 2003 06:49:58 +0000 (UTC), in comp.lang.c , Richard
Heathfield <do******@addre ss.co.uk.invali d> wrote:
"Mornington Crescent" is a joke on "I'm Sorry I Haven't A Clue", a Radio 4
'comedy' quiz program. The contestants (always the same four, I think, so
really they're members of the cast - Tim Brooke-Taylor and Graeme Garden of
"The Goodies",
Its highly likely you'll now have to explain "The Goodies". Good
luck...
one of Barry {Humphries|Crye r},
Cryer
and some other bloke)
Willie Rushton (decd)
there are in fact no rules whatsoever.
Balderdash, you heretic !! Graeme provided the following rules for the
terminally confused ie those stuck at Aldwych, Barking or Edgware Road
(District Line).

-Boxing out the F, J, O and W placings draws the partner into an
elliptical progression north to south
-In weak positional play, it is vital to consolidate an already strong
outer square, eg Pentonville Road
-In a straight rules game, it's inadmissible to transfer inversely,
which is otherwise a powerful tactic
-Opening the triangle will block any of the three possible reverse
draws and is usually played early in the game (before the Central Line
has been quartered) so that the risk of a diagonal move is negligible,
as is the possibility of quartering
-The lateral shift decisively breaks opponents' horizontal and
vertical approaches.
-The A40 northbound used as a counter-play offers rear access to
suburban bidding
I understand I may have broken some kind of cabalistic law by revealing this
fact, so if I don't post any more after today, you'll know why.


Be afraid, be very afraid.....
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.c om/ms3/bchambless0/welcome_to_clc. html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Nov 13 '05 #327
On Thu, 6 Nov 2003 06:51:41 +0000 (UTC), in comp.lang.c , Richard
Heathfield <do******@addre ss.co.uk.invali d> wrote:
Mark McIntyre wrote:
Well..... NULL is a macro, which is converted by the preprocessor to a
constant inserted literally into the processed code, whose value is
selected to be the one the implementation uses to mean "I point
nowhere". So its not actually a pointer at this point. If you see my
point.


The Standard says: "Such a pointer, called a null pointer, is guaranteed to
compare unequal to a pointer to any object or function."


Well, no actually.

It says
"An integer constant expression with the value 0, or such an
expression cast to type void *, is called a null pointer constant. If
a null pointer constant is converted to a pointer type, the resulting
pointer, called a null pointer, is guaranteed to compare unequal to a
pointer to any object or function." (6.3.2.3-1)

You will note the phrase "if .... converted to a pointer type". I
believe we agree that NULL is a macro with value either zero or
(void*)0. It is therefore a null pointer constant. And I read the
above as saying that its not a pointer until its converted to a
pointer type. My case rests. For now...
But thats fine - its not a pointer either... :-)


The Standard disagrees with you.


I disagree that it disagrees. In order to compare p to NULL, you must
convert p to a pointer type (see quote above, plus 6.3.2.3-4). I'm
doubtful that you could convert a null pointer constant to a pointer
type without storing it somewhere....

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.c om/ms3/bchambless0/welcome_to_clc. html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Nov 13 '05 #328
On Thu, 6 Nov 2003 07:59:34 +0000 (UTC), in comp.lang.c , Richard
Heathfield <do******@addre ss.co.uk.invali d> wrote:
goose wrote:
Joona I Palaste <pa*****@cc.hel sinki.fi> wrote in message
news:<bo******* ***@oravannahka .helsinki.fi>.. .

TIWITAW.


<all confused>


FWIW, IUWJM


BUAATOO, IR.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.c om/ms3/bchambless0/welcome_to_clc. html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Nov 13 '05 #329
>"Chris Torek" <no****@elf.eng .bsdi.com> wrote in message
news:bo******* ***@elf.eng.bsd i.com... [much snippage]
len = c1 * 256 + c2; /* if big-endian */
len = c2 * 256 + c1; /* if little-endian */


In article <tA************ *******@twister 01.bloor.is.net .cable.rogers.c om>,
nobody <no****@nowhere .non> wrote:Wouldn't left shift be better? Or are today's compilers "smart" enough
to do this kind of stuff themselves? /*Someone had mentioned this
possibility earlier (particular case was multiplication by 2).*/


Assuming there is no overflow -- and if "len" is at least
unsigned int, and c1 and c2 are in the range [0..255], then
we can make sure that there is none by replacing "256" with
"256U" in each case -- then writing either of:

len = (c1 << 8) + c2;
or len = c1 * 256 + c2;

makes no difference, as a left-shift is equivalent to a multiply.
Of course these should be expressed as:

len = ((unsigned int)c1 << 8) + c2;
and len = c1 * 256U + c2;

respectively.

As for whether one form or the other is "better", it depends on
what you intend to convey to a (human) reader. Any compiler worth
what you paid for it will optimize "c1 * 256U" (or even c1*256,
without the U) into a left shift, and -- in the absence of overflow
-- left shifts are defined in terms of multiplication. (In the
presence of overflow, neither is strictly defined by the C standards,
and a compiler can use the shift anyway on any typical modern CPU.)
Thus, whether you write "what you mean" or "how to do it" is in a
sense irrelevant, as they are isomorphic.

Even the division-by-shifting optimization is easy for compilers
to implement, although here it is more likely to occur for unsigned
operands, because a compiler must typically include some "compensati on"
code for signed divison. This is because:

y = x >> 2;
vs y = x / 4;

is typically not the same when x is negative. For instance, (-1)
/ 4 is usually 0 (and I think is *required* to be 0 in C99), while
(-1) >> 2 is usually -1, on today's machines. Note, however, that
while left shift is *defined* in terms of multiplication -- in both
C89 and C99 -- right shift is not defined in terms of division
except for non-negative "x". Thus, in this case, you really *must*
write "what you mean" instead of "how to do it", as the two are
not necessarily synonymous.

<begin OT>
For the curious, the "compensati on" code for a negative dividend
(and positive divisor) -- remember in x / y, x is the dividend and
y is the divisor -- works out to the following, all assuming 2s
complement and an arithmetic right-shift:

/* divide signed input "x" by divisor, whose log2 is d2 */
int divide_by_power _of_two(int x, int divisor, int d2) {
int adj;

/* required: (1 << d2) == divisor */
adj = (x & SIGNBIT) ? divisor - 1 : 0;
return (ux + adj) >> d2;
}

The idea here is that, e.g., when dividing by 4 (d2 == 2), we want
-1 to give 0, -2 to give 0, -3 to give 0, but -4 to give -1; -5
through -7 should also be -1, while -8 should be -2; and so on.
If x is nonnegative, x >> d2 gives the right answer, but if x is
negative, it gives the wrong answer unless x is an even multiple
of the divisor, otherwise it gives a value one too small (-1 instead
of 0, -2 instead of -1, and so on). Adding (positive) 3 gives the
right answer for -1 through -3 and leaves -4 at -1, which shifts
to -1; and so on. An equivalent trick is to add 1 to the result
if any "1" bits are shifted out during the right-shift operation,
but this is harder to test on typical machines -- the FPU has
hardware to collect such bits (in the "sticky bit" part of IEEE FP
processing), but the integer unit lacks it. The calculation of
the (x&SIGNBIT) adjustment value can, however, be done branchlessly
by shifting x the appropriate number of bits right, e.g., 31 for
32-bit x, to produce an all-ones mask for negative values and
all-zeros for nonnegative, then ANDing this mask with (divisor-1).
On a typical RISC we get something like:

mov x, reg # assuming x is already in a register
asr reg, 31, reg # where asr is arithmetic shift right
and reg, 3, reg # for divisor == 4
add reg, x, reg
asr reg, 2, reg # again for divisor == 4
# final result is now in "reg"

The constants (31, 3, and 2 here) are "number of bits in x that
are not the sign bit", "divisor - 1", and "log2 divisor". For
small divisors these usually fit in the instruction format -- most
RISCs have constant fields that go to at least 255, if not higher;
4095 is not unusual. All of this is only a win if the divide takes
more cycles than the four instructions above. Assuming a single
barrel or funnel shifter and two ALUs, the four instructions take
two cycles, while a typical integer divide is at least four cycles
and as long as 31 or 100 or so cycles, depending on the CPU, so
this is indeed a win, and the compiler should use it.

Of course, if the CPU has a single-cycle divide, or if the dividE
is "parallelizable " and there is other work to do before referring
to the result-value register, it is better just to do "idiv x, 4,
reg". On the (old-only?) MIPS, where you move the values into the
mul/div unit, it is something of a toss-up -- the divide runs in
parallel to any remaining work, but the extra moves consume extra
cycles.
<end OT>
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (4039.22'N, 11150.29'W) +1 801 277 2603
email: forget about it http://67.40.109.61/torek/index.html (for the moment)
Reading email is like searching for food in the garbage, thanks to spammers.
Nov 13 '05 #330

This thread has been closed and replies have been disabled. Please start a new discussion.

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.