|
I'm using the MFC collection data types in a VC++ 2003 application and am getting the "conversion from 'INT_PTR' to 'int', possible loss of data" when calling collection functions like GetSize() and such.
I know these "Warnings" are 64-bit Portability warnings that occur when using the default /Wp64 command line option. I am attempting to accomodate the warnings and adapt my code so that it will compile fine in a 64-bit environment (within reason)
Original code: (Used to work fine in Visual C++ 6.0)
///////////////////////////////////////
// Member variable
CArray<int,int&> m_someArray;
// typical usage
int nObjectCount=m_someArray.GetSize();
///////////////////////////////////////
My question is...
Which type (or typedef) should I use for my offset (int, INT, INT_PTR)?
int nObjectCount=(int)someArray.GetSize(); // OR
INT nObjectCount=(INT)someArray.GetSize(); // OR
INT_PTR nObjectCount=(INT_PTR)someArray.GetSize();
Thanks in advance for any guidance.
|
|
|
|
|
|
I'm not sure if that will properly prepare me for 64-bit compiling later as the standard types are going to remain 32-bit in size. I was under the impression that pointers were the only values that would be 64-bit without explicitly asking for it like _int64, DWORD64, INT64 etc...
size_t is defined as an unsigned int which would still be 32-bit under the 64-Bit Windows abstract data model.
Boy this is confusing... 
|
|
|
|
|
size_t is 32 bits long under 32 bits system (unsigned long), but 64 bits long under 64 bits system (__int64) !!!!
so it is exactly what you need, isn't it ?
TOXCCT >>> GEII power
[VisualCalc 3.0 updated ][Flags Beginner's Guide new! ]
|
|
|
|
|
Yes. I apologize as I did not dig deeper to find the __int64.
Thanks again for helping remove the confusion.
|
|
|
|
|
I'm confused too. 
<blockquote class="FQ"><div class="FQA">bob16972 wrote:</div>int nObjectCount=m_someArray.GetSize();</blockquote>
Are you compiling for 64 bit or 32 bit? Even if you are compiling for 32 bit, GetSize() returns an int and you are assigning that to an int, so there is no potential for truncation. If you are compiling for 64 bit, I can only assume that the the GetSize() method no longer returns an int, but returns some other type. Are there #ifdef's in the CArray header file that show what it returns differently for a 64 bit compile? If there are then you have to put the same kind of #ifdef's for your declarations prior to the assignment call.
But like I said at the start, I'm confused.
Chris Meech
I am Canadian. [heard in a local bar]
The America I believe in has always understood that natural harmony is only one meal away from monkey burgers. [Stan Shannon]
GOOD DAY FOR: Bean counters, as the Australian Taxation Office said that prostitutes and strippers could claim tax deductions for adult toys and sexy lingerie. [Associated Press]
|
|
|
|
|
GetSize used to return an int.
On VC++ 2003 it returns an INT_PTR
I'm doing everything under 32-bit but the warnings came up so I'm trying to use the INT_PTR but it's like a chain reaction since anything that uses the value needs to be prepared for it. In this case, it's an accessor function for a private member so my return value needs to be INT_PTR I guess and on down the line. It just had enough ripple effect that I thought I needed to question it.
Sorry about the confusion.
|
|
|
|
|
bob16972 wrote: On VC++ 2003 it returns an INT_PTR
That's a pretty significant change.  I'm guessing that this means you are given the address of where the size is stored, and thus when the size changes, in effect you will be notified. Regardless of the reason though, I think you need to change your code to
INT_PTR pObjectCount = m_someArray.GetSize(); and that should compile with the option you previously specified and not produce a warning.
Chris Meech
I am Canadian. [heard in a local bar]
The America I believe in has always understood that natural harmony is only one meal away from monkey burgers. [Stan Shannon]
GOOD DAY FOR: Bean counters, as the Australian Taxation Office said that prostitutes and strippers could claim tax deductions for adult toys and sexy lingerie. [Associated Press]
|
|
|
|
|
It's more of an offset in context so it would resemble x86 real mode offset pointers I guess.
"size" seems to be the agreeable term so far about it thus far. Tox pointed me to the size_t typedef which appears as if it would work. However, I'm inclined to use INT_PTR at this point as it should make the code readily understandable once INT_PTR becomes a household typedef methinks.
Thanks for the comments and help!
|
|
|
|
|
Just FYI, last time I checked (its been a little while, so 2005 may have changed it), INT_PTR and INT were the same thing (for a 32-bit build, they were longs, for 64-bit, they were long longs).
When using the MFC collection classes, I generally use whatever they return for as long as possible and only cast it if absolutely necessary. That usually saves a lot of headaches.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
Zac Howland wrote: use whatever they return for as long as possible and only cast it if absolutely necessary
I would agree. I just wrote the program in VC++ 6.0 which was "int" at that point so I'm going through the code adjusting accordingly.
Thanks for the advise!
|
|
|
|
|
I have built an IE (in a dialog-based application) using the microsoft webbrowser activex control.
I know how to get access to the IHTMLDocument and IHTMLElements.
Does any one know how to retrieve the distance the user has scrolled from the top of the page???
Thank you
llp00na
|
|
|
|
|
I believe you can get the get_scrollTop and get_scrollLeft functions of the
IHTMLTextContainer interface, which the IHTMLBodyElement object should implement.
- S
50 cups of coffee and you know it's on!
|
|
|
|
|
I want to include a header file (ServeurDicoView.h (hérited from CFormView.h) in a another class ( MySocket )
but when i put #include "CFormView.h"
i have too many errors like
error C2146: syntax error : missing ';' before identifier 'm_sListenSocket' as it's explained here :
Mot* tabSupp[100];<br />
MonSocket m_sListenSocket; <br />
MonSocket m_sConnectSocket;
in the "Monsocket.h"
#include "ServeurDicoView.h"
thanx for readin' my message .... and certainely for answering me 
i can't compile the "Monsocket.h"...
-- modified at 11:03 Wednesday 24th May, 2006
|
|
|
|
|
Mahhouraaaaaa wrote: #include "ServeurDicoView.h"
The view class is also dependent on the document class. If your going to couple your class to the view like this, you will also need to inclide the document class. (order of inclusion is important but I forget which one comes first). Also, it may take some jacking around with where your declarations are if they are shared by multiple classes. Sometimes forward declarations work, sometimes putting it in the stdafx.h etc...
Lastly, I hate it when others say "you shouldn't do it this way" but for what it's worth, just a friendly FYI, and I still resort to this from time to time so I'm guilty of it as well, but you should try to avoid close coupling your classes to the view/doc/app classes to promote simpler reuse. Sorry. It seems to be our civic duty to point that out around here till it's pouring out of our ears. For what it's worth...
|
|
|
|
|
HI all
I want to delete Internet Explorer's history , for this using method ClearHistory of IUrlHistoryStg2 interface.
the code that i am using is as follows
<br />
HRESULT hRes;<br />
IUrlHistoryStg2* pUrlHistoryStg2 = NULL;<br />
CoInitialize(NULL);<br />
<br />
hRes = CoCreateInstance(CLSID_CUrlHistory, NULL, <br />
CLSCTX_INPROC_SERVER, IID_IUrlHistoryStg2, <br />
(void**)&pUrlHistoryStg2);<br />
<br />
if(SUCCEEDED(hRes))<br />
{<br />
hRes = pUrlHistoryStg2 -> ClearHistory();<br />
}<br />
MessageBox("History is Cleaned");<br />
here the function succeeded bu does not clear the history.
Please suggest me how to clear history of Internet Explorer.
Thanks
|
|
|
|
|
|
See here.
"The largest fire starts but with the smallest spark." - David Crow
|
|
|
|
|
Hello!
Why does the boost::weak_ptr throw an exception when I'm trying to
construct an shared_ptr from it, if the weak_ptr has not been initialized?
Wouldn't it make more sense if the shared_ptr would be initialized
as an empty_ptr? (I have to check for emptyness anyway!)
Because of this I need an additional try-catch-block (in this case for
checking an integer value in the object pointed to)...
Alex
|
|
|
|
|
For standard toolbars the Studio creates a 16-color bitmap and puts all icons into that single bitmap. But what if you use third party controls that supports high-color icons, how do you manage your icons? Currently I have all icons in individual bmp files which I add to my resources and then set the icons manually at runtime, which is pretty painful. I also gave up to put them all into a single bitmap because I had to count the pixels to know where the new icon begins.
I would like to have a set of 16-color bitmaps and one with 24-bit, maybe 32-bit with alpha channel.
How do you manage your icons? Any tool recommendation?
|
|
|
|
|
Create bitmap in any tool you like, then import in into VS. I'm using http://www.awicons.com/awicons.html, but any special icon editor will do.
When you will need to edit bitmap, just open it in external tool, without doing anything in VS.
Igor Green
http://www.grigsoft.com/ - files and folders comparison tools
|
|
|
|
|
Thanks, but I'm not looking for a tool to create/paint the icons but for a tool where I can create a single bitmap out of the individuals and assign a Command ID to each button.
I'm looking for a tool like this:
http://www.codeproject.com/tools/ToolbarEditor.asp[^]
|
|
|
|
|
I feel that I really should know this, but I'm having an off-day, and I've just been told my car needs new wheel-bearings, a brake caliper and disc on one of the wheels, which would at least explain why I keep having to turn the radio up
I have a function int __cdecl xxx(const char* value, ...) which is in a C DLL. I'm writing a wrapper class which loads the DLL and and does a GetProcAddress to retrieve the function address. So far so good. Except that for my wrapper class, I'm providing a wrapper::xxx member which (having checked the DLL is loaded and the proc address isn't null) will call down through the pointer.
So I have
int xxx(const char*value,...)
as a member function, and
int (__cdecl *m_pf_xxx)(const char*,...)
as a member too.
What incantation do I need to get my class function to call via the pointer?
If it wasn't for the variable args, it would be
(*m_pf_xxx)(format);
but of course, I need to pass the other args if there are any...
The reason for doing it this way is that the DLL is a 3rd party one (one of a set, in fact), which is loaded at runtime. I can't simply delayload, since the DLL is specified by configuration at runtime, and the wrapper class handles multiple similar ones (think of a codec, for instance).
Like I say, I ought to know this; and before anyone suggests it, I can't change the DLLs, since they are 3rd party, and the developers are not interested in changing them (of course). Trouble is, I'm tied to using them in this instance.
Steve S
Developer for hire
|
|
|
|
|
you can't pass ... to ...
what you need is for the DLL to expose a va_list form of the function:
int (__cdecl *m_pf_xxx)(const char*, va_list)
then, in your wrapper, you can unpack the ... to a va_list and pass it to the DLL.
Cleek | Image Toolkits | Thumbnail maker
|
|
|
|
|
Thanks Chris, that's exactly what I was afraid of. 
The 3rd party are adamant that they won't change their code, but since the function in question is a 'convenience' one, I think I can emulate what it's doing, making calls to other functions within the DLL anyway. Having looked at stack frames, I can see why it wouldn't be possible.
I don't even want to think about playing with the stack frame to try and jump to the code, writing the emulation code in the wrapper would be much easier & faster...
Steve S
Developer for hire
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
