Re: CC-mode highlight change between 24.5 and 25

[Yuri Khan]

On Fri, Sep 2, 2016 at 8:27 PM, Alan Mackenzie <address@hidden> wrote:

>> 4      std::ofstream fout (file_name);

> The trouble is that L4 looks _exactly_ like a function declaration, the
> function `fout' returning something of type `std::ofstream', and taking
> a single parameter of type `file_name'.

> Can you help me out here, please - by what criterion is the C++ compiler
> deciding that `fout' is a variable initialised to `file_name' rather
> than a function declaration?

There is no such criterion in the syntax alone.

The more famous version of this ambiguity is called “C++’s most vexing
parse”. Lifting an example from Scott Meyers, Effective STL, chapter 1
Item 6:

    list<int> data(istream_iterator<int>(dataFile),  // warning! this doesn't do
                   istream_iterator<int>());         // what you think it does

This looks like initialization of a variable “data” of type
“list<int>” with a pair of iterators which are constructed on the
spot, but it can alternatively be parsed as a declaration of a
function named “data” that returns a list<int> and accepts two
arguments, the first of which is named “dataFile” and has type
“istream_iterator<int>”, and the second of which is unnamed and has
type “function of no arguments returning istream_iterator<int>”.

The C++ syntax requires the compiler to resolve the ambiguity in favor
of a declaration.

The canonical workaround is to add parentheses around arguments so
that they no longer fit the syntax of a function argument:

    list<int> data((istream_iterator<int>(dataFile)),
                   istream_iterator<int>());

In the original “fout” example, the ambiguity does not arise because
the compiler knows “file_name” to be a value, not a type, and because
there is no implicit int in C++.