On Tue, 23 Jun 2009 11:03:06 +0200, Mats Kindahl <Mats.Kindahl@stripped>
wrote:
>
>
> Tor Didriksen wrote:
>> On Mon, 22 Jun 2009 19:12:08 +0200, Roy Lyseng <Roy.Lyseng@stripped>
>> wrote:
>>
>>>
>>>
>>> Konstantin Osipov wrote:
>>>> * Tor Didriksen <Tor.Didriksen@stripped> [09/06/22 17:23]:
>>>>
>>>>> "Structure types are typedef'ed to an all-upper-case identifier."
>>>>> Can someone explain the reasoning behind this?
>>>>> ALL_UPPERCASE_NAME says DANGEROUS_THIS_IS_A_MACRO to me, rather than
>>>>> struct/class.
>>>>>
>>>>> typedef struct foo { ... } FOO;
>>>>> Is legacy C-style, and does not belong in a C++ style guide (imho).
>>>>>
>>>>> Roy had an email about this:
>>>>> http://lists.mysql.com/internals/36570
>>>>> I could find no objections to his mail, the thread simply died.
>>>>>
>>>>
>>>> This is an obsolete convention, but it is still widely used in the
>>>> optimizer and semantic analysis code, even in new parts of it. It
>>>> was difficult for me to involve some optimizer engineers into
>>>> discussion about the coding style.
>>>>
>>>> In runtime, I find it largely irrelevant: I advocate against
>>>> introduction of new struct objects into the code base, classes
>>>> should be used instead, and for classes we use a different naming
>>>> rule.
>>>>
>>>> We also have a lot of legacy code that follows this old guideline.
>>>> typedef's are really a pain to maintain, since they obfuscate
>>>> tags-jumping, make forward declarations more difficult.
>>>>
>>>> I guess updating the old code could be a task for reengineering
>>>> team. Drizle did it one of the first things. I would gladly review
>>>> any patch that removes unnecessary typedefs
>>>> from the code, and submit such patches myself once in a while.
>>>> Nobody else, however, seem to have done much about it instead of
>>>> talking :-<.
>>>>
>>>> Please submit a change request to the coding style group to remove
>>>> that rule (unless this mail is already a change request).
>>>>
>>>>
>>>> As Tor said, there is already a proposal:
>>>> http://lists.mysql.com/internals/36570.
>>>
>>> When it is accepted, I will be more than happy to start removing old
>>> typedefs. But I consider it a waste of time unless we have a clear
>>> rule.
>>>
>>> Thanks,
>>> Roy
>>
>> Please note that I am not suggesting a major rewrite of existing code.
>> I don't think that is productive use of engineer time.
>
> Actually, I think that is a productive use of engineer time. I tried to
> work out
> the dependencies of lex.h (to make it self-sufficient), and this is what
> I got:
>
> class Table_ident; /* Need to be before include of sql_yacc.h */
> class Item_num;
> class String;
> class Key_part_spec;
> struct TABLE_LIST;
> typedef struct st_udf_func udf_func;
> typedef struct st_lex_user LEX_USER;
> #include "sql_list.h" /* Pull in List<> */
> #include "set_var.h" /* Pull in sys_var_with_base */
> #include "sql_yacc.h" /* Pull in symbol definitions */
>
> For each line, I had to do a symbol search to find the definition of it
> and see
> how and where it was defined. Most other files have similar
> dependencies...
>
> /Matz
wow!
Each header file should have been self-contained of course, there should
be no need for forward declarations before #include
-- didrik
>
>>
>> -- didrik
>>
>>
>>
>>
>
