Xref: utzoo comp.lang.c++:13707 comp.std.c++:939 Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!decwrl!deccrl!bloom-beacon!bloom-picayune.mit.edu!news.mit.edu!marc From: marc@mit.edu (Marc Horowitz) Newsgroups: comp.lang.c++,comp.std.c++ Subject: Re: Constructor Limitation: [Was: Re: Constructor question] Message-ID: Date: 27 May 91 18:09:43 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> euaeny@eua.ericsson.se (Erik Nyquist) writes: dsouza@gwen.cad.mcc.com (Desmond Dsouza) writes: >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. I don't say that we should change the language, but how can we solve this problem without language extensions? We could also ask ourselves if we really should try to solve this problem. That surely depends on how common it is! I posted to comp.lang.c++ last night with almost exactly the same problem. A local friend mentioned that this issue had been recently discussed, so I'm responding to that original post. I I'll start by saying that this problem should definitely be looked at. It apparently happens at least somewhat often, since it happened to me last night. I had an even more difficult situation. My classes look like this: class A { public: A(int a, int b, int c, int d); // ... }; class B : public A { public: B(char *s) :A(/* ??? */) { /* too late */ } // ... }; void f(const char *s, int *a, int *b, int *c, int *d); f takes a string, and parses the integers out of it. It's somewhat expensive. Now, how should I go about doing this? Every solution I've been able to come up with is a morally abhorrent kludge involving some large number of static variables. I really would like to be able to have a block where I could define a few local temporaries, call f, and pass those temps into the base constructor. I could add another constructor to A, but A shouldn't need to depend on f, since f is really a part of B. Also note that subclassing won't help, since the arguments to A aren't functions of a common temporary, as f(x) and f(x)+1 are in the original example. I agree with Desmond: this seems like a definite flaw in the language. Someone mentioned that adding another block where temporaries could be created could result in programmers accidentally thinking the object was constructed while writing code in this block. I think this problem is solvable. If the block is in a scope similar to that of a static member function (e.g., ``this'' is not defined), then any use of a non-static member is an error. I think this is the way it should be, and is not overly restrictive. As long as someone can come up with a non-ambiguous syntax, it doesn't seem that code generation should be too difficult, either. Marc -- Marc Horowitz 617-253-7788