Vlad Harchev wrote:

[...]

>  IMO, the permission given to implementors in paragraph 4 restricts the
> allocators' writers considerably. Especially this is important in respect to
> 'pointer' and 'const_pointer' type members. Even allowing to assume that
> all instances of a given allocator type are interchangeable and always
> compare equal to each other, but requiring to make no assumptions on the
> nature of 'pointer' and 'const_pointer', the class of supported allocators
> can be considerably extended.

[...]

>  I can give the following example:
>   Sharing the container between processes (via Unix shared memory mechanism
>   - shmat, shmop ..) has the feature that the start addresses of shared
> segment can be different in each process that has mapped that region. So
> sharing non-trivial data structure as list will be complicated. Each process
> should store the offset that should be added to the pointer read from shared
> memory to calculate the address in that process's address space. Writing the
> special allocator, for which the member 'pointer' is not a T* will solve the
> problem, but most STL implementations assume that 'pointer' is T* as
> standard
> permits. When such allocator is written, each process attached to segment
> can
> access, insert and remove elements from the list (if processes were compiled
> using the similar STLs).

Note that there's more about shared memory than just allocators.
For example, I believe container implementors are allowed to
use any of virtual functions, virtual base classes etc. for their
helper classes. That is, there may be pointers hidden in the
implementation which are controlled by the compiler rather than
by the library. (The same is true if the contained object has
any of those, but there it's under the control of the user -
POD objects will always be fine.)
The only way to have containers using shared memory is to add
an extra requirement that the container implementation may only
use objects which are suitable for shared memory (this might be
just PODs) and doesn't use ordinary pointers anywhere (f.ex. as
back-pointers to the container variable which may lie on stack,
or elsewhere in memory).

[...]


[ 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              ]

Greg Colvin wrote in message <74c2e6$dv$1@engnews2.Eng.Sun.COM> ...
>Yes.  This is the infamous "Kona compromise".  I believe that the
>Dinkumware STL relaxes the requirements as Vlad wishes.  I am not
>sure what other STL implementations will do, since the standard,
>unfortunately, does not require anything beyond raw pointers.  I
>consider this to be a hole in the standard that needs to be filled
>if allocators are to fulfill their original promise.  In the
>meantime, and that means years, all you can do is lean on your
>vendor.

  Dinkumware STL shipped with VC 6.0 assumes that the 'pointer' is T*
(search for 'address' in container headers). Original STL and RW STL v1.0
and v2.0 are more advanced from this POV - they use 'address' in list
contaniner headers. I think that RW STLs are most advanced STLs in this
respect (I've checked SGI, Dinkumware, Modena, RW).

- Vlad




[ 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              ]

Francis Glassborow <francis@robinton.demon.co.uk> wrote
>
> In article <366841c4.0@monster.ssau.ru>, Vlad Harchev
> <vladhar@imimail.ssau.ru> writes
> >2) Original STL description didn't contain any assumptions beyond specified
> >in Table 32.
>
> All I can remember is that those two extras were added in order to reach
> a compromise.  There were serious problems with allocators and we did
> not have time to continue with analysis to find the best solution.  What
> we did was to provide something that we believed was a safe solution.

Yes.  This is the infamous "Kona compromise".  I believe that the
Dinkumware STL relaxes the requirements as Vlad wishes.  I am not
sure what other STL implementations will do, since the standard,
unfortunately, does not require anything beyond raw pointers.  I
consider this to be a hole in the standard that needs to be filled
if allocators are to fulfill their original promise.  In the
meantime, and that means years, all you can do is lean on your
vendor.

It turns out to be trickier than one might think to nail down the
requirements on pointer and const_pointer, even though it isn't
that hard to implement the STL with generalized pointer types,
except for basic_string, which needs raw pointers.  We had two
proposals, from myself and Matt Austern, but in the end we ran out
of time to reconcile them.

------------------------------------------------------------------
Greg Colvin          s/-//g          c-o-l-v-i-n-g-@-a-c-m-.-o-r-g




[ 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              ]

In article <74c2e6$dv$1@engnews2.Eng.Sun.COM>, Greg Colvin
<colving@acm.org> writes
>It turns out to be trickier than one might think to nail down the
>requirements on pointer and const_pointer, even though it isn't
>that hard to implement the STL with generalized pointer types,
>except for basic_string, which needs raw pointers.  We had two
>proposals, from myself and Matt Austern, but in the end we ran out
>of time to reconcile them.

It might help if we continued work in this area with the possibility of
understanding exactly how far things can be relaxed as well as having
some implementation experience.



Francis Glassborow      Chair of Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation


[ 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              ]

 In CD2, in [lib.allocator.requirements] paragraph 4,5 stated:

4 Implementations of containers described in this International Standard
  are  permitted to assume that their Allocator template parameter meets
  the following two additional requirements beyond those in Table 32.
  --All instances of a given allocator type are required  to  be  inter-
    changeable and always compare equal to each other.
  --The  typedef  members pointer, const_pointer, size_type, and differ-
    ence_type are required to be T*, T const*,  size_t,  and  ptrdiff_t,
    respectively.
5 Implementors  are encouraged to supply libraries that can accept allo-
  cators that encapsulate more general memory models  and  that  support
  non-equal   instances.   In  such  implementations,  any  requirements
  imposed on allocators by containers  beyond  those  requirements  that
  appear  in  Table  32,  and the semantics of containers and algorithms
  when  allocator  instances  compare  non-equal,  are   implementation-
  defined.
-----end quote

 IMO, the permission given to implementors in paragraph 4 restricts the
allocators' writers considerably. Especially this is important in respect to
'pointer' and 'const_pointer' type members. Even allowing to assume that
all instances of a given allocator type are interchangeable and always
compare equal to each other, but requiring to make no assumptions on the
nature of 'pointer' and 'const_pointer', the class of supported allocators
can be considerably extended.
 IMO most current implementation of the STL will be broken in this respect
if given permission (I mean the type of 'pointer' and 'const_pointer') is
removed (search for 'address' in container headers of STLs). But I think
that usability of the STL will be increased when such permission is removed
(and STLs are updated).
 I can give the following example:
  Sharing the container between processes (via Unix shared memory mechanism
  - shmat, shmop ..) has the feature that the start addresses of shared
segment can be different in each process that has mapped that region. So
sharing non-trivial data structure as list will be complicated. Each process
should store the offset that should be added to the pointer read from shared
memory to calculate the address in that process's address space. Writing the
special allocator, for which the member 'pointer' is not a T* will solve the
problem, but most STL implementations assume that 'pointer' is T* as
standard
permits. When such allocator is written, each process attached to segment
can
access, insert and remove elements from the list (if processes were compiled
using the similar STLs).
  Moreover,
1) It's proofable that even making no assumptions about allocators other
than
specified in Table 32 (Allocator requirements), the 'semantics of containers
and algorithms when allocator instances compare non-equal' will be the same
(may be the following requirement should be added: pointer arithmetic and
it's
semantic is availble for types 'pointer' and 'const_pointer').
2) Original STL description didn't contain any assumptions beyond specified
in Table 32.

 What do you think?

 - Vlad




[ 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              ]

In article <366841c4.0@monster.ssau.ru>, Vlad Harchev
<vladhar@imimail.ssau.ru> writes
>2) Original STL description didn't contain any assumptions beyond specified
>in Table 32.

All I can remember is that those two extras were added in order to reach
a compromise.  There were serious problems with allocators and we did
not have time to continue with analysis to find the best solution.  What
we did was to provide something that we believed was a safe solution.



Francis Glassborow      Chair of Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation


[ 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              ]