[contract] first attempt to N3351 concepts
Hello all, I made a first attempt to sketch how N3351-like concepts will look into Boost.Contract (just for the find algorithm and its concepts for now): http://contractpp.svn.sourceforge.net/viewvc/contractpp/branches/stl_concept... This code doesn't compile quite yet but I played with its bits and pieces enough to conclude that it should be implementable as listed. It will take quite a bit of time and effort to implement this... Please tell me what you think now so I don't waste time implementing this design if it has issues. Thanks a lot! --Lorenzo
On Tue, Oct 9, 2012 at 2:17 PM, Lorenzo Caminiti <lorcaminiti@gmail.com>wrote:
Hello all,
I made a first attempt to sketch how N3351-like concepts will look into Boost.Contract (just for the find algorithm and its concepts for now):
http://contractpp.svn.sourceforge.net/viewvc/contractpp/branches/stl_concept...
This code doesn't compile quite yet but I played with its bits and pieces enough to conclude that it should be implementable as listed. It will take quite a bit of time and effort to implement this... Please tell me what you think now so I don't waste time implementing this design if it has issues.
I've only skimmed it, but it looks good! I do have one very superficial suggestion about future documentation -- it may be helpful to use a custom-build of quickbook that highlights the "keywords" concept and requires (and also recommend users to update their IDE to highlight on these keywords as well, since it makes things much easier to read, at least IMO). You can make the changes to quickbook by altering the keywords_holder type in syntax_highlight.cpp. Actually, quickbook should probably be officially updated for C++11 keywords too. It seems as though they were never added. -- -Matt Calabrese
On Tue, Oct 9, 2012 at 3:27 PM, Matt Calabrese <rivorus@gmail.com> wrote:
On Tue, Oct 9, 2012 at 2:17 PM, Lorenzo Caminiti <lorcaminiti@gmail.com>wrote:
Hello all,
I made a first attempt to sketch how N3351-like concepts will look into Boost.Contract (just for the find algorithm and its concepts for now):
http://contractpp.svn.sourceforge.net/viewvc/contractpp/branches/stl_concept...
This code doesn't compile quite yet but I played with its bits and pieces enough to conclude that it should be implementable as listed. It will take quite a bit of time and effort to implement this... Please tell me what you think now so I don't waste time implementing this design if it has issues.
I've only skimmed it, but it looks good! I do have one very superficial suggestion about future documentation -- it may be helpful to use a custom-build of quickbook that highlights the "keywords" concept and requires (and also recommend users to update their IDE to highlight on these keywords as well, since it makes things much easier to read, at least IMO). You can make the changes to quickbook by altering the keywords_holder type in syntax_highlight.cpp.
True. The same goes for Boost.Contract "keywords" like precondition, postcondition, etc. I didn't know how to do this but I'll look into quickbook's syntax_highlight.cpp as you suggested (ideally, new "keywords" could be added from a Jamfile...).
Actually, quickbook should probably be officially updated for C++11 keywords too. It seems as though they were never added.
This should be done. --Lorenzo
on Tue Oct 09 2012, Lorenzo Caminiti <lorcaminiti-AT-gmail.com> wrote:
Hello all,
I made a first attempt to sketch how N3351-like concepts will look into Boost.Contract (just for the find algorithm and its concepts for now):
http://contractpp.svn.sourceforge.net/viewvc/contractpp/branches/stl_concept...
This code doesn't compile quite yet but I played with its bits and pieces enough to conclude that it should be implementable as listed. It will take quite a bit of time and effort to implement this... Please tell me what you think now
Since you asked what I think, "pseudo-signatures > usage patterns" but that's probably not the kind of information you were looking for :-) -- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost
On Tue, Oct 9, 2012 at 7:16 PM, Dave Abrahams <dave@boostpro.com> wrote:
on Tue Oct 09 2012, Lorenzo Caminiti <lorcaminiti-AT-gmail.com> wrote:
Hello all,
I made a first attempt to sketch how N3351-like concepts will look into Boost.Contract (just for the find algorithm and its concepts for now):
http://contractpp.svn.sourceforge.net/viewvc/contractpp/branches/stl_concept...
This code doesn't compile quite yet but I played with its bits and pieces enough to conclude that it should be implementable as listed. It will take quite a bit of time and effort to implement this... Please tell me what you think now
Since you asked what I think,
"pseudo-signatures > usage patterns"
but that's probably not the kind of information you were looking for :-)
Yes, that's more of a critique to N3351 than my design to implement it but it's a fare comment. If N3351 approach is to be abandoned in favor of pseudo-signatures then no point in implementing N3351 but I don't think there's consensus on this either way yet. I personally don't have an opinion yet... (and maybe I should have an opinion before I go off an impl the entire N3351). Thanks, --Lorenzo
Since you asked what I think,
"pseudo-signatures > usage patterns"
but that's probably not the kind of information you were looking for :-)
Yes, that's more of a critique to N3351 than my design to implement it but it's a fare comment. If N3351 approach is to be abandoned in favor of pseudo-signatures then no point in implementing N3351 but I don't think there's consensus on this either way yet. I personally don't have an opinion yet... (and maybe I should have an opinion before I go off an impl the entire N3351).
Even if you decide to go with pseudo-signatures, one novel thing from N3351 is worth adapting: treating every concept as a predicate, so that the programmer can check himself whether a certain set of types models the concept: static_assert( ForwardIterator<int*>, "ouch" ); and so that you can combine concept requirements with any boolean meta-function: template <class T> requires Copyable<T> && sizeof(T) < 8 ... Regards, &rzej
On Wed, Oct 10, 2012 at 1:51 AM, Andrzej Krzemienski <akrzemi1@gmail.com> wrote:
Since you asked what I think,
"pseudo-signatures > usage patterns"
but that's probably not the kind of information you were looking for :-)
Yes, that's more of a critique to N3351 than my design to implement it but it's a fare comment. If N3351 approach is to be abandoned in favor of pseudo-signatures then no point in implementing N3351 but I don't think there's consensus on this either way yet. I personally don't have an opinion yet... (and maybe I should have an opinion before I go off an impl the entire N3351).
Even if you decide to go with pseudo-signatures, one novel thing from N3351 is worth adapting: treating every concept as a predicate, so that the programmer can check himself whether a certain set of types models the concept:
static_assert( ForwardIterator<int*>, "ouch" );
and so that you can combine concept requirements with any boolean meta-function:
template <class T> requires Copyable<T> && sizeof(T) < 8 ...
I agree that concepts should be boolean meta-functions as they are in N3351, they will be in Boost.Contract, and I think they are in Boost.Generic. Also I think that's the only (?) way for concepts to remove the function/class templates from the overload/specialization set instead of causing a hard compiler error. However, there might be some requirements that cannot be checked as a boolean meta-function but that can be checked as to generate an hard compiler error. For example, in C++03 we could not program an has_copy_constructor boolean meta-function but Boost.ConceptCheck can check the CopyConstructible concept to generate a hard compiler error. If there are similar situations in C++11 still, that's a reason to keep Boost.ConceptCheck around in C++11 together with Boost.Contract and Boost.Generic concepts. Thanks. --Lorenzo
On Wed, Oct 10, 2012 at 4:51 AM, Andrzej Krzemienski <akrzemi1@gmail.com>wrote:
Even if you decide to go with pseudo-signatures, one novel thing from N3351 is worth adapting: treating every concept as a predicate, so that the programmer can check himself whether a certain set of types models the concept:
static_assert( ForwardIterator<int*>, "ouch" );
and so that you can combine concept requirements with any boolean meta-function:
template <class T> requires Copyable<T> && sizeof(T) < 8 ...
The functionality of retrieving a boolean value is supported in Boost.Generic, but you can't just use the concept directly as a value/MPL-style integral constant because accessing the concept as, for instance, Copyable<T> has to access the concept map. Making it an MPL integral constant type would conflict. The way you do it in Boost.Generic is any of a number of ways. First, if you want a boolean value you can use the macros BOOST_GENERIC_CONCEPT_IS_MODELED_BY and BOOST_GENERIC_CONCEPT_IS_MODELED_BY_C. If you want to assert, which is generally more common, you can #include <boost/generic/assert.hpp> and do any of the following: // Generates a static_assert, alerting the user if the concept is not modeled and all of the individual reasons why it's not. BOOST_GENERIC_ASSERT( YourConcept< T > ); // Generates a static_assert, alerting the user if the concept is not modeled, giving a user-provided error message. Boost_GENERIC_ASSERT_MSG( YourConcepts, "Your message." ); // Generates a static_assert, alerting the user if the concept is modeled. BOOST_GENERIC_ASSERT_NOT( YourConcept< T > ); // Generates a static_assert, alerting the user if the concept is modeled, giving a user-provided error message. BOOST_GENERIC_ASSERT_NOT_MSG( YourConcept< T >, "Your message." ); If you look through the Boost.Generic std_concept/concepts and std_concept/support_concepts tests in the sandbox you can see examples. I'm working on detailed documentation right now while I update some other functionality in the library, but there's a ton of stuff to do at the moment. -- -Matt Calabrese
2012/10/9 Lorenzo Caminiti <lorcaminiti@gmail.com>
Hello all,
I made a first attempt to sketch how N3351-like concepts will look into Boost.Contract (just for the find algorithm and its concepts for now):
http://contractpp.svn.sourceforge.net/viewvc/contractpp/branches/stl_concept...
This code doesn't compile quite yet but I played with its bits and pieces enough to conclude that it should be implementable as listed. It will take quite a bit of time and effort to implement this... Please tell me what you think now so I don't waste time implementing this design if it has issues.
N3351 allows specifying sort-of postconditions with axioms, like: axiom Clearing(Vec vec) { vec.clear(), vec.empty(); } This uses the comma operator in a tricky way to perform two instructions. I wonder if this will interfere with the way the comma is interpreted in Boost.Contract. Is it possible in your design to type: axiom( (vec.clear(), vec.empty()) ) ?
On Wed, Oct 10, 2012 at 12:54 AM, Andrzej Krzemienski <akrzemi1@gmail.com> wrote:
2012/10/9 Lorenzo Caminiti <lorcaminiti@gmail.com>
Hello all,
I made a first attempt to sketch how N3351-like concepts will look into Boost.Contract (just for the find algorithm and its concepts for now):
http://contractpp.svn.sourceforge.net/viewvc/contractpp/branches/stl_concept...
This code doesn't compile quite yet but I played with its bits and pieces enough to conclude that it should be implementable as listed. It will take quite a bit of time and effort to implement this... Please tell me what you think now so I don't waste time implementing this design if it has issues.
N3351 allows specifying sort-of postconditions with axioms, like:
axiom Clearing(Vec vec) { vec.clear(), vec.empty(); }
Yes, this won't work.
This uses the comma operator in a tricky way to perform two instructions. I wonder if this will interfere with the way the comma is interpreted in Boost.Contract. Is it possible in your design to type:
axiom( (vec.clear(), vec.empty()) )
Yes, this should work. But then again, given that we are only checking axioms syntax and we are not running them, it won't make any difference in practice... Thanks, --Lorenzo
participants (4)
-
Andrzej Krzemienski -
Dave Abrahams -
Lorenzo Caminiti -
Matt Calabrese