Look at this I see: we have one byte 8 bits long. transform_width should transform this in to "pieces" each 6 bits long. So there are two choices. return 1 6 bit piece and throw away 2 bits or return 2 6 bit pieces. This would require 12 bits from the input. Hence one would have to feed it 2 bytes. So that's why it requests 2 input bytes to produce 2 6 bit items. So a couple of "solutions" don't feed it it short strings. (fast, only done at setup, but perhaps burdensome) or alter transformwidth so that requests beyond the end of the input(easy to use, but perhaps slower) So I see that as the current situation. Robert Ramey Eames, Andrew wrote:
I posted this on the boost users group but got no final answer - this looks like a bug to me or am I just using it incorrectly?
Andrew
From: Eames, Andrew Sent: Friday, January 04, 2008 1:13 PM To: 'boost-users@lists.boost.org' Subject: Re: [Boost-users] base 64 encoding
I must be missing something fundamental here. The following code fragment doesn't work (VC++ 8.0 SP1) - the checked iterators in STL catch walking off the end of the source - transform_width is attempting to access the second element of the vector
typedef
base64_from_binary<
transform_width<vector<char>::const_iterator, 6, 8>
> base64_t;
vector<char> hippo(1);
string enc(base64_t(hippo.begin()), base64_t(hippo.end())); // -> checked iterator assertion fires
In basic_text_oprimitive.ipp, the iterator is a pointer so it's possible it may be silently doing something bad
Andrew
From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Robert Ramey Sent: Friday, January 04, 2008 11:58 AM To: boost-users@lists.boost.org Subject: [Spam:***** SpamScore] Re: [Boost-users] base 64 encoding
Take a look at basic_text_oprimitive.ipp around line # 64.
Note that I add "padding" here to address this problem. Perhaps that is the missing
magic. Hmmm. perhaps that code should be part of the iterator.
Also look at the code text_iterators_base64 in the serialization test suite.
Robert Ramey
"Eames, Andrew" <andrew@cognex.com> wrote in message news:8F37BF6F420455468C4BD57DD6BE199004C6146B@cobra.pc.cognex.com...
But there is still the problem with running off the end of the source - If the source is not a multiple of 3 bytes then the input iterator will run off the end of the input sequence which can cause an error.
Andrew
From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Robert Ramey Sent: Thursday, January 03, 2008 6:47 PM To: boost-users@lists.boost.org Subject: Re: [Boost-users] base 64 encoding
I had to separately record the number of bytes. Then when I decode, just pull off that number of bytes.
Robert Ramey
"Eames, Andrew" <andrew@cognex.com> wrote in message news:8F37BF6F420455468C4BD57DD6BE199004C613F8@cobra.pc.cognex.com...
Hi,
I'm trying to encode base64 data by composing base64_from_binary with transform_width but this doesn't appear to work correctly when the data is not a multiple of 3 long. What is the correct way to handle this - do I have to handle the padding myself by extending the input data and then patching the tail of the result?
Thanks
Andrew
________________________________
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost