|
Boost : |
From: Andrei Alexandrescu (andrei_at_[hidden])
Date: 2006-04-28 19:03:51
Gennadiy Rozental wrote:
> "Andrei Alexandrescu" <andrei_at_[hidden]> wrote in message
> news:e2r31o$29s$1_at_sea.gmane.org...
>> [Apologies if this appears multiple times. Apparently I can't use an
>> invalid email address anymore, and that's caused a number of problems
>> with my account.]
>>
>> Gennadiy Rozental wrote:
>>> "bwood" <brass_at_[hidden]> wrote in message
>> news:20060423224436.A5D61B6554B_at_gateway.mailvault.com...
>>>> : "Gennadiy Rozental" <gennadiy.rozental_at_[hidden]> wrote in message
>>>> :>"Ivan Vecerina" <ivec_at_[hidden]> wrote in message
>>>>
>>>> :> It's not like boost::serialize currently dominates the world
>>>> :> of persistent storage.
>>>> :
>>>> :So? I see a potencial for it to become a standard like iostreams now.
>>>>
>>>> I'm glad you added the part about iostreams as I think it hits the
>>>> nail on the head. I agree with Andrei's opinions of iostreams.
>>>>
>>>> http://groups.google.com/group/comp.lang.c++.moderated/browse_frm/thread
>>>> /86a5a3f804c84ea4/48842ae2fd029ce6?hl=en#48842ae2fd029ce6
>>> I don't have time to read through this huge thread regarding garbage
>> collection to search for iostreams related staff, but after his recent
>> "performace" in printf article I wouldn't value his opinion in I/O
>> domain that much.
>>
>> Ouch. What did I do? I'd be glad to hear any criticism. If this is
>> off-topic in this group, feel free to use comp.lang.c++.moderated
>> instead. Thanks!
>>
>> Andrei
>
> Sorry, Andrei. I am really busy at the moment. I will need to dig out the
> article in CUJ to answer specifically. But I remember I was really
> disappointed at the time. I will try to reply soon.
Thanks, I'd appreciate that. Speed would be issue #1 that I didn't like
about the initial version because it doesn't do any buffering; but the
framework allows that very easily. That's why I didn't care to provide
more than a proof of concept. The opening comment of SafeFormat.h is:
// Crude writing method: writes straight to the file, unbuffered
// Must be combined with a buffer to work properly (and efficiently)
So that was one issue I am aware of; I didn't want to write a faster
output facility, just to prove that one could be written :o). I'm sure
there's other problems though.
To bring this more on topic: are there any plans to implement input to
complement Boost::Format?
Andrei
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk