OMNeT++/OMNEST Bug Tracker - OMNeT++
View Issue Details
0000820OMNeT++simulation kernelpublic2015-03-21 08:492016-04-07 16:30
pkerling 
andras 
normalmajoralways
resolvedfixed 
4.6 
5.0 
0000820: OMNeT headers should not pollute the global namespace with two-letter macros
OMNeT already has support for namespaces, but still #defines some preprocessor macros which are of course available globally. Among them are the two-letter macros "ev", "EV" and the common English word "simulation". There is no option to disable definition of those macros. While they might be convenient, they pollute the global namespace. Specifically, "ev" is a common abbreviation for "event" and cannot be used as e.g. function parameter in any code. Some libraries, e.g. Boost.System, uses "ev" as function parameter name and can thus not be included after omnetpp.h.

Try:
#include <omnetpp.h>
#include <boost/system/system_error.hpp>

This will give a lot of compilation errors. Ensuring a defined order of inclusion of headers across a lot of files and complicated inter-dependencies is very difficult and to be honest should not be necessary with good C++ libraries.
OMNeT should at least have an option to disable generation of those macros or use a properly prefixed name (OMNETPP_ev or similar). It would be preferrable to make this the default, but that might rise too many compatibility issues.
No tags attached.
Issue History
2015-03-21 08:49pkerlingNew Issue
2015-03-23 12:47andrasNote Added: 0001046
2015-03-30 16:10pkerlingNote Added: 0001047
2015-03-30 17:20andrasNote Added: 0001048
2015-03-30 17:47pkerlingNote Added: 0001049
2015-10-12 09:28ammmar1988Issue cloned: 0000853
2016-04-07 16:30andrasNote Added: 0001208
2016-04-07 16:30andrasStatusnew => resolved
2016-04-07 16:30andrasFixed in Version => 5.0
2016-04-07 16:30andrasResolutionopen => fixed
2016-04-07 16:30andrasAssigned To => andras

Notes
(0001046)
andras   
2015-03-23 12:47   
> There is no option to disable definition of those macros.

Well there's always #undef, but generally I agree with your comments that macros aren't that nice because they don't obey namespaces, and that "ev" is particularly offensive...

We plan a lot of header file cleanup for OMNeT++ 5.0. "ev" will probably go as well, as EV has completely replaced it for logging.
(0001047)
pkerling   
2015-03-30 16:10   
> Well there's always #undef
There sure is, but I think we can agree that stuff like "ev" and "simulation" really shouldn't be #define-d in the first place.

> We plan a lot of header file cleanup for OMNeT++ 5.0. "ev" will probably go as well, as EV has completely replaced it for logging.
This will at least solve the boost problem, but what about "simulation"? I think "EV" is pretty obtrusive, too.

If we can agree on a naming scheme, I'd be happy to provide a patch that introduces an option to disable those global macros.
(0001048)
andras   
2015-03-30 17:20   
> There sure is, but I think we can agree that stuff like "ev" and "simulation"
> really shouldn't be #define-d in the first place.

Basically yes.

Background: they were introduced for backward compatibility reasons. They used to be real objects in older versions, but ceased to be due to refactoring -- however, it had to be ensured that old code still compiles and works. We don't want to break models needlessly, nor generate porting work for model maintainers, if that can be avoided at all.

Removing "ev" and "simulation" is OK, because they are not widely used (any longer). Removing "EV" is out of question at this point.

> If we can agree on a naming scheme, I'd be happy to provide a patch that introduces an option to disable those global macros.

Thank you, but with such changes, the problem is usually not the implementation (takes half an hour to write those few lines of #ifdefs), but to find the solution that's acceptable for everyone, figure out and document migration, teaching everyone the new way, updating the manual, updating the test suite, answering the thousand support requests on the mailing list that were generated by the change, updating models that possibly no longer have maintainers, and so on...

All those items usually outweigh the cost of implementation by a factor of 10-100 times...
(0001049)
pkerling   
2015-03-30 17:47   
Cool, making both ev and simulation go away is already the most important part of my initial bug report. Thanks!

I've given it some more thought, and while I don't think it would generate as much as work as you outline in OMNeT itself for the case that EV is still available by default and only optionally not #define-d, it wouldn't really help. As long as INET and other frameworks use "EV" in their public headers (which I assume they do), it wouldn't be possible to activate the no global macros option in OMNeT when using them. Making it go away entirely is the only useful way to go which I agree would generate a lot of work. OMNeT 5 would be a great opportunity to do just that, though.

In conclusion, I'll give up on "EV" until I actually run into problems with it in library headers.
(0001208)
andras   
2016-04-07 16:30   
No lowercase macros left, and the only short uppercase name is EV which would be too disrupting to remove. If it's in the way, use #undef EV after including <omnetpp.h>.