🚀 go-pugleaf

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