home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.lang.c++
- From: nikki@trmphrst.demon.co.uk (Nikki Locke)
- Path: sparky!uunet!pipex!demon!trmphrst.demon.co.uk!nikki
- ReplyTo: nikki@trmphrst.demon.co.uk
- Subject: Re: Default assignment semantics
- References: <BuJs8K.Hzr@vcd.hp.com>
- Distribution: world
- X-Mailer: cppnews $Revision: 1.16 $
- Organization: Trumphurst Ltd.
- Lines: 29
- Date: Tue, 15 Sep 1992 11:43:17 +0000
- Message-ID: <716582597snx@trmphrst.demon.co.uk>
- Sender: usenet@gate.demon.co.uk
-
-
- In article <BuJs8K.Hzr@vcd.hp.com> jm@vcd.hp.com (John Matthews) writes:
-
- > As I understand it, if a class does not have an explicitly defined
- > assignment operator, a default assignment operator is generated
- > by the compiler. This default operator simply does a member-wise
- > assignment. As has been pointed out many times, these semantics
- > are dangerous for classes that have pointers to dynamically created
- > objects as fields.
- >
- > It seems to me that a more robust default assignment operator would
- > have the following semantics:
- >
- > 1) Invoke the destructor of the object being assigned to.
- > 2) Invoke the copy constructor on the object being assigned
- > to, taking as an argument the object being assigned from.
- >
- The problem with this is that it introduces the most common assignment
- operator bug. Try it with ...
-
- String a"(Hello");
-
- a = a;
- ---
- Nikki Locke | | nikki@trmphrst.demon.co.uk
- Trumphurst Ltd. | Tel: +44 (0)691-670318 | nikki@cix.compulink.co.uk
- PC and Unix consultancy | Fax: +44 (0)691-670316 | nikki@kewill.co.uk
- trmphrst.demon.co.uk is NOT affiliated with ANY other sites at demon.co.uk.
- Demon.co.uk is a dial-up subscription access point to the Internet.
-