| Re: [cdt-dev] Instantiation of dependent expressions may not work |
After reading a bit in the standard, I think I understand. However, I'm not sure what to use as the point of instantiation, as the method seems to expect the very unspecific type IASTNode. If I have the following member declaration: "std::unique_ptr<int> intptr;", what should I use as the starting point? The IASTSimpleDeclaration, which is the entire statement, the ICPPASTDeclarator, which is "intptr" (this seems unlikely), or just the ICPPASTNamedTypeSpecifier, which is "std::unique_ptr<int>? Also, if I understand correctly, a non-partial specialization of a Template is also an instantiation. If I have a class that is fully (or partially) specialized before I instantiate it as a member variable, do I have to use that specialization as the starting point in order to find all constructors, or is it sufficient to use my member declaration as a starting point? Simon On 02/02/2015 05:41 PM, Sergey Prigogin wrote: > The getConstructors() method may have to do template instantiation in > order to return constructors. Template instantiation requires a point of > instantiation. Failure to provide the 'point' argument may cause the > method to return incomplete or invalid results. > > -sergey > > On Mon, Feb 2, 2015 at 4:41 AM, Simon Levermann <simon@xxxxxxxxxxxxx > <mailto:simon@xxxxxxxxxxxxx>> wrote: > > Hi, > > I'm currently in the process of developing an 'Encapsulate Field' > refactoring for the CDT, and I've run into a bit of a problem that I > don't quite understand: > > In order to generate getters and setters that actually compile, I have > to find out whether the field I'm encapsulating is copyable > (forwarding/move setters might need to be generated instead of a > "regular" setter). In order to achieve this, I have written the > following class: > https://github.com/sonOfRa/cdt/blob/encapsulate_field/core/org.eclipse.cdt.ui/src/org/eclipse/cdt/internal/ui/refactoring/encapsulatefield/CopyabilityResolver.java > > This class seems to operate correctly, however for some template types > inside the standard library, like std::unique_ptr<T>, an Exception with > the following message is logged: "Unsafe method call. Instantiation of > dependent expressions may not work.", from > org.eclipse.cdt.internal.core.pdom.dom.cpp.PDOMCPPClassSpecialization.getConstructors(PDOMCPPClassSpecialization.java:276). > > It then proceeds to invoke getConstructors() with point = null. The > documentation on when this can be "unsafe" is quite sparse (or I haven't > found the right piece of documentation yet). What exactly are the > implications of calling getConstructors() (or similar methods) with a > starting point that is null, and why is this method call unsafe? The > interface does not state any thrown Exceptions, which is why I'm > wondering how this case should be correctly handled. > > Best regards, > Simon Levermann > > > > > _______________________________________________ > cdt-dev mailing list > cdt-dev@xxxxxxxxxxx <mailto:cdt-dev@xxxxxxxxxxx> > To change your delivery options, retrieve your password, or > unsubscribe from this list, visit > https://dev.eclipse.org/mailman/listinfo/cdt-dev > > > > > _______________________________________________ > cdt-dev mailing list > cdt-dev@xxxxxxxxxxx > To change your delivery options, retrieve your password, or unsubscribe from this list, visit > https://dev.eclipse.org/mailman/listinfo/cdt-dev >
Attachment:
signature.asc
Description: OpenPGP digital signature