Re: Naming conventions (was Re: valgrind leak I can't find)

On 23.08.2024 17:57, James Kuyper wrote:

[...]

 
That's possible because C defines separate name spaces of identifiers
(not to be confused with C++ namespaces) for labels, tags, each struct
or union type, and attributes; all other identifiers are in the ordinary
name space. Because of the relevant grammar rules, names in the
different spaces can never occur in locations where it is ambiguous as
to which name space the identifier is from. Therefore, C allows you do
use the same identifier in different name spaces in the same scope with
different meanings. For example, identifiers in the tag name space are
always prefixed with struct, union or enum, so they can never be
confused with names from the ordinary name space.
 
In C++, there are separate name spaces only for macros and labels. All
other identifiers are in the same name space, including tags. Class,
struct, and union members are not controlled by name spaces, but by
scope rules that are different from those in C. That's what allows you
to use a tag without a preceding "class", "struct", or "union" keyword.
Note: The name space for macros isn't really comparable to the other
name spaces I've mentioned, which is why C doesn't have such a name
space. Macros are replaced with their expansions during translation
phase 3, whereas the other name spaces only become meaningful during
translation phase 8.
 
If C were changed to allow use of tags without "struct" or "union"
before them, the tag name space would have to be merged into the
ordinary name space, and that would break all kinds of legacy code that
uses the same identifier as a tag and as an identifier in the ordinary
name space. That would be a backwards incompatible change, and the
committee tends to avoid such changes.

I recall (when I learned C) that the type definitions confused me.

The clear things were ('typedef'-)definitions like

  typedef  struct { double re, im; }  complex;

But then there were also examples like

  typedef  struct tnode {
    ...
    struct tnode * right;
  }  TREENODE, *TREEPTR;

(Both examples taken from an old K&R book.)

In the first case there's no struct name (only the typedef'd one.

In the second case an explicit struct name (necessary for the
type self-reference inside the struct) despite type names being
defined. - Appeared crude to me (and still does).

I don't recall internal name-spaces (as you explain them above)
having been documented and explained. But I may be misremembering.

Janis

[...]