Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

What problem is in this pointer copy?

32 views
Skip to first unread message

fl

unread,
May 2, 2017, 5:23:27 AM5/2/17
to
Hi,

I read "C++ Primer" of Stanley B. Lippman etc. In Chapter 13, it talks about
pointer copy. I looks understand the pointer dangling problem related, but
I don't understand his explanation:

"because the value of a pointer
is distinct from the value of the object to which it points."

I run the below code snippet on Windows, MSVC.
ptr1 content: {ptr=0x00affa98(0), val=42}
ptr2 content: {ptr=0x00affa98(0), val=42}

This simple plain design does have problem, but it doesn't show the problem
only after the copy execution.

Could you tell me what the authors say?
"because the value of a pointer
is distinct from the value of the object to which it points."


Thanks,

\\\\\\\\\\\\\\\\\\\\\

// class that has a pointer member that behaves like a plain pointer
class HasPtr {
public:
friend ostream& operator<<(ostream&, const HasPtr&);
// copy of the values we're given
HasPtr(int *p, int i): ptr(p), val(i) { }

// const members to return the value of the indicated data member
int *get_ptr() const { return ptr; }
int get_int() const { return val; }

// nonconst members to change the indicated data member
void set_ptr(int *p) { ptr = p; }
void set_int(int i) { val = i; }

// return or change the value pointed to, so ok for const objects
int get_ptr_val() const { return *ptr; }
void set_ptr_val(int val) const { *ptr = val; }

private:
int *ptr;
int val;
};

/////////////

int obj = 0;

HasPtr ptr1(&obj, 42); // int* member points to obj, val is 42
HasPtr ptr2(ptr1); // int* member points to obj, val is 42
--------------

After the copy, the pointers in ptr1 and ptr2 both address the same object
and the int values in each object are the same. However, the behavior of
these two members appears quite different, because the value of a pointer
is distinct from the value of the object to which it points. After the
copy, the int values are distinct and independent, whereas the pointers are
intertwined.

Paavo Helde

unread,
May 2, 2017, 5:45:03 AM5/2/17
to
The only problem I see is that both pointers inside objects do not point
to their respective inner member 'val', but point to some outside object
'obj' instead. 'ptr' and 'val' have been put inside the same class, but
they appear to be not connected in any way.

As written, there is no dangling pointer yet, but there easily could be
if 'obj' goes out of scope before 'ptr1' or 'ptr2'.

Anyway, I guess you are supposed to change the values of obj and val
(via setint()) and observe what numbers are returned by get_int() and
get_ptr_val().






Juha Nieminen

unread,
May 2, 2017, 9:36:34 AM5/2/17
to
fl <rxj...@gmail.com> wrote:
> "because the value of a pointer
> is distinct from the value of the object to which it points."

I suppose that what the author is trying to say is that when you assign
a pointer to another, they will both point to the same object, rather
than the object itself being copied as well.

This raises a problem of ownership, and dangling pointers.

The most common problematic scenario is if you allocate something
dynamically (with 'new') and then have two pointers pointing to it.
Since C++ doesn't natively offer any automation on how to manage
the lifetime of that dynamically allocated object, you need to either
be extremely careful with how you handle those pointers, or use
exclusively something like std::shared_ptr to handle it. (In general
it's advisable to avoid this situation altogether, if you can.)

But that's only one scenario that causes a problem. You don't even
need dynamic allocation to encounter problems. Suppose you have
something like this:

class C
{
int table[10];
int* tablePtr;

public:
C(): tablePtr(&table[0]) {}
};

That 'tablePtr' is supposed to point to an element of 'table'.
But consider what happens if you do this:

C obj1;
C obj2 = obj1;

Where do you think the tablePtr of obj2 is pointing to?

This becomes especially dangerous if you do seemingly innocuous
things like:

C foo() { return C(); }
0 new messages