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.
Related
I have a question about performance. I think this can also applies to other languages (not only C++).
Imagine that I have this function:
int addNumber(int a, int b){
int result = a + b;
return result;
}
Is there any performance improvement if I write the code above like this?
int addNumber(int a, int b){
return a + b;
}
I have this question because the second function doesn´t declare a 3rd variable. But would the compiler detect this in the first code?
To answer this question you can look at the generated assembler code. With -O2, x86-64 gcc 6.2 generates exactly the same code for both methods:
addNumber(int, int):
lea eax, [rdi+rsi]
ret
addNumber2(int, int):
lea eax, [rdi+rsi]
ret
Only without optimization turned on, there is a difference:
addNumber(int, int):
push rbp
mov rbp, rsp
mov DWORD PTR [rbp-20], edi
mov DWORD PTR [rbp-24], esi
mov edx, DWORD PTR [rbp-20]
mov eax, DWORD PTR [rbp-24]
add eax, edx
mov DWORD PTR [rbp-4], eax
mov eax, DWORD PTR [rbp-4]
pop rbp
ret
addNumber2(int, int):
push rbp
mov rbp, rsp
mov DWORD PTR [rbp-4], edi
mov DWORD PTR [rbp-8], esi
mov edx, DWORD PTR [rbp-4]
mov eax, DWORD PTR [rbp-8]
add eax, edx
pop rbp
ret
However, performance comparison without optimization is meaningless
In principle there is no difference between the two approaches. The majority of compilers have handled this type of optimisation for some decades.
Additionally, if the function can be inlined (e.g. its definition is visible to the compiler when compiling code that uses such a function) the majority of compilers will eliminate the function altogether, and simply emit code to add the two variables passed and store the result as required by the caller.
Obviously, the comments above assume compiling with a relevant optimisation setting (e.g. not doing a debug build without optimisation).
Personally, I would not write such a function anyway. It is easier, in the caller, to write c = a + b instead of c = addNumber(a, b), so having a function like that offers no benefit to either programmer (effort to understand) or program (performance, etc). You might as well write comments that give no useful information.
c = a + b; // add a and b and store into c
Any self-respecting code reviewer would complain bitterly about uninformative functions or uninformative comments.
I'd only use such a function if its name conveyed some special meaning (i.e. more than just adding two values) for the application
c = FunkyOperation(a,b);
int FunkyOperation(int a, int b)
{
/* Many useful ways of implementing this operation.
One of those ways happens to be addition, but we need to
go through 25 pages of obscure mathematical proof to
realise that
*/
return a + b;
}
I have a weird problem when I create a release build with Visual Studio 2008. I was wondering if one of you could help me understand what is going on.
Description:
I have a class member function which returns a pointer to a structure stored in the class:
const MyStruct * Myclass::getPointer() {
return mystruct_variable; // this is properly initialyzed
}
One another point worth pointing out is that this class/method is in a dll, and I export it to use in a separate executable project. When I make a release build and try to use the above mentioned method, the run crashes depending on if the getPointer() method is inlined (i.e. placed in the header file part of the class) or not (placed in the cpp file).
The usage is:
const MyStruct * cf = myclassObj.getPointer();
int n = cf->size_t;
std::cout<<n<<std::endl;
When MyClass::getPointer() is inlined in the header the assembly looks like:
const MyStruct * cf = myclassObj.getPointer();
012514A8 mov esi,dword ptr [ebx+794h]
int n =cf->size_t;
012514AE mov eax,dword ptr [esi+20h]
std::cout<<n<<std::endl;
012514B1 mov ecx,dword ptr [__imp_std::endl (1252038h)]
012514B7 push ecx
012514B8 mov ecx,dword ptr [__imp_std::cout (125203Ch)]
012514BE push eax
012514BF call dword ptr [__imp_std::basic_ostream<char,std::char_traits<char> >::operator<< (1252048h)]
012514C5 mov ecx,eax
012514C7 call dword ptr [__imp_std::basic_ostream<char,std::char_traits<char> >::operator<< (1252044h)]
The same code when the class method for getPointer() is not inlined, and placed in the corresponding cpp file gives:
const MyStruct * cf = myclassObj.getPointer();
00DA14A8 mov ecx,ebx
00DA14AA call dword ptr [__imp_MyClass::getPointer(0DA2104h)]
int n =cf->size_t;
std::cout<<n<<std::endl;
00DA14B0 mov ecx,dword ptr [__imp_std::endl (0DA2038h)]
00DA14B6 mov esi,eax
00DA14B8 mov eax,dword ptr [esi+20h]
00DA14BB push ecx
00DA14BC mov ecx,dword ptr [__imp_std::cout (0DA203Ch)]
00DA14C2 push eax
00DA14C3 call dword ptr [__imp_std::basic_ostream<char,std::char_traits<char> >::operator<< (0DA2048h)]
00DA14C9 mov ecx,eax
00DA14CB call dword ptr [__imp_std::basic_ostream<char,std::char_traits<char> >::operator<< (0DA2044h)]
Any thoughts why the two cases have different assembly set? Am I doing something wrong?
Thanks!
If you link against a C++ DLL you must make sure all the compiler flags are exactly the same. Otherwise the size of structures, virtual tables etc. might be different and the code fails with an invalid access to memory. Inlining of course overcomes this as the code is inside the exe file, not in the dll, and thus compiled with the correct flags.
Simply put - for a release build use release DLL, for a debug build use debug DLL.
Enviroment: Microsoft Visual Studio 2010 with SP1 Preminum(10.0.40219.1 SP1Rel), Windows XP SP3
VC10 compiler support auto keyword, but the deduced type related information seems not always correct for enumeration.
example:
#include <type_traits>
enum fruit_t
{
apple = 100,
banana = 200,
};
int main()
{
const auto pa = new auto(banana);
const auto pb = new fruit_t(banana);
static_assert(std::is_same<decltype(pa), decltype(pb)>::value, "not same!");
delete pb;
delete pa;
}
The code above should have no compiler-time error or runtime error. But what suprising me is that, it compiles ok without any error or warning but, does not run correctly. The debugger tells after exit the main function:
HEAP CORRUPTION DETECTED: after %hs block (#55) at 0x00034878. CRT detected that the application wrote to memory after end of heap buffer.
so I guess that the compiler may have bug in "auto" type deduction. Assembler window below shows that, the requested memeory size in the first "operator new" call is 1 byte, while the second "operator new" 4 bytes. It suggests that the compiler has made a big mistake on the size of deduced type.
Did you think this is a compiler bug? And is there any bug fixes from Microsoft?
int main()
{
004113C0 push ebp
004113C1 mov ebp,esp
004113C3 sub esp,10Ch
004113C9 push ebx
004113CA push esi
004113CB push edi
004113CC lea edi,[ebp-10Ch]
004113D2 mov ecx,43h
004113D7 mov eax,0CCCCCCCCh
004113DC rep stos dword ptr es:[edi]
const auto pa = new auto(banana);
004113DE push 1
004113E0 call operator new (411181h)
004113E5 add esp,4
004113E8 mov dword ptr [ebp-104h],eax
004113EE cmp dword ptr [ebp-104h],0
004113F5 je main+51h (411411h)
004113F7 mov eax,dword ptr [ebp-104h]
004113FD mov dword ptr [eax],0C8h
00411403 mov ecx,dword ptr [ebp-104h]
00411409 mov dword ptr [ebp-10Ch],ecx
0041140F jmp main+5Bh (41141Bh)
00411411 mov dword ptr [ebp-10Ch],0
0041141B mov edx,dword ptr [ebp-10Ch]
00411421 mov dword ptr [pa],edx
const auto pb = new fruit_t(banana);
00411424 push 4
00411426 call operator new (411181h)
0041142B add esp,4
0041142E mov dword ptr [ebp-0F8h],eax
00411434 cmp dword ptr [ebp-0F8h],0
0041143B je main+97h (411457h)
0041143D mov eax,dword ptr [ebp-0F8h]
00411443 mov dword ptr [eax],0C8h
00411449 mov ecx,dword ptr [ebp-0F8h]
0041144F mov dword ptr [ebp-10Ch],ecx
00411455 jmp main+0A1h (411461h)
00411457 mov dword ptr [ebp-10Ch],0
00411461 mov edx,dword ptr [ebp-10Ch]
00411467 mov dword ptr [pb],edx
static_assert(std::is_same<decltype(pa), decltype(pb)>::value, "not same!");
delete pb;
0041146A mov eax,dword ptr [pb]
0041146D mov dword ptr [ebp-0ECh],eax
00411473 mov ecx,dword ptr [ebp-0ECh]
00411479 push ecx
0041147A call operator delete (411087h)
0041147F add esp,4
delete pa;
00411482 mov eax,dword ptr [pa]
00411485 mov dword ptr [ebp-0E0h],eax
0041148B mov ecx,dword ptr [ebp-0E0h]
00411491 push ecx
00411492 call operator delete (411087h)
00411497 add esp,4
}
Yes, I think it's a VS2010 bug. Running the same as you (or at least very similar) with XP SP3 (32-bit) and VS2010 SP1, I get the exact same error. It looks to be specific to enums, as trying it with classes showed everything working properly. I also tried adding another fruit item to the enum, with a value of 100000 just to make sure it wasn't something silly like your enum having all values below 255. Same result.
I did a quick search at Microsoft Connect, and I do not see a bug report for this, so I recommend that you enter one. That is the best way to make sure Microsoft knows and possibly get it fixed.
In the wake of this question about static methods in managed code, I'm interesting if the answers there is relevant to unmanaged code like c++.
I make thousands of instances, and my question is mainly about static methods. Do this methods save memory compared regular methods?
thank you, and sorry about my poor English.
All methods require their binary code to be in memory in order to run. The executable code for static and non-static methods is (largely) the same.
Both types of methods require only one place in memory, so they're not replicated with every instance of the class.
Let's now take a look at some code:
class A
{
public:
void foo();
static void goo();
};
void A::foo()
{
004113D0 push ebp
004113D1 mov ebp,esp
004113D3 sub esp,0CCh
004113D9 push ebx
004113DA push esi
004113DB push edi
004113DC push ecx
004113DD lea edi,[ebp-0CCh]
004113E3 mov ecx,33h
004113E8 mov eax,0CCCCCCCCh
004113ED rep stos dword ptr es:[edi]
004113EF pop ecx
004113F0 mov dword ptr [ebp-8],ecx
}
004113F3 pop edi
004113F4 pop esi
004113F5 pop ebx
004113F6 mov esp,ebp
004113F8 pop ebp
004113F9 ret
void A::goo()
{
00411530 push ebp
00411531 mov ebp,esp
00411533 sub esp,0C0h
00411539 push ebx
0041153A push esi
0041153B push edi
0041153C lea edi,[ebp-0C0h]
00411542 mov ecx,30h
00411547 mov eax,0CCCCCCCCh
0041154C rep stos dword ptr es:[edi]
}
0041154E pop edi
0041154F pop esi
00411550 pop ebx
00411551 mov esp,ebp
00411553 pop ebp
00411554 ret
int main()
{
A a;
a.foo();
0041141E lea ecx,[a]
00411421 call foo (4111E5h)
a.goo();
00411426 call A::goo (4111EAh)
return 0;
}
There are only minor differences, such as pushing the this pointer onto the stack for the non-static function, but they are minor, and probably a decent optimizer will reduce the differences even further.
A decision about whether or not to use static functions should be strictly design-driven, not memory-driven.
Static methods are essentially just free functions and so their memory footprint is the same. Member functions have an extra parameter and so the added memory is slightly larger, although it's meaningless to care about such things.
The amount of memory a function takes up is per-class, not per-instance. You shouldn't be concerned.
Short answer: No. A method is a function with an implicit first argument equal to its class, and a static function lacks this first argument. Actually, the situation is just the same as in garbage collected languages, so the answers to the other question apply fully.
The difference between a static and instance method is just the first parameter. In C++ all instance methods compile to a normal function with a substituted first parameter called this which is a pointer to the object on which the method was called.
On most architectures this will be an 8-byte value, so it's not really significant unless you're doing some very resource-strict embedded systems coding.
If you've been programming for a while then you probably noticed something completely impossible occurs every now and then for which you are convinced there is no possible explanation ("IT'S A COMPILER BUG!!"). After you find out what it was caused by though you are like "oooohhh".
Well, it just happened to me :(
Here AuthDb is NOT NULL but a valid pointer:
SingleResult sr(AuthDb, format("SELECT Id, Access, Flags, SessionKey, RealmSplitPreference FROM accounts WHERE Name = '%s'") % Escaped(account_name));
Here it mysteriously becomes NULL:
struct SingleResult : public BaseResult
{
SingleResult(Database *db, const boost::format& query) { _ExecuteQuery(db, query.str()); }
}
Notice that it's the immediate next call. It can be explained much better with two screenshots:
http://img187.imageshack.us/img187/5757/ss1zm.png
http://img513.imageshack.us/img513/5610/ss2b.png
EDIT: AuthDb is a global variable. It itself keeps pointing to the right thing; but the copy of the ptr Database *db points at NULL.
ASM code (unfortunately I don't even know how to read it :/)
Of the first screenshot
01214E06 mov eax,dword ptr [ebp-328h]
01214E0C push eax
01214E0D push offset string "SELECT Id, Access, Flags, Sessio"... (13C6278h)
01214E12 lea ecx,[ebp-150h]
01214E18 call boost::basic_format<char,std::char_traits<char>,std::allocator<char> >::basic_format<char,std::char_traits<char>,std::allocator<char> > (11A3260h)
01214E1D mov dword ptr [ebp-32Ch],eax
01214E23 mov ecx,dword ptr [ebp-32Ch]
01214E29 mov dword ptr [ebp-330h],ecx
01214E2F mov byte ptr [ebp-4],2
01214E33 mov ecx,dword ptr [ebp-330h]
01214E39 call boost::basic_format<char,std::char_traits<char>,std::allocator<char> >::operator%<Snow::Escaped> (11A3E18h)
01214E3E push eax
01214E3F mov edx,dword ptr [__tls_index (144EC40h)]
01214E45 mov eax,dword ptr fs:[0000002Ch]
01214E4B mov ecx,dword ptr [eax+edx*4]
01214E4E mov edx,dword ptr [ecx+12A3Ch]
01214E54 push edx
01214E55 lea ecx,[sr]
01214E58 call Snow::SingleResult::SingleResult (11A27D4h)
01214E5D mov byte ptr [ebp-4],4 // VS GREEN ARROW IS HERE
01214E61 lea ecx,[ebp-150h]
01214E67 call boost::basic_format<char,std::char_traits<char>,std::allocator<char> >::~basic_format<char,std::char_traits<char>,std::allocator<char> > (11A1DBBh)
01214E6C mov byte ptr [ebp-4],5
01214E70 lea ecx,[ebp-170h]
01214E76 call Snow::Escaped::~Escaped (11A42D2h)
const bool account_found = !sr.Error();
01214E7B lea ecx,[sr]
01214E7E call Snow::BaseResult::Error (11A2964h)
01214E83 movzx eax,al
01214E86 test eax,eax
01214E88 sete cl
01214E8B mov byte ptr [account_found],cl
if (!account_found) {
01214E8E movzx edx,byte ptr [account_found]
01214E92 test edx,edx
01214E94 jne AuthSession+1C0h (1214F10h)
client.Kill(format("%s: Attempted to login with non existant account `%s'") % client % account_name, true);
Second screenshot
011A8E7D mov dword ptr [ebp-10h],ecx
011A8E80 mov ecx,dword ptr [this]
011A8E83 call Snow::BaseResult::BaseResult (11A31D9h)
011A8E88 mov dword ptr [ebp-4],0
011A8E8F lea eax,[ebp-30h]
011A8E92 push eax
011A8E93 mov ecx,dword ptr [query]
011A8E96 call boost::basic_format<char,std::char_traits<char>,std::allocator<char> >::str (11A1E01h)
011A8E9B mov dword ptr [ebp-34h],eax
011A8E9E mov ecx,dword ptr [ebp-34h]
011A8EA1 mov dword ptr [ebp-38h],ecx
011A8EA4 mov byte ptr [ebp-4],1
011A8EA8 mov edx,dword ptr [ebp-38h]
011A8EAB push edx
011A8EAC mov eax,dword ptr [db]
011A8EAF push eax
011A8EB0 mov ecx,dword ptr [this]
011A8EB3 call Snow::SingleResult::_ExecuteQuery (124F380h)
011A8EB8 mov byte ptr [ebp-4],0 // VS GREEN ARROW HERE
011A8EBC lea ecx,[ebp-30h]
011A8EBF call std::basic_string<char,std::char_traits<char>,std::allocator<char> >::~basic_string<char,std::char_traits<char>,std::allocator<char> > (11A2C02h)
011A8EC4 mov dword ptr [ebp-4],0FFFFFFFFh
011A8ECB mov eax,dword ptr [this]
011A8ECE mov ecx,dword ptr [ebp-0Ch]
011A8ED1 mov dword ptr fs:[0],ecx
011A8ED8 pop edi
011A8ED9 add esp,38h
011A8EDC cmp ebp,esp
011A8EDE call _RTC_CheckEsp (12B4450h)
011A8EE3 mov esp,ebp
011A8EE5 pop ebp
011A8EE6 ret 8
UPDATE
Following the suggestion of peterchen, I added ASSERT(AuthDb); here:
ASSERT(AuthDb);
SingleResult sr(AuthDb, format("SELECT Id, Access, Flags, SessionKey, RealmSplitPreference FROM accounts WHERE Name = '%s'") % Escaped(account_name));
And it failed O.o And yet the debugger keeps insisting that it's not NULL.. It's not shadowed by a local
UPDATE2*
cout << AuthDb; is 0 in there even if the debugger says it's not
FOUND THE PROBLEM
Database *AuthDb = NULL, *GameDb = NULL; in a .cpp
extern thread Database *AuthDb, *GameDb; in a .h
The variable was marked thread (TLS - Thread local storage) in the header, but not TLS in the definition...
Countless hours wasted on this super stupid mistake, no warnings or hints or anything from the compiler that I feel like killing right now. :( Oh well, like I said for each impossible behavior there is a solution that once known seems obvious :)
Thanks to everyone who helped, I was really desperate!
Is AuthDB a thread-local variable?
Maybe the debugger isn't handling it correctly. What if you ASSERT(AuthDB) before the constructor is called?
UPDATE: If it is thread-local, it simply hasn't been initialized in this thread.
One possibility is that in the second screenshot, you have the debugger stopped at the very beginning of the function, before the stack has been manipulated, and so the variable locations aren't correct. You might also be after the end of the function, where the stack has already been torn down. I've seen that sort of thing before.
Expand that function to be a multiline function, so that it looks like this:
struct SingleResult : public BaseResult
{
SingleResult(Database *db, const boost::format& query)
{
_ExecuteQuery(db, query.str());
}
}
... and see if it still shows db as null when you have the debugger stopped on the _ExecuteQuery line.
Do you have a local AuthDB that is null and hides your global one?
(I'd expect the debugger in this case to correctly show you the local one... but with VS quality decay, I'd not rely on that)
I'd change the code to:
_ASSERTE(AuthDb);
SingleResult sr(AuthDb, format(...));
....
struct SingleResult : public BaseResult
{
SingleResult(Database *db, const boost::format& query)
{
_ASSERTE(db);
_ExecuteQuery(db, query.str());
}
}
And follow the disassembly in the debugger.
Well I'm not sure what classes/functions you're using here, but from a quick glance, shouldn't it be:
SingleResult sr(AuthDb, format("SELECT Id, Access, Flags, SessionKey, RealmSplitPreference FROM accounts WHERE Name = '%s'", Escaped(account_name)));
instead of:
SingleResult sr(AuthDb, format("SELECT Id, Access, Flags, SessionKey, RealmSplitPreference FROM accounts WHERE Name = '%s'") % Escaped(account_name));
It seems to me you're putting a modulus of the of Escaped(account_name) rather than passing that as an argument to format. However, I could just be confused.
Mike
I have no guess what is going on, but if I were debugging this I would be looking at the assembly language to see what is happening. You may need to get a better understanding of your platforms calling convention (i.e. how are arguments passed, on the stack, in registers, etc.) to troubleshoot this.
There is likely a bug somewhere else in your program. I suggest you find the problem by looking elsewhere in your code.
Another possibility--you might be looking at a memory overwrite due to a wild pointer somewhere.
Assuming your debugger supports it when you hit the first line set a memory-write breakpoint on AuthDb.