Re: [boost] Is Boost interested in the Boost-based Base64 library
2011/6/10 Robert Ramey <ramey@rrsd.com>
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. - Denis
2011/6/10 Robert Ramey <ramey@rrsd.com>
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. - Denis
Denis Shevchenko wrote:
2011/6/10 Robert Ramey <ramey@rrsd.com>
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
"Robert Ramey" <ramey@rrsd.com> writes: [snipped example wrapping detailed, generic code to provide "obvious" if less flexible interface]
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?
Maybe add a "Boost.Cookbook", showing mere mortal C++ programmers how to best use the deeper aspects of Boost? It could even be advertised as "non-normative", in a sense, so that it wouldn't hold up a release.
b) would it include all the boost machinery besides code? documentation, formal review, tests etc?
If we allocated a cookbook / samples directory, we could use "silos" to apply the formal process to individual files/functions: doc/base64.txt src/base64.hpp test/base64_test.cpp This would be completely independent of someone taking, e.g., one of the TCP servers out of the ASIO docs and making a sample out of it: doc/tcp_server.txt src/tcp_server.hpp test/tcp_server_test.hpp I just caught up on a week or two of posts to boost-devel, and I recall there was at least one other instance of someone suggesting a tiny snippit of code for inclusion into boost, and others replying [essentially] that there's too much overhead to bother adding 6 lines somewhere.
c) All this for one small special purpose function?
There are many other useful small snippits that are currently strewn across the documentation for various libraries. Maybe centralizing them in one place (again, as "cookbook" or "here's how the boost experts /use/ boost, as opposed to when they're writing boost") would be helpful. I'm particularly reminded of a quote from Scott Meyer's _Effective STL_: "One programmer's vision of expressive purity is another programmer's demonic missive from Hell."
d) How is a user going to find this pair of functions in the boost libraries.
A cookbook with an index, especially with keywords, would be nice. (Speaking of which, is there a single index that covers all the boost libs in a single document?)
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.
Ah, but the cookbook approach would allow for a better response: we've shown you how to do the simple, straightforward thing using these powerful constructs; if you want to change something, take this code and adapt it to your needs, or use the more powerful tools directly.
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.
Does a cookbook seem a reasonable way to 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.
It might be that creating such a nook would allow for quite a few contributions, precisely because there's such a high hurdle to overcome for a normal library. I'd guess that everyone on this list has a handful of "helper functions" that they'd be happy to submit if it only took an hour of their time, but can't afford to make fully generic and fleshed out and then wait 6 months for review. Just an idea. Best regards, Tony
Anthony Foiani wrote:
"Robert Ramey" <ramey@rrsd.com> writes:
[snipped example wrapping detailed, generic code to provide "obvious" if less flexible interface]
...
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.
Does a cookbook seem a reasonable way to 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.
It might be that creating such a nook would allow for quite a few contributions, precisely because there's such a high hurdle to overcome for a normal library. I'd guess that everyone on this list has a handful of "helper functions" that they'd be happy to submit if it only took an hour of their time, but can't afford to make fully generic and fleshed out and then wait 6 months for review.
Just an idea
It's not such a bad idea - but it's an entirely different idea than what boost is. I think we're in agreement here. Off topic - but I'll make a couple of comments on the C++ Cookbook ideal Actually this exists. I simply troll the net for "C++ base64 source code" and I get a bunch of hits. I didn't look into them but I would hope/expect that there would be something similar to that which has been proposed. I would look at them, and perhaps copy one of them out and into my code. This is fine, works fine, and solves my problem. But this doesn't belong in boost. Boost strives to catalogue the difinitive, complete and general solution to widely encountered problem domains. This means the the libraries are of necessity more complete, better documented, better tested, rigorously reviewed and vetted. It's an entirely different thing than the C++ cookbook. Boost is feeling the strain trying to keep up with it's current mission which no one else is doing. It can't expand in to new territory which is already covered. Just because an idea may be a good idea, it doesn't necessarily follow that it should be in boost. Robert Ramey
On Sun, Jun 12, 2011 at 1:15 AM, Robert Ramey <ramey@rrsd.com> wrote:
It's not such a bad idea - but it's an entirely different idea than what boost is. I think we're in agreement here.
Off topic - but I'll make a couple of comments on the C++ Cookbook ideal
Actually this exists. I simply troll the net for "C++ base64 source code" and I get a bunch of hits. I didn't look into them but I would hope/expect that there would be something similar to that which has been proposed. I would look at them, and perhaps copy one of them out and into my code. This is fine, works fine, and solves my problem.
IMO it's not fine. It's a recipe for big scale code duplication. If the same function appears in tons of C++ apps it's IMO a sign that some lib is lacking. Olaf
participants (4)
-
Anthony Foiani -
Denis Shevchenko -
Olaf van der Spek -
Robert Ramey