This is what std::reference_wrapper is for.
> I don't care what kind of data structure this came from
Fortunately, neither does the STL.
for_each(begin(foo_container), end(foo_container), some_foo_op);
Do you know what kind of container foo_container is? It doesn't matter. It can be a set, vector, list, or even a plain array.
> And then you can dream up things like the ability to take an iterator< foo > and a method on foo that will return a bar, to get an iterator< bar >
You can do this with std::transform.
transform(begin(foo_container), end(foo_container), begin(bar_container), op_to_make_foo_into_bar);
edit: I see from your other response that what you actually want is streams or generators, not an iterator.
Thank you for demonstrating a better way to do it. Hopefully I'll remember that the next time that I need it. (Which is likely to be several years from now.)
Also you're right that I would like streams and generators. But, to me, it is the same abstraction as iteration. See, for instance, how Python does it.
Put another way, the effort of learning something needs to be amortized over all of the times that you'll likely use that knowledge. I use C++, rarely enough that I won't get much amortization. (And when I do use it, it is painful enough that I don't want to explore it just for personal enjoyment. Leading to my avoiding C++...)
Template related error messages have historically been a huge pain, but modern versions of Clang and g++ are doing a much better job than they used to. If you haven't tried C++ recently (say last year or two), you might try again with a newer version of Clang.
Try to translate http://perl.plover.com/Stream/stream.html into C++ iterators to see how the current abstraction limits the ways you can think about a program. By contrast suppose that my hypothetical iterator< foo > type was required to have a pointer overload, and supported the methods done() and next(). Now go back and try to translate that article - you'll find that it is pretty easy.
That article demonstrated the power of this idea by writing code that fairly efficiently generates the Hamming sequence, which consists of all positive integers whose only divisors are 2, 3, and 5. (So 1, 2, 3, 4, 5, 6, 8, 9, 10, 12, 15, 16, 18, ...)
C++ is for larger , high performance applications.
The piper needs to be paid one way or another. If you rewrite a perl script in C++ for performance, the relative increase in verbosity is the price you pay.
However I believe that a substantial amount of verbosity could be removed without impacting said performance. In fact C++11 removes some with type deduction.
I also get tired of typing some_big_type foo = some_big_type(); - is there a way to say, "I want this thing, and I want it to get the obvious default initialization?" Because what I type now is straight from the redundant department of redundancy department. (Yes, a typedef can make that shorter. You still write the idea twice.)
If you're not talking about initialization, but instead talking about construction, just do some_big_type foo; (no parens needed).
I thought I was very clear when I said: "I want this thing, and I want it to get the obvious default initialization?"
I often wound up typing something like this:
std::vector< my_big_type > list_foo = std::vector< my_big_type >();
It seemed useless the first time, and just got sillier as time went on.
Now foo has been created.
Want to pass parameters to its constructor:
some_big_type foo(parameters, go, here);
foo has been initialised.
Need a pointer?
auto *foo = new some_big_type foo(parameters, go, here);
There are examples of iterators that use type erasure, but they still incorporate the iterator category in the type.
In practice, it's not really useful all that often. It has non-zero overhead so it's not good default choice, and you rarely absolutely need it. Most situations where you'd want to return a value then do something with it can be transformed into passing a callback to the function instead, which lets you use a templated operator() to achieve the same result without the runtime overhead.
However the biggest frustration for me (aside from the verbosity) is that things work until they suddenly don't work, and then it isn't obvious why they don't work from the debugging stack you get back. They often don't work for good reason - but unless you're a C++ expert you don't know that reason.
For example suppose that I have a class that has reference members. Those are fields specified with & - they are kind of like a pointer except that you can't change them, and you use . instead of ->. Because you can't change them, operator= is not generated for you. I didn't notice this until I tried to use one in an std::map< ... > and everything blew up.
However luckily confusing backtrace message plus google usually leads to a useful stack overflow answer, else I'd find this process much more painful.
My one remaining frustration is that I hate how the STL did iterators. In the STL, if you have a data_type< foo > template, you iterate over it with a data_type< foo >::iterator. So you get a std::vector< foo >::iterator, a std::set< foo >::iterator, a std::dequeue< foo >::iterator, etc.
This is great for the compiler, but as a programmer it is backwards. I don't care what kind of data structure this came from, I care what kind of data type I get out. I'd like to see those three examples produce an iterator< foo >. And then you can dream up things like the ability to take an iterator< foo > and a method on foo that will return a bar, to get an iterator< bar >. I am used to having map/grep/etc, and it would be nice to be able to translate list-oriented thinking into C++ with less verbose boilerplate.