RE: [boost] Views library in vault

From: Gary Powell (Gary.Powell_at_[hidden])
Date: 2000-04-20 10:11:11

> > On adding stuff to std::, isn't this currently very much a live issue
> for
> > debate?
> 
A formal request for changing the wording of the std was just made this week
by Alan Griffths. The text was reprinted in comp.std.c++. Alan very clearly
outlines the general problem of swap, and any other std algorithm.

> > As Gary says "it's the best of a lot of worse choices" - I didn't
> > read this as being a gratuitous violation of the standard, but more a
> > compromise until the current issues on how to properly extend things
> like
> > std::swap for user-defined containers and template stuff is resolved.
> 
Here is the problem as it relates to views.

  If you call std::swap(view a, view b), with out my overloading std::swap
it will compile and probably do the wrong thing. Since std::swap knows
nothing about views, you get a bitwise swapping of the data. This may or may
not be ok. There is just no way for the swap to know for sure that this is
going to work. A view needs to pass off the swap to the container it is
adapting. This could be a user container or a std one.

  If I overload std::swap, there is now no way for you to call the real
std::swap(view,view); But it could be argued that this is never correct.

  If you always write:
  using std::swap;
  swap(view, view)

and I have my own swap in my namespace (which for the moment doesn't compile
but I will work on this.) we can rely on Koening lookup to find the correct
swap and use that. Except the lookup doesn't do the right thing (as far as
what I want THIS time.) if this is done in a member function. It finds the
std swap only.

  If you call a std algorithm, it must use the "using" trick to get the
correct swap. And there is no way for you to know for sure short of reading
the code that it will be done correctly. Plus it silently compiles making
maintenance a nightmare.

  I'd be glad to do the right thing. It just isn't clear to me what that is.
So I did the the next best and did what seems to work on the majority of
compilers. I had about a week of email with Alan over what to do about this
and I settled on adding to std.

  Feel free to email me or post what you would prefer. I don't mind
maintaining two versions, or having compile time flags to allow users to
choose.

> > On the forward declaration issues, just include the full headers - it's
> just
> > a compile time optimisation.
No Problem.

I just posted a patch file to the vault. It includes the two necessary
changed files so that there is an optimization flag which can be set to use
forward declarations of std containers. By default its off.

I did leave the non standard but well used containers, slist, hash_set,
hash_map, hash_multiset, hash_multimap, as forward declarations. They aren't
std yet.

-gary-