Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > would C be easier to read if...

Reply
Thread Tools

would C be easier to read if...

 
 
Robert Smith
Guest
Posts: n/a
 
      04-03-2008
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*))ThreadProc, (void
*)parameter);



 
Reply With Quote
 
 
 
 
Chris Dollin
Guest
Posts: n/a
 
      04-03-2008
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*))ThreadProc, (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

 
Reply With Quote
 
 
 
 
Hallvard B Furuseth
Guest
Posts: n/a
 
      04-03-2008
Chris Dollin writes:
>Robert Smith wrote:
>> pthread_create(&thread, NULL, (void *(*)(void*))ThreadProc, (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
 
Reply With Quote
 
Ben Bacarisse
Guest
Posts: n/a
 
      04-03-2008
"Robert Smith" <(E-Mail Removed)> writes:

> 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*))ThreadProc, (void
> *)parameter);


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

--
Ben.
 
Reply With Quote
 
vippstar@gmail.com
Guest
Posts: n/a
 
      04-03-2008
On Apr 3, 5:08 pm, Hallvard B Furuseth <(E-Mail Removed)>
wrote:
> Chris Dollin writes:
> >Robert Smith wrote:
> >> some of the syntax wasn't overloaded so much...

C is old. Back then a lot of symbols were missing from the keyboard,
thus C has a simple character set. (and alternatives such as digraphs
and trigraphs which are not that used, but some regulars claim to have
used them under certain circumstances)
I don't think adding/changing symbols would make the language simpler.
> >> pthread_create(&thread, NULL, (void *(*)(void*))ThreadProc, (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.

Even if parameter was const char * const parameter = "hello world";
the cast can still be omitted, as long as ThreadProc does not try to
mutate what is pointed to by parameter.
 
Reply With Quote
 
Hallvard B Furuseth
Guest
Posts: n/a
 
      04-03-2008
Robert Smith wrote:
> some of the syntax wasn't overloaded so much...


Overloaded symbols are a problem in C, yes. But in this case it's a
design feature that syntax for declaring a variable is the same as for
using it. As a result there is one and not two syntaxes you need to
learn in order to dig your way through a complex use of a variable.

http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:
>On Apr 3, 5:08 pm, Hallvard B Furuseth <(E-Mail Removed)> wrote:
>(...)
>>>> pthread_create(&thread, NULL, (void *(*)(void*))ThreadProc, (void
>>>> *)parameter);

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

>
> Even if parameter was const char * const parameter = "hello world";
> the cast can still be omitted, as long as ThreadProc does not try to
> mutate what is pointed to by parameter.


No. pthread_create() takes a void* 3rd parameter. It's an error
to assign or pass a "pointer to const" to a "pointer to not-const".
On the other hand the const may be cast away, and if the underlying
object was not created with 'const' type it may be mutated.

--
Hallvard
 
Reply With Quote
 
vippstar@gmail.com
Guest
Posts: n/a
 
      04-03-2008
On Apr 3, 6:17 pm, Hallvard B Furuseth <(E-Mail Removed)>
wrote:
> Robert Smith wrote:
> > some of the syntax wasn't overloaded so much...

>
> Overloaded symbols are a problem in C, yes. But in this case it's a
> design feature that syntax for declaring a variable is the same as for
> using it. As a result there is one and not two syntaxes you need to
> learn in order to dig your way through a complex use of a variable.
>
> (E-Mail Removed) wrote:
> >On Apr 3, 5:08 pm, Hallvard B Furuseth <(E-Mail Removed)> wrote:
> >(...)
> >>>> pthread_create(&thread, NULL, (void *(*)(void*))ThreadProc, (void
> >>>> *)parameter);
> >>(...)
> >> And hopefully 'parameter' is a non-const pointer so the void* cast
> >> can be dropped too.

>
> > Even if parameter was const char * const parameter = "hello world";
> > the cast can still be omitted, as long as ThreadProc does not try to
> > mutate what is pointed to by parameter.

>
> No. pthread_create() takes a void* 3rd parameter. It's an error
> to assign or pass a "pointer to const" to a "pointer to not-const".

I don't remember what the POSIX standard says about this, but in C it
is not. Ofcourse, pthread_create is not mentioned in the C99 standard,
however, what I demonstrate here is a function taking void *, and
passing to that function a const char * const. Note that this function
could be the callback to pthread_create. In pthread_create()'s manual
there is no mention of *requiring* the last argument to be modifiable.

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); }
 
Reply With Quote
 
Hallvard B Furuseth
Guest
Posts: n/a
 
      04-03-2008
(E-Mail Removed) writes:
>On Apr 3, 6:17 pm, Hallvard B Furuseth <(E-Mail Removed)> wrote:
>>> Even if parameter was const char * const parameter = "hello world";
>>> the cast can still be omitted, as long as ThreadProc does not try to
>>> mutate what is pointed to by parameter.

>>
>> No. pthread_create() takes a void* 3rd parameter. It's an error
>> to assign or pass a "pointer to const" to a "pointer to not-const".

>
> I don't remember what the POSIX standard says about this, but in C it
> is not.


You are confusing something with something. Half the purpose of the
const qualifier is that the compiler's type checking can help you catch
assignments to read-only objects.

> (...) what I demonstrate here is a function taking void *, and
> passing to that function a const char * const.


void* isn't that magical. You can pass a char* to a void* or
a const char* to a const void*. Not a const char* to a void*.

> (...) Here's a perfectly conforming C99 program (...)


I'm not up to digging through the standard at the moment, but if you
compile it with "gcc -std=c99 -pedantic-errors" and bugreport the
resulting error message, maybe they'll tell you where to find it

--
Hallvard
 
Reply With Quote
 
vippstar@gmail.com
Guest
Posts: n/a
 
      04-03-2008
On Apr 3, 6:47 pm, Hallvard B Furuseth <(E-Mail Removed)>
wrote:
> (E-Mail Removed) writes:
> >On Apr 3, 6:17 pm, Hallvard B Furuseth <(E-Mail Removed)> wrote:
> >>> Even if parameter was const char * const parameter = "hello world";
> >>> the cast can still be omitted, as long as ThreadProc does not try to
> >>> mutate what is pointed to by parameter.

>
> >> No. pthread_create() takes a void* 3rd parameter. It's an error
> >> to assign or pass a "pointer to const" to a "pointer to not-const".

>
> > I don't remember what the POSIX standard says about this, but in C it
> > is not.

>
> You are confusing something with something. Half the purpose of the
> const qualifier is that the compiler's type checking can help you catch
> assignments to read-only objects.

Well, that's *your* opinion. My opinion is that const is there for
optimization and documentation.
Ie foo(const int *) informs the programmer foo shall not modify what
is pointed to by its argument.
>
> > (...) what I demonstrate here is a function taking void *, and
> > passing to that function a const char * const.

>
> void* isn't that magical. You can pass a char* to a void* or
> a const char* to a const void*. Not a const char* to a void*.

That is not true, and it's not about void *'s "magic". You can also
assign a const char * to a char * and still have a conforming program.
Also, while thinking about it, pthread_create shouldn't be able to
access what is pointed to by its last argument. Unless POSIX says
something about it (and I'm positive it does not) then it's POSIX
conforming too.

> > (...) Here's a perfectly conforming C99 program (...)

>
> I'm not up to digging through the standard at the moment, but if you
> compile it with "gcc -std=c99 -pedantic-errors" and bugreport the
> resulting error message, maybe they'll tell you where to find it

gcc has idiotic and inaccurate warning messages [1] (which btw you
turn into diagnostic errors with -pedantic-errors)
My program is 100% conforming to C99 (and perhaps C89/POSIX too).

[1] It correctly warns/errors, however the semantics are incorrect, eg
says "statement" where "expression" should be used, et cetera.
 
Reply With Quote
 
Ben Bacarisse
Guest
Posts: n/a
 
      04-03-2008
(E-Mail Removed) writes:

> On Apr 3, 6:47 pm, Hallvard B Furuseth <(E-Mail Removed)>
> wrote:
>> (E-Mail Removed) writes:

<snip>
>> > (...) what I demonstrate here is a function taking void *, and
>> > passing to that function a const char * const.

>>
>> void* isn't that magical. You can pass a char* to a void* or
>> a const char* to a const void*. Not a const char* to a void*.


> That is not true, and it's not about void *'s "magic". You can also
> assign a const char * to a char * and still have a conforming
> program.


Only because "conforming program" is a rather loose term. A
conforming program can use non-portable features.

<snip>
>> > (...) Here's a perfectly conforming C99 program (...)


What do you mean by "perfectly conforming"? If you mean the same as
"strictly conforming", I disagree. Here is the code again:

#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); }

>> I'm not up to digging through the standard at the moment, but if you
>> compile it with "gcc -std=c99 -pedantic-errors" and bugreport the
>> resulting error message, maybe they'll tell you where to find it

> gcc has idiotic and inaccurate warning messages [1] (which btw you
> turn into diagnostic errors with -pedantic-errors)
> My program is 100% conforming to C99 (and perhaps C89/POSIX too).


Again, what is 100% conforming? It violates a constraint and thus
requires a diagnostic.

6.5.2.2 Function calls
Constraints
...
2 If the expression that denotes the called function has a type that
includes a prototype, the number of arguments shall agree with the
number of parameters. Each argument shall have a type such that its
value may be assigned to an object with the unqualified version of
the type of its corresponding parameter.

I.e. the argument, p, must have a type such that its value may be
assigned to an object of type void *. The correctness of the call is
defined in terms of the correctness of:

const char * const arg = "hello world";
void *param = arg;

So we got to:

6.5.16.1 Simple assignment
Constraints
One of the following shall hold:

— the left operand has qualified or unqualified arithmetic type and
the right has arithmetic type;

— the left operand has a qualified or unqualified version of a
structure or union type compatible with the type of the right;

— both operands are pointers to qualified or unqualified versions of
compatible types, and the type pointed to by the left has all the
qualifiers of the type pointed to by the right;

No to these three.

— one operand is a pointer to an object or incomplete type and the
other is a pointer to a qualified or unqualified version of void,
and the type pointed to by the left has all the qualifiers of the
type pointed to by the right;

No, but this is close. One (arg) is a pointer to an object and the
other (param) is a pointer to an unqualified version of void, but the
type pointed to by the left (void) does not have all the qualifiers of
the type pointed to by the right (const char).

— the left operand is a pointer and the right is a null pointer
constant; or

— the left operand has type _Bool and the right is a pointer.

No for these as well. So gcc is correct in issuing a diagnostic.

--
Ben.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
an oddball scary kind of thing you would think would never happen richard Computer Support 4 01-31-2010 06:34 PM
read a ruby script like you would read a text file Mmcolli00 Mom Ruby 2 01-27-2009 10:52 PM
Has to be an easier way? (gateway issues) Captain Cisco 13 08-28-2004 12:30 AM
Hash of Structs in a Package, is there an easier way? Norman Ackroyd Perl 1 07-28-2004 11:54 AM
Phone Validation Problem (I reformatted the code to make it easier to read) AnnMarie Javascript 8 11-21-2003 10:37 PM



Advertisments