On 9/27/2010 2:04 PM, Smith, Jacob N wrote:
On Monday, September 27, 2010 10:53 AM, Eric Niebler wrote:
On Sep 27, 2010, at 10:11 AM, Eric Niebler wrote:
On 9/27/2010 12:49 AM, David Abrahams wrote:
At Sun, 26 Sep 2010 22:31:54 -0400, Eric Niebler wrote:
>> No. rule::operator= expects SpiritParser to be a strongly-typed
> > Meaning? Spell it out and you have your requirements.
Meaning:
+ If the topmost node has tag-type "plus", there must be exactly one child node that models SpiritParser + If the topmost node has tag-type "shift_right", there must be exactly two child nodes that model SpiritParser, + If the topmost node has tag-type "subscript", there must be a left node that models SpiritParser and a right node that models PhoenixLambda, ... etc, etc, etc, ad nauseum <snip> How do I express that as a concept?
Summoning up my dim memory of proposed concept notation (so there are guaranteed nits to pick), that might translate into something like:
concept SpiritNode<typename Node, typename Tag> { }
template <class Node> concept_map SpiritNode<typename Node, plus> { requires SameType<Node::children,int_<1> >; typename child_t; requires SpiritParser<child_t>; child_t child; }
template <class Node> concept_map SpiritNode<typename Node, shift_right> { requires SameType<Node::children,int_<2> >; typename child1_t; requires SpiritParser<child1_t>; typename child2_t; requires SpiritParser<child2_t>;
child1_t child1; child2_t child2; }
template <class Node> concept_map SpiritNode<typename Node, subscript> { requires SameType<Node::children,int_<2> >; typename child1_t; requires SpiritParser<child1_t>; typename child2_t; requires PhoenixLambda<child2_t>;
child1_t child1; child2_t child2; }
concept RHSOfAssign<typename X> { typename tag_type; // Every RHSOfAssign has an associated tag_type requires SpiritNode<X, tag_type>; }
This isn't really how concepts were "meant to be used," though.
You haven't shown how the SpiritNode and SpiritParser concepts are related.
Of course not; you didn't say they were related. I just translated
On 9/27/2010 1:02 PM, David Abrahams wrote: tree. the constraints you wrote down into concepts-land.
You were the one who invented the SpiritNode concept, and then didn't tie it into the discussion! I described a recursive description of the SpiritParser concept and you showed one without any recursive property at all. :-P
There must be some recursive relationship, like "a SpiritParser is a SpiritNode<plus> /or/ a SpiritNode<right_shift> /or/ ..." It requires OR constraints
Do say that, you just use concept_maps to declare that SpiritNode<plus> models SpiritParser, etc.:
concept_map SpiritParser<SpiritNode<plus> > { // ... }
concept_map SpiritParser<SpiritNode<right_shift> > { // ... }
Not according to my reading of the standard. A concept_map is for mapping *types* to concepts, not *concepts* to concepts, as you appear to be doing here.
The grammar for a concept_map requires the thing after "concept_map" to be a concept-id, which may include a template-argument-list (as yours does). That consists of template-arguments which are constant-expression, type-id, or id-expression. I looked up each. None appear to allow concept-ids.
I can also find no examples in the standard of using concept maps to map one concept to another. Can you?
I ported parts of the BGL, GIL, MTL, and IETL to ConceptGCC. Then I set up a modeling relationship between the various concepts (in layers) to implement the Shi-Malik algorithm for image segmentation. I wrote up the results:
I can't access the pdf. Can you put it someplace we can read it? I'm not sure about MTL or IETL, but I know that BGL and GIL are generic libraries cut from the same cloth as STL: algorithms over homogeneous containers. I'm not sure the same techniques apply to heterogeneous composites like Proto trees.
Mapping concept-to-concept is part of the core ideas defined by Gregor & Stroustrup.
Then it seems curious that the standard didn't seem to allow it. -- Eric Niebler BoostPro Computing http://www.boostpro.com