🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

2 total messages Started by John Wray Fri, 06 Oct 1995 06:41
Initialization by non-C++ main() routine
#2133
Author: John Wray
Date: Fri, 06 Oct 1995 06:41
58 lines
3209 bytes
On many platforms, there is a de-facto calling standard that many 
language processors can generate calls to, allowing libraries to be
be implemented in one language, and called from others.  Often
(although 
not always) this standard is the native "C" calling mechanism on the
platform, but almost always it is possible to use C to create libraries

that obey the standard, such that they can be invoked by languages 
other than C.  It would be really nice if C++ could be used in the 
same way, to produce language-neutral libraries.

Since C++ defines the 'extern "C"' construct, with the goal of being
able to call routines from the C RTL, this seems to imply that the 
C++ language constrains data objects (objects without member-functions)
to be built in memory in the same way that C would build those objects.

Given this data compatibility with C, the only reason I can see that
call-in (e.g. calling a C++ routine from a C main program) may not work

is that a program with a C main() function may not properly initialize 
any C++ modules it's linked with, so that non-local static objects 
declared in those modules may not get constructed.

I was wondering if there's any likelihood of a fix for this situation
getting into the standard?  It doesn't seem too hard - one solution
would be to define a #pragma directive, whose purpose would be to
create a public initialization routine for the module in which it
appears (with a name supplied as an argument to the pragma), which a
non-C++ user of the module would have to invoke prior to any other
routines or objects exported by the module.  Implementations that 
use some linker or loader magic to auto-initialize would probably
generate an empty routine from this pragma; implementations that
generate explicit calls for initialization would generate a routine
containing the same initialization code as would be generated if 
the module contained a C++ main function.  The freedom as to when 
(in a C++ program) initialization of a module occurs doesn't seem to
have any bearing on this, as regardless of when the C++ environment 
would call a module's initialization function, such a function must be
generated by the compiler; all I'm proposing is that a pragma be
defined to allow a similar initialization function to be generated 
for explicit calling by non-C++ programs.

The generated initialization function must not mind being called
multiple times, nor must it mind if both it and the "internal" C++
initialization process are invoked.  Other than this, I don't see 
any particular problems.

Any comments?


John


---
[ 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. ]
Re: Initialization by non-C++ main() routine
#2160
Author: John Max Skaller
Date: Tue, 10 Oct 1995 08:15
37 lines
2189 bytes
jcwray@ix.netcom.com (John Wray ) wrote:
>
>On many platforms, there is a de-facto calling standard that many 
>language processors can generate calls to, allowing libraries to be
>be implemented in one language, and called from others.  Often
>(although not always

   Indeed, MS-Windows uses "Pascal" calling conventions.

) this standard is the native "C" calling mechanism on the
>platform, but almost always it is possible to use C to create 
> libraries that obey the standard, such that they can be invoked 
>by languages other than C.  It would be really nice 
> if C++ could be used in the 
>same way, to produce language-neutral libraries.

>I was wondering if there's any likelihood of a fix for this situation
>getting into the standard?  

   Not the ISO Standard. No chance.

   There are however various industry standards for this,
such as IBM SOM and Sun ABI.

   The most ambitious is not really what you asked for but
something much better -- CORBA, which provides for network
based object access. 

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

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads