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

Sv: Memory allocators

>>>>// the code...
>>>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,
>functions as ppffunctionname () - and the linker doesn't find them

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,
>>you don't have to add "pp::" to your new calls. Same goes for everything
>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.