On Sat, 27 Jun 2009 10:25:14 +0200, Michael Widenius <monty@stripped>
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).
Note that my initial mail was quite specific: I want to deprecate the
UPPERCASE typedef naming rule because
- the chosen names are BAD_BAD_BAD
- having two names for the same thing, when only one name suffices,
creates confusion
- the rule has been interpreted in different ways, and is not used
consistently anyways.
-- didrik
If you want to start a discussion on header files etc. please read up on
other peoples experiences first,
and then start a separate thread. A possible starting point would be:
http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Header_File_Dependencies
--regards, didrik
>
> The reason for always try to avoid forwards, is that this can introduce
> strange bugs when the code changes in the include file.
>
> Some reasons why:
> - Struct may be changed to a class
> - Someone could replace the class name with a macro with some compile
> options.
> - 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.
> - If one adds an include directive for the original declaration, one
> will often forget to removed the now duplicated forwards.
>
> 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 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).
>
> 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++.
>
>>> 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 ?
>
> Regards,
> Monty
>
