Re: traits and policies
On Aug 2, 1:28 am, Mathias Gaunard <loufo...@gmail.com> wrote:
On Aug 1, 3:21 pm, Abhishek Padmanabh <abhishek.padman...@gmail.com>
wrote:
5. std::numeric_limits - that can be said to be a traits (or a
collection of traits). They tell about what max() for a type is, what
epsilon() for a type is. They are not policies. They don't achieve
some behaviour but they may represent how types should/may behave or
properties they have.
max() etc. shouldn't be functions but rather static const ints. (Note
that it doesn't work with floats, which can be considered a language
deficiency)
The next standard prefers to introduce constexpr functions to fix that
issue rather than making them static const literals.
Yeah, making them functions induces the function call overhead that
can be overcome by having exposed public constants. Although, inlining
them can be easy and then they would be equivalent. I wonder why they
were made functions initially? Could you point me to what constexpr
functions are and the proposal that intends to introduce them? And why
these would be better than just exposing constants? What about the
backward-compatibility?
6. I cannot specialize traits.
Traits are simply proprieties of a type.
They're specialized for every type by nature.
7. I can specialize policies.
Policies are usually just classes with static member functions, the
class fulfilling a particular concept.
How is that specialized?
Sorry to not be clear enough initially. By specialization, I did not
mean template specialization (for different types). By specialization,
I mean if there is a trait for a type, that remains so. They can be no
2 similar traits. It is hard to explain this in traits context because
it is too obvious but is clearer in case of policies, where in similar
allocation policy, for example, for a type can be implemented in
different specialized ways. They can have same names (template
specializations) or simply renamed classes fulfilling the policy
definition (cruder way). This one I think is too obviousn to mention
as well. You may ignore these two out of the discussion.
8. Type traits are compile time variants of RTTI.
RTTI allows to get an unique type dependent identifier from a
variable, to eventually compare it with other identifiers.
I don't see what a compile-time variant of this be. At compile-time,
types exist, so you can just compare the types to see whether they're
the same.
Not exactly C++ RTTI but RTTI in general sense - reflection. I was
just looking for an analogous name at runtime. Reflection suits better
as it is in C# or Java, not exactly as in C++.
9. basic_string template would have been better defined as considering
(3) above:
template< class CharT, template <class> CharTPolicyCollection,
template <class> AllocationPolicy>
class basic_string : public CharTPolicyCollection<CharT>,
public AllocationPolicy<CharT>
{
//members
};
10. The above uses public inheritance (MI). Is this correct modelling
No, if there are just policies (which prevents stateful allocators and
a lot of other stuff) they should neither be inherited (even worse not
publically) nor be members.
I see what you are saying. Having the string class inherit from those
will uselessly expose the members of those 2 policies from the
string's interface. Now I feel it is a rather naive thought on my
part. I have new questions on this now:
Isn't the allocator parameter in STL classes a policy? How does it
prevent stateful allocators?
I haven't changed much of the allocator parameter - just that it uses
template template parameters. I can agree to remove the public
inheritance here (also see [*] below) but in the current state, it is
quite easy to write:
std::vector<int, std::allocator<long> > someVec; //same for
basic_string, I guess
Although, that is wrong, it is not imposed at compile time. The
compilers either tend to ignore this template instantiation on long
and instead get the right one via rebind<T>::other or they do the
wrong allocations. With std::list (node based containers) this is more
clearer. With template template parameters, rebind won't be necessary
for vector etc. except for node-based containers but atleast it avoids
the confusing declaration as above.
The motive of the CharTPolicyCollection was to illustrate the the
char_traits are not really char traits but are implementation
policies. Please let me know if I am wrong here. Do policies always
need to expose some interface in their host class? (also, see [*]
below)
[*]Could I not have protected/private inheritance of the
CharTPolicyCollection<CharT> and AllocationPolicy<CharT> in the above?
Similarly, composition could server the pupose. I wonder why you
reject both options of inheritance or composed members? How does
policy based design work then? I don't think it is mandatory for
policies to expand the host class interface. They could just be used
as an implementation details providing the option to the user of the
class to choose it.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]