Topic: Problems with current 'main


Author: alfps@start.no ("Alf P. Steinbach")
Date: Wed, 22 Nov 2006 23:20:10 GMT
Raw View
* tasjaevan@gmail.com (is that /you/, James?  and if so, which James?):
>
> On Nov 22, 12:26 am, rdnewsNOSPAM2...@sbcglobal.net ("Tony") wrote:
>> ""Alf P. Steinbach"" <a...@start.no> wrote in messagenews:4sflo4Fvec3aU1@mid.individual.net...
>>
>>> Problems: (A) having 'main' singled out as "the" startup function forces a
>>> 'main'-centered design, especially with respect to dynamic initialization
>>> of statics, where only those appearing in 'main's translation unit are
>>> guaranteed to occur before 'main' is entered,
>>>
>>Only POD's I believe. Class objects are another story (?).
>
> No. File-scope POD objects do not have dynamic initialisation.
>
> File-scope user-defined objects requiring dynamic initialisation are
> guaranteed to be constructed before any function in a translation unit
> is called. Hence, those objects lucky enough to share a translation
> unit with main are guaranteed construction before main.
>
> I disagree with Alf that this forces a 'main'-centred design. That
> pre-supposes a design based around globals, and even in a such a
> design, it would be better to use singletons.

I was mainly thinking of singleton actions (if I may be allowed to
invent terminology, I mean single, guaranteed actions) at startup.

But I framed it in terms of what you call globals (OK, I also use that
term): no need to go abstract or complicated, I thought.

Consider the problem of extensible deserialization.  We want object
factory functions for new types added by client code, to install
themselves in the deserialization code's factory function repository.
The natural way to do that for a type T is locally in a translation unit
dedicated to T:

   namespace
   {
      struct ModuleEnvelope
      {
          ModuleEnvelope() { installFactoryFunction(); }
      };

      ModuleEnvelope envelope;
   }

The deserialization code has no dependency on this translation unit: it
only uses the factory repository.

To make this work with C++ an artificial dependency has to be
introduced, and to be very sure and avoid a mess where one looses sight
of which artificial dependency is added in which arbitrary location, the
artifical dependency must be introduced in main's translation unit.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]