gamiddleton@orchid.UUCP (08/06/87)
As far as I can tell, the following fragment should be (syntactically)
correct:
class zot {
int *x;
public:
zot( zot & );
~zot() { delete x; }
};
void zot::zot( zot &z ) {
x = new (int);
*x = *z.x;
}
When I compile it, I get:
ccc zot.cc:
"zot.cc", line 11: error: zot ::zot () with return type
1 error
It works fine if zot::zot() is left undeclared (leaving 'void' out).
What am I missing? Or is this a bug?
__
-Guy Middleton, University of Waterloo Institute for Computer Research
gamiddleton@math.waterloo.edu, watmath!gamiddleton, gamiddleton@water.bitnetark@alice.UUCP (08/07/87)
In article <10120@orchid.waterloo.edu>, gamiddleton@orchid.UUCP writes: > As far as I can tell, the following fragment should be (syntactically) > correct: > > class zot { > int *x; > public: > zot( zot & ); > ~zot() { delete x; } > }; > > void zot::zot( zot &z ) { > x = new (int); > *x = *z.x; > } A constructor never returns a value, so one does not ever declare the type of its value. Thus one says class foo { public: foo(); }; and not class foo { public: void foo(); }; Similarly, one just writes foo::foo() { } and not void foo::foo() { }
gamiddleton@orchid.UUCP (08/08/87)
In article <10120@orchid.waterloo.edu> gamiddleton@orchid.waterloo.edu (Guy Middleton) writes: > As far as I can tell, the following fragment should be (syntactically) > correct: > > [some stuff with constructors ... ] > > It works fine if zot::zot() is left undeclared (leaving 'void' out). > What am I missing? Or is this a bug? Several helpful people have pointed out that constructors do not have types, not even 'void'. In that case, it wasn't a *completely* dumb question, since the example I used (at the top of page 180 of the C++ book) has the same error. __ -Guy Middleton, University of Waterloo Institute for Computer Research gamiddleton@math.waterloo.edu, watmath!gamiddleton, gamiddleton@water.bitnet
cxv@csadfa.oz (Christopher Vance) (08/11/87)
in article <7164@alice.UUCP>, ark@alice.UUCP says: > > In article <10120@orchid.waterloo.edu>, gamiddleton@orchid.UUCP writes: [ omitted ] > > A constructor never returns a value, so one does not ever > declare the type of its value. Thus one says > > class foo { > public: > foo(); > }; > > and not > > class foo { > public: > void foo(); > }; `void' (in an ordinary function declaration) means precisely that there is no value returned. Omitting `void' normally means that a function returns an `int'. The intended meaning is unambiguous and correct. Any incorrectness is due: 1) to use of a similar but slightly different syntax for constructors and member functions; and/or 2) to the use of `char' (sometimes? always?) to represent `void'. > Similarly, one just writes > > foo::foo() { } > > and not > > void foo::foo() { } There is an inconsistency, unless one makes the distinction between constructors and ordinary member functions more explicit. A quick look shows that the book does not deal with this point as clearly as it could -- maybe in the fine print. I'll try to suggest a way of explaining the distinction which make the current usage seem more sensible. A destructor has a distinguished declaration syntax, and therefore cannot be confused with an ordinary member function. It definitely returns no value, and so conceptually returns `void', but since it always appears to be invoked implicitly, and never explicitly, we are off the hook. A constructor could be seen as a member function which has a type (its class type), but no function name; or again as a function where the type and name are elided together because they are identical. Unlike a destructor, its declaration and definition CAN be confused with an ordinary member function, and usually has the appearance of being called explicitly. Moreover, it always returns (or constructs) a value by definition, even though the body (of the constructor) doesn't have to say so, since it ends with an implicit `return this'. Perhaps it also needs some distinguishing syntax, rather than just relying on a coincidence of names. Whether it should be seen as returning `void' or the class name type is another matter. It seems to me that defining `void' to mean `char' is just plain wrong if your C compiler already knows that `void' means `no value'. Does C++ use the (ordinary) C compiler defined `void' if it is implemented? Surely most compilers are going this way, as the standardisation process continues. [I haven't looked at this myself because we haven't yet managed to obtain C++; although we have been trying for a while. Apparently we have to deal through AT&T Japan. "Hello? Is anyone there?"] -- Christopher J.S. Vance | cxv@cs.adfa.oz[.au] | gateways: Commun. ACM, Oct. 86
cxv@csadfa.oz (Christopher Vance) (08/13/87)
In article <1097@csadfa.oz>, I said: > .... [I > haven't looked at this myself because we haven't yet managed to obtain C++; > although we have been trying for a while. Apparently we have to deal through > AT&T Japan. "Hello? Is anyone there?"] It seems I was mistaken. We do indeed have the release tape, but the fact wasn't advertised here because we've haven't yet received the Pyramid mods (from another site in Australia), and because our programmer doesn't know how long it'll take to put up. Rule #1: check facts before firing. Sigh. -- Christopher J.S. Vance | cxv@cs.adfa.oz[.au] | gateways: Commun. ACM, Oct. 86