On Sun, Sep 16, 2012 at 5:48 PM, Dave Abrahams <dave@boostpro.com> wrote:
on Sun Sep 02 2012, Roland Bock <rbock-AT-eudoxos.de> wrote:
Due to a lack of formal contracts in much of day to day programming and the enormous compile time overhead, I don't see the library being used all over the place anytime soon, but I expect it to be used in generic algorithms, helping both developers and library users.
Do we know the sources of the compile-time overhead?
No, I don't.
If it's mostly in the preprocessor,
I could be in both the preprocessor (either the parsing of the syntax or the expansion of the declaration and contract code) and/or in the template meta-programming code.
I suggest consulting with Paul Mensonides.
I will do some analysis first (probably after the 1st Boost release as the meta-programming optimizations should not alter the public API): http://sourceforge.net/apps/trac/contractpp/ticket/48 Then I will ask the experts as needed--Paul for the pp and yourself for the MPL part ;)
He was an enormous help in getting the preprocessing cost associated with Boost.Python under control. In particular, it's important to make good use of the _D, _R, and _Z suffixes described in http://www.boostpro.com/mplbook/preprocessor.html#id6
IMO, the syntax is "bad" but the compile-time overhead is the real barrier for a broader use of the lib. Therefore, improving compilation time (if at all possible) will be a priority right after the 1st Boost release. Thanks, --Lorenzo