stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <se...@roguewave.com>
Subject Re: type_traits progress
Date Tue, 27 May 2008 19:57:46 GMT
Travis Vitek wrote:
>  
> 
[...]
>> Regarding naming:
>>
>>  *  File names should be abbreviated so as not to exceed the 14
>>     character minimum required by POSIX.
> 
> I wasn't aware of a 14 character limit, and I'm guessing that this is to
> do with the length of the header name as we don't limit the length of
> the test names or config test names in any way.

The test names don't matter as much as those of the library headers
because the worst that can happen is with the tests that the they
won't compile. With the library header names being too long, the
library might fail to compile or parts of it might be unusable.

> 
> If this is the case I may opt to merge the headers. i.e. _rw_has.h

I'd get rid of the _rw prefix and abbreviate the names. E.g., use
"ctor" instead of "constructor" etc. In fact, I wouldn't be at all
upset if we abbreviated the names of some the private traits as
well, e.g., truncate __rw_add_lvalue_reference to __rw_add_lval_ref
or something similar). Not just to spare us the typing a few extra
characters but also to reduce the sizes of symbol tables generated
for specializations involving these critters (FYI: this was bad
enough in C++ 98 that the IA64 ABI put in special cases for the
most egregious symbols: std::string and std::wstring).

On a related note, I wonder if it would make sense to consolidate
some of the implementation headers that we don't expect to be useful
in the rest of the library on their own (e.g., all the ctor
headers/traits).

> 
> 
>>  *  Do the trait member (e.g., _C_type, _C_value) need to be
>>     privatized or would it make more sense to use the required names?
> 
> I'm not sure what you're saying here. The types in the public interface
> all have the required names [from the base integral_constant template].
> 
> Everything else is an internal class, and I thought that we always
> needed to use privatized names for internal classes exposed in the
> headers. Using names consistent with those in the public interface
> doesn't buy us anything significant that I can think of, and there is no
> requirement that I know of saying we should.
> 
> Other than avoiding the additional three characters, Is there any
> motivation to switch? The _C_ thing is starting to grow on me.

Heh -- didn't I tell you it would? ;-)

The motivation for privatizing the names of implementation-defined
class members is to avoid clashing with user-defined macro names.
Since the names "type," "value," and "value_type" are used
throughout the library we don't need to privatize them (although
we certainly can for consistency).

One reason why I asked the question was that if we derived the
standard traits from the implementation-defined ones we wouldn't
need to re-declare these members. (I now see that we don't use
derivation).

Another, and probably far more important reason for keeping the
names of the members the same, to make our implementation traits
look and feel like standard traits, i.e., conform to the traits
requirements. Otherwise the rest of our library won't be able
to easily use the private traits.

> 
>> Regarding the supporting infrastructure (config tests and headers):
>>
>>  *  In etc/config/src/RVALUE_REFERENCE.cpp needs, the _TYPENAME
>>     macro isn't defined at this stage. Also, I'm not sure why
>>     the test needs to use templates at all.
> 
> You are right about the typename macro. I was being lazy and just copied
> a snippet of code out of the rvalue-reference proposal.
> 
>>  *  In etc/config/src/VARIADIC_TEMPLATES.cpp, shouldn't struct
>>     pack (the primary template) be defined?
> 
> No. I'm still a little new to this, but what you are calling the primary
> template is just a fwd declaration.
> 
> If you supply one or more template arguments, the first specialization
> will be used, otherwise the empty specialization will be used.
> 
>>     Also, is the empty specialization of pack valid?
> 
> I'm pretty sure it is. 14.3 p4 says
> 
>   When template argument packs or default template-
>   arguments are used, a template argument list can
>   be empty. In that case the empty <> brackets shall
>   still be used as the template argument list.

I see. I told you my C++ was getting rusty! But I'm becoming quite
good at awk! ;-)

> 
> The code is taken from Doug Gregor's Variadic Templates paper
> [http://tinyurl.com/48s8dr]. This paper is referenced from Proposed
> Wording for Variadic Templates [http://tinyurl.com/47n9uf] which appears
> to be the basis for the the wording in the current draft and the gcc-4
> implementation.
> 
> Perhaps I should write a simpler test.
> 
>>     Finally, even though it may
>>     not matter for correctness, the pack specialization should
>>     probably be defined as a struct rather than class.
> 
> Agreed.
> 
>>  *  In include/rw/_config-msvc.h: Would we have a naming conflict
>>     with any of our other macros if we dropped the _TT_ bit from
>>     the type traits macros? (I would prefer to keep the names of
>>     the macros short and as close to the type traits intrinsics
>>     as possible).
> 
> Well, I was supplying macros for the internal type trait names, but they
> don't really do anything other than cut down on the number of characters
> to type. If I eliminated, or renamed those, then I would be able to use
> the more appropriate names.
> 
>>  *  In include/rw/_defs.h, what is __NATIVE_TYPE_TRAITS_SUPPORTED
>>     and where does it come from?
> 
> It is from Howard Hinnant's original draft proposal for compiler support
> for type traits [http://tinyurl.com/3ez8ol]. I recently found James
> Widman's Compiler Support for type_traits proposal
> [http://tinyurl.com/3tyytp] and it removes the requirement for this
> macro.
> 
>>     I'm also concerned that the macro
>>     might be #defined but not all the traits might be supported or
>>     one of them might be spelled differently.
> 
> Yeah, the original proposal said that the macro would be defined if the
> compiler provided 'this interface', so I think it would need to provide
> exactly those names. Since the macro was removed from the current
> document I don't believe that I can rely on it, so I'll be removing the
> block from rw/_defs.h and add platform specific blocks somewhere else
> [probably in the _config-<compiler>.h files for now].
> 
>> I also noticed that some files (e.g., _is_floating_point.h) make
>> use of the _RWSTD_SPECIALIZED_CLASS macro while others assume
>> explicit specialization is supported. I suspect we might as well
>> assume it is and do away with the macro. Ditto for _TYPENAME.
>>
> 
> I tried to use the macros everywhere. Since we haven't finished up the
> discussion about what compiler features we can expect, I figured I had
> better stick with what we're already doing.

That sounds reasonable. We should just remember to do the cleanup
at some point before 4.3 goes out.

> 
>> Martin
>>
> 
> I'll try to post the updated patch this afternoon. That might get pushed
> back to tomorrow if the merge from 4.3 to trunk takes any more than a
> few hours.
> 
> Travis

Sounds good!
Martin

Mime
View raw message