copy constructor

[Charles Herman]

I am using push_back to place a class object into a vector. This class
contains data members that are pointers to a char string. When I use
push_back, I believe a copy of the object is first made, and then deposited
into the vector.

But I want this copy to not mereley copy the pointer to the char string, but
rather, I want to malloc new space, and make a copy of the char string.

The default copy constructor is defined as

MyClass( const MyClass& oldObject ).

At this stage, my method that defines the copy constructor would copy the
char string from oldObject to the new object. With push_back I can't do
this. The only way I can think of to do this, is to make two copies of the
object, one for the purpose of using the above copy constructor, and a
second when it is push_back'd to the vector.

This can be rather expensive. Is there a way I can achieve what I want and
avoid doing duplicat work?

-charles
I might be able to use the following syntax:

push_back(MyClass( oldObject )).

Will this work, and will it avoid making two copies?

 

[Ron Natalie]

But I want this copy to not mereley copy the pointer to the char string, but
rather, I want to malloc new space, and make a copy of the char string.

The default copy constructor is defined as

MyClass( const MyClass& oldObject ). \

First off, do NOT confuse char* with a string. A char* is a pointer to a single
character. Perhaps the easiest way around this is to NOT use char*. This
is C++, use std::string. std::string's constructors, assignment operators, and
destructors handle all this memory management for you.

push_back(MyClass( oldObject )).

What makes you think this would do anything less than
push_back(oldObject);

 

[Rolf Magnus]

I am using push_back to place a class object into a vector. This class
contains data members that are pointers to a char string. When I use
push_back, I believe a copy of the object is first made, and then
deposited into the vector.

But I want this copy to not mereley copy the pointer to the char
string, but rather, I want to malloc new space, and make a copy of the
char string.

The default copy constructor is defined as

MyClass( const MyClass& oldObject ).

At this stage, my method that defines the copy constructor would copy
the char string from oldObject to the new object. With push_back I
can't do this.
Why?

The only way I can think of to do this, is to make two copies of the
object, one for the purpose of using the above copy constructor, and a
second when it is push_back'd to the vector.

Why do you want to copy the object at all before push_back'ing it into
the vector?

This can be rather expensive. Is there a way I can achieve what I want
and avoid doing duplicat work?

I don't understand your question. If you don't want to do an additional
copy, simply don't do it.

I might be able to use the following syntax:

push_back(MyClass( oldObject )).

Will this work, and will it avoid making two copies?

On the contrary, it adds a copy. What makes you believe that this does
one copy less than a simple:

push_back(oldObject);

?

 

[Charles Herman]

First off, do NOT confuse char* with a string. A char* is a pointer to a
single
character. Perhaps the easiest way around this is to NOT use char*.
This
is C++, use std::string. std::string's constructors, assignment
operators, and destructors handle all this memory management for you.
What makes you think this would do anything less than
push_back(oldObject);

The problem with std::string, is that it is too slow; accesing an element of
a string takes anywhere from 2 to 4 times as long as acccessing an element
from a char* (this depeneds on which compiler one is using, I'm using g++
on Solaris, and it takes twice as long).

Also sometimes I want to make a copy of the string, and other times I want
to merely point to the original, when creating a copy of the object. In
either case, when I use char*, I have a pointer.

This is the reason for this question?

-charles

 

[lilburne]

The problem with std::string, is that it is too slow; accesing an element of
a string takes anywhere from 2 to 4 times as long as acccessing an element
from a char* (this depeneds on which compiler one is using, I'm using g++
on Solaris, and it takes twice as long).

So how many strings does your application need to process
per second and is the bottleneck really string processing?

Also sometimes I want to make a copy of the string, and other times I want
to merely point to the original, when creating a copy of the object. In
either case, when I use char*, I have a pointer.

So use a pointer to a string.

 

[Paul]

The problem with std::string, is that it is too slow; accesing an element of
a string takes anywhere from 2 to 4 times as long as acccessing an element
from a char* (this depeneds on which compiler one is using, I'm using g++
on Solaris, and it takes twice as long).

Then use std::vector<char> instead of char*. std::vector is copyable and
assignable without you having to manage the memory. Also, the vector's
storage is contiguous, making it viable as a replacement for an array.

Paul

 

[Ron Natalie]

a string takes anywhere from 2 to 4 times as long as acccessing an element
from a char* (this depeneds on which compiler one is using, I'm using g++
on Solaris, and it takes twice as long).

I just tested G++ on solaris and you are wrong. The difference in time is
negligable. Are you sure you are using an optimization setting that supports
inlining? Most of the gripes about the standard library performance come from
people who bench mark the things with inlining supressed so that the overloaded
operators incur function call overhead.

Also sometimes I want to make a copy of the string, and other times I want
to merely point to the original, when creating a copy of the object. In
either case, when I use char*, I have a pointer.

Yes, but you get messed up if you don't manage making the copy in contexts
where you need a copy. And once you go to the effort of managing the copy
you've spent as much effort as switching to vector or string, and you cause
maintainablility issues.