
Hi Lorenzo, This is definitely outside the scope of the review, but I was wondering whether it would be feasible for the macros in Boost.Contract to handle base class aliases, as described in this proposal: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2881.html The positive "side effect" of your framework is that it has the potential to add various missing language features. I am wondering if these aliases proposed in N2881 are worth the effort. Regards, &rzej

Hi, On Tue, Aug 28, 2012 at 12:27 AM, Andrzej Krzemienski <akrzemi1@gmail.com> wrote:
Hi Lorenzo, This is definitely outside the scope of the review, but I was wondering whether it would be feasible for the macros in Boost.Contract to handle base class aliases, as described in this proposal: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2881.html
Sure, this should be possible. I've entered a ticket for it: https://sourceforge.net/apps/trac/contractpp/ticket/65 I'd propose the following syntax (given that these are essentially typedefs), now in C++: template< typename T, class CloneAlloc, class Alloc> class ptr_vector : public ptr_sequence_adapter<T, std::vector<void*, Alloc>, CloneAlloc> { typedef ptr_sequence_adapter<T, std::vector<void*, Alloc>, CloneAlloc> base_class; // base_class visible here (2) // ... }; In N2881: template< typename T, class CloneAlloc, class Alloc> class ptr_vector : base_class = public ptr_sequence_adapter<T, std::vector<void*, Alloc>, CloneAlloc> // base_class visible here (1) { // base_class visible here (2) // ... }; In a future Boost.Contract: CONTRACT_CLASS( template< typename T, class CloneAlloc, class Alloc > class (ptr_vector) extends( typedef (public ptr_sequence_adapter<T, std::vector<void*, Alloc>, CloneAlloc>) base_class ) // maybe base_class visible here (1)... ) { // base_class visible here (2) // ... }; This syntax is fully backward compatible with the current Boost.Contract syntax. I don't know if I can make base_class visible in the remaining base class list (1) (maybe I can... I'll have to see when implementing this) but I can definitely make it visible in the base class declaration (2) (as a typedef with the access level suggested by N2881).
The positive "side effect" of your framework is that it has the potential to add various missing language features. I am wondering if these aliases
Yep, it's a "little" DSEL used to declare (not define) classes and functions instead of the usual C++ declarations: http://contractpp.svn.sourceforge.net/viewvc/contractpp/releases/contractpp_... Concept declarations could be added too (and use something like Boost.Generic in the back-end, only I couldn't get my hands on Boost.Generic source code :( ): http://contractpp.svn.sourceforge.net/viewvc/contractpp/releases/contractpp_... The downside is that users need to learn the DSEL (even if it resembles C++ syntax), bad preprocessor/compiler errors if you misuse the syntax, and slow compilation times :( . Thanks, --Lorenzo
participants (2)
-
Andrzej Krzemienski
-
Lorenzo Caminiti