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

[ImpalerCore]

[snip]

Something that has to be remembered (and isn't emphasized enough in
introductory materials IMO) is that C (*and* C++) declaration syntax
is expression-centric, not object-centric.  The reason we declare
pointers as "T *p" is because the type of the *expression* "*p" is
T.

Strange, but it is Stroustrup's coding style in his own book that
advocated postfix modifiers for declaring pointer and reference
variables, so the C++ part of your statement is likely not true.  

As far as the language grammar is concered, it is.  Here's a grammar
trace for a simple pointer declaration "int* p;" (taken fromhttp://www.open-std.org/jtc1/sc22/open/n2356/gram.html):

                   declaration
                        |
                 block-declaration
                        |
                simple-declaration
                   /            \
    decl-specifier-seq     init-declarator-list
              |                     |
       type-specifier          init-declarator
              |                     |
     simple-type-specifier       declarator
              |                   /    \
             int         ptr-operator declarator
                                |         |
                                *   direct-declarator
                                          |
                                     id-expression
                                          |
                                    unqualified-id
                                          |
                                      identifier
                                          |
                                          p

Thanks for the link.

The '*' operator is bound to the declarator (the trace for a reference
declaration is identical, as '&' is also a production of ptr-
operator).  I get what Stroustrup is saying, and I've done enough C++
to see where that approach makes certain things easier (particularly
in a generic container type), but unfortunately the language grammar
doesn't work that way.

I see your point now; it does make sense to declare pointer variables
according to the grammar designed for the C compiler.

In the absence of historical bias, I would still advocate that 'char*
a, b[10], c;' represent

a - char* pointer
b - an array of 10 char* pointers
c - char* pointer

It would require a grammar change to the C language that is never
going to happen. And I'll say that the internals of the compiler are
"deep magic" to me (with an engineering education background), so
unfortunately I'm not well equipped to argue one way or another which
grammar is better (and I have no idea how the above semantics change
the expression parse tree). I do wish I had a better background on
compiler and language design.

I wonder what prompted Stroustrup to use the type postfix location in
his coding style a la 'char* p' or 'int& r' if the grammar itself is
defined otherwise.

Best regards,
John D.

 

[Neville Dempsey]

int x*; // x is a pointer to int
int arr*[10]; // arr is a pointer to a 10-element array of int
int arr[10]*; // arr is a 10-element array of pointer to int
int f*(); // f is a pointer to a function returning int
int f()*; // f is a function returning a pointer to int

re: Algol 68

REF INT x; # x is a pointer to INT #
REF [10] INT arr; # arr is a pointer to a 10-element array of INT
#
[10] REF INT arr; # arr is a 10-element array of pointer to INT #
REF PROC INT f; # f is a pointer to a function returning INT #
PROC REF INT f; # f is a function returning a pointer to INT #

That looks great, and reads almost like English (better than actual Algol68
which always seems to require capitals or quoting for reserved words).

For publication types (MODEs) would normally be in bold typeface.
Neither usenet, nor ascii use typefaces, hence the use of UPPER
stropping.

The alternative is us use "quote stropping":
'ref' 'int' x; # x is a pointer to int #
'ref' [10] 'int' arr; # arr is a pointer to a 10-element array of
int #
[10] 'ref' 'int' arr; # arr is a 10-element array of pointer to
int #
'ref' 'proc' 'int' f; # f is a pointer to a function returning
int #
'proc' 'ref' 'int' f; # f is a function returning a pointer to
int #

Basically "quote stropping" is an early form of "wikitext". (It also
may make parsing simpler?)

There is also "res stropping" where reserved words are in the same
case as variables:
ref int x; # x is a pointer to int #
ref [10] int arr; # arr is a pointer to a 10-element array of int
#
[10] ref int arr; # arr is a 10-element array of pointer to int #
ref proc int f; # f is a pointer to a function returning int #
proc ref int f; # f is a function returning a pointer to int #

"res stropping" requires more complex syntax highlighting for journal
publication and is not common.

NevilleDNZ

 

[Daniel Pitts]

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.

How is that not the same thing as a while loop?

void noPast() {
while (true) {
try {
process();
return;
} catch(Exception ex) {
log(ex);
reinit();
}
}
}

I'd rather have continuations over gotos.
<http://en.wikipedia.org/wiki/Continuation-passing_style>, but I don't
think I'd like either in Java or C++, they wouldn't fit well.

 

[Tom Anderson]

How is that not the same thing as a while loop?

While loops don't include puns about noodles.

tom

 

[Ramon F Herrera]

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

I like the use of brackets to deal with relational arrays.

-RFH

 

[Martin Gregorie]

[...] I consider something spaghetti only if it's long, round, and a
bit thicker than Angel Hair.

[*] Pasta-shaped pasta, of course.

It sounds like you are suggesting the C Standard Committee to add the
"spaghetti integer" data type. Beware the oven-flows!

It's ideal for use in layered architectures. Along with plenty of ragu
and bechamel sauce.

Shirley, penne pasta is better for that.

 

[Ian Collins]

Right. I thought that might be what you meant. I used to do that but
I've gone off this style. One reason is simply a silly OCD one. I
don't like it when the explanation causes the comment to be multi-line
so I found myself mentally editing my comments to the point where they
were often ambiguous. Your "Terminating character of scan" has already
shown this effect in this thread.

I've switched to block comments. Often, these don't refer the variables
directly but instead they tell a story (in tiny pieces of course) so,
for example, I might write:

/* Scan the buffer for the first non-digit found to follow the
* exponent. The terminating null ensures there always will be
* such a character.
*/
char *cp = buffer, first_non_digit;

Or

char first_non_digit = find_first_non_digit_in( buffer );

Which should be clear enough to stand on its own without a comment.

 

[Ben Bacarisse]

Or

char first_non_digit = find_first_non_digit_in( buffer );

Which should be clear enough to stand on its own without a comment.

But that's not what my (imaginary) code does and the comment explains
that! The function should be called

find_first_non_digit_after_exponent_in

Even so, that only pushes the problem somewhere else unless it is your
contention that one should never write a function complex enough to need
a comment.

 

[Mike Schilling]

How is that not the same thing as a while loop?

While loops don't force you to use your noodle.

 

[Daniel Pitts]

While loops don't include puns about noodles.

I have two responses to that:

1. Your sentence requires too many backtracking to parse "While x
does/doesn't something, y does/doesn't" was the first parse attempt."

2. You've never had Spaghetti-Os? That is a looped noodle! Or is that an
American only kind of thing?

 

[Daniel Pitts]

While loops don't force you to use your noodle.

Yet another incomplete sentence. While they don't force you to use your
noodle, they do what?

 

[Ian Collins]

But that's not what my (imaginary) code does and the comment explains
that! The function should be called

find_first_non_digit_after_exponent_in

Ah, I didn't read and digest the comment!

Even so, that only pushes the problem somewhere else unless it is your
contention that one should never write a function complex enough to need
a comment.

I wouldn't go so far as to say "never" (although some purists do),
seldom maybe.

 

[RedGrittyBrick]

Seebs wrote:

[...] I consider something spaghetti only if it's long, round, and a
bit thicker than Angel Hair.

[*] Pasta-shaped pasta, of course.

It sounds like you are suggesting the C Standard Committee to add the
"spaghetti integer" data type. Beware the oven-flows!

It's ideal for use in layered architectures. Along with plenty of ragu
and bechamel sauce.

Shirley, penne pasta is better for that.

You guys are nuts!

It's obvious that lasagne pasta is for layered architectures.

 

[Martin Gregorie]

On Mon, 11 Oct 2010, Vincenzo Mercuri wrote:

Seebs wrote:

[...] I consider something spaghetti only if it's long, round, and a
bit thicker than Angel Hair.

[*] Pasta-shaped pasta, of course.

It sounds like you are suggesting the C Standard Committee to add the
"spaghetti integer" data type. Beware the oven-flows!

It's ideal for use in layered architectures. Along with plenty of ragu
and bechamel sauce.

Shirley, penne pasta is better for that.

You guys are nuts!

It's obvious that lasagne pasta is for layered architectures.

FYI 'penne pasta' == 'lasagna laminae' - or so a pasta recipe site said.

 

[Tom Anderson]

Yet another incomplete sentence. While they don't force you to use your
noodle, they do what?

Do-what? The do-while is rarely enough used, i hardly think we need yet
another arcane variant!

tom

 

[Jon]

You can always write a library that wraps all string-handling
functions from the standard library so that it can use a customized
string data type (i.e., struct c_string {}.

That solution has been tried many times and has been found to be
inadequate as many times as it has been tried. It can't be fixed at the
library level because it's a language level problem.

 

[Jon]

Let me try int &c in C, List<List<Foo>> in C++, or int *x; in Java.
Oh wait.
There is a not-insignificant amount of difference between C, C++, and
Java. The primary things that are really the same between the
languages is the use of curly braces for scope definition,

A good thing.

semicolon-terminated
statements,

A bad thing.

the use of `\' as an escape character,

A bad thing.

and the function
calling syntax of func(args).

A bad (for it's nebulousnousness) thing.

The latter two are common even in those
languages which are not curly-braced delimited (e.g., python), and
aren't really anything that people would complain about.

Oh, except me then.

That pretty much leaves the curly-brace-delimited and
semicolon-delimited natures as the only truly common parts of syntax
which are arguable,

Hardly scientific reasoning that you present.

and probably anyone who would be inhabiting these
newsgroups are not going to be arguing against those.
Politician.


I would like to note that many of my... issues with C++ and Java
syntaxes are of those constructs which are (more or less) unique to
those languages [1], so "they're quite similar" isn't good enough.

Name them all, don't be shy.

That sounds nice until you realize that many people on the other
newsgroups don't follow comp.lang.c, such as yours truly.

I have a feeling that syntax discussions would be less disdained in the C
group than the C++ group, though none of the "hard core"/language-lawyers
will have any of that kind of "banter".

[1] Java generics and C++ templates are sufficiently different that I
am going to call them unique constructs.

That is so high-level though that it becomes the proverbial "low-hanging
fruit" for discussion.

 

[Jon]

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

Let me try int &c in C, List<List<Foo>> in C++, or int *x; in Java.
Oh wait.

There is a not-insignificant amount of difference between C, C++, and
Java. The primary things that are really the same between the
languages is the use of curly braces for scope definition,
semicolon-terminated statements, the use of `\' as an escape
character, and the function calling syntax of func(args). The latter
two are common even in those languages which are not curly-braced
delimited (e.g., python), and aren't really anything that people
would complain about.

That pretty much leaves the curly-brace-delimited and
semicolon-delimited natures as the only truly common parts of syntax
which are arguable, and probably anyone who would be inhabiting these
newsgroups are not going to be arguing against those.

I would like to note that many of my... issues with C++ and Java
syntaxes are of those constructs which are (more or less) unique to
those languages [1], so "they're quite similar" isn't good enough.

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

That sounds nice until you realize that many people on the other
newsgroups don't follow comp.lang.c, such as yours truly.

[1] Java generics and C++ templates are sufficiently different that I
am going to call them unique constructs.

I would use = for comparison and := for assignment. You could argue
that this is lexical structure rather than syntax, but it's common to
all three languages.

I took the OP as a "wipe the slate clean" suggestion rather than "unify
all dissimilarities" one. What DID you mean OP?

 

[Jon]

I'll offer 2 cents worth:

(1) I happen to *love* C syntax. You might prefer
Pascal syntax but, at the risk of sounding rude,
why don't you just then go code in Pascal?

He said nothing of Pascal.

(2) Some will mention the second-class nature of arrays
as being bad.

Explain please "second class nature of arrays".

Some will mention the expression decay
(foo[0] becomes *foo) as being confusing. *I think these
facts result from a unique and wonderful elegance in
the C language*.

(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 &&.)

== gets grade F from me.

(4) Declarations like char* a, b, c;
are confusing: a is a pointer but b and c are not.
(It's little problem for most of us, who write instead
char *a, b, c;
)

But you wrote the same thing: that is, equally as obscure. Eliminate the
confusion:

char* a; // comment here if necessary, but don't overdo comments!
char b;
char c;

"Strong" typing is good when you are thoughtful of it. Undisciplined code
is hard to maintain, and C does little to make code regular and
maintainable.

Problem (4) seems like a problem that might afflict any
linear language which, unlike Lisp, is not fully
parenthesized.

You are defending Lisp syntax? Wow, quite bold.

Uh oh. Someone's going to have the wonderful idea of
2-D languages where editing is done with a click-based
interface to open/close syntax nodes and get a "friendly"
2D-like effect. Fortunately I won't be around to see it.

It's been around for decades for the asking/taking. "Literate
programming" touched on it. Syntax-directed text editors are only now
becoming reality after decades of such initial concepualization. And you
know (probably) some kind of point-n-click code-generating "IDE" (Aside:
Is PowerBuilder still around?).

 

[Jon]

No problem at all for those of us who declare our variables at the
point of initialisation.

That C/C++ language problem is a separate issue though.