Re: would C be easier to read if...

On Apr 3, 6:04 pm, "Bartc" <b...@xxxxxxxxxx> wrote:
"Ben Pfaff" <b...@xxxxxxxxxxxxxxx> wrote in message

news:87lk3u7pwj.fsf@xxxxxxxxxxxxxxxxxxx

"Bartc" <b...@xxxxxxxxxx> writes:

What on earth does (void *(*)(void*)) mean? It's some sort of cast, so
the
type is:

void *(*)(void*)

My guess is it's a function returning type void*, and maybe taking a
single
parameter of void*, but what about the (*) in the middle?!

That means it's a pointer to a function.  The full type is
"pointer to function taking a void * argument and returning void
*".

OK thanks.

And * does apparently seem to change position. Unless I've got these
wrong:
int *a    a is pointer to int (* on left)

OK.

(int *)    pointer to int (* on right)

That's not a type or a declaration.  It's a cast.  In a cast,
there is no variable to name, so "a" is omitted.  If there was a
variable there, it would be in the same position.

I agree that the type-declaration scheme /is/ logical when you analyse it,
it's just difficult to read! Being adept at it does not change that.

While we're in this fantasy thread, I knocked up this new left-to-right
easy-to-read syntax for C type declarations. Type-decls are constructed with
the following symbols (enums and some other stuff left out):

*               Pointer to
type            Type name (built-in or typedef-ed)
function        Optional function indicator
(...)T          Function Takes these params, returns type T
[]              Array of
[N]             Array of N of
struct{...}     Struct of
struct S{...}   Struct S of

These are written left to right, example:

*int a,b;                 a,b are both pointers to int
function(int,int)float    Function taking two int params and returning float
result
(int,int)float            Same without the 'function'
[10]char s,t              s,t are both 10-char arrays
[10]*char list            Array of pointers to char (array of strings)
*function(*void)*void     Above example
*(*void)*void             Above example without 'function'

Pros:
* Easy to read, translates naturally to English
* Variables sharing same array/pointer properties share the one type-decl(as
in above examples)
* The typedef T U statement, in practice may have T and U hopelessly
intermingled for complex type-decls. With this scheme T and U stay separate.
* Also type-decls appear in typedefs, var-decls, casts, and function params
all have the same form

Cons:
* Can't mix declaration of variables that have different array/pointer
attributes (but I think that's a bad idea anyway).

Here's the thing: that's not any more or less readable than C's
syntax, just different. In order to really change the readability,
you'd have to go back to the type system itself and look at it.

C's type system admits the following[1] as types:

void (the type that has no values.)
char, short, int, long, long long, and unsigned/signed variants
(ordinal types.)
float and double
struct {T1, T2, ...} (structure/named tuple types.)
pointers to any function signature.
('a' is a type -> 'a (*) (T1, T2, ...)' is a type)
pointers to any value type
('a' is a type -> 'a *' is a type)
constants of any type
('a' is a type -> 'a const' is a type)

It also halfways admits to the existence of arrays; each pair
(unsigned number, type) is a distinct array type, but you can't pass
values of array types around directly.

Functions themselves, however, are not directly represented in C's
type system. This makes sense; C is not a functional language and you
cannot create functions in it at runtime.

The treatment of void is somewhat inconsistent: it's a type with
exactly zero values. All other types have at least one value.
Consequently, you can declare pointers to void, but not have
expressions or variables whose type is void.

I posit that any syntax that expresses the C type system will be
"messy" the same way C's syntax is: the mess is in the (pragmatic and
very useful) type system itself. If you want a language with a
cleaner syntax for expressing types, choose a language with a cleaner
type system.

-o-

[1] Not intended to be exhaustive.
.

Relevant Pages

  • Re: sizeof(ptr) = ?
    ... A void * has the same representation as a char *. ... Char pointers which require additional data ... iff the default offset is 0. ...
    (comp.lang.c)
  • Re: Malloc code
    ... int xxx; ... As for not using the void pointer, I will have to do some further testing ... I just needed some insight on passing arrays of pointers. ... struct MCB *r1; ...
    (microsoft.public.vc.language)
  • Re: polymorphic design approach
    ... > polymorphism. ... * 'Device' pointers are stored so as to allow polymorphic ... virtual void handleMessage ...
    (alt.comp.lang.learn.c-cpp)
  • Re: Realloc and pointer arithmetics
    ... through an AVL tree that managed void* data. ... the C standard does not. ... My frist thought was actually to store into the tree pointers to array ...
    (comp.lang.c)
  • Re: On the creation of an API for containers in C
    ... pointers, and these dynamic vectors. ... where 'dyt' was basically a wrapper for an anonymous void pointer. ... cost of this approach), although, if one makes use of the dynamic-type ... typed void pointers' and 'tagged references' (where the value is essentially ...
    (comp.lang.c)