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