|
can anybody please tell me what these errors is saying....
email test error LNK2019: unresolved external symbol __beginthreadex referenced in function "public: int __thiscall CWinThread::CreateThread(unsigned long,unsigned int,struct _SECURITY_ATTRIBUTES *)" (?CreateThread@CWinThread@@QAEHKIPAU_SECURITY_ATTRIBUTES@@@Z)
email test error LNK2019: unresolved external symbol __endthreadex referenced in function "void __stdcall AfxEndThread(unsigned int,int)" (?AfxEndThread@@YGXIH@Z)
Thank you in advance 
|
|
|
|
|
I'm guessing you are not linking to the Multithread C Runtime library.
Make sure in your project settings C++/Code Generation/Runtime Library section you've set it
as one of the multithreaded options.
Mark
|
|
|
|
|
Did you set
/MT<code> for your project <br />
<br />
<div class="ForumSig"><div style="padding: 0; margin: 0; background-color: rgba(170, 214, 255, 1); text-align: center; font-family: Arial; font-weight: bold; font-style: italic; font-size: 9pt"><br />
<div style="color: rgba(255, 255, 255, 1); width: 300px"><br />
<hr width="250" size="7">WhiteSky<hr width="220" size="7"></div></div></div>
|
|
|
|
|
Look at sample.
<br />
int main(int, const char **) {<br />
int a = -2;<br />
unsigned b = 1;<br />
int array[5] = { 1, 2, 3, 4, 5 };<br />
int *ptr = array + 3;<br />
ptr = ptr + (a + b);
printf("%i\n", *ptr);
return 0;<br />
}<br />
Do you know why this code does not work on 64-bit system? Do you assured, what no similar errors founds in your code? Do you know other typical errors reduce to down state C++ code on 64-bit platforms?
Under the specified link you can find huge quantity of references to the documentation and article, devoted porting on 64-bit platforms.
http://www.viva64.com/links.php
http://www.viva64.com/articles.php
(Spam or not spam - People are interested.)
|
|
|
|
|
Karpov2007 wrote: The computer industry is changing, and 64-bit technology is the next, inevitable step.
There is nothing "changing" at all, 64-bit systems have been around for a long time. What you think 64-bit XP was the first... 
If you have a decent compiler, it will notify you about the 64-bit compatibility issues like in your example. Unless of course you don't like the warnings and turned the feature OFF!
|
|
|
|
|
WalderMort wrote: There is nothing "changing" at all, 64-bit systems have been around for a long time. What you think 64-bit XP was the first...
Yes. But, most 64 bit compilers today use the LP64 model (including Solaris, AIX, HP, Linux, MacOS native compilers), Microsoft however decided to use the LLP64 model.
This essential difference also will present programmers much unexpectedness.
WalderMort wrote: If you have a decent compiler, it will notify you about the 64-bit compatibility issues like in your example. Unless of course you don't like the warnings and turned the feature OFF!
Unfortunately, you are not right. Show me the compiler which is giving out the prevention on the resulted example. If you even will find such compiler, that is weight of other errors not diagnosed by compilers. I recommend familiarize with http://www.viva64.com/articles.php.
Static analyzers (Gimpel Software PC-Lint, Parasoft C ++ test) are engaged in search of considered errors. But they are grinded under model LP64 instead of LLP64. Especially they analyzers of the general will give purpose and considered problem not enough attention. Viva64 - the static analyzer which supports model LLP64. Also it is especially grinded for search of mistakes at carry of programs on 64-bit systems.
|
|
|
|
|
Nice SPAM 
As C++ programmers we should know our data types and how we're using them IMO.
Anyway, Microsoft's 64-bit compiler doesn't handle this line correctly?
ptr = ptr + (a + b); //Invalid pointer value on 64-bit platform
|
|
|
|
|
Nope, as the OP states their example works fine as 32bit but fails when compiled as 64bit.
The compiler gives no errors or warnings.
As an example, when i run as 64bit:
int *ptr = array + 3;
ptr = ptr + (a + b);
^
The disassembly shows ptr = ptr + (a + b):
As posted by OP
0000000000401078 mov eax,dword ptr [b]
000000000040107C mov ecx,dword ptr [a]
0000000000401080 add ecx,eax
0000000000401082 mov eax,ecx
0000000000401084 mov eax,eax <--- looks like an effective no-op to me (rax == eax)
0000000000401086 mov rcx,qword ptr [ptr]
000000000040108B lea rax,[rcx+rax*4] <--- bad math, rax wrong
000000000040108F mov qword ptr [ptr],rax
Change 'unsigned b = 1;' to 'int b = 1;'
0000000000401078 mov eax,dword ptr [b]
000000000040107C mov ecx,dword ptr [a]
0000000000401080 add ecx,eax
0000000000401082 mov eax,ecx
0000000000401084 cdqe <--- convert DWORD to QWORD (rax = sign extend of eax)
0000000000401086 mov rcx,qword ptr [ptr]
000000000040108B lea rax,[rcx+rax*4] <--- good math, rax correct
000000000040108F mov qword ptr [ptr],rax
The problem is with the unsigned b, change it to int b and everything is fine again.
To me this _should_ be a compiler bug.
The OP seems to imply it is correct (though possibly unexpected) behaviour for x64 compilers.
I've been doing x64 coding for the last year and never run into any issues like this.
[OP code - reposted for bug dissection]
int _tmain(int argc, _TCHAR* argv[])
{
int a = -2;
unsigned b = 1;
int array[5] = { 1, 2, 3, 4, 5 };
int *ptr = array + 3;
ptr = ptr + (a + b);
printf("%i\n", *ptr);
return 0;
}[/OP code]
...cmk
Save the whales - collect the whole set
|
|
|
|
|
Thanks that have estimated an example. I know many other examples.
The example of the change in the virtual function behavior.
class CWinApp {<br />
...<br />
virtual void WinHelp(DWORD_PTR dwData, UINT nCmd);<br />
...<br />
};<br />
<br />
class CSampleApp : public CWinApp {<br />
...<br />
virtual void WinHelp(DWORD dwData, UINT nCmd);<br />
...<br />
};
It is the common example which the developer may face while porting his application to the 64-bit architecture. Let’s follow the life-cycle of the developing of some application. Suppose it was being developed for Visual Studio 6.0. at first when the function "WinHelp" in class "CWinApp" had the following prototype:
virtual void WinHelp(DWORD dwData, UINT nCmd = HELP_CONTEXT);
It would be absolutely correct to implement the overlap of the virtual function in class "CSampleApp", as it is shown in the example. Then the project was placed into Visual Studio 2005 where the prototype of the function in class "CWinApp" underwent changes that consist in replacing "DWORD" type with "DWORD_PTR" type. On the 32-bit platform this program will continue to work properly for here "DWORD" and "DWORD_PTR" types coincide. Troubles will occur while compliling this code for the 64-bit platform. We get two functions with the same names but with different parameters the result of which is that the user’s code won’t be called.
There are also other issues which can prove on a 64-bit platform. I recommend to familiarize with article: Evgeniy Ryzhkov "Peculiarities of the Development of 64-bit Applications" in which it is possible to learn a lot of interesting on the given subjects: http://www.viva64.com/articles.php
|
|
|
|
|
I agree there are a number things to look out for when porting to 64bit.
I went through all this a year ago, i went through all my code checking every prototype (both mine and MS's) and promoting long to size_t (and other like things) where needed.
I consider the WinHelp error more of a (required) API change by MS that can break old code.
There are a bunch of other examples like that in the ODBC API, where SQLUINTEGER was changed to SQLULEN (see: sqltype.h for SQLULEN typedef).
Aside from all that, people are going to have a problem with you pushing your software here, that's why your OP was removed.
You would be better off showing the problem and a solution - posting a link to your software is not good enough.
...cmk
Save the whales - collect the whole set
|
|
|
|
|
Thank you for the details! I have no 64-bit compiler so I appreciate that!
cmk wrote: The problem is with the unsigned b, change it to int b and everything is fine again.
Of course. That's why I said that it's really up to us to know/use types correctly.
cmk wrote: To me this _should_ be a compiler bug.
The OP seems to imply it is correct (though possibly unexpected) behaviour for x64 compilers.
I don't believe it's correct behavior (hopefully someone will prove me wrong). I think the
disassembly shows that. Shouldn't the two DWORDs be promoted to QWORDs before the arithmetic?
Why is a treated as 32 bit instead of 64? And that's just for the "add". What happens after
is a WTF. Did something change in C pointer arithmetic? Did I miss a memo?
Anyway I'm glad I wouldn't code like that
Thanks again,
Mark
|
|
|
|
|
For the sake of flogging a dead horse ...
For those unaware of the changes in 64 arch:
The 64bit r?x registers extend the 32bit e?x registers
in the same way the 32bit registers extend the 16bit ?x registers.
Let's simplify the example and look at some variations:
1. Working
long a[] = {1, 2, 3};
long b = -1;
long *p = a + 2;
p = p + b;
movsxd rax,dword ptr [b] ; rax = ffffffff-ffffffff
mov rcx,qword ptr [p] ; rcx = 00000000-0012fec0
lea rax,[rcx+rax*4] ; rax = 00000000-0012febc
; rax*4 overflows gives ffffffff-fffffffc
; rcx + (rax*4) overflows, net effect is to sub 4 from rcx
; net effect is that we get the right value
mov qword ptr [p],rax ; p = 00000000-0012febc
2. Working, compiles using entirely different strategy
long a[] = {1, 2, 3};
ulong b = 1;
long *p = a + 2;
p = p - b;
mov eax,dword ptr [b] ; eax = 1, rax = 00000000-00000001
shl rax,2 ; rax *= 4, rax = 00000000-00000004
mov rcx,qword ptr [p] ; rcx = 00000000-0012fec0
sub rcx,rax ; rcx = 00000000-0012febc
mov rax,rcx ; rax = 00000000-0012febc
mov qword ptr [p],rax ; p = 00000000-0012febc
3. Fails, back to OP problem
long a[] = {1, 2, 3};
ulong b = 1;
long *p = a + 2;
p = p + (-b);
mov eax,dword ptr [b] ; eax = 1, rax = 00000000-00000001
neg eax ; eax = ffffffff, rax = 00000000-ffffffff
mov eax,eax ; noop, rax goes forth un sign extended
mov rcx,qword ptr [p] ; rcx = 00000000-0012fec0
lea rax,[rcx+rax*4] ; rax = 00000040-0012febc
; rax = 00000000-0012fec0 + (00000000-ffffffff * 4)
; rax = 00000000-0012fec0 + 00000003-fffffffc <- damn
mov qword ptr [p],rax ; p = 00000040-0012febc
What interests me is that
p = p - b;
produces such different code than
p = p + (-b);
when b is unsigned
...cmk
Save the whales - collect the whole set
|
|
|
|
|
The C and C++ languages state that in computations involving a mix of types, all values should be promoted to the largest type. In this case the expression (a + b) is performed first. Because a is int but b is unsigned int, a is promoted to unsigned int. That leaves the expression as 0xFFFFFFFE + 1, which has the value 0xFFFFFFFF.
That value is then added to ptr making an offset of nearly 4GB. It works on 32-bit only due to an overflow occurring. Whether or not that causes an access violation on 64-bit depends on what virtual memory is allocated and what the access mask is.
It feels like a pretty contrived example, though.
|
|
|
|
|
|
I stand by my original statement, i feel this _should_ be a compiler bug.
I am aware of type promotion rules, but i feel the compiler has more than enough info to 'do the right thing'.
The fact that turning on optimizations will generate correct code somewhat supports this view.
(I know _someone_ will say that even wrong code can produce right results now and then, to which i say  )
...cmk
Save the whales - collect the whole set
|
|
|
|
|
cmk wrote: I know _someone_ will say that even wrong code can produce right results now and then, to which i say
Sorry, I guess I will have to be that someone 
Seriously though, officially the code has undefined behavior, which means the C++ standard no longer imposes any requirements on what the code does, and does not require a diagnostic from the compiler. However, it's possible that the specific compiler used may document this behavior, in which case it would be safe to use (on that compiler), or it may issue a warning as a matter of QoI (quality of implementation).
--
Marcus Kwok
|
|
|
|
|
I have two dialogbars. I want docked them on right but in same column. one is on top of another.
lucy
|
|
|
|
|
You could nest them in a single CControlBar which is docked on the right.
|
|
|
|
|
Does anyone know of any image libraries that help aid with image manipulations and comparison. Something simerlar to Aforge but obviously in C++?
|
|
|
|
|
have you tried searching this site ?
|
|
|
|
|
yes but i havent found anything.
|
|
|
|
|
Hi All,
I need to write some application that getting some string and folder and check witch file in this folder ( the file are not Binary file - just text file ) contain the string that i looking.
What i mean is that i don't want to open each file and start to seek for the string.
In the windows search option we have this option to "search word or phrase in the file" - this what i looking for - how to do it with no using windows option.
Thanks for any help.
|
|
|
|
|
First thing you need to do it enumerate the directory for any file type that you are looking for. Use a combination of FindFirstFile() and FindNextFile(). Each file that you find, check the extension for whatever filetypes you want to look in ( ".txt" ). If it's a text file then open the file with CreateFile() or fopen(), read each line and do a string comparison for your string with strstr().
|
|
|
|
|
WalderMort wrote: ...then open the file with CreateFile() or fopen(), read each line and do a string comparison for your string with strstr().
But what about the "i don't want to open each file and start to seek for the string." requirement?
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
I presumed he meant he didn't want to open every single file with an arbritary file format. If you want to find something inside a file you are going to have to look inside it somehow.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
