vector<Foo> how to force default constructor

[lchian]

Hi,

I have a vector of class Foo.

When I do a push_back(), I expect stl to call the default constructor
I wrote for Foo. But instead, stl makes up its own default that is
initialized with garbage.

Is there a way to force stl to use MY default constructor?

Thanks

[atgraham]

We need to see some code.

[lchian]

Sorry, I typed the whole thing then the network went down.

class Foo
{
public:
vector<FooBar> vec;
.......
}

class FooBar
{
public:
FooBar(0;
FooBar(const Foobar &f){*this=f;}
Foobar &operator=(const FooBar &f);
~FooBar();
.......
}

int main()
{
Foo me;

FooBar b;
......

me.vec.push_back(b);
}

[atgraham]

I don't see anything wrong here. The FooBar() constructor is called
automatically for "b" before push_back() is called. The FooBar copy
constructor is unnecessary; that's the default behavior.

Most likely the bug is somewhere else in your code.

[lchian]

It is related to push_back.

As I understand it, STL always insert a copy of the object. in this
case, a copy of "b".

First, it calls the (wrong) default constructor, then use the
assignment operator to assign the data inside "b" to the newly created
object, then put it into "vec".

[atgraham]

That's right; a copy of "b" will be inserted into the vector. However,
I can't see your implementation of the FooBar() constructor. The bug
could be there. Your implementation of the copy constructor uses the
assignment operator. But I can't see your implementation of the
assignment operator either, so the bug could be there as well.
Nonetheless, The fact that you've attempted to define your own copy and
assignment constructor is curious. If you want it to exhibit the
default behavior, then don't define them at all. Otherwise, the bug is
probably there.

[BobR]

lc****@yahoo.com wrote in message

class FooBar{
public:
FooBar(0;
FooBar(); // This should help
FooBar(const Foobar &f){*this=f;}
Foobar &operator=(const FooBar &f);
~FooBar();
.......
}

--
Bob R
POVrookie

[lchian]

There was a typo: it should be FooBar(), not FooBar(0, fogot the shift
key.

Anyway, I put break point in the default constructor and found it was
never called.

[Michiel.Salters]

lc****@yahoo.com wrote:

It is related to push_back.

As I understand it, STL always insert a copy of the object. in this
case, a copy of "b".
True, that is what logically happens.
First, it calls the (wrong) default constructor, then use the
assignment operator to assign the data inside "b" to the newly created
object, then put it into "vec".

That is apparently what your implementation does. However, part of the
vector<T> specification is that T must have proper object semantics.
Apparently, your FooBar doesn't, and thus vector<FooBar> doesn't work.

That said, I'm not 100% sure if push_back officially requires the
default ctor.
Some vector members do, some don't, and I'd have to look up the exact
rules. Personally, I just stick to "int semantics".

HTH,
Michiel Salters

[jollygoodfellow]

"Apparently, your FooBar doesn't, and thus vector<FooBar> doesn't
work."

Its a typo, like the man said.

Lets get on with the answers.

[Andrew Koenig]

<lc****@yahoo.com> wrote in message
news:11**********************@g14g2000cwa.googlegr oups.com...

class FooBar
{
public:
FooBar(0;
This line shouldn't compile. I'm assuming you meant FooBar();
FooBar(const Foobar &f){*this=f;}
Foobar &operator=(const FooBar &f);
~FooBar();
.......
}

int main()
{
Foo me;

FooBar b;
......

me.vec.push_back(b);
}

This should do the following:

Call the FooBar default constructor to initialize b

Construct a new last element for me.vec by copying b into it.

So if you think that something else is happening, we need to see what the
default constructor for FooBar is doing, and also what your evidence is that
your program is not doing the right thing.

[Andrew Koenig]

<lc****@yahoo.com> wrote in message
news:11*********************@g49g2000cwa.googlegro ups.com...

Anyway, I put break point in the default constructor and found it was
never called.

Please post a complete program that shows the problem without the need to
set breakpoints.

[Ron Natalie]

lc****@yahoo.com wrote:

Sorry, I typed the whole thing then the network went down.

class Foo
{
public:
vector<FooBar> vec;
.......
}

class FooBar
{
public:
FooBar(0;
FooBar(const Foobar &f){*this=f;}

This copy constructor is highly suspect. You do know that
constructors are mutually exclusive? Only one ever runs
for an object. You assign into an uninitaizized *this here.

[Ron Natalie]

lc****@yahoo.com wrote:

First, it calls the (wrong) default constructor, then use the
assignment operator to assign the data inside "b" to the newly created
object, then put it into "vec".

That's how vectors work. Your objects are free to be copied either
by the assignment operator or the copy constructor at various times
in the vector. The object MUST work in light of that.

A default constructor is not necessary. The few places where a
non-copy-initialized object is used the call has an additional
argument which is the "prototype" object to copy (it's just defaulted
to a default constructed object).

Your use of the term "wrong" with "default constructor" is confusing.
There is only one default constructor. If you have more than one,
your program is ill-formed.

[Mirek Fidler]

lc****@yahoo.com wrote:

Hi,

I have a vector of class Foo.

When I do a push_back(), I expect stl to call the default constructor
I wrote for Foo. But instead, stl makes up its own default that is
initialized with garbage.

Actually, std::vector never calls the default constructor for T during
push_back (nor any other operation AFAIK), just the copy constructor.

Mirek

[Mirek Fidler]

>>First, it calls the (wrong) default constructor, then use the

assignment operator to assign the data inside "b" to the newly created
object, then put it into "vec".

That is apparently what your implementation does. However, part of the
vector<T> specification is that T must have proper object semantics.
Apparently, your FooBar doesn't, and thus vector<FooBar> doesn't work.

That said, I'm not 100% sure if push_back officially requires the
default ctor.
Some vector members do, some don't, and I'd have to look up the exact

AFAIK, vector does not require default constructor. The only place where
it is required is for some default arguments.

Mirek

[Mirek Fidler]

> First, it calls the (wrong) default constructor, then use the

assignment operator to assign the data inside "b" to the newly created
object, then put it into "vec".

Incorrect. It just copy-constructs element into its target place (usual
implementation uses placement new). Default constructor is never called
(it is more optimal this way).

Mirek

[Earl Purple]

Ron Natalie wrote:

[note: typos corrected]

class FooBar
{
public:
FooBar();
FooBar(const FooBar &f){*this=f;}

This copy constructor is highly suspect. You do know that
constructors are mutually exclusive? Only one ever runs
for an object. You assign into an uninitaizized *this here.

Actually this copy-constructor is valid. All the elements in "this"
have been initialised by this point.

Usually it is better though to implement operator= in terms of
copy-construction, not the other way round. That way you are safer if
an exception is thrown somewhere.

[Luke Meyers]

lc****@yahoo.com wrote:

FooBar(const Foobar &f){*this=f;}

Implement operator= in terms of the copy ctor, not the other way
around. The idiom used by Herb Sutter in Exceptional C++ item 13 (also
available as a GotW -- it's "Writing Exception-Safe Code, Part 6") is
just right. It goes like this:

Foo & operator=(Foo const& that) {
Foo temp(that); // Construct a temporary -- this is the only line
that can throw.
swap(temp); // Implement a no-throw swap and use it here
return *this;
}

I like the following terse variant, which takes advantage of
pass-by-value to construct the temporary:

Foo & operator=(Foo that) {
swap(that);
return *this;
}

Just to get a little crazy, if swap() returned *this rather than void,
you could make it even more terse:

Foo & operator=(Foo that) {
return swap(that);
}

But that's probably going overboard, and doesn't line up with
std::swap.

Luke