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 CallUnmanagedMethod() // 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(inputString); // 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.StringToHGlobalAnsi 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.StringToHGlobalAnsi(text).ToPtr();
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]

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

#pragam managed
class ManagedWrapper
{
void CallUnmanagedMethod() // 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(inputString); // 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).

 

[Ben Voigt [C++ MVP]]

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.

 

[Creativ]

Sorry for the imcomplete code.
I just wrote it for my questions. Indeed for inputString there should
be a "delete inputString;"

Thanks for the your comments about the class lib objects accross the
boundary. That make sense.
Is there any documentation that I can read about that?

 

[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 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)

 

[David Wilkinson]

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".

 

[Ben Voigt [C++ MVP]]

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 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).

 

[Ben Voigt [C++ MVP]]

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 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 ...

 

[David Wilkinson]

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

Mihai:

It has to work, because that is what COM does.

 

[adebaene]

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

Except that the pure interface cannot use library objects in it's
definition (eg, you can't have a method that take a std::string as
parameter in your pure interface). This makes this approach not very
much better that a C-style interface, because you'are doomed to define
all types used in the interface - or use "compatible" types like the
ugly BSTR and it's awfull API.

Arnaud

 

[Mihai N.]

But I think I can understand why that would work ...

It has to work, because that is what COM does.

I believe you that it works. I was just find an
explanation why it does, and I think I did.
I don't accept that "it works because COM does,"
I would rather say "COM works because this works"

The reason that why it works is because a pure
interface object has certain memory layout.
(and was trying to figure out exactly what is so
special about a pure interface that allows it,
what that memory layout is and why)

 

[David Wilkinson]

I believe you that it works. I was just find an
explanation why it does, and I think I did.
I don't accept that "it works because COM does,"
I would rather say "COM works because this works"

The reason that why it works is because a pure
interface object has certain memory layout.
(and was trying to figure out exactly what is so
special about a pure interface that allows it,
what that memory layout is and why)

Mihai:

Yes, and COM relies on this same memory layout, which is what allows it
to be compiler independent.

[This is the only thing I know about COM; I never actually use it.]

 

[Ben Voigt [C++ MVP]]

I believe you that it works. I was just find an
explanation why it does, and I think I did.
I don't accept that "it works because COM does,"
I would rather say "COM works because this works"

The reason that why it works is because a pure
interface object has certain memory layout.
(and was trying to figure out exactly what is so
special about a pure interface that allows it,
what that memory layout is and why)

That memory layout is that the object starts with a pointer to the v-table.
It's pretty easy to be convinced that that would be compiler independent.

Now the v-table, which is an array of function pointers, also has to have a
predictable layout, and it's a little harder to believe it is compiler
independent. Yes, base class members have to be listed first, but why
should the ordering within a particular class be fixed? Well, I don't have
the standard to quote from, but apparently the Windows ABI requires that the
v-table be arranged in order of declaration. Thus the v-table neatly
side-steps the problem of name mangling because consumers don't have to
agree on the name, only the index into the v-table.

 

[Mihai N.]

Well, I don't have the standard to quote from, but apparently the

Windows ABI requires that the
v-table be arranged in order of declaration. Thus the v-table neatly
side-steps the problem of name mangling because consumers don't have to
agree on the name, only the index into the v-table.

This was also my guess when I wrote
"But I think I can understand why that would work ..."

Even if the standard does not require for this, it is a pretty simple
thing to keep from one version to the next.
The issue was about MS breaking compatibility.
I don't think they do this intentionally, and there are things easy
to keep (this kind of v-table layout) and things that are not so
easy to keep (the layout of some random class generated from templates).