Re: [boost] [explore] Library Proposal: Container Streaming

Subject: Re: [boost] [explore] Library Proposal: Container Streaming
From: strasser_at_[hidden]
Date: 2009-12-01 14:47:00

the whole list is up in arms about printing a vector...

Zitat von Jeremy Pack <rostovpack_at_[hidden]>:
> I agree with Volodya here. In my environment at least, we would not be
> willing to include all of the serialization headers just to be able to print
> a vector to the screen.

in my environment, I wouldn`t even be willing to look if there`s a  
boost library that prints a vector for me.
is printing containers all it does? then it`s argueable just filling  
an omission of the STL container library, and could be part of  
Boost.Container, which is already on the review schedule.
when both libraries are accepted seperately it would be like boost had  
Boost.Variant and Boost.OutputVariant, DateTime/OutputDateTime, ...

until then, STL can handle most cases:
copy(V.begin(), V.end(), ostream_iterator<int>(cout, ","));

> Here is what you're example looks like with boost serialization

link an external library for printing a vector?

> Yes, too much time and resources. When building debug variant, an  
> program that does nothing
> but creates std::vector<int> is a 53K object file. When I add  
> serialization, I get:
[...]
> - a 387K object file

that doesn't mean anything, does it?
boost.serialization creates huge call stacks and instantiates dozends  
if not hundreds of trivial functions, that are all removed in a  
non-debug build.