Order of Initialization of constructors using member initialization lists in MFC

Question

4.00/5 (2 votes)

See more:

See more: MFC Hi,

In my Dialog based MFC application, I have the below error w.r.t Constructor, even though multiple changes made in order, and types of params, the error w.r.t constructor still exists,

//Dialog.h
CDlgMac : public CDialog
{
// Construction
public:
//  CDlgMac (CMac*,CWrkShp*,CWnd* pParent = NULL);   // Existing Standard(Signature 1) constructor -> Scenario-I sucessfully builds with no errors.
CDlgMac (CMac*,CWrkShp*,CPtrList& ,CJoe&,CWnd* pParent = NULL); //Signature 2 on including Class Job and Pointer in Constructor the error is depicted.

Seems this is typical handling for constructors, I think I am missing some where in member initialization lists.Two new data members get added here below

CJoe& m_Opt;
CPtrList& m_Obj;

After above inclusion, the same constructor definition are as under,
In Dialog.cpp

//Earlier Existing Constructor definition w.r.t Dialog.h file,(signature 1)

CDlgMac ::CDlgMac (CMac* pMac,CWrkshp* pWkshp,CWnd* pParent /*=NULL*/)
 : CDialog(CDlgMac ::IDD, pParent), m_pMac(pMac),m_pWorkShop(pWrkShp)
{
//{{AFX_DATA_INIT(CDlgMac )
// NOTE: the ClassWizard will add member initialization here
 //}}AFX_DATA_INIT
}

modified constructor definition as below,

CDlgMac::CDlgMac(CMac* pMac,CWrkShp* pWrkShp,CPtrList& ObjectLst,CJoe& OptPage2 ,CWnd* pParent /*=NULL*/)
    : CDialog(CDlgMac::IDD, pParent), m_pMac(pMac),m_pWrkShp(pWrkShp),m_Obj(ObjectLst),m_Opt(OptPage2)
{
    //{{AFX_DATA_INIT(CDlgMac)
        // NOTE: the ClassWizard will add member initialization here
      //}}AFX_DATA_INIT
}....
....

In OtherFile Job.cpp

I invoke the following code,

...
...
CDlgMac dlg(pMac,m_pParent->GetWork(),NULL); ----> Error shown in this line

On build, I get the following errors,

1>error C2664: 'CDlgMac::CDlgMac(CMac *,CWrkShp *,CPtrList &,CJoe &,CWnd *)' : cannot convert parameter 3 from 'int' to 'CPtrList &'

OR

2>d:\v-olp\Job.cpp(1906) : error C2668: 'CDlgMac::CDlgMac' : ambiguous call to overloaded function

Basically, my target is to initialize all the variables/data members using member initialization lists, using pointer and class(reference).

Any help in resolving the above would be much appreciable.,
I am using MFC 9.0v. using VS2008 Feature pack.

With Regards,
VishalK

Posted 29-Jul-12 21:45pm

Vishalk_92

Updated 29-Jul-12 22:13pm

nv3

v2

Add a Solution

Comments

pasztorpisti 30-Jul-12 15:34pm

As others pointed out a reference is a pointer that can never be NULL and can never be uninitialized. The implementation of the reference is actually a pointer but it acts as a value, as the object it points to, its often called an "alias". References must be initialized immediately where they are declared/created - either with an assignment where you declare them or with a ctor intializer list if the ref is a member variable of a class. A serious desing flaw of references is that their lifetime might be longer than the actual object it points to - if this happens its a programming error and its easy to create such a situation unfortunately. In that case the reference points to an alread deleted object.

3 solutions

Solution 3

Also notice that you must respect the order of initialisaton the same way as you declare the members :
since :

C#

CJoe& m_Opt;
CPtrList& m_Obj;

following is not correct either :

C#

CDlgMac::CDlgMac(CMac* pMac,CWrkShp* pWrkShp,CPtrList& ObjectLst,CJoe& OptPage2 ,CWnd* pParent /*=NULL*/)
    : CDialog(CDlgMac::IDD, pParent), m_pMac(pMac),m_pWrkShp(pWrkShp),m_Obj(ObjectLst),m_Opt(OptPage2)
{
    //{{AFX_DATA_INIT(CDlgMac)
        // NOTE: the ClassWizard will add member initialization here
      //}}AFX_DATA_INIT
}....
....

because m_Opt should come before m_Obj.

Posted 30-Jul-12 11:29am

Philip Stuyck

Comments

Richard MacCutchan 31-Jul-12 3:31am

Not true, see http://msdn.microsoft.com/en-us/library/f1h35k32.aspx.

Philip Stuyck 31-Jul-12 4:22am

Checked this in visual studio and apparently this no longer is an issue.
Don't know what the latest version of gnu would do but I have had compiler warnings about this and as such I keep the order of initialisation consistent.

Richard MacCutchan 31-Jul-12 4:59am

I have used MS, GNU and Sun C++ compilers, and never seen this problem.

Philip Stuyck 31-Jul-12 5:41am

I believe you Richard, compilers are under contant evolution it is possible that in the projects I have been working in, the compilers are a bit old. So perhaps this used to be a warning that they removed in recent compilers. I am quite sure I came across warnings like this during developments. It was a warning, and compiler told me then that he would reorder himself in the right order. But since we are not allowed to deliver code with warnings, ...
Nevertheless since the compiler can solve it, why issue the warning. So I think it is better not to have the warning in this case.
Thanks for your comment and correcting me Richard.

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

nv3 · Accepted Answer · 2012-07-29T22:19:00

Well, the error message seems clear: The third parameter is supposed to be a reference to CPtrList and you passed NULL. A reference can never be NULL; it's not like a pointer. Hence, the compiler guesses that NULL (defined is 0) is an integer and that cannot be converted to a reference.

If your want the third parameter to be optional, define it as a pointer and not a reference and then you can give this parameter a default value of NULL. That will work.

Richard MacCutchan · Accepted Answer · 2012-07-29T22:31:00

Solution 2

This has already been explained to you in your previous question[^]. If you are going to allow a parameter to be NULL then it cannot be a reference. Given what you are trying to do it would be much more sensible to use pointers for all parameters rather than mixing them as you are trying to do.

Posted 29-Jul-12 22:31pm

Richard MacCutchan

Comments

pasztorpisti 30-Jul-12 16:20pm

+5, Mixing refs and pointers can be a nightmare! Even if a system uses refs for a given type it often happens that somewhere else a pointer needed...
But in general: Can it be NULL? Can it be uninitialized? Does it have to change in its lifespan? These are the questions to answer before opting for references.

Richard MacCutchan 31-Jul-12 3:27am

Thanks, and very true comments. I do wonder where some of our questioners get their training from.

pasztorpisti 31-Jul-12 6:24am

I guess: from knowhere. Teachers usually expect their students to learn this stuff by reading thick books, but even if they dive into the books they don't have the time to put their knowledge into practice because of other useless courses. Without practice programming is just dry theory. The best to learn is by practice, enjoying the stuff without time constraints, even if you don't produce anything useful. If someone starts coding at the university then he is in trouble. It unlikely that he becomes a programmer becase all he reminds is the though exams. I know only one coder who learnt the art during his university years.

Richard MacCutchan 31-Jul-12 6:40am

Totally agree, all the great programmers I have ever worked with were largely self-taught, and spent much of their time learning and practising.

Order of Initialization of constructors using member initialization lists in MFC

3 solutions

Solution 1

Solution 2

Solution 3

Add your solution here

Preview 0

Existing Members

...or Join us