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:[EMAIL PROTECTED]]
>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" <[EMAIL PROTECTED]>
>To: ; "Jörg" <[EMAIL PROTECTED]>;
><[EMAIL PROTECTED]>
>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" <[EMAIL PROTECTED]>
>> >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
>>
>>
>
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" <[EMAIL PROTECTED]> >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
RE: [PATCH] Update 2 - Setup.exe property sheet patch
Hi Robert, >> "Once virtual, always virtual", i.e., it isn't necessary to add >"virtual" to >> any overridden virtual functions, and in fact it's not possible to >> "unvirtualize" once virtualized. I do try to maintain them as a >stylistic >> convention, but even I fall short sometimes ;-). Thanks for patching >that. > >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
Re: [PATCH] Update 2 - Setup.exe property sheet patch
- Original Message -
From: "Gary R Van Sickle" <[EMAIL PROTECTED]>
>
> "Once virtual, always virtual", i.e., it isn't necessary to add
"virtual" to
> any overridden virtual functions, and in fact it's not possible to
> "unvirtualize" once virtualized. I do try to maintain them as a
stylistic
> convention, but even I fall short sometimes ;-). Thanks for patching
that.
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'.
> > 2) See download.cc - is next_dialog still used, and should a
> > fail result
> > in the previous behaviour?
> >
>
> I believe it is still used in a few places (some of the "do_xxx"'s).
That
> whole mechanism is one of the next things to go. As far as behavior
is
> concerned, I'm trying hard to specifically *not* change any at this
point,
> but simply to get the new property page and class foundation laid
("simply"
> he sez ;-)). So you're saying that a download failure isn't being
handled
> properly?
I think that 2 things are broken:
1) A local install doesn't.
2) A failure during download may not behave correctly - but I don't
know.
Rob
RE: [PATCH] Update 2 - Setup.exe property sheet patch
> Having had a good close look, there is a little more that is needed
> before committing to CVS.
>
> 1) You've skipped at least one dialog - IDD_S_FROM_CWD - which is what
> was breaking local_dir.
Ok, I'll get that fixed tonight.
> (Oh, and the functions weren't virtual in some
> child classes :}).
"Once virtual, always virtual", i.e., it isn't necessary to add "virtual" to
any overridden virtual functions, and in fact it's not possible to
"unvirtualize" once virtualized. I do try to maintain them as a stylistic
convention, but even I fall short sometimes ;-). Thanks for patching that.
> 2) See download.cc - is next_dialog still used, and should a
> fail result
> in the previous behaviour?
>
I believe it is still used in a few places (some of the "do_xxx"'s). That
whole mechanism is one of the next things to go. As far as behavior is
concerned, I'm trying hard to specifically *not* change any at this point,
but simply to get the new property page and class foundation laid ("simply"
he sez ;-)). So you're saying that a download failure isn't being handled
properly?
> I've attached an updated patch for you with the virtual functions
> actually still virtual.
>
Thanks, and thanks for running it through indent. It looks all GNUey now
;-).
> Rob
>
--
Gary R. Van Sickle
Braemar Inc.
11481 Rupp Dr.
Burnsville, MN 55337
Re: [PATCH] Update 2 - Setup.exe property sheet patch
Having had a good close look, there is a little more that is needed before committing to CVS. 1) You've skipped at least one dialog - IDD_S_FROM_CWD - which is what was breaking local_dir. (Oh, and the functions weren't virtual in some child classes :}). 2) See download.cc - is next_dialog still used, and should a fail result in the previous behaviour? I've attached an updated patch for you with the virtual functions actually still virtual. Rob Gary2.patch.bz2 Description: Binary data
Re: [PATCH] Update 2 - Setup.exe property sheet patch
Last time around hopefully! 1) format your changelog with line wrap at 80 columns. 2) It's a changelog, so if you #if 0 and then remove a function during your local testing, the final change is actually just a remove. Likewise, chooser.[cc|h] should not be mentioned because it never exists (from CVS's viewpoint). 3) You've _Still_ got blank lines in the log. 4) You've got multiple log entries - this is going in as a single commit, so thats inappropriate (IMO, open to discussion). In a nutshell: This is a Changelog from CVS 'NOW' to CVS 'after the commit'. The acid test I recommed you perform is to walk through the .diff with the changelog open beside you. Make sure all changes are listed, and you also get to do a code walkthrough for free. 5) (Blame me) Remove the change to link against comctl32 - thats in CVS now (I've checked in my working dir as I recently got stable again the chooser). (Which, IMO is starting to 'get there'.) It's not a historical set of notes that you've gone through in your sandbox but rather an explanation of the desired effect of the change getting committed. Don't worry about sending updated source, I just need the ChangeLog and it'll all get committed. Rob === - Original Message - From: "Gary R. Van Sickle" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, December 20, 2001 5:19 PM Subject: [PATCH] Update 2 - Setup.exe property sheet patch > Changes as per your (Rob) last email, plus a few other improvements. Diff, new > files, and ChangeLog attached. > > -- > Gary R. Van Sickle > Brewer. Patriot. >
[PATCH] Update 2 - Setup.exe property sheet patch
Changes as per your (Rob) last email, plus a few other improvements. Diff, new files, and ChangeLog attached. -- Gary R. Van Sickle Brewer. Patriot. setup.diff.bz2 Description: Binary data setup-newfiles.tar.bz2 Description: Binary data setup.ChangeLog Description: Binary data
