Calling constructors using parentheses may result in unwelcome
surprises. Assume the following class interface is available:
        verb(    class Data
    {
        public:
            Data();
            Data(int one);
            Data(int one, int two);

            void display();
    };)

The intention is to define two objects of the class Data, using, respectively,
the first and second constructors, while using parentheses in the object
definitions. Your code looks like this (and, ignoring the 'not used' warnings,
compiles correctly):
        verb(    #include "data.h"
    int main()
    {
        Data d1();
        Data d2(argc);
    })

Let's get rid of the 'not used' warnings by adding two statements to tt(main):
            verb(        d1.display();
        d2.display();)

But, surprise, the compiler complains about the first of these two:

em(error: request for member 'display' in 'd1', which is of non-class type
'Data()')

What's going on here? First of all, notice the data type the compiler refers
to: tt(Data()), rather than tt(Data). What are those tt(()) doing there?

Before answering that question, let's broaden our story somewhat. We know that
somewhere in a library a emi(factory function) tt(dataFactory) exists. A
factory function creates and returns an object of a certain type. This
tt(dataFactory) function returns a tt(Data) object, constructed using
tt(Data)'s default constructor. Hence, tt(dataFactory) needs no arguments. We
want to use tt(dataFactory) in our program, but must declare the function. So
we add the declaration to tt(main), as that's the only location where
tt(dataFactory) will be used. It's a function, not requiring arguments,
returning a tt(Data) object:
            verb(        Data dataFactory();)

This, however, looks remarkably similar to our tt(d1) object definition:
            verb(        Data d1();)

Here we found the solution of our problem: tt(Data d1()) apparently is em(not)
the definition of a tt(d1) object, but the em(declaration) of a function,
returning a tt(Data) object. So, what's happening here and how should we
define a tt(Data) object using tt(Data)'s default constructor?

    First: what's happening here is that the compiler, when confronted with
tt(Data d1()), actually had a choice. It could either define a tt(Data)
object, or declare a function. It declares a function. 

Here we're encountering an i(ambiguity) in bf(C++)'s grammar which is solved,
according to the language's standard, by always letting a declaration prevail
over a definition. We'll encounter more situations where this ambiguity occurs
later on in this section.

    Second: there are several ways we can solve this ambiguity in the way we
want it to be solved. To define an object using its default constructor:
    itemization(
    it() merely mention it (like tt(int x)): tt(Data d1);
    it() use the curly brace initialization: tt(Data d1{});
    it() use the assignment operator and an anonymous default constructed
        tt(Data) object: tt(Data d1 = Data{}), or possibly tt(Data d1 =
        Data()). 
    )
