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

Sv: Namespaces (was: Memory allocators)

>I added it to the main headers here. (I'll upload those very soon)
Good. We'll be have to be carefull not to do this, though:

#include "blah.h"

class ppBlah

We'd be getting ppBlah as pp::internal::pp:internal::ppBlah. Easy thing to
do accidentally.

>>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".
Yes... I see how that is bad.

>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.
That's a better solution, agreed. We aren't going to mirror the standard
library stream classes, though, right?

>>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.
>>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:
>* 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
> [...]
Do C functions loose their prefixes? Or do we have C stuff with prefixes,
and C++ stuff without prefixes?

>* 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)
Well, for the C++ stuff, I think we should lose the prefix altogether.

>* And generally the export-things-from-pp::internal-to-pp scheme you
>proposed is good.