In the first two posts we introduced basic parsing techniques defined by Spirit. The parsing is only useful, if we can do something with parsing results. In Spirit you achieve this with semantic actions.

Semantic actions are expected to use functional programming paradigms. The most basic semantic action has the following prototype:

 void f(IteratorT first, IteratorT last);

or as functor

  struct my_functor
    {
        void operator()(IteratorT first, IteratorT last) const;
    };

Here is an example of simple action from Spirit user guide:

 void
    my_action(char const* first, char const* last)
    {
        std::string str(first, last);
        std::cout << str << std::endl;
    }

Applying the action is rather simple. You specify them in [] after the rule. From previous e-mail address parser, you can write:

 
    r = *(mailTo | anychar_p);
    mailTo = "mailTo:" >> emailAddress[&my_action];
    emailAddress = lexeme_d[ +alnum_p >> '@' >> +alnum_p >> *('.' >> +alnum_p)];

my_action will be called with iterator pointing to start and end of the parsed e-mail address. The above action will result in printing all the e-mail addresses in the input.

In a lot of cases, it is wasteful to call actions with the Iterators pointing to first and last. After all, Spirit has just parsed the contents. For this purpose the boost defines specialized actions. For example

  void func(NumT val);

or equivalent functor

struct fctr
    {
        void operator()(NumT val) const;
    };

can be applied to any numeric parsers (real_p, ureal_p, int_p, uint_p). Similar actions exist for other other types of parsers. Please check Spirit guide for details.

The complete program looks like:

#include <boost/spirit/core.hpp>
#include <iostream>
using namespace boost::spirit;

void
my_action(const char* first, const char* last)
{
std::string str(first, last);
std::cout << str << std::endl;
}

struct my_grammar : public grammar<my_grammar>
{
template <typename ScannerT>
struct definition
{
rule<ScannerT>  r, mailTo, emailAddress;
definition(my_grammar const& self)  {
r = *(mailTo | anychar_p);
mailTo = “mailTo:” >> emailAddress[&my_action];
emailAddress = lexeme_d[ +alnum_p >> '@' >> +alnum_p >> *('.' >> +alnum_p)];
}
rule<ScannerT> const& start() const { return r; }
};
};

int main(){
const char* str = “mailTo:a@b.com  test mailTo:d@f.com”;
my_grammar g;
if (parse(str, str + strlen(str), g, space_p).full)
std::cout << “parsing succeeded\n”;
else
std:: cout << “parsing failed\n”;
return 0;
}
In addition, there is a large selection of pre-defined actions. You an find them here.

In practice, the difference between a mathematical function and the notion of a “function” used in imperative programming is that imperative functions can have side effects, changing the value of already calculated computations. Because of this they lack referential transparency, i.e. the same language expression can result in different values at different times depending on the state of the executing program. Conversely, in functional code, the output value of a function depends only on the arguments that are input to the function, so calling a function f twice with the same value for an argument x will produce the same result f(x) both times. Eliminating side-effects can make it much easier to understand and predict the behavior of a program, which is one of the key motivations for the development of functional programming.

STL provides set of algorithms which can be viewed as FP. For example std::copy will always copy source to destination.

The next concept in FP is called currying, technique in which a function is applied to its arguments one at a time, with each application returning a new function that accepts the next argument. The STL function bind1st, bind2nd and binary_compose can be used for currying

All funcitonal programming languages are based on Lambda Calculus introduced in 1930s which is based on anonymous functions and currying. You can read more on it here.

Boost.Lambda and Boost.Phoenix introduce formal system of funcitonal programming and lambda expressions to C++. I typically use Boost.Lambda. I only use Phoenix when using Spirit since they are more closely integrated. They share a lot of similar concept. This post will discuss Boost.Lambda. The next post will use these concepts to introduce Phonix as applied to Boost.Spirit.

Let us start with a simple lambda expression _1 = 1 is definition of an anonymous function which takes one argument and sets it to 1. So to initialize a variable to 1 you could write:

(_1 + 1)(i);

or if you wanted to initialize all variables in a container to 1, you would write something like:

std::vector v;

std::for_each(v.begin(), v.end(), _1=1);

or to print everyobject in a container:

std::for_each(v.begin(), v.end(), std::cout << _1);

What if you wanted to define a function with calls a function with one argument and assigns results to the same argument:

That function will be _1 = bind(foo, _1);

Bind is generalized version of std::bind1st and bind2nd. With the above expression in place one can write:

(_1 = bind(foo, _1))(i);

Which will be equivalent to:

i = foo(i);

So with for_each one can write:

std::for_each(v.begin(), v.end(); _1 = bind(foo, _1));

_1 in the above examples are called placeholders which are equlvalent of lambda in the lambda expression. The above can be generalized with larger number of placeholders. For example one can write: (_1 + _2) to create a function which adds its two arguments. Boost Lambda defines up to 3 place holders. Higher order functions can be constructed using currying.

A function definition which used _2 takes 2 arguments and one which uses _3 takes 3 arguments.

For example _3 = 1, takes 3 argument and

(_3 = 1)(k) will have compile time errors.

(_3 = 1)(i,j,k) is good and is equivalent to k = 1.

Above, we are using simple expressions to create anonymous functions which do not have side effects and depend only on their arguments. As alluded earlier BLL also provides bind expression as generalization of bind1st and bind2nd. With BLL bind expression it is possible to bind any method with up to 9 arguments for delayed executions. It can target C++ class members, or simple functions as target. The syntax used is similar to bind1st and bind2nd.

In the last post we discussed how to write a simple parser using Spirit. Most real life parsers are a lot more complex requiring several rules and combining them to create a full grammar. Spirit provides support to declare a full grammar. Let us create a parser which looks for all mailto: tag with associated e-mail address in an input. All Spirit grammar are derived from grammar class. The following is definition of grammar:

 struct my_grammar : public grammar<my_grammar>
    {
        template <typename ScannerT>
        struct definition
        {
            rule<ScannerT>  r;
            definition(my_grammar const& self)  { r = /*..define here..*/; }
            rule<ScannerT> const& start() const { return r; }
        };
    };

The my_grammar is derived from grammar class using curiously recurring template pattern (CRTP). For those who are new to CRTP, it was introduced by Jim Copelien and Wikipedia has some details on it. Using CRTP it is possible to achieve effect of dynamic polymorphism without taking cost of virtual function. More on CRTP another day.

Each grammar class must define another nested structure called definition. The definition must have a function called start which returns starting parser rule. So let us start writing rules for e-mail address parser. The mailto rule can be written as:

     mailTo = "mailto:" >> emailAddress;

From our previous post, emailAddress can be written as:

     emailAddress =  lexeme_d[ +alnum_p >> '@' >> +alnum_p >> *('.' >> +alnum_p)];

Of course the full input has things other than the mailto: tags. So we must skip other characters. You do that as follows:

       r = mailTo | anychar_p;

The above rule is saying that try matching the input with mailTo and if it does not match mailTo rule, match it against any character parser.

So combining these two the grammar constructor now can be written as:

      definition(my_grammar const& self)  { 
            r = mailTo | anychar_p;
            mailTo = "mailTo:" >> emailAddress;
            emailAddress = lexeme_d[ +alnum_p >> '@' >> +alnum_p >> *('.' >> +alnum_p)];
      }

First thing one notices is that the rule “r” refers to rules “emailAddress” and “mailTo” before they are initialized. It works because the rules are held by reference and not by value. The referred rule can be initialized anytime. This does complicate programming a little bit. It means that it is user’s responsibility to make sure that the referred rules never go out of scope. So emailAddress cannot be local to definition. Typically, one declares all rules as part of the definition call definition. The full grammar now becomes:

 struct my_grammar : public grammar<my_grammar>
    {
        template <typename ScannerT>
        struct definition
        {
            rule<ScannerT>  r;
            rule<ScannerT>  emailAddress mailTo;
            definition(my_grammar const& self)  { 
                r = mailTo | anychar_p;
                mailTo = "mailTo:" >> emailAddress;
                emailAddress = lexeme_d[ +alnum_p >> '@' >> +alnum_p >> *('.' >> +alnum_p)];
            }
            rule<ScannerT> const& start() const { return r; }
        };
    };

OK! now we have the grammar. Let us use it.

   my_grammar g;
    if (parse(first, last, g, space_p).full)
        cout << "parsing succeeded\n";
    else
        cout << "parsing failed\n";

Here first and last are iterators pointing to first and the last characters in the input.

Note that the above grammar matches exactly one e-mail address or any other character. This can be easily be modified to match all e-mail addresses.

The new rule will be:

r = *(mailTo | anychar_p);

I recently had write a parser in C++ and decided to give Boost.Spirit a chance. I was delighted with ease of use of the parser itself. It was a steep learning curve to get started. However, once I got started, it made life significantly simple.

Boost.Spirit provides a very simple way to create a parser using EBNF grammar. Let us consider an e-mail address parser as an example.
+alnum_p >> '@' >> +alnum_p >> *('.' >> +alnum_p);
Simple! Let us understand the above statement. In Boost.Spirit rule<> template defines basic grammar rule. A rule is made up of parsers and other rules. In Boost.Spirit built-in parser all have _p as suffix. The alnum_p parser matches any character or number. ‘+’ represents operator which matches one more more instances of the enclosed parser.

‘>>’ is an overloaded operator which simply says followed by.’@’ is short form of parser which matches character ‘@’.

So the above statement says any alphanumeric string followed by ‘@’ followed by any other alpha numeric string. This can than be followed by any number of “.<alphanumber>”.

By default the >> includes white space skipping. This implies the above parser will match (a@b as well as a @ b).

We don’t want white space skipping for e-mail address. So we need to modify the above rule such that >> does not skip white space. For this and other purposes, the Spirit allows directives. These are special instructions which can be applied to a part of the rule. No white space skipping is achieved by using lexeme_d.
lexeme_d[ +alnum_p >> '@' >> +alnum_p >> *('.' >> +alnum_p);];

I have no clue why the name. But the suffix is _d for all directives.OK! we got a rule. Now let us check if this rule matches a specified string:

bool isEmailAddress(const std::string& str){
return parse(str, lexeme_d[ +alnum_p >> '@' >> +alnum_p >> *('.' >> +alnum_p);], space_p).full;
}

The above statement will check if the supplied string is an e-mail address or not.

In the next post we will discuss how to create more complex examples as well as deal with parse actions.

One of the things we have not looked at the definition of concept map. In the previous example of sort, the template takes ForwardIterator as an argument. The article did not discuss what makes a forward iterator. Can we use an int* as a forard iterator? We have also said that ForwardIterator must has value_type argument. int* does not have a member value_type. But we want to pass int* as parameter to sort so that for example, we can sort an array of integers.

C++0x provides a way to solve this problem called concept_map. Using concept_map we can define what constitute ForwardIterator.

template ;
	concept_map ForwardIterator {
                                    // T*'s value_type is T
		typedef T value_type;
	};

Using above syntax we are saying that any T”*’s value_type is T. This removes need to wrap int* in another container.

In all C++0x concept provides solution for one of the biggest ongoing frustration with generic programming with C++. It will provide early and clear compilation errors for template users and authors both and bind them in template parameter contract.

Other C++0x sources on the web

• Bjarne Stroustru’s C++0x FAQ
• Wikipedia

ConceptC++

Unlike the Boost Concept Check Library (BCCL), which is implemented purely using standard C++ constructs, these extensions are implemented by extending C++ language. By changing the C++ definition, it is possible to do things which was not possible otherwise. In particular, remember that with BCCL, it was not possible to make template parameter restriction part of template or function definition. With ConceptC++, this becomes now possible. In addition to enforcing restriction on instantiation of template, ConceptC++ also imposes restrictions on template implementation and makes sure that it only uses template parameter’s facility defined in the contract.

To understand ConceptC++, let us consider sum template which adds two parameters and returns the value:

template <typename T>

T sum(T a, T b){

   return a+b;

}

With Concept C++ we can rewrite this to:

template <CopyConstructable T>

T sum(T a, T b){

   return a+b;

}

This says T must be copy constructable. If we compile this template using ConceptC++ (even without any instantiation) we get the following error:

error: no match for 'operator+' in 'a+b'

That is because the template definition did not require T to implement operator+ but is trying to use it. This forces template signature to accurately define the template signature as:

template <CopyConstructable T>
  requires Addable<T>

T sum(T a, T b){

   return a+b;

}

In other words ConceptC++ puts restrictions on both template instantiation and template definition and binds them in a contract with respect to template parameter. This is what function, class or template definition, etc. are supposed to be.

We have been using magic words like CopyConstructable, Addable, etc. What are they? Are they new language features or are provided by library? What if we wanted to implement our own custom concepts? How will we go about that.

The C++ language addition provides capability to define new concepts while the library provides set of standard concepts. It is rather easy to build your own concept. For example let us look at definition of Addable concept:

auto concept Addable<typename T> {
  T operator+(T x, T y);
};

How simple can that be? The above definition is saying that the Addable concept implies that the template parameter must implement operator+ which takes two parameters of type T and returns T.

With this background, let us modify out example sort template. In case of sort, the template parameters are iterators and value pointed to by the iterator must implement less than operator. With ConceptC++ you can specify these restrictions as follows:

#include <concepts>
template<std::ForwardIterator T>
    requires LessThanComparable<T::value_type>

void sort(T b, T e)

{

  ....

}

As you can see ConceptC++ provides natural way of definining restrictions on template parameters allowing compilers to perform early error checking.

Performance

The ConceptC++ implements its functionality by reducing compile speed. However, just like BCCL the ConceptC++ does not incur any run time overhead.

Any person who has ever used C++ templates knows that compiler error messages when using templates are pain to understand. The problem stands from the fact that there is no easy way for template developers to define constraints on template parameters. For example let us consider the following example:

#include <vector>
#include <complex>
#include <algorithm>

int main()
{
     std::vector<std::complex<float> > v;
     std::stable_sort(v.begin(), v.end());
}

On my machine running GCC 4.2.1 it produces the following error:

/usr/include/c++/4.2.1/bits/stl_algo.h: In function âvoid std::__insertion_sort(_RandomAccessIterator, _RandomAccessIterator) [with _RandomAccessIterator = __gnu_cxx::__normal_iterator<std::complex<float>*, std::vector<std::complex<float>, std::allocator<std::complex<float> > > >]â:

/usr/include/c++/4.2.1/bits/stl_algo.h:3176:   instantiated from âvoid std::__inplace_stable_sort(_RandomAccessIterator, _RandomAccessIterator) [with _RandomAccessIterator = __gnu_cxx::__normal_iterator<std::complex<float>*, std::vector<std::complex<float>, std::allocator<std::complex<float> > > >]â

/usr/include/c++/4.2.1/bits/stl_algo.h:3892:   instantiated from âvoid std::stable_sort(_RandomAccessIterator, _RandomAccessIterator) [with _RandomAccessIterator = __gnu_cxx::__normal_iterator<std::complex<float>*, std::vector<std::complex<float>, std::allocator<std::complex<float> > > >]â

t.cc:11:   instantiated from here

/usr/include/c++/4.2.1/bits/stl_algo.h:2356: error: no match for âoperator<â in â__val < __first. __gnu_cxx::__normal_iterator<_Iterator, _Container>::operator* [with _Iterator = std::complex<float>*, _Container = std::vector<std::complex<float>, std::allocator<std::complex<float> > >]()â

/usr/include/c++/4.2.1/bits/stl_algo.h: In function âvoid std::__merge_without_buffer(_BidirectionalIterator, _BidirectionalIterator, _BidirectionalIterator, _Distance, _Distance) [with _BidirectionalIterator = __gnu_cxx::__normal_iterator<std::complex<float>*, std::vector<std::complex<float>, std::allocator<std::complex<float> > > >, _Distance = int]â:

/usr/include/c++/4.2.1/bits/stl_algo.h:3182:   instantiated from âvoid std::__inplace_stable_sort(_RandomAccessIterator, _RandomAccessIterator) [with _RandomAccessIterator = __gnu_cxx::__normal_iterator<std::complex<float>*, std::vector<std::complex<float>, std::allocator<std::complex<float> > > >]â

/usr/include/c++/4.2.1/bits/stl_algo.h:3892:   instantiated from âvoid std::stable_sort(_RandomAccessIterator, _RandomAccessIterator) [with _RandomAccessIterator = __gnu_cxx::__normal_iterator<std::complex<float>*, std::vector<std::complex<float>, std::allocator<std::complex<float> > > >]â

t.cc:11:   instantiated from here

/usr/include/c++/4.2.1/bits/stl_algo.h:3082: error: no match for âoperator<â in â__middle. __gnu_cxx::__normal_iterator<_Iterator, _Container>::operator* [with _Iterator = std::complex<float>*, _Container = std::vector<std::complex<float>, std::allocator<std::complex<float> > >]() < __first. __gnu_cxx::__normal_iterator<_Iterator, _Container>::operator* [with _Iterator = std::complex<float>*, _Container = std::vector<std::complex<float>, std::allocator<std::complex<float> > >]()â

/usr/include/c++/4.2.1/bits/stl_algo.h: In function âvoid std::__unguarded_linear_insert(_RandomAccessIterator, _Tp) [with _RandomAccessIterator = __gnu_cxx::__normal_iterator<std::complex<float>*, std::vector<std::complex<float>, std::allocator<std::complex<float> > > >, _Tp = std::complex<float>]â:

/usr/include/c++/4.2.1/bits/stl_algo.h:2362:   instantiated from âvoid std::__insertion_sort(_RandomAccessIterator, _RandomAccessIterator) [with _RandomAccessIterator = __gnu_cxx::__normal_iterator<std::complex<float>*, std::vector<std::complex<float>, std::allocator<std::complex<float> > > >]â

/usr/include/c++/4.2.1/bits/stl_algo.h:3176:   instantiated from âvoid std::__inplace_stable_sort(_RandomAccessIterator, _RandomAccessIterator) [with _RandomAccessIterator = __gnu_cxx::__normal_iterator<std::complex<float>*, std::vector<std::complex<float>, std::allocator<std::complex<float> > > >]â

/usr/include/c++/4.2.1/bits/stl_algo.h:3892:   instantiated from âvoid std::stable_sort(_RandomAccessIterator, _RandomAccessIterator) [with _RandomAccessIterator = __gnu_cxx::__normal_iterator<std::complex<float>*, std::vector<std::complex<float>, std::allocator<std::complex<float> > > >]â

t.cc:11:   instantiated from here

/usr/include/c++/4.2.1/bits/stl_algo.h:2309: error: no match for âoperator<â in â__val < __next. __gnu_cxx::__normal_iterator<_Iterator, _Container>::operator* [with _Iterator = std::complex<float>*, _Container = std::vector<std::complex<float>, std::allocator<std::complex<float> > >]()â

/usr/include/c++/4.2.1/bits/stl_algo.h: In function â_ForwardIterator std::lower_bound(_ForwardIterator, _ForwardIterator, const _Tp&) [with _ForwardIterator = __gnu_cxx::__normal_iterator<std::complex<float>*, std::vector<std::complex<float>, std::allocator<std::complex<float> > > >, _Tp = std::complex<float>]â:

/usr/include/c++/4.2.1/bits/stl_algo.h:3094:   instantiated from âvoid std::__merge_without_buffer(_BidirectionalIterator, _BidirectionalIterator, _BidirectionalIterator, _Distance, _Distance) [with _BidirectionalIterator = __gnu_cxx::__normal_iterator<std::complex<float>*, std::vector<std::complex<float>, std::allocator<std::complex<float> > > >, _Distance = int]â

/usr/include/c++/4.2.1/bits/stl_algo.h:3182:   instantiated from âvoid std::__inplace_stable_sort(_RandomAccessIterator, _RandomAccessIterator) [with _RandomAccessIterator = __gnu_cxx::__normal_iterator<std::complex<float>*, std::vector<std::complex<float>, std::allocator<std::complex<float> > > >]â

/usr/include/c++/4.2.1/bits/stl_algo.h:3892:   instantiated from âvoid std::stable_sort(_RandomAccessIterator, _RandomAccessIterator) [with _RandomAccessIterator = __gnu_cxx::__normal_iterator<std::complex<float>*, std::vector<std::complex<float>, std::allocator<std::complex<float> > > >]â

t.cc:11:   instantiated from here

…

…

/usr/include/c++/4.2.1/bits/stl_algo.h:3252: error: no match for âoperator<â in â* __first2 < * __first1â

Experienced C++ programmers may be able to figure out this error message however for most users it is extremely difficult. The error message is long and does not provide any insight in to cause of the error. The basic error is that  std:complex<float> does not model LessThanComparable which is required by std:sort.  In C++ there is no easy way for template developers to provide requirements on their parameters. Hence, compilers are not capable of testing the parameter errors early and provide meaningful error message. This C++ deficiency has significantly affected wider adaptation of templates and has resulted in development various methods of providing template parameter checks. These alternatives include both Language based and library based. C++0x Concepts will provide language level facility for error early error detection and meaningful error generation for template parameters.

It will probably take some time before MSVC and G++ support Concepts in their mainline languages. Till such time, existing alternatives may provide you with short term solutions.

Boost Concept Check Library

The Boost Concept Checking Library provides a library level concepts check facility without any language changes. Also the mechanism does not incur any run-time overhead. The checks are completely implemented at compile time. According to BCCL, it provides:

• A mechanism for inserting compile-time checks on template parameters at their point of use.
• A framework for specifying concept requirements though concept checking classes.
• A mechanism for verifying that concept requirements cover the template.
• A suite of concept checking classes and archetype classes that match the concept requirements in the C++ Standard Library.
• An alternative to the use of traits classes for accessing associated types that mirrors the syntax proposed for the next C++ standard.

With BCCL the std::stable_sort can be written as:

template<typename T>

void sort(T b, T e)

{

  function_requires< LessThanComparableConcept<T> >();

  typedef typename
     std::iterator_traits<T>::value_type value_type;

  function_requires
     <LessThanComparableConcept<value_type> >();

  ....

}

With this change the error message changes to:

/usr/include/boost/concept_check.hpp: In member function âvoid boost::LessThanComparableConcept<TT>::constraints() [with TT = std::complex<float>]â:

/usr/include/boost/concept_check.hpp:48:   instantiated from âvoid boost::function_requires(boost::mpl::identity<T>*) [with Concept = boost::LessThanComparableConcept<std::complex<float> >]â

t.cc:13:   instantiated from âvoid mysort(T, T) [with T = __gnu_cxx::__normal_iterator<std::complex<float>*, std::vector<std::complex<float>, std::allocator<std::complex<float> > > >]â

t.cc:21:   instantiated from here

/usr/include/boost/concept_check.hpp:314: error: no match for âoperator<â in â((boost::LessThanComparableConcept<std::complex<float> >*)this)->boost::LessThanComparableConcept<std::complex<float> >::a < ((boost::LessThanComparableConcept<std::complex<float> >*)this)->boost::LessThanComparableConcept<std::complex<float> >::bâ

/usr/include/c++/4.2.1/bits/stl_algo.h: In function âvoid std::__insertion_sort(_RandomAccessIterator, _RandomAccessIterator) [with _RandomAccessIterator = __gnu_cxx::__normal_iterator<std::complex<float>*, std::vector<std::complex<float>, std::allocator<std::complex<float> > > >]â:

/usr/include/c++/4.2.1/bits/stl_algo.h:3176:   instantiated from âvoid std::__inplace_stable_sort(_RandomAccessIterator, _RandomAccessIterator) [with _RandomAccessIterator = __gnu_cxx::__normal_iterator<std::complex<float>*, std::vector<std::complex<float>, std::allocator<std::complex<float> > > >]â

/usr/include/c++/4.2.1/bits/stl_algo.h:3892:   instantiated from âvoid std::stable_sort(_RandomAccessIterator, _RandomAccessIterator) [with _RandomAccessIterator = __gnu_cxx::__normal_iterator<std::complex<float>*, std::vector<std::complex<float>, std::allocator<std::complex<float> > > >]â

t.cc:15:   instantiated from âvoid mysort(T, T) [with T = __gnu_cxx::__normal_iterator<std::complex<float>*, std::vector<std::complex<float>, std::allocator<std::complex<float> > > >]â

t.cc:21:   instantiated from here

/usr/include/c++/4.2.1/bits/stl_algo.h:2356: error: no match for âoperator<â in â__val < __first. __gnu_cxx::__normal_iterator<_Iterator, _Container>::operator* [with _Iterator = std::complex<float>*, _Container = std::vector<std::complex<float>, std::allocator<std::complex<float> > >]()â

/usr/include/c++/4.2.1/bits/stl_algo.h: In function âvoid std::__merge_without_buffer(_BidirectionalIterator, _BidirectionalIterator, _BidirectionalIterator, _Distance, _Distance) [with _BidirectionalIterator = __gnu_cxx::__normal_iterator<std::complex<float>*, std::vector<std::complex<float>, std::allocator<std::complex<float> > > >, _Distance = int]â:

/usr/include/c++/4.2.1/bits/stl_algo.h:3182:   instantiated from âvoid std::__inplace_stable_sort(_RandomAccessIterator, _RandomAccessIterator) [with _RandomAccessIterator = __gnu_cxx::__normal_iterator<std::complex<float>*, std::vector<std::complex<float>, std::allocator<std::complex<float> > > >]â

/usr/include/c++/4.2.1/bits/stl_algo.h:3892:   instantiated from âvoid std::stable_sort(_RandomAccessIterator, _RandomAccessIterator) [with _RandomAccessIterator = __gnu_cxx::__normal_iterator<std::complex<float>*, std::vector<std::complex<float>, std::allocator<std::complex<float> > > >]â

t.cc:15:   instantiated from âvoid mysort(T, T) [with T = __gnu_cxx::__normal_iterator<std::complex<float>*, std::vector<std::complex<float>, std::allocator<std::complex<float> > > >]â

t.cc:21:   instantiated from here

/usr/include/c++/4.2.1/bits/stl_algo.h:3082: error: no match for âoperator<â in â__middle. __gnu_cxx::__normal_iterator<_Iterator, _Container>::operator* [with _Iterator = std::complex<float>*, _Container = std::vector<std::complex<float>, std::allocator<std::complex<float> > >]() < __first. __gnu_cxx::__normal_iterator<_Iterator, _Container>::operator* [with _Iterator = std::complex<float>*, _Container = std::vector<std::complex<float>, std::allocator<std::complex<float> > >]()â

/usr/include/c++/4.2.1/bits/stl_algo.h: In function âvoid std::__unguarded_linear_insert(_RandomAccessIterator, _Tp) [with _RandomAccessIterator = __gnu_cxx::__normal_iterator<std::complex<float>*, std::vector<std::complex<float>, std::allocator<std::complex<float> > > >, _Tp = std::complex<float>]â:

/usr/include/c++/4.2.1/bits/stl_algo.h:2362:   instantiated from âvoid std::__insertion_sort(_RandomAccessIterator, _RandomAccessIterator) [with _RandomAccessIterator = __gnu_cxx::__normal_iterator<std::complex<float>*, std::vector<std::complex<float>, std::allocator<std::complex<float> > > >]â

/usr/include/c++/4.2.1/bits/stl_algo.h:3176:   instantiated from âvoid std::__inplace_stable_sort(_RandomAccessIterator, _RandomAccessIterator) [with _RandomAccessIterator = __gnu_cxx::__normal_iterator<std::complex<float>*, std::vector<std::complex<float>, std::allocator<std::complex<float> > > >]â

/usr/include/c++/4.2.1/bits/stl_algo.h:3892:   instantiated from âvoid std::stable_sort(_RandomAccessIterator, _RandomAccessIterator) [with _RandomAccessIterator = __gnu_cxx::__normal_iterator<std::complex<float>*, std::vector<std::complex<float>, std::allocator<std::complex<float> > > >]â

t.cc:15:   instantiated from âvoid mysort(T, T) [with T = __gnu_cxx::__normal_iterator<std::complex<float>*, std::vector<std::complex<float>, std::allocator<std::complex<float> > > >]â

t.cc:21:   instantiated from here

/usr/include/c++/4.2.1/bits/stl_algo.h:2309: error: no match for âoperator<â in â__val < __next. __gnu_cxx::__normal_iterator<_Iterator, _Container>::operator* [with _Iterator = std::complex<float>*, _Container = std::vector<std::complex<float>, std::allocator<std::complex<float> > >]()â

/usr/include/c++/4.2.1/bits/stl_algo.h: In function â_ForwardIterator std::lower_bound(_ForwardIterator, _ForwardIterator, const _Tp&) [with _ForwardIterator = __gnu_cxx::__normal_iterator<std::complex<float>*, std::vector<std::complex<float>, std::allocator<std::complex<float> > > >, _Tp = std::complex<float>]â:

/usr/include/c++/4.2.1/bits/stl_algo.h:3094:   instantiated from âvoid std::__merge_without_buffer(_BidirectionalIterator, _BidirectionalIterator, _BidirectionalIterator, _Distance, _Distance) [with _BidirectionalIterator = __gnu_cxx::__normal_iterator<std::complex<float>*, std::vector<std::complex<float>, std::allocator<std::complex<float> > > >, _Distance = int]â

/usr/include/c++/4.2.1/bits/stl_algo.h:3182:   instantiated from âvoid std::__inplace_stable_sort(_RandomAccessIterator, _RandomAccessIterator) [with _RandomAccessIterator = __gnu_cxx::__normal_iterator<std::complex<float>*, std::vector<std::complex<float>, std::allocator<std::complex<float> > > >]â

/usr/include/c++/4.2.1/bits/stl_algo.h:3892:   instantiated from âvoid std::stable_sort(_RandomAccessIterator, _RandomAccessIterator) [with _RandomAccessIterator = __gnu_cxx::__normal_iterator<std::complex<float>*, std::vector<std::complex<float>, std::allocator<std::complex<float> > > >]â

t.cc:15:   instantiated from âvoid mysort(T, T) [with T = __gnu_cxx::__normal_iterator<std::complex<float>*, std::vector<std::complex<float>, std::allocator<std::complex<float> > > >]â

t.cc:21:   instantiated from here

….
….

/usr/include/c++/4.2.1/bits/stl_algo.h:3252: error: no match for âoperator<â in â* __first2 < * __first1â

Clearly a better error message (still a little longer than what we want it to be).

Although, BCCL provides better error message. The biggest drawback of the BCCL is that the restriction on the template parameter is not part of template prototype and hence not easily discoverable by algorithm user.  Language level support is needed to support that. The ConceptC++ was an experimental implementation of language level support. Significant parts of C++0x is derived from ConceptC++ and boost experimantation. I will discuss these changes in future posts.

The key to the wrapper definition is that the fact that all objects created on the stack are eventually destroyed when the object goes out of the scope. For example:

class Test{
    void method(){
         X a;
       // Implementation
       return;
     }

}

In the above case the X’s destructor is called when Test::method returns due to return call or exception.

Now let us use this knowledge to define the Wrap class. Let us first define the prefix, suffix and the wrapped class:

#include <iostream>
 using namespace std;
 void prefix() { cout << "prefix\n" }
 void suffix() { cout << "suffix\n"; }

// The person class looks like this:

class Person{
  std::string mName;
  Person(std::string pName): mName(name){}
  void printName(){
     std::cout << mName << std::endl;
  }

};

Now we can define the Wrap class as the following:

template <class T >
class Wrap {
     T * p ;
     public:
             Wrap (T * pp ) :p (pp) { }
             Call_proxy <T> operator ->() {
                   prefix ();
                   return Call_proxy<T>(p);
             }
};

template <class T >
class Call_proxy {
       T * p ;
       public :
              Call_proxy (T * pp ) :p (pp ){ }
              ˜Call_proxy () {
                     suffix ();
               }
               T * operator ->() {
                          return p ;
                }
 };

We can now wrap any object  of type T in the Wrap class. For example: we can take class Person and wrap it like Wrap<Person> person(new Person);

Any dereferencce of person using -> operator, results in call to operator-> of Wrap class. The method calls the prefix function , creates a new object of type Call_proxy containing the pointer to object. The method is called. On return from the method, Call_proxy is destroyed which implicitly results in call to suffix().

Let us test it. the following code snippet:

Wrap<Person> person(new Person("test"));
person->printName();

should print:

prefix
test
suffix

Rather straightforward and elegant to use. But, syntatic sugar to implement.

Note that suffix will be called even if the method returned due to exception.  This is better than Java, where the programmer has to take explicit action to make sure suffix is called in case of exception.

The Stroustrup’s paper also covers other issues like ownership, parametrization etc.  In most cases you may not need to worry about those. If you need to, take a look at the paper.

Happy proxying!

• Templates provide power with efficiency: Templates provide a lot of power without compromising efficiency. The Andrei’s book is full of examples of such power. A quick look inside the boost library provides examples of such power. Look at simple construct like boost::any which allows you to hold any type of data in it so that you can create a container/array which can hold boolean, integers, your various classes, etc. all at the same time. You can also look at a lot more complex construct like boost::lambda library which brings lambda programming to C++. Recently the boost has added boost::proto discussed in a seperate post on this site. The power really exists. Using these libraries can make your programming life a lot simpler. It is natural tendency to write your own templates on the same line. Should you or shouldn’t you?
• Templates are not well understood: The templates are not well understood yet. Most experienced C++ programmers find it hard to understand how to program templates. At present templates are a the stage as Object Oriented Programming was several years ago. The compilers have progressed to state where they can correctly compile templates. However, the power of templates is yet to be distilled in to developer community at large. So if you decide to use templates, please be patient and give plenty of time for developers to learn and get up to speed.
• Template debugging is horrifying experience for first time users: Error messages produced by compiler are horrifying large and complex. For simplest of errors, one gets 3 pages long error message with actual error who knows where. Once you get used to of debugging compilation issues you can generally figure out the error but it takes time to get used to of those errors. Template adaption will go a long way if the compilers start producing better error messages. But if you think compiler was the only issue just wait till you get to debuggers. The debuggers have not yet found a good way to deal with templates. Last but not least is compile time with templates. With most compilers, templates have to be included in header files. A simple change in the template requires compilation of all of your code which uses templates. This is like going backward on libraries.

In my experience, templates offer a lot of power and flexibility without compromising efficiency. The compilers can mostly deal with templates correctly. However debugger, compiler errors, and ways to reduce compile time can go a very long way in helping wider adaptation of templates. But if you are one of those early adapters and technology enthusiast, go ahead experiment and adapt templates and it will go a long way in helping your projects.

If you are going to use templates, you should start off by reading C++ FAQ Lite on template.

I recently came across Java’s proxy object. That is some cool technology. Using this one can wrap one object in another object in a completely typesafe way. From user’s point of view, the proxy object looks something like:

ProxiedObjectInterface obj = (ProxiedObjectInterface)ProxyCreator.newInstance( proxiedObject );

More details on proxy object are available here.

Since the interface exposed is of the proxied type, all calls to obj are typsef and can be checked by compiler. In java ProxyCreator class does not need to know anything about proxied object. This makes it very powerful.

I have been wondering if there is any easy way to create a similar facility in C++. I cannot think of one right away. I know we can do some cool things with template meta-programming. What will that be?