Re: Phew...

[Christian Reiniger <warewolf@mayn.de>]

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

Yup.

>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.

Nice.

>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.).

Cool.

>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:
>
>__ppInternalError
>char const * const  _ppNoFuncNameMsg
>__pp_db_func_loc
>__pp_db_lineno_loc
>__ppWarning
>__ppFatalError
>__ppDebug
>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
correct it.

>This works better:
>
>#define ppAssert(expr)
>#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
>problems.

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
>error?

Right.

>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.


	Christian
-- 

Drive A: not responding...Formatting C: instead