假设的，以前的C ++ 0x概念问题 [英] Hypothetical, formerly-C++0x concepts questions
问题描述
（前导：我是C ++ 0x游戏的迟到追随者，最近有关从C ++ 0x标准中删除概念的争议激励我更多地了解它们。虽然我明白我的所有问题都是完全假设的 - 只要概念不会是有效的C ++代码在一段时间，如果有 - 我仍然有兴趣了解更多的概念，特别是如何将帮助
(Preamble: I am a late follower to the C++0x game and the recent controversy regarding the removal of concepts from the C++0x standard has motivated me to learn more about them. While I understand that all of my questions are completely hypothetical -- insofar as concepts won't be valid C++ code for some time to come, if at all -- I am still interested in learning more about concepts, especially given how it would help me understand more fully the merits behind the recent decision and the controversy that has followed)
在阅读了关于C ++ 0x（直到最近）的概念的一些介绍材料之后，他们，我有麻烦包装我的思想一些语法问题。下面是我的问题：
After having read some introductory material on concepts as C++0x (until recently) proposed them, I am having trouble wrapping my mind around some syntactical issues. Without further ado, here are my questions:
1）支持特定派生概念的类型（隐式地，通过auto关键字，或通过concept_maps显式）需要支持基本概念独立？换句话说，从另一个（例如概念B <类型名T>：A ）派生概念的动作隐含地包括不可见 B，需要A< T>; ）？混乱来自维基百科页面的概念，其中陈述：
1) Would a type that supports a particular derived concept (either implicitly, via the auto keyword, or explicitly via concept_maps) also need to support the base concept indepdendently? In other words, does the act of deriving a concept from another (e.g. concept B<typename T> : A<T>) implicitly include an 'invisible' requires statement (within B, requires A<T>;)? The confusion arises from the Wikipedia page on concepts which states:
类继承中，
类型满足派生的
概念也满足
的基本概念的要求。
Like in class inheritance, types that meet the requirements of the derived concept also meet the requirements of the base concept.
这似乎只说一种类型需要满足派生概念的要求，而不一定是基本概念的要求，这对我来说没有意义。我知道维基百科远不是一个明确的来源;是上面的描述只是一个很差的单词选择？
That seems to say that a type only needs to satisfy the derived concept's requirements and not necessarily the base concept's requirements, which makes no sense to me. I understand that Wikipedia is far from a definitive source; is the above description just a poor choice of words?
2）列出类型名的概念是auto吗？如果是这样，编译器如何自动映射这些类型名？
2) Can a concept which lists typenames be 'auto'? If so, how would the compiler map these typenames automatically? If not, are there any other occasions where it would be invalid to use 'auto' on a concept?
为了说明，请考虑以下假设代码：
To clarify, consider the following hypothetical code:
template<typename Type>
class Dummy {};
class Dummy2 { public: typedef int Type; };
auto concept SomeType<typename T>
{
typename Type;
}
template<typename T> requires SomeType<T>
void function(T t)
{}
int main()
{
function(Dummy<int>()); //would this match SomeType?
function(Dummy2()); //how about this?
return 0;
}
这些类中的任何一个是否匹配SomeType？或者是涉及typenames的概念所必需的concept_map？
Would either of those classes match SomeType? Or is a concept_map necessary for concepts involving typenames?
3）最后，我很难理解将允许定义什么公理。例如，我可以有一个概念定义逻辑上不一致的公理，例如
3) Finally, I'm having a hard time understanding what axioms would be allowed to define. For example, could I have a concept define an axiom which is logically inconsistent, such as
concept SomeConcept<typename T>
{
T operator*(T&, int);
axiom Inconsistency(T a)
{
a * 1 == a * 2;
}
}
这是否是有效的？
我明白这是一个很长的问题集，所以我提前感谢你。
I appreciate that this is a very long set of questions and so I thank you in advance.
推荐答案
I've used the most recent C++0x draft, N2914 (which still has concepts wording in it) as a reference for the following answer.
1）。这是一个非常简单的例子。概念就像接口一样。如果你的类型支持一个概念，它也应该支持所有的基本概念。如果知道 T 满足概念 Derived< T> ，那么从类型的客户端的角度来看， $ c>，则他还知道它满足概念 Base< T> 。从类型作者的角度来看，这自然意味着两者都必须实现。参见14.10.3 / 2。
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 T satisfies concept Derived<T>, then he also knows that it satisfies concept Base<T>. From type author perspective, this naturally means that both have to be implemented. See 14.10.3/2.
2）是的， typename 成员的概念可以是 auto 。如果这些成员在同一概念中的功能成员的定义中使用，则可以自动推导出这样的成员。例如，用于迭代器的 value_type 可以推导为其运算符* 的返回类型。但是，如果类型成员不在任何地方使用，则不会被推导出来，因此不会被隐式定义。在您的示例中，无法为 Dummy 或<$ c $>推导 SomeType< T> :: Type c> Dummy1 ，因为类型不被概念的其他成员使用，因此两个类都不会映射到概念，没有类可能可以自动映射到它）。参见14.10.1.2/11和14.10.2.2/4。
2) Yes, a concept with typename members can be auto. Such members can be automatically deduced if they are used in definitions of function members in the same concept. For example, value_type for iterator can be deduced as a return type of its operator*. 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 SomeType<T>::Type for either Dummy or Dummy1, as Type 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.
3）公理是规范的弱点，它们不断更新， ）意义。就在概念从草稿中提取之前，有一个论文
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 paper that changed quite a bit - read it and see if it makes more sense to you, or you still have questions regarding it.
对于你的具体例子（解释句法）差别），这意味着允许编译器考虑表达式（a * 1）与（a * 2），为了语言的as-if规则的目的（即，编译器允许进行它想要的任何优化，只要结果表现为，如同 ）。然而，编译器不以任何方式验证公理的正确性（因此为什么它们被称为公理！） - 它只是接受他们是什么。
For your specific example (accounting for syntactic difference), it would mean that compiler would be permitted to consider expression (a*1) to be the same as (a*2), 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 as if 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.
这篇关于假设的，以前的C ++ 0x概念问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
