C++0x: alignof vs. alignment_of
Scott Meyers
defines
the result of alignment_of<T> to be the same as the result of
alignof(T), but
the wording of the preconditions for the two are not identical, so it's
possible
that one covers more cases than the other. Is there intentionally a
semantic
difference between the two? If not, is there a reason not to omit
alignment_of?
(It'd still be in TR1.)
Thanks,
Scott
--
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std...@netlab.cs.rpi.edu]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
daniel....@googlemail.com
> Is there any semantic difference between these two features?
I don't think so.
> Table 34 defines the result of alignment_of<T> to be the same
> as the result of alignof(T), but the wording of the preconditions
> for the two are not identical, so it's possible that one covers
> more cases than the other. Is there intentionally a semantic
> difference between the two? If not, is there a reason not to omit
> alignment_of? (It'd still be in TR1.)
I belief the fact that alignment_of was already part of TR1 (which
was published in 2005) is the reason for it's remaining existence.
The advanced alignment support (introducing the new keyword
alignof and more including some further library facilities) was
voted into the working paper in 2007 - I think it was introduced with
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2369.pdf
Greetings from Bremen,
Daniel
Scott Meyers
> I belief the fact that alignment_of was already part of TR1 (which
> was published in 2005) is the reason for it's remaining existence.
If it truly adds no capabilities not already provided by alignof and if
it's not
too late to remove it from the standard, I think it would be nice to get
rid of
it. It just makes the standard bigger and more confusing.
Scott
Thomas J. Gritzan
> daniel....@googlemail.com wrote:
>> I belief the fact that alignment_of was already part of TR1 (which
>> was published in 2005) is the reason for it's remaining existence.
>
> If it truly adds no capabilities not already provided by alignof and if
> it's not
> too late to remove it from the standard, I think it would be nice to get
> rid of
> it. It just makes the standard bigger and more confusing.
Aren't there many similar templates in TR1 that will be replaced by
concepts (is_pod & friends)?
They could be removed for the same reason; or they could remain in
std::tr1::* for compatibility.
--
Thomas
Scott Meyers
> Scott Meyers schrieb:
>> daniel....@googlemail.com wrote:
>>> I belief the fact that alignment_of was already part of TR1 (which
>>> was published in 2005) is the reason for it's remaining existence.
>> If it truly adds no capabilities not already provided by alignof and if
>> it's not
>> too late to remove it from the standard, I think it would be nice to get
>> rid of
>> it. It just makes the standard bigger and more confusing.
>
> Aren't there many similar templates in TR1 that will be replaced by
> concepts (is_pod & friends)?
> They could be removed for the same reason; or they could remain in
> std::tr1::* for compatibility.
TR1 is not a standard, so if there is useful functionality in TR1 that
we'd like
in C++0x, it needs to be in the C++0x standard. My concern is a few
cases where
it appears that TR1 functionality is available in C++0x through a different
mechanism, thus obviating the need to migrate the TR1 feature to C++0x.
Alignment support is one such area. From what I can tell, TR1's
alignment_of
functionality is fully subsumed by C++0x's alignof operator, so, from
what I can
tell, there is no reason to bring alignment_of into C++0x.
Scott
--
Thomas J. Gritzan
> Thomas J. Gritzan wrote:
>> Scott Meyers schrieb:
>>> daniel....@googlemail.com wrote:
>>>> I belief the fact that alignment_of was already part of TR1 (which
>>>> was published in 2005) is the reason for it's remaining existence.
>>> If it truly adds no capabilities not already provided by alignof and if
>>> it's not
>>> too late to remove it from the standard, I think it would be nice to get
>>> rid of
>>> it. It just makes the standard bigger and more confusing.
>>
>> Aren't there many similar templates in TR1 that will be replaced by
>> concepts (is_pod & friends)?
>> They could be removed for the same reason; or they could remain in
>> std::tr1::* for compatibility.
>
> TR1 is not a standard, so if there is useful functionality in TR1 that
> we'd like
> in C++0x, it needs to be in the C++0x standard.
That's true. But the TR1 library implementations won't go away. If you
need it, you can use TR1. If you have a C++0x compiler, you can use the
replacement techniques.
> My concern is a few cases where
> it appears that TR1 functionality is available in C++0x through a different
> mechanism, thus obviating the need to migrate the TR1 feature to C++0x.
Your point is that there are type_traits, where we have keywords in
C++0x that do the same.
My point is that there are type_traits, which we can use concepts for,
instead.
-- For example:
LvalueReference - is_lvalue_reference
PolymorphicClass - is_polymorphic
EnumerationType - is_enum
FloatingPointType - is_floating_point
SameType - is_same
DerivedFrom - is_base_of
Using the True concept, we can use type_traits in places where concepts
are needed, but I don't know how to get a value similar to is_same<X,
Y>::value out of the concept SameType<X, Y>, without defining a template
for each such case.
If they could be used interchangeably, there were no reason to have both.
There are also type_traits, where I couldn't find a concept for:
is_pointer and is_array, for example.
> Alignment support is one such area.
> From what I can tell, TR1's alignment_of
> functionality is fully subsumed by C++0x's alignof operator
Yes. Since alignment_of<T> is specified in terms of alignof(T), the
futher can't be used in more cases than the latter. So alignment_of
could safely be removed.
--
Thomas
SG
> -- For example:
> LvalueReference - is_lvalue_reference
> PolymorphicClass - is_polymorphic
> EnumerationType - is_enum
> FloatingPointType - is_floating_point
> SameType - is_same
> DerivedFrom - is_base_of
>
> Using the True concept, we can use type_traits in places where concepts
> are needed,
This is not going to work because you create a restricted template
without adding the required constraints. But the compiler needs those
constraints to assemble arche types and perform proper checking of the
restricted template:
template<typename T>
// the following requirement doesn't say anything
// about the type T as far as the compiler is concerned
requires True<is_default_constructible<T>::value>
void foo() {
T t; // won't compile, due to a restricted context
// and a missing constructor requirement
}
> but I don't know how to get a value similar to is_same<X,
> Y>::value out of the concept SameType<X, Y>, without defining a template
> for each such case.
You mean for each concept? Yes. It also bugs me a little that you have
to write an is_xyz<> template for each Xyz concept. It would be nice
to have a constexpr bool directly accessible a la
typedef long t1;
typedef char t2;
constexpr bool foo = SameType<t1,t2>; // returns false
Cheers!
SG
--
Thomas J. Gritzan
> On 24 Mai, 23:13, "Thomas J. Gritzan" <phygon_antis...@gmx.de> wrote:
>> -- For example:
>> LvalueReference - is_lvalue_reference
>> PolymorphicClass - is_polymorphic
>> EnumerationType - is_enum
>> FloatingPointType - is_floating_point
>> SameType - is_same
>> DerivedFrom - is_base_of
>>
>> Using the True concept, we can use type_traits in places where concepts
>> are needed,
>
> This is not going to work because you create a restricted template
> without adding the required constraints. But the compiler needs those
> constraints to assemble arche types and perform proper checking of the
> restricted template:
>
> template<typename T>
> // the following requirement doesn't say anything
> // about the type T as far as the compiler is concerned
> requires True<is_default_constructible<T>::value>
> void foo() {
> T t; // won't compile, due to a restricted context
> // and a missing constructor requirement
> }
Then it must be late_check'ed.
>> but I don't know how to get a value similar to is_same<X,
>> Y>::value out of the concept SameType<X, Y>, without defining a template
>> for each such case.
>
> You mean for each concept? Yes. It also bugs me a little that you have
> to write an is_xyz<> template for each Xyz concept. It would be nice
> to have a constexpr bool directly accessible a la
>
> typedef long t1;
> typedef char t2;
> constexpr bool foo = SameType<t1,t2>; // returns false
No implicit conversion, please.
constexpr bool foo = has_concept_map(SameType<t1,t2>);
Hm. Don't know. Do we really need this?
The type traits in TR1 will mostly be used for SFINAE anyway, won't
they? That can be replaced by concepts completely.
However, it would be nice for debugging output.
--
Thomas
Niels Dekker - no reply address
Scott's issue regarding alignment_of is now at Howard Hinnant's preview
page of LWG issues: #1131, "C++0x does not need alignment_of"
http://home.roadrunner.com/~hinnant/issue_review/lwg-active.html#1131
Kind regards, Niels
--
Niels Dekker
http://www.xs4all.nl/~nd/dekkerware
Scientific programmer at LKEB, Leiden University Medical Center
--