Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>I've used the most recent C++0x draft, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2914.pdf" rel="noreferrer">N2914</a> (which still has concepts wording in it) as a reference for the following answer.</p> <p>1) Concepts are like interfaces in that. If your type supports a concept, it should also support all "base" concepts. Wikipedia statement you quote makes sense from the point of view of a type's client - if he knows that <code>T</code> satisfies concept <code>Derived&lt;T&gt;</code>, then he also knows that it satisfies concept <code>Base&lt;T&gt;</code>. From type author perspective, this naturally means that both have to be implemented. See 14.10.3/2.</p> <p>2) Yes, a concept with <code>typename</code> members can be <code>auto</code>. Such members can be automatically deduced if they are used in definitions of function members in the same concept. For example, <code>value_type</code> for iterator can be deduced as a return type of its <code>operator*</code>. However, if a type member is not used anywhere, it will not be deduced, and thus will not be implicitly defined. In your example, there's no way to deduce <code>SomeType&lt;T&gt;::Type</code> for either <code>Dummy</code> or <code>Dummy1</code>, as <code>Type</code> isn't used by other members of the concept, so neither class will map to the concept (and, in fact, no class could possibly auto-map to it). See 14.10.1.2/11 and 14.10.2.2/4.</p> <p>3) Axioms were a weak point of the spec, and they were being constantly updated to make some (more) sense. Just before concepts were pulled from the draft, there was a <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2887.pdf" rel="noreferrer">paper</a> that changed quite a bit - read it and see if it makes more sense to you, or you still have questions regarding it.</p> <p>For your specific example (accounting for syntactic difference), it would mean that compiler would be permitted to consider expression <code>(a*1)</code> to be the same as <code>(a*2)</code>, for the purpose of the "as-if" rule of the language (i.e. the compiler permitted to do any optimizations it wants, so long as the result behaves <em>as if</em> there were none). However, the compiler is not in any way required to validate the correctness of axioms (hence why they're called axioms!) - it just takes them for what they are.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload