Curiously recurring template pattern

[iuweriur]

A few questions on the curiously recurring template pattern:

This page:
http://c2.com/cgi/wiki?CuriouslyRecurringTemplate

this part:
template<typena me T> struct ArithmeticType
{
T operator + (const T& other) const
{
T result(*this); // <--------- THIS LINE
result += other;
return result;
}
// etc.
};

In the above marked line, how comes that one doesn't need any type of
cast from *this to const T& ?

And if the cast is needed, what type of cast would you use?
I suppose that the reinterpret_cas t would not be portable (in theory, or
also in practice?) and anyway does not handle cases with MI, and the
dynamic_cast is slow and works only on polimorphic types, right?


Another question on this page:
http://www.informit.com/articles/art...31473&seqNum=3

At the end there is written:
----
In general, CRTP is useful to factor out implementations of interfaces
that can only be member functions (for example, constructor,
destructors, and subscript operators).
----

For the subscript I can maybe understand, but how can you do it for
constructors and destructors?
Thank you
iuweriur

[Alf P. Steinbach]

* iuweriur:

A few questions on the curiously recurring template pattern:

This page:
http://c2.com/cgi/wiki?CuriouslyRecurringTemplate

this part:
template<typena me T> struct ArithmeticType
{
T operator + (const T& other) const
{
T result(*this); // <--------- THIS LINE
result += other;
return result;
}
// etc.
};

In the above marked line, how comes that one doesn't need any type of
cast from *this to const T& ?
Presumably the intent is that class T has a public constructor that takes
an ArithmeticType< T> argument and uses dynamic_cast down to T.

I think that's ugly, and doing a downcast in ArithmeticType is also ugly.

Downcasting is what virtual functions are all about achieving in a type-
safe and efficient manner, so I'd write
template<typena me T>
class ArithmeticType
{
protected:
virtual T const& thisT() const = 0;

T operator + (const T& other) const
{
T result( thisT() );
result += other;
return result;
}
// etc.
};
And if the cast is needed, what type of cast would you use?
No cast needed; see above.

Another question on this page:
http://www.informit.com/articles/art...31473&seqNum=3

At the end there is written:
----
In general, CRTP is useful to factor out implementations of interfaces
that can only be member functions (for example, constructor,
destructors, and subscript operators).
----

For the subscript I can maybe understand, but how can you do it for
constructors and destructors?

A set of classes may have very similar constructors or constructor parts,
differing only in the concrete types involved.

Such a constructor can be factored out in a CRT base class.

For example, the CRT base class might be Window, and a typical derived
class Button, and Button might have a static function nativeWindowHan dle()
that the Window class constructor calls; see FAQ 23.4 for other techniques
to do just about the same without using the CRT pattern.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Jonathan Turkanis]

"Alf P. Steinbach" <al***@start.no > wrote in message
news:40******** ******@news.ind ividual.net...

* iuweriur:

A few questions on the curiously recurring template pattern:

This page:
http://c2.com/cgi/wiki?CuriouslyRecurringTemplate

this part:
template<typena me T> struct ArithmeticType
{
T operator + (const T& other) const
{
T result(*this); // <--------- THIS LINE
result += other;
return result;
}
// etc.
};

In the above marked line, how comes that one doesn't need any type of cast from *this to const T& ?
Presumably the intent is that class T has a public constructor that

takes an ArithmeticType< T> argument and uses dynamic_cast down to T.

A static_cast should do the trick here. I think it's required in the
above example. Maybe the authors were using VC6.

Jonathan

[Jonathan Turkanis]

"Jonathan Turkanis" <te******@kanga roologic.com> wrote in message
news:2l******** ****@uni-berlin.de...

A static_cast should do the trick here. I think it's required in the
above example. Maybe the authors were using VC6.

Whoops. VC6 needs the cast too.

[Alf P. Steinbach]

* Jonathan Turkanis:

"Alf P. Steinbach" <al***@start.no > wrote in message
news:40******** ******@news.ind ividual.net...

* iuweriur:

A few questions on the curiously recurring template pattern:

This page:
http://c2.com/cgi/wiki?CuriouslyRecurringTemplate

this part:
template<typena me T> struct ArithmeticType
{
T operator + (const T& other) const
{
T result(*this); // <--------- THIS LINE
result += other;
return result;
}
// etc.
};

In the above marked line, how comes that one doesn't need any type of cast from *this to const T& ?

Presumably the intent is that class T has a public constructor that

takes

an ArithmeticType< T> argument and uses dynamic_cast down to T.

A static_cast should do the trick here.

Keeping in mind that no cast is needed if the scheme shown in my earlier
posting is used: no, the reason I wrote dynamic_cast, not static_cast, is
that the (presumed) constructor is public, and so cannot know what kind of
beast it's passed. Of course ArithmeticType then needs at least one
virtual function.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[iuweriur]

Jonathan Turkanis wrote:

A static_cast should do the trick here. I think it's required in the
above example. Maybe the authors were using VC6.

Jonathan

Hey how can you use static_cast to downcast like this?
When the compiler compiles the ArithmeticType, *this is not guaranteed
to be of type T as far as the compiler knows

Am I wrong?

[John Harrison]

On Sat, 10 Jul 2004 03:50:56 -0500, iuweriur <iu******@hhhh. com> wrote:

Jonathan Turkanis wrote:

A static_cast should do the trick here. I think it's required in the
above example. Maybe the authors were using VC6.
Jonathan

Hey how can you use static_cast to downcast like this?
When the compiler compiles the ArithmeticType, *this is not guaranteed
to be of type T as far as the compiler knows

Am I wrong?

Isn't that the whole point of static_cast?

If the CRTP is being used correctly *this will be as base class of type T
and the static_cast will work. If CRTP is being used incorrectly then
*this will not be a base class of T and you will get a compile error.

john

[Alf P. Steinbach]

* John Harrison:

On Sat, 10 Jul 2004 03:50:56 -0500, iuweriur <iu******@hhhh. com> wrote:

Jonathan Turkanis wrote:

A static_cast should do the trick here. I think it's required in the
above example. Maybe the authors were using VC6.
Jonathan

Hey how can you use static_cast to downcast like this?
When the compiler compiles the ArithmeticType, *this is not guaranteed
to be of type T as far as the compiler knows

Am I wrong?

Isn't that the whole point of static_cast?

If the CRTP is being used correctly *this will be as base class of type T
and the static_cast will work. If CRTP is being used incorrectly then
*this will not be a base class of T and you will get a compile error.

Well I'm wondering about that: how does it work with 'export'? <g/>

Okay I don't have a compiler that supports 'export' so don't know much
about it, but if it's able to compile templates separately then it
seems that the _linker_ must detect the invalid static_cast.

So, is that detection required by the standard (if so, where), and are
linkers really that smart?

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Rob Williscroft]

Alf P. Steinbach wrote in news:40******** *******@news.in dividual.net in
comp.lang.c++:

Isn't that the whole point of static_cast?

If the CRTP is being used correctly *this will be as base class of
type T and the static_cast will work. If CRTP is being used
incorrectly then *this will not be a base class of T and you will
get a compile error.
Well I'm wondering about that: how does it work with 'export'? <g/>

What about export makes you think it won't work ?
Okay I don't have a compiler that supports 'export' so don't know much
about it, but if it's able to compile templates separately then it
seems that the _linker_ must detect the invalid static_cast.
The "compilatio n" done by export is only half the "compilatio n" that
needs to be done. A compiler that implements export must do the
second half (instantiation) at _link_ time.

So, is that detection required by the standard (if so, where), and are
linkers really that smart?

No the compiler (whenever it compiles) detects the errors:

template < typename A, typename B >
A &my_cast( B &b )
{
return static_cast< A & >( b );
}

struct base {} b;
struct derived : base {} d;

int main()
{
base &b = d;
derived &d = my_cast< derived >( b );

int &i = my_cast< int >( d ); /* <-- error */
}

If my_cast<>() were exported then the export mechanism would need to
be told sufficient information about base and derived so that it could
be instantiated, and sufficient info' about derived so it knows it can't
do the static_cast< int & >, there is no difference between the exported
code calling static_cast<>, or operator + or trying to invoke A::foo().

When the compiler instantiates the exported code it need's to
callback (if you like) to the main compile to get all the info'
about the paramiter types.

Rob.
--
http://www.victim-prime.dsl.pipex.com/

[Alf P. Steinbach]

* Rob Williscroft:

Alf P. Steinbach wrote in news:40******** *******@news.in dividual.net in
comp.lang.c++:

Isn't that the whole point of static_cast?

If the CRTP is being used correctly *this will be as base class of
type T and the static_cast will work. If CRTP is being used
incorrectly then *this will not be a base class of T and you will
get a compile error.

Well I'm wondering about that: how does it work with 'export'? <g/>

What about export makes you think it won't work ?

The reason I'm wondering was given in the next paragraph, cited below:

Okay I don't have a compiler that supports 'export' so don't know much
about it, but if it's able to compile templates separately then it
seems that the _linker_ must detect the invalid static_cast.

The "compilatio n" done by export is only half the "compilatio n" that
needs to be done. A compiler that implements export must do the
second half (instantiation) at _link_ time.

By studying your answers below I think I see what's going on. It's
not instantiation at _link_ time but instantiation that uses precompiled
information. In other words, the compiler needs access to the compiled
form of the template, not just the header file -- and if that's the
case then 'export' seems to be a very limited feature.

The alternative is that the linker invokes a partial compilation, or at
least class hierarchy information, but below you answer "no" to that?

So, is that detection required by the standard (if so, where), and are
linkers really that smart?

No the compiler (whenever it compiles) detects the errors:

When the compiler instantiates the exported code it need's to
callback (if you like) to the main compile to get all the info'
about the paramiter types.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?