home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.lang.c++
- Path: sparky!uunet!microsoft!hexnut!jimad
- From: jimad@microsoft.com (Jim Adcock)
- Subject: Re: Renew?
- Message-ID: <1992Jul30.172824.7760@microsoft.com>
- Date: 30 Jul 92 17:28:24 GMT
- Organization: Microsoft Corporation
- References: <memo.547224@cix.compulink.co.uk> <23347@alice.att.com>
- Lines: 22
-
- In article <23347@alice.att.com> ark@alice.UUCP () writes:
- |If renew guarantees to the user that the copy constructor and
- |destructor will be called for each object moved, that greatly
- |ameliorates the situation. It is then sufficient for the user to
- |get those two functions right, or make them private (which would
- |prohibit renew on objects of that class).
-
- Not sufficient, also the programmer has to make sure not to have
- any interior pointers to objects in the array. Because C++ *still* wouldn't
- have support for "move"able objects. What it would have then would be
- support for constructing a new array of objects based on a previous
- array of objects which are destroyed in the process.
-
- For C++ to allow programmers to "move" objects would require language
- support for identifying pointers at runtime, and "patching" those pointers
- and/or refs to refer to objects' new locations. This is a good idea IMHO,
- and is necessary for effective GC and OODB. The central problem then becomes
- the inability to support the historic "C" hack of casting pointers to/from
- ints. This problem and others lead to the idea that such an approach would
- require a Modula-3-like split of the C++ programming world into "safe"
- verses "unsafe" parts.
-
-