Josh Bialkowski (Posts about C++ Discoveries and Notes)

python-like kwargs in C++

Josh Bialkowski — Mon, 16 Jun 2014 03:18:55 GMT

When dealing with functions that have lots of optional parameters, or at least for which resonable defaults are readily available, it's often a bit of a frustration in C++. Generally defaults are specified during a function declaration as in:

double BinarySearch(std::function fn,
                    int max_depth = 16, double epsilon = 1e-9,
                    double lower_bound = 0, double upper_bound = 100);

And then if we call BinarySearch with only one parameter then the call will use the default values for the rest. But what if I want to specify custom bound, and use the defaults for the other parameters? Admittedly, this is a somewhat contrived example since bounds are less likely to be optional then the others, and we could reorder them better going from most-likely-to-be- specified to least, but it's easy to see how something more flexible would be desirable.

Consider then the following two code snippets. Which is more readable?

First snippet:

double solution = BinarySearch(fn, 0, 100);

Second snippet:

double solution = BinarySearch(fn, lower_bound = 0, upper_bound = 100);

I really like the way that optional arguments work in python with kwargs. I'd love to have that same kind of functionality in C++. kwargs.h implements one mechanism of achieving this.

How does it work

kwargs takes advantage of variadic templates in C++ to build up a single data structure which contains all of the optional parameters (I'll call this a "parameter pack"). Each optional parameter of type T is stored in a structure of type Arg<tag,T> where tag is a unique numeric identifier associated with a particular optional argument key.

The parameter pack data structure derives from Arg<tag,T> for each (tag,T) pair that shows up in the list of optional arguments.

Overloading of the assignment (=) operator gives us an opportunity for building the (tag,T) pairs within the parameter list of the function call.

Get it

See the source and doxygen on github.

Example

I'll conclude with an example usage:

#include 
#include "kwargs.h"

// these are tags which will uniquely identify the arguments in a parameter
// pack
enum Keys {
  c_tag,
  d_tag
};

// global symbols used as keys in list of kwargs
kw::Key c_key;
kw::Key d_key;

// a function taking kwargs parameter pack
template 
void foo(int a, int b, Args… kwargs) {
  // first, we construct the parameter pack from the parameter pack
  kw::ParamPack params(kwargs…);

  std::cout << "foo:\n--------"
            << "\na: " << a
            << "\nb: " << b
  // We can attempt to retrieve a key while providing a default fallback value.
  // If c_key is in kwargs then this will return the value associated with
  // that key, and will have the correct type. Note that the type of the default
  // parameter in this case is const char*.
            << "\nc: " << kw::Get(params,c_key,"null");
  // We can also do stuff conditionally based on whether or not arg exists in
  // the param pack. We still need to provide a default value, since we need to
  // know the return type of the Get function when the key is not in kwargs.
  // In this case, the default value wont ever be used at runtime.
  if( kw::ContainsTag::result ) {
    std::cout << "\nd: " << kw::Get(params,d_key,0);
  }

  std::cout << "\n\n";
}

int main( int argc, char** argv )
{
  foo(1, 2);
  foo(1, 2, c_key=3);
  foo(1, 2, c_key=3, d_key=4);
  foo(1, 2, d_key=4);
}

Range Based for-loops in C++11

Josh Bialkowski — Fri, 02 Aug 2013 14:07:04 GMT

One of the new features of C++11 that is a complete win in my opinion is the support for range-based for-loop syntax. Judicious use allows for significantly more compact and readable code. However, one thing that is lacking from this feature is the ability to iterate over a range of integers. This isn't a problem, however, because it is very easy to implement.

// This file compiles as a single unit, you can test it by saving it 
// as range_for.cpp and compiling with 
// g++ -std=c++11 -o range_for range_for.cpp
// Adjust the interface as you see fit

// Implementation (put this in a header)
// --------------------------------------------


/// encapsulates a range of integral numbers for use in a c++11 range-based for 
/// loop
template< typename T>
struct Range
{
    /// the begin() and end() functions must return an iterator with a specific
    /// interface
    struct Iterator
    {
        T val;  ///< storage for the actual value

        /// implicit construction from the value type
        Iterator( T val ):val(val){}

        /// the range-based for loops attempt to dereference an iterator using
        /// this operator
        T operator*(){ return val; }

        /// the range-based for loops quit when the comparison of iter != end
        /// returns false
        bool operator !=( T other ){ return val != other; }

        /// iterators in a range-based for loop must have the prefix increment
        /// operator
        Iterator& operator++(){ ++val; return *this; }

        /// we likely want to implicitly convert to the value type
        operator T(){ return val; }
    };

    private:
        T m_begin;  ///< the first integral value
        T m_end;    ///< one past the last integral value

    public:
        /// construct a range [begin, end)
        Range( T begin, T end ):
            m_begin(begin),
            m_end(end)
        {}

        /// interface required by range-based for loop
        Iterator begin(){ return m_begin; }

        /// interface required by range-based for loop
        Iterator end()  { return m_end;   }
};


/// return an object which can be used in a range-based for loop
template 
Range range( T begin, T end )
{
    return Range(begin,end);
}




// Usage 
// ---------------------------------------------

#include 

int main(int argc, char** argv)
{
    std::cout << "Static ranges\n----------------\n";
    std::cout << "\nint:\n";
    for( int i : range(1,5) )
        std::cout << "   i: " << i << "\n";

    std::cout << "\nunsigned int:\n";
    for( unsigned int i : range(1u,5u) )
        std::cout << "   i: " << i << "\n";

    std::cout << "\nlong:\n";
    for( long i : range(1L,5L) )
        std::cout << "   i: " << i << "\n";

    std::cout << "\nDynamic range (program args)\n----------------\n";
    for( int i : range(0,argc) )
        std::cout << i << " : " << argv[i] << "\n";

    return 0;
}

The range<T>( T begin, T end ) function template returns a Range&ltT> object which supports the required interface for range-based loops. It has a begin and end method, both of which return an iterator. The iterator has the same storage says as the integral type used to instantiate the templates. It is implicitly convertable to and from the integral type. Futhermore, it has the prefix ++ operator, and can be "dereferenced" to get the stored integral value.

The implementation is likely to yield compiled code equivalent to a normal for loop.

The output of the demo program above is:

josh@Nadie:~/Desktop$ g++ -std=c++11 -o range_for range_for.cpp 
josh@Nadie:~/Desktop$ ./range_for arg1 arg2 arg3 arg4 arg5
Static ranges
-----------

int:
   i: 1
   i: 2
   i: 3
   i: 4

unsigned int:
   i: 1
   i: 2
   i: 3
   i: 4

long:
   i: 1
   i: 2
   i: 3
   i: 4

Dynamic range (program args)
-----------
0 : ./range_for
1 : arg1
2 : arg2
3 : arg3
4 : arg4
5 : arg5
josh@Nadie:~/Desktop$

C++ FreeFontStack

Josh Bialkowski — Wed, 06 Feb 2013 21:58:20 GMT

I've been doing a lot of research into free software font technologies and as a consequence I've been playing around a lot with Freetype2 and Fontconfig (actually the library interface libfontconfig). These are "straight up" c-libraries and so I (personally) find the interface a bit "clunky" in C++ code. Don't get me wrong, I wouldn't presume to criticize their design as it is clear the authors/maintainers are far more knowledgeable about this stuff than I am… but from a users perspective I desire a bit more.

So… I've written some C++ wrappers for freetype2 and fontconfig. The main goals in these projects are:

Don't change the usage patterns of the library
Provide a pointer-like type which automatically performs reference counting for reference counted objects
Provide a pointer-like type which exposes member-functions where relevant
Provide a pointer-like type which still allows access to the public data members of the underlying structures
Allow access to the native c-pointer for use in parts of the library that I haven't finished wrapping

So far… cppfontconfig wraps more or less all the functionality of libfontconfig. I'd still like to add some interface for assignment by touples in order to grab error codes when desired without the error being part of the function signature. Perhaps in the future.

cppfreetype isn't nearly as complete (freetype2 is a much larger library). I still haven't decided the appropriate way to deal with structures which are normally stack allocated. I do however have wrappers for FT_Face, FT_GlyphSlot, and an iterface for iterating over contours and points in an FT_Outline.

These libraries are released as GPLv3. I have public git repositories and publicly accessible doxygen documentation available in the links below. No bug tracker though since I'm giving up on redmine.

cppfontconfig - Simple C++ interface into fontconfig

Josh Bialkowski — Sun, 29 Jul 2012 19:43:34 GMT

Lately I've been trying to learn how to use (and I mean really use) the open source font stack. Since I tend to greatly prefer c++ over c, as part of the process of learning these libraries I figured I'd workout API wrappers. Since the font stack libraries are generally object oriented, I figured a C++ wrapper around these would be easy to accomplish.

As a start, I wrote cppfontconfig, a C++ wrapper around font config.

github

I'm not sure if the design is good or if it's even useful, I guess we'll see.

Exception Streams in C++

Josh Bialkowski — Sat, 02 Jun 2012 15:37:27 GMT

Here's a short but handy C++ Snippet. I was looking for a way to quickly generate runtime exceptions with useful information about the current program state. My process was:

Create a string stream
Build the message
Throw the exception using the string from the stream

I felt like this was particularly cumbersome and quite annoying, especially for doing things like string parsing or SQL because there are a lot of places in the code where error checking is required.

In any case, I came up with this simple little class tempate which sits in a single header file and is included in the cpp file where it is to be used.

#ifndef _UTILITY_EXCEPTIONSTREAM_H_
#define _UTILITY_EXCEPTIONSTREAM_H_

#include 
#include 

namespace utility   {

/// used to simplify the process of generating an exception message
/**
 *  Derives from stringstream so provides an ostream interface, but throws
 *  an exception with the contents of the string when the object is destroyed
 *
 *  \tparam Exception_t must be an exception type which accepts a
 *                      const char* in it's constructor
 *
 */
template 
class ExceptionStream :
    public std::stringstream
{
    public:
        ~ExceptionStream()
        {
            throw Exception_t( str().c_str() );
        }

        std::ostream& operator()()
        {
            return *this;
        }
};


typedef ExceptionStream ex;


} /* namespace utility */
#endif /* EXCEPTIONSTREAM_H_ */

Usage is like this:

ex fExp;

fExp = evalf( m_expression["radius"].subs(m_x == iRadius));
if( is_a(fExp) )
    radius= ex_to(fExp).to_double();
else
{
    utility::ex()() << "GiNaC failed to parse radius expression: "
                    << fExp;
}

Here I'm using GiNaC to parse a string into a mathematical expression. If the process fails I want to throw a runtime exception (typedef'ed as utility::ex).

The class derives from string stream so it works just like a string stream… building a string by catting together the RHS of all the string operators. The magic is that the destructor for the class throws an exception. The message for the exception is the string that was built.

It's a very handy time saver… though I'm not sure if it's actually safe to use. If the destructor throws an exception, is the object memory still freed?

My cmake Bootstrap Process

Josh Bialkowski — Mon, 06 Jun 2011 19:51:13 GMT

I've been using eclipse as an IDE for a long time. For Java, eclipse is ridiculously beautiful. It almost writes your programs for you. Eclipse CDT is lacking a some features I would really like to see, and it's impossible to understand the code base and write plugins (and so… I have not implemented anything myself) however, as a traditionalist, I like my IDE to work on top of the command line tools, not in place of them. Also, I like that there are PHP, Javascript, XML, Perl, and Latex plugins… which means that my life is much easier given that I work on all my projects with the same familiar interface.

Lately, I've also started using CMake (instead of my ridiculously complicated but super-stream-lined personal makefile system). The CMake project generator for Eclipse is really awesome, and I'm completely sold on using cmake now. However, creating a new project from within eclipse doesn't work as well as I'd like. Also, I have a couple of other files that I generally include in every project, so I've started bootstrapping my projects by using a template directory, and a pair of scripts.

Consequently I find myself repeating several tasks every time I start a new project… just like when I was starting off with programming.

copy an old project
rip out all the unnecessary classes
chop of the CMakeLists.txt files to get it down to a bare bones
initialize a git repository
make an initial commit
create a build directory
export my development root directory so cmake can find it
call cmake (which, for eclipse projects, is a chore)

All this gets a little tedious. I'd really like to have an eclipse plugin that does this… but I'm not that skilled in the advanced features of Eclipse, so I started automating this with a script. Most of the things that I've been working on lately have been Gtkmm programs. So I've created a barebones project directory with stubs for all of the common parts I need:

all the gtkmm cmake find modules
a stub CMakeFile.txt
a stub glade file
a stub UI xml file
a simple main.cpp
one class called Application to load the glade file and the UI
some git helper scripts
a .gitignore file
a doxyfile
a doxygen mainpage file
a bootstrap script

I also wrote a script which does all of the redundant tasks mentioned above. I'll go through all the files in the template directory and the new project script describing what they're for. The template files can be downloaded as a gzipped tarball here. The new project script can be retrieved here

Scripts I Always Use

countlines.pl

This is a simple script that I use to count the number of lines of code in a project. It reports the total number of lines of code as a raw number, exluding whitespace, and exluding comments.

my @extensions  = ("cpp","h","hpp");
my @directories = ("src");
my @filelist;

foreach $directory( @directories )
{
    print "searching $directoryn";
    foreach $extension( @extensions )
    {
        print "   for *.$extensionn";
        open INLIST, " find $directory -name '*.$extension' |";
        while()
        {
            chomp;
            push(@filelist, $_);
        }
        close INLIST;
    }
}

$totallines     = 0;
$written        = 0;
$noncomment     = 0;

my $blockcomment    = 0;
my $comment         = 0;

print "parsing filesn";

foreach $file( @filelist )
{
    print "   $filen";
    open INFILE, "./" . $file or die "failed to open" . $file . "n";

    while()
    {
        chomp;
        s/s//g;

        $totallines++;

        $comment        = 0;
        if( /^(//)/ )   {$comment        = 1;  }
        if( /(/*)/ )    {$blockcomment   = 1;  }
        if( /(*/)/ )    {$blockcomment   = 0;  }

        $noncomment++   unless( length($_) == 0 || $comment || $blockcomment );
        $written++      unless( length($_) == 0 );
    }

    close INFILE;
}

print "n";
print "total:       " . $totallines     . "n";
print "written:     " . $written        . "n";
print "noncomment:  " . $noncomment     . "n";

$dummy = <>;

logChanges.sh

This is a helper script I use to format my git commits the way I like. I like to have a list of all the files changed at each commit stored right in the log. This script strips the comment hashes from the git status report.

#!/bin/bash

echo ""
echo "Files Changed:"
git status | sed -e "s/#t//" -e "/^#/d"

commitAll.sh

This is a script that I call to commit all changes to the git repository. It calls logChanges.sh to generate a changelog changes.txt, and then opens nano to add a nice comment to the log entry.

#!/bin/bash

git add -A
bash logChanges.sh > changes.txt
nano changes.txt
git commit -F changes.txt

bootstrap.sh

This is a script that calls cmake from the build directory. It prepends $HOME/Codes/devroot to the CMake prefix path so that it can find all of my develepment libraries. It adds the corresponding lib/pkgconfig directory to the PKG_CONFIG_PATH variable so that pkg-config looks for my development library versions before checking the system versions. It also sets the prefix- path directory to be the install prefix. Then it calls cmake to generate Eclipse CDT4 project files, along with a source project and the option to build with debug flags.

#!/bin/bash

export PREFIX=$HOME/Codes/devroot

export SCRIPT_DIR=`dirname $0`;
export CMAKE_PREFIX_PATH=$PREFIX:CMAKE_PREFIX_PATH
export PKG_CONFIG_PATH=$PREFIX/lib/pkgconfig/:PKG_CONFIG_PATH
cmake -G "Eclipse CDT4 - Unix Makefiles" -DECLIPSE_CDT4_GENERATE_SOURCE_PROJECT=TRUE -DCMAKE_BUILD_TYPE=Debug -DCMAKE_INSTALL_PREFIX=$PREFIX $SCRIPT_DIR

Configuration Files

doxy.config.in

Doxygen configuration file. The project, version, paths, and some other things are set via cmake variables

#--------------------------------------------------
# Project related configuration options
#--------------------------------------------------
DOXYFILE_ENCODING      = UTF-8
PROJECT_NAME           = "${PROJECT_NAME}"
PROJECT_NUMBER         = v${${PROJECT_NAME}_VERSION_MAJOR}.${${PROJECT_NAME}_VERSION_MINOR}.${${PROJECT_NAME}_VERSION_BUGFIX}
OUTPUT_DIRECTORY       = ./doc
CREATE_SUBDIRS         = NO
OUTPUT_LANGUAGE        = English
BRIEF_MEMBER_DESC      = YES
REPEAT_BRIEF           = YES
ABBREVIATE_BRIEF       =
ALWAYS_DETAILED_SEC    = YES
INLINE_INHERITED_MEMB  = NO
FULL_PATH_NAMES        = YES
STRIP_FROM_PATH        = ${CMAKE_CURRENT_SOURCE_DIR}/src
STRIP_FROM_INC_PATH    = {CMAKE_CURRENT_SOURCE_DIR}/src/
SHORT_NAMES            = NO
JAVADOC_AUTOBRIEF      = NO
QT_AUTOBRIEF           = NO
MULTILINE_CPP_IS_BRIEF = YES
INHERIT_DOCS           = YES
SEPARATE_MEMBER_PAGES  = NO
TAB_SIZE               = 4
ALIASES                =
OPTIMIZE_OUTPUT_FOR_C  = NO
OPTIMIZE_OUTPUT_JAVA   = NO
OPTIMIZE_FOR_FORTRAN   = NO
OPTIMIZE_OUTPUT_VHDL   = NO
EXTENSION_MAPPING      =
BUILTIN_STL_SUPPORT    = YES
CPP_CLI_SUPPORT        = NO
SIP_SUPPORT            = NO
IDL_PROPERTY_SUPPORT   = YES
DISTRIBUTE_GROUP_DOC   = NO
SUBGROUPING            = YES
TYPEDEF_HIDES_STRUCT   = NO
SYMBOL_CACHE_SIZE      = 0

#--------------------------------------------------
# Build related configuration options
#--------------------------------------------------
EXTRACT_ALL            = YES
EXTRACT_PRIVATE        = YES
EXTRACT_STATIC         = NO
EXTRACT_LOCAL_CLASSES  = YES
EXTRACT_LOCAL_METHODS  = NO
EXTRACT_ANON_NSPACES   = NO
HIDE_UNDOC_MEMBERS     = NO
HIDE_UNDOC_CLASSES     = NO
HIDE_FRIEND_COMPOUNDS  = NO
HIDE_IN_BODY_DOCS      = NO
INTERNAL_DOCS          = NO
CASE_SENSE_NAMES       = NO
HIDE_SCOPE_NAMES       = NO
SHOW_INCLUDE_FILES     = YES
FORCE_LOCAL_INCLUDES   = NO
INLINE_INFO            = YES
SORT_MEMBER_DOCS       = YES
SORT_BRIEF_DOCS        = YES
SORT_MEMBERS_CTORS_1ST = NO
SORT_GROUP_NAMES       = YES
SORT_BY_SCOPE_NAME     = YES
GENERATE_TODOLIST      = YES
GENERATE_TESTLIST      = YES
GENERATE_BUGLIST       = YES
GENERATE_DEPRECATEDLIST= YES
ENABLED_SECTIONS       =
MAX_INITIALIZER_LINES  = 30
SHOW_USED_FILES        = YES
SHOW_DIRECTORIES       = YES
SHOW_FILES             = YES
SHOW_NAMESPACES        = YES
FILE_VERSION_FILTER    =
LAYOUT_FILE            =

#--------------------------------------------------
# configuration options related to warning and progress messages
#--------------------------------------------------
QUIET                  = NO
WARNINGS               = YES
WARN_IF_UNDOCUMENTED   = YES
WARN_IF_DOC_ERROR      = YES
WARN_NO_PARAMDOC       = NO
WARN_FORMAT            = "$file:$line: $text"
WARN_LOGFILE           =

#--------------------------------------------------
# configuration options related to the input files
#--------------------------------------------------
INPUT = ${CMAKE_CURRENT_SOURCE_DIR}/src
        ${CMAKE_CURRENT_SOURCE_DIR}/include
        ${CMAKE_CURRENT_SOURCE_DIR}/docs/pages
        ${CMAKE_CURRENT_BINARY_DIR}/src
        ${CMAKE_CURRENT_BINARY_DIR}/include
        ${CMAKE_CURRENT_BINARY_DIR}/docs/pages

INPUT_ENCODING         = UTF-8
FILE_PATTERNS          = *.cpp
                         *.h
                         *.hpp
RECURSIVE              = YES
EXCLUDE                =
EXCLUDE_SYMLINKS       = NO
EXCLUDE_PATTERNS       =
EXCLUDE_SYMBOLS        =
EXAMPLE_PATH           =
EXAMPLE_PATTERNS       =
EXAMPLE_RECURSIVE      = NO
IMAGE_PATH             =
INPUT_FILTER           =
FILTER_PATTERNS        =
FILTER_SOURCE_FILES    = NO

#--------------------------------------------------
# configuration options related to source browsing
#--------------------------------------------------
SOURCE_BROWSER         = YES
INLINE_SOURCES         = NO
STRIP_CODE_COMMENTS    = YES
REFERENCED_BY_RELATION = NO
REFERENCES_RELATION    = NO
REFERENCES_LINK_SOURCE = YES
USE_HTAGS              = NO
VERBATIM_HEADERS       = YES

#--------------------------------------------------
# configuration options related to the alphabetical class index
#--------------------------------------------------
ALPHABETICAL_INDEX     = NO
COLS_IN_ALPHA_INDEX    = 5
IGNORE_PREFIX          =

#--------------------------------------------------
# configuration options related to the HTML output
#--------------------------------------------------
GENERATE_HTML          = YES
HTML_OUTPUT            = html
HTML_FILE_EXTENSION    = .html
HTML_HEADER            =
HTML_FOOTER            =
HTML_STYLESHEET        =
HTML_TIMESTAMP         = YES
HTML_ALIGN_MEMBERS     = YES
HTML_DYNAMIC_SECTIONS  = NO
GENERATE_DOCSET        = NO
DOCSET_FEEDNAME        = "Doxygen generated docs"
DOCSET_BUNDLE_ID       = org.doxygen.Project
GENERATE_HTMLHELP      = NO
CHM_FILE               =
HHC_LOCATION           =
GENERATE_CHI           = NO
CHM_INDEX_ENCODING     =
BINARY_TOC             = NO
TOC_EXPAND             = NO
GENERATE_QHP           = NO
QCH_FILE               =
QHP_NAMESPACE          =
QHP_VIRTUAL_FOLDER     = doc
QHP_CUST_FILTER_NAME   =
QHP_CUST_FILTER_ATTRS  =
QHP_SECT_FILTER_ATTRS  =
QHG_LOCATION           =
GENERATE_ECLIPSEHELP   = NO
ECLIPSE_DOC_ID         = org.doxygen.Project
DISABLE_INDEX          = NO
ENUM_VALUES_PER_LINE   = 4
GENERATE_TREEVIEW      = YES
USE_INLINE_TREES       = NO
TREEVIEW_WIDTH         = 400
FORMULA_FONTSIZE       = 12
SEARCHENGINE           = NO
SERVER_BASED_SEARCH    = NO

#--------------------------------------------------
# configuration options related to the LaTeX output
#--------------------------------------------------
GENERATE_LATEX         = NO
LATEX_OUTPUT           = latex
LATEX_CMD_NAME         = latex
MAKEINDEX_CMD_NAME     = makeindex
COMPACT_LATEX          = YES
PAPER_TYPE             = letter
EXTRA_PACKAGES         = amsmath
                         amsfonts
                         hyperref
LATEX_HEADER           =
PDF_HYPERLINKS         = YES
USE_PDFLATEX           = YES
LATEX_BATCHMODE        = YES
LATEX_HIDE_INDICES     = NO
LATEX_SOURCE_CODE      = NO

#--------------------------------------------------
# configuration options related to the RTF output
#--------------------------------------------------
GENERATE_RTF           = NO
RTF_OUTPUT             = rtf
COMPACT_RTF            = NO
RTF_HYPERLINKS         = NO
RTF_STYLESHEET_FILE    =
RTF_EXTENSIONS_FILE    =

#--------------------------------------------------
# configuration options related to the man page output
#--------------------------------------------------
GENERATE_MAN           = NO
MAN_OUTPUT             = man
MAN_EXTENSION          = .3
MAN_LINKS              = NO

#--------------------------------------------------
# configuration options related to the XML output
#--------------------------------------------------
GENERATE_XML           = YES
XML_OUTPUT             = xml
XML_SCHEMA             =
XML_DTD                =
XML_PROGRAMLISTING     = NO

#--------------------------------------------------
# configuration options for the AutoGen Definitions output
#--------------------------------------------------
GENERATE_AUTOGEN_DEF   = NO

#--------------------------------------------------
# configuration options related to the Perl module output
#--------------------------------------------------
GENERATE_PERLMOD       = NO
PERLMOD_LATEX          = NO
PERLMOD_PRETTY         = YES
PERLMOD_MAKEVAR_PREFIX =

#--------------------------------------------------
# Configuration options related to the preprocessor
#--------------------------------------------------
ENABLE_PREPROCESSING   = YES
MACRO_EXPANSION        = NO
EXPAND_ONLY_PREDEF     = NO
SEARCH_INCLUDES        = YES
INCLUDE_PATH           =
INCLUDE_FILE_PATTERNS  =
PREDEFINED             =
EXPAND_AS_DEFINED      =
SKIP_FUNCTION_MACROS   = YES

#--------------------------------------------------
# Configuration::additions related to external references
#--------------------------------------------------
TAGFILES               =
GENERATE_TAGFILE       = ${PROJECT_NAME}.tag
ALLEXTERNALS           = NO
EXTERNAL_GROUPS        = YES
PERL_PATH              = /usr/bin/perl

#--------------------------------------------------
# Configuration options related to the dot tool
#--------------------------------------------------
CLASS_DIAGRAMS         = YES
MSCGEN_PATH            = ${CMAKE_MSCGEN_PATH}
HIDE_UNDOC_RELATIONS   = YES
HAVE_DOT               = NO
DOT_FONTNAME           = FreeSans
DOT_FONTSIZE           = 10
DOT_FONTPATH           =
CLASS_GRAPH            = YES
COLLABORATION_GRAPH    = YES
GROUP_GRAPHS           = YES
UML_LOOK               = NO
TEMPLATE_RELATIONS     = NO
INCLUDE_GRAPH          = YES
INCLUDED_BY_GRAPH      = YES
CALL_GRAPH             = NO
CALLER_GRAPH           = NO
GRAPHICAL_HIERARCHY    = YES
DIRECTORY_GRAPH        = YES
DOT_IMAGE_FORMAT       = png
DOT_PATH               = ${CMAKE_DOT_PATH}
DOTFILE_DIRS           =
DOT_GRAPH_MAX_NODES    = 50
MAX_DOT_GRAPH_DEPTH    = 0
DOT_TRANSPARENT        = NO
DOT_MULTI_TARGETS      = NO
GENERATE_LEGEND        = YES
DOT_CLEANUP            = YES

CMakeLists.txt

The root CMakeLists file. The project name is replaced by the new project script

cmake_minimum_required(VERSION 2.8)

# defines the project name
project (projectName)
set( ${CMAKE_PROJECT_NAME}_VERSION_MAJOR 0 )
set( ${CMAKE_PROJECT_NAME}_VERSION_MINOR 1 )
set( ${CMAKE_PROJECT_NAME}_VERSION_BUGFIX 0 )

# adds the project-specific cmake module directory cmake/Modules to the cmake
# search path
set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} "${CMAKE_SOURCE_DIR}/cmake/Modules/")

# finds pkg-config
find_package(PkgConfig REQUIRED)

# add the src/ subdirectory to the list of directories cmake processes
add_subdirectory(src)
add_subdirectory(include)

# configure the doxygen configuration
configure_file(
    "${PROJECT_SOURCE_DIR}/doxy.config.in"
    "${PROJECT_BINARY_DIR}/doxy.config"
    )

# use Jan Woetzel's doxygen doc target
include("${CMAKE_MODULE_PATH}/TargetDoc.cmake" OPTIONAL)

src/CMakeLists.txt

The CMakeLists for the application.

find_package(GTKmm REQUIRED)
#find_package(Boost COMPONENTS iostreams REQUIRED)

include_directories(
#   ${Boost_INCLUDE_DIRS}
    ${GTKmm_INCLUDE_DIRS}
    )

set(LIBS ${LIBS}
#   ${Boost_LIBRARIES}
    ${GTKmm_LIBRARIES}
    )

add_executable( ${CMAKE_PROJECT_NAME} main.cpp Application.cpp)

target_link_libraries( ${CMAKE_PROJECT_NAME} ${LIBS})

configure_file(
    ${CMAKE_CURRENT_SOURCE_DIR}/mainwindow.glade
    ${CMAKE_CURRENT_BINARY_DIR}/mainwindow.glade COPYONLY )

configure_file(
    ${CMAKE_CURRENT_SOURCE_DIR}/mainwindow.xml
    ${CMAKE_CURRENT_BINARY_DIR}/mainwindow.xml COPYONLY )

New Project Script

start_new_project.sh

This is the script I use to start a new project. It copies the template directory to a new directory in $HOME/Codes/cpp/ named after the new project. It also replaces the project name in the root CMakeLists to the project name. It initializes a git repository in the source and make an initial commit with all the files. It then creates a build directory in $HOME/Codes/cpp/builds. It changes to that directory and then calls the bootstrap script to generate the project files and makefiles.

#!/bin/bash

EXPECTED_ARGS=1
if [ $# -ne $EXPECTED_ARGS ]
then
    echo "Usage: `basename $0` {arg}"
    exit 1
fi

PROJECT_DIR="$HOME/Codes/cpp/$1″
BUILD_DIR="$HOME/Codes/cpp/builds/$1″
TEMPLATE_DIR="$HOME/Codes/cpp/template"

if [ -d "$HOME/Codes/cpp/$1" ]
then
    echo "The directory '$PROJECT_DIR' already exists"
    exit 1
fi

echo "Making $PROJECT_DIR"
mkdir $PROJECT_DIR

echo "Copying files from $TEMPLATE_DIR to $PROJECT_DIR"
cp -rv $TEMPLATE_DIR/* $PROJECT_DIR/

echo "Setting project name in CMakeList.txt"
sed -i "s/projectName/$1/" $PROJECT_DIR/CMakeLists.txt

echo "Changing to project directory"
cd $PROJECT_DIR
echo "   pwd: `pwd`"

echo "Initializing the git repository"
git init
git add -A
git commit -m "Initial commit, template project"

echo "Changing to the build directory"
mkdir $BUILD_DIR
cd $BUILD_DIR
echo "   pwd: `pwd`"

echo "Bootstrapping cmake"
$PROJECT_DIR/bootstrap.sh

Program Source Files

src/main.cpp

/*
 *  file   main.cpp
 *  date   May 31, 2011
 */

#include 
#include "Application.h"

int main(int argc, char** argv)
{
    Gtk::Main kit(argc, argv);
    Application app;
    kit.run(app.getWindow());
}

src/Application.h

/*
 *  file   Application.h
 *  date   Mar 19, 2011
 */

#ifndef APPLICATION_H_
#define APPLICATION_H_

#include

class Application
{
    private:
        Glib::RefPtr      m_builder;
        Glib::RefPtr    m_ui;
        Gtk::Window*                    m_mainWindow;

    public:
        Application();
        virtual ~Application();

        Gtk::Window& getWindow();
};

#endif /* Application_H_ */

src/Application.cpp

/*
 *  file   Application.cpp
 *  date   Apr 29, 2011
 */

#include "Application.h"

Application::Application():
    m_mainWindow(0)
{
    using namespace Glib;
    using namespace Gtk;

    m_builder = Builder::create_from_file("mainwindow.glade");
    m_mainWindow = 0;
    m_builder->get_widget("main_window",m_mainWindow);

    VBox* vbox = 0;
    m_builder->get_widget("main_vbox", vbox);

    m_ui = UIManager::create();
    m_ui->add_ui_from_file("mainwindow.xml");
    Gtk::Widget* menubar = m_ui->get_widget("/mb_main");
    Gtk::Widget* toolbar = m_ui->get_widget("/tb_main");
    vbox->pack_start(*menubar,false,false);
    vbox->pack_start(*toolbar,false,false);
    vbox->reorder_child(*menubar,0);
    vbox->reorder_child(*toolbar,1);

    m_mainWindow->show_all();
}

Application::~Application()
{

}

Gtk::Window& Application::getWindow(){ return *m_mainWindow; }

src/mainwindow.glade

(failed import from wordpress)

src/mainwindow.xml

(failed import from wordpress)

Gtkmm 3.0 in Ubuntu 11.04

Josh Bialkowski — Mon, 06 Jun 2011 17:01:29 GMT

Lately I've been writing a lot of codes using gtkmm 3.0. The latest stable branch is 2.4, but this is based on GTK+ 2… and I really want to use GTK+ 3. Why? Because GTK+ 3 uses cairo for it's native drawing API, and cairo is sweet. gtkmm uses cairomm, which is even sweeter. So here are my notes on getting gtkmm-3 built and installed for Ubuntu 11.04. I've written a shell script to do all the work, but I'll go through it section by section to explain what's going on.

Setup

Traditionally /usr/ is used for normal system stuff /usr/local is for experimental stuff (it's essentially the same as /usr but it makes it easy to find and remove stuff after it breaks your system). However, since I originally was developing with the unstable Gtkmm branch in Ubuntu 10.04, which didn't even have a package for GTK+ 3 in the repositories, I started installing things into my home directory… since it's just for testing anyway. Therefore, I create a directory $HOME/Codes/devroot (for development root filesystem) where I install all the "unstable" packages I'm using, or where I practice-install the programs/libraries I'm writing.

I also make a directory $HOME/Codes/cpp/gnome where I download all the source tarballs and do the building.

#!/bin/bash
cd $HOME

export BASE=$HOME/Codes/devroot
export PATH=$BASE/bin:$PATH
export LD_LIBRARY_PATH=$BASE/lib:$LD_LIBRARY_PATH
export PKG_CONFIG_PATH=$BASE/lib/pkgconfig:$PKG_CONFIG_PATH
export XDG_DATA_DIRS=$BASE/share:$XDG_DATA_DIRS
export ACLOCAL_FLAGS="-I $BASE/share/aclocal $ACLOCAL_FLAGS"

mkdir -p $BASE
mkdir -p Codes/cpp/gnome
cd Codes/cpp/gnome

Next I export some variables containing the versions of the unstable packages I'm using. This is so that I can quickly update the script for future installations and things.

export MM_COMMON_VER=0.9.5
export GLIBMM_VER=2.28.1
export ATKMM_VER=2.22.5
export PANGOMM_VER=2.28.2
export CAIROMM_VER=1.1.10
export GTKMM_VER=3.0.1

Then I download all the source tarballs

wget http://ftp.acc.umu.se/pub/GNOME/sources/mm-common/0.9/mm-common-$MM_COMMON_VER.tar.gz
wget http://ftp.acc.umu.se/pub/GNOME/sources/glibmm/2.28/glibmm-$GLIBMM_VER.tar.gz
wget http://ftp.acc.umu.se/pub/GNOME/sources/atkmm/2.22/atkmm-$ATKMM_VER.tar.gz
wget http://ftp.acc.umu.se/pub/GNOME/sources/pangomm/2.28/pangomm-$PANGOMM_VER.tar.gz
wget http://ftp.acc.umu.se/pub/GNOME/sources/gtkmm/3.0/gtkmm-$GTKMM_VER.tar.gz
wget http://cairographics.org/snapshots/cairomm-$CAIROMM_VER.tar.gz

And extract them all into $HOME/Codes/cpp/gnome (currently PWD).

tar xvzf mm-common-$MM_COMMON_VER.tar.gz
tar xvzf glibmm-$GLIBMM_VER.tar.gz
tar xvzf atkmm-$ATKMM_VER.tar.gz
tar xvzf pangomm-$PANGOMM_VER.tar.gz
tar xvzf gtkmm-$GTKMM_VER.tar.gz
tar xvzf cairomm-$CAIROMM_VER.tar.gz

Then we start installing the packages in the appropriate order. There are a few ugly things that we have to do in the process though.

cd mm-common-$MM_COMMON_VER
./configure -prefix=$BASE
make -j6
make install
cd ..

cd glibmm-$GLIBMM_VER
./configure -prefix=$BASE
make -j6
make install

The first ugly thing is that the glibmm package doesn't install the doctool perl script like it should… so we have to do that manually:

mkdir -p $BASE/share/glibmm-2.4/doctool/
cp docs/doc-install.pl $BASE/share/glibmm-2.4/doctool/

Then we continue installing the libraries

cd ..

cd atkmm-$ATKMM_VER
./configure -prefix=$BASE
make -j6
make install
cd ..

cd pangomm-$PANGOMM_VER
./configure -prefix=$BASE

The second ugly thing we have to do is move libfreetype.la to where libtool can find it. I'm not sure why it can't find this specific library but for whatever reason, even after setting LD_LIBRARY_PATH it always looks in /usr/lib. So I just pretend like no ones watching and create a symlink.

sudo ln -s /usr/lib/x86_64-linux-gnu/libfreetype.la /usr/lib/

And everything after that goes pretty normally.

make -j6
make install
cd ..

cd cairomm-$CAIROMM_VER
./configure -prefix=$BASE
make -j6
make install
cd ..

cd gtkmm-$GTKMM_VER
./configure -prefix=$BASE
make -j6
make install
cd ..

HTML Documentation with Equation Numbers (Referencing an External PDF Document with Doxygen's HTML Documentation)

Josh Bialkowski — Sat, 17 Apr 2010 20:17:44 GMT

So, anyone who uses Doxygen to document their code knows that it's pretty much the most amazing thing ever. Seriously, it's awesome. One cool thing about it is the ability to reference external documentation. For instance, if you use a library in your code and you want to include the library's documentation with your own. However, let's say that (hypothetically of course) you're an academic… and the code you write implements some theoretical design or model. In that case, you may actually want your documentation to reference a paper, or a report that you've written. Perhaps, even many such papers or reports.

The Problem

In particular, let's say that you're a grad student, in the process of writing a paper (and of course, you used LaTex… because, well, why wouldn't you?) and you go and write some code to simulate or demonstrate some elements of that paper. In that case, some of your functions may implement certain equations. Some of your classes (if it's object oriented) may implement certain models. For an example, lets say this is your paper:

Let's also assume that you've been good, and have been documenting your code with Doxygen. Let's say you had some c++ class that implemented your model and it's definition looks something like this:

/**
 *  file       CTheoreticalModel.h
 *  author     Joe Author (jauthor@institute.edu)
 *  date       Apr 17, 2010
 *  brief      Definition file for CTheoreticalModel class
 */

#ifndef CTHEORETICALMODEL_H_
#define CTHEORETICALMODEL_H_


/**
 *  brief  Theoretical Model derived in section 2, on page 1
 *
 *  This is a detailed description of the model
 */
class CTheoreticalModel
{
    private:
        double    m_alpha;    ///< [parameter] defined in equation 2.1
        double    m_beta;     ///< [parameter] defined in equation 2.2

    public:
        /**
         *  brief      Construct a new model using the given parameters
         *  param[in]  alpha   [parameter] defined in equation 2.1
         *  param[in]  beta    [parameter] defined in equation 2.2
         */
        CTheoreticalModel( double alpha, double beta );


        /**
         *  brief      calculates [some property] by implementing algorithm 2.1
         *              on page 1
         *  return     [some property]
         */
        double algorithmA();


        /**
         *  brief      updates the model by [some parameter] according to the
         *              dynamics of equation 2.4
         *  param[in]  gamma   [parameter] defined in equation 2.3
         */
        void equationB( double gamma );


        /**
         *  brief      tests [some parameter] against the model; implements
         *              equation 2.6
         *  param[in]  theta   [some parameter] defined by equation 2.5
         */
        bool testC( double theta );
};

#endif /* CTHEORETICALMODEL_H_ */

Then the html documentation that doxygen will generate will look like this:

Now let's say that you talk to your advisor and he suggests that maybe section 2 should come after section 3. Moreover, you add a bunch of content to section 1 so now all of the code for this model is on page five. So then you end up with this:

So now you have to go back and change all of the equation numbers and page references in your code. But wait, when we wrote our document we "label{}"ed all of our equations, algorithms, and sections. Wouldn't it be cool if we could just reference those in the comments? Doxygen exposes latex's math mode for us to document inline equations. It uses latex to render the equations, and then uses dvipng to turn those into png images. Moreover, latex has the xr package, which allows us to reference labels from other documents. Lastly, the "ref{}" command is valid inside math-mode. So we have all the tools we need, but there is one slight problem. In order to use the xr latex package, we need to include the "externaldocument" command in the header of the document.

The solution

Now here's the fun part. When Doxygen renders all of the equations, it does so by generating a single latex source file called "_formulas.tex". We don't have explicit access to modify the preamble of that source file, but we are allowed to add optional packages to the list of what is included. We do that by modifying the "EXTRA_PACKAGES" line of the doxyfile. For instance, if we edit the doxyfile like this:

…
# The EXTRA_PACKAGES tag can be to specify one or more names of LaTeX 
# packages that should be included in the LaTeX output.

EXTRA_PACKAGES = amsmath xr amsfonts
…

then when doxygen generates _formulas.tex it will include in the preamble a list of includes like this

    usepackage{amsmath}
    usepackage{xr}
    usepackage{amsfonts}

Note that Doxygen tokenizes the list of packages (parses it) at whitespace, and then takes each token and wraps it with "usepackage{}", inserting it into the header. We can hijack this method of input by making EXTRA_PACKAGES variable like this

…
EXTRA_PACKAGES = amsmath xr}externaldocument[paper-]{dummy}% amsfonts
…

Then the preamble of _formulas.tex will look like this

    usepackage{amsmath}
    usepackage{amsfonts}
    usepackage{xr}externaldocument[paper-]{dummy}%}
    usepackage{hyperref}

Note how we use a comment character (percent) to comment out the closing bracket that doxygen put's around our 'package'. Now we have an extra command in our preamble. If you haven't looked up the xr documentation yet, this command means to look for a file called "dummy.aux" generated by latex. The package extracts all the labels from that file and appends "paper-" to the front of the label names. Now we can change our code documentation to look like this:

/**
 *  file       CTheoreticalModel.h
 *  author     Joe Author (jauthor@institute.edu)
 *  date       Apr 17, 2010
 *  brief      Definition file for CTheoreticalModel class
 */

#ifndef CTHEORETICALMODEL_H_
#define CTHEORETICALMODEL_H_


/**
 *  brief  Theoretical Model derived in section f$ref{paper-sec:Model}f$,
 *          page f$pageref{paper-sec:Model}f$
 *
 *  This is a detailed description of the model
 */
class CTheoreticalModel
{
    private:
        double    m_alpha;    ///< [parameter] defined in equation f$ref{paper-eqn:alphaDef}f$
        double    m_beta;     ///< [parameter] defined in equation f$ref{paper-eqn:betaDef}f$

    public:
        /**
         *  brief      Construct a new model using the given parameters
         *  param[in]  alpha   [parameter] defined in equation
         *                      f$ref{paper-eqn:alphaDef}f$
         *  param[in]  beta    [parameter] defined in equation
         *                      f$ref{paper-eqn:betaDef}f$
         */
        CTheoreticalModel( double alpha, double beta );


        /**
         *  brief      calculates [some property] by implementing algorithm
         *              f$ref{paper-alg:SomeAlgorithm}f$ on page
         *              f$pageref{paper-alg:SomeAlgorithm}f$
         *  return     [some property]
         */
        double algorithmA();


        /**
         *  brief      updates the model by [some parameter] according to the
         *              dynamics of equation f$ref{paper-eqn:SomeEquation}f$
         *              on page f$pageref{paper-eqn:SomeEquation}f$
         *  param[in]  gamma   [parameter] defined in equation
         *                      f$ref{paper-eqn:gammaDef}f$
         */
        void equationB( double gamma );


        /**
         *  brief      tests [some parameter] against the model; implements
         *              condition f$ref{paper-eqn:SomeCondition}f$
         *  param[in]  theta   [some parameter] defined by equation
         *                      f$ref{paper-eqn:thetaDef}f$
         */
        bool testC( double theta );
};

#endif /* CTHEORETICALMODEL_H_ */

Now all we have to do is dump dummy.aux (generated when we build the paper using latex) into the html directory where doxygen is going to build _formulas.tex and then when we make the documentation it looks like this:

Sure, all the references are images… which isn't particularly great, but it's a lot better than having to go in and change the labels every time we make a change to the referenced document. Whenever writing a code and a referenced document are done in parallel, this could be quite a handy trick. If you want the html document to look a little more professional, add a package that will set the font to the same as the font set by your doxygen CSS stylesheet.

If you want to play around with the files used in this post, pick them up here: dummy.7z. Create the latex document with the following command.

latex dummy.tex

Then copy dummy.aux into the html directory.

cp dummy.aux html/

Then run doxygen

doxygen doxyfile

Instanciate Objects of Unknown Type from Their Parent Interface

Josh Bialkowski — Fri, 14 Aug 2009 19:13:36 GMT

This is based on my previous two posts on Static Interfaces in C++ and Keep Track of and Enumerate All Sub-classes of a Particular Interface. The idea is that I want my code to be extensible in the feature without requiring any re-writing of the current code base. The code base operates on generic objects via their interfaces, so as long as newly-coded classes properly extend those interfaces, the program should know how to handle them. The problem is, how can we write the program in such a manner that a user interface can enumerate available options for implementations of a particular interface, and how can we instantiate those objects?

In Keep Track of and Enumerate All Sub-classes of a Particular Interface I showed how to maintain a registry of classes deriving from a given interface, which handles the first problem, but there is a limitation in that all of these classes must provide a factory method that takes no parameters (void input). I decided that, for my project, this was not acceptable and I needed a way to define the creation parameters as part of the factory methods, whereas the creation parameters may be different for particular interfaces.

In Static Interfaces in C++ I showed how we can enforce the requirement of a static method in derived classes with a particular signature using a template interface.

In this post I will combine the two so that we can create a registry of classes that inherit from a particular interface, and provide a static factory method for creating objects of that interface, using a particular creation method signature unique to that interface. The registry will pair class names with function pointers that match the specific signature of the interface the class is being registered for.

Disclaimer: I do not claim this is the "best" way to handle this issue. This is just what I came up with. It happens to be pretty involved and overly indirect, which means it's probably bad design. It is, however, an extremely interesting exercise in generic programming.

Prequil: the code will require these later so there they are:

    /**
     *  file          RegistryTest.cpp
     *  date:      Aug 14, 2009
     *  brief:
     *
     *  detail:
     */


    #include 
    #include 
    #include 
    #include 

    using namespace std;

Ok, so lets begin. First let's define a couple of interfaces that we're interested in.

    class InterfaceA{};
    class InterfaceB{};
    class InterfaceC{};

Now we create a template class whose sole purpose is to create a per-interface typedef of the function signature that is necessary for instantiating and object of that class. Is it really possible that all sub-objects can be instantiated with the same parameters? If that's the case, shouldn't they all be combined into a single class that just contains that information as private members? Probably, but in my case these parameters are more like a "bare minimum" for instantiation, and then many more parameters are set by the user. It makes sense to me, I promise. If it doesn't to you, you don't have to use this.

    template< typename InterfaceType >
    class Factory
    {
        public:
            typedef InterfaceType*(*Creator)(void);
    };

Creator is now a typedef that aliases a function pointer that takes no parameters. Wait, isn't that what we had before? Yes, but now we make a couple of template specializations to define the different signatures for our specific interfaces. These specializations would normally be in the file that contained the interface declaration.

    /// specializations can define other creators, this one requires an int
    template<> class Factory
    {
        public:
            typedef InterfaceB*(*Creator)(int);
    };

    /// specializations can define other creators, this one requires an int, a
    /// bool, and a char
    template<> class Factory
    {
        public:
            typedef InterfaceC*(*Creator)(int,bool,char);
    };

Cool. Now we create a static interface that enforces it's derivative classes to contain a static method called createNew which can be used to instantiate a new object of that interface. We can use the typedef we just created to make the function signature generic for this template (or specific to individual instantiations of it).

    template
    class IStaticFactory
    {
        public:
            IStaticFactory()
            {
                typename Factory::Creator check = ClassType::createNew;
                check = check;
            }
    };

Still following? Good. Now we define the registry class template, which maps the class name of a derived class to a function pointer with an interface- specific signature that serves as a static factory for objects of the derived class, returning a pointer to that object of the type of the interface. See my previous post for details on this class.

    template 
    class Registry
    {
        private:
            std::map< std::string, typename Factory::Creator > m_creatorMap;


            Registry(){}

        public:

            static Registry& getInstance();


            bool registerClass( const std::string& name,
                                 typename Factory::Creator creator );


            std::set  getClassNames();


            typename
            Factory::Creator
            Registry::getCreator(
                    std::string className );
    };



    // A convient macro to compact the registration of a class
    #define RegisterWithInterface( CLASS, INTERFACE )                   
    namespace                                                           
    {                                                                   
        bool dummy_ ## CLASS =                                          
        Registry::getInstance().registerClass(     
                #CLASS, CLASS::createNew );                               
    }


    template 
    Registry& Registry::getInstance()
    {
        static Registry    registry;
        return registry;
    }


    template 
    bool Registry::registerClass( const std::string& name,
                            typename Factory::Creator creator )
    {
        m_creatorMap[name] = creator;
        return true;
    }

    template 
    std::set  Registry::getClassNames()
    {
        std::set   keys;

        typename
        std::map< std::string, InterfaceType* (*)(void) >::iterator pair;

        for( pair = m_creatorMap.begin(); pair != m_creatorMap.end(); pair++)
            keys.insert( pair->first );

        return keys;
    }

    template 
    typename
    Factory::Creator
    Registry::getCreator(
            std::string className )
    {
        return m_creatorMap[className];
    }

The difference between this and the Registry in my previous post, is that this time the registry uses the generic Factory<InterfaceType>::Creator typedef to define the function pointer. This way, that pointer is forced to have the specific signature. Sweet!

Now lets write some derived classes of those interfaces.

    class   DerivedA : public InterfaceA,
                        public IStaticFactory
    {
        public:
            static InterfaceA*  createNew(){ return (InterfaceA*)1; }
    };


    RegisterWithInterface(DerivedA, InterfaceA);



    class   DerivedB : public InterfaceB,
                        public IStaticFactory
    {
        public:
            static InterfaceB*  createNew(int a){ return (InterfaceB*)2; }
    };


    RegisterWithInterface(DerivedB, InterfaceB);



    class   DerivedC : public InterfaceC,
                        public IStaticFactory
    {
        public:
            static InterfaceC*  createNew(int a, bool b, char c){ return (InterfaceC*)3; }
    };

    RegisterWithInterface(DerivedC, InterfaceC);

These classes are basically dummies, but inheriting from IStaticFactory… the compiler will enforce that they contain the static method createNew with the proper signature. Notice that InterfaceA uses the default template so the static factory in DerivedA takes no parameters, while InterfaceB and InterfaceC have specializations so the static factories in DerivedB and DerivedC have their respective parameters. Since this is just an example, the methods don't actually create new objects they just return pointers, but in reality this is where we would use new DerivedA(…) and so on.

Well that's it. Pretty cool huh? The compiler will enforce all this stuff for us so we can actually say to ourselves when we write new implementations months from now "If it compiles, it will be compatible."

Lastly, here's a little test case to run

    int main()
    {
        DerivedA    a;
        DerivedB    b;
        DerivedC    c;

        InterfaceA* pA;
        InterfaceB* pB;
        InterfaceC* pC;

        Factory::Creator makesObjectOfA =
                Registry::getInstance().getCreator("DerivedA");
        pA = (*makesObjectOfA)();

        Factory::Creator makesObjectOfB =
                Registry::getInstance().getCreator("DerivedB");
        pB = (*makesObjectOfB)(1);

        Factory::Creator makesObjectOfC =
                Registry::getInstance().getCreator("DerivedC");
        pC = (*makesObjectOfC)(1,false,'a');

        cout << "pA: " << pA << "n";
        cout << "pB: " << pB << "n";
        cout << "pC: " << pC << "n";

        return 0;
    }

Static Interfaces in C++

Josh Bialkowski — Thu, 13 Aug 2009 15:09:12 GMT

I remember looking around a few weeks ago for how to make a "static interface" in c++. Basically, I wanted a way to use the compiler to enforce that a class had certain static functions. Almost all of the internet resources I found basically said "Why would you ever want to do that; you don't really want to do that; you probably have bad design" and so on… continuously begging the question. Of course, they were right: the design was bad and that wasn't really what I wanted to do. Well, never the less, I still managed to think of a way to create a sort of static interface using a template class.

The strategy is to define a template class that uses the static methods of the template parameter class. That way, as long as the template is instantiated, the compiler will complain unless we have provided those static functions. We can ensure that the template is instantiated and enforce the inheritance idea by making the derived class extend from the template class we wrote to enforce those static methods.

Here is an example. We can create the static interface by declaring a class template that uses the functions we want to enforce as part of the interface.

    template < typename T >
    class StaticInterface
    {
        public:
            StaticInterface()
            {
                int(*fooCheck)(int)     = T::foo;
                bool(*barCheck)(bool)   = T::bar;
            }
    };

By assigning T::foo and T::bar to function pointers, we are saying, implicitly, that whatever class is provided as a parameter to this template must have a static method called foo and a static method called bar and, furthermore, that those static methods must have
the same signature as the function pointers we stuff them into.

By putting this code inside the constructor of the class, we know that this method of the template will be instantiated, even if we don't explicitly use it later in the code, as long as we derive from this class somewhere. So then, the last question is, where can we derive from it?

Well, in the class that we want to inherit the interface of course!

    class DerivedClass : public StaticInterface
    {
        public:
            static int foo(int  param){ return 10; }
            static bool bar(bool param){ return 20; }
    };

The DerivedClass constructor implicitly calls the StaticInterface constructor, which assigns the function pointers fooCheck and barCheck to the address of the functions DerivedClass::foo and DerivedClass::bar. As a result, if we forget the bar function in the DerivedClass the compiler will choke with an error. g++ says the following:

src/poc/test/StaticInterfaceTest.cpp: In constructor
`StaticInterface::StaticInterface() [with T = DerivedClass]':  
src/poc/test/StaticInterfaceTest.cpp:41: instantiated from here  
src/poc/test/StaticInterfaceTest.cpp:20: error: `bar' is not a member of
`DerivedClass'

Pretty cool huh?

As a final note, please consider this "an interesting observation" and not necessarily a "great design choice". As I said, I decided against actually trying to utilize this idea in my project, and I urge you think carefully before about yours before trying to use it yourself.