Sv: Sv: Sv: Sv: Memory allocators

["Bjarke Hammersholt Roune" <asmild@post6.tele.dk>]

>In other words, auto_ptr light ;)
>I guess I'll write such a thing (or you do, as I have quite little time ;)
>
No problem. I'll do it. When will you need it?

>That's ok in that situation, but if the second allocation is in some bigger
>if () block either two try-catch blocks are needed or alnost the entire
>function has to be included in one, which is an extra indendation level for
>everything, which is ugly.
>
I wouldn't say "ugly", but I will agree on inconvinient, a bit irritating
and marginally bad on readability.

>>I migth have misunderstod this, but if we place some code into a
namespace,
>>and define our own, within the namespace, global new() function, then we
can
>>implement it like this, without affection any other namespace's new
>>functions.
>
>Right. I didn't think about namespaces. We already thought about putting
>all internal PPlay code into a namespace - what is the general feeling
>about that?
>
Well, as you migth have figured out, I'm all for it :)

I suggest having one main namespace, pp I imagine, and then give each
namespace its own sub-namespace into this, so PFile would perhaps be
pp::file, PSound would perhaps be pp::sound etc.

The main namespace, pp, would then include all the sub-namespaces into the
main namespace. This makes it possible for everyone to have their own
namespace, while making the effect of this so that it doesn't hinder the
user of the libs.

There's also the benefit that including and excluding whole parts of PPlay
is as simple as excluding or including a "using namespace ...".

Perhaps having just one namespace is a better idea, I'm not sure.

>>void* new(size_t size)
>
>You mean "void *operator new (size_t size)"  ?
>
Sorry. Yes, of course.

>>Anyways, the main point is that using bad_alloc is the C++ standard, and
not
>>to use it therefore must logically be bad behavior. Also, I suspect that
the
>
>That means that VC++ behaves badly ;)
>
The documentation for VC++ 5.0 says that it throws an exception of type
xalloc at allocation failure. This was the behavior endorced by a draft of
the standard at the time VC++ 5.0 was released (or so the documentation
says). However, you are correct; today, VC++ 5.0 behaves badly. I don't know
the situation for VC 6.0

>Serious again - any idea on how we can detect whether new throws bad_alloc
>or returns 0 ?
>
Well, we can make it the default to check for all possible situations. Then,
people who knows what their variation of the standard library does at
allocation failure, can define one of three preprocessor symbols, one
meaning that returning 0 is the default, one meaning that throwing bad_alloc
is the default, one meaning that throwing some exception of another type
than bad_alloc is the default.

This works, and for people who think performance matters, it is as effecient
at it can get.

I don't think there's any way to automaticly detect what the situation is.