Re: Typedeffing a function template instance
On Jul 14, 5:04 pm, Alexander Lamaison <nos...@example.com> wrote:
On Mon, 13 Jul 2009 22:09:28 CST, Zachary Turner wrote:
typedef int (*return_int_no_arguments)();
return_int_no_arguments call_foo_for_ints = foo<int>;
return_int_no_arguments call_foo_for_doubles = foo<double>;
First, thanks to everyone who took the time to reply. I have many options
to choose from. For the moment I just wrapped a call to foo<bar> in
another function but I may change this to the suggestion above which has
appeared a couple of times.
Typedefing lots of functions like this is rare, but of course
everything is needed at some point or another. If you actually have a
use case in mind for something like this, maybe you should elaborate
more on what it is and we can see if there's a better way to
accomplish it.
What I was trying to make was basically a 'compile-time function factory'
where the template parameter defines some varying aspect of the behaviour
of an otherwise largely identical function. I had some functions that were
identical except for their final call to a Windows API. I'm passing the
actual API call wrapped in a functor as the template argument.
However, I wanted all this jiggerypokery to be hidden from the user so I
tried to typedef instantiations of the functions to the names of the
original functions they were replacing. I tried to do it just as I would
have for a particular instance of a class template. Of course, I as
forgetting that functions are instances not types.
Thanks everyone.
There are a couple of ways to do what you want. The simplest is
probably to use a boost::function (assuming you can use boost). For
example:
class foo
{
public:
typedef boost::function<Ret (Arg1, Arg2, Arg3)> behavior_func;
foo(behavior_func behavior)
: custom_behavior_(behavior)
{
}
void do_something()
{
RetType t = custom_behavior_(1, 2, 3);
}
private:
boost::function<RetType (Arg1Type, Arg2Type, Arg3Type)>
custom_behavior_;
};
then the client simply passes a pointer to the function into the
constructor.
If you need some flexibility, particularly the ability for the client
to customize the types that a class sees, or perhaps providing
multiple different behaviors to be used in different circumstances,
then one common way to achieve this is through "policy" classes. See
Alexandrescu's Modern C++ Design for a more thorough treatment of
policies. But the 5 minute version is that your template parameter is
actually a struct which mandates a specific compile-time interface
that all types used to parameterize this class must satisfy.
Generally you don't ever create an instance of this type (although
sometimes it might be desirable), you just use it as a way to provide
customizability, typically via agreed-upon-in-advance typedefs that
the struct contains, or perhaps static inline functions defined by the
struct. Here's an example (I'll use some Windows specific stuff since
you mentioned it).
struct native_interlocked_integer
{
boost::uint32_t increment(boost::uint32_t& t)
{
return ::InterlockedIncrement(&t);
}
boost::uint32_t decrement(boost::uint32_t& t)
{
return ::InterlockedDecrement(&t);
}
boost::uint32_t compare_exchange(boost::uint32_t& dest,
boost::uint32_t exch, boost::uint32_t comp)
{
return ::InterlockedCompareExchange(&dest, exch, comp);
}
};
/*Note that you can't actually do this in C++ since there's no such
thing as an object_monitor<T> class. I made it up just for the sake
of illustration. Pretend,
however, that it operates the same as Java's monitor or C#'s monitor*/
struct monitored_interlocked_integer
{
boost::uint32_t increment(boost::uint32_t& t)
{
::object_monitor<int>::scoped_lock(&t);
return ++t;
}
boost::uint32_t decrement(boost::uint32_t& t)
{
::object_monitor<int>::scoped_lock(&t);
return --t;
}
boost::uint32_t compare_exchange(boost::uint32_t& dest,
boost::uint32_t exch, boost::uint32_t comp)
{
::object_monitor<int>::scoped_lock(&t);
boost::uint32_t orig = dest;
if (dest == comp)
dest = exch;
return orig;
}
};
template<class locker>
class foo
{
public:
void do_something()
{
//...
locker::increment(var);
//...
}
private:
volatile boost::uint32_t var;
};
Now you can simply create this as
foo<native_interlocked_integer> native_locked_foo;
foo<monitor_interlocked_integer> monitor_locked_foo;
One nice feature of policy classes is that since the class need not be
instantiated, and the functions are static, policy class functions can
easily be inlined directly at the point of invocation. With a
boost::function you incur overhead in space as well as runtime, since
not only are you storing a reference to the object in your class for
later use at some arbitrary time, but you also have to invoke the
function through this reference, probably stored internally as a
function pointer, meaning you don't get the inlining.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]