|
Boost : |
From: scleary_at_[hidden]
Date: 2000-01-17 14:15:48
On call_traits, we need to define some strict requirements; for example,
which of the following are valid for _any_ T:
void func(call_traits<T>::param_type a)
{
call_traits<T>::value_type v = a; // assuming T has a copy constructor
call_traits<T>::reference r1 = a;
call_traits<T>::reference r2 = v;
call_traits<T>::const_reference cr1 = a;
call_traits<T>::const_reference cr2 = r1;
v = a; // assuming T allows assignment; maybe we could have a
const_value_type?
a = v; // assuming T allows assignment; maybe we could have a
const_param_type?
// should we look at a return_type? Or is it not necessary?
}
IMO, we should allow, as much as possible, for reference, etc. to be proxy
types for a given T, so well-defined restrictions on how the types in
call_traits may be used is a must.
-
Howard: on your implementation of compressed_pair, I would add the ability
to derive from both types if they're both empty, thus allowing
compressed_pair to be an empty class as well. (I already have some classes
that allow up to 3 contained templated classes to be empty -- a
compressed_pair of a compressed_pair :), and other classes that are empty if
their contained template classes are empty). Of course, if both types are
the same type (watch out for cv-qualification), then we would have to
contain one and derive from the other, like you have it now.
Also, it's just personal preference, but I like to hide (in 'details'), as
much as possible, anything that is not documented, like the default template
parameters on compressed_pair. For example, instead of:
template <class T1, class T2,
bool FirstEmpty = is_empty<T1>::value,
bool SecondEmpty = is_empty<T2>::value>
class compressed_pair;
I prefer:
namespace details {
template <class T1, class T2,
bool FirstEmpty = is_empty<T1>::value,
bool SecondEmpty = is_empty<T2>::value>
class compressed_pair_helper;
// implementation identical to original compressed_pair
} // namespace details
template <class T1, class T2> class compressed_pair
: public details::compressed_pair_helper<T1, T2>
{ ... (constructors) };
// OK to derive public because the base class is
// in 'details', which the user shouldn't use
It's a bit more work, but will work if user code requires a compressed_pair
to have only two template parameters (think of a user class with a template
template parameter trying to be satisfied by compressed_pair -- not likely,
but possible).
-Steve
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk