* [PATCH] document cp_operator_id and cp_assignment_operator_id @ 2017-06-15 16:57 Martin Sebor 2017-06-15 21:25 ` Jason Merrill 0 siblings, 1 reply; 4+ messages in thread From: Martin Sebor @ 2017-06-15 16:57 UTC (permalink / raw) To: Gcc Patch List, Jason Merrill [-- Attachment #1: Type: text/plain, Size: 136 bytes --] Attached is a documentation-only change to add comments explaining the C++ cp_operator_id and cp_assignment_operator_id macros. Martin [-- Attachment #2: gcc-cp_operator_id-doc.diff --] [-- Type: text/x-patch, Size: 1045 bytes --] gcc/cp/ChangeLog: * cp-tree.h (cp_operator_id, cp_assignment_operator_id): Document. diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h index da45d95..234441b 100644 --- a/gcc/cp/cp-tree.h +++ b/gcc/cp/cp-tree.h @@ -1731,9 +1731,16 @@ struct GTY(()) language_function { || (NAME) == cp_operator_id (DELETE_EXPR) \ || (NAME) == cp_operator_id (VEC_DELETE_EXPR)) +/* Evaluates to an id matching operator CODE. Used to obtain the set + of operator overloads for the specified CODE. */ #define cp_operator_id(CODE) \ (operator_name_info[(int) (CODE)].identifier) -#define cp_assignment_operator_id(CODE) \ + +/* An id matching a member assignment operator CODE, both simple (with + CODE == NOP_EXPR) and compound (e.g., with CODE == PLUS_EXPR for +=). + Includes copy assignment. Use copy_fn_p() to test specifically for + copy assignment. */ +#define cp_assignment_operator_id(CODE) \ (assignment_operator_name_info[(int) (CODE)].identifier) /* In parser.c. */ extern tree cp_literal_operator_id (const char *); ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] document cp_operator_id and cp_assignment_operator_id 2017-06-15 16:57 [PATCH] document cp_operator_id and cp_assignment_operator_id Martin Sebor @ 2017-06-15 21:25 ` Jason Merrill 2017-06-15 22:57 ` Martin Sebor 0 siblings, 1 reply; 4+ messages in thread From: Jason Merrill @ 2017-06-15 21:25 UTC (permalink / raw) To: Martin Sebor; +Cc: Gcc Patch List On Thu, Jun 15, 2017 at 12:57 PM, Martin Sebor <msebor@gmail.com> wrote: > Attached is a documentation-only change to add comments explaining > the C++ cp_operator_id and cp_assignment_operator_id macros. Hmm, I'd say that these macros return the identifier used internally to represent "operator OP" and "operator OP=", respectively. Looking up overloads is one thing you can do with that name, but the same is true of all identifiers, do we need to mention it specifically? Jason ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] document cp_operator_id and cp_assignment_operator_id 2017-06-15 21:25 ` Jason Merrill @ 2017-06-15 22:57 ` Martin Sebor 2017-07-01 21:42 ` Jason Merrill 0 siblings, 1 reply; 4+ messages in thread From: Martin Sebor @ 2017-06-15 22:57 UTC (permalink / raw) To: Jason Merrill; +Cc: Gcc Patch List [-- Attachment #1: Type: text/plain, Size: 1488 bytes --] On 06/15/2017 03:24 PM, Jason Merrill wrote: > On Thu, Jun 15, 2017 at 12:57 PM, Martin Sebor <msebor@gmail.com> wrote: >> Attached is a documentation-only change to add comments explaining >> the C++ cp_operator_id and cp_assignment_operator_id macros. > > Hmm, I'd say that these macros return the identifier used internally > to represent "operator OP" and "operator OP=", respectively. Looking > up overloads is one thing you can do with that name, but the same is > true of all identifiers, do we need to mention it specifically? I tried to describe the use case that I needed but that wasn't obvious to me from the examples I cam across. If these cp_foo_id() helpers and the other identifier macros were defined and documented in one place there could be a few examples at the top of the section listing them showing some of the less obvious use cases. As it is, cp_operator_id() and cp_assignment_operator_id() are defined in one place (and using the cp_foobar_id() naming convention), while the {ctor,dtor}_ identifier macros in another (and using a different convention). Perhaps there's a good reason for it but knowing as little as I do I find it confusing because I used both to do the same thing: iterate over the overloads of the special functions. With that in mind, attached is an update that tries to clarify things without mentioning the example in the comments for (just) the operator _id macros. If you have a better suggestion I'll be happy to take it. Martin [-- Attachment #2: gcc-cp_operator_id-doc.diff --] [-- Type: text/x-patch, Size: 2723 bytes --] gcc/cp/ChangeLog: * cp-tree.h (cp_operator_id, cp_assignment_operator_id): Document. diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h index da45d95..b4795d2 100644 --- a/gcc/cp/cp-tree.h +++ b/gcc/cp/cp-tree.h @@ -209,8 +209,19 @@ extern GTY(()) tree cp_global_trees[CPTI_MAX]; /* std::align_val_t */ #define align_type_node cp_global_trees[CPTI_ALIGN_TYPE] -/* We cache these tree nodes so as to call get_identifier less - frequently. */ +/* We cache these tree nodes so as to call get_identifier less frequently. + For identifiers for functions, including special member functions such + as ctors and assignment operators, the nodes can be used (among other + things) to iterate over their overloads defined by/for a type. For + example: + + tree ovlid = cp_assignment_operator_id (NOP_EXPR); + tree overloads = lookup_fnfields_slot (type, ovlid); + for (ovl_iterator it (overloads); it; ++it) { ... } + + iterates over the set of implicitly and explicitly defined overloads + of the assignment operator for type (including the copy and move + assignment operators, whether deleted or not). */ /* The name of a constructor that takes an in-charge parameter to decide whether or not to construct virtual base classes. */ @@ -231,6 +242,18 @@ extern GTY(()) tree cp_global_trees[CPTI_MAX]; /* The name of a destructor that destroys virtual base classes, and then deletes the entire object. */ #define deleting_dtor_identifier cp_global_trees[CPTI_DELETING_DTOR_IDENTIFIER] + +/* The name of the identifier used internally to represent operator CODE. */ +#define cp_operator_id(CODE) \ + (operator_name_info[(int) (CODE)].identifier) + +/* The name of the identifier used to represent assignment operator CODE, + both simple (i.e., operator= with CODE == NOP_EXPR) and compound (e.g., + operator+= with CODE == PLUS_EXPR). Includes copy and move assignment. + Use copy_fn_p() to test specifically for copy assignment. */ +#define cp_assignment_operator_id(CODE) \ + (assignment_operator_name_info[(int) (CODE)].identifier) + #define delta_identifier cp_global_trees[CPTI_DELTA_IDENTIFIER] #define in_charge_identifier cp_global_trees[CPTI_IN_CHARGE_IDENTIFIER] /* The name of the parameter that contains a pointer to the VTT to use @@ -1731,10 +1754,6 @@ struct GTY(()) language_function { || (NAME) == cp_operator_id (DELETE_EXPR) \ || (NAME) == cp_operator_id (VEC_DELETE_EXPR)) -#define cp_operator_id(CODE) \ - (operator_name_info[(int) (CODE)].identifier) -#define cp_assignment_operator_id(CODE) \ - (assignment_operator_name_info[(int) (CODE)].identifier) /* In parser.c. */ extern tree cp_literal_operator_id (const char *); ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] document cp_operator_id and cp_assignment_operator_id 2017-06-15 22:57 ` Martin Sebor @ 2017-07-01 21:42 ` Jason Merrill 0 siblings, 0 replies; 4+ messages in thread From: Jason Merrill @ 2017-07-01 21:42 UTC (permalink / raw) To: Martin Sebor; +Cc: Gcc Patch List OK. On Thu, Jun 15, 2017 at 6:57 PM, Martin Sebor <msebor@gmail.com> wrote: > On 06/15/2017 03:24 PM, Jason Merrill wrote: >> >> On Thu, Jun 15, 2017 at 12:57 PM, Martin Sebor <msebor@gmail.com> wrote: >>> >>> Attached is a documentation-only change to add comments explaining >>> the C++ cp_operator_id and cp_assignment_operator_id macros. >> >> >> Hmm, I'd say that these macros return the identifier used internally >> to represent "operator OP" and "operator OP=", respectively. Looking >> up overloads is one thing you can do with that name, but the same is >> true of all identifiers, do we need to mention it specifically? > > > I tried to describe the use case that I needed but that wasn't > obvious to me from the examples I cam across. > > If these cp_foo_id() helpers and the other identifier macros were > defined and documented in one place there could be a few examples > at the top of the section listing them showing some of the less > obvious use cases. As it is, cp_operator_id() and > cp_assignment_operator_id() are defined in one place (and using > the cp_foobar_id() naming convention), while the {ctor,dtor}_ > identifier macros in another (and using a different convention). > Perhaps there's a good reason for it but knowing as little as > I do I find it confusing because I used both to do the same > thing: iterate over the overloads of the special functions. > > With that in mind, attached is an update that tries to clarify > things without mentioning the example in the comments for (just) > the operator _id macros. > > If you have a better suggestion I'll be happy to take it. > > Martin ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2017-07-01 21:42 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-06-15 16:57 [PATCH] document cp_operator_id and cp_assignment_operator_id Martin Sebor 2017-06-15 21:25 ` Jason Merrill 2017-06-15 22:57 ` Martin Sebor 2017-07-01 21:42 ` Jason Merrill
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).