Re: Memory allocators

[Christian Reiniger <warewolf@mayn.de>]

Bjarke Hammersholt Roune wrote:

>>SearchXXX () not only does "some kind of" processing, it looks for the
>>specified file/dir recursively. GetXXX doesn't make that clear enough IMO.
>>
>Recursively? You mean you pass in a complete path like
>"c:\blah\blah\blah.txt" (or something like it), and then the container
>itself figures things out (search in entry "c:\blah" for "\blah\blah.txt")?

Almost. I pass it a "path" that's *relative* to this container. But
otherwise you're right. With the new URL system we pass a bit more info.

Ok, while we're at it, here's a brief rundown on the new URL processing
stuff.

The core components are the struct ppf_URLInfo and the function
ppf_ParseURL ().

ppf_ParseURL takes an URL, analyzes it and stores the info on an
ppf_URLInfo struct *provided by the caller* (to minimize dynamic
allocation. See the code in ppfOpen.cpp for examples).
A ppf_URLInfo struct contains things like a pointer to the URL's Path part
(without the fstype specifier etc), an array of pointers to the starts of
each part of the part, an array with the lengths of these parts, some flags
indicating whether the path is absolute etc and an FSType number.

That means URLs are completely parsed once up front and then the info
structure is passed around.

For the dir classes that means their SearchXXX methods get a (reference to
an) URL info struct plus the number of the part they are at.

ppf_Directory::SearchXXX() still has the old code, but it's still good for
understanding the "recursive" thing.

>>Well, right. Now we have to care about not using too much hash-specific
>>code ;)
>>
>Wouldn't all hash-specific code be encapsulated in the class for
>directories/files, and/or the hash-table?

Ideally yes, but I don't know whether that's possible 100%.

>>>*C++AndCHeader*
>>>PP_NAMESPACE_BEGIN
>>>// the code...
>>>PP_NAMESPACE_END
>>
>>Regardless of the above issues I like that.
>>
>Yeah, I like that best too. We *could* do it like this:
>
>#define PP_PREFIX(NAME) pp##NAME
>
>So ppFunction becomes PP_PREFIX(Function). I'm not sure I like that, though.

NO!!!

Imagine we'd use that for the PFile API. Now we compile libpenguinplay.so -
of course with a C++ compiler. That means the API functions are stored in
the library as pp::ffunctionname ()
Now some user writes a little C game using PFile. His C compiler sees the
functions as ppffunctionname () - and the linker doesn't find them anywhere.

>>How would you do the custom operator new stuff then?
>>
>Well, if all PPlay stuff is in a certain namespace, they will all use the
>global operator new of that namespace. Put everything into namespace pp, and
>you don't have to add "pp::" to your new calls. Same goes for everything
>else.

-----usercode----------
#include <PenguinPlay/PenguinPlay.h>

void *operator new (size_t size)
{
    // allocate
}

int main (void)
{
  using namespace pp;

  char *mystring = new char [255];

  return 0;
}

Which operator new is called in that example? The PPlay one or the user's
global one?


	Christian
--

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