|
Notes |
|
|
(0001110)
|
|
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. |
|
|
|
|
> 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. |
|
|
|
(0001112)
|
|
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... |
|
|
|
|
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. |
|