RE: [boost] Re: io operations for stl containers?

From: Paul A. Bristow (boost_at_[hidden])
Date: 2003-02-10 14:18:22

I have followed this discussion with great interest.

I feel that the lack of an easy, 'library' 'standard' way of 'outputting' STL
objects is a major turnoff to their use.  There is persistent re-invention of
wheels. Some users may have their own special ideas about format, but a default
would be easy and essential, and be enough for most people.

If it can be used from debug tools, better still, but this should not deter work
from the promising start to allow std::cout << list;.

Paul

Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB  UK
[phone]   Mobile [phone]
Mobile mailto:pabristow_at_[hidden]
mailto:pbristow_at_[hidden]

> -----Original Message-----
> From: boost-bounces_at_[hidden]
> [mailto:boost-bounces_at_[hidden]]On Behalf Of Terje Slettebø
> Sent: Friday, February 07, 2003 9:38 PM
> To: Boost mailing list
> Subject: Re: [boost] Re: io operations for stl containers?
>
> The point with my posting was also to solicit feedback from others on the
> issue, what they think about it, what it could be used for. It would help
> define the application domain (also called problem domain).
>
> > > One thing is to create something useful. Another thing is to create
> > > something useful as a _library_ component. As has been noted regarding
> > > application and library development, application development and library
> > > development is typically quite different. With an application, you
> typically
> > > have quite specific requirements. With a library component, however,
> it's
> > > about anticipating future use. Or making something general enough to be
> > > useful as a library component.
> >
> > Very true,  but some libraries are useful simply because they're simply
> code that
> > people would write themselves over and over... only done in a better way.
>
> Yeah. Also, Björn Karlsson had an informal questionnaire on the list a while
> ago, about what people were using Boost for, and it turned out to be
> especially the simple components (not necessarily simple in implementation,
> by all means, but simple in concept) which were used, such as ref, bind,
> function objects, the smart pointers, etc.
>
> These are components which, as I mentioned, does one thing, and one thing
> well. That makes it easier to use/reuse these components in different
> contexts, as they are like building blocks.
>
> Of course "one thing" may be anything. In the case of MPL, it's a framework
> for metaprogramming, where each component does one thing. Thus, it provides
> a "language" for making things.
>
> > In the
> > current state of discussion, it sounds like something that I would
> definitely
> > use.  I've implemented poor versions on the fly in the past... always more
> > specific than composite_format...  One big use of special display
> > functions/operators is that you can call them from the debugger.  If there
> was a
> > debug-time friendly version of composite object output functions... and
> all I
> > needed to do was #include a specific header, that would be absolutely
> fantastic!
>
> Aha. Good point.
>
> > > You may do this:
> > >
> > > for(MapList::const_iterator i=list.begin(); i!=list.end(); ++i)
> > >   std::cout << '[' << i->first << ',' << i->second << "]\n";
> > >
> > > Or you may do:
> > >
> > > std::cout << composite_format<Map>("[", "]", "\n") << list;
> > >
> > > The question is, is it worth it?
> > >
> > > Of course, having defaults, the latter may be reduced to:
> > >
> > > std::cout << list;
> >
> > I absolutely hate not being able to do this last one by default.
> It would certainly be useful to come up with what we'd like to be able to
> do. We can consider this "time out", for reconsidering what we'd like to
> have.
>
>
> Regards,
>
> Terje
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>