when can pass by value be dangerous?

[ceo]

Hi there,

I'm reffering to a text that says following:

"To summarize: When a copy of an object is generated because it passed
to a function, the object's constructor function is not called.
However, when the copy of the object inside the function is destroyed,
its destructor is called.

By default, when a copy of an object is made, a bitwise copy occurs.
This means that the new object is an exact duplicate of the original.
The fact that an exact copy is made can, at time, be a source of
trouble. Even though objects are passed to functions by means of the
normal call-by-value parameter passing mechanism, which, in theory,
protects and insulates the calling argument. For example, if an object
used as an argument allocates memory and frees that memory when it is
destroyed, then its local copy inside the function will free the same
memory when its destructor is called. This will leave the original
object damaged and effectively useless."

Could someone give me an example that will damage the original object?

Thanks,
Ceo

 

[Sebastian Redl]

Hi there,


Could someone give me an example that will damage the original object?

Thanks,
Ceo

It's dangerous when the class you're passing is poorly written. E.g. a
primitive string class:

class stupid_string
{
char *data;
public:
stupid_string(const char *str) {
size_t l = strlen(str);
data = new char[l+1];
strcpy(data, str);
}
~stupid_string() {
delete[] data;
}

// Functions that actually make the class useful.
};

This class, when copied (as happens with pass-by-value), will not behave
correctly. Specifically, the new instance will refer to the same memory
with data. Thus, when the copy gets destructed, it will delete that memory
and the old instance refers to invalid memory.

The problem here is not pass-by-value, though. The problem is the lack of a
copy constructor.

stupid_string(const stupid_string &o) {
size_t l = strlen(o.data);
data = new char[l+1];
strcpy(data, o.data);
}

This way, the new instance has its own memory to mess with.


If it is not possible to give a class proper copy semantics, then you should
make it _impossible_ to copy it, by making the copy constructor and
assignment operator private and not giving them implementations:

class noncopyable
{
private:
noncopyable(const noncopyable &o);
noncopyable &operator =(const noncopyable &o);
};

Another method is to derive from boost::noncopyable, which accomplishes the
same thing, but in a way that makes it very clear what the code does.

class my_noncopyable : public boost::noncopyable
{
};

http://www.boost.org/

 

[Howard]

Hi there,

I'm reffering to a text that says following:

"To summarize: When a copy of an object is generated because it passed
to a function, the object's constructor function is not called.
However, when the copy of the object inside the function is destroyed,
its destructor is called.

By default, when a copy of an object is made, a bitwise copy occurs.
This means that the new object is an exact duplicate of the original.
The fact that an exact copy is made can, at time, be a source of
trouble. Even though objects are passed to functions by means of the
normal call-by-value parameter passing mechanism, which, in theory,
protects and insulates the calling argument. For example, if an object
used as an argument allocates memory and frees that memory when it is
destroyed, then its local copy inside the function will free the same
memory when its destructor is called. This will leave the original
object damaged and effectively useless."

Could someone give me an example that will damage the original object?

Thanks,
Ceo

Suppose the object has a pointer inside it to another, dynamically allocated
sub-object. What happens then? When the object is passed by value and gets
copied, its internal pointer simply gets copied. But now, both objects have
pointers to the SAME sub-object instead of to separate copies of that
sub-object.

This is exactly what the copy constructor is for! If your object contains
pointers to dynamic memory, then you're likely going to need a copy
constructor (as well as an assignment operator and a destructor), because
the default (compiler-generated) ones will not suffice. (Google for the
"Rule of Three".)

-Howard

 

[Andrey Tarasevich]

...
I'm reffering to a text that says following:

"To summarize: When a copy of an object is generated because it passed
to a function, the object's constructor function is not called.
However, when the copy of the object inside the function is destroyed,
its destructor is called.

Out of context, the above makes no sense. This text must be referring to
some concrete class. Without the context, once again, it makes no sense.

By default, when a copy of an object is made, a bitwise copy occurs.

Same problem.

This means that the new object is an exact duplicate of the original.
The fact that an exact copy is made can, at time, be a source of
trouble. Even though objects are passed to functions by means of the
normal call-by-value parameter passing mechanism, which, in theory,
protects and insulates the calling argument. For example, if an object
used as an argument allocates memory and frees that memory when it is
destroyed, then its local copy inside the function will free the same
memory when its destructor is called. This will leave the original
object damaged and effectively useless."

Could someone give me an example that will damage the original object?
...

It seems to refer to the typical situation when a shallow copy is made
where a deep copy is really needed:

class A {
int* p;
public:
A() : p(new int[10]) {}
~A() { delete[] p; }
};

void foo(A x) {
/* Here 'x' is a shallow copy of the original 'a' in 'main', i.e.
'x.p' points to the same memory as 'a.p' */

...

/* The function is about to end. Destructor 'A::~A' will now
be called for object 'x'. The destructor will deallocate
memory pointed to by 'x.p' (and 'a.p') */
}

int main()
{
A a;
foo(a);
/* At this point object 'a' is broken. The destructor, called
at the end of 'foo', deallocated memory used to be pointed to
by 'a.p' */
}

 

[Rolf Magnus]

Hi there,

I'm reffering to a text that says following:

"To summarize: When a copy of an object is generated because it passed
to a function, the object's constructor function is not called.

That is nonsense. The copy constructor is called. And a constructor is not a
function, since it doesn't return anything (not even void). Note that for
each object of class type, a constructor and the destructor both are always
called exactly once.

However, when the copy of the object inside the function is destroyed,
its destructor is called.

That's right.

By default, when a copy of an object is made, a bitwise copy occurs.
This means that the new object is an exact duplicate of the original.

Again, nonsense. If it is of class type, the copy constructor gets called.
If no user-defined copy-constructor exists, a compiler-generated one will
do a member-wise copy, which again means that for each member of class
type, the copy constructor gets called. Only POD-types are copied bitwise.

The fact that an exact copy is made can, at time, be a source of
trouble. Even though objects are passed to functions by means of the
normal call-by-value parameter passing mechanism, which, in theory,
protects and insulates the calling argument. For example, if an object
used as an argument allocates memory and frees that memory when it is
destroyed, then its local copy inside the function will free the same
memory when its destructor is called. This will leave the original
object damaged and effectively useless."

If that happens, that class has a bug and needs fixing. It needs to adjusted
to satisfy the Rule of Three (tm), which says that if your class needs one
of a copy constructor, assignment operator or destructor, it almost
certainly needs all three of them.

PS: If that text is from a book, burn it! If it is in digital form, drill a
hole into the disk that contains it!

 

[Old Wolf]

I'm reffering to a text that says following:

"To summarize: When a copy of an object is generated because it passed
to a function, the object's constructor function is not called.
However, when the copy of the object inside the function is destroyed,
its destructor is called.

By default, when a copy of an object is made, a bitwise copy occurs.
This means that the new object is an exact duplicate of the original.

I think you have been reading too much BullSchildt.

 

[DHOLLINGSWORTH2]

the destructor, is not fualty for accessing, shared, and static resources.

I'm not sure if he's full of SH___.
but create an object with a static variable to keep track of how many
objects are created.

pass one object into a function.
and when it returns, if he's right, then the static count will have a) Not
been incremented during the create, and b) decremented during the function
exit.
Droping the count to zero, when we know it is one.

This would certainly prove one way or the other. And just who is full of
SH__. and Who just doesn't Give a SH__.


dan

 

[msalters]

I'm not sure if he's full of SH___.
but create an object with a static variable to keep track of how many

objects are created.

pass one object into a function.
and when it returns, if he's right, then the static count will have a) Not
been incremented during the create, and b) decremented during the function
exit.
Droping the count to zero, when we know it is one.

If you make sure that every constructor changes this variable, you're
right. However, how doy you force the compiler-generated default copy
ctor to change it? After all, the compiler-generated does nothing more
than copying each member. So, your count ends up counting the number
of calls to compiler-generated ctors.

This would certainly prove one way or the other. And just who is full of
SH__. and Who just doesn't Give a SH__.

Actually, it will prove nothing if you don't understand
compiler-generated
constructors.

Regards,
Michiel Salters

 

[DHOLLINGSWORTH2]

Actually, it will prove nothing if you don't understand
compiler-generated
constructors.

That was the mans point right?

He said, it does not call your constructor. But it does call your
destructor.

I dont need to know a thing about compiler-generated whosits to know when my
code has ran.

My method proves it right or wrong.

I will elaborate for you,

My method either Proves him to be correct, or my method will prove him to be
wrong. Either way My method proves it.

If he's wrong then there is no danger in passing emmediate, as described by
the man.

 

[Rolf Magnus]

That was the mans point right?

I don't think so.

He said, it does not call your constructor. But it does call your
destructor.

The quoted text said: "the object's constructor function is not called". But
that is clearly wrong. It is called. If you define a copy constructor, it
is called. If you don't, the compiler generates one that is called instead.
But whatever you do, the copy constructor is called.

I dont need to know a thing about compiler-generated whosits to know when
my code has ran.

Well, you do need to know that the compiler-generated one will not do what
you want, which means you have to know that you need to write your own one.

My method proves it right or wrong.

I will elaborate for you,

My method either Proves him to be correct, or my method will prove him to
be
wrong. Either way My method proves it.

If he's wrong then there is no danger in passing emmediate, as described
by the man.

Right. If you write the class correctly, it will prove him wrong.