Sv: Sv: Sv: Memory allocators

["Bjarke Hammersholt Roune" <asmild@post6.tele.dk>]

>Hey, cool down. We don't have a fixed release date ;)
>
I didn't mean it that way.

>We code when we have time and as long as it keeps being fun.
>
That's what I meant.

>>>The URL stuff is implemented and the API functions are already using it.
>>>
>>API functions? Didn't you mean most of the API functions are already using
>>it?
>
>Was that an emphasis on "most" ? Otherwise the two phrases are absolutely
>identical.
>
"the group X does Y" and "part of group X does Y" isn't the same.

>What I wanted to say is that the functions in ppfOpen.cpp etc are adapted
>to use the new URL processing scheme and that's it. The functions/methods
>called bythem are not converted yet.
>
Ah, ok.

>>Technically, the method that finds an entry in the container is an
accessor
>>method, and therefore should be prefixed with Get instead of Search. Of
>>course, Search does make it more clear that some kind of processing is
going
>>on to come up with the result. I'd personally go for GetXXX().
>
>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")?
If that's not what you mean, I'm not sure I understand what you mean by
"recursively".

>>I suspect that the dependency that cannot be removed is where in the
>>pak-file other data is stored (like the actual files and directories the
>>directory is made up of). Completely off?
>
>No. Partially right. But more about that tomorrow. I'm too tired now ;+)
>
Know the feeling :)

>And don't forget to enjoy your weekend ;)
>
Don't worry... :)

>>really short on time. And the dependencies have to be cleaned up anyway
>>(there´s too much tree-specific stuff outside of the tree code) ;)
>>
>Well, the tree-specific code we can just delete, since there isn't any tree
>anymore...

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

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

>>>The namespace for internals on the other hand is useful because it
>>>allows us to e.g. override operator new without interfering with some
>>>custom operator new defined by the user.
>>>
>>I think it'd be annoying and unnessecarily confusing to add "pp::" to some
>>things, and not to others, solely based on what is internal and what is
not.
>>If we change something from internal to external, or vice versa, the
change
>>would cascade through code.
>
>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.