language-lawyer

问题 The following program gives no error when compiling with clang: namespace X { struct i {}; } namespace Y { using X::i; struct i {}; } int main() {} Let's use int instead of struct, then we get: namespace X { int i; } namespace Y { using X::i; int i; } int main() {} This program gives a redefinition error when compiling with clang. The only difference between the programs is the kind of entity used (struct or int), but one compiles without errors and the other gives a redefinition error. Does

问题 N4527 5.20[expr.const]p2 A conditional-expression e is a core constant expression unless the evaluation of e, following the rules of the abstract machine (1.9), would evaluate one of the following expressions: (2.7) — an lvalue-to-rvalue conversion (4.1) unless it is applied to (2.7.1) — a non-volatile glvalue of integral or enumeration type that refers to a complete non-volatile const object with a preceding initialization, initialized with a constant expression, or (2.7.2) — a non-volatile

问题 According to the C++03 standard, is it valid to have references to incomplete types? I'm not aware of any implementation that implements references as any other than non-null pointers, so such code ought to work. However, I wonder whether references to incomplete types are standard conforming. I would appreciate answers with quotes and references to the C++ standard. 回答1: The C++ standard doesn't explicitly say, as far as I know, that you can have a reference to an incomplete type. But the

问题 When another member of a union is accessed, the C++ standard used to be silent on what happens, but that was fixed to explain that member access to a union object was allowed for the purpose of assigning to that yet no existent object, which would magically create the object, by assignment to it or one of its members. Essentially the member access operator returns a promise of a future object and you have to use it with an assignment. Given union U { int i; long l; }; We can create a i or l

问题 According to this stackoverflow answer about C++11/14 strict alias rules: If a program attempts to access the stored value of an object through a glvalue of other than one of the following types the behavior is undefined: the dynamic type of the object, a cv-qualified version of the dynamic type of the object, a type similar (as defined in 4.4) to the dynamic type of the object, a type that is the signed or unsigned type corresponding to the dynamic type of the object, a type that is the

问题 Compiling with Clang 3.0 -std=c++98, the following code is accepted: template<int> struct I { typedef int Type; }; template<class> struct S { static int f(int); //static int f(int*); // implicitly instantiates I<sizeof(int)> typedef I<sizeof(f(0))>::Type Type; }; S<int>::Type s; Uncommenting the overload of 'f' causes Clang to report an error "missing 'typename' prior to dependent type name". G++ 4.8 reports the same error with or without the overload. msvc10 does not give any errors with or

问题 I'm looking through n3690 , a draft of the upcoming C++14 standard, and I see in section 7.2 paragraph 9 : Two enumeration types are layout-compatible if they have the same underlying type. However, I can't find anything that says an enumeration type is layout-compatible with its underlying type. To me it seems obvious that this should follow given the reasonable semantics for what "underlying type" means, but is it actually guaranteed by the standard? 回答1: NO, there is no black-letter quote

问题 In the c++ standard, in [basic.lval]/11.6 says: If a program attempts to access the stored value of an object through a glvalue of other than one of the following types the behavior is undefined:[...] an aggregate or union type that includes one of the aforementioned types among its elements or non-static data members (including, recursively, an element or non-static data member of a subaggregate or contained union),[...] This sentence is part of the strict-aliasing rule. Can it allow us to

问题 Consider the follow code, which arose from this question: const int (*foo(const char *a))[1] { return (const int (*)[1]) a; } When compiled with GCC 8.2 (and older versions) using -Wcast-qual, GCC warns: source>:2:15: warning: cast discards 'const' qualifier from pointer target type [-Wcast-qual] { return (const int (*)[1]) a; } ^ Is this warning correct? Clearly the destination type has a const qualifier in it. It is on the element type rather than on the thing immediately pointed to by the

问题 Does the standard guarantee that std::less<MyEnumType> will order MyEnumType as if a value of MyEnumType was cast to an appropriately sized integer type? enum MyEnumType { E1 = 0, E2 = 6, E3 = 3 }; 回答1: Yes, std::less::operator() is defined as (§20.8.5/5): operator() returns x < y For using relational operators on enumeration types, the following is stated (§5.9/2): The usual arithmetic conversions are performed on operands of arithmetic or enumeration type. For unscoped enumeration types,