Re: [boost] Will addressof be in C++0x?

From: Andrey Semashev (andysem_at_[hidden])
Date: 2007-10-13 15:42:42

First of all, thank you for your reply and sorry for a bit lengthy post.

>> I'd like to ask if boost::addressof is going to be proposed to be
>> included in the upcoming C++ Standard. And what is more important to  
>> me,
>> will it solve the problem of storing objects with custom operator& in
>> STL containers and acquiring their addresses with
>> std::allocator<T>::address.
> 
> As of last week, it looks like std::allocator<T>::address will supply  
> the functionality of boost::addressof.  This is LWG issue 634:
> 
> http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#634

It's nice to see it, thanks for the link.

> I'm afraid my answer amounts to: we're seriously considering it;  
> maybe. :-\
> 
> Perhaps I should turn this around and ask you a question:  What  
> motivating use cases (of yours) can I bring to the committee to affirm  
> our current position that value_type's with overloaded operator& can  
> be put into the standard containers?

Well, actually I don't quite realize the cause of this restriction in
the first place as I don't see why would the CopyConstructible
requirement need to impose a denial of the operator& overload.

Anyway, here's a real life example. In our company we had a long
struggle against storing ATL types, like CComBSTR and CComPtr, directly
in STL containers since the STL implementation we used compiled it
silently but leaked the resources in the runtime (it just didn't call
destructors of those classes, thinking that it destructs raw pointers
returned by their operator&). I understand that our developers were
wrong by not reading MSDN thoroughly, and that our STL implementation
could have been more friendly, and ATL could have been made differently,
and... But it's the fact that such a behavior is stated legal by the
Standard that bugs me.

We have spent months in hunting down those leaks, retesing and
rereleasing our product, we've put significant effort in developing
instruments to detect them and integrating those tools into our code.
We've updated our questionnaire for the new employees (which, BTW,
showed that  a great deal of aspirants, just not to say majority of
them, have no idea of this STL limitation) and drew attention to the
issue of our current developers. And still, as we were switching to a
new STL implementation recently, we were still finding several places in
our code with this problem.

Another good motivating example, a bit theoretical nowdays though, is
implementing smart-references, along with smart-pointers. I see you
mentioned them in your proposal regarding allocator.address() and I saw
them mentioned in some different proposals. I think it would be a good
idea to have the ability to store them in containers, like we can do
with reference_wrapper and shared_ptr now.

As I see it, there are three major points to allow storing types with
user-defined operator& in containers:
* The CopyConstructible concept should deal with the ability to create a
copy of an object. It should not involve any third-party functions like
operator&. If it can be overloaded, assume it is. And this fact does not
interleave with the ability to call the object's copy constructor.
* Same goes with containers. Their primary job is to store objects and
while doing this they should call minimum of user-defined functions
(thus imposing minimum set of requirements on types that can be stored).
It should be assumed that operator& may be overloaded and is not
suitable to acquire the address of the stored object for the internal
needs of the container (for example, to destroy the object). I think, it
would be natural to use allocator facilities for this purpose.
* The restriction is counter-intuitive. This makes C++ a little more
complicated than it could be. My practice have shown that this issue
can, actually, impose serious problems on the users' side, both in
writing the code and in learning the language.