🚀 go-pugleaf

> Path: ..!g.cs.cmu.edu!byee (Bennet Yee @ Carnegie-Mellon University, CS/RI)
>
> I've started playing with C++ & wrote the following:
> 
> class hashtable {
> 	queue_t	bucket[HASHSIZE];
> 	int	(*hash_f)(char *);
> public:
> 	hashtable(int (*hf)(char *)) { hash_f = hf; }
> 	...
> }
> 
> but the compiler complains with syntax error at the declaration
> for the constructor (3 lines), and also then complains something
> about hf, type expected.  What did I do wrong, O c++ wizards?
> 
> -Bsy

There is a nasty and hard to remove (but not impossible to remove) bug in cfront
involving pointers to functions: If a pointer to function appears as the type
of the first argument in a function declaration you get a syntax error.
You can avoid the problem either by using a typedef:

	typedef	int (*PF)(char *);
	class hashtable {
	 	queue_t	bucket[HASHSIZE];
		PF hash_f;
	public:
		hashtable(PF hf) { hash_f = hf; }
		// ...
	};

or by using an explicit ``storage class specifier'':

	class hashtable {
	 	queue_t	bucket[HASHSIZE];
		int	(*hash_f)(char *);
	public:
		hashtable(auto int (*hf)(char *)) { hash_f = hf; }
		// ...
	};

In most cases I prefer the typedef and release 1.0 chokes on that ``auto'';
release 1.1 does not. A similar problem can occur with local variables of
pointer to function type. The same workarounds apply. Sorry.

Mark Terrible had a bad day and wrote this about the original quiry:
 
> Well, for one thing, inline function definitions must be followed by
> a semicolon.  This is one that your fingers will take a while to get
> used to!

Function definitions do not require a ; after the final }. Semicolons after
right-curlies is in nearly all cases needless clutter and a minor source or
errors. For example:

	if (a) {
		// ...
	};
	else {
		// ...
	}

I try to use }; only where it is necessary; that is, after class and enum
declarations where you don't want to declare an object. For example:

	class x { /* ... */ };

If you forget the ; here you get some variation of another famous bug:

	class x {
		// ...
	}

	main()
	{
		// ...
	}

Fortunately, cfront knows better than to accept that one.