Question

I am developing a client-database using MFC and lately I was trying to create a class in order to perform DAO operations (instead of implementing these operations directly at the CDocument class). I named this class as CModel, and CDocument contains it. In order to perform SQL operations using the CModel class, I must have access to the m_session variable - which represents a database access session - and it can be found in the RecordSet class - which represent one table in a database of mine. Here is a piece of code to better illustrate the situation:

#pragma once
#include "MFCApplicationSet.h"

class CModel
{
public:
    CModel(CMFCApplicationSet ApplicationSet);
    ~CModel();
    CMFCApplicationSet * pModelSet;
}

// Model.cpp : implementation file
//

#include "stdafx.h"
#include "MFCApplication.h"
#include "Model.h"
#include "SQLQuery.h" 
#include "MFCApplicationSet.h"

#ifdef _DEBUG
#define new DEBUG_NEW
#endif

CModel::CModel(CMFCApplicationSet ApplicationSet)
{
   pModelSet = &ApplicationSet //not sure if it is right
}

CModel::~CModel()
{
}


// MFCApplicationDoc.h : interface of the CMFCApplicationDoc class
#pragma once
#include "MFCApplicationSet.h"
#include "Model.h"

class CMFCApplicationDoc : public CDocument
{
protected: // create from serialization only
    CMFCApplicationDoc();
    DECLARE_DYNCREATE(CMFCApplicationDoc)
// Attributes
public:
    CMFCApplicationSet m_MFCApplicationSet;
    CModel Model;
}


// MFCApplicationDoc.cpp : implementation of the CMFCApplicationDoc class
//

#include "stdafx.h"
#ifndef SHARED_HANDLERS
#include "MFCApplication.h"
#endif

#include "MFCApplicationSet.h"
#include "MFCApplicationDoc.h"
#include "Model.h"

#ifdef _DEBUG
#define new DEBUG_NEW
#endif

IMPLEMENT_DYNCREATE(CMFCApplicationDoc, CDocument)

BEGIN_MESSAGE_MAP(CMFCApplicationDoc, CDocument)
END_MESSAGE_MAP()

// CMFCApplicationDoc construction/destruction

CMFCApplicationDoc::CMFCApplicationDoc()
{
    //problem in implementing a instruction to call the Model object constructor
}

CMFCApplicationDoc::~CMFCApplicationDoc()
{
}

I've used the debugger to analyse my code flow and I noticed that, from the CMFCApplicationDoc constructor (CDocument), the constructor from each variable declared in the CMFCApplicationDoc.h is initialized. Here's my problem: I've tried to create a CModel constructor in order to the pModelSet pointer automatically reference the variable m_MFCApplicationSet (check the constructor arguments) declared in the Doc class, but I am experiencing some trouble in giving this instruction inside the construction of the Doc class. Is there a specific or maybe an alternative way to do this? (sorry if this task is kind of elementary, but I am still very newbie in C++)

Was it helpful?

Solution

Your constructor:

CModel(CMFCApplicationSet ApplicationSet);

takes object of type CMFCApplicationSet by value, meaning that the copy of passed object is created and this copy is then used within its body. When you do the following:

pModelSet = &ApplicationSet;

you are actually storing the addres of temporary object, which is destructed when execution goes out of the scope of the constructor. If you try to dereference this pointer afterwards, it will produce undefined behavior.

Some might suggest you to pass a pointer, but if you look at your CModel class closely, you will see that it has only one constructor and it takes the PessoaSet object, i.e. the instance of CModel requires the existance of some object of type PessoaSet, i.e. you should keep a reference, not a pointer:

class CModel
{
public:
    CModel(CMFCApplicationSet& ApplicationSet) : modelSet(ApplicationSet) { }
    CMFCApplicationSet&  modelSet;
}

and in the other class that contains instance of CModel:

class CMFCApplicationDoc
{
public:
    CMFCApplicationDoc() :
      Model(m_MFCApplicationSet) { }

    CMFCApplicationSet m_MFCApplicationSet;
    CModel Model;
}

just note that the order, in which members of CMFCApplicationDoc are declared actually matters here, since you want m_MFCApplicationSet to be initialized earlier than Model and the standards (12.6.2 §5) says: "nonstatic data members shall be initialized in the order they were declared in the class definition".

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top