Native lib with singleton and C++/CLI program

  • Thread starter Thread starter joes.staal
  • Start date Start date
J

joes.staal

Hi,

I know this has been asked earlier on, however, none of the other
threads where I looked solved the following problem.
1. I've got a native C++ library (lib, not a dll) with a singleton.
2. I've got a C++/CLI program with a wrapper around some functions in
the singleton of the native lib.
3. When I run my program, the wrappers instantiate their own copy of
the singleton, i.e.

CLIAssembly::CLIObject::Value(42); // Is a wrapper around
Native::SingleObject::instance().value(int i)
Native::SingleObject::instance().value(13);

Console::WriteLine("Value in CLI object is {0}",
CLIAssembly::CLIObject::Value());
Console::WriteLine("Value in Native object is {0}",
Native::SingleObject::instance().value());

gives as output

Value in CLI object is 42
Value in Native object is 13

Only when I put the source code of the native lib in the CLI/C++
program project I get the behaviour I'd expect.

I've tried various options:
- Compiling the native lib with /clr
- adding #pragma managed and #pragma unmanaged around the include for
the native code in the CLI project.
All to no avail.

Any help and ideas would be much appreciated.

Joes
 
Only when I put the source code of the native lib in the CLI/C++
program project I get the behaviour I'd expect.

I've tried various options:
- Compiling the native lib with /clr
- adding #pragma managed and #pragma unmanaged around the include for
the native code in the CLI project.
All to no avail.

Any help and ideas would be much appreciated.
Click to expand...

How is your code linked? (i.e. is it a single monolightic EXE, EXE+DLL,
multiple DLLs, etc) How is the singleton actually declared? Code
defined in a library will, of course, be duplicated in each image (DLL, EXE,
etc) that uses the library.

If you've got two different values, you have one of two problems:
1. Your wrapper isn't really wrapping what you think it is.
2. Youe singleton is actually a doubleton.

A short complete example (i.e. something that other can compile/link/run)
would be very helpful in understanding where exactly the problem lies.

-cd
 
How is your code linked?  (i.e. is it a single monolightic EXE, EXE+DLL,
multiple DLLs, etc)   How is the singleton actually declared?    Code
defined in a library will, of course, be duplicated in each image (DLL, EXE,
etc) that uses the library.

If you've got two different values, you have one of two problems:
1. Your wrapper isn't really wrapping what you think it is.
2. Youe singleton is actually a doubleton.

A short complete example (i.e. something that other can compile/link/run)
would be very helpful in understanding where exactly the problem lies.

-cd
Click to expand...

Hi Carl,

I can post some code or a zip file somewhere with the projects
tomorrow. The code setup is as follows:
- lib with singleton (native C++ code)
- exe with a public ref wrapper class that is abstract and sealed and
two static methods that
make a call to the singleton instance from the lib and set or get a
value.

Calling the singleton via the wrapper class gives different values
than calling it directly,
as I showed in the code snippet in my initial post.

Anyway, I'll give some code tomorrow when I am back at my work
machine.

Thx,

Joes
 
A follow up. The issue I was encountering was the following. I have
three projects, one producing a native static lib (LIB), one a .NET
assembly (DLL) and one executable (EXE).
The LIB implements a singleton, the DLL writes a wrapper around it.
The EXE calls the singleton directly by linking in the LIB, and
indirectly by referencing the wrapper DLL. It turns out the wrapper
has its own copy of the singleton and so the EXE has two independent
singletons.

Turning the LIB into a native DLL and exporting the singleton removes
the doubleton, giving the EXE access to the same instance by calling
the wrapper as well as the direct call.

I think I quite understand that, and I also know what to do to solve
the issues I've got within my projects.

Thx,

Joes
 
Joes said:
A follow up. The issue I was encountering was the following. I have
three projects, one producing a native static lib (LIB), one a .NET
assembly (DLL) and one executable (EXE).
The LIB implements a singleton, the DLL writes a wrapper around it.
The EXE calls the singleton directly by linking in the LIB, and
indirectly by referencing the wrapper DLL. It turns out the wrapper
has its own copy of the singleton and so the EXE has two independent
singletons.

Turning the LIB into a native DLL and exporting the singleton removes
the doubleton, giving the EXE access to the same instance by calling
the wrapper as well as the direct call.

I think I quite understand that, and I also know what to do to solve
the issues I've got within my projects.
Click to expand...

Yep - that's what I thought, based on your description. Glad you got it
sorted - you're right that the only way to have a true in-process singleton
is to implement it in a DLL.

-cd
 
Back
Top