Re: [vdr] Small fix for GCC 4.6 issue
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
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Small fix for GCC 4.6 issue
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
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Small fix for GCC 4.6 issue
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
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Small fix for GCC 4.6 issue
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
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
