On 6 Dez., 00:03, AlbertoBarb...@libero.it (Alberto Ganesh Barbati)
wrote:
> Daniel Kr   gler ha scritto:
> Don't worry about that. It is listed as "rejected"

Ah, thanks for the reminder Alberto!  At first glance, it seems that
the
main arguments came from

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2339.txt

If I correctly understand the reasoning the original request
would have prevented allocators which have an
allocator::pointer that is not directly convertible to void*.
allocator::address() could be used (think of boost::addressof,
which also works for class types overriding the unary
operator &), but internally the allocator could chose
a better route to obtain the object address to construct
into or to destruct.
I accept this generalization of the allocator, but I still
think that this process to get the object address
will be const for the allocator (otherwise I don't understand
how allocator::address itself is required to be const).

Any further ideas?

Thanks so far,

Daniel


---
[ 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.comeaucomputing.com/csc/faq.html                      ]

Both 14882:2003 and the recent draft N2461 declare in
[lib.default.allocator] and [default.allocator], resp.
as well as [lib.allocator.members] and [allocator.members],
resp. the non-static member functions

void construct(pointer p, const T& val);
void destroy(pointer p);

and

void construct(pointer p, const T& val);
template<class... Args> void construct(pointer p, Args&&... args);
void destroy(pointer p);

resp. Comparing these declarations with the table
for Allocator requirements (32 and 40, resp.) and
with the specific member requirements of the
default std::allocator class I see no reasons why
these functions should not be const.

Are there existing implementations where this
change would break something?

Greetings from Bremen,

Daniel Kr   gler


---
[ 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.comeaucomputing.com/csc/faq.html                      ]

Daniel Kr  gler wrote:

> Comparing these declarations with the table
> for Allocator requirements (32 and 40, resp.) and
> with the specific member requirements of the
> default std::allocator class I see no reasons why
> these functions should not be const.

Are you saying that constructing an object cannot possibly change the
internal state of the allocator?

--
Sebastian Redl

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

On Dec 5, 9:49 am, Sebastian Redl <e0226...@student.tuwien.ac.at>
wrote:
> Daniel Kr   gler wrote:
> > Comparing these declarations with the table
> > for Allocator requirements (32 and 40, resp.) and
> > with the specific member requirements of the
> > default std::allocator class I see no reasons why
> > these functions should not be const.
>
> Are you saying that constructing an object cannot possibly change the
> internal state of the allocator?

I'm *asking* that, yes. It definitively seems not so for
std::allocator, the effect clause is explicitly given as

new((void *)p) T(val);

for construct and

((T*)p)->~T();

for destroy. The same is specified in the general
allocator requirements, table 32. The recent draft
does give a more loose description, like

Constructs an object of type T at p by
invoking T(forward<Args>(args)...)

Actually I see no reason for allowing non-const
functions, because the construction/destruction
is not *directly* associated to the allocator, similar
to the address() overloads (which are already const).
So, if the intend was to allow something like logging,
a similar request would be valid for those const
functions and a similar fix would be to mark the
logger as mutable (which is also more usual than
not doing so). But may-be there are other relevant
points which I've overlooked?

Of-course, this complete discussion would stop if

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2257.html

would be relevant.

Greetings from Bremen,

Daniel Kr   gler

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

Daniel Kr=C3=BCgler ha scritto:
>=20
> Of-course, this complete discussion would stop if
>=20
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2257.html
>=20
> would be relevant.
>=20

Don't worry about that. It is listed as "rejected" in
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2433.html

Ganesh

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

Daniel Kr  gler wrote:

> I'm *asking* that, yes. It definitively seems not so for
> std::allocator, the effect clause is explicitly given as
>
> new((void *)p) T(val);
>
> for construct and
>
> ((T*)p)->~T();
>
> for destroy. The same is specified in the general
> allocator requirements, table 32. The recent draft
> does give a more loose description, like
>
> Constructs an object of type T at p by
> invoking T(forward<Args>(args)...)

I think trying to derive general requirements from what the basic default
implementation happens to do is not a very good idea.

Nevertheless, in this case I actually have to agree. Since there is no
requirement to actually call construct and destruct for construction and
destruction, it would be perilous for the allocator to introduce state
changes in these functions.

> Of-course, this complete discussion would stop if
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2257.html
>
> would be relevant.

I really think it's a shame that it was rejected.

--
Sebastian Redl

---
[ 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.comeaucomputing.com/csc/faq.html                      ]