Some compilers, notably GCC, allow the character ‘$’ to be a constituent of identifiers in the languages C, C++, and Objective C. CC Mode defaults to accepting these ‘$’ characters and fontifying the identifiers in which they appear like any others.
However, the compiler you’re using, or your project coding standards
may disallow such use. In such cases, you can set
c-warn-ids-with-dollar to non-nil. This causes these
invalid identifiers to be fontified distinctively.
When this customization option is non-nil, identifiers
containing the ‘$’ character are fontified with
font-lock-warning-face.
In some languages, particularly in C++, there are constructs which are syntactically ambiguous—they could be either declarations or expressions, and CC Mode cannot tell for sure which. Often such a construct is one of the operators ‘*’ or ‘&’ surrounded by two identifiers.
Experience shows that very often when such a construct is a declaration it will be written with the operator touching exactly one of the identifiers, like:
foo *bar
or
foo& bar
. Whether such code is fontified depends on the setting of
c-asymmetry-fontification-flag.
When c-asymmetry-fontification-flag is non-nil (which it is by
default), code like the above, with white space either before or after
the operator, but not both, is fontified as a declaration. When the
variable is nil, such a construct gets the default face.
When the construct is an expression there will often be white space both before and after the operator or there will be no white space around it at all, like:
foo * bar
or
foo&bar
.
Such code is not fontified as a declaration. (Typically, the identifiers don’t get a non-default face.)
For clarity’s sake, we emphasize that the “asymmetry” rule in this section only applies when CC Mode cannot disambiguate a construct in any other way.