[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
First off, there is both a ppfWin32PosixImpl.c and a ppfWin32PosixImpl.cpp
in the tarball. There should only be a .cpp file. To make matters worse,
these are both versions of ppfWin32PosixImpl that don't work nor compiles.
The zip I've attached contains only one updated ppfWin32PosixImpl
Directory and File now derives directly from DirEntry using public
I *really* think we should removed the virtual methods GetSize(),
AsDirectory() and AsFile() from DirEntry.
GetSize() makes absolutely no sense what-so-ever for Directory, and it
therefore does not belong in a base class that File shares with Directory.
AsDirectory() and AsFile() makes the virtual table larger than nessecary,
and are ineffecient anyway. There really is no point in returning a value
that is already known by calling code in a method that cannot be inlined.
GetType() obsoletes both of these methods, and does the job more effeciently
Also, AsFile() makes no sense for Directory, and AsDirectory makes no sense
for File, so it shouldn't be in a base class shared among these.
Am I missing some crucial element of this?
URLInfo works perfectly for both dos and unix style paths. You might want to
give it a quick test that things work the way you intend for them to do,
Why doesn't ToVirt() work for native paths? I made it work for dos-style
ones. Unix-style ones seem to work ok, except the leading / is trimmed away
for absolute paths (this very much seemed intentional, so I didn't change
I have changed is_for_plain to is_native and supplemented IsForPlain() and
ToPlain() with IsNative() and ToNative(). I havne't removed IsForPlain() and
ToPlain() as it would break code all over.
I fully agree that ToNative() and IsNative() is much more intuitive than
IsForPlain() and ToPlain(). We should change all calls to ToPlain() and
IsForPlain() with calls to ToNative() and IsNative(), so that ToPlain() and
IsForPlain() can be removed from URLInfo.
I have done the dossification with #ifdef's. If you have a good reason for
implementing this stuff in seperate methods (ie, why does it matter to a
compile under linux wheter Win32 is ok?), I'll be happy to change it to work
like that. The code changed are, in some places, stuff like just a single
line. In no place is it over 10 lines. I just felt that moving all
dos-specific functionality into seperate methods would make everything more
complicated with no gain.
There was some other small issues in a few places making sutff not compile.
Very minor stuff, like the order in which functions are implemented in a
file (only thing I can remember right now).
The source is coming in priv. mail. I included the project file as you
requested. If you want it to have another name, or its location is wrong,
please tell me, as that matters (well, you CAN rename it, but the project
will still have the old name from within MSVC. You can't move it without
I also included the fixes I mention in the other E-mail.