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)