|Anonymous | Login||2022-01-22 02:00 UTC|
|My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000905||OMNeT++||simulation kernel||public||2015-10-12 10:05||2016-03-16 10:21|
|Target Version||Fixed in Version||5.0rc|
|Summary||0000905: OMNeT headers should not pollute the global namespace with two-letter macros|
|Description||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.|
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.
|Tags||No tags attached.|
> 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.
> 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.
> 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.
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...
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.
|2015-10-12 10:05||ammmar1988||New Issue|
|2015-10-12 10:05||ammmar1988||Issue generated from: 0000853|
|2016-03-16 10:21||andras||Status||new => resolved|
|2016-03-16 10:21||andras||Fixed in Version||=> 5.0rc|
|2016-03-16 10:21||andras||Resolution||open => fixed|
|2016-03-16 10:21||andras||Assigned To||=> andras|
|Copyright © 2000 - 2022 MantisBT Team|