home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.lang.c++
- Path: sparky!uunet!charon.amdahl.com!pacbell.com!mips!sdd.hp.com!wupost!m.cs.uiuc.edu!sunb10.cs.uiuc.edu!sparc10.cs.uiuc.edu!pjl
- From: pjl@sparc10.cs.uiuc.edu (Paul Lucas)
- Subject: Re: Return values for constructors.
- Message-ID: <1992Aug19.165125.25338@sunb10.cs.uiuc.edu>
- Sender: news@sunb10.cs.uiuc.edu
- Organization: University of Illinois at Urbana-Champaign
- References: <3474@unisql.UUCP>
- Date: Wed, 19 Aug 1992 16:51:25 GMT
- Lines: 36
-
- In <3474@unisql.UUCP> nandraj@unisql.UUCP (Nandraj Arni) writes:
-
- [ stuff about ctors returning values ]
-
- > One way would be like this:
-
- > Foo *p;
-
- > int return_value = new p(...); // not allowing Foo *p = new Foo(...);
- > // This could be invalid assingment...
-
- *****> Huh? So where does the pointer to the object go? You'll get
- your return-value, but lose the object you just created. Not
- very useful.
-
- > And for others:
- >
- > float value; // This does not have a value, even objects
- > // should be like that.
-
- > So other way would be:
-
- > Foo p;
-
- > int return_value = p(...);
-
- *****> Similarly, this would create an unnamed object that would be
- destroyed immediately. Again, not very useful.
-
- Anyway, functions, and ctors if ther were allowed to have return-
- types, are insufficient to distinguish when overloading is
- concerned.
- --
- - Paul J. Lucas University of Illinois
- AT&T Bell Laboratories at Urbana-Champaign
- Naperville, IL pjl@cs.uiuc.edu
-