So, I'm trying to record and display an image using CImg but I'm also using a linear algebra library called Eigen. Coincidentally, they each seem to have a macro with the same name, "Success". I've tried doing an #undef but that didn't work out smoothly. So whenever I try to compile, I get this error that "Success" is defined twice in different files. How should I go about removing this error without losing either macro? Help is much appreciated!
The problem arises because CImg includes the X11 header X.h which has a macro called "Success" defined. This macro clashes with the ComputationInfo enum definition in Eigen, since it has an enum value called "Success".
As a workaround, you can undefine "Success" after including CImg, and before including Eigen as so:
#include <CImg/CImg.h>
#ifdef Success
#undef Success
#endif
#include <eigen3/Eigen/Eigen>
See also issue #253 on Eigen's bug tracker: http://eigen.tuxfamily.org/bz/show_bug.cgi?id=253
Neither Eigen nor CImg have such a #define. However, Eigen does have such an enum in the Eigen namespace, so the problem more likely comes from X11 X.h header file which #define Success.
So, if you need to use Success from X11, then include Eigen's header before X11 ones (or anyone that could include it).
If you need Success from Eigen, then include Eigen last, and #undef Success before it.
You may also want to display the includes of the X11 header files in CImg, by defining macro cimg_display to 0 before including "CImg.h" (or put the -Dcimg_display=0 flag when compiling).
Of course, do this only if you don't need the display capabilities of CImg.
If you dont need one of them macros in your code, you can #undef it between the 2 includes. So, it really depeneds on what you need in your code.
Related
I'm trying to use (Ligra) in a project. The framework works as long as the chief header "ligra.h" is included. Trouble is, that header has an implementation of parallel_main, which is a macro wrapper around main with OpenMP trickery. So if I wanted to write a simple program:
#include "ligra.h"
#include <iostream>
int main(){
std::cout<<"Hello World";
return 0;
}
It would not compile. Redefinition of symbol main.
Also, I need a parallel_main, with the exact macro trickery done in the "parallel.h" header.
So I think I have two options:
1) modify the file, add a pair of #ifdef LIGRA_MAIN's and not define the macro at compile time. Thus I can have my own main and not have redefinition. Trouble is I need my project to be using the upstream version of ligra, and Julian Shun, the original developer has probably forgottten about his project (and github, since he ignored more than one pull request).
2) Use/Write a #pragma that would strip that function out at the include stage.
I don't know how to do that last part, and would be very much in your debt if someone who did, reached out.
A solution that does not involve modifying library files (but is somewhat brittle) could be to do the following:
#include "ligra/parallel.h" (this does #define parallel_main main).
#undef parallel_main to prevent this rewriting of function names.
#include "ligra/ligra.h" as usual. Since parallel.h has an include guard, its repeated inclusion is prevented and parallel_main will not be redefined.
Proceed as normal.
You might also want to wrap this into a header so you only have to write it once.
Alternatively, you could do what #user463035818 suggests and redefine main only for the inclusion of ligra.h for very similar effect. The difference is in the names that the parallel_main function(s) from ligra will get.
You can simply not include ligra.h. If there is something useful in that file, then create a copy of the file - excluding the main function - and use that copy.
Sure, that means that if the upstream ligra.h is updated, your copy will not have the corresponding changes. However, given the premise "the original developer has probably forgottten about his project", this is probably not a problem. If the premise is wrong, then a better approach would be to create a pull request to make the framework usable as a library.
I'm reading a piece of code that seems like it optionally uses the C++ Boost library. It is as follows:
#ifdef _HAVE_BOOST
#include <boost/random.hpp>
#endif
Later on in the code, there are several statements that depend on this "_HAVE_BOOST". I presume that _HAVE_BOOST is simply a flag that is set to true, if the C++ library is properly imported.
Is the "_HAVE_BOOST" flag a built-in part of C++ ifdef syntax? That is, I tried Googling for this flag but didn't find any documentation. Also, at the head of the file, no #include<boost> is present. It looks like this boost functionality is deprecated throughout the file -- would _HAVE_BOOST be set to true if this #include<boost> were added?
Is there a list or documentation somewhere for describing the kinds of capital letters that go along with #ifdef?
I presume that _HAVE_BOOST is simply a flag that is set to true...
#ifdef _HAVE_BOOST does not test whether _HAVE_BOOST is true; It test whether such preprocessor macro is defined at all, regardless of the value.
...if the C++ library is properly imported.
Yes, considering the context, this particular macro is probably meant to signify, whether Boost is available or not and thus, whether it's possible to depend on it.
Is there a list or documentation somewhere for describing the kinds of capital letters that go along with #ifdef?
Macros can be defined with either #define directive in a header file or, in the compilation command (See the -D option for gcc for example). Compilers may also predefine some macros as well.
Any header file can define macros. You should usually be able to find which macros may be defined by reading the documentation, or if you don't have documentation, by reading the header files themselves.
would _HAVE_BOOST be set to true if this #include were added?
I find it unlikely that it would be defined in <boost> itself. After all, testing if Boost is available after you try to include it would be rather pointless.
When is _HAVE_BOOST defined?
You should ask that from the person who wrote the code. Another question to ponder is, is it defined at all? If it isn't, then the code between the ifdefs is removed by the preprocessor.
My crystal ball tells me that it's probably supposed to be defined by some sort of configuration script for the build process. For example, autoconf has a macro that will define a preprocessor macro HAVE_header-file if a header exists. Note the lack of underscore at the beginning.
this just means that if you define a preprocessor macro "_HAVE_BOOST" the compiler will include boost/random.hpp. Like this:
#define _HAVE_BOOST
#ifdef _HAVE_BOOST
#include <boost/random.hpp>
#endif
Look here for more details about preprocessor directives.
If the compiler supports c++11, it will have <random> support.
With some clever use of indirect includes and typedefs (or using statements ?!) it could be made to work with or without boost for random.
Hi I am trying to find a way to prevent the inclusion of platform specific header file for example windows.h.
Curiously none of the solution I found are not satisfactory to me. Maybe it can't be achieved.
I think to achieve this goal several technique need to be used. And there is a lot of example on internet but I couldn't found any about one aspect. Something has to talk/create to your abstraction. Here is an example:
This is a really simplified version of a render window render target.
//D3D11RenderWindow.h
#include <d3d11.h>
class D3D11RenderWindow: public GfxRenderWindow
{
public:
bool initialize(HWND windowHandle);
private:
HWND windowHandle_; /// Win32 window handle
};
That is not so much the problem, this is a platform specific code that get included only by platform specific code. But we need to actually instanciate this type so an "entry point" need to know about the platform specific code too.
For example a factory class:
//GfxRenderWindowFactory.h
#define WIN32_LEAN_AND_MEAN
#define NOMINMAX
#include <windows.h>
class GfxRenderWindow;
class GfxRenderWindowFactory
{
public:
static std::unique_ptr<GfxRenderWindow> make(HWND windowHandle);
};
Now this factory class need to be included by the "client" of the library (here a renderer). What I don't like is that #include "windows.h", because it is too error prone to me, anybody that include it, even if they don't need it will have all the world and windows.... Precompile header is not a solution because now it is enforced by the compiler that all cpp have include it (it is a valuable tool to speed compile time but not a tool to separate platform specific code from the portable code)
What I thought is to put the #include in the cpp before the include of its header instead of in the header file like this:
//GfxRenderWindowFactory.cpp
#define WIN32_LEAN_AND_MEAN
#define NOMINMAX
#include <windows.h>
#include "GfxRenderWindowFactory.h"
/// Implementation of GfxRenderWindowFactory goed here ....
This way it force anybody that want to use this class to include the relevant platform specific header and they will be in better position to judge if they are including this header in a bad place like in one of their own header file.
What are your solution for this?
What do you think of my solution?, crazy?
I want to point out that to me it is of the uberimportance to do portable code right! Answer like just include windows.h and don't sweat about it is not a valid answer. It is not a good coding practice to me.
I hope i made my question clear. If not tell me i'll clarify
Thanks a lot!
## Edit ##
From a small conversation with hmjd I would like to keep the inclusion of windows.h in the header file since, i agree, this make it way more usable. So it would be nice to have a way to prevent the inclusion in a header file and this way enforce that the file can only be included in a cpp. Is this possible?
Is using a predefined macro, like WIN32, or a macro defined by your build system not sufficient:
#ifdef WIN32
#include <windows.h>
#else
include other platform specific headers
#endif
This is a common approach (and FWIW the only approach I have ever used).
Since the underlying issue is passing an HWND to GfxRenderWindowFactory::make, don't have GfxRenderWindowFactory::make take an HWND.
Hey I worked on the wxsmith cross-platform GUI API. The first thing that you need to do is create classes with your own handles. A handle is 1 of 3 things:
A void *.
Class *.
Struct *.
Use a function like so:
#define create_handle(handle) struct __##handle{unsigned int unused;}; typedef __##handle *##handle;
Then call this function and it creates a struct and a pointer to a struct. The pointer is the handle. Then cast to whatever you desire reinterpret_cast(your handle here); and your done then you can cast like this in your object files or your libs or dlls. And make a global define for your window handle, research how other OS's do it and you done.
I am using both the JUCE Library and a number of Boost headers in my code. Juce defines "T" as a macro (groan), and Boost often uses "T" in it's template definitions. The result is that if you somehow include the JUCE headers before the Boost headers the preprocessor expands the JUCE macro in the Boost code, and then the compiler gets hopelessly lost.
Keeping my includes in the right order isn't hard most of the time, but it can get tricky when you have a JUCE class that includes some other classes and somewhere up the chain one file includes Boost, and if any of the files before it needed a JUCE include you're in trouble.
My initial hope at fixing this was to
#undef T
before any includes for Boost. But the problem is, if I don't re-define it, then other code gets confused that "T" is not declared.
I then thought that maybe I could do some circular #define trickery like so:
// some includes up here
#define ___T___ T
#undef T
// include boost headers here
#define T ___T___
#undef ___T___
Ugly, but I thought it may work.
Sadly no. I get errors in places using "T" as a macro that
'___T___' was not declared in this scope.
Is there a way to make these two libraries work reliably together?
As greyfade pointed out, your ___T___ trick doesn't work because the preprocessor is a pretty simple creature. An alternative approach is to use pragma directives:
// juice includes here
#pragma push_macro("T")
#undef T
// include boost headers here
#pragma pop_macro("T")
That should work in MSVC++ and GCC has added support for pop_macro and push_macro for compatibility with it. Technically it is implementation-dependent though, but I don't think there's a standard way of temporarily suppressing the definition.
Can you wrap the offending library in another include and trap the #define T inside?
eg:
JUICE_wrapper.h:
#include "juice.h"
#undef T
main.cpp:
#include "JUICE_wrapper.h"
#include "boost.h"
rest of code....
I then thought that maybe I could do some circular #define trickery like so:
The C Preprocessor doesn't work this way. Preprocessor symbols aren't defined in the same sense that a symbol is given meaning when, e.g., you define a function.
It might help to think of the preprocessor as a text-replace engine. When a symbol is defined, it's treated as a straight-up text-replace until the end of the file or until it's undefined. Its value is not stored anywhere, and so, can't be copied. Therefore, the only way to restore the definition of T after you've #undefed it is to completely reproduce its value in a new #define later in your code.
The best you can do is to simply not use Boost or petition the developers of JUCE to not use T as a macro. (Or, worst case, fix it yourself by changing the name of the macro.)
Deep down in WinDef.h there's this relic from the segmented memory era:
#define far
#define near
This obviously causes problems if you attempt to use near or far as variable names. Any clean workarounds? Other then renaming my variables?
You can safely undefine them, contrary to claims from others. The reason is that they're just macros's. They only affect the preprocessor between their definition and their undefinition. In your case, that will be from early in windows.h to the last line of windows.h. If you need extra windows headers, you'd include them after windows.h and before the #undef. In your code, the preprocessor will simply leave the symbols unchanged, as intended.
The comment about older code is irrelevant. That code will be in a separate library, compiled independently. Only at link time will these be connected, when macros are long gone.
Undefine any macros you don't want after including windows.h:
#include <windows.h>
#undef near
#undef far
maybe:
#undef near
#undef far
could be dangerous though...
You probably don't want to undefined near and far everywhere. But when you need to use the variable names, you can use the following to undefine the macro locally and add it back when you are done.
#pragma push_macro("near")
#undef near
//your code here.
#pragma pop_macro ("near")
Best not to. They are defined for backwards compatibility with older code - if you got rid of them somehow and then later needed to use some of that old code you'd be broken.