Thanks, I had completely missed default arguments in templates! It may help
when some implementations are much more common than others. However, in cases
when no such distinctions can be made, the problem is still there.

Regards,
Roger

Thanks, I had completely missed default arguments in templates! It may help
when some implementations are much more common than others. However, in cases
when no such distinctions can be made, the problem is still there.

Regards,
Roger

Thanks, I had completely missed default arguments in templates! It may help
when some implementations are much more common than others. However, in cases
when no such distinctions can be made, the problem is still there.

Regards,
Roger

> Roger Larsson (d90rogla@isy.liu.se) wrote:
>> To simplify the declarations I would like to generalize the template
>> mechanism to include typedefs as well. For example:
>> template <class T> struct A {T value;};
>> template <class R, class T> struct B {R implementation; T &op ();};
>> template <class T> typedef B<A<T>,T> BA<T>;

riyer@interaccess (Ravikant Iyer) writes:
> template <class T>
>    struct cant_think_of_a_name_for_this {typedef B<A<T>, T> BA<T>;};
> cant_think_of_a_name_for_this::BA<some_thing> some_var ;

Or, for a more succinct convention, give the class template the descriptive
name, and give the dummy name `t' to the typedef which is its sole member.
You can use the result just like a typedef template, except that you append
`::t' to it:

     template <class T> struct BA {typedef B<A<T>,T> t;};
     BA<Foo>::t foo_ba;

I agree that actual typedef templates would make for more readable code and a
more uniform language.

Roger Larsson <d90rogla@isy.liu.se> writes:

>I'm working on a datastructure library making extensive use of
>layered template instantiations. To simplify the declarations I
>would like to generalize the template mechanism to include
>typedef:s as well.
[...]
>These kind of constructions arise when specifying implementation as well as
>contents through template arguments. As you can see, the declarations grow
>exponentially.
>
>Of course this could be solved by introducing new derived classes but
>that requires redefinition of at least all constructors in every new class.
>To avoid down casting, garding against potential compiler problems, we must
>also redefine all functions returning references to the base class.
>
>What do you think, am I lazy, have I missed something or do I have a point?

I think you have a very good point.

--
Fergus Henderson                       | I'll forgive even GNU emacs as
fjh@cs.mu.oz.au                        | long as gcc is available ;-)
http://www.cs.mu.oz.au/~fjh            |             - Linus Torvalds

In article <3pihjo$6pp@newsy.ifm.liu.se>,
Roger Larsson  <d90rogla@isy.liu.se> wrote:
>[...]
>template <class T>
>struct A {
> T value;
>};
>
>template <class R, class T>
>struct B {
> R implementation;
> T &op ();
>};
>
>template <class T>
>typedef B<A<T>, T> BA<T>;  [// why not legal?]
>[...]

D&E 15.8 mentions template typedefs: "The extension is technically
trivial, but I'm not sure how wise it would be to introduce another
renaming feature."  Stroustrup instead discusses how derivation from
templates is a powerful feature, though like you a say it then becomes
a real pain when trying to assign a B<A<T>,T> to a derived BA<T> or
when trying to use the types compatibly in a function declaration.

I wouldn't mind having tmeplate typedefs, but most of the situations
I've encountered over the years where I have needed them are solved by
default template arguments.  For example, I use to do:

 template<class T, class Comp>  // special T's need to use this class
 class ListComp {/*...*/};

 template<class T>  // most users use this class
 class List : public List<T,DefaultCompare<T> > {/*...*/};

but now I can simply do:

 template<class T, Comp = DefaultCompare<T> >
 class List {/*...*/};

In your example, if you don't mind swapping your arguments you can
simply use B instead of BA:

 template <class T, class R = A<T> >
 struct B {
  R implementation;
  T &op ();
 };

 B<Foo> ba;

Or, if you impose a requirement on R that it define a MyType nested
type you can preserve the original order of your template arguments:

 template <class T>
 struct A {
  T value;
  typedef T MyType;
 };

 template <class R, class T = R::MyType>  // I think this is legal
 struct B {
  R implementation;
  T &op ();
 };

 B<A<Foo> > ba;

Jamshid Afshar
jamshid@ses.com

Roger Larsson (d90rogla@isy.liu.se) wrote:
: Hi.

: I'm working on a datastructure library making extensive use of
: layered template instantiations. To simplify the declarations I
: would like to generalize the template mechanism to include
: typedef:s as well. For example:
: ----------------------
: template <class T>
: struct A
: {
:  T value;
: };

: template <class R, class T>
: struct B
: {
:  R implementation;
:  T &op ();
: };

: template <class T>
: typedef B<A<T>, T> BA<T>;
: --------------------------
How about using the following
template <class T>
struct cant_think_of_a_name_for_this
{
 typedef B<A<T>, T> BA<T>;
};
now u can simply say
cant_think_of_a_name_for_this::BA<some_thing> some_var ;

This way you need not have a derrived class to specialize your class
B. and just one struct can be used for all such typedefs needed by
your project .

: These kind of constructions arise when specifying implementation as well as
: contents through template arguments. As you can see, the declarations grow
: exponentially.

: Of course this could be solved by introducing new derived classes but
: that requires redefinition of at least all constructors in every new class.
: To avoid down casting, garding against potential compiler problems, we must
: also redefine all functions returning references to the base class.

: What do you think, am I lazy, have I missed something or do I have a point?

: // Roger
-Ravikant

In article <3pihjo$6pp@newsy.ifm.liu.se>,
Roger Larsson  <d90rogla@isy.liu.se> wrote:
>Hi.
>
>I'm working on a datastructure library making extensive use of
>layered template instantiations. To simplify the declarations I
>would like to generalize the template mechanism to include
>typedef:s as well. For example:

 So would Australia. It is on our list of things we
would like to see done.

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,
        81A Glebe Point Rd, GLEBE   Mem: SA IT/9/22,SC22/WG21
        NSW 2037, AUSTRALIA     Phone: 61-2-566-2189

Hi.

I'm working on a datastructure library making extensive use of
layered template instantiations. To simplify the declarations I
would like to generalize the template mechanism to include
typedef:s as well. For example:
----------------------
template <class T>
struct A
{
 T value;
};

template <class R, class T>
struct B
{
 R implementation;
 T &op ();
};

template <class T>
typedef B<A<T>, T> BA<T>;
--------------------------
These kind of constructions arise when specifying implementation as well as
contents through template arguments. As you can see, the declarations grow
exponentially.

Of course this could be solved by introducing new derived classes but
that requires redefinition of at least all constructors in every new class.
To avoid down casting, garding against potential compiler problems, we must
also redefine all functions returning references to the base class.

What do you think, am I lazy, have I missed something or do I have a point?

// Roger