Re: [Boost-users] Boost.IOStreams and Custom filters on strings

From: Jonathan Turkanis (turkanis_at_[hidden])
Date: 2008-02-12 14:28:10

Stefan Arentz wrote:
> On Feb 7, 2008 4:54 AM, Jonathan Turkanis <turkanis_at_[hidden]> wrote:
>> Stefan Arentz wrote:
>>> I've written a really simple aggregate_filter that runs the world
>>> famous and highly secret ROT13 encryption. This filter works fine when
>>> I use a file_sink and file_source. But I really just want to run this
>>> on a bunch of string buffers. Unfortunately it does not work, the
>>> destination string is always empty. Does anyone understand why?
>> This is the same problem discussed in your other thread 'Another
>> desperate ...'. It can be solved the same way, using reset() or pop().
>>
>> I guess this would be a good place to ask: As a newcomer to the
>> iostreams library, would you be surprised if
>>
>>         copy(in, out)
>>
>> where in and out are filter chains, automatically popped both chains,
>> assuming this behavior was clearly documented?
> 
> Hi Jonathan,
> 
> For me 'copy' means that data is moved from source to destination
> without any additional actions from my part. Whether it pops() or
> resets() the filter internally is ok, as long as it is part of the
> copy procedure and documented behaviour as you say.

Right, I agree that not copying all the data is wrong; but popping the 
terminal device is surprising as well. I guess I'm just going to have to 
announce that close() pops a filter chain.

> I find both operations, pop or reset, very misleading in this case
> though. They are the last thing you think of when what you really want
> to do is 'flush' the final bits of the copy.

I didn't understand this the first time I read it, so let me make sure I 
get your point: are you saying that 'pop' and 'reset' don't sound like 
names of functions you would normally call as part of a copy operation, 
but that the behavior of the functions would be okay after a copy 
operation, as long as one of them were renamed 'close', or if 'close' 
were to call one of them? If so, I think I now agree.

> Another thing that would be really nice would be the ability to do
> something like this:
> 
>   copy(src, base64_decoder() | aes_filter("Secret") | gzip_decompressor(), dst);
> 
> Or maybe even a shortcut like:
> 
>   std::string src, dst;
>   filter(src, base64_decoder() | ...more ... | ...filters ... |
> gzip_decompressor(), dst)

When I wrote the library I wanted to make

        copy(src | filter1 | ... | filtern, dest)

and

        copy(src, filter1 | ... | filtern | dest)

(and also, as a side-effect

        copy( src | filter1 | ... | filterm,
               filter(m+1) | ... | filtern | dest ) )

work as you might expect. Unfortunately I couldn't get it to work on 
some of the old compilers we supported at the time. (Even though the 
library seems pretty simple, there's a lot of magic that goes on behind 
the scenes to allow standard streams, user-defined classes, iterators, 
and iterator ranges to be handled with the same simple interface. For 
new compilers it is not much of a challenge, but the old compilers were 
pushed almost to the breaking point.) It should be pretty easy to 
implement this now, but it will have to wait to 1.36.

I have opened a ticket http://svn.boost.org/trac/boost/ticket/1633.

> Since I think a lot of people are operating directly on strings.
> 
>  S.

Thanks,

-- 
Jonathan Turkanis
CodeRage
http://www.coderage.com