[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:
PP_NAMESPACE_BEGIN
#include "blah.h"
//...
PP_NAMESPACE_END
*blah.h*
PP_NAMESPACE_BEGIN
class ppBlah
//...
PP_NAMESPACE_END
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.
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:
>
>* 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.
>
:)