question on no-argument constructor

Discussion in 'C++' started by Oliver, Feb 21, 2012.

  1. Oliver

    Oliver Guest

    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
     
    Oliver, Feb 21, 2012
    #1
    1. Advertising

  2. On 21.02.2012 14:26, Oliver wrote:
    > 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
     
    Alf P. Steinbach, Feb 21, 2012
    #2
    1. Advertising

  3. Subject: question on no-argument constructor

    aka "default constructor"

    On Feb 21, 1:32 pm, "Alf P. Steinbach" <alf.p.steinbach
    > wrote:
    > On 21.02.2012 14:26, Oliver wrote:


    > > 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.


    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;
    };


    > > 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.
     
    Nick Keighley, Feb 21, 2012
    #3
  4. "Oliver" wrote in message
    news:18415058.42.1329830819543.JavaMail.geo-discussion-forums@vbne13...
    >
    >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) {};
    }
     
    Fred Zwarts \(KVI\), Feb 21, 2012
    #4
  5. Oliver

    Oliver Guest

    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

















    On Tuesday, February 21, 2012 8:44:55 AM UTC-5, F.Zwarts wrote:
    > "Oliver" wrote in message
    > news:18415058.42.1329830819543.JavaMail.geo-discussion-forums@vbne13...
    > >
    > >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, Feb 21, 2012
    #5
  6. 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.

    On Feb 21, 2:41 pm, Oliver <> wrote:

    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



    > On Tuesday, February 21, 2012 8:44:55 AM UTC-5, F.Zwarts wrote:
    > > "Oliver"  wrote in message
    > >news:18415058.42.1329830819543.JavaMail.geo-discussion-forums@vbne13...

    >
    > > >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) {};
    > > }- Hide quoted text -

    >
    > - Show quoted text -
     
    Nick Keighley, Feb 21, 2012
    #6
  7. Nick Keighley <> wrote:
    > 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.)
     
    Juha Nieminen, Feb 21, 2012
    #7
  8. Oliver

    Jorgen Grahn Guest

    On Tue, 2012-02-21, Oliver wrote:
    >
    > 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

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
     
    Jorgen Grahn, Feb 21, 2012
    #8
  9. Oliver

    Goran Guest

    On Feb 21, 3:41 pm, Oliver <> wrote:
    > 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.
     
    Goran, Feb 22, 2012
    #9
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    2
    Views:
    284
    mlimber
    Sep 1, 2005
  2. Replies:
    0
    Views:
    248
  3. Replies:
    6
    Views:
    518
  4. Generic Usenet Account
    Replies:
    10
    Views:
    2,323
  5. Nosophorus
    Replies:
    6
    Views:
    1,017
    Vidar Hasfjord
    Jan 16, 2009
Loading...

Share This Page