Ben Tilly <[email protected]> writes: ... > If I have a vector of type Foo, then an iterator over it has type > std::vector< Foo >::iterator. > > If I have a map from Foo to Bar, then an iterator over it has type > std::map< Foo, Bar >::iterator. > > If I have a set of things of type Foo, then an iterator over it has > type std::set< Foo >::iterator. > > What's wrong with this? As a programmer I don't care what data type > they came from, I care what I am getting out of them. Therefore I
Not relevant to your point, but the type deduction on the auto keyword in C++11 looks kind of nice for not needing to hard code in a certain type of iterator in your local variables, though I guess it's not meant for you to stop caring about the types -- C++ never wants you to stop caring about type, does it. > would prefer the data types std::iterator< Foo >, std::iterator< > std::pair< Foo, Bar > >, and std::iterator< Foo >. For the use cases > currently supported by the STL, the compiler should be able to trace > through the data, and replace with what you currently have to write, > and then do something efficient. But it can fall back on a "slow" > generic implementation. (Slow in quotes because other languages do > not even blink at what is required.) > > What would you gain from this? Well read > http://perl.plover.com/Stream/stream.html and it is easy to translate > those examples into easy abstractions over the types that I wish the > STL provided. But none of it can be easily done in C++ today. (Well, > I can write the slow generic implementation and make it work, but not > so easily.) You want something in STL named std::iterator (not the actual std::iterator in <iterator> but a hypothetical thing) with streams support? But if you use it on a finite data structure you want it to realize that and generate as good code as would be done with what you'd use now? Do I have you right? Even if it were easy to do, this would bother most C++ programmers I think. There's too much of the compiler figuring out what you (perhaps needing knowledge of a library feature?) want for you and not a simple and direct enough mental model to map from source to machine code. When you want that you use some other language. I'd rather stream support be in there as an additional library feature (or something in boost) with a name other than iterator and leave the existing stuff as is. I wonder if Stepanov's original STL, the one that Stroustrup felt he had to chop up and prune down for the standards body, had anything like that. It's said he dated Scheme (and Ada) before falling in love with C++. He must be familiar with streams. But how do you get streams with C++ not having first class functions and lexical closures? Maybe there's a way around that somehow, but my thought would be to not fight the lack and look for an alternative fitting C++ more naturally like using function objects to provide the lazy evaluation, memoizing into an ordinary STL collection. This is kind of hand waving, so if I'm bored and have time in the next few days maybe I'll try it with the hamming number example. - Mike _______________________________________________ Boston-pm mailing list [email protected] http://mail.pm.org/mailman/listinfo/boston-pm
