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

  • Thread starter Thread starter Russell Hind
  • Start date Start date
R

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;
}
 
--------------------
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
Click to expand...
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.
Click to expand...

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
 
Arjun said:
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
Click to expand...

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
 
Russell said:
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?
Click to expand...

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

-cd
 
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
 
Ronald said:
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.
Click to expand...

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
 
Russell said:
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.
Click to expand...

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
 
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
 
Russell said:
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?
Click to expand...

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
 
Russell Hind said:
(I have solved the problem by making the has_empty_target return an int
for now).
Click to expand...

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
 
William said:
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;
}
Click to expand...

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

Cheers

Russell
 
Carl said:
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.
Click to expand...

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
 
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
 
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.
Click to expand...

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
Click to expand...
Click to expand...
 
Back
Top