The main idea behind this method was that in case if compiler uses stack to pass parameters to called functions and also in case caller is responsible for stack maintenance then, essentially, calling a function with N parameters of type T sized X each is basically the same as calling this function with 1 “big” parameter sized N * X and which memory footprint is corresponding to passed parameters. This can be achieved, using just regular templates, but it has some limitations:

• only arguments passed via stack pushing are supported;
• caller maintains stack state, therefore target function can’t accept ellipsis (….) as an argument, e.g. printf can’t be called using this method;
• target function has to accept N arguments of exactly same type, or if arguments are POD entities, exactly same size, otherwise — additional infrastructure has to be developed to provide correct type handling, which I hasn’t addressed (and am not planning to at the moment:)).

I think that’s all. Only working example is left to be published
We again used compile–time recursion to generate required a set of “big” types for us, for all possible cases (1 parameter, 2 parameters etc).

#include <cstdlib>
#include <vector>
#include <string>
#include <stdio.h>

// This is a "big" holder for function parameters
template <class TElement, int nElements>
struct ParamsHolder
{
    // Such layout ensures that copy constructors do get correctly called
    TElement m_Val[nElements];
};

template <class TElement, int nInst>
struct F
{
    typedef ParamsHolder<TElement, nInst> TParamsHolder;

    template <class TIt>
    static void f(void *pFunc, TIt itFirst, TIt itLast)
    {
        if (nInst == (itLast - itFirst))
        {
            // We're ready to call the function
            // Creating pseudo function signature
            void (*fun)(TParamsHolder) = reinterpret_cast<void(*)(TParamsHolder)>(pFunc);

            // Creating actual container for parameter values
            TParamsHolder paramsHolder;

            // Filling params holder from vector
            for (--itLast; itFirst <= itLast; --itLast)
                paramsHolder.m_Val[itLast - itFirst] = *itLast;

            // Calling the function
            fun(paramsHolder);
        }
        else
        {
            // We have to find right instantiation matching the number of passed parameters
            F<TElement, nInst + 1>::f(pFunc, itFirst, itLast);
        }
    }
};

template <class TElement>
struct F<TElement, 50>
{
    template <class TIt>
    static void f(void *pFunc, TIt itFirst, TIt itLast)
    {
        // runtime_assert(!"Please increase number of possible instantiations of F");
    }
};

template <class TElement, class TIt>
void call_fun(void *pFunc, TIt itFirst, TIt itLast)
{
    F<TElement, 0>::f(pFunc, itFirst, itLast);
}

// This is the target function that we'll pass as void*
void func(std::string p0, std::string p1)
{
    // parameters are correctly passed to here
}

int main(int argc, char** argv)
{
    // Container with parameters
    std::vector<std::string> strVec(2);

    strVec[0] = "Param 0!";
    strVec[1] = "Param 1!";

    // Getting raw function pointer
    void *pFunc = reinterpret_cast<void*>(&func);

    call_fun<std::string>(pFunc, strVec.begin(), strVec.end());

    return (EXIT_SUCCESS);
}

    template <class TParameterType>
    void call_function(void *pFunction, std::vector<TParameterType> pars)
    {
        pFunction(pars.begin(), pars.end());
    }

Easy to imagine — tricky to implement!

I felt like I remembered I couldn’t have achieved that some few years ago, in c++03, when I had similar problem for myself. Some discussion in the list made me feel that it’s really kinda tricky task. But what came to my mind were variadic templates from c++0x. Well, we already know, partially from my previous posts, how to manipulate parameters typed with variadic templates. So I decided to apply similar technique to accomplish this task as well, which I had success with!

Some few words on the above excerpt: it’s important that we don’t have the exact function pointer type inside call_function, we have clear void*. Otherwise the task would’ve been somehow simpler. But of course arity of the function actually pointed by pFunction should match the number of parameters contained in pars, otherwise we’ll end up calling function with wrong number of arguments, with all the consequences.

Typical usage of that would be to create a table of functions each accepting some specific number of args, keep it in some homogeneous way (like vector of void* pointers), and then, before calling call_function, to chose the right function pointer from the table based on the number of elements in pars vector. So that at runtime arbitrary number can be accepted and correctly passed.

So, there we go. Below is just the same example that I posted to the list, with some more comments. This is a completely working example, buildable at least with gcc-4.4.1 on Ubuntu 9.10, with -std=c++0x option.

#include <cstdlib>
#include <vector>
#include <stdio.h>

// We need to wrap function in class to bypass impossibility to have partially specialized template functions
// nInst is the "reverse" number of instantiations. If first called with value X, then each instantiation of F<Y>
// would serve a target function call with arity (X-Y). In total we'll have X instantiations, meaning that we'll have
// functions with up to X arguments
template <int nInst>
struct F
{
    // Iterator type and "collecting" list of function parameters, with corresponding values:
    // function pointer, first argument to add, end of arguments list, actual parameters values
    template <class TIt, class ...TParams>
    static void f(void* pFunc, TIt curIt, TIt lastIt, TParams ...params)
    {
        if (curIt == lastIt)
        {
            // We reach the end of arguments list
            // Converting void* to function pointer with required arity.
            void (*fun)(TParams...) = reinterpret_cast<void(*)(TParams...)>(pFunc);
            // Finally calling the function
            fun(params...);
        }
        else
        {
            // Extracting next argument
            TIt nextIt = curIt + 1;
            // recursively calling ourselves, previously adding extracted parameter to variadic parameters list
            F<nInst - 1>::f(pFunc, nextIt, lastIt, params..., *curIt);
        }
    }
};

// This specialization is required for compiler to finish producing compile--time instantiations of F with, which
// would happen otherwise because of the line above:  F<nInst - 1>::f(pFunc, nextIt, lastIt, params..., *curIt);
template<>
struct F<0>
{
    template <class TIt, class ...TParams>
    static void f(void* pFunc, TIt curIt, TIt lastIt, TParams ...params)
    {
        // In case designed number of parameters is not enough
        //runtime_assert(!"Please, increase number of instantiations of F");
    }
};

// This is the one that well use, the interface function,
// which actully introduces the syntactic sugar we want:
// func(v.begin(), v.end());
template <class TIt>
void call_fun(void* pFunc, TIt curIt, TIt lastIt)
{
    TIt nextIt = curIt + 1;
    // We default to max 50 arguments by now
    F<50>::f(pFunc, nextIt, lastIt, *curIt);
}

int main(int argc, char** argv)
{
    // Container with parameters
    std::vector<const char*> pCharVec(2);

    pCharVec[0] = "There we go, par = %s!";
    pCharVec[1] = "'I'm a parameter!'";

    // Function pointer, should handle ok the number of paramters in container
    // The actual signature isn't required here! It'll be "composed" based on the
    // number of paratmers in container above.
    // We explicitly show this by casting "something" (printf) to void*.
    void *pFunc = reinterpret_cast<void*>(&printf);

    call_fun(pFunc, pCharVec.begin(), pCharVec.end());

    return (EXIT_SUCCESS);
}

So what do we do?
Using compile-time recursion we create 50 possible instantiations of F (and consequently F::f), that implement function calling with 1, 2 … 50 arguments. Then, using runtime recursion we extract arguments from vector, one by one, and using variadic templates transforming arguments vector to real arguments list. At the same time we chose the right arity to use with the function pointer. As soon as we reach last argument we simply cast function pointer to function accepting the number of arguments deduced from arguments vector size, with arguments types deduced from vector elements type and, finally, we call that function using the list of arguments that we prepared using variadic templates. Pretty simple and works.

C++0x is sweeeeeet!

PS We can somehow more generalize it by passing function return value type as a template argument as well.
PPS This technique can be used with heterogeneous arguments containers as well. Of course, function pointers have to match types of arguments from container, and their quantity.
PPPS This technique can be used to create dynamic–languages like behavior: by using single function with single argument …, and by for example preceeding each parameter in the list with object representing its type, we can create a function that can be called with apriori unknown number of arguments and their types. And arguments for the function can created / decided in run–time!. This almost implements function call reflection in C++, without any additional runtime support required. Isn’t that even more sweeeeeeeet? ))

This example will show probably the most simple case: server holding a certificate and client verifying that certificate. So before running you’ll need to generate both: Ca and Server certs.

Here goes server part:

#include <cstdlib>
#include <iostream>
#include <vector>

#include <RCF/Idl.hpp>
#include <RCF/RcfServer.hpp>
#include <RCF/TcpEndpoint.hpp>
#include <RCF/FilterService.hpp>
#include <RCF/OpenSslEncryptionFilter.hpp>
#include <RCF/SessionObjectFactoryService.hpp>

RCF_BEGIN(I_X, "I_X")
RCF_METHOD_R1(int, test, int)
RCF_END(I_X)

class X
{
public:
    int test(int x)
    {
        std::vector<RCF::FilterPtr> transportFilters;
        RCF::getCurrentRcfSession().getTransportFilters(transportFilters);

        if (transportFilters.size() == 1)
        {
            boost::shared_ptr<RCF::OpenSslEncryptionFilter> filterPtr =
                boost::dynamic_pointer_cast<RCF::OpenSslEncryptionFilter>(
                    transportFilters.front());

            if (filterPtr)
            {
                RCF::getCurrentRcfSession().lockTransportFilters();
                RCF::getCurrentRcfSession().unlockTransportFilters();

                return x*x;
            }
        }

        return -1;
    }
};

int main()
{
    RCF::RcfServer server(RCF::TcpEndpoint(50001));

    RCF::SessionObjectFactoryServicePtr sofsPtr(new RCF::SessionObjectFactoryService());
    server.addService(sofsPtr);

    sofsPtr->bind<I_X, X>();

    RCF::FilterServicePtr fsPtr(new RCF::FilterService());
    fsPtr->addFilterFactory(RCF::FilterFactoryPtr(
        new RCF::OpenSslEncryptionFilterFactory("/path.../server.pem", "")));
    server.addService(fsPtr);

    server.start();

    std::cout << "Press Enter to exit..." << std::endl;
    std::cin.get();

    return (EXIT_SUCCESS);
}

and here goes client part:

#include <cstdlib>
#include <iostream>
#include <vector>

#include <RCF/Idl.hpp>
#include <RCF/RcfServer.hpp>
#include <RCF/TcpEndpoint.hpp>
#include <RCF/FilterService.hpp>
#include <RCF/OpenSslEncryptionFilter.hpp>
#include <RCF/SessionObjectFactoryService.hpp>

RCF_BEGIN(I_X, "I_X")
RCF_METHOD_R1(int, test, int)
RCF_END(I_X)

int main()
{
    RcfClient<I_X> client(RCF::TcpEndpoint(50001));

    client.getClientStub().createRemoteSessionObject();

    client.getClientStub().requestTransportFilters(
        RCF::FilterPtr(
            new RCF::OpenSslEncryptionFilter("", "", "/path.../ca.pem")));

    std::cout << client.test(21) << std::endl;

    return (EXIT_SUCCESS);
}

Very simple and very similar to example in RCF’s docs.

When we’re talking about transport–level security that’s undisputidly what is called a Secure Sockets Layer, or SSL. There is a number of free libraries out there implementing SSL, like popular OpenSSL or less popular Ajisai (based on cryptographic C++ library Botan). In my case I had to stick to OpenSSL as I also was about to use RCF for my client–server communication and RCF had already got support for OpenSSL integration to secure it’s transport channels.

OpenSSL uses certificates to make secured interactions work. So we immediately face a problem of getting these certificates. Searching the Internet would not give immediate understanding of what kind of certificate to we need and where to get the required one. so I’ve put all the pieces of information together and am sharing that knowledge with you

First of all let me point out that most of OpenSSL usage instructions here were extracted from here — a beautiful post regarding setting–up of a secured Apache web–server.

Let’s get away a bit from our original goal (securing a custom client–server communication channel with SSL) and will have a look at more common SSL usage scenario: securing a connection between some privately held web–server with client web–browsers. Using SSL here resolves 2 problems:

1. It ensures client that the server he’s talking to is really the actual server matching the one client wants to talk to and not the forged one. I.e. client can be sure that someserver.com is really someserver.com and not badguysserver.com trying to look like (pretend he is) a someserver.com.
2. It ensures that information between server and client will not be stolen or modified by any 3–rd party in between.

Both are achieved at first by ensuring server’s authenticity. Using asymmetrical cryptography server just proves that it does really hold the private key it wants client to believe it holds, i.e. server signs its message first. Then anyone having the public key (client) can ensure that the correct private key was used for signature. But when client receives a signature it has no idea if the signature comes really from that server: i.e. private key is proven, but not ensured that it is exactly the one required. In order to solve that, the hierarchy of Certificate Authorities was invented — client queries Certificate Authority if the received signature is authentic, or, more precisely, client just checks who issued the certificate that server used to make the signature. If server’s certificate was issued by a trusted Certificate Authority that would automatically mean that the server is authentic. Certificate Authority, before it issues certificates to for servers, performs a lot of checks and procedures. That means that only true server owners would receive certificates from CA. Basically “receiving” a certificate from CA would just mean that CA itself signs the certificate the server provides. Anyway, the list of trusted CA’s in its place is well known and is usually placed on client’s computer. Such CA’s are generally added to client’s system automatically during initial installation or update. Later client can add additional CA’s to his system (for example some not well known CAs that client still would like to trust to).

Once authenticity of server is proved using the method above, client and server interchange symmetrical cryptographic keys (using asymmetrical data interchange), and that keys are used to protect the session.

That’s why using a server certificate not signed by a well known CA for a web server would generally cause problems — clients visiting the web page will be prompted that the authenticity of the server is not checked. This also answers the question how CA’s earn their living — they just take some money to sign certificates of servers, in order for latter ones to be recognized by every potential client (which of course would already trust that CAs).

How one can try avoiding the need to sign his certificate with a well known CA?
Obviously, by using an unknown CA, for example even one’s own CA! Then just all clients have to be convinced to trust that home–made CA which won’t likely to happen
That’s why everyone out there uses pretty good known CAs for certificates located on public web services.

But what about our original case? There is a big difference with what we have in a web–server area: for our case we control both: the server and the client. That means that we can setup the client to check against any CA that we want and not only against some narrow list of big known trusted CAs.

So for our scenario we need to, firstly, create our own CA’s private key and CA’s certificate, and, secondly, create an actual server certificate and sign it with our CA’s certificate. After that we can embed CA certificate to client’s code so that client will check server’s authenticity using our own CA. And this will immediately solve 3 problems for us:

1. Our clients will check our server’s authenticity
2. Connection between our server and our client will be protected
3. We won’t spend money on getting signature / certificate from public recognized CA

So how can we manage that?

As it was first noted, let’s deal with our own CA certificate. To create it we’ll need first to generate a private key for our CA.

openssl genrsa -out ca.key 4096

This will create a 4096 bit RSA private key for our CA, named ca.key.

Now we have to create a CA certificate request based on CA private key for our future signed CA certificate. We will then sign this certificate request using the same key we just generated (so we’ll have a self–signed CA certificate).

openssl req -new -key ca.key -out ca.req

This will crete a certificate request located in ca.req file.

Finally we have to sign our CA certificate request with itself, i.e. with it’s own private key:

openssl x509 -req -days 3650 -in ca.req -signkey ca.key -out ca.crt

This way we get our home–made CA certificate valid for 10 years, signed with our CA key. The certificate is located in ca.crt file. This certificate will be embedded into our client, to check authenticity of our server.

Later after initially publishing this article I discovered a single command that could substitute 2 commands from the above

openssl req -new -x509 -days 3650 -key ca.key -out ca.crt

This should create self-signed CA certificate without intermediate step of creation of CA certificate request.

Having CA private key and CA certificate we now would like to create server’s certificate.
This is pretty similary to creation of CA’s certificate with the only exclusion: on step 3 we will sign our server certificate not with itself (its own private key), but with our CA’s private key.

// Creating server private key
openssl genrsa -out server.key 4096
// Generating server certificate request, based on server private key
openssl req -new -key server.key -out server.req
// Signing server's certificate request with our CA's certificate (using CA's private key to prove that we have rights to use it)
openssl x509 -req -days 3650 -set_serial 01 -in server.req -CA ca.crt -CAkey ca.key -out server.crt

Voila! Now you can make your server use server.crt to use for server-side SSL and ship your clients with ca.crt, to check server’s authenticity. Obviously you can create certificate(s) for your clients just in the same manner, if you require them.

Please note, that in order to use certificate on server you’ll need both: your server’s certificate and server’s private key used to produced that certificate. In some cases you’ll be able to provide both separately and in some others (like RCF library) you’ll need to combine them into one file:

cat server.crt server.key > server.pem

That’s pretty all — what I need for my RCF + OpenSSL stuff.

I decided to develop this idea a bit further to allow “multi–level” delayed construction of objects.

In other words to allow delayed construction of objects that by themselves parameters for other objects being delayed–constructed. This would allow one to create a chain of such delayed–constructed objects. Until main (root) object is requested to be constructed — the rest of objects, upon which the root one is dependent, will also remain unconstructed. But as soon as root obj is created — all the others will be created in a chain, in a depth–first manner.

The actual implementation idea behind that functionality is very simple: we’ll just add a type cast operator for our DelayedConstructor helper. This type cast operation will actually create the embedded object. Having this we can pass instances of DelayedConstructor in place of actual objects. When this would happen all appropriate objects will be created and passed as required.

By the way, all these things are done in a static manner, without using procedural code from the interface perspective — we just say “prepare to create Obj with parameters Args… when we ask you to”. — all in a single line.

Besides that I added creation policies for the objects being created, so we can use new, copy or move–like construction:

template <class T>
struct CreateNew
{
    typedef T* TCreated;

    template <class ...Args>
    TCreated Create(Args ...args)
    {
        return new T(args...);
    }
};

template <class T>
struct CreateCopy
{
public:
    typedef T TCreated;

    template <class ...Args>
    TCreated Create(Args ...args)
    {
        return TCreated(args...);
    }
};

template <class T>
struct CreateMove
{
public:
    typedef T&& TCreated;

    template <class ...Args>
    TCreated Create(Args ...args)
    {
        return T(args...);
    }
};

These are self–explanatory and don’t require much attention I believe.

Instead, let’s have a look at our modified DelayedConstructor: it has just an added creation policy handing in its inner worker class plus adds an appropriate type cast operator.

template <class TObject, template <class T> class TCreationPolicy = CreateNew>
class DelayedConstructor
{
public:
    typedef typename TCreationPolicy<TObject>::TCreated TCreated;

    template <class ...Args>
    DelayedConstructor(Args ...args)
    {
        class ConstructHelper
        {
        public:
            static TCreated DoConstruct(Args ...args)
            {
                return TCreationPolicy<TObject>().Create(args...);
            }
        };

        m_funHelper = boost::bind(ConstructHelper::DoConstruct, args...);
    }

    TCreated operator()()
    {
        return m_funHelper();
    }

    operator TCreated()
    {
        operator()();
    }

protected:
    boost::function<TCreated(void)> m_funHelper;
};

That’s pretty all.

Now we can happily do things like that:

//Creation via operator new
DelayedConstructor<int> dc(42);
int *pInt = dc();

//Creation via returning a copy from inner stack
int  vInt = DelayedConstructor<int, CreateCopy>(42);

//2--level delayed construction:
//First we create an int on stack via copying and the
//we create an std::string via new
//Int argument is created only _after_
//std::string has been requested to create an instance
delayedConstructor<std::string> strDc = DelayedConstructor<std::string>(DelayedConstructor<int, CreateCopy>(42));
std::string str = strDc();

I’d like to add to these starter–oriented hints yet another one. The question risen usually when one first meets variadic templates is “a… is it possible to find out which types exactly were passed, like enumerate them and all sorts of such things?…” Usual answer refers to mentioned above count<T...> implementation only, saying that there could be little done with regards to the rest of problems. While it is true to some extent it is not actually.

This is indeed true if to be armed with pure compiler support only and have no time to create the whole required infrastructure. But wait, there already exist a number of excellent libraries dealing with C++ type sequences in all the ways allowing to get every bit of information from them. One of these is Boost MPL.

I won’t get into details with it: go on your own. Instead I’ll present a simple way to turn an arbitrary argument pack from variadic template to such a sequence. That would automatically mean you can have any information on the passed types you just might think of. Yes, you can count types, iterate through them, compare them do anything. The example I’ll give will be based on mpl::vector sequence. It doesn’t really matter which one to use, but vector is indexable, bidirectionally accessible so it might feet your needs the best.

The approach uses the same know recursive technique as is usually used in examples how to count the number of variadic template arguments.

//General definition of the helper class
template <typename ...Args> struct FromVariadic;

//This specialization does the actual job: it splits the whole pack
//into 2 parts: one single type T and the rest of types Args...
//As soon as it is done T is added to an mpl::vector.
//"bottom--up" recursion is used to fetch all types
template <class T, typename ...Args>
struct FromVariadic<T, Args...>
{
    typedef typename mpl::push_front<typename FromVariadic<Args...>::type, T>::type type;
};

//This is a specialization for the case when only one type is passed
//and also finishes recursive descent
template <class T>
struct FromVariadic<T>
{
    typedef mpl::vector<T> type;
};

//This one handles the case when no types where passed at all
template <>
struct FromVariadic<>
{
    typedef mpl::vector<> type;
};

Having this defined you can use it in the following way:

template <typename ...Args>
class A
{
    typedef typename FromVariadic<Args...>::type MplVector;

    //Do whatever you might imagine with MplVector ---
    //this is really a boost::mpl::vector !
};

And yes, this is compilable by gcc-4.4.1, with c++0x enabled.

template <class TObject>
class DelayedConstructor
{
public:
    template <class ...Args>
    DelayedConstructor(Args ...args)
    {
        class ConstructHelper
        {
        public:
            static TObject* DoConstruct(Args ...args)
            {
                return new TObject(args...);
            }
        };
        m_funHelper = boost::bind(ConstructHelper::DoConstruct, args...);
    }

    TObject* operator()()
    {
        return m_funHelper();
    }

protected:
    boost::function<TObject*(void)> m_funHelper;
};

And here we use it:

class A
{
public:
    A(int a, std::string str) { }
};

//Binding values to the constructor
DelayedConstructor<A> dc(21, "Good stuff!");

//Actually creating an object
A *pA = dc();

To me it looks very simple and rational. And keep in mind that it would work with any number of constructor arguments, which you don’t have to worry about at all. Just Use it.

But what’s left for a homework? Okay, let’s teach it to accept binding of only specific args. As we are used to do with regular functions.

P.S. But what is even more exciting is that as soon as c++0x lambdas come to play the solution of this problem would become trivial by using lambda factory function for desired class, which will eliminate usage of boot::bind.