Error: anachronistic initializer of an old-style base class

Question

The following code generates the following compilation error for all versions of GCC that I tried in C ++ 98, C ++ 11, and C ++ 14 modes:

struct T { T(void* x) : (x) {} }; // main.cpp: In constructor 'T::T(void*)': // main.cpp:3:18: error: anachronistic old-style base class initializer [-fpermissive] // T(void* x) : (x) {} // ^ // main.cpp:3:16: error: unnamed initializer for 'T', which has no base classes // T(void* x) : (x) {} 

Of course, this is clearly broken code, because I'm not really initializing anything.

But why is it the initializer of the base class and why is it “anachronistic” and not just wrong? Was it ever true? When? And what does it mean?

---

only rel ated links I found to this on the Internet there were people who encountered an error when the participant name was accidentally displayed by a macro, which ultimately led to the same code as above:

 #define bar // ^ some library could have done this struct T { T(int x) : bar(x) // effectively just `: (x)` {} int bar; // will cause its own error }; 

These people never knew what a mistake was, although they later at least discovered why their program was broken.

Answer 1

Found in the documentation for the release of CFSS 1984-5, the first C ++ compiler:

The constructor can be written like this:

  vec.vec(int lb, int hb) : (hb-lb+1) { if (hb-lb<0) hb * lb low = lb; high = hb; } 

Construction: (hb-lb + 1) is used to specify a list of arguments needed for the constructor vector of the base class ().

It makes sense if you think about it. Presumably, an explicit base class name assignment has been added to support multiple inheritance.

Confirm http://www.softwarepreservation.org/projects/c_plus_plus/ for archiving documents.

... and wow, I just realized that "CFront" is a pun.

Answer 2

Indeed, this is an invalid C ++ standard, so we must look at the annals of the history of languages ​​to find the point at which it became invalid.

In 1989, when the further definition of “C ++” since its initial creation under this name in 1985, Stroustrup announced that basic initialization had changed from the language of previous incarnations to deal with multiple inheritance: [1]

[p191] The C ++ Programming Language [Stroustrup 1986] describes C ++ as defined and implemented in August 1985. This article describes the growth of the language since then and clarifies several points in the definition. It is emphasized that these language modifications are extensions; C ++ has been and will remain a stable language, suitable for the long-term development of software. The main new features of C ++: multiple inheritance , type-secure communication, better resolution of overloaded functions, recursive definition of assignment and initialization, best features for user memory management, abstract classes, static member of a function, constant functions, protected members, operator overloading -> and pointers to members. These functions are introduced in version 2.0 in C ++.

[p214] The syntax for initializing base classes and members has been extended to deal with multiple inheritance, and the initialization order has been more precisely defined. [..]

This text demonstrates the base class initialization syntax that we are currently familiar with, and as Sneftel already pointed out (saving me the trouble of finding older documents!), This did not happen back in 1985, in the original C ++ implementation , which itself evolved from "C with classes." So, we can conclude that C ++ 2.0 introduced the more familiar syntax in 1989, and this “anachronistic” version was valid until then.

Note, of course, that there is no base in the interrogation code. Thus, even in C ++ 1.0, a program would ultimately not be successfully compiled. However, we found out why the syntax is parsed this way.

Remarkably, GCC diagnoses an obscure, long-forgotten syntax that has not been valid in any C ++ incarnation for nearly thirty years.

---

[1] "The evolution of C ++: from 1985 to 1989," Bjarne Stroustrup, AT & T Bell Laboratories 1989; pdf

Answer 3

This has been specifically described in ARM, section 18.3.2, as an anachronism.

The reason for such functions was, as a rule, to ensure continuity for older versions of C ++ or C with classes. All "anachronisms" had undesirable characteristics. Compilers are not required to provide such functions, but if they did, they were required to allow the programmer to deactivate it and / or be warned about using it.