Code gen error with /CLR and boos::bind and boost::function

[Russell Hind]

I'm trying to use boost::bind and boost::function inside managed code,
but there appears to be some code generation problems. The following
code compiles fine, but the function object throws an exception when you
call it with f() saying the function is empty. If you un-comment the
#pragma unamanged, it runs fine. It appears to be a code generation
problem when compiling function and bind as managed.

Thanks

Russell

#include "stdafx.h"
#using <mscorlib.dll>

//#pragma unmanaged

#include <boost/bind.hpp>
#include <boost/function.hpp>

class Test_c
{
public:
void test(void)
{
}
};

int main()
{
Test_c Test;
boost::function<void (void)> f(boost::bind(&Test_c::test, &Test));
f();
return 0;
}

 

[Arjun Bijanki [VCPP MSFT]]

--------------------

Date: Mon, 07 Jun 2004 10:52:15 +0100
From: Russell Hind <[email protected]>
Subject: Code gen error with /CLR and boos::bind and boost::function

I'm trying to use boost::bind and boost::function inside managed code,
but there appears to be some code generation problems. The following
code compiles fine, but the function object throws an exception when you
call it with f() saying the function is empty. If you un-comment the
#pragma unamanged, it runs fine. It appears to be a code generation
problem when compiling function and bind as managed.

This sounds familiar. There should be a function named has_empty_target in
function\function_base.hpp. It returns a bool; if you change it to return
an int I believe the problem should stop occurring.

The reason is that the bool is not being properly marshalled across
unmanaged/managed transitions. vararg functions are compiled as unmanaged.
Please see this link for more information:

http://support.microsoft.com/default.aspx?scid=kb;en-us;813488

 

[Russell Hind]

This sounds familiar. There should be a function named has_empty_target in
function\function_base.hpp. It returns a bool; if you change it to return
an int I believe the problem should stop occurring.

The reason is that the bool is not being properly marshalled across
unmanaged/managed transitions. vararg functions are compiled as unmanaged.
Please see this link for more information:

http://support.microsoft.com/default.aspx?scid=kb;en-us;813488

Thanks, just out of interest, will there be some sort of service pack
for VS.Net 2003 with the fix for this in that is mentioned on the page?

Russell

 

[Carl Daniel [VC++ MVP]]

Thanks, just out of interest, will there be some sort of service pack
for VS.Net 2003 with the fix for this in that is mentioned on the
page?

Not directly answering the question (which I cannot), but IIRC, this is
actually a CLR bug, not a C++ bug.

-cd

 

[Ronald Laeremans [MSFT]]

Yes, this is a fairly deep issue with how the marshalling concepts in the
CLR that could not realistically be fixed in a service pack.

Ronald Laeremans
Visual C++ team

 

[Russell Hind]

Yes, this is a fairly deep issue with how the marshalling concepts in the
CLR that could not realistically be fixed in a service pack.

But the support page says they have an update of clxx.dll and feac.dll.
How could these not be distributed as a patch, if you can ring up for
them?

It makes me worried about trying to move to VC++. Currently have lots
of code in C++Bulider and am trying to port it to compare with VC++ but
if using bools can cause errors, its pretty much a waste of time.

Cheers

Russell

 

[Carl Daniel [VC++ MVP]]

It makes me worried about trying to move to VC++. Currently have lots
of code in C++Bulider and am trying to port it to compare with VC++
but if using bools can cause errors, its pretty much a waste of time.

Only when bools are marshalled from unmanaged to managed is there a problem.
If you're just moving native C++ from Borland to VC++ you won't have any
problems related to bools.

-cd

 

[Russell Hind]

I thought this, but the initial code I posted was all compiled as
managed. AFAIK, the boost headers don't put #pragma unmanaged anywhere
and all the function code is template stuff in header files so should
have been compiled as managed. So why would the error occur?

(I have solved the problem by making the has_empty_target return an int
for now).

Thanks

Russell

 

[Carl Daniel [VC++ MVP]]

I thought this, but the initial code I posted was all compiled as
managed. AFAIK, the boost headers don't put #pragma unmanaged
anywhere and all the function code is template stuff in header files
so should have been compiled as managed. So why would the error
occur?

When you compile C++ as managed with VC7.1 you get a mixture of managed and
unmanaged code as a result. Apparently you were lucky enough to get a bool
marshalled from unmanaged to managed in the process. Whidbey (VC8) will
support generation of pure MSIL from C++ code but the current compiler does
not.

-cd

 

[William DePalo [MVP VC++]]

(I have solved the problem by making the has_empty_target return an int
for now).

That's one way to go. FWIW, When this problem bit me in the ***, I did this:

bool someFunc()
{
bool ok;

// set ok

__asm xor eax, eax
return ok;
}

On the fine day when the problem is resolved, I'll search for the __asm
lines and remove them and keep the same function signatures.

Regards,
Will

 

[Russell Hind]

That's one way to go. FWIW, When this problem bit me in the ***, I did this:

bool someFunc()
{
bool ok;

// set ok

__asm xor eax, eax
return ok;
}

Thanks, I'll try that. Much neater than my solution.

Cheers

Russell

 

[Russell Hind]

When you compile C++ as managed with VC7.1 you get a mixture of managed and
unmanaged code as a result. Apparently you were lucky enough to get a bool
marshalled from unmanaged to managed in the process. Whidbey (VC8) will
support generation of pure MSIL from C++ code but the current compiler does
not.

Thanks, I thought that when I had no unmanaged pragma's in there, I was
getting pure MSIL. I'll use William's solution now as it seems much
neater than replacing the return types if _MANAGED is defined.

Cheers

Russell

 

[Ronald Laeremans [MSFT]]

If I recall correctly, we marshall as int for a workaround in that package.
That workaround will likely end up in an SP for 7.1. I was talking about a
global fix.

Ronald

 

[Russell Hind]

Thanks. I've used the asm fix for now, until that arrives.

Cheers

Russell

If I recall correctly, we marshall as int for a workaround in that package.
That workaround will likely end up in an SP for 7.1. I was talking about a
global fix.

Ronald

Ronald Laeremans [MSFT] wrote:

Yes, this is a fairly deep issue with how the marshalling concepts in the
CLR that could not realistically be fixed in a service pack.

But the support page says they have an update of clxx.dll and feac.dll.
How could these not be distributed as a patch, if you can ring up for
them?

It makes me worried about trying to move to VC++. Currently have lots of
code in C++Bulider and am trying to port it to compare with VC++ but if
using bools can cause errors, its pretty much a waste of time.

Cheers

Russell