🚀 go-pugleaf

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. ]

In article <44rrsp$r59@peippo.cs.tut.fi>, esap@cs.tut.fi says...
>
>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 certainly like that. Is it possible to consider this as a proposal for 
changing C++ standard?

	Michael

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. ]

engr@gssi.MV.COM (MichaelFurman) wrote:
>In article <44j7pn$ca9@oznet07.ozemail.com.au>,
>John Max Skaller <maxtal@suphys.physics.su.oz.au> wrote:
>
>>engr@gssi.MV.COM (MichaelFurman) wrote:
>>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.
>
>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++.

     Sure. I personally strongly supported providing proper
support for control of initialisation in C++. However the problems
involved are difficult and in the end the committee has decided 
mainly to ensure the existing specification is clear without
extending the semantics. Probably, this is right at this stage,
there are too many alternatives.

     In general, there's conly one way to control complex initialisation
in C++: manually. I think little is lost here, because initialisation
of devices is inherently complex, operating system and device
specific, and generally initialisation of multiple devices CANNOT
be done independently for each device. So integrated initialisation
code may need to be written anyhow.


     Perhaps the best solution of this kind of problem is
a meta-solution -- a program which generates initialisation
code. One might write that in C++ to generate C++ code
and build in appropriate rules.

>> 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. 

    Agreed. But device drivers are a good example.


>>     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++. 

     The form of the specification file is as portable as YOU make
it: you are writing the program which reads it and generates
appropriate code.

>>>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". 

    That is possible of course, but I doubt it is "all we need". :-)

>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'd guess many existing compilers either:

    a) do global initialisation before main anyhow for non-DLL code
    b) provide pragmas (Borland does, for example)
    c) allow you to write and link in your own startup code

I know this is not portable. The problem is that portability requires
corresponding constraints on architectures. Standards bodies generally
decide not to dictate such constraints unless there is virtual
unanimity in this kind of thing.

It may well be appropriate, for example, to have standardised
C++ extensions in the POSIX standard, rather than the C++ one
(since POSIX already constrains OS architectures)


-- 
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. ]