diff mbox

Small fix for GCC 4.6 issue

Message ID 4DCCC52B.5030101@e-tobi.net
State New
Headers

Commit Message

Tobias Grimm May 13, 2011, 5:44 a.m. UTC 
  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
#! /bin/sh /usr/share/dpatch/dpatch-run
## 99_gcc4.6-fix.dpatch by Tobias Grimm <tg@e-tobi.net>
##
## All lines beginning with `## DP:' are a description of the patch.
## DP: Fixes gcc 4.6 issue - const needs custom default ctor or initializer
## DP: See C++ standard 8.5/9

@DPATCH@

Comments

Udo Richter May 13, 2011, 9:47 p.m. UTC | #1 
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
Tobias Grimm May 14, 2011, 11:06 a.m. UTC | #2 
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
Klaus Schmidinger May 15, 2011, 9:45 p.m. UTC | #3 
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
Udo Richter May 15, 2011, 11:13 p.m. UTC | #4 
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
diff mbox

Patch

diff --git a/PLUGINS/src/skincurses/skincurses.c b/PLUGINS/src/skincurses/skincurses.c
index 84076cd..debc8f7 100644
--- a/PLUGINS/src/skincurses/skincurses.c
+++ b/PLUGINS/src/skincurses/skincurses.c
@@ -26,7 +26,7 @@  public:
   virtual void DrawText(cPixmap *Pixmap, int x, int y, const char *s, tColor ColorFg, tColor ColorBg, int Width) const {}
   };
 
-static const cCursesFont Font;
+static const cCursesFont Font = cCursesFont();
 
 // --- cCursesOsd ------------------------------------------------------------