Re: [boost] base64?

24 Jul 2017

      On 7/24/17 9:54 AM, Roger Leigh via Boost wrote:
...
On 24/07/17 16:28, Vinnie Falco via Boost wrote:
...
On Mon, Jul 24, 2017 at 8:27 AM, Vinnie Falco  
wrote:
...
On Mon, Jul 24, 2017 at 8:24 AM, Greger via Boost 
 wrote:
I also see this note:
...
It is available for a moderate compensation. Let me know by
email and I will send you the source.
Is this library open source or commercial in nature? What license is
it furnished under? Also, how is this better than the numerous other
base64 libraries (which are free) such as this one:
http://renenyffenegger.ch/notes/development/Base64/Encoding-and-decoding-bas...
Or 
https://github.com/ome/ome-common-cpp/blob/master/lib/ome/common/base64.h
which I probably wrote based on a similar source when I realised the 
Boost base64 support was broken and needed a quick implementation.  It 
avoids allocation issues by allowing the use of iterators including 
back_inserter.
We already have base64 conversion in 
boost/archive/iterators/*base64*.hpp.  It works but screws up the 
whitespace 
(https://stackoverflow.com/questions/10521581/base64-encode-using-boost-throw...). 
  It's a shame the various adapters don't work properly together; is 
there any prospect of this being fixed, or is the existing design simply 
too inflexible to make a proper base64 implementation?
I'm guessing it would be pretty easy to fix.  I base this on the design 
which is built up as a stack of iterator pairs.  This is documented in 
the serialization library under

http://www.boost.org/doc/libs/1_64_0/libs/serialization/doc/dataflow.html

This is used for the base64 stuff in the serialization library which as 
far as I know is correct.  That doesn't include adding on padding at the 
end - which maybe it should.

In any case making a stand along base64 component would require 
understanding the issues, making a small variation on the one in the 
library, make a test and adding it the test suite and making a 
commitment to support it in the future.  I just haven't had the 
motivation to do that - even though I think the code and design are very 
convenient and flexible.  Result is decent performance as well.  FYI it 
was made before boost ranges and can be considered a demonstration of 
the validity of using the range idea.

Robert Ramey
...
Regards,
Roger
_______________________________________________
Unsubscribe & other changes: 
http://lists.boost.org/mailman/listinfo.cgi/boost