C++ Wrapper library vs C# Unsafe Code which one is better?

[Arthur Mnev]

The scenario:

a library written in C;- source avaialble.
the end cosumer is C# code.

There are a few different approaches:

1) Compile C code as .lib and link it to C++ library, write a managed
wrapper around it and off we go.

2) Compile native C DLL and write a wrapper in C# through P/Invoke


The real quesiton is which one is better? My basic analysis:

C++ Managed DLL + C code = buggy implementation by Microsoft. There
are issues related to OS level locks placed during dllMain execution
(which has to happen because of CRT). Microsoft's work arounds seem to
do the job to a point, yet there is still a possibility of deadlocking
(see microsofts' articles on the subject)

Even assuming that those issues are fixed - still the same question is
in place:

One of the functions that is being executed follows the signature:

"C"

void myfunct(char* dest, int* dsize_t, const char* src, int ssize_t);

memory for dest must be preallocated, the size of it is unknown until
the function returns when dsize_t can be examined.

Consequently, when writing a wrapper, whether it is C++ or C# I have
to execute the function, then examine the data and then copy the data,
allocate managed buffer of the appropriate size and then copy the
data.

Data copy required will need to be performed ether way, regardless of
whether it is C++ or C# code. The wrapper could be written in C++ with
static linking or through C# with dynamic linking. If someone has a
good technical answer - please let me know what your thoughts are.
Initially, assume that Microsoft's dllMain bugs are fixed and the
static library requiring CRT can actually be linked to managed class
with no issues.


As a side question; does someone have a good answer as to what in the
world is the real technical difference between supplying "ref int
variable" vs "int* variable" from unsafe C# code.

- Arthur

 

[Lloyd Dupont]

The scenario:

a library written in C;- source avaialble.
the end cosumer is C# code.

There are a few different approaches:

1) Compile C code as .lib and link it to C++ library, write a managed
wrapper around it and off we go.

2) Compile native C DLL and write a wrapper in C# through P/Invoke

either is good.
However I found a project C# only or managed C++ only is much easier to
develop than in both languages. (as the program goes, you wil have headache
when you would like your C++ project to refer class in your C#)

Where I would be you I would:
if it's a small library (few function exposed, even if it 23Mb DLL!) I will
simple used DllImport
if it's a big project I will write a managed C++ wrapper and work only with
managed C++ for a little while.
After I will do your C# library using this one, although at this stage you
might do it in managed C++ too, except C# is much leaner.

The real quesiton is which one is better? My basic analysis:

C++ Managed DLL + C code = buggy implementation by Microsoft. There

why do you want MS to provide a buggy implementation ?
I think it's good.

are issues related to OS level locks placed during dllMain execution
(which has to happen because of CRT). Microsoft's work arounds seem to
do the job to a point, yet there is still a possibility of deadlocking
(see microsofts' articles on the subject)

Even assuming that those issues are fixed - still the same question is
in place:

One of the functions that is being executed follows the signature:

"C"

void myfunct(char* dest, int* dsize_t, const char* src, int ssize_t);

memory for dest must be preallocated, the size of it is unknown until
the function returns when dsize_t can be examined.

Consequently, when writing a wrapper, whether it is C++ or C# I have
to execute the function, then examine the data and then copy the data,
allocate managed buffer of the appropriate size and then copy the
data.

yep, so ?

Data copy required will need to be performed ether way, regardless of
whether it is C++ or C# code. The wrapper could be written in C++ with
static linking or through C# with dynamic linking. If someone has a
good technical answer - please let me know what your thoughts are.
Initially, assume that Microsoft's dllMain bugs are fixed and the
static library requiring CRT can actually be linked to managed class
with no issues.


As a side question; does someone have a good answer as to what in the
world is the real technical difference between supplying "ref int
variable" vs "int* variable" from unsafe C# code.

if you write a library for some other people to use, I'm sure they will
dislike having to feed an int* to the exposed function, while they would be
ok with int[]

- Arthur

Lloyd

 

[Arthur Mnev]

[C++ Managed DLL + C code = buggy implementation by Microsoft. ]Microsofts implementation is buggy (i'd prefer for it not to be)
Read that and related articles - the problem will be fixed in the next
version of runtime; meanwhile you are guaranteed to have a potential
for sys. deadlocks.

http://support.microsoft.com/?id=814472

if you write a library for some other people to use, I'm sure they will
dislike having to feed an int* to the exposed function, while they would be
ok with int[]

I was refering to how data is passed around, not what people would
prefer to see. But thanks for a point.

The scenario:

a library written in C;- source avaialble.
the end cosumer is C# code.

There are a few different approaches:

1) Compile C code as .lib and link it to C++ library, write a managed
wrapper around it and off we go.

2) Compile native C DLL and write a wrapper in C# through P/Invoke

either is good.
However I found a project C# only or managed C++ only is much easier to
develop than in both languages. (as the program goes, you wil have headache
when you would like your C++ project to refer class in your C#)

Where I would be you I would:
if it's a small library (few function exposed, even if it 23Mb DLL!) I will
simple used DllImport
if it's a big project I will write a managed C++ wrapper and work only with
managed C++ for a little while.
After I will do your C# library using this one, although at this stage you
might do it in managed C++ too, except C# is much leaner.

The real quesiton is which one is better? My basic analysis:

C++ Managed DLL + C code = buggy implementation by Microsoft. There

why do you want MS to provide a buggy implementation ?
I think it's good.

are issues related to OS level locks placed during dllMain execution
(which has to happen because of CRT). Microsoft's work arounds seem to
do the job to a point, yet there is still a possibility of deadlocking
(see microsofts' articles on the subject)

Even assuming that those issues are fixed - still the same question is
in place:

One of the functions that is being executed follows the signature:

"C"

void myfunct(char* dest, int* dsize_t, const char* src, int ssize_t);

memory for dest must be preallocated, the size of it is unknown until
the function returns when dsize_t can be examined.

Consequently, when writing a wrapper, whether it is C++ or C# I have
to execute the function, then examine the data and then copy the data,
allocate managed buffer of the appropriate size and then copy the
data.

yep, so ?

Data copy required will need to be performed ether way, regardless of
whether it is C++ or C# code. The wrapper could be written in C++ with
static linking or through C# with dynamic linking. If someone has a
good technical answer - please let me know what your thoughts are.
Initially, assume that Microsoft's dllMain bugs are fixed and the
static library requiring CRT can actually be linked to managed class
with no issues.


As a side question; does someone have a good answer as to what in the
world is the real technical difference between supplying "ref int
variable" vs "int* variable" from unsafe C# code.

if you write a library for some other people to use, I'm sure they will
dislike having to feed an int* to the exposed function, while they would be
ok with int[]

- Arthur

Lloyd