Xref: utzoo comp.lang.c++:13827 comp.std.c++:949 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!mintaka!bloom-beacon!eru!hagbard!sunic!chalmers.se!appli!niklas From: niklas@appli.se (Niklas Hallqvist) Newsgroups: comp.lang.c++,comp.std.c++ Subject: Re: Constructor Limitation: [Was: Re: Constructor question] Message-ID: <1389@appli.se> Date: 2 Jun 91 01:33:01 GMT References: Followup-To: comp.lang.c++ Organization: Applitron Datasystem AB, GOTHENBURG, SWEDEN Lines: 95 pena@brainware.fi (Olli-Matti Penttinen) writes: :In article marc@mit.edu (Marc Horowitz) writes: : [ lotsa stuff zapped ] : 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. :Do you ever use f for anything but to initialize or change the value :of some A. If not, then f would really belong in A. In anycase, why :not add A::A(const char *); that uses f to compute the 4 ints. :Besides, Bjarne's proposal to use a protected init-method works well, :too, iff A has a default constructor. Admittedly, things might get a :little dirty if an A cannot have a meaningful state constructed out of :nothing. In that case, one could (accidentally) use the value of an A :before the object is fully constructed, so the problem would still be :there. :All in all, I don't see a reason to extend the language just because :a new feature would occasionally save a few keystrokes. : [ more text deleted ] You forgot to read the requirements of the problem. The class A and the function f could not be altered (probably due to a binary only license of some library). The way to do this is of course by using MI, private inheritance and the well-known dependence of base class declaration order ;-) class A { public: A(int a, int b, int c, int d); // ... }; void f(const char* s, int* a, int* b, int* c, int* d); class B_helper { protected: int a, b, c, d; B_helper(const char* s) { f(s, &a, &b &c, &d); } }; class B : private B_helper, public A { public: B(const char* s) : B_helper(s), A(a, b, c, d) { /* usual code */ } // ... }; This code is untested by me, but I did send this suggestion to Marc a few days ago, and as he has not (yet) replied negatively, I suppose it works. If it does, this should be general enough to solve any problem of this kind, isn't it so? Marc! I got your reply, have you tested this code yet? Niklas -- Niklas Hallqvist Phone: +46-(0)31-40 75 00 Applitron Datasystem Fax: +46-(0)31-83 39 50 Molndalsvagen 95 Email: niklas@appli.se S-412 63 GOTEBORG, Sweden mcsun!sunic!chalmers!appli!niklas