Re: [boost] Re: A config.hpp #define for operator member templates

From: David Abrahams (abrahams_at_[hidden])
Date: 2000-08-04 16:27:41

----- Original Message -----
From: "Daryle Walker" <darylew_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Wednesday, August 02, 2000 6:24 PM
Subject: [boost] Re: A config.hpp #define for operator member templates

> on 8/1/00 1:39 PM, Howard Hinnant at hinnant_at_[hidden] wrote:
>
> > Daryle Walker wrote on 8/1/2000 1:05 PM
> >> My compiler, Metrowerks CodeWarrior Pro 5 for Mac OS (with 5.3 update),
> >> allows some types of member templates, but does not allow others.  For
> >> instance I couldn't define a "template <typename T> operator T*()
const"
> >> method for a class I tried to write.  Could we add another #define in
> >> config.hpp for this type of compiler limitation (maybe
> >> BOOST_NO_TEMPLATE_MEMBER_OPERATORS, but I don't know the exact range of
the
> >> limitation)?
> >
> > This limitation will be lifted in Pro 6 (real soon now).
>
> But that won't help people using CWP 5 now (or still using it when CWP 6
> comes out) or any other compiler that may have the same problem.  So we
may
> need some sort of guard anyway.  The config.hpp file already shields some
> errors according to compiler version, so this guard can be done the same
> way.
>
> I know the limitation does not let me create generic pointer conversions
or
> generic member-pointer conversions, but I don't know what other
(conversion)
> operators it affects.  We would need to know that before establishing any
> new BOOST_NO_TEMPLATE_* guard.

It affects all template conversion operators in CW 5.3. This is all
documented in the CW 5 release notes. In fact, I think the real limitation
is that CW 5.3 doesn't implement implicit conversions through member
templates. Thus, you can have a template constructor, but an implicit
conversion will never proceed through it. Since a template conversion
operator is most useful for implicit conversion, I think they just
prohibited them altogether.

> On a related note, shouldn't we enforce any hierarchies in the guards?
For
> instance, if BOOST_NO_USING_TEMPLATE is defined, all other
template-related
> guards should be defined, without having to explicitly set every one of
> those guards in a compiler listing.  I guess this could come after the
> compiler-specific portion.  For example:
>
> #ifdef BOOST_NO_USING_TEMPLATE
> #define BOOST_NO_DEPENDENT_TYPES_IN_TEMPLATE_VALUE_PARAMETERS
> #define BOOST_NO_MEMBER_TEMPLATES
> #define BOOST_NO_MEMBER_TEMPLATE_FRIENDS
> #define BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION
> #endif

Problem is, you've misinterpreted BOOST_NO_USING_TEMPLATE. It doesn't mean
there are no template facilities. It means that using-declarations of
template names don't work.

-Dave