paul@mtnmath.UUCP (paul) (09/27/90)
The following code is compiled by HCR's (SCO Canada) and Comeau's C++
compilers without a whimper. (These are ports of AT&T's code versions
2.0 and 2.1 respectively.)
class Example {
char * Point ;
public:
Example(char * point) {point=Point;}
};
There are two errors that it would be helpful to flag with
warning messages.
1. Member variable `Point' is used before it is set.
2. Constructor parameter `point' which is not a reference
is set before it is used.
The latter message could apply to any subroutine definition, while
the former is only valid for constructors.
Is there some reason warnings of this sort should not be given?
If not it would be a helpful addition for those of us who are
slightly dislexix and make the above error with infrequent but
painful regularity.
Paul Budnik
Mountain Math Software
(408) 353-3989
uunet!mtnmath!paulpal@xanadu.wpd.sgi.com (Anil Pal) (09/27/90)
In article <2@mtnmath.UUCP>, paul@mtnmath.UUCP (paul) writes: |> class Example { |> char * Point ; |> public: |> Example(char * point) {point=Point;} // NOTE inverted intialization! |> }; One helpful hint to avoid this problem is to initialize the variables the way you would call a base class constructor, rather than in the body of the constructor. Thus class Example { char * Point ; public: Example(char * point) : Point(point) {} }; With this syntax, interchanging the two will cause an error at compile time. As a subtle point, this also *initializesa* Point, rather than *assigning* to it. This is irrelevant for a char*, but makes a difference for consts, references, and user-defined classes where initialization and operator= are different. Anil A. Pal, Silicon Graphics, Inc. pal@sgi.com (415)-335-7279
steve@taumet.com (Stephen Clamage) (09/27/90)
paul@mtnmath.UUCP (paul) writes: >class Example { > char * Point ; >public: > Example(char * point) {point=Point;} >}; >There are two errors that it would be helpful to flag with >warning messages. > 1. Member variable `Point' is used before it is set. > 2. Constructor parameter `point' which is not a reference > is set before it is used. >The latter message could apply to any subroutine definition, while >the former is only valid for constructors. >Is there some reason warnings of this sort should not be given? No reason at all. Some compilers do warn about these kinds of errors. Oregon C++ (not an AT&T port) typically warns about variables used before being set, but does not in this particular instance. Turbo C++ (not an AT&T port) warns about parameter "point" not being used, which is a more correct statement than your #2 above. Both compilers were derived from earlier compilers which did some flow analysis to detect local variables used before being set. The case of a data member used before being set in a constructor requires a different sort of test, and was evidently overlooked in these two compilers. Non-dyslexics can also make the sort of error you have here, and it is worth checking for, as a "quality of implementation" compiler issue. However, this example is also an argument for choosing distinct names, rather than "Point" and "point" which are easily confused. -- Steve Clamage, TauMetric Corp, steve@taumet.com
roger@procase.UUCP (Roger H. Scott) (10/02/90)
I would like to reinforce the suggestion that *all* class members be
*initialized* in constructors using *initialization* (not assignment) syntax.
While this is not always possible (due to the need to do non-trivial
computation in order to generate the actual member values), it often possible.
I find that many of my constructors have empty "{}" bodies, since all they
do is initialize members and subclasses.vaughan@mcc.com (Paul Vaughan) (10/04/90)
From: roger@procase.UUCP (Roger H. Scott)
I would like to reinforce the suggestion that *all* class members be
*initialized* in constructors using *initialization* (not assignment) syntax.
While this is not always possible (due to the need to do non-trivial
computation in order to generate the actual member values), it often possible.
I find that many of my constructors have empty "{}" bodies, since all they
do is initialize members and subclasses.
I've been tending to use the initialization form more and more, but I
don't really have a good reason for why I should do that. A simple
argument against using the initialization form is that you have to
initialize members for each constructor, where assignments are
conveniently swept into an init function called by each constructor.
And as is pointed out above, you have to decide first whether it's
even feasible. So, how do you (anybody who is reading this) justify
this opinion?
Paul Vaughan, MCC CAD Program | ARPA: vaughan@mcc.com | Phone: [512] 338-3639
Box 200195, Austin, TX 78720 | UUCP: ...!cs.utexas.edu!milano!cadillac!vaughandlw@odi.com (Dan Weinreb) (10/04/90)
In article <11745@cadillac.CAD.MCC.COM> vaughan@mcc.com (Paul Vaughan) writes:
I've been tending to use the initialization form more and more, but I
don't really have a good reason for why I should do that.
For some types in your program you might have an operator= that has
non-trivial cost; by using the initialization form instead of
assigning data member variables from argument variables, you can avoid
that cost, for such types. I have seen this arise in practice in a
few places. I realize that this is a special case.rae@gpu.utcs.toronto.edu (Reid Ellis) (10/05/90)
Paul Vaughan <vaughan@mcc.com> writes: >I've been tending to use the initialization form more and more, but I >don't really have a good reason for why I should do that. If you ever pass your object X to a function/method that expects a "(const X)" and you use '=' to initialize your fields, then you can't call that function. It fails when it tries to construct a const X since the constructor is attempting to use '=' on a const object. Usually this doesn't come up since you would typically pass "(const X &)" instead, but I thought I'd point it out. Reid -- Reid Ellis 264 Broadway Avenue, Toronto ON, M4P 1V9 Canada rae@gpu.utcs.toronto.edu || rae%alias@csri.toronto.edu || +1 416 487 1383
roger@procase.UUCP (Roger H. Scott) (10/06/90)
In article <11745@cadillac.CAD.MCC.COM> vaughan@mcc.com (Paul Vaughan) writes: >... >A simple argument against using the initialization form is that you have to >initialize members for each constructor, where assignments are >conveniently swept into an init function called by each constructor. >And as is pointed out above, you have to decide first whether it's >even feasible. So, how do you (anybody who is reading this) justify >this opinion? Your argument holds some water with respect to members, but doesn't apply to superclass (base class) initialization, which still must be done in each constructor. The need to repeat such initialization (both for superclasses and for members) is unfortunate. A couple of years ago I suggested to AT&T a small generalization of the language that would alleviate this problem: just as the constructor for a derived class can invoke a constructor for a base class, one constructor for a given class should be able to invoke another constructor of that same class using the identical syntax, e.g. class Base { public: Base(char *, int, int); protected: ... // member data }; class Derived : public Base { public: Derived(char *p, int i, int j, int k) : Base(p, i, j), myFoo(i + k), myBar(j + k) { } Derived(char *p) : Derived(p, 0, 0, 1) {} // build on the first one Derived() : Derived("default") {} // build on the second one protected: int myFoo, myBar; }; IMHO the preponderence of init() member functions in C++ classes throughout the world is clear evidence of a problem in the language.