> I see portability as the main goal with SD-6: If a newer feature > is not > available on one of your target platform/compiler combinations you > have > to roll back to the older facility. Different compilers are at > different places toward full feature support.
Of course; but N4190 doesn't add a new feature, it removes features. It's a completely different sort of problem, one that we really haven't explored before. > > The question is, once someone writes code that uses a new/better > > facility in place of a deprecated/removed facility, would they > > really want or need to keep around the code that uses the > removed > > facility? How would they benefit by doing so? > Portability - across compilers and even within a compiler across > C++ versions. Your gave a very general answer to a question I intended to be pretty specific. Let me make it even more specific. Someone has some code that uses auto_ptr. He changes it to use unique_ptr. He might benefit by keeping around the old code, for portability to an implementation that doesn't provide unique_ptr. But he will benefit only if there's a feature-test macro that tells him that he can use unique_ptr. A macro that tells him that he can't use auto_ptr doesn't seem like it would be useful. If he is willing to assume (or simply hope) that unique_ptr is available everywhere, then he simply has no reason to keep around the code that uses auto_ptr, whether it's available or not. Clark _______________________________________________ Features mailing list [email protected] http://www.open-std.org/mailman/listinfo/features
