Re: Sv: Sv: Sv: Memory allocators

[Christian Reiniger <warewolf@mayn.de>]

Bjarke Hammersholt Roune wrote:

>Consider this:
>
>template<class TYPE>
>class delPtr
>{
>    ~delPtr()
>        {delete m_pPtr;}
>// declare all operators  one-line inline functions that makes
>// delPtr behave as a real pointer to an object of type TYPE.
>protected:
>    TYPE* m_pPtr;
>}

In other words, auto_ptr light ;)
I guess I'll write such a thing (or you do, as I have quite little time ;)

>In some cases, one might not wish to have the memory allocated deleted. In
>that case, it's possible to set the value of the object of type delPtr to 0
>(NULL).

Or provide a simple method for that, yes.

>Also, I really don't see what's so bad about this:
>
>int SomeFunc (void)
>{
>  char* pStr1 = 0;
>  char* pStr2 = 0;
>
>  try
>  {
>    pStr1 = new char[256];
>    pStr2 = new char[256];
>  }
>  catch (...)
>  {
>    delete[] pStr1;
>    delete[] pStr2;
>    throw;
>  }
>
>  // do something
>
>  delete[] String1;
>  delete[] String2;
>}

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.

>However, to me, these are merely auxillary arguments. The real and best
>argument is simply that throwing bad_alloc is what's supposed to happen. A
>library not built around this is IMHO not a well-behaved library. Also, the

Or it has a C API like PenguinFile ;) So at least the PFile API can't throw
bad_alloc.  But if you're only talking about the internals, you're right.

>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?

>void* new(size_t size)

You mean "void *operator new (size_t size)"  ?

>{
>    static bad_alloc excep; // can't allocate this if there's no memory...
>                                            // so it has to be static
>    void* pMem = someOtherNamespaceWithNoNewDefined::new(size);
>    if (pMem == 0)
>        throw excep;
>    return pMem;
>}
>
>This isn't very effecient if new already throws bad_alloc at allocation
>failure. The simple fix is to make it dependent on a preprocessor symbol
>wheter or not this custom new gets included in the namespace.
>
>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 ;)

Serious again - any idea on how we can detect whether new throws bad_alloc
or returns 0 ? 


	Christian
--

Drive A: not responding...Formatting C: instead