Re: Implementation of forward_list (and compressed_pair)

[Paolo Carlini <paolo dot carlini at oracle dot com>]

Hi,
> To be honest, I was more focused on forward_list and treated
> compressed_pair more as a place holder albeit one that did what it
> needs to do.  I studied some other implementations and put something
> together.  I tested the sizeof and it did the trick.
>
> I did think the single argument ctors were unnatural.  I couldn't see
> myself using them because of the ambiguities just mentioned and, well,
> it's a *pair* after all.  I'm working on a version where I remove all
> single argument ctors.
>
> I also removed the ifdef.  I'm going with the dummy member for reasons
> outlined in the comment.
Ok, great.
> Also. I'm using some C++-09 features.  It was convenient.  If this is
> really going to get used in other containers it might be good to roll
> back to C++-03 features.  That way, the other containers will used
> compressed pair allocators before C++-09 becomes default.  I think we
> have internal replacements for remove_cv and such.
Uhhmm, I didn't consider that issue. In fact, as an independently useful
extension, it would be nice if it could work also in C++03 mode. All in
all, I'm thinking we should probably change a bit our plans, if you
agree: let's separate the two projects, the main one being forward_list.
I would ask you to contribute first a self-contained forward_list, using
tuple for the pair of allocators. That could go in almost immediately. I
still believe a __compressed_pair makes sense as an extension, but we
should probably perfect it separately, and do our best to avoid relying
on C++03 features for it (TR1 is fine). What do you think? Is it too
much work for you to quickly split out a self-contained forward_list
using std::tuple?

Paolo.