When working on an application I wanted that the drawn text is always well readable on the background. The background color can be changed by the user. In order not have same or similar colors for background and foreground I directly thought of contrasting colors.

I just binded background color and value of the font color to each other. In other words the foreground color is set when changing the background in dependency to the value of background color.

I didn’t want to withhold you the function I used, it’s a nice reusable snippet of code:

#define TOLERANCE 0x40
 
int GetContrastColor (int cBg)
{
        if (
                abs(((cBg      ) & 0xFF) - 0x80) <= TOLERANCE &&
                abs(((cBg >>  8) & 0xFF) - 0x80) <= TOLERANCE &&
                abs(((cBg >> 16) & 0xFF) - 0x80) <= TOLERANCE
 
        ) return (0x7F7F7F + cBg) & 0xFFFFFF;
        else return cBg ^ 0xFFFFFF;
}

It takes an integer for the background color that has 0xRRGGBB or 0xBBGGRR format.
The color is made up of three parts (red, green, blue), each part is tested if it’s close to 0×80 (128 in decimal). If all three match 0x7F7F7F is added to the color to get the best possible different color.

For the comparison with the TOLERANCE absolut value the function abs is needed.
abs(x) takes and integer or long value and returns the absolute value of parameter it is given.
If the given value is complex, it returns the complex modulus (magnitude), which is the same as

sqrt(real(X).^2 + imag(X).^2)

It’s definied in math.h, but to verify that the function also works without math header you can add this ifndef-block:

#ifndef abs
        #define abs(x)          ((x) < 0 ? (-(x)) : (x))
#endif

Finally it’s important to prevent an overflow (range only goes from 0x000000 to 0xFFFFFF). The result simply is ANDed with 0xFFFFFF.

Today I’d like to show you the feature boost libraries provides I do like best.
Smart Pointers are much more smarter than usual pointers - althougth they are not more complicated.

Boost smart pointer library provides five smart pointer classes which behave much like built-in C++ pointers except that they automatically delete the object pointed to at the appropriate time.

• scoped_ptr - (scoped_ptr.hpp)

The scoped_ptr class template stores a pointer to a dynamically allocated object. (Almost) everything the object pointed to is guaranteed to be deleted, either on destruction of the scoped_ptr, or via an explicit reset.

• scoped_array - [scoped_array.hpp]

Almost the same as scoped_ptr but it stores to a dynamically allocated array. It cannot correctly hold a pointer to a single object. See scoped_ptr for that usage.

• shared_ptr - [shared_ptr.hpp]

shared_ptr can be used in C++ Standard Library containers.

• shared_array - [shared_array.hpp]

Almost the same as shared_ptr but for stores to a dynamically allocated array. Can be used in STL containers.

• weak_ptr - [weak_ptr.hpp]

The weak_ptr class template stores a “weak reference” to an object that’s already managed by a shared_ptr. To access the object, a weak_ptr can be converted to a shared_ptr.

• intrusive_ptr - [intrusive_ptr.hpp]

A light pointer with an embedded reference count. Every new intrusive_ptr instance increments the reference count.

The scoped_ptr class is the simplest one, it just ensures deletion when a pointer becomes invalid because of being no longer needed.

Instead of the usual way…

void Example()
{
  CMyClass* pPtr(new CMyClass);
  if (!pPtr->Call())
  {
    delete pPtr;
    return;
  }
 
  pPtr->Use();
  delete pPtr;
}

…you can do it like this:

void Example()
{
  boost::scoped_ptr<CMyClass> pPtr(new CMyClass);
 
  if (!pPtr->Call())
    return;    
 
  pPtr->Use();
}

Almost everything concerning memory management of the object is done automatically. You don’t have to care about - this can reduce the error rate a lot. The loss of performance is mostly not really noticeable - it’s about the same fast/slow as normal new/delete.

It’s not possible to use it for STL container elements, more than one pointer on an object, or other allocators than new and delete.

If you need more than one smart pointer to an object, you have to define a criterion when the object is no longer needed and can be destroyed.
That’s what shared_ptr is for. A reference counter holds the number of pointers that have a reference to one object. Every object has it’s own counter. If a new pointer is added to the object, the counter increments and when a destructor is called it decrements. If the counter becomes zero the objects at once gets deleted.

void Example()
{
  boost::shared_ptr<CMyClass> pPtr1(new CMyClass);
 
  boost::shared_ptr<CMyClass> pPtr2= myclass;
 
  pPtr1.reset();
}

An object (in my testcase an object of CMyClass) gets stored on the heap and pPtr1 points on it. Later another pointer points on it. Then pPtr1 gets reset (same as set to NULL). When the last existing reference of CMyClass gets invalid the object will be deleted.

Whenever you need to have a container of pointers to heap-allocated objects, there is usually only one exception-safe way: to make a container of smart pointers like boost’s shared_ptr.

Many container classes (e.g. STL container) need a copy-constructor for adding existing elements to the object list. When storing complex classes you usually use an container of pointers.

std::vector<CMyClass*> list;
list.push_back( new CMyClass(333,"sample") ); 	
list.push_back( new CMyClass(666,"word") );

A disadvantage of that is that you have to care yourself about the deletion of objects.
For cases like that boost provides a shared_ptr template class.

typedef boost::shared_ptr<CMyClass> CMyClassPtr;
std::vector<CMyClassPtr> list;
list.push_back( CMyClassPtr(new CMyClassPtr(333,"sample")) );
list.push_back( CMyClassPtr(new CMyClassPtr(666,"word")) );

Now the stored objects in the list get freed (deleted) with the list.

It’s also possible to use shared_ptr for void. It can act as a generic object pointer similar to void*. A shared_ptr can be handled much the same manner as a raw void* which is used to temporarily strip type information from an object pointer.

When using shared_ptr you might notice that they can be big and slow ’cause every shared_ptr needs it’s own tracker. To get rid of performance loss your choice should be intrusive_ptr which is something like the lightweight version of shared_ptr but you have to write the counter mechanism yourself.

In boost mailinggroups I found a thread-save implementation that is also compatible to the rest of the boost standard.

void intrusive_ptr_add_ref(CRefCounted * p)
{
   _InterlockedIncrement(&(p->references));
}
 
void intrusive_ptr_release(CRefCounted * p)
{
  if (_InterlockedDecrement(&(p->references)) == 0)
  delete p;
}

Important to know is that boost differs between strong and weak pointers. shared_ptr stands for a strong pointer ’cause it avoids deletion ahead of time.

The weak_ptr is, as the name says, the implementation for a weak pointer. A weak reference can be get from a strong reference. If the strong does no more exist to that time the weak reference is just 0.

shared_ptr<double> pStrong(new double(5.562));
weak_ptr<double> pWeak(pStrong);
 
if(double* reference = pWeak.get())
{
    reference->SomeFunc();
}

A weak_ptr does not provide any accessing method or operator (operator->, or get()-method).
To convert a weak_ptr to shared_ptr you can use the lock()-method.

weak_ptr<X> target;
 
if(shared_ptr<X> pPtr1 = target.lock())
{
  pPtr1->SomeFunc();
}
else
{
  // target lost (e.g. expired), acquire a new one
}

Things you’d know about smart pointers:

• No circular references

If you have two objects referencing each other through a reference counting pointer, they are never deleted. To break those circle the usage of weak_ptr is recommented.

• Assign a newly constructed instance to a smart pointer immediately

Instances should always get assigned to a smart pointer at once. An assigned smart pointer holds an object that you don’t have to care once again. This helps to not accidentally delete an object that is still referenced by a smart pointer. When not doing this it can end up with an invalid reference count.

• Convert carefully

Always be carful with convertion between real pointers and smart pointers. Smart pointers are no more real pointers.

If you keep in mind these points nothing should go fatally wrong.

use_count returns the number of shared_ptr(s) that point on an object. Besides the detection whether an object is needed anymore and maybe can be destroyed, it has the possibility to verify that an object is valid. However it’s just provided as a testing and debugging aid rather than for use in productive code.

if(pObj.use_count() > -1) { oObj->MakeMeHappy() }

The < operator doesn’t compare the stored pointers, instead it tells you about the ownership.
It enables that you can question if p1 shares ownership with p2.
A valid expression is:

if( !(p1 < p2) && !(p2 < p1) ) {}

You can have diverse reason why using smart pointers. Some common reasons can be:

• Bug prevention

As so often the prevention of bugs justifies the effort of bringing in a new technique. Automatic cleanup reduces the chance that the programmer forgets about cleanup an object.

• No need for NULL

The constructor of smart pointer initializes the pointer to NULL.

• Exception savety

Imagine a function called from a dynamic generated object fails during run progress. In most cases the object from where the function was called never gets deleted. If we’re lucky, this leads only to memory leaks.

• Smart garbage collector

C++ in its standard doesn’t have a garbage collector. Smart pointers can be used for that purpose.

Link:
Smart Pointers Overview on Boost C++ Libraries Website

You often need tracing for debugging a application or just to keep an eye on the progress (e.g. drawing / data reading or something similar).
I mostly use this simple function or a bit modified one if needed:

void Debugging::Trace(char* szTmp, ...)
{
    char msgbuf[256];
    my_list args;
    my_start(args, szTmp);
    vsnprintf(msgbuf, 255, szTmp, args);
    my_end(args) ;
 
    fprintf(stdout, "Trace: %s\n", msgbuf);
}

By the way, for me tracing is sometimes the only way when debugging drawing progress ’cause as the debugger appears the frame for drawing gets hidden. When the drawing frame is shown again it forces a redraw. That really sucks when trying to step through OnDraw/OnPaint events…
To improve tracing for more detailed results you can use magic variables which hold some useful information.

The probably best known of these is __func__, which is part of the C99 standard.
It’s equal to __FUNCTION__ and hold the name of the current function. For maximum portability it’s recommented to use __func__.

When programming in C __PRETTY_FUNCTION__ is just another alias for __FUNCTION__, but when using C++ it gives plenty of information about the function. Instead of just holding the name it holds also its signature:

bool HasValue(int x)
{
 cout << "__FUNCTION__: " << __FUNCTION__ << endl;
 cout << "__PRETTY_FUNCTION__: " << __PRETTY_FUNCTION__ << endl;
 
 return true;
}

Prints:

__FUNCTION__: HasValue
__PRETTY_FUNCTION__: bool HasValue(int)

The last two are very common but significant for hard to debug codeparts like those you sometimes have for example in multi-threaded applications.

__LINE__ is for the current line and __FILE__ as expected for the source file.

I usually just need them for asserts:

if ( !assert(mainobject) )
    throwMsg( "Assertion failed on line %d of file %s\n",
                        __LINE__, __FILE__ );

It maybe relevant for you to know that I didn’t test those non-preprocessor makros on many different compilers. Most of them do work with VS compiler, all of them with GCC, but I’m pretty sure that compilers like Borland provide very similar makros.

Exclusive or is a type of logical disjunction on two operands that results in a value of “true” if and only if exactly one of the operands has a value of “true”.

The truth table is as follows:

a | b | a XOR b
—-+—-+———
0 | 0 | 1
0 | 1 | 0
1 | 0 | 0
1 | 1 | 1

• 1 xor 1 = 0
• 1 xor 0 = 1
• 1110 xor 1001 = 0111

XOR can be used to swap two numeric variables, using the XOR swap algorithm; however it’s regarded as more of a curiosity and not encouraged in practice.

As you know ^ declares XOR in C/C++.

void XorSwap(int* x, int* y)
{
    if (x != y) {
        *x ^= *y; // the right-most expression
        *y ^= *x; // the middle expression
        *x ^= *y; // the left-most expression
    }
}

A reson why you’d better avoid excessive use of XOR is that on modern CPUs, the XOR technique is considerably slower than using a temporary variable to do swapping. One reason is that modern CPUs strive to execute commands in parallel. In the XOR technique, the inputs to each operation depend on the results of the previous operation, so they must be executed in strictly sequential order.

XOR can simply be used for an easy to understand encryption algorithm.
In an XOR encryption program each letter of the key and the input(e.g text) gets converted to ascii, then to binary (0’s and 1’s). The 0 or 1 from the key is xored against the 0 or 1 of the text.

Consider that function:

string XOR(string value,string key)
{
    string retval(value);
 
    short unsigned int klen=key.length();
    short unsigned int vlen=value.length();
    short unsigned int k=0;
    short unsigned int v=0;
 
    for(v;v<vlen;v++)
    {
        retval[v] = value[v] ^ key[k];
        k=(++k < klen ? k : 0);
    }
 
    return retval;
}

It can be used like this:

string value("Hello World");
string key("key");
 
cout << "Plain text: " << value << "\n\n";
value = XOR(value,key);
cout << "Cipher text: " << value << "\n\n";
value = XOR(value,key);
cout << "Decrypted text: " <<value << std::endl;

XORing is used in many cryptographic algorithms to produce a ciphertext from the key and plaintext - especially in so-called “stream ciphers”.
You might have noticed that this encryption is similar to Vigenère Cipher method and basically an enhanced version of it. XOR encryption takes the result of XORing the ascii number of the value and the number of the key value to produce a crypted value. Vigenère Cipher takes the result of adding (modulo 255) the ascii number of the value to the ascii number of value to produce a crypted value. That’s the reason why XOR encryption is more attractive than the addition function XOR is a symmetric operation, whereas addition is not.

If you’d like to use XOR encryption I would therefore advice you that function, cause it’s valid C++ and uses a template. You don’t have to care about datatypes you like to crypt/encrypt.

template<typename>
void BetterXor(const T& value, const T& key, T& result)
{
   typedef unsigned char byte;
 
   const byte* pvalue = reinterpret_cast<const>(&value);
   const byte* pkey = reinterpret_cast<const>(&key);
 
   byte* pResult = reinterpret_cast[byte*](&result);
 
   for( size_t i = 0; i < sizeof(value) && i < sizeof(key); ++i )
      pResult[i] = pvalue[i] ^ pkey[i];
}

Nevertheless if you need strong encryption, DO NOT USE XOR algorithms. If true security is an issue then you will want to use something else.

I assume that all C++ programmers always wonder how the clearest way declaring constants might be when using them. It’s every again time a really vexatious issue…

A constant is similar to a variable in the sense of representing a memory location (or simply, a value). As you probably know, it is different from a normal variable and cannot change it’s value in the program - it must stay for ever stay constant. In general, constants are useful for preventing program bugs and logical errors.

There are two main ways of defining constants in C++, and I’ll review and compare both of them, seeing their advantages and disadvantages.

Let’s see the good old, C way first:

#define Pi 3.1415

Maybe better would be:

const float fPi = 3.1415;

First think we can notice here, is that we defined a type for the constant, float. This allows some type checking by the compiler.
Another advantage is that the scope of the constant can be definied, you can set it either private or global, while using the first method (#define), the constant can only be globally declared.

If you like to contradict to me you’d probably say that for example the suffix “L” can be added to the #define and the variable can be used as a long data type :

#define Pi 3.1415L

Although this is a better way than declaring it without a type information you’d prefer the const keyword just for the reason that it’s not old c style.

Consider the following call to function myPow():

void func()
{
   int a = 1;
   int b = 2;
   double c = myPow(x, y);
}
 
double myPow(int a, int b)
{
    return pow(a,b);
}

Assuming a typical C++ implementation that has registers and a stack, the registers and parameters get written to the stack just before the call to myPow(), then the parameters get read from the stack inside myPow() and read again to restore the registers while MyPow() returns to func(). But that’s a lot of unnecessary reading and writing, especially in cases when the compiler is able to use registers for variables a and b: each variable could get written twice (as a register and also as a parameter) and read twice (when used within myPow() and to restore the registers during the return to func()).

If the compiler inline-expands the call to myPow(), all those memory operations could vanish. The registers wouldn’t need to get written or read since there wouldn’t be a function call, and the parameters wouldn’t need to get written or read since the optimizer would know they’re already in registers.

Inlining is one of the easiest optimizations to use in C++ and it can result in the most dramatic improvements in execution speed. The main thing to know is when you should inline a method and when you shouldn’t inline.
There is always a trade-off between code size and execution speed when inlining. In general, small methods (for example, accessors) should be inlined and large methods should not be inlined.

The compiler preprocessor can be used to implement conditional inlining. This is useful so that during testing the code is easier to debug. But for compiling production code, there are no changes to be made to the source code. This is implemented by using a preprocessor macro called INLINE. Inlined code is defined within #ifdef INLINE ... #endif code blocks. Similarly, non-inlined code is defined within #ifndef INLINE ... #endif code blocks. Then to compile using inlined code, you tell the compiler to treat INLINE as defined. (-DINLINE with G++)

GCC implements three different semantics of declaring a function inline. One is available with -std=gnu89, another when -std=c99 or -std=gnu99, and the third is used when compiling C++ (usage of G++).

To declare a function inline, use the inline keyword in its declaration, like this:

static inline int inc(int* a)
{
 (*a)++;
}

When a function is both inline and static, if all calls to the function are integrated into the caller, and the function’s address is never used, then the function’s own assembler code is never referenced. In this case, GCC does not actually output assembler code for the function, unless you specify the option -fkeep-inline-functions.

As required by ISO C++, GCC considers member functions defined within the body of a class to be marked inline even if they are not explicitly declared with the inline keyword. You can override this with -fno-default-inline.

Before putting great effort into ‘inline’ you’d know that it’s ignored by many C and C++ compilers, as the compiler can generally make a better decision about what to inline and what not to inline than the programmer.

Finally, as systems got better, compilers got into the act, and started doing enough analysis to make good decisions on their own without ‘inline’ keyword.
Inline was always defined as a hint, not a requirement. If you are damn sure that you have a function that needs to be inlined VC++ (V6.0) provides a makro that forces inlining. The __forceinline keyword overrides the cost/benefit analysis and relies on the judgment of the programmer instead.