Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / Languages / Managed C++ / October 2007

Tip: Looking for answers? Try searching our database.

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

Thread view: 
Enable EMail Alerts  Start New Thread
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 Magazines

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

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.