Re: [boost] [parameter] - catching accidental duplicate parameters at compile time
David Abrahams:
On conforming compilers, the library uses overloading to look up the value associated with any given keyword. I assumed that having two of the same keyword would cause an ambiguity error at lookup time:
7.3.3/12 of the standard appears to deal with this: "When a using-declaration brings names from a base class into a derived class scope, member functions in the derived class override and/or hide member functions with the same name and parameter types in a base-class (rather than conflicting)." i.e. a working model of the same keyword twice on an arg_list: struct keyword {}; struct base { int operator[](const keyword &) { return 1; } }; struct derived : public base { using base::operator[]; int operator[](const keyword &) { return 2; } }; int main() { return derived()[keyword()]; }
The problem with this (aside from the use of an ALL_CAPS name for something other than a macro)
Thanks for the tip!
is that it costs O(N^2) instantiations, where N is the number of arguments. OTOH you could do it with overloading (or just use an mpl::set, which uses overloading internally) to do it in O(N).
Oooh, that's much better. With used_keywords as an empty set in empty_arg_list, all it needs in arg_list is: BOOST_STATIC_ASSERT((!boost::mpl::has_key< typename Next::used_keywords, key_type>::type::value)); typedef typename mpl::insert<typename Next::used_keywords, key_type>::type used_keywords; Or is there already something that captures the above pattern, i.e. refuses to insert a duplicate? --Daniel.
Daniel Earwicker <daniel.earwicker@gmail.com> writes:
Oooh, that's much better. With used_keywords as an empty set in empty_arg_list, all it needs in arg_list is:
BOOST_STATIC_ASSERT((!boost::mpl::has_key< typename Next::used_keywords, key_type>::type::value));
Use BOOST_MPL_ASSERT_MSG here.
typedef typename mpl::insert<typename Next::used_keywords, key_type>::type used_keywords;
Or is there already something that captures the above pattern, i.e. refuses to insert a duplicate?
Not that I know of. Actually in this case I think I'd prefer to see a solution using overloading directly, just to cut down on instantiations. The arg_list, after all, is almost the same structure as the set already. Something like: static char (& has_key(K const&) )[2]; BOOST_MPL_ASSERT_MSG( sizeof(Next::has_key(make<K>())) == 1 , duplicate_keyword, (K) ); If you could submit a patch to the current CVS along with an expected-compilation-failure test case, I'd be happy to apply it. -- Dave Abrahams Boost Consulting www.boost-consulting.com
On 11/3/05, David Abrahams <dave@boost-consulting.com> wrote:
Something like:
static char (& has_key(K const&) )[2];
BOOST_MPL_ASSERT_MSG( sizeof(Next::has_key(make<K>())) == 1 , duplicate_keyword, (K) );
If you could submit a patch to the current CVS along with an expected-compilation-failure test case, I'd be happy to apply it.
Excellent, thanks. One question about the above code: is make<> already declared somewhere? In the meantime I've added this as a member of arg_list: template <class T> static const T &make(); Or how about passing has_key a pointer, as NULL pointers are easy to make? Apologies for my ignorance about these details. --Daniel.
Daniel Earwicker <daniel.earwicker@gmail.com> writes:
On 11/3/05, David Abrahams <dave@boost-consulting.com> wrote:
Something like:
static char (& has_key(K const&) )[2];
BOOST_MPL_ASSERT_MSG( sizeof(Next::has_key(make<K>())) == 1 , duplicate_keyword, (K) );
If you could submit a patch to the current CVS along with an expected-compilation-failure test case, I'd be happy to apply it.
Excellent, thanks.
One question about the above code: is make<> already declared somewhere?
Probably a thousand places ;-)
In the meantime I've added this as a member of arg_list:
template <class T> static const T &make();
Or how about passing has_key a pointer, as NULL pointers are easy to make?
Yeah, that saves a make(). Good idea.
Apologies for my ignorance about these details.
You seem pretty knowledgeable to me :) -- Dave Abrahams Boost Consulting www.boost-consulting.com
On 11/8/05, David Abrahams <dave@boost-consulting.com> wrote:
Daniel Earwicker <daniel.earwicker@gmail.com> writes:
One question about the above code: is make<> already declared somewhere?
Probably a thousand places ;-)
Where I come from, we call that the copy'n'paste methodology. :)
You seem pretty knowledgeable to me :)
The sad thing is... I showed that comment to my colleagues. I've attached the arg_list patch and failduplicate.cpp to test it. Apologies for the delay.
Daniel Earwicker wrote:
I've attached the arg_list patch and failduplicate.cpp to test it. Apologies for the delay.
Thank you! Unfortunately this won't work on at least VC6/7. I will apply this patch for other compilers and leave VC6/7 without this feature until I have the time to create a workaround. -- Daniel Wallin
Daniel Wallin wrote:
Daniel Earwicker wrote:
I've attached the arg_list patch and failduplicate.cpp to test it. Apologies for the delay.
Thank you! Unfortunately this won't work on at least VC6/7. I will apply this patch for other compilers and leave VC6/7 without this feature until I have the time to create a workaround.
I used the technique used in mpl::set<> to work around the problem. Code and test is now checked in. Thanks for you help. -- Daniel Wallin
Daniel Wallin wrote:
Thank you! Unfortunately this won't work on at least VC6/7. I will apply this patch for other compilers and leave VC6/7 without this feature until I have the time to create a workaround.
I used the technique used in mpl::set<> to work around the problem. Code and test is now checked in.
Thanks for you help.
A pleasure. Sorry I could only test it on VC7.1 (and some old version of gcc I had).
Daniel Earwicker <daniel.earwicker@gmail.com> writes:
Daniel Wallin wrote:
Thank you! Unfortunately this won't work on at least VC6/7. I will apply this patch for other compilers and leave VC6/7 without this feature until I have the time to create a workaround.
I used the technique used in mpl::set<> to work around the problem. Code and test is now checked in.
Thanks for you help.
A pleasure. Sorry I could only test it on VC7.1 (and some old version of gcc I had).
Unfortunately not old enough. The changes seem to have broken gcc-2.95.3 http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues.... -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
Daniel Earwicker <daniel.earwicker@gmail.com> writes:
Daniel Wallin wrote:
Thank you! Unfortunately this won't work on at least VC6/7. I will apply this patch for other compilers and leave VC6/7 without this feature until I have the time to create a workaround. I used the technique used in mpl::set<> to work around the problem. Code and test is now checked in.
Thanks for you help. A pleasure. Sorry I could only test it on VC7.1 (and some old version of gcc I had).
Unfortunately not old enough. The changes seem to have broken gcc-2.95.3
Yes. I've been trying to find a workaround, but can't get anything working outside my small tests. :( mpl::set<> doesn't work on gcc2.95 either, so maybe we should just leave this feature out for that compiler. -- Daniel Wallin
participants (3)
-
Daniel Earwicker -
Daniel Wallin -
David Abrahams