List:Internals« Previous MessageNext Message »
From:Mats Kindahl Date:June 29 2009 10:30am
Subject:Re: MySql coding style: Request for deprecation of UPPERCASE typedefs
View as plain text  

Michael Widenius wrote:
> Hi!
> 
>>>>>> "Mats" == Mats Kindahl <mats@stripped> writes:
> 
> <cut>
> 
>>> I also tested this with gcc and didn't get any error for the
>>> following file:
>>>
>>> typedef struct foo FOO;
>>> struct foo {int a;};
>>> typedef struct foo FOO;
>>>
>>> struct foo a;
>>> FOO b;
>>>
>>> What is it that would give an error?
> 
> Mats> Sorry, I confused two situations: this will not produce an error. The real
> Mats> problem is the following:
> 
> Mats> In some places of the code, it is "typedef struct st_foo FOO" and in some
> places
> Mats> it is "struct FOO" and you always have to check which one it is when
> forward
> Mats> declaring the name, which is wasting time (I'm sitting with this right now,
> and
> Mats> it is not always as easy as hitting M-.).
> 
> The simple rule to solve this is to NEVER forward anything if you can
> avoid it by doing an include. (In a few cases one can't do it as it
> would create circular dependencies but that should be the only exception).

This is not an exception, but rather a common case.

> The reason for always try to avoid forwards, is that this can introduce
> strange bugs when the code changes in the include file.

Please give an example.

> Some reasons why:
> - Struct may be changed to a class

Structs and classes are equivalent according to the C++ standard. I know that
Visual Studio had a problem with that previously, but I assume that it is
resolved by now since that was many years ago. Maybe somebody else can provide
info on this.

> - Someone could replace the class name with a macro with some compile options.

I would consider that evil and not something that we want to support.

> - Not used forwards doesn't produce warnings and over time, as code
>   changes, there will be confusing forward declarations in the code
>   that is never used.

Those forward declarations are completely benign and IMHO is not very confusing.

> - If one adds an include directive for the original declaration, one
>   will often forget to removed the now duplicated forwards.

Those extra forwards are completely benign and IMHO not a good reason to not use
forward declarations.

> Mats, the above is also an reply to your email about:
> http://lists.mysql.com/internals/36891
> Subject line: RFC: draft of physical structure of server code

I am happy to see that you seem to agree with most of it, with the exception of
what you mention below.

> I don't like the idea of not including the real declaration of the
> class/function.  In the past, many of the hard to find problems we
> have had with MySQL have come from wrong declarations because people
> have been to lazy to include the appropriate include file.
> (For example, using 'extern int foo' in a program or not taking into
> account that some things they use can be defined to something else in
> another include file).

Just to clarify, when we mention forward declarations here, we are talking about
forward declarations of *classes* only, not variables, so the "extern int foo"
is not an example of a forward declaration we are considering. For functions and
variables, it is a requirement to use an include file.

I definitely agree that there can be confusing and hard-to-find bugs if one uses
extern declarations (of variables or functions) instead of using an include
file, but as you might have seen later in the proposal, it is suggested that
this should never be used (it is called "introducing gratuitous link dependencies").

I am sorry if that was not clear, so I will update the document to make it clear.

> Mats> - If it is "typedef struct st_foo FOO", "struct FOO" will throw an error.
> 
> Mats> - If it is "struct FOO", then "typedef struct st_foo FOO" will throw an
> error.
> 
> Having a proper naming converting would solve this...
> (Ie, one should use struct foo but typedef struct st_foo FOO).
> 
> Mats> I would prefer if we never used typedef to introduce aliases for
> Mats> struct/class/union, they cause more problem that it's worth, and they are
> not
> Mats> needed in C++ at all.
>>> MySQL was coded in part so that it would be able to easily mix C++ and
>>> C code and allow you to move things from C++ and C with little work.
> 
> Mats> I think that in practice it is not possible to move from C++ to C (since
> C++
> Mats> code inevitable will contain C++ constructs), and that the extra work
> required
> Mats> to move from C to C++ does not really motivate using typedefs.
> 
> Not everything in C++ should/need to be coded with classes and
> constructors.  If one creates a good multipurpose library, it's in
> many cases much better to keep to use C-style as it's has more general
> usage than C++.

That is a very subjective statement.

>>> As MySQL is using C libraries with typedefs, you can't easily get rid
>>> of all the typedefs.
> 
> Mats> It depends on your definition of easy, but I think I can with only minor
> changes
> Mats> to the C code...
> 
> Why change the C code at all ?
> Typedefs should be allowed to use in C, shouldn't it ?

Problem is that they are used in both C and C++, so moving them to only be
available for C is one path forward, the other one is to use the
standards-supported idiom "typedef struct foo { } foo" which will introduce only
one class name and not an alias, making the following legal:

typedef struct foo foo;
struct foo;

Best wishes,
Mats Kindahl
-- 
Mats Kindahl
Senior Software Engineer
Database Technology Group
Sun Microsystems
Thread
MySql coding style: Request for deprecation of UPPERCASE typedefsTor Didriksen22 Jun
  • Re: MySql coding style: Request for deprecation of UPPERCASE typedefsMats Kindahl22 Jun
    • Re: MySql coding style: Request for deprecation of UPPERCASE typedefsMichael Widenius24 Jun
      • Re: MySql coding style: Request for deprecation of UPPERCASE typedefsTor Didriksen25 Jun
        • Re: MySql coding style: Request for deprecation of UPPERCASE typedefsMichael Widenius27 Jun
      • Re: MySql coding style: Request for deprecation of UPPERCASE typedefsMats Kindahl25 Jun
        • Re: MySql coding style: Request for deprecation of UPPERCASE typedefsMichael Widenius27 Jun
          • Re: MySql coding style: Request for deprecation of UPPERCASE typedefsJay Pipes27 Jun
          • Re: MySql coding style: Request for deprecation of UPPERCASE typedefsTor Didriksen29 Jun
          • Re: MySql coding style: Request for deprecation of UPPERCASE typedefsMats Kindahl29 Jun
            • Re: MySql coding style: Request for deprecation of UPPERCASE typedefsKristian Nielsen29 Jun
              • Re: MySql coding style: Request for deprecation of UPPERCASE typedefsTor Didriksen30 Jun
                • Re: MySql coding style: Request for deprecation of UPPERCASE typedefsMats Kindahl30 Jun
                • Re: MySql coding style: Request for deprecation of UPPERCASE typedefsKristian Nielsen30 Jun
                  • Re: MySql coding style: Request for deprecation of UPPERCASE typedefsTor Didriksen1 Jul
                    • Re: MySql coding style: Request for deprecation of UPPERCASE typedefsKristian Nielsen1 Jul
                  • Re: MySql coding style: Request for deprecation of UPPERCASE typedefsKonstantin Osipov1 Jul
              • Re: MySql coding style: Request for deprecation of UPPERCASE typedefsKonstantin Osipov1 Jul
                • Re: MySql coding style: Request for deprecation of UPPERCASE typedefsKristian Nielsen2 Jul
  • Re: MySql coding style: Request for deprecation of UPPERCASE typedefsKonstantin Osipov22 Jun
    • Re: MySql coding style: Request for deprecation of UPPERCASE typedefsRoy Lyseng22 Jun
      • Re: MySql coding style: Request for deprecation of UPPERCASE typedefsTor Didriksen23 Jun
        • Re: MySql coding style: Request for deprecation of UPPERCASE typedefsMats Kindahl23 Jun
          • Re: MySql coding style: Request for deprecation of UPPERCASE typedefsTor Didriksen23 Jun
            • Re: MySql coding style: Request for deprecation of UPPERCASE typedefsMats Kindahl23 Jun
              • Re: MySql coding style: Request for deprecation of UPPERCASE typedefsMichael Widenius27 Jun
                • Re: MySql coding style: Request for deprecation of UPPERCASE typedefsMats Kindahl30 Jun
            • Re: MySql coding style: Request for deprecation of UPPERCASE typedefsMichael Widenius24 Jun
              • Re: MySql coding style: Request for deprecation of UPPERCASE typedefsTor Didriksen25 Jun
                • Re: MySql coding style: Request for deprecation of UPPERCASE typedefsJonas Oreland25 Jun
                  • Re: MySql coding style: Request for deprecation of UPPERCASE typedefsDavi Arnaut25 Jun
                    • Re: MySql coding style: Request for deprecation of UPPERCASE typedefsMichael Widenius27 Jun
                  • Re: MySql coding style: Request for deprecation of UPPERCASE typedefsMichael Widenius27 Jun
                • Re: MySql coding style: Request for deprecation of UPPERCASE typedefsJay Pipes25 Jun
                  • Re: MySql coding style: Request for deprecation of UPPERCASE typedefsMats Kindahl25 Jun
                  • Re: MySql coding style: Request for deprecation of UPPERCASE typedefsMichael Widenius27 Jun
                • Re: MySql coding style: Request for deprecation of UPPERCASE typedefsMichael Widenius27 Jun
                  • Re: MySql coding style: Request for deprecation of UPPERCASE typedefsMats Kindahl30 Jun
              • Re: MySql coding style: Request for deprecation of UPPERCASE typedefsMats Kindahl25 Jun
                • Re: MySql coding style: Request for deprecation of UPPERCASE typedefsMichael Widenius27 Jun
                  • Re: MySql coding style: Request for deprecation of UPPERCASE typedefsJay Pipes27 Jun
                    • Re: MySql coding style: Request for deprecation of UPPERCASE typedefsMichael Widenius30 Jun
                  • Re: MySql coding style: Request for deprecation of UPPERCASE typedefsJay Pipes27 Jun
                    • Re: MySql coding style: Request for deprecation of UPPERCASE typedefsMichael Widenius1 Jul
    • Re: MySql coding style: Request for deprecation of UPPERCASE typedefsTor Didriksen23 Jun
  • Re: MySql coding style: Request for deprecation of UPPERCASEtypedefsSergei Golubchik22 Jun
    • Re: MySql coding style: Request for deprecation of UPPERCASE typedefsTor Didriksen23 Jun
      • Re: MySql coding style: Request for deprecation of UPPERCASEtypedefsSergei Golubchik23 Jun
        • Re: MySql coding style: Request for deprecation of UPPERCASE typedefsTor Didriksen23 Jun
  • Re: MySql coding style: Request for deprecation of UPPERCASE typedefsAlex Esterkin1 Jul
    • Re: MySql coding style: Request for deprecation of UPPERCASE typedefsTor Didriksen1 Jul
    • Re: MySql coding style: Request for deprecation of UPPERCASE typedefsKonstantin Osipov1 Jul