This is the mail archive of the
mailing list for the GCC project.
Re: [cxx-conversion] is enable_if ok?
On 4/14/12, Gabriel Dos Reis <firstname.lastname@example.org> wrote:
> On Apr 14, 2012 Pedro Lamarão <email@example.com> wrote:
> > currently proposed C++ Coding Conventions imply a very strict
> > weird-is-forbidden style, which I like.
> > But if defining new templates should in general be avoided,
> > I'm unsure what is the best path in converting VEC.
> > VEC interface optimizes element acessors to copy primitive
> > types and point-to object types.
> > If VEC is to be a template class, default accessors in C++ would
> > naturally return a (const-)reference-to anything. It would be
> > possible to optimize accessors to return a copy instead of a
> > const-reference-to with enable_if. All this would allow VEC to
> > be mostly just one thing, with small variations in corresponding
> > to VEC_last and VEC_index.
> > Since enable_if is not part of C++98, it would be added to GCC
> > itself -- perhaps in namespace gcc.
> > This decision will not block work in the branch, of course --
> > VEC can be converted first unoptimized and then reoptimized
> > with whatever tricks are allowed.
> One of the requirements is that the code should bootstrap with
> any C++03 compiler. Another requirement is to keep template
> usage simple. Those two requirements to me mean avoid enable_if.
> Of course, maintainers will exercise judgment on specific cases,
> but as a general guideline, I would suggest to forget them.
Implicit, I think, in Gabriel's statement is that if you really need
enable_if, and make a convincing case, you can get an exception to
the general rule.
To my mind, one of the advantages of enable_if is that customers do
not need to know about it. It is an internal implementation issue,
and presumably authors using enable_if are comfortable with it.