Implementation of forward_list (and compressed_pair)

[Ed Smith-Rowland]

Paolo Carlini wrote:
> Chris Fairles wrote:
>   
>> Speaking of interfaces, should tuple's get, tuple_element, tuple_size
>> etc. be extended for __compressed_pair like they are for std::pair?
>>   
>>     
> I have an answer for this question: I don't think so, I don't think, in
> general, we should keep to a minimum dependencies and links between
> Standard facilities and extensions.
>
> About the other issue, I'll leave it to Ed. Agreed, if perfecting
> __compressed_pair turns out to be too annoying, we can also base
> forward_list on tuple, for now, at least...
>
> Paolo.
>
>   
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.

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.

Another thing I left out of forward_list at least is the pseudo 
concepts.  I'll also browse around for docs and examples.

Ed