--------------------
> Date: Mon, 07 Jun 2004 10:52:15 +0100
> From: Russell Hind <rhind@mac.com>
> 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

Signature
Arjun Bijanki, Microsoft Visual C++ Team
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
Russell Hind - 08 Jun 2004 08:47 GMT
> 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
[quoted text clipped - 5 lines]
>
> 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] - 08 Jun 2004 17:07 GMT
> 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] - 08 Jun 2004 22:17 GMT
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
>> 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
[quoted text clipped - 4 lines]
>
> -cd
Russell Hind - 09 Jun 2004 09:41 GMT
> 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] - 09 Jun 2004 18:17 GMT
> 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 - 09 Jun 2004 19:07 GMT
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
>>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++
[quoted text clipped - 5 lines]
>
> -cd
Carl Daniel [VC++ MVP] - 09 Jun 2004 20:30 GMT
> 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
Russell Hind - 10 Jun 2004 08:50 GMT
> 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
William DePalo [MVP VC++] - 10 Jun 2004 00:41 GMT
> (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 - 10 Jun 2004 08:49 GMT
> That's one way to go. FWIW, When this problem bit me in the ***, I did this:
>
[quoted text clipped - 7 lines]
> return ok;
> }
Thanks, I'll try that. Much neater than my solution.
Cheers
Russell
Ronald Laeremans [MSFT] - 10 Jun 2004 18:58 GMT
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
>> 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.
[quoted text clipped - 10 lines]
>
> Russell
Russell Hind - 14 Jun 2004 09:16 GMT
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
[quoted text clipped - 16 lines]
>>
>>Russell