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)

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.

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)

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

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

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.