Derived member variables in initializer lists

This is a discussion on Derived member variables in initializer lists within the C++ Programming forums, part of the General Programming Boards category; Code: class A { public: int nData; }; class B : public A { public: B():nData(0) {} //<----Causes error ~B() ...

  1. #1
    mustang benny bennyandthejets's Avatar
    Join Date
    Jul 2002
    Posts
    1,401

    Derived member variables in initializer lists

    Code:
    class A
    {
    public:
          int nData;
    };
    
    class B : public A
    {
    public:
          B():nData(0) {} //<----Causes error
          ~B() {}
    };
    The marked line causes this error:
    error C2614: 'B' : illegal member initialization: 'nData' is not a base or member
    Is there any way to initialize derived variables in a list like the way I have tried?
    benforbes@optusnet.com.au
    Microsoft Visual Studio .NET 2003 Enterprise Architect
    Windows XP Pro

    Code Tags
    Programming FAQ
    Tutorials

  2. #2
    Registered User
    Join Date
    Dec 2001
    Posts
    88
    You can't initialize members of a base class in the constructor of the derived class.

    Members are initialized in the constructor: nData is initialized in A() (default ctor)

    So you cannot initialize nData in B
    You need to call an appropriate constructor of A in B to initialize nData.

    BTW:
    public or protected member variables are harmful - do not use them unless you really really need to.
    Hope you don't mind my bad english, I'm Austrian!

  3. #3
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    I don't see any problem in protected member variables.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  4. #4
    Cat
    Cat is offline
    Registered User
    Join Date
    May 2003
    Posts
    1,571
    Protected member variables are as bad as public. Your derived classes should access the base object through a protected interface just as non-derived classes access the base object through the public interface.

    It should be possible to completely reinvent the implementation of a base class, while keeping the same interface, and not have to do ANYTHING besides replace the base class source and recompile.

    You essentially want as little coupling between classes as you can; this minimizes the impact of an implementation change.

    The ONLY reason to use them is if a code profiler tells you that accessor functions are a serious problem from an efficiency standpoint. They *always* negatively affect coupling, so only if there is a necessary performance gain should you make the tradeoff.
    Last edited by Cat; 11-24-2003 at 03:05 PM.
    You ever try a pink golf ball, Wally? Why, the wind shear on a pink ball alone can take the head clean off a 90 pound midget at 300 yards.

  5. #5
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    Got your point. But if I was developing a base class and a few derived classes at the same time (to be treated as one unit), I'd probably still have some protected member variables.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  6. #6
    Cat
    Cat is offline
    Registered User
    Join Date
    May 2003
    Posts
    1,571
    You could... I still would avoid that; it's typically unnecessary if you write your classes well. And in the cases you need it, I typically just inline an accessor method -- speed and low coupling.
    You ever try a pink golf ball, Wally? Why, the wind shear on a pink ball alone can take the head clean off a 90 pound midget at 300 yards.

  7. #7
    mustang benny bennyandthejets's Avatar
    Join Date
    Jul 2002
    Posts
    1,401
    Your derived classes should access the base object through a protected interface just as non-derived classes access the base object through the public interface.
    Could you show an example of this?
    benforbes@optusnet.com.au
    Microsoft Visual Studio .NET 2003 Enterprise Architect
    Windows XP Pro

    Code Tags
    Programming FAQ
    Tutorials

  8. #8
    lyx
    lyx is offline
    Amateur
    Join Date
    Sep 2003
    Posts
    228
    I would do something like that:
    Code:
    class A {
    public:
        A(int n = 0) : n(n) {}
        ~A() {}
    
        int GetN() { return n; }
        void SetN(int n) { this->n = n; }
    
    private:
        int n;
    };
    
    class B : public A {
    public:
        B() : A(0) {}
        ~B() {}
    };
    
    // A protected interface would have been
    class A {
    public:
        A(int n = 0) : n(n), m(0) {}
        ~A() {}
    
        // Accessors, n is publicly accessible
        int GetN() { return n; }
        void SetN(int n) { this->n = n; }
    
    protected:
        // You can construct an object with an initialized m member in your derived class
        A(int n = 0, int m = 0) : n(n), m(m) {}
    
        // Accessors, m is accessible by the derived classes
        int GetM() { return m; }
        void SetM(int m) { this->m = m; }
    
    private:
        int n;
        int m;
    };
    
    class B : public A {
    public:
        B(int m) : A(0, m) {}
        ~B() {}
    };

  9. #9
    mustang benny bennyandthejets's Avatar
    Join Date
    Jul 2002
    Posts
    1,401
    How could this be applied to an actual problem?
    benforbes@optusnet.com.au
    Microsoft Visual Studio .NET 2003 Enterprise Architect
    Windows XP Pro

    Code Tags
    Programming FAQ
    Tutorials

  10. #10
    Cat
    Cat is offline
    Registered User
    Join Date
    May 2003
    Posts
    1,571
    One example is MFC. You can derive window classes from CWnd/CDialog/etc., and you access the base through its interface. This means you, as the programmer, need never be concerned with implementation.

    In general, it is always better to make the variable private; it minimizes coupling, and coupling is a bad thing.
    You ever try a pink golf ball, Wally? Why, the wind shear on a pink ball alone can take the head clean off a 90 pound midget at 300 yards.

  11. #11
    mustang benny bennyandthejets's Avatar
    Join Date
    Jul 2002
    Posts
    1,401
    Ok, I'll keep that in mind. So, in summary, I should call the base constructor to initialize my base class variable?

    Code:
    class A
    {
    public:
         int nValue;
    
         A(int nValue_=0):nValue(nValue_) {}
         ~A() {}
    };
    
    class B : public A
    {
    public:
         B(int nValue_=1):A(nValue_) {}
         ~B() {}
    };
    benforbes@optusnet.com.au
    Microsoft Visual Studio .NET 2003 Enterprise Architect
    Windows XP Pro

    Code Tags
    Programming FAQ
    Tutorials

  12. #12
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    Actually MFC is a very bad example as nearly everything there is public...
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  13. #13
    Cat
    Cat is offline
    Registered User
    Join Date
    May 2003
    Posts
    1,571
    Originally posted by CornedBee
    Actually MFC is a very bad example as nearly everything there is public...
    In CWnd, the only public variable is m_hWnd -- which SHOULD be private (it even has an accessor function), but isn't.
    You ever try a pink golf ball, Wally? Why, the wind shear on a pink ball alone can take the head clean off a 90 pound midget at 300 yards.

  14. #14
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    I count 3 public and about 8 protected members in CWnd, not including the stuff inherited from CCmdTarget (another 3 public at least).
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Replies: 8
    Last Post: 12-02-2008, 11:45 AM
  2. Can you check what is wrong with this code
    By Ron in forum C++ Programming
    Replies: 4
    Last Post: 08-01-2008, 10:59 PM
  3. Cleaning variables for a CGI app (as a derived class?)
    By drrngrvy in forum C++ Programming
    Replies: 1
    Last Post: 02-01-2006, 11:34 AM
  4. Please Help - Problem with Compilers
    By toonlover in forum C++ Programming
    Replies: 5
    Last Post: 07-23-2005, 10:03 AM
  5. derived class member function pointer
    By btq in forum C++ Programming
    Replies: 2
    Last Post: 10-20-2002, 12:41 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21