[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
likes best.

>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
headers in


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