-----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Jim Douglas
[...]
Yeah... some libraries are so general-purpose (e.g. lambda, mpl, preprocessor) that it's hard for me to say anything that most people will identify as their use case.
Does *anyone* use them?
Yes, many people use them.
OK I was being slightly flippant, but some examples of would help identify use cases for those particular libraries.
The problem is that these libraries--particularly the MPL and the pp-lib--are general-purpose to the point of being language-like rather than library-like. Enumerating use cases for these libraries is like enumerating use cases of looping or branching. Listing several use cases doesn't even slightly do justice to the underlying concepts, and they become nothing more than complex examples. IMO, the approach of trying to solve a particular problem, searching for a library that solves (or helps to solve) the particular problem, and expecting to find one of these types of libraries is flawed. It works the other way around. Instead, you invest the time necessary to understand what kind of things these libraries can do, etc. (which doesn't imply mastering the library). Later, when you evaluate possible solutions to a particular problem, you often have more realistic possibilities because these libraries remove design limitations that would otherwise cause you to reject a possibility. Because of that, real-world use cases of these libraries are usually completely unrelated to what these libraries do. The libraries themselves are just used to implement "something else" that otherwise couldn't be easily implemented. (I'm having a hard time formulating what I'm thinking, so perhaps I'm not describing what I'm trying to get at very clearly.) Any given interface falls at some point between completely specific to completely general. An interface that is completely specific has only one specific use case. Such an interface is not a _library_ interface. An interface that is completely general has an infinite set of use cases that covers an infinitely broad scope. Such an interface cannot exist. Libraries in Boost vary greatly in where they fall along this specific->general axis. The more general a library is, the more difficult it is to describe the library in terms of use cases. When a library approaches being completely general, effective use requires a significant amount of lateral thought by the user, not use cases in the documentation. Examples (as opposed to use cases) in the documentation exist mainly as an attempt to induce the necessary lateral thought, not to show what problems the library solves. Hopefully, that made any kind of sense. I've given this a lot of thought over the last several years for the pp-lib docs, as this is a typical complaint ("The docs don't tell me in what situations the library is useful."). I still don't know what I could write to do that, and, at this point, I'm starting to think that attempting to do that is counterproductive. Regards, Paul Mensonides