C++ std::string Parameter is <Bad Ptr>

I'm using Visual Studio 2010.

I have a class with the following constructor:

CVideoAnnotation::CVideoAnnotation(std::string aPort, DWORD aBaudRate)

I create an instance of CVideoAnnotation as follows:

CVideoAnnotation cVideoAnnotation("COM3", CBR_9600);

'CBR_9600' is a macro that resolves to 9600.

Down in the constructor, aBaudRate is 9600 as expected. However, aPort does not get passed properly. When I hover the cursor over it, IntelliSense gives a value of <Bad Ptr>.

Does anybody have any thoughts on why the string does not pass properly?

Thanks, Dave

As开发者_运维知识库 an update to my original question, I'm adding the assembly code for the constructor call and the population of locals once inside the constructor.

   CVideoAnnotation cVideoAnnotation("COM3", CBR_9600);
0041177D  push        2580h  
00411782  sub         esp,20h  
00411785  mov         ecx,esp  
00411787  mov         dword ptr [ebp-174h],esp  
0041178D  push        offset string "COM3" (4198C8h)  
00411792  call        std::basic_string<char,std::char_traits<char>,std::allocator<char> >::basic_string<char,std::char_traits<char>,std::allocator<char> > (41131Bh)  
00411797  mov         dword ptr [ebp-17Ch],eax  
0041179D  lea         ecx,[ebp-11h]  
004117A0  call        dword ptr [__imp_CVideoAnnotation::CVideoAnnotation (41D4DCh)]  
004117A6  mov         dword ptr [ebp-180h],eax  
004117AC  mov         dword ptr [ebp-4],0  





CVideoAnnotation::CVideoAnnotation(std::string aPort, DWORD aBaudRate)
{
100137F0  push        ebp  
100137F1  mov         ebp,esp  
100137F3  push        0FFFFFFFFh  
100137F5  push        offset __ehhandler$??0CVideoAnnotation@@QAE@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@K@Z (1001DC82h)  
100137FA  mov         eax,dword ptr fs:[00000000h]  
10013800  push        eax  
10013801  sub         esp,164h  
10013807  push        ebx  
10013808  push        esi  
10013809  push        edi  
1001380A  push        ecx  
1001380B  lea         edi,[ebp-170h]  
10013811  mov         ecx,59h  
10013816  mov         eax,0CCCCCCCCh  
1001381B  rep stos    dword ptr es:[edi]  
1001381D  pop         ecx  
1001381E  mov         eax,dword ptr [___security_cookie (10026090h)]  
10013823  xor         eax,ebp  
10013825  mov         dword ptr [ebp-10h],eax  
10013828  push        eax  
10013829  lea         eax,[ebp-0Ch]  
1001382C  mov         dword ptr fs:[00000000h],eax  
10013832  mov         dword ptr [ebp-18h],ecx  
10013835  mov         dword ptr [ebp-84h],0  
1001383F  mov         dword ptr [ebp-4],0  

---

If you are implementing CVideoAnnotation in a separate DLL then you are having a well know issue of crossing DLL boundaries when using STL containers. To verify that this is the case create a new constructor taking a const char* instead of std::string and try..

Another thing, instead of std::string prefer to use const std::string&

---

Passing string to and from DLLs should work just fine. As noted above using STL containers in this way can be problematic but string is fine.

Do you have any evidence beyond Intellisense that the string is messed up? In Release builds Intelliesnse can be sketchy. Try adding cout << aPort << endl; into that constructor to make sure.

If it really is incorrect I would just debug from the caller into the constructor call - see where the string is pushed as a parameter, and see where on the stack it's picked up from for use inside the constructor. Something must be out of sync here, assuming both DLL and app use the same version of the C++ runtimes, and you should be able to tell why by inspecting the assembler code.

---

"COM3" is not a std::string it is a const char *, try creating a std::string to pass in.

---

I too was fighting what looked like bad byte alignment resulting in . Based on the suggestions here that crossing library boundaries can be problematic, I suspected (even though I am using a static library instead of DLL) that I might be dealing with the same sort of problem. I was instantiating a class in one library whose code was in another. When I moved the instantiation into the library where its code was the problem went away. I don't understand why this worked but at least I can now move forward.