15 obscure features of C ++ (1)

This list collects some Obscure features of the C ++ language. It is collected from various aspects of the language I have been studying for years. C ++ is very large and I can always learn some new knowledge. Even if you are familiar with C ++, I hope you can learn something from the list. The features listed below are sorted in a descending order based on the obscure degree.

• 1. true meanings of square brackets
• 2. the most annoying Parsing
• 3. Replace operator tags
• 4. Redefinition of keywords
• 5. Placement new
• 6. branch while declaring Variables
• 7. Reference modifier of member functions
• 8. Turn to complete template metaprogramming
• 9. pointer operators pointing to members
• 10. Static instance method
• 11. Heavy Load ++ and-
• 12. Operator Overloading and Check order
• 13. functions as template parameters
• 14. The template parameters are also templates
• 15. try block as Function

True Meaning of square brackets

Ptr [3], which is used to access array elements, is only the abbreviation of * (ptr + 3). It is equivalent to * (3 + ptr, therefore, it is equivalent to 3 [ptr]. Using 3 [ptr] is a fully valid code.

The most annoying Parsing

The term "most vexing parse" was proposed by Scott Meyers because the ambiguity of the C ++ syntax statement can lead to unreasonable behavior:

 
 

  
  
// Is the explanation correct?
  
  
// 1) Will variables of the std: string type be instantiated through std: string?
  
  
// 2) a function declaration returns a std: string value with a function pointer parameter,
  
  
// This function also returns a std: string but no parameter?
  
  
Std: string foo (std: string ());
  
  

  
  
// Or is this correct?
  
  
// 1) Will int type variables be instantiated through int (x?
  
  
// 2) a function declaration returns an int value with a parameter,
  
  
// Is this parameter an int variable named x?
  
  
Int bar (int (x ));
 
 

In both cases, the C ++ standard requires the second interpretation, even if the first interpretation looks more intuitive. Programmers can eliminate ambiguity by enclose the initial values of variables in parentheses:

 
 

  
  
// Remove ambiguity with parentheses
  
  
Std: string foo (std: string ()));
  
  
Int bar (int (x )));
 
 

In the second case, int y = 3 is equivalent to int (y) = 3;

Note: I am confused about this. below is my test case under g ++:

 
 

  
  
# Include <iostream>
  
  
# Include <string>
  
  
Using namespace std;
  
  

  
  
Int bar (int (x); // equivalent to int bar (int x)
  
  

  
  
String foo (string (); // equivalent to string foo (string (*)())
  
  

  
  
String test (){
  
  
Return "test ";
  
  
}
  
  

  
  
Int main ()
  
  
{
  
  
Cout <bar (2) <endl; // output 2
  
  
Cout <foo (test); // output test
  
  
Return 0;
  
  
}
  
  

  
  
Int bar (int (x )){
  
  
Return x;
  
  
}
  
  

  
  
String foo (string (* fun )()){
  
  
Return (* fun )();
  
  
}
 
 

Correct output, but if you add brackets as intended by the author before compilation, a bunch of errors will be reported: "Not declared in this scope", "redefinition", etc, the author's intention is unclear.

Replacement Operator

Tag and, and_eq, bitand, bitor, compl, not, not_eq, or, or_eq, xor, xor_eq, <%, %>, <: and:> can be used to replace our commonly used &, & =, &, | ,~, !, ! =, |, | =, ^, ^ =, {,}, [And]. You can use these operation tags instead of when there are no necessary symbols on the keyboard.

Redefinition of keywords

Technically, redefinition of keywords by the Preprocessor may cause errors, but this is actually allowed. Therefore, you can use a prank like # define true false or # define else. However, when it is valid and useful, for example, if you are using a large library and need to bypass the C ++ access protection mechanism, in addition to patching the library, you can also disable access protection before including the Library header file, but remember to enable the protection mechanism after including the Library header file!

 
 

  
  
#define class struct 
  
  
#define private public 
  
  
#define protected public 
  
  
  
  
  
#include "library.h" 
  
  
  
  
  
#undef class 
  
  
#undef private 
  
  
#undef protected 
 
 

Note that this method is not effective every time and is related to your compiler. When the instance variables are not modified by access controllers, C ++ only needs to arrange these instance variables in sequence. Therefore, the compiler can sort the access controllers to change the memory layout freely. For example, allow the compiler to move all private members to the end of a Public member. Another potential problem is name rename mangling. Microsoft's C ++ compiler combines access controllers into their name mangling tables, therefore, changing the access control operator means that the compatibility of the existing compiled code will be compromised.

Note: In C ++, Name Mangling is a technology added to support overloading. The compiler adjusts the name of the target source file. In this way, the name used in the symbolic table of the target file and the name used in the connection process is different from that in the source program of the compiled target file, thus implementing overloading.