Re: Enum semantics

> One needs to fake the other, IMHO.  Either can fake being the other.
> Choosing choice 2 (no count) means we assume all enumerations are
> imperitive and destructive.  Choosing choice 3 (applicative) means we
> assume all enumerations have not-slow counts (no worse than O(n) time and
> O(log n) stack/memory to return a count of n), and we don't need a clone.
> Choosing choice 1 means we've choosen not to choose (which is always a
> choice), and expect everyone to deal with both types of enumerator.

I agree with Brian here.
Since we don't want the forward/input iterator distinction to be enforced by
the type of the enumeration itself, we have two choices left : having a flag
that can tell about it - that's somehow what's fast_count is doing now - or
enforcing it into the count function directly, with an int option return
type. The problem is, what can do the people that want to count an input
iterator ? Enum.count is nice because it's working all the time, fast_count
is here to help if you care about performances. Of course, the complexity of
a call to Enum.count can be specified such as taking at more O(n) time and
O(log n) stack that looks reasonable.
Specifying an O(n) count function is not nice, you should rely on Enum to do
the work for you, and then treat your data as an input enumerator.

Regards,
Nicolas Cannasse



-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click