Parameter destruction

A

Adriano Coser

Hello.

I'm facing a problem analog to the one described here:

http://groups.google.com/groups?hl=...04280815.2d93f31b%40posting.google.com&rnum=5

I have an unmanaged class that receives a gcroot<> to a control in its
constructor. When I invoke this constructor from a managed class
passing directly the control* the program crashes when I try to access
the parameter into the refered constructor.

I had the same problem for others classes passed by value from managed
to unmanaged classes.

Does anyone know if this problem is already solved or if there's a
workaround other then change the parameters by value to const&?

Thanks in advance for any help.

Regards,
Adriano.
 
G

Gustavo L. Fabro

Hi there

I have the same issue. I "solved" by passing the parameter using const&
instead of by value, but that is just a workaround for what I believe *IS a
BUG* in VC++ 7.1 (at least happens in 7.1.3088 with .NET 1.1.4322 SP1).

Someone tell me if I'm wrong! Unexpected destruction of a parameter passed
by value??? I'm impressed how it appears not to have been solved yet.

As for Mr. Gary Chang's workaround suggestions:

¡¤ linking with /opt:noref
Already did, but didn't solve it.

¡¤ passing the shared_ptr by const reference and not by value
That did it, but, as Arnaud Debaene said, it is a workaround...

..Fabro
 
R

Ronald Laeremans [MSFT]

Gustavo said:
Hi there




I have the same issue. I "solved" by passing the parameter using const&
instead of by value, but that is just a workaround for what I believe *IS a
BUG* in VC++ 7.1 (at least happens in 7.1.3088 with .NET 1.1.4322 SP1).

Someone tell me if I'm wrong! Unexpected destruction of a parameter passed
by value??? I'm impressed how it appears not to have been solved yet.

As for Mr. Gary Chang's workaround suggestions:

¡¤ linking with /opt:noref
Already did, but didn't solve it.

¡¤ passing the shared_ptr by const reference and not by value
That did it, but, as Arnaud Debaene said, it is a workaround...

..Fabro
This is fixed in Whidbey. The reason it wasn't fixed before and is not
available as a QFE (patch) for 7.0 or 7.1 is that fixing this required
fundamental changes in the way the CLR handles interop: we needed an
exact way to specify what the right copy constructer and destructor for
a type passed by value across an interop boundary is since the CLR
internally needs to call it). Previously the CLR had heuristics and pace
and this was the (main) case where they failed.

Ronald Laeremans
Visual C++ team
 
G

Gustavo L. Fabro

This is fixed in Whidbey. The reason it wasn't fixed before and is not
available as a QFE (patch) for 7.0 or 7.1 is that fixing this required
fundamental changes in the way the CLR handles interop: we needed an exact
way to specify what the right copy constructer and destructor for a type
passed by value across an interop boundary is since the CLR internally
needs to call it). Previously the CLR had heuristics and pace and this was
the (main) case where they failed.

Ronald Laeremans
Visual C++ team


Thanx for the reply!

Guess I can sleep better now! :)

..Fabro
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top