Re: C++ design question

From: kurth (kurth_at_avanade.com)
Date: 09/29/04 

Date: Tue, 28 Sep 2004 23:11:37 -0600

"H. S. Lahman" <h.lahman@verizon.net> wrote in message
news:q2h6d.3092$OX.3079@trndny07...
> Responding to Elliott...
>
>> I've been advised by the guys over on comp.lang.c++ to post this here
>> to see if anyone can recommend a design improvement. In the following
>> code example, the base class depends on an object in a derived class:
>> fooBase has a reference to an object in fooDerived. It's been pointed
>> out that this is potentially unsafe if bar_base_ref_ is accessed in the
>> fooBase constructor.
>
> I see this as a C++ problem rather than a design problem...
>
>> class fooDerived:public fooBase
>> {
>> private:
>> barDerived my_bar_derived_;
>> public:
>> fooDerived(int i1, int i2):fooBase(my_bar_derived_),
>> my_bar_derived_(42,43){}
>> virtual ~fooDerived(void){};
>> };
>
> It seems to me the basic problem exists in invoking class constructors of
> other objects as if they were attribute assignments. C++ may allow such
> nonsense, but that doesn't mean you have an obligation to shoot yourself
> in the foot. Move both initializations inside the ellipses so that you
> have control over the sequencing:

There are several cases where an initialization list is required.
- call non-default base class constructor
- initialize constant members
- initialize reference members (&)

The initializers are called in the order they are declared rather then the
order listed in the initialization list.

class A {};
class B
{
private:
   B() {} //. no default constructor
public:
  B(int x) {}
};
class S
{
   char buffer[1024];
public:
  S() { memset(buffer, 0, sizeof(buffer)); }
  S(char c) { memset(buffer, c, sizeof(buffer)) }

};
class C : public A, pubic B
{
  S X;
  const char Y;
  S &Z;
  C(S &x, char y) : B(5), Y(y), Z(Y), A() {} {
      X = x;
   }
}

The memory will first be allocated for sizeof(C) (= sizeof(A) + sizeof(B) +
sizeof(S) + sizeof(char) + sizeof(S&)). This memory is uninitialized it
contains whatever happened to be in memory at the time, aka garbage (note:
in debug builds usually memory is zero'd) . The members are then
initialized in the order declared first the base classes and then finally
members of derived class, so the actual initialization looks like A(), B(5),
X(), Y(y), Z(Y), {X.operator=(x)}.

This is why it was unsafe for fooDerived to pass a member to fooBase the
fooDerived's members have not yet initialized (even after construction has
completed it still will not work because fooBase has copied the
uninitialized address).

Notice that Y is const and must be in the initialization list.
Z is a reference and must be in the initialization list.
Additionally Z takes Y as a parameter this will work because Y is
initialized before Z. If we defined C as { S X; S &Z; const char Y; ... }
value of Y would be still be garbage producing undefined results.
Also note that X was implicitly initialized prior to { X = x; } resulting
setting 1024 bytes to 0 unnecessarily, if there was no default constructor
you would have recieved an compile time error. By adding X(x) to the
initialization list the copy constructor would have been invoked rather then
the default constructor initializing it imediatly to the desired char,
rather then the calling the default assignment operator within the {}.
There isn't any difference with buit-in types int and the like because they
are not implicitly initialized as X was.

Initialization lists are actually the recommended method to initialize
members during construction. In some cases they are required and in other
situations they may provide a slight performance beneift. However they can
be difficult to read, and the performance benefit is probably not worth the
added complexity if not well understood by those maintaining it. In
summary, if you need them you have no choice, if they provide a significant
performance benifit use them reluctantly ( clock cycles are cheap these
days), if you can avoid them avoid them.

- Kurt

>
> fooDerived (int i1, int i2)
> {
> this.bar_base_ref_ = (barBase&) my_bar_dervice;
> this.my_bar_derived.setI1(i1);
> this.my_bar_derived.setI2(i2);
> }
>
> Why not invoke the barDerived constructor? Because constructors are
> notoriously fragile and it is wise to do as little as possible inside
> them. A good rule of thumb is to limit them to simple data assignments.
> Explicitly invoking another constructor within a constructor is an
> unnecessary complication. If the initialization of an instance is
> necessarily complex, there should be a separate initializer method that
> separates those rules and policies from the more mundane housekeeping of
> instantiation.
>
> However, I have a more abstract question: Why have both my_bar_derived and
> bar_base_ref_? my_bar_derived is private so there is no issue of it
> being accessed by some external object. Since it is an embedded object,
> it is a matter of private implementation to know that it is a member of
> the barDerived class. Therefore casting of bar_base_ref_ does not risk
> type safety if specialized properties are accessed /within/ fooDerived.
>
> *************
> There is nothing wrong with me that could
> not be cured by a capful of Drano.
>
> H. S. Lahman
> hsl@pathfindermda.com
> Pathfinder Solutions -- Put MDA to Work
> http://www.pathfindermda.com
> blog (under constr): http://pathfinderpeople.blogs.com/hslahman
> (888)-OOA-PATH
>
>
>
>

Relevant Pages

  • Re: Message Builder vs. a Build Method?
    ... Builder class would encapsulate all the complex algorithms for making ... OTOH, as Daniel T. suggests, sometimes the initialization requires unique processing for initialization that is clearly intrinsic to the object itself. ... Constructors tend to be fragile and it is difficult to manage errors when they occur in a constructor scope, so it is usually a good idea to keep the processing in constructors as simple as possible. ... When the initialization of attribute data requires complex processing AND it seems like is intrinsic ot the object, that justifies having a separate initialization method that is invoked immediately after the constructor. ...
    (comp.object)
  • Re: Localization Service
    ... these assets are contents to be edited by the users. ... problem with a validatorFactory. ... I was filling the dictionary on the constructor. ... beware of too much deferred initialization. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Constructor as a "Reset" Button
    ... constructor is more or less just for initialization, ... In PHP you might get ... And HIPPA certification is not easy - nor is it cheap. ...
    (comp.lang.php)
  • Ctor initialization lists: three details beyond the FAQ-lite
    ... 'calling' the base constructor from there, ... Does this mean that it's a small advantage of the initialization ... to use the values of BASE class members to initialize DERIVED ... I know the initialization lists do not support the syntax ...
    (comp.lang.cpp)
  • Re: Initialize an array of classes?
    ... Currently you cannot use member initialization list for a nonstatic array of a class if it does not have a default constructor. ... however you may encounter the warning C4351 and I do not think that it is useful to use such initialization for an array. ... Microsoft Online Community Support ...
    (microsoft.public.dotnet.languages.vc)