I have written a small conditional statement in a dll project in visual studio 2010 as below.
#ifndef WINDOWS
int a=10;
#endif
From the above conditional statemnt, for windows operating system this statement(int a=10) should not be included.But this statement (int a=10) also included while compiling.
I am unable to find the problem.
Since WINDOWS is not defined anywhere, the variable will be included. There is no such pre-defined macro.
Try #ifndef _WIN32 or #ifndef __WIN32.
Macros to identify the OS are defined by the compiler in question.
Quoting from 64-Bit Compiler:
Predefined macros
The compiler defines the following macros to identify the platform.
Macro Meaning
_WIN64 A 64-bit platform.
_WIN32 A 32-bit platform. This value is also defined by the 64-bit compiler for backward compatibility.
_WIN16 A 16-bit platform.
The following macros are specific to the architecture.
Macro Meaning
_M_IA64 A 64-bit Intel platform.
_M_IX86 A 32-bit Intel platform.
Related
In a c program I want to do different things. This program will run on x86/x64 based GNU/Linux system as well as ARM based one e.g. on a PC or RaspberryPI.
Is there predefined macros in GCC to tell the platform?
something like
#ifdef _X64_
/do x64 stuff
#elif _ARM_
//do arm stuff
#endif
Or maybe that is the wrong approach? I will be using Makefileto compile and I could get away with my own defines.
What would be the best/safest approach?
This has already been answered on these posts:
GCC predefined macros for architecture X, Detecting CPU architecture compile-time
You can have them here:
http://sourceforge.net/p/predef/wiki/Architectures/
Your approach should only be used for small portions of code or functions but it should work.
Edit:
Basically, because links can become invalid:
__arm__ should work on ARM.
__x86_64__ should work on x64 architecture.
And yes, you can do:
#ifdef __x86_64__
// do x64 stuff
#elif __arm__
// do arm stuff
#endif
I'm trying to use the stdbool.h library file in a C program. When I try to compile, however, an error message appears saying intellisense cannot open source file stdbool.h.
Can anyone please advise how I would get visual studio to recognise this? Is this header file even valid? I'm reading a book on learning C programming.
typedef int bool;
#define false 0
#define true 1
works just fine. The Windows headers do the same thing. There's absolutely no reason to fret about the "wasted" memory expended by storing a two-bit value in an int.
As Alexandre mentioned in a comment, Microsoft's C compiler (bundled with Visual Studio) doesn't support C99 and likely isn't going to. It's unfortunate, because stdbool.h and many other far more useful features are supported in C99, but not in Visual Studio. It's stuck in the past, supporting only the older standard known as C89. I'm surprised you haven't run into a problem trying to define variables somewhere other than the beginning of a block. That bites me every time I write C code in VS.
One possible workaround is to configure Visual Studio to compile the code as C++. Then almost everything you read in the C99 book will work without the compiler choking. In C++, the type bool is built in (although it is a 1-byte type in C++ mode, rather than a 4-byte type like in C mode). To make this change, you can edit your project's compilation settings within the IDE, or you can simply rename the file to have a cpp extension (rather than c). VS will automatically set the compilation mode accordingly.
Modern versions of Visual Studio (2013 and later) offer improved support for C99, but it is still not complete. Honestly, the better solution if you're trying to learn C (and therefore C99 nowadays) is to just pick up a different compiler. MinGW is a good option if you're running on Windows. Lots of people like the Code::Blocks IDE
Create your own file to replace stdbool.h that looks like this:
#pragma once
#define false 0
#define true 1
#define bool int
In Visual Studio 2010 I had an issue using typedef int bool; as suggested elsewhere. IntelliSense complained about an "invalid combination of type specifiers." It seems that the name "bool" is still special, even though it's not defined.
Just as a warning, on x64 platforms, VS2017 (I'm not sure about previous versions) defines bool as a value of 1 byte on C++ (e.g. a char). So this
typedef int bool;
could be really dangerous if you use it as an int (4 bytes) in C files and as a native bool in C++ (1 byte) (e.g. a struct in a .h might have different sizes depending if you compile it with C or C++).
with MVS2008, this line works fine:
_fsopen(file_name, "wb+", _SH_DENYRW);
Borland C++builderX from 2003 complains about the argument _SH_DENYRW. I changed to
_fsopen(file_name, "wb+", SH_DENYRW);
removing the underscore and Borland compiles well now. Is it good what I'm doing? I saw this modification somewhere on the web.
Thanks a lot..
Microsoft has been working bit by bit over time to make the names used in their C/C++ headers and libraries more standards compliant (though they aren't necessarily doing the same for names in the SDK headers and libraries - a subtle but important distinction). So you'll find that more and more of names that aren't in the standard are being prefixed with an underscore.
But MS often provides the ability to use the old, non-standards compliant names for backwards compatibility. You should be able to use the SH_DENYRW name in either MSVC or Borland unless you're telling the compiler to use strict standards compliance (for example, with the /Za option), since MSVC defines the following in share.h:
#if !__STDC__
/* Non-ANSI names for compatibility */
#define SH_DENYRW _SH_DENYRW
#define SH_DENYWR _SH_DENYWR
#define SH_DENYRD _SH_DENYRD
#define SH_DENYNO _SH_DENYNO
#endif
#endif /* _INC_SHARE */
Is there a simple preprocessor macro that is defined for a 64-bit build? I thought _WIN64 might have been it, but even when I build a 32-bit target, the parts enclosed in a #ifdef _WIN64 ... #endif are compiled in, and this is causing problems. It's Friday and I can't think straight, but I'm sure I'm overlooking something very simple here. Maybe even something involving sizeof.
I have always used _WIN64 to check if it is a 64 bit build.
N.B. _WIN32 is also always (automatically) defined by MSVC in 64 bit builds, so check for _WIN64 before you check for _WIN32:
#if defined( _WIN64 )
// Windows 64 bit code here
#elif defined( _WIN32 )
// Windows 32 bit code here
#else
// Non-Windows code here
#endif
It sounds like your problem might be related to a header or project setting improperly defining _WIN64 - that should be left to the compiler.
There's a subtle difference between WIN64 and _WIN64 (at least for the Microsoft compilers - other compilers should follow suit, but not all do):
_WIN64 is defined by the compiler when it's building a program for a Windows 64-bit platform. Note that this name is in the compiler implementor's namespace (leading underscore followed by a capital letter)
WIN64 is defined by the Windows Platform SDK (or whatever they're calling it this year) when targeting a 64-bit platform.
So if you're only including standard headers and don't take other measures to define it, WIN64 will not be defined.
There's a similar story for _WIN32 and WIN32 - but checking other compilers: GCC 3.4.5 does define WIN32 even if only standard headers are used. As does Digital Mars.
Microsoft's compilers and Comeau do not.
Another bit of (hopefully) well known trivia is that _WIN32 and WIN32 are set when targeting 64-bit Windows platforms. Too much stuff would have broken otherwise.
The Visual C++ compiler defines the following macros:
_M_IX86 - x86 platform
_M_IA64 - ia64 platform
_M_X64 - x64 platform
Check your project's build properties, particularly the preprocessor section. Are you defining _WIN64 somewhere in WIN32 builds? The sizeof thing probably won't work since you cannot use in a #if test.
I am about to port a Windows 32 Bit application to 64 Bit, but might decide to port the whole thing to Linux later.
The code contains sections which are dependent on the amount of memory available to the application (which depends on whether I'm creating a 32 or 64 Bit build), while the ability to compile a 32 Bit version of the code should be preserved for backward compatibility.
On Windows, I am able to simply wrap the respective code sections into preprocessor statements to ensure the right version of the code is compiled.
Unfortunately I have very few experience on programming on the Linux platform, so the question occurred:
How am I able to identify a 64 Bit build on the Linux platform?
Is there any (preferably non-compiler-specific) preprocessor define I might check for this?
Thanks in advance!
\Bjoern
Assuming you are using a recent GNU GCC compiler for IA32 (32-bit) and amd64 (the non-Itanium 64-bit target for AMD64 / x86-64 / EM64T / Intel 64), since very few people need a different compiler for Linux (Intel and PGI).
There is the compiler line switch (which you can add to CFLAGS in a Makefile) -m64 / -m32 to control the build target.
For conditional C code:
#if defined(__LP64__) || defined(_LP64)
#define BUILD_64 1
#endif
or
#include <limits.h>
#if ( __WORDSIZE == 64 )
#define BUILD_64 1
#endif
While the first one is GCC specific, the second one is more portable, but may not be correct in some bizarre environment I cannot think of.
At present both should both work for IA-32 / x86 (x86-32) and x86-64 / amd64 environments correctly. I think they may work for IA-64 (Itanium) as well.
Also see Andreas Jaeger's paper from GCC Developer's Summit entitled, Porting to 64-bit GNU/Linux Systems which described 64-bit Linux environments in additional detail.
According to the GCC Manual:
__LP64__
_LP64
These macros are defined, with value 1, if (and only if) the
compilation is for a target where long
int and pointer both use 64-bits and
int uses 32-bit.
That's what you need, right?
Also, you can try
#define __64BIT (__SIZEOF_POINTER__ == 8)