would C be easier to read if...

[Robert Smith]

some of the syntax wasn't overloaded so much...

Was just musing that if pointer de-referencing and pointer-to-type had
seperate syntax (ie use a character other than '*' for one of them) it would
make things much easier to read. You wouldn't get stuff like:

pthread_create( &thread, NULL, (void *(*)(void*))Thr eadProc, (void
*)parameter);

[Chris Dollin]

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

Robert Smith wrote:

some of the syntax wasn't overloaded so much...
>
Was just musing that if pointer de-referencing and pointer-to-type had
seperate syntax (ie use a character other than '*' for one of them) it would
make things much easier to read. You wouldn't get stuff like:
>
pthread_create( &thread, NULL, (void *(*)(void*))Thr eadProc, (void
*)parameter);

Surely either `ThreadProc` is already the right type, in which case
the cast can and should be discarded, or it isn't, in which case
the cast is a bug waiting to manifest and `ThreadProc` should be
fixed.

Yes?

--
"In vain I have struggled. It will not do." /Pride and Prejudice/

Hewlett-Packard Limited Cain Road, Bracknell, registered no:
registered office: Berks RG12 1HN 690597 England

[Hallvard B Furuseth]

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

Chris Dollin writes:

>Robert Smith wrote:

>pthread_create (&thread, NULL, (void *(*)(void*))Thr eadProc, (void
>*)parameter) ;

>
Surely either `ThreadProc` is already the right type, in which case
the cast can and should be discarded, or it isn't, in which case
the cast is a bug waiting to manifest and `ThreadProc` should be
fixed.
>
Yes?

And hopefully 'parameter' is a non-const pointer so the void* cast
can be dropped too.

The times where you do need to clutter the code with unreadable
type casts, it may make sense to typedef the offending type.

--
Hallvard

[Ben Bacarisse]

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

"Robert Smith" <someone@somewh ere.comwrites:

some of the syntax wasn't overloaded so much...
>
Was just musing that if pointer de-referencing and pointer-to-type had
seperate syntax (ie use a character other than '*' for one of them) it would
make things much easier to read. You wouldn't get stuff like:
>
pthread_create( &thread, NULL, (void *(*)(void*))Thr eadProc, (void
*)parameter);

All the *s there have the same meaning, don't they? How would
changing the symbol help?

--
Ben.

[Bartc]

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


"Robert Smith" <someone@somewh ere.comwrote in message
news:rd5Jj.5608 $n8.2434@news-server.bigpond. net.au...

some of the syntax wasn't overloaded so much...
>
Was just musing that if pointer de-referencing and pointer-to-type had
seperate syntax (ie use a character other than '*' for one of them) it
would make things much easier to read. You wouldn't get stuff like:
>
pthread_create( &thread, NULL, (void *(*)(void*))Thr eadProc, (void
*)parameter);

I've got more serious problems with understanding C declarations, for
example:

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?!

And * does apparently seem to change position. Unless I've got these wrong:

int *a a is pointer to int (* on left)
(int *) pointer to int (* on right)
*a dereference pointer to int (* on left again).

In my case a type declaration that reads linearly from left to right would
help tremendously, because that's what I'm familiar with. Just having the
word 'function' in a function declaration would make things so much clearer!

Maybe C's syntax will get easier with use, I don't know, but since I stay
well clear of anything complicated, probably not.

--
Bart

[Ben Pfaff]

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

"Bartc" <bc@freeuk.comw rites:

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
*".

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.

There is one situation where the variable name may be included or
omitted, at your option, and that is in a function prototype (that
is not for a function being defined). So the following are
equivalent, and may be enlightening:
void foo(int *a);
void foo(int *);
See? The variable name is just omitted, and there's no changing
of position going on.
--
int main(void){char p[]="ABCDEFGHIJKLM NOPQRSTUVWXYZab cdefghijklmnopq rstuvwxyz.\
\n",*q="kl BIcNBFr.NKEzjwC IxNJC";int i=sizeof p/2;char *strchr();int putchar(\
);while(*q){i+= strchr(p,*q++)-p;if(i>=(int)si zeof p)i-=sizeof p-1;putchar(p[i]\
);}return 0;}

[Ian Collins]

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

Hallvard B Furuseth wrote:

Chris Dollin writes:

>Robert Smith wrote:

>>pthread_creat e(&thread, NULL, (void *(*)(void*))Thr eadProc, (void
>>*)parameter );

>Surely either `ThreadProc` is already the right type, in which case
>the cast can and should be discarded, or it isn't, in which case
>the cast is a bug waiting to manifest and `ThreadProc` should be
>fixed.
>>
>Yes?

>
And hopefully 'parameter' is a non-const pointer so the void* cast
can be dropped too.
>
The times where you do need to clutter the code with unreadable
type casts, it may make sense to typedef the offending type.
>

No, all the typedef dose is introduce an alias, it doesn't remove the
need to cast an inappropriate type.

If you do need to clutter the code with unreadable casts, you are doing
something smelly and should reconsider what you are doing.

--
Ian Collins.

[Robbie Hatley]

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


"Robert Smith" wrote:

some of the syntax wasn't overloaded so much...
>
Was just musing that if pointer de-referencing and pointer-to-type had
seperate syntax (ie use a character other than '*' for one of them) it would
make things much easier to read. You wouldn't get stuff like:
>
pthread_create( &thread, NULL, (void *(*)(void*))Thr eadProc, (void
*)parameter);

At my last job, we used some function pointers of complicated types
which were defined using typedefs, similar to:

typedef int (*MessageProc)( int, int, int*, const char*);

or some damn such thing. The pointers could point to any of several
alternate functions with the same signature, to tailor behaviour.
Sort of "poor man's function overloading". Such things no longer even
seem obfuscated to me. One gets used to it.

--
Cheers,
Robbie Hatley
lonewolf aatt well dott com
www dott well dott com slant user slant lonewolf slant

[CBFalconer]

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

vippstar@gmail. com wrote:

>

.... snip ...

>
Here's a perfectly conforming C99 program
>
#include <stdio.h>
int foo(void *);
int main(void) {
const char * const p = "hello world";
foo(p);
return 0;
}
int foo(void *p) { return puts(p); }

And here is one with one less line, no requirements for exact line
equivalence, and much more understandable, especially to the
neophyte.

#include <stdio.h>

int foo(void *p) { return puts(p); }

int main(void) {
char *p = "hello world";

foo(p);
return 0;
}

I also added blank lines to separate code segments. I didn't
install 'static' qualifiers.

I thought I had eliminated all possible warning, but I got:

junk.c:6: warning: initialization discards qualifiers from pointer
target type

and I am confused. Why? gcc is run through an alias for cc:

alias cc=gcc -W -Wall -ansi -pedantic -Wwrite-strings -Wfloat-equal
-gstabs+ -ftrapv -O1

(I suspect the -Wwrite-strings param).

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home .att.net>
Try the download section.



--
Posted via a free Usenet account from http://www.teranews.com

[Default User]

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

CBFalconer wrote:

vippstar@gmail. com wrote:

... snip ...

Here's a perfectly conforming C99 program

#include <stdio.h>
int foo(void *);
int main(void) {
const char * const p = "hello world";
foo(p);
return 0;
}
int foo(void *p) { return puts(p); }

>
And here is one with one less line, no requirements for exact line
equivalence, and much more understandable, especially to the
neophyte.
>
#include <stdio.h>
>
int foo(void *p) { return puts(p); }
>
int main(void) {
char *p = "hello world";
>
foo(p);
return 0;
}
>
I also added blank lines to separate code segments. I didn't
install 'static' qualifiers.
>
I thought I had eliminated all possible warning, but I got:
>
junk.c:6: warning: initialization discards qualifiers from pointer
target type
>
and I am confused. Why? gcc is run through an alias for cc:
>
alias cc=gcc -W -Wall -ansi -pedantic -Wwrite-strings -Wfloat-equal
-gstabs+ -ftrapv -O1
>
(I suspect the -Wwrite-strings param).

I suspect you are right.

-Wwrite-strings
When compiling C, give string constants the type "const
char[length]" so that copying the address of one into a
non-"const" "char *" pointer will get a warning; when
compiling C++, warn about the deprecated conversion from
string constants to "char *". These warnings will help
you find at compile time code that can try to write into
a string constant, but only if you have been very
careful about using "const" in declarations and
prototypes. Otherwise, it will just be a nuisance; this
is why we did not make -Wall request these warnings.



Brian

[Hallvard B Furuseth]

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

Ian Collins writes:

>Hallvard B Furuseth wrote:

>The times where you do need to clutter the code with unreadable
>type casts, it may make sense to typedef the offending type.
>>

No, all the typedef dose is introduce an alias, it doesn't remove the
need to cast an inappropriate type.

Indeed. But I was talking about making such code readable, which
is what this thread is about in the first place. Like you said
in your next message in this thread:-)

If you do need to clutter the code with unreadable casts, you are
doing something smelly and should reconsider what you are doing.

Likely yes. Not always.

--
Hallvard

[Kenneth Brody]

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

Robert Smith wrote:

>
some of the syntax wasn't overloaded so much...
>
Was just musing that if pointer de-referencing and pointer-to-type had
seperate syntax (ie use a character other than '*' for one of them) it would
make things much easier to read. You wouldn't get stuff like:
>
pthread_create( &thread, NULL, (void *(*)(void*))Thr eadProc, (void
*)parameter);

Aside from what the others said, consider this:

char *p;

The use of "*" is consistent, IMO, because:

"p" is of type "char *", just like the definition says, and
"*p" is of type "char", just like the definition says.

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer .h|
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:ThisIsA SpamTrap@gmail. com>

[Keith Thompson]

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

Kenneth Brody <kenbrody@spamc op.netwrites:

Robert Smith wrote:

>some of the syntax wasn't overloaded so much...
>>
>Was just musing that if pointer de-referencing and pointer-to-type had
>seperate syntax (ie use a character other than '*' for one of them) it would
>make things much easier to read. You wouldn't get stuff like:
>>
>pthread_create (&thread, NULL, (void *(*)(void*))Thr eadProc, (void
>*)parameter) ;

>
Aside from what the others said, consider this:
>
char *p;
>
The use of "*" is consistent, IMO, because:
>
"p" is of type "char *", just like the definition says, and
"*p" is of type "char", just like the definition says.

Be careful. Your second statement, that *p is of type char, is
correct and consistent with the syntax of the declaration. The first,
that p is of type char*, is also correct, but it's not really what the
declaration *means*, at least not directly.

Consider:

char *p, q;

This says that *p is of type char (implying that p is of type char*),
but q is of type char, so p and q are of different types.

There's a school of thought that says that, in a pointer declaration,
the "*" should be adjacent to the type:

char* p;

and the declaration should be read as "p is of type char*". The above
problem is then avoided by declaring only one object per line:

char* p;
char q;

Personally, I prefer to have the code layout reflect the syntax. As a
programmer, you have to understand the syntax anyway, so I see no
point in concealing it with odd spacing.

Kenneth, I don't mean to imply that you don't understand this; my
remarks are mostly just a matter of emphasis.

--
Keith Thompson (The_Other_Keit h) <kst-u@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"