On Thu, Sep 27, 2012 at 8:45 PM, Lorenzo Caminiti <lorcaminiti@gmail.com>wrote:
On Thu, Sep 27, 2012 at 2:09 PM, Matt Calabrese <rivorus@gmail.com> wrote:
On Thu, Sep 27, 2012 at 4:00 PM, Lorenzo Caminiti <lorcaminiti@gmail.com wrote:
It might help to start by taking a look at contract/detail/preprocessor/traits/. Also, this is a possible syntax I had in mind for C++0x concept definitions:
http://contractpp.svn.sourceforge.net/viewvc/contractpp/releases/contractpp_...
Looks great. I'll probably do most of that eventually, but I'd like to save those changes for later, since what is in currently works and I'd rather focus on new features first before I overhaul the interface.
Makes sense. Also be careful that Boost.Contract increases compilation times x30!! Essentially the lib does the following steps (1) macros parse the syntax (pp), (2) macros expand code that implements the contracts (pp), (3) the expanded code (there's a lot of template meta-programming here) is compiled (compiler). I don't know how the x30 is distributed between (1), (2), and (3) (I still have to analyze and optimize that) but if you were to adopt the syntax you'll start paying the overhead that comes from (1)--(2)
Right. Well, with respect to concepts at least, preprocessing overhead isn't as big of a deal for me anymore as it used to be, since concepts change very often -- as I mentioned, using the pre-preprocessed headers I provide (that are trivial to generate with the Boost.Wave driver) decreases compilation speed for Boost.Generic tests by over 50% by getting rid of all of the complex preprocessor metaprogramming, so even if using your macros behind the scenes increases compilation times because of preprocessing, I don't think it would matter too much in practice. Besides, I doubt your approach would be considerably slower or faster than what I'm doing right now. The interface is now much more important than preprocessing time. -- -Matt Calabrese