I am compiling a legacy C code here and there is a lot of variables and struct members named "interface", but VC2008 express is complaining about these, do you know how to disable this?
I already changed settings to compile the code only as a C code, but no effect on this.
Problem is that MS #defines interface to struct so that
interface Name {...}
can be used in COM c++ code.
(objbase.h:199: #define interface __STRUCT__)
Just #undef interface after including Windows.h ..
Do a
#define interface QQInterface
before your code (eg. in the header file), this way everywhere where the keyword interface is used, the compilers sees "QQInterface", which is not a keyword. If all code includes this define, you will not get compiler or linker errors.
If you are trying to compile reasonably portable C code, it might be worth disabling the Microsoft language extensions (/Za on the command line, Configuration Properties > C/C++ > Language in VS) and see if the code compiles then.
"interface" a should not be a keyword in C nor ISO C++. It is a keyword in the Managed Extensions for C++, so, I guess, somewhere in your configuration you are still telling it to create code for .NET. Make sure everywhere is set to "Native Code"
However, it's quite possible that you CANNOT set it to Native Code in the Express edition --- That's just a guess, but it reasonable considering MS positioning of the Express/Standard/Pro editions.
UPDATE: Disregard that last paragraph. MSFT insists that you can create native Win32 apps with VisualC++ Express: http://www.microsoft.com/express/vc/
I faced a similar problem while compiling C++ code which included a dbus header file. since dbus has several functions where it uses "interface" as an I/P parameter name, which happens to be C++ keyword, I got following error: error: expected ',' or '...' before 'struct'.
When I tried this:
#ifdef interface
#undef interface
#endif
it solved the issue.
Not sure if using dbus C++ binding would have been better. Anyways I was not using dbus, just had a remote dependeny on one of dbus headers, this solution just worked fine!!
You can define WIN32_LEAN_AND_MEAN to avoid inclusion of this definition. See MSDN Docs
Related
I am working on a static analysis tool for C. I need to pass the code being analysed through the C preprocessor so that the tool can see the library function prototypes, type definitions, etc. Unfortunately both with clang on Mac OS X and gcc on Linux distros, some of the standard header files refer to compiler built-in types like __builtin_va_list that my tool doesn't know about. Does anyone have any suggestions for how to work around this. One possibility, if it's available somewhere, would be a vanilla-flavoured set of header files that produce C that conforms strictly to the standard. The header files don't have to map to any ABI, as the tool doesn't need to compile and run the code: they just have to give the API promised by the C standard. Any suggestions will be gratefully received.
Instead of finding a set of standard standard header files, you can just use a set of empty files with the expected names and pass the source code through the compiler preprocessor with a -Idirectory option. Your syntax analysis tool should be able to deal with the remaining symbols.
It would be useful to have a preprocessor option in addition to -dI to preserve #include lines instead of handling them.
In the mean time, you can try using the include files from my nolibc repository.
basically I am programming on a Mac, but I'm using source code from a group at school that had "windows.h" included.
I did some research and apparently there is no replica of that file for OSX.
I saw an answer on a thread here that said it was possible to make a "dummy" windows.h file and just insert whatever #includes or function prototypes I needed. To do this I just went online and got the functions I needed from some Microsoft directories.
I proceeded to do that and everything was working fine until the ZeroMemory function gave me errors.
So, inside of my dummy "windows.h" file:
void ZeroMemory([in] PVOID Destination,[in] SIZE_T Length);
I get these errors:
Expected parameter declarator
Use of undeclared identifier 'in'
Expected ')'
Now, I have googled the function and its errors and I keep finding a bunch of code that just has this line of code in it, which doesn't really help much.
What I need to know is where do I go from here? Am I doing the right thing by creating this "dummy" windows.h file? Or is there another way to get around using windows.h?
The link I found the answer to use a dummy windows.h file is here.
I appreciate all the input, so if you have anything on your mind, please throw it down! Thanks so much everyone!
After changing some of the code according to the comments:
void ZeroMemory(PVOID Destination, SIZE_T Length);
I get these errors:
Unknown type name PVOID
Unknown type name SIZE_T
I was thinking there may be some definitions I am missing but these are TYPE names, so they must be coming out of something like a Struct? Correct me if I'm wrong please? :D
If your header has [in] annotations then you grabbed the wrong file, most likely the IDL file instead of the actual header. In the header it should be _In_ instead, which will be an empty macro. In any case, you'll still have problems because you'll be missing the definitions of things like SIZE_T as you discovered. Unless you want to go and replace every dependency you hit, I'd recommend just replacing the calls themselves with your own versions. For ZeroMemory(p,s), you should be able to replace it trivially with memset(p,0,s). This of course assumes you're only using trivial functionality in the Windows header. If you're using actual platform-specific stuff like windowing, input, etc. then you'll probably just need to get a machine or VM running Windows.
It is a very bad habit that developers on the windows platform tend to fall into, including "windows.h" in simple applications that otherwise conform to standard C or C++.
The most correct option would be to encourage the other students / teacher? to only use standard c or c++ header files when writing their applications. This will ensure that they do not use any windows api specific functions.
You can, of course, create a windows.h, and inline in any trivial windows methods (As MooseBoys answers, ZeroMemory can be trivially implemented with memset) to be able to compile simple programs without altering them, but sooner or later some program is going to use a windows api with no easy or convenient standard C / C++ or CoreFoundation (On OSX, the equivalent framework to access windowing things) equivalent.
I am not a native english speaker, so please excuse any spelling or grammar mistakes
I am not a compiling expert, nor do I have any useful experience with builds and their errors
I am C# programmer and mainly working in an MS Enviroment
I only know the 3 "must know to survive in Linux commands" "./configure, make & make install" from my little Linux Experience
My Development Enviroment
I am using a Windows 7 Workstation
with Cygwin and MinGW (as Linux 'Replacement') to compile.
The Problem
I want to compile C source code on windows, which is primary written for Linux distributions.
/Configure works without problems.
If I use the command make to compile the sources, I run into following error:
Error
grib_keys.c:50:34:
error: 'alphasort' undeclared (first use in this function)
Research:
My Research proved me, that this problem already has been solved, but unfortunately, the answer isn't working for me.
Implicit declaration of scandir; alphasort is undeclared
http://ubuntuforums.org/archive/index.php/t-1653576.html
The solution says, that I only have to include following: #define _GNU_SOURCE
Which I tried, but as already stated, it doesn't work.
I included it in following files:
- grib_keys.c
- config.h
and tried to compile them with concurrent and not concurrent inclusion.
In the end, the important parts of the files looked like this:
config.h
********
/* Add #define _GNU_SOURCE to solve "'alphasort' undeclared" error */
#define _GNU_SOURCE
grib_keys.c
***********
#define _GNU_SOURCE
count = scandir(dir, &files, 0, alphasort);
What I want to achive & to know:
I want to compile the whole sourcecode of below named API, to use the binaries on a windows operating system.
Also I would like to know, whether I wrote the "#define _GNU_SOURCE"-Tag to the right place, or if I made a mistake.
Downloads:
Api
https://software.ecmwf.int/wiki/display/GRIB/Home
If you're going to declare feature-test macros such as _GNU_SOURCE, you must ensure that the preprocessor sees them before it sees any code that uses them. That generally means they have to be processed before any system headers. The best placement, therefore, is at the top of each of your C source files (not headers), before any #include directives.
With that said, you need a solution that applies to the C library you're actually using, and its development headers. For MinGW, it seems that would be Microsoft's C library, which does not appear to document an alphasort() function.
Even if you were using glibc (Cygwin's version, for instance) my glibc docs claim that the needed feature-test macro for alphasort() is either _BSD_SOURCE or _SVID_SOURCE, not _GNU_SOURCE. Since glibc 2.10, it looks like it's probably best to use _POSIX_C_SOURCE >= 200809L, or _XOPEN_SOURCE >= 700, as these reflect the fact that the function was standardized in POSIX.1-2008.
When trying to compile some C code in Visual Studio, I often get numerous errors. The reason for this problem is Visual Studio's C compiler only supports an old version of C. How can I quickly fix all of my C code to be compatible with the Visual Studio compiler?
For example, I'm trying to compile websocket.c and associated headers—from http://libwebsockets.org/trac/libwebsockets. I'm getting a lot of errors about "illegal use of this type as an expression" which, according to other answers, indicates that I need to move my variable declarations to the beginning of every block.
The problem with compiling C in Visual Studio
Visual Studio does not provide full support for ANSI C. If you want C code to be portable enough to compile with Visual Studio, you'll probably have to target C89 or have it compile as C++ code. The first option is unnecessarily restrictive, unless for some reason you really really love the '89 standard C and you hate all of the new features of later standards.
Compiling as C++
The second option, compiling as C++, can be achieved, as dialer mentions in his comment, by changing the target language type. You can do this by right-clicking the source file(s), and selecting Properties, navigate to C/C++ -> Advanced and changing the Compile As option to Compile as C++ code.
You can also specify the source file type as C++ by using the /Tp <filename> switch on the command line, or use the /TP switch to compile everything as C++.
Problems with Linking
If you're linking to a library written in C, the above fix can cause linking to fail. This is because, now that you're compiling your C files as C++, the function names will be mangled. When the compiler adds the library and tries to match the name of the function you called to one exported by the library, it will fail because the name exported by the library will not be mangled.
To combat this problem, C++ allows you to specify that specific names are exported with "C" linkage, which tells the compiler that the names are not mangled. This is usually done by prefixing the function declaration with extern "C", or placing everything in a block of
extern "C" {
/* header contents here */
}
Well-disciplined C library developers know about this problem and will use techniques, such as macros, to combat it. A common technique is to detect when the user is compiling as C++, and place macros similar to these at the beginning and end of a block of declarations in a header file:
#if defined (__cplusplus)
#define BEGIN_EXTERN_C extern "C" {
#define END_EXTERN_C }
#else
#define BEGIN_EXTERN_C
#define END_EXTERN_C
#endif
If you're using well-established and well-coded C libraries, the headers probably contain something similar to this. If not, you might need to do it yourself (and if the library is open-source, submit the changes as a patch!)
The future of C in Visual Studio
There is an MSDN blog post from July 2013, which announced that a large number of C99 features have been implemented for Visual Studio 2013. Part of the reason for this seems to be that the features are mentioned in parts of some C++ standards, so they would be required anyway. The new features include new math.h functions, new inttypes.h types and more. See the post for a full list.
An earlier post gives the following tidbits:
Additionally, some C99 Core Language features will be implemented in 2013 RTM:
C99 _Bool
C99 compound literals
C99 designated initializers
C99 variable declarations
Note that there are features missing, including:
The tgmath.h header is missing. C compiler support is needed for this header.
Note that the ctgmath header was added—this is possible because that header does not require the tgmath.h header—only the ccomplex and
cmath headers.
The uchar.h header is missing. This is from the C Unicode TR.
Several format specifiers in the printf family are not yet supported.
The snprintf and snwprintf functions are missing from stdio.h and wchar.h.
Although you can expect them in the future:
We don't hate snprintf() (quite the contrary), we just missed it and ran out of time.
Note that other language features that don't have to do with the standard library are still not available.
It looks like standard C will receive more support in the future, although probably just because the implementation of more modern features is necessary to support C++11 and C++14.
<tgmath.h> and its associated compiler magic are special and I don't know our plans for them (as Pat's post explained, C++ has overloading/templates and doesn't need C compiler magic).
I'm using Eclipse Galileo with CDT for C development targeting embedded devices.
Like so many other compilers targeted at µcontrollers, the IAR compiler uses some non-standard variable types that Eclipse/CDT doesn't recognize and flags them as problems. Since these variable types are the foundations of other variable types I use the problem cascades to the point that just about every line using variables declared with the non-standard types are flagged as having syntax problems, even when the syntax is correct. It's not a critical problem, but it is definitely a nuisance.
Is there a setting within Eclipse/CDT where I can add non-standard syntax, or...
Is there some predefined macro within Eclipse/CDT that I can access with something like #ifdef SECRET_ECLIPSE_MACRO ... for conditionally setting or clearing a macro with the string of the offending variable type definition?
Well, you can go the other way around. Define a NOT_ECLIPSE macro when you compile your code, and check for its non-existence in your code. If it's not defined, you're in Eclipse.
Is there some predefined macro within Eclipse/CDT that I can access
Yes, there are many.
See this page.
http://help.eclipse.org/galileo/index.jsp?topic=/org.eclipse.cdt.doc.user/reference/cdt_u_prop_build_variables.htm
Don't forget to check the 'SHow system variables' option.
__CDT_PARSER__
is defined during CDT editor preprocessing stage (works at least with Indigo SR2)