Boost logo

Boost :

Subject: Re: [boost] Boost.Generic, C++0x Concepts, and C++1y Concepts
From: Matt Calabrese (rivorus_at_[hidden])
Date: 2012-09-27 20:57:24


On Thu, Sep 27, 2012 at 8:45 PM, Lorenzo Caminiti <lorcaminiti_at_[hidden]>wrote:

> On Thu, Sep 27, 2012 at 2:09 PM, Matt Calabrese <rivorus_at_[hidden]> wrote:
> > On Thu, Sep 27, 2012 at 4:00 PM, Lorenzo Caminiti <lorcaminiti_at_[hidden]
> >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_0_4_1/doc/html/contract__/concepts.html#contract__.concepts.concept_definitions__not_implemented_
> >
> >
> > 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

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk