This is the mail archive of the
mailing list for the GCC project.
RE: behavior of egcs?
- To: "'Thomas Handler'" <th at umundum dot vol dot at>
- Subject: RE: behavior of egcs?
- From: Kaz Kylheku <kaz at cafe dot net>
- Date: Fri, 20 Mar 1998 13:10:28 -0800
- Cc: "'egcs-bugs at cygnus dot com'" <egcs-bugs at cygnus dot com>
On Friday, March 20, 1998 8:13 AM, Thomas Handler [SMTP:firstname.lastname@example.org]
> I'm working with gcc 2.7.3 at the moment and some things don't work as
> expected. Now I'm wondering if egcs has the same behavior or if not.
Why don't you download it and try it? When you have an actual EGCS bug
report, then write to egcs-bugs. Show some spirit and plunge right in!
> Example 1:
> calling virtual member functions in the constructor doesn't seem to work
> (I couldn't find a definition wether the output of my compiler is wrong
> or not - I suppose it's wrong):
> in A's constructor i=2
> in class A vmethod called with i=2 <=== **** so what's that ?
> in B's constructor i=2
The class B is derived from class A.
In order to construct a B object, the ``embedded'' A parts have
to be constructed first, which means that the constructor for
A is executed. The constructor for A calls a virtual function;
it is resolved to the virtual function within the A class, not
in the derived class. This is proper C++ behavior; at the
time of the A constructor call, the B portions have not yet
See clause 12.7 of the Dec 1996 Draft, paragraph 3:
Member functions, including virtual functions (10.3)
can be called during construction or destruction (12.6.2).
When a virtual function is called directly or indirectly from
a constructor (including one from the mem-initializer for a
data member) or from a destructor, and the object to
which the call applies is the object under construction or
destruction, the function called is the one defined in the
constructor or destructor's own class or in one of its bases,
but not a function overriding it in a class derived from the
constructor or destructor's class, or overriding it
in one of the other base classes of the most derived
This rule makes a lot of common sense. You are constructing
an object of known type A, so the virtual function should be bound
to that type.
> Example 2:
> Occuring exceptions while creating objects via new in free store give
> memory leaks (section 14.4.4 Stroustrup C++ programming language 3rd ed.
> seems to define this as I would have expected).
Yes, so does 15.2 in the Dec 1996 C++ Draft Standard: ``If the object or array
was allocated in a new-expression and the new-expression does not
contain a new-placement, the deallocation function (126.96.36.199, 12.5) is
called to free the storage occupied by the object; the deallocation function
is chosen as specified in 5.3.4. ''