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

From: Terje Slettebø (tslettebo_at_[hidden])
Date: 2003-02-07 16:37:45

>From: "Jason House" <jhouse_at_[hidden]>

> Terje Slettebø wrote:
>
> > Regarding this project. I've got doubts about the viability of it.
>
> Well, I'm glad you've given it a greater level of thought.  I really like
the idea
> of the composite_format, and probably should try to do the same :)

Thanks for your feedback. I like the idea, as well. We have I/O for single
objects, but no specific way for composites. The question is if we should
have that. :) Maybe the reason we don't have it, yet, is that it may be hard
to come up with a system that is general enough, yet easy to use.

Since I posted this, I've been reading the discussion on
serialisation/persistence, such as Jens Maurer's, and Robert Ramey's
recently reviewed serialisation library. It seems there were similar issues
there: It was hard to find one way of doing it, which could be generally
agreed on.

It may actually be easier to come up with a system for serialisation, at
least when it comes to the serialised format, since the format to use for
serialisation may be easier to define. However, for operators for
human-readable I/O, there's a potentionally large variation in how you might
want to do it.

In the case of the composite operators, nobody has complained about lack of
generality, or ease of use, but I've been thinking about this issue, myself.

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.  Having a
well
> written default for this makes it all worth it for me!  The for loop has
no chance
> of being evaluated properly in a debugger, but a debugger can likely call
the <<
> operator with less difficulty.

Right.

> How easilly can a debugger print out an STL object?  I know that gdb can
call
> functions that are defined in the code.  For templated functions, this is
probably
> a major hassle.  Could there be some way to enable a debugger to call a
function
> like this?  If so, what's the best way to enable that without massive
efforts from
> the user?

I guess it depends on the debugger. I've typically done such printing
explicitly in the code, rather than invoking it in the debugger.

> I also could imagine some way of adding hooks intended for calling from a
debugger
> to alter output behavior based on what the person debugging is interested
in....
> Say for instance forcing the output of a specific type to be suppressed?
>
> I'm pulling at stings, but there has to be good stuff to add if we come up
with
> the right aspect to develop.  I have never heard of a library designed for
> evaluation of debug-time expressions...  It would be interesting to see
how
> powerful of a "compile-time debugger enhancement" concept we could come up
with.
> Why stop with just debugging symbols?  Make an army of debugging
functions...

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