Message ID | 4DCCC52B.5030101@e-tobi.net |
---|---|
State | New |
Headers |
Received: from mail.tu-berlin.de ([130.149.7.33]) by www.linuxtv.org with esmtp (Exim 4.69) (envelope-from <listaccount@e-tobi.net>) id 1QKlAb-0002ds-Bs for vdr@linuxtv.org; Fri, 13 May 2011 07:44:14 +0200 X-tubIT-Incoming-IP: 212.227.17.9 Received: from moutng.kundenserver.de ([212.227.17.9]) by mail.tu-berlin.de (exim-4.75/mailfrontend-2) with esmtp for <vdr@linuxtv.org> id 1QKlAa-0003vL-JJ; Fri, 13 May 2011 07:44:13 +0200 Received: from [192.168.30.37] (p4FD699CA.dip0.t-ipconnect.de [79.214.153.202]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0MQA9X-1QQ0Eh1DzX-005D13; Fri, 13 May 2011 07:44:12 +0200 Message-ID: <4DCCC52B.5030101@e-tobi.net> Date: Fri, 13 May 2011 07:44:11 +0200 From: Tobi <listaccount@e-tobi.net> User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110402 Icedove/3.1.9 MIME-Version: 1.0 To: vdr@linuxtv.org Content-Type: multipart/mixed; boundary="------------070808030601000401090805" X-Provags-ID: V02:K0:pOeG3U5wrYvT58Q3Ju4NO/xynuOe3ndA1X+hea5nMHC Xo0uUGnd/HtmTVGexOFa4d6BUwQwMk3thAI7fxX4vWIGDg1b+Q 1F9eu35YSNwvi/PuQZ8GQH7+03jFEO0uBpH30RrJcarrwQH7pg BnyUby1fUnWVNktgiHvlwltKnKR9T46F5kjmHR3MZRkNg5jDto W4sjQKX1S2MNnt9hgUsPA== X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.5.13.53317 X-PMX-Spam: Gauge=IIIIIIII, Probability=8%, Report=' FROM_NAME_ONE_WORD 0.05, MIME_TEXT_ONLY_MP_MIXED 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1900_1999 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, __ANY_URI 0, __BAT_BOUNDARY 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __CTYPE_MULTIPART_MIXED 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __MOZILLA_MSGID 0, __SANE_MSGID 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __URI_NO_PATH 0, __URI_NO_WWW 0, __URI_NS , __USER_AGENT 0' X-LSpam-Score: -5.1 (-----) X-LSpam-Report: No, score=-5.1 required=5.0 tests=AWL=1.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4 autolearn=ham Subject: [vdr] Small fix for GCC 4.6 issue X-BeenThere: vdr@linuxtv.org X-Mailman-Version: 2.1.11 Precedence: list Reply-To: VDR Mailing List <vdr@linuxtv.org> List-Id: VDR Mailing List <vdr.linuxtv.org> List-Unsubscribe: <http://www.linuxtv.org/cgi-bin/mailman/options/vdr>, <mailto:vdr-request@linuxtv.org?subject=unsubscribe> List-Archive: <http://www.linuxtv.org/pipermail/vdr> List-Post: <mailto:vdr@linuxtv.org> List-Help: <mailto:vdr-request@linuxtv.org?subject=help> List-Subscribe: <http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr>, <mailto:vdr-request@linuxtv.org?subject=subscribe> X-List-Received-Date: Fri, 13 May 2011 05:44:14 -0000 Status: O X-Status: X-Keywords: X-UID: 24733 |
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
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
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 ------------------------------------------------------------