3 ms·
>While they will remain supported, their removal from the standard can be cited by engineers for political support to modernize code bases Man... Who do you wo
by EpicEng 10y ago
>While they will remain supported, their removal from the standard can be cited by engineers for political support to modernize code bases
Man... Who do you work for? If I used that as a reason for a refactoring my boss would laugh at me (and he's technical) . I imagine his boss would glaze over for a bit and then ask him to leave his office.
- klodolph 10y agoI think this casts my explanation in a very ungenerous light, I'm not really such an absurd person. Think of how a reasonable engineer would do it. Speaking as an engineer, some of us have a tendency to want to refactor and polish code past the point where we should ship it and move on to something else. Management also has a tendency to view refactoring as unproductive and hurtful to the company's bottom line. Both are very reasonable positions. In most cases, the best strategy tends to be in the middle somewhere. The auto_ptr class is gone from C++17 because it is error-prone to use it and there are better alternatives. However, I don't need to explain the intricacies of auto_ptr to my boss. I can just say something like, "We want to keep up with the latest industry best practices and standards. Some simple changes to our code base will reduce the chance for bugs and reduce support costs, and make it easier to develop new features." The fact that auto_ptr has been removed from the standard entirely sends a stronger signal that you really should stop using it. Which is a good signal to send.