RE: pure virtual w/implementation bug in GCC 3.3?

RE: pure virtual w/implementation bug in GCC 3.3?

[lrtaylor]

Without actually looking at the standard, isn't a pure virtual function with an implementation simply a contradiction?  The fact that there is no implementation is what makes it "pure".  Otherwise, it's just a regular virtual function.  It doesn't make sense to try to say something is both pure virtual and that it has a definition.  That's just self contradictory...

Thanks,
Lyle Taylor

-----Original Message-----
From: Eljay Love-Jensen [mailto:eljay@adobe.com]
Sent: Thursday, September 18, 2003 1:38 PM
To: gcc-help@gcc.gnu.org
Subject: pure virtual w/implementation bug in GCC 3.3?

Hi everyone,

Using GCC 3.3 or GCC 3.2, it appears unable to digest this code:

--------8<--------
class Foo
{
public:
        virtual ~Foo() = 0 { }
};
--------8<--------

> g++33 -c foo.cpp
foo.cpp:4: error: parse error before `{' token
foo.cpp:4: error: missing ';' before right brace

Pure virtual functions can have implementations.  Pure virtual destructors (if I recall correctly) MUST have implementations.

And if the implementation is defined later with GCC 3.2 or 3.3 -- either as inline or not as inline ("out of line"?) -- it digests it with out an issue.

As per Stroustrup's C++PL, the EBNF grammar looks like it should and does support the syntax given above.  (The "implicit inline" of a method given in the class declaration.)

Is this a known bug in GCC?

Or is this a new bug in GCC?

Or am I misinformed?

Thanks,
--Eljay

RE: pure virtual w/implementation bug in GCC 3.3?

[Eljay Love-Jensen]

Hi Lyle,

>Without actually looking at the standard, isn't a pure virtual function with an implementation simply a contradiction?

No, it's not really the contradiction that it first appears.

The compiler enforces that all derived classes implement the pure virtual function (or become marked as "abstract" themselves).

A pure virtual function can have an imlpementation in that base class, such that derived classes could do a "using basefunc;" to explicitly utilize the base classes behavior implemented in the pure virtual basefunc method.

I grant you, it is a bit unusual.  When I run across one, I tend to do a double take.  But just like have a "const volatile", there are appropriate situations for pure virtuals with implementations.

*grin*
--Eljay

Re: pure virtual w/implementation bug in GCC 3.3?

[m.]

How about this (taken from the standard 10.4 Abstract classes [class.abstract]):

[Note: a function declaration cannot provide both a pure-specifier and a definition ---end note] [Example:

struct C {
          virtual void f() { }=0;                 // ill-formed
};

---end example]

m.

On Thu, 18 Sep 2003 14:52:45 -0500
Eljay Love-Jensen <eljay@adobe.com> wrote:

>Hi Lyle,
>
>>Without actually looking at the standard, isn't a pure virtual function with an implementation simply a contradiction?
>
>No, it's not really the contradiction that it first appears.
>
>The compiler enforces that all derived classes implement the pure virtual function (or become marked as "abstract" themselves).
>
>A pure virtual function can have an imlpementation in that base class, such that derived classes could do a "using basefunc;" to explicitly utilize the base classes behavior implemented in the pure virtual basefunc method.
>
>I grant you, it is a bit unusual.  When I run across one, I tend to do a double take.  But just like have a "const volatile", there are appropriate situations for pure virtuals with implementations.
>
>*grin*
>--Eljay
>
>
>

Re: pure virtual w/implementation bug in GCC 3.3?

[Eljay Love-Jensen]

Hi m,

Thank you for the clarification.  :-)

10.4 paragraph 2 clearly shows that the construct is illegal.

I'll use the sanctioned form:
class Foo { public: virtual ~Foo() = 0; };
inline Foo::~Foo() { }

Sincerely,
--Eljay

RE: pure virtual w/implementation bug in GCC 3.3?

[lrtaylor]

I was under the impression that virtual functions could not be inlined (seems I read that somewhere), because, especially in the case of polymorphism, which function to call cannot be determined at compile time.  I can see cases where the compiler _would_ know that it could be inlined, though.  It just seemed that that was a matter of policy in the standard.  Is my impression incorrect?

Thanks,
Lyle Taylor

-----Original Message-----
From: Eljay Love-Jensen [mailto:eljay@adobe.com]
Sent: Friday, September 19, 2003 11:33 AM
To: m.; gcc-help@gcc.gnu.org
Subject: Re: pure virtual w/implementation bug in GCC 3.3?

Hi m,

Thank you for the clarification.  :-)

10.4 paragraph 2 clearly shows that the construct is illegal.

I'll use the sanctioned form:
class Foo { public: virtual ~Foo() = 0; };
inline Foo::~Foo() { }

Sincerely,
--Eljay

RE: pure virtual w/implementation bug in GCC 3.3?

[Eljay Love-Jensen]

Hi Lyle,

Note:  we're getting off topic for the subject of this thread of conversation.  If we continue, we should probably change the subject line.

Virtual functions can be inlined.

Some old compilers had problems with inlined virtual functions.  I think those days are ancient history.

There is an issue with some compilers when ALL virtual functions are inlined.

The reason why is because many compilers use the strategy of generating the virtual function pointer table when it sees the first non-inlined function generated -- the "blessed" non-inline virtual function..

Since the "blessed" non-inlined function is (usually) only generated ONCE, in some module (or compilation unit), this strategy is normally a good way to assure that there isn't wasted space with loads of virtual function pointer tables being generated helter-skelter.

If all virtual functions are inlined, then there is no "first non-inlined virtual function" which to "bless".

One strategy for this situation is to generate virtual function pointer tables in all modules (compilation units), and then trust the linker to weed out duplicates.  I think this is the strategy used by GCC for C++ programs.

Another (bad!) strategy is to not generate any virtual function pointer table at all.  My old DEC C++ compiler did this.  Very annoying.  The workaround was simple: generate a "do nothing" private virtual function that wasn't inline.  But still a kluge.

I don't think any modern C++ compiler follows the "punish the prorammer for valid code" strategy these days.

There can also be an issue when using member function pointers when the function is inlined.  GCC assists in that unfortunate (and relatively uncommon) situation with the -fkeep-inline-functions flag.

Sincerely,
--Eljay

pure virtual w/implementation bug in GCC 3.3?

[Eljay Love-Jensen]

Hi everyone,

Using GCC 3.3 or GCC 3.2, it appears unable to digest this code:

--------8<--------
class Foo
{
public:
        virtual ~Foo() = 0 { }
};
--------8<--------

> g++33 -c foo.cpp
foo.cpp:4: error: parse error before `{' token
foo.cpp:4: error: missing ';' before right brace

Pure virtual functions can have implementations.  Pure virtual destructors (if I recall correctly) MUST have implementations.

And if the implementation is defined later with GCC 3.2 or 3.3 -- either as inline or not as inline ("out of line"?) -- it digests it with out an issue.

As per Stroustrup's C++PL, the EBNF grammar looks like it should and does support the syntax given above.  (The "implicit inline" of a method given in the class declaration.)

Is this a known bug in GCC?

Or is this a new bug in GCC?

Or am I misinformed?

Thanks,
--Eljay