This bugzilla service is closed. All entries have been migrated to https://gitlab.com/libeigen/eigen
Bug 253 - Success enum constant in Eigen clashes with macro in X11 header file
Summary: Success enum constant in Eigen clashes with macro in X11 header file
Status: RESOLVED FIXED
Alias: None
Product: Eigen
Classification: Unclassified
Component: Interoperability (show other bugs)
Version: 3.0
Hardware: All All
: --- Unknown
Assignee: Nobody
URL:
Whiteboard:
Keywords:
: 274 (view as bug list)
Depends on:
Blocks:
 
Reported: 2011-04-20 11:34 UTC by Jitse Niesen
Modified: 2019-12-04 10:39 UTC (History)
5 users (show)



Attachments

Description Jitse Niesen 2011-04-20 11:34:53 UTC
This issue is discussed on the mailing list in the thread "eigen3 migration" started 13 April, see http://thread.gmane.org/gmane.comp.lib.eigen/1941 . A summary of the discussion follows.

The problem is that the X11 header file X.h include the following macro:

#define Success 0

If this header file is included before Eigen/Core, then the following definition fails to compile:

enum ComputationInfo {
   Success = 0,
   NumericalIssue = 1,
   NoConvergence = 2 
};

Furthermore, the resulting error message is apparently rather puzzling.

Possible solutions:

1. Rename Success in Eigen to something else, say SuccessfulComputation. This does however break all Eigen3 user code which uses this constant.

2. Do nothing, and have the user resolve the problem. For instance, the user could #undef Success before the #include <Eigen/Core> if they are not using X.h's Success.

We could make the error message a bit easier to understand with things like

#ifdef Success
#error "Success macro defined by some header file, possibly X.h"
#endif

3. Rhys suggested the following: Would something goofy like

enum ComputationInfo {
#ifndef Success
 Success = 0,
#elif Success == 0
# undef Success
 Success = 0,
# define Success 0
#else
#  error "Success #defined with non-zero value"
#endif
 NumericalIssue = 1,
 NoConvergence = 2
};

work?  This works around any preceding '#define Success 0' macro by
'pushing/popping' its definition.  In the end, the token 'Success' will still
be macro expanded but ComputationInfo's enum will contain an entry for the
literal as well.  Finally, it loudly breaks if someone uses the wholly
incompatible '#define Success 1'.
Comment 1 Gael Guennebaud 2011-04-20 12:02:08 UTC
solution 3 does not work with: Eigen::Success.

So it remains options 1 or 2 and I'd go for 2 with an explicit error message. It is not our business to deal with crappy #define ... The pb is on X11 side.
Comment 2 Christoph Hertzberg 2011-04-20 14:47:36 UTC
(In reply to comment #1)
> solution 3 does not work with: Eigen::Success.
> 
> So it remains options 1 or 2 and I'd go for 2 with an explicit error message.
> It is not our business to deal with crappy #define ... The pb is on X11 side.

I agree, you can't implement spurious workarounds for every macro that some other library defines -- especially if they don't stick to conventions such as UPPERCASE_ONLY and starting with a (hopefully) unique prefix.
Maybe the #error message should contain a workaround (or a link to one), though.

With any solution there is still a problem when including X11 after Eigen and using Eigen::Success (which can't be detected by Eigen).
Comment 3 Jitse Niesen 2011-05-04 15:33:59 UTC
I added an #error in case Success is already defined (changesets d84c8f4660e6 and 336bc7749caa). I hope users are smart enough to look at the first error message, as it is followed at least on GCC with a lot of other error messages.
Comment 4 Jitse Niesen 2011-05-20 22:45:44 UTC
*** Bug 274 has been marked as a duplicate of this bug. ***
Comment 5 Nobody 2019-12-04 10:39:40 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to gitlab.com's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.com/libeigen/eigen/issues/253.

Note You need to log in before you can comment on or make changes to this bug.