This is the mail archive of the cygwin-patches@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

FW: [PATCH] Update 2 - Setup.exe property sheet patch


did not recognize, that Robert mailed twice - one private, one to the list

-----Original Message-----
From: Schaible, Jörg 
Sent: Monday, January 07, 2002 3:24 PM
To: 'Robert Collins'
Subject: RE: [PATCH] Update 2 - Setup.exe property sheet patch


Hi Robert,

unfortunately is this document not freely available and have to be purchased
from the ISO commitee, but I can cite here:

------------------- 10.3.2 ---------------
If a virtual member function "vf" is declared in a class "Base" and in a
derived class "Derived", derived directly or indirectly from "Base", a
member function "vf" with the same name and same parameter list as
"Base::vf" is declared, then "Dervived::vf" is also virtual (wether or not
so declared) and it overrides(97) "Base::vf". For conveniance we say that
any virtual function overrides itself. Then in any well-formed class, for
each virtual function declared in that class or any of its direct or
indirect base classes there is a unique "final overrider" that overrides
that function and every other overrider of that function. The rules for
member lookup (10.2) are used to determin the final overrider for a virtual
function in the scope of a derived class but ignoring names introduced by
"using-declaration"s. [Example:

struct A {
	virtual void f();
};
struct B : virtual A {
	virtual void f();
};

struct C : B , virtual A {
	using A::f;
}
void foo() {
	C c;
	c.f();	// calls "B::f", the final overrider
	c.C::f();	// calls "A::f" because of the using-declaration
-- end example]

97) A function with the same name but a different parameter list (clause 13)
as a virtual function is not necessarily virtual and does not override. The
use of the "virtual" specifier in the declaration of an overriding function
is legal but redundant (has empty semantics). Access control (clause 11) is
not considered in determining overriding.
------------------------------------

Regards,
Jörg

BTW: The address book entries are managed in a company wide Exchange server,
so no modification possible. It seems that you've setup your mail client to
accept "," as separator, while normally only ";" is accepted.



>-----Original Message-----
>From: Robert Collins [mailto:robert.collins@itdomain.com.au]
>Sent: Monday, January 07, 2002 2:47 PM
>To: Schaible, Jörg
>Subject: Fw: [PATCH] Update 2 - Setup.exe property sheet patch
>
>
>
>===
>----- Original Message -----
>From: "Robert Collins" <robert.collins@itdomain.com.au>
>To: <Schaible>; "Jörg" <Joerg.Schaible@gft.com>;
><cygwin-patches@sourceware.cygnus.com>
>Sent: Tuesday, January 08, 2002 12:46 AM
>Subject: Re: [PATCH] Update 2 - Setup.exe property sheet patch
>
>
>> I'm sorry Jorg, but I don't have the standard to reference. Do you
>know
>> of an on-line copy? (Googling for "c++ standard 10.3.2" gave me lots
>of
>> useless hits :})
>>
>> I got my info from the C++ FAQS second edition (Cline Lomow & Girou),
>> FAQ 33.09.
>>
>> Rob
>> ===
>> ----- Original Message -----
>> From: "Schaible, Jörg" <Joerg.Schaible@gft.com>
>> >My understanding is that this is not 100% the case. Or more
>> >pedantically - in a class derived from a a class with virtual
>> >functions,
>> >those virtual functions wil get overriden, but if not declared
>virtual
>> >themselves, any further derivations will not. I believe that the
>> >technique of doing this to allow inlining of code calling references
>to
>> >an object is called 'final classes'.
>>
>> Sorry, Gary is right. See 10.3.2 of the standard.
>>
>> Regards,
>> Jörg
>>
>>
>


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