|  | Duplication between type_traits and concepts | | |
| | | Scott McMurray |  |
|  Posted: Mon Sep 01, 2008 7:12 am Post subject: Duplication between type_traits and concepts |  |
| |  | |
Looking at concepts papers (n2737 in this case), I see things like
TriviallyCopyConstructible. Of course, the draft (n2723) has
has_trivial_copy_constructor in <type_traits>.
Why are there 2 names for exactly the same thing?
Certainly it seems to me that defining the latter in terms of the
former is obvious:
template <typename T>
struct has_trivial_copy_constructor : false_type {};
template <TriviallyCopyConstructible T>
struct has_trivial_copy_constructor : true_type {};
but why should it be necessary to define the type_trait for it at all?
It feels like there must be a way to get rid of it, and use the traits
naming for the concepts.
(Possibly naïve musings follow:)
The hackiest way I can think would be to make a matches_concept
keyword, so instead of using
type_traits::has_trivial_copy_constructor<T>::value, you'd use
matches_concept(has_trivial_copy_constructor<T>). Obviously keyword
additions are the least favourite way of doing things, though.
It would be much nicer to pass concepts as template arguments, and
allow all the predicates to be replaced with a single
matches_concept<concept C> meta-function. It would be interesting to
know if there would be any other possible uses for passing concepts.
A variation on the last idea: Let concepts be used themselves as
types, with implicit ::type and ::value members. The ::type would be
true_type (and the ::value true) if the concept matched, and all the
members of the concept would also be there; if the concept did not
match, then only the false_type ::type would be there (with
the ::value false).
Or hopefully there's a better idea out there that someone closer to
the problem can come up with.
Thanks,
~ Scott
--
[ See LINK for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
| |
| | | restor | |
| | Posted: Mon Sep 01, 2008 10:03 pm Post subject: Re: Duplication between type_traits and concepts | |
| | | |
Hi,
| Quote: | The hackiest way I can think would be to make a matches_concept
keyword, so instead of using
type_traits::has_trivial_copy_constructor<T>::value, you'd use
matches_concept(has_trivial_copy_constructor<T>).
|
In addition to your question, I would like to ask this: If the
concepts get into the standard is there any good reason for having
"predicate" type traits (is_poiter, has_trivial_copy) at all? The main
usage of predicate traits that I can think of is to selectively
disable template instatiations:
template< typename T >
typename add_lvalue_reference< //
typename remove_pointer<T>::type // return type
| Quote: | ::type //
dereference( typename enable_if< is_pointer<T> >::type ptr ) |
{
return *ptr;
}
With concepts one could do this this way:
template< IsPointer Ptr >
Ptr::pointee_type
dereference( Ptr p )
{
return *p;
}
(Yes, I know that the easiest way to do it is to write
template< typename T >
T dereference( T* ptr ) { return *ptr; }
but just for the sake of the example...)
In fact for transforming type traits one could also find a concept
replacement, as in above example, which is somewhat simpler, as the
keyword 'typename' can be omitted.
Is there any other usage of type traits that concepts cannot improve?
Regards,
&rzej
--
[ See LINK for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
| |
| | | Alberto Ganesh Barbati | |
| | Posted: Tue Sep 02, 2008 1:35 am Post subject: Re: Duplication between type_traits and concepts | |
| | | |
Scott McMurray ha scritto:
| Quote: | Looking at concepts papers (n2737 in this case), I see things like
TriviallyCopyConstructible. Of course, the draft (n2723) has
has_trivial_copy_constructor in <type_traits>.
Why are there 2 names for exactly the same thing?
|
Mainly because concepts are still work-in-progress. Before the last
meeting in Sophia it was not granted that concepts would have been in
the language, so it was premature to consider removing traits.
| Quote: | Certainly it seems to me that defining the latter in terms of the
former is obvious:
template <typename T
struct has_trivial_copy_constructor : false_type {};
template <TriviallyCopyConstructible T
struct has_trivial_copy_constructor : true_type {};
|
Yup!
| Quote: | but why should it be necessary to define the type_trait for it at all?
|
That is a good question, indeed. A question which I frankly can't
answer. However, I feel uncomfortable with the duplication and given
that concepts are so much more powerful, I'd be very happy with removing
as much type traits as we can.
| Quote: | It feels like there must be a way to get rid of it, and use the traits
naming for the concepts.
|
The proposed concepts have very carefully chosen names, which usually
resemble the names of corresponding type traits, with a few notable
exceptions (for example is_base_of becomes DerivesFrom). I don't think
there's a real need to be strict and keep the trait name in all cases as
long as the difference is motivated.
Ganesh
--
[ See LINK for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
| |
| | | Scott McMurray | |
| | Posted: Tue Sep 02, 2008 1:36 am Post subject: Re: Duplication between type_traits and concepts | |
| | | |
On Sep 1, 6:03 pm, restor <akrze...@interia.pl> wrote:
| Quote: |
In fact for transforming type traits one could also find a concept
replacement, as in above example, which is somewhat simpler, as the
keyword 'typename' can be omitted.
Is there any other usage of type traits that concepts cannot improve?
|
Excellent points! I had only been thinking about the predicates,
having forgotten about HasDereference::result_type and friends. n2737
even has a subsection titled Type transformations (20.1.2,
[concept.transform]).
Taking a quick look at boost.type_traits, almost everything is
immediately doable with concepts. There are a few that aren't, but
they're easy to solve. add_reference isn't really needed, since IIRC
using T & works properly now anyways, but it's logical to add a
reference_type to the ReferentType concept and similar, so that
PointeeType<HasDereference<T>::result_type>::pointer_type would be the
same as T.
(Hmm, I can't see an IsReference concept -- is it missing or am I just
missing it?)
Similarly, ObjectType could get types that cover the add_const,
add_cv, and add_volatile traits. Adding HasConstQualifier,
HasVolatileQualifier, and HasCVQualifier seem reasonable, and would
cover the remove_const, remove_cv, and remove_volatile traits.
So as you say, what's left?
I suppose the only thing I can think of is meta-programming, where I
might want to filter a list of types based on some predicate, since
the type_traits match the Boost.MPL MetaFunction concept. But is that
an important enough case to justify specifying ALL the type_traits?
It seems like it might be reasonable to just have people define more
precise metafunctions when they need them, since the concepts will
make it easy and (presumably) MPL usually would use domain-specific
predicates built out of others, rather than directly using the
fundamental ones.
On a similar note, is there a rationale given for naming concepts as
they are? Keeping to the has_something and is_something naming seems
logical to me.
Also, I personally find HasConstructor and Constructible being
different to be exceedingly confusing.
~ Scott
--
[ See LINK for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
| |
| | | restor | |
| | Posted: Tue Sep 02, 2008 7:45 pm Post subject: Re: Duplication between type_traits and concepts | |
| | | |
| Quote: | On a similar note, is there a rationale given for naming concepts as
they are? Keeping to the has_something and is_something naming seems
logical to me.
|
The newest revision of foundational concepts (n2737) provides the
rationale for naming convention. Basically, it says that HasXXX only
requires a function to be availible, and XXXable sort of requires that
it does what the name suggests; e.g.:
class String{...};
bool operator< ( String const& str1, String const& str2 )
{
gFile = fopen( str1, str2 );
return gFile != NULL;
}
class String matches the concept HasLess because it has operator<
but it doesn't match concept LessThanComparable as it doesn't satisfy
the semantic requirements (axioms) like Transitivity.
| Quote: | Also, I personally find HasConstructor and Constructible being
different to be exceedingly confusing.
|
But the rationale above suggests the algorithm to differentiate
between them.
1. If starts with Has, you have only syntax availible
2. if ends with -able, you also get some meaningful semantics
3. If you have the -able one, you get Has- automatically.
Regards,
&rzej
--
[ See LINK for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
| |
| | | David Abrahams | |
| | Posted: Tue Sep 09, 2008 10:05 pm Post subject: Re: Duplication between type_traits and concepts | |
on Tue Sep 02 2008, Alberto Ganesh Barbati <AlbertoBarbati-AT-libero.it> wrote:
| Quote: | If I read the concepts proposal correctly, static_assert-declarations
are not allowed in concept bodies nor in concept maps. They are allowed
inside associated functions, but I don't think they are very useful
there. A predicate can be used more effectively in a requirement clause
as an argument to True<>.
|
One of the problems with predicates in requirement clauses, especially
when there are several overloaded functions available, is that error
messages tend to be less helpful than they might otherwise be. "No
function matches the arguments ..." is not typically as useful a message
as the one you could generate with static_assert, having already
captured the arguments.
--
Dave Abrahams
BoostPro Computing
LINK
[ See LINK for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
| |
| | | restor | |
| | Posted: Sat Sep 13, 2008 8:28 pm Post subject: Re: Duplication between type_traits and concepts | |
| Quote: | Except for iterator traits that are present in C++03, type traits are
mentioned only in TR1 and in the *draft* of the next C++ standard.
Neither of those two papers is an ISO standard. This doesn't mean that
they can be easily removed from the draft, but for sure it's not as
"nearly impossible" as it would be if were speaking of a standard.
|
There are also char traits that could be successfully replaced (or
duplicated) with something like Character concept. Also, it seems that
some parts of numeric limits fit better into ArithmeticLike and
FloatingPointLike foundational concepts.
Regards,
&rzej
--
[ See LINK for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
| |
|
|
