[cxx-conversion] is enable_if ok?

[cxx-conversion] is enable_if ok?

[Pedro Lamarão]

Hello,

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.

--
  P.

Re: [cxx-conversion] is enable_if ok?

[Jonathan Wakely]

On 14 April 2012 20:55, Pedro Lamarão wrote:
> Since enable_if is not part of C++98, it would be added to GCC itself --
> perhaps in namespace gcc.

libstdc++ provides __gnu_cxx::__enable_if in <ext/type_traits.h:>

Re: [cxx-conversion] is enable_if ok?

[Pedro Lamarão]

On 04/14/2012 05:07 PM, Jonathan Wakely wrote:
> On 14 April 2012 20:55, Pedro Lamarão wrote:
>> Since enable_if is not part of C++98, it would be added to GCC itself --
>> perhaps in namespace gcc.
>
> libstdc++ provides __gnu_cxx::__enable_if in<ext/type_traits.h:>
>

When vec.h is compiled in stage1 by the host compiler, can we include 
the file you mention?

Or perhaps the suggestion is to optimize with enable_if only after stage1?

--
  P.

Re: [cxx-conversion] is enable_if ok?

[Jonathan Wakely]

On 14 April 2012 21:14, Pedro Lamarão wrote:
> On 04/14/2012 05:07 PM, Jonathan Wakely wrote:
>>
>> On 14 April 2012 20:55, Pedro Lamarão wrote:
>>>
>>> Since enable_if is not part of C++98, it would be added to GCC itself --
>>> perhaps in namespace gcc.
>>
>>
>> libstdc++ provides __gnu_cxx::__enable_if in<ext/type_traits.h:>
>>
>
> When vec.h is compiled in stage1 by the host compiler, can we include the
> file you mention?

I don't know, my point is just that GCC already contains an enable_if
that works in C++03 mode, in addition to std::enable_if, so reusing it
somehow would make more sense than adding a third implementation.

Re: [cxx-conversion] is enable_if ok?

[Marc Glisse]

On Sat, 14 Apr 2012, Pedro Lamarão wrote:

> Hello,
>
> 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.

Do you seriously expect it to make a difference? Accessors should be 
inlined to the point of making the value/reference thing irrelevant. If 
std::vector suffers a performance penalty because of this, it is a serious 
optimizer deficiency that should be fixed so all C++ users can benefit.

-- 
Marc Glisse

Re: [cxx-conversion] is enable_if ok?

[Gabriel Dos Reis]

On Sat, Apr 14, 2012 at 2:55 PM, Pedro Lamarão <pedro.lamarao@gmail.com> wrote:
> Hello,
>
> 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.

-- Gaby

Re: [cxx-conversion] is enable_if ok?

[Lawrence Crowl]

On 4/14/12, Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:
> On Apr 14, 2012 Pedro Lamarão <pedro.lamarao@gmail.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.

-- 
Lawrence Crowl