Travis Vitek wrote:
Martin Sebor wrote:
Travis Vitek wrote:
[...]
Right. That could be another wrinkle. Our traits won't
work with generic code that takes integral_constant<T, V>
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?
Derivation from integral_constant?
The original proposal explains the motivation for the base class:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1345.html
There is one potential problem with integral constant members that
should be raised: these require an out of line definition as well
as an inline initialisation (but see issues 48 and 82). One
implementation strategy that avoids the problem of having to provide
lots of definitions for these static members, would be to have the
traits classes inherit from a common base class:
template <bool b> struct boolian_traits {
static const bool value = b;
};
template <bool b> bool boolian_traits<b>::value;
typedef boolian_traits<true> true_type;
typedef boolian_traits<false> false_type;
template <class T> struct is_void : public false_type {};
template <> struct is_void<void> : public true_type {};
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 <class T, T v>
struct __rw_integral_constant
{
static const T value = v;
typedef T value_type;
typedef integral_constant<T,v> 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 don't know about serious but it does probably mean that we will
need to expose integral_constant among our private names and let
it "leak" into the std namespace wherever any of our private type
traits are used. Unless someone can come up with a way to avoid
it we might as well drop __rw_integral_constant and derive all
our private traits directly from integral_constant instead.
};
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<T>
// by applying Transformer<T>, otherwise leaves
// T unchanged:
template <class T,
template <class> Property,
template <class> 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.
That's true for the standard traits, but not for user-defined ones.
Of course, that would only be an issue in the unlikely event that
we decided to expose an interface where users could supply their
own traits. Still, I don't see any benefit in avoiding the standard
names, value and type, in our private traits. We'll just end up with
more of these names in our implementation than there already are.
Martin
