gcc once again became a little bit more strict about the C++ standard, so the skincurses plugin will not compile anymore.
8.5/9 of the C++ standard says
"If no initializer is specified for an object, and the object is of (possibly cv-qualified) nonPOD class type (or array thereof), the object shall be default-initialized; if the object is of const-qualified type, the underlying class type shall have a user-declared default constructor.
Otherwise, if no initializer is specified for an object, the object and its sub-objects, if any, have an indeterminate initial value; if the object or any of its sub-objects are of const-qualified type, the program is ill-formed."
Adding an initializer solves this issue. Please see the attached patch.
Thx,
Tobias
Am 13.05.2011 07:44, schrieb Tobi:
8.5/9 of the C++ standard says
"If no initializer is specified for an object, and the object is of (possibly cv-qualified) nonPOD class type (or array thereof), the object shall be default-initialized; if the object is of const-qualified type, the underlying class type shall have a user-declared default constructor.
Interestingly irritating... Since I don't have an GCC4.6 at hand, I *think* the source of the problem might be that cCursesFont has just an default constructor. So it should also work if you add an empty constructor cCursesFont::cCursesFont() { } ???
I thought such an empty constructor would always behave the same as the default constructor...
Does anyone know the background why the standard doesn't just use the default constructor for const objects?
Cheers,
Udo
On 13.05.2011 23:47, Udo Richter wrote:
Am 13.05.2011 07:44, schrieb Tobi:
Interestingly irritating... Since I don't have an GCC4.6 at hand, I *think* the source of the problem might be that cCursesFont has just an default constructor.
Right. The C++ standard explicitly requires an "user-declared default constructor" here.
So it should also work if you add an empty constructor cCursesFont::cCursesFont() { } ???
Yes. Either this or -fpermissive. But personally I prefer the initializer here, but I must admit I don't understand the technical reason, why the standard requires a user defined default constructor at all.
Tobias
On 14.05.2011 13:06, Tobi wrote:
On 13.05.2011 23:47, Udo Richter wrote:
Am 13.05.2011 07:44, schrieb Tobi:
Interestingly irritating... Since I don't have an GCC4.6 at hand, I *think* the source of the problem might be that cCursesFont has just an default constructor.
Right. The C++ standard explicitly requires an "user-declared default constructor" here.
So it should also work if you add an empty constructor cCursesFont::cCursesFont() { } ???
Yes. Either this or -fpermissive. But personally I prefer the initializer here, but I must admit I don't understand the technical reason, why the standard requires a user defined default constructor at all.
I also have to admit that I don't understand what difference this makes. Apparently the program works, so the initialization must be taking place, even without explicitly calling cCursesFont().
At any rate, I've adopted the patch.
Klaus
Am 15.05.2011 23:45, schrieb Klaus Schmidinger:
On 14.05.2011 13:06, Tobi wrote:
Right. The C++ standard explicitly requires an "user-declared default constructor" here.
So it should also work if you add an empty constructor cCursesFont::cCursesFont() { } ???
Yes. Either this or -fpermissive. But personally I prefer the initializer here, but I must admit I don't understand the technical reason, why the standard requires a user defined default constructor at all.
I also have to admit that I don't understand what difference this makes. Apparently the program works, so the initialization must be taking place, even without explicitly calling cCursesFont().
What makes this even more strange to me is the fact, that
static const cCursesFont Font;
requires an user-declared default constructor, while
static const cCursesFont Font = cCursesFont();
creates an temporary non-const cCursesFont object, and then uses the implicitly declared copy constructor to create the final Font object. So why is the implicitly declared default constructor forbidden, and the implicitly declared copy constructor ok?
You'll really need an lawyer when it comes to standards specifications...
Cheers,
Udo