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 :)
> 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. 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!
> I've thought a lot about this, these days, regarding the composite
> operators. Trying to find the essential abstraction. Clearly, they are about
> passing composite objects (such as arrays, standard containers, etc.) to a
> stream, so that is the abstraction. This is also something which isn't
> covered much in current libraries. The question is if there's enough
> commonality in this abstraction, to warrant a library implementation.
>
> For the composite operators to be genuinely useful in a broader context, I
> think it's important that they do one thing, and one thing well.
>
> The challenge is to make something general enough, yet reasonably easy to
> use. Easy things should be easy, and hard things should be possible.
>
> My concern is, for example, for outputting a
> std::vector<std::pair<int,double> >:
>
> typedef std::pair<int, double> Map;
> typedef std::vector<Map> MapList;
>
> MapList list;
>
> 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.
> It also comes back to the question of commonality and variability.
> Currently, it uses static strings for start, end, and element delimiter.
> Anything else, and you need to use something else.
>
> I was first thinking of generalising it to any string type (rather than
> std::basic_string), but I've found that even that doesn't go far enough, if
> you want to change it radically. I've then been thinking of the possibility
> of passing a functor, instead, to the manipulator. The manipulator could
> then invoke this functor for each element to be output. This would enable
> things like listing element number in the output, by passing in an
> appropriate functor for this. The current semantics might be catered for by
> another functor, and overloaded constructors for this case may also be
> provided for convenience.
>
> BGL is similar, in that graphs are also composite objects. It uses
> "visitors", which are functors with multiple member functions (not just
> overloaded operator()), which are called at specific points in an algorithm.
> The same could be done with the composite operators, calling the functor at
> start, end and for each element.
>
> However, as the algorithm in this case is just iterating over a sequence,
> calling a functor or outputting each element, it's more or less the same as
> a for-loop, or for_each.
>
> It's also a question of what design space we are targeting: Originally,
> Vladimir Prus's suggestion was for something that could help with debug
> output. It's a question whether or not this can be made general enough to be
> useful beyond that, and if that is even desirable, concerning things like
> usability.
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 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...
> Regards,
>
> Terje
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
