[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
There still are a few problems, though:
There's one issue about the new way of doing things I haven't been able to
resolve. Atleast, I think you would be better at resolving it. It has to do
with ppfDir. It makes it possible to iterate over the contents of a
directory. It's just that you have to use a DirectoryEntryIterator to do
that, and ppfDir is simply expecting a start and end pointer to an array. It
won't work that way, as not all entries are in the same array.
Btw, is it really nessecary to iterator over *entries* ? Isn't it sufficient
to iterate over either child dirs or child files? If that is the case, then
a start and end pointer will be suffcient. We'll still have to break the
encapsulation of HashTable by declaring any function that manipulates the
first/last members of ppfDir friends of HashTable.
The very best thing would be to do it the proper way, ie, to use the
iterators. If C code is only ever given a pointer to a ppfDir, that
shouldn't be a problem, but I don't know exactly how ppfDir is used...
On a related note, the class DirEntry can no longer be used to iterate, so
it no longer has the method GetNext(). This method is used in a few places.
In ppfMkdir.cpp in ppfMkdir() I removed this line:
mode_t omode = 0;
The reason was that my compiler didn't know about "mode_t", I didn't have
anything on it in any docs, and it wasn't used in the function anyway.
In alot of places RTTI no longer needs to be used because of the new way
serialization is done. Just call the serialization functions who is supposed
to have the functionality you want. If you don't get an EUnsupported
exception, things are fine. If you do, you got the wrong type. Nice, simple,
effecient and no RTTI.
Some good news: PFile compiles just fine on my system. I had to change a
single line in debug.h, but otherwise, I had no hacks anywhere (like
commenting out troublesome code etc.).
I still got a large amount of build errors, though: 161 errors + 4 warnings.
Most of these were the unresolved link type. I corrected some of them which
was cause by my code (forgot to declare a method pure virtual, which gave a
few errors). Still 156 errors remained.
The symbols I were getting unresolved link errors on were these:
char const * const _ppNoFuncNameMsg
char * __cdecl pp::internal::Strdup(char const *)
char * __cdecl pp::internal::Strndup(char const *,unsigned int)
int __cdecl pp::internal::CopyToPlain(class pp::internal::URLInfo const
&,class pp::internal::URLInfo const &,struct ppfDirEntry &)
And that was it. Some of these symbols got an error from every obj file, so
thats's the reason for the high amount of errors.
The problem I was having with debug.h was that MS VC++ does not support
__STRING. This was used the definition of the ppThrow macro. We'll have to
let exceptions take an interger for the line argument instead of a string.
This was also causing errors in non-debug builds:
#define ppAssert(expr) (void) ()
#define ppThrow(XCept, details) (void) ()
This works better:
#define ppThrow(XCept, details)
(as a side note, I only get 14 build errors when PP_DEBUG is not defined,
and PP_DEBUGLEVEL is 0. 1 of those being for main() (well, actually
_WinMain(), but anyway) )
Notice that the code I've written positively will not work. The reason for
this is that I obviously haven't had a chance to test it to find the
I'm having some problems with interpreting the errorlog you gave me. None of
your errors turns up on my compiler. Anything that doesn't say warning is an
I've fixed the float stuff, and made the directory methods better match from
definition to implementation in regard to the throw stuff.
If there is anything else I should have fixed, but neglected to fix, then
I'm sorry, I didn't see it.
Source coming in priv. mail
If you fix the build errors, this thing might actually just run today, or,
well, right now its tomorrow for me, or... well, no, but its very close to
being today ehh... yesterday... ehh... Forget I said anything... :)