passing std::string from visual studio 2005 to an C++ DLL generated by VC 6.0

[Creativ]

I've looked through this thread and still have quetions.
Suppose In visual studio 2005, I write the following

#pragam managed
class ManagedWrapper
{
void CallUnmanagedMe thod() // The unmanaged class /method is
imported from a C++ DLL generated by vc 6.0
{
std::string* inputString = new string();
inputString = "Text";
UnmanagedClass uc;
uc.Run(inputStr ing); // signature uc.Run(string* input)
}
}

since std::string* is unmanaged. So it's a mix mode code. So
inputString unmanaged. Why can't I do something like that?
So in this case I can work without Marshal.StringT oHGlobalAnsi if I
don't have to copy content from managed String, right?

Second question is,
I also tried this,
String^ text = "AAA";
char* buffer = (char*)Marshal. StringToHGlobal Ansi(text).ToPt r();
std::string input;
input = buffer;
UnmanagedClass uc; // imported from a C++ DLL generated by VC 6.0
uc.Run(input);

Now the questions is,
This piece of code compile and link perfectly. But when Í run it, my
unmanaged class just got some garbage string. If there are other
parameter after string,
those parameter will be filled with garbage data. But unmanaged DLL
doesn't complain. It just cast the input into the right type.
Why is it?
Thanks a lot if anyone can help me.

[David Wilkinson]

Creativ wrote:

I've looked through this thread and still have quetions.
Suppose In visual studio 2005, I write the following

#pragam managed
class ManagedWrapper
{
void CallUnmanagedMe thod() // The unmanaged class /method is
imported from a C++ DLL generated by vc 6.0
{
std::string* inputString = new string();
inputString = "Text";
UnmanagedClass uc;
uc.Run(inputStr ing); // signature uc.Run(string* input)
}
}

Creativ:

First of all this code should not compile, because because inputString
is a string*, not a string. But why are you allocating it on the heap
anyway? Doesn't your code leak memory?

Second, in general it is not possible to mix .exe's and .dll's created
using different versions of the VC compiler. It definitely will not work
if you pass library objects across the boundary, because these objects
may have different layouts in the two cases (this is certainly the case
for std::string in VC6/VC8).

--
David Wilkinson
Visual C++ MVP

[Ben Voigt [C++ MVP]]

"David Wilkinson" <no******@effis ols.comwrote in message
news:%2******** **********@TK2M SFTNGP06.phx.gb l...

Creativ wrote:

>I've looked through this thread and still have quetions.
Suppose In visual studio 2005, I write the following

#pragam managed
class ManagedWrapper
{
void CallUnmanagedMe thod() // The unmanaged class /method is
imported from a C++ DLL generated by vc 6.0
{
std::string* inputString = new string();
inputString = "Text";
UnmanagedClass uc;
uc.Run(inputStr ing); // signature uc.Run(string* input)
}
}

Creativ:

First of all this code should not compile, because because inputString is
a string*, not a string. But why are you allocating it on the heap anyway?
Doesn't your code leak memory?

Second, in general it is not possible to mix .exe's and .dll's created
using different versions of the VC compiler. It definitely will not work
if you pass library objects across the boundary, because these objects may
have different layouts in the two cases (this is certainly the case for
std::string in VC6/VC8).

In effect, this means that C++ classes can't be part of a library's public
interface. I think that STL classes specifically forbid being
dllexport/dllimport-ed.

>
--
David Wilkinson
Visual C++ MVP

[Mihai N.]

In effect, this means that C++ classes can't be part of a library's public

interface.

Actually, they can, but you must use the exact same compiler.
--
Mihai Nita [Microsoft MVP, Windows - SDK]
http://www.mihai-nita.net
------------------------------------------
Replace _year_ with _ to get the real email

[Mihai N.]

Second, in general it is not possible to mix .exe's and .dll's created

using different versions of the VC compiler.

You can, but you can cannot expose any C++ objects. Plain C is ok.
In fact, with plain C you can even mix and match compilers as you want
(gcc/watcom/vs/you_name_it)
--
Mihai Nita [Microsoft MVP, Windows - SDK]
http://www.mihai-nita.net
------------------------------------------
Replace _year_ with _ to get the real email

[David Wilkinson]

Mihai N. wrote:

>Second, in general it is not possible to mix .exe's and .dll's created
using different versions of the VC compiler.

You can, but you can cannot expose any C++ objects. Plain C is ok.
In fact, with plain C you can even mix and match compilers as you want
(gcc/watcom/vs/you_name_it)

Mihai:

I said "in general".

--
David Wilkinson
Visual C++ MVP

[Ben Voigt [C++ MVP]]

"Mihai N." <nm************ **@yahoo.comwro te in message
news:Xn******** ************@20 7.46.248.16...

>In effect, this means that C++ classes can't be part of a library's
public
interface.

Actually, they can, but you must use the exact same compiler.

That's not really a "public" interface then, but internal to one specific
application, because it prevents generic reuse of the library.

>

--
Mihai Nita [Microsoft MVP, Windows - SDK]
http://www.mihai-nita.net
------------------------------------------
Replace _year_ with _ to get the real email

[Mihai N.]

That's not really a "public" interface then, but internal to one specific

application, because it prevents generic reuse of the library.

Depends on your definition of "public"

In my definition "public" is "visible to the outside world."
The fact that "the world" doesn't understand it is another thing.

A public Java or C# class is not usable from C++ (or C),
but this does not make it less public.
The main problem is that the decorations for C++ are not standard,
so each compiler does it's own thing. And then the memory layout of
a C++ object is not standard, so there is also compiler speciffic stuff.

Yes, it is a pitty that the C++ standard does not cover those
areas, but it is not MS fault.
And, as much as MS would like to keep compatibility, there is no
way to move forward. We all asked for better C++ standard compatibility.
Especially in the templates area. So fixing that I guess changed the
std::string layout. Yes, it is a not good. But what can you do?

This was a known problem from a long time: you want "generic (C++)
reuse of the library", you have wrap it in C and only expose C api,
or use sources (STL style).
--
Mihai Nita [Microsoft MVP, Windows - SDK]
http://www.mihai-nita.net
------------------------------------------
Replace _year_ with _ to get the real email

[Ben Voigt [C++ MVP]]

"Mihai N." <nm************ **@yahoo.comwro te in message
news:Xn******** ************@20 7.46.248.16...

>That's not really a "public" interface then, but internal to one specific
application, because it prevents generic reuse of the library.

Depends on your definition of "public"

In my definition "public" is "visible to the outside world."
The fact that "the world" doesn't understand it is another thing.

There are all kinds of exports which are not part of a public interface.
The entire Nt* family of functions (I think they're in ntdll.dll) for
example.

[snip]

>
This was a known problem from a long time: you want "generic (C++)
reuse of the library", you have wrap it in C and only expose C api,
or use sources (STL style).

Well, exposing a pure interface also gives binary compatibility while
preserving OO style. But those are essentially the three options for
reusable C++ libraries.

>

--
Mihai Nita [Microsoft MVP, Windows - SDK]
http://www.mihai-nita.net
------------------------------------------
Replace _year_ with _ to get the real email

[Mihai N.]

Well, exposing a pure interface also gives binary compatibility while

preserving OO style.

I have never tried that one, sounds interesting, I might take a look.
But I think I can understand why that would work ...

--
Mihai Nita [Microsoft MVP, Windows - SDK]
http://www.mihai-nita.net
------------------------------------------
Replace _year_ with _ to get the real email