GSoC: Enforcing Code Feature Requirements
Hi, I have recently reread the article "Enforcing Code Feature Requirements in C++" by Scott Meyers <http://www.artima.com/cppsource/codefeaturesP.html> I have posted some ideas that could improve the design (<http://www.artima.com/forums/flat.jsp?forum=226&thread=238798&start=0#372622>) I wanted to know if this could be a good subject for GSoC, if the approach I purpose to solve some issues is acceptable and if there is some students interested. Of course any comments are welcome. Best, _____________________ Vicente Juan Botet Escribá
vicente.botet wrote:
Hi,
I have recently reread the article "Enforcing Code Feature Requirements in C++" by Scott Meyers <http://www.artima.com/cppsource/codefeaturesP.html>
I have posted some ideas that could improve the design (<http://www.artima.com/forums/flat.jsp?forum=226&thread=238798&start=0#372622>)
I wanted to know if this could be a good subject for GSoC, if the approach I purpose to solve some issues is acceptable and if there is some students interested.
Of course any comments are welcome.
I like the idea of playign with this, but: isn't this somethign Concept and Concept-based SFINAE should handle ?
On Wed, Mar 31, 2010 at 8:55 AM, Joel Falcou <joel.falcou@lri.fr> wrote:
I like the idea of playign with this, but: isn't this somethign Concept and Concept-based SFINAE should handle ?
I have always used them to handle such situations. What would be the advantages of the approach you describe (Vicente) over this one ? -- Alp Mestanogullari http://alpmestan.wordpress.com/ http://alp.developpez.com/
----- Original Message ----- From: "Alp Mestanogullari" <alp@mestan.fr> To: <boost@lists.boost.org> Sent: Wednesday, March 31, 2010 1:15 PM Subject: Re: [boost] GSoC: Enforcing Code Feature Requirements
On Wed, Mar 31, 2010 at 8:55 AM, Joel Falcou <joel.falcou@lri.fr> wrote:
I like the idea of playign with this, but: isn't this somethign Concept and Concept-based SFINAE should handle ?
I have always used them to handle such situations. What would be the advantages of the approach you describe (Vicente) over this one ?
I have resumed them on the link: Advantage of this approach: * Support controlled call to 3pp functions. * Support operators. * Allows to specify code features for groups of functions (class) * No impact on runtime performance. * Improve diagnostics: static assert is enough explicit. * the user can specialize the can_call metafunction for specific functions directly. Liabilities: * Unable to call different functions depending on the provided features. This needs to maintain the feature parameter. Best, Vicente
----- Original Message ----- From: "Joel Falcou" <joel.falcou@lri.fr> To: <boost@lists.boost.org> Sent: Wednesday, March 31, 2010 8:55 AM Subject: Re: [boost] GSoC: Enforcing Code Feature Requirements
vicente.botet wrote:
Hi,
I have recently reread the article "Enforcing Code Feature Requirements in C++" by Scott Meyers <http://www.artima.com/cppsource/codefeaturesP.html>
I have posted some ideas that could improve the design (<http://www.artima.com/forums/flat.jsp?forum=226&thread=238798&start=0#372622>)
I wanted to know if this could be a good subject for GSoC, if the approach I purpose to solve some issues is acceptable and if there is some students interested.
Of course any comments are welcome.
I like the idea of playign with this, but: isn't this somethign Concept and Concept-based SFINAE should handle ?
Sure concepts can help. In my proposition I use traits class to set all the features, but a trait by features is also possible to emulate concepts. IIUC SFINAE needs to add a parameter to the function. The main goal of my approach is to don't need such a parameter. Joel, maybe you can elaborate how the Concept/SFINAE approach manages with this problem. Best, Vicente
Joel, maybe you can elaborate how the Concept/SFINAE approach manages with this problem.
Sure, in my head, we can define Concepts callee ThreadSafe, ExceptionSafe etc and just use BOOST_CONCEPT_REQUIRE on those (or the real C++0x concept maps) and have Concept Violation error when you try to call one function with improper settings. Then, IIRC there was planned to have SFINAE based on concept so we cna alos have function prunning (ie nice 'no such function f() defined' inthose case. Using BOOST.CC, I already do that for parallel computing enforcement: i have a type traits that I can specialize per obejct or function type basis and the concept class just check for this concept then I write: template<class F,class A> BOOST_CONCEPT_REQUIRE( (CalalbleObject<F>)(DataParallel<F>) , std::vector<boost::result_of<F(A)>::type> ) map( F f, std::vector<A>); if f is not a CallableObjec supporting data-parallelism (here I just check that is_dataparallel<F>::value is true) then the function is not permitted. Such a mechanism can be applied to what's describe in the article, or am I mistaken ?
joel falcou-3 wrote:
Joel, maybe you can elaborate how the Concept/SFINAE approach manages with this problem.
Sure,
in my head, we can define Concepts callee ThreadSafe, ExceptionSafe etc and just use BOOST_CONCEPT_REQUIRE on those (or the real C++0x concept maps) and have Concept Violation error when you try to call one function with improper settings. Then, IIRC there was planned to have SFINAE based on concept so we cna alos have function prunning (ie nice 'no such function f() defined' inthose case.
Using BOOST.CC, I already do that for parallel computing enforcement: i have a type traits that I can specialize per obejct or function type basis and the concept class just check for this concept then I write:
template<class F,class A> BOOST_CONCEPT_REQUIRE( (CalalbleObject<F>)(DataParallel<F>) , std::vector<boost::result_of<F(A)>::type> ) map( F f, std::vector );
if f is not a CallableObjec supporting data-parallelism (here I just check that is_dataparallel<F>::value is true) then the function is not permitted.
Such a mechanism can be applied to what's describe in the article, or am I mistaken ?
Well, the problem is that the constraints on features must be checked on the caller function. So you will need to add a parameter or a template parameter for the caller function. This is what I try to avoid. In your case we will need to have template<class F,class A, typename CALLER> BOOST_CONCEPT_REQUIRE( (CalalbleObject<F>)(DataParallel<F>)(ThreadSafe<CALLER>) , std::vector<boost::result_of<F(A)>::type> ) map( F f, std::vector ); and the user will need to call the function map as follows void g() { map<void g()>(foo, v); } On the other side this can not be applied to 3pp function which don't have specified the constraint using SFINAE. Hoping my concern will be clear now. Vicente -- View this message in context: http://old.nabble.com/GSoC%3A-Enforcing-Code-Feature-Requirements-tp28091769... Sent from the Boost - Dev mailing list archive at Nabble.com.
Ok I completety get it now. So, thumb up for me :)
This seems like an interesting idea. I think it might factor nicely into my PhD dissertation which seems to involve both concepts and software maintenance issues. Would it be entirely entirely inappropriate for me to submit a proposal or just marginally inappropriate for me to submit a proposal :) Andrew Sutton andrew.n.sutton@gmail.com
----- Original Message ----- From: "Andrew Sutton" <andrew.n.sutton@gmail.com> To: <boost@lists.boost.org> Sent: Wednesday, March 31, 2010 10:09 PM Subject: Re: [boost] GSoC: Enforcing Code Feature Requirements
Ok I completety get it now. So, thumb up for me :)
This seems like an interesting idea. I think it might factor nicely into my PhD dissertation which seems to involve both concepts and software maintenance issues.
Would it be entirely entirely inappropriate for me to submit a proposal or just marginally inappropriate for me to submit a proposal :)
Hi Andrew, you are of course welcome to submit a proposal, I know you will do it much better than I could do on the best day of the week ;-) Glad to hear that there is people interested in, Vicente
Would it be entirely entirely inappropriate for me to submit a proposal or just marginally inappropriate for me to submit a proposal :)
Hi Andrew, you are of course welcome to submit a proposal, I know you will do it much better than I could do on the best day of the week ;-)
You're being much too gracious :) I'm not sure if its even possible to be a GSoC student, mentor, and admin for the same organization. That article looks like it has some very interesting ideas. I'll have to spend some time digesting it tomorrow. Andrew Sutton andrew.n.sutton@gmail.com
On 3/31/10, Andrew Sutton <andrew.n.sutton@gmail.com> wrote:
Ok I completety get it now. So, thumb up for me :)
This seems like an interesting idea. I think it might factor nicely into my PhD dissertation which seems to involve both concepts and software maintenance issues.
Andrew Sutton andrew.n.sutton@gmail.com
I've been thinking lately that concepts and test cases and APIs and documentation are all intertwined. D (language) allows unit tests to be coded right beside the implementation code. Concepts describe constraints that must be successfully 'passed' - like unit tests. APIs and documentation often include example-code. unit tests are often the best examples, and often the best^H^H^H^H only documentation of the API - ie the API does this - and is suppose to do this - because that's what the unit tests test for. Docs can be written in the code comments (eg javadocs), but concepts and unit tests (particularly in D) are right in the code. Obviously very vague ideas at the moment. Maybe I should read up on Knuth's WEB again... Tony
Gottlob Frege wrote:
On 3/31/10, Andrew Sutton <andrew.n.sutton@gmail.com> wrote:
Ok I completety get it now. So, thumb up for me :)
This seems like an interesting idea. I think it might factor nicely into my PhD dissertation which seems to involve both concepts and software maintenance issues.
Andrew Sutton andrew.n.sutton@gmail.com
I've been thinking lately that concepts and test cases and APIs and documentation are all intertwined.
D (language) allows unit tests to be coded right beside the implementation code. Concepts describe constraints that must be successfully 'passed' - like unit tests.
APIs and documentation often include example-code.
unit tests are often the best examples, and often the best^H^H^H^H only documentation of the API - ie the API does this - and is suppose to do this - because that's what the unit tests test for.
Docs can be written in the code comments (eg javadocs), but concepts and unit tests (particularly in D) are right in the code.
Obviously very vague ideas at the moment. Maybe I should read up on Knuth's WEB again...
Tony, You lost me. Where do you want to go? Best, Vicente -- View this message in context: http://old.nabble.com/GSoC%3A-Enforcing-Code-Feature-Requirements-tp28091769... Sent from the Boost - Dev mailing list archive at Nabble.com.
On Fri, Apr 2, 2010 at 5:19 AM, Vicente Botet Escriba <vicente.botet@wanadoo.fr> wrote:
Gottlob Frege wrote:
On 3/31/10, Andrew Sutton <andrew.n.sutton@gmail.com> wrote:
Ok I completety get it now. So, thumb up for me :)
This seems like an interesting idea. I think it might factor nicely into my PhD dissertation which seems to involve both concepts and software maintenance issues.
Andrew Sutton andrew.n.sutton@gmail.com
I've been thinking lately that concepts and test cases and APIs and documentation are all intertwined.
D (language) allows unit tests to be coded right beside the implementation code. Concepts describe constraints that must be successfully 'passed' - like unit tests.
APIs and documentation often include example-code.
unit tests are often the best examples, and often the best^H^H^H^H only documentation of the API - ie the API does this - and is suppose to do this - because that's what the unit tests test for.
Docs can be written in the code comments (eg javadocs), but concepts and unit tests (particularly in D) are right in the code.
Obviously very vague ideas at the moment. Maybe I should read up on Knuth's WEB again...
Tony, You lost me. Where do you want to go?
Best, Vicente
Well, considering it was only a vague idea that has been floating around in the back of my head, and that I wrote the email at 2am, I'm not surprised it made little sense. Let me try again. And start by saying, and this is somewhat my point, I don't know where it goes. Maybe it is something a grad student can take and run with. Or if someone wants to pay my bills and feed my family, I'll investigate it further :-) (I should also mention that it has probably veered somewhat from your original post about 'Code Features' and Meyers' article, and had more to do with Andrew Sutton's response and mention of concepts and software maintenance. But even 'Code Features' was about verifying necessary constraints, so I suppose it applies as well. As I will hopefully explain in the following...) The idea(s) is that concepts (ala C++) are a way to *verify* that the types passed in meet the necessary requirements. Now this verification is somewhat weak (more syntactic than semantic) but let's call it verification for now. (For more semantic checking, see David Musser's (of STL fame) recent work on provability algorithms.) Unit tests are also a form of verification. So there seems to be a possible avenue of research here - using concepts as unit tests, or merging the 2 ideas. I think the D language, with its inherent support for unit tests, and with its easy handling of compile-time code, might be a an interesting testbed for some of these ideas. Unit tests are also a form of documentation. Sometimes the only documentation, or at least the only accurate documentation - ie if the docs say that the sort function is a stable-sort, but the unit-tests don't test for 'stability' then I'd be wary as to whether the sort really is stable - maybe it once was, but via 'fixes' and 'optimizations' is no longer meeting its claims. And concepts are also a form of documentation. sort<RandomAccessContainer c, StrictWeakOrder comparitor>()... *documents* the requirements for the types necessary for sorting. And in general, we are always striving for 'self-documenting code'. (Again this would be a place to mention Knuth and his WEB language, which somewhat turns the code-document relationship on its head.) So they all seem to be interrelated. Makes me start to think that over time we might be able to merge them into something more powerful. I have no idea what that would end up looking like. As a start, maybe if the h file or interface of the class was - member functions, etc - which we have now - documentation - unit tests - concepts in some consistent language, we'd have more maintainable code... And importantly, they would need to be interrelated/merged enough that the documentation *could not!* get out of sync with the unit tests, which got out of sync with the concepts, which was out of sync with the member functions. ie if it is not consistent, it doesn't compile. The more merged those items are, the easier it would be to stay consistent. If I need to repeat that 'the comparison is a strict weak order' or 'the function leaves the container sorted' in the code, comments, unit tests, and concepts, then I'll go crazy (as I do now!). I'd rather say it once. Tony
I've also been thinking about similar relationships recently. Just a couple of comments...
The idea(s) is that concepts (ala C++) are a way to *verify* that the types passed in meet the necessary requirements.
Unit tests are also a form of verification. So there seems to be a possible avenue of research here - using concepts as unit tests, or merging the 2 ideas.
I disagree that concepts are a method of *verifying* anything. Concepts only *specify* constraints or abstractions. Verification is something that could be done by a program checker, theorem prover, or test suite. Some people want to aspects of verification into the compiler (e.g., Spec#), which turns out to have some nice benefits.
Unit tests are also a form of documentation.
No! Unit tests make terrible documentation. They're only incrementally better than reading the class body, and only then because they might demonstrate a particular order in which calls should be made or demonstrates the invariants, preconditions, or postconditions that can't be proven.
And concepts are also a form of documentation.
Only in as much as a class or function is "self-documenting".
So they all seem to be interrelated.
Sure, but I think the more interesting relationship is between proof and testing, and the elements of a language or program that enable either form (or both!) of reasoning about a program's correctness. Documentation somewhat of an orthogonal concern. To try to tie this back into the original post :) Scott's article is addressing the issue of improving verifiability through metaprogramming. Think of the it annotating a function call. Of course, you're still have to making claims about your program which need to be validated independently. If those claims are valid, then (theoretically), any function you call should also be valid under those stated assumptions. Very cool.
Andrew Sutton andrew.n.sutton@gmail.com
participants (7)
-
Alp Mestanogullari -
Andrew Sutton -
Gottlob Frege -
joel falcou -
Joel Falcou
-
Vicente Botet Escriba -
vicente.botet