>From: "Jason House" <[EMAIL PROTECTED]> > 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 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost