Re: Advice of generic interface
On 7 Mag, 00:02, Jonathan Lee <cho...@shaw.ca> wrote:
If your answer happens to be "Well, nobody's gonna
add things to A" then I think _that_ would be bad
practice.
Well, nobody is supposed to add things to namespace std, I think :)
Anyway, you've made a good point and, as others have also said,
enable_if or SFINAE is appropriate.
[=85]
The rationale with the code above is to allow one to use f(), g() and
operator<< with different types by overloading only f()
See.. this I would use SFINAE for. For example, if f()
is some kind of toString() function, then I'd simply
make it a member of X. The operator<< template would just
read
os << x.toString();
What if X is not a class? You would have to overload all the functions
and operators=85 The idea behind the approach I was trying is to reduce
to amount of code you would have to write for a new arbitrary type. My
goal was to adapt unrelated types to my interface without changing
them or wrapping them. But now I realize that I was doing something
pretty silly, which can be summarized as:
namespace A {
template <typename T> T f(T const&);
template <typename T> void g(T const&) { /* =85 */ f(x); }
template <typename T> ostream& operator<<(ostream& os, T const& x);
typedef std::pair<int,int> Y;
Y f(Y const& y) { /* =85 */ }
}
Then, A::g(A::Y()) would be fine (with a forward declaration), but for
operators (e.g., std::cout << A::Y()) there's no hope. Besides, this
has nothing to do with the genericity of the functions and operators.
It seems like using a base class (as another poster has suggested)
would be much easier=85 A =93generic is-a=94 seems far less simple without
further support, Is boost::enable_if going to become part of the
standard?