Xref: utzoo comp.lang.c++:13594 comp.std.c++:926 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!dali.cs.montana.edu!uakari.primate.wisc.edu!sdd.hp.com!cs.utexas.edu!radar!cadillac!dsouza From: dsouza@gwen.cad.mcc.com (Desmond Dsouza) Newsgroups: comp.lang.c++,comp.std.c++ Subject: Re: Constructor Limitation: [Was: Re: Constructor question] Message-ID: Date: 22 May 91 18:19:58 GMT References: <1991Apr2.110623.22219@and.cs.liv.ac.uk> <20164@alice.att.com> <1991Apr18.005426.21863@dragon.wpd.sgi.com> <71952@microsoft.UUCP> <72461@microsoft.UUCP> Sender: news@cadillac.CAD.MCC.COM Organization: MCC CAD Program, Austin, Texas Lines: 43 In-reply-to: jimad@microsoft.UUCP's message of 20 May 91 20:59:57 GMT In article <72461@microsoft.UUCP> jimad@microsoft.UUCP (Jim ADCOCK) writes: > You cannot compute any temporaries (e.g. common subexpressions) > which are needed for initialization of such data members. Consider: ---- int F1(int j) { /* something really really big and horrible here */ return j;} class A { public: A(int m, int n); }; class B { public: B (int j); private: int f1; A a1; // initialized with F1(j), F1(j)+1 for some horribly complex F1 }; B::B(int j) // how can I share the computation of F1(j) here ??? !!! Try the following: : f1(F1(j)), a1(f1, f1+1) { // this part does not help: I cannot modify a1 at this point. } No good. You cannot afford to add a data member per object instance to simply store an intermediate constructor variable. (There is also the subtle point about order of initialization of data members -- it follows the order in the class definition, so you had it right). -- Desmond. -- ------------------------------------------------------------------------------- Desmond D'Souza, MCC CAD Program | ARPA: dsouza@mcc.com | Phone: [512] 338-3324 Box 200195, Austin, TX 78720 | UUCP: {uunet,harvard,gatech,pyramid}!cs.utexas.edu!milano!cadillac!dsouza