'Re: [cfe-dev] on libc++ extensions and slist'

[prev in list] [next in list] [prev in thread] [next in thread] 

List: cfe-dev
Subject: Re: [cfe-dev] on libc++ extensions and slist
From: Sean Hunt <scshunt () csclub ! uwaterloo ! ca>
Date: 2011-07-31 23:39:12
Message-ID: CAMQXVwVt3kkFvzLNS+T6EACV38MK2uwQtvvMQbgM6XtfF_Mayg () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]

On Sat, Jul 30, 2011 at 18:31, Howard Hinnant <hhinnant@apple.com> wrote:

> <snip>
>
> 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).

Thoughts?

Sean

[Attachment #5 (text/html)]

<div class="gmail_quote">On Sat, Jul 30, 2011 at 18:31, Howard Hinnant <span \
dir="ltr">&lt;<a href="mailto:hhinnant@apple.com">hhinnant@apple.com</a>&gt;</span> \
wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px \
#ccc solid;padding-left:1ex;">

&lt;snip&gt; 
 
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&#39;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.

</blockquote><div> 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&#39;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&#39;m aware that this is not applicable in our \
situation).

<br>Thoughts?<br><br>Sean<br></div></div>

_______________________________________________
cfe-dev mailing list
cfe-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

[prev in list] [next in list] [prev in thread] [next in thread] 