From: Andrey Semashev (andysem_at_[hidden])
Date: 2007-06-20 17:05:48
Scott Woods wrote:
> ----- Original Message -----
>> Andrey Semashev <andysem_at_[hidden]> writes:
>>> 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...
> 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,
> * 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
> whether unicoding should be present within a debug stream evaporates. It
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk