This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

RE: behavior of egcs?


On Friday, March 20, 1998 8:13 AM, Thomas Handler [SMTP:th@umundum.vol.at] 
wrote:
> Hi!
>
> 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
been constructed.

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
	object (1.7)

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 (3.7.3.2, 12.5) is
called to free the storage occupied by the object; the deallocation function
is chosen as specified in 5.3.4. ''



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]