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  21380 
> > Give me a break.
Sure. Take a break, any time you like.
Hilarious. Back to children's games, I see.
In comp.lang.c.moderated, I suspect that many of your articles would
simply not be approved by the moderator. Feel free to try to prove me wrong.
As would many of yours.
filled with irrelevant technical details,
You may consider the details irrelevant. I do not, however, pitch my
answers at your level of understanding, but at the questions actually asked by
real people. When the details matter, I give the details. When they don't, I
don't. Now, you may have considered my answer to be overly technical, but
it's a walk in the park compared to the answer I /could/ have given. I
included as much detail as I considered the OP could reasonably be
expected to take in (in one sitting), together with a little encouragement that it
really isn't as hard as he's been led to believe. I continue to maintain
that this was an appropriate response to his question.
I'm not talking about your pointer response, which was generally good, as I
already said. I'm talking about the newsgroup in general. Read some of the
responses to newbies. See how helpful they are.
Even the first one in this thread was quite unhelpful. The guy was like "I
heard it was about Turbo C and MS-DOS -- that means you shouldn't read
it." -- with no further explanation. Do you think a newbie knows what that
means, or knows what Turbo C is (or even DOS)? A much more helpful response
would be along the lines of, "This book appears to be rooted in a particular
platform, one that happens to be outdated, and thus may confuse you with a
lot of information that you don't need to know." which you would never hear in the real world.
Well, actually, I do discuss such (relevant) technical details in the real
world, as well as on Usenet. And anyway, what makes you think that Usenet
is not part of the real world?
Stop with the sniveling wordplay already. Then they
get turned off to C and think it's for wankers.
Speculation. I've found that people often respond well to being told the
underlying truth, rather than the helicopter-joystick method of
programming: "fiddle with the program, and watch what the computer does,
because if you want it to do that again, that is the code you have to
write" is not a very satisfactory way to learn programming.
I agree that that's a terrible way to learn. Without the concepts, you're
just blindly hacking. That's why I specifically said that you need at least
TWO perspectives. I encourage them to read your article. My claim is that
that's not sufficient. They should read a concrete explanation like mine.
Together they will help you understand pointers.
Plus my article encouraged them to learn the abstract while being rooted in
the concrete, not to focus on the concrete at the expense of the abstract.
This is exactly like the top-post thread. You're so goddamn close-minded
that you think the only way to do everything is your own. I, on the other
hand, recognize that sometimes things needs multiple perspectives, and there
are multiple valid ways of doing things. Sometimes there is no right and
wrong, just personal preference. I know it's a lot to handle, since you
like rigid rules so much. obscures the real question. Getting a job, or learning how
to write a real program that does what you want it to do.
That wasn't the real question. The real question was about pointers.
OK, so do you think that the OP wanted just to study pointers for the sake
of dinner party conversation, or eventually write a real program? Again,
READ BETWEEN THE LINES. Jesus Christ. It may technically, but not in colloquial usage.
Then colloquial usage is wrong, and should be changed.
Q.E.D. Another perfect example of why my underemployed flames were so
accurate. Everybody else is wrong; and you're right. Yes. You can insist
on using the term object however you want. However the rest of the world
will continue to use a more useful definition. I guess Stroustrop and
Ritchie and all the people who use the term OOP are wrong. Since, of
course, by default you should assume when someone says "object" in C++, they
mean something that takes storage, and not something with a constructor and
destructor and all that.
Let me suggest that you are the one who needs to change. Wrong. It's a *vital* word for those who wish truly to understand C.
Maybe for understanding the C standard. It is not vital for those who
simply wish to write successful programs,
If one wishes to write /correct/ C programs, an understanding of the
principles laid out in the Standard is vital. The easiest way to achieve
this understanding is by reading and understanding the C Standard.
What percent of the total number of C programs in the world do you think are
correct in this sense?
Was your first C program correct in this sense? Would it have taken more
time and effort to make it correct, knowing what you knew then? What do you
think the OP is interested in doing, _at this stage in the game_? Do think
he is interested in reading the C standard, before having written anything
substantial or understanding pointers at a practical level?
No sarcasm there, just answer honestly.
Roose
On Sun, 02 Nov 2003 21:24:25 +0000, Mark McIntyre <ma**********@spamcop.net> wrote:
On Sun, 02 Nov 2003 20:43:30 GMT, in comp.lang.c , "Roose"
<no****@nospam.nospam> wrote:
Not better for a newbie. I would love to see some
beginner ask you about C programming, and you start blathering on about
lvalues.
And whats wrong with learning the techncal words that help define the
language you're using? The concept of an lvalue is very useful in C.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/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 =---
Mark: The limit for sigs on the Usenet is 4 lines and they need to be
immediately below a "-- " line.
Fix yours or I will have to killfile you.
What Newsfeed.Com is doing amounts to nothing but spam. Ditch them.
--
Alan C this post ends with w
q
On Sun, 02 Nov 2003 21:30:37 GMT, Roose <no****@nospam.nospam> wrote:
I do wonder why K&R didn't find it important enough to include a reference
to it in the index to the 2nd Edition....
Not to be redundant, but this is probably because it is not common in
colloquial usage among C programmers. It probably exists to give compiler
writers a convenient term for a general idea, which the regular C programmer
needn't be concerned with.
Whereas Roose's explanation of "object" wasn't quite as useful as the one
above, I was very much attracted to his ideas about anchoring the abstract
in the real world of cpu registers and such.
I'm glad you found it useful.
Perhaps it wouldn't be a bad idea to learn a little assembly language at
this point?
That might help, but you don't even need to learn a specific machine. You
can have a quite simplified model of what assembly language is and it will
be helpful in C programming. After all, it is different for each machine,
so you don't want to have _too_ specific an idea.
Basically you have a CPU which has a clock say every microsecond if you're
on a gighertz machine.
Wouldn't that be "nanosecond"?
A program is a stream of instructions (pretend they are stored in 32 bits in a binary format). Pretend it is a big array of
bytes. You start at the beginning, and just drag through the stream. They
are executed as fast as possible on these discrete clock ticks. Some
instructions take more cycles than others. Adds are cheap (say they take 1
cycle), multiplies a little slower (2 cycles), divides slower (4 cycles).
These are numbers I pulled out of my ass, of course it's different on every
machine.
One assumes that you washed them before posting :-|
You also have all the bitwise operators in C as single instructions, more or less. You have floating point and integer
instructions. Character strings are arrays of integers (ASCII). Pointers
are integers as well.
There are instructions to load a word from memory into a CPU register, and
vice versa, to store a word from a CPU register to memory. Note that memory
accesses are much more expensive than arithmetic instructions (pretend 50
cycles on average). All the instructions only work on CPU registers. So to
add to integers in memory, you would have to:
1. load them both from memory to CPU registers
2. execute the add instruction and specify those two registers
3. store the result back to memory
So memory is just dumb storage. I didn't realize that.
Memory is just a big array of bytes. If you have 1 gig of memory, pretend
it is addressed 0 .. 0x3FFFFFFF. This is 2^30-1, or 1 gig. 0xFFFFFFFF is
2^32-1, which means 4 gigs. If you have heard Apple's stupid advertisements
that you can have more than 4 gigs of RAM in their PCs, that is because they
use more than 32 bits for pointers (i.e. the G5's 64-bit).
Don't get THAT at all, but that's okay for now.
In your previous post you recommended that I learn hexadecimal (which I
have a slight handle on: 0-9-F with one character to describe identify
a nibble.
By this you mean learning to convert it to decimal, right?
Also, you know that if's and goto's can be substituted for all for and while
loops.
I do?
Loops are just a convenient abstraction. On the machine, they are
all implemented in terms of if's and goto's (called jumps in assembly
language, you jump from one instruction to another than is not sequential).
So basically the CPU drags through the instructions sequentially, until it
hits a jump instruction.
Sounds like the b command in sed. (oops! The b command in sed must be
like the jump instruction in C :-)
If you want to know about I/O, you'll have to learn about interrupts and
such,
and I'll stop here because that is more than enough to absorb.
Well, I knew THAT at least.
(Note: nitpickers will be flamed. I _know_ for a fact these things are not
all true on every machine, but is a convenient model, in the interest of
giving something _concrete_, again)
Singe the hair off their balls: I'm getting a lot out of this.
It's really hard to learn the basics of anything if you get too bogged down
in exactness. May I also point out that quoting the ANSI standard to a novice is about
as useful as replying in Swahili :-)
Indeed.
Roose
I read this carefully, twice, consulting K&R for basic definitions.
At present I see each piece of hardware as having a control panel with
switches and dials (card) with the program deciding which switch to flip
or dial to turn, in what order...
Thanks again Roose. There is altogether too little practical talk in
the programming world, which makes it very hard for novices.
--
Alan C this post ends with w
q
On Mon, 03 Nov 2003 01:07:01 +0100, Irrwahn Grausewitz <ir*******@freenet.de> wrote:
"Roose" <no****@nospam.nospam> wrote:
"Irrwahn Grausewitz" <ir*******@freenet.de> wrote in message
news:r1********************************@4ax.com... > "Roose" <no****@nospam.nospam> wrote:
> <snip>
> > I'm trying to help the guy learn.
>
> This is best done by providing *correct* information.
Actually, it's best done by giving someone something to _do_, rather then
telling them information. Which is what I did.
No. You provided incorrect information and got defensive when you were
corrected.
Information that isn't relevant only confuses. Besides, the term object is
just a name, i.e. your statement is a synthetic fact (as opposed an
analytic). If you don't know what I mean, go read some philosophy.
In order to dicuss something you first have to get the terms right. If
you don't know what I mean, follow your own advice and go read some
philosophy.
I
didn't know what an object is in C until now, and I have programmed
successfully for many years, shipped many products, etc. It doesn't matter.
Hopefully I never have to use one of those products.
Nobody has ever learned anything by reading a bunch of facts. They learn by
doing. If the OP does what I told him to do successfully, he will have gone
A LOT farther toward being a professional programmer in C then if simply
reads all of the "definitions" post.
Reread the thread: the poster asked for the definition of the term
"object" in the context of the C language. Why not answer his question
instead of gibbering?
It wasn't "gibbering", it was very helpful.
A lot more helpful than this.
--
Alan C this post ends with w
q
"Roose" <no****@nospam.nospam> writes:
[...] Basically you have a CPU which has a clock say every microsecond if you're
on a gighertz machine.
[...]
To nitpick: a gigahertz machine would have a clock cycle every
nanosecond, not every microsecond.
--
Keith Thompson (The_Other_Keith) ks*@cts.com <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
In article <KD*****************@newsread4.news.pas.earthlink. net>
Alan Connor <xx**@yyy.zzz> writes: So memory is just dumb storage. I didn't realize that.
Good, because there are machines on which this is not the case. :-)
C's model (of "objects" and values) does require that plain old
"dumb storage" memory *exist*, but it permits "smart storage" too,
and on machines that have it, compilers are allowed to use it.
(There is an important and interesting -- but alas, off-topic in
c.l.c -- class of machines with "atomic memory" on which various
forms of lock-free parallelism are possible.)
On Sun, 02 Nov 2003 21:30:37 GMT, Roose <no****@nospam.nospam> wrote:Memory is just a big array of bytes. If you have 1 gig of memory,
pretend it is addressed 0 .. 0x3FFFFFFF. ... If you have heard Apple's
stupid advertisements that you can have more than 4 gigs of RAM in
their PCs, that is because they use more than 32 bits for pointers
(i.e. the G5's 64-bit).
Don't get THAT at all, but that's okay for now.
I am not sure which part you "don't get", but be aware that this,
too, is not required of systems that will run C, and indeed, there
are systems on which it is not true, or at least only partly true.
One of them was very common only a decade ago: the 80x86 CPU in
the ordinary IBM PC has non-linear ("segmented") addressing, and
in 16-bit modes -- which are no longer used for much, but were all
one had until the 80386 came out -- a memory address was made up
of segment:offset pairs.
Of course, actually using this to good effect was slow at best,
and a lot of old C compilers for the x86 used bizarre modifiers
(spelled "far" and "near" in some cases; now more like _FAR and
_NEAR in backwards compatible modes) to let you mix "fast" code
that avoided the use of segments with "slow" code that used segments
so as to be able to break the "64K barrier" (or rather, 128K, with
64K of code and 64K of data, in a split I&D design reminiscent of
some PDP-11s, where C was originally developed).
All C really requires of memory is that it be able to store values,
and that it be "addressable" in some way. Which is where the pointers
that are in the "subject:" line here come in -- taking the address
of a memory region holding a C "object" yields a pointer to that
object.
Actually, C does impose a few more conditions on memory. In
particular, C requires that arrays be (or at least seem to be)
contiguous. An array is defined by its "element type" and a numeric
size -- in C89, an integer constant like 42 -- and an array must
be stored in memory as a contiguous sequence of that many of those
elements. Each element is itself an "object" (region of storage),
but the array as a whole is an object too, just a composed one.
If all of a given computer's memory is one big blob of bytes in
sequence, which is certainly an easy way to build a computer, then
it is equally easy to divide up this one blob any way you like.
But C does allow other arrangements, which can have add security
or reliability features for instance, as long as the resulting
memory can be grouped together to hold arrays. Other than those
arrays, there is no *requirement* that there be a neat numerical
sequencing of "all memory"; it just happens to be pretty common,
because it is so easy.
(As an aside: on modern operating systems, "memory" is usually an
illusion anyway. The OS will *simulate* a nice linear sequence of
bytes, but it does so with "pages" that are "paged in" and "paged
out" to/from some form of "backing store" -- typically on disk --
and shuffled and reshuffled without any individual program, whether
coded in C or any other language, being able to see what is happening.
The hardware must provide a certain amount of assistance to let
the OS know what a program is trying to do, and the OS then determines
whether the code is doing something "normal" and "allowed", and if
so, arranges to allow it. The OS can then also determine whether
the program is running amok, and if so, stop it. While large chunks
of OSes can be written in nothing other than strictly conforming
C code, parts *must* be written using stuff outside the C standard,
and often must be hand-coded in assembly. These include the parts
that talk with hardware to find out what the various user programs
are attempting.)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.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.
Roose wrote: I do wonder why K&R didn't find it important enough to include a
reference
to it in the index to the 2nd Edition....
Not to be redundant, but this is probably because it is not common in
colloquial usage among C programmers.
On the contrary, it's simply a false statement. The term /is/ in the index
of K&R2.
--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Sheldon Simms wrote: On Sat, 01 Nov 2003 21:12:00 -0800, Larry Niven wrote:
I would rather read a book than reading on the Web, because I have poor eyesight.
Your eyes are more precious than $25USD, so I suggest you buy the book.
In fact, that book is worth reading.
Apparently you have read the book. Tell me, do the words "far pointer"
and "near pointer" appear in the book? If so, don't read the book.
"The Magic Goes Away" is worth reading.
It sounds like "Mastering C Pointers" isn't worth reading at all.
P'haps Larry should ask Jerry P about C pointers ;-)
--
Lew Pitcher
Master Codewright and JOAT-in-training
Registered Linux User #112576 ( http://counter.li.org/)
Slackware - Because I know what I'm doing.
Roose wrote: > Give me a break.
Sure. Take a break, any time you like.
Hilarious. Back to children's games, I see.
No. I am not a mind-reader. I answer to what you say, not to what you might
or might not mean. You asked me to give you a break, and I'm happy to
oblige. If you have a problem with taking a break, why ask me for one?
In comp.lang.c.moderated, I suspect that many of your articles would
simply not be approved by the moderator. Feel free to try to prove me wrong.
As would many of yours.
It's possible, but irrelevant, since I never start these kinds of
disagreement anyway. But, as it happens, although I don't regularly read
clcm, I have had around 90 articles posted there, according to Google.
> which you would never hear in the real world.
Well, actually, I do discuss such (relevant) technical details in the
real world, as well as on Usenet. And anyway, what makes you think that
Usenet is not part of the real world?
Stop with the sniveling wordplay already.
Do you always resort to abuse when you run out of logic?
> Then they
> get turned off to C and think it's for wankers.
Speculation. I've found that people often respond well to being told the
underlying truth, rather than the helicopter-joystick method of
programming: "fiddle with the program, and watch what the computer does,
because if you want it to do that again, that is the code you have to
write" is not a very satisfactory way to learn programming.
I agree that that's a terrible way to learn. Without the concepts, you're
just blindly hacking.
And that's why we treat the concepts so seriously here, the ones that you
seem so loathe to recognise as important - such as the concept of "object".
That's why I specifically said that you need at
least TWO perspectives. I encourage them to read
your article. My claim is that that's not sufficient.
They should read a concrete explanation like mine.
Together they will help you understand pointers.
Specific discussions of particular platforms /are/ sometimes held here, but
they normally demonstrate why concrete experience can be misleading rather
than enlightening.
<snip>
[...] The real question was about pointers.
OK, so do you think that the OP wanted just to study pointers for the sake
of dinner party conversation, or eventually write a real program? Again,
READ BETWEEN THE LINES.
I think that the OP wanted to study pointers so that he could understand
them. That is why I answered as I did. To derive one's "understanding" of
pointers from a particular platform is a foolish thing to do. There are
still people who think that C has "near" and "far" keywords, and who are
rather surprised when their pointer code suddenly stops working when moved
to a different target machine. They have learned pointers your way. They
should have learned them properly, didn't, and now pay the price.
> It may technically, but not in colloquial usage.
Then colloquial usage is wrong, and should be changed.
Q.E.D. Another perfect example of why my underemployed flames were so
accurate.
I do not have such a huge amount of spare time that there is not a cost to
the community associated with my taking time out to debunk your errors.
Everybody else is wrong; and you're right.
At last you understand.
<snip>
--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
"Richard Heathfield" <do******@address.co.uk.invalid> wrote: Yes, a typo, already corrected elsethread. No, I didn't notice it myself.
Yes, sorry, the elsethread had not yet reached my news server when I replied.
--
Simon.
Chris, I enjoyed reading your post and there is definitely interesting
information here. But I would contend that if someone doesn't yet have a
good understanding of pointers, he won't have the foggiest idea what you're
talking about. : )
"Chris Torek" <no****@elf.eng.bsdi.com> wrote in message
news:bo**********@elf.eng.bsdi.com... In article <KD*****************@newsread4.news.pas.earthlink. net>
Alan Connor <xx**@yyy.zzz> writes:So memory is just dumb storage. I didn't realize that.
Good, because there are machines on which this is not the case. :-)
C's model (of "objects" and values) does require that plain old
"dumb storage" memory *exist*, but it permits "smart storage" too,
and on machines that have it, compilers are allowed to use it.
(There is an important and interesting -- but alas, off-topic in
c.l.c -- class of machines with "atomic memory" on which various
forms of lock-free parallelism are possible.)
On Sun, 02 Nov 2003 21:30:37 GMT, Roose <no****@nospam.nospam> wrote:Memory is just a big array of bytes. If you have 1 gig of memory,
pretend it is addressed 0 .. 0x3FFFFFFF. ... If you have heard Apple's
stupid advertisements that you can have more than 4 gigs of RAM in
their PCs, that is because they use more than 32 bits for pointers
(i.e. the G5's 64-bit).
Don't get THAT at all, but that's okay for now.
I am not sure which part you "don't get", but be aware that this,
too, is not required of systems that will run C, and indeed, there
are systems on which it is not true, or at least only partly true.
One of them was very common only a decade ago: the 80x86 CPU in
the ordinary IBM PC has non-linear ("segmented") addressing, and
in 16-bit modes -- which are no longer used for much, but were all
one had until the 80386 came out -- a memory address was made up
of segment:offset pairs.
Of course, actually using this to good effect was slow at best,
and a lot of old C compilers for the x86 used bizarre modifiers
(spelled "far" and "near" in some cases; now more like _FAR and
_NEAR in backwards compatible modes) to let you mix "fast" code
that avoided the use of segments with "slow" code that used segments
so as to be able to break the "64K barrier" (or rather, 128K, with
64K of code and 64K of data, in a split I&D design reminiscent of
some PDP-11s, where C was originally developed).
All C really requires of memory is that it be able to store values,
and that it be "addressable" in some way. Which is where the pointers
that are in the "subject:" line here come in -- taking the address
of a memory region holding a C "object" yields a pointer to that
object.
Actually, C does impose a few more conditions on memory. In
particular, C requires that arrays be (or at least seem to be)
contiguous. An array is defined by its "element type" and a numeric
size -- in C89, an integer constant like 42 -- and an array must
be stored in memory as a contiguous sequence of that many of those
elements. Each element is itself an "object" (region of storage),
but the array as a whole is an object too, just a composed one.
If all of a given computer's memory is one big blob of bytes in
sequence, which is certainly an easy way to build a computer, then
it is equally easy to divide up this one blob any way you like.
But C does allow other arrangements, which can have add security
or reliability features for instance, as long as the resulting
memory can be grouped together to hold arrays. Other than those
arrays, there is no *requirement* that there be a neat numerical
sequencing of "all memory"; it just happens to be pretty common,
because it is so easy.
(As an aside: on modern operating systems, "memory" is usually an
illusion anyway. The OS will *simulate* a nice linear sequence of
bytes, but it does so with "pages" that are "paged in" and "paged
out" to/from some form of "backing store" -- typically on disk --
and shuffled and reshuffled without any individual program, whether
coded in C or any other language, being able to see what is happening.
The hardware must provide a certain amount of assistance to let
the OS know what a program is trying to do, and the OS then determines
whether the code is doing something "normal" and "allowed", and if
so, arranges to allow it. The OS can then also determine whether
the program is running amok, and if so, stop it. While large chunks
of OSes can be written in nothing other than strictly conforming
C code, parts *must* be written using stuff outside the C standard,
and often must be hand-coded in assembly. These include the parts
that talk with hardware to find out what the various user programs
are attempting.)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.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.
On 2 Nov 2003 22:48:36 -0700, Chris Torek <no****@elf.eng.bsdi.com> wrote:
In article <KD*****************@newsread4.news.pas.earthlink. net>
Alan Connor <xx**@yyy.zzz> writes:So memory is just dumb storage. I didn't realize that.
Good, because there are machines on which this is not the case. :-)
Wouldn't ya know it...
C's model (of "objects" and values) does require that plain old
"dumb storage" memory *exist*, but it permits "smart storage" too,
and on machines that have it, compilers are allowed to use it.
(There is an important and interesting -- but alas, off-topic in
c.l.c -- class of machines with "atomic memory" on which various
forms of lock-free parallelism are possible.)
Well, it's incomprehensible and therefore SHOULD be OT :-) On Sun, 02 Nov 2003 21:30:37 GMT, Roose <no****@nospam.nospam> wrote:Memory is just a big array of bytes. If you have 1 gig of memory,
pretend it is addressed 0 .. 0x3FFFFFFF. ... If you have heard Apple's
stupid advertisements that you can have more than 4 gigs of RAM in
their PCs, that is because they use more than 32 bits for pointers
(i.e. the G5's 64-bit).
Don't get THAT at all, but that's okay for now.
I am not sure which part you "don't get",
90% of this post, as a matter of fact.
Thanks for the effort, but I'm still not exactly sure what an object is.
(except that they aren't 3-dimensional constructions having weight and mass)
Co-processing parallel non-linear 16-bit sugar-free oscillators are a
wee bit over my head...
--
Alan C this post ends with w
q
On Mon, 3 Nov 2003 06:21:00 +0000 (UTC), Richard Heathfield <do******@address.co.uk.invalid> wrote:
Roose wrote:
I do wonder why K&R didn't find it important enough to include a
reference
to it in the index to the 2nd Edition....
Not to be redundant, but this is probably because it is not common in
colloquial usage among C programmers.
On the contrary, it's simply a false statement. The term /is/ in the index
of K&R2.
--
You are right. I was looking at the C Answer Book. Sorry.
But the explanation in K&R is not nearly as good as the ones I received
from you and others here.
--
Alan C this post ends with w
q
Richard Heathfield wrote: Roose wrote:
I do wonder why K&R didn't find it important enough to
include a reference to it in the index to the 2nd
Edition....
Not to be redundant, but this is probably because it is not
common in colloquial usage among C programmers.
On the contrary, it's simply a false statement. The term /is/
in the index of K&R2.
In my 1978 first edition of K&R, Chapter 0, page 3:
"In C. the fundamental data objects are characters, integers of
several sizes, and floating point numbers. In addition, there is
a heirarchy of derived data types created with pointers, arrays,
structures, unions, and functions."
The term did not appear in the index of K&R1; and one needs to do
a little reading to find it - but only a /little/ since the
quoted text appears at the very top of page three. 8-)
Probably the "C programmers" referred to are those who prefer
ignorance to the drudgery of reading all that boring technical
literature and learning the associated vocabulary - self-styled
'free spirits' and all that (the kind who only check the value
returned from critical functions when they're in the mood.)
--
Morris Dovey
West Des Moines, Iowa USA
C links at http://www.iedu.com/c
Read my lips: The apple doesn't fall very far from the tree.
Morris Dovey wrote: Richard Heathfield wrote:
The term ["object"] /is/ in the index of K&R2.
In my 1978 first edition of K&R, Chapter 0, page 3:
"In C. the fundamental data objects are characters, integers of
several sizes, and floating point numbers. In addition, there is
a heirarchy of derived data types created with pointers, arrays,
structures, unions, and functions."
Parcel the book up carefully. I'll send you my mailing address under
separate cover.
<snip>
Probably the "C programmers" referred to are those who prefer
ignorance to the drudgery of reading all that boring technical
literature and learning the associated vocabulary - self-styled
'free spirits' and all that (the kind who only check the value
returned from critical functions when they're in the mood.)
I'm afraid that this point will be lost on the very people who could learn
most from it, but that doesn't make it any less true.
--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Alan Connor <zz****@xxx.yyy> wrote: Irrwahn Grausewitz <ir*******@freenet.de> wrote:
<abstRoose's crap snipped> Reread the thread: the poster asked for the definition of the term
"object" in the context of the C language. Why not answer his question
instead of gibbering?
It wasn't "gibbering", it was very helpful.
If you find misleading, off-topic and partly incorrect information
given by an individual having horrible misconceptions about how C works
helpful: your decision. Just be prepared for others to disagree.
A lot more helpful than this.
Indeed; why did you post it then?
Regards
--
Irrwahn
(ir*******@freenet.de)
On Sun, 2 Nov 2003, Alan Connor wrote: Perhaps it wouldn't be a bad idea to learn a little assembly language at
this point?
It would be a very good idea. Just don't fall into the trap that Roose
does: that all the world looks like the particular cpu you have learnt.
There are many things that seem natural and obvious if all you know is a
typical CPU architecture and a not too smart C compiler. Things which
aren't actually C but only happen to work. Sometimes.
May I also point out that quoting the ANSI standard to a novice is about
as useful as replying in Swahili :-)
Telling you fantasy stories that sound right but aren't shouldn't be very
useful, either ;)
-Peter
Being really good at C++ is like being really good at using rocks to
sharpen sticks.
-- Thant Tessman
Let me preface this with some meta-comments. If your goal is to learn C, by
all means go ahead and dive right into the C language. You only learn by
making mistakes. But is a common fact in computers that you really only
master something when you have at least learned the level below it, i.e.
_what it is abstracting_. Then you see where the abstraction came from.
See these articles: http://www.joelonsoftware.com/articl...tractions.html http://biztech.ericsink.com/Abstraction_Pile.html
So if you configure OSes, it's good to learn some scripting. If you script,
good to know some compiled programming. If you program C, good to know some
assembly/computer architecture.
The idea was to give a simple concrete model that anyone can learn, but
don't get bogged down if your real goal is to learn C. Basically what I'm
describing is a von Neumann machine with some details (this is a very
influential hardware architecture that created the descendants of PCs,
roughly). Unfortunately with a cursory google search, I couldn't find any
good links for that, maybe someone else can help out here. Basically you have a CPU which has a clock say every microsecond if
you're on a gighertz machine.
Wouldn't that be "nanosecond"?
Yes, whoops.
1. load them both from memory to CPU registers
2. execute the add instruction and specify those two registers
3. store the result back to memory
So memory is just dumb storage. I didn't realize that.
Yes, you can think of it as inert. The CPU controls everything, the
"brain". Memory is a separate unit which just stores bits. Same with the
hard disk. Notice that as the access time increases, so does the size of
the medium.
Memory is just a big array of bytes. If you have 1 gig of memory,
pretend it is addressed 0 .. 0x3FFFFFFF. This is 2^30-1, or 1 gig. 0xFFFFFFFF
is 2^32-1, which means 4 gigs. If you have heard Apple's stupid
advertisements that you can have more than 4 gigs of RAM in their PCs, that is because
they use more than 32 bits for pointers (i.e. the G5's 64-bit).
Don't get THAT at all, but that's okay for now.
The main point here was that a pointer is a C language abstraction (for an
address in memory). A pointer at the hardware level _is an integer_.
Memory is just a big array of bytes again. Say you have 1 meg of memory,
then you can just number the bytes 0 .. 1,048,575 (2^20-1). Suppose you
have a variable numFiles that is the number of files in a directory = 55.
That variable must be stored somewhere. Say it is stored at the 200,005th
byte. Then a pointer to numFiles would have the numeric value 200,004 (get
used to indexing from 0 in C). That's it. Nothing else. It's like an
array index if you think of the array as all of memory.
e.g.
int numFiles = 55;
int* pNumFiles = &numFiles; // pNumFiles is a variable of pointer
type, with the numeric value 200,004
Of course, as always, there are details, but I'm not going to clutter up
that simple concept with them. And this is very real, you can inspect
pointers in a debugger and see this (which was my suggestion).
Say you have a 32 bit register. After you learn binary/hex, you will see
why the number of different integers you can store in 32-bits is 2^32 = 4
gigs. A pointer can be thought of as an integer index, like I said. Thus
if a pointer is 32-bits, then you can only address 4 gigs of memory.
In your previous post you recommended that I learn hexadecimal (which I
have a slight handle on: 0-9-F with one character to describe identify
a nibble.
By this you mean learning to convert it to decimal, right?
You don't actually NEED to in order to do the exercise I suggested, since
many debuggers will display all values in decimal, but it helps to get into
the mindset. It is pretty simple if you are even mildly mathematical. Hex
is really a shorthand for binary, in some sense. There are probably plenty
of tutorials on the web, but afterwards you should be able to understand
these common equivalences:
2^8-1 = 255 = 0xFF = 1111 1111
2^8 = 256 = 0x100 = 1 0000 0000 = 0.25 K
2^16-1 = 65535 = 0xFFFF = 1111 1111 1111 1111 (spaces in binary added for
clarity)
2^16 = 65536 = 0x10000 = 1 0000 0000 0000 0000 = 64 K
0x1 = 0001 b
0x2 = 0010 b
0x4 = 0100 b
0x8 = 1000 b
0x1 = 0001 b
0x3 = 0011 b
0x7 = 0111 b
0xF = 1111 b
Also, you know that if's and goto's can be substituted for all for and
while loops.
I do?
Yes, try taking a simple for loop or while loop and doing the exact same
thing with if's and goto's, if you don't see it right away. Of course this
is very bad programming practice, since loops make your logic more much
clearer to the reader.
(If you're not totally familiar with loops in general, you might want to try
a higher-level language like Python/Java/C# before attempting C.)
Sounds like the b command in sed. (oops! The b command in sed must be
like the jump instruction in C :-)
Well "jump" is an assembly term for specific CPU instructions. Goto is the
equilavent in C. My point was that for and while loops compile down to
jumps and tests (instruction that return true or false, basically).
Singe the hair off their balls: I'm getting a lot out of this.
It's really hard to learn the basics of anything if you get too bogged
down in exactness.
Good, I'm glad. This confirms an observation developed from some years of
teaching. Exactness isn't necessarily the problem, but you just have to
know WHAT you need to be exact about (i.e. not irrelevant details like
rarely used terminology).
Let me close with some more high level observations. What does C add on top
of this model (besides nice syntax, I'm talking ideas here)?
1) Platform independence -- instead of writing in native assembly, you write
in C, and then compilers for every platform translate your C program into a
stream of instructions (just byte data)
2) Constructs like functions, for and while loops, if's and switches, to
organize this enormous stream of instructions
3) A strong type system -- this can be confusing at first
This is why I wanted to emphasize that pointers are just integers in
hardware. They're a C language construct. Same thing with characters/
character strings. Now floats ARE actually different in hardware, but we
won't get to that.
4) some other stuff which I don't care to think up now : )
The point of the type system is to catch mistakes at an obvious level.
Compiling a C program to see if all the types match up can catch a lot of
mistakes. It's sort of a sanity check, and it helps you structure your
program.
But again, you can read all you want, but if you can pull off the exercise
with the debugger I suggested, you will learn a whole lot.
Roose
Alan Connor wrote: Thanks for the effort, but I'm still not exactly sure what an object is.
(A bit informal here)
You can say that a variable has two parts. A name and somewhere
to stay in memory. The name is an identifier and the part that
is stored in memory is the object.
So if you do this:
int i;
You will get an area of memory where you can put values by
doing stuff like i = 3; i is the name of this area of storage.
So you can say that an object is the actual area of memory
where the values of the variable is stored.
--
Thomas.
Alan,
Ignore the trolls... there's nothing particular about the architecture I
described... other than the numbers, and I already said where those came
from. As I said, what I described is basically a von Neumann machine, which
is something you would learn about in college if you took a course on
computer architecture.
And yes, I do program on wildly different architectures -- PS2, GameCube,
and XBox, each of which have more than one processor and memory space. And
I write code that is portable across the 3 consoles.
"Peter "Firefly" Lund" <fi*****@diku.dk> wrote in message
news:Pi*******************************@ask.diku.dk ... On Sun, 2 Nov 2003, Alan Connor wrote:
Perhaps it wouldn't be a bad idea to learn a little assembly language at
this point?
It would be a very good idea. Just don't fall into the trap that Roose
does: that all the world looks like the particular cpu you have learnt.
There are many things that seem natural and obvious if all you know is a
typical CPU architecture and a not too smart C compiler. Things which
aren't actually C but only happen to work. Sometimes.
May I also point out that quoting the ANSI standard to a novice is about
as useful as replying in Swahili :-)
Telling you fantasy stories that sound right but aren't shouldn't be very
useful, either ;)
-Peter
Being really good at C++ is like being really good at using rocks to
sharpen sticks.
-- Thant Tessman
Roose <no****@nospam.nospam> scribbled the following: Alan,
Ignore the trolls... there's nothing particular about the architecture I
described... other than the numbers, and I already said where those came
from. As I said, what I described is basically a von Neumann machine, which
is something you would learn about in college if you took a course on
computer architecture.
Would these trolls have names like Heathfield and Grausewitz? In that
case you have a pretty weird definition of "troll".
--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"The day Microsoft makes something that doesn't suck is probably the day they
start making vacuum cleaners."
- Ernst Jan Plugge
Alan Connor wrote: Thanks for the effort,
but I'm still not exactly sure what an object is.
An object is a region of contiguous memory,
allocated by the program.
The address of a register qualified object,
may not be accessed by the program,
so everything that has to do with the addresses of objects,
does not apply to register objects.
There's three main ways of allocation:
1
int object_1 = 0;
object_1, is an ordinary variable.
2
char *pointer_1 = "object_2";
char *pointer_2 = "object_2";
"object_2" is paradoxically, the name of an anonymous object.
pointer_1 and pointer_2, may or may not point to the same object.
3
pointer = malloc(sizeof object_3);
malloc returns either NULL,
or a pointer to an anonymous and typeless object.
The value of an object depends on the bit pattern in the object
and on the type of identifier used to access the object.
An object may be accessed safely by any type of identifier
as long as:
1 the size of the type of the identifier
doesn't excede the size of the object,
2 and there are no conflicts with the type of the pointer
and the alignment of the object,
3 if being read, the bit pattern read from the object,
is defined for the type of the identifier.
(*(unsigned char*)&object_1 == 0)
A pointer to any object, when cast to a pointer to char,
signed or unsigned, points to the lowest addressable byte
of the object.
The addresses of any two objects may be compared for equality
or inequality.
("object_2" != (char*)&object_1)
The addresses of any two bytes within the same object,
as well as the address of the very next byte after an object,
may also be compared with each other for greater than or less than.
((char*)&object_1 + sizeof object_1 > (char*)&object_1)
The greater than or less than comparison of the addresses
of two bytes in unrelated objects, is undefined.
/* ("object_2" > (char*)&object_1), Undefined */
--
pete
Before responding, I'd appreciate it if you answer the questions you ignored
from my posts... otherwise I'm not going to bother responding to your post,
either.
Richard wrote: If one wishes to write /correct/ C programs, an understanding of the
principles laid out in the Standard is vital. The easiest way to achieve
this understanding is by reading and understanding the C Standard.
What percent of the total number of C programs in the world do you think are
correct in this sense?
Was your first C program correct in this sense? Would it have taken more
time and effort to make it correct, knowing what you knew then? What do you
think the OP is interested in doing, _at this stage in the game_? Do think
he is interested in reading the C standard, before having written anything
substantial or understanding pointers at a practical level?
No sarcasm there, just answer honestly.
"Richard Heathfield" <do******@address.co.uk.invalid> wrote in message
news:bo*********@hercules.btinternet.com... Roose wrote:
> Give me a break.
Sure. Take a break, any time you like.
Hilarious. Back to children's games, I see.
No. I am not a mind-reader. I answer to what you say, not to what you
might or might not mean. You asked me to give you a break, and I'm happy to
oblige. If you have a problem with taking a break, why ask me for one?
In comp.lang.c.moderated, I suspect that many of your articles would simply not be approved by the moderator. Feel free to try to prove me wrong.
As would many of yours.
It's possible, but irrelevant, since I never start these kinds of
disagreement anyway. But, as it happens, although I don't regularly read
clcm, I have had around 90 articles posted there, according to Google.
> which you would never hear in the real world.
Well, actually, I do discuss such (relevant) technical details in the
real world, as well as on Usenet. And anyway, what makes you think that
Usenet is not part of the real world?
Stop with the sniveling wordplay already.
Do you always resort to abuse when you run out of logic?
> Then they
> get turned off to C and think it's for wankers.
Speculation. I've found that people often respond well to being told
the underlying truth, rather than the helicopter-joystick method of
programming: "fiddle with the program, and watch what the computer
does, because if you want it to do that again, that is the code you have to
write" is not a very satisfactory way to learn programming.
I agree that that's a terrible way to learn. Without the concepts,
you're just blindly hacking.
And that's why we treat the concepts so seriously here, the ones that you
seem so loathe to recognise as important - such as the concept of
"object". That's why I specifically said that you need at
least TWO perspectives. I encourage them to read
your article. My claim is that that's not sufficient.
They should read a concrete explanation like mine.
Together they will help you understand pointers.
Specific discussions of particular platforms /are/ sometimes held here,
but they normally demonstrate why concrete experience can be misleading rather
than enlightening.
<snip>
[...] The real question was about pointers.
OK, so do you think that the OP wanted just to study pointers for the
sake of dinner party conversation, or eventually write a real program?
Again, READ BETWEEN THE LINES.
I think that the OP wanted to study pointers so that he could understand
them. That is why I answered as I did. To derive one's "understanding" of
pointers from a particular platform is a foolish thing to do. There are
still people who think that C has "near" and "far" keywords, and who are
rather surprised when their pointer code suddenly stops working when moved
to a different target machine. They have learned pointers your way. They
should have learned them properly, didn't, and now pay the price.
It may technically, but not in colloquial usage.
Then colloquial usage is wrong, and should be changed.
Q.E.D. Another perfect example of why my underemployed flames were so
accurate.
I do not have such a huge amount of spare time that there is not a cost to
the community associated with my taking time out to debunk your errors.
Everybody else is wrong; and you're right.
At last you understand.
<snip>
--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
[top-posting fixed] Richard wrote:
<snip>
Roose wrote:
Before responding, I'd appreciate it if you answer the questions you
ignored from my posts... otherwise I'm not going to bother responding to
your post, either.
I only post replies to you when it is necessary to correct your errors. If
you don't write articles, you won't make errors, so it won't be necessary
to correct them.
I think you've stumbled across a big time-saver. Well done.
--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Peter \"Firefly\" Lund wrote: On Sun, 2 Nov 2003, Alan Connor wrote:
Perhaps it wouldn't be a bad idea to learn a little assembly
language at this point?
It would be a very good idea. Just don't fall into the trap
that Roose does: that all the world looks like the particular
cpu you have learnt.
Roose would be much less maligned if he would surround his
explanations with "non-precise" cavils. An unnamed number of
decades ago I had a very good mathematics instructor, who often
preceded some explanation with "this is not exact nor complete,
but it gives the general flavor. Later we will return and develop
some real proofs".
People would be well advised to learn the assembly language of a
simple processor. About the simplest is the PDP-8, while a more
complex machine is the 8080. I am omitting things like the 8008
because they are non-extendible, while the above two have complete
instruction sets which can be made to do many things with suitable
hardware. MIX belongs in there somewhere also.
--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
CBFalconer <cb********@yahoo.com> scribbled the following: People would be well advised to learn the assembly language of a
simple processor. About the simplest is the PDP-8, while a more
complex machine is the 8080. I am omitting things like the 8008
because they are non-extendible, while the above two have complete
instruction sets which can be made to do many things with suitable
hardware. MIX belongs in there somewhere also.
I once took it upon myself to learn the assembly language of the MOS
Technologies 6502 and 6510 series. This is the only real-world processor
whose assembly language I know. Nevertheless, it has given me an insight
to how assembly languages differ from high-level languages such as C.
--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"I will never display my bum in public again."
- Homer Simpson
On 3 Nov 2003 18:45:30 GMT, Joona I Palaste <pa*****@cc.helsinki.fi> wrote: CBFalconer <cb********@yahoo.com> scribbled the following: People would be well advised to learn the assembly language of a
simple processor. About the simplest is the PDP-8, while a more
complex machine is the 8080. I am omitting things like the 8008
because they are non-extendible, while the above two have complete
instruction sets which can be made to do many things with suitable
hardware. MIX belongs in there somewhere also.
I once took it upon myself to learn the assembly language of the MOS
Technologies 6502 and 6510 series. This is the only real-world processor
whose assembly language I know. Nevertheless, it has given me an insight
to how assembly languages differ from high-level languages such as C.
In college, I learned (to my later benefit) IBM 370 Assembly language. Around
the time I got my first real job in computers, I taught myself Intel 8080
Assembly /and/ Zilog Z80 Assembly language. Prior to that, I had a brush with
PDP-10 and PDP-11 assembler language, but never really understood them.
For what it's worth, I firmly believe that it would do most of the current crop
of "low level programmers" to learn IBM 370 Assembly language. This to find out
how to do things when you don't have a stack, aren't working in ASCII, and must
calculate with /very/ long decimal numbers. ;-)
--
Lew Pitcher
IT Consultant, Enterprise Technology Solutions
Toronto Dominion Bank Financial Group
(Opinions expressed are my own, not my employers')
On Mon, 03 Nov 2003 10:58:49 +0100, Irrwahn Grausewitz <ir*******@freenet.de> wrote:
Alan Connor <zz****@xxx.yyy> wrote:
Irrwahn Grausewitz <ir*******@freenet.de> wrote: ><abstRoose's crap snipped> > Reread the thread: the poster asked for the definition of the term
> "object" in the context of the C language. Why not answer his question
> instead of gibbering?
It wasn't "gibbering", it was very helpful.
If you find misleading, off-topic and partly incorrect information
given by an individual having horrible misconceptions about how C works
helpful: your decision. Just be prepared for others to disagree.
A lot more helpful than this.
Indeed; why did you post it then?
Regards
--
Irrwahn
(ir*******@freenet.de)
What Roose posted was very helpful to me.
I am not going to dismiss an obviously intelligent and learned person on
your say so.
--
Alan C this post ends with w
sq
On Mon, 03 Nov 2003 15:18:34 GMT, Roose <no****@nospam.nospam> wrote:
Alan,
Ignore the trolls... there's nothing particular about the architecture I
described... other than the numbers, and I already said where those came
from. As I said, what I described is basically a von Neumann machine, which
is something you would learn about in college if you took a course on
computer architecture.
And yes, I do program on wildly different architectures -- PS2, GameCube,
and XBox, each of which have more than one processor and memory space. And
I write code that is portable across the 3 consoles.
I can tell the wheat from the chaff, Richard.
--
Alan C this post ends with w
q
On Mon, 03 Nov 2003 18:40:15 GMT, CBFalconer <cb********@yahoo.com> wrote:
Peter \"Firefly\" Lund wrote: On Sun, 2 Nov 2003, Alan Connor wrote:
> Perhaps it wouldn't be a bad idea to learn a little assembly
> language at this point?
It would be a very good idea. Just don't fall into the trap
that Roose does: that all the world looks like the particular
cpu you have learnt.
Roose would be much less maligned if he would surround his
explanations with "non-precise" cavils. An unnamed number of
decades ago I had a very good mathematics instructor, who often
preceded some explanation with "this is not exact nor complete,
but it gives the general flavor. Later we will return and develop
some real proofs".
I didn't need those cavils, and he was addressing me.
People would be well advised to learn the assembly language of a
simple processor. About the simplest is the PDP-8, while a more
complex machine is the 8080. I am omitting things like the 8008
because they are non-extendible, while the above two have complete
instruction sets which can be made to do many things with suitable
hardware. MIX belongs in there somewhere also.
Thanks much. Actually sounds fascinating.
--
Alan C this post ends with w
q
On Mon, 03 Nov 2003 14:39:22 +0000, Thomas Stegen <ts*****@cis.strath.ac.uk> wrote:
Alan Connor wrote:
Thanks for the effort, but I'm still not exactly sure what an object is.
(A bit informal here)
You can say that a variable has two parts. A name and somewhere
to stay in memory. The name is an identifier and the part that
is stored in memory is the object.
So if you do this:
int i;
You will get an area of memory where you can put values by
doing stuff like i = 3; i is the name of this area of storage.
So you can say that an object is the actual area of memory
where the values of the variable is stored.
--
Thomas.
Thanks Thomas.
--
Alan C this post ends with w
q
On Mon, 03 Nov 2003 17:12:11 GMT, pete <pf*****@mindspring.com> wrote:
Alan Connor wrote:
Thanks for the effort,
but I'm still not exactly sure what an object is.
An object is a region of contiguous memory,
allocated by the program.
The address of a register qualified object,
may not be accessed by the program,
so everything that has to do with the addresses of objects,
does not apply to register objects.
What's a "register (qualified) object"?
There's three main ways of allocation:
1
int object_1 = 0;
object_1, is an ordinary variable.
2
char *pointer_1 = "object_2";
char *pointer_2 = "object_2";
"object_2" is paradoxically, the name of an anonymous object.
pointer_1 and pointer_2, may or may not point to the same object.
3
pointer = malloc(sizeof object_3);
malloc returns either NULL,
or a pointer to an anonymous and typeless object.
The value of an object depends on the bit pattern in the object
and on the type of identifier used to access the object.
An object may be accessed safely by any type of identifier
as long as:
1 the size of the type of the identifier
doesn't excede the size of the object,
2 and there are no conflicts with the type of the pointer
and the alignment of the object,
3 if being read, the bit pattern read from the object,
is defined for the type of the identifier.
(*(unsigned char*)&object_1 == 0)
A pointer to any object, when cast to a pointer to char,
signed or unsigned, points to the lowest addressable byte
of the object.
The addresses of any two objects may be compared for equality
or inequality.
("object_2" != (char*)&object_1)
The addresses of any two bytes within the same object,
as well as the address of the very next byte after an object,
may also be compared with each other for greater than or less than.
((char*)&object_1 + sizeof object_1 > (char*)&object_1)
The greater than or less than comparison of the addresses
of two bytes in unrelated objects, is undefined.
/* ("object_2" > (char*)&object_1), Undefined */
--
pete
Most of that was over my head, pete. But thanks for the effort.
It will be in the archives when I'm ready for it.
--
Alan C this post ends with w
q
On Mon, 3 Nov 2003 18:20:31 +0000 (UTC), Richard Heathfield <do******@address.co.uk.invalid> wrote:
[top-posting fixed]
Richard wrote:
<snip>
Roose wrote:
Before responding, I'd appreciate it if you answer the questions you
ignored from my posts... otherwise I'm not going to bother responding to
your post, either.
I only post replies to you when it is necessary to correct your errors. If
you don't write articles, you won't make errors, so it won't be necessary
to correct them.
I think you've stumbled across a big time-saver. Well done.
Well, you just crossed the line with that bit of deceitful and sophomoric
trolling.
Killfiled for N days.
I'm into saving time too.
--
Alan C this post ends with w
q
On Mon, 03 Nov 2003 20:39:38 GMT, Alan Connor <zz****@xxx.yyy> wrote: On Mon, 03 Nov 2003 17:12:11 GMT, pete <pf*****@mindspring.com> wrote:
Alan Connor wrote:
Thanks for the effort,
but I'm still not exactly sure what an object is.
An object is a region of contiguous memory,
allocated by the program.
The address of a register qualified object,
may not be accessed by the program,
so everything that has to do with the addresses of objects,
does not apply to register objects.
What's a "register (qualified) object"?
register int SomeThing;
as opposed to
int SomeThingElse;
Given
int *PointerToSomething;
you can
PointerToSomething = &SomeThingElse;
but not
PointerToSomething = &SomeThing;
because SomeThing is a register qualified object, but SomeThingElse is not.
--
Lew Pitcher
IT Consultant, Enterprise Technology Solutions
Toronto Dominion Bank Financial Group
(Opinions expressed are my own, not my employers')
On Mon, 03 Nov 2003 05:50:46 GMT, Roose <no****@nospam.nospam> wrote:
Let me preface this with some meta-comments. If your goal is to learn C, by
all means go ahead and dive right into the C language. You only learn by
making mistakes. But is a common fact in computers that you really only
master something when you have at least learned the level below it, i.e.
_what it is abstracting_. Then you see where the abstraction came from.
See these articles:
http://www.joelonsoftware.com/articl...tractions.html
http://biztech.ericsink.com/Abstraction_Pile.html
Will do.
So if you configure OSes, it's good to learn some scripting. If you script,
good to know some compiled programming. If you program C, good to know some
assembly/computer architecture.
Yes!
The idea was to give a simple concrete model that anyone can learn, but
don't get bogged down if your real goal is to learn C. Basically what I'm
describing is a von Neumann machine with some details (this is a very
influential hardware architecture that created the descendants of PCs,
roughly). Unfortunately with a cursory google search, I couldn't find any
good links for that, maybe someone else can help out here.
> Basically you have a CPU which has a clock say every microsecond if you're > on a gighertz machine.
Wouldn't that be "nanosecond"?
Yes, whoops.
> 1. load them both from memory to CPU registers
> 2. execute the add instruction and specify those two registers
> 3. store the result back to memory
>
So memory is just dumb storage. I didn't realize that.
Yes, you can think of it as inert. The CPU controls everything, the
"brain". Memory is a separate unit which just stores bits. Same with the
hard disk. Notice that as the access time increases, so does the size of
the medium.
> Memory is just a big array of bytes. If you have 1 gig of memory, pretend > it is addressed 0 .. 0x3FFFFFFF. This is 2^30-1, or 1 gig. 0xFFFFFFFF is >> > 2^32-1, which means 4 gigs. If you have heard Apple's stupid
advertisements > that you can have more than 4 gigs of RAM in their PCs, that is because they > use more than 32 bits for pointers (i.e. the G5's 64-bit).
Don't get THAT at all, but that's okay for now.
The main point here was that a pointer is a C language abstraction (for an
address in memory). A pointer at the hardware level _is an integer_.
Memory is just a big array of bytes again. Say you have 1 meg of memory,
then you can just number the bytes 0 .. 1,048,575 (2^20-1). Suppose you
have a variable numFiles that is the number of files in a directory = 55.
That variable must be stored somewhere. Say it is stored at the 200,005th
byte. Then a pointer to numFiles would have the numeric value 200,004 (get
used to indexing from 0 in C). That's it. Nothing else. It's like an
array index if you think of the array as all of memory.
e.g.
int numFiles = 55;
int* pNumFiles = &numFiles; // pNumFiles is a variable of pointer
type, with the numeric value 200,004
Of course, as always, there are details, but I'm not going to clutter up
that simple concept with them. And this is very real, you can inspect
pointers in a debugger and see this (which was my suggestion).
Say you have a 32 bit register. After you learn binary/hex, you will see
why the number of different integers you can store in 32-bits is 2^32 = 4
gigs. A pointer can be thought of as an integer index, like I said. Thus
if a pointer is 32-bits, then you can only address 4 gigs of memory.
In your previous post you recommended that I learn hexadecimal (which I
have a slight handle on: 0-9-F with one character to describe identify
a nibble.
By this you mean learning to convert it to decimal, right?
You don't actually NEED to in order to do the exercise I suggested, since
many debuggers will display all values in decimal, but it helps to get into
the mindset. It is pretty simple if you are even mildly mathematical. Hex
is really a shorthand for binary, in some sense. There are probably plenty
of tutorials on the web, but afterwards you should be able to understand
these common equivalences:
2^8-1 = 255 = 0xFF = 1111 1111
2^8 = 256 = 0x100 = 1 0000 0000 = 0.25 K
2^16-1 = 65535 = 0xFFFF = 1111 1111 1111 1111 (spaces in binary added for
clarity)
2^16 = 65536 = 0x10000 = 1 0000 0000 0000 0000 = 64 K
0x1 = 0001 b
0x2 = 0010 b
0x4 = 0100 b
0x8 = 1000 b
0x1 = 0001 b
0x3 = 0011 b
0x7 = 0111 b
0xF = 1111 b
> Also, you know that if's and goto's can be substituted for all for and while > loops.
I do?
Yes, try taking a simple for loop or while loop and doing the exact same
thing with if's and goto's, if you don't see it right away. Of course this
is very bad programming practice, since loops make your logic more much
clearer to the reader.
(If you're not totally familiar with loops in general, you might want to try
a higher-level language like Python/Java/C# before attempting C.)
Nah. I've written hundreds of for,while,until loops in sh.
Sounds like the b command in sed. (oops! The b command in sed must be
like the jump instruction in C :-)
Well "jump" is an assembly term for specific CPU instructions. Goto is the
equilavent in C. My point was that for and while loops compile down to
jumps and tests (instruction that return true or false, basically).
Singe the hair off their balls: I'm getting a lot out of this.
It's really hard to learn the basics of anything if you get too bogged
down in exactness.
Good, I'm glad. This confirms an observation developed from some years of
teaching. Exactness isn't necessarily the problem, but you just have to
know WHAT you need to be exact about (i.e. not irrelevant details like
rarely used terminology).
Let me close with some more high level observations. What does C add on top
of this model (besides nice syntax, I'm talking ideas here)?
1) Platform independence -- instead of writing in native assembly, you write
in C, and then compilers for every platform translate your C program into a
stream of instructions (just byte data)
Good. That's an important piece of the puzzle.
2) Constructs like functions, for and while loops, if's and switches, to
organize this enormous stream of instructions
All of this is found in sh, some of it being called "flow control".
(except maybe "switches" do you mean options to the compiler/assembler?)
3) A strong type system -- this can be confusing at first
This is why I wanted to emphasize that pointers are just integers in
hardware. They're a C language construct. Same thing with characters/
character strings. Now floats ARE actually different in hardware, but we
won't get to that.
4) some other stuff which I don't care to think up now : )
The point of the type system is to catch mistakes at an obvious level.
Compiling a C program to see if all the types match up can catch a lot of
mistakes. It's sort of a sanity check, and it helps you structure your
program.
Don't really get that, but it *feels* important. Errr....Can you say
"feel" on a programming newsgroup? :-)
But again, you can read all you want, but if you can pull off the exercise
with the debugger I suggested, you will learn a whole lot.
It'll happen.
Roose
Thank you again. Back to K&R and the Answer Book and I'll check out those
websites in due course.
Got really fed up with the Richard fellow. Killfiled his arrogant ass for
a while.
--
Alan C this post ends with w
q
Alan Connor <zz****@xxx.yyy> wrote: On Mon, 3 Nov 2003 18:20:31 +0000 (UTC), Richard Heathfield <do******@address.co.uk.invalid> wrote:
<snip> Roose wrote:
Before responding, I'd appreciate it if you answer the questions you
ignored from my posts... otherwise I'm not going to bother responding to
your post, either.
I only post replies to you when it is necessary to correct your errors. If
you don't write articles, you won't make errors, so it won't be necessary
to correct them.
I think you've stumbled across a big time-saver. Well done.
Well, you just crossed the line with that bit of deceitful and sophomoric
trolling.
Killfiled for N days.
I'm into saving time too.
You call Heathfield a troll? Bwhm. Bwhmhe. Bwhmhehehehe.
Bruahahahahahhaaaahahahahaahaaaaaahhaha <gasp> gnihihihihi.
You haven't been reading c.l.c for more than two days, have you?
--
Irrwahn
(ir*******@freenet.de)
Alan Connor <zz****@xxx.yyy> wrote: What Roose posted was very helpful to me.
I am not going to dismiss an obviously intelligent and learned person on
your say so.
You enjoy to be fed by an obvious troll? Happy proceedings.
--
Irrwahn
(ir*******@freenet.de)
Alan Connor <zz****@xxx.yyy> wrote: On Mon, 03 Nov 2003 18:40:15 GMT, CBFalconer <cb********@yahoo.com> wrote:
<snip> Roose would be much less maligned if he would surround his
explanations with "non-precise" cavils. An unnamed number of
decades ago I had a very good mathematics instructor, who often
preceded some explanation with "this is not exact nor complete,
but it gives the general flavor. Later we will return and develop
some real proofs".
I didn't need those cavils, and he was addressing me.
But he posted to the news-group. There is not much privacy in
usenet discussions, ya know?!?
<snip>
--
Irrwahn
(ir*******@freenet.de)
In article <el******************@newssvr14.news.prodigy.com >
Roose <no****@nospam.nospam> writes: ... I do program on wildly different architectures -- PS2, GameCube,
and XBox, each of which have more than one processor and memory space. ...
I would not call them "wildly different". The XBox uses an Intel
x86-type CPU as its main driver; the GameCube has a PowerPC CPU;
and the PS2 has a MIPS CPU. The latter two are traditional
register-oriented RISCs (although the PowerPC has a bizarre
instruction set, to anyone used to Intel and MIPS and even old IBM
370 assembly -- but not as bizarre as HP-PA or Itanium, if you ask
me). The Intel type CPU is common as dirt these days, of course.
Moreover, while game consoles do have specialized hardware (such
as special video RAM and "outboard" 3D transform engines), all
of these machines still have conventional linearly-addressed memory
for the CPUs to use, and the CPUs use it in conventional linear
fashion. And of course, all three of these are game consoles,
so they have the same ultimate goals, which results in remarkable
similarities of design.
For something really different, I would suggest trying these:
- Univac 11xx series: 18 and 36 bit integers, ones' complement
arithmetic. C compilers use 9-bit bytes.
- Data General Eclipse: conventional flat-memory RISC with one
twist: "byte pointers" (for char * and void *) are different
from all other, normal "word pointers". To convert a word
pointer to a byte pointer, the compiler must shift it left,
introducing a low-order zero bit.
- IBM AS/400. This is a "virtual architecture" with segmented,
protected memory. Pointers carry special qualification values
(a sort of access control list, as it were, or a "capability"
as it is usually called in other systems); pointers to code
are *much* larger than pointers to data.
One last architecture, for which I doubt there are any C compilers
(or even machines left? :-) ), that can expand one's idea of how
to build computers, is the Burroughs A-series. There is a brief
(albeit a bit "gushy" :-) ) overview at
<http://www.ajwm.net/amayer/papers/B5000.html>. (Many might quibble
with the claim that the Burroughs was the first machine to have
virtual memory, giving that honor instead to Manchester's Ferranti
Atlas.)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.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.
Alan Connor wrote: Well, you just crossed the line with that bit of deceitful and sophomoric
trolling.
Killfiled for N days.
I'm into saving time too.
Alan...
Wow! I'm impressed by your judgment. Richard has been one of the
most highly regarded regulars of comp.lang.c for some years now.
He's earned the professional (and personal) respect of many of
the best C programmers in the world, been recognized by Don Knuth
for spotting an error and providing a correction to "The Art of
Computer Programming", co-authored the book "C Unleashed" with
some of the most knowledgeable regulars here, and provided really
high-quality help to an awesome number of newbies (and a large
number of not-so-newbies, including myself) - all under the
scrutiny of expert peers who delight in picking nits - especially
when they're aware the poster /really/ knows his stuff.
I did say "impressed". I didn't say "favorably impressed". I
think I'd be honored if you called me deceitful and sophomoric
and a troll and killfiled me, too. I don't post as frequently as
Richard; but it /would/ save you at least some small amount of time.
--
Morris Dovey
West Des Moines, Iowa USA
C links at http://www.iedu.com/c
Read my lips: The apple doesn't fall very far from the tree.
Alan Connor wrote: What Roose posted was very helpful to me.
I'm not sure why you are so fascinated with Roose the Troll, but it's
not a good way to get good information in this newsgroup.
I am not going to dismiss an obviously intelligent and learned person on
your say so.
Irrwhan is a knowledgable and helpful member of this group. Roose is a
dispenser of bad information and a troll. I suggest reviewing the two
persons' posting history on this newsgroup via a visit to groups.google.
Brian Rodenborn
Alan Connor wrote:
[Richard Heathfield] Well, you just crossed the line with that bit of deceitful and sophomoric
trolling.
You are making a huge mistake. Richard is a frequent posters, a textbook
author and a well-respected member of this newsgroup.
Roose, on the other hand, is a troll who willing dispenses erroneous
information and replies with flames when challenged.
I suggest you reverse your decision. Killfile Roose, do not do the same
with Richard.
Brian Rodenborn Le*********@td.com (Lew Pitcher) wrote in message news:<3f***************@news21.on.aibn.com>... In college, I learned (to my later benefit) IBM 370 Assembly language.
Heh. I have an emulator for the System/360. It accepts batch jobs
(luckily, it doesn't take JCL) and returns a complete listing (a dump
if I've messed up).
Those old machines were rather interesting, especially where the
designers kind of knew what they really wanted but had to work around
the hardware to get something close.
Around
the time I got my first real job in computers, I taught myself Intel 8080
Assembly /and/ Zilog Z80 Assembly language.
Heh. I guess the fact that Z80 assembly was binary-compatible with
8080 didn't help you much, then? ;)
Prior to that, I had a brush with
PDP-10 and PDP-11 assembler language, but never really understood them.
Then I guess you never learned the beauty that is VAX, I suppose?
More's the pity: Understanding some of the intricacies of the DEC
minicomputers can help you grasp why some of C's crucial early design
decisions were made the way they were. For example, a flat memory
model and the whole notion of pre[increment|decrement] being usefully
different from post[increment|decrement] both came directly from the
PDPs.
Truly, C was designed to be somewhere between PDP-11 assembly and
PL/1, but closer to assembly in some key ways.
For what it's worth, I firmly believe that it would do most of the current crop
of "low level programmers" to learn IBM 370 Assembly language. This to find out
how to do things when you don't have a stack, aren't working in ASCII, and must
calculate with /very/ long decimal numbers. ;-)
And I think learning PDP-8 assembly is what seperates the men from the
boys, esepcially if you can only use the 8 `actual' opcodes. ;)
Alan Connor wrote: On Mon, 3 Nov 2003 18:20:31 +0000 (UTC), Richard Heathfield
<do******@address.co.uk.invalid> wrote:
[top-posting fixed]
Richard wrote:<snip>
Roose wrote:
Before responding, I'd appreciate it if you answer the questions you
ignored from my posts... otherwise I'm not going to bother responding to
your post, either.
I only post replies to you when it is necessary to correct your errors.
If you don't write articles, you won't make errors, so it won't be
necessary to correct them.
I think you've stumbled across a big time-saver. Well done.
Well, you just crossed the line with that bit of deceitful and sophomoric
trolling.
Not a troll, not deceitful. "Sophomoric" is a matter of opinion, of course,
but I can assure you that I am not, nor have I ever been, a sophomore.
Killfiled for N days.
You have absolutely no idea how devastated I am to hear this.
I'm into saving time too.
The biggest win is to stop reading Usenet.
--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Lew Pitcher wrote: Alan Connor <zz****@xxx.yyy> wrote:
.... snip ...
What's a "register (qualified) object"?
register int SomeThing;
as opposed to
int SomeThingElse;
Given
int *PointerToSomething;
you can
PointerToSomething = &SomeThingElse;
but not
PointerToSomething = &SomeThing;
because SomeThing is a register qualified object,
but SomeThingElse is not.
Which doesn't answer his question. The above is a penalty for
using register qualification, which actually means "I think this
variable would be better handled in a register". It is only a
suggestion, and the compiler need not pay any attention to it,
other than to enforce the above penalty. With modern optimizers
it is usually better not used.
--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
Alan Connor wrote: CBFalconer <cb********@yahoo.com> wrote:
.... snip ...
Roose would be much less maligned if he would surround his
explanations with "non-precise" cavils. An unnamed number of
decades ago I had a very good mathematics instructor, who often
preceded some explanation with "this is not exact nor complete,
but it gives the general flavor. Later we will return and
develop some real proofs".
I didn't need those cavils, and he was addressing me.
You have a basic misconception. He may think he is addressing
you, and you may think he is addressing you, but in reality he is
addressing the general public, as are you and I. He may also have
been addressing points you brought up. There is nothing private
about anything said here. Thus the cavils are needed to avoid
misinforming the larger audience.
So far your evaluation of the newsgroup participants appears to be
sadly flawed.
--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
On Mon, 03 Nov 2003 21:29:12 +0000, Alan Connor wrote: Got really fed up with the Richard fellow. Killfiled his arrogant ass for
a while.
You are of course welcome to killfile anyone you want, however you
should be aware that Richard is telling you the truth and Roose is
not. At least, he is not telling you the whole truth.
For example, Roose said "a pointer is an integer". This is not
true. A pointer *might* be an integer, and it might be something
else, like two distinct integers, or something else entirely.
I understand that you might not see why it matters one way or
the other, but there is a good reason to be precisely correct
right from the start: it prevents you from making lazy assumptions
that might not bite you now, but that probably will bite you
later.
I don't know why you are learning C, but lets imagine that you
might someday want to program professionally using C. If so, you
might find it professionally embarrassing when your code crashes
the airplane, cash register, medical device, file server, robot,
etc. because you assumed that a pointer is "just an integer",
as Roose urged you to.
Perhaps you think that's just hypothetical, that you'll worry
about the details when you know C better. Well that might work,
but on the other hand, I have seen things like that happen
(well, nothing as dramatic as a plane crash) because the
programmer didn't *really* know how C worked.
-Sheldon
On Mon, 03 Nov 2003 20:39:39 GMT, in comp.lang.c , Alan Connor
<zz****@xxx.yyy> wrote: On Mon, 3 Nov 2003 18:20:31 +0000 (UTC), Richard Heathfield <do******@address.co.uk.invalid> wrote:
I think you've stumbled across a big time-saver. Well done.
Well, you just crossed the line with that bit of deceitful and sophomoric trolling.
Killfiled for N days.
I'm sorry, did you just killfile RJH?
I'm into saving time too.
well, killfiling the CLC regulars and gurus is certainly going to
achieve that. After a fashion.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/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 =---
On Mon, 03 Nov 2003 00:29:05 GMT, in comp.lang.c , Alan Connor
<zz****@xxx.yyy> wrote: --
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/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 =---
Mark: The limit for sigs on the Usenet is 4 lines and they need to be
immediately below a "-- " line.
I have no control over what alibis.com stick on after my sig, which is
three lines long.
Fix yours or I will have to killfile you.
Feel free.
What Newsfeed.Com is doing amounts to nothing but spam. Ditch them.
Its that or ntl's servers. Believe me, you don't want to use ntl's
news servers for more than about ten seconds.
By the way, are you also known as roose? I'm suspicious of your sudden
appearance in this thread, and your evident agreement with a troll.
Apologies if I'm maligining you but you see my point?
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/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 =---
"Richard Heathfield" <do******@address.co.uk.invalid> wrote in message
news:bo**********@titan.btinternet.com... Alan Connor wrote:
<snip> Well, you just crossed the line with that bit of deceitful and
sophomoric trolling.
Not a troll, not deceitful. "Sophomoric" is a matter of opinion, of
course, but I can assure you that I am not, nor have I ever been, a sophomore.
OK, I for one have been getting a good laugh at your exchanges with Roose,
but this bit surprises me. Is it a British thing, or have you really never
been in the second year of secondary school or college? EMWTK.
<snip> This thread has been closed and replies have been disabled. Please start a new discussion. |
