streaming redux

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Wed Dec 29 00:33:33 PST 2010


On 12/29/10 1:37 AM, Robert Jacques wrote:
> On Tue, 28 Dec 2010 23:34:42 -0700, Andrei Alexandrescu
> <SeeWebsiteForEmail at erdani.org> wrote:
>
>> On 12/28/10 11:54 AM, Sean Kelly wrote:
>>> Andrei Alexandrescu Wrote:
>>>
>>>> On 12/28/10 5:09 AM, Vladimir Panteleev wrote:
>>>>>> abstract interface Formatter;
>>>>>
>>>>> I'm really not sure about this interface. I can see at most three
>>>>> implementations of it (native, high-endian and low-endian variants),
>>>>> everything else being too obscure to count. I think it should be
>>>>> implemented as static structs instead. Also, having an abstract method
>>>>> for each native type is quite ugly for D standards, I'm sure there's a
>>>>> better solution.
>>>>
>>>> Nonono. Perhaps I chose the wrong name, but Formatter is really
>>>> anything
>>>> that takes typed data and encodes it in raw bytes suitable for
>>>> transporting. That includes e.g. json, csv, and also a variety of
>>>> binary
>>>> formats.
>>>
>>> This one is really difficult to get right. JSON, for example, has
>> named members of its object type. How could the name of a field be
>> communicated to the formatter? The best I was able to do with C++
>> iostreams was to create an abstract formatter class that knew about the
>> types I needed to format and have protocol-specific derived classes do
>> the work. Here's some of the dispatching code:
>>>
>>> printer* get_printer( std::ios_base& str )
>>> {
>>> void*& ptr = str.pword( printer::stream_index() );
>>>
>>> if( ptr == NULL )
>>> {
>>> str.register_callback(&printer_callback, printer::stream_index() );
>>> ptr = new xml_printer();
>>> }
>>> return static_cast<printer*>( ptr );
>>> }
>>>
>>> std::ostream& operator<<( std::ostream& os, const message_header& val )
>>> {
>>> printer* ptr = get_printer( os );
>>> return (*ptr)( os, val );
>>> }
>>>
>>> Actually using this code to write data to a stream looks great:
>>>
>>> ostr<< header<< someobj<< anotherobj<< end_msg;
>>>
>>> but I'm not happy about how much specialized underlying code needs to
>>> exist.
>>>
>>> I guess what I'm saying is that a generic formatter may be great for
>>> simple formats like zip streams, CSV files, etc, but not so much for
>>> more structured output. That may be a sufficient goal for
>>> std.stream2, but if so I'd remove JSON from your list of possible
>>> output formats :-)
>>
>> I agree with the spirit. In brief, I think it's fine to have a Json
>> formatter as long as data is provided to it as Json-friendly types
>> (ints, strings, arrays, associative arrays). In other words, I need to
>> simplify the interface to not attempt to format class and struct types
>> - only built-in types.
>
> By the way, JSON doesn't support associative arrays in general. It only
> supports AA in the sense that JSON objects are an array of string:value
> pairs.

Yah, I meant AAs keyed on string types and with values that in turn are 
JSON-friendly.

Andrei


More information about the Digitalmars-d mailing list