In the case of encoders, you also have to take into account the effects of
the Grouper class. For decoders, characters outside the encoding alphabet
are ignored, so the decoded length is unpredictable.
I think it's easy to program in a way that does not require knowledge of the
output size ahead of time. Use StringSink or the default attachment
MessageQueue (followed by Get()). If you really do need to know, put the
code that computes the output size using ArraySink::TotalPutLength() into a
reusable function, and use that.
----- Original Message -----
From: "Jens Peter Secher" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Monday, September 11, 2006 4:54 AM
Subject: Re: Size for Binary to Text Encoders and Decoders
On 9/9/06, Jason Smethers <[EMAIL PROTECTED]> wrote:
Is there any sort of static method for obtaining the encode and decode
size for data passed through HexEncoder, HexDecoder, Base64Encoder,
Base64Decoder, Base32Encoder, and Base32Decoder?
[...]
virtual unsigned int EncodeLength(unsigned int dataLength) const = 0;
virtual unsigned int DecodeLength(unsigned int dataLength) const = 0;
It would be better to implement them directly in classes BaseN_Encoder
and BaseN_Decoder, which should have all the necessary information.
--
Jens Peter Secher
_DD6A 05B0 174E BFB2 D4D9 B52E 0EE5 978A FE63 E8A1 jpsecher gmail com_
A. Because it breaks the logical sequence of discussion
Q. Why is top posting bad?
