Sv: Memory allocators

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

>>>>*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!!!
>
>functions as ppffunctionname () - and the linker doesn't find them
anywhere.

Yes, I see how that is bad. Hmm... We could seperate things so that a C++
program using PPlay never uses the C functions. That would be kind of a
solution. Perhaps in the same breath putting everything (or wrapping) into
classes so as to make everything OO.

That reminds me, those structs whose data-members C directly accesses (like
ppfDirEntry) shouldn't be used raw in C++ like that. It would be better to
declare a class that encapsulated this via protected enheritance in C++.

Perhaps we should just both stuff everything in a namespace and keep the
"ppX" prefix. Keeping C++ and C apart is the "correct" solution, though. The
C stuff would keep the "pp" prefix, but the C++ wouldn't. I'm not sure I
like any of these prospects.

>>>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.
>
>Which operator new is called in that example? The PPlay one or the user's
>global one?
>
I'm not sure. Outting everything into "::pp::internal" (read my other mail)
would solve that problem if it is there, though.