From -53260457939814805 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,f5d433881cc29cff X-Google-Attributes: gidf78e5,public From: Jason Merrill Subject: Re: Named return value optimisation- reprise. Date: 1997/06/19 Message-ID: #1/1 X-Deja-AN: 250997497 References: <1.5.4.32.19970618041515.0069daac@mail.ipswich.gil.com.au> X-Original-Date: 18 Jun 1997 11:15:06 -0700 Organization: Cygnus Solutions, Sunnyvale, CA X-Auth: PGPMoose V1.1 PGP comp.std.c++ iQBFAgUBM6iUpeEDnX0m9pzZAQHpVgGAiAPDQpbADKDD5urtQbbpTCjDNJMQNgpf SNbExF+tuSRSIorOOAcX9KlNLXWrLwqz =pqIq Newsgroups: comp.std.c++ Originator: fjh@mundook.cs.mu.OZ.AU >>>>> Brian Parker writes: > Martin D Kealey wrote: >> What it means in terms of coding is that assignment and copy-constructors >> should be idempotent, and should provide either value or reference >> semantics, but not both. If both are required, then *two* classes >> should be used. > I don't agree that these design rules are similar to, say, not returning a > reference to a local as that is a well defined life-time issue, but ensuring > value/reference semantics is a vague design rule. Try defining a precise > definition of "value-semantics" that could be added to the draft- once one > starts using garbage-collection techniques and sharing storage in a complex > fashion the issue is not so clear cut. There's no need to define "value-semantics" in the draft; it is enough for the draft to say that a program may not rely on the copy constructor being called in (N)RVO situations. David Vandevoorde's version of valarray is a good example of the value/reference split. Jason --- [ comp.std.c++ is moderated. To submit articles: try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ FAQ: http://reality.sgi.com/employees/austern_mti/std-c++/faq.html ] [ Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ] [ Comments? mailto:std-c++-request@ncar.ucar.edu ]