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

[Vladimir Prus]

Terje Slettebų wrote:

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.

Most likely I don't need to say it again, but having fixed i/o operators with
fixed output format is better that have nothing. As you've noticed, my original motivation was debugging output, and I still find this important enough.

[...]

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.

True. But there are some limits to what you could reasonably do by outputting
composite objects. For example, generation of code, or html, or something,
is not easily feasible. In fact, I cannot suggest any "advances" usage which is not close to serialization.

And, sure enough, I don't want to use serialization for debug output. Your current code is 4K. You cannot make serialization library of that size.

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.

But you don't write library, put a seal on it, and stop. There's nothing wrong
with making it more flexible when users demand it. As it stands, only few persons are interested in the simplest facilities. Is it worth spending time on completely generic/flexible solution if no-one has expressed desire for it?

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.

+1. I've tried to make the same point above.

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.

+1, again.

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.

- Volodya

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost