casey@CS.UCLA.EDU (10/06/88)
VERSION: GNU CC 1.27 GNU C++ 1.27 GNU LIBG++ 1.25 CLIENT MACHINE: VAX 8350 CLIENT OPERATING SYSTEM: ULTRIX 2.2 - no patches installed SYNOPSIS: The GNU C++ compiler automatically allocates temporaries for expression evaluation. It properly calls constructors for the class of the temporaries, but doesn't call destructors for them. REPEAT-BY: The following program demonstrates the problem. No fix yet, but we'll start looking immediately because we can't proceed with our work until this is fixed. If anyone comes up with a fix please mail us a copy. Thanks! ----- char *malloc(unsigned int); /* * CLASS FOO */ class foo { int *store; public: foo(int); ~foo(void); friend foo operator+(foo &, foo&); }; inline foo::foo(int n) /* FOO CONSTRUCTOR */ { puts("foo constructor"); store = (int *)malloc(sizeof(*store)); if (store) *store = n; else perror("malloc"); } inline foo::~foo(void) /* FOO DESTRUCTOR */ { puts("foo destructor"); if (store) free(store); } inline foo operator+(foo &a, foo &b) /* FOO OPERATOR + */ { return(*a.store + *b.store); } /* * Trivial main program. * * GNU C++ generates a temporary of type foo to handle the expression to * compute the value of s. A constructor for the temporary is properly * called, but a destructor for it is never called. This is a bug. */ main() { foo a(1), b(2), c(5); foo s = a + b + c; }
casey@CS.UCLA.EDU (10/06/88)
P.S. It's fairly important to our work that stack variables, including compiler temporaries be allocated (constructed) and deallocated (destructed) in ``stack order''. Unfortunately I don't know if anything in the C++ standard says anything about this. Can anyone shed any light on this issue?
schmidt@crimee.ics.uci.edu (Doug Schmidt) (10/07/88)
In article <16551@shemp.CS.UCLA.EDU> casey@CS.UCLA.EDU (Casey Leedom) writes: [ code that breaks g++ 1.27 ] > >inline foo operator+(foo &a, foo &b) /* FOO OPERATOR + */ >{ > return(*a.store + *b.store); >} > If you omit the inline on this function the destructor gets called correctly. (But it is still seems like a bug!) Doug