.NET Forum / Languages / Managed C++ / October 2007
passing std::string from visual studio 2005 to an C++ DLL generated by VC 6.0
|
|
Thread rating:  |
Creativ - 11 Oct 2007 09:55 GMT 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 - 11 Oct 2007 13:19 GMT > I've looked through this thread and still have quetions. > Suppose In visual studio 2005, I write the following [quoted text clipped - 11 lines] > } > } 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).
 Signature David Wilkinson Visual C++ MVP
Ben Voigt [C++ MVP] - 11 Oct 2007 17:23 GMT >> I've looked through this thread and still have quetions. >> Suppose In visual studio 2005, I write the following [quoted text clipped - 23 lines] > 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.
Mihai N. - 12 Oct 2007 04:53 GMT > 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.
 Signature Mihai Nita [Microsoft MVP, Windows - SDK] http://www.mihai-nita.net ------------------------------------------ Replace _year_ with _ to get the real email
Ben Voigt [C++ MVP] - 15 Oct 2007 15:17 GMT >> 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 N. - 16 Oct 2007 06:49 GMT > 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).
 Signature Mihai Nita [Microsoft MVP, Windows - SDK] http://www.mihai-nita.net ------------------------------------------ Replace _year_ with _ to get the real email
Ben Voigt [C++ MVP] - 16 Oct 2007 17:29 GMT >> That's not really a "public" interface then, but internal to one specific >> application, because it prevents generic reuse of the library. [quoted text clipped - 3 lines] > 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. - 17 Oct 2007 10:16 GMT > 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 ...
 Signature Mihai Nita [Microsoft MVP, Windows - SDK] http://www.mihai-nita.net ------------------------------------------ Replace _year_ with _ to get the real email
David Wilkinson - 17 Oct 2007 13:00 GMT >> 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:
It has to work, because that is what COM does.
 Signature David Wilkinson Visual C++ MVP
Mihai N. - 18 Oct 2007 04:59 GMT >> 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)
 Signature Mihai Nita [Microsoft MVP, Windows - SDK] http://www.mihai-nita.net ------------------------------------------ Replace _year_ with _ to get the real email
David Wilkinson - 18 Oct 2007 11:40 GMT >>> But I think I can understand why that would work ... > [quoted text clipped - 10 lines] > 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.]
 Signature David Wilkinson Visual C++ MVP
Ben Voigt [C++ MVP] - 18 Oct 2007 15:29 GMT >>> But I think I can understand why that would work ... > [quoted text clipped - 10 lines] > 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. - 19 Oct 2007 08:48 GMT > 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).
 Signature Mihai Nita [Microsoft MVP, Windows - SDK] http://www.mihai-nita.net ------------------------------------------ Replace _year_ with _ to get the real email
adebaene@club-internet.fr - 17 Oct 2007 13:39 GMT > 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
Creativ - 11 Oct 2007 19:37 GMT 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. - 12 Oct 2007 04:55 GMT > 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)
 Signature Mihai Nita [Microsoft MVP, Windows - SDK] http://www.mihai-nita.net ------------------------------------------ Replace _year_ with _ to get the real email
David Wilkinson - 12 Oct 2007 12:40 GMT >> 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".
 Signature David Wilkinson Visual C++ MVP
Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
|
|