question on no-argument constructor

[Oliver]

hi, all -

I have a newbie question: suppose I have a user-defined class that must take a argument to properly initialize. so I have something like:

class Foo {
explicit Foo(const string &str);
....
}

Another class define Foo as its member:

class Bar {

private:
Foo foo;
}

Now the compiler complains that it can find the candidate constructor. So it seems I must define a no-argument constructor for Foo ... at the risk of the object can exist without being properly initialized? I must have missed something ...

Thanks for your help

Oliver

 

[Alf P. Steinbach]

hi, all -

I have a newbie question: suppose I have a user-defined class that
must take a argument to properly initialize. so I have something like:

class Foo {
explicit Foo(const string&str);
...
}

Another class define Foo as its member:

class Bar {

private:
Foo foo;
}

Now the compiler complains that it can find the candidate constructor.
So it seems I must define a no-argument constructor for Foo ...
Yes.


at the risk of the object can exist without being properly initialized?
No.


I must have missed something ...

Yes, but it's difficult to say what.


Cheers & hth.,

- Alf

 

[Nick Keighley]

Subject: question on no-argument constructor

aka "default constructor"

On 21.02.2012 14:26, Oliver wrote:






Yes.

or some other constructor? Something must call Foo's constructor.

class Bar {
public:
Bar(): foo("hello")
{}

private:
Foo foo;
};


class Bar {
public:
Bar(const std::string& boom): foo(boom)
{}

private:
Foo foo;
};

 

[Fred Zwarts \(KVI\)]

"Oliver" wrote in message

hi, all -

I have a newbie question: suppose I have a user-defined class that must
take a argument to properly initialize. so I have something like:

class Foo {
explicit Foo(const string &str);
...
}

Another class define Foo as its member:

class Bar {

private:
Foo foo;
}

Now the compiler complains that it can find the candidate constructor. So
it seems I must define a no-argument constructor for Foo ... at the risk of
the object can exist without being properly initialized? I must have missed
something ...

Thanks for your help

Oliver

Initialize foo in the constructor of bar, e.g.:

class Bar {

private:
Foo foo;

explicit Bar (const string &str) : foo (str) {};
}

 

[Oliver]

Thanks for all your replies. Using Bar's member initialization list to initialize Foo will work in this case. So I guess what follows is, if Foo's init depends on Bar, and Bar's init depends on Foo, that should be considered a bad design ...

I wonder how to handle this particular design scenario I am dealing with:

class Foo maintain a open file handle; (a piece of shared info)

class Bar (or any number of other classes) contribute to write part of that file pending on the input.

Class Foo co-ordinate the write and call Bar to do the actual work.

In my current design, the class Foo has a member of Bar, but Bar needs to have the file handler that Foo has, that is why I am thinking of passing that in through constructor ... maybe this is not right way. Can someone enlighten me?

Thanks

Oliver

 

[Nick Keighley]

please don't top post. if you are continuing the post you are replying
to the put your reply after it (or dispersed within it). remove
anything you aren't responding to. Often these deleteions are marked
<snip>. I've left your post unedited for top-posting.


class Bar {
public:
Bar(): foo("hello")
{}

private:
Foo foo;
}

Thanks for all your replies. Using Bar's member initialization list to initialize Foo will work in this case.  So I guess what follows is, if Foo's init depends on Bar, and Bar's init depends on Foo, that should be considered a bad design ...

Foo doesn't really depend on Bar. Consider if foo were an int. When
int was designed (late Jurassic) no one knew of your Bar.

[<deity, I hate names like Foo and Bar...]

I wonder how to handle this particular design scenario I am dealing with:

class Foo maintain a open file handle; (a piece of shared info)

class File holds a file handle of some sort (std::ifstream perhaps?)

class Bar (or any number of other classes) contribute to write part of that file pending on the input.

various Writer classes use the File class to write to a file.

Class Foo co-ordinate the write and call Bar to do the actual work.

oops. Lost me who is asking who to do the work? Could we scrap the
Foos and Bars and get some more concret names?

In my current design, the class Foo has a member of Bar, but Bar needs tohave the file handler that Foo has, that is why I am thinking of passing that in through constructor ... maybe this is not right way. Can someone enlighten me?

I need a clearer requirement

 

[Juha Nieminen]

class Bar {
public:
Bar(): foo("hello")
{}

private:
Foo foo;
}

In C++11 you can also do this:

class Bar
{
private:
Foo foo("hello");
};

(which effectively amounts to the same, but is less verbose.)

 

[Jorgen Grahn]

Thanks for all your replies. Using Bar's member initialization list ...

I was going to reply with something helpful here, but you've topposted
(mentioned by someone else) and also not broken your lines - your
posting was hundreds of characters wide. That last thing in
particular is a showstopper for me.

/Jorgen

 

[Goran]

Thanks for all your replies. Using Bar's member initialization list to initialize Foo will work in this case.  So I guess what follows is, if Foo's init depends on Bar, and Bar's init depends on Foo, that should be considered a bad design ...

I wonder how to handle this particular design scenario I am dealing with:

class Foo maintain a open file handle; (a piece of shared info)

class Bar (or any number of other classes) contribute to write part of that file pending on the input.

Does each instance of Bar and other classes operates on one Foo, or
each operates on it's own Foo? If former, then you can pass Foo by
reference to all these instances and take care of the lifetime (Foo
must outlive all instances who hold it by reference). If later, then
Bar and others can also be constructed with a file name and create a
Foo on a per-instance basis.

(In any case, I would err towards former solution, see below).

Class Foo co-ordinate the write and call Bar to do the actual work.

In my current design, the class Foo has a member of Bar, but Bar needs tohave the file handler that Foo has, that is why I am thinking of passing that in through constructor ... maybe this is not right way. Can someone enlighten me?

In my mind, that's too complicated. In what way does Foo co-ordinate
the write? If it's merely "hold the file handle, provide a stream
(handle) to write on", then I would split it in two classes: base that
provides write operations, derived that holds the handle to write on.
Bar would only know of the base class (and hold a reference to it). In
fact, that's what all stream (file) libraries I know do, I am saying
nothing interesting here.

Goran.