Boost logo

Boost :

Subject: Re: [boost] Review Request: impl_ptr (pimpl)
From: Vladimir Batov (Vladimir.Batov_at_[hidden])
Date: 2017-08-22 21:18:59


On 08/23/2017 01:06 AM, Gary Furnish via Boost wrote:
> While I like the idea in general (bikeshedding aside), it should not
> be possible to end up with nulls when treating something as a value
> type.

Is it a general observation or you have a particular use-case in mind
that involves the discussed impl_ptr? It that is the former, then IMO it
is not an issue as impl_ptr is a base class and the user/interface/proxy
class ultimately decides if it is "possible to end up with nulls" or
not. If that is the latter, then I'd certainly like to look at it and to
evaluate and to fix if necessary.

> All of that should be hidden away with some sort of enable if
> machinery. Also your support for allocators doesn't work properly
> because if you use something like an allocator that returns offset
> pointers you assume that all allocators return normal pointers.

Well, "your support for allocators doesn't work properly" seems like a
sweeping statement. They "seem" to work for me but you must have a
particular use-case in mind where they do not. Do you mind elaborating,
sharing it? I am somewhat puzzled by the meaning of "offset pointers". I
presume it is a pointer offset from the beginning of actually allocated
block, right? If so, does std::allocator support that?.. impl_ptr uses
the facilities provided by the allocator concept. Namely, if your
particular allocator returns an "offset pointer" from allocate(), then
that same pointer is given back to your allocator to deal with inside
deallocate(). So, where does "your support for allocators doesn't work
properly" come in?


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk