Seminumerical algorithms, was Re: Unlimited integer: conversion to built-in int?

From: scleary_at_[hidden]
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
> standard,
> 
> see e.g.
> 
> http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2001/n1296.htm
> 
> 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 
traits.

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 
integer traits".

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?

        -Steve