"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