NetNews Usenet Archive 1992 #16/NN_1992_16.iso/spool/comp/lang/cplus/11813

Internet Message Format | 1992-07-30 | 2.0 KB

Path: sparky!uunet!olivea!bu.edu!news.bbn.com!mips2!granite.ma30.bull.com!horvath
From: [e-mail] (John Horvath)
Newsgroups: comp.lang.c++
Subject: Design of Constructors
Message-ID: <[e-mail]>
Date: 30 Jul 92 21:19:45 GMT
Sender: [e-mail] (Usenet News Manager)
Organization: Bull HN Information Systems Inc.
Lines: 34
Originator: [e-mail]

Executive summary: If constructors can't return values, is it their intent
they should not try to do anything that can fail?
-----

  Constructors are suppose to be the place were a class's
initialization takes place. Since they can't return a value (directly),
it seems that the only initialization that they should be doing is
stuff that can't fail. (e.g. they shouldn't do things like memory
allocation, open files or access devices). In the FAQ for this group,
it mentions that one possibility for solving a failed constructor is to
include a status data member that indicates if the class is "alive" or
not. Later, other class functions can check if the class is active
before doing any action.
  This seems a little contradictory (shifting initialization checking
to functions who should only be doing their functional purpose). I'm
trying to resolve, for myself, the intended purpose of this limitation
to constructors. If the constructor involves actions that could fail,
should they instead be included in a separate function that can
initialize the class? Something like an activate function that can
return a failed status? But this requires that the class usage has an
explicit protocol which doesn't seem to fit in with my perception of
the "information hiding" paradigm.

       constructor (simple initialization)
       activator (completes initialization with error return)
       action_function (can assume activator successful)

  I understand how throw & catch can solve this, but I think that using
them still hides the basic question about why constructors were
designed with this restraint.


john horvath
internet: [e-mail]