If you could change the C or C++ or Java syntax, what would you like different?
Alexander
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
Stuart Golodetz
...and thus began a long, pointless and heated debate :-)
Doesn't sound like a good plan to me:
1) It will annoy the regulars in comp.lang.c with lots of off-topic
stuff about C++ and Java.
2) It won't be actionable -- if you were serious about changing the
syntax, you'd need to get on the standards committees and spend about a
decade of effort working on the details.
3) The syntax of each of the languages is different (despite a certain
amount they have in common) -- it's very hard to have a productive
discussion about three different languages at once.
If I were a betting man, I'd say you were a troll.
Regards,
Stu
Dann Corbit
e8d020...@a36g2000yqc.googlegroups.com>, alv...@gmail.com says...
If I wanted to change the features of the language, I would post to
news:comp.std.c where the design of the language is discussed.
If I were to add any feature to C, it would be a totally safe string
type, that carries its length.
But that is neither here nor there.
red floyd
Or else some guy posting his homework question.
Lew
>>> Please share your oppinion on anything you do not like in the C or C++
>>> or Java syntax (they're quite similar).
I don't like the way people start flame wars about something that doesn't
amount to a hill of beans in this world.
>>> In order to maintain the integrity of the discussion (have everything
*What* integrity?
>>> at the same place) please respond on comp.lang.c.
Stuart Golodetz wrote:
>> ...and thus began a long, pointless and heated debate :-)
>>
>> Doesn't sound like a good plan to me:
>>
>> 1) It will annoy the regulars in comp.lang.c with lots of off-topic
>> stuff about C++ and Java.
>> 2) It won't be actionable -- if you were serious about changing the
>> syntax, you'd need to get on the standards committees and spend about a
>> decade of effort working on the details.
>> 3) The syntax of each of the languages is different (despite a certain
>> amount they have in common) -- it's very hard to have a productive
>> discussion about three different languages at once.
>>
>> If I were a betting man, I'd say you were a troll.
red floyd wrote:
> Or else some guy posting his homework question.
I wouldn't bet against Stuart. The question doesn't really smell like
homework, but it reeks of troll doo-doo.
--
Lew
If you get on this discussion, you're going to regret it. Oh, not right away,
but soon and for the rest of your life.
Joshua Cranmer
> 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.
--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth
Keith H Duggar
> red floyd wrote:
> Stuart Golodetz wrote:
> > > If I were a betting man, I'd say you were a troll.
>
> I wouldn't bet against Stuart.  The question doesn't really smell like
> homework, but it reeks of troll doo-doo.
I'd bet on a guy with "I'm gonna design a better
language and write a compiler" day dreams.
KHD
James Dow Allen
> ... anything you do not like in the C ... syntax.
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? :-)
(2) Some will mention the second-class nature of arrays
as being bad. 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 &&.)
(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;
)
Problem (4) seems like a problem that might afflict any
linear language which, unlike Lisp, is not fully
parenthesized.
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. :-)
James Dow Allen
BGB / cr88192
"James Dow Allen" <jdall...@yahoo.com> wrote in message
news:9ae021aa-dc20-4dfe...@l38g2000pro.googlegroups.com...
On Oct 9, 2:09 am, Alexander <alva...@gmail.com> wrote:
> ... anything you do not like in the C ... syntax.
<--
-->
the only notable syntax alteration I would likely want to make would be be
to make the syntax non-ambiguous in the face of missing prior type
declarations (say by using a more Java or C#-like declaration syntax, as in
effectively requiring a single 'type name' which effectively terminates the
type part of a declaration, and with no modifiers which may follow it). this
is not likely to much effect the general look of the language much, or
likely even impact all that much code (except obscure cases). however,
as-is, absent typedefs the syntax is ambiguous and there is no real good
solution within the confines of the standard (it would necessarily break
standard conformance and cause some subset of otherwise conforming code to
break).
another would be to not require that, semantically, headers always behave as
if they were lexically included (although this is less certain as there are
many nifty things one can do with #if and #ifdef, and headers in general,
which could be impacted...). (as is, there are only a few scenarios in which
precompiled headers may be safely used).
possibly, less ugly function pointers (especially when returning function
pointers), but it is unclear what would be a solidly better syntax (many of
my ideas could add ambiguities, or require backtracking, which is not good).
so, alas, there is no solid way to "improve" the syntax in a general sense,
as most possible changes would also come with many costs...
or such...
Ian Collins
> On Oct 9, 2:09 am, Alexander<alva...@gmail.com> wrote:
>> ... anything you do not like in the C ... syntax.
>
> 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;
> )
No problem at all for those of us who declare our variables at the point
of initialisation.
--
Ian Collins
Ben Bacarisse
Eh? How does char* a = 0, b = 0, c = 0; make the syntax any less
error-prone? Did you mean "for those of us who declare our variables
one per declaration"?
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;
Part of the reason I like it is that it is compact. The more of the
semantically important code I can take in at once, the happier I am.
I don't recall any hard bugs being due to a mistaken declaration. I'd
imaging that most get found at the first compile. I agree that the
layout is important. I can't abide either char* a; or char * a;.
--
Ben.
Ian Collins
> Ian Collins<ian-...@hotmail.com> writes:
>
>> On 10/ 9/10 08:02 PM, James Dow Allen wrote:
>>> On Oct 9, 2:09 am, Alexander<alva...@gmail.com> wrote:
>>>> ... anything you do not like in the C ... syntax.
>>>
>>> (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;
>>> )
>>
>> No problem at all for those of us who declare our variables at the
>> point of initialisation.
>
> Eh? How does char* a = 0, b = 0, c = 0; make the syntax any less
> error-prone? Did you mean "for those of us who declare our variables
> one per declaration"?
Maybe "at the point of first use (which happens to be the point of
initialisation)" would have been clearer?
--
Ian Collins
Ian Collins
> one per declaration"?
That too!
--
Ian Collins
BartC
news:0.d8d18d98b65e37458b9e.2010...@bsb.me.uk...
> Ian Collins <ian-...@hotmail.com> writes:
>> No problem at all for those of us who declare our variables at the
>> point of initialisation.
>
> Eh? How does char* a = 0, b = 0, c = 0; make the syntax any less
> error-prone? Did you mean "for those of us who declare our variables
> one per declaration"?
Perhaps he means at the point of first use. Although this doesn't help much
here:
fn(&a);
where fn is expected to initialise a which has not yet been declared.
> 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..
> Part of the reason I like it is that it is compact.
Not needing to declare variables is even more compact...
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.
--
Bartc
Rui Maciel
> If I were to add any feature to C, it would be a totally safe string
> type, that carries its length.
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 {};). No matter how you cut
it, the solution to that issue (which isn't necessarily a problem) will always assume that form.
Rui Maciel
BartC
news:9ae021aa-dc20-4dfe...@l38g2000pro.googlegroups.com...
>> ... anything you do not like in the C ... syntax.
>
> 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? :-)
The languages don't do the same thing. Some people want to have the same
coding freedom C provides, but with a different, perhaps more formal,
syntax.
I'm not a C programmer. But from attempting to compile other people's open
source projects, it seems to me that a C programmer needs to know 4
languages:
(A) The C syntax itself
(B) The preprocessor language, which at first looks ultra-simple, just a few
#-directives, until you start using macros. This can lead to code which is
no longer C, and horrendous to decipher if you are not the author.
(C) Type declaration syntax. I'm surprised no-one has mentioned this
elephant in the room. 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.
(D) Make-file syntax. If you're trying to build an application, and no other
instructions exist to assemble the project, then you're at the mercy of this
syntax. Especially if the make-syntax is not compatible with your compiler,
or you need to make changes.
Taken all together, the whole thing can look a mess to anyone who doesn't
deal with this every day and who thinks nothing of it.
These comments apply to C. For C++, you can probably add (E) and (F). In
other words, a nightmare.
Java I don't know anything about; I understand it's big (having once spent
ages downloading a 28MB version (as 20 chunks at 9.6Kbaud), then finding I
needed another 20MB to download the docs before I could do anything).
--
Bartc
Felix Palmen
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. I even employ this in languages that would allow
declarations anywhere, like C#.
Regards,
Felix
--
Felix Palmen (Zirias) + [PGP] Felix Palmen <fe...@palmen-it.de>
web: http://palmen-it.de/ | http://palmen-it.de/pub.txt
my open source projects: | Fingerprint: ED9B 62D0 BE39 32F9 2488
http://palmen-it.de/?pg=pro + 5D0C 8177 9D80 5ECF F683
Felix Palmen
> Doesn't stop it being rubbish syntax. Along with the crap preprocessor
> it was one of the irritations I endured when first writing in C. It
> makes no sense that when I think I'm declaring a char, it turns out that
> some of the things I'm declaring are not, in fact, chars, but rather
> pointers to char (or, possibly, far worse).
Well, I have to admit it surprised me, too, because I first looked at C
after programming some object pascal, so I was used to the concept that
the attribute "pointer" applies to the type. But I think the C point of
view, that the notion of a type only relates to the stored data and the
attribute "pointer" instead applies to the individual variable, is
equally valid.
Ben Bacarisse
I'm not sure. If the following line is
while (a[b] != c) ...
then the "point of first use" is the declaration I wrote. Similarly, if
you need:
char buf[SIZE], *start = buf, c = *start;
I can't think of a form that is closer to declaring them at "the point
of first use" than this! I accept that some people don't like this
form, but I don't think it's related to initialising things just prior
to use.
--
Ben.
Ben Bacarisse
> "Ben Bacarisse" <ben.u...@bsb.me.uk> wrote in message
<snip>
>> 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.
>> Part of the reason I like it is that it is compact.
>
> 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: <i8phfl$5s4$1...@news.eternal-september.org>
--
Ben.
August Karlstrom
> There is always a tension between writing clear code and using the
> language to it's fullest extent.
Good point.
/August
--
The competent programmer is fully aware of the limited size of his own
skull. He therefore approaches his task with full humility, and avoids
clever tricks like the plague. --Edsger Dijkstra
osmium
> On Oct 8, 6:26Ź?pm, Lew <no...@lewscanon.com> wrote:
>> red floyd wrote:
>> Stuart Golodetz wrote:
>>>> If I were a betting man, I'd say you were a troll.
>>> Or else some guy posting his homework question.
>>
>> I wouldn't bet against Stuart. Ź?The question doesn't really smell
>> like homework, but it reeks of troll doo-doo.
>
> 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
"Ben Bacarisse" <ben.u...@bsb.me.uk> wrote in message
news:0.1f7a73555a7d9103805e.2010...@bsb.me.uk...
> "BartC" <b...@freeuk.com> writes:
>> "Ben Bacarisse" <ben.u...@bsb.me.uk> wrote in message
>>> 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: <i8phfl$5s4$1...@news.eternal-september.org>
--
Bartc
Alan Curry
James Dow Allen <jdall...@yahoo.com> wrote:
>On Oct 9, 2:09 am, Alexander <alva...@gmail.com> wrote:
>
>(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.
--
Alan Curry
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
"Alan Curry" <pac...@kosh.dhis.org> wrote in message
news:i8qbp9$9i$1...@speranza.aioe.org...
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)
--
Bartc
Ian Collins
> * Ian Collins<ian-...@hotmail.com>:
>> On 10/ 9/10 11:12 PM, Ben Bacarisse wrote:
>>> Ian Collins<ian-...@hotmail.com> writes:
>>>> No problem at all for those of us who declare our variables at the
>>>> point of initialisation.
>>>
>>> Eh? How does char* a = 0, b = 0, c = 0; make the syntax any less
>>> error-prone? Did you mean "for those of us who declare our variables
>>> one per declaration"?
>>
>> Maybe "at the point of first use (which happens to be the point of
>> initialisation)" would have been clearer?
>
> 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.
--
Ian Collins
Ben Bacarisse
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.
--
Ben.
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.
Richard Harter
That's not much of a recommendation for C++.
Marcin Grzegorczyk
> Anand Hariharan <mailto.anan...@gmail.com> writes:
>
>> On Oct 9, 5:12 am, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>> (...)
>>> 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>.
--
Marcin Grzegorczyk
Richard Harter
<ben.u...@bsb.me.uk> wrote:
>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.
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.
Comments!? We don't need no steenking comments!
Ian Collins
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.
--
Ian Collins
BartC
"August Karlstrom" <fusio...@gmail.com> wrote in message
news:i8qsd9$ihp$1...@speranza.aioe.org...
> On 2010-10-08 21:09, Alexander wrote:
>> 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 `=='.
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.
--
Bartc
Ben Bacarisse
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?
> Comments!? We don't need no steenking comments!
--
Ben.
Richard
> On 2010-10-08 21:09, Alexander wrote:
>> 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
Oh for goodness sake. It takes about a minute to learn what it does.
Yes there are bugs, but generally from typos or idiots.
Lets not go on and on and on about language features that might confuse
new programmers.
What next? Stop using "*p" in case someone thinks we are multiplying
the previous char in the code text by p?
> 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
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.
Lets move on to how Z=a?b:c; is impossible for ANYONE to understand....
(I think its nice)
--
"Avoid hyperbole at all costs, its the most destructive argument on
the planet" - Mark McIntyre in comp.lang.c
Richard
> "August Karlstrom" <fusio...@gmail.com> wrote in message
> news:i8qsd9$ihp$1...@speranza.aioe.org...
>> On 2010-10-08 21:09, Alexander wrote:
>>> 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 `=='.
>
> This was the biggest problem I had, when trying to code a sizeable C project
> a couple of years back.
If that was the biggest problem then you should not have been anyhere
NEAR a sizeable C project.
>
> The syntax I normally used had for ":=" for assignment, and "=" for
> equality.
So what?
>
> 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...
Yes, yes, yes. Its been one of the earliest things to learn for ANY C
programmer. its normally covered in lesson 0.001a and people get it
after about 2 seconds.
>
> 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.
Is this some kind of sick joke going on here?
Most common languages use "=" for assignment.
And people manage just fine.
Richard
Indeed.
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.
Richard Harter
Some people actually believe that.
Ian Collins
The truth is like that.
--
Ian Collins
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
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...
luser- -droog
> "August Karlstrom" <fusionf...@gmail.com> wrote in message
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) ...
--
imagine i'm emphatically raising my eyebrows.
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*)
Ian Collins
> * Ian Collins<ian-...@hotmail.com>:
>> On 10/10/10 01:28 AM, Felix Palmen wrote:
>>> 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.
>
> 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.
--
Ian Collins
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).
>
> 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
news:i8r4ne$pd6$4...@news.eternal-september.org...
> "BartC" <b...@freeuk.com> writes:
>
>> "August Karlstrom" <fusio...@gmail.com> wrote in message
>> news:i8qsd9$ihp$1...@speranza.aioe.org...
>>> On 2010-10-08 21:09, Alexander wrote:
>>>> 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 `=='.
>>
>> This was the biggest problem I had, when trying to code a sizeable C
>> project
>> a couple of years back.
>
> 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..
>> 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.
>
> 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
BartC
news:8hcqju...@mid.individual.net...
So if you were to write a novel, you wouldn't bother with any content, just
give it a very, very long title?
--
Bartc
Nick Keighley
<snip>
> (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
> >news:i8qsd9$ihp$1...@speranza.aioe.org...
<snip>
> >> 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.
>
> If that was the biggest problem then you should not have been anyhere
> NEAR a sizeable C project.
>
> > The syntax I normally used had for ":=" for assignment, and "=" for
> > equality.
>
> So what?
so his coding auto-pilot needed re-programming
> > 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...
>
> Yes, yes, yes. Its been one of the earliest things to learn for ANY C
> programmer. its normally covered in lesson 0.001a and people get it
> after about 2 seconds.
no. I was still slipping up months into learning C. I even went
through a phase of occaisionally using == for assignment! And learning
a Lisp-like language has caused me to start writing for loops in C
like so
(for i
and then a mental alarm goes off. Switching syntaxi can cause an
initial confusion. I'm happy it doesn't cause you one.
> > 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.
>
> Is this some kind of sick joke going on here?
>
> Most common languages use "=" for assignment.
yes, because they copied it from C
Nick Keighley
<snip>
> > 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
>
> Oh for goodness sake. It takes about a minute to learn what it does.
quite right
<snip>
> > It's a shame that a left arrow is not in the (7 bit) ASCII table. IMHO
> > `:=' is second best to the left arrow.
>
> 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?
--
Bartc
Nick Keighley
> "Ian Collins" <ian-n...@hotmail.com> wrote in message
>
> news:8hcqju...@mid.individual.net...
>
>
>
>
>
> > On 10/10/10 03:46 PM, Richard Harter wrote:
> >> On Sun, 10 Oct 2010 12:27:26 +1300, Ian Collins
>
> >>> On 10/10/10 12:15 PM, Richard Harter wrote:
> >>>> On Sat, 09 Oct 2010 16:35:36 +0100, Ben Bacarisse
> >>>> <ben.use...@bsb.me.uk> wrote:
>
> >>>>> 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.
>
> >>>> 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.
>
> >> Some people actually believe that.
>
> > 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?
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
Richard
I agree with you. If someone argues that i is not "clear" in
for(int i=0;i<n;i++){
doSomething(MyGlobs[i]);
}
then they should get another life.
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
--
The competent programmer is fully aware of the limited size of his own
skull. He therefore approaches his task with full humility, and avoids
clever tricks like the plague. --Edsger Dijkstra
Richard
> On 2010-10-10 03:29, Richard wrote:
>> 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
Big time. Java is a mess.
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
> On 10 Oct, 02:24, Richard <rgrd...@gmail.com> wrote:
>> := 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?
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.
--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
. @ .
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.
Nick
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.
--
Online waterways route planner | http://canalplan.eu
Plan trips, see photos, check facilities | http://canalplan.org.uk
robert...@yahoo.com
wrote:
Fortran maybe. Use of "=" for assignment was common far before C.
But I don't think that the issue is really "=" vs. "==" as being
confusing as to purpose. I don't think the two operators confuses
anyone beside some newcomers to the language, and even them only for a
few minutes. Rather the problem is that C doesn't have an assignment
*statement* in the sense that most languages do, rather it has an
assignment *operator*. Thus in most languages you cannot accidentally
use the wrong operator - and many languages use that context to
overload the same "operator." So if Pascal had used "=" for
assignment and "==" for the equality test, it wouldn't be much of an
issue, since the misuse would never get past the compiler.
In the case of C, swapping the operators very often results in valid
(but wrong) code. And the similarity of the two operators at that
point exacerbates the problem, particularly making typos excessively
likely. At least most compilers warn about finding assignment
operators in certain unlikely places.
Richard Harter
<ben.u...@bsb.me.uk> wrote:
>c...@tiac.net (Richard Harter) writes:
>
>> On Sat, 09 Oct 2010 16:35:36 +0100, Ben Bacarisse
>> <ben.u...@bsb.me.uk> wrote:
>>
>>>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.
>>
>> 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?
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 */
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.
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".
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.
A nice feature of a dictionary is that it is easy to find
definitions, particularly if you alphabetize the entries. Some
say that that isn't needed because their whiz bang editor will
jump to the definition with a key stroke. So it will as long as
our hero is within the cocoon of his favorite computing
environment and has his whiz bang editor at hand.
A counter argument is that definition should be next to first
use, e.g., for(int i=0...). The thought is that this is
convenient and that it makes it obvious what i is without having
to search for a declaration elsewhere. Good arguments. On the
other side, suppose that you have half a dozen or more of these
declarations in a function and it dawns on you they should have
been declared long. Better get them all.
Now I don't suppose I'm going to convince anyone - programmers
often think that their favorite way of doing things is the only
right and proper way to do things. The truth is that style
doesn't matter that much if you have small functions and modest
sized files. The sad truth is that bloated files and functions
that sprawl across many screens/pages are pervasive.
Richard Harter
<ian-...@hotmail.com> wrote:
>On 10/10/10 03:46 PM, Richard Harter wrote:
>> On Sun, 10 Oct 2010 12:27:26 +1300, Ian Collins
>> <ian-...@hotmail.com> wrote:
>>
>>> On 10/10/10 12:15 PM, Richard Harter wrote:
>>>> On Sat, 09 Oct 2010 16:35:36 +0100, Ben Bacarisse
>>>> <ben.u...@bsb.me.uk> wrote:
>>>>
>>>>
>>>>> 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.
>>>>
>>>> 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.
>>
>> Some people actually believe that.
>
>The truth is like that.
Not up on our Kipling, are we.
Richard
You did nothing but take up more real estate. call it terminateChar and
its self commented.
>
> 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.
To do what? To generate a lot of hot air it seems.
>
> Some would say that it suffices to have meaningful names. Of
It does.
> course it is good to have meaningful names. However yesterday's
More than that.
> "meaningful name" all too often is today's "what in the hell is
> that".
Then they werent meaningful names. or they were and the programmer was
too lazy to rename them when their usage changed. comments wont change
that. neither will a variable called z that is in fact a pointer to a
strcpy function. nor will reams of hot air known as "comments".
>
> 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
No one said that. What was said that excessive commenting is not good as
excessive comments are frequently unnecessary and left to rot.
> meaning of a variable, its intent and how it is used is something
> that should rarely change. Many programming disasters come about
exactly.
> precisely because of ill defined variables that subtly change
> meaning in mid stream.
More come from blowhards over engineering everything and confusing the
hell out of people.
>
> A nice feature of a dictionary is that it is easy to find
> definitions, particularly if you alphabetize the entries. Some
Dictionary?!?!? Alphabetize? Did you never hear of local definitions?
> say that that isn't needed because their whiz bang editor will
> jump to the definition with a key stroke. So it will as long as
> our hero is within the cocoon of his favorite computing
> environment and has his whiz bang editor at hand.
Seriously, what the hell are you talking about?
>
> A counter argument is that definition should be next to first
> use, e.g., for(int i=0...). The thought is that this is
It should. For a good reason.
> convenient and that it makes it obvious what i is without having
> to search for a declaration elsewhere. Good arguments. On the
And proven in millions of lines of code.
> other side, suppose that you have half a dozen or more of these
> declarations in a function and it dawns on you they should have
> been declared long. Better get them all.
Huh? What are you talking about? You use the local one. if scoping is
now up there with i++ for debate as being confusing then you're in the
wrong job.
> Now I don't suppose I'm going to convince anyone - programmers
> often think that their favorite way of doing things is the only
> right and proper way to do things. The truth is that style
> doesn't matter that much if you have small functions and modest
> sized files. The sad truth is that bloated files and functions
Nonsense. consistency across large code bases is important. That IS a
style.
> that sprawl across many screens/pages are pervasive.
And will be more so if anyone pays any attention to your recommendations
which I disagree with pretty much 100%.
Richard Harter
I expect that C got it from Fortran.
Ian Collins
The one who bakes exceedingly good cakes or the author?
--
Ian Collins
Ian Collins
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
Patrick May
> On Fri, 08 Oct 2010 12:09:19 -0700, Alexander wrote:
>> Please share your oppinion on anything you do not like in the C or C++
>> or Java syntax (they're quite similar).
>>
>> the same place) please respond on comp.lang.c.
>
> ...
>
> <munch, munch>
>
> Er, where's all the action?
>
> What, only five replies? What, nobody's even SUGGESTED operator
> 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.
Hear, hear! Let's get C++ and Java out of the playpen!
Patrick
------------------------------------------------------------------------
http://www.softwarematters.org
Large scale, mission-critical, distributed OO systems design and
implementation. (C++, Java, Common Lisp, Jini, middleware, SOA)
Richard Harter
<ian-...@hotmail.com> wrote:
The poet, "In the Neolithic Age", see
http://www.kipling.org.uk/poems_neolithic.htm
However the cakes are very good also.
Richard Harter
wrote:
The usual. Please get a life beyond the boundaries of your
cubicle and your narrow working environment. Not only will you
be happier for it, you may become less of a twit.
Ian Collins
Ah-ha!
--
Ian Collins
Richard Harter
And if there are several possible foos?
>
>and to declare endchar immediately after the scan (again, as const if it
>really is read only)
Oops, here we have the usual ambiguities of natural language. To
me "terminating character" means the character whose presence
terminates the scan. To you it seemingly meant the terminal
character of the scanned portion of foo. The terminating
character must be defined in advance; the terminal character does
not.
>
>> 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.
Agreed.
>
>> 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.
True.
>
>> 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!
Been there, done that, don't want to do it again.
Mike Schilling
>>> 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.
>> Ahh. <grabs popcorn> <lies back>
>>
>> Lisp macros and first-class lambdas. In all three languages.
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.
Patricia Shanahan
Hmmm. This seems to carry a risk of coming close to arbitrary goto, and
hiding a loop.
I would code it with an explicit loop as:
boolean done = false;
while(!done)
{
try
{
process();
done = true;
}
catch (Exception ex)
{
log(ex);
reinit();
}
}
In practice, I would also put a limit on the number of retries, and take
more drastic action if it is exceeded.
Anyone have a smoother idiom for this one?
Patricia
Patrick May
> Mike Schilling wrote:
>>>>> 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.
>>>> Ahh. <grabs popcorn> <lies back>
>>
>>>>
>>>> Lisp macros and first-class lambdas. In all three languages.
>>
>> 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.
>
> Hmmm. This seems to carry a risk of coming close to arbitrary goto, and
> hiding a loop.
>
> I would code it with an explicit loop as:
>
> Anyone have a smoother idiom for this one?
I believe Mr. Schilling was applying the "tongue in cheek" idiom.
Regards,
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
--
... and the children still cry "Make mine a 99"
Lew
> As an entirely unrelated aside, why is it that some Americans insist on
> referring to all kinds of pasta as spaghetti?
For the same reason they call DVDs "tapes" and they "dial" pushbutton phones?
Metonymy, historicity,
not-giving-a-hoot-about-the-difference-between-rotini-and-farfalle-y?
--
Lew
Joshua Cranmer
> 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.
Don't worry, with BGGA closures, you could probably implement this.
In all seriousness, being able to continue execution from certain
exceptions (like smalltalk's exceptions can do) would be helpful at
times. I can't think of any instances where I wanted to do this off the
top of my head, though.
--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth
Roedy Green
wrote, quoted or indirectly quoted someone who said :
>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.
see http://mindprod.com/jgloss/bali.html
--
Roedy Green Canadian Mind Products
http://mindprod.com
You encapsulate not just to save typing, but more importantly, to make it easy and safe to change the code later, since you then need change the logic in only one place. Without it, you might fail to change the logic in all the places it occurs.
Mike Schilling
"Joshua Cranmer" <Pidg...@verizon.invalid> wrote in message
news:i8uucc$kpd$1...@news-int2.gatech.edu...
> On 10/11/2010 02:18 AM, Mike Schilling wrote:
>> 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.
>
> Don't worry, with BGGA closures, you could probably implement this.
>
> In all seriousness, being able to continue execution from certain
> exceptions (like smalltalk's exceptions can do) would be helpful at times.
> I can't think of any instances where I wanted to do this off the top of my
> head, though.
In _The Design and Evolution of C++_, Stroustrup makes almost exactly this
point. Some exception-handling systems, like VMS's, provided this ability,
but few people used it, and those who did often later removed it as
error-prone. which is why he didn't include it in C++.
ImpalerCore
> On Oct 9, 2:09 am, Alexander <alva...@gmail.com> wrote:
>
> > ... anything you do not like in the C ... syntax.
<snip>
> (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;
> )
>
> Problem (4) seems like a problem that might afflict any
> linear language which, unlike Lisp, is not fully
> parenthesized.
For me personally, I still don't like the syntax of having to
associate a pointer type modifier next to the variable declaration.
For me, the difference between char and char* is a difference in type,
and should be reflected in the type portion of the declaration, not a
property of the variable name. I would prefer that 'char* a, b, c;'
declare three char* pointers and just not allow mixed pointer and
regular type declarations on a single line.
Even now, I still declare char pointers using 'char* p' (which I used
coming from a C++ background), and use single line declaration for
each pointer variable. It's probably the most contentious difference
in style that I have with other C coders.
Tom Anderson
Stroustrup *didn't* include something in C++ because it was error-prone?
Was he having an off day or something?
Tom
--
It is big (I didn't realise how big 17" is) -- Martin
Seebs
> As an entirely unrelated aside, why is it that some Americans insist on
> referring to all kinds of pasta as spaghetti?
I have no idea. The generic term I use for pasta is "metalini"*, I consider
something spaghetti only if it's long, round, and a bit thicker than Angel
Hair.
-s
[*] Pasta-shaped pasta, of course.
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
Jim Janney
> On 10/08/2010 03:09 PM, Alexander wrote:
>> 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.
--
Jim Janney
Vincenzo Mercuri
> [...] I consider
> something spaghetti only if it's long, round, and a bit thicker than Angel
> Hair.
>
> -s
> [*] 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! :-)
--
Non puoi insegnare qualcosa ad un uomo. You cannot teach a man anything.
Lo puoi solo aiutare -- Galileo Galilei -- You can only help him
a scoprirla dentro di sé. discover it in himself.
Vincenzo Mercuri
Jorgen Grahn
Read the book. He describes his (and others') way of reasoning and the
massive field experience he collected in order to make a decision.
And your sarcasm falls flat compared to it.
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
John Bode
> On Oct 9, 3:02 am, James Dow Allen <jdallen2...@yahoo.com> wrote:
>
> > On Oct 9, 2:09 am, Alexander <alva...@gmail.com> wrote:
>
> > > ... anything you do not like in the C ... syntax.
>
> <snip>
>
> > (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;
> > )
>
> > Problem (4) seems like a problem that might afflict any
> > linear language which, unlike Lisp, is not fully
> > parenthesized.
>
> For me personally, I still don't like the syntax of having to
> associate a pointer type modifier next to the variable declaration.
> For me, the difference between char and char* is a difference in type,
> and should be reflected in the type portion of the declaration, not a
> property of the variable name. I would prefer that 'char* a, b, c;'
> declare three char* pointers and just not allow mixed pointer and
> regular type declarations on a single line.
Do you feel the same way about array or function declarators? After
all, you're doing the same thing; applying the type modifier to the
variable name, not the type specifier. It may feel more natural
because the "[]" and "()" operators are postfix and there's no
confusion about whether they should be associated with the declarator
or the type specifier, but it's the exact same issue.
Then you have complex declarations like
int *(*(*f)())[10];
which could not be written as compactly if the dereference operator
was bound to the type specifier as opposed to the declarator (whether
that's a good or bad thing in itself is an open question).
If the dereference operator were made postfix, this whole issue would
go away. And if it were postfix, it would have the same precedence as
"[]", "()", ".", and "->", so you could use operator position to
distinguish between "array of pointer" and "pointer to array", rather
than having to use parentheses to do the grouping:
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
Our complex declaration above could be rewritten as
int f*()*[10]*;
which reads pretty easily as "f is a pointer to a function returning a
pointer to a 10-element array of pointer to int".
Of course, this change would probably create as many (if not more)
problems than it solves.
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.
Topic: the only truly unfortunate aspect of C's design is the use of
"=" for assignment and "==" for equality, and that's a lexical issue
rather than syntax. If only the assignment operator had been ":=" or
something similarly unlike the equality operator, then a whole class
of bugs would never have existed.
ClassCastException
> In comp.lang.c++ ClassCastException <zjkg3...@gmail.invalid> wrote:
>> 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.
Closures and semi-anonymous lambdas are an existing feature of Java, if
you abuse some syntactic salt, such as anonymous inner classes:
public interface IntInt {
int foo (int x);
}
/**
* Returns an IntInt that computes the same function as f, but adds amt
* to the output; e.g. if f returns its input return adds amt to its input
* and if f doubles its input return doubles and adds amt.
*/
public class FooExample {
public IntInt addUp (final IntInt f, final int amt) {
return new IntInt () {
public int foo (int x) {
return f.foo(x) + amt;
}
}
}
}
(WARNING: untested code)
Functional programming idioms can be used in Java but presently are
extremely ugly. Compare Scheme-style:
(defun add-up (f amt) (
(lambda (x) (+ amt (f x)))))
Two lines of code, no interface or types, no syntactic salt. Less compile
time type safety though, and you might not care for prefix instead of
infix arithmetic. :-)
It's even possible to get a Smalltalkesque return-from-calling-method
capability by abusing RuntimeException, and a Smalltalkesque ability to
do other nonfunctional idioms within closures by passing in and out one-
element arrays or other mutable boxes instead of values.
As for macros, C and C++ have an existing, weak and unsafe macro
facility. Gensyms would go a long way toward addressing the latter. C++
templates provide more of the power of Lisp macros, especially combined
with C++ macros in some cases, but still, clunkier and less safe.
Superior syntax around certain use-cases of templates, and the addition
of a syntax for an anonymous local functor (an implicit local class
declaration and instantiation, implementing the () operator and able to
use variables in the lexically enclosing scope) would go a long way in C+
+.
John Bode
Damn you Harter for making me agree with Just Richard, but he's got
some good points here.
[snip]
> > Some would say that it suffices to have meaningful names. Of
>
> It does.
>
> > course it is good to have meaningful names. However yesterday's
>
> More than that.
>
> > "meaningful name" all too often is today's "what in the hell is
> > that".
>
> Then they werent meaningful names. or they were and the programmer was
> too lazy to rename them when their usage changed.
[snip]
A truly meaningful name may no longer be *valid* for a particular
context, but its original usage should still be clear from the name.
It shouldn't suddenly become totally meaningless.
>
> > 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
>
> No one said that. What was said that excessive commenting is not good as
> excessive comments are frequently unnecessary and left to rot.
>
Agreed. Inline comments should be kept to a minimum.
> > meaning of a variable, its intent and how it is used is something
> > that should rarely change. Many programming disasters come about
>
> exactly.
>
> > precisely because of ill defined variables that subtly change
> > meaning in mid stream.
>
Which implies a problem in the *process*, not the code. Fix the
process, and those kinds of problems...well, they don't go away, but
they do become more manageable.
>
> > A nice feature of a dictionary is that it is easy to find
> > definitions, particularly if you alphabetize the entries. Some
>
> Dictionary?!?!? Alphabetize? Did you never hear of local definitions?
>
If you need a dictionary, you're doing it wrong.
> > say that that isn't needed because their whiz bang editor will
> > jump to the definition with a key stroke. So it will as long as
> > our hero is within the cocoon of his favorite computing
> > environment and has his whiz bang editor at hand.
>
> Seriously, what the hell are you talking about?
>
>
>
> > A counter argument is that definition should be next to first
> > use, e.g., for(int i=0...). The thought is that this is
>
> It should. For a good reason.
>
> > convenient and that it makes it obvious what i is without having
> > to search for a declaration elsewhere. Good arguments. On the
>
> And proven in millions of lines of code.
>
> > other side, suppose that you have half a dozen or more of these
> > declarations in a function and it dawns on you they should have
> > been declared long. Better get them all.
>
> Huh? What are you talking about? You use the local one. if scoping is
> now up there with i++ for debate as being confusing then you're in the
> wrong job.
It *is* a contrived argument; one of the benefits of keeping
declaration close to usage is that it reduces precisely those kinds of
"oops" moments.
>
> > Now I don't suppose I'm going to convince anyone - programmers
> > often think that their favorite way of doing things is the only
> > right and proper way to do things. The truth is that style
> > doesn't matter that much if you have small functions and modest
> > sized files. The sad truth is that bloated files and functions
>
> Nonsense. consistency across large code bases is important. That IS a
> style.
>
> > that sprawl across many screens/pages are pervasive.
>
My experience runs somewhat counter to yours.
Sir Placenta teh Brave
> Please share your oppinion on anything you do not like in the C or C++
> or Java syntax (they're quite similar).
>
> at the same place) please respond on comp.lang.c.
>
> Alexander
Java, like C/C++? Lol! Java is shite. Once, I read a book on Java, and
within 5 minutes, I had gotten bored. I'm thinking of sticking it in a
bonfire.
--
I'm not a fan of soap operas...unless you're talking about
alt.suicide.holiday.
Official 2010 winner of the "super mega evil luciferian doo doo head
award" from Lisa Ruby.
Previously known as "zx386," but recently given the title "Sir Placenta
the Brave."
BartC
"John Bode" <jfbod...@gmail.com> wrote in message
news:4f1c9d33-7b96-4890...@d17g2000yqm.googlegroups.com...
> On Oct 11, 9:33 am, ImpalerCore <jadil...@gmail.com> wrote:
> Then you have complex declarations like
>
> int *(*(*f)())[10];
>
> which could not be written as compactly if the dereference operator
> was bound to the type specifier as opposed to the declarator (whether
> that's a good or bad thing in itself is an open question).
>
> If the dereference operator were made postfix, this whole issue would
> go away. And if it were postfix, it would have the same precedence as
> "[]", "()", ".", and "->", so you could use operator position to
> distinguish between "array of pointer" and "pointer to array", rather
> than having to use parentheses to do the grouping:
>
> 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
>
> Our complex declaration above could be rewritten as
>
> int f*()*[10]*;
>
> which reads pretty easily as "f is a pointer to a function returning a
> pointer to a 10-element array of pointer to int".
Not as easily as the English; and the name is still in the middle instead of
at either end. And the "int" specifier, although dominant, is actually a
minor part of the type spec (after the first pointer is dereferenced, the
function called, the result [dereferenced and] indexed, and dereferenced yet
again, *then* you have the int result).
In fact, why *not* allow the declaration to be in English, since no-one is
going to agree on any new compact syntax? Eg.
declare f "pointer to function returning a pointer to a (10) element array
of pointer to int";
where "to", "returning", "a", "element", "array", and "of" are optional.
> Topic: the only truly unfortunate aspect of C's design is the use of
> "=" for assignment and "==" for equality, and that's a lexical issue
> rather than syntax. If only the assignment operator had been ":=" or
> something similarly unlike the equality operator, then a whole class
> of bugs would never have existed.
Actually I think ":=" can still be introduced to C, and be used as an
alternative to "=".
This won't immediately solve the "="/"==" problem, but if I was writing
":="/"==" all the time, then I think a lone "=" would stand out.
--
Bartc
Ben Bacarisse
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;
<snip>
--
Ben.
Ben Bacarisse
<snip>
> If the dereference operator were made postfix, this whole issue would
> go away. And if it were postfix, it would have the same precedence as
> "[]", "()", ".", and "->", so you could use operator position to
> distinguish between "array of pointer" and "pointer to array", rather
> than having to use parentheses to do the grouping:
>
> 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
The issue does not quite go away. There is still the matter of type
qualifiers -- do they still attach to the "base type" or do they, too,
follow the variable. When you include these as post-fix modifiers it
may strike you that you could do the same with the base type as well --
make that post-fix too and the declaration becomes uni-directional.
Of course you can decide if you now want to switch and make everything
pre-fix, but other languages, like Algol 68, use the left to right order
only they put the name at the end rather than in front to the type:
> Our complex declaration above could be rewritten as
>
> int f*()*[10]*;
With post-fix base types:
f*()*[10]* int;
In Algol 68 the name goes after the type but the order of the
"declarators" (not an Algol 68 term) is the same as you have here:
ref proc() ref [10] ref int f;
[You would not use all those refs in typical Alog 68 but that's not the
point here.]
--
Ben.
ImpalerCore
I still like the array postfix modifier the way its designed. So in
that sense it's somewhat hypocritical of me to advocate keeping the
pointer modifier to the type portion while still being ok with an
array modifier attached to the variable name. I suppose that it's
simply because the array postfix '[]' is so ubiquitous between many
different languages that it's not easily confused.
Most of my bias is probably due to learning programming from the
Stroustrup's C++ book, where declaring both pointers and references
were modifiers of the type portion of the variable declaration. The
choice of using '&' to declare references means that the potential for
confusion between declaring a reference type and referencing the
address of a variable would be much higher. My guess is that
Stroustrup's intent was to distinguish using the '&' as a prefix
operator to signify taking the address of a variable, from using '&'
as a postfix operator to signify a type modifier used to declare a
'reference to type'.
In the same manner, the style of using '*' in his book is used as a
prefix operator to signify pointer dereference, and as a postfix
operator of a type to modify it to a 'pointer to type'. When I got to
C, now people wanted to use prefix '*' to mean both, which due to my
history I find more confusing, and definitely feel resistance to
adopt.
As far as function pointers, they are in their own category and I'm
not sure whether I like them or not. It certainly took some time to
get used to them, but I can't think of an alternate syntax since
functions declaration themselves have return type prefixes and
argument postfix modifiers. I certain would be resistant to any
change in function pointer or declaration semantics now.
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. I
don't recall if K&R mentioned if there was any motive behind their
choice for pointer variable declaration syntax. Now pointer syntax
has the weight of history behind it, and I know that my pointer
declaration preferences will likely remain an outlier opinion in C
because of it.
> Topic: the only truly unfortunate aspect of C's design is the use of
> "=" for assignment and "==" for equality, and that's a lexical issue
> rather than syntax. If only the assignment operator had been ":=" or
> something similarly unlike the equality operator, then a whole class
> of bugs would never have existed.
Seems reasonable. It certainly would have mitigated the whole '0 ==
variable' use, which I can't stand from a style perspective.
Backwards code my read to like I.
Best regards,
John D.
BartC
news:0.d40a8ebaf5fee8e72403.2010...@bsb.me.uk...
> John Bode <jfbod...@gmail.com> writes:
>> 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
>> Our complex declaration above could be rewritten as
>>
>> int f*()*[10]*;
>
> With post-fix base types:
>
> f*()*[10]* int;
>
> In Algol 68 the name goes after the type but the order of the
> "declarators" (not an Algol 68 term) is the same as you have here:
>
> ref proc() ref [10] ref int f;
I've never used Algol68 but make use of pretty much the same syntax (the
above would be ref proc: ref [10] ref int f, although I prefer 'function' to
'proc').
That looks great, and reads almost like English (better than actual Algol68
which always seems to require capitals or quoting for reserved words).
And an extra advantage is being able to share a complex declaration amongst
several identifiers, without messing with typedefs:
ref function: ref [10] ref int f, g, h
This applies to prototype declarations too, when many functions share the
same signature.
> [You would not use all those refs in typical Alog 68 but that's not the
> point here.]
[Why not?]
--
Bartc
John Bode
> On Oct 11, 10:22 pm, John Bode <jfbode1...@gmail.com> wrote:
[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 from
http://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
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.