From djsamperi at gmail.com  Fri Apr 30 22:38:11 2010
From: djsamperi at gmail.com (Dominick Samperi)
Date: Fri, 30 Apr 2010 16:38:11 -0400
Subject: [Rd] Memory allocation in C/C++ vs R?
In-Reply-To: <1342B552-E181-45CC-9149-DD1C9C931959@r-project.org>
References: <m2qd4cf43b61004292203x8265d834wb1d42c483813d55d@mail.gmail.com>
	<491D8740-466D-4442-B6BE-942A9C423CD0@r-project.org>
	<u2vd4cf43b61004301040jc5a99578k9b44b41e7b414b0a@mail.gmail.com>
	<F58D45DC-69AB-43C5-B6E4-CE5C87354DBE@r-project.org>
	<l2yd4cf43b61004301151vaa9e8229i48641cffbb53c653@mail.gmail.com>
	<1342B552-E181-45CC-9149-DD1C9C931959@r-project.org>
Message-ID: <p2rd4cf43b61004301338j1d90aa24v9262f4cf1f7d9f3d@mail.gmail.com>

> Indeed. As I said, using heap objects (explicit initialization) does solve that issue, but you have to be again wary of other libraries which may still use static initializers.

I just did a little test and found, in the case of gcc/g++, that a
main C main program linked with a C++ library
that has static intializers works just fine. The sequence of commands was:

g++ -fpic -c mylib.cpp
g++ -shared -o foo.so mylib.o
gcc mylibtest foo.so

It appears that the runtime system / shared library loading process
makes sure that the static initializers for
classes defined in mylib.so are run before the C program defined in
mylibtest.c is started.

Of course, we knew this already ("it works when it works"), but this
shows, at least in the case of gcc/g++,
what is going on. But as you have pointed out, the whole process is
OS-dependent and may not work
as smoothly on other platforms.

Dominnick



[Rd] Memory allocation in C/C++ vs R?
Dominick Samperi