[cfe-dev] Allow implicit copy constructor between address spaces in C++

Richard Smith richard at metafoo.co.uk
Thu May 29 16:20:36 PDT 2014


On Sun, May 25, 2014 at 7:04 AM, Adam Strzelecki <ono at java.pl> wrote:

> > I think the most general thing to do would be to teach SemaInit that a
> reference can bind to an object with a different address space if the
> initialized entity is the first parameter of a trivial copy or move
> constructor or assignment, and to teach it to add a new
> cross-address-space-copy step when that happens.
>
> One thing that bothers me is that reference is kind of constant pointer,
> so dropping address space qualifier sounds kind of weird.


We wouldn't be dropping them; we'd insert an AST node representing "copy
from this address space to that address space" as a special conversion
before we bind the reference. But that's all just implementation details.
The user model is approximately that, for each trivial copy or move
operation, there's something like an overload set copying from each address
space.

Though that would only solve the problem of copying *from* some custom
address space to the default address space. For the other direction, you'd
presumably need address-space-qualified member functions (in particular,
assignment operators).


> > Separately, overload resolution should be taught that this is possible;
> the first standard conversion sequence in such a case should probably have
> conversion rank.
>
> I am afraid this isn't trivial change anymore. Do you think we could
> resolve these address-space issues before final 3.5?


Magic 8-ball says "ask again later" =)


> > +        const RecordType *DestRecordType =
> DestType->getAs<RecordType>();
> > +        CXXRecordDecl *DestRecordDecl
> > +          = cast<CXXRecordDecl>(DestRecordType->getDecl());
> >
> > This is just DestType->getAsCXXRecordDecl().
>
> Thanks for a hint.
>
> --
> Adam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140529/358755ad/attachment.html>


More information about the cfe-dev mailing list