Why pointers??

[onkar]

Why use pointers at all??

[Richard Tobin]

In article <is********************************@4ax.com>,
Mark McIntyre <ma**********@spamcop.netwrote:

>>>>Why use pointers at all??

>>>How else would you point to things?

>>Well you could let that be the compiler's problem, like it is in many
other languages.

>Huh? You mean languages where its not possible to point at things,
like Basic ? There's a reason Basic didn't take over the world.

I'll treat your question seriously. I wasn't really thinking of
Basic.

What's the difference between variable in C containing a pointer to a
structure, and one in Java or Lisp whose value is an object? All of
them are an abstraction of the address of the object. In languages
like Java and Lisp almost everything is in that sense a pointer without
any explicit action by the user.

But we don't usually call the Java and Lisp ones "pointers". C's
pointers are much closer to the machine addresses: in particular you
can do arithmetic on them, while the Java and Lisp versions are quite
opaque. You can confine yourself to a subset of C that only uses
pointers in the way that Java and Lisp do - to pass around references
to structures and (implicitly) for array operations.

So to return to the orignal question, you *have* to use pointers in
C to get what other languages provide without explicit pointers, but
taking advantage of the extra things you can do with pointers in C
is entirely optional.

-- Richard

[CBFalconer]

Spiros Bousbouras wrote:

>

.... snip ...

>
But BASIC has peek and poke so in a sense you can
point at things. Your pointers are simply integers
which hold addresses.

No they aren't. In some systems they may be.

if ((sizeof(int) != sizeof(int*))
puts("Certainly not on this machine");
else puts("Could be, not guaranteed");

--
Some informative links:
news:news.announce.newusers
http://www.geocities.com/nnqweb/
http://www.catb.org/~esr/faqs/smart-questions.html
http://www.caliburn.nl/topposting.html
http://www.netmeister.org/news/learn2quote.html

--
Posted via a free Usenet account from http://www.teranews.com

[Keith Thompson]

CBFalconer <cb********@yahoo.comwrites:

Spiros Bousbouras wrote:

>>

... snip ...

>>
But BASIC has peek and poke so in a sense you can
point at things. Your pointers are simply integers
which hold addresses.

No they aren't. In some systems they may be.

I think Spiros was referring to BASIC (i.e., the integer arguments you
pass to peek and poke are the closest thing BASIC has to pointers).

There are a number of different versions of BASIC, and I haven't used
any of them in decades; his statement is plausible, but I can't
comment on whether it's accurate.

if ((sizeof(int) != sizeof(int*))
puts("Certainly not on this machine");
else puts("Could be, not guaranteed");

He said "integers", not "ints". If pointers are bigger than ints, but
are represented the same way as unsigned longs, then you could almost
reasonably say that pointers are "simply integers that hold addresses"
-- though of course it's a bad idea to do so if you're talking about
standard C (as opposed to the innards of some particular
implementation).

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[August Karlstrom]

Richard Tobin wrote:
[...]

What's the difference between variable in C containing a pointer to a
structure, and one in Java or Lisp whose value is an object? All of
them are an abstraction of the address of the object. In languages
like Java and Lisp almost everything is in that sense a pointer without
any explicit action by the user.

Then we have the languages between C and Java in high-levelness. In
Oberon for instance, pointers are explicit but restricted. Raw pointers,
when needed, are available through the SYSTEM module.
August

[langwadt]

Tom St Denis skrev:

Richard Heathfield wrote:

onkar said:

Why use pointers at all??

No reason at all, if you don't want to. So don't bother, until a need for
them arises.

Explain to me how you'd use memory mapped I/O then?

Tom

make a struct/array that looks the like the memory mapped device and
make the linker place it on the rigth adress

-Lasse

[Peter Nilsson]

Old Wolf wrote:

Peter Nilsson wrote:

Conformance is generally limited to two things: issuing _at least
one_ diagnostic for constraint violations, and the correct semantic
implementation of strictly conforming programs (subject to
implementation limits.)

Code that is not strictly conforming may or may not require a
diagnostic. If it does, then a conforming compiler must issue it.

But whether such code is accepted, compiled, linked, etc... is
completely at the implementation's discretion. That is the freedom
that undefined behaviour allows.

It also has to compile conforming (but not strictly conforming)
programs that are don't have any syntax errors or constraint violations.

Note that the language doesn't state what 'compiling' is. That is
simply
a term commonly used to describe a collection of later translation
phases. There is nothing that I can see in the standard that states
that
a non strictly conforming translation unit must 'pass' a number of
translation phases before an implementation is allowed to reject it.

--
Peter

[Spiros Bousbouras]

Keith Thompson wrote:

CBFalconer <cb********@yahoo.comwrites:

Spiros Bousbouras wrote:

>

... snip ...

>
But BASIC has peek and poke so in a sense you can
point at things. Your pointers are simply integers
which hold addresses.

No they aren't. In some systems they may be.

I think Spiros was referring to BASIC (i.e., the integer arguments you
pass to peek and poke are the closest thing BASIC has to pointers).

Yeah , when I said "Your pointers are simply integers
which hold addresses" I meant in the context of BASIC
ie you would use BASIC's integer types to hold addresses
and that would make them "pointers".

>
There are a number of different versions of BASIC, and I haven't used
any of them in decades; his statement is plausible, but I can't
comment on whether it's accurate.

if ((sizeof(int) != sizeof(int*))
puts("Certainly not on this machine");
else puts("Could be, not guaranteed");

He said "integers", not "ints". If pointers are bigger than ints, but
are represented the same way as unsigned longs, then you could almost
reasonably say that pointers are "simply integers that hold addresses"
-- though of course it's a bad idea to do so if you're talking about
standard C (as opposed to the innards of some particular
implementation).

In a BASIC which has poke and peek you can use BASIC's
integers to refer to memory addresses. There's no pointer
type separate from integers , you just treat integers as
pointers. (Actually for all I know there may be BASIC dialects
where you have an innate pointer type but I wasn't thinking
of those)

On second thought though whether you have poke and peek is
irrelevant. You can define a large integer 1-dimensional
array and you will treat it as memory. Indices in the array
will be your pointers. But then creating a pointer to pointer
will be problematic.

I guess C is better after all ;-)

[Keith Thompson]

"Spiros Bousbouras" <sp****@gmail.comwrites:
[...]

In a BASIC which has poke and peek you can use BASIC's
integers to refer to memory addresses. There's no pointer
type separate from integers , you just treat integers as
pointers. (Actually for all I know there may be BASIC dialects
where you have an innate pointer type but I wasn't thinking
of those)

On second thought though whether you have poke and peek is
irrelevant. You can define a large integer 1-dimensional
array and you will treat it as memory. Indices in the array
will be your pointers. But then creating a pointer to pointer
will be problematic.

I guess C is better after all ;-)

Agreed, but pointers to pointers wouldn't be a problem. A pointer
variable would be an integer whose value is an array index. A pointer
to pointer would be an integer whose value is an array index, where
the specified array element contains an array index.

You can do the same thing in C. It could even be useful, if you want
to represent a dynamic data structure (e.g., a binary tree) in a way
that can easily be written to an external file, without having to
worry about maintaining pointer representations.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[sven_tmp]

onkar wrote:

Why use pointers at all??

Possible reasons:

1) with a declaration like "int a;" you
allocat memory on the stack. When you use a
pointer and the malloc-function you allocate memory on
the heap. Allocation memory on the stack is
usually faster than on the heap, but the stack size
is limited.

2) when you declare a function like foo (int a),
the value will be copied into the new stackframe when
you call the function foo. To copy a value in the memory
is slow. It is faster when you point to the memory area where
the value is located (foo (int *a)).

Sven

[John Bode]

onkar wrote:

Why use pointers at all??

1. To allow a function to modify its arguments (technically, what its
arguments are pointing to);
2. To track dynamically allocated memory;
3. To reduce redundancy (i.e., instead of multiple instances of the
same data, have one instance with multiple pointers to it);
4. To easily build dynamic structures such as lists, trees, and queues
(ties in to #2);
5. To use functions and objects in a dynamically loaded library;

And a few others I can't think of off the top of my head. You'll know
it when you see it.

[lovecreatesbea...]

Richard Heathfield wrote:

[e-mail] said:

onkar wrote:

Why use pointers at all??

If the arguments of a function should be modified

You can't modify a function's arguments. You can, however, modify the value
of a function parameter.

The function parameters might not be changeable always, for example
when they are qualified with const keywords.

then the addresses of
them

You can't take the address of an argument. Arguments are expressions, and
expressions in the general case do not necessarily have addresses.

should be passed into the function and the corresponding
parameters should be declared as pointers of type same as the arguments.

What you're trying to explain is /how/ to use a pointer in a function call
to facilitate the modification of an object's value within that function,

Thank you for the correction.

but the question is /why/ you would want to do that.

[Richard Heathfield]

[e-mail] said:

>
Richard Heathfield wrote:

>[e-mail] said:

onkar wrote:
Why use pointers at all??

If the arguments of a function should be modified

You can't modify a function's arguments. You can, however, modify the
value of a function parameter.

The function parameters might not be changeable always, for example
when they are qualified with const keywords.

That is indeed true, but extremely irrelevant to the point I was making.
Similarly, one might say "you can't drive a garage, but you can drive a
car", only to be met with the objection "you can't drive a car if it has no
fuel".

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Kenny McCormack]

In article <6J********************@bt.com>,
Richard Heathfield <in*****@invalid.invalidwrote:
....

>That is indeed true, but extremely irrelevant to the point I was making.
Similarly, one might say "you can't drive a garage, but you can drive a
car", only to be met with the objection "you can't drive a car if it has no
fuel".

Ah, but you *can* drive a car if it has no fuel. You just won't get
very far.