I think it would be hard to keep out. Also I think it would be very difficult to keep it from growing. I think this is a general problem in boost: feature creep is all over
Hi Robert, I think you are asking the right questions On 2015-10-31 17:10, Robert Ramey wrote: the place. Considering the little manpower that is actually developing boost, adding new features is likely to have long term consequences as it is much easier to add stuff to boost than to remove it. There is also very little oversight, once a library is accepted. This is a result of the boost model: people propose their libraries to boost, but boost does not have a list of "open problems". As there are no requirements on what the libraries priorities are, there is only little guidelines regarding the time after acceptance. This model also has an impact of the later point you mentioned: while there are people actively developing new libraries for boost, there is not much checking whether it is relevant. People who do not understand the problem are likely to stay away from the review and thus biasing the review process: "I have never heard about coroutines or fibers, apparently this is a thing. Someone else should review it before I write something stupid".
I'm actually more concerned about the demand for such a thing. I think it's very compelling. But as a member of the Program Committee for CPPcon 2015 I was very much struck by the lack of interest in topics related to mathematics and mathematical thinking. In particular there was a proposal for Algorithmic Differentiation implemented via TMP. In spite of strong advocacy on my part, other committee members were convinced that it was too advanced mathematically for the expected attendees. They might well have been right - if they were - it's even more disturbing to me.
I agree, this is disturbing especially considering how much scientific high performance code is written in C++. But I think this is a symptom of an underlying problem: there are no math standards in the C++ world, no standardized libraries or any agreement on interfaces. Therefore people are spread over many incompatible libraries and thus the impact of a single boost library is limited to the small fraction of scientific programmers that happen to be compatible to that interface. For example we have uBLAS as one competitor for linear algebra, but currently Eigen and Armadillo are just better. As boost has impact, there are a few projects which try to be compatible to uBLAS (e.g. viennaCL and the thing i rolled myself) but still this does not give this library some magical impact because Eigen is so much better. I would say that uBLAS is therefore a "lost cause" as it has so many features that there is no way that the performance problems can be solved within the given development constraints. now, coming back to the TMP automdiff library: if there is no standardized way to represent vectors and the boost way is not favorable, there is also no standardized way to represent vector valued functions let alone their derivatives. Without this, automatic differentiation is just not as useful as working with single dimensional functions is almost trivial, especially as there are many tools which just spit out the right derivative and implementing that is only a few lines of code. On the other hand, as someone who wrote a few thousand lines of derivatives of vector-valued functions in machine learning, I would love to see a high performance TMP solution that I could just plug-in. Best, Oswin