Gennaro Prota wrote:
....
> P.S.: this should rather go in another thread but while we are at
> it... I'm not able to reverse-engineer the standard enough to
> understand whether the fact that allocator::allocate() and
> allocator::deallocate() are non-const member functions is intentional
> or not. Do you? Is this a legacy of the pre mutable keyword days?

You're right, there's no need for std::allocator<T>::allocate() and
deallocate() to be non-const. I'm not sure why they are.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

I'm not sure whether I correctly understand what table 32 in
[lib.allocator.requirements] says about types, so let me cite
the corresponding lines ..

(Table 31 -> T ... any type, X ... an Allocator class for type T)

Table 32:
expression          return type        assertion/note,pre/post-condition
---------------------------------------------------------------------------
X::pointer          Pointer to T
X::const_pointer    Pointer to const T
X::reference        T&
X::const_reference  T const&
X::value_type       Identical to T


Does that mean that the entries in the 1st column are typedef's for
T*, T const* ,T& ,T const& and T ?

One argument against this interpretation would be the paragraph some
lines later ..
   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.
   - [skipped]
   - The typedef members pointer, const_pointer, size_type, and
     difference_type are required to be T*, T const*, size_t, and
     ptrdiff_t, respectively.


Thanks,
Markus.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Markus Mauhart wrote:
> I'm not sure whether I correctly understand what table 32 in
> [lib.allocator.requirements] says about types, so let me cite
> the corresponding lines ..
>
> (Table 31 -> T ... any type, X ... an Allocator class for type T)
>
> Table 32:
> expression          return type        assertion/note,pre/post-condition
> ---------------------------------------------------------------------------
> X::pointer          Pointer to T
> X::const_pointer    Pointer to const T
> X::reference        T&
> X::const_reference  T const&
> X::value_type       Identical to T
>
>
> Does that mean that the entries in the 1st column are typedef's for
> T*, T const* ,  ...

No. The term "Pointer to" is deliberately meant to allow for other
possibilities.

> ... T& ,T const& and T ?

Yes.

> One argument against this interpretation would be the paragraph some
> lines later ..
>    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.
>    - [skipped]
>    - The typedef members pointer, const_pointer, size_type, and
>      difference_type are required to be T*, T const*, size_t, and
>      ptrdiff_t, respectively.

X::pointer is allowed to be a a smart pointer class, rather than an
actual pointer. It can be such a class either by making it a typedef, or
by making it a member class of X.

It's been suggested that the same can be done with X::reference, but
it's not possible in C++ to implement a true reference class. The key
problem being that it's not possible to provide a user-defined '.' operator.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

"James Kuyper Jr."" <kuyper@wizard.net> wrote ...
>
> Markus Mauhart wrote:
> > I'm not sure whether I correctly understand what table 32 in
> > [lib.allocator.requirements] says about types, so let me cite
> > the corresponding lines ..
> >
> > (Table 31 -> T ... any type, X ... an Allocator class for type T)
> >
> > Table 32:
> > expression          return type        assertion/note,pre/post-condition
> > ---------------------------------------------------------------------------
> > X::pointer          Pointer to T
> > X::const_pointer    Pointer to const T
> > X::reference        T&
> > X::const_reference  T const&
> > X::value_type       Identical to T
> >
> >
> > Does that mean that the entries in the 1st column are typedef's for
> > T*, T const* ,  ...
>
> No. The term "Pointer to" is deliberately meant to allow for other
> possibilities.

3.9.2,par3:
   'A pointer to objects of type T is referred to as a "pointer to T."'

> > ... T& ,T const& and T ?
>
> Yes.
>
> > One argument against this interpretation would be the paragraph some
> > lines later ..
> >    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.
> >    - [skipped]
> >    - The typedef members pointer, const_pointer, size_type, and
> >      difference_type are required to be T*, T const*, size_t, and
> >      ptrdiff_t, respectively.
>
> X::pointer is allowed to be a a smart pointer class, rather than an
> actual pointer. It can be such a class either by making it a typedef, or
> by making it a member class of X.
>
> It's been suggested that the same can be done with X::reference, but
> it's not possible in C++ to implement a true reference class. The key
> problem being that it's not possible to provide a user-defined '.' operator.


Thanks for that clear interpretation.
In the current form it's impossible to get it from the written text.

Main difference between intent and content are the two lines of table 32
regarding X::[const_]pointer; psbl solutions:
1) remove them
2) replace the current 'return type' through one of ..
  "a nested type name (9.9); e.g. some 'smart pointer' or a typedef for T*"
  "a nested type name (9.9), CopyConstructible (20.1.3)"

Additionally the consistent hiding of T[[const]&] behind unmotivated
synonyms is only confusing, this masquerade forces the reader to pay
for functionality that is neither available nor defined.
Therefore the defining 3 lines in table 32 should have added an
explanation, probably 'typedefs necessary for backwards compatibility'
or whatever reason else. From all other parts of 20.1.5 (e.g. table 31)
that synonyms should be removed.

If I have a wish left then replace "identical to T" through "T" to
make it more consistent with the rest of the table and most other
tables - with the current confusing state I really tried to find
the intent for the deliberate difference between "T[const]&" and
"Y" on one side and "identical to T" on the other side.


Would that make sense ?


Thanks,
Markus.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Thu, 7 Nov 2002 03:14:33 +0000 (UTC), kuyper@wizard.net ("James
Kuyper Jr.") wrote:

>X::pointer is allowed to be a a smart pointer class, rather than an
>actual pointer. It can be such a class either by making it a typedef, or
>by making it a member class of X.

I haven't checked the standard because I'm really to busy now, but if
it uses the word "pointer" I doubt that a smart pointer can be used.
Since when a smart pointer is a pointer? (OTOH the standard is
tremendously deficient in the area of basic definitions, and I
strongly suspect there's no definition of "pointer". I remember a
pseudo-definition of pointer declaration, but that's different. In any
case I would bet my PC that if "pointer" includes smart pointers then
defects can be found in flocks. "Return type" of an expression, BTW,
is quite funny too)

Genny.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

"James Kuyper Jr." wrote:
>
> It's been suggested that [allowing a smart 'pointer' class] can be done with X::reference, but
> it's not possible in C++ to implement a true reference class. The key
> problem being that it's not possible to provide a user-defined '.' operator.
>

The original reason for having a reference typedef was the same as for
pointer typedefs: supporting near and far versions. It is, indeed,
possible to do this: the compiler takes care of the details.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Gennaro Prota wrote:
> On Thu, 7 Nov 2002 03:14:33 +0000 (UTC), kuyper@wizard.net ("James
> Kuyper Jr.") wrote:
>
>
>>X::pointer is allowed to be a a smart pointer class, rather than an
>>actual pointer. It can be such a class either by making it a typedef, or
>>by making it a member class of X.
>
>
> I haven't checked the standard because I'm really to busy now, but if
> it uses the word "pointer" I doubt that a smart pointer can be used.
> Since when a smart pointer is a pointer? (OTOH the standard is

I've reached this conclusion, not because it's an obvious one from the
description of "X::pointer", but only because any other interpretation
would seem to render 20.1.5p4's comments about 'pointer' and
'const_pointer' redundant. The standard could easily be made more
explicit on this issue, either by saying "T*" or "random-access iterator
with a value type of T", depending upon what was actually intended.

> tremendously deficient in the area of basic definitions, and I
> strongly suspect there's no definition of "pointer". I remember a

See 8.3.1.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Fri, 8 Nov 2002 04:08:27 +0000 (UTC), kuyper@wizard.net ("James
Kuyper Jr.") wrote:

>Gennaro Prota wrote:
>> On Thu, 7 Nov 2002 03:14:33 +0000 (UTC), kuyper@wizard.net ("James
>> Kuyper Jr.") wrote:
>>
>>
>>>X::pointer is allowed to be a a smart pointer class, rather than an
>>>actual pointer. It can be such a class either by making it a typedef, or
>>>by making it a member class of X.
>>
>>
>> I haven't checked the standard because I'm really to busy now, but if
>> it uses the word "pointer" I doubt that a smart pointer can be used.
>> Since when a smart pointer is a pointer? (OTOH the standard is
>
>I've reached this conclusion, not because it's an obvious one from the
>description of "X::pointer", but only because any other interpretation
>would seem to render 20.1.5p4's comments about 'pointer' and
>'const_pointer' redundant.

Yes. That was exactly why the OP asked his question. Your
interpretation is maybe what the writers of that part wanted to allow,
but given the current wording that's not only far from clear, it's
erroneous. And if I was an implementer of the library being reading
that paragraph I would beware of typedef'ing X::pointer to something
different from T*. Granted, 20.1.5p4 makes it clear that I'm not
required to use a pointer, but it's not clear what else I can do. What
types can I use instead of T*? By choosing something else, I would
always fear to miss some requirement in (or following from) other
parts of the standard. That's also due to another IMHO questionable
habit of the committee which, considering my horrid English, I'll
better explain with an example: consider the resolution of library
issue 199:

  http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#199

Look especially at the rationale. It says, in practice, that since
allocate(0) must return a past-the-end iterator then there was no need
to *specify* the behavior of allocate(0). But that doesn't mean that
the return value of allocate(0) is "unspecified" as the resolution
says!!! Just that section 20.1.5 doesn't specify it again! After all
that's so an evident (and direct!) corollary of the other
requirements... (that there was a DR about it :-) Well, if one really
wanted to clarify he could have added a note saying that the behavior
of allocate(0) is still constrained by requirements on (past-the-end)
iterators. Otherwise better not having the note at all, don't you
think?

Well, all this rigmarole is to say that you can never use a single
paragraph of the standard as a reference; there's always the doubt
that what you have read (e.g. allocate(0) returns an unspecified
value) isn't the whole story. I remember a known expert saying this is
the meta-rule that "specifics override generalities"; actually it just
means that it's allowed to say erroneous things as long as, for the
"special cases", they are corrected elsewhere ;-) If you want another
example, just consider 6.6.3/2; according to that paragraph

  int main() {}

invokes undefined behavior.


>The standard could easily be made more
>explicit on this issue, either by saying "T*" or "random-access iterator
>with a value type of T", depending upon what was actually intended.

I agree. BTW table 32 itself says that the result of allocate is a
random access iterator (though the specifications of
std::allocator::allocate() say the function returns a "pointer to the
initial element of an array of storage").


>> tremendously deficient in the area of basic definitions, and I
>> strongly suspect there's no definition of "pointer". I remember a
>
>See 8.3.1.

That's what I was remembering. As you may see from my previous post I
called it a pseudo-definition. It gets close, but it's actually just
an assertion concerning the "type of an identifier". However I grant
you that, in this specific case, I'm being to harsh (not in other
cases where the definitions are really inexistent and where total
confusion between "if" and "if and only if" reigns though)


P.S.: this should rather go in another thread but while we are at
it... I'm not able to reverse-engineer the standard enough to
understand whether the fact that allocator::allocate() and
allocator::deallocate() are non-const member functions is intentional
or not. Do you? Is this a legacy of the pre mutable keyword days?

Genny.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Yours truly Gennaro wrote:

>though the specifications of
>std::allocator::allocate() say the function returns a "pointer to the
>initial element of an array of storage").

Oops. Please be clement enough to ignore that stupid remark :-(

Genny.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]