This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 4/5] add gcc/gdb interface files


>>>>> "Jakub" == Jakub Jelinek <jakub@redhat.com> writes:

>> +GCC_METHOD7 (gcc_decl, build_decl,
>> +	     const char */* name */,
>> +	     enum gcc_c_symbol_kind /* sym_kind */,
>> +	     gcc_type /* sym_type */,
>> +	     const char */* substitution_name */,
>> +	     gcc_address /* address */,
>> +	     const char */* filename */,
>> +	     unsigned int /* line_number */)
>> 
>> I must say that I hate the embedded comments in the signatures.
>> Especially when you end up with something like:

It's not so bad with colorizing but not everybody likes fruit salad.  I
can see how it would be pretty painful without.

Jakub> Why it can't be:
Jakub> GCC_METHOD7 (gcc_decl, build_decl,
Jakub> 	     const char *name,
Jakub> 	     enum gfc_c_symbol_kind sym_kind,
Jakub> ...
Jakub> i.e. provide comments in the form of argument names
Jakub> (sure, you can't use bool for the name of the parameter then...).

It's important that just the types are there.
For example the .def file is used to instantiate C++ templates:

#define GCC_METHOD7(R, N, A, B, C, D, E, F, G) \
  rpc<R, cc1_plugin::N, A, B, C, D, E, F, G>,

Here we can't have a parameter name.


I chose this commenting approach since it named the parameters, albeit
in comments.

The "/* bool */" comments are there because gdb doesn't have a bool
type, but it still seemed worthwhile to document the intent.


I could drop the names and extend the various introductory comments to
explain argument ordering.  What do you think of that?

Tom


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]