Two containers, instantiated with allocator parameters of differing
types, are incompatible types themselves.

std::list< int, sharedInts > L1; // is not compatible with
std::list< int > L2

therefore L1.swap( L2 ) won't compile.

--
Regards, Marcus


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Marcus Barnes wrote:
>
> Two containers, instantiated with allocator parameters of differing
> types, are incompatible types themselves.
>
> std::list< int, sharedInts > L1; // is not compatible with
> std::list< int > L2
>
> therefore L1.swap( L2 ) won't compile.

But different allocators don't need to have different types.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Marcus Barnes wrote:
>
> Two containers, instantiated with allocator parameters of differing
> types, are incompatible types themselves.
>
> std::list< int, sharedInts > L1; // is not compatible with
> std::list< int > L2
>
> therefore L1.swap( L2 ) won't compile.

But the shared and unshared allocators don't have to be different of
different C++ types:

MyAllocator<int> a1, a2;
a1.shared(true);
// In reality, the set-up of sharing would probably be more complicated

std::list<int> L1(a1), L2(a2);

An implementation that allows inequivalent allocator instances of the
same type would deal with these in an implementation-defined manner,
which might be a useful one. However, an implementation which took
advantage of the standard's expression permission to ignore that
possibility would have precisely the problems that Scott Meyers was
talking about.

As a practical matter, I think allocators which can switch at run-time
between shared and unshared semantics would be a bad design, but
something like that is legal, and it's needed to render Scott's
objection relevant.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

James Kuyper <kuyper@wizard.net> a    crit dans le message :
397EFD10.C9E3CBA3@wizard.net...
> Marcus Barnes wrote:

[...]

> MyAllocator<int> a1, a2;
> a1.shared(true);
> // In reality, the set-up of sharing would probably be more complicated
>
> std::list<int> L1(a1), L2(a2);
>
[...]

The problem with what you write above is that (a restriction on) allocators
of the same type should be "interchangeable". I wonder if it is true above!
;-)
I am not sure if the fact that allocators of the same type should be
interchangeable is in the standard...
But I read in the book "The C++ Standard Library" of Nicolai M.Josuttis that
allocators of the same type are required to be interchangeable in order to
be used by the standard containers!!

Hicham BOUHMADI            hicham@citeweb.net


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Hicham BOUHMADI wrote:
>=20
> James Kuyper <kuyper@wizard.net> a =E9crit dans le message :
> 397EFD10.C9E3CBA3@wizard.net...
> > Marcus Barnes wrote:
>=20
> [...]
>=20
> > MyAllocator<int> a1, a2;
> > a1.shared(true);
> > // In reality, the set-up of sharing would probably be more complicat=
ed
> >
> > std::list<int> L1(a1), L2(a2);
> >
> [...]
>=20
> The problem with what you write above is that (a restriction on) alloca=
tors
> of the same type should be "interchangeable". I wonder if it is true ab=
ove!

Most certainly not, which is precisely what I was talking about.

> ;-)
> I am not sure if the fact that allocators of the same type should be
> interchangeable is in the standard...

There is no such restriction on allocators themselves. See the allocator
requirements in section 20.1.5. The definitions of =3D=3D and !=3D on
allocators would be pointless if they were required to always compare
equal. The qualification of the description of 'p', which says "where
a1=3D=3Da" would be redundant. The post condition on "X a(b);" that
"Y(a)=3D=3Db" would also be redundant.

Paragraph 4 of that same section does give implementors of standard
library containers PERMISSION to assume that allocators of the same type
are interchangeable. Therefore portable code must not pass such
allocators to standard library containers. Of course, portable code can
pass such allocators to user-defined classes meeting the standard's
container requirements, so long as those classes were designed to cope
with inequivalent allocators.

However, paragraph 5 of that same section also explicitly encourages
implementors to NOT make that assumption. Non-portable code can make use
of a specific implementation's decision to support inequivalent
allocators. I specifically stated that I was talking about "An
implementation that allows inequivalent allocators." Such an
implementation might even choose to provide such allocators, guaranteed
to work properly with it's own implementation of the standard
containers.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]