🚀 go-pugleaf

>>>>> "SV" == Stephen Vavasis <vavasis@CS.Cornell.EDU> writes:

    SV> I would like to write a subroutine in C++ that gets called
    SV> by an existing program.  The subroutine might get loaded with a
    SV> dynamic loader into an already compiled program to which I, the C++
    SV> programmer, have no access. 

    SV> In this case, there is no C++ main().  Nonetheless, I would still
    SV> like to use C++ features like global static data items whose
    SV> constructors and destructors get called.

You can still use global static data.  The constructors will be called
the first time the shared object is loaded.  Of course, you need to have
a compiler that will support building shared objects.

- Chris


-- 
Christopher Barber ----- Software Engineer ---- BBN Systems and Technologies
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy is
  in http://reality.sgi.com/employees/austern_mti/std-c++/policy.html. ]

vavasis@CS.Cornell.EDU (Stephen Vavasis) writes:

>I would like to propose that the standard deal with the following
>issue.  I would like to write a subroutine in C++ that gets called by
>an existing program.  The subroutine might get loaded with a dynamic
>loader into an already compiled program to which I, the C++
>programmer, have no access.  I imagine other people have the same
>situation.
>
>In this case, there is no C++ main().  Nonetheless, I would still like
>to use C++ features like global static data items whose constructors
>and destructors get called.
>
>To handle this, I would like to be able to put an explicit call like
>"cpp_start()" at the entry point of the routine, and "cpp_finish()" at
>the end that would take care of all the initialization/cleanup C++
>normally does in main.  
[...]
>But as far as I know, the names of these start/finish calls are not
>standardized, so I can't count on portability.

I think this is a good idea.  I would just like to forestall any
possible objection that this is something that can't be standandized by
pointing out that the Ada-95 standard deals with the issue.  It uses
the names "adainit" and "adafinal".

| B.1 Interfacing Pragmas
| 
|       Implementation Advice
|       
|    (39)
|           If an implementation supports pragma Export to a given
|           language, then it should also allow the main subprogram to be
|           written in that language. It should support some mechanism for
|           invoking the elaboration of the Ada library units included in
|           the system, and for invoking the finalization of the
|           environment task. On typical systems, the recommended mechanism
|           is to provide two subprograms whose link names are "adainit"
|           and "adafinal". Adainit should contain the elaboration code for
|           library units. Adafinal should contain the finalization code.
|           These subprograms should have no effect the second and
|           subsequent time they are called.

--
Fergus Henderson             	WWW: http://www.cs.mu.oz.au/~fjh
fjh@cs.mu.oz.au              	PGP: finger fjh@128.250.37.3
---
[ To submit articles: try just posting with your news-reader.
                      If that fails, use mailto:std-c++@ncar.ucar.edu
  FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html
  Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu.
]