Friday 28 December 2012

Safe release of resources

If class allocates unmanaged resources (database connections, sockets, window handles, bitmaps...) it has to implement IDisposable interface with a single method Dispose() which deallocates such resources. When user of this class does not need its instance any more, it has to make sure Dispose() is called - even in the case of an exception. This can be achieved by using try-catch-finally block or with using statement:

Some classes in .NET which implement IDisposable have method Close() along with method Dispose(). Dispose() usually calls Close():

...so it's perfectly safe omitting explicit call to Close() when using using statement.

Resources:
Proper use of the IDisposable interface (SO)
close or dispose (SO)
Does Stream.Dispose always call Stream.Close (and Stream.Flush) (SO)

Friday 27 July 2012

Creating graphs and diagrams with Doxygen


Install Doxygen and GraphViz.

Open Doxywizard.

In Wizard tab, click on Diagrams topic. Enable Use dot tool from the GraphViz package and select desired graphs to generate.

In Expert tab, click on Project topic. Enable SHORT_NAMES.

In Expert tab, click on Dot topic. Enable HAVE_DOT and set DOT_PATH to relative path to GraphViz binaries (e.g. ../../../Program Files/Graphviz 2.28/bin). Set other attributes by your needs.

When run, Doxygen will create image files for all specified diagrams and create hyperlinks to them across the generated html files.

How to exclude directory from Doxygen parsing

Let's say we want to generate documentation for some code which is at the following path:

C:\development\project1

This project might be using some module (e.g. 3rd party code) which is contained in project1's subdirectory:

C:\development\project1\module1

How to exclude module1 from Doxygen parser? In Doxywizard, open Expert tab and click on Input topic. Find EXCLUDE_PATTERNS attribute and type:

*/module1/*

NOTE:
INPUT attribute should be set to the absolute path to the code of our project:

C:\development\project1

Tuesday 12 June 2012

Appending string to STL stringstream

std::stringstream constructor has two optional parameters: string that this stream will be initialized with and the buffer mode. Default mode for stringstream is ios::in|ios::out. Put pointer (the one that points to the location in the buffer where the next output operation will start inserting characters) is always set to location 0 upon stream creation regardless of the buffer content. That explains why Test 2 in the code below yields overwriting of the content on the second output.

If we want to initialize stream during its creation and to make next output operation to append characters, we need to move put pointer to the end of the buffer explicitly - by setting buffer open mode to ios::ate (see Test 3).

main.cpp:


Output:
Test 1:
Contained string: "abc"; Output pointer position: 3
Contained string: "abcdef"; Output pointer position: 6

Test 2:
Contained string: "abc"; Output pointer position: 0
Contained string: "def"; Output pointer position: 3

Test 3:
Contained string: "abc"; Output pointer position: 3
Contained string: "abcdef"; Output pointer position: 6

Friday 18 May 2012

One Definition Rule and Unnamed namespaces

It is possible to have multiple (different) definitions of a class with all methods declared as inline, in different translation units. Both compiler and linker do not complain. Compiler sees only a single unit and so only a single definition. Linker treats all definitions of inline class methods equally, picks only one for linking and discards the rest. But different definitions of the same class are introducing undefined behaviour as linker can pick e.g. constructor implementation from one module and method implementation from another. So the client code might potentially call method defined in one module on some object created with constructor defined in another module. Different definitions of the same class within the same program break the One Definition Rule (§3.2, C++11 standard draft N3242=11-0012). (See my Stack Overflow question)

It is possible to define classes with the same name in different translation units in a safe way. Classes are visible in all units because member functions of non-local classes have external linkage by default. It doesn't matter whether methods are declared as inline, static or they are declared without any specifiers. So this is the reason why linker is able to see multiple definitions of the same method, allowing it to (arbitrary) pick the one and discard the rest. We need to suppress this, we need to hide definitions inside translation units. If we had a variable or a function, we could achieve this by declaring it as static and therefore imposing internal linkage on them. But we cannot apply static keyword on classes (user defined types). What we can do is to place class definition in each translation unit inside a unnamed namespace. This way we are limiting class access only to the translation unit this class is defined in and disable breaking of the One Definition Rule.


Links and References:

external vs internal linkage and performance (SO)
Unnamed/anonymous namespaces vs. static functions (SO)
Superiority of unnamed namespace over static? (SO)
Why unnamed namespace is a“ superior” alternative to static? (SO)
static keyword useless in namespace scope? (SO)


Tuesday 15 May 2012

WaitForMultipleObjects and priority of the events

The order of event handlers in the handler array passed to WaitForMultipleObjects function must be carefully chosen if we want to differentiate priorities of events.

Let us assume that we have two events, Event1 and Event2, and that we want Event2 to have a higher priority so if both events are set, WaitForMultipleObjects returns the index of the Event2. We can make this by defining the order of the event handlers in the array passed to WaitForMultipleObjects.

In the example below, Event2 controls when the program execution jumps out of the loop. If Event1 is set quickly enough between ResetEvent() and WaitForMultipleObjects, it is Event1 that will always cause WaitForMultipleObjects to return, no matter what is the state of Event2. Execution will get out of the loop only if Event2 is set and Event1 is not set before WaitForMultipleObjects (which might never happen):



If we want to make sure that WaitForMultipleObjects first checks whether Event2 is set so it breaks out of the loop as soon as this event is set, we need to place Event2 before Event1 in the array:



This time, even if both events are set, WAIT_OBJECT_0 case is executed and program flow leaves the loop.

This is the consequence of the following feature of WaitForMultipleObjects:

If more than one object became signaled during the call, WAIT_OBJECT_0 is the array index of the signaled object with the smallest index value of all the signaled objects.


Listening TCP Socket

TCP is a connection-oriented transport protocol which means that end points have to establish a connection prior to sending any (payload) data. Server opens one socket only for listening for incoming connection requests that come from clients. When placing a socket into a listening state, a maximum number of pending incoming connections is set. Those connections are waiting to be accepted and when backlog gets full no new connections are accepted.

Operations on listening socket are:
Listening socket never gets into connected state and shutdown() called on it yields socket error 10057 - WSAENOTCONN (Socket is not connected).

Here is the timeline of one simple dialogue between the client and the server:

Client Server
sock = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) sockListen= socket(AF_INET, SOCK_STREAM, IPPROTO_TCP)
- sockaddr_in sSockAddr;
sSockAddr.sin_family = AF_INET;
sSockAddr.sin_addr.s_addr = inet_addr("192.168.0.24");
sSockAddr.sin_port = htons(43501);

bind(sockListen, (SOCKADDR*)&sSockAddr, sizeof(sSockAddr));
- listen(sockListen, MAXPENDING)
struct sockaddr_in sockAddrRemoteNode;
memset(&sockAddrRemoteNode, 0, sizeof(sockAddrRemoteNode));
sockAddrRemoteNode.sin_family = AF_INET;
sockAddrRemoteNode.sin_addr.s_addr = inet_addr("192.168.0.24");
sockAddrRemoteNode.sin_port = htons(43501);

connect(sock, (struct sockaddr*) &sockAddrRemoteNode, sizeof(sockAddrRemoteNode));
struct sockaddr sockAddrClt;
int nSockAddrLen = sizeof(sockAddrClt);

sockClient = accept(sockListen, (struct sockaddr*) &sockAddrClt, &nSockAddrLen);
send(sock, buffSend, SEND_BUFF_SIZE, 0) int recvPacketLen = recv(sockClient, buffRecv, RECV_BUFF_SIZE, 0)
shutdown(sock, SD_BOTH) shutdown(sockClient, SD_BOTH)
closesocket(sock) closesocket(sockClient)
- closesocket(sockListen)

Thursday 3 May 2012

Observer pattern: from GoF implementation to events and delegates


Let us assume we have some class (Subject) with properties that can be changed. A set of current values of all properties defines Subject's state. Another class (Observer) must be notified each time Subject's state changes (each time some property changes). Observer pattern decouples direct dependencies between (concrete) subject and (concrete) observer by using interfaces.

The following code shows classic (Gang of Four) implementation of the Observer pattern applied to two subjects (PropertyOwner1 and PropertyOwner2) and their observers (PropertyObserver1 and PropertyObserver2):

main.cpp:


Output:


PropertyOwner1: property1's new value is: 1
PropertyObserver1: PropertyOwner1 property1's value is: 1
PropertyObserver2: PropertyOwner1 property2's value is: 0

PropertyOwner1: property2's new value is: 1.2
PropertyObserver1: PropertyOwner1 property1's value is: 1
PropertyObserver2: PropertyOwner1 property2's value is: 1.2

PropertyOwner2: property1's new value is: 1
PropertyObserver1: PropertyOwner2 property2's value is: 0
PropertyObserver2: PropertyOwner2 property1's value is: 1

PropertyOwner2: property2's new value is: 3.4
PropertyObserver1: PropertyOwner2 property2's value is: 3.4
PropertyObserver2: PropertyOwner2 property1's value is: 1

PropertyOwner1: property1's new value is: 2
PropertyObserver2: PropertyOwner1 property2's value is: 1.2

PropertyOwner1: property2's new value is: 4.5
PropertyObserver2: PropertyOwner1 property2's value is: 4.5

As we can see, observer is notified each time any property of the subject changes. E.g. if we look the test where PropertyOwner1's property1 changes to 2 but PropertyObserver2 is notified regardless the fact that it is interested only in PropertyOwner1's property2.

In this model client gets information that the subject's state (some property) has been changed but it does not know exactly which property has been changed. Of course, observer could maintain the history of obtained values for each property and compare new values with the previous ones and thus detect for which property the value has changed but this increases complexity of the observer.

Somehow we need to pass to the observer information about which property has changed. If we assign each property in a system a unique ID we could pass it to the observer as an additional parameter of the Subject::update() method:

main.cpp:

#include
#include
#include

class Subject;

enum PropertyID
{
Property1,
Property2
};

class Observer
{
public:
virtual ~Observer(){}
// pointer to Subject is passed so ConcreteObserver can distinct ConcreteSubjects
virtual void update(Subject*, PropertyID) = 0;
};

class Subject
{
public:
virtual ~Subject(){}

void registerObserver(Observer* const o)
{
std::list::const_iterator it = std::find(observers_.begin(), observers_.end(), o);
if(it != observers_.end())
throw std::runtime_error("Observer already registered");

observers_.push_back(o);
}

void unregisterObserver(Observer* const o)
{
std::list::const_iterator it = std::find(observers_.begin(), observers_.end(), o);
if(it != observers_.end())
observers_.remove(o);
}

void notify(PropertyID propertyID)
{
std::list::const_iterator it = observers_.begin();
for(; it != observers_.end(); ++it)
(*it)->update(this, propertyID);
}

protected:
std::list observers_;
};


// Concrete Subject
class PropertyOwner1 : public Subject
{
int property1_;
float property2_;

public:

PropertyOwner1() : property1_(0), property2_(0.0f){}

void property1(int n)
{
if(n != property1_)
{
property1_ = n;
std::cout << "\nPropertyOwner1: property1's new value is: " << property1_ << std::endl; notify(Property1); } } int property1() const { return property1_;} void property2(float n) { if(n != property2_) { property2_ = n; std::cout << "\nPropertyOwner1: property2's new value is: " << property2_ << std::endl; notify(Property2); } } float property2() const { return property2_;} }; class PropertyOwner2 : public Subject { bool property1_; double property2_; public: PropertyOwner2() : property1_(false), property2_(0.0){} void property1(bool n) { if(n != property1_) { property1_ = n; std::cout << "\nPropertyOwner2: property1's new value is: " << property1_ << std::endl; notify(Property1); } } bool property1() const { return property1_;} void property2(double n) { if(n != property2_) { property2_ = n; std::cout << "\nPropertyOwner2: property2's new value is: " << property2_ << std::endl; notify(Property2); } } double property2() const { return property2_;} }; // Concrete Observer // observes changes in property1 of ConcreteSubject1 and // property2 of ConcreteSubject2 class PropertyObserver1 : public Observer { // ConcreteObserver knows about ConcreteSubjects PropertyOwner1* pPropertyOwner1_; PropertyOwner2* pPropertyOwner2_; public: PropertyObserver1(PropertyOwner1* pConcreteSubject1, PropertyOwner2* pPropertyOwner2) : pPropertyOwner1_(pConcreteSubject1), pPropertyOwner2_(pPropertyOwner2){} void update(Subject* pSubject, PropertyID propertyID) { if(pSubject == pPropertyOwner1_) { if(propertyID == Property1) { int property1 = pPropertyOwner1_->property1();
std::cout << "\tPropertyObserver1: PropertyOwner1 property1's value is: " << property1 << std::endl; } } else if(pSubject == pPropertyOwner2_) { if(propertyID == Property2) { double property2 = pPropertyOwner2_->property2();
std::cout << "\tPropertyObserver1: PropertyOwner2 property2's value is: " << property2 << std::endl; } } } }; // Concrete Observer // observes changes in property2 of ConcreteSubject1 and // property1 of ConcreteSubject2 class PropertyObserver2 : public Observer { PropertyOwner1* pPropertyOwner1_; PropertyOwner2* pPropertyOwner2_; public: PropertyObserver2(PropertyOwner1* pPropertyOwner1, PropertyOwner2* pPropertyOwner2) : pPropertyOwner1_(pPropertyOwner1), pPropertyOwner2_(pPropertyOwner2){} void update(Subject* pSubject, PropertyID propertyID) { if(pSubject == pPropertyOwner1_) { if(propertyID == Property2) { float property2 = pPropertyOwner1_->property2();
std::cout << "\tPropertyObserver2: PropertyOwner1 property2's value is: " << property2 << std::endl; } } else if(pSubject == pPropertyOwner2_) { if(propertyID == Property1) { bool property1 = pPropertyOwner2_->property1();
std::cout << "\tPropertyObserver2: PropertyOwner2 property1's value is: " << property1 << std::endl; } } } };






Output shows that this time each observer knew exactly which property of which subject has been changed:


PropertyOwner1: property1's new value is: 1
PropertyObserver1: PropertyOwner1 property1's value is: 1

PropertyOwner1: property2's new value is: 1.2
PropertyObserver2: PropertyOwner1 property2's value is: 1.2

PropertyOwner2: property1's new value is: 1
PropertyObserver2: PropertyOwner2 property1's value is: 1

PropertyOwner2: property2's new value is: 3.4
PropertyObserver1: PropertyOwner2 property2's value is: 3.4

PropertyOwner1: property1's new value is: 2

PropertyOwner1: property2's new value is: 4.5
PropertyObserver2: PropertyOwner1 property2's value is: 4.5

There is a room for further improvements: notify() (and so observer's update()) function is called each time any property of the subject is changed. Yes, Property ID is passed so observer knows which property has been modified but still - can we avoid calling update() of the observer that is not interested in that particular property?

The solution is to granulate Observer pattern: instead of taking PropertyOwners as concrete subjects, let us move Observer pattern one level down and take PropertyOwners' properties as explicit concrete subjects. This implies that observers will need to register with properties, not with their owning classes - PropertyOwners. Each property will implement Subject interface and maintain its list of observers. When calling notify()/update() it needs to pass information on the type of its owner (PropertyOwner - "implicit concrete subject") so the observer knows which PropertyOwner has changed. On the observer's side we can do the same, granulate the pattern to smaller units which belong to particular class (PropertyObserverOwner - "implicit concrete observer") and which observe particular
property of the particular class. Templates come handy for this implementation:


main.cpp:

#include
#include
#include

// Abstract Observer
template
class PropertyObserver
{
public:
virtual void update(const TPropertyType& newValue) = 0;
};

// Concrete Observer (member of the class that observes a set of properties through a set of
// property concrete observers)
template
class PropertyObserverMember : public PropertyObserver
{
TPropertyObserverOwner* pPropertyObserverOwner_;

typedef void (TPropertyObserverOwner::*TPropertyChangeHandler)(const TPropertyType&);
TPropertyChangeHandler handler_;

public:
PropertyObserverMember(TPropertyObserverOwner* pPropertyObserverOwner, TPropertyChangeHandler handler) :
pPropertyObserverOwner_(pPropertyObserverOwner), handler_(handler){}

void update(const TPropertyType& newValue)
{
(pPropertyObserverOwner_->*handler_)(newValue);
}
};

// Subject
template
class ObservableProperty
{
public:
virtual ~ObservableProperty(){};
void registerObserver(PropertyObserver* const o)
{
std::list* const>::const_iterator it = std::find(observers_.begin(), observers_.end(), o);
if(it != observers_.end())
throw std::runtime_error("Observer already registered");
observers_.push_back(o);
}

void unregisterObserver(PropertyObserver* const o)
{
std::list* const>::const_iterator it = std::find(observers_.begin(), observers_.end(), o);
if(it != observers_.end())
observers_.remove(o);
}

void notify(const TPropertyType& newValue)
{
std::list* const>::const_iterator it = observers_.begin();
for(; it != observers_.end(); ++it)
(*it)->update(newValue);
}

protected:
std::list* const> observers_;
};

// Concrete Subject
template
class Property : public ObservableProperty
{
TPropertyType t_;
TPropertyOwner* owner_;
public:
Property(const TPropertyType& t, TPropertyOwner* owner) : t_(t), owner_(owner){}

void set(const TPropertyType& t)
{
if(t_ != t)
{
t_ = t;

std::cout << typeid(TPropertyOwner).name() << "'s property of type " << typeid(TPropertyType).name() << " has been set to " << t << std::endl; notify(t); } } TPropertyType get() const { return t_; } }; // class that owns concrete subjects struct PropertyOwner1 { Property property1;
Property property2;
//Property property3;

PropertyOwner1() :
property1(0, this),
property2(0.0f, this)/*,
property3("", this)*/
{}
};

// class that owns concrete subjects
struct PropertyOwner2
{
Property property1;
Property property2;

PropertyOwner2() :
property1(false, this),
property2(0.0, this)
{}
};

// class that owns concrete observers and through them
// observes changes in property1 of PropertyOwner1 and property2 of PropertyOwner2
struct PropertyObserverOwner1
{
PropertyObserverMember propertyOwner1_property1_Observer_;
PropertyObserverMember propertyOwner2_property2_Observer_;
//PropertyObserverMember propertyOwner1_property3_Observer_;

PropertyObserverOwner1() :
propertyOwner1_property1_Observer_(this, &PropertyObserverOwner1::OnPropertyOwner1Property1Changed),
propertyOwner2_property2_Observer_(this, &PropertyObserverOwner1::OnPropertyOwner2Property2Changed)/*,
propertyOwner1_property3_Observer_(this, &PropertyObserverOwner1::OnPropertyOwner1Property3Changed)*/
{}

void OnPropertyOwner1Property1Changed(const int& newValue)
{
std::cout << "\tPropertyObserverOwner1::OnPropertyOwner1Property1Changed(): \n\tnew value is: " << newValue << std::endl; } void OnPropertyOwner2Property2Changed(const double& newValue) { std::cout << "\tPropertyObserverOwner1::OnPropertyOwner2Property2Changed(): \n\tnew value is: " << newValue << std::endl; } /* void OnPropertyOwner1Property3Changed(const std::string& newValue) { std::cout << "\tPropertyObserverOwner1::OnPropertyOwner1Property3Changed(): \n\tnew value is: " << newValue << std::endl; } */ }; // class that owns concrete observers and through them // observes changes in property2 of PropertyOwner1 and property1 of PropertyOwner2 struct PropertyObserverOwner2 { PropertyObserverMember propertyOwner1_property2_Observer_;
PropertyObserverMember propertyOwner2_property1_Observer_;

PropertyObserverOwner2() :
propertyOwner1_property2_Observer_(this, &PropertyObserverOwner2::OnPropertyOwner1Property2Changed),
propertyOwner2_property1_Observer_(this, &PropertyObserverOwner2::OnPropertyOwner2Property1Changed){}

void OnPropertyOwner1Property2Changed(const float& newValue)
{
std::cout << "\tPropertyObserverOwner2::OnPropertyOwner1Property2Changed(): \n\tnew value is: " << newValue << std::endl; } void OnPropertyOwner2Property1Changed(const bool& newValue) { std::cout << "\tPropertyObserverOwner2::OnPropertyOwner2Property1Changed() \n\tnew value is: " << newValue << std::endl; } }; int main(int argc, char** argv) { PropertyOwner1 propertyOwner1; PropertyOwner2 propertyOwner2; PropertyObserverOwner1 propertyObserverOwner1; PropertyObserverOwner2 propertyObserverOwner2; // register propertyObserverOwner1's observers propertyOwner1.property1.registerObserver(&propertyObserverOwner1.propertyOwner1_property1_Observer_); propertyOwner2.property2.registerObserver(&propertyObserverOwner1.propertyOwner2_property2_Observer_); // register propertyObserverOwner2's observers propertyOwner1.property2.registerObserver(&propertyObserverOwner2.propertyOwner1_property2_Observer_); propertyOwner2.property1.registerObserver(&propertyObserverOwner2.propertyOwner2_property1_Observer_); propertyOwner1.property1.set(1); propertyOwner1.property2.set(1.2f); propertyOwner2.property1.set(true); propertyOwner2.property2.set(3.4); // unregister propertyObserverOwner1's observers propertyOwner1.property1.unregisterObserver(&propertyObserverOwner1.propertyOwner1_property1_Observer_); propertyOwner2.property2.unregisterObserver(&propertyObserverOwner1.propertyOwner2_property2_Observer_); propertyOwner1.property1.set(2); propertyOwner1.property2.set(4.5f); }






Output shows that this time a single update() call is made for a single property change:

struct PropertyOwner1's property of type int has been set to 1
   PropertyObserverOwner1::OnPropertyOwner1Property1Changed():
   new value is: 1
struct PropertyOwner1's property of type float has been set to 1.2
   PropertyObserverOwner2::OnPropertyOwner1Property2Changed():
   new value is: 1.2
struct PropertyOwner2's property of type bool has been set to 1
   PropertyObserverOwner2::OnPropertyOwner2Property1Changed()
   new value is: 1
struct PropertyOwner2's property of type double has been set to 3.4
   PropertyObserverOwner1::OnPropertyOwner2Property2Changed():
   new value is: 3.4
struct PropertyOwner1's property of type int has been set to 2
struct PropertyOwner1's property of type float has been set to 4.5
   PropertyObserverOwner2::OnPropertyOwner1Property2Changed():
   new value is: 4.5

I don't like the previous implementation. It is too complex and its scalability is questionable.

I was always a big fan of C# events and delegates. It is so easy to bind some event with its handler. I tried to implement something similar in C++ and here is the result:

main.cpp:

#include
#include
#include

// use base class to resolve the problem of how to put into collection objects of different types
template
struct PropertyChangedDelegateBase
{
virtual ~PropertyChangedDelegateBase(){};
virtual void operator()(const TPropertyType& t) = 0;
};

template
struct PropertyChangedDelegate : public PropertyChangedDelegateBase
{
THandlerOwner* pHandlerOwner_;

typedef void (THandlerOwner::*TPropertyChangeHandler)(const TPropertyType&);
TPropertyChangeHandler handler_;

public:
PropertyChangedDelegate(THandlerOwner* pHandlerOwner, TPropertyChangeHandler handler) :
pHandlerOwner_(pHandlerOwner), handler_(handler){}

void operator()(const TPropertyType& t)
{
(pHandlerOwner_->*handler_)(t);
}
};

template
class PropertyChangedEvent
{
public:
virtual ~PropertyChangedEvent(){};

void add(PropertyChangedDelegateBase* const d)
{
std::list* const>::const_iterator it = std::find(observers_.begin(), observers_.end(), d);
if(it != observers_.end())
throw std::runtime_error("Observer already registered");

observers_.push_back(d);
}


void remove(PropertyChangedDelegateBase* const d)
{
std::list* const>::const_iterator it = std::find(observers_.begin(), observers_.end(), d);
if(it != observers_.end())
observers_.remove(d);
}

// notify
void operator()(const TPropertyType& newValue)
{
std::list* const>::const_iterator it = observers_.begin();
for(; it != observers_.end(); ++it)
{
(*it)->operator()(newValue);
}
}

protected:
std::list* const> observers_;
};

// class that owns concrete subjects
class PropertyOwner1
{
int property1_;
float property2_;
public:
PropertyChangedEvent property1ChangedEvent;
PropertyChangedEvent property2ChangedEvent;

PropertyOwner1() :
property1_(0),
property2_(0.0f)
{}

int property1() const {return property1_;}
void property1(int n)
{
if(property1_ != n)
{
property1_ = n;
std::cout << "PropertyOwner1::property1(): property1_ set to " << property1_ << std::endl; property1ChangedEvent(property1_); } } float property2() const {return property2_;} void property2(float n) { if(property2_ != n) { property2_ = n; std::cout << "PropertyOwner1::property2(): property2_ set to " << property2_ << std::endl; property2ChangedEvent(property2_); } } }; // class that owns concrete subjects class PropertyOwner2 { bool property1_; double property2_; public: PropertyChangedEvent property1ChangedEvent;
PropertyChangedEvent property2ChangedEvent;

PropertyOwner2() :
property1_(false),
property2_(0.0)
{}

bool property1() const {return property1_;}
void property1(bool n)
{
if(property1_ != n)
{
property1_ = n;
std::cout << "PropertyOwner2::property1(): property1_ set to " << property1_ << std::endl; property1ChangedEvent(property1_); } } double property2() const {return property2_;} void property2(double n) { if(property2_ != n) { property2_ = n; std::cout << "PropertyOwner2::property2(): property2_ set to " << property2_ << std::endl; property2ChangedEvent(property2_); } } }; // class that observes changes in property1 of PropertyOwner1 and property1 of PropertyOwner2 struct PropertyObserver1 { void OnPropertyOwner1Property1Changed(const int& newValue) { std::cout << "\tPropertyObserver1::OnPropertyOwner1Property1Changed(): \n\tnew value is: " << newValue << std::endl; } void OnPropertyOwner2Property1Changed(const bool& newValue) { std::cout << "\tPropertyObserver1::OnPropertyOwner2Property1Changed(): \n\tnew value is: " << newValue << std::endl; } }; // class that observes changes in property2 of PropertyOwner1 and property2 of PropertyOwner2 struct PropertyObserver2 { void OnPropertyOwner1Property2Changed(const float& newValue) { std::cout << "\tPropertyObserver2::OnPropertyOwner1Property2Changed(): \n\tnew value is: " << newValue << std::endl; } void OnPropertyOwner2Property2Changed(const double& newValue) { std::cout << "\tPropertyObserver2::OnPropertyOwner2Property2Changed(): \n\tnew value is: " << newValue << std::endl; } }; int main(int argc, char** argv) { PropertyOwner1 propertyOwner1; PropertyOwner2 propertyOwner2; PropertyObserver1 propertyObserver1; PropertyObserver2 propertyObserver2; // register observers PropertyChangedDelegate delegate1(&propertyObserver1, &PropertyObserver1::OnPropertyOwner1Property1Changed);
propertyOwner1.property1ChangedEvent.add(&delegate1);

PropertyChangedDelegate delegate2(&propertyObserver2, &PropertyObserver2::OnPropertyOwner1Property2Changed);
propertyOwner1.property2ChangedEvent.add(&delegate2);

PropertyChangedDelegate delegate3(&propertyObserver1, &PropertyObserver1::OnPropertyOwner2Property1Changed);
propertyOwner2.property1ChangedEvent.add(&delegate3);

PropertyChangedDelegate delegate4(&propertyObserver2, &PropertyObserver2::OnPropertyOwner2Property2Changed);
propertyOwner2.property2ChangedEvent.add(&delegate4);

propertyOwner1.property1(1);
propertyOwner1.property2(1.2f);

propertyOwner2.property1(true);
propertyOwner2.property2(3.4);

// unregister PropertyObserver1
propertyOwner1.property1ChangedEvent.remove(&delegate1);
propertyOwner2.property1ChangedEvent.remove(&delegate3);

propertyOwner1.property1(2);
propertyOwner1.property2(4.5f);
}

Output:
PropertyOwner1::property1(): property1_ set to 1
   PropertyObserver1::OnPropertyOwner1Property1Changed():
   new value is: 1
PropertyOwner1::property2(): property2_ set to 1.2
   PropertyObserver2::OnPropertyOwner1Property2Changed():
   new value is: 1.2
PropertyOwner2::property1(): property1_ set to 1
   PropertyObserver1::OnPropertyOwner2Property1Changed():
   new value is: 1
PropertyOwner2::property2(): property2_ set to 3.4
   PropertyObserver2::OnPropertyOwner2Property2Changed():
   new value is: 3.4
PropertyOwner1::property1(): property1_ set to 2
PropertyOwner1::property2(): property2_ set to 4.5
   PropertyObserver2::OnPropertyOwner1Property2Changed():
   new value is: 4.5

This is exactly what I wanted: observer registered with particular property (event), notified when property's changed and with a knowledge of property's owner and a new value.

Removing STL list elements whilst iterating through it

I have already written about the traps and solutions when we try to remove elements from vectors and maps whilst iterating through them. Today I want to cover the same topic regarding lists.

Let us assume we have a list containing integers and we want to remove all elements that are odd numbers. If not aware of std::list::remove() side effects, the first thing we would try could be the following:



When run, this program removes element with the value 1 but the next time it tries to dereference iterator it crashes with the message:

Microsoft Visual Studio
Unhandled exception at 0x00d5c7a2 in Test.exe: 0xC0000005: Access violation reading location 0xfeeefef6.

The most often source of errors when working with STL containers are invalid iterators. Before calling some function on some STL container, we need to make sure we understand how it affects container's iterators. The latest draft of the new C++ standard (C++11) says (§ 23.3.5.5):

void remove(const T& value);
template void remove_if(Predicate pred);

Effects: Erases all the elements in the list referred by a list iterator i for which the following conditions
hold: *i == value, pred(*i) != false. Invalidates only the iterators and references to the erased
elements.


Throws: Nothing unless an exception is thrown by *i == value or pred(*i) != false.

This explains what happened in our program: remove() invalidated iterator and all subsequent operations on iterator (incrementing, dereferencing) yielded undefined behaviour (crash in our case).

A simple solution to this is to save iterator's value before removing an element, increment it and then remove element on the saved (previous) iterator value. In the next iteration iterator will be pointing to the next element after the removed one:


This time program works as expected and yields the following output:

display_elements()
list[0] = 1
list[1] = 2
list[2] = 3
list[3] = 4


display_elements()
list[0] = 2
list[1] = 4

Instead of using temporary variable to store previous value of the iterator, we can use post-increment operator (this works as function arguments are fully evaluated before a function is called):



Another function that removes an element (or a range of elements) from a list is std::list::erase(). Instead of the element value, an iterator is passes as its argument. Similar to list::remove(), it invalidates the iterator of the erased element.



This yields debug assertion error:

---------------------------
Microsoft Visual C++ Debug Library
---------------------------
Debug Assertion Failed!

Program: C:\test\Tests.exe
File: c:\program files\microsoft visual studio 10.0\vc\include\list
Line: 227

Expression: list iterator not incrementable

For information on how your program can cause an assertion
failure, see the Visual C++ documentation on asserts.

(Press Retry to debug the application)
---------------------------
Abort Retry Ignore
---------------------------

Applying the same fix like before solves the problem:



If we want to remove from a list all elements that match certain criteria, the best way to achieve that is not to fiddle with iterators and loops but to use std::list::remove_if(). This function uses unary predicate to check the criteria for the current element. In our case the predicate returns true if the value is odd number:



Output:

display_elements()
list[0] = 1
list[1] = 2
list[2] = 3
list[3] = 4


display_elements()
list[0] = 2
list[1] = 4

NOTE: The signature of the predicate does not need to have const &, but the function must not modify the objects passed to it.

To make the code even smaller, we can move the code from a predicate to a lambda expression:

Monday 30 April 2012

pImpl Idiom

If class A has an instance of class B as its member, A.h must include B.h:

A.h:


A's client must include A.h either in its header or in a source file:

clientA.h:


clientA.cpp:



By including A.h, clientA.cpp has implicitly included B.h as well thus creating dependency between clientA and B. clientA now knows about B but it should know only about A. B is a part of the A's implementation which should be hidden from clientA. If anything changes in B.h, it is not just A that has to be recompiled but testA as well. We want to break this compiler dependency.

The most common way to achieve this is through breaking up class A into two parts: publicly accessible shell class, with public interface and minimal dependency on other headers and private implementation class, which depends on other headers. For this Private IMPLementation moment, this idiom got its name - PIMPL. (Or because shell class contains Pointer to IMPLementation class - see the next paragraph.)

Class A declaration contains forward declaration of implementation class (AImpl) and pointer to it, both of which are private. RAII semantics is achieved by using boost::scoped_ptr (std::unique_ptr could have been used as well).

B.h:


B.cpp:


A.h:


A.cpp:


main.cpp:


Output:
A::A()
AImpl::AImpl()
A::foo()
AImpl::foo(). n = 3
AImpl::foo(). res = 1
A::~A()
AImpl::~AImpl()

If we decide to change B's interface, e.g. divide() to return type double instead of int, we just need to recompile unit A but not clientA:

B.h:


B.cpp:


A.cpp:


Output:
A::A()
AImpl::AImpl()
A::foo()
AImpl::foo(). n = 3
AImpl::foo(). res = 1.5
A::~A()
AImpl::~AImpl()

References:
Pointer To Implementation (pImpl)
GotW #100: Compilation Firewalls
Pimpl Idiom
Private class data pattern (Wikipedia)
Opaque pointer (Wikipedia)
pimpl idiom vs. bridge design pattern (SO)
pimpl: shared_ptr or unique_ptr (SO)
std::auto_ptr or boost::shared_ptr for pImpl idiom? (SO)
Private members in pimpl class? (SO)


Monday 23 April 2012

Deleting objects through pointer to void

An object of type T stored in dynamic memory (heap) can be safely deleted through pointer of type void* only if T is a POD type.

POD types are:

  • scalar types
  • POD classes
  • arrays of such types and
  • cv-qualified versions of these types

where

Scalar types are:

  • arithmetic(fundamental) types (like bool, char, int, float, double,...)
  • enumeration types
  • pointer types
  • pointer to member types
  • std::nullptr_t
  • cv-qualified versions of these types

Example 1: int is a POD type


Example 2: struct B is a POD type


Example 3: struct C is not a POD type

Memory leak is reported in debug output window when running Example 3:
Detected memory leaks!
Dumping objects ->
{144} normal block at 0x00595580, 4 bytes long.
Data: < > 01 00 00 00
Object dump complete.

This last example yields memory leak because delete applied to void* pointer freed memory allocated for C members but it did not call C destructor thus leaving memory pointed by p_ allocated.

Friday 20 April 2012

JSON Data Binding with JSON Spirit

JSON is, like XML, a human readable, text-based format for data representation.

JSON document represents either object or an array.

Object starts and ends with curly brackets ({ }) and contains zero or more key-value pairs. Key (or name) is a string and value can be another object, number, string, array or literal true, false or null. Key is separated from value with a single colon (:). Key-value pars are separated with commas (,).

Array starts and ends with square brackets ([ ]) and contains zero or more values.

I wrote a mini series of articles on XML Data Binding and in this article I want to show how to serialize C++ object to JSON document and how to perform reverse process - how to deserialize JSON document back to the object.

JSON parser I am using here is JSON Spirit. Here is the list of steps of how to get working example from the scratch:

  1. Download and unpack master from http://gitorious.org/json-spirit/json-spirit/trees/master
  2. Find and open provided Visual Studio solution file (convert it to VS2010 format if necessary). It contains projects: json_demo, json_headers_only_demo, json_map_demo, json_spirit_lib and json_test.
  3. We will create test project that will be using JSON Spirit static library and its headers (Boost headers will be necessary as well). Build json_spirit_lib project which output is static library named json_spirit_lib.lib.
  4. In Project Settings for our test project, add json_spirit_lib.lib to Additional Dependencies as well as path to JSON Spirit headers (path to json_spirit directory) and path to Boost.
  5. Use main.cpp provided below which contains couple of functions that demonstrate JSON/C++ serialization/deserialization:
main.cpp:


Output:
Serialization result (generated JSON string):

{
   "name" : "Fyodor",
   "surName" : "Dostoyevsky"
}

Deserialization result:

name: Fyodor
surName: Dostoyevsky

Serialization result (generated JSON string):

{
   "author" : {
      "name" : "Fyodor",
      "surName" : "Dostoyevsky"
   },
   "isbn" : 123456789,
   "title" : "Crime and Punishment",
   "type" : 1
}

Deserialization result:

author name: Fyodor
author surName: Dostoyevsky
isbn: 123456789
title: Crime and Punishment
type: 1


Links and References:
The application/json Media Type for JavaScript Object Notation (JSON) - RFC 4627
Can a JSON start with [? (SO)

Thursday 19 April 2012

Logging into file in C#


If this approach is used in WCF service hosted on IIS, we will more likely be interested in the Web Service Application directory which can be obtained by using HostingEnvironment.ApplicationPhysicalPath property - it returns WCF service application's physical path e.g. C:\inetpub\wwwroot\WebServices\MyService.



Make sure that IIS_IUSRS has permission to create, modify and delete files in the directory where WCF service log file resides.


Some features of C#


This is a collection of some features of C# I found useful and interesting, given I am coming from a C++ background.


- it is easy to stringify enum values by using Enum.ToString Method
- it is possible to use strings in switch statement
- In C++, derived class constructor calls base class constructor by stating base class name:

...while in C# keyword base is used:

- C# does not allow multiple inheritance (class cannot inherit multiple base classes)

Abstract Classes

Both in C++ and C# abstract classes are designed to be base classes and can never be instantiated.
In C++, a class is abstract if has at least one pure virtual method.
In C#, a class is abstract if declared with abstract keyword. It may contain abstract methods and properties (they are declared as abstract and don't have implementation).
A non-abstract class derived from an abstract class must include actual implementations of all inherited abstract methods and accessors. Those implementations are method overrides and must be declared with override keyword.
Abstract methods are implicitly virtual.


Auto-Implemented Properties


Auto-implemented properties come very handy for properties with trivial accessors. Compiler creates a private, anonymous backing field that can only be accessed through the property's get and set accessors.

Don't try to implement auto-implemented properties. You'll end up having stack overflow! Example:



Object types and memory storage


In C++ there are POD (Plain Old Data) types (e.g. int, float, pointers, certain struct types,...see further explanations here) and non-POD types. Object of any type can be stored on the stack (e.g. if declared as a local variable) or on the heap (if created with new).

C# uses different type classification: there are value types and reference types. C# doesn't care where are they stored in memory. In C# a new can be used to store (value type) object either on the stack or on the heap.

Further reading:
Type Fundamentals
The Truth About Value Types
The Stack Is An Implementation Detail
C# Heap(ing) Vs Stack(ing) in .NET

Monday 16 April 2012

When does pure virtual destructor need its definition?

Deleting an instance of inherited class through a pointer to the base class yields memory leaks if destructor of the base class is not declared as virtual:

main.cpp:


Output:
main()
Parent::Parent()
Child::Child()
Child::foo()

Windows debugger output:
Detected memory leaks!
Dumping objects ->
{142} normal block at 0x00315588, 40 bytes long.
Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
Object dump complete.

It is not enough just to declare base class as virtual, but we need to provide its definition as well (the one with empty body will suffice), otherwise linker will report error (if derived class' destructor is defined, implicitly or explicitly, as it calls base class destructor):

error LNK2001: unresolved external symbol "public: virtual __thiscall Parent::~Parent(void)" (??1Parent@@UAE@XZ)

Note that if our code didn't call (implicitly or explicitly) Child's destructor, and so Parent's one, linker would not complain. But in our case we have construction and destruction of Child object so Parent needs to have destructor defined:



Output (memory leaks are not reported anymore):
main()
Parent::Parent()
Child::Child()
Child::foo()
Child::~Child()
Parent::~Parent()

We are able to instantiate Parent class but if we want to prevent that but with keeping default implementation of foo(), we can declare its destructor as pure virtual function. But there is one interesting thing: although it is declared as pure virtual, we still need to provide implementation of destructor, otherwise linker will complain (if derived class' destructor is defined - which calls base class destructor)!

Parent as abstract base class:


Just to make this article complete, it is worth mentioning that if foo() wasn't declared as virtual in the base class, we would have needed to cast base class pointer to derived class pointer in order to invoke derived class' version of the function:



Output (no memory leaks):
main()
Parent::Parent()
Child::Child()
Parent::foo()
Child::foo()
Child::~Child()
Parent::~Parent()

Further reading:
(Im)pure Virtual Functions

Friday 13 April 2012

How to terminate thread gracefully

Wait for "terminate" event inside thread callback and once it's signalled, set flag which will cause execution to leave the loop. In the main thread wait for worker thread's handle (join):



Output:
Keep running...
Keep running...
Keep running...
Keep running...
Keep running...
Keep running...
Keep running...
Keep running...
Keep running...
Keep running...
Keep running...
Keep running...
Keep running...
Keep running...
Keep running...
Keep running...
Keep running...
Keep running...
Keep running...
Keep running...
Terminate Event signalled
Thread terminated

NOTE: Another solution is using InterlockedCompareExchange.

Thursday 5 April 2012

Operator chaining

Operator chaining enables repetitive use of some operator on the same object within the same expression.
One typical example is usage of the stream insertion operator (operator<<) on the std::cout stream object:

Insertion operator is left-associative so the statement above can be interpreted (or written) like this:

Another example would be chained assignment operator (operator=) defined for type std::string:

Assignment operator is right-associative so the statement with chain can be interpreted (or written) like this:

If we have some custom class C and want to enable assignment operator chaining we need to make sure that operator= returns a non-const reference to the object it is being executed on. Compiler-generated (implicit) assignment operator meets this requirement so we can rely on it, or, if we need to define our custom assignment operator, we need to make it returning such reference:

Output:

c1 = 987; c2 = 987; c3 = 987

If we want to keep operator= enabled but want to disable chaining, we need to make operator= returning void:

The following code:

will generate compiler error: error C2679: binary '=' : no operator found which takes a right-hand operand of type 'void' (or there is no acceptable conversion), but the following code:

will be fine.

Links and References:
Operator overloading (Wiki)
Why does overloaded assignment operator return reference to class?
Why = Returns a Reference
Overloading assignment operator
C++ Operator Overloading Guidelines

Singleton pattern

This pattern:

  • disables creation of more than one instance of a class
  • provides global access to the class

A long time ago I used to be a big fan of singletons. I would have four, five, six...CThisManager and CThatManager "manager" classes that would be used from everywhere throughout the code without any control. But then I run into some funny problems during their construction and destruction if they would use each other and, design-wise, I realized that singletons were nothing more than just fancy global objects. Why would I allow some class to be accessed from everywhere? Why would I allow so many hidden dependencies? Difficult to follow, difficult to test.

Today, I am using only one class implemented as a singleton: a logger. Logger does not depend on any other class and all other classes (or most of them) are using it. Regarding other "manager" classes: I create a single instance and pass it down to its clients through dependency injection. Dependency is visible and under control. Just like objects' lifetimes.

Anyway, just to make this article complete, I am providing typical singleton implementations. There are many debates on their lifetime, thread- and exception-safety but the general conclusion is that they should be used wise, depending on the context.

Non thread-safe implementation:

Output:

main()
Singleton::getInstance()
Singleton::Singleton()
val_ = 0
Singleton::getInstance()
Singleton::getInstance()
val_ = 3

In order to make this class thread-safe, we need to put its construction inside the critical section:

Thread-safe implementation of Singleton class:


Obviously, critical section member must be defined in the source file (e.g. main.cpp):




Links and References:
Singleton Pattern (Wiki)
Dependency Injection (Wiki)
C++ and the Perils of Double-Checked Locking (Scott Meyers, Andrei Alexandrescu)
Is Meyers implementation of Singleton pattern thread safe? (SO)
C++ Singleton design pattern (SO)
Finding C++ static initialization order problems (SO)
Singleton instance declared as static variable of GetInstance method (SO)
Singletons Are Evil
Singleton: How should it be used (SO)
SINGLETON PATTERN - 1. THREAD SAFETY


Tuesday 3 April 2012

Batch files which delete specific directories and files

I have many projects on my disk and usually, even if not working on them any more, keep IDE-generated user- or IDE session-specific files (with extensions sdf, sbr, suo, ilk...) as well as project build outputs which are in various directories (named Debug, Release, bin, obj...depending on the type of the project). They can use lots of disk space so I created several scripts to automatize removing these directories and files.

Script that deletes all subdirectories of a specific name - delete_dir.bat:

@ECHO OFF
IF "%1" == "" GOTO ERROR1
ECHO Deleting subdirectories with name "%1":
FOR /r /d %%D IN (%1) DO (
   if exist %%D (
      echo Deleting "%%D"
      RMDIR /S /Q "%%D"
   )
)
GOTO END
:ERROR1
ECHO ERROR: Directory name not specified
ECHO Usage: delete_dir.bat <dir_name>
ECHO Script removes all subdirectories with name <dir_name>
:END

Script that deletes all files with a specified extension - delete_files_with_ext.bat:

@ECHO OFF
IF "%1" == "" GOTO ERROR1
ECHO Deleting files with extension "%1":
FOR /F "tokens=*" %%F IN ('dir *.%1 /s /b') DO (
   echo Deleting "%%F"
   del "%%F"
)
GOTO END
:ERROR1
ECHO ERROR: File extension not specified
ECHO Usage: delete_files_with_ext.bat <ext_name>
ECHO Script deletes all files with extension <ext_name> that are contained in the current directory or its subdirectories.
:END

Script that calls previous scripts in order to perform deleting Visual Studio-generated user-specific, IDE-session specific and build output directories and files - clean_all.bat:

@ECHO OFF
ECHO Script removes all subdirectories with names: Debug, Release, ipch, bin, obj and files with extensions sdf, pch, obj
call delete_dir.bat Debug
call delete_dir.bat Release
call delete_dir.bat ipch
call delete_dir.bat bin
call delete_dir.bat obj
call delete_file_ext.bat sdf
call delete_file_ext.bat pch
call delete_file_ext.bat obj

Links and references:
Windows CMD

Monday 2 April 2012

Special class methods for object creation, assignment and destruction

Object in C++ can be created as a:
  • global (on the stack)
  • local (on the stack)
  • dynamic (on the heap)
  • temporary object by explicitly calling its constructor (e.g. passing temporary object to function)
  • temporary object when created implicitly by compiler (e.g. when passing object to function by value)
  • data member of another class (created when another class is created)
  • base class sub-object of the instance of the inherited class (base part)

There are three types of C++ class constructor:
  • default constructor - the one that can be called with no parameters (it does not have any parameters or all parameters have default values); can be implicitly (compiler-) or user-defined; if it is not user-defined and class does not contain const or reference members, it will be created by compiler and will be public
  • non-default constructor - must be called with at least one argument; 
  • copy constructor - called when one object is created from another (already created);  has a single parameter of type A&, const A&, volatile A&, or const volatile A&; can be implicitly (compiler-) or user-defined; if it is not user-defined, it will be created by compiler and will be public; implicit copy-constructor performs shallow copy (memberwise copy); user-defined copy constructor can have additional parameters but they all must have default values

Assignment operator (operator=) assigns value of one (already created) object to another (already created object). If the left-hand side object is being created from the already existing right-hand side object then a copy-constructor will be called (not assignment operator!). operator= can be implicitly (compiler-) or user-defined; if it is not user-defined, it will be created by compiler and will be public; implicit assignment operator performs shallow copy (memberwise copy).

Destructor is another special function that is generated by compiler if it is not provided by the user. When objects created on the stack go out of the scope, their destructor will be called automatically. Destructor must be explicitly called for dynamic objects otherwise we would have memory leaks.

The following example demonstrates relying on compiler-generated copy-constructor and assignment operator:



Output:
goo(): n = 1
c0:
C::C(): n_ = 0
c1:
C::C(): n_ = 1
c2:
c3:
c4:
C::C(): n_ = 0
c5:
C::C(): n_ = 5
C::~C(): n_ = 5
C::~C(): n_ = 1
C::~C(): n_ = 1
C::~C(): n_ = 1
C::~C(): n_ = 1
C::~C(): n_ = 0

The following example demonstrates program output when using user-defined copy-constructor and assignment operator:



Output:
goo(): n = 1
c0:
C::C(): n_ = 0
c1:
C::C(): n_ = 1
c2:
C::C(const C&): rhs.n_ = 1
c3:
C::C(const C&): rhs.n_ = 1
c4:
C::C(): n_ = 0
C::operator=(const C&): rhs.n_ = 1
c5:
C::C(): n_ = 5
C::~C(): n_ = 5
C::~C(): n_ = 1
C::~C(): n_ = 1
C::~C(): n_ = 1
C::~C(): n_ = 1
C::~C(): n_ = 0

One interesting thing happened in line (4) - we would expect copy-constructor to be called here but normal constructor is called instead. This is the consequence of compiler's optimization called Copy elision. When temporary object is meant to be created only to initialize object that is to be constructed, compiler only constructs target object, passing arguments of temporary object constructor to it.

If we want to make our class non-copiable and non-assignable we just have to declare copy-constructor and assignment operator as private, without providing definitions! Our declaration tells compiler not to generate these methods so there will be no implicit definitions. If we call them through public access - the code won't compile. If we try to call them inside class method, the code will compile but linker will complain as it could not find definitions for these two methods.



Compiler output:
(1) error C2248: 'C::C' : cannot access private member declared in class 'C'
(2) error C2248: 'C::C' : cannot access private member declared in class 'C'
(3) error C2248: 'C::C' : cannot access private member declared in class 'C'
(4) error C2248: 'C::C' : cannot access private member declared in class 'C'

Links and references:

Constructors (C++)
Constructor (object-oriented programming) (Wikipedia)
Copy constructor (Wikipedia)
Assignment operator (C++) (Wikipedia)
The Anatomy of the Assignment Operator by Richard Gillam
Destructor (Wikipedia)
Constructors (by Danny Kalev)
Why is the copy constructor not called? (SO)