[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Namespaces (was: Memory allocators)
Bjarke Hammersholt Roune wrote:
>>>>>// the code...
>>>>Regardless of the above issues I like that.
>>>Yeah, I like that best too. We *could* do it like this:
I added it to the main headers here. (I'll upload those very soon)
>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
No, no, no. That's like saying "you must not use functions from the C
stdlib in a C++ program".
>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++.
That's what the planned iostream-like API of PFile is for. So we'll have a
procedural API and an object oriented one, and the user can use the one he
>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.
I think it's ok. Here's how I'd do it now:
* macros are (of course) global and thus keep their prefix
* C API declarations are in global namespace when used in C programs and in
the pp namespace when used in C++ programs. This is done by wrapping their
and prefixing each function with PP_EXTC
(see the new headers for info on those)
* All internals are in the namespace pp::internal, and only have a prefix
indicating what part they belong to (f for PFile, s for PSound etc)
(FIX: is the part prefix really good? It makes things clearer, but looks
ugly. And name clashes shouldn't occur here anyway - IMHO it's even better
if a missing prefix tells us about two identical names)
* And generally the export-things-from-pp::internal-to-pp scheme you
proposed is good.
Drive A: not responding...Formatting C: instead