|
c++ is 32 based (win95 and above), nothing with processor.
result (exe) is always same.
it is impossible to find 64 bits from compiling.
includeh10
|
|
|
|
|
Hmm. But 64-bit is coming, that's for sure.
And Microsoft's C/C++ will compile 'int's as 32-bit, and 'long's as 32-bit, '__int64' will be 64-bit.
But GNU's GCC will compile 'int's as 32-bit, and 'long's as 64-bit.
Now, when I want to define a 64-bit type, how do I decide which type is the correct one?
Thanks for your reply
Dominik
_outp(0x64, 0xAD);
and
__asm mov al, 0xAD __asm out 0x64, al
do the same... but what do they do??
(doesn't work on NT)
|
|
|
|
|
cpp is OS related, if u compile a app under windows, don't hope to use it under unix, so nothing to warry about.
includeh10
|
|
|
|
|
includeh10 wrote:
cpp is OS related
I am currently programming a console-based tool for Windows and Linux. It compiles perfectly on both operating systems.
Dominik
_outp(0x64, 0xAD);
and
__asm mov al, 0xAD __asm out 0x64, al
do the same... but what do they do??
(doesn't work on NT)
|
|
|
|
|
it doesn't mean "OS independent".
and if it is at commercial level, i am surprised.
otherwise what is usage of 32 and 64?
includeh10
|
|
|
|
|
Why are you surprised?
I have floppy disks full of portable code that work as command line applications for Windows, MS-DOS or a number of UN*X variants and linux.
Steve S
|
|
|
|
|
includeh10 wrote:
cpp is OS related, if u compile a app under windows, don't hope to use it under unix
Actually, MFC is OS related. CPP should be portable.
|
|
|
|
|
cpp is OS related
I want you to tell me what you are talking about.
Thank You
Bo Hunter
|
|
|
|
|
You can do something like this to support both MSVC and GCC:
#ifdef __GNUC__<br />
typedef long long _int64_t;<br />
#else<br />
typedef __int64 _int64_t;<br />
#endif
The long long type in GCC is at least 64 bits wide on both 32-bit and 64-bit platforms.
- Mike
|
|
|
|
|
sizeof(int) works for all standard C and C++ compilers. By using sizeof and #include <limits.h> you should be able to make your code work correctly independently of the word size of the CPU.
|
|
|
|
|
|
Hello,
I am trying to define safe integer types. For example an UWORD8 should always be an 8-bit unsigned integer variable.
To define UWORD8, I tried this:
#if defined(__int8)
typedef unsigned __int8 UWORD8;
#elif (sizeof(char) == 1)
typedef unsigned char UWORD8;
#else
#error Cannot define an 8-bit unsigned integer type.
#endif
...
#if defined(__int64)
typedef unsigned __int64 UWORD64;
#elif (sizeof(int) == 8)
typedef unsigned int UWORD64;
#elif (sizeof(long) == 8)
typedef unsigned long UWORD64;
#elif (sizeof(long int) == 8)
typedef unsigned long int UWORD64;
#elif (sizeof(long long) == 8)
typedef unsigned long long UWORD64;
#else
#error Cannot define an 64-bit unsigned integer type.
#endif
But it doesn't compile. The compiler says:
fatal error C1017: invalid expression for integer constant ,
always in the lines where I check the sizeof()s.
What am I doing wrong? How would you define safe integer variables? Any better way?
Dominik
_outp(0x64, 0xAD);
and
__asm mov al, 0xAD __asm out 0x64, al
do the same... but what do they do??
(doesn't work on NT)
|
|
|
|
|
say, just one line in a cpp file:
int i=sizeof(int);
it causes a compile error because sizeof() is a runtime staff (similar call a function).
in ur file, u have multiple lines of the example.
includeh10
|
|
|
|
|
You are mixing up preprocess or commands and C++ keywords (which are compiled). sizeof and __int64 are not preprocessor commands so you can't have them in #if conditions.
The way to do what you want is test compiler-specific preprocessor constants and have a block of typedef s for each compiler. Eg:
#if defined(MSC_VER) && MSC_VER >= 1200 // MSVC 6+
typedef unsigned char UWORD8;
typedef unsigned __int16 UWORD16;
typedef unsigned __int32 UWORD32;
typedef unsigned __int64 UWORD64;
#elif defined (GNU_CPP) // or whatever GNU's symbol is
#endif
--Mike--
Ericahist | CP SearchBar v2.0.2 | Homepage | RightClick-Encrypt | 1ClickPicGrabber
There is a saying in statistics that a million monkeys pounding on typewriters would eventually create a work of Shakespeare. Thanks to the Internet, we now know that this is not true.
|
|
|
|
|
If your compiler has the inttypes.h header available (such as GCC), you're in luck. This header defines types such as int64_t and uint64_t . So, you might want to create something like this:
#ifdef __GNU_C__<br />
#include <inttypes.h><br />
#define HAS_INTTYPES<br />
#endif<br />
<br />
<br />
<br />
#ifndef HAS_INTTYPES<br />
#ifdef MSC_VER<br />
typedef __int64 int64_t;<br />
#elif __BORLANDC__<br />
typedef __int64 int64_t;<br />
#endif<br />
#endif
This was just off the top of my head. Hope this helps
- Mike
|
|
|
|
|
Hello everybody, I hope you`r all fine I have finished a project excecpt 1 thing i haven`t found any resource explain it Printing a Bell which contain : no,product`s name ,price ,total etc... how can i print it as you know the bell contains subjects i just want to print just what i sell[product info.] so any help will help thank you and big fat bye .
|
|
|
|
|
i know that normally i should code my drawing for eg a rectangle in SDI view.cpp. But my project(SDI) consists of several dialogs requiring user input for rect dimensions. so is it advisable to code in the view.cpp and with my member dialog variables declared there, or i can code my drawing in the respesctive dialogs.cpp and then point to SDI view? i tried the former and i get assertion error coz when the program was 1st run, it tried to draw the rect which should not be the case as i want the user to open the dialog within the SDI and input the dimensions then when "OK" is clicked only will the rectangle appear...can anyone advise?
btw, i was using opengl to draw my rect.
|
|
|
|
|
Generally speaking, proper architecture would suggest that code that draws in the view should be in the view class. If you want to prevent drawing until after soliciting user input, use a boolean or some other check to ensure that the drawing code doesn't execute until you're ready.
|
|
|
|
|
hmm,I am now trying to code my ONPAINT fuction in a dialog.cpp while keeping all the other ONCreate, OnDestroy, On Setpixeldescription in my view. How do I call a pointer to the view.cpp from my dialog ONPAINT? Is it feasible?
|
|
|
|
|
If you need a pointer to the view, just create a member variable of that type in the dialog class, and initialize it after creating, but before showing, the dialog. For instance, in the dialog header, you'd have something like
CMyView* m_ptrOwnerView;
In the function that creates the dialog,
CMyDialog md;
md.m_ptrOwnerView = this;
md.ShowModal();
However, if you're trying to draw into the view in response to the WM_PAINT message received by the dialog, you have a bit of a problem. You need to draw in response to the WM_PAINT received by the view, not that recieved by the dialog. The WM_PAINT messages sent to the dialog by the OS are not related to view. Re-think your architecture.
|
|
|
|
|
erm, okie i a bit confused over this WM_PAINT thing, so what u are saying is that, if i code my draw rect in my dialog's WM_PAINT function and then i point it to my CView, the CView will not be able to show the rect on screen is it? i been trying to find out the best way to show my grpahics on SDI window whenever user input dimensions into my dialog...so i know i have a problem linking this dialog to my view.then the best way is to code all my drawing into the CView WM_PAINT function?
|
|
|
|
|
Hello, everyone!
I often use the following three popular sleep methods under Linux and Windows platform, they are,
1. sleep
2. usleep
3. nanosleep
But I do not understand what are the special advantages and disadvantages of each sleep methods. Can anyone tell me what are their special advantages and disadvantages? Or attributes? Under what circumstance should I use them?
Thanks in advance,
George
|
|
|
|
|
You haven't "often used" sleep, usleep or nanosleep on the Windows platform, they are all Unix calls. You might have used Sleep (notice the capital). If it is really Linux coding help you want, this is not the best place for it.
--
-Blake (com/bcdev/blake)
|
|
|
|
|
Thanks, Blake buddy!
It seems that you are familiar with Linux/Unix platform. So can you tell me what is their special advantage or disadvantage?
If this is not the best place to discuss the problem, can you introduce me a best online forum or maillist that can be most helpful to me?
regards,
Geo
|
|
|
|
|
Not really, sorry. I was a Unix bigot for years, but I haven't been one since Linus was in middle school.
--
-Blake (com/bcdev/blake)
|
|
|
|