If you could change the C or C++ or Java syntax, what would you like different?

[Ben Bacarisse]

"Ben Bacarisse" <[email protected]> wrote in message

For the record, I *like* C's declaration syntax and, left to my own
devices, I'd be very happy to declare

char buf[SIZE], *start = buf, c = *buf;

This is actually confusing; I wasn't sure what sort of pointer c was
supposed to be at first, as I read it as c = &buf..

There is always a tension between writing clear code and using the
language to it's fullest extent. However, to quote you from another
post in this thread[1]:

| I'm not a C programmer.

so I am not sure what weight to give to your confusion. It would be
wonderful if all programing languages were clear to everyone -- even
those who were not familiar with them -- but I don't think that this is
possible.

I'd be prepared to say that "mixed" declarations (declarations with
multiple forms of declarator) were considered idiomatic in "old" C. I
remember coming across the advice of having one declarator per
declaration quite late and thinking it rather odd and fussy.

Not needing to declare variables is even more compact...

True, but we are talking about C and removing declarations can't be done
in C.

If you mean you can declare arrays, pointers and single characters all
in the same statement, then I suppose it might be. But not everyone
would agree it's a good thing.

Oh sure. That's why I said "left to my own devices". I'd do it in
"house style" if I were ever to do that kind of job again.

[1] Message-ID: <[email protected]>

 

[August Karlstrom]

There is always a tension between writing clear code and using the
language to it's fullest extent.

Good point.


/August

 

[osmium]

I'd bet on a guy with "I'm gonna design a better
language and write a compiler" day dreams.

Amen to that. If someone wants a composite language we already have at
least one, PL/I.

 

[BartC]

char buf[SIZE], *start = buf, c = *buf;

This is actually confusing; I wasn't sure what sort of pointer c was
supposed to be at first, as I read it as c = &buf..

There is always a tension between writing clear code and using the
language to it's fullest extent. However, to quote you from another
post in this thread[1]:

| I'm not a C programmer.

so I am not sure what weight to give to your confusion.

It's possible to be familiar enough with a language to offer an opinion,
without being a full-time programmer in it.

(I've spent enough time trying to interface to software with APIs defined
using C code.)

That declaration just seemed to me to have a 'shape' I'd normally associate
with a c=&buf type of initialisation.

[1] Message-ID: <[email protected]>

 

[Alan Curry]

(3) That ==, etc. have precedence over & or | is annoying, but
easy to remember once you get used to it. (Ritchie explains
this is vestige of an early dialect which didn't distinguish
& and &&.)

Speaking of precedence, the shift operators are equivalent to multiplication
and division, but don't have the same precedence as multiplication and
division. That feels wrong.

And in a completely different category: switch syntax is too loose.

case should not be a goto-like label, it should be a grammatical construct
that owns the following statement, and a switch() statement should be
mandatorily followed by a block consisting solely of cases.

This will fix not only Duff's device (my answer to Duff's question is
"against!") but also the dreaded "deafult", since labels will not be allowed
in the same place where the "case" and "default" keywords are allowed.

 

[Anand Hariharan]

For the record, I *like* C's declaration syntax and, left to my own
devices, I'd be very happy to declare

  char buf[SIZE], *start = buf, c = *buf;

Assuming this was local to a function, what is the value of 'c'?
Isn't it UB to dereference buf (access buf[0]) without initialising
buf?

 

[BartC]

Speaking of precedence, the shift operators are equivalent to
multiplication
and division, but don't have the same precedence as multiplication and
division. That feels wrong.

And in a completely different category: switch syntax is too loose.

case should not be a goto-like label, it should be a grammatical construct
that owns the following statement, and a switch() statement should be
mandatorily followed by a block consisting solely of cases.

This will fix not only Duff's device (my answer to Duff's question is
"against!") but also the dreaded "deafult", since labels will not be
allowed
in the same place where the "case" and "default" keywords are allowed.

You seem to be taking this seriously..

There was a long thread along these lines, starting Mar 5 2010, called "Has
thought been given given to a cleaned up C? Possibly called C+."

My post on Mar 10 ('Mario Day') listed a whole set of improvements, which I
think included
your suggestions.

(Sorry I've no idea how to do actual links to messages)

 

[Ian Collins]

Which would be -- in the general case of first using them somewhere in
the middle of a scope block -- illegal in C89.

In fact, I like this C89 restriction. The beginning of a scope block is
also a good place to document the variables that are needed inside with
an appropriate comment.

If they have a sensible name and are declared where needed, they don't
need a descriptive comment.

I even employ this in languages that would allow
declarations anywhere, like C#.

Or modern C. Doing that must make you unpopular with your colleagues,
it certainly would on a C++ project.

 

[Ben Bacarisse]

For the record, I *like* C's declaration syntax and, left to my own
devices, I'd be very happy to declare

  char buf[SIZE], *start = buf, c = *buf;

Assuming this was local to a function, what is the value of 'c'?
Isn't it UB to dereference buf (access buf[0]) without initialising
buf?

Only if char has trap representations. Otherwise the value is
indeterminate but a valid value for the type.

However, your point stands -- it's not a good example. At file scope

char buf[SIZE], *start = buf, c = 0;

is clearer. I wanted three declarators because the original example had
three. I should have stuck with two.

 

[August Karlstrom]

Please share your oppinion on anything you do not like in the C or C++
or Java syntax (they're quite similar).

The assignment operator `=' will confuse any newcomer with a basic
knowledge of mathematics. You can only imagine how many bugs it has
caused in C and C++ when being inadvertently used as an equality
operator instead of `=='. In code comments it also makes the usage of
the mathematical `=' slightly ambiguous which forces people to use `=='
instead. UGLY is the word.

It's a shame that a left arrow is not in the (7 bit) ASCII table. IMHO
`:=' is second best to the left arrow.


/August

 

[Marcin Grzegorczyk]

For the record, I *like* C's declaration syntax and, left to my own
devices, I'd be very happy to declare

char buf[SIZE], *start = buf, c = *buf;

Assuming this was local to a function, what is the value of 'c'?
Isn't it UB to dereference buf (access buf[0]) without initialising
buf?

Only if char has trap representations.

It appears that accessing any object using type ‘char’ cannot cause UB
(6.2.6.1p5 specifically excludes all character types), regardless of the
object representation, so arguably char cannot have trap representations.

Otherwise the value is
indeterminate but a valid value for the type.

Note that this provision is specific to C99, and that C1X is restricting
it to objects that reside in memory (i.e. have a static or thread
storage duration, or have their address taken). For more information,
see DR #338 <http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_338.htm>.

 

[Ian Collins]

Count me as odd and fussy. I'm of the school that believes that
variables should have a well defined meaning and that that
meaning should be documented.

And the best way to do that is to give them a meaningful name and
declare them when they are needed. That way the use is obvious.

 

[BartC]

The assignment operator `=' will confuse any newcomer with a basic
knowledge of mathematics. You can only imagine how many bugs it has caused
in C and C++ when being inadvertently used as an equality operator instead
of `=='.

This was the biggest problem I had, when trying to code a sizeable C project
a couple of years back.

The syntax I normally used had for ":=" for assignment, and "=" for
equality.

Wrongly using ":=" in C just gave a syntax error. Wrongly using "=" in the
other languages (using my own not very robust compilers), either caused a
crash, or silently did nothing (certainly not assignment). While using "="
in C instead of "==" had it's own problems...

But, yes, the use of "=" and "==" in C I don't think were the best choices,
but they have propagated through to too many other languages now.

 

[Ben Bacarisse]

Count me as odd and fussy. I'm of the school that believes that
variables should have a well defined meaning and that that
meaning should be documented.

I agree (how could anyone not agree?) but I think I must have missed
your point because I don't see the connection with what I wrote. Would
you elaborate?

 

[Ian Collins]

Some people actually believe that.

The truth is like that.

 

[ClassCastException]

Please share your oppinion on anything you do not like in the C or C++
or Java syntax (they're quite similar).

In order to maintain the integrity of the discussion (have everything at
the same place) please respond on comp.lang.c.

Cheers,
Alexander

Ahh. <grabs popcorn> <lies back>

....

<munch, munch>

Er, where's all the action?

What, only five replies? What, nobody's even SUGGESTED operator
overloading in Java yet? Waaah, where's the flamewar!? I feel like I sat
down in the theatre to watch a Jean Claude Van Damme movie and so far it
more resembles the Ya-Ya Sisterhood of Traveling Bra-Straps III or
whatever the latest damn chick flick is called.

Okay, then, I guess it's up to me. I've got to stop lurking and take
action. A man's gotta do what a man's gotta do.

Lisp macros and first-class lambdas. In all three languages.

 

[Felix Palmen]

If they have a sensible name and are declared where needed, they don't
need a descriptive comment.


Or modern C. Doing that must make you unpopular with your colleagues,
it certainly would on a C++ project.

While descriptive names are mandatory for clear code, they can't replace
having an overview of all variables used inside a block entirely in any
case. I find code separating declarations from actual statements
generally better readable. As scope blocks should be small in /good/
code, it's admittedly not that much of a difference...

Regards,
Felix

 

[Felix Palmen]

The assignment operator `=' will confuse any newcomer with a basic
knowledge of mathematics. You can only imagine how many bugs it has
caused in C and C++ when being inadvertently used as an equality
operator instead of `=='. In code comments it also makes the usage of
the mathematical `=' slightly ambiguous which forces people to use `=='
instead. UGLY is the word.

Agreed with that. But I think the /worst/ thing in existence are
languages using the single 'equals' sign for both, assignment AND
comparison, depending on the context. (...basic...*cough*)

Regards,
Felix

 

[luser- -droog]

This was the biggest problem I had, when trying to code a sizeable C project
a couple of years back.

The syntax I normally used had for ":=" for assignment, and "=" for
equality.

Wrongly using ":=" in C just gave a syntax error. Wrongly using "=" in the
other languages (using my own not very robust compilers), either caused a
crash, or silently did nothing (certainly not assignment). While using "="
in C instead of "==" had it's own problems...

But, yes, the use of "=" and "==" in C I don't think were the best choices,
but they have propagated through to too many other languages now.

Ooo, I know!
We can replace both "=" and "==" with "is" and let the compiler
figure it out! You could give it a hint with
#pragma is_assignment
c=getchar();
#pragma is_equality_test
if (c==EOF) ...

 

[Ian Collins]

While descriptive names are mandatory for clear code, they can't replace
having an overview of all variables used inside a block entirely in any
case. I find code separating declarations from actual statements
generally better readable. As scope blocks should be small in /good/
code, it's admittedly not that much of a difference...

That is true.

One point which is often overlooked is variables (for lack of a better
name) that are constants can be declared as const if they are declared
when needed. This may be a small detail, but it does add to the self
documenting nature of the code and my help with optimisations.

I prefer not to mix calculations with comparisons, so I often assign the
result of a calculation to a const and then use it in a comparison. For
example in code dealing with power calculations I'd write

const int power = amps*volts;

if( power > 42 ) {..}

rather than

if( amps*volts > 42 ) {..}

That style isn't as clear if power had to be declared at the top of the
scope.