Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   C++ (http://www.velocityreviews.com/forums/f39-c.html)
-   -   overloading on the template parameter arity of a template templateparameter (http://www.velocityreviews.com/forums/t455495-overloading-on-the-template-parameter-arity-of-a-template-templateparameter.html)

Howard Gardner 07-19-2006 08:08 PM

overloading on the template parameter arity of a template templateparameter
 
// 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;

Victor Bazarov 07-19-2006 08:28 PM

Re: overloading on the template parameter arity of a template template parameter
 
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



Howard Gardner 07-19-2006 09:15 PM

Re: overloading on the template parameter arity of a template templateparameter
 
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.

Arkadiy 07-19-2006 10:06 PM

Re: overloading on the template parameter arity of a template template parameter
 
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


Howard Gardner 07-19-2006 11:10 PM

Re: overloading on the template parameter arity of a template templateparameter
 
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.


All times are GMT. The time now is 04:06 PM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.