Topic: standardizing routines without main()


Author: fjh@cs.mu.OZ.AU
Date: 1996/02/21
Raw View
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.
]





Author: vavasis@CS.Cornell.EDU (Stephen Vavasis)
Date: 1996/02/15
Raw View
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.  As programmer, I would take responsibility for
making sure that nothing is done before cpp_start() or after
cpp_finish().

In fact, some C++ implementations already offer such a call just for
this purpose.  See, for example,
     http://www.mathworks.com/1606.html
which describes how to write dynamically-loadable C++ subroutines for
matlab using the Watcom C++ compiler.

But as far as I know, the names of these start/finish calls are not
standardized, so I can't count on portability.

Thanks,
Steve Vavasis
---
[ 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. ]