Re: Sv: Sv: Memory allocators

[Christian Reiniger <warewolf@mayn.de>]

Bjarke Hammersholt Roune wrote:

>>How much time do you have? Mine is *very* limited right now.
>>
>I don't know exactly how much time I have. I haven't got any plans for the
>weekend. But of course, I don't think I would enjoy doing nothing but
>program all weekend. I have a fair amount of time, I'd say.

Hey, cool down. We don't have a fixed release date ;)
We code when we have time and as long as it keeps being fun.

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

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.

>>Now the internal code has to be modified to do the same (that´s
>>primarily the SearchXXX () methods in the new directory container (the
>>hash) plus some methods in ppf_TGlobalData - oh, and the specialized API
>>code (ppf_Open.cpp, ppf_OpenDir.cpp etc).
>>
>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.

>>I wanted to do at least the hash myself, because AFAIK you don´t have
>>the same level of "insight" of the various dependencies with that yet
>>(PakFile reading/writing (writing needs to be changed anyway, at least
>>partly) and the overall dir management).
>>
>I get a hint that you have considered the possibility that I migth get
>offended by your saying that I don't have the same level of insight into the
>various dependencies as you do (or I'm just way off and talking nonsense to

Right. Email is a tricky medium and I learnt to be careful...

>is certainly true, but some people just are that way. I'm not that easy to
>offend, though (just thought I'd clear it up. After having run other
>projects (non-programming related), I know how one has to worry about these
>kinds of things, as its hard to really get to know people over the net)

Good to know :)

>Anyways, ideally the container itself should only know how to serialize
>itself, and how to serialize the components of which it is made up of (or
>how to ask them to serialize themselves). Ie, this should all be ideally
>done without any dependencies of any kind (ie, keep things on a need-to-know
>basis).
>
>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 ;+)
I'm uploading the new basic CVS hierarchy to the ftp space
(ftp://sunsite.auc.dk/pub/os/linux/penguinplay/cvsnew-19990910.tar.gz). It
includes the current PFile sources.
And don't forget to enjoy your weekend ;)

>>But if you plan to stay with
>>PFile you´ll have to gain hat insight sooner or later anyway ;)
>>
>I certainly do plan to stay with PFile.

Good :)

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

>>PFile´s C API has to be usable both from C and C++ for example.
>>
>Easy.
>
>*CHeader.h*
>// the code ...
>
>*C++Header.h*
>namespace pp
>{
>#include CHeader.h
>}

Theoretically ok, but I still don't like it.
First we still need the "pp" prefix for the C API even with this - which
makes the API inconsistent.
Second I have a bad feeling ;)

>*C++AndCHeader*
>PP_NAMESPACE_BEGIN
>// the code...
>PP_NAMESPACE_END

Regardless of the above issues I like that.

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


	Christian
--

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