Re: [boost] [rfc] I/O Library Design

From: Andrey Semashev (andysem_at_[hidden])
Date: 2007-06-20 17:05:48

Scott Woods wrote:
> ----- Original Message ----- 
>> Andrey Semashev <andysem_at_[hidden]> writes:
>>
>> [snip]
>>
>>>  From my point of view we have touched two problems in the discussion:
>>> the ability to easy and efficiently format things into text or octet
>>> strings and internationalization support.
> 
> With you so far, but there is so much more! ;-)
> 
> What if...

[snip]

> Dont mean to be flippant with these examples. They are just supposed
> to shine the light around; drag some significant parties into the
> discussion, i.e. would resulting libraries be targeted at developers
> and their debug requirements or developers and their pan-language
> UI requirements?
> 
> A functional breakdown of the above might look like;
> 
> 1. Character stream with embedded runtime values
> * default format control on a per-C++ type basis
> * format overrides (unsigned long as dotted IP)
> * user-defined format for user-defined types
> * user-defined input-text-to-type-instance conversion
> 
> 2.Character stream with embedded runtime layout control
> * default layout control for tabulation of STL containers (no headers, 8 
> space tabstops)
> * layout overrides (specific headers and tabstops)
> * user-defined layouts for user-defined types (e.g. labels, 
> line-per-type-member)
> * navigation, selection and text input of layouts

Most of the above is about formatting and parsing data to/from text. 
IMHO, most of it is implementable via stream manipulators in the same 
manner. Thus I don't see much difference between 1 and 2 in this way.

> 3. Runtime construction of i8n display information
> * too big to start listing

That's the least covered area in the discussion. Unfortunately, I don't 
have much experience in supporting i18n since I mostly develop server 
applications, so I don't have much to say here. It would be good if 
someone more experienced than me could elaborate this field better.

> This is just a sequential listing; the order is not intended to be 
> significant. The grouping
> relates to the examples rather than a set of suggested proposals.
> 
> I suspect there is a matrix of end-user system requirements and potential
> software technologies. Developers need to be able to declare at compile-time
> whether the application debug stream has user-defined types and/or unicoding
> requirements. Does the UI need to speak anything other than Cantonese (and
> is that the developers first language?).
> 
> With that ability to "cook up" the different streams the potential arguments 
> over
> whether unicoding should be present within a debug stream evaporates. It 
> becomes
> a per-application decision.

Agreed, users should be able to decide what they need and should not pay 
for what they don't need.

> As further input to this thread; I have recently done a lot of work in the
> areas of serialization and also rendering that same information in different
> UIs. There is an intriguing amount of overlap between what serialization
> does and what debug/logging/UI streams need to do. While I wont go
> as far as saying that application streams should exist over serialization
> technology (hmmmm) there might be borrowed techniques?

Could be. In fact, I tend to think that streaming IO should implicitly 
support serialization as a form of formatting.