home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / lang / cplus / 12570 < prev    next >
Encoding:
Text File  |  1992-08-19  |  1.4 KB  |  48 lines

  1. Newsgroups: comp.lang.c++
  2. 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
  3. From: pjl@sparc10.cs.uiuc.edu (Paul Lucas)
  4. Subject: Re: Return values for constructors.
  5. Message-ID: <1992Aug19.165125.25338@sunb10.cs.uiuc.edu>
  6. Sender: news@sunb10.cs.uiuc.edu
  7. Organization: University of Illinois at Urbana-Champaign
  8. References: <3474@unisql.UUCP>
  9. Date: Wed, 19 Aug 1992 16:51:25 GMT
  10. Lines: 36
  11.  
  12. In <3474@unisql.UUCP> nandraj@unisql.UUCP (Nandraj Arni) writes:
  13.  
  14. [ stuff about ctors returning values ]
  15.  
  16. >   One way would be like this:
  17.  
  18. >   Foo *p;
  19.  
  20. >   int return_value = new p(...); // not allowing Foo *p = new Foo(...);
  21. >                  // This could be invalid assingment...
  22.  
  23. *****>    Huh?  So where does the pointer to the object go?  You'll get
  24.     your return-value, but lose the object you just created.  Not
  25.     very useful.
  26.  
  27. >   And for others:
  28. >   float value;        // This does not have a value, even objects
  29. >               // should be like that.
  30.  
  31. >   So other way would be:
  32.  
  33. >   Foo p;
  34.  
  35. >   int return_value = p(...);
  36.  
  37. *****>    Similarly, this would create an unnamed object that would be
  38.     destroyed immediately.  Again, not very useful.
  39.  
  40.     Anyway, functions, and ctors if ther were allowed to have return-
  41.     types, are insufficient to distinguish when overloading is
  42.     concerned.
  43. -- 
  44.     - Paul J. Lucas                University of Illinois    
  45.       AT&T Bell Laboratories        at Urbana-Champaign
  46.       Naperville, IL            pjl@cs.uiuc.edu
  47.