Re: [boost] Unused template parameters

From: Daniel Frey (daniel.frey_at_[hidden])
Date: 2003-03-03 05:15:42

Daryle Walker wrote:
> 
> On Thursday, February 13, 2003, at 6:11 AM, Daniel Frey wrote:
> 
> > Markus Schöpflin wrote:
> >>
> >> Daniel Frey wrote:
> >>
> >>> Markus Schöpflin wrote:
> >>
> >>>> This was the original source:
> >>>>
> >>>> template<bool, typename> struct enable_if;
> >>>> -----------------------^
> >>>>
> >>>> Visual Age doesn't like this, it needs a name here.
> >>>
> >>>   ^^^^^^^^^^
> >>>
> >>> Ah, that's the reason. But given my recent discomfort about
> >>> unmaintainable code, look at it again:
> >>>
> >>>   #  if BOOST_WORKAROUND(__HP_aCC, <= 33900)
> >>>       template<bool cond, typename T> struct enable_if;
> >>>   #  else
> >>>       template<bool, typename T> struct enable_if;
> >>>   #  endif
> >>>
> >>> Does this really makes sense? Shouldn't we just keep one version
> >>> with names for template parameters? AFAICS this should work for all
> >>> compilers and it could be a general boost coding guideline to always
> >>> provide names for template parameters. Comments?
> >>
> >> Agreed, if it works for all compilers, let's just keep the version
> >> with the names. (And add a comment that it should stay like it is!)
> >
> > No, don't add a comment. Let's make it a boost coding guideline,
> > otherwise we will clutter the code again with comments instead of
> > workarounds. Remember that this is only one example of a line with
> > template parameters. Would you like to add a comment for every line
> > all over boost?
> 
> Should the template parameter names be something like Unused (if
> there's exactly one) or Unused1, Unused2, etc.?

Technically, this would work, but see below...

> Later, on February 16, 2003, at 9:29 PM, Dave Gomboc wrote:
> 
> >> So you would prefer
> >>
> >> #if BOOST_WORKAROUND(__HP_aCC, <= 33900)
> >>     template<bool cond, typename T> struct enable_if;
> >> #elif BOOST_WORKAROUND(__VisualAge, <= 12345) // Dummy values
> >>     template<bool, typename T> struct enable_if;
> >> #else
> >>     template<bool, typename> struct enable_if;
> >> #endif
> >>
> >> over
> >>
> >> template<bool cond, typename T> struct enable_if;
> >>
> >> If that is the case, then we disagree. Do you have any reason to
> >> prefer the first version?
> >
> > No, I would prefer
> >
> > #if BOOST_WORKAROUND(__HP_aCC, <=33900) ||
> > BOOST_WORKAROUND(__VisualAge,
> > <=12345)
> >     template <bool cond, typename T> struct enable_if;
> > #else
> >     template <bool, typename> struct enable_if;
> > #endif
> >
> > I already explained the reason: C++ compiler vendors use Boost with
> > BOOST_NO_CONFIG for conformance testing.  I'd rather see broken
> > compilers get fixed than developers forever spending time finding
> > workarounds.
> 
> If vendors want to do this check, then they could #define Unused,
> Unused1, Unused2, etc. to be nothing.  (Make sure to check all the
> files to see if my suggestion is the only use of these words.)

There are two problems I see: The name is not unique enough and should
thus be something like BOOST_UNUSED_PARAMETER. It should also be a
MACRO-name (all caps) to indicate that the preprocessor is going to
fiddle with it. If it is not and it would be something like
BoostUnusedParameter, people would IMHO wonder why it's not
boost::UnusedParameter and will forget that they cannot use it for
function parameter names of variables.
The second problem is, that it might be useful for function parameters,
too. This would be a problem if we have a compiler that likes left-out
parameter names for functions but not for templates. You cannot remove
them depending on the context, thus the context needs to be merged into
the name. This leads to BOOST_UNUSED_TEMPLATE_PARAMETER which is much
longer than just Unused.
Now to the numbering of Unused1, Unused2, etc. There are two cases to
think about: More than one unused parameter in one template declaration
and nested templates. Especially for the latter I don't think it's a
good idea to add some kind of counter. "Real" identifiers are much more
maintainable and have the added benefit of telling me something -
Unused42 doesn't (except it's unused of course :).

To sum it up: I think we should stick with Dave G.'s solution - all in
all it is the best alternative when faced with stup^H^H^H^Hbroken
compilers :)

Regards, Daniel

-- 
Daniel Frey
aixigo AG - financial training, research and technology
Schloß-Rahe-Straße 15, 52072 Aachen, Germany
fon: [phone], fax: [phone]
eMail: daniel.frey_at_[hidden], web: http://www.aixigo.de