int* ptr=10;.......issue.

[Frederick Gotham]

Salt_Peter posted:

If you do understand the limitations

I don't think there's *anything* you can't do with a pointer.

and intricacies of pointers,

Two things to learn:

(1) A pointer stores a memory address.
(2) Pointer arithmetic is based upon the size of the pointed-to type.

There ain't much more to it.

they can certainly be very useful in the hands of a competant
programmer.

Competant programmers are the only ones I pay attention to (unless of
course someone is trying to learn and is asking a question).

I'm not one of those "competant" programmers.

Practise makes perfect.

 

[peter koch]

Salt_Peter posted:



I don't think there's *anything* you can't do with a pointer.

What do you mean? You can't add two pointers for one thing, and
operator overloading is impossible with "only" pointers.
Aprart from that I agree there's a lot you can do with pointers. But
are you always interested in that? (The answer should be "NO").

Two things to learn:

(1) A pointer stores a memory address.
(2) Pointer arithmetic is based upon the size of the pointed-to type.

There ain't much more to it.

Right! Come on.... look at the questions posed here. Loads of them come
from (ab)use of pointers.

Competant programmers are the only ones I pay attention to (unless of
course someone is trying to learn and is asking a question).

And this is exactly the ones you find here (as original posters,
anyway).

[snip]

/Peter (competent)

 

[Philip Potter]

Salt_Peter posted:

I don't think there's *anything* you can't do with a pointer.

Dereference a null pointer.
Dereference a pointer which has been incremented beyond the end of the array
it points to.

Two things to learn:

(1) A pointer stores a memory address.
(2) Pointer arithmetic is based upon the size of the pointed-to type.

There ain't much more to it.

You're right, to an extent. Pointers in themselves are, in the right
situation, useful and simple to use. I think a lot of people's problems with
pointers come from the fact that they are closely linked to dynamic memory
allocation, which is something which is easy to mess up.

Competant programmers are the only ones I pay attention to (unless of
course someone is trying to learn and is asking a question).

Competent programmers don't lay traps for themselves. Pointers are often
difficult to understand, and easy to mess up. Pointers are "evil" (see FAQ
for definition).

Philip

(Consistency is the hobgoblin of a small mind.)

 

[Salt_Peter]

Salt_Peter posted:



I don't think there's *anything* you can't do with a pointer.

Thats the problem.

Two things to learn:

(1) A pointer stores a memory address.
(2) Pointer arithmetic is based upon the size of the pointed-to type.

There ain't much more to it.

Let me correct you,
1) a pointer stores a memory address but not neccessarily an address to
an object. A pointer also cannot extend the lifetime of an object. A
reference cannot be broken, a pointer can.
2) pointer aritmetic is based on whatever pointer-type you've casted it
into as well. And what if the container is not sequential? Iterators
are a much better solution than pointer arithmetic. A pointer is not
bound to the type - its bound to the value, if any.

Competant programmers are the only ones I pay attention to (unless of
course someone is trying to learn and is asking a question).




Practise makes perfect.

It certainly does. The more often an interface uses a pointer instead
of a reference the more often someone out there will find a way to
break that interface. The point here is why design with a pointer and
risk breakage when you can do it with a reference and guarantee
success?

 

[Frederick Gotham]

Salt_Peter posted:

1) a pointer stores a memory address but not neccessarily an address to
an object.

Indeed, it can also store the null pointer value.

A pointer also cannot extend the lifetime of an object.

And neither can a "reference to const". Read the rules for binding a
"reference to const" to an R-value, and all will become clear.

A reference cannot be broken, a pointer can.

Define "broken". Does the following reference become "broken"?

int &i = *new int;

delete &i;

i = 5;

2) pointer aritmetic is based on whatever pointer-type you've casted it
into as well.

Yes... it's relative to the pointed-to type.

And what if the container is not sequential? Iterators
are a much better solution than pointer arithmetic.

Not for simple things. I only resort to fancy features like vector, string,
etc. when things get overly complicated. For simple solutions, pointers are
just fine.

A pointer is not bound to the type - its bound to the value, if any.

I don't understand that statement.

It certainly does. The more often an interface uses a pointer instead
of a reference the more often someone out there will find a way to
break that interface.

As long as we use bleach in our houses in the developed world, there's
going to be the occasional medical emergency whereby a child drank it.

I'm not going to stop using bleach just because it's not safe for two year
olds.

The point here is why design with a pointer and
risk breakage when you can do it with a reference and guarantee
success?

References are preferable in a lot of places. I was *not* advocating the
use of pointers everywhere, but rather I was expressing my own way of doing
things: I use pointers when they're good for getting the job done.

 

[Robert J. Hansen]

When posting to comp.lang.c++, it's wise to assume that your audience is

competant. Competant programmers can use pointers perfectly well.

Competent programmers are rare, and their brains are better spent
solving new problems than tracking down memory leaks and
non-exception-safe code.

Pointers are best avoided. When avoiding them isn't possible, wrap
them in shared_ptr<>s or some other mechanism to make them safer and
easier to manage.