I switched from Visual Studio to Code::Blocks yesterday, and just had some strange compiler error messages.
I included windows.h and i can use all the API calls just fine, such as creating window classes and creating windows / buttons and stuff. But when I tried to send some keypresses with SendInput(), I got error messages on these two declarations:
INPUT ip;
KEYBDINPUT kbi;
Compiler errors:
C:\code_blocks\test-app\main.cpp|21|error: 'INPUT' was not declared in this scope|
C:\code_blocks\test-app\main.cpp|22|error: 'KEYBDINPUT' was not declared in this scope|
I can even right click the KEYBDINPUT and INPUT structors and click on "Find declaration", it finds it inside the "winuser.h" (which is inside ), but it's still giving me these error messages that they are not declared.
This code works fine in VS with just windows.h included. I'm using the GNU GCC compiler.
I think you need the pre-processor directives (Visual Studio may already add them):
What do you have _WIN32_WINNT defined as?
Perhaps you could add:
#ifndef _WIN32_WINNT
#define _WIN32_WINNT 0x0400
#endif
or you can add it to your pre-processor directives as part of your compile sequence. Any good compiler will have it.
If it still doesn't work, remove the include guards and define it directly. Maybe it is getting defined elsewhere.
Some compilers will have this in the pre-processor directive settings: WIN32,_DEBUG,_CONSOLE,_MBCS,_WIN32_WINNT=0x0400
To elaborate on Changeling's answer, if you look at the documentation for say KEYBDINPUT, you will see that near the bottom it has a table of minimal supported OS versions. VC++ sets _WIN32_WINNT to a later version than MinGW/GCC (which I am guessing is the compiler you are using with Code::Blocks), which is probably why you have encountered this problem.
The purpose of this macro is to prevent you inadvertently using API's that are not compatible with your minimum intended target OS.
There are a number of version related macros used by Windows API headers. The details can be found here
Related
I am using Visual Studio 2019 (updated to date, running on Windows) to rewrite old program code in cross-platform C++ language (Windows & Linux).
In the code, I am using the pre-compilation directives #if, #else, #endif to toggle platform-specific blocks of code.
Example:
76 #ifdef WINDOWS_OS
77 errno_t success = fopen_s(&arq, logConfigFileName.str().c_str(), "rt");
78 #else
79 arq = fopen(logConfigFileName.str().c_str(), "rt");
80 #endif
In the Visual Studio editor, everything looks correct (see screenshot).
Project selected: Windows, Debug, x86.
Lines 1 and 2 appear normally (active and without error indication) and lines 3 to 5 appear in gray indicating they are disabled, that is, it appears as it should be.
However, when compiling I get the error:
Error C4996 'fopen': This function or variable may be unsafe. Consider using fopen_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
error on line 79, line that should be ignored by the compiler.
How can I fix this, so that my code can be compiled for both platforms without problems ?
You don't need to create / define macros to identify the OS.
Compiler do it already. See C++ compiling on Windows and Linux: ifdef switch for the list.
Problem solved.
The problem was in the definition of the WINDOWS_OS flag, I had defined it in the code with the #define WINDOWS_OS statement.
The IDE recognized the instruction, but the preprocessor didn't.
The solution was to include the WINDOWS_OS flag in the list of definitions in: Project Properties -> Settings Properties -> C++ > Preprocessor - Preprocessor Settings.
To me this does not make sense, my everyday IDE is Rad Studio and in it if you set a compiler directive in the code it is valid for everything.
Thank you all.
I am trying to compile a library using clang. The library makes calls to 'unlink', which is not defined by clang:
libmv/src/third_party/OpenExif/src/ExifImageFileWrite.cpp:162:17: error: use of undeclared identifier 'unlink'; did you mean 'inline'?
unlink( mTmpImageFile.c_str() ) ;
My question is, what is the clang equivalent of unlink? As I see it, the path forward would be to #define unlink somewhere with an equivalent routine.
There is no "Clang equivalent". Neither GCC nor Clang have ever been responsible for defining unlink, though they do probably distribute the POSIX headers which do (I don't recall specifically where POSIX headers come from).
Unfortunately, this appears to be a bug with the library you're using; the OpenExif developers failed to include the correct headers. Different C++ implementations may internally #include various headers for their own purposes, which has apparently masked this bug on your previous toolchain.
You can hack your copy and/or submit a patch to add:
#include <unistd.h>
So, I built boost with the following script conveniently posted by toma
and it compiles and I can add the respective frameworks in Xcode6 to my iOS target and my OSX target.
It runs properly on iOS, but when I try compiling on OSX I get errors in has_binary_operator.hpp in the following lines:
template < typename Lhs, typename Rhs >
struct operator_exists {
static ::boost::type_traits::yes_type check(has_operator); // this version is preferred when operator exists
static ::boost::type_traits::no_type check(no_operator); // this version is used otherwise
BOOST_STATIC_CONSTANT(bool, value = (sizeof(check(((make<Lhs>() BOOST_TT_TRAIT_OP make<Rhs>()),make<has_operator>())))==sizeof(::boost::type_traits::yes_type)));
};
Error messages:
.../boost.framework/Headers/type_traits/detail/has_binary_operator.hpp:155:42: Expected member name or ';' after declaration specifiers
.../boost.framework/Headers/type_traits/detail/has_binary_operator.hpp:156:41: Expected member name or ';' after declaration specifiers
Screenshot:
PS: My stdlib is libc++ and I want to use C++11 and Clang in both iOS and MacOSX. I mean it works perfectly for iOS, so why is it not working with the MacOSX target?!?
Quickfix:
Undefining 'check' seems to solve the error, as this seems to be a keyword reserved on MacOSX. Still it seems a weird solution to just undefine an OSX keyword, wouldn't this cause problems later?
#undef check
#include <boost/multi_array.hpp>
check is not a keyword, but an unfortunately named macro in a file supplied by Apple.
This has been an ongoing problem for boost (and other library vendors) for many years.
The header file <AssertMacros.h> is where this macros is defined.
See https://svn.boost.org/trac/boost/ticket/2115 for some history on this.
The latest version of this file (that Apple ships with the 10.9 SDK) contains the following text:
Prior to Mac OS X 10.6 the macro names used in this file conflicted with some
user code, including libraries in boost and the proposed C++ standards efforts,
and there was no way for a client of this header to resolve this conflict. Because
of this, most of the macros have been changed so that they are prefixed with
__ and contain at least one capital letter, which should alleviate the current
and future conflicts. However, to allow current sources to continue to compile,
compatibility macros are defined at the end with the old names. A tops script
at the end of this file will convert all of the old macro names used in a directory
to the new names. Clients are recommended to migrate over to these new macros as
they update their sources because a future release of Mac OS X will remove the
old macro definitions ( without the double-underscore prefix ). Clients who
want to compile without the old macro definitions can define the macro
__ASSERT_MACROS_DEFINE_VERSIONS_WITHOUT_UNDERSCORES to 0 before this file is
included.
So, you could add -D__ASSERT_MACROS_DEFINE_VERSIONS_WITHOUT_UNDERSCORES=0 to your build commands to fix this problem.
Alternately, you could get a newer version of boost, where those calls have been renamed from check to s_check.
I'm trying to make an application that captures selection of context menu items and up until now I've had windows.h included and it seemed to work fine, but for some reason I'm getting an error "WM_MENUCOMMAND was not declared in this scope". I am on windows xp so I meet the minimum system requirements as indicated by MSDN, I figure theres no reason it shouldn't work. How do I get WM_MENUCOMMAND to work?
WM_MENUCOMMAND is defined in winuser.h (which windows.h includes), but only when WINVER is >= 0x0500 and _WIN32_WCE is not defined. So you likely have WINVER set too low. It is set to 0x0500 by default, so something in your project must be redefining it to a lower value.
I encounter this error when I am trying to compile a c++ code via a Makefile.
error: expected initializer before ':' token
I have checked the compatibility of the compiler of my system
I also checked the paths etc. I also did some test; such as adding a semicolon after the 2nd declaration of class but didnt work. I have little to no experience with c++, the script is not even written by me; it is part of vtk library (Visualisation toolkit). Part of the script from where
the error generates is:
#ifndef __vtkProcessObject_h
#define __vtkProcessObject_h
#include "vtkAlgorithm.h"
class vtkDataObject;
class VTK_FILTERING_EXPORT vtkProcessObject : public vtkAlgorithm
{
public:
vtkTypeRevisionMacro(vtkProcessObject,vtkAlgorithm);
void PrintSelf(ostream& os, vtkIndent indent);
I get the error in line 8.
Probably it is something really straightforward, but as I said I have no clue how this language works.
The VTK_FILTERING_EXPORT macro is defined in a header, and is largely there for Windows and/or GCC symbol visibility. You don't mention what version of VTK you are compiling, but using CMake to generate the Makefiles would ensure the correct include paths are set up. If this is Linux, and the GCC visibility functionality has not been activated you could define the macro to nothing, but I suspect you would hit many other issues once you got past this point in the compilation.