jeenglis@nunki.usc.edu (Joe English) (04/10/89)
Wouldn't it make sense to be able to overload operators new
and delete for class objects than to have to assign to
'this' in the constructors and destructor? Also, if
operator delete could be overloaded, it would obviate the
need in the destructor to find out if the object was
dynamically or statically allocated.
The Book says that operators new and delete may be overloaded,
but it doesn't say exactly how. I tried
overload operator delete;
overload operator new;
void operator delete (myclass *); // this makes sense to me
myclass * operator new (void /* what goes here??? */);
but my compiler (Zortech 1.06) wouldn't take it. (It choked on
the overload declarations, and complained about redefining _new
and _delete when I removed them).
I also tried
class myclass {
...
myclass *operator new(void /* again, what should go here? */);
void operator delete(myclass *);
...
};
which the compiler accepted, but apparently ignored entirely.
I haven't tried either method on gcc yet.
So, what's the story? Is it possible to do what I'm trying to do,
and will it be possible in future definitions of C++?
While I was experimenting with this, I found what seem to be
bugs in Zortech C++ version 1.06. Those who don't use (and
didn't write :-) Zortech can skip this part...
The program in question was testing an implementation of
class string.
BLINK couldn't find _vec_delete(); I had to link vector.obj
directly. (I've had this problem before, but I understand it's
been fixed in 1.07).
Examining the assembly code, I found that it never called
_vec_new or otherwise initialized a 3-D array of strings.
string::string(void) was declared and in scope.
Constructors for which tried to overload the standard
allocator by assigning to 'this' in the function body still
compiled a call to _new() at the start of the function.
(This ended up fixing the program though, since my allocator
got called when _new failed...)
The destructor behaved properly, although the optimizer didn't
take out the call to _delete even though it was always skipped.
That's no big deal; I was just surprised since it's usually much
smarter.
Are these known problems, and have they been fixed in 1.07 (which
I'm going to buy any day now...)? Also, what is the official
procedure for reporting bugs? (I know Walter reads this
newsgroup, so I figured that here was as good as anywhere
else...)
I should mention that I'm very happy with Zortech C++; these are
the first serious problems I've encountered. I've been using it
for several months now and it's made my life *much* easier.
Thanks,
--Joe English
jeenglis@nunki.usc.eduark@alice.UUCP (Andrew Koenig) (04/10/89)
In article <3439@nunki.usc.edu>, jeenglis@nunki.usc.edu (Joe English) writes: > Wouldn't it make sense to be able to overload operators new > and delete for class objects than to have to assign to > 'this' in the constructors and destructor? Yes. Stay tuned for AT&T C++ 2.0. -- --Andrew Koenig ark@europa.att.com
hearn@claris.com (Bob Hearn) (04/11/89)
From article <3439@nunki.usc.edu>, by jeenglis@nunki.usc.edu (Joe English): > > Wouldn't it make sense to be able to overload operators new > and delete for class objects than to have to assign to > 'this' in the constructors and destructor? Also, if > operator delete could be overloaded, it would obviate the > need in the destructor to find out if the object was > dynamically or statically allocated. A recent language extension allows overloading of new and delete. New takes a long arg specifying size (since derived classes may be larger). Overloading new and delete is different from other overloading in that applications of new to types which don't have new overloaded always use the global new, regardless of scope. But this is only natural; from a programmer's point of view new is not really an operator anyway, it is a language construct. Other recent extensions include multiple inheritance, pointers to member functions, protected members, and overloading the -> operator. I don't know which, if any, of these extensions the Zortech compiler implements. For more info, see "The Evolution of C++: 1985 to 1987," if you can find it anywhere. Bob Hearn hearn@claris.com
bertil@isy.liu.se (Bertil Reinhammar) (04/11/89)
In article <9175@alice.UUCP> ark@alice.UUCP (Andrew Koenig) writes: [Other discussion cut] > >Yes. Stay tuned for AT&T C++ 2.0. >-- > --Andrew Koenig > ark@europa.att.com Ah ! Would anybody please be so very kind as to tell when this AT&T C++ 2.0 is expected be deliverable. -- Bertil Reinhammar Dept. of Electrical Engineering ...!uunet!mcvax!enea!rainier!bertil University of Linkoping, Sweden bertil@isy.liu.se
prl@iis.UUCP (Peter Lamb) (04/12/89)
In article <9175@alice.UUCP> ark@alice.UUCP (Andrew Koenig) writes: > >Yes. Stay tuned for AT&T C++ 2.0. > --Andrew Koenig > ark@europa.att.com Until I turn old and grey? (only 1/2 a :-) . I was last told release date 89Q3 by AT&T Unix Europe. I have been told earlier (already past) release dates by the same people. -- Peter Lamb uucp: uunet!mcvax!ethz!prl eunet: prl@ethz.uucp Tel: +411 256 5241 Integrated Systems Laboratory ETH-Zentrum, 8092 Zurich