Re: Problems

[Christian Reiniger <warewolf@mayn.de>]

Bjarke Hammersholt Roune wrote:

>**** The std namespace
>I don't know about your implementation of the standard C++ library, but in
>mine, the header cstdio does not put FILE into the namespace ::std, but
>rather the global namespace. To me, this seems a bit weird, but that's
>what's happening.

It puts nothing from the c* headers into any namespace yet, but std::FILE
works because the std:: is ignored. That's for easing the transition from
old, not-namespace-capable versions of the compiler to coming, completely
compliant ones.

>Very, very weird is the fact that the template functions min and max are NOT
>defined in the header algortihms.h as they should be. The best I get in

<checking> Yes, they should be.

Here they are defined like this (in stl_algobase.h included by algorithms):

--------
#ifndef __BORLANDC__

#undef min
#undef max

template <class _Tp>
inline const _Tp& min(const _Tp& __a, const _Tp& __b) {
  return __b < __a ? __b : __a;
}

template <class _Tp>
inline const _Tp& max(const _Tp& __a, const _Tp& __b) {
  return  __a < __b ? __b : __a;
}

#endif /* __BORLANDC__ */
--------

The fact that it doesn't exist in your stdlib implementation means that we
won't use it and instead define our own versions in the ::pp::internal
namespace.



>**** The current serialization scheme
>It'll all have to change to incorporate the new serialization scheme. The
>current stuff simply doesn't fit into the new Directory implementation.

Correct. Dump the old one and write the new from scratch. If you give me
the sources beforehand I can help you a bit with that.

>The current serialization scheme seems somewhat more complicated than
>needed. Just what is the reason for having two passes rather than just one?

It works no matter how random the data is spread in the PakFile.

>I think its alot more effecient (and simple!) to do a little processing
>before hand so that all information is present before the first pass,
>meaning that only one pass is nessecary. Is there something I'm overlooking
>that makes this impossible?

No. Not if we write PakF1 dir info as you proposed, which is good.

>I really don't like the way recursion is performed via the GetNext() method
>of DirEntry. If one has a thousand files in a directory, one will get a call
>stak a thousand methods deep...

/me is staring at the screen
<time passes>
Geeeez, when I wrote that I didn't even *recognize* it as recursion!!
When you find that gun, please send it to me, ok?

>Why all the ppf_PakMWriteLEIntXX() stuff? I mean, memcpy works just as well,
>and its much clearer what's going on... Its faster too. Atleast my
>implemenation is, as its inline assembly that goes to the next 4-byte border
>and then copies 4 bytes at a time.

But memcpy doesn't automatically convert endianness and expand the data
size.

ppSizeT Val = 0xdeadbeef;
memcpy (dest, &Val, sizeof (Val));

will write a 4-Byte, big endian value on a (non-Ultra) SPARC, instead of a
8-Byte, little endian one.

>Why store a pointed to the parent of each item in the actual pak file?

The destructors do a parent->Remove (this) (which is unneccessary if
I don't seriously miss something).
And for the Directory class it's neccessary for correct part traversal.

>It seems that the varying-length nature of the name string is screwing
>things up when writing data. Why not just write it to the file before
>creating the in-memory buffer of the rest of the info? That way, it can be
>ignored alltogether.

How do you mean that? Having a block of file names somewhere?

>The new scheme offers a framwork that makes everything independent, and this
>is incompatible with the current way of doing it. This means I'm going to
>have to change alof of stuff to get it to work. I thougth I had better run
>this by you first.

As said above - consider the old code garbage.

>**** Those SetParent() methods all over
>All SetParent() methods call Remove() on their former parent. Wouldn't the
>former parent always be NULL ? Are anything ever really moved (ie, changing
>parent) ?

Hmmm, not yet I think. But it's very likely that some future implementation
will support file moving.
Perhaps we should comment it out for now - but it's impact on the
performance is almost non-existent so we should leave it in. It's a little
bit safer as well.

>**** Constants
>How about moving constants from Const to pp::internal:: ?

Yup. Const only exists because I didn't have a common namespace.

>**** Serialization initialisation
>What exactly makes the output serialization process start in the current
>implementation? I've been unable to find the spot...

PakFile::Umount (), called by TGlobalData::Umount (), called by ppfUmount ()

>Well, the good news is that I've figured out the last few problems with the
>new serialization scheme. Atleast in theory.

*grin*
Are you done with the namespace thing? Then it would be nice if you sent me
the code so that I can help you & add the missing URL functionality etc.


	Christian
-- 

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