logic behind initializing via constructors

[sanctus]

thanks to some people here I know now that if I have a class CmbCalc then the following code

CmbCalc::CmbCalc() :infla(true) 

will initialize infla to be true.
This class is defined in a header file what it implies it is a global class for all .cc files which include this header file, right?

Now the question is when will the constructor be executed?

All this problem arises from a already written monte-carlo simulation code. There is a function called master() which writes to disk and makes the function slave() do the calculations. The slave() always defines an object of type CmbCalc, does this mean the constructor is executed every time the master calls the slave?
This is important because at the of the slave's calculation one has infla=false and the code to work properly needs to start always with infla=true.

Thanks very much for any clarification!

[weaknessforcats]

Constructors are called every time an object is created.

If your slave() function has a CmbCalc as a local variable, then the constructor will be called.

If your slave() function has a CmbCalc as an argument variable, then the constructor will be called.

If your slave() function has a CmbCalc as a reference argument variable, then the constructor will not be called.

[sanctus]

The slave has a definition like:

CmbCalc cmbcalc;
 

So if I understood you right the constructor is called and it solves my doubt (but not the problem since the program still goes in an eternal loop stopping when using 2 Gb of active memory...)

Thanks very much.

[weaknessforcats]

The loop is a separate issue.

Is the slave() calling itself??

If so, this is a recursion and will continue until you crash. Recursive calls need a means of limiting the number of recursions.

[sanctus]

The loop is a separate issue.

Is the slave() calling itself??

If so, this is a recursion and will continue until you crash. Recursive calls need a means of limiting the number of recursions.

No the slave sends the results to the master() (via MPI, don't understand that really) and requests a new task. Then the master sends a new task...there is a do-while "loop" in the master() with the condition being just a boolean.

I'll try to learn to use "advanced gdb" (in the sense using it further than just to see where a program crashes) to find what it keeps calculating...

[weaknessforcats]

It's probably the Message Passing Interface (MPI). There may be many slave() calls still running unless you have forced them to completion.

I would look there.

[sanctus]

Thanks, eventually I figured it out a pointer was not deleted: in the new function I added I called the old pointer to be deleted instead of the new one... and in this in 8 different slaves so obviously there would be no memory left.
Something what I don't understand though is the way in the program it was original deleted, it had a line

delete pointerA;//maybe there is delete[], I don't remember now but that is not a problem
pointerA=0;//this is the problem
 

If one deletes it why also pose =0?

[weaknessforcats]

When you delete a pointer, the memory allocated for it is returned to the free store. At the location where the memory is allopcated, there is a header just in front of that address which contains information bout how big th allocation is. After the delete, this header is overwritten by the delete operator. Should you delete again, the second delete will see this overwritten header and will crash your program.

You protect against a second delete by setting the pointer to zero. Deleting a zero pointer does nothing. delete just returns. Unfortunately, this only works when you are certain that there is only one coppy of the pointer.

That is what the setting of the pointer to zer is about.

You can protect against deletion of memory when there are multiple copies of the pointer in the program by using a handle class object instead of the pointer.

These are called smart, or managed, pointers. This article explains how this works.