home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / std / cplus / 1802 < prev    next >
Encoding:
Text File  |  1992-12-16  |  3.9 KB  |  96 lines
  1. Newsgroups: comp.std.c++
  2. Path: sparky!uunet!mcsun!news.funet.fi!funic!nokia.fi!tele.nokia!girod
  3. From: girod@tele.nokia.fi (Marc Girod)
  4. Subject: Initialization of nonlocal static objects
  5. Message-ID: <GIROD.92Dec16104623@node_262d6.tele.nokia.fi>
  6. Sender: usenet@noknic.nokia.fi (USENET at noknic)
  7. Nntp-Posting-Host: rat.ts.tele.nokia.fi
  8. Reply-To: marc.girod@ntc.nokia.com
  9. Organization: kpd
  10. Distribution: comp
  11. Date: Wed, 16 Dec 1992 08:46:23 GMT
  12. Lines: 82
  13.  
  14. Hello everybody!
  15.  
  16. Abstract:
  17.  
  18. [ARM], 3.4 p 19: "Such initializations [nonlocal static objects] may
  19. be done before the first statement of main() or deferred to any point
  20. in time before the first use of a function or object defined in that
  21. translation unit".
  22.  
  23. In the case described here (below), I would not need anything else but
  24. that initialisation of nonlocal static objects would be carried before
  25. the first statement of main(), and think that I have good reasons not
  26. to want to use any function or object of the translation unit
  27. explicitly priorily (this would defeat my whole purpose!).
  28.  
  29. My experience is that g++ does defer the initialisation, while HP CC
  30. v3.0 seems not to. Are there strong arguments in favour of this freedom
  31. to implementors, or shouldn't this rule be tightened up, in better
  32. conformance with C?
  33.  
  34.  
  35. Detailed description of the case:
  36.  
  37. I have two teams of people, the ones providing with a "system", the
  38. others with "applications" to run on it.
  39.  
  40. The system will receive messages as untyped data from external
  41. processes. The messages have a header though, containing a type id.
  42. Internal events of suitable type should be constructed from the
  43. messages (one message, one event).
  44.  
  45. This is thus a typical "virtual constructor" problem, and the solution
  46. I am working on is the following: in the "interface object" dealing
  47. with external messages, there is a table of pointers to static
  48. objects, one for every event type, which know how to build an event
  49. out of a message (again, for a given type only).
  50.  
  51. How to build this? Well, here are the classes:
  52.  
  53. - A base Event class.
  54.  
  55. - Event classes defined so far: Event1, Event2, Event'n', derived from
  56.   Event.
  57.  
  58. - A base class EvEx (for Event Exemplar, terminology from [Coplien92])
  59.   with as a static member exColl, the table of EvEx*, initialised with
  60.   all the entries pointing to a default (static too) EvEx, dealing
  61.   with unregistered event types.
  62.  
  63. - In every class Event'p', a nested class Ev'p'Ex, derived from EvEx,
  64.   and a static member of this class (member of class Event'p' since
  65.   nested classes may not have static data!). The constructor of
  66.   Ev'p'Ex will add a copy of the 'this' pointer to exColl (already
  67.   initialised, since defined in the base class).
  68.  
  69. This way, I thought that if somebody from the "applications" team
  70. would like to add an event type, say 'n+1', he would have to provide
  71. only a new class Event'n+1' (with its nested class and static member
  72. ev'n+1'Ex) and to modify some objects to be suitable as destinations
  73. for events of this new type, but HE WOULDN'T HAVE TO TOUCH ANY OF THE
  74. "SYSTEM" FILES...
  75.  
  76. This unfortunately fails because the static members are not guarantied
  77. to be initialised before main() is called.
  78.  
  79. Thanks for replies, and help on how to decently turn the problem!
  80.  
  81.  
  82. [Coplien92]: Advanced C++ - Programming styles and idioms
  83.              James O. Coplien
  84.              Addison-Wesley 1992
  85.  
  86. [ARM]:       The Annotated C++ Reference Manual
  87.              Margaret Ellis and Bjarne Stroustrup
  88.              Addison-Wesley 1990
  89. --
  90. +-----------------------------------------------------------------------------+
  91. | Marc Girod - Nokia Telecommunications       Phone: +358-0-511 7703          |
  92. | TL4E - P.O. Box 12                            Fax: +358-0-511 7432          |
  93. | SF-02611 Espoo 61 - Finland              Internet: marc.girod@ntc.nokia.com |
  94. |    X.400: C=FI, A=Elisa, P=Nokia Telecom, UNIT=TRS, SUR=Girod, GIV=Marc     |
  95. +-----------------------------------------------------------------------------+
  96.