* MEMBER_TYPE and CV qualifiers @ 2005-07-17 15:38 Nathan Sidwell 2005-07-17 20:07 ` Mark Mitchell 0 siblings, 1 reply; 11+ messages in thread From: Nathan Sidwell @ 2005-07-17 15:38 UTC (permalink / raw) To: gcc mailing list; +Cc: Jason Merrill, Mark Mitchell I'm looking at holding the CV qualifiers of a member function on the MEMBER_TYPE node itself, rather than only on the this pointer argument. this brings up a design issue of what TYPE_MAIN_VARIANT should be of a cv qualified member function. Should it be itself (thereby breaking the invariant that T_M_V is always unqualified), or should it be the cv unqualified member function? Our current behaviour is such that T_M_V of a member function is a self reference. Clearly cp_build_qualified_type should continue to reject cv qualifying a MEMBER_TYPE. We'd need a new cp_build_qualified_member_type to do that, so we can correctly deal with the syntactic differences. thoughts? nathan -- Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery LLC nathan@codesourcery.com :: http://www.planetfall.pwp.blueyonder.co.uk ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: MEMBER_TYPE and CV qualifiers 2005-07-17 15:38 MEMBER_TYPE and CV qualifiers Nathan Sidwell @ 2005-07-17 20:07 ` Mark Mitchell 2005-07-18 10:15 ` Giovanni Bajo 0 siblings, 1 reply; 11+ messages in thread From: Mark Mitchell @ 2005-07-17 20:07 UTC (permalink / raw) To: Nathan Sidwell; +Cc: gcc mailing list, Jason Merrill Nathan Sidwell wrote: > I'm looking at holding the CV qualifiers of a member function on the MEMBER_TYPE > node itself, rather than only on the this pointer argument. I don't think that's a good idea. The "const" on the member function really does apply to the type pointed to be the "this" pointer, and it doesn't have much significance beyond that. (For example, the reason you can't call a non-const member function on a cost object is just that you can't pass a "T*" to a function expecting "T const*".) I can see that -- purely for convenience or efficiency -- it might make sense to also maintain the cv-qualifiers on the FUNCTION_TYPE itself, but I'd want to see proof first, as that does mean that we'd have to keep the two copes in synch, which has historically been a source of bugs. > this brings up a design issue of what TYPE_MAIN_VARIANT should be of a cv > qualified member function. Should it be itself (thereby breaking the invariant > that T_M_V is always unqualified), or should it be the cv unqualified member > function? Our current behaviour is such that T_M_V of a member function is a > self reference. I think that's the right choice. The function type is no more cv-qualified than any other function type; the only thing that's cv-qualified is the type pointed to by the first argument. -- Mark Mitchell CodeSourcery, LLC mark@codesourcery.com (916) 791-8304 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: MEMBER_TYPE and CV qualifiers 2005-07-17 20:07 ` Mark Mitchell @ 2005-07-18 10:15 ` Giovanni Bajo 2005-07-18 14:25 ` Mark Mitchell 2005-07-19 18:44 ` Jason Merrill 0 siblings, 2 replies; 11+ messages in thread From: Giovanni Bajo @ 2005-07-18 10:15 UTC (permalink / raw) To: Mark Mitchell, Nathan Sidwell; +Cc: jason, gcc Mark Mitchell <mark@codesourcery.com> wrote: > The function type is no more > cv-qualified than any other function type; the only thing that's > cv-qualified is the type pointed to by the first argument. The standard does not agree with you though, see 9.3.1/3. In fact, what happens is that we currently deduce the type wrong (PR 8271) because of the fact that the METHOD_TYPE is not cv-qualified. So either we special-case this, or we represent it correctly. FWIW, Jason agreed that the right way to fix this problem is to put cv qualification on METHOD_TYPE, rather than special-case hacks: http://gcc.gnu.org/ml/gcc-patches/2004-07/msg00550.html http://gcc.gnu.org/ml/gcc-patches/2004-07/msg00630.html -- Giovanni Bajo ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: MEMBER_TYPE and CV qualifiers 2005-07-18 10:15 ` Giovanni Bajo @ 2005-07-18 14:25 ` Mark Mitchell 2005-07-18 15:30 ` Gabriel Dos Reis 2005-07-19 18:44 ` Jason Merrill 1 sibling, 1 reply; 11+ messages in thread From: Mark Mitchell @ 2005-07-18 14:25 UTC (permalink / raw) To: Giovanni Bajo; +Cc: Nathan Sidwell, jason, gcc Giovanni Bajo wrote: > Mark Mitchell <mark@codesourcery.com> wrote: > > >>The function type is no more >>cv-qualified than any other function type; the only thing that's >>cv-qualified is the type pointed to by the first argument. > > > The standard does not agree with you though, see 9.3.1/3. It does indeed say that. I've already said that it might make sense to put the cv-qualifiers in both places, but I've also said that I think it's dangerous, because you have to keep the two places in synch, and that's always been risky. You also have to deal with the fact that much of the compiler may assume function types are not cv-qualified. Furthermore, you have to be careful of things like the fact that you cannot assign a pointer-to-nonconst-member-function to a pointer-to-const-member-function, even though, of course, you can assign a "T*" to a "const T*" if "T" is an object type. So, there are still special cases. Furthermore, 9.3.1/3 is at odds with 3.9.3/1, which says: Each type which is a cv-unqualified complete or incomplete object type or is void (_basic.types_) has three corre- sponding cv-qualified versions of its type: a const-qualified version, a volatile-qualified version, and a const-volatile-qualified version. Note that it explicitly leaves out function types. Obviously, the most important thing is to get the right behavior. Following the standard in our internal representation is secondary -- but highly desirable. In this case, my opinion is that it's a bad idea to put the cv-qualifiers on the FUNCTION_TYPE; I'd rather see the special cases. And, maybe, cp_type_quals should be taught about this case -- we're already supposed to be using that in most places. -- Mark Mitchell CodeSourcery, LLC mark@codesourcery.com (916) 791-8304 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: MEMBER_TYPE and CV qualifiers 2005-07-18 14:25 ` Mark Mitchell @ 2005-07-18 15:30 ` Gabriel Dos Reis 0 siblings, 0 replies; 11+ messages in thread From: Gabriel Dos Reis @ 2005-07-18 15:30 UTC (permalink / raw) To: Mark Mitchell; +Cc: Giovanni Bajo, Nathan Sidwell, jason, gcc Mark Mitchell <mark@codesourcery.com> writes: | Furthermore, 9.3.1/3 is at odds with 3.9.3/1, which says: | | Each type which is a cv-unqualified complete or | incomplete object type or is void (_basic.types_) has three corre- | sponding cv-qualified versions of its type: a const-qualified version, | a volatile-qualified version, and a const-volatile-qualified version. | | Note that it explicitly leaves out function types. Yes. For some reasons (I have not gotten explanations for yet), the specification of member functions seems to be very odd at different places in the standard :-( -- Gaby ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: MEMBER_TYPE and CV qualifiers 2005-07-18 10:15 ` Giovanni Bajo 2005-07-18 14:25 ` Mark Mitchell @ 2005-07-19 18:44 ` Jason Merrill 2005-07-19 18:48 ` Mark Mitchell 1 sibling, 1 reply; 11+ messages in thread From: Jason Merrill @ 2005-07-19 18:44 UTC (permalink / raw) To: Giovanni Bajo; +Cc: Mark Mitchell, Nathan Sidwell, gcc I think that the underlying problem here, as with pointers to data members, comes from using POINTER_TYPE in the first type. Pointers to members are not pointers, and so using POINTER_TYPE just causes confusion. Jason ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: MEMBER_TYPE and CV qualifiers 2005-07-19 18:44 ` Jason Merrill @ 2005-07-19 18:48 ` Mark Mitchell 2005-07-19 19:47 ` Gabriel Dos Reis 0 siblings, 1 reply; 11+ messages in thread From: Mark Mitchell @ 2005-07-19 18:48 UTC (permalink / raw) To: Jason Merrill; +Cc: Giovanni Bajo, Nathan Sidwell, gcc Jason Merrill wrote: > I think that the underlying problem here, as with pointers to data members, > comes from using POINTER_TYPE in the first type. Pointers to members are > not pointers, and so using POINTER_TYPE just causes confusion. I heartily agree. PTRMEM_CST was a step in the right direction, on the object-representation side; we need a PTRMEM_TYPE on the type side as well. Because we don't have a proper lowering phase, the difficulty is that we need to transmute PTRMEM_TYPE into OFFSET_TYPE/RECORD_TYPE at some point. However, that's no excuse for forming a POINTER_TYPE pointing to a METHOD_TYPE or member FUNCTION_TYPE. Such things should be replaced with the RECORD_TYPEs we presently use to represent pointers to member functions. -- Mark Mitchell CodeSourcery, LLC mark@codesourcery.com (916) 791-8304 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: MEMBER_TYPE and CV qualifiers 2005-07-19 18:48 ` Mark Mitchell @ 2005-07-19 19:47 ` Gabriel Dos Reis 2005-07-19 20:14 ` Mark Mitchell 0 siblings, 1 reply; 11+ messages in thread From: Gabriel Dos Reis @ 2005-07-19 19:47 UTC (permalink / raw) To: Mark Mitchell; +Cc: Jason Merrill, Giovanni Bajo, Nathan Sidwell, gcc Mark Mitchell <mark@codesourcery.com> writes: | Jason Merrill wrote: | > I think that the underlying problem here, as with pointers to data members, | > comes from using POINTER_TYPE in the first type. Pointers to members are | > not pointers, and so using POINTER_TYPE just causes confusion. | | I heartily agree. PTRMEM_CST was a step in the right direction, on Agreed. | the object-representation side; we need a PTRMEM_TYPE on the type side | as well. Because we don't have a proper lowering phase, the | difficulty is that we need to transmute PTRMEM_TYPE into | OFFSET_TYPE/RECORD_TYPE at some point. | | However, that's no excuse for forming a POINTER_TYPE pointing to a | METHOD_TYPE or member FUNCTION_TYPE. Such things should be replaced | with the RECORD_TYPEs we presently use to represent pointers to member | functions. Hmm, using RECORD_TYPE for both classes and pointer to member functions seem to me to be less desirable as say, using tree for just about any data structure. I would think as we gradually move toward representations closer to the standard specification we would represent distinct notions by distinct data structures. I recon that such representation needs a lowering stage, but it looks like we're doing that more or less already. Do I miss something? -- Gaby ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: MEMBER_TYPE and CV qualifiers 2005-07-19 19:47 ` Gabriel Dos Reis @ 2005-07-19 20:14 ` Mark Mitchell 2005-07-19 20:35 ` Gabriel Dos Reis 0 siblings, 1 reply; 11+ messages in thread From: Mark Mitchell @ 2005-07-19 20:14 UTC (permalink / raw) To: Gabriel Dos Reis; +Cc: Jason Merrill, Giovanni Bajo, Nathan Sidwell, gcc Gabriel Dos Reis wrote: > | the object-representation side; we need a PTRMEM_TYPE on the type side > | as well. Because we don't have a proper lowering phase, the > | difficulty is that we need to transmute PTRMEM_TYPE into > | OFFSET_TYPE/RECORD_TYPE at some point. > | > | However, that's no excuse for forming a POINTER_TYPE pointing to a > | METHOD_TYPE or member FUNCTION_TYPE. Such things should be replaced > | with the RECORD_TYPEs we presently use to represent pointers to member > | functions. > > Hmm, using RECORD_TYPE for both classes and pointer to member > functions seem to me to be less desirable as say, using tree for just > about any data structure. I would think as we gradually move toward > representations closer to the standard specification we would represent > distinct notions by distinct data structures. Isn't that exactly what I just said above? > I recon that such > representation needs a lowering stage, but it looks like we're doing > that more or less already. Do I miss something? Yes -- we don't really have a lowering stage, unless you count transformation to GENERIC. Doing proper lowering would means lots of changes throughout the front end. For example, "(a.*b)()" gets turned into various manipulations of low-level as soon as it is processed. -- Mark Mitchell CodeSourcery, LLC mark@codesourcery.com (916) 791-8304 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: MEMBER_TYPE and CV qualifiers 2005-07-19 20:14 ` Mark Mitchell @ 2005-07-19 20:35 ` Gabriel Dos Reis 2005-07-19 20:50 ` Mark Mitchell 0 siblings, 1 reply; 11+ messages in thread From: Gabriel Dos Reis @ 2005-07-19 20:35 UTC (permalink / raw) To: Mark Mitchell; +Cc: Jason Merrill, Giovanni Bajo, Nathan Sidwell, gcc Mark Mitchell <mark@codesourcery.com> writes: | Gabriel Dos Reis wrote: | | > | the object-representation side; we need a PTRMEM_TYPE on the type side | > | as well. Because we don't have a proper lowering phase, the | > | difficulty is that we need to transmute PTRMEM_TYPE into | > | OFFSET_TYPE/RECORD_TYPE at some point. | > | | However, that's no excuse for forming a POINTER_TYPE pointing to | > a | > | METHOD_TYPE or member FUNCTION_TYPE. Such things should be replaced | > | with the RECORD_TYPEs we presently use to represent pointers to member | > | functions. | > Hmm, using RECORD_TYPE for both classes and pointer to member | > functions seem to me to be less desirable as say, using tree for just | > about any data structure. I would think as we gradually move toward | > representations closer to the standard specification we would | > represent | > distinct notions by distinct data structures. | | Isn't that exactly what I just said above? I did not understand it that way. Thanks for the clarification. | | > I recon that such | > representation needs a lowering stage, but it looks like we're doing | > that more or less already. Do I miss something? | | Yes -- we don't really have a lowering stage, unless you count | transformation to GENERIC. Yes, I had transformation to GENERIC in mind. Were you thinking of having another stage in addition of transformation to GENERIC? What would be its distinctive characeteristics? -- Gaby ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: MEMBER_TYPE and CV qualifiers 2005-07-19 20:35 ` Gabriel Dos Reis @ 2005-07-19 20:50 ` Mark Mitchell 0 siblings, 0 replies; 11+ messages in thread From: Mark Mitchell @ 2005-07-19 20:50 UTC (permalink / raw) To: Gabriel Dos Reis; +Cc: Jason Merrill, Giovanni Bajo, Nathan Sidwell, gcc Gabriel Dos Reis wrote: > | > I recon that such > | > representation needs a lowering stage, but it looks like we're doing > | > that more or less already. Do I miss something? > | > | Yes -- we don't really have a lowering stage, unless you count > | transformation to GENERIC. > > Yes, I had transformation to GENERIC in mind. Were you thinking of > having another stage in addition of transformation to GENERIC? What > would be its distinctive characeteristics? I'm not sure whether or not a separate stage makes sense. The point is that it's a lot of work, and we don't have it yet, so RECORD_TYPEs are going to continue be used to represent pointers-to-member functions for some time. -- Mark Mitchell CodeSourcery, LLC mark@codesourcery.com (916) 791-8304 ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2005-07-19 20:50 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2005-07-17 15:38 MEMBER_TYPE and CV qualifiers Nathan Sidwell 2005-07-17 20:07 ` Mark Mitchell 2005-07-18 10:15 ` Giovanni Bajo 2005-07-18 14:25 ` Mark Mitchell 2005-07-18 15:30 ` Gabriel Dos Reis 2005-07-19 18:44 ` Jason Merrill 2005-07-19 18:48 ` Mark Mitchell 2005-07-19 19:47 ` Gabriel Dos Reis 2005-07-19 20:14 ` Mark Mitchell 2005-07-19 20:35 ` Gabriel Dos Reis 2005-07-19 20:50 ` Mark Mitchell
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).