Denis Shevchenko wrote:
> 2011/6/10 Robert Ramey <
[hidden email]>
>
>> I think you'd find it interesting to see how the serialization
>> library
> does
>> it.
>
>> ../boost/archive/iterators/base64_from_binary
>> ../boost/archive/iterators/binary_from_base64
>
> Yes, Robert. :-)
>
> I took theese iterators (and 'transform_width') and wrap them in one
> simple and ready-to-use solution. Simple and ready-to-use even for
> novices.
>
> I need a such solution, for this common task. And I definetly know
> many developers looking for such solution. Solution they can use
> immediately, without long studying the documentation. Just few lines
> of code:
>
> int main() {
> std::string text = "TEXT";
> std::string encoded = boost::base64().encode( text );
> std::string text_again = boost::base64().decode< std::string >(
> encoded );
> }
>
> You think such (or similar) solution is not needed for Boost? Well,
> probably it is not needed, but I think it's useful. If not - I
> apologize for troubling.
Hmmm - so you are proposing that something like the following header
be added to boost?
#include <string>
#include <list>
#include <boost/archive/iterators/binary_from_base64.hpp>
#include <boost/archive/iterators/base64_from_binary.hpp>
#include <boost/archive/iterators/insert_linebreaks.hpp>
#include <boost/archive/iterators/remove_whitespace.hpp>
#include <boost/archive/iterators/transform_width.hpp>
namespace boost{
namespace base64{
// convert to base64
template<typename CharType>
std::string encode(std::basic_string<CharType> & s){
CharType *raw_data = s.c_str();
std::size_t size = s.size();
typedef std::list<CharType> text_base64_type;
text_base64_type text_base64;
typedef
boost::archive::iterators::insert_linebreaks<
boost::archive::iterators::base64_from_binary<
boost::archive::iterators::transform_width<
CharType *
,6
,sizeof(CharType) * 8
>
>
,72
> translate_out;
std::copy(
translate_out(static_cast<CharType *>(rawdata)),
translate_out(rawdata + size),
std::back_inserter(text_base64)
);
}
std::string decode(std::string & s){
...
}
Which I don't really see as a bad idea in and of itself. But I wonder about
other aspects?
a) where in the directory/namespace would this be? boost, boost/utility, or?
b) would it include all the boost machinery besides code? documentation,
formal review
tests etc?
c) All this for one small special purpose function?
d) How is a user going to find this pair of functions in the boost
libraries.
e) As soon as someone puts this in, imediately some else will ask - great
but it needs a parameter to so I can change the line width. Then someone
asks
for someother tweak. This is the result of making a "simple solution".
It's easy
enough to make a simple solution - it's very hard to keep it simple.
This is the reasoning behind my suggestion that for something like this one
should
be prepared to think bigger. In my view value of something like this (it
DOES have
value) isn't justified by the cost of getting it into boost. My advice -
think bigger.
I realize that the overhead of all this isn't your fault, but it still
exists. I don't see boost
as having the infrasture to handle an army of small (special purpose)
functions such as this.
Robert Ramey
_______________________________________________
Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
Locked
