By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
449,369 Members | 1,599 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 449,369 IT Pros & Developers. It's quick & easy.

overloading on the template parameter arity of a template templateparameter

P: n/a
// I think that there is no way to write the template "cant_write_me" in
// this example. Would love to be wrong.

// one of many approaches that won't work
template< template< typename class struct cant_write_me{};
template< template< typename, typename class struct cant_write_me{};

template< typename struct arity_one{};
template< typename, typename struct arity_two{};

cant_write_me< arity_one instantiated_arity_one;
cant_write_me< arity_two instantiated_arity_two;
Jul 19 '06 #1
Share this Question
Share on Google+
4 Replies


P: n/a
Howard Gardner wrote:
// I think that there is no way to write the template "cant_write_me"
in // this example. Would love to be wrong.

// one of many approaches that won't work
template< template< typename class struct cant_write_me{};
template< template< typename, typename class struct
cant_write_me{};
'cant_write_me' here cannot be used because it's not a specialisation of
the original template. The name has to be unique or it has to be some
kind of specialisation (which requires the <after the name).
template< typename struct arity_one{};
template< typename, typename struct arity_two{};

cant_write_me< arity_one instantiated_arity_one;
cant_write_me< arity_two instantiated_arity_two;
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Jul 19 '06 #2

P: n/a
Victor Bazarov wrote:
Howard Gardner wrote:
>// I think that there is no way to write the template "cant_write_me"
in // this example. Would love to be wrong.

// one of many approaches that won't work
template< template< typename class struct cant_write_me{};
template< template< typename, typename class struct
cant_write_me{};

'cant_write_me' here cannot be used because it's not a specialisation of
the original template. The name has to be unique or it has to be some
kind of specialisation (which requires the <after the name).
>template< typename struct arity_one{};
template< typename, typename struct arity_two{};

cant_write_me< arity_one instantiated_arity_one;
cant_write_me< arity_two instantiated_arity_two;

V
I know :)

I've tried a large number of approaches that use specializations. I've
gotten very creative. I think that there simply is no way to write
cant_write_me.

I ran across it because I was trying to write a facility to use like this:

template_arity_of< class-template-identifier >::value

I did in fact manage to solve that problem, but the solution is pretty
unloveable. I have to write

template_arity_of
<
MACRO( class-template-identifier )
>::value
that solution looks like:

#include <ostream>
#include <cstddef>

typedef char no;
struct yes{ no value[2]; };

template< template< typename class >
yes test_1();

template< template< typename, typename class >
no test_1();

template< template< typename class >
no test_2();

template< template< typename, typename class >
yes test_2();

template< size_t, size_t >
struct template_arity_of;

template< >
struct template_arity_of< sizeof( yes ), sizeof( no ) >
{
static const size_t value = 1;
};

template< >
struct template_arity_of< sizeof( no ), sizeof( yes ) >
{
static const size_t value = 2;
};

#define MACRO( template_class_id ) \
sizeof( test_1< template_class_id >() ),\
sizeof( test_2< template_class_id >() )

template< typename struct arity_one;
template< typename, typename struct arity_two;

int
main()
{
using namespace std;
cout << template_arity_of< MACRO( arity_one ) >::value << endl;
cout << template_arity_of< MACRO( arity_two ) >::value << endl;
}

There're two really vile problems with this solution.

First, if N is the largest arity that I test for, implementing this
solution requires 2*N*N + N bits of syntax.

Second, there's the macro. It's there for three reasons. First, a
straight use requires N bits of syntax. Second, those bits of syntax are
very likely to contain a bug. Third, it's pretty obvious that N will
grow and it would be bad to have to rewrite all the uses.

I'm looking into another variation of the sizeof trick (sometimes used
for a restricted typeof) which would let me implement a less hateful
kludge, but I'd much rather learn that there's some way to write
"cant_write_me" after all.
Jul 19 '06 #3

P: n/a
Howard Gardner wrote:
template_arity_of
<
MACRO( class-template-identifier )
>::value
What about

TEMPLATE_ARITY_OF(class-template-identifier)

?

This is almost a religious issue. People hate macros, but I think the
reasons are related to macro usage that hides the runtime code. In a
compile-time facility like this, macros compliment template
meta-programming in the areas where it's not that great -- variable
number of template/function parameters.
First, if N is the largest arity that I test for, implementing this
solution requires 2*N*N + N bits of syntax.
Just use the Boost.Preprocessor library and have it generate these bits
of syntax for you.

Regards,
Arkadiy

Jul 19 '06 #4

P: n/a
Arkadiy wrote:
Howard Gardner wrote:
>template_arity_of
<
MACRO( class-template-identifier )
> >::value

What about

TEMPLATE_ARITY_OF(class-template-identifier)

?

This is almost a religious issue. People hate macros, but I think the
reasons are related to macro usage that hides the runtime code. In a
compile-time facility like this, macros compliment template
meta-programming in the areas where it's not that great -- variable
number of template/function parameters.
>First, if N is the largest arity that I test for, implementing this
solution requires 2*N*N + N bits of syntax.

Just use the Boost.Preprocessor library and have it generate these bits
of syntax for you.
I sure don't want to fight a battle in the macros holy war :)

I prefer not to use them, but sometimes using them is better. I think
that was a pretty clear case, and it was even clearer in the real code
where N was 8 right off the bat.

I macrod the template parameter syntax rather than the whole invocation
because that was enough to encapsulate the cruft.

I didn't use the Boost.Preprocessor library because I don't know it.
When I do eventually grapple with it, it will probably be because I want
to read the boost source code (Function, Lambda, TypeTraits, and MPL)
and not because I actually want to use it.

I got the other solution working. It looks like this:

#include <ostream>
#include <cstddef>

typedef char t01[1];
template< template< typename class >
t01 * test();

typedef char t02[2];
template< template< typename, typename class >
t02 * test();

template< size_t xSize >
struct template_arity_of
{
static const size_t value = xSize;
};

template< typename struct arity_one;
template< typename, typename struct arity_two;

int
main()
{
using namespace std;

cout
<< template_arity_of< sizeof( * test< arity_one >() ) >::value
<< endl;

cout
<< template_arity_of< sizeof( * test< arity_two >() ) >::value
<< endl;
}

It's better, but the invocation syntax is still ugly. It's tempting to
macro it, but in this case I'll probably refrain.

The situation is different than it was because the old reasons don't
apply anymore:

1) It's not horrifically long.

2) It's not particularly likely that someone will accidentally write
something that compiles but doesn't work.

3) Even though N will grow, the existing syntax won't have to change.

4) (I failed to mention this when I was apologizing for the macro in the
previous rendition) I don't think I'd use the macro personally.

The new temptation actually comes from the fact that I WANT to change
the invocation syntax, and will do it the very INSTANT that I can find
better syntax.
Jul 19 '06 #5

This discussion thread is closed

Replies have been disabled for this discussion.