[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Bjarke Hammersholt Roune wrote:
>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.
Ok, I can chenge that to use the iterator.
>Btw, is it really nessecary to iterator over *entries* ? Isn't it sufficient
>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...
Just pointers to ppfDIR are passed to the calling code. Its internals may
only be accessed by PFile code.
>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.
Will change that.
>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.
Because it isn't used anymore. Oversaw that.
>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)
All implemented in src/ppUtils.cpp
Did you compile and link that?
>int __cdecl pp::internal::CopyToPlain(class pp::internal::URLInfo const
>&,class pp::internal::URLInfo const &,struct ppfDirEntry &)
Now that's weird... I'll look into that.
>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.
Ok, no problem.
>This was also causing errors in non-debug builds:
>#define ppAssert(expr) (void) ()
>#define ppThrow(XCept, details) (void) ()
A leftover from the evaluate-args-even-if-macro-is-skipped time. I'll
>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.
Yup, then all debug macros are left out, i.e. all the missing symbols above
Strdup () aren't showing up.
>1 of those being for main() (well, actually
>_WinMain(), but anyway) )
What error exactly?
>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
Sure. It will need some more debugging iterations until it really *works*.
>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.
Good, that's already most of the stuff.
>If there is anything else I should have fixed, but neglected to fix, then
>I'm sorry, I didn't see it.
I think that was it.
>If you fix the build errors, this thing might actually just run today, or,
Don't expect too much though. I have *very* little time currently.
Drive A: not responding...Formatting C: instead