git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [RFC] struct *_struct

From
Michael Witten <mfwitten@gmail.com>
Date
Aug 6, 2010, 03:57 UTC
Message-ID
<4c5b8819.4f3fdc0a.14ad.22b1@mx.google.com>
In-Reply-To
<20100805224321.GA22430@localhost.localdomain>
On Wed, Aug 4, 2010 at 14:24, Junio C Hamano <gitster@pobox.com> wrote:
>>> I hate... "typedef foo struct foo"
On Thu, Aug 05, 2010 at 11:20:14AM -0500, Michael Witten wrote:
>> How come?
On Thu, Aug 5, 2010 at 17:43, Jared Hance <jaredhance@gmail.com> wrote:
Show 31 quoted lines
> In my opinion, it creates ambiguity. If I have
>
>    typedef struct foo foo;
>
> And I have "foo" used in a code snippet, it is much less easier to see
> if foo is being used in the type context or if its an instance, since
> I like to do
>
>    struct foo foo;
>
> which reads much less well as:
>
>    foo foo;
>
>
> Its also much less easier to grep though to find all the places the
> type is used. If I do
>
>    $ git grep "foo"
>
> I will end up with the instances and the struct type. whereas I can do
>
>    $ git grep "struct foo"
>
> to find (most|all) of the types, depending on whether the code uses
> decent practices (there shouldn't be a second space between struct and
> foo, or a newline between them).
>
> I could also use a similar regular expression to find all the
> instances (ie, all the instances of foo that aren't prefixed with
> struct).

Those are valid points, but I'm not sure they have a practical basis; your problems are largely solved by capitalization conventions (which essentially provide shorter replacements for `struct '):

    typedef struct { /* ... */ } Foo;
    Foo foo;

Unfortunately, such conventions don't enjoy the benefit of semantic protection. However, language-aware source navigation tools (like ctags) should be able to solve that problem and are probably more efficient in navigation time than grepping.

Moreover, the form:
    foo foo;

is probably not that problematic in practice; it's presence is likely to be short lived for 2 reasons:

    * Subjectively : everyone thinks it looks awful.
    * Objectively  : It's technically constrained.
The typedef declaration:
    typedef /*type*/ foo;

introduces the typedef name `foo' into the `ordinary identifier' name space; consequently, the declaration:

    foo foo;

cannot even occur in the same scope as the typdef, and when it does occur in an inner scope, it hides the original typdef name `foo' for all subsequent inner scopes:

    typedef struct {char x;} foo;
    foo foo;         // error: attempt to redeclare `foo'.
    foo a;
    int main()
    {
      foo foo;       // OK; hide typedef name with variable `foo'
      foo b;         // error: `foo' is not a type.
      {
        foo c;       // error: `foo' is not a type.
        typedef struct {char x;} foo;   // OK; hide variable `foo'
        foo foo;     // error: attempt to redeclare `foo'
        foo d;
        d = a;       // error: anonymous structs are always different types.
        {
          foo foo;   // OK; hide typedef name with variable `foo'
          d = foo;   // OK; same type
          foo e;     // error: `foo' is not a type.
        }
        {
          foo foo;   // OK; hide typedef name with variable `foo'
          d = foo;   // OK; same type
          foo f;     // error: `foo' is not a type.
        }
      }
    }

Sincerely, Michael Witten

Previous: Jared HanceNext: Jared Hance
Message 6 of 8 in “[RFC] struct *_struct”
  1. Jared HanceAug 4, 2010
  2. Junio C HamanoAug 4, 2010
  3. Refactor structures in the form of *_struct.Jared Hance, Aug 4, 2010
  4. Michael WittenAug 5, 2010
  5. Jared HanceAug 5, 2010
  6. Michael WittenAug 6, 2010
  7. Jared HanceAug 6, 2010
  8. Miles BaderAug 6, 2010

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.