[compiler workaround] Are we purging history?
As I understand it, the people modernizing Boost code by getting rid of old compiler workarounds are doing two things: 1. Remove the workaround macro flags and the code that uses them, leaving the code that doesn't use the workarounds behind. 2. Purging those workaround macros from Boost.Config. If we are doing [2], why? Doing [1] is sufficient for modernization. Doing [2] is just purging history that we spent blood/sweat/tears generating. Authors/maintainers generally have free reign to use as many or as few workarounds as they want. They can't do that if we're deleting that knowledge from Boost.Config. Daryle W.
Daryle Walker <darylew <at> hotmail.com> writes:
As I understand it, the people modernizing Boost code by getting rid of old compiler workarounds are doing two things:
1. Remove the workaround macro flags and the code that uses them, leaving the code that doesn't use the workarounds behind. 2. Purging those workaround macros from Boost.Config.
If we are doing [2], why? Doing [1] is sufficient for modernization. Doing [2] is just purging history that we spent blood/sweat/tears generating.
Personal opinion here: equivalent (or larger) amounts of b/s/t have been spent in generating the code that [1] is sending into oblivion, so if you're OK with [1] why do you care for [2]? Joaquín M López Muñoz Telefónica Digital
As I understand it, the people modernizing Boost code by getting rid of old compiler workarounds are doing two things:
1. Remove the workaround macro flags and the code that uses them, leaving the code that doesn't use the workarounds behind. 2. Purging those workaround macros from Boost.Config.
If we are doing [2], why? Doing [1] is sufficient for modernization. Doing [2] is just purging history that we spent blood/sweat/tears generating. Authors/maintainers generally have free reign to use as many or as few workarounds as they want. They can't do that if we're deleting that knowledge from Boost.Config.
Boost.Config is also a library whose code people sometimes read and need to maintain, so the same arguments for removing unnecessary clutter that justify removing the use of the workaround macros in other libraries, I think justify removing their definitions from Boost.Config. The workaround definitions will remain in version control history, if anyone ever cares about them. Regards, Nate
participants (3)
-
Daryle Walker -
Joaquin M Lopez Munoz -
Nathan Ridge