[ACCEPTED]-#ifdef for 32-bit platform-32-bit

Accepted answer
Score: 18

I'm not sure if there is a universal #if 12 def that is appropriate. The C++ standard 11 almost certainly does not define one. There 10 are certainly platform spcefic ones though.

For 9 example, Windows

#if _WIN64 
// 64 bit build
#else
// 32 bit build
#endif

EDIT OP mentioned this is a 8 cross compile between Windows and Non-Windows 7 using GCC and other compilers

There is no 6 universal macro that can be used for all 5 platforms and compilers. A little bit of 4 preprocessor magic though can do the trick. Assuming 3 you're only working on x86 and amd64 chips 2 the following should do the trick. It can 1 easily be expanded for other platforms though

#if _WIN64 || __amd64__
#define PORTABLE_64_BIT
#else
#define PORTABLE_32_BIT
#endif
Score: 15

I recommend bookmarking the predef SourceForge. There's no 15 one answer, but it can certainly help you 14 get started.

EDIT: For GCC-only code, you 13 can use __i386__ to check for 32-bit x86 chips, and 12 I suggest trying __X86_64__ or something similar to 11 check for 64-bit x86 chips. (Note: It has 10 come to my attention that the previous answer 9 involving __ia86__ is actually a different chip, not 8 a 64-bit x86 chip. This just shows my lack 7 of hardware experience. For those more knowledgeable 6 about hardware than I, consule the SourceForge 5 page on predefined macros that I link to 4 above. It's much more accurate than I am.) There 3 are some other ones that would work, but 2 those two should be fairly universal amongs 1 GCC versions.

Score: 6

Have a look at that:

i386 macros
AMD64 macros

0

Score: 6

I would test it indirectly, via the maximum 5 pointer value constant:

#include <stdint.h>

#if UINTPTR_MAX == 0xffFFffFF
// 32-bit platform
#elif UINTPTR_MAX == 0xffFFffFFffFFffFF
// 64-bit platform
#else
#error Unknown platform - does not look either like 32-bit or 64-bit
#endif

This way you don't 4 rely on any platform-specific define for 3 architecture, but on the direct consequence 2 of having a specific architecture - the 1 pointer size.

Score: 5

You could check a well known type for it's 13 size e.g. sizeof(int*) == 4 for a 32 bit 12 platform.

As sizeof is known at compiletime 11 I believe a

if(sizeof(int*) == 4)
{
  ...
}

should do the trick

Edit: the 10 comments are right, you need to use a regular 9 if, #if won't work.

If you are using C++ You 8 could create templated code and let the 7 compiler choose the specialization for you 6 based on the sizeof() call. If you build 5 for a 32 bit platform the compiler would 4 only instantiate the code for the 32 bit 3 platform. If you build for a 654 bit platform 2 the compiler would only instantiate the 1 code for the 64 bit platform.

Score: 2

What I would probably end up doing, is within 6 a Makefile, determine if you are on a 32 5 bit platform or 64 bit using uname. Then, add 4 to your CFLAGS, -DX32, or -DX64. That you 3 could just #ifdef X64.

But this is just a 2 unixy solution. I'm not sure what I would 1 do on windows.

Score: 2

At least 32-bit Solaris has a limit of 256 41 file pointers because the structure stores 40 the file descriptor in an unsigned char 39 field. This is retained for backwards compatibility 38 with some almost impossibly old versions 37 of SunOS. Other platforms - I'm tempted 36 to say most other platforms - do not share 35 that limitation. On the other hand, it 34 is relatively unusual for an ordinary user 33 program to need that many files open concurrently; it 32 more often indicates a bug (not closing 31 the files when finished with them) than 30 not. Having said that, though, it can be 29 a problem for things like database servers 28 which need to have lots of data files open 27 at the same time.


One comment says:

That's 26 almost it. We don't have a large number 25 of files open, but the server handles a 24 large number of connections from clients. Socket 23 handles and file descriptors seem to come 22 from the same place. When we have a lot 21 of connections, 'fopen' fails because the 20 system-level call returns and fd > 255.

'Socket 19 handles' are file descriptors at the system 18 call level, so they come from the same place 17 as regular file descriptors for files.

If 16 you have to work around this, then you need 15 to wrap your current socket opening code 14 so that if it gets an file descriptor in 13 the range 0..255, then it calls 'dup2()' to create 12 a file descriptor in the range that stdio 11 won't use - and then close the original 10 file descriptor. The only snag with this 9 is that you have to keep track of which 8 file descriptors are available, because 7 dup2 will merrily close the target file descriptor 6 if it is currently open.

Of course, I'm assuming 5 your socket code reads file descriptors 4 and not file pointers. If that's the case, you 3 have bigger problems - too many things want 2 to use the same resources and they can't 1 all use them at the same time.

Score: 2

I use a construction like this for Windows:

#if defined(_WIN64)
   //64-bit code
#elif  defined(_M_IX86)
   //32-bit code
#else
#error "Unknown platform"
#endif

Versus:

#if defined(_WIN64)
  // 64 bit code
#else
  // 32-bit code
#endif

In 17 the former solution, because of the #error 16 the compiler will be able to tell you where 15 you need to add code for a new platform. This 14 aids maintainability should you ever encounter 13 a platform that is neither 64-bit nor 32-bit. Yes, the 12 _M_IX86 is not exactly synonymous with 32-bit, but 11 I think the only 32-bit platform most of 10 us are supporting is in fact x86. So as 9 a practical measure it suffices.

In the later 8 solution you'll have to manually figure 7 out where you need code for your new platform 6 using grep or something like that. This 5 is tedious and error prone.

It occurs to 4 me that the following construction would 3 also be acceptable, although I have not 2 tested it in production nor I have really 1 thought about it very much.

#if defined(_WIN64)
   //64-bit code
#elif  defined(_WIN32)
   //32-bit code
#else
#error "Unknown platform"
#endif
Score: 1

Depends on your OS and compiler, those are 1 implementation decisions.

Score: 0

I believe the define is _WIN64

0

Score: 0

There is no such symbol defined by the C++ standard 3 - your specific platform (which you haven't 2 specified in your question) may provide 1 one.

More Related questions