Date: 2001-08-25 14:23:41
> For a specialiced version for a user defined type,
> your version would require function overloading,
> my verions would require template (traits) class specialization.
> In the current language definition, however,
> it is not allowed to overload functions in std namespace,
> so it is not clear how this version could ever become
> see e.g.
> for details.
> This is the reason why my version is more complicated
> internally, but AFAIK,
> there is no principal problem that could exclude it from
> becoming stanard.
> From the outside, fortunately, both versions
> are almost equivalent.
Right -- either way, usage is similar. However, I was playing with
the overloaded functions approach because:
1) The disallowing of overloaded functions in ::std is generally
considered a defect; I expect this restriction to be removed.
2) IMO, we need to keep these 'traits' as open as possible -- allow
users/other libraries to add their own. What if there is some
generic numeric algorithm out there that requires some other
property? IOW, a fast implementation of pow() depends on testing for
oddness, something that should be faster using a specialized function
than "i % 2 == 1" for non-builtins. But what if pow() wasn't in the
released library? We would see no need to test for oddness, and
wouldn't include it in the library. But since the traits are just
functions in a namespace, users/other libraries can add additional
This was just a thought -- it may turn out to be very bad in
practice, since it opens up a new way for users and libraries to mess
up each other. OTOH, going with a more traditional traits approach
will require each such extension to define their own "additional
Hmm. I don't see a really good solution from either of these. This
is just an explanation of the problem, as I see it: how can we
provide a 'traits' concept that allows the adding of user traits?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk