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

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-02-10 10:13:30

Terje Slettebø wrote:
>>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.

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