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
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
>>
>>
>
[PATCH] cygpath.cc
Hi, as already announced here is the next patch for cygpath.cc supporting -l option to convert file names to Windows long format. Unfortunately this works not for strict mode, since functions cygwin_conv_to_win32_path and cygwin_conv_to_full_win32_path will return an error for a Windows short path/name. 2002-05-20 Joerg Schaible <[EMAIL PROTECTED]> * cygpath.cc (main): Add option l to support conversion to Windows long file names. Refactured code for capital options. Support of options from file for capital options. (dowin): New function. Refactured from main. (doit): Call long path conversion. (get_long_name): New function. (get_long_paths): New function. (get_long_path_name_w32impl): New function. Reimplementation of Windows API function GetLongPathName (only 98/Me/2000/XP or higher). (get_short_name): Call GetShortPathName only once. (get_short_paths): Fix calculating buffer size. * utils.sgml: Update cygpath section for l option. Regards, Jörg cygpath.diff Description: Binary data utils.diff Description: Binary data
RE: [PATCH] cygpath.cc
Hi Corinna, >AFAICS, the patch is ok. Fine. >Just two question: > >- The -s and -l options are only valid with the -w option. Shouldn't > either the usage reflect that or the -s and -l options imply -w > automatically? It's not *that* obvious for the user that s/he > has to use `cygpath -w -l ...'. I always had in mind that it would be great to implement the options once for -u, too. Example: $ cygdrive -u `cygdrive -asw \`cygdrive -u 'C:\Dokumente und Einstellungen\All Users\.bashrc'\`` /cygdrive/c/DOKUME~1/ALLUSE~1/BASHRC~2 It would be nice to have instead: $ cygdrive -us 'C:\Dokumente und Einstellungen\All Users\.bashrc' /cygdrive/c/DOKUME~1/ALLUSE~1/BASHRC~2 Another example: At least on my box W2K is converting TEMP automatically into short form if I open a console. This is quite inconvenient in bash and I would like to have rather the long form: $ echo $TEMP /cygdrive/c/DOKUME~1/joehni/LOKALE~1/Temp Prefered call: $ export TEMP=`cygpath -ul $TEMP` $ echo $TEMP /cygdrive/c/Dokumente\ und\ Einstellungen/joehni/Lokale\ Einstellungen/Temp In any case, the normal usage of cygpath should not care about -s or -l, since you would normally only convert a Unix path into a DOSish notation (which is by default the long form anyway). Both options are IMHO for very special purposes. What bothers me more, is that you cannot convert a short path into the long version when check_case:strict is set, since the conversion functions in the cygwin1.dll will reject that path as non-matching. But I am not really sure, whether this functions should look for the alternative physical name or not. Another problem arises with Java CLASSPATHs, since their element may be also files instead of directories, which prevents a conversion unfortunately, too. Regards Jörg
RE: [PATCH] cygpath.cc
Hi Corinna, >I see and that's a good idea, IMHO. However, for now I have >applied your patch and just tweaked the usage output slightly. Fine. I was unhappy with it by myself also, but was not sure how to improve it in the best way. :)
RE: /dev patch
Hi Chris, >This patch adds support for a virtual /dev which just lists >the devices that >cygwin currently supports. Just curious, since I have this setup: Have you ever tested what happens when /cygdrive is renamed to /dev already ?? Regards, Jörg
