At some point, you find yourself writing a C++ method that ends up having a lot of repetitious code that is very context-specific to that method. Sure, you could create a private method that encapulates the repetitious code. But, that approach brings about 2 problems that I respectively call class namespace pollution (declarations at class scope level that should be done at a lower or higher scope level) and local context exposure (context declarations at class scope that are specific to only one method). Both are readability issues that can create confusion for later maintainers. Unfortunately, this leads to further degradation of the code.

A good solution that avoids these readability and maintainability problems is a local functor. Recall that a functor is a class with function-call semantics on its instances. This functor is declared, defined, instantiated and utilized completely at method scope and contains the common code called from multiple places in the method. Nice, clean and tight!

In addition to code, the functor can also carry context data in the form of data members.

Example

void SomeClass::SomeMethod()
{
    class LocalFunctor
    {
    public:
        void operator()(....)
        {
            // TODO: Common code here
        }
    };
    ....
    if (/* some condition */)
    {
        ....
        //  implicit instantiation of functor followed by call to
        // overloaded operator () with the arguments
        LocalFunctor(/* args for this case */);
        ....
        // functor instance implicitly destroyed when this
        // block exits
    }
    else if (/* some other condition */)
    {
        ....
        LocalFunctor(/* args for this different case */);
        ....
    }
    ....
}

As you can see, the functor is an ordinary class. The function-call semantics come from overloading the function call operator (). Other than that, most anything a class can do a functor can do.

Writing long constructors that perform a number of operations outside of merely initializing data members is generally discouraged due to the inherant problems with error handling. However, there are times when an object must undergo complex initialization before it can be used.

Generally, I prefer to make such initialization as transparent as possible to simplify usage and eliminate the potential for errors from an improperly initialized object. I prefer the two-phase construction idiom over any other approach due to its usage simplicity and safety. I’ll explain this in detail and provide an example.

The idiom requires that you provide a class public static construction method that takes the appropriate arguments and returns an instance to the class. I prefer to call it Create. Like a constructor, the static construction method can be overloaded if necessary. However, unlike a constructor, it can safely throw exceptions if needed and provide return values.

The idiom also requires that your actual constructor(s) is(are) either protected or private. This ensures that an instance can be created only through your static construction method.

Internally, the idiom’s implementation requires that all constructors do only simple data member initialization that is guaranteed to succeed. Initialization of complex data members and other initialization logic that has the potential to fail is contained in a protected or private initializer method. I prefer to call it construct or _construct depending upon its visibility.

The static construction method creates the appropriate instance of the object. It then calls the internal initializer method to carry out the complex and/or failure-potential initialization code. Based upon the success or failure of the initializer, the construction method will either return the new instance or clean up and return an error or throw an exception.

An example of two-phase construction:

class SomeComplexClass
{
public:
    static SomeComplexClass * Create();
    ....
private:
    SomeComplexClass();
    void _construct();
    ....
};
....
SomeComplexClass * SomeComplexClass::Create()
{
    SomeComplexClass * pNewObj = NULL;
    try
    {
        // create a new instance first
        pNewObj = new SomeComplexClass();

        // now call the internal initializer and finish building the object
        pNewObj->_construct();
    }
    catch (SomeException & rEx)
    {
        // clean up the object
        delete pNewObj;
        pNewObj = NULL;

        // pass the exception on
        throw;
    }

    return pNewObj;
}
....
void SomeComplexClass::_construct()
{
    ....
    // perform some complex initialization here that can fail
    ....
}
....

Usage of this idiom is straight-forward:

....
try
{
    SomeComplexClass * pObj = SomeComplexClass::Create();
    ....
    // use the object here
    ....
    // clean up
    delete pObj;
    pObj = NULL;
}
catch (SomeException & rEx)
{
    // TODO: Do some error handling here.
}
....

There are cases where you must provide a pointer to an instance of a C++ class but you need to prevent the object from being destroyed via operator delete.

The preferred approach is to make the class destructor either protected or private. Doing this will cause the compiler to generate an error when calling delete on any class instance.

A second way to prevent deletion is to overload operator delete at the class level and provide either no implementation or an empty implementation. In the former case, a compiler error will occur when attempting to call delete. If you take this overloading approach, you must also be sure to overload operator new as well lest you accidentally allow for the creation of undeleteable objects!

This last technique is best with a class that is not designed to be dynamically constructed, but rather declared as a global, class static or stack variable. It can also be employed when compatibility with existing templates is needed.

To quickly initialize a data structure with all zeros (i.e. zero’ed memory), do this:

SOME_STRUCT myStruct = { NULL };

Glossary of Terms

Posted: July 22, 2008 in General
Tags: , ,

These days, the software world is flush with acronyms, names and other terminology.  This is my “cheat sheet” of terms.  Check back often – it lives!

My sed one-liners

Posted: July 2, 2008 in Tools
Tags: , , ,

Being the hardcore geek that I am, I inevitably find a need to use the GNU stream editor (aka “sed”) for some complex text conversion/filtering from the command lines.

Below is a list of my sed one-liners by category.  I normally use GNU sed from the GnuWin32 project under Windows, but most of these one-liners can be adapted to other seds.

General Text Filtering

  • Remove all newlines from an input file and emit as one giant long text string.
sed -n ":top;$!{N;s/\n//g;t top};$p" input.txt > output.txt
  • Filter all lines from an input file starting with a ‘#’ character (i.e. commented-out line).
sed -n "/^#/!p" input.txt > output.txt

More to come…

If you regularly develop extensions to IE (like I do), at some point you’ll need (or want) to extend the user-agent header string that IE sends up to web servers.  Fortunately, all you have to do is put a few entries in the registry.

Let’s say you want to add the token “MyIEExtension 1.0.0.0″ to IE’s user-agent string for the current user. Just enter it as the name of a string value (without the quotes, of course) under the registry key:

HKEY_CURRENT_USER\

    SOFTWARE\

        Microsoft\

            Windows\

                CurrentVersion\

                    Internet Settings\

                        User Agent\

                            Post Platform

If you want the token to be added to all users, use the same path except put it under HKEY_LOCAL_MACHINE.

Want to know more? Go to “Understanding User-Agent Strings” at MSDN.

Welcome to my blog!

Posted: December 19, 2007 in General
Tags: , , , , ,

Well, hello and welcome to my humble blog.  I’m Dylan Greiner and I’m a professional software engineer/developer/architect.  Without going into too much excruciating detail, I have been developing commercial and consumer software for 20-odd years now.  Most of my work has been done under Windows, starting all the way back in 2.0!  These days, I also do website development and back-end systems development.  My weapons of choice are C++, C#, Java, Javascript, HTML, XML…with the odd diversion into Lisp, Prolog and other lingua inusitatus.

What’s this blog about?  This is where I’ll publish interesting tidbits, learnings, rants, musings and other chatter about software programming and development things I encounter.

So, let’s get to it…