[boost] Re: io operations for stl containers?

From: Jason House (jhouse_at_[hidden])
Date: 2003-02-10 11:31:50

Vladimir Prus wrote:

> >>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...
>
> This sounds interesting, but I'm not sure what those other functions could be.

  I agree... I have only the fogiest of ideas as to what that would be...
  For starters,  a display function for each composite object type.  One very serious
complication with templated types, is that it might very well be an army of
functions...  Will debuggers perform type matching similar to a compiler?  Or would
the template parameters need to be explicitely stated?
  In addition, what about overrides to the basic output characteristics?  Seperation
characters is one thing,but an almost more important one would be output
suppression...   Like having a map output all the keys, but skipping all the
values...  (likely boiling down to a pair outputting one of the two items inside of
it)... When I was thinking of extra support functions, I was thinking of the
override/suppression concept...
  As far as what else, I don't know... but again, even such a basic functionality
would be great to have in a #included library header :)  The other potential issue
that I have is that for the library to be most useful, you should be able to have
output functions for composite objects available to you by default... maybe something
like adding a macro to replace typedef...

like maybe
#ifdef COMPOSITE_TYPE_DEBUG
#define COMPOSITE_TYPE(x,y) \
    typedef x y; \
    { \
        /* force compiler to make output function */
        y boost_dummy_variable; \
        boost::composit_io::details::null << boost_summy_variable; \
    }
#else
#define COMPOSITE_TYPE(x,y) typedef x y;
#endif

of course, that might not be the best approach... I think #defines are avoided... but
hopefully the concept is clear...