Re: auto_ptr for array of built-ins

Carlos Moreno wrote:
> (...)
> 
> The thing is, the "buggy" code using auto_ptr does
> compile and run as expected --- even when linked with
> Electric Fence  (not 100% if electric fence does cover
> memory leaks as well as illegal memory accesses).  In
> any case, it runs without EFence objecting.
> 

You see, the thing is, for example on VS2005 or VS2008 the default
implementation of new[] and delete[] for PODs just go on to call malloc
and free so you could even call free(p) on a POD-array that was
allocated with new[] and it still would "work".
Of course: If someone start to overload new[] or you change the
compiler(version) or something else it might suddenly stop to work, and
you're left with broken, non-std compliant code that's a real pain to
fix ...

> I guess at this point I'm more curious than anything
> else, in that I think even doing something as silly as
> a simple class house_keeper (you know, to do the
> housekeeping upon return) with:
> 
> template <typename T>
> class house_keeper
> {
>      T * p;
> public:
>      house_keeper (T * p) : p(p) {}
> 
>      ~house_keeper() { delete [] p; }
> };
> 
> And then:
> 
>      char * result = new char [ ... ];
>      house_keeper<char> r (result);
>      // ...  (use the raw pointer result as needed)
>      return string (result, result + length);
> 
> Seems like I'm getting the very small required subset of
> auto_ptr or scoped_prt/array that provides me with memory
> management and exception-safety at a very low cost (...)

If you do not plan to include boost, implement a variant of scoped_ptr
and scoped_array yourself. I would certainly not call that silly!

template <typename T>
class house_kept_array
{
      T * p;
public:
      explicit house_kept_array (size_t n) : p(new T[n]) {}
      ~house_kept_array() { delete [] p; }
      T* get() { return p; }
};


br,
Martin

-- 
      [ See http://www.gotw.ca/resources/clcm.htm
for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]