Re: CC-mode highlight change between 24.5 and 25

[Alan Mackenzie <acm@muc.de>]

Hello, Yuri.

On Fri, Sep 02, 2016 at 08:10:33PM +0600, Yuri Khan wrote:
> On Fri, Sep 2, 2016 at 8:27 PM, Alan Mackenzie <acm@muc.de> 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.

I feared as much.  I've often wondered why the C++ language developers
have had such a low regard for unambiguous syntax, such as most other
(computer) languages have.  I've cursed them for it on more than one
occasion.

> 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++.

In other words, only semantics determine that the line 4 is a variable
declaration rather than a function declaration.  CC Mode doesn't do
semantics, except to a _very_ limited degree.  So we're reduced, yet
again, to difficult and unreliable heuristics.  Curse the C++ language
developers!

-- 
Alan Mackenzie (Nuremberg, Germany).