[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Sv: Memory allocators

Bjarke Hammersholt Roune schrieb:
> >I won't be able to do *any* coding until the weekend - likely even until
> >after the weekend, so it's not urgent. Besides I first want to do the other
> >changes (hashing code + URLs, then custom allocators) before. Well, perhaps
> >including the auto_ptr stuff *before* the custom allocators is better...
> >
> Perhaps it would be a good idea to find out exactly who does what. I'm
> finished with the ppDelPtr class (documenting it now).
> You are going to do the hashtable and the URLs? Anything else that needs
> doing?

How much time do you have? Mine is *very* limited right now.

The URL stuff is implemented and the API functions are already using it.
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).

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). But if you plan to stay with
PFile you´ll have to gain hat insight sooner or later anyway ;)  And I´m
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) ;)

If you want I can send you my current code plus a rundown of
what-does-what and what-to-care-about when I´m back home.

> >I'd say just one namespace (PenguinPlay) for all internals. The API should
> >be outside the namespace to make things simpler for the user and because
> >some APIs (e.g. the PFile one) have to be accessible from plain C (which
> >doesn't know about namespaces).
> >
> I disagree. As far as my understanding goes, the C API is distinct and in
> different headers than the C++ API (if its not, I think that migth be worth
> considering). This means that the C API can be put in the global namespace,
> and the C++ API can be put in its own namespace.

PFile´s C API has to be usable both from C and C++ for example.

In any case we have the "pp" prefix whih makes the namespace for API
stuff pretty unneccessary.
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.