[cfe-dev] on libc++ extensions and slist
scshunt at csclub.uwaterloo.ca
Sun Jul 31 16:39:12 PDT 2011
On Sat, Jul 30, 2011 at 18:31, Howard Hinnant <hhinnant at apple.com> wrote:
> 1. We could create an ext::slist that lacks size(). That way the customer
> would not have to change their code unless they used size().
> Disadvantage: We haven't delivered a seamless drop in replacement lib.
> They still have to change their code. Why not also change the name of the
> container to std::forward_list at the same time? Otherwise we have to
> support slist. And not just to ease migration. Once we introduce it, we
> have to support it for forever for backward compatibility with our own lib.
Size is not the only issue with slist. Slist also features container
operations without the _after suffix, meaning they operate on the elements
pointed to by the iterators. These, also, must have linear complexity, and
so don't exist in forward_list. Given this, the migration may be far from
trivial - especially given that clients might find that they really ought to
be using a doubly-linked list (or some other container) in their situation.
One idea that I had for an unrelated problem but might be useful for this
one as well would be to have specific deprecated tags like
[[deprecated(forward_string)]]. We could put these on the functions that are
removed from the standard library, and migration could be done one container
at a time by turning on each deprecated tag in order (something akin to
-Wdeprecated=forward_string). We could put this on the slist functions that
are not present in forward_list, and thus someone can clean up their
codebase until it should be a drop-in replacement, and then perform the
drop-in replacement. (N.B. to Chandler: I'm aware that this is not
applicable in our situation).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cfe-dev