On Fri, Sep 2, 2011 at 3:14 PM, Dave Abrahams <dave@boostpro.com> wrote:
on Fri Sep 02 2011, Lorenzo Caminiti <lorcaminiti-AT-gmail.com> wrote:
For whomever is curious, I have implemented the new Boost.Contract syntax. Here's large number of examples that now compile with the new syntax: http://svn.boost.org/svn/boost/sandbox/contract/libs/contract/doc/html2/cont...
Wow. This is a powerful new language! How does this relate to the work
Indeed, Boost.Contract defines a new DSEL which I named L++ ;) Here's the complete grammar (draft): http://svn.boost.org/svn/boost/sandbox/contract/libs/contract/doc/html2/cont... IMO, what is very interesting about L++ when compared with other DSEL (Boost.Phoenix, Boost.Lambda, etc) is that L++ is actually parsed all the way up by the preprocessor. Therefore, L++ can use both preprocessor and template meta-programming to implement it's features (and not "just" template meta-programming). For example, this allows to program the following basic Contract Programming rule: if a member function is not public then it does not check the class invariants This rule cannot be implemented using only template meta-programming because (AFAIK) it is not possible to check if a function is public using a C++ template meta-function like is_public<function-type>. Instead a macro IS_PUBLIC(function-decl) can be written to parse the L++ function declaration and expand to 1 if and only if the function is public: #define IS_PUBLIC(function_decl) ... IS_PUBLIC( public void f ( int x ) ) // expand to 1 IS_PUBLIC( private void g ( int y ) ) // expand to 0
Matt Calabrese started on implementing concepts in C++11 (see the boostcon video)?
Matt and I have exchanged a couple of emails previously on this thread. It looks like we are using similar pp techniques. However, I will have to study Matt's work in more detail before I can really comment...
It looks like this can't possibly be quite right (can it?)
http://svn.boost.org/svn/boost/sandbox/contract/libs/contract/doc/html2/cont...
Don't you need a comma after "boost::InputIterator<Iter>"?
Yes, I fixed it (I compiled this example with CONTRACT_CONFIG_NO_CONCEPTS which disables concepts so the compiler did not error).
Highlights are: * Side-by-side comparison with N1962 (contracts) and N2081 (concepts) syntax: http://svn.boost.org/svn/boost/sandbox/contract/libs/contract/doc/html2/cont... I have also added C++0x-like virtual specifiers (final, override, and new) to Boost.Contract: http://svn.boost.org/svn/boost/sandbox/contract/libs/contract/doc/html2/cont... Side-by-side comparison with Eiffel syntax: http://svn.boost.org/svn/boost/sandbox/contract/libs/contract/doc/html2/cont...
Comments are always welcome :)
* Very impressive! I might even try programming in this language. * How's debuggability (sorry for asking)?
After I have implemented the library I have to study: 1) Compile-time overhead (both pp and templates). This could be very significant because the macros use tons of pp code and expand tons of C++ template code. 2) Run-time overhead. This could also be very significant but mainly because of Contract Programming itself. If all contracts are disabled at compile-time that the run-time overhead should instead be 0. 3) Debuggability (integration with gdb, etc). This could be OK. 4) Integration with other tools like Doxygen, IntelliSense, etc. These other tools might simply not work because they might not be able to expand the macros (too complex pp code)... Boost.Wave should work instead...
* What's a "loop variant?" I've heard of "loop invariants."
A loop variant is a non-negative integer expression that monotonically decreases at each iteration of the loop (so it ensures that the loop will terminate because it starts from 100, then 98, then 90, eventually 0 and if less than 0 before the loop terminates the contract is broken because the variant must be >= 0 and the program -- not just the loop :) -- terminates ). http://en.wikipedia.org/wiki/Loop_variant. Eiffel has loop variants, N1962 does not. I implemented them in Boost.Contract but I can't argue they have been very useful for me... http://svn.boost.org/svn/boost/sandbox/contract/libs/contract/doc/html2/cont...
(I still have to implement named parameter support (using Boost.Parameter behind the scene) but that shouldn't be too hard. The macros already parse the named parameter syntax using in/out/inout "keywords".)
I can't wait.
The grammar for positional, named, and deduced params is here: http://svn.boost.org/svn/boost/sandbox/contract/libs/contract/doc/html2/cont... Thanks for your comments! --Lorenzo