Eclipse class initialisation error

[cryomick]

I created an eclipse project with a single class called "CSlaveController" and a plain C++ source file called "main.cpp". The main function simply creates and initialises an instance of the class.

But when I try to do this, the program terminates at the line where I use "new". The exit code is -1073741571

main.cpp

  #include "CSlaveController.h"

  int main(){
	printf("1");
	CSlaveController* m_oTestSlave;
	printf("3");
	m_oTestSlave = new CSlaveController(); ////Code fails here
//	CDevice* test;
//	test = new CDevice();
	printf("2");
	return 0;
   }

CSlaveController:

   #include "CSlaveController.h"

   CSlaveController::CSlaveController() {
      printf("Hello");
   }

When I debug it opens up the disassembly file. Can anyone help me out here?

[Peter87]

I can't see anything wrong with the code that you have posted. Please post real code if you want help. If the code is too long remove everything that is not relevant but make sure the code can still be compiled and still produces the problem.

[cryomick]

Thank you @Peter87 for the reply. The main function is the same as I posted above. The only difference is that the constructor for the CSlaveController Class creates an object of a CDevice class.

main.cpp

#include "CSlaveController.h"
#include "CDevice.h"

int main(){
	CSlaveController* m_oTestSlave;
	m_oTestSlave = new CSlaveController();
	return 0;
}

CSlaveController:

#include "CSlaveController.h"
#include "CDevice.h"

CSlaveController::CSlaveController() {
	// TODO Auto-generated constructor stub
	CDevice* m_oTestDevice;
	m_oTestDevice = new CDevice();                            //Creation and Initialisation of Device object
}

CSlaveController::~CSlaveController() {
	// TODO Auto-generated destructor stub
}

CDevice:

#include "CDevice.h"

CDevice::CDevice() {
	// TODO Auto-generated constructor stub
	cout<<"Device Created!!!";
}

CDevice::~CDevice() {
	// TODO Auto-generated destructor stub
}

The code really doesn't do anything now. I had initially placed the main function in the CSlaveController class itself, and it worked. It created the CDevice class object, rather than the CSlaveController object. The error happens when I move it to a separate main file.
From the debugging I tried to do, I believe the error is related to the creation of the CDevice class object.

[cryomick]

UPDATE:

The error seems to be in this line
m_oTestDevice = new CDevice(); //Creation and Initialisation of Device object
The debugger doesn't move past this line. Commenting this out fixes the issue. But I have no idea why this is happening.

[Peter87]

So this is the program that gives you the -1073741571 error code? What's the content of CDevice.h and CSlaveController.h? Note that cout/printf are buffered so if you don't see "Hello" or "Device Created" printed it doesn't necessarily mean the object was not created.

[cryomick]

So this is the program that gives you the -1073741571 error code?

I realise it isn't much, but I am getting back into C++ after a long time. So I expected to be trumped by the smallest of errors :D

Note that cout/printf are buffered so if you don't see "Hello" or "Device Created!!!" printed it doesn't necessarily mean the object were not created.

I have tried to do a file write operation as well to check for this. I am convinced that the CDevice class object is not being created.

What's the content of CDevice.h and CSlaveController.h?

The CDevice class contains the declarations for a few functions that haven't been defined yet, but other than that it is all standard.

CDevice:

#ifndef CDEVICE_H_
#define CDEVICE_H_

#include "CSlaveController.h"

class CDevice: public CSlaveController {
public:
	CDevice();
	virtual ~CDevice();
private:
	int fnHWInit();
	int fnHWDeInit();
	int fnStart();
	int fnStop();
	int fnSim();
	int fnAcq();
	int fnStartStopSync();
	int fnHealthStatus();
};

#endif /* CDEVICE_H_ */ 

CSlaveController:

#ifndef CSLAVECONTROLLER_H_
#define CSLAVECONTROLLER_H_

#include <iostream>
#include <ctime>
#include <fstream>
#include <stdio.h>

using namespace std;

class CSlaveController {
public:
	CSlaveController();
	virtual ~CSlaveController();
};

#endif /* CSLAVECONTROLLER_H_ */ 

[Peter87]

I see what's wrong now.

The CSlaveController constructor creates a CDevice, and because CDevice inherits from CSlaveController it will call the CSlaveController constructor which will in turn create a new CDevice which calls the CSlaveController constructor which creates a new CDevice, and so on...

This is an infinite recursion which causes the program to crash when it runs out of stack space.

[cryomick]

The thing is that CDevice class has to inherit CSlaveController and also CSlaveController should create a requisite amount of CDevice objects in its constructor (in this case 1). Is there any way to avoid this recursion?
I genuinely did not know that an object will call the constructor of its parent as well!

[Peter87]

You do realize that inheritance creates an "is-a" relationship?

CDevice is a CSlaveController.

When a CDevice is created it first calls the CSlaveController constructor in order to initialize the CSlaveController part of the CDevice object.

If a CDevice is not a CSlaveController you shouldn't be using inheritance.

[cryomick]

Thank you for that! I have removed the inheritance and that fixed the issue.
But, hypothetically, is there no way for a parent class to create a number of child objects in its constructor?

[Peter87]

It is certainly possible if you have a mechanism for preventing the derived class from creating such objects. One way would be to use another constructor that doesn't create the objects. Another way would be to let a constructor argument decide if the objects should be created.

But all of this sounds a bit like a hack and I suspect that there might be a more elegant solution. Are you sure you're not trying to make the class do too many things? Maybe you could split it into two classes so that the list is owned by an object outside of the class hierarchy.

[cryomick]

My initial problem was solved. I was asking this purely from an academic standpoint. The way you have explained it, it does sound like I would forcing the class to behave in a way that it shouldn't. Thank you!!