In article <44j7pn$ca9@oznet07.ozemail.com.au>,
John Max Skaller <maxtal@suphys.physics.su.oz.au> wrote:

>engr@gssi.MV.COM (MichaelFurman) wrote:
>>   Reading some answers in C++ newsgroups and ARM I found that feature that
>>I am using is not supported by C++ draft standard. I rely on fact that all
>>static class instances in the program will be initialized (by calling
>>appropriate constructors) before executing "main" function. I do not know
>>how to implement what I want (see below) without it.
>[]
>>   If initialization can be "deferred to any point in time before the first
>>use a function or object defined in that translation unit" (as described in
>>ARM and I believe - I do not have it with me - in draft standard) - I can
>>not implement this strategy at all because in main part of software I do not
>>know which translation units - drivers - I have. It seams to me that I can
>>not avoid recompilation of some file and I have to change that file each
>>time I implement a new driver.
>
>   Not true. You cannot implement PORTABLE code that way. You CAN
>rely on a particular compiler though.

Either I can rely on another language e. t. c.
Seriously, of cause, in my particular program I am relying on compiler(s)
I have and I do not think I will have a trouble in nearest future. But reason
of my post is not a solving my problem, but discussing features of C++.

> If you are implementing
>device drivers, this might not be so much of a problem.

It is not necessary device drivers - they may be modules of any expandable
system.

>
>>
>>My questions:
>>
>>1. What is a reason of allowing it to be deferred.
>
>     Dynamic Link Libraries.
>
>>2. May be I just don't see how to implement it better, without relying on
>>this unsupported fact (actually all compilers I know do it before calling
main)
>.
>
>     The correct way to implement it requires writing an initialisation
>module which DOES know what drivers are to be supplied. To avoid
>writing it out by hand all the time, write a program to generate
>this initialisation function from information obtained somehow
>from a specication file describing the available drivers.

The problem is that is no portable form of such specification file
(it may be only input data for linker or executable program file). And there
is no portable way to do something with this information. And it is
nothing with C++.
>
>>3. If not - may be it is possible to consider changing the standard.
>
>    This topic has been discussed many times: the current situation
>is not entirely satisfactory. Unfortunately, any solution appears
>to require a language extension.

Yes, I understand it. But all we need - just to mark somehow definitions
of objects that has to be initialized before executing "main". May be some
existant language attribute can be used? Global scope? No - it would prevent
optimisation based on virtual memory. "Const"? Do anybody have an idea?

        Regards,
                        Michael Furman
----------------------------------------------------------------------------
--------
Michael Furman,                                   (603)893-1109
Geophysical Survey Systems, Inc.              fax:(603)889-3984
13 Klein Drive - P.O. Box 97                      engr@gssi.mv.com
North Salem, NH 03073-0097                        71543.1334@compuserve.com
----------------------------------------------------------------------------
--------


[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

In article <199510021604.MAA10538@mv.mv.com>,
MichaelFurman <engr@gssi.MV.COM> wrote:
>
>Yes, I understand it. But all we need - just to mark somehow definitions
>of objects that has to be initialized before executing "main". May be some
>existant language attribute can be used? Global scope? No - it would prevent
>optimisation based on virtual memory. "Const"? Do anybody have an idea?
>
I once thought marking an object volatile would do the trick.
Since as the DWP states ([dcl.type.cv]/7) volatile is meant to disallow
a set of optimizations for the use of the object. When an object is
volatile, the compiler shouldn't make any assumptions about when
the object's value is changed. Thus, since the compiler
can't know when the object's value is changed, it can't rely it
being initialized when the first use of the object is made
[basic.start.init]/1  (perhaps in an interrupt etc), except if it
initializes the object before main(). Of course this applies only to
volatile objects with static storage duration and user defined
constructor.

I understand this isn't perhaps what volatile is meant for (the DWP says
it should work "as in C"), but it certainly fits with my
view of how volatile should work.
--
   Esa Pulkkinen                        | C++ programmers do it virtually
   E-Mail:  esap@cs.tut.fi              | everywhere with a class, resulting
   WWW   :  http://www.cs.tut.fi/~esap/ | in multiple inheritance.


---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

   Reading some answers in C++ newsgroups and ARM I found that feature that
I am using is not supported by C++ draft standard. I rely on fact that all
static class instances in the program will be initialized (by calling
appropriate constructors) before executing "main" function. I do not know
how to implement what I want (see below) without it.

My problem:
   I have implemented the data acquisition  system that can store data on
different devices (disk, tape, RAM buffer, e. t. c). I have "drivers" for
each device and I want to configure system software at the link time,
without changing source code and without using special run time parameters.
Each device has ID and main program does not know what drivers included and
even what drivers exist.

  I do it by using special class ddesc (driver descriptor). Constructor of
this class has an argument - device ID. Each driver file contains static
object of this class initialized with appropriate ID. Constructor saves ID
and driver entry point in class body and link just created instance to
common link list (with static member as head pointer).

   Now if all such member will be initialized before main program started I
can go through this list, create driver table, display names of all
supported devices and ask user to choose device for output.

   If initialization can be "deferred to any point in time before the first
use a function or object defined in that translation unit" (as described in
ARM and I believe - I do not have it with me - in draft standard) - I can
not implement this strategy at all because in main part of software I do not
know which translation units - drivers - I have. It seams to me that I can
not avoid recompilation of some file and I have to change that file each
time I implement a new driver.

My questions:

1. What is a reason of allowing it to be deferred.
2. May be I just don't see how to implement it better, without relying on
this unsupported fact (actually all compilers I know do it before calling main).
3. If not - may be it is possible to consider changing the standard.

----------------------------------------------------------------------------
--------
Michael Furman,                                   (603)893-1109
Geophysical Survey Systems, Inc.              fax:(603)889-3984
13 Klein Drive - P.O. Box 97                      engr@gssi.mv.com
North Salem, NH 03073-0097                        71543.1334@compuserve.com
----------------------------------------------------------------------------
--------


[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

In article <199509282107.RAA13781@mv.mv.com>,
MichaelFurman <engr@gssi.MV.COM> wrote:

>   If initialization can be "deferred to any point in time before the first
>use a function or object defined in that translation unit" (as described in
>ARM and I believe - I do not have it with me - in draft standard) - I can
>not implement this strategy at all because in main part of software I do not
>know which translation units - drivers - I have. It seams to me that I can
>not avoid recompilation of some file and I have to change that file each
>time I implement a new driver.
>
>My questions:
>
>1. What is a reason of allowing it to be deferred.

I'd think the reason is to allow dynamic linking. If the initialization
would have to be done always before main(), dynamic linking would not be
possible, because those dynamically linked modules can't generally be
initialized before the call to main().

Also, the requirement allows the system to optimize initialization
of different translation units by not loading the entire program into
memory on startup (which can be very slow), but
instead only loading everything the translation unit containing
main() needs, and then initializing each translation unit when the
first use of the translation unit is done. On large programs, most of
the time used for the startup could be spent in loading all the translation
units to memory (most of which don't ever get used) otherwise.

>2. May be I just don't see how to implement it better, without relying on
>this unsupported fact (actually all compilers I know do it before calling
>main).

I don't think there's a (portable) way to force a compiler to
initialize everything before main(). I suspect it couldn't be
implemented on all platforms (with primitive linker support).
--
   Esa Pulkkinen                        | C++ programmers do it virtually
   E-Mail:  esap@cs.tut.fi              | everywhere with a class, resulting
   WWW   :  http://www.cs.tut.fi/~esap/ | in multiple inheritance.
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

engr@gssi.MV.COM (MichaelFurman) wrote:
>   Reading some answers in C++ newsgroups and ARM I found that feature that
>I am using is not supported by C++ draft standard. I rely on fact that all
>static class instances in the program will be initialized (by calling
>appropriate constructors) before executing "main" function. I do not know
>how to implement what I want (see below) without it.
[]
>   If initialization can be "deferred to any point in time before the first
>use a function or object defined in that translation unit" (as described in
>ARM and I believe - I do not have it with me - in draft standard) - I can
>not implement this strategy at all because in main part of software I do not
>know which translation units - drivers - I have. It seams to me that I can
>not avoid recompilation of some file and I have to change that file each
>time I implement a new driver.

   Not true. You cannot implement PORTABLE code that way. You CAN
rely on a particular compiler though. If you are implementing
device drivers, this might not be so much of a problem.

>
>My questions:
>
>1. What is a reason of allowing it to be deferred.

     Dynamic Link Libraries.

>2. May be I just don't see how to implement it better, without relying on
>this unsupported fact (actually all compilers I know do it before calling main).

     The correct way to implement it requires writing an initialisation
module which DOES know what drivers are to be supplied. To avoid
writing it out by hand all the time, write a program to generate
this initialisation function from information obtained somehow
from a specication file describing the available drivers.


>3. If not - may be it is possible to consider changing the standard.

    This topic has been discussed many times: the current situation
is not entirely satisfactory. Unfortunately, any solution appears
to require a language extension.

--
John Max Skaller               voice: 61-2-566-2189
81 Glebe Point Rd              fax:   61-2-660-0850
GLEBE NSW 2037                 email: maxtal@suphys.physics.oz.au
AUSTRALIA                      email: skaller@maxtal.com.au




---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]