C++ syntax; Instantiating a class with parameters; constructor run order

Is there a way to do this without creating the first ClassB instance which is later thrown away?

BTW, some more reading and info about initializer lists:

http://www.cprogramming.com/tutorial/initialization-lists-c++.html ("Understanding Initialization Lists in C++")
http://www.efnetcpp.org/wiki/Constructor_Initializer ("Constructor Initializer")

OK I have a slightly more complicated version. Instead of initializing an integer, I would like ClassA to create and save an instance of ClassC, and then create and save an instance of ClassB passing the instance of ClassC as the parameter.

File ClassA.h

#pragma once
#include "ClassB.h"
#include "ClassC.h"

class ClassA
{
public:
  ClassA(void);
  ~ClassA(void);
private:
  ClassB myClassB;
  ClassC myClassC;
};

Select allOpen in new window

File ClassA.cpp

#include "StdAfx.h"
#include "ClassA.h"
#include "ClassC.h"

ClassA::ClassA(void)
{
  myClassB = ClassB();
  myClassC = ClassC(myClassB);
  //further lines...
}


ClassA::~ClassA(void)
{
}

Select allOpen in new window

This is a stripped down version of my actual project. Something isn't going right in the initialization of my actual project. When it executes line 8 of ClassA.cpp it skips all further lines like there's some internal error. Anything wrong with this code?

I think my problem is I'm passing myClassB as a parameter (line 8 ClassA.cpp), and that's making a copy of myClassB, so I end up with two identical copies of myClassB.

I'm guessing the constructor for the copy of myClassB isn't being called, where I allocate a resource. So the destructor gets called for the original, then the copy, attempting to release the same resource a 2nd time.

I wanted to synchronize access to a simple variable (integer or float), make it thread safe, so I allocate and save a mutex in the constructor of ClassB:

      ghMutex = CreateMutex( 
        NULL,              // default security attributes
        FALSE,             // initially not owned
        NULL);             // unnamed mutex

Select allOpen in new window

Then in the destructor I release that mutex:

CloseHandle(ghMutex);

Select allOpen in new window

Maybe there's a better way to synchronize access to an integer so I don't have two threads, one writing the other reading the variable at the same time?

Will declaring the integer and float variables volatile be sufficient to make them multithreaded safe?

How would I use InterlockedExchange to protect a float or a double?

Do I also need a protected read function? Or is the protected write function enough?

Thank you very much. One more question,

ClassA::ClassA(void) : myClassB(), myClassC(myClassB) // 'myClassB' here just serves the purpose to enforce the construction before 'myClassC'
{
 
  //further lines...
}

Select allOpen in new window

In this initializer list list it looks like we're storing myClassB in variable myClassC.

The syntax is confusing.

How would I use InterlockedExchange to protect a float or a double?

there is a fast mutex class which uses the InterlockedIncrement and InterlockedDecrement to grant exclusive access to any other resource.

class FastMutex
{
      volatile long lock;
public:
      FastMutex() : lock(0) {}
 
     void enter() 
      {
         while (InterlockedIncrement(&lock) > 1)
         {
             InterlockedDecrement(&lock);
             Sleep(0);
         }
       }
       void leave() { InterlockedDecrement(&lock); }
};

Select allOpen in new window

the "interlocked" mode would guarantee that two threads would run one after the other and the second would be locked while the first thread does not release the lock.

note with the fast mutex a thread cannot call 'enter' twice without dead-locking. if that is an issue you should use a critical section instead which can be entered multiple times by the same thread (and needs a leave for each enter).

Anything wrong with this code?

hmmm. i don't know why you need 3 classes which mutually make a reference to each other. that actually adds complexity which is unnecessary in almost all cases. beside of avoiding redundancy, your class design needs to have clear responsibilities. a mutex is a helper only. it may not be the determining factor for a design. creating the mutex in the constructor and destroying it in the destructor is fine. the mutex should be a member of classA as it is the 'parent' class which was deleted after their class members. if those also should use the mutex you may provide a member function of classA which returns a reference to the mutex object and the sub classes classB and classC may hold a pointer to their parent which easily could be passed in classA constructor:

classA::classA() : myclassB(this), myClassC(this) { }

Select allOpen in new window

note, if your hierarchy is

classA -> classB -> classC

you would have myxclassB a member of classA and myClassC a member of classB. if additionally both classes clasB and classC should have access to their parents you would have a member pointer to classA in classB and a member pointer to classB in classC. the constructors would be like

classA::classA() : classB(this) {}

classB::classB(classA * pA) : pmyClassA(pA), myClassC(this) {}

classC::classC(classB * pB) : pmyClassB(pB) {}

Select allOpen in new window

here pointers are the better choice over references if you want to use classB and classC objects independently of a 'parent'. for those cases you would pass a NULL pointer.

myClassB = ClassB();

this statement makes no sense in a c++ constructor because the myClassB already was created before it was entering the constructor's. that is the reason why c++ has an initializer list outside of the constructor's body to initialize members and create class members with a non-default constructor. with the statement you made you create an additional temporary classB object and assign it to the already created myclassB object. if classB has a default constructor which correctly initializes all members that copy+assign doesn't make anything worse. but nevertheless it is not needed and error-prone. if myClassB was initialized with an existing member, the assignment would destroy the contents of the member and its origin.
     
Sara