MC++ and /MD

  • Thread starter Thread starter gauss
  • Start date Start date
G

gauss

Hi,

I am using VS2003.NET. When /clr option is activated, /MT(d) is
automatically chosen (just as said in the doc). Can I changed that to
/MD(d)? Knowing that in VS2005 /MD is chosen by default. And not forgetting
the non-deterministic Mixed DLL problem under VS2003.Net

The situation is the following: I have a native dll, a mixed dll and a .Net
application. The mixed dll interfaces the native dll for .Net (common
senario). One of the methods of a native class returns 2 std::vector 's in
its parameters list which are resized in native code. So the mixed dll has
to declare 2 vectors (with default ctor), send them to the native function
and read back the reuslts in .net arrays.

That worked fine untill I used a different type of vectors (not STL). The
difference I found is that the default ctor of stl vectors in VC7.1 doesn't
allocate memory (doesn't call new) if initiale size is zero (that's good).
But the other type of vectors does that. And when delete is called in the
native code after resizing the vector... Boom!!! _CrtIsValidHeapPointer
Assertion.

I have to say that the native dll is compiled with /MD and the the mixed dll
is compiled with /MT!!!! So that's it. But I can't compile the native dll
with /MT. And in the first place common heap managment requires /MD
compilation (I think).

So the question (once again) can I compile mixed dll with /MD?

Thanks,
GY
 
Hi,
I am using VS2003.NET. When /clr option is activated, /MT(d) is
automatically chosen (just as said in the doc). Can I changed that to
/MD(d)? Knowing that in VS2005 /MD is chosen by default. And not forgetting
the non-deterministic Mixed DLL problem under VS2003.Net
Click to expand...

Yes. I just ran an MFC app compiled with /clr and /MDd and it worked just
fine.
I know MSDN says /MT is automatically chosen, but that does not seem to
happen in my case.

I did the same with an MFC dll, and depends.exe shows clearly that it is
linked against MSVCR71.dll
That worked fine untill I used a different type of vectors (not STL). The
difference I found is that the default ctor of stl vectors in VC7.1 doesn't
allocate memory (doesn't call new) if initiale size is zero (that's good).
But the other type of vectors does that. And when delete is called in the
native code after resizing the vector... Boom!!! _CrtIsValidHeapPointer
Assertion.
Click to expand...

Yes that is a recipe for disaster.
I have to say that the native dll is compiled with /MD and the the mixed dll
is compiled with /MT!!!! So that's it. But I can't compile the native dll
with /MT. And in the first place common heap managment requires /MD
compilation (I think).

So the question (once again) can I compile mixed dll with /MD?
Click to expand...

Yes. just compile with /MD and /MDd. It works for me.

--

Kind regards,
Bruno.
(e-mail address removed)
Remove only "_nos_pam"
 
Hi again

Bruno van Dooren said:
Hi,


Yes. I just ran an MFC app compiled with /clr and /MDd and it worked just
fine.
I know MSDN says /MT is automatically chosen, but that does not seem to
happen in my case.

I did the same with an MFC dll, and depends.exe shows clearly that it is
linked against MSVCR71.dll


Yes that is a recipe for disaster.


Yes. just compile with /MD and /MDd. It works for me.

--

Kind regards,
Bruno.
(e-mail address removed)
Remove only "_nos_pam"
Click to expand...

Thanks for your reply. I think, I have to take this option because I don't
see other solutions but I needed confirmations about it. And you are right
when I choose dynamic link to MFC it switches to /MD (with /clr choosen) (I
don't use MFC so didn't check that)
Thanks again

Best regards
GY
 
Back
Top