Detecting pointer on the heap
in [C++]
|
Prev: performance of hash_map in combination with strings on vstudio 2003
Next: Dot operator Overloading
From: pfultz2 on 1 Apr 2010 16:36 For example, if I have two classes like this: template<class T, int N> class value_array { T data[N]; public: int length() { return N; } T* pointer() { return data; } //Methods for operator overloading }; template<class T> class array { int len; T* data; public: explicit array(int n) { len = n; data = new T[N]; } template<int N> array(value_array<T, N>& a) { data = a.pointer(); len = N; } int length() { return N; } T* pointer() { return data; } void deallocate() { if (is_heap(data)) delete [] data; } //Methods for operator overloading }; This is kind of a rough sketch of what im trying to accomplish. When I want to deallocate the array, I need to check if it on the heap because it could be pointing to an array on the stack that it got from value_array. Now, when I use a garbage collector this is ok, but If want to manage the array myself, I guess I will need to add an extra bool in there to signal that it is a heap array or a stack array. But I would really like to avoid carrying around an extra integer in the class., so I figure maybe I could check it when i delete it. I know the Boehm-Demers-Weiser garabage collector knows when its on the heap or the stack. Now that GC is not completly portable but it is portable enough for what im trying to do. I just need it to run on Windows/Mac/ Ubuntu. So I could use Win32 API on windows, and use some other API on Unix/Linux(perhaps POSIX). I want to use this when I manage the array either because Im not using GC, or I want to help the GC in deallocating. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Goran on 1 Apr 2010 20:46 On Apr 2, 9:36 am, pfultz2 <pful...(a)yahoo.com> wrote: > For example, if I have two classes like this: > template<class T, int N> > class value_array > { > T data[N]; > > public: > int length() > { > return N; > > } > > T* pointer() > { > return data; > > } > > //Methods for operator overloading > > }; > > template<class T> > class array > { > int len; > T* data; > > public: > explicit array(int n) > { > len = n; > data = new T[N]; > > } > > template<int N> > array(value_array<T, N>& a) > { > data = a.pointer(); > len = N; > > } > > int length() > { > return N; > > } > > T* pointer() > { > return data; > > } > > void deallocate() > { > if (is_heap(data)) delete [] data; > > } > > //Methods for operator overloading > > }; > > This is kind of a rough sketch of what im trying to accomplish. Why not simply this: class array { // ... bool _owns; explicit array(int n) : _owns(true) { len = n; data = new T[N]; } template<int N> array(value_array<T, N>& a) : _owns(false) { data = a.pointer(); len = N; } ~array() { // NB: you should probably forget your "deallocate" idea. if (_owns) delete [] data; } } But! But... I seriously question your design. Why do think you should have modifiable data in multiple arrays like this? Do you actually want to mix them this way? From a design standpoint, it seems mighty dubious to me. One reason I can think of why you would want that is that after __serious__ performance measurement and a __serious__ work on optimization (most notably, elimination of copying), you still need to go faster. If, OTOH, you were thinking "it will be faster if I do it this way" for no apparent reason... Just forget the whole idea and go for std::vector. Honestly. Also, did you consider using shared_ptr? Goran. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Mark Zaytsev on 2 Apr 2010 01:02 On Apr 1, 10:03 am, George Neuner <gneun...(a)comcast.net> wrote: > On Wed, 31 Mar 2010 13:39:59 CST, pfultz2 <pful...(a)yahoo.com> wrote: > >I want detect if a pointer is pointing to memory on the heap or the > >stack, so I came up with this approach: [skip] > > The stack check works on Unix/Linux and Windows because their stacks > are contiguous - but there may be other platforms for which it won't > work (although I've yet to meet such a platform). > Stack of which thread ? If object allocated on the other thread's stack, your check will say: HEAP... -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: James Kanze on 2 Apr 2010 07:02 On Apr 1, 3:03 pm, Nick Hounsome <nick.houns...(a)googlemail.com> wrote: > On 31 Mar, 20:39, pfultz2 <pful...(a)yahoo.com> wrote: [...] > Not only is it not portable it is fundamentally a bad design. That's true, but. > Memory problems are best avoided by only deleting objects in > the class that allocates them. That depends on why you're using dynamic allocation to begin with. Entity objects will be deleted when the design says they should be, often using a "delete this". If the allocation is for polymorphism, with the actual type not known at compile time, std::auto_ptr or boost::scoped_ptr should probably be used to take care of the deletion. Only if dynamic allocation is being used for variable sized storage (e.g. as in std::vector) does it make sense for the allocating class to do the deletion. -- James Kanze -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: James Kanze on 2 Apr 2010 07:03
On Apr 1, 3:03 pm, George Neuner <gneun...(a)comcast.net> wrote: > On Wed, 31 Mar 2010 13:39:59 CST, pfultz2 <pful...(a)yahoo.com> wrote: [...] > In general there's no portable way to do it because there is no > standard program memory layout. What you can do, though, is assume > that the stack is contiguous, Just for the record, I've worked on one machine where it wasn't. Where stack frames were allocated using the same mechanism as malloc (and were spread out through out the free space arena). That's probably history, though, and I can't imagine a modern implementation using this technique. -- James Kanze -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |