Re: implementation of Unary Traits
Travis Vitek wrote: [...] If you ask what I prefer, I'm going to tell you I prefer the second option (that is essentially what I wrote originally). But, honestly, for me to care either way, I need to know that there actually a noticeable performance difference between the two techniques. FYI: I used gcc 4.3 and EDG eccp to measure the difference between the compilation times of each of the two approaches (i.e., using specialization vs using remove_cv). In a program involving 10,000 invocations of is_void on distinct types, the specialization approach was 5 and 10 times faster than the one using remove_cv when using gcc and eccp, respectively. In the same program using only 1000 types, the specialization solution compiled 2 and 3 times faster, respectively. With gcc, the compiler also required about half the amount of system memory to compile the specialization-based solution than the other one. (I didn't measure eccp memory usage). This confirms that template metaprogramming is significantly more costly in terms of system resources than alternative approaches, at least in the gcc and eccp implementations. We should re-run the same tests with other compilers to get a complete picture. Martin
RE: C++ 0x testing
Martin Sebor wrote: > >Eric Lemings wrote: >> >> >>Martin Sebor wrote: >>> >>> Unless I'm missing something, C++ 0x testing is currently disabled >>> in nightly builds. I.e., because tests for the newly added C++ 0x >>> features are guarded by the _RWSTD_NO_CXX_0X macro and because >>> _RWSTD_EXT_CXX_0X is not #defined, the tests are compiled into >>> what essentially amounts an empty main(). Yes. >>> With type traits and tuple being nearly done, I think it's time >>> to start exercising these and any other new components in nightly >>> builds. One approach that might be easily implementable at least >>> for gcc is the one suggested in a recent thread: for 4.3.x, add >>> -std=gnu++0x to the set of compiler options for gcc 4.3 and >>> beyond, and make _RWSTD_EXT_CXX_0X synonymous with gcc's >>> __GXX_EXPERIMENTAL_CXX0X__. This should be okay. >>> >>> Is there a better approach? I'd like to get things set up >>> sometime this week. >> >> Rather than hard-code the flags, I suggest a command-line make >> definition; e.g. make _RWSTD_EXT_CXX_0X=1 ... >> >> I thought this is the way it was originally proposed. > >I'm not sure where the _RWSTD_EXT_CXX_0X macro came from or why >C++ 0x is disabled by default even for compilers that it works >with. I remember suggesting _RWSTD_NO_EXT_CXX_0X but not >_RWSTD_EXT_CXX_0X. Of course, it's entirely possible that >I forgot. Travis, what's your insight into this? The discussion that I remember (I should check the archives) we said that we wanted to disable the c++0x extensions by default, but wanted to provide a way to enable them. We had also said that we wanted to enable them by default at some time in the future. This was the primitive method that I came up with to allow for this while still allowing us to do manual builds. I don't rally see a huge advantage to doing it the way I have it now, and I'm completely open to removing the _RWSTD_EXT_CXX_0X macro and using compiler specific macros or even config tests to see if we can safely attempt to use the c++0x extensions. >> Anyways, >> the gcc.config flag appends the appropriate compiler flags and >> defines only if this make variable is defined; e.g. >> >> ifeq ($(_RWSTD_EXT_CXX_0X),1) >> CXXFLAGS += -std=gnu++0x -D_RWSTD_EXT_CXX_0X >> endif > This would work also. This is what I was expecting to have to do until we opted to enable the extensions by default (for 5.0.0). >I'm suggesting we unconditionally enable it on 4.3.x in builds >with gcc 4.3 (and all other compilers where it's intended to >be tested). Just gcc-4.3 and msvc-8.0 right now. I haven't bothered to work with any other platforms because it seems the traits implementation is still in limbo. >IIUC, the approach outlined above won't help us test >the implementation in nightly builds because it'll still leave >C++ 0x disabled unless we also change the buildntest script to >define the make variable the way you show. If we were to take >this approach I don't see the advantage over simply setting >CXXOPTS=-std=gnu++0x instead. It seems to me that most users >are more likely to be familiar and comfortable with using >compiler options than with #defining our config macros. > If we are absolutely confident that we won't introduce any incompatibilities, then I don't see any serious problems with doing this. The only issue I can think of is that the library may configure differently with -std=gnu++0x and the users could want build without it. Doing it this way would make it more difficult to remove the flag. >Martin >
Re: C++ 0x testing
Eric Lemings wrote: -Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor Sent: Monday, June 30, 2008 3:54 PM To: dev@stdcxx.apache.org Subject: C++ 0x testing Unless I'm missing something, C++ 0x testing is currently disabled in nightly builds. I.e., because tests for the newly added C++ 0x features are guarded by the _RWSTD_NO_CXX_0X macro and because _RWSTD_EXT_CXX_0X is not #defined, the tests are compiled into what essentially amounts an empty main(). With type traits and tuple being nearly done, I think it's time to start exercising these and any other new components in nightly builds. One approach that might be easily implementable at least for gcc is the one suggested in a recent thread: for 4.3.x, add -std=gnu++0x to the set of compiler options for gcc 4.3 and beyond, and make _RWSTD_EXT_CXX_0X synonymous with gcc's __GXX_EXPERIMENTAL_CXX0X__. Is there a better approach? I'd like to get things set up sometime this week. Rather than hard-code the flags, I suggest a command-line make definition; e.g. make _RWSTD_EXT_CXX_0X=1 ... I thought this is the way it was originally proposed. I'm not sure where the _RWSTD_EXT_CXX_0X macro came from or why C++ 0x is disabled by default even for compilers that it works with. I remember suggesting _RWSTD_NO_EXT_CXX_0X but not _RWSTD_EXT_CXX_0X. Of course, it's entirely possible that I forgot. Travis, what's your insight into this? Anyways, the gcc.config flag appends the appropriate compiler flags and defines only if this make variable is defined; e.g. ifeq ($(_RWSTD_EXT_CXX_0X),1) CXXFLAGS += -std=gnu++0x -D_RWSTD_EXT_CXX_0X endif I'm suggesting we unconditionally enable it on 4.3.x in builds with gcc 4.3 (and all other compilers where it's intended to be tested). IIUC, the approach outlined above won't help us test the implementation in nightly builds because it'll still leave C++ 0x disabled unless we also change the buildntest script to define the make variable the way you show. If we were to take this approach I don't see the advantage over simply setting CXXOPTS=-std=gnu++0x instead. It seems to me that most users are more likely to be familiar and comfortable with using compiler options than with #defining our config macros. Martin
RE: implementation of Unary Traits
Martin Sebor wrote:
>Travis Vitek wrote:
>>
>>
[...]
>
>I can think of a couple of options that satisfy these. I'm not sure
>how palatable I find them yet, but I might get over their (initial)
>lack of appeal if the payoff is worth it. YMMV.
>
>One is to drop the cv specializations of the __rw_is_xxx traits and
>define the standard traits in terms of both remove_cv and the __rw
>traits, like so:
>
> template
> struct is_void:
> integral_constant _RW::__rw_is_void _RW::__rw_remove_cv<_TypeT>::type>::value>
> { };
>
>or more concisely:
>
> template
> struct is_void:
> integral_constant
> { };
>
>with _RWSTD_IS_VOID() being #defined like so:
>
> #define _RWSTD_IS_VOID(T) \
> _RW::__rw_is_void::type>
>
>All internal code would always need to use _RWSTD_IS_VOID() and
>never _RW::__rw_is_void directly.
>
I think there is a problem with _RWSTD_IS_VOID() being defined like this
because it can't be used outside a template (because of the typename
keyword being used in the macro definition).
$ cat u.cpp && g++ u.cpp
namespace __rw {
template
struct __rw_remove_cv { typedef T type; };
template
struct __rw_is_void { enum { value = 0 }; };
template <>
struct __rw_is_void { enum { value = 1 }; };
}
#define _RW __rw
#define _RWSTD_IS_VOID(T) \
_RW::__rw_is_void::type>
int main ()
{
const bool b = _RWSTD_IS_VOID(void)::value;
return b == 0;
}
u.cpp: In function 'int main()':
u.cpp:23: error: using 'typename' outside of template
Travis
>
RE: Tuple status
Committed. Note, there is still a problem with using reference wrappers with make_tuple() which I'm currently working on but I didn't want to hold up this rather large change any longer. Brad. > -Original Message- > From: Eric Lemings [mailto:[EMAIL PROTECTED] > Sent: Monday, June 30, 2008 10:46 AM > To: dev@stdcxx.apache.org > Subject: Tuple status > > > Just a brief status on tuple progress. > > I got the remaining portions of tuple (except the tie() function) work > late Friday. I did a personal code review over the weekend and am > applying some cleanup and other finishing touches. Should be checking > in a lot of changes later today. So just a heads up. > > Brad. >
RE: C++ 0x testing
> -Original Message- > From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor > Sent: Monday, June 30, 2008 3:54 PM > To: dev@stdcxx.apache.org > Subject: C++ 0x testing > > Unless I'm missing something, C++ 0x testing is currently disabled > in nightly builds. I.e., because tests for the newly added C++ 0x > features are guarded by the _RWSTD_NO_CXX_0X macro and because > _RWSTD_EXT_CXX_0X is not #defined, the tests are compiled into > what essentially amounts an empty main(). > > With type traits and tuple being nearly done, I think it's time > to start exercising these and any other new components in nightly > builds. One approach that might be easily implementable at least > for gcc is the one suggested in a recent thread: for 4.3.x, add > -std=gnu++0x to the set of compiler options for gcc 4.3 and > beyond, and make _RWSTD_EXT_CXX_0X synonymous with gcc's > __GXX_EXPERIMENTAL_CXX0X__. > > Is there a better approach? I'd like to get things set up > sometime this week. Rather than hard-code the flags, I suggest a command-line make definition; e.g. make _RWSTD_EXT_CXX_0X=1 ... I thought this is the way it was originally proposed. Anyways, the gcc.config flag appends the appropriate compiler flags and defines only if this make variable is defined; e.g. ifeq ($(_RWSTD_EXT_CXX_0X),1) CXXFLAGS += -std=gnu++0x -D_RWSTD_EXT_CXX_0X endif Brad.
RE: implementation of Unary Traits
Martin Sebor wrote:
>
>Travis Vitek wrote:
>>
>>
>> Martin Sebor wrote:
>>> The implementation of Unary Traits (e.g., is_void) uses explicit
>>> specialization on all four combinations of cv-qualifiers for each
>>> trait (plain, const, volatile, and const volatile). I'm wondering
>>> if the alternative approach of stripping the qualifiers before
>>> "dispatching" to just one explicit specialization has been
>>> considered.
>>
>> That is what I had originally done.
>
>I forgot about that.
>
>[...]
>>
>> The only issue is that this creates a cyclic dependency
>> between traits
>> defined in and those in .
>
>But only because of the __rw_add_xxx Transformation Traits. Not
>because of the __rw_is_xxx Unary Traits, correct?
Yes.
>IMO, the two
>categories belong in separate headers anyway. Not just logically
>but also (and mainly) because unlike the latter, I don't expect
>us to be needing the former in [many] other areas of the library.
I can accept that.
Originally I wanted separate headers for each trait, but it was
determined that the overhead from including all of these small files
would be to much, so I suggested splitting traits up into groups based
on what they did (, , ...) but that was
vetoed also.
>
>> An easy way to
>> 'fix' this would be to forward declare __rw_remove_cv in
>> and then include at the bottom, but
>> this goes against our conventions. Another option was to put the
>> remove-cv traits into their own header, but this went against your
>> request to organize the traits in files according to some rationale.
>
>My suggested guideline is to group traits according to how likely
>they are to be used in other areas of the library.
It seems that your 'suggested guideline' is in direct conflict with your
'requirement' that the traits be arranged into files according to some
'well defined rationale'. This is the same reasoning you used to reject
my proposal of splitting related traits into separate files.
>From what I gather, you are suggesting that all traits go into
unless they are likely to be used in other areas of the
library. If they are 'likely' to be used in other parts of the library,
then they go into some other header(s), the names of which depend on
some yet to be determined naming scheme. So the 'well defined rationale'
does not seem to be very well defined.
>I expect the
>is_cv-kind of traits to be used pervasively (in containers and
>some algorithms). OTOH, I expect the add_cv ones to be used only
>exceedingly rarely, if ever. Traits that are not used in other
>library headers can be defined directly in or
>grouped in implementation-specific headers according to some
>other sensible criteria.
Okay, I've already taken two shots at this. One that I showed as an
initial implementation for review, and the other which has been
committed to subversion.
>I don't have a strong preference as
>long as they don't get pulled in to translation units
>unnecessarily.
This is in conflict with the feedback you provided on my initial traits
implementation. You didn't like that each trait was in its own header,
yet no trait was unnecessarily pulled in.
>
>>
>>> The potential advantage of this approach is fewer
>>> declarations, smaller translation units, and thus (presumably)
>>> faster compilation.
>>>
>>
>> There has to be a balance somewhere.
>
>Absolutely.
>
>> If all traits are in one file, we
>> have few includes, but lots of unnecessary declarations. If we spread
>> them all out, then we have few unnecessary declarations, but many
>> includes. Both can _potentially_ lead to (ever so slightly) longer
>> compile times in some cases and shorter ones in other cases.
>>
>> I'm definitely open to suggestions and I'm willing to make
>any necessary
>> changes. Unfortunately any suggestion has to take the
>following criteria
>> into consideration...
>>
>> A. the number of trait headers should be kept to a minimum (to keep
>> compile times down)
>> B. there should not be many unnecessary declarations in
>any header (to
>> keep compile times down)
>> C. traits should be put into files according to some well defined
>> rationale (to keep things organized)
>>
>> Unfortunately, I don't really see a clear path to satisfying
>> all of the above requirements.
>
>I can think of a couple of options that satisfy these. I'm not sure
>how palatable I find them yet, but I might get over their (initial)
>lack of appeal if the payoff is worth it. YMMV.
>
>One is to drop the cv specializations of the __rw_is_xxx traits and
>define the standard traits in terms of both remove_cv and the __rw
>traits, like so:
>
> template
> struct is_void:
> integral_constant _RW::__rw_is_void _RW::__rw_remove_cv<_TypeT>::type>::value>
> { };
>
>or more concisely:
>
> template
> struct is_void:
> integral_constant
> { };
>
>with _RWSTD_IS_VOID() being #defined like so:
>
> #define _RWSTD_IS_VOID(T) \
> _RW::__rw_is_void::type>
>
If you do
C++ 0x testing
Unless I'm missing something, C++ 0x testing is currently disabled in nightly builds. I.e., because tests for the newly added C++ 0x features are guarded by the _RWSTD_NO_CXX_0X macro and because _RWSTD_EXT_CXX_0X is not #defined, the tests are compiled into what essentially amounts an empty main(). With type traits and tuple being nearly done, I think it's time to start exercising these and any other new components in nightly builds. One approach that might be easily implementable at least for gcc is the one suggested in a recent thread: for 4.3.x, add -std=gnu++0x to the set of compiler options for gcc 4.3 and beyond, and make _RWSTD_EXT_CXX_0X synonymous with gcc's __GXX_EXPERIMENTAL_CXX0X__. Is there a better approach? I'd like to get things set up sometime this week. Martin
Re: [VOTE] naming convention for variadic template arguments
Eric Lemings wrote: [...] If we are proposing this pattern as a naming convention for variadic template parameters, then I would find that acceptable. As I said in the VOTE post: "...the proposed naming convention to follow unless more specific names are appropriate" When it's known that all the types model the same concept, using the name of the concept instead of the generic TypeT certainly sounds like a good idea. That's also why we have template parameters named InputIter[ator] and similar in the existing code base rather than just TypeT and TypeU everywhere. That said, I hope not to get too distracted by a discussion of hypothetical cases. The point of this vote is to [re]establish consistency in areas where newly added code has started to diverge. If we find in the future that the convention doesn't adequately cover some new cases we can certainly revisit it and tighten things up to address the cases we missed this time. Martin
Re: svn commit: r672048 - /stdcxx/branches/4.3.x/tests/utilities/
Travis Vitek wrote: Martin Sebor wrote: [EMAIL PROTECTED] wrote: Author: vitek Date: Thu Jun 26 15:48:21 2008 New Revision: 672048 URL: http://svn.apache.org/viewvc?rev=672048&view=rev Log: 2008-06-27 Travis Vitek <[EMAIL PROTECTED]> * tests/utilities/20.forward.cpp [_RWSTD_NO_EXT_CXX_0X]: Add guard to get test to compile and run when extension is not explicitly enabled. Include rw/_defs.h explicitly in case rw_driver.h does not. Every stdcxx header should always end up #including so that no code outside the library needs to (as always, there are unavoidable exceptions). includes the header via which in turn should be #included by every test driver header. Yes, I know. Are there any circumstances when this doesn't happen? No. My comment is misleading. I'm simply applying the undocumented style for #include directives in stdcxx [http://tinyurl.com/6abxfz], which is quoted below... This applies to library headers only (modulo exceptions, the rest of the project doesn't #include any private headers as a rule). > >> 2. include directives are in alphabetical order, with >> rw/_defs.h being last (it still ends up getting included >> first, indirectly, by the first header); the exception >> here is when a stdcxx config macro needs to be tested >> before the first #include directive > Martin
RE: svn commit: r672048 - /stdcxx/branches/4.3.x/tests/utilities/
Martin Sebor wrote: > >[EMAIL PROTECTED] wrote: >> Author: vitek >> Date: Thu Jun 26 15:48:21 2008 >> New Revision: 672048 >> >> URL: http://svn.apache.org/viewvc?rev=672048&view=rev >> Log: >> 2008-06-27 Travis Vitek <[EMAIL PROTECTED]> >> >> * tests/utilities/20.forward.cpp [_RWSTD_NO_EXT_CXX_0X]: Add >> guard to get test to compile and run when extension is not >> explicitly enabled. Include rw/_defs.h explicitly in case >> rw_driver.h does not. > >Every stdcxx header should always end up #including >so that no code outside the library needs to (as always, there >are unavoidable exceptions). includes the header >via which in turn should be #included by every >test driver header. Yes, I know. > > Are there any circumstances when this doesn't happen? No. My comment is misleading. I'm simply applying the undocumented style for #include directives in stdcxx [http://tinyurl.com/6abxfz], which is quoted below... > >> 2. include directives are in alphabetical order, with >> rw/_defs.h being last (it still ends up getting included >> first, indirectly, by the first header); the exception >> here is when a stdcxx config macro needs to be tested >> before the first #include directive > >Martin > >
Re: svn commit: r672048 - /stdcxx/branches/4.3.x/tests/utilities/
[EMAIL PROTECTED] wrote: Author: vitek Date: Thu Jun 26 15:48:21 2008 New Revision: 672048 URL: http://svn.apache.org/viewvc?rev=672048&view=rev Log: 2008-06-27 Travis Vitek <[EMAIL PROTECTED]> * tests/utilities/20.forward.cpp [_RWSTD_NO_EXT_CXX_0X]: Add guard to get test to compile and run when extension is not explicitly enabled. Include rw/_defs.h explicitly in case rw_driver.h does not. Every stdcxx header should always end up #including so that no code outside the library needs to (as always, there are unavoidable exceptions). includes the header via which in turn should be #included by every test driver header. Are there any circumstances when this doesn't happen? Martin
Re: svn commit: r672395 - in /stdcxx/branches/4.3.x/include: functional rw/_ref_wrap.h
Eric Lemings wrote:
-Original Message-
From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor
Sent: Saturday, June 28, 2008 2:51 PM
To: dev@stdcxx.apache.org
Subject: Re: svn commit: r672395 - in
/stdcxx/branches/4.3.x/include: functional rw/_ref_wrap.h
...
5. The definitions of even trivial non-empty functions should
never appear on the same line as the function signature. I.e.,
the above should be:
type& get() const {
_RWSTD_ASSERT (0 != _C_ptr);
Should we still use integral constant `0' for null pointers when writing
C++0x code or should we use the new `nullptr' name? Or (more likely),
an internal macro aliasing one or the other; e.g., _RWSTD_NULLPTR?
I don't see the need for nullptr in these checks, on the contrary.
It would make the code considerably more verbose and, IMO, harder
to read.
Martin
Re: svn commit: r669735 - in /stdcxx/branches/4.3.x: include/rw/_meta_other.h include/type_traits tests/utilities/20.meta.trans.other.cpp
Travis Vitek wrote: Martin Sebor wrote: Travis Vitek wrote: Martin Sebor wrote: I searched library headers and sources for how we define unions and with the exception of limits_bits.cpp we always follow this rule. Unless there is a reason not to make this change to aligned_union, I think we should change both limits_bits.cpp and aligned_union to always define the member with the more strict alignment requirement first, just for peace of mind. Is there any reason/advantage to having the char buffer first? If the first member is used to define the alignment, then you have to know (at compile time) which of the union members has the strictest alignment requirement so that it can be put first. Yes. But putting the char buffer first doesn't obviate the need to do this, does it? No, I'm just poking another hole in the policy of always putting the most strictly aligned member first. If I can't reliably determine the most strictly aligned member, it makes it a tad difficult to declare it first. So now the policy becomes 'put the one that you think has the most stringent alignment requirement on platform X'. That's essentially been the guideline in existing code. What do you suggest as an improvement? Martin
Re: svn commit: r672395 - in /stdcxx/branches/4.3.x/include: functional rw/_ref_wrap.h
Eric Lemings wrote:
-Original Message-
From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor
Sent: Saturday, June 28, 2008 2:51 PM
To: dev@stdcxx.apache.org
Subject: Re: svn commit: r672395 - in
/stdcxx/branches/4.3.x/include: functional rw/_ref_wrap.h
...
@@ -45,10 +45,11 @@
#include
+#include
The #include directive should be guarded by #ifndef
_RWSTD_NO_EXT_CXX_0X. That way non-C++ 0x users won't be penalized
by #including the header and we won't have to worry about wrapping
the whole contents of in a pair of these #ifdef/
#endif directives.
I don't have a problem with this really but are you certain this
"penalty" is really worth adding redundant compile guards, considering
that the header already contains guards, albeit within the header? I'm
not sure the perceived penalty is really worth the trouble.
There's no trouble. The _RWSTD_NO_EXT_CXX_0X conditionals
need to be somewhere, and the public header is the logical
place for them (see, for example, ). Otherwise
they would have to be replicated in every C++ 0x
implementation header.
...
template
-class __rw_ref_wrap
+class reference_wrapper
{
+_Type* _C_ptr;
+
+public:
+
+typedef _Type type;
+
+reference_wrapper (_Type& __x)
+: _C_ptr (&__x) { /* empty */ }
+
+reference_wrapper (const reference_wrapper<_Type>& __x)
+: _C_ptr (__x._C_ptr) { /* empty */ }
+
+reference_wrapper& operator= (const
reference_wrapper<_Type>& __x) {
+_C_ptr = __x._C_ptr;
+return *this;
1. We prefer to use the public types in favor of those of template
parameters in definitions of standard templates. This is in
contrast to the spec which prefers the template paramaters for
some unknown reason. Our rationale is that the public names are
more stable and more familiar to users and maintainers alike.
Hmm. I have no problem with that either. I'd like to have a more
convincing
rationale (for either case) though.
I don't have the time to produce an elaborate rationale for
every single one of our established conventions that will
satisfy everyone. Often, no such rationale even exists and
the only reason is historical practice. If you want to do
things differently you're certainly welcome to put forward
a proposal for a change. However, in such cases, it's up
to you to produce a rationale for it that the rest of us
will find convincing.
Does the compiler treat a typedef and a template parameter the same or
are
there actually slight differences?
2. We omit redundant template arguments in the definition of
a template class. The rationale is simplicity.
Thus, the declaration of the assignment operator should look
like so:
reference_wrapper& operator= (const reference_wrapper& __x)
Oh right. I usually do it that way myself. Not sure why I explicitly
named them here.
3. We omit definitions of special member functions (ctors, non
virtual dtors, and assignment operators) that are normally
implicitly generated by the compiler (provided the effects
are right, of course). The rationale is efficiency and
simplicity.
Simplicity, yes. Not sure its any less efficient.
The better efficiency of compiler generated functions
is cited among the motivating reasons for the defaulted
functions enhancement in N2346:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2346.htm
But there should be a comment explicitly stating that the
compiler-generated members are expected/acceptable? If for example
another ctor were added, the comment would remind the developer that the
compiler-generate members are no longer there and must be added.
A comment indicating that a class in intended to be default
or CopyConstructible, or CopyAssignable (or satisfies any
other common constraint) sounds like a fine idea.
Martin
RE: svn commit: r669735 - in /stdcxx/branches/4.3.x: include/rw/_meta_other.h include/type_traits tests/utilities/20.meta.trans.other.cpp
Martin Sebor wrote:
>
>Travis Vitek wrote:
>>
>>
>> Martin Sebor wrote:
>>> I searched library headers and sources for how we define unions and
>>> with the exception of limits_bits.cpp we always follow this rule.
>>> Unless there is a reason not to make this change to aligned_union,
>>> I think we should change both limits_bits.cpp and aligned_union to
>>> always define the member with the more strict alignment requirement
>>> first, just for peace of mind.
>>>
>>> Is there any reason/advantage to having the char buffer first?
>>>
>>
>> If the first member is used to define the alignment, then you have to
>> know (at compile time) which of the union members has the strictest
>> alignment requirement so that it can be put first.
>
>Yes. But putting the char buffer first doesn't obviate the
>need to do this, does it?
No, I'm just poking another hole in the policy of always putting the
most strictly aligned member first. If I can't reliably determine the
most strictly aligned member, it makes it a tad difficult to declare it
first.
So now the policy becomes 'put the one that you think has the most
stringent alignment requirement on platform X'.
>Btw., if you're not subscribed to [EMAIL PROTECTED] yet,
Yes, I am finally subscribed.
>aligned_union was among the alignment features discussed
>last week. An new issue has been filed to remove
>aligned_union because it's superseded by the alignas()
>core language feature:
>http://tinyurl.com/5da3l8
I tinyurl'd this to fit into a 70 character line.
According to the issue, aligned_union<> is supposedly being supersceeded
by 'extended unions', but I understand that some things could be done
with alignas(). If alignas() is supported, then aligned_storage<> can,
for the most part, be implemented trivially, but aligned_union<> still
requires some work.
I realize that this is really not the place to argue against its
removal, but I don't really understand why either should be removed. At
the very least, both of these allow library implementations to support
functionality when the compiler support doesn't exist yet (I can
implement aligned_union<>, but I most definitely cannot implement
alignas()). Not only that, but I honestly find code using the trait much
more readable than using the keyword directly.
>I also plan to submit an issue to remove the other aligned
>traits for the same reason, although the initial feedback
>suggests that this issue might be more controversial than
>the removal of aligned_union.
>
>In any case, it seems likely that the question of which of
>the members of aligned_union comes first may soon be moot
>anyway. That said...
>
>>
>> This problem comes up in the definition of
>__rw_aligned_buffer. On most
>> implementations the members are ordered according to the scheme you
>> mentioned previously, but it is very possible for them to be out of
>> order.
>
>...I'm not sure I see your point WRT __rw_aligned_buffer. In
>the absence of alignas (or some such), how do you suggest we
>prevent this?
I don't. As I mentioned above, I'm poking holes in the policy.
>
>Martin
>
>>
>> union {
>> #ifndef _RWSTD_NO_LONG_DOUBLE
>> long double _C_pad;
>> #else
>> double _C_pad;
>> #endif // _RWSTD_NO_LONG_DOUBLE
>> void *_C_void_pad;
>> void (*_C_pfn_pad)();
>> char_C_data [sizeof (_TypeT)];
>> } _C_buf;
>>
>> Travis
>
>
Re: svn commit: r669735 - in /stdcxx/branches/4.3.x: include/rw/_meta_other.h include/type_traits tests/utilities/20.meta.trans.other.cpp
Travis Vitek wrote:
Martin Sebor wrote:
I searched library headers and sources for how we define unions and
with the exception of limits_bits.cpp we always follow this rule.
Unless there is a reason not to make this change to aligned_union,
I think we should change both limits_bits.cpp and aligned_union to
always define the member with the more strict alignment requirement
first, just for peace of mind.
Is there any reason/advantage to having the char buffer first?
If the first member is used to define the alignment, then you have to
know (at compile time) which of the union members has the strictest
alignment requirement so that it can be put first.
Yes. But putting the char buffer first doesn't obviate the
need to do this, does it?
Btw., if you're not subscribed to [EMAIL PROTECTED] yet,
aligned_union was among the alignment features discussed
last week. An new issue has been filed to remove
aligned_union because it's superseded by the alignas()
core language feature:
http://home.twcny.rr.com/hinnant/cpp_extensions/issues_preview/lwg-active.html#856
I also plan to submit an issue to remove the other aligned
traits for the same reason, although the initial feedback
suggests that this issue might be more controversial than
the removal of aligned_union.
In any case, it seems likely that the question of which of
the members of aligned_union comes first may soon be moot
anyway. That said...
This problem comes up in the definition of __rw_aligned_buffer. On most
implementations the members are ordered according to the scheme you
mentioned previously, but it is very possible for them to be out of
order.
...I'm not sure I see your point WRT __rw_aligned_buffer. In
the absence of alignas (or some such), how do you suggest we
prevent this?
Martin
union {
#ifndef _RWSTD_NO_LONG_DOUBLE
long double _C_pad;
#else
double _C_pad;
#endif // _RWSTD_NO_LONG_DOUBLE
void *_C_void_pad;
void (*_C_pfn_pad)();
char_C_data [sizeof (_TypeT)];
} _C_buf;
Travis
RE: svn commit: r672395 - in /stdcxx/branches/4.3.x/include: functional rw/_ref_wrap.h
> -Original Message-
> From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor
> Sent: Saturday, June 28, 2008 2:51 PM
> To: dev@stdcxx.apache.org
> Subject: Re: svn commit: r672395 - in
> /stdcxx/branches/4.3.x/include: functional rw/_ref_wrap.h
>
...
>5. The definitions of even trivial non-empty functions should
> never appear on the same line as the function signature. I.e.,
> the above should be:
>
> type& get() const {
> _RWSTD_ASSERT (0 != _C_ptr);
Should we still use integral constant `0' for null pointers when writing
C++0x code or should we use the new `nullptr' name? Or (more likely),
an internal macro aliasing one or the other; e.g., _RWSTD_NULLPTR?
Brad.
Tuple status
Just a brief status on tuple progress. I got the remaining portions of tuple (except the tie() function) work late Friday. I did a personal code review over the weekend and am applying some cleanup and other finishing touches. Should be checking in a lot of changes later today. So just a heads up. Brad.
RE: svn commit: r672395 - in /stdcxx/branches/4.3.x/include: functional rw/_ref_wrap.h
> -Original Message-
> From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor
> Sent: Saturday, June 28, 2008 2:51 PM
> To: dev@stdcxx.apache.org
> Subject: Re: svn commit: r672395 - in
> /stdcxx/branches/4.3.x/include: functional rw/_ref_wrap.h
>
...
> > @@ -45,10 +45,11 @@
> >
> >
> > #include
> > +#include
>
> The #include directive should be guarded by #ifndef
> _RWSTD_NO_EXT_CXX_0X. That way non-C++ 0x users won't be penalized
> by #including the header and we won't have to worry about wrapping
> the whole contents of in a pair of these #ifdef/
> #endif directives.
I don't have a problem with this really but are you certain this
"penalty" is really worth adding redundant compile guards, considering
that the header already contains guards, albeit within the header? I'm
not sure the perceived penalty is really worth the trouble.
>
...
> >
> > template
> > -class __rw_ref_wrap
> > +class reference_wrapper
> > {
> > +_Type* _C_ptr;
> > +
> > +public:
> > +
> > +typedef _Type type;
> > +
> > +reference_wrapper (_Type& __x)
> > +: _C_ptr (&__x) { /* empty */ }
> > +
> > +reference_wrapper (const reference_wrapper<_Type>& __x)
> > +: _C_ptr (__x._C_ptr) { /* empty */ }
> > +
> > +reference_wrapper& operator= (const
> reference_wrapper<_Type>& __x) {
> > +_C_ptr = __x._C_ptr;
> > +return *this;
>
>1. We prefer to use the public types in favor of those of template
> parameters in definitions of standard templates. This is in
> contrast to the spec which prefers the template paramaters for
> some unknown reason. Our rationale is that the public names are
> more stable and more familiar to users and maintainers alike.
Hmm. I have no problem with that either. I'd like to have a more
convincing
rationale (for either case) though.
Does the compiler treat a typedef and a template parameter the same or
are
there actually slight differences?
>
>2. We omit redundant template arguments in the definition of
> a template class. The rationale is simplicity.
> Thus, the declaration of the assignment operator should look
> like so:
>
> reference_wrapper& operator= (const reference_wrapper& __x)
Oh right. I usually do it that way myself. Not sure why I explicitly
named them here.
>
>3. We omit definitions of special member functions (ctors, non
> virtual dtors, and assignment operators) that are normally
> implicitly generated by the compiler (provided the effects
> are right, of course). The rationale is efficiency and
> simplicity.
Simplicity, yes. Not sure its any less efficient.
But there should be a comment explicitly stating that the
compiler-generated members are expected/acceptable? If for example
another ctor were added, the comment would remind the developer that the
compiler-generate members are no longer there and must be added.
> In reference_wrapper, we can safely omit the definition of
> not just the dtor but also that of the copy ctor and the
> copy assignment operator.
>
> > +}
> >
> > +operator _Type& () const { return *_C_ptr; }
> > +
> > +_Type& get() const { return *_C_ptr; }
>
>4. Function invariants should be asserted wherever possible.
Yep, good point.
>
>5. The definitions of even trivial non-empty functions should
> never appear on the same line as the function signature. I.e.,
> the above should be:
>
> type& get() const {
> _RWSTD_ASSERT (0 != _C_ptr);
> return *_C_ptr;
> }
No problem.
Good suggestions. :)
Brad.
RE: [VOTE] naming convention for variadic template arguments
> -Original Message-
> From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor
> Sent: Saturday, June 28, 2008 12:17 PM
> To: dev@stdcxx.apache.org
> Subject: Re: [VOTE] naming convention for variadic template arguments
>
> Travis Vitek wrote:
> >
> >
> >> Eric Lemings wrote:
...
> >
> >> In this case, it depends on whether the two parameters are
> actually part
> >> of the same type list. If _TypesT and _Types are actually
> part of the
> >> same type list then they should be named either _TypeT and _TypesT
> >> respectively (or _Type and _Types as shown in #2). If
> they are not part
> >> of the same type list, then they should be named _TypeT and _TypesU
> >> (similar to #4).
>
> This makes sense. The only potential problem is that (I suspect)
> it may not necessarily be known at the point of the declaration
> of every template whether the types are related or not (just like
> an InputIterator in some container member function templates may
> not be an iterator at all but size_type). But that case can be
> handled by simply assuming that the types are related (analogous
> to the InputIterator case).
That's a slightly different case. This parameter, whether it is an
iterator or an offset type, is still separate from the other parameters.
In the variadic template case (e.g. _Head, _Tail...), the parameters
are logically the same template parameter; that is, they are actually
part of the same type list and only named separately to to implement
the variadic template.
>
...
>
> I realize the convention I proposed has at least one other
> shortcoming in that it doesn't scale to member templates:
>
> template
> struct Parent {
> template
> Child {
> template
> Grandchild { };
> };
> };
>
> To account for this, taking into account the existing convention
> (and assuming your _TTypes was really meant to be _TypesT), the
> generic case would look like so:
>
> template
> struct Parent {
> template
> Child {
> template
> Grandchild { };
> };
> };
>
> Applying Brad's proposal (if I understand it correctly) to related
> types, we'd have this:
>
> template
> struct Parent {
> template
> Child {
> template
> Grandchild { };
> };
> };
>
> and for unrelated types this:
>
> template
> struct Parent {
> template
> Child {
> template
> Grandchild { };
> };
> };
>
> Does this look okay to everyone?
Uhm, that depends. :)
Are you proposing that we are limited only to these specific names or to
this naming _pattern_? (I would prefer to specify conventions --
especially new conventions -- as patterns rather than limiting them to
specific rules.)
In other words, I (prefer to) only use the name "Type" (or "TypeT") when
the template parameter can actually be any type: no requirements, no
restrictions. If, for example, the template parameter must be an
integral type, would the following naming conventions for variadic
templates also apply?
For type lists:
template
struct Parent {
template
Child {
template
Grandchild { };
};
};
For types other than type lists:
template
struct Parent {
template
Child {
template
Grandchild { };
};
};
If we are proposing this pattern as a naming convention for variadic
template parameters, then I would find that acceptable.
Brad.
RE: svn commit: r669735 - in /stdcxx/branches/4.3.x: include/rw/_meta_other.h include/type_traits tests/utilities/20.meta.trans.other.cpp
Martin Sebor wrote:
>
>I searched library headers and sources for how we define unions and
>with the exception of limits_bits.cpp we always follow this rule.
>Unless there is a reason not to make this change to aligned_union,
>I think we should change both limits_bits.cpp and aligned_union to
>always define the member with the more strict alignment requirement
>first, just for peace of mind.
>
>Is there any reason/advantage to having the char buffer first?
>
If the first member is used to define the alignment, then you have to
know (at compile time) which of the union members has the strictest
alignment requirement so that it can be put first.
This problem comes up in the definition of __rw_aligned_buffer. On most
implementations the members are ordered according to the scheme you
mentioned previously, but it is very possible for them to be out of
order.
union {
#ifndef _RWSTD_NO_LONG_DOUBLE
long double _C_pad;
#else
double _C_pad;
#endif // _RWSTD_NO_LONG_DOUBLE
void *_C_void_pad;
void (*_C_pfn_pad)();
char_C_data [sizeof (_TypeT)];
} _C_buf;
Travis
