RE: type_traits progress
Martin Sebor wrote:
>Travis Vitek wrote:
>[...]
>>> Right. That could be another wrinkle. Our traits won't
>>> work with generic code that takes integral_constant
>>> by reference.
>>
>> I don't really see the motivation, but it is obvious that
>> the committee thought it was important for the standard
>> traits to do so, so we should probably follow suit in our
>> internal implementation.
Can you think of a reason why this 'feature' would be important?
>>
>> If we did decide to do this then we would probably want our own write
>> __rw_integral_constant and use that internally to avoid namespace
>> pollution? Then I'd assume we'd want something like the following
>> example for is_const...
>
>Yes, I think this is close to what we want. The only thing that bugs
>me about it is...
>
>>
>> template
>> struct __rw_integral_constant
>> {
>> static const T value = v;
>> typedef T value_type;
>> typedef integral_constant type;
>
>...this backward dependency on integral_constant, but I don't see how
>to break it without template typedefs. I don't think there's a compiler
>out there that supports them yet.
Actually, this was originally a typo on my part, but I do see where this
is going. I haven't read about template typedefs, but it seems that
there would be a serious problem caused by the cyclic dependency.
>> };
>>> I hadn't thought too deeply about how the traits could be
>>> used, but I have used traits outside of enable_if. I think
>>> its should be easy to contrive code that wouldn't work with
>>> our approach. Let me try:
>>>
>>> // transforms T if it satisfies Property
>>> // by applying Transformer, otherwise leaves
>>> // T unchanged:
>>>
>>> template >> template Property,
>>> template Transformer>
>>> struct TransformIf;
>>
>> Yes, if we go with the above approach then this problem just
>> disappears for any trait inheriting from __rw_integral_constant.
>> For the other types I can just expose the names that the standard
>> defines.
>>
>> I'm okay with that if you think that the motivation is there.
>
>I'm not sure the contrived example I gave qualifies as a motivating
>use case but it is a use case nonetheless. That said, I don't think
>consistency with other uglified names is a compelling enough reason
>for us to dismiss even this contrived use case.
>
I'm starting to think that the above example is not motivating at all.
There is no reason that any of our library code would ever need to use
the public types because those types are just alternate names for the
internal implmentation types. If we are writing code to be used in other
parts of our implementation, then we would always use the internal _C_
names.
>Martin
>
Re: type_traits progress
Travis Vitek wrote:
[...]
Right. That could be another wrinkle. Our traits won't
work with generic code that takes integral_constant
by reference.
I don't really see the motivation, but it is obvious that the committee
thought it was important for the standard traits to do so, so we should
probably follow suit in our internal implementation.
If we did decide to do this then we would probably want our own write
__rw_integral_constant and use that internally to avoid namespace
pollution? Then I'd assume we'd want something like the following
example for is_const...
Yes, I think this is close to what we want. The only thing that bugs
me about it is...
template
struct __rw_integral_constant
{
static const T value = v;
typedef T value_type;
typedef integral_constant type;
...this backward dependency on integral_constant, but I don't see how
to break it without template typedefs. I don't think there's a compiler
out there that supports them yet.
};
template
struct __rw_is_const_impl
{
enum { _C_value = 0 };
};
template
struct __rw_is_const_impl
{
enum { _C_value = 1 };
};
template
struct __rw_is_const
: __rw_integral_constant::_C_value>
{
};
template
struct integral_constant : __rw_integral_constant
{
};
template
struct is_const : integral_constant::value>
{
};
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.
But this should only be an issue if we are passing around traits as
template parameters, right?
Right.
All of the scenerios I can think of we would be using
__rw_enable_if or
specialization on non-type template parameters. Can you think of any
case where the name of the member would be important?
I searched the latest draft standard to see if traits were
being used anywhere in the spec but didn't get any hits.
I hadn't thought too deeply about how the traits could be
used, but I have used traits outside of enable_if. I think
its should be easy to contrive code that wouldn't work with
our approach. Let me try:
// transforms T if it satisfies Property
// by applying Transformer, otherwise leaves
// T unchanged:
template Property,
template Transformer>
struct TransformIf;
Yes, if we go with the above approach then this problem just disappears
for any trait inheriting from __rw_integral_constant. For the other
types I can just expose the names that the standard defines.
I'm okay with that if you think that the motivation is there.
I'm not sure the contrived example I gave qualifies as a motivating
use case but it is a use case nonetheless. That said, I don't think
consistency with other uglified names is a compelling enough reason
for us to dismiss even this contrived use case.
Martin
Re: [jira] Commented: (STDCXX-810) inconsistent testuite header names
Eric Lemings (JIRA) wrote:
[ https://issues.apache.org/jira/browse/STDCXX-810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12601298#action_12601298 ]
Eric Lemings commented on STDCXX-810:
-
I noticed the prefix {{rwt_}} used in some places. As long as we're renaming
header files, wouldn't this prefix further distinguish RWTest headers from
other headers (e.g. internal library headers)? Or would that be a little too
invasive?
That was the original intent of the prefix, but we somehow managed
to drop the 't' (I don't think it was deliberate). AFAIK, there's
just one file that uses the rwt_ prefix. The rest of the driver
uses rw_, so I'd say changing it would definitely be very invasive.
Martin
inconsistent testuite header names
--
Key: STDCXX-810
URL: https://issues.apache.org/jira/browse/STDCXX-810
Project: C++ Standard Library
Issue Type: Improvement
Components: Test Driver
Affects Versions: 4.1.2, 4.1.3, 4.1.4, 4.2.0
Reporter: Martin Sebor
Assignee: Eric Lemings
Priority: Minor
Fix For: 4.3
Original Estimate: 1h
Remaining Estimate: 1h
The names of some test suite headers start with the {{rw_}} prefix (such as
[rw_alarm.h|http://svn.apache.org/repos/asf/stdcxx/trunk/tests/include/rw_alarm.h])
but others don't follow this convention (e.g.,
[21.strings.h|http://svn.apache.org/repos/asf/stdcxx/trunk/tests/include/21.strings.h]
or
[driver.h|http://svn.apache.org/repos/asf/stdcxx/trunk/tests/include/driver.h]).
For consistency, we should add the {{rw_}} prefix to all test suite headers
that are missing it.
RE: type_traits progress
> -Original Message- > From: Martin Sebor [mailto:[EMAIL PROTECTED] > Sent: Friday, May 30, 2008 3:05 PM > To: dev@stdcxx.apache.org > Subject: Re: type_traits progress > > Travis Vitek wrote: > > > > > > Eric Lemings wrote: > >>> Travis Vitek wrote: > >>> > >> ... > >>> As an example, the array traits above are all closely related > >>> and their > >>> implementations are similar. There are five traits, and > those traits > >>> span three sections of the standard. > >>> > >>> I'm open to doing some type of grouping, we just need to > >>> understand how > >>> we want to group them and then how we want to name the files. > >> The term you're looking for is cohesion. :) I kinda like this > >> organization. Couple things though. > >> > >> Why put __rw_decay, a single helper trait in its own header? > > > > Well decay deals with conversion from array to pointer and > function to > > function pointer conversions. I can't necessarily put it into both > > _meta_array.h and _meta_func.h, so I figured it would be > best to put it > > into a file by itself. > > FWIW, I see no problem with bundling groups of traits together > even if some of them are unlikely to be used in the rest of the > lib, just as long as their implementation isn't too big (i.e., > doesn't bloat translation units and unnecessarily increase > compilation time). Well when it comes to metaprogramming, there's almost always a tradeoff in these two respects. Either the translation unit size increases or compile times increase. But you're right: we should minimize both whenever possible. BTW, which of these two should be the preferred: comile-time computations (metaprogramming) or runtime processing? I would say compile-time even though that will signficantly impact us developers but I think users would prefer this since they do not build nearly as often. Brad.
Re: type_traits progress
Travis Vitek wrote: Eric Lemings wrote: Travis Vitek wrote: ... As an example, the array traits above are all closely related and their implementations are similar. There are five traits, and those traits span three sections of the standard. I'm open to doing some type of grouping, we just need to understand how we want to group them and then how we want to name the files. The term you're looking for is cohesion. :) I kinda like this organization. Couple things though. Why put __rw_decay, a single helper trait in its own header? Well decay deals with conversion from array to pointer and function to function pointer conversions. I can't necessarily put it into both _meta_array.h and _meta_func.h, so I figured it would be best to put it into a file by itself. FWIW, I see no problem with bundling groups of traits together even if some of them are unlikely to be used in the rest of the lib, just as long as their implementation isn't too big (i.e., doesn't bloat translation units and unnecessarily increase compilation time). Martin Also I would use the filename rw/_meta_util.h rather than rw/_meta_other.h but that's just me. :) Yeah, I could do that. Brad.
RE: svn commit: r659253 - in /stdcxx/branches/4.2.x: examples/manual/ src/ tests/algorithms/ tests/containers/ tests/localization/ tests/numerics/ tests/regress/ tests/src/ tests/strings/ util/
> -Original Message- > From: Travis Vitek [mailto:[EMAIL PROTECTED] > Sent: Friday, May 23, 2008 2:24 PM > To: dev@stdcxx.apache.org > Subject: RE: svn commit: r659253 - in /stdcxx/branches/4.2.x: > examples/manual/ src/ tests/algorithms/ tests/containers/ > tests/localization/ tests/numerics/ tests/regress/ tests/src/ > tests/strings/ util/ > > ... > > Looks like there is some duplication of summaries here. Both of these > are about the same changes. The log should probably be modified. > > Also, I noticed that the formatting you're using isn't consistent with > what we normally use for changelog entries. As an example, I see that > you are indenting some lines. In the above snip you've > indented the line > that begins with tests/algorithms/25.generate.cpp in the second block. > There should be an asterisk there. You are doing the same thing with > function names in other places. > > Also, if the description of the resolution is the same as the entry > above, you should probably just write 'Ditto.' and leave it at that. Fixed. See svn propchange: r659253 - svn:log. > > > >Modified: stdcxx/branches/4.2.x/tests/algorithms/25.fill.cpp > >URL: > >http://svn.apache.org/viewvc/stdcxx/branches/4.2.x/tests/algori > >thms/25.fill.cpp?rev=659253&r1=659252&r2=659253&view=diff > >=== > >=== > >--- stdcxx/branches/4.2.x/tests/algorithms/25.fill.cpp (original) > >+++ stdcxx/branches/4.2.x/tests/algorithms/25.fill.cpp Thu May > >22 13:54:39 2008 > >@@ -146,7 +146,7 @@ > > const OutputIterator begin = > > make_iter (buf, buf, buf_end, dummy_iter); > > > >-const Size n (i, 0 /* dummy */); > >+const Size n (int (i), 0 /* dummy */); > > const Tvalue; > > > > // the number of invocations of the assignment operator > > > > Wouldn't the correct way to fix this be to add a member typedef to the > Size class template and then use it? That way the code would > be correct > if Size is actually Size or whatever. _TYPENAME > Size::IntegralType(i) is pretty verbose, but it is correct. That it would. I didn't actually look past the constructor call to the Size class template. Fixing it now. Brad.
RE: type_traits progress
Eric Lemings wrote: > >> Travis Vitek wrote: >> >... >> >> As an example, the array traits above are all closely related >> and their >> implementations are similar. There are five traits, and those traits >> span three sections of the standard. >> >> I'm open to doing some type of grouping, we just need to >> understand how >> we want to group them and then how we want to name the files. > >The term you're looking for is cohesion. :) I kinda like this >organization. Couple things though. > >Why put __rw_decay, a single helper trait in its own header? Well decay deals with conversion from array to pointer and function to function pointer conversions. I can't necessarily put it into both _meta_array.h and _meta_func.h, so I figured it would be best to put it into a file by itself. >Also I would use the filename rw/_meta_util.h rather than >rw/_meta_other.h but that's just me. :) Yeah, I could do that. > >Brad. >
RE: svn commit: r660336 - /stdcxx/branches/4.2.x/tests/localization/22.locale.ctype.widen.cpp
I believe this test was added then subsequently removed. Not sure how it got picked up in your merge. Brad. > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Monday, May 26, 2008 5:22 PM > To: [EMAIL PROTECTED] > Subject: svn commit: r660336 - > /stdcxx/branches/4.2.x/tests/localization/22.locale.ctype.widen.cpp > > Author: sebor > Date: Mon May 26 16:22:23 2008 > New Revision: 660336 > > URL: http://svn.apache.org/viewvc?rev=660336&view=rev > Log: > 2008-05-26 Martin Sebor <[EMAIL PROTECTED]> > > Merged rev 649564 from trunk. > > 2008-04-18 Eric Lemings <[EMAIL PROTECTED]> > > STDCXX-866 > * tests/localization/22.locale.ctype.widen.cpp: Migrated new > test from old Perforce repository. > > Added: > stdcxx/branches/4.2.x/tests/localization/22.locale.ctype.widen.cpp > - copied unchanged from r649564, > stdcxx/trunk/tests/localization/22.locale.ctype.widen.cpp > >
RE: type_traits progress
> -Original Message- > From: Travis Vitek [mailto:[EMAIL PROTECTED] > Sent: Friday, May 30, 2008 12:40 PM > To: dev@stdcxx.apache.org > Subject: RE: type_traits progress > > ... > > As an example, the array traits above are all closely related > and their > implementations are similar. There are five traits, and those traits > span three sections of the standard. > > I'm open to doing some type of grouping, we just need to > understand how > we want to group them and then how we want to name the files. The term you're looking for is cohesion. :) I kinda like this organization. Couple things though. Why put __rw_decay, a single helper trait in its own header? Also I would use the filename rw/_meta_util.h rather than rw/_meta_other.h but that's just me. :) Brad.
RE: type_traits progress
Martin Sebor wrote:
>
>Travis Vitek wrote:
>>
>[...]
>>> 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).
>>
>> I think it would. I'd like to consolidate these a little further. I'd
>> like to either put them in headers by category, something like this
>> [those not mentioned would go into their own header].
>
>My initial thought was to group them based on how they are
>likely to be used in the rest of the library. Another option
>would be to follow the breakdown used by the standard. Your
>organization doesn't seem to fall into either of these two
>categories. What was your rationale for it?
I'm just grouping closely related traits.
>> rw/_meta_arr.h
>> * __rw_rank
>> * __rw_extent
>> * __rw_is_array
>> * __rw_remove_extent
>> * __rw_remove_all_extents
As an example, the array traits above are all closely related and their
implementations are similar. There are five traits, and those traits
span three sections of the standard.
I'm open to doing some type of grouping, we just need to understand how
we want to group them and then how we want to name the files.
>>
> * 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.
>>
>> [snip]
>>
>>> 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).
>>
>> We're not allowed to. In all cases the public type is required to to
>> inherit 'directly or indirectly' from integral_constant.
>
>Right. That could be another wrinkle. Our traits won't
>work with generic code that takes integral_constant
>by reference.
I don't really see the motivation, but it is obvious that the committee
thought it was important for the standard traits to do so, so we should
probably follow suit in our internal implementation.
If we did decide to do this then we would probably want our own write
__rw_integral_constant and use that internally to avoid namespace
pollution? Then I'd assume we'd want something like the following
example for is_const...
template
struct __rw_integral_constant
{
static const T value = v;
typedef T value_type;
typedef integral_constant type;
};
template
struct __rw_is_const_impl
{
enum { _C_value = 0 };
};
template
struct __rw_is_const_impl
{
enum { _C_value = 1 };
};
template
struct __rw_is_const
: __rw_integral_constant::_C_value>
{
};
template
struct integral_constant : __rw_integral_constant
{
};
template
struct is_const : integral_constant::value>
{
};
>>
>>> 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.
>>
>> But this should only be an issue if we are passing around traits as
>> template parameters, right?
>
>Right.
>
>>
>> All of the scenerios I can think of we would be using
>__rw_enable_if or
>> specialization on non-type template parameters. Can you think of any
>> case where the name of the member would be important?
>
>I searched the latest draft standard to see if traits were
>being used anywhere in the spec but didn't get any hits.
>
>I hadn't thought too deeply about how the traits could be
>used, but I have used traits outside of enable_if. I think
>its should be easy to contrive code that wouldn't work with
>our approach. Let me try:
>
> // transforms T if it satisfies Property
> // by applying Transformer, otherwise leaves
> // T unchanged:
>
> templatetemplate Property,
> template Transformer>
> struct TransformIf;
Yes, if we go with the above approach then this problem just disappears
for any trait inheriting from __rw_integral_constant. For the other
types I can just expose the names that the standard defines.
I'm okay with that if you think that the motivation is there.
>
>Martin
>
RE: svn commit: r659253 - in /stdcxx/branches/4.2.x: examples/manual/ src/ tests/algorithms/ tests/containers/ tests/localization/ tests/numerics/ tests/regress/ tests/src/ tests/strings/ util/
> -Original Message- > From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor > Sent: Monday, May 26, 2008 2:31 PM > To: dev@stdcxx.apache.org > Subject: Re: svn commit: r659253 - in /stdcxx/branches/4.2.x: > examples/manual/ src/ tests/algorithms/ tests/containers/ > tests/localization/ tests/numerics/ tests/regress/ tests/src/ > tests/strings/ util/ > ... > > > > (As an aside, I wonder why this is defined here when the only > > place it's used is display.cpp. We should move it there.) > > FYI: this has been done in >http://svn.apache.org/viewvc?rev=660283&view=rev > Noted.
RE: svn commit: r659253 - in /stdcxx/branches/4.2.x: examples/manual/ src/ tests/algorithms/ tests/containers/ tests/localization/ tests/numerics/ tests/regress/ tests/src/ tests/strings/ util/
> -Original Message-
> From: Martin Sebor [mailto:[EMAIL PROTECTED]
> Sent: Friday, May 23, 2008 2:05 PM
> To: dev@stdcxx.apache.org
> Subject: Re: svn commit: r659253 - in /stdcxx/branches/4.2.x:
> examples/manual/ src/ tests/algorithms/ tests/containers/
> tests/localization/ tests/numerics/ tests/regress/ tests/src/
> tests/strings/ util/
>
...
> > #if defined (_SC_CLK_TCK)
> > -const float TICKS_PER_SEC = sysconf (_SC_CLK_TCK);
> > +const float TICKS_PER_SEC = float (sysconf (_SC_CLK_TCK));
>
> (As an aside, I wonder why this is defined here when the only
> place it's used is display.cpp. We should move it there.)
Will do.
>
> > #elif defined (CLK_TCK)
> > const float TICKS_PER_SEC = CLK_TCK;
> > #elif defined (CLOCKS_PER_SEC)
> > @@ -521,7 +521,7 @@
> > bad_value (optname, optarg);
> >
> > errno = 0;
> > -defaults->timeout = strtol (optarg, &end, 10);
> > +defaults->timeout = unsigned (strtol
> (optarg, &end, 10));
>
> I suggest using strtoul() here instead.
strtoul() would still cause a conversion warning, wouldn't it?
>
> > if (*end || errno)
> > bad_value (optname, optarg);
> > }
> > @@ -573,7 +573,7 @@
> > && !memcmp (opt_exit, argv [i],
> sizeof opt_exit - 1)) {
> > /* exit immediately with the specified status */
> > optname = opt_exit;
> > -optarg = get_long_val (argv, &i, sizeof
> opt_exit - 1);
> > +optarg = get_long_val (argv, &i, unsigned
> (sizeof opt_exit - 1));
>
> I suggest changing the get_long_val() signature to take size_t
> as the last argument (it will also help reduce the line length
> under 80 characters ;-)
Depends on how the parameter is used within get_long_val(). If its
converted again, that'll just move conversion warnings from one
place to another. I'll have to check it out.
>
> > if (optarg && *optarg) {
> > if (!isdigit (*optarg))
> > bad_value (optname, optarg);
> > @@ -581,7 +581,7 @@
> > errno = 0;
> > const long code = strtol (optarg, &end, 10);
> > if ('\0' == *end && !errno)
> > -exit (code);
> > +exit (int (code));
>
> Seems this code (not necessarily the change) could do with some
> error checking and reporting...
I noticed the same and not only here but I limited my changes only
to what the issue calls for.
>
> > }
> > }
> > else if ( sizeof opt_help - 1 == arglen
> > @@ -595,7 +595,7 @@
> > && !memcmp (opt_sleep, argv [i],
> sizeof opt_sleep - 1)) {
> > /* sleep for the specified number of seconds */
> > optname = opt_sleep;
> > -optarg = get_long_val (argv, &i, sizeof
> opt_sleep - 1);
> > +optarg = get_long_val (argv, &i, unsigned
> (sizeof opt_sleep - 1));
> > if (optarg && *optarg) {
> > if (!isdigit (*optarg))
> > bad_value (optname, optarg);
> > @@ -603,7 +603,7 @@
> > errno = 0;
> > const long nsec = strtol (optarg, &end, 10);
> > if ('\0' == *end && 0 <= nsec && !errno) {
> > -rw_sleep (nsec);
> > +rw_sleep (int (nsec));
>
> Same here (e.g., passing in a very large number on the command
> line as a result of a scripting error).
I can start filing minor issues for mo' betta range checking
on program options when I find such lax usage in the future.
Brad.
RE: svn commit: r659253 - in /stdcxx/branches/4.2.x: examples/manual/ src/ tests/algorithms/ tests/containers/ tests/localization/ tests/numerics/ tests/regress/ tests/src/ tests/strings/ util/
> -Original Message- > From: Martin Sebor [mailto:[EMAIL PROTECTED] > Sent: Friday, May 23, 2008 11:37 AM > To: dev@stdcxx.apache.org > Subject: Re: svn commit: r659253 - in /stdcxx/branches/4.2.x: > examples/manual/ src/ tests/algorithms/ tests/containers/ > tests/localization/ tests/numerics/ tests/regress/ tests/src/ > tests/strings/ util/ > ... > > FYI: The cast above changes the semantics of the expression > by slicing the high 32-bits of which (when it's 64 bits wide) > before shifting the result right, potentially causing it to > lose its high order bits. I don't think the code is really > unsafe since which is 32 bits wide in ILP32 but a more robust > fix (should the type of which change to 64 bits in the future) > would be to cast the result of the shift expression. Oh so instead of casting just which, cast the result of the whole expression? I'll add that to my TODO list. Brad.
RE: svn commit: r659253 - in /stdcxx/branches/4.2.x: examples/manual/ src/ tests/algorithms/ tests/containers/ tests/localization/ tests/numerics/ tests/regress/ tests/src/ tests/strings/ util/
> -Original Message- > From: Martin Sebor [mailto:[EMAIL PROTECTED] > Sent: Friday, May 23, 2008 10:54 AM > To: dev@stdcxx.apache.org > Subject: Re: svn commit: r659253 - in /stdcxx/branches/4.2.x: > examples/manual/ src/ tests/algorithms/ tests/containers/ > tests/localization/ tests/numerics/ tests/regress/ tests/src/ > tests/strings/ util/ > ... > > > > -*n_copy = UserClass::n_total_copy_ctor_; > > -*n_asgn = UserClass::n_total_op_assign_; > > +*n_copy = int (UserClass::n_total_copy_ctor_); > > +*n_asgn = int (UserClass::n_total_op_assign_); > > Would changing the type of n_copy and n_asgn to match the type > of the UserClass data members throughout the test be a cleaner > solution? Possibly. I'll check it out. Brad.
RE: Jira work log comments?
Very nice. It's nice to use something for the first time that's been staring you in the face all along. :P Brad. > -Original Message- > From: Travis Vitek [mailto:[EMAIL PROTECTED] > Sent: Thursday, May 22, 2008 4:35 PM > To: dev@stdcxx.apache.org > Subject: RE: Jira work log comments? > > > > Eric Lemings wrote: > > > >Where do they go? > > They appear on the Work Log panel in the Jira issue. You can > see them if > you scroll down to just below the description and click 'All' or 'Work > Log'. > > > > >Brad. > > > > >
Re: type_traits progress
Travis Vitek wrote: [...] 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). I think it would. I'd like to consolidate these a little further. I'd like to either put them in headers by category, something like this [those not mentioned would go into their own header]. My initial thought was to group them based on how they are likely to be used in the rest of the library. Another option would be to follow the breakdown used by the standard. Your organization doesn't seem to fall into either of these two categories. What was your rationale for it? rw/_meta_cv.h * __rw_add_const * __rw_add_volatile * __rw_add_cv * __rw_is_const * __rw_is_volatile * __rw_remove_const * __rw_remove_volatile * __rw_remove_cv rw/_meta_trivial.h * __rw_is_trivial * __rw_has_trivial_ctor * __rw_has_trivial_copy * __rw_has_trivial_assign * __rw_has_trivial_dtor rw/_meta_nothrow.h * __rw_has_nothrow_ctor * __rw_has_nothrow_copy * __rw_has_nothrow_assign * __rw_has_nothrow_dtor rw/_meta_sign.h * __rw_is_signed * __rw_is_unsigned * __rw_make_signed * __rw_make_unsigned rw/_meta_arr.h * __rw_rank * __rw_extent * __rw_is_array * __rw_remove_extent * __rw_remove_all_extents rw/_meta_ptr.h * __rw_add_pointer * __rw_remove_pointer * __rw_is_pointer rw/_meta_ref.h * __rw_is_lval_ref * __rw_is_rval_ref * __rw_is_ref * __rw_add_lval_ref * __rw_add_rval_ref rw/_meta_member.h * __rw_is_mem_ptr * __rw_is_mem_obj_ptr * __rw_is_mem_fun_ptr rw/_meta_align.h * __rw_aligned_storage * __rw_aligned_union rw/_meta_decay.h * __rw_decay rw/_meta_other.h * __rw_enable_if * __rw_conditional What do you think of this? * 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. [snip] 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). We're not allowed to. In all cases the public type is required to to inherit 'directly or indirectly' from integral_constant. Right. That could be another wrinkle. Our traits won't work with generic code that takes integral_constant by reference. 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. But this should only be an issue if we are passing around traits as template parameters, right? Right. All of the scenerios I can think of we would be using __rw_enable_if or specialization on non-type template parameters. Can you think of any case where the name of the member would be important? I searched the latest draft standard to see if traits were being used anywhere in the spec but didn't get any hits. I hadn't thought too deeply about how the traits could be used, but I have used traits outside of enable_if. I think its should be easy to contrive code that wouldn't work with our approach. Let me try: // transforms T if it satisfies Property // by applying Transformer, otherwise leaves // T unchanged: template Property, template Transformer> struct TransformIf; Martin
