From: brangdon@cix.compulink.co.uk (Dave Harris)

In-Reply-To: <200407072103.i67L3Jk28273@tesh.systems.susq.com> stewart@sig.com (Rob Stewart) wrote (abridged):

...

...

v << foo() << bar();

I don't like that. It suggests formatted insertion rather than initialization.

It's not intended to be initialisation. It does a push_back(), so you can do it at any time and not just on empty vectors. I guess I'd pick a different name for the library, but as written that includes += so it too is not just for initialisation.

The name misleads one into thinking myopically about its use.

As I said, I don't think formatting is an essential characteristic of operator<<(). It happens to be necessary for streams because they are text oriented. The serialisation library uses operator<<() without formatting.

A reasonable point, though not having used the serialization library, I still think of operator<< and operator>> as doing formatted I/O.

...

As you point out, conversion is possible, but one can't overload operator<< to customize the initialization.

Why not?

vector<Foo> &operator<<( vector<Foo> &v, const Bar &bar ) { return v << bar.toFoo(); // Or whatever conversion you want. }

Or whatever the right types are.

I overstated the case. How many types will one have to overload operator<< (and operator>>) for? The combinatorial explosion (containers X types to use with the initialization library X 2) will be overwhelming. If there is a standard representation one wants in those contexts, one might get away with using a function template to genericize the container type, but then you'd need a way for that template to be used only in specific contexts. Also, what if you want different formatting in different containers, even with the same type? (No doubt I'm trying to make difficult what's supposed to be a simplistic task.)

...

Thus, it doesn't fit neatly with IOStreams.

It's not polymorphic with them, but I think it fits about as neatly as the serialisation library.

I can't agree, at least not yet. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;