🚀 go-pugleaf

hacrat@catfish.lcs.mit.edu (Nate Osgood) writes:

>Hi.  I'm using g++ 2.2.2 on Sun4 hardware, running SunOS release
>4.1.2.  I've noticed something that I believe is not a bug in g++ but
>rather an incompatibility between g++ 2.2.2 and the standard
> routines for use in debugging heap-based allocation problems.  i'm
>wondering whether other people on this group might have encountered
>this problem before and/or would be able to describe how to get around
>it or be able confirm its character (as a NON bug)

You are right: this is NOT a bug.

>  in particular, after hacking around at the assembly language level
>i've noticed that g++ 2.2.2's memory layout for vectors of objects
>differs substantially from its layout for single objects
[...]
>g++ 2.2.2 seems to have a somewhat "trickier" strategy.  for
>non-vector objects, the format seems to be the same.  for at least some vector
>objects, it seems that another format is used:

Yes. The objects in question are those with destructors.
When you invoke vector operator delete on a vector of objects with destructors,
the destructor is called for each object. For this reason, the compiler needs
to save the number of elements, etc.

>class Foo 
>{
> public:
>  Foo() {}
>  ~Foo() {}
>};
> 
>main()
>{
>  Foo *p = new Foo[1];
> 
>  delete p; 
That should be
   delete[] p;

(or with some old compilers, "delete[1] p;" )

>}

You would be best advised to read an up-to-date C++ book which discusses
dynamically allocating and deallocating arrays.

If changing the "delete p" to "delete[] p" doesn't fix your problem, then
you will probably need a new version of malloc.o for g++.
-- 
Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
This .signature virus is a self-referential statement that is true - but 
you will only be able to consistently believe it if you copy it to your own
.signature file!