My advice on implementing stuff in C: [LWN.net]

My advice on implementing stuff in C:

Posted Oct 19, 2010 9:54 UTC (Tue) by nix (subscriber, #2304)
In reply to: My advice on implementing stuff in C: by HelloWorld
Parent article: Russell: On C Library Implementation

What? Implicit int doesn't have anything to do with the complexity of name lookup. I was thinking of things like Koenig lookup, the effect of templates on name lookup in general, and what happened to it when 'export' came in. All the rules in isolation are sensible, but in combination it's fearsome.

to post comments

My advice on implementing stuff in C:

Posted Oct 19, 2010 14:46 UTC (Tue) by HelloWorld (guest, #56129) [Link] (1 responses)

It does have to do with the name lookup rules in very non-obvious ways. I quote from "Design and Evolution of C++", page 141/142:

typedef int P();
typedef int Q();
class X {
  static P(Q); // define Q to be a P. 
               // equivalent to ''static int Q()''
               // the parentheses around Q are redundant

               // Q is no longer a type in this scope

  static Q(P); // define Q to be a function taking an argument of type P
               // and returning an int.
               // equivalent to ''static int Q(int());
};
Declaring two functions with the same name in the same scope is fine as long as their argument types differ sufficiently. Reverse the order of member declarations, and we define twi functions called P instead. Remove the typedef for either P or Q from the context, and we get yet other meanings.
This example ought to convince anybody that standards work is dangerous to your mental health. The rules we finally adopted makes[sic] this example undefined.

Note that this example -- like many others -- is based on the unfortunate ''implicit int'' rule inherited from C.

My advice on implementing stuff in C:

Posted Oct 19, 2010 15:32 UTC (Tue) by nix (subscriber, #2304) [Link]

Ah yes, I forgot that ingenious example. However, my point stands: this is not a name lookup problem, it is a particularly ingenious use of the parsing rules around implicit int to produce radically different parse trees from nearly identical input (and by no means the only example: see Alexandrescu's wonderful code in _Modern C++ Design_ to execute arbitrary code at compile time via abuse of sizeof().)

But, yes, this sort of example is probably an indictment of C++. Clarity in coding this is not!