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

[Juha Nieminen]

What, only five replies? What, nobody's even SUGGESTED operator
overloading in Java yet?

I think the question was about *syntax*, not features. In other words,
which of the *existing* features of the language would you prefer being
able to write using a different syntax.

 

[Rui Maciel]

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.

That statement leads to believe that you delved into a "sizeable C project" without even knowing how
to program in C, which clearlly is not a problem related to the design of the C programming
language.


Rui Maciel

 

[Michael Angelo Ravera]

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.

Taking your post at face value, I'd like to see the ability to have a
sparse parameter list to a function, but this is kind of "out there".
You need first function with variable arguments and then a large
number of variable arguments and then a function that allows a large
number of arguments many of which aren't often needed, but might be
needed in any combination.

The API on an OS for which I write frequently has a function FIELINFO
with variable arguments, many of which you often don't need. If you
frequently need only either the file handle for the open file or a
filename for one that need not be open and these are the first two
nominal arguments. It would be cool not to have to count the damn
commas in the call:
FILEINFO (FNum,,,,,,,,, &rec_len); and instead to use a syntax like:
FILEINFO (fnum:FNum, lrecl:&rec_len); I picked colon because that is
how I think of it, we could just as eaily use accent grave or sharp or
dollar sign or even at sign
FILEINFO (fnum`FNum, lrecl`&rec_len);
FILEINFO (fnum$FNum, lrecl$&rec_len);
FILEINFO (fnum#FNum, lrecl#&rec_len);
FILEINFO (fnum@FNum, lrecl@&rec_len);
or even
FILEINFO (@fnum=FNum, @lrecl=&&rec_len);

using a colon seems most natural to me (equal sign would be more
natural, but things could get confusing in a hurry.)

By the way, yes there are better ways to design an API, like creating
an argument that specifies a list of the stuff that you want and an
argument into which to store the stuff that you want. In fact, that
idea was used for functions that were created later and which had more
values to return, but I will tell you that it is not any much easier
to use. Especially, if you only want 3 or 4 of the available pieces of
information returned.

 

[BartC]

If that was the biggest problem then you should not have been anyhere
NEAR a sizeable C project.

It was the biggest *practical* problem, amongst others, due to programming
in two syntaxes at once and getting the syntax muddled.

Of course there were also the usual kinds of problems of coding and getting
the thing working..

Is this some kind of sick joke going on here?

Most common languages use "=" for assignment.

"=" and ":=" are both common, but yes I believe "=" is winning out. I
happened to have used ":=" for a few decades.

And people manage just fine.

Using exclusively one syntax then it wouldn't be an issue.

 

[BartC]

The truth is like that.

So if you were to write a novel, you wouldn't bother with any content, just
give it a very, very long title?

 

[Nick Keighley]

(C) Type declaration syntax. I'm surprised no-one has mentioned this
elephant in the room.

me too!

I find it utterly impossible once I go beyond the
basics. I always need to try random combinations with CDECL until I get what
I want, then safely lock the result away until I might need it again.

use typedef (which should be called typealias) and build your complex
type out of simpler components

<snip>

 

[Nick Keighley]

Oh for goodness sake. It takes about a minute to learn what it does.

quite right

Why does an obviously intelligent person keep harping on about language
features that wont change and that are there for historical reasons?

the subject of the thread is "If you could change the C or C++ or Java
syntax, what would you like different?". If you aren't interested in
the topic then don't post to it.

:= would be a LOT worse in a language featuring ";" as a core part.

I've programmed in Algol-60, CORAL and Pascal and I noticed no
problem. Doesn't Ada do it this way as well?

Lets move on to how Z=a?b:c; is impossible for ANYONE to understand....

(I think its nice)

me too, though a lot of people don't for some reason. I've even seen a
programming standard that advised against its use. And had people
comment in code reveiws. And I don't nest them or use them in a hard
to understand manner.

 

[BartC]

Why does an obviously intelligent person keep harping on about language
features that wont change and that are there for historical reasons?

:= would be a LOT worse in a language featuring ";" as a core part.

Why?

 

[Nick Keighley]

So if you were to write a novel, you wouldn't bother with any content, just
give it a very, very long title?

a program isn't a novel. A variable name can be perfectly clear and
short. I campaign for single letter variables if their type is
sufficiently clear.

void add_block_to_queue (Queue *q, Block *b)
{
some code
}

you analogy is a strawman

 

[August Karlstrom]

Over commenting tends to be the suck blanket for the incompetent.

Comments are the *Last* thing that get updated in future maintenance
since they're invariably already wrong or make no sense. Let the code do
the talking and annotate with comments in only the most complicated
areas. Clearly each function needs a terse docstring however. Possibly
many variable declarations too.

But anyone that writes code like this:

int loopcount=0; /* the loop counter */

needs a stern lecture.

Well said. From what I have seen, overly long identifiers and
meaningless prose tends to be quite common in the Java community.


/August

 

[Rui Maciel]

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.

That is true. Yet, it must be said that what's obvious to the person writing the code may not be so
obvious to those who will have to maintain it. Therefore, it doesn't hurt to go a bit beyond
simplly attributing meaningful names to variables and using them as they are needed.


Rui Maciel

 

[Niklas Holsti]

I've programmed in Algol-60, CORAL and Pascal and I noticed no
problem. Doesn't Ada do it this way as well?

Yes, Ada uses ":=" for assignment and "=" for equality comparison. (I
like it more than the C style, but then I was trained with Algol.)

The only confusion in Ada between ':' and ';' that I have experienced
is the simple typo of ending a statement with ':' instead of ';', just
because they are adjacent on my keyboard and are hard to separate
visually in some fonts. The GNU Ada compiler (GNAT) has always diagnosed
this error correctly.

 

[geowar]

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

I really like Lua's ability to return multiple values:

m, d, y = GetBirthday("George");

(int, int, int) GetBirthday(char* inName) {
.
.
.
return (mm, dd, tttt);
}

(FYI: this isn't Lua's exact syntax (no typed variables); just a
proposed C syntax.)

 

[Felix Palmen]

I really like Lua's ability to return multiple values:

m, d, y = GetBirthday("George");

(int, int, int) GetBirthday(char* inName) {
.
.
.
return (mm, dd, tttt);
}

This would be just a shorthand for

typedef struct {
int year,
int month,
int day
} CalendarDate;

CalendarDate GetBirthday(const char *name);

The version explicitly defining the struct type is much better readable
and doesn't force you to look at the function's body to find out the
actual order of the return values just to call it.

Regards,
Felix

 

[Nick]

I really like Lua's ability to return multiple values:

m, d, y = GetBirthday("George");

(int, int, int) GetBirthday(char* inName) {
.
.
.
return (mm, dd, tttt);
}

(FYI: this isn't Lua's exact syntax (no typed variables); just a
proposed C syntax.)

And I suspect it wouldn't be that difficult to do. All you are really
doing is creating an invisible ad-hoc anonymous structure.

You could even prove the utility by a special preprocessor to convert to
something like (quoted lines as input, unquoted as output). I've
ignored the need for special prefixes for namespace reasons:

m, d, y = GetBirthday("George");

struct MAGIC_a {int p1, int p2, int p3} wk1 = GetBirthday("George");
m=wk1.p1, d=wk1.p2, y=wk1.p3;

(int, int, int) GetBirthday(char* inName) {

struct MAGIC_a GetBirthday(char *inName) {
struct MAGIC_a retval;

.
.
. ..
..
..
return (mm, dd, tttt);

return (struct MAGIC_a){p1=mm, p2=dd, p3=tttt};

}

}

I do hope I've got that literal structure right, I don't use them very
often.

You do end up creating a pile of short-lived structures in C for this
sort of thing, and for state variables passed around between functions
that take function pointers. I wonder if there is something similar
that could be done for these.

 

[Ian Collins]

Not up on our Kipling, are we.

The one who bakes exceedingly good cakes or the author?

 

[Ian Collins]

My apologies for being unclear. I dare say I was thinking of
rather more than what I actually wrote. My preferred style is to
have one declaration per line with an optional initializer, an
optional comment, and with each element of the declaration
vertically aligned. For example programmer X writes

char *b, endchar;

and I might write the same as

char *b = 0; /* Ptr to beginning of foo */
char endchar; /* Terminating character of scan */

My preference would be in the context where foo has been declared,

char* const beginning = &foo;

and to declare endchar immediately after the scan (again, as const if it
really is read only)

The thought is to create a dictionary for the scope, a dictionary
that contains the terms that are used within the scope. Like all
good dictionaries it contains definitions and is organized so
that terms are easy to find.

That does make sense but I believe "scope" should be broader than
literal C meaning of the term.

Some people might say that it looks like a lot of pointless work.
I submit that that is a specious objection. It's a modest amount
of work in the larger scheme of things and it definitely has a
point.

Some would say that it suffices to have meaningful names. Of
course it is good to have meaningful names. However yesterday's
"meaningful name" all too often is today's "what in the hell is
that".

Which is why the declaration context (or "scope') is equally important.

And then there is the person who says that we shouldn't put in
comments because the comments don't get updated when the code
changes. There is something to that. However the precise
meaning of a variable, its intent and how it is used is something
that should rarely change. Many programming disasters come about
precisely because of ill defined variables that subtly change
meaning in mid stream.

How true!

 

[Ian Collins]

The poet, "In the Neolithic Age", see
http://www.kipling.org.uk/poems_neolithic.htm

Ah-ha!

 

[Mike Schilling]

Please share your oppinion on anything you do not like in the C or C++
A construct that allows explicit transfer of control to another statement in
order to create control structures more complex than if-then-else or
while-do. Call it "past", e.g.

try
{
a:
process();
}
catch (Exception ex)
{
log(ex);
reinit();
past a; // i.e. transfer control to the statement just past the
label a
}

A method which uses this construct can be called "past a" code.

 

[Tom Anderson]

A construct that allows explicit transfer of control to another
statement in order to create control structures more complex than
if-then-else or while-do. Call it "past", e.g.

try
{
a:
process();
}
catch (Exception ex)
{
log(ex);
reinit();
past a; // i.e. transfer control to the statement just past the label a
}

A method which uses this construct can be called "past a" code.

As an entirely unrelated aside, why is it that some Americans insist on
referring to all kinds of pasta as spaghetti?

tom