f



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

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
0
Alexander
10/8/2010 7:09:19 PM
comp.lang.c++ 49423 articles. 7 followers. Post Follow

670 Replies
3358 Views

Similar Articles

[PageSpeed] 56

Alexander 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.
> 
> Cheers,
> Alexander

....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
0
Stuart
10/8/2010 7:43:04 PM
In article <f3bfce1a-e3d9-48e9-9c84-
e8d020bde7ec@a36g2000yqc.googlegroups.com>, alvatov@gmail.com says...
> 
> 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.

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.

0
dcorbit (2697)
10/8/2010 8:18:50 PM
On Oct 8, 12:43=A0pm, Stuart Golodetz <b...@blah.com> wrote:
> Alexander 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.
>
> > Cheers,
> > Alexander
>
> ...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.

Or else some guy posting his homework question.
0
red
10/8/2010 8:31:46 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).

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.
0
Lew
10/8/2010 10:26:06 PM
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.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth
0
Joshua
10/8/2010 11:29:17 PM
On Oct 8, 6:26=C2=AC=E2=80=A0pm, 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. =C2=AC=E2=80=A0The 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
0
Keith
10/9/2010 12:22:36 AM
On Oct 9, 2:09=A0am, Alexander <alva...@gmail.com> wrote:
> ... 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 =3D=3D, 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

0
James
10/9/2010 7:02:00 AM
"James Dow Allen" <jdallen2000@yahoo.com> wrote in message 
news:9ae021aa-dc20-4dfe-8dab-ea176d104e62@l38g2000pro.googlegroups.com...
On Oct 9, 2:09 am, Alexander <alva...@gmail.com> wrote:
> ... 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.  :-)
-->

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...


0
BGB
10/9/2010 8:14:29 AM
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.

-- 
Ian Collins
0
Ian
10/9/2010 8:24:50 AM
In article 
<9ae021aa-dc20-4dfe-8dab-ea176d104e62@l38g2000pro.googlegroups.com>,
 James Dow Allen <jdallen2000@yahoo.com> wrote:

> (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;
> )

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

Too late to change now, though.

-- 
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted"  --  Bill of Rights 1689
0
Tim
10/9/2010 9:48:12 AM
Ian Collins <ian-news@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"?

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.
0
Ben
10/9/2010 10:12:41 AM
On 10/ 9/10 11:12 PM, Ben Bacarisse wrote:
> Ian Collins<ian-news@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
0
Ian
10/9/2010 10:17:06 AM
On 10/ 9/10 11:12 PM, Ben Bacarisse wrote:
> Did you mean "for those of us who declare our variables
> one per declaration"?

That too!

-- 
Ian Collins
0
Ian
10/9/2010 10:17:56 AM
"Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message
news:0.d8d18d98b65e37458b9e.20101009111241BST.87lj67wu7a.fsf@bsb.me.uk...
> Ian Collins <ian-news@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 

0
BartC
10/9/2010 10:27:34 AM
Dann Corbit wrote:

> 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
0
Rui
10/9/2010 10:36:33 AM
"James Dow Allen" <jdallen2000@yahoo.com> wrote in message
news:9ae021aa-dc20-4dfe-8dab-ea176d104e62@l38g2000pro.googlegroups.com...
> On Oct 9, 2:09 am, Alexander <alva...@gmail.com> wrote:
>> ... 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 

0
BartC
10/9/2010 10:51:20 AM
* Ian Collins <ian-news@hotmail.com>:
> On 10/ 9/10 11:12 PM, Ben Bacarisse wrote:
>> Ian Collins<ian-news@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. I even employ this in languages that would allow
declarations anywhere, like C#.

Regards,
Felix

-- 
 Felix Palmen       (Zirias)  + [PGP] Felix Palmen <felix@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
0
felix4560 (61)
10/9/2010 12:28:23 PM
* Tim Streater <timstreater@waitrose.com>:
> 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.

Regards,
Felix

-- 
 Felix Palmen       (Zirias)  + [PGP] Felix Palmen <felix@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
0
felix
10/9/2010 12:32:19 PM
Ian Collins <ian-news@hotmail.com> writes:

> On 10/ 9/10 11:12 PM, Ben Bacarisse wrote:
>> Ian Collins<ian-news@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?

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.
0
Ben
10/9/2010 3:14:12 PM
"BartC" <bc@freeuk.com> writes:

> "Ben Bacarisse" <ben.usenet@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.
0
Ben
10/9/2010 3:35:36 PM
On 2010-10-09 17:35, Ben Bacarisse wrote:
> 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
0
August
10/9/2010 4:32:33 PM
Keith H Duggar wrote:

> 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. 


0
osmium
10/9/2010 5:25:28 PM

"Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message 
news:0.1f7a73555a7d9103805e.20101009163536BST.871v7zwf93.fsf@bsb.me.uk...
> "BartC" <bc@freeuk.com> writes:
>> "Ben Bacarisse" <ben.usenet@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 

0
BartC
10/9/2010 5:52:59 PM
In article <9ae021aa-dc20-4dfe-8dab-ea176d104e62@l38g2000pro.googlegroups.com>,
James Dow Allen  <jdallen2000@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
0
pacman
10/9/2010 6:20:26 PM
On Oct 9, 5:12=A0am, 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
>
> =A0 char buf[SIZE], *start =3D buf, c =3D *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?
0
Anand
10/9/2010 6:44:32 PM

"Alan Curry" <pacman@kosh.dhis.org> wrote in message
news:i8qbp9$9i$1@speranza.aioe.org...
> In article
> <9ae021aa-dc20-4dfe-8dab-ea176d104e62@l38g2000pro.googlegroups.com>,
> James Dow Allen  <jdallen2000@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.

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
 

0
BartC
10/9/2010 7:06:10 PM
On 10/10/10 01:28 AM, Felix Palmen wrote:
> * Ian Collins<ian-news@hotmail.com>:
>> On 10/ 9/10 11:12 PM, Ben Bacarisse wrote:
>>> Ian Collins<ian-news@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
0
Ian
10/9/2010 8:10:16 PM
Anand Hariharan <mailto.anand.hariharan@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.  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.
0
Ben
10/9/2010 9:29:09 PM
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 
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

-- 
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
0
August
10/9/2010 11:04:11 PM
On Sun, 10 Oct 2010 09:10:16 +1300, Ian Collins
<ian-news@hotmail.com> wrote:

>On 10/10/10 01:28 AM, Felix Palmen wrote:
>> * Ian Collins<ian-news@hotmail.com>:
>>> On 10/ 9/10 11:12 PM, Ben Bacarisse wrote:
>>>> Ian Collins<ian-news@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.

That's not much of a recommendation for C++.



0
cri
10/9/2010 11:06:53 PM
Ben Bacarisse wrote:
> Anand Hariharan <mailto.anand.hariharan@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
0
Marcin
10/9/2010 11:15:07 PM
On Sat, 09 Oct 2010 16:35:36 +0100, Ben Bacarisse
<ben.usenet@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!


0
cri
10/9/2010 11:15:52 PM
On 10/10/10 12:15 PM, Richard Harter wrote:
> On Sat, 09 Oct 2010 16:35:36 +0100, Ben Bacarisse
> <ben.usenet@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.

-- 
Ian Collins
0
Ian
10/9/2010 11:27:26 PM

"August Karlstrom" <fusionfile@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 

0
BartC
10/9/2010 11:58:54 PM
cri@tiac.net (Richard Harter) writes:

> On Sat, 09 Oct 2010 16:35:36 +0100, Ben Bacarisse
> <ben.usenet@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?

> Comments!? We don't need no steenking comments!

-- 
Ben.
0
Ben
10/10/2010 12:39:40 AM
August Karlstrom <fusionfile@gmail.com> writes:

> 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
0
Richard
10/10/2010 1:24:01 AM
"BartC" <bc@freeuk.com> writes:

> "August Karlstrom" <fusionfile@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.

-- 
"Avoid hyperbole at all costs, its the most destructive argument on
the planet" - Mark McIntyre in comp.lang.c
0
Richard
10/10/2010 1:26:05 AM
Ian Collins <ian-news@hotmail.com> writes:

> On 10/10/10 12:15 PM, Richard Harter wrote:
>> On Sat, 09 Oct 2010 16:35:36 +0100, Ben Bacarisse
>> <ben.usenet@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.

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.

-- 
"Avoid hyperbole at all costs, its the most destructive argument on
the planet" - Mark McIntyre in comp.lang.c
0
Richard
10/10/2010 1:29:01 AM
On Sun, 10 Oct 2010 12:27:26 +1300, Ian Collins
<ian-news@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.usenet@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.


0
cri
10/10/2010 2:46:53 AM
On 10/10/10 03:46 PM, Richard Harter wrote:
> On Sun, 10 Oct 2010 12:27:26 +1300, Ian Collins
> <ian-news@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.usenet@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.

-- 
Ian Collins
0
Ian
10/10/2010 3:35:26 AM
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).
> 
> 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.
0
ClassCastException
10/10/2010 4:22:16 AM
* Ian Collins <ian-news@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...

Regards,
Felix

-- 
 Felix Palmen       (Zirias)  + [PGP] Felix Palmen <felix@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
0
felix4560 (61)
10/10/2010 7:20:22 AM
* August Karlstrom <fusionfile@gmail.com>:
> The assignment operator `=' will confuse any newcomer with a basic 
> knowledge of mathematics. You can only imagine how many bugs it has 
> caused in C and C++ when being inadvertently used as an equality 
> operator instead of `=='. In code comments it also makes the usage of 
> the mathematical `=' slightly ambiguous which forces people to use `==' 
> instead. UGLY is the word.

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

Regards,
Felix

-- 
 Felix Palmen       (Zirias)  + [PGP] Felix Palmen <felix@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
0
felix4560 (61)
10/10/2010 7:32:04 AM
On Oct 9, 6:58=A0pm, "BartC" <b...@freeuk.com> wrote:
> "August Karlstrom" <fusionf...@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 `=3D' will confuse any newcomer with a basic
> > knowledge of mathematics. You can only imagine how many bugs it has cau=
sed
> > in C and C++ when being inadvertently used as an equality operator inst=
ead
> > of `=3D=3D'.
>
> This was the biggest problem I had, when trying to code a sizeable C proj=
ect
> a couple of years back.
>
> The syntax I normally used had for ":=3D" for assignment, and "=3D" for
> equality.
>
> Wrongly using ":=3D" in C just gave a syntax error. Wrongly using "=3D" i=
n the
> other languages (using my own not very robust compilers), either caused a
> crash, or silently did nothing (certainly not assignment). While using "=
=3D"
> in C instead of "=3D=3D" had it's own problems...
>
> But, yes, the use of "=3D" and "=3D=3D" in C I don't think were the best =
choices,
> but they have propagated through to too many other languages now.
>

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

--
imagine i'm emphatically raising my eyebrows.
0
luser
10/10/2010 7:35:16 AM
On 10/10/10 08:20 PM, Felix Palmen wrote:
> * Ian Collins<ian-news@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
0
Ian
10/10/2010 8:14:34 AM
In comp.lang.c++ ClassCastException <zjkg3d9gj56@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.
0
Juha
10/10/2010 9:03:09 AM
BartC wrote:

> 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
0
Rui
10/10/2010 9:06:12 AM
On Oct 8, 12:09=A0pm, Alexander <alva...@gmail.com> 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.

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=3DFNum, @lrecl=3D&&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.

0
maravera (58)
10/10/2010 10:07:27 AM
"Richard" <rgrdev_@gmail.com> wrote in message 
news:i8r4ne$pd6$4@news.eternal-september.org...
> "BartC" <bc@freeuk.com> writes:
>
>> "August Karlstrom" <fusionfile@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 

0
BartC
10/10/2010 10:32:55 AM
"Ian Collins" <ian-news@hotmail.com> wrote in message
news:8hcqjuFn29U1@mid.individual.net...
> On 10/10/10 03:46 PM, Richard Harter wrote:
>> On Sun, 10 Oct 2010 12:27:26 +1300, Ian Collins
>> <ian-news@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.usenet@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?

-- 
Bartc 

0
BartC
10/10/2010 10:44:11 AM
On 9 Oct, 11:51, "BartC" <b...@freeuk.com> wrote:

<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>

0
Nick
10/10/2010 11:14:32 AM
On 10 Oct, 02:24, Richard <rgrd...@gmail.com> wrote:
> August Karlstrom <fusionf...@gmail.com> writes:
> > On 2010-10-08 21:09, Alexander wrote:

<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.
0
Nick
10/10/2010 11:28:18 AM
"Richard" <rgrdev_@gmail.com> wrote in message 
news:i8r4jh$pd6$3@news.eternal-september.org...

> 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 

0
BartC
10/10/2010 11:38:35 AM
On 10 Oct, 11:44, "BartC" <b...@freeuk.com> wrote:
> "Ian Collins" <ian-n...@hotmail.com> wrote in message
>
> news:8hcqjuFn29U1@mid.individual.net...
>
>
>
>
>
> > On 10/10/10 03:46 PM, Richard Harter wrote:
> >> On Sun, 10 Oct 2010 12:27:26 +1300, Ian Collins
> >> <ian-n...@hotmail.com> =A0wrote:
>
> >>> 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> =A0 wrote:
>
> >>>>> I'd be prepared to say that "mixed" declarations (declarations with
> >>>>> multiple forms of declarator) were considered idiomatic in "old" C.=
 =A0I
> >>>>> 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. =A0I'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. =A0That 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, ju=
st
> 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




0
Nick
10/10/2010 12:02:08 PM
Nick Keighley <nick_keighley_nospam@hotmail.com> writes:

> On 10 Oct, 11:44, "BartC" <b...@freeuk.com> wrote:
>> "Ian Collins" <ian-n...@hotmail.com> wrote in message
>>
>> news:8hcqjuFn29U1@mid.individual.net...
>>
>>
>>
>>
>>
>> > On 10/10/10 03:46 PM, Richard Harter wrote:
>> >> On Sun, 10 Oct 2010 12:27:26 +1300, Ian Collins
>> >> <ian-n...@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.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
>

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.

-- 
"Avoid hyperbole at all costs, its the most destructive argument on
the planet" - Mark McIntyre in comp.lang.c
0
Richard
10/10/2010 12:42:39 PM
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

-- 
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
0
August
10/10/2010 12:50:59 PM
August Karlstrom <fusionfile@gmail.com> writes:

> 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.


-- 
"Avoid hyperbole at all costs, its the most destructive argument on
the planet" - Mark McIntyre in comp.lang.c
0
Richard
10/10/2010 1:02:00 PM
Ian Collins wrote:

> 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
0
Rui
10/10/2010 1:10:23 PM
Nick Keighley wrote:
> 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
       .      @       .
0
Niklas
10/10/2010 1:31:35 PM
On Oct 8, 12:09=A0pm, Alexander <alva...@gmail.com> wrote:
> 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 =3D 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.)

0
geowar
10/10/2010 3:06:49 PM
* geowar <geowar1@mac.com>:
> I really like Lua's ability to return multiple values:
> 
> m, d, y = GetBirthday("George");
> 
> (int, int, int) GetBirthday(char* inName) {
>    .
>    .
>    .
>    return (mm, dd, tttt);
> }

This would be just a shorthand for

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

CalendarDate GetBirthday(const char *name);

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

Regards,
Felix

-- 
 Felix Palmen       (Zirias)  + [PGP] Felix Palmen <felix@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
0
felix
10/10/2010 3:28:13 PM
geowar <geowar1@mac.com> writes:

> On Oct 8, 12:09 pm, Alexander <alva...@gmail.com> wrote:
>> 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.)

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
0
3-nospam (285)
10/10/2010 3:33:23 PM
On Sun, 10 Oct 2010 01:39:40 +0100, Ben Bacarisse
<ben.usenet@bsb.me.uk> wrote:

>cri@tiac.net (Richard Harter) writes:
>
>> On Sat, 09 Oct 2010 16:35:36 +0100, Ben Bacarisse
>> <ben.usenet@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.

      




0
cri
10/10/2010 5:07:08 PM
On Sun, 10 Oct 2010 16:35:26 +1300, Ian Collins
<ian-news@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-news@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.usenet@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.

0
cri
10/10/2010 5:08:55 PM
cri@tiac.net (Richard Harter) writes:

> On Sun, 10 Oct 2010 01:39:40 +0100, Ben Bacarisse
> <ben.usenet@bsb.me.uk> wrote:
>
>>cri@tiac.net (Richard Harter) writes:
>>
>>> On Sat, 09 Oct 2010 16:35:36 +0100, Ben Bacarisse
>>> <ben.usenet@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.

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%.


-- 
"Avoid hyperbole at all costs, its the most destructive argument on
the planet" - Mark McIntyre in comp.lang.c
0
Richard
10/10/2010 5:26:04 PM
On 10/11/10 06:08 AM, Richard Harter wrote:
> On Sun, 10 Oct 2010 16:35:26 +1300, Ian Collins
> <ian-news@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-news@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.usenet@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.

The one who bakes exceedingly good cakes or the author?

-- 
Ian Collins
0
Ian
10/10/2010 7:16:53 PM
On 10/11/10 06:07 AM, Richard Harter wrote:
> On Sun, 10 Oct 2010 01:39:40 +0100, Ben Bacarisse
> <ben.usenet@bsb.me.uk>  wrote:
>
>> cri@tiac.net (Richard Harter) writes:
>>
>>> On Sat, 09 Oct 2010 16:35:36 +0100, Ben Bacarisse
>>> <ben.usenet@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 */

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
0
Ian
10/10/2010 7:37:47 PM
ClassCastException <zjkg3d9gj56@gmail.invalid> writes:
> 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).
>> 
>> 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>
>
> ...
>
> <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.

     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)
0
10/10/2010 8:55:53 PM
On Mon, 11 Oct 2010 08:16:53 +1300, Ian Collins
<ian-news@hotmail.com> wrote:

>On 10/11/10 06:08 AM, Richard Harter wrote:
>> On Sun, 10 Oct 2010 16:35:26 +1300, Ian Collins
>> <ian-news@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-news@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.usenet@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.
>
>The one who bakes exceedingly good cakes or the author?

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

However the cakes are very good also.



0
cri
10/11/2010 12:18:31 AM
On Sun, 10 Oct 2010 19:26:04 +0200, Richard <rgrdev_@gmail.com>
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.


0
cri
10/11/2010 12:22:14 AM
On 10/11/10 01:18 PM, Richard Harter wrote:
> On Mon, 11 Oct 2010 08:16:53 +1300, Ian Collins
> <ian-news@hotmail.com>  wrote:
>
>> On 10/11/10 06:08 AM, Richard Harter wrote:
>>> On Sun, 10 Oct 2010 16:35:26 +1300, Ian Collins
>>> <ian-news@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-news@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.usenet@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.
>>
>> The one who bakes exceedingly good cakes or the author?
>
> The poet, "In the Neolithic Age", see
> http://www.kipling.org.uk/poems_neolithic.htm

Ah-ha!

-- 
Ian Collins
0
Ian
10/11/2010 12:27:12 AM
On Mon, 11 Oct 2010 08:37:47 +1300, Ian Collins
<ian-news@hotmail.com> wrote:

>On 10/11/10 06:07 AM, Richard Harter wrote:
>> On Sun, 10 Oct 2010 01:39:40 +0100, Ben Bacarisse
>> <ben.usenet@bsb.me.uk>  wrote:
>>
>>> cri@tiac.net (Richard Harter) writes:
>>>
>>>> On Sat, 09 Oct 2010 16:35:36 +0100, Ben Bacarisse
>>>> <ben.usenet@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 */
>
>My preference would be in the context where foo has been declared,
>
>char* const beginning = &foo;

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.


0
cri
10/11/2010 12:42:32 AM
>>> 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. 

0
Mike
10/11/2010 6:18:19 AM
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:

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
0
pats (3556)
10/11/2010 7:25:36 AM
Patricia Shanahan <pats@acm.org> writes:
> 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,

Patrick

------------------------------------------------------------------------
http://www.softwarematters.org
Large scale, mission-critical, distributed OO systems design and
implementation.  (C++, Java, Common Lisp, Jini, middleware, SOA)
0
10/11/2010 10:15:34 AM
On Sun, 10 Oct 2010, 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.
>
>   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"
0
Tom
10/11/2010 11:53:27 AM
Tom Anderson wrote:
> 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
0
Lew
10/11/2010 12:00:48 PM
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.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth
0
Joshua
10/11/2010 12:02:20 PM
On Fri, 8 Oct 2010 12:09:19 -0700 (PDT), Alexander <alvatov@gmail.com>
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.
0
see_website (5876)
10/11/2010 12:28:48 PM

"Joshua Cranmer" <Pidgeot18@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++. 

0
Mike
10/11/2010 2:19:45 PM
On Oct 9, 3:02=A0am, James Dow Allen <jdallen2...@yahoo.com> wrote:
> On Oct 9, 2:09=A0am, Alexander <alva...@gmail.com> wrote:
>
> > ... anything you do not like in the C ... syntax.

<snip>

> (4) Declarations like =A0char* =A0 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
> =A0 =A0 char =A0 *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.
0
jadill33 (205)
10/11/2010 2:33:04 PM
On Mon, 11 Oct 2010, Mike Schilling wrote:

> "Joshua Cranmer" <Pidgeot18@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++.

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
0
Tom
10/11/2010 2:43:12 PM
On 2010-10-11, Tom Anderson <twic@urchin.earth.li> wrote:
> 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-nospam@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.
0
Seebs
10/11/2010 5:48:51 PM
Joshua Cranmer <Pidgeot18@verizon.invalid> writes:

> 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
0
Jim
10/11/2010 5:52:55 PM
Seebs wrote:

> [...] 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
0
Vincenzo
10/11/2010 7:56:51 PM
["Followup-To:" header set to comp.lang.c++.]

On Mon, 2010-10-11, Tom Anderson wrote:
> On Mon, 11 Oct 2010, Mike Schilling wrote:
>
>> "Joshua Cranmer" <Pidgeot18@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++.
>
> Stroustrup *didn't* include something in C++ because it was error-prone? 
> Was he having an off day or something?

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   .
0
Jorgen
10/11/2010 10:30:05 PM
[Please do not mail me a copy of your followup]

Jorgen Grahn <grahn+nntp@snipabacken.se> spake the secret code
<slrnib73vd.dlt.grahn+nntp@frailea.sa.invalid> thusly:

>Read the book. He describes his (and others') way of reasoning and the
>massive field experience he collected in order to make a decision.

Given that this was published in 1994 and C++ has evolved considerably
since then, it would be interesting to see a book that covers the
evolution of C++ over the last 15 years.  I don't know if Stroustrup
would be the person to write such a book or if it is better suited to
a group of authors, considering the effect of Boost on the standard.
-- 
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
 <http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/>

      Legalize Adulthood! <http://legalizeadulthood.wordpress.com>
0
jeeves (202)
10/11/2010 10:34:58 PM
On Oct 11, 9:33=A0am, ImpalerCore <jadil...@gmail.com> wrote:
> On Oct 9, 3:02=A0am, James Dow Allen <jdallen2...@yahoo.com> wrote:
>
> > On Oct 9, 2:09=A0am, Alexander <alva...@gmail.com> wrote:
>
> > > ... anything you do not like in the C ... syntax.
>
> <snip>
>
> > (4) Declarations like =A0char* =A0 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
> > =A0 =A0 char =A0 *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. =A0I 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
"=3D" for assignment and "=3D=3D" for equality, and that's a lexical issue
rather than syntax.  If only the assignment operator had been ":=3D" or
something similarly unlike the equality operator, then a whole class
of bugs would never have existed.

0
John
10/12/2010 2:22:12 AM
On Sun, 10 Oct 2010 09:03:09 +0000, Juha Nieminen wrote:

> In comp.lang.c++ ClassCastException <zjkg3d9gj56@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+
+.
0
ClassCastException
10/12/2010 3:01:52 AM
On Oct 10, 12:26=A0pm, Richard <rgrd...@gmail.com> wrote:
> c...@tiac.net (Richard Harter) writes:
> > On Sun, 10 Oct 2010 01:39:40 +0100, Ben Bacarisse
> > <ben.use...@bsb.me.uk> wrote:
>
> >>c...@tiac.net (Richard Harter) writes:
>
> >>> 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. =
=A0I
> >>>>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. =A0I'm of the school that believes that
> >>> variables should have a well defined meaning and that that
> >>> meaning should be documented. =A0
>
> >>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. =A0Wou=
ld
> >>you elaborate?
>
> > My apologies for being unclear. =A0I dare say I was thinking of
> > rather more than what I actually wrote. =A0My 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. =A0For example programmer X writes
>
> > char *b, endchar;
>
> > and I might write the same as
>
> > char =A0*b =A0 =A0 =A0 =3D 0; =A0 =A0 =A0 =A0 /* Ptr to beginning of fo=
o =A0 =A0 =A0 */
> > char =A0 endchar; =A0 =A0 =A0 =A0 =A0 =A0 /* Terminating character of s=
can */
>
> > The thought is to create a dictionary for the scope, a dictionary
> > that contains the terms that are used within the scope. =A0Like all
> > good dictionaries it contains definitions and is organized so
> > that terms are easy to find.
>
> You did nothing but take up more real estate. call it terminateChar and
> its self commented.
>
>

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. =A0Of
>
> It does.
>
> > course it is good to have meaningful names. =A0However 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. =A0There is something to that. =A0However 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. =A0Many 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. =A0Some
>
> 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. =A0So 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=3D0...). =A0The 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. =A0Good arguments. =A0On 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. =A0Better 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. =A0The truth is that style
> > doesn't matter that much if you have small functions and modest
> > sized files. =A0The 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.
0
jfbode1029 (228)
10/12/2010 3:54:52 AM
On Mon, 2010-10-11, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> Jorgen Grahn <grahn+nntp@snipabacken.se> spake the secret code
> <slrnib73vd.dlt.grahn+nntp@frailea.sa.invalid> thusly:
>
>>Read the book. He describes his (and others') way of reasoning and the
>>massive field experience he collected in order to make a decision.
>
> Given that this was published in 1994 and C++ has evolved considerably
> since then,

From my point of view it hasn't really -- the situation in 1994 seemed
to be pretty much what was standardized in 1998. And the exciting
parts of the book were IMHO about what happened earlier, in the 1980s
when it wasn't clear in which direction the language would be going.

> it would be interesting to see a book that covers the
> evolution of C++ over the last 15 years.  I don't know if Stroustrup
> would be the person to write such a book or if it is better suited to
> a group of authors, considering the effect of Boost on the standard.

A chronicle of the C++ "community" since 1994 would be interesting to
read. But probably difficult to write ...

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .  .
\X/     snipabacken.se>   O  o   .
0
Jorgen
10/12/2010 7:52:36 AM
On 08/10/2010 20: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).
>
> In order to maintain the integrity of the discussion (have everything
> at the same place) please respond on comp.lang.c.
>
> Cheers,
> 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."
0
Sir
10/12/2010 9:16:28 AM
"John Bode" <jfbode1029@gmail.com> wrote in message 
news:4f1c9d33-7b96-4890-8699-66cd294c7f38@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 

0
BartC
10/12/2010 10:40:53 AM
cri@tiac.net (Richard Harter) writes:

> On Sun, 10 Oct 2010 01:39:40 +0100, Ben Bacarisse
> <ben.usenet@bsb.me.uk> wrote:
>
>>cri@tiac.net (Richard Harter) writes:
>>
>>> On Sat, 09 Oct 2010 16:35:36 +0100, Ben Bacarisse
>>> <ben.usenet@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.

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.
0
Ben
10/12/2010 12:27:27 PM
John Bode <jfbode1029@gmail.com> writes:
<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.
0
Ben
10/12/2010 1:12:43 PM
"Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message 
news:0.d40a8ebaf5fee8e72403.20101012141243BST.87mxqjv9kk.fsf@bsb.me.uk...
> John Bode <jfbode1029@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 

0
BartC
10/12/2010 2:20:21 PM
On Oct 11, 10:22=A0pm, John Bode <jfbode1...@gmail.com> wrote:
> On Oct 11, 9:33=A0am, ImpalerCore <jadil...@gmail.com> wrote:
>
>
>
> > On Oct 9, 3:02=A0am, James Dow Allen <jdallen2...@yahoo.com> wrote:
>
> > > On Oct 9, 2:09=A0am, Alexander <alva...@gmail.com> wrote:
>
> > > > ... anything you do not like in the C ... syntax.
>
> > <snip>
>
> > > (4) Declarations like =A0char* =A0 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
> > > =A0 =A0 char =A0 *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. =A0I 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. =A0It 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.

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.

> Then you have complex declarations like
>
> =A0 =A0 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. =A0And 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:
>
> =A0 =A0 int x*; =A0 =A0 =A0 =A0// x is a pointer to int
> =A0 =A0 int arr*[10]; =A0// arr is a pointer to a 10-element array of int
> =A0 =A0 int arr[10]*; =A0// arr is a 10-element array of pointer to int
> =A0 =A0 int f*(); =A0 =A0 =A0// f is a pointer to a function returning in=
t
> =A0 =A0 int f()*; =A0 =A0 =A0// f is a function returning a pointer to in=
t
>
> Our complex declaration above could be rewritten as
>
> =A0 =A0 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. =A0The 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.  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
> "=3D" for assignment and "=3D=3D" for equality, and that's a lexical issu=
e
> rather than syntax. =A0If only the assignment operator had been ":=3D" 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 =3D=3D
variable' use, which I can't stand from a style perspective.
Backwards code my read to like I.

Best regards,
John D.
0
jadill33 (205)
10/12/2010 2:22:20 PM
On Oct 12, 9:22=A0am, ImpalerCore <jadil...@gmail.com> wrote:
> On Oct 11, 10:22=A0pm, 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. =A0The 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. =A0

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.
0
John
10/12/2010 5:54:28 PM
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.

tom

-- 
Caps lock is like cruise control for cool.
0
Tom
10/12/2010 6:19:55 PM
On Oct 12, 1:54=A0pm, John Bode <jfbode1...@gmail.com> wrote:
> On Oct 12, 9:22=A0am, ImpalerCore <jadil...@gmail.com> wrote:
>
> > On Oct 11, 10:22=A0pm, 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. =A0The 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. =A0
>
> As far as the language grammar is concered, it is. =A0Here's a grammar
> trace for a simple pointer declaration "int* p;" (taken fromhttp://www.op=
en-std.org/jtc1/sc22/open/n2356/gram.html):
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0declaration
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0block-declaration
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 simple-declaration
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/ =A0 =A0 =A0 =A0 =A0 =A0\
> =A0 =A0 decl-specifier-seq =A0 =A0 init-declarator-list
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
> =A0 =A0 =A0 =A0type-specifier =A0 =A0 =A0 =A0 =A0init-declarator
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
> =A0 =A0 =A0simple-type-specifier =A0 =A0 =A0 declarator
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 / =A0 =
=A0\
> =A0 =A0 =A0 =A0 =A0 =A0 =A0int =A0 =A0 =A0 =A0 ptr-operator declarator
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0=
 =A0 =A0 |
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * =A0 dir=
ect-declarator
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 |
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0id-expression
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 |
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 u=
nqualified-id
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 |
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 identifier
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 |
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 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). =A0I 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.
0
jadill33 (205)
10/12/2010 6:40:46 PM
[Please do not mail me a copy of your followup]

Jorgen Grahn <grahn+nntp@snipabacken.se> spake the secret code
<slrnib84u4.dlt.grahn+nntp@frailea.sa.invalid> thusly:

>On Mon, 2010-10-11, Richard wrote:
>> [Please do not mail me a copy of your followup]
>>
>> Jorgen Grahn <grahn+nntp@snipabacken.se> spake the secret code
>> <slrnib73vd.dlt.grahn+nntp@frailea.sa.invalid> thusly:
>>
>>>Read the book. He describes his (and others') way of reasoning and the
>>>massive field experience he collected in order to make a decision.
>>
>> Given that this was published in 1994 and C++ has evolved considerably
>> since then,
>
>From my point of view it hasn't really -- the situation in 1994 seemed
>to be pretty much what was standardized in 1998.

Really?  I consider the new uses of auto, lambda functions, rvalue
references, move semantics and perfect forwarding and other changes in
C++0x to be pretty big changes.

>A chronicle of the C++ "community" since 1994 would be interesting to
>read. But probably difficult to write ...

Dunno about the interesting part, it would really depend on who was
editor/guiding force of such an effort.  However, I really agree about
the difficulty! :-)
-- 
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
 <http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/>

      Legalize Adulthood! <http://legalizeadulthood.wordpress.com>
0
legalize
10/12/2010 8:25:16 PM
On Oct 12, 11:12 pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> John Bode <jfbode1...@gmail.com> write
> >     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 #

On Oct 13, 12:20 am, "BartC" <b...@freeuk.com> wrote:
> 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
--
To download Linux's Algol68 Compiler, Interpreter & Runtime:
* http://sourceforge.net/projects/algol68/files
0
Neville
10/12/2010 9:12:41 PM
On 10/10/2010 11:18 PM, 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.
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.

-- 
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
0
10/12/2010 9:18:02 PM
On Tue, 12 Oct 2010, Daniel Pitts wrote:

> On 10/10/2010 11:18 PM, 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.
>> 
>> 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?

While loops don't include puns about noodles.

tom

-- 
there is never a wrong time to have your bullets passing further into
someone's face -- D
0
Tom
10/12/2010 9:28:05 PM
On Oct 8, 2:09=A0pm, Alexander <alva...@gmail.com> 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.
>
> Cheers,
> Alexander

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

-RFH
0
ramon (1518)
10/12/2010 10:36:36 PM
On Tue, 12 Oct 2010 19:19:55 +0100, Tom Anderson wrote:

> 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.
 

-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |
0
Martin
10/12/2010 11:43:08 PM
On Mon, 11 Oct 2010 20:54:52 -0700 (PDT), John Bode
<jfbode1029@gmail.com> wrote:

>On Oct 10, 12:26=A0pm, Richard <rgrd...@gmail.com> wrote:
>> c...@tiac.net (Richard Harter) writes:
>> > On Sun, 10 Oct 2010 01:39:40 +0100, Ben Bacarisse
>> > <ben.use...@bsb.me.uk> wrote:
>>
>> >>c...@tiac.net (Richard Harter) writes:
>>
>> >>> 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. =
>=A0I
>> >>>>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. =A0I'm of the school that believes that
>> >>> variables should have a well defined meaning and that that
>> >>> meaning should be documented. =A0
>>
>> >>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. =A0Wou=
>ld
>> >>you elaborate?
>>
>> > My apologies for being unclear. =A0I dare say I was thinking of
>> > rather more than what I actually wrote. =A0My 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. =A0For example programmer X writes
>>
>> > char *b, endchar;
>>
>> > and I might write the same as
>>
>> > char =A0*b =A0 =A0 =A0 =3D 0; =A0 =A0 =A0 =A0 /* Ptr to beginning of fo=
>o =A0 =A0 =A0 */
>> > char =A0 endchar; =A0 =A0 =A0 =A0 =A0 =A0 /* Terminating character of s=
>can */
>>
>> > The thought is to create a dictionary for the scope, a dictionary
>> > that contains the terms that are used within the scope. =A0Like all
>> > good dictionaries it contains definitions and is organized so
>> > that terms are easy to find.
>>
>> You did nothing but take up more real estate. call it terminateChar and
>> its self commented.
>>
>
>Damn you Harter for making me agree with Just Richard, but he's got
>some good points here.

Don't mind Just Richard - he's just channelling his inner
grandfather, and his inner grandfather is a crabby old man.

Of course he has some good points -- after all, he's advocating a
style of coding that many people find congenial.
>
>[snip]
>
>> > Some would say that it suffices to have meaningful names. =A0Of
>>
>> It does.
>>
>> > course it is good to have meaningful names. =A0However 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.

I opine that you and crabby Richard underestimate the problems
with picking "meaningful" names.  Yes, most of the time there
isn't a problem - the context and usage make it clear what the
variable is.  However most of the time is not always.  Here are
some issues.

There are several different potential audiences for code.  There
is the code author while writing and debugging the code, the code
review group (if any), the author some months later making a
change or fixing a reported bug, the author or another member of
the team doing some refactoring, the maintenance programmer
charged with a little routine update (hah!) long after the author
has moved on, and, of course, the long suffering customers - if
any.  Are you quite confident that you can always pick names that
are meaningful to all of these audiences?

The besides of which, code authors are at a disadvantage in
picking names because they know the intended meaning.  Notice
that Ben prefers to write an explanatory block comment.  There is
much to be said for that approach when one is dealing with tricky
code.

Real estate is another issue.  Some people like long names that
have a lot of detail about the variable.  The trouble with long
names is that they occupy a lot of space - and that amount of
space is consumed every time the variable is referenced.  Even
medium length names, say 10-16 chars, eat up a lot of space if
they are frequently referenced.  

>>
>> > 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. =A0There is something to that. =A0However 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.

That doesn't say much - what, after all, is a minimum?  A more
useful criterion is:  Comment carefully tricky code, don't worry
about code that is clear and simple.

The fabled comment rot is not quite the boojum that some make it
out to be.  Experience says (in punishment for my sins I've
looked at a lot of large project file chang statistics) that the
most files change no more than 2 times.  The kind of change
history that encourages comment rot is confined to hot spot files
that change frequently.  That said, a real problem with generous
commenting is that it makes it hard (for conscientious
programmers) to change the code.

In my opinion, though, it is ridiculous to claim that attaching
comments to variable declarations is excessive commenting.  YMMV.

>
>> > meaning of a variable, its intent and how it is used is something
>> > that should rarely change. =A0Many 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.

I quite agree.  I'm suggesting that documenting the actual
meaning of the variables is part of the process.

>>
>> > A nice feature of a dictionary is that it is easy to find
>> > definitions, particularly if you alphabetize the entries. =A0Some
>>
>> Dictionary?!?!? Alphabetize? Did you never hear of local definitions?
>
>If you need a dictionary, you're doing it wrong.

We're clearly on different pages here.  What did you think I
meant and what do you think is wrong.

[Oops, snipped too much, can't get it back]

>> 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.

Let me give a (contrived) example.  Suppose you have multiple
instances of loops that start out with "for(int i=0;foo[i];i++)"
where foo is some big honking array.  Let's also suppose that int
and long originally were the same size but the code has been
moved to a new environment where longs are bigger than ints and
the foos are much bigger.  Now all of those "int i=0"
declarations should be changed to "long i=0".

I grant that the example is contrived; the point is that using
local declarations can create situations where there are multiple
instances of the same declaration and the potential of needing to
change some or all of them in a single change. 
>>
>> > 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. =A0The truth is that style
>> > doesn't matter that much if you have small functions and modest
>> > sized files. =A0The 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.

Your innocence is refreshing.  



0
cri (1432)
10/13/2010 2:20:10 AM
On Tue, 12 Oct 2010 13:27:27 +0100, Ben Bacarisse
<ben.usenet@bsb.me.uk> wrote:

>cri@tiac.net (Richard Harter) writes:
>
>> On Sun, 10 Oct 2010 01:39:40 +0100, Ben Bacarisse
>> <ben.usenet@bsb.me.uk> wrote:
>>
>>>cri@tiac.net (Richard Harter) writes:
>>>
>>>> On Sat, 09 Oct 2010 16:35:36 +0100, Ben Bacarisse
>>>> <ben.usenet@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.
>
>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.

Good point.  Sometimes you have to bite the bullet and do the
multi-line thing.  
>
>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;
>

I've done that also.  Over the years I must have tried every
documentation style around.  I think of block comments as being
orthogonal to variable documentation.  In truth, the only
variables that I really feel need documenting are the ones in
structure definitions.

By the by, may I commend you on the quality and civility of your
comments.  It's really quite refreshing.



0
cri
10/13/2010 2:40:23 AM
On 10/13/10 01:27 AM, Ben Bacarisse wrote:
> cri@tiac.net (Richard Harter) writes:
>>
>> 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.
>
> 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.

-- 
Ian Collins
0
Ian
10/13/2010 2:45:10 AM
Ian Collins <ian-news@hotmail.com> writes:

> On 10/13/10 01:27 AM, Ben Bacarisse wrote:
>> cri@tiac.net (Richard Harter) writes:
>>>
>>> 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.
>>
>> 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.

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.

-- 
Ben.
0
Ben
10/13/2010 3:05:10 AM

"Daniel Pitts" <newsgroup.spamfilter@virtualinfinity.net> wrote in message 
news:eg4to.720$ql4.421@newsfe23.iad...
> On 10/10/2010 11:18 PM, 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.
> How is that not the same thing as a while loop?

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

0
Mike
10/13/2010 3:07:13 AM
On 10/12/2010 2:28 PM, Tom Anderson wrote:
> On Tue, 12 Oct 2010, Daniel Pitts wrote:
>
>> On 10/10/2010 11:18 PM, 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.
>>>
>>> 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?
>
> 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' Tech Blog: <http://virtualinfinity.net/wordpress/>
0
Daniel
10/13/2010 3:26:51 AM
On 10/12/2010 8:07 PM, Mike Schilling wrote:
>
>
> "Daniel Pitts" <newsgroup.spamfilter@virtualinfinity.net> wrote in
> message news:eg4to.720$ql4.421@newsfe23.iad...
>> On 10/10/2010 11:18 PM, 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.
>> How is that not the same thing as a while loop?
>
> 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?


-- 
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
0
10/13/2010 3:28:04 AM
On 10/13/10 04:05 PM, Ben Bacarisse wrote:
> Ian Collins<ian-news@hotmail.com>  writes:
>
>> On 10/13/10 01:27 AM, Ben Bacarisse wrote:
>>> cri@tiac.net (Richard Harter) writes:
>>>>
>>>> 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.
>>>
>>> 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.
>
> 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.

-- 
Ian Collins
0
Ian
10/13/2010 3:34:27 AM
On 13/10/2010 00:43, Martin Gregorie wrote:
> On Tue, 12 Oct 2010 19:19:55 +0100, Tom Anderson wrote:
>
>> 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.

-- 
RGB
0
RedGrittyBrick
10/13/2010 9:01:02 AM
On Tue, 2010-10-12, Richard wrote:
> Jorgen Grahn <grahn+nntp@snipabacken.se> spake the secret code
> <slrnib84u4.dlt.grahn+nntp@frailea.sa.invalid> thusly:
>
>>On Mon, 2010-10-11, Richard wrote:
>>> [Please do not mail me a copy of your followup]
>>>
>>> Jorgen Grahn <grahn+nntp@snipabacken.se> spake the secret code
>>> <slrnib73vd.dlt.grahn+nntp@frailea.sa.invalid> thusly:
>>>
>>>>Read the book. He describes his (and others') way of reasoning and the
>>>>massive field experience he collected in order to make a decision.
>>>
>>> Given that this was published in 1994 and C++ has evolved considerably
>>> since then,
>>
>>From my point of view it hasn't really -- the situation in 1994 seemed
>>to be pretty much what was standardized in 1998.
>
> Really?  I consider the new uses of auto, lambda functions, rvalue
> references, move semantics and perfect forwarding and other changes in
> C++0x to be pretty big changes.

The key is "from my point of view" -- I haven't looked at C++0x yet. I
suspect it's less fun to read about the design and evolution of things
you haven't used yet ... and less fun to read about standards work,
than about a few bearded guys cooking up new languages at Bell Labs!

>>A chronicle of the C++ "community" since 1994 would be interesting to
>>read. But probably difficult to write ...
>
> Dunno about the interesting part, it would really depend on who was
> editor/guiding force of such an effort.  However, I really agree about
> the difficulty! :-)

:-)

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .  .
\X/     snipabacken.se>   O  o   .
0
Jorgen
10/13/2010 2:58:11 PM
On Wed, 13 Oct 2010 10:01:02 +0100, RedGrittyBrick wrote:

> On 13/10/2010 00:43, Martin Gregorie wrote:
>> On Tue, 12 Oct 2010 19:19:55 +0100, Tom Anderson wrote:
>>
>>> 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.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |
0
Martin
10/13/2010 4:43:07 PM
On Tue, 12 Oct 2010, Daniel Pitts wrote:

> On 10/12/2010 8:07 PM, Mike Schilling wrote:
>
>> "Daniel Pitts" <newsgroup.spamfilter@virtualinfinity.net> wrote in
>> message news:eg4to.720$ql4.421@newsfe23.iad...
>>> On 10/10/2010 11:18 PM, 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.
>>>> 
>>>> 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?
>> 
>> 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?

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

tom

-- 
Indeed, as rarely as remix albums work out for the best, this record
bottoms out on par with Weezer tribute albums, deployed WMDs and birth
defects. -- Nick Sylvester, on 'Daft Club'
0
Tom
10/13/2010 6:53:40 PM
Rui Maciel wrote:
> Dann Corbit wrote:
>
>> 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 {};).

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.



0
Jon
10/14/2010 4:33:50 AM
Joshua Cranmer wrote:
> 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,

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.

>
>> 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.

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. 


0
Jon
10/14/2010 4:41:38 AM
Jim Janney wrote:
> Joshua Cranmer <Pidgeot18@verizon.invalid> writes:
>
>> 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.

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


0
Jon
10/14/2010 4:44:02 AM
James Dow Allen wrote:
> On Oct 9, 2:09 am, Alexander <alva...@gmail.com> wrote:
>> ... 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?  :-)

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?).

>
> James Dow Allen 


0
Jon
10/14/2010 4:57:47 AM
Ian Collins wrote:
> 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.

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


0
Jon
10/14/2010 4:58:56 AM
Ian Collins wrote:
> On 10/ 9/10 11:12 PM, Ben Bacarisse wrote:
>> Ian Collins<ian-news@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?

That can be done in C? (I forget, because I use a C++ compiler), but, I 
think your point of syntax/semantics is fundamentally elevatable akin to 
raising locks to a higher level (but I have no handy example). 


0
Jon
10/14/2010 5:02:39 AM
Felix Palmen wrote:
> * Ian Collins <ian-news@hotmail.com>:
>> On 10/ 9/10 11:12 PM, Ben Bacarisse wrote:
>>> Ian Collins<ian-news@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.

What about loop vars? Same thing?

for (int i = 0; i < 100; i++)
    // blah with i

Isn't that effectively the same as "in the middle of a scope"?

> 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 


0
Jon
10/14/2010 5:05:29 AM
Ian Collins wrote:
> On 10/10/10 01:28 AM, Felix Palmen wrote:
>> * Ian Collins<ian-news@hotmail.com>:
>>> On 10/ 9/10 11:12 PM, Ben Bacarisse wrote:
>>>> Ian Collins<ian-news@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 wonder about people (their ability to program anything) that comment 
profusely.



0
Jon
10/14/2010 5:07:52 AM
Tim Streater wrote:
> In article
> <9ae021aa-dc20-4dfe-8dab-ea176d104e62@l38g2000pro.googlegroups.com>,
> James Dow Allen <jdallen2000@yahoo.com> wrote:
>
>> (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;
>> )
>
> 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).
>
> Too late to change now, though.

It's never too late to learn an assembly language. :) 


0
Jon
10/14/2010 5:13:17 AM
Felix Palmen wrote:
> * Tim Streater <timstreater@waitrose.com>:
>> 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.

The C one-upper (C++) has that unwritten rule of thumb.

> 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.

Sounds like another language and not C, not sure.



0
Jon
10/14/2010 5:15:54 AM
BartC wrote:
> "James Dow Allen" <jdallen2000@yahoo.com> wrote in message
> news:9ae021aa-dc20-4dfe-8dab-ea176d104e62@l38g2000pro.googlegroups.com...
>> On Oct 9, 2:09 am, Alexander <alva...@gmail.com> wrote:
>>> ... 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.

I think it may be regular at the expense of being clear, and I'm leaning 
toward the conclusion that the regularity is a defficiency:

int a[100]; // ugly
int[100] a; // nice

I understand that the ugly syntax may be a compiler-writer's friend, but 
at this juncture I am drawing a line at a different place than the C 
language does.

(In the above though, who uses primitive arrays anyway?).

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

Definitely undone work but I don't think anyone has implemented a good 
solution. Some languages have "modules", for example, but supposedly they 
are less scalable than C header files/source files.

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

Java = play in the sandbox I give you/move to the cloud where we can 
control you/be in power. 


0
jomar (6)
10/14/2010 5:26:26 AM
Nick Keighley wrote:
> use typedef (which should be called typealias)

#define Alias typedef

If the preprocessor is not your friend, then C will be your enemy. You're 
welcome.




0
Jon
10/14/2010 5:29:19 AM
* Jon <jomar@spblocker.net>:
> Felix Palmen wrote:
>> * Ian Collins <ian-news@hotmail.com>:
>>> 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.
> 
> What about loop vars? Same thing?
> 
> for (int i = 0; i < 100; i++)
>    // blah with i
> 
> Isn't that effectively the same as "in the middle of a scope"?

No, a loop is its own scope where the block delimeters /can/ be omitted
for a single-statement body (but this is often discouraged in coding
conventions).

Regards, Felix

-- 
 Felix Palmen       (Zirias)  + [PGP] Felix Palmen <felix@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
0
felix
10/14/2010 5:31:53 AM
* Jon <jomar@spblocker.net>:
> I think it may be regular at the expense of being clear, and I'm leaning 
> toward the conclusion that the regularity is a defficiency:
> 
> int a[100]; // ugly
> int[100] a; // nice

This is exactly the same discussion as for pointer declarations. Either
the attributes like pointer or array are considered part of the type, or
the type only applies to the actual stored data, leaving pointer and
array as attributes of the individual variable. You can't really
proclaim one of those "ugly", as long as it's consistent in the
language. It comes down to a matter of taste and, of course, of what
you're used to.

Regards,
Felix

-- 
 Felix Palmen       (Zirias)  + [PGP] Felix Palmen <felix@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
0
felix
10/14/2010 6:03:10 AM
Felix Palmen wrote:
> * Jon <jomar@spblocker.net>:
>> Felix Palmen wrote:
>>> * Ian Collins <ian-news@hotmail.com>:
>>>> 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.
>>
>> What about loop vars? Same thing?
>>
>> for (int i = 0; i < 100; i++)
>>    // blah with i
>>
>> Isn't that effectively the same as "in the middle of a scope"?
>
> No,

OK.

> a loop is its own scope

Hello, duh.

> where the block delimeters /can/ be
> omitted for a single-statement body

Advanced topics in language implementation and compiler design then, yes?

> (but this is often discouraged in
> coding conventions).

"they" are wrong and *I* am right on this one (it's worth it):

if(you_suck)
{
    do_unnecessary_parenthetic_eww_parents_suck();
}

if (i_rock)
    kiss_me_kate();

/*----------

Nuff said?

------ (now about this ugly comnent syntax...)
*/


0
Jon
10/14/2010 6:21:55 AM
August Karlstrom wrote:
> 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
> 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.
>

The litmus test (C syntax):

a  = sqrt(b^2 + c^2)

Anyone suggesting anything is more obvious (about the equal symbol) than 
the above is a dufus. a "equals what I tell you it equals", *I* am the 
programmer. The STATEMENT (not a ponderance), says, evaluate that 
expression and put the result where *I* wanted. (What all you 
mathematicians are up about, I will consider).





0
Jon
10/14/2010 6:39:18 AM
Rui Maciel wrote:
> BartC wrote:
>
>> 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.
>

Gee, I wish I had a retirement plan too. :P 


0
Jon
10/14/2010 6:40:17 AM
Nick Keighley wrote:
> On 10 Oct, 02:24, Richard <rgrd...@gmail.com> wrote:
>> August Karlstrom <fusionf...@gmail.com> writes:
>>> On 2010-10-08 21:09, Alexander wrote:
>
> <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

That's not the point of course, but... ?

>
> <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.

IOW, shut up or put up?

>
>> := 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?

For us "posterity", what was the "problem" you referred to?



0
Jon
10/14/2010 6:46:39 AM
In article <i963h3$3f5$1@news.eternal-september.org>,
 "Jon" <jomar@spblocker.net> wrote:

> Tim Streater wrote:
> > In article
> > <9ae021aa-dc20-4dfe-8dab-ea176d104e62@l38g2000pro.googlegroups.com>,
> > James Dow Allen <jdallen2000@yahoo.com> wrote:
> >
> >> (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;
> >> )
> >
> > 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).
> >
> > Too late to change now, though.
> 
> It's never too late to learn an assembly language. :) 

Indeed. And in my case its 68000 asm which I'm using at the moment.

-- 
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted"  --  Bill of Rights 1689
0
Tim
10/14/2010 8:28:32 AM
On 13/10/2010 17:43, Martin Gregorie wrote:
> On Wed, 13 Oct 2010 10:01:02 +0100, RedGrittyBrick wrote:
>
>> On 13/10/2010 00:43, Martin Gregorie wrote:
>>> On Tue, 12 Oct 2010 19:19:55 +0100, Tom Anderson wrote:
>>>
>>>> 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.
>
>

Oh OK. I thought penne were the "pen shaped" short diagonally-cut tubes.

It all makes perfect sense now.

-- 
RGB
0
RedGrittyBrick
10/14/2010 8:36:33 AM

"Felix Palmen" <felix@palmen-it.de> wrote in message 
news:N3e8I4cb69d1eT3be4@erwin.home.palmen-it.de...
> * Jon <jomar@spblocker.net>:
>> I think it may be regular at the expense of being clear, and I'm leaning
>> toward the conclusion that the regularity is a defficiency:
>>
>> int a[100]; // ugly
>> int[100] a; // nice
>
> This is exactly the same discussion as for pointer declarations. Either
> the attributes like pointer or array are considered part of the type, or
> the type only applies to the actual stored data, leaving pointer and
> array as attributes of the individual variable. You can't really
> proclaim one of those "ugly", as long as it's consistent in the
> language. It comes down to a matter of taste and, of course, of what
> you're used to.

In some contexts, a pointer/array attribute is part of the variable, eg. in 
declarations (and the dereference appears on the left).

In other contexts, a pointer/array attribute is part of the type, eg. in 
casts (and the dereference symbol appears on the right).

So it's also inconsistent.

-- 
Bartc 

0
BartC
10/14/2010 10:15:46 AM
Jon posted this message in ROT13 encoding:

> Joshua Cranmer wrote:
>
>>  semicolon-terminated >> statements,
>
> A bad thing.
>
>> the use of `\' as an escape character,
>
> A bad thing.

I disagree.

-- 
The Czechs announced after Sputnik that they, too, would launch a satellite.
Of course, it would orbit Sputnik, not Earth!
0
Chris
10/14/2010 10:29:24 AM
"Rui Maciel" <rui.maciel@gmail.com> wrote in message
news:4cb18204$0$16134$a729d347@news.telepac.pt...
> BartC wrote:
>
>> 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,

I don't know how you deduced that from my statement.

I can program C if I have to; it's a simple enough language, if you look
beyond the syntax. (Something that can't be said for C++, even if it's 
syntax were to look more like Basic.)

> which clearlly is not a problem related to the design of the C programming
> language.

I think it was (though not necessarily the fault of C, since the choice of
"=" over ":=" or whatever was reasonable enough in the 1960s).

-- 
Bartc 

0
BartC
10/14/2010 10:37:44 AM
"RedGrittyBrick" <RedGrittyBrick@spamweary.invalid> wrote in message 
news:4cb6c113$0$12156$fa0fcedb@news.zen.co.uk...
> On 13/10/2010 17:43, Martin Gregorie wrote:

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

> Oh OK. I thought penne were the "pen shaped" short diagonally-cut tubes.

They are.

-- 
Bartc 

0
BartC
10/14/2010 10:48:22 AM
On Wed, 13 Oct 2010, Jon wrote:

> Joshua Cranmer wrote:
>
>> the use of `\' as an escape character,
>
> A bad thing.

Bullshit. Justify this or strangle yourself immediately.

tom

-- 
you can't feel your stomack with glory -- Czako
0
Tom
10/14/2010 11:48:14 AM
On 2010-10-14 08:39, Jon wrote:
> The litmus test (C syntax):
>
> a  = sqrt(b^2 + c^2)
>
> Anyone suggesting anything is more obvious (about the equal symbol) than
> the above is a dufus. a "equals what I tell you it equals", *I* am the
> programmer. The STATEMENT (not a ponderance), says, evaluate that
> expression and put the result where *I* wanted. (What all you
> mathematicians are up about, I will consider).

If you apply your reasoning to a = a + 1 you will see the problem.


/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
0
August
10/14/2010 12:05:44 PM
"Jon" <jomar@spblocker.net> writes:

> James Dow Allen wrote:
>> On Oct 9, 2:09 am, Alexander <alva...@gmail.com> wrote:
>>> ... anything you do not like in the C ... syntax.
>>
>> I'll offer 2 cents worth:
<snip>
>> (2) Some will mention the second-class nature of arrays
>> as being bad.
>
> Explain please "second class nature of arrays".

The term has a standard meaning in this sort of context:
http://en.wikipedia.org/wiki/First-class_object

<snip>
-- 
Ben.
0
Ben
10/14/2010 12:10:25 PM
"Jon" <jomar@spblocker.net> writes:

> August Karlstrom wrote:
<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.
>>
>
> The litmus test (C syntax):
>
> a  = sqrt(b^2 + c^2)
>
> Anyone suggesting anything is more obvious (about the equal symbol) than 
> the above is a dufus. a "equals what I tell you it equals", *I* am the 
> programmer. The STATEMENT (not a ponderance), says, evaluate that 
> expression and put the result where *I* wanted. (What all you 
> mathematicians are up about, I will consider).

Given the "dufus" remark, it's possible that you are not bothered about
having a debate, but assignment it very different from "making this
equal that".  If the type of 'a' is int, for example, a = E; may leave
a != E in many cases.

This is, in part, an argument that quality and assignment should use
different symbols (and C complies with this) but because assignment is
asymmetric, it's a shame that the symbol isn't similarly asymmetric.
Both := and an arrow have that in their favour.  It's also an argument
that assignment should not be so similar to equality that people forget
the difference, but this is almost a psychological point rather than a
programming one.

A couple of minor points: what you wrote is an expression not a
statement.  It would be a statement if it had a trailing semi-colon.
Secondly, I presume that the xor b^2 is written in jest, yes?  [For
anyone new to C reading this, C does not have an exponentiation
operator.]

-- 
Ben.
0
Ben
10/14/2010 12:45:15 PM
* BartC <bc@freeuk.com>:
> In other contexts, a pointer/array attribute is part of the type, eg. in 
> casts (and the dereference symbol appears on the right).

Alright, I really forgot about casts. I tend to write tham like this:

T *foo = (T *)bar;

But of course, this is just some cosmetic. If one would remove these
attributes from the type in casting, the possibility to cast between
pointers and values would disappear. Is it really needed?

Regards,
Felix

-- 
 Felix Palmen       (Zirias)  + [PGP] Felix Palmen <felix@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
0
felix
10/14/2010 1:14:25 PM
"Jon" <jomar@spblocker.net> writes:
> Nick Keighley wrote:
>> use typedef (which should be called typealias)
>
> #define Alias typedef
>
> If the preprocessor is not your friend, then C will be your enemy. You're 
> welcome.

If I'm reading code that uses typedef, I have to understand how typedef
works.

If I'm reading code that uses your "Alias" macro, I still have to
understand how typedef works -- *and* that "Alias" means typedef.

It doesn't help.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
0
Keith
10/14/2010 3:43:27 PM
On 2010-10-14, RedGrittyBrick <RedGrittyBrick@spamweary.invalid> wrote:
> Oh OK. I thought penne were the "pen shaped" short diagonally-cut tubes.

Yes.  A similar argument explains manicotti.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@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.
0
Seebs
10/14/2010 6:48:41 PM
On Thu, 14 Oct 2010, Seebs wrote:

> On 2010-10-14, RedGrittyBrick <RedGrittyBrick@spamweary.invalid> wrote:
>> Oh OK. I thought penne were the "pen shaped" short diagonally-cut tubes.
>
> Yes.  A similar argument explains manicotti.

I have no opinions or knowledge to share on this, but i am genuinely 
really hungry now.

tom

-- 
I believe there is no philosophical high-road in science, with
epistemological signposts. No, we are in a jungle and find our way by
trial and error, building our road behind us as we proceed. -- Max Born
0
Tom
10/14/2010 6:55:38 PM
"Seebs" <usenet-nospam@seebs.net> wrote in message 
news:slrnibek5o.fc7.usenet-nospam@guild.seebs.net...
> On 2010-10-14, RedGrittyBrick <RedGrittyBrick@spamweary.invalid> wrote:
>> Oh OK. I thought penne were the "pen shaped" short diagonally-cut tubes.
>
> Yes.  A similar argument explains manicotti.

The one that amuses me is "ziti". http://recipes.wikia.com/wiki/Ziti

It comes from a word meaning "bridegroom". One pasta book I had claimed not 
to know why that was. I couldn't tell if the author was truly ignorant, or 
couldn't, as they say, find a suitably delicate way of expressing the 
relationship. A web search informs me that the original ziti were much 
larger.




Brian
-- 
Day 617 of the "no grouchy usenet posts" project.


0
Default
10/14/2010 9:20:32 PM
BartC wrote:

>> That statement leads to believe that you delved into a "sizeable C
>> project" without even knowing how
>> to program in C,
> 
> I don't know how you deduced that from my statement.

This is not up to debate: if you fail to understand how to assign values to variables in a 
programming language then you simply don't know how to use it.  You simply can't hack away Pascal 
code in a text file with a .c extension and not only expect it to be C but also complain that the 
compiler throws syntax errors.


Rui Maciel
0
Rui
10/14/2010 11:28:07 PM
Jon wrote:

> 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.

Nonsense. 


Rui Maciel
0
Rui
10/14/2010 11:30:03 PM

"Rui Maciel" <rui.maciel@gmail.com> wrote in message 
news:4cb79208$0$6656$a729d347@news.telepac.pt...
> BartC wrote:
>
>>> That statement leads to believe that you delved into a "sizeable C
>>> project" without even knowing how
>>> to program in C,
>>
>> I don't know how you deduced that from my statement.
>
> This is not up to debate: if you fail to understand how to assign values 
> to variables in a
> programming language then you simply don't know how to use it.

Yes, when I sometimes fumble for the gear stick in a left-hand-drive car, 
after normally using right-hand-drive, it means I don't know how to drive.

The project happened to be mixed language. Also, the problem wasn't so much 
using ":=" in C, which is quickly picked up as a syntax error, as using "=" 
in the other language, which was still legal but did bad things that were 
hard to track down.

Since I'd used the other language for many years (having invented it), I 
don't think the problem was not knowing how to use it. Just getting muddled 
(because the designers of C inconsiderately used the wrong assignment 
symbol...)


-- 
Bartc
 

0
BartC
10/15/2010 12:07:44 AM
"BartC" <bc@freeuk.com> writes:

> The project happened to be mixed language. Also, the problem wasn't so
> much using ":=" in C, which is quickly picked up as a syntax error, as
> using "=" in the other language, which was still legal but did bad
> things that were hard to track down.
>
> Since I'd used the other language for many years (having invented it),
> I don't think the problem was not knowing how to use it. Just getting
> muddled (because the designers of C inconsiderately used the wrong
> assignment symbol...)

I'm programming in a mixed environment of C, Javascript, a HTML
templating language with loop constructs and a home-brew scripting
language.  Not to mention little bits of embedded SQL, make files and
similar.

It's not that uncommon to get an error because I've put a semicolon on
the end of a line in the scripting language, or used == in it.
-- 
Online waterways route planner            | http://canalplan.eu
Plan trips, see photos, check facilities  | http://canalplan.org.uk
0
3-nospam (285)
10/15/2010 7:22:10 AM
On Oct 10, 2:04=A0am, August Karlstrom <fusionf...@gmail.com> wrote:
> 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 `=3D' 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 `=3D=3D'. In code comments it also makes the usage of
> the mathematical `=3D' slightly ambiguous which forces people to use `=3D=
=3D'
> instead. UGLY is the word.
>
> It's a shame that a left arrow is not in the (7 bit) ASCII table. IMHO
> `:=3D' is second best to the left arrow.

I don't know. I learnt C pretty young, and I was able to distinguish
between '=3D' and '=3D=3D', thanks to three subtle notions:

a) They differ by one character.
b) I knew the quantitative difference between 1 (one) and 2 (two).
c) I was told they had different behaviour.

If one is not competent enough to be able to differentiate between
them, I weep for minds younger than mine. Or actually, I don't, screw
them.

Disclaimer: Of course I've had my fair share of 'if(a=3D0)' bugs. To err
is human.
0
Michael
10/15/2010 7:22:49 AM
"Nick" <3-nospam@temporary-address.org.uk> wrote in message 
news:87lj5zsyxp.fsf@temporary-address.org.uk...
> "BartC" <bc@freeuk.com> writes:
>
>> The project happened to be mixed language. Also, the problem wasn't so
>> much using ":=" in C, which is quickly picked up as a syntax error, as
>> using "=" in the other language, which was still legal but did bad
>> things that were hard to track down.

> I'm programming in a mixed environment of C, Javascript, a HTML
> templating language with loop constructs and a home-brew scripting
> language.  Not to mention little bits of embedded SQL, make files and
> similar.

> It's not that uncommon to get an error because I've put a semicolon on
> the end of a line in the scripting language, or used == in it.

I've tended to use my own syntax for the last 30 years, but as I said, the 
problem was picking up C habits too well! Writing "=" in the wrong language, 
as well as sprinkling semicolons everywhere as you mentioned (fortunately 
the other language didn't care about extra semicolons, the only problem was 
developing RSI sooner..)

Another problem was mistakenly using the "!" comment-to-end-of-line symbol 
from the other syntax in C, where it often isn't a syntax error (and my 
editor highlights it as comment, which doesn't help). However lines with "!" 
in front of them still get executed in C, with unexpected results...

-- 
Bartc 

0
BartC
10/15/2010 10:25:19 AM
"Michael Foukarakis" <electricdelta@gmail.com> wrote in message 
news:21ed201b-4880-484e-ae11-2f1e223ff8fc@j25g2000yqa.googlegroups.com...
> On Oct 10, 2:04 am, August Karlstrom <fusionf...@gmail.com> wrote:
>> 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
>> 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.
>
> I don't know. I learnt C pretty young, and I was able to distinguish
> between '=' and '==', thanks to three subtle notions:
>
> a) They differ by one character.
> b) I knew the quantitative difference between 1 (one) and 2 (two).
> c) I was told they had different behaviour.

Until you also use a second language where the meanings of "=" and "==" are 
reversed. Yet (a), (b) and (c) are still true for each language.

In fact, in the real world outside of C programming, "=" to mean equality is 
pretty much universal.

-- 
Bartc 

0
BartC
10/15/2010 12:28:35 PM
"BartC" <bc@freeuk.com> wrote in message 
news:i8phfl$5s4$1@news.eternal-september.org...

> ...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...
> (C) Type declaration syntax...
> (D) Make-file syntax...

Perhaps one more can be added:

(E) Compiler options

(The gcc.info file that comes with gcc lists some 1300 options, with other 
stuff inside a 27000-line file (about 500 pages when printed out..))

-- 
Bartc  
0
BartC
10/15/2010 2:15:13 PM
On 14 Oct, 05:33, "Jon" <jo...@spblocker.net> wrote:
> Rui Maciel wrote:
> > Dann Corbit wrote:
>
> >> 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 {};).
>
> 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.

and what, pray tell, do you think they write, say, C++ std::string in?
I know std::string is actually a template but it doesn't have to be.
You can write opaque types in C.
0
Nick
10/15/2010 2:38:37 PM
BartC wrote:

> I don't know how you deduced that from my statement.

After re-reading this particular branch of this discussion I have to say that not only my reading 
comprehension skills failed me miserably but that also my replies were inappropriate.  My apologies.

 The truth is that, even with a bit of practice, it's quite possible for an experienced C programmer 
to have, let's say, a moment of weakness and inadvertently mix up "=" with "==" in some point in the 
code, which could in turn cause problems that can be a bit hard to find.  There is a good reason why 
programs such as lint were developed to check for this type of problem.

With that under consideration, adopting some other syntax for the assignment operator (i.e., ":=" 
for example) could have been a small step that would have go a long way to avoid this sort of 
problems.


Rui Maciel
0
Rui
10/15/2010 2:53:16 PM
"BartC" <bc@freeuk.com> writes:
<snip>
> In fact, in the real world outside of C programming, "=" to mean
> equality is pretty much universal.

I have no idea how far from universal "pretty much universal" is but I
can think of:

    B C++ C# Objective-C D Haskell Java PHP (two equality operators
    neither of which is =) Perl Python Fortran (again two, == and .eg.)
    Ruby Lua Scala Erlang (two again) Algol 68 (one the two is not =)
    Prolog TCL

and probably others.  How many would make it not pretty much universal?

-- 
Ben.
0
Ben
10/15/2010 3:55:04 PM
On 10/15/2010 10:53 AM, Rui Maciel wrote:
> BartC wrote:
>
>> I don't know how you deduced that from my statement.
>
> After re-reading this particular branch of this discussion I have to say that not only my reading
> comprehension skills failed me miserably but that also my replies were inappropriate.  My apologies.
>
>   The truth is that, even with a bit of practice, it's quite possible for an experienced C programmer
> to have, let's say, a moment of weakness and inadvertently mix up "=" with "==" in some point in the
> code, which could in turn cause problems that can be a bit hard to find.  There is a good reason why
> programs such as lint were developed to check for this type of problem.
>
> With that under consideration, adopting some other syntax for the assignment operator (i.e., ":="
> for example) could have been a small step that would have go a long way to avoid this sort of
> problems.
>
>
> Rui Maciel

The xBASE languages use the = sign for both assignment and equality by 
examining the context in which it is used. For example:

a = 42

is an assignment and..

if a = 42

is a test for equality.

-- 
Joe Wright
"If you rob Peter to pay Paul you can depend on the support of Paul."
0
Joe
10/15/2010 4:23:02 PM
Joe Wright <joewwright@comcast.net> writes:

> The xBASE languages use the = sign for both assignment and equality by
> examining the context in which it is used.

So does, for example, BASIC.
-- 
Ben Pfaff 
http://benpfaff.org
0
Ben
10/15/2010 4:32:49 PM
On 10/15/2010 12:23 PM, Joe Wright wrote:
[...]
> The xBASE languages use the = sign for both assignment and equality by
> examining the context in which it is used. For example:
>
> a = 42
>
> is an assignment and..
>
> if a = 42
>
> is a test for equality.

But, you apparently can't do things like:

     if ( f = fopen(filename,mode) )
or
     while ( pt = NextItem() )

True, I would write them:

     if ( (f = fopen(filename,mode)) != NULL )
or
     while ( (pt = NextItem()) != NULL)

but it appears that there would be no equivalent in xBase.

-- 
Kenneth Brody
0
Kenneth
10/15/2010 4:33:48 PM
In article <o7SdnWHjk7vxHyXRnZ2dnUVZ_rWdnZ2d@bestweb.net>,
 Kenneth Brody <kenbrody@spamcop.net> wrote:

> On 10/15/2010 12:23 PM, Joe Wright wrote:
> [...]
> > The xBASE languages use the = sign for both assignment and equality by
> > examining the context in which it is used. For example:
> >
> > a = 42
> >
> > is an assignment and..
> >
> > if a = 42
> >
> > is a test for equality.
> 
> But, you apparently can't do things like:
> 
>      if ( f = fopen(filename,mode) )
> or
>      while ( pt = NextItem() )
> 
> True, I would write them:
> 
>      if ( (f = fopen(filename,mode)) != NULL )
> or
>      while ( (pt = NextItem()) != NULL)
> 
> but it appears that there would be no equivalent in xBase.

And quite right too. I find it egregious that people think it OK that a 
side effect of testing something is to put a packet on the wire. Keep 
things nicely separated and we shall get on.

-- 
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted"  --  Bill of Rights 1689
0
Tim
10/15/2010 4:55:14 PM
* Ben Bacarisse <ben.usenet@bsb.me.uk>:
> "BartC" <bc@freeuk.com> writes:
> <snip>
>> In fact, in the real world outside of C programming, "=" to mean
>> equality is pretty much universal.
> 
> I have no idea how far from universal "pretty much universal" is but I
> can think of:

You should probably widen your scope a little in order to understand
Bart's statement. This is not just about programming languages -- there
are of course quite a few borrowing this stupid idea from C. Oh, and I
don't mean to bash C ... it's just ONE really poor decision in the
language's syntax and this thread is all about hypothetical
improvements.

Regards,
Felix

-- 
 Felix Palmen       (Zirias)  + [PGP] Felix Palmen <felix@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
0
felix
10/15/2010 5:16:53 PM
On 2010-10-15, Michael Foukarakis <electricdelta@gmail.com> wrote:
> I don't know. I learnt C pretty young, and I was able to distinguish
> between '=' and '==', thanks to three subtle notions:

Oh, I can distinguish between them.  It's just that I'm much more likely
to get them wrong than I am more-distinct operators.  Especially if I've
recently been working in a language that uses '=' for comparison.  Basically,
if you present me with an otherwise mostly correct piece of code that uses
= where it should have been ==, it's quite possible for me to miss it,
especially if there are other errors which are more obvious.

I do not think C would have been a worse language had the assignment operator
been more obviously distinct, such as :=, but it wasn't, so here we are.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@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.
0
Seebs
10/15/2010 5:20:43 PM
On 2010-10-15 17:55, Ben Bacarisse wrote:
> "BartC"<bc@freeuk.com>  writes:
> <snip>
>> In fact, in the real world outside of C programming, "=" to mean
>> equality is pretty much universal.
>
> I have no idea how far from universal "pretty much universal" is but I
> can think of:
>
>      B C++ C# Objective-C D Haskell Java PHP (two equality operators
>      neither of which is =) Perl Python Fortran (again two, == and .eg.)
>      Ruby Lua Scala Erlang (two again) Algol 68 (one the two is not =)
>      Prolog TCL
>
> and probably others.  How many would make it not pretty much universal?

I think Bart means in the real world outside of computer programming. To 
everyone who has not been exposed to programming for instance.


/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
0
August
10/15/2010 5:24:14 PM
On 2010-10-15 16:15, BartC wrote:
> (The gcc.info file that comes with gcc lists some 1300 options, with
> other stuff inside a 27000-line file (about 500 pages when printed out..))

Holy cow, where is the emergency break?


/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
0
August
10/15/2010 5:40:02 PM
August Karlstrom <fusionfile@gmail.com> writes:
> On 2010-10-15 17:55, Ben Bacarisse wrote:
>> "BartC"<bc@freeuk.com>  writes:
>> <snip>
>>> In fact, in the real world outside of C programming, "=" to mean
>>> equality is pretty much universal.
>>
>> I have no idea how far from universal "pretty much universal" is but I
>> can think of:
>>
>>      B C++ C# Objective-C D Haskell Java PHP (two equality operators
>>      neither of which is =) Perl Python Fortran (again two, == and .eg.)
>>      Ruby Lua Scala Erlang (two again) Algol 68 (one the two is not =)
>>      Prolog TCL
>>
>> and probably others.  How many would make it not pretty much universal?
>
> I think Bart means in the real world outside of computer programming. To 
> everyone who has not been exposed to programming for instance.

Agreed.

The use of "==" for equality was introduced by B, as far as I
can tell (B's ancestor BCPL apparently used "=").  I suspect that
there are few, if any, uses of "==" to denote equality that are
not directly or indirectly influenced by its use in the B and
C languages.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
0
Keith
10/15/2010 5:47:19 PM
felix@palmen-it.de (Felix Palmen) writes:

> * Ben Bacarisse <ben.usenet@bsb.me.uk>:
>> "BartC" <bc@freeuk.com> writes:
>> <snip>
>>> In fact, in the real world outside of C programming, "=" to mean
>>> equality is pretty much universal.
>> 
>> I have no idea how far from universal "pretty much universal" is but I
>> can think of:
>
> You should probably widen your scope a little in order to understand
> Bart's statement. This is not just about programming languages -- there
> are of course quite a few borrowing this stupid idea from C. Oh, and I
> don't mean to bash C ... it's just ONE really poor decision in the
> language's syntax and this thread is all about hypothetical
> improvements.

I just wanted to show that it's not a rare notation.  I'm not saying
it's good or bad (I've given an opinion elsewhere in the thread) nor am
I saying all those languages choose their equality operators
independently.  Non-programming uses seem to be a red herring because I
don't see people up in arms about * for multiplication or ! for not or
any other deviation from "real world" use.  == for equality is far less
peculiar than any of these.

A computer language chooses a set of symbols that you have to learn --
normally they won't be absurd (< for equality and * for assignment would
really annoy me) but I can't get worked up about slightly infelicitous
choices such as = for assignment.

-- 
Ben.
0
Ben
10/15/2010 6:19:11 PM
* Ben Bacarisse <ben.usenet@bsb.me.uk>:
> I just wanted to show that it's not a rare notation.  I'm not saying
> it's good or bad (I've given an opinion elsewhere in the thread) nor am
> I saying all those languages choose their equality operators
> independently.  Non-programming uses seem to be a red herring because I
> don't see people up in arms about * for multiplication or ! for not or
> any other deviation from "real world" use.  == for equality is far less
> peculiar than any of these.

The mathematical symbols for multiplication (·) and negation (¬) are not
in US (7bit) ascii and/or not reachable on a standard PC keyboard. So, I
see your point, but I think there is still a difference…

> A computer language chooses a set of symbols that you have to learn --
> normally they won't be absurd (< for equality and * for assignment would
> really annoy me) but I can't get worked up about slightly infelicitous
> choices such as = for assignment.

I don't say it's that hard to get used to it, but still, it just wasn't
the best possible choice. Not only is "==" for equality different from
the usual symbol, but also is the standard symbol used for something
different.

Regards,
Felix

-- 
 Felix Palmen       (Zirias)  + [PGP] Felix Palmen <felix@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
0
felix
10/15/2010 6:37:52 PM
felix@palmen-it.de (Felix Palmen) writes:
[...]
> I don't say it's that hard to get used to it, but still, it just wasn't
> the best possible choice. Not only is "==" for equality different from
> the usual symbol, but also is the standard symbol used for something
> different.

Oh?  What else is "== used for?

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
0
Keith
10/15/2010 7:39:11 PM
Keith Thompson <kst-u@mib.org> writes:

> August Karlstrom <fusionfile@gmail.com> writes:
>> On 2010-10-15 17:55, Ben Bacarisse wrote:
>>> "BartC"<bc@freeuk.com>  writes:
>>> <snip>
>>>> In fact, in the real world outside of C programming, "=" to mean
>>>> equality is pretty much universal.
>>>
>>> I have no idea how far from universal "pretty much universal" is but I
>>> can think of:
>>>
>>>      B C++ C# Objective-C D Haskell Java PHP (two equality operators
>>>      neither of which is =) Perl Python Fortran (again two, == and .eg.)
>>>      Ruby Lua Scala Erlang (two again) Algol 68 (one the two is not =)
>>>      Prolog TCL
>>>
>>> and probably others.  How many would make it not pretty much universal?
>>
>> I think Bart means in the real world outside of computer programming. To 
>> everyone who has not been exposed to programming for instance.
>
> Agreed.

Yes, I agree that is what he meant, but = in mathematics is not at all
the same kind of beast as the equality operator in a programming
language.  x = y + 1 is not an expression with a value -- it is a kind
of definition (or maybe a constraint).  I am not at all bothered that
the operator which produces 0 or 1 from a comparison is written
differently.

> The use of "==" for equality was introduced by B, as far as I
> can tell (B's ancestor BCPL apparently used "=").

Did you mean to type ":="?  BCPL uses ":=" (and it's not an operator).

>  I suspect that
> there are few, if any, uses of "==" to denote equality that are
> not directly or indirectly influenced by its use in the B and
> C languages.

I think Haskell is a possible counter example.  It uses = for
definitions which is the natural choice and therefore something else is
needed for the non-mathematical operator that compares things.  Of
course, it's not possible to say that it did not "come from C" but it's
a natural choice.

-- 
Ben.
0
Ben
10/15/2010 8:11:53 PM
* Keith Thompson <kst-u@mib.org>:
> felix@palmen-it.de (Felix Palmen) writes:
> [...]
>> I don't say it's that hard to get used to it, but still, it just wasn't
>> the best possible choice. Not only is "==" for equality different from
>> the usual symbol, but also is the standard symbol used for something
>> different.
> 
> Oh?  What else is "== used for?

Maybe try to read and think again? No, I wasn't referring to "==" as a
"standard symbol"?

-- 
 Felix Palmen       (Zirias)  + [PGP] Felix Palmen <felix@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
0
felix
10/15/2010 8:45:24 PM
* Ben Bacarisse <ben.usenet@bsb.me.uk>:
> Yes, I agree that is what he meant, but = in mathematics is not at all
> the same kind of beast as the equality operator in a programming
> language.  x = y + 1 is not an expression with a value -- it is a kind
> of definition (or maybe a constraint).  I am not at all bothered that
> the operator which produces 0 or 1 from a comparison is written
> differently.

It is NOT a definition. It is a claim. It reads: "x equals y + 1". Of
course, whoever writes anything like that is convinced that the claim
really is true. But whent it comes to expression evaluation, it's just
natural to check the claim and assign a boolean value to it.

Assignment is something completely different. You see assignment in
mathematics when defining a function:

f: x -> x²

So, the colon is the mathematical symbol for assignment. Following the
principle of least surprise, the colon should be used for assignment in
programming languages, too. That said, ":=" is still better (less
surprising) than just "=", which states equality in mathematics.

Regards,
Felix

-- 
 Felix Palmen       (Zirias)  + [PGP] Felix Palmen <felix@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
0
felix4560 (61)
10/15/2010 8:53:05 PM
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Keith Thompson <kst-u@mib.org> writes:
[...]
>> The use of "==" for equality was introduced by B, as far as I
>> can tell (B's ancestor BCPL apparently used "=").
>
> Did you mean to type ":="?  BCPL uses ":=" (and it's not an operator).

No, I meant "="; I was talking about equality, not assignment.
BCPL does use ":=" for assignment.

[...]

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
0
Keith
10/15/2010 9:38:59 PM
felix@palmen-it.de (Felix Palmen) writes:
> * Keith Thompson <kst-u@mib.org>:
>> felix@palmen-it.de (Felix Palmen) writes:
>> [...]
>>> I don't say it's that hard to get used to it, but still, it just wasn't
>>> the best possible choice. Not only is "==" for equality different from
>>> the usual symbol, but also is the standard symbol used for something
>>> different.
>> 
>> Oh?  What else is "== used for?
>
> Maybe try to read and think again? No, I wasn't referring to "==" as a
> "standard symbol"?

Ok, I *think* I understand what you were saying (but it took me
several re-readings).

You meant that "==" for equality is different from the usual symbol
("=") for equality, but also the standard symbol ("=") is used for
something else (assignment).

If you had written "... but also the standard symbol is used ..." I
would have found it less confusing.  Perhaps a language barrier?

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
0
Keith
10/15/2010 9:59:25 PM
felix@palmen-it.de (Felix Palmen) writes:

> * Ben Bacarisse <ben.usenet@bsb.me.uk>:
>> Yes, I agree that is what he meant, but = in mathematics is not at all
>> the same kind of beast as the equality operator in a programming
>> language.  x = y + 1 is not an expression with a value -- it is a kind
>> of definition (or maybe a constraint).  I am not at all bothered that
>> the operator which produces 0 or 1 from a comparison is written
>> differently.
>
> It is NOT a definition. It is a claim.

"Let x = y + 1" is often not a claim by the usual meaning of the word
(sometimes it's a claim -- let x = p/r for integer p and q might start a
proof by contradiction -- but it is not always a claim) but I really
don't want get into a fight about the definition of a very slippery
symbol.

> It reads: "x equals y + 1". Of
> course, whoever writes anything like that is convinced that the claim
> really is true. But whent it comes to expression evaluation, it's just
> natural to check the claim and assign a boolean value to it.

Except that is not done.  If it were the Kronecker delta function would
be obsolete.

> Assignment is something completely different. You see assignment in
> mathematics when defining a function:
>
> f: x -> x²

You also see f(x) = x².

We could go back a forth like all week long.  I accept that you see
things differently.  You see '=' (in maths) as a claim with a truth
value but that's not how I see it.  Let's agree to differ.

> So, the colon is the mathematical symbol for assignment. Following the
> principle of least surprise, the colon should be used for assignment in
> programming languages, too. That said, ":=" is still better (less
> surprising) than just "=", which states equality in mathematics.

Yes.  In fact I've agreed with this in the past.  I was only commenting
on '==' which I am happy to have as distinct from the mathematical
symbol '='.

-- 
Ben.
0
Ben
10/15/2010 10:22:51 PM
On 2010-10-15 22:53, Felix Palmen wrote:
> Assignment is something completely different. You see assignment in
> mathematics when defining a function:
>
> f: x ->  x²

This is a definition, not an assignment, at least not in a programming 
sense, since in a mathematical text you don't redefine f to be something 
else later on.


/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
0
August
10/15/2010 10:23:48 PM
Keith Thompson <kst-u@mib.org> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>> Keith Thompson <kst-u@mib.org> writes:
> [...]
>>> The use of "==" for equality was introduced by B, as far as I
>>> can tell (B's ancestor BCPL apparently used "=").
>>
>> Did you mean to type ":="?  BCPL uses ":=" (and it's not an operator).
>
> No, I meant "="; I was talking about equality, not assignment.
> BCPL does use ":=" for assignment.

Somehow I though you were talking about assignment despite some very
considerable evidence to the contrary!

-- 
Ben.
0
Ben
10/15/2010 10:24:13 PM
"Nick Keighley" <nick_keighley_nospam@hotmail.com> wrote in message 
news:4f688601-5344-41ec-a077-9b95c71e41d0@a37g2000yqi.googlegroups.com...
> On 14 Oct, 05:33, "Jon" <jo...@spblocker.net> wrote:
>> Rui Maciel wrote:
>> > Dann Corbit wrote:
>>
>> >> 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 {};).
>>
>> 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.
>
> and what, pray tell, do you think they write, say, C++ std::string in?

Note that string literals in C++ are not std::strings.

> I know std::string is actually a template but it doesn't have to be.
> You can write opaque types in C. 


0
Jon
10/16/2010 7:22:10 AM
"Rui Maciel" <rui.maciel@gmail.com> wrote in message
news:4cb7927b$0$6656$a729d347@news.telepac.pt...
> Jon wrote:
>
>> 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.
>
> Nonsense.
>

Try it and see. (I meant from the context of complete replacement of C 
strings, by working at the library level cannot be done).



0
Jon
10/16/2010 7:23:52 AM
"Tom Anderson" <twic@urchin.earth.li> wrote in message 
news:alpine.DEB.1.10.1010141247000.22804@urchin.earth.li...
> On Wed, 13 Oct 2010, Jon wrote:
>
>> Joshua Cranmer wrote:
>>
>>> the use of `\' as an escape character,
>>
>> A bad thing.
>
> Bullshit. Justify this or strangle yourself immediately.
>

It's a too-overloaded token: dos/windows paths, line continuation, 
escape... making for unnecessary contextual analysis by parsers. 


0
Jon
10/16/2010 7:29:06 AM
"Keith Thompson" <kst-u@mib.org> wrote in message 
news:lnbp6wbx0g.fsf@nuthaus.mib.org...
> "Jon" <jomar@spblocker.net> writes:
>> Nick Keighley wrote:
>>> use typedef (which should be called typealias)
>>
>> #define Alias typedef
>>
>> If the preprocessor is not your friend, then C will be your enemy. 
>> You're
>> welcome.
>
> If I'm reading code that uses typedef, I have to understand how typedef
> works.
>
> If I'm reading code that uses your "Alias" macro, I still have to
> understand how typedef works -- *and* that "Alias" means typedef.
>
> It doesn't help.
>

Think of a new programmer. Is he likely to understand that typedef means 
alias in reality or likely to think that it means declaration of a new 
type? Therefore, "Alias" is better. 


0
Jon
10/16/2010 7:32:42 AM
"Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message 
news:0.05cea5a2c906a7e378b1.20101014134515BST.87tykpq6xw.fsf@bsb.me.uk...
> "Jon" <jomar@spblocker.net> writes:
>
>> August Karlstrom wrote:
> <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.
>>>
>>
>> The litmus test (C syntax):
>>
>> a  = sqrt(b^2 + c^2)
>>
>> Anyone suggesting anything is more obvious (about the equal symbol) 
>> than
>> the above is a dufus. a "equals what I tell you it equals", *I* am the
>> programmer. The STATEMENT (not a ponderance), says, evaluate that
>> expression and put the result where *I* wanted. (What all you
>> mathematicians are up about, I will consider).
>
> Given the "dufus" remark, it's possible that you are not bothered about
> having a debate, but assignment it very different from "making this
> equal that".  If the type of 'a' is int, for example, a = E; may leave
> a != E in many cases.
>
> This is, in part, an argument that quality and assignment should use
> different symbols (and C complies with this) but because assignment is
> asymmetric, it's a shame that the symbol isn't similarly asymmetric.
> Both := and an arrow have that in their favour.  It's also an argument
> that assignment should not be so similar to equality that people forget
> the difference, but this is almost a psychological point rather than a
> programming one.
>
> A couple of minor points: what you wrote is an expression not a
> statement.  It would be a statement if it had a trailing semi-colon.
> Secondly, I presume that the xor b^2 is written in jest, yes?  [For
> anyone new to C reading this, C does not have an exponentiation
> operator.]

I meant to write "C-like" syntax in the parenthetical text, given that 
the debate was about the "best" tokens to do equality testing and 
assignment.


0
Jon
10/16/2010 7:45:25 AM
In comp.lang.c++ Jon <jomar@spblocker.net> wrote:
> It's a too-overloaded token: dos/windows paths,

  Did you know that you can use '/' to separate paths in dos/windows
as well? (Well, at least with all compilers I know.)

> line continuation,

  I don't think it's easy to confuse the meaning of a lone \
at the end of a line with something like "\n".

> escape... making for unnecessary contextual analysis by parsers. 

  A "contextual analysis by parsers" is not necessary for your "paths
in dos/windows", so we are left with two, rather unambiguous, cases.
0
Juha
10/16/2010 8:15:43 AM
"August Karlstrom" <fusionfile@gmail.com> wrote in message 
news:i96rmm$aro$1@speranza.aioe.org...
> On 2010-10-14 08:39, Jon wrote:
>> The litmus test (C syntax):
>>
>> a  = sqrt(b^2 + c^2)
>>
>> Anyone suggesting anything is more obvious (about the equal symbol) 
>> than
>> the above is a dufus. a "equals what I tell you it equals", *I* am the
>> programmer. The STATEMENT (not a ponderance), says, evaluate that
>> expression and put the result where *I* wanted. (What all you
>> mathematicians are up about, I will consider).
>
> If you apply your reasoning to a = a + 1 you will see the problem.
>

I don't see it. 


0
Jon
10/16/2010 8:25:17 AM
On 2010-10-16, Jon <jomar@spblocker.net> wrote:
> Think of a new programmer. Is he likely to understand that typedef means 
> alias in reality or likely to think that it means declaration of a new 
> type? Therefore, "Alias" is better. 

You're making an awful lot of assumptions about other peoples' intuition
here.  I would have been more confused by alias than I was by typedef.

See, I learned "alias" from shells, in which it's a *pure* textual
replacement -- more like a C #define than like typedef.

So if you'd called it "alias", then I would have thought that:

	alias char * foo;

meant that

	foo a, b;

would be EXACTLY identical to

	char * a, b;

meaning that b would have been a char, not a pointer-to-char.

The behavior of typedef is not all that much like that of many things
called "aliases", and I think it's better to have an unambiguously new
term, which you can explain, than to overload an old term, which people
may think they know but be mistaken about.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@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.
0
Seebs
10/16/2010 8:31:23 AM
"Juha Nieminen" <nospam@thanks.invalid> wrote in message 
news:4cb95f2f$0$12216$7b1e8fa0@news.nbl.fi...
> In comp.lang.c++ Jon <jomar@spblocker.net> wrote:
>> It's a too-overloaded token: dos/windows paths,
>
>  Did you know that you can use '/' to separate paths in dos/windows
> as well? (Well, at least with all compilers I know.)

You can sometimes, but not always (the times you can't escape me).

>
>> line continuation,
>
>  I don't think it's easy to confuse the meaning of a lone \
> at the end of a line with something like "\n".

If the goal is to make parsing trivially easy though, the overloading of 
tokens has to go away.

>
>> escape... making for unnecessary contextual analysis by parsers.
>
>  A "contextual analysis by parsers" is not necessary for your "paths
> in dos/windows", so we are left with two, rather unambiguous, cases.
>

Every context where a token shows up has ramifications. I'll bet one can 
contrive some incorrect code where having discrete tokens for paths, line 
continuations, and escape would have to be considered in a parser. 


0
joe
10/16/2010 8:33:05 AM
On Oct 16, 2:29=A0am, "Jon" <jo...@spblocker.net> wrote:
> "Tom Anderson" <t...@urchin.earth.li> wrote in message
>
> news:alpine.DEB.1.10.1010141247000.22804@urchin.earth.li...
>
> > On Wed, 13 Oct 2010, Jon wrote:
>
> >> Joshua Cranmer wrote:
>
> >>> the use of `\' as an escape character,
>
> >> A bad thing.
>
> > Bullshit. Justify this or strangle yourself immediately.
>
> It's a too-overloaded token: dos/windows paths, line continuation,
> escape... making for unnecessary contextual analysis by parsers.


Not really.  Translation phases 2 and 3 take care of everything, with
minimal context issues.  Line continuations are handled in 2,
independently of anything else, and the pre-processor tokenization
process (phase 3) has no ambiguity in dealing with the other uses.

A caveat is that parsing of header names is odd in any event, but is
not made any worse by the possible overloading of backslash.

But the parsing rules for 2 are 3 are pretty simple.

The only significant complication occurs is if you are cross compiling
to an environment with a different character set, then you have to
maintain the escaped characters in constants and string literals
distinctly until phase 5, where the source character set is translated
to the target character set.  But that isn't impacted by exactly what
the escape character is.
0
robertwessel2
10/16/2010 9:04:52 AM
joe wrote:
)
) "Juha Nieminen" <nospam@thanks.invalid> wrote in message 
) news:4cb95f2f$0$12216$7b1e8fa0@news.nbl.fi...
)>  Did you know that you can use '/' to separate paths in dos/windows
)> as well? (Well, at least with all compilers I know.)
)
) You can sometimes, but not always (the times you can't escape me).

When you're executing some old dos commands, which parse / as
a commandline switch flag.  Other than that, / is fine.


SaSW, Willem
-- 
Disclaimer: I am in no way responsible for any of the statements
            made in the above text. For all I know I might be
            drugged or something..
            No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
0
Willem
10/16/2010 9:19:38 AM
Jon wrote:

> Try it and see. (I meant from the context of complete replacement of C
> strings, by working at the library level cannot be done).

What leads you to believe that I, or anyone for that matter, never tried it?


Rui Maciel
0
Rui
10/16/2010 10:00:02 AM
Jon wrote:

> Note that string literals in C++ are not std::strings.

A "safe string type" is not necessarily, nor it needs to be, a string literal.


Rui Maciel
0
Rui
10/16/2010 10:01:31 AM
Jon wrote:

> Think of a new programmer. Is he likely to understand that typedef means
> alias in reality or likely to think that it means declaration of a new
> type? 

You tell me.  What do you believe a "new programmer" understands and does not understand?


> Therefore, "Alias" is better.

You have to try to make a case for it before you can claim it is better.


Rui Maciel

0
Rui
10/16/2010 10:06:00 AM
* Keith Thompson <kst-u@mib.org>:
> If you had written "... but also the standard symbol is used ..." I
> would have found it less confusing.  Perhaps a language barrier?

Perhaps, at least I didn't expect the placement of a little verb to have
a strong influence on understanding what I wrote. Was it wrongly placed
or just uncommon?

Regards,
Felix

-- 
 Felix Palmen       (Zirias)  + [PGP] Felix Palmen <felix@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
0
felix4560 (61)
10/16/2010 10:06:33 AM
Jon wrote:

> It's a too-overloaded token: dos/windows paths, line continuation,
> escape... making for unnecessary contextual analysis by parsers.

Please provide an example of valid C code where the escape character can be confused with what you 
describe as "dos/windows paths".  And if you have trouble understanding the difference between an 
escape token and CPP's line continuation token then I'm afraid you have to deal with much more 
serious problems than C's syntax.


Rui Maciel
0
Rui
10/16/2010 10:10:54 AM
joe wrote:

>>  I don't think it's easy to confuse the meaning of a lone \
>> at the end of a line with something like "\n".
> 
> If the goal is to make parsing trivially easy though, the overloading of
> tokens has to go away.

I don't believe anyone can claim that this is a problem to anyone who ever invested some time 
writing a compiler.


>>> escape... making for unnecessary contextual analysis by parsers.
>>
>>  A "contextual analysis by parsers" is not necessary for your "paths
>> in dos/windows", so we are left with two, rather unambiguous, cases.
>>
> 
> Every context where a token shows up has ramifications. I'll bet one can
> contrive some incorrect code where having discrete tokens for paths, line
> continuations, and escape would have to be considered in a parser.

You failed to provide a single example.  Are you able to provide any real example that can back up 
your statement?


Rui Maciel
0
Rui
10/16/2010 10:16:18 AM
"Jon" <jomar@spblocker.net> writes:

> "Keith Thompson" <kst-u@mib.org> wrote in message 
> news:lnbp6wbx0g.fsf@nuthaus.mib.org...
>> "Jon" <jomar@spblocker.net> writes:
>>> Nick Keighley wrote:
>>>> use typedef (which should be called typealias)
>>>
>>> #define Alias typedef
>>>
>>> If the preprocessor is not your friend, then C will be your enemy. 
>>> You're
>>> welcome.
>>
>> If I'm reading code that uses typedef, I have to understand how typedef
>> works.
>>
>> If I'm reading code that uses your "Alias" macro, I still have to
>> understand how typedef works -- *and* that "Alias" means typedef.
>>
>> It doesn't help.
>
> Think of a new programmer. Is he likely to understand that typedef means 
> alias in reality or likely to think that it means declaration of a new 
> type? Therefore, "Alias" is better. 

A #define is particularly bad for new programmers -- they need to see
repeated examples of C syntax un-obscured so that the patterns sink in.
If I were specifically targeting people who did not yet know C I'd use a
comment:

  /* Define 'Point' as an alias for struct point: */
  typedef struct point Point;

Applying your argument to other elements that are not obvious to new
programmers would completely obscure the language (static, const, '*' --
all three uses -- and so on).

-- 
Ben.
0
Ben
10/16/2010 10:47:59 AM
* Juha Nieminen <nospam@thanks.invalid> [comp.lang.c]:
> In comp.lang.c++ Jon <jomar@spblocker.net> wrote:
>> It's a too-overloaded token: dos/windows paths,
> 
>  Did you know that you can use '/' to separate paths in dos/windows
> as well? (Well, at least with all compilers I know.)

The compiler doesn't matter here. Most windows api functions accept '/'
nowadays (but not all). You're better off using '\' for the windows
platform, because there are still cases '/' won't work.

But then, it was Microsoft's awkward decision to use '\' as a path
separator with the rest of the world using '/'. It probably came back on
them the instant they built web functionality (browser, server) in their
OS.

Regards,
Felix

-- 
 Felix Palmen       (Zirias)  + [PGP] Felix Palmen <felix@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
0
felix
10/16/2010 10:48:44 AM
* Jon <jomar@spblocker.net>:
> Think of a new programmer. Is he likely to understand that typedef means 
> alias in reality or likely to think that it means declaration of a new 
> type? Therefore, "Alias" is better. 

And how is typedef NOT declaring a new type? (in fact, it should say
"defining"!) Defining new types is always done by means of existing
types, in any language that allows type definitions.

-- 
 Felix Palmen       (Zirias)  + [PGP] Felix Palmen <felix@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
0
felix
10/16/2010 10:59:58 AM
On Sat, 16 Oct 2010, Jon wrote:

> "Tom Anderson" <twic@urchin.earth.li> wrote in message
> news:alpine.DEB.1.10.1010141247000.22804@urchin.earth.li...
>> On Wed, 13 Oct 2010, Jon wrote:
>>
>>> Joshua Cranmer wrote:
>>>
>>>> the use of `\' as an escape character,
>>>
>>> A bad thing.
>>
>> Bullshit. Justify this or strangle yourself immediately.
>
> It's a too-overloaded token: dos/windows paths, line continuation,
> escape... making for unnecessary contextual analysis by parsers.

Thanks for the answer. I don't see the problem with its use in Windows 
file paths; the solution to that problem, if it is a problem, is simply 
not to use Windows.

I don't think the use for both esapes and line continuation is a problem 
either, because i think both those functions belong together - they're a 
way of writing a string that doesn't correspond exactly to the characters 
in the input. Essentially, the escape sequence backslash-newline 
represents the empty string.

On the specific point of contextual analysis by parsers, then i'm not 
aware that multiple uses of backslash lead to *any* contextual analysis by 
the java parser; to it, a backslash always introduces an escape sequence.

tom

-- 
News flash: there's no deep meaning or hidden message BECAUSE DAVID
LYNCH IS INSANE
0
Tom
10/16/2010 11:18:07 AM
On Sat, 16 Oct 2010 08:15:43 +0000, Juha Nieminen wrote:

>> line continuation,
> 
>   I don't think it's easy to confuse the meaning of a lone \
> at the end of a line with something like "\n".
>
Its not different, just another escape where the escaped character 
happens to be invisible. The escaped character is, of course, CR or LF. 
The proof of this is that if \ is followed by space or tab it isn't a 
line continuation.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |
0
Martin
10/16/2010 12:06:08 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).
> 
> In order to maintain the integrity of the discussion (have everything
> at the same place) please respond on comp.lang.c.
> 

The first thing I would do is to get rid of "->". Srsly, if the dot operator 
is applied on a pointer value p, it will be equivalent to "(*p).mem".
0
Johannes
10/16/2010 12:31:19 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).
> 
> In order to maintain the integrity of the discussion (have everything
> at the same place) please respond on comp.lang.c.
> 

The first thing I would do is to get rid of "->". Srsly, if the dot operator 
is applied on a pointer value p, it will be equivalent to "(*p).mem".

0
Johannes
10/16/2010 12:32:42 PM
"Johannes Schaub (litb)" <schaub-johannes@web.de> writes:

> Alexander 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.
>> 
>
> The first thing I would do is to get rid of "->". Srsly, if the dot operator 
> is applied on a pointer value p, it will be equivalent to "(*p).mem".


You are joking?

-- 
"Avoid hyperbole at all costs, its the most destructive argument on
the planet" - Mark McIntyre in comp.lang.c
0
Richard
10/16/2010 1:14:14 PM
Richard wrote:

> "Johannes Schaub (litb)" <schaub-johannes@web.de> writes:
> 
>> Alexander 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.
>>> 
>>
>> The first thing I would do is to get rid of "->". Srsly, if the dot
>> operator is applied on a pointer value p, it will be equivalent to
>> "(*p).mem".
> 
> 
> You are joking?
> 

Why should I be joking? I regard it as one of the most ugly thing that dot 
operator only works on struct and unions. 

I see no reasons for "->".
0
Johannes
10/16/2010 1:22:57 PM
"Johannes Schaub (litb)" <schaub-johannes@web.de> writes:

> Richard wrote:
>
>> "Johannes Schaub (litb)" <schaub-johannes@web.de> writes:
>> 
>>> Alexander 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.
>>>> 
>>>
>>> The first thing I would do is to get rid of "->". Srsly, if the dot
>>> operator is applied on a pointer value p, it will be equivalent to
>>> "(*p).mem".
>> 
>> 
>> You are joking?
>> 
>
> Why should I be joking? I regard it as one of the most ugly thing that dot 
> operator only works on struct and unions. 
>
> I see no reasons for "->".

Huh? What language are you talking about? If you dont see the point in
language for -> in C then I am amazed.

-- 
"Avoid hyperbole at all costs, its the most destructive argument on
the planet" - Mark McIntyre in comp.lang.c
0
Richard
10/16/2010 1:34:19 PM
In article <i9c9kt$3au$2@news.eternal-september.org>,
Richard  <rgrdev_@gmail.com> wrote:
....
>> I see no reasons for "->".
>
>Huh? What language are you talking about? If you dont see the point in
>language for -> in C then I am amazed.

Now, now.  Calm down.  Obviously, it won't ever be changed, because C is
what it is.

But the argument, which is valid as far as I can tell, is that the "->"
operator is unnecessary because "." is all you need.  I.e., if we were
doing it over from scratch, we could say that whenever we see:

	something.member

and the compiler can determine that something is a pointer, then it
would internally convert it to:

	something -> member

Since C is a statically typed language, this should work.

And, in fact, if I am reading things that others have posted on the
subject correctly, other languages, like Java, do exactly this.

Finally, note that the basic argument of "If it isn't necessary, then it
is bad" isn't necessarily convincing.  Some people have argued that even
if "->" isn't necessary, it is still a good thing, because it makes the
code easier to understand.  I.e., it is a "documentation aid".
Personally, I favor this last argument.

-- 
Religion is regarded by the common people as true,
	by the wise as false,
	and by the rulers as useful.

(Seneca the Younger, 65 AD)

0
gazelle
10/16/2010 1:47:01 PM
gazelle@shell.xmission.com (Kenny McCormack) writes:

> In article <i9c9kt$3au$2@news.eternal-september.org>,
> Richard  <rgrdev_@gmail.com> wrote:
> ...
>>> I see no reasons for "->".
>>
>>Huh? What language are you talking about? If you dont see the point in
>>language for -> in C then I am amazed.
>
> Now, now.  Calm down.  Obviously, it won't ever be changed, because C is
> what it is.
>
> But the argument, which is valid as far as I can tell, is that the "->"
> operator is unnecessary because "." is all you need.  I.e., if we were
> doing it over from scratch, we could say that whenever we see:
>
> 	something.member
>
> and the compiler can determine that something is a pointer, then it
> would internally convert it to:
>
> 	something -> member
>
> Since C is a statically typed language, this should work.
>
> And, in fact, if I am reading things that others have posted on the
> subject correctly, other languages, like Java, do exactly this.
>
> Finally, note that the basic argument of "If it isn't necessary, then it
> is bad" isn't necessarily convincing.  Some people have argued that even
> if "->" isn't necessary, it is still a good thing, because it makes the
> code easier to understand.  I.e., it is a "documentation aid".
> Personally, I favor this last argument.

I want to know when its a pointer.

I realise its the new fad to make C look like some hackup like Java but
I want to know what I am dealing with.

"->" tells me just that.

-- 
"Avoid hyperbole at all costs, its the most destructive argument on
the planet" - Mark McIntyre in comp.lang.c
0
Richard
10/16/2010 1:51:23 PM
On 10/16/2010 03:29 AM, Jon wrote:
> "Tom Anderson"<twic@urchin.earth.li>  wrote in message
> news:alpine.DEB.1.10.1010141247000.22804@urchin.earth.li...
>> On Wed, 13 Oct 2010, Jon wrote:
>>
>>> Joshua Cranmer wrote:
>>>
>>>> the use of `\' as an escape character,
>>>
>>> A bad thing.
>>
>> Bullshit. Justify this or strangle yourself immediately.
>>
>
> It's a too-overloaded token: dos/windows paths, line continuation,
> escape... making for unnecessary contextual analysis by parsers.

Nowhere near as overloaded as *, which is used for multiplication, 
pointer dereferencing, and declaration of pointer types.

Since paths are not actually handled by a language parser (most of the 
time), that only leaves line continuation and escape as a need to 
disambiguate. Which is still pretty trivially easy if you look at the 
Follow sets (i.e., LL(1)).

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth
0
Joshua
10/16/2010 2:04:39 PM
"Johannes Schaub (litb)" <schaub-johannes@web.de> wrote:
> The first thing I would do is to get rid of "->". Srsly, if the dot operator 
> is applied on a pointer value p, it will be equivalent to "(*p).mem".

  Wouldn't this cause a problem when trying to overload the operator
(eg. in smart pointers)?
0
Juha
10/16/2010 6:10:40 PM
Juha Nieminen <nospam@thanks.invalid> wrote in
news:4cb9eaa0$0$32174$7b1e8fa0@news.nbl.fi: 

> "Johannes Schaub (litb)" <schaub-johannes@web.de> wrote:
>> The first thing I would do is to get rid of "->". Srsly, if the dot
>> operator is applied on a pointer value p, it will be equivalent to
>> "(*p).mem". 
> 
>   Wouldn't this cause a problem when trying to overload the operator
> (eg. in smart pointers)?
> 

One would need to be able to overload operator. for smart pointers. 
However, then it might become cumbersome to write smart pointer 
implementation itself. One should then add a .. operator or whatever, as a 
"real dot operator".  Coming to think about that, what's missing in the 
current C++ is a non-overloadable -> operator, so that would be something I 
would add to current C++ syntax.

Cheers
Paavo
0
Paavo
10/16/2010 6:52:48 PM
On 10/16/2010 8:52 PM, Paavo Helde wrote:
> Juha Nieminen<nospam@thanks.invalid>  wrote in
> news:4cb9eaa0$0$32174$7b1e8fa0@news.nbl.fi:
>
>> "Johannes Schaub (litb)"<schaub-johannes@web.de>  wrote:
>>> The first thing I would do is to get rid of "->". Srsly, if the dot
>>> operator is applied on a pointer value p, it will be equivalent to
>>> "(*p).mem".
>>
>>    Wouldn't this cause a problem when trying to overload the operator
>> (eg. in smart pointers)?
>>
>
> One would need to be able to overload operator. for smart pointers.
> However, then it might become cumbersome to write smart pointer
> implementation itself. One should then add a .. operator or whatever, as a
> "real dot operator".  Coming to think about that, what's missing in the
> current C++ is a non-overloadable ->  operator, so that would be something I
> would add to current C++ syntax.
>
> Cheers
> Paavo

Operator -> already is non-overloadable as a non member function. You 
can apply the member version iff (if and only if) the operand is not a 
pointer and the non-member version iff the operand is pointer. As long 
as both a non-overloadable operator. and overloadable member operator-> 
are available I don't see what needs to be added. I for one am quite 
happy with the operators . and -> the way they are now.
0
Stefan
10/16/2010 8:09:19 PM
Stefan van Kessel <stefan.van.kessel@mytum.de> wrote in
news:i9d0po$ast$1@news.informatik.tu-muenchen.de: 

> On 10/16/2010 8:52 PM, Paavo Helde wrote:
>> Coming to think about that, what's missing
>> in the current C++ is a non-overloadable ->  operator, so that would
>> be something I would add to current C++ syntax.
>>
>> Cheers
>> Paavo
> 
> Operator -> already is non-overloadable as a non member function. You 
> can apply the member version iff (if and only if) the operand is not a
> pointer and the non-member version iff the operand is pointer. As long
> as both a non-overloadable operator. and overloadable member
> operator-> are available I don't see what needs to be added. I for one
> am quite happy with the operators . and -> the way they are now.

Yeah, you are right. I think I confused it up with the address-of 
operator instead, but never mind.

Cheers
Paavo



0
Paavo
10/16/2010 10:00:09 PM
felix@palmen-it.de (Felix Palmen) writes:
> * Juha Nieminen <nospam@thanks.invalid> [comp.lang.c]:
>> In comp.lang.c++ Jon <jomar@spblocker.net> wrote:
>>> It's a too-overloaded token: dos/windows paths,
>> 
>>  Did you know that you can use '/' to separate paths in dos/windows
>> as well? (Well, at least with all compilers I know.)
>
> The compiler doesn't matter here. Most windows api functions accept '/'
> nowadays (but not all). You're better off using '\' for the windows
> platform, because there are still cases '/' won't work.
>
> But then, it was Microsoft's awkward decision to use '\' as a path
> separator with the rest of the world using '/'. It probably came back on
> them the instant they built web functionality (browser, server) in their
> OS.

My understanding is that early versions of MS-DOS didn't support
directories (or maybe it was CP/M).  By the time they decided to
add directories, they were already using '/' as an option delimiter
(like '-' in Unix).

The Unix convention probably wasn't as widespread then as it is
now, so using '\' wasn't an obviously absurd choice at the time.
(VMS, for example, uses '.' to separate directory names.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
0
Keith
10/16/2010 10:28:12 PM
felix@palmen-it.de (Felix Palmen) writes:
> * Jon <jomar@spblocker.net>:
>> Think of a new programmer. Is he likely to understand that typedef means 
>> alias in reality or likely to think that it means declaration of a new 
>> type? Therefore, "Alias" is better. 
>
> And how is typedef NOT declaring a new type? (in fact, it should say
> "defining"!) Defining new types is always done by means of existing
> types, in any language that allows type definitions.

Given, for example:

    struct foo {
        int data;
    };

    typedef struct foo foo_t;

the typedef really doesn't create a new type.  All it does is create a
new name for an existing type.  "struct foo" and "foo_t" are not merely
two different types with the same characteristics; they are quite
literally the same type.

By contrast, given:

    struct foo {
        int data;
    };

    struct bar {
        int data;
    };

"struct foo" and "struct bar" are two distinct types.  Assigning a
value of type "pointer to struct foo" to an object of type "pointer
to struct bar" is a constraint violation, requiring a diagnostic.

Replace "pointer to struct bar" with "pointer to foo_t" in the above,
and there's no problem.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
0
Keith
10/16/2010 10:34:34 PM
felix@palmen-it.de (Felix Palmen) writes:
> * Keith Thompson <kst-u@mib.org>:
>> If you had written "... but also the standard symbol is used ..." I
>> would have found it less confusing.  Perhaps a language barrier?
>
> Perhaps, at least I didn't expect the placement of a little verb to have
> a strong influence on understanding what I wrote. Was it wrongly placed
> or just uncommon?

I don't think it's wrong, but it is unusual.  Noticing that you post
from a ".de" domain helped me figure it out.

No criticism intended; your English is certainly far better than my
German.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
0
Keith
10/16/2010 10:36:25 PM
On Sat, 16 Oct 2010 15:28:12 -0700, Keith Thompson wrote:

> felix@palmen-it.de (Felix Palmen) writes:
>> * Juha Nieminen <nospam@thanks.invalid> [comp.lang.c]:
>>> In comp.lang.c++ Jon <jomar@spblocker.net> wrote:
>>>> It's a too-overloaded token: dos/windows paths,
>>> 
>>>  Did you know that you can use '/' to separate paths in dos/windows
>>> as well? (Well, at least with all compilers I know.)
>>
>> The compiler doesn't matter here. Most windows api functions accept '/'
>> nowadays (but not all). You're better off using '\' for the windows
>> platform, because there are still cases '/' won't work.
>>
>> But then, it was Microsoft's awkward decision to use '\' as a path
>> separator with the rest of the world using '/'. It probably came back
>> on them the instant they built web functionality (browser, server) in
>> their OS.
> 
> My understanding is that early versions of MS-DOS didn't support
> directories (or maybe it was CP/M).  By the time they decided to add
> directories, they were already using '/' as an option delimiter (like
> '-' in Unix).
>
Correct. MS-DOS 2.x introduced directories. Before that, MS-DOS, like the 
other 8 bit OSen (FLEX, FLEX-09, CP/M, etc.), just had a flat list of 
file names which was OK because few of its users could afford disks big 
enough for the lack of directories to be a problem.

It looks as though MS-DOS inherited the A: drive letter convention from 
CP/M, which in turn may have gotten it from the PDP-8 OSen such as RTOS: 
the CP/M  command language pretty much copied its syntax, command names 
and file naming conventions.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |
0
Martin
10/16/2010 10:55:46 PM
"Rui Maciel" <rui.maciel@gmail.com> wrote in message 
news:4cb977a8$0$6662$a729d347@news.telepac.pt...
> Jon wrote:
>
>> Try it and see. (I meant from the context of complete replacement of C
>> strings, by working at the library level cannot be done).
>
> What leads you to believe that I, or anyone for that matter, never 
> tried it?
>

In your case (not anyone else), because you don't know that it's not 
practical. 


0
Jon
10/16/2010 11:32:35 PM
* Keith Thompson <kst-u@mib.org>:
> felix@palmen-it.de (Felix Palmen) writes:
>> * Jon <jomar@spblocker.net>:
>>> Think of a new programmer. Is he likely to understand that typedef means 
>>> alias in reality or likely to think that it means declaration of a new 
>>> type? Therefore, "Alias" is better. 
>>
>> And how is typedef NOT declaring a new type? (in fact, it should say
>> "defining"!) Defining new types is always done by means of existing
>> types, in any language that allows type definitions.
[...]
>    typedef struct foo foo_t;
> 
> the typedef really doesn't create a new type.  All it does is create a
> new name for an existing type.  "struct foo" and "foo_t" are not merely
> two different types with the same characteristics; they are quite
> literally the same type.

Sure, that's because in your example, the definition of the type foo_t
is as simple as it could be: just another type. In this case, you could
also call it an alias. But in the general case, typedef will accept any
complex type expression to define the new type, so I'd say there is
absolutely nothing wrong with the name "typedef".

Regards,
Felix

-- 
 Felix Palmen       (Zirias)  + [PGP] Felix Palmen <felix@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
0
felix
10/17/2010 12:25:35 AM
* Keith Thompson <kst-u@mib.org> [comp.lang.c]:
> felix@palmen-it.de (Felix Palmen) writes:
>> But then, it was Microsoft's awkward decision to use '\' as a path
>> separator with the rest of the world using '/'. It probably came back on
>> them the instant they built web functionality (browser, server) in their
>> OS.
[early MS-DOS]
> The Unix convention probably wasn't as widespread then as it is
> now, so using '\' wasn't an obviously absurd choice at the time.
> (VMS, for example, uses '.' to separate directory names.)

Maybe it wasn't too obvious back then that interoperability could matter
some day. But, (we're talking about 1980...) Unix was already used a
lot. Only 5 years later, AmigaOS had the "standard" path separator (and
also, to some extent, the concept of mounting devices).

Regards,
Felix

-- 
 Felix Palmen       (Zirias)  + [PGP] Felix Palmen <felix@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
0
felix
10/17/2010 12:56:13 AM
felix@palmen-it.de (Felix Palmen) writes:
> * Keith Thompson <kst-u@mib.org>:
>> felix@palmen-it.de (Felix Palmen) writes:
>>> * Jon <jomar@spblocker.net>:
>>>> Think of a new programmer. Is he likely to understand that typedef means 
>>>> alias in reality or likely to think that it means declaration of a new 
>>>> type? Therefore, "Alias" is better. 
>>>
>>> And how is typedef NOT declaring a new type? (in fact, it should say
>>> "defining"!) Defining new types is always done by means of existing
>>> types, in any language that allows type definitions.
> [...]
>>    typedef struct foo foo_t;
>> 
>> the typedef really doesn't create a new type.  All it does is create a
>> new name for an existing type.  "struct foo" and "foo_t" are not merely
>> two different types with the same characteristics; they are quite
>> literally the same type.
>
> Sure, that's because in your example, the definition of the type foo_t
> is as simple as it could be: just another type. In this case, you could
> also call it an alias. But in the general case, typedef will accept any
> complex type expression to define the new type, so I'd say there is
> absolutely nothing wrong with the name "typedef".

Regardless of how complex the type is, a typedef does nothing more that
create an alias for the existing type.  The definition is *always* "just
another type".

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
0
Keith
10/17/2010 1:32:56 AM
"Seebs" <usenet-nospam@seebs.net> wrote in message 
news:slrnibion1.2682.usenet-nospam@guild.seebs.net...
> On 2010-10-16, Jon <jomar@spblocker.net> wrote:
>> Think of a new programmer. Is he likely to understand that typedef 
>> means
>> alias in reality or likely to think that it means declaration of a new
>> type? Therefore, "Alias" is better.
>
> You're making an awful lot of assumptions about other peoples' 
> intuition
> here.

Hardly. Note that a poster further down thought that typdef created a new 
type. I remember thinking that long ago too. I'm sure many C programmers 
think that today.


0
Jon
10/17/2010 1:57:32 AM
"Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message 
news:0.4ef395e0027b90f26249.20101016114759BST.87zkuemn1c.fsf@bsb.me.uk...
> "Jon" <jomar@spblocker.net> writes:
>
>> "Keith Thompson" <kst-u@mib.org> wrote in message
>> news:lnbp6wbx0g.fsf@nuthaus.mib.org...
>>> "Jon" <jomar@spblocker.net> writes:
>>>> Nick Keighley wrote:
>>>>> use typedef (which should be called typealias)
>>>>
>>>> #define Alias typedef
>>>>
>>>> If the preprocessor is not your friend, then C will be your enemy.
>>>> You're
>>>> welcome.
>>>
>>> If I'm reading code that uses typedef, I have to understand how 
>>> typedef
>>> works.
>>>
>>> If I'm reading code that uses your "Alias" macro, I still have to
>>> understand how typedef works -- *and* that "Alias" means typedef.
>>>
>>> It doesn't help.
>>
>> Think of a new programmer. Is he likely to understand that typedef 
>> means
>> alias in reality or likely to think that it means declaration of a new
>> type? Therefore, "Alias" is better.
>
> A #define is particularly bad for new programmers

The issue is not a define, but rather that "typedef" is a poor choice of 
keyword for what it does in the C language. "alias" would have been much 
better.


0
Jon
10/17/2010 2:00:12 AM
"Jon" <jomar@spblocker.net> writes:

> "Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message 
> news:0.4ef395e0027b90f26249.20101016114759BST.87zkuemn1c.fsf@bsb.me.uk...
>> "Jon" <jomar@spblocker.net> writes:
>>
>>> "Keith Thompson" <kst-u@mib.org> wrote in message
>>> news:lnbp6wbx0g.fsf@nuthaus.mib.org...
>>>> "Jon" <jomar@spblocker.net> writes:
>>>>> Nick Keighley wrote:
>>>>>> use typedef (which should be called typealias)
>>>>>
>>>>> #define Alias typedef
>>>>>
>>>>> If the preprocessor is not your friend, then C will be your enemy.
>>>>> You're
>>>>> welcome.
>>>>
>>>> If I'm reading code that uses typedef, I have to understand how 
>>>> typedef
>>>> works.
>>>>
>>>> If I'm reading code that uses your "Alias" macro, I still have to
>>>> understand how typedef works -- *and* that "Alias" means typedef.
>>>>
>>>> It doesn't help.
>>>
>>> Think of a new programmer. Is he likely to understand that typedef 
>>> means
>>> alias in reality or likely to think that it means declaration of a new
>>> type? Therefore, "Alias" is better.
>>
>> A #define is particularly bad for new programmers
>
> The issue is not a define,

I thought you were suggesting one.

> but rather that "typedef" is a poor choice of 
> keyword for what it does in the C language. "alias" would have been much 
> better.

I'd prefer a keyword that included "type" in it because alias is a very
general word, but I agree that there might be a better word.  I don't
agree (given the C language we have) that the #define you posted makes
anything better.

-- 
Ben.
0
Ben
10/17/2010 2:06:53 AM
"Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message 
news:0.1380ee9f31ea3465db09.20101017030653BST.87ocatmv2a.fsf@bsb.me.uk...
> "Jon" <jomar@spblocker.net> writes:
>
>> "Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message
>> news:0.4ef395e0027b90f26249.20101016114759BST.87zkuemn1c.fsf@bsb.me.uk...
>>> "Jon" <jomar@spblocker.net> writes:
>>>
>>>> "Keith Thompson" <kst-u@mib.org> wrote in message
>>>> news:lnbp6wbx0g.fsf@nuthaus.mib.org...
>>>>> "Jon" <jomar@spblocker.net> writes:
>>>>>> Nick Keighley wrote:
>>>>>>> use typedef (which should be called typealias)
>>>>>>
>>>>>> #define Alias typedef
>>>>>>
>>>>>> If the preprocessor is not your friend, then C will be your enemy.
>>>>>> You're
>>>>>> welcome.
>>>>>
>>>>> If I'm reading code that uses typedef, I have to understand how
>>>>> typedef
>>>>> works.
>>>>>
>>>>> If I'm reading code that uses your "Alias" macro, I still have to
>>>>> understand how typedef works -- *and* that "Alias" means typedef.
>>>>>
>>>>> It doesn't help.
>>>>
>>>> Think of a new programmer. Is he likely to understand that typedef
>>>> means
>>>> alias in reality or likely to think that it means declaration of a 
>>>> new
>>>> type? Therefore, "Alias" is better.
>>>
>>> A #define is particularly bad for new programmers
>>
>> The issue is not a define,
>
> I thought you were suggesting one.

Pfft. I know better than to "suggest" a change to the ISO C standard in 
this ng.

>
>> but rather that "typedef" is a poor choice of
>> keyword for what it does in the C language. "alias" would have been 
>> much
>> better.
>
> I'd prefer a keyword that included "type" in it because alias is a very
> general word, but I agree that there might be a better word.

In the modern times of "programmer creates types", *especially* anything 
with 'type' in it is bad. Suggest something better than 'alias' then. 
'imposter'? I like 'alias'.

>  I don't
> agree (given the C language we have) that the #define you posted makes
> anything better.
>

Did you say that "just right"? 


0
Jon
10/17/2010 5:02:11 AM
"BartC" <bc@freeuk.com> wrote in message 
news:i9863r$r9e$1@news.eternal-september.org...

> Since I'd used the other language for many years (having invented it),

I though Dennis Ritchie invented C!


0
Jon
10/17/2010 5:15:08 AM
"Rui Maciel" <rui.maciel@gmail.com> wrote in message 
news:4cb86ade$0$6657$a729d347@news.telepac.pt...
> BartC wrote:
>
>> I don't know how you deduced that from my statement.
>
> After re-reading this particular branch of this discussion I have to 
> say that not only my reading
> comprehension skills failed me miserably but that also my replies were 
> inappropriate.  My apologies.

Stop lying: you're a "shoot-from-the-hip gunslinger". I know what you're 
thinking:

"Did he fire six shots or only five?" Well, to tell you the truth, in all 
this excitement I kind of lost track myself. But being as this is C, the 
most powerful programming language in the world, and would blow your 
finger clean off, you've got to ask yourself one question: "Do I feel 
lucky?" Well, do ya, punk?





0
Jon
10/17/2010 5:22:29 AM
On Sat, 16 Oct 2010 11:10:54 +0100, Rui Maciel wrote:

> Jon wrote:
> 
>> It's a too-overloaded token: dos/windows paths, line continuation,
>> escape... making for unnecessary contextual analysis by parsers.
> 
> Please provide an example of valid C code where the escape character can
> be confused with what you describe as "dos/windows paths".

I can't think of any that would confuse *the compiler* or complicate its 
design.

There's one way in which the collision can bother *the C coder*, though: 
the backslash has to be escaped in string literals, unlike the forward 
slash, and paths are commonplace string literals, so on systems that use 
the backslash the coder may be inconvenienced by the need to do much more 
escaping than on systems that use the forward slash path separator.
0
ClassCastException
10/17/2010 5:27:28 AM
"Richard Harter" <cri@tiac.net> wrote in message 
news:4cb257e2.118252798@text.giganews.com...
> On Sun, 10 Oct 2010 19:26:04 +0200, Richard <rgrdev_@gmail.com>
> 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.
>

I'm trying to mark this thread as read because I *am* interested in some 
posts. As I go thru all of the posts, in cursory inspection, I find your 
above blather. Can you and your mate take it pvt please and stop the 
noise in the room? Wait, are onlookers supposed to save you or us from 
you or other? Just get to the point please. Else, feel free to STFU. If 
you want to banter like old women, go or create the old woman banter 
room. Everything is not all the time and this room has a topic (yet to be 
defined (?),. but certainly it is not old women bantering). 


0
Jon
10/17/2010 5:41:07 AM
I am at this time marking this thread as read. No offense intended.

"Alexander" <alvatov@gmail.com> wrote in message 
news:f3bfce1a-e3d9-48e9-9c84-e8d020bde7ec@a36g2000yqc.googlegroups.com...
> 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 


0
jomar (6)
10/17/2010 5:44:19 AM
On Sat, 16 Oct 2010 22:55:46 +0000, Martin Gregorie wrote:

> On Sat, 16 Oct 2010 15:28:12 -0700, Keith Thompson wrote:
> 
>> felix@palmen-it.de (Felix Palmen) writes:
>>> * Juha Nieminen <nospam@thanks.invalid> [comp.lang.c]:
>>>> In comp.lang.c++ Jon <jomar@spblocker.net> wrote:
>>>>> It's a too-overloaded token: dos/windows paths,
>>>> 
>>>>  Did you know that you can use '/' to separate paths in dos/windows
>>>> as well? (Well, at least with all compilers I know.)
>>>
>>> The compiler doesn't matter here. Most windows api functions accept
>>> '/' nowadays (but not all). You're better off using '\' for the
>>> windows platform, because there are still cases '/' won't work.
>>>
>>> But then, it was Microsoft's awkward decision to use '\' as a path
>>> separator with the rest of the world using '/'. It probably came back
>>> on them the instant they built web functionality (browser, server) in
>>> their OS.
>> 
>> My understanding is that early versions of MS-DOS didn't support
>> directories (or maybe it was CP/M).  By the time they decided to add
>> directories, they were already using '/' as an option delimiter (like
>> '-' in Unix).
>>
> Correct. MS-DOS 2.x introduced directories. Before that, MS-DOS, like
> the other 8 bit OSen (FLEX, FLEX-09, CP/M, etc.), just had a flat list
> of file names which was OK because few of its users could afford disks
> big enough for the lack of directories to be a problem.

It's about to happen again. In the mid-80s we reached the scaling limits 
of flat file lists and went to hierarchical directories. Now we're 
approaching the scaling limits of hierarchical directories. I haven't 
seen a modern system that doesn't have some ludicrously long full-path-
names of files, highly deeply nested directory structures, and human 
trouble navigating the wilderness of files and keeping track of what 
files are for what purpose. Applications come with numerous files; on 
Windows systems they tend to be bundled with it in Program Files (with 
some libraries being elsewhere, or else duplicated wastefully); on Unix 
systems all kinds of config and other files get scattered to the four 
winds, /usr, /etc, /bin, and ~/.appname. Documents might end up anywhere, 
at least on Windows machines.

Another tension is between organizing by program and organizing by higher 
level task. Say someone's throwing together a report and presentation. 
The report is made in Word, the presentation in PowerPoint, both using 
data from an Excel spreadsheet, and some of the graphs were copied, 
pasted into Photoshop, prettied up, and then embedded as .png files. Oh, 
and the whole thing is also HTMLized using FrontPage and posted to the 
company LAN as well as the PP presentation presented at the Friday 
afternoon general staff meeting and the printed report handed to the boss 
afterward in the hall outside the conference room. And the guys that 
couldn't attend the meeting in person phone-conferenced with those that 
were while consulting the copy on the LAN's internal website.

So you've got Photoshopped pngs along with xls, doc, pp, and other files, 
that logically are part of one project. The user wants to file them as 
"2010 2nd quarter budget report" or whatever, under "2010 budget 
reports", under "budget reports", ideally; the programs all would like to 
keep track of their own files, docs with docs, xlses with xlses; and 
Windows itself would dearly love it if you'd just shove the whole mess in 
"My Documents" along with every single other file the user ever creates, 
thus turning back the clock to 1982 and flat file lists again.

Unix users get nearly the analogous treatment with ~/ substituting for 
"My Documents" and the gimp for Photoshop and other more or less 
straightforward substitutions.

Add to that how every kind of browser, file sharing tool, or similar 
client for downloadable content ends up with its own preferred 
directories for storing received files, plus iTunes, plus various sync 
folders for your phone and laptop, and so on, and so forth, and we're 
rapidly heading straight back into file management hell.

What's our savior going to be? I'm beginning to suspect we're going to 
soon see a wave of new file management tools, at first appearing as third-
party "knowledge manager" programs and eventually superseding Explorer-
style shells as those have superseded the old C:\ prompt. These will 
provide their own nonhierarchical, link-based file management ability, 
probably with the ability to easily convert any subnetwork of stuff into 
web pages, or even acting as a web site itself; a locally-hosted web app 
that can easily adapt to make some stuff publishable remotely. Hyperlinks 
will creep into everything and become easy to create via drag and drop; 
no copying and pasting (or worse, memorizing and typing) long filenames.

We already see hints of this with the big commercial websites. When was 
the last time you saw a human-readable URL at a major news or corporate 
site instead of something like http://site.example.com/html/content/
cms/1.45.907/08102010/58120156-18856-ac78f9d107bb8088.htm or similarly. 
Occasionally you might see something like that but with a -report-on-iraq-
casualties just before the .htm, but dollars to doughnuts you can delete 
that from the url or replace it with -report-on-stolen-doughnuts and it 
will still fetch the same page.

Filenames and paths are becoming a layer increasingly managed by 
automation instead of manually, now by big website CMSes and soon by 
Windows 8 and Gnome 2015 I expect. The user will not type paths or even 
drill down through folders, he will follow hyperlinks.

And when he needs to make a nonlocal jump he will use search. Faster, 
more incremental, and better search than we have so far.

Vista already has raised the bar. I use some Vista machines and almost 
never click Programs after Start, unlike when forced to use an older XP 
box. Programs is slow, balky, unwieldy, and has shoddy ergonomics. It 
worked at first and didn't scale, despite being hierarchical. Vista's 
start menu has a nice fat incremental search box at the bottom just 
begging for your input, and you can find something like Calculator much 
faster by typing "calc" into it and then clicking one of the few 
remaining items above than by clicking Programs, then Accessories, etc. 
and waiting for each level of menu to unfold. Vista also makes it easy to 
tag photographs and search by tag, just by typing e.g. tag:(budget OR 
finance) into an Explorer window's upper-right-corner search box.

Two things still scale poorly: the searches aren't especially fast, 
particularly on large tagged photo libraries, and photo tagging is itself 
one tag at a time one image at a time with poor support for copy, paste, 
or mass tagging (it would be nice to be able to select a large group of 
images and assign a tag to the lot with one command).

The knowledge managers can beat Explorer by providing their own facility 
for associating any imported object with metadata, including metadata, 
and using suitable lightweight local database software to make it fast to 
search. This allows tagging images that aren't JPEG or TIFF (so don't 
have EXIF metadata) and tagging non-images, as well as doing so in a 
uniform manner. (EXIF tags and other document-format-supported metadata, 
like mp3 ID3 tags, could be imported when a file is first seen by the 
system.) Metatagging is most important, of course, for nonverbal data 
such as audio, still pictures, and video. (Advanced tools could 
potentially attempt voice recognition on audio and OCR on stills and 
video to extract what verbal content is in there, but fuzzy-matching 
would have to be used for this to be searchable I expect, and even then 
an unlabeled photo of an apple would not be found by searching for 
"apple" without solving some hard problems in AI and machine vision.)

So your documents become much more searchable and you can link them into 
a web of interrelatedness. Something like this almost HAS to replace 
Explorer-style shells in the very near future, I'm thinking, if only 
because of the stupendous explosion of user-generated audiovisual content 
that has to be searchable and the general scaling problems happening with 
users' documents nowadays.

As for what any of this has to do with the original topic: very little. I 
guess that's Usenet for you. On the other hand all of this will have to 
be implemented in some language, and it's a sure bet that it's gonna wind 
up involving C code, C++ code, and/or code that runs on the JVM. :-)
0
10/17/2010 5:55:55 AM
On Oct 17, 12:55=A0am, ClassCastException <zjkg3d9g...@gmail.invalid>
wrote:
> On Sat, 16 Oct 2010 22:55:46 +0000, Martin Gregorie wrote:
> > On Sat, 16 Oct 2010 15:28:12 -0700, Keith Thompson wrote:
>
> >> fe...@palmen-it.de (Felix Palmen) writes:
> >>> * Juha Nieminen <nos...@thanks.invalid> [comp.lang.c]:
> >>>> In comp.lang.c++ Jon <jo...@spblocker.net> wrote:
> >>>>> It's a too-overloaded token: dos/windows paths,
>
> >>>> =A0Did you know that you can use '/' to separate paths in dos/window=
s
> >>>> as well? (Well, at least with all compilers I know.)
>
> >>> The compiler doesn't matter here. Most windows api functions accept
> >>> '/' nowadays (but not all). You're better off using '\' for the
> >>> windows platform, because there are still cases '/' won't work.
>
> >>> But then, it was Microsoft's awkward decision to use '\' as a path
> >>> separator with the rest of the world using '/'. It probably came back
> >>> on them the instant they built web functionality (browser, server) in
> >>> their OS.
>
> >> My understanding is that early versions of MS-DOS didn't support
> >> directories (or maybe it was CP/M). =A0By the time they decided to add
> >> directories, they were already using '/' as an option delimiter (like
> >> '-' in Unix).
>
> > Correct. MS-DOS 2.x introduced directories. Before that, MS-DOS, like
> > the other 8 bit OSen (FLEX, FLEX-09, CP/M, etc.), just had a flat list
> > of file names which was OK because few of its users could afford disks
> > big enough for the lack of directories to be a problem.
>
> It's about to happen again. In the mid-80s we reached the scaling limits
> of flat file lists and went to hierarchical directories. Now we're
> approaching the scaling limits of hierarchical directories. I haven't
> seen a modern system that doesn't have some ludicrously long full-path-
> names of files, highly deeply nested directory structures, and human
> trouble navigating the wilderness of files and keeping track of what
> files are for what purpose. Applications come with numerous files; on
> Windows systems they tend to be bundled with it in Program Files (with
> some libraries being elsewhere, or else duplicated wastefully); on Unix
> systems all kinds of config and other files get scattered to the four
> winds, /usr, /etc, /bin, and ~/.appname. Documents might end up anywhere,
> at least on Windows machines.
>
> Another tension is between organizing by program and organizing by higher
> level task. Say someone's throwing together a report and presentation.
> The report is made in Word, the presentation in PowerPoint, both using
> data from an Excel spreadsheet, and some of the graphs were copied,
> pasted into Photoshop, prettied up, and then embedded as .png files. Oh,
> and the whole thing is also HTMLized using FrontPage and posted to the
> company LAN as well as the PP presentation presented at the Friday
> afternoon general staff meeting and the printed report handed to the boss
> afterward in the hall outside the conference room. And the guys that
> couldn't attend the meeting in person phone-conferenced with those that
> were while consulting the copy on the LAN's internal website.
>
> So you've got Photoshopped pngs along with xls, doc, pp, and other files,
> that logically are part of one project. The user wants to file them as
> "2010 2nd quarter budget report" or whatever, under "2010 budget
> reports", under "budget reports", ideally; the programs all would like to
> keep track of their own files, docs with docs, xlses with xlses; and
> Windows itself would dearly love it if you'd just shove the whole mess in
> "My Documents" along with every single other file the user ever creates,
> thus turning back the clock to 1982 and flat file lists again.
>
> Unix users get nearly the analogous treatment with ~/ substituting for
> "My Documents" and the gimp for Photoshop and other more or less
> straightforward substitutions.
>
> Add to that how every kind of browser, file sharing tool, or similar
> client for downloadable content ends up with its own preferred
> directories for storing received files, plus iTunes, plus various sync
> folders for your phone and laptop, and so on, and so forth, and we're
> rapidly heading straight back into file management hell.
>
> What's our savior going to be? I'm beginning to suspect we're going to
> soon see a wave of new file management tools, at first appearing as third=
-
> party "knowledge manager" programs and eventually superseding Explorer-
> style shells as those have superseded the old C:\ prompt. These will
> provide their own nonhierarchical, link-based file management ability,
> probably with the ability to easily convert any subnetwork of stuff into
> web pages, or even acting as a web site itself; a locally-hosted web app
> that can easily adapt to make some stuff publishable remotely. Hyperlinks
> will creep into everything and become easy to create via drag and drop;
> no copying and pasting (or worse, memorizing and typing) long filenames.
>
> We already see hints of this with the big commercial websites. When was
> the last time you saw a human-readable URL at a major news or corporate
> site instead of something likehttp://site.example.com/html/content/
> cms/1.45.907/08102010/58120156-18856-ac78f9d107bb8088.htm or similarly.
> Occasionally you might see something like that but with a -report-on-iraq=
-
> casualties just before the .htm, but dollars to doughnuts you can delete
> that from the url or replace it with -report-on-stolen-doughnuts and it
> will still fetch the same page.
>
> Filenames and paths are becoming a layer increasingly managed by
> automation instead of manually, now by big website CMSes and soon by
> Windows 8 and Gnome 2015 I expect. The user will not type paths or even
> drill down through folders, he will follow hyperlinks.
>
> And when he needs to make a nonlocal jump he will use search. Faster,
> more incremental, and better search than we have so far.
>
> Vista already has raised the bar. I use some Vista machines and almost
> never click Programs after Start, unlike when forced to use an older XP
> box. Programs is slow, balky, unwieldy, and has shoddy ergonomics. It
> worked at first and didn't scale, despite being hierarchical. Vista's
> start menu has a nice fat incremental search box at the bottom just
> begging for your input, and you can find something like Calculator much
> faster by typing "calc" into it and then clicking one of the few
> remaining items above than by clicking Programs, then Accessories, etc.
> and waiting for each level of menu to unfold. Vista also makes it easy to
> tag photographs and search by tag, just by typing e.g. tag:(budget OR
> finance) into an Explorer window's upper-right-corner search box.
>
> Two things still scale poorly: the searches aren't especially fast,
> particularly on large tagged photo libraries, and photo tagging is itself
> one tag at a time one image at a time with poor support for copy, paste,
> or mass tagging (it would be nice to be able to select a large group of
> images and assign a tag to the lot with one command).
>
> The knowledge managers can beat Explorer by providing their own facility
> for associating any imported object with metadata, including metadata,
> and using suitable lightweight local database software to make it fast to
> search. This allows tagging images that aren't JPEG or TIFF (so don't
> have EXIF metadata) and tagging non-images, as well as doing so in a
> uniform manner. (EXIF tags and other document-format-supported metadata,
> like mp3 ID3 tags, could be imported when a file is first seen by the
> system.) Metatagging is most important, of course, for nonverbal data
> such as audio, still pictures, and video. (Advanced tools could
> potentially attempt voice recognition on audio and OCR on stills and
> video to extract what verbal content is in there, but fuzzy-matching
> would have to be used for this to be searchable I expect, and even then
> an unlabeled photo of an apple would not be found by searching for
> "apple" without solving some hard problems in AI and machine vision.)
>
> So your documents become much more searchable and you can link them into
> a web of interrelatedness. Something like this almost HAS to replace
> Explorer-style shells in the very near future, I'm thinking, if only
> because of the stupendous explosion of user-generated audiovisual content
> that has to be searchable and the general scaling problems happening with
> users' documents nowadays.
>

Sounds like Xerox Star!

0
mijoryx (966)
10/17/2010 7:04:20 AM
On Oct 16, 9:06=A0pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> "Jon" <jo...@spblocker.net> writes:
> > "Ben Bacarisse" <ben.use...@bsb.me.uk> wrote in message
> >news:0.4ef395e0027b90f26249.20101016114759BST.87zkuemn1c.fsf@bsb.me.uk..=
..
> >> "Jon" <jo...@spblocker.net> writes:
>
> >>> "Keith Thompson" <ks...@mib.org> wrote in message
> >>>news:lnbp6wbx0g.fsf@nuthaus.mib.org...
> >>>> "Jon" <jo...@spblocker.net> writes:
> >>>>> Nick Keighley wrote:
> >>>>>> use typedef (which should be called typealias)
>
> >>>>> #define Alias typedef
>
> >>>>> If the preprocessor is not your friend, then C will be your enemy.
> >>>>> You're
> >>>>> welcome.
>
> >>>> If I'm reading code that uses typedef, I have to understand how
> >>>> typedef
> >>>> works.
>
> >>>> If I'm reading code that uses your "Alias" macro, I still have to
> >>>> understand how typedef works -- *and* that "Alias" means typedef.
>
> >>>> It doesn't help.
>
> >>> Think of a new programmer. Is he likely to understand that typedef
> >>> means
> >>> alias in reality or likely to think that it means declaration of a ne=
w
> >>> type? Therefore, "Alias" is better.
>
> >> A #define is particularly bad for new programmers
>
> > The issue is not a define,
>
> I thought you were suggesting one.
>
> > but rather that "typedef" is a poor choice of
> > keyword for what it does in the C language. "alias" would have been muc=
h
> > better.
>
> I'd prefer a keyword that included "type" in it because alias is a very
> general word, but I agree that there might be a better word. =A0I don't
> agree (given the C language we have) that the #define you posted makes
> anything better.


#define typealias typedef

?
0
luser
10/17/2010 7:12:53 AM
Jon wrote:

> Stop lying: you're a "shoot-from-the-hip gunslinger". I know what you're
> thinking:
> 
> "Did he fire six shots or only five?" Well, to tell you the truth, in all
> this excitement I kind of lost track myself. But being as this is C, the
> most powerful programming language in the world, and would blow your
> finger clean off, you've got to ask yourself one question: "Do I feel
> lucky?" Well, do ya, punk?
> 

Are you high?


Rui Maciel
0
Rui
10/17/2010 9:43:41 AM
Jon wrote:

> In your case (not anyone else), because you don't know that it's not
> practical.

Freudian projection is a hell of a defense mechanism.


Rui Maciel
0
Rui
10/17/2010 9:49:32 AM
ClassCastException wrote:

> There's one way in which the collision can bother *the C coder*, though:
> the backslash has to be escaped in string literals, unlike the forward
> slash, and paths are commonplace string literals, so on systems that use
> the backslash the coder may be inconvenienced by the need to do much more
> escaping than on systems that use the forward slash path separator.

I see what you mean but I don't believe that to be a problem.  If a programmer decides to, for 
example, rely on a CPP macro to specify text strings, including paths, that extend for multiple 
lines then he will expect the trailing backslash.  Even if the programmer has difficulties 
remembering this, he only needs to start using any text editor which implmeents syntax highlighting.


Rui Maciel
0
Rui
10/17/2010 10:00:08 AM
On 16 Oct, 11:01, Rui Maciel <rui.mac...@gmail.com> wrote:
> Jon wrote:
> > Note that string literals in C++ are not std::strings.
>
> A "safe string type" is not necessarily, nor it needs to be, a string literal.

and you can initialise a "safe string" from a string literal.

   std::string s ("pippo");
   Safe_string s = ss_create ("pippo");

0
Nick
10/17/2010 10:07:21 AM
On 16 Oct, 08:29, "Jon" <jo...@spblocker.net> wrote:
> "Tom Anderson" <t...@urchin.earth.li> wrote in message
>
> news:alpine.DEB.1.10.1010141247000.22804@urchin.earth.li...
>
> > On Wed, 13 Oct 2010, Jon wrote:
>
> >> Joshua Cranmer wrote:
>
> >>> the use of `\' as an escape character,
>
> >> A bad thing.
>
> > Bullshit. Justify this or strangle yourself immediately.
>
> It's a too-overloaded token: dos/windows paths, line continuation,
> escape... making for unnecessary contextual analysis by parsers.

continuation lines are sorted out before the parser gets a look in.
And \ in strings also don't need parsing.
0
Nick
10/17/2010 10:09:11 AM
On 17 Oct, 03:06, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> "Jon" <jo...@spblocker.net> writes:
> > "Ben Bacarisse" <ben.use...@bsb.me.uk> wrote in message
> >news:0.4ef395e0027b90f26249.20101016114759BST.87zkuemn1c.fsf@bsb.me.uk..=
..
> >> "Jon" <jo...@spblocker.net> writes:
> >>> "Keith Thompson" <ks...@mib.org> wrote in message
> >>>news:lnbp6wbx0g.fsf@nuthaus.mib.org...
> >>>> "Jon" <jo...@spblocker.net> writes:
> >>>>> Nick Keighley wrote:


> >>>>>> use typedef (which should be called typealias)
>
> >>>>> #define Alias typedef
>
> >>>>> If the preprocessor is not your friend, then C will be your enemy.

terrible advice.

Look, this whole thread is a contrafactual. *if* we'd been sitting at
Dennis Ritchie's right hand when he was designing C what would we have
suggested to him?. There's no suggestion that any of these changes to
C are actually real.

> >>>>> You're welcome.
>
> >>>> If I'm reading code that uses typedef, I have to understand how
> >>>> typedef works.
>
> >>>> If I'm reading code that uses your "Alias" macro, I still have to
> >>>> understand how typedef works -- *and* that "Alias" means typedef.
>
> >>>> It doesn't help.
>
> >>> Think of a new programmer. Is he likely to understand that typedef
> >>> means
> >>> alias in reality or likely to think that it means declaration of a ne=
w
> >>> type? Therefore, "Alias" is better.
>
> >> A #define is particularly bad for new programmers
>
> > The issue is not a define,
>
> I thought you were suggesting one.
>
> > but rather that "typedef" is a poor choice of
> > keyword for what it does in the C language. "alias" would have been muc=
h
> > better.
>
> I'd prefer a keyword that included "type" in it because alias is a very
> general word, but I agree that there might be a better word. =A0I don't
> agree (given the C language we have) that the #define you posted makes
> anything better.

my original suggestion was "typealias" not "alias"
0
Nick
10/17/2010 10:24:09 AM
On 15 Oct, 16:55, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> "BartC" <b...@freeuk.com> writes:
>
> <snip>
>
> > In fact, in the real world outside of C programming, "=3D" to mean
> > equality is pretty much universal.
>
> I have no idea how far from universal "pretty much universal" is but I
> can think of:
>
> =A0 =A0 B C++ C# Objective-C D Haskell Java PHP (two equality operators
> =A0 =A0 neither of which is =3D) Perl Python Fortran (again two, =3D=3D a=
nd .eg.)
> =A0 =A0 Ruby Lua Scala Erlang (two again) Algol 68 (one the two is not =
=3D)
> =A0 =A0 Prolog TCL
>
> and probably others. =A0How many would make it not pretty much universal?

Scheme

    (set! i 1)
0
10/17/2010 10:29:05 AM
On 15 Oct, 21:53, fe...@palmen-it.de (Felix Palmen) wrote:
> * Ben Bacarisse <ben.use...@bsb.me.uk>:
>
> > Yes, I agree that is what he meant, but =3D in mathematics is not at al=
l
> > the same kind of beast as the equality operator in a programming
> > language. =A0x =3D y + 1 is not an expression with a value -- it is a k=
ind
> > of definition (or maybe a constraint). =A0I am not at all bothered that
> > the operator which produces 0 or 1 from a comparison is written
> > differently.
>
> It is NOT a definition. It is a claim. It reads: "x equals y + 1". Of
> course, whoever writes anything like that is convinced that the claim
> really is true. But whent it comes to expression evaluation, it's just
> natural to check the claim and assign a boolean value to it.
>
> Assignment is something completely different. You see assignment in
> mathematics when defining a function:
>
> f: x -> x=B2

I can't see an assignment there. I see a definition. Does f change
during the course of the proof (computation?)

> So, the colon is the mathematical symbol for assignment. Following the
> principle of least surprise, the colon should be used for assignment in
> programming languages, too. That said, ":=3D" is still better (less
> surprising) than just "=3D", which states equality in mathematics.
0
Nick
10/17/2010 10:33:21 AM
On 17 Oct, 11:29, Nick Keighley <nick_keighley_nos...@hotmail.com>
wrote:
> On 15 Oct, 16:55, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>
>
>
>
>
> > "BartC" <b...@freeuk.com> writes:
>
> > <snip>
>
> > > In fact, in the real world outside of C programming, "=3D" to mean
> > > equality is pretty much universal.
>
> > I have no idea how far from universal "pretty much universal" is but I
> > can think of:
>
> > =A0 =A0 B C++ C# Objective-C D Haskell Java PHP (two equality operators
> > =A0 =A0 neither of which is =3D) Perl Python Fortran (again two, =3D=3D=
 and .eg.)
> > =A0 =A0 Ruby Lua Scala Erlang (two again) Algol 68 (one the two is not =
=3D)
> > =A0 =A0 Prolog TCL
>
> > and probably others. =A0How many would make it not pretty much universa=
l?
>
> Scheme
>
> =A0 =A0 (set! i 1)

nonsense of course. I'm confusing assignment with equality (see it
*is* confusing!)

scheme has various ways of testing for equality

   (=3D i 1)
   (eq? i 'red)
   (string=3D? i "red yellow")

etc.



0
10/17/2010 10:37:49 AM
On 16 Oct, 14:14, Richard <rgrd...@gmail.com> wrote:
> "Johannes Schaub (litb)" <schaub-johan...@web.de> writes:
> > Alexander 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.
>
> > The first thing I would do is to get rid of "->". Srsly, if the dot operator
> > is applied on a pointer value p, it will be equivalent to "(*p).mem".
>
> You are joking?

why? I've always thought it quite a reasonable idea. What's the
problem?

But then I always thought having to explicitly take the address of
something to mimic pass by reference was bizzare.

   swop (&i, &j);



0
10/17/2010 10:40:34 AM
On 16 Oct, 14:51, Richard <rgrd...@gmail.com> wrote:
> gaze...@shell.xmission.com (Kenny McCormack) writes:
> > In article <i9c9kt$3a...@news.eternal-september.org>,
> > Richard =A0<rgrd...@gmail.com> wrote:
> > ...
> >>> I see no reasons for "->".
>
> >>Huh? What language are you talking about? If you dont see the point in
> >>language for -> in C then I am amazed.
>
> > Now, now. =A0Calm down. =A0Obviously, it won't ever be changed, because=
 C is
> > what it is.
>
> > But the argument, which is valid as far as I can tell, is that the "->"
> > operator is unnecessary because "." is all you need. =A0I.e., if we wer=
e
> > doing it over from scratch, we could say that whenever we see:
>
> > =A0 =A0something.member
>
> > and the compiler can determine that something is a pointer, then it
> > would internally convert it to:
>
> > =A0 =A0something -> member
>
> > Since C is a statically typed language, this should work.
>
> > And, in fact, if I am reading things that others have posted on the
> > subject correctly, other languages, like Java, do exactly this.
>
> > Finally, note that the basic argument of "If it isn't necessary, then i=
t
> > is bad" isn't necessarily convincing. =A0Some people have argued that e=
ven
> > if "->" isn't necessary, it is still a good thing, because it makes the
> > code easier to understand. =A0I.e., it is a "documentation aid".
> > Personally, I favor this last argument.
>
> I want to know when its a pointer.
>
> I realise its the new fad to make C look like some hackup like Java but
> I want to know what I am dealing with.
>
> "->" tells me just that.

so you're in favour of specially operators for floating point numbers?

   i =3D i + 1;
   d =3D d +d 1.0;

because I too want to know if I'm dealing with an integer or a
floating point

Couldn't you just look at the definition, which will be close by, if
you are momentarily confused about the type of a variable?

0
10/17/2010 10:44:32 AM
"Jon" <jomar@spblocker.net> writes:

> "Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message 
> news:0.1380ee9f31ea3465db09.20101017030653BST.87ocatmv2a.fsf@bsb.me.uk...
>> "Jon" <jomar@spblocker.net> writes:
>>
>>> "Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message
>>> news:0.4ef395e0027b90f26249.20101016114759BST.87zkuemn1c.fsf@bsb.me.uk...
>>>> "Jon" <jomar@spblocker.net> writes:
>>>>
>>>>> "Keith Thompson" <kst-u@mib.org> wrote in message
>>>>> news:lnbp6wbx0g.fsf@nuthaus.mib.org...
>>>>>> "Jon" <jomar@spblocker.net> writes:
>>>>>>> Nick Keighley wrote:
>>>>>>>> use typedef (which should be called typealias)
>>>>>>>
>>>>>>> #define Alias typedef
>>>>>>>
>>>>>>> If the preprocessor is not your friend, then C will be your enemy.
>>>>>>> You're
>>>>>>> welcome.
>>>>>>
>>>>>> If I'm reading code that uses typedef, I have to understand how
>>>>>> typedef
>>>>>> works.
>>>>>>
>>>>>> If I'm reading code that uses your "Alias" macro, I still have to
>>>>>> understand how typedef works -- *and* that "Alias" means typedef.
>>>>>>
>>>>>> It doesn't help.
>>>>>
>>>>> Think of a new programmer. Is he likely to understand that typedef
>>>>> means
>>>>> alias in reality or likely to think that it means declaration of a 
>>>>> new
>>>>> type? Therefore, "Alias" is better.
>>>>
>>>> A #define is particularly bad for new programmers
>>>
>>> The issue is not a define,
>>
>> I thought you were suggesting one.
>
> Pfft. I know better than to "suggest" a change to the ISO C standard in 
> this ng.

Eh?  I know you didn't.  You suggested a #define.  I was commenting on
only on that and, in particular, the value you claimed it would have for
new programmers.

<snip>
-- 
Ben.
0
Ben
10/17/2010 12:33:39 PM
luser- -droog <mijoryx@yahoo.com> writes:

> On Oct 16, 9:06 pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>> "Jon" <jo...@spblocker.net> writes:
>> > "Ben Bacarisse" <ben.use...@bsb.me.uk> wrote in message
>> >news:0.4ef395e0027b90f26249.20101016114759BST.87zkuemn1c.fsf@bsb.me.uk...
>> >> "Jon" <jo...@spblocker.net> writes:
>>
>> >>> "Keith Thompson" <ks...@mib.org> wrote in message
>> >>>news:lnbp6wbx0g.fsf@nuthaus.mib.org...
>> >>>> "Jon" <jo...@spblocker.net> writes:
>> >>>>> Nick Keighley wrote:
>> >>>>>> use typedef (which should be called typealias)
>>
>> >>>>> #define Alias typedef
>>
>> >>>>> If the preprocessor is not your friend, then C will be your enemy.
>> >>>>> You're
>> >>>>> welcome.
>>
>> >>>> If I'm reading code that uses typedef, I have to understand how
>> >>>> typedef
>> >>>> works.
>>
>> >>>> If I'm reading code that uses your "Alias" macro, I still have to
>> >>>> understand how typedef works -- *and* that "Alias" means typedef.
>>
>> >>>> It doesn't help.
>>
>> >>> Think of a new programmer. Is he likely to understand that typedef
>> >>> means
>> >>> alias in reality or likely to think that it means declaration of a new
>> >>> type? Therefore, "Alias" is better.
>>
>> >> A #define is particularly bad for new programmers
>>
>> > The issue is not a define,
>>
>> I thought you were suggesting one.
>>
>> > but rather that "typedef" is a poor choice of
>> > keyword for what it does in the C language. "alias" would have been much
>> > better.
>>
>> I'd prefer a keyword that included "type" in it because alias is a very
>> general word, but I agree that there might be a better word.  I don't
>> agree (given the C language we have) that the #define you posted makes
>> anything better.
>
> #define typealias typedef
>
> ?

Jokes are best flagged in some way (a smiley or maybe a few !!s).  If
this was not a joke (it certainly made me smile) the I refer you to the
previous posts from Keith Thompson and myself.

-- 
Ben.
0
Ben
10/17/2010 12:42:36 PM
Nick Keighley <nick_keighley_nospam@hotmail.com> writes:

> On 16 Oct, 11:01, Rui Maciel <rui.mac...@gmail.com> wrote:
>> Jon wrote:
>> > Note that string literals in C++ are not std::strings.
>>
>> A "safe string type" is not necessarily, nor it needs to be, a string literal.
>
> and you can initialise a "safe string" from a string literal.
>
>    std::string s ("pippo");
>    Safe_string s = ss_create ("pippo");

For the C version, you can't do this at file scope (but that may not
matter much).  If you don't have C99 things are worse -- you can't use
this method to initialise an element of an aggregate.

-- 
Ben.
0
Ben
10/17/2010 12:58:44 PM
Nick Keighley <nick_keighley_nospam@hotmail.com> writes:

> On 17 Oct, 11:29, Nick Keighley <nick_keighley_nos...@hotmail.com>
> wrote:
>> On 15 Oct, 16:55, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>>
>> > "BartC" <b...@freeuk.com> writes:
>>
>> > <snip>
>>
>> > > In fact, in the real world outside of C programming, "=" to mean
>> > > equality is pretty much universal.
>>
>> > I have no idea how far from universal "pretty much universal" is but I
>> > can think of:
>>
>> >     B C++ C# Objective-C D Haskell Java PHP (two equality operators
>> >     neither of which is =) Perl Python Fortran (again two, == and .eg.)
>> >     Ruby Lua Scala Erlang (two again) Algol 68 (one the two is not =)
>> >     Prolog TCL
>>
>> > and probably others.  How many would make it not pretty much universal?
>>
>> Scheme
>>
>>     (set! i 1)
>
> nonsense of course. I'm confusing assignment with equality (see it
> *is* confusing!)
>
> scheme has various ways of testing for equality
>
>    (= i 1)
>    (eq? i 'red)
>    (string=? i "red yellow")

Yes, one of which is, in fact, = so I left it out.  I should have left
Algol 68 out for the same reason.

-- 
Ben.
0
Ben
10/17/2010 1:01:23 PM
On Sun, 17 Oct 2010 02:56:13 +0200, Felix Palmen wrote:

> * Keith Thompson <kst-u@mib.org> [comp.lang.c]:
>> felix@palmen-it.de (Felix Palmen) writes:
>>> But then, it was Microsoft's awkward decision to use '\' as a path
>>> separator with the rest of the world using '/'. It probably came back
>>> on them the instant they built web functionality (browser, server) in
>>> their OS.
> [early MS-DOS]
>> The Unix convention probably wasn't as widespread then as it is now, so
>> using '\' wasn't an obviously absurd choice at the time. (VMS, for
>> example, uses '.' to separate directory names.)
> 
> Maybe it wasn't too obvious back then that interoperability could matter
> some day. But, (we're talking about 1980...) Unix was already used a
> lot. Only 5 years later, AmigaOS had the "standard" path separator (and
> also, to some extent, the concept of mounting devices).
>
....and Microware OS-9, which appeared in 1980 thus preceding MS-DOS, used 
the UNIX convention of / in pathnames and -options and provided system 
support for holding text (error messages etc.) independently of programs. 
Its still alive and well in the realtime embedded OS world. Indeed, some 
of us still run it on desktops. I have the 1992 vintage OS-9 v2.4 and 
have yet to find a bug in the OS, utilities or development tools. I was 
and am impressed with that record.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |
0
Martin
10/17/2010 1:47:56 PM
luser- -droog <mijoryx@yahoo.com> writes:
[143 lines deleted]
>>
>
> Sounds like Xerox Star!

You do know that you don't have to quote an entire article to post a
one-line response, don't you?


-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
0
Keith
10/17/2010 4:31:50 PM
luser- -droog <mijoryx@yahoo.com> writes:
> On Oct 16, 9:06 pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>> "Jon" <jo...@spblocker.net> writes:
[...]
>> > The issue is not a define,
>>
>> I thought you were suggesting one.
>>
>> > but rather that "typedef" is a poor choice of
>> > keyword for what it does in the C language. "alias" would have been much
>> > better.
>>
>> I'd prefer a keyword that included "type" in it because alias is a very
>> general word, but I agree that there might be a better word.  I don't
>> agree (given the C language we have) that the #define you posted makes
>> anything better.
>
>
> #define typealias typedef
>
> ?

I agree that "typedef" was not a good choice of name for the semantics.
Perhaps "typealias" would have been better.

But "typedef" is in the language, and it's not going away.  Every C
programmer needs to understand that "typedef" doesn't define a type
(just as "const" doesn't mean constant).

Adding an obfuscating macro *does not help*, any more than
    #define BEGIN {
    #define END }
    #define IF if (
    #define THEN ) {
and so on.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
0
Keith
10/17/2010 4:35:40 PM
Nick Keighley <nick_keighley_nospam@hotmail.com> writes:
[...]
> But then I always thought having to explicitly take the address of
> something to mimic pass by reference was bizzare.
>
>    swop (&i, &j);

On the other hand, there's something to be said for being able look
at a function call and *know* that the arguments won't be modified
(unless it's really a macro invocation).

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
0
Keith
10/17/2010 4:38:33 PM
On 17 Oct, 17:38, Keith Thompson <ks...@mib.org> wrote:
> Nick Keighley <nick_keighley_nos...@hotmail.com> writes:
>
> [...]
>
> > But then I always thought having to explicitly take the address of
> > something to mimic pass by reference was bizzare.
>
> > =A0 =A0swop (&i, &j);
>
> On the other hand, there's something to be said for being able look
> at a function call and *know* that the arguments won't be modified
> (unless it's really a macro invocation).

most other languages manage without it
0
Nick
10/17/2010 4:44:30 PM
On Oct 17, 11:31=A0am, Keith Thompson <ks...@mib.org> wrote:
> luser- -droog <mijo...@yahoo.com> writes:
>
> [143 lines deleted]
>
>
>
> > Sounds like Xerox Star!
>
> You do know that you don't have to quote an entire article to post a
> one-line response, don't you?
>

ACK!
0
luser
10/17/2010 4:47:52 PM
On Oct 17, 7:42=A0am, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> luser- -droog <mijo...@yahoo.com> writes:
> > On Oct 16, 9:06=A0pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> >> I'd prefer a keyword that included "type" in it because alias is a ver=
y
> >> general word, but I agree that there might be a better word. =A0I don'=
t
> >> agree (given the C language we have) that the #define you posted makes
> >> anything better.
>
> > #define typealias typedef
>
> > ?
>
> Jokes are best flagged in some way (a smiley or maybe a few !!s). =A0If
> this was not a joke (it certainly made me smile) the I refer you to the
> previous posts from Keith Thompson and myself.
>

Two faux pas in one night!
That can't be a record, but I am duly repentant.

--
Relentless Energy Drink
0
luser
10/17/2010 4:57:29 PM
* Keith Thompson <kst-u@mib.org>:
> Regardless of how complex the type is, a typedef does nothing more that
> create an alias for the existing type.  The definition is *always* "just
> another type".

IBTD. As I already said earlier, new types are /always/ defined by means
of existing ones (at least in any language I know that supports type
definitions). But as soon as the type is more complex than just one
simple builtin type, I don't think "alias" really describes what's going
on.

| typedef struct {
|   float speed;
|   char *model;
|   
|   void (*accelerate)(void *this, float delta);
|   void (*decelerate)(void *this, float delta);
| } Car;

Would you really call "Car" an alias?

(finally ... a car example :D)

-- 
 Felix Palmen       (Zirias)  + [PGP] Felix Palmen <felix@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
0
felix
10/17/2010 7:15:43 PM

"Kenny McCormack" <gazelle@shell.xmission.com> wrote in message
news:i9cacl$a0b$1@news.xmission.com...
> In article <i9c9kt$3au$2@news.eternal-september.org>,
> Richard  <rgrdev_@gmail.com> wrote:
> ...
>>> I see no reasons for "->".
>>
>>Huh? What language are you talking about? If you dont see the point in
>>language for -> in C then I am amazed.
>
> Now, now.  Calm down.  Obviously, it won't ever be changed, because C is
> what it is.
>
> But the argument, which is valid as far as I can tell, is that the "->"
> operator is unnecessary because "." is all you need.  I.e., if we were
> doing it over from scratch, we could say that whenever we see:
>
> something.member
>
> and the compiler can determine that something is a pointer, then it
> would internally convert it to:
>
> something -> member
>
> Since C is a statically typed language, this should work.

It means that given the following defs:

struct pt {int x,y,z;} v = {2708,2716,2732};
struct pt*    p=&v;
struct pt**   q=&p;
struct pt***  r=&q;

then currently, to access the .y coordinate using only ".", each of these
variables in turn requires:

v.y;
(*p).y;
(**q).y;
(***r).y;

Using "->", this simplifies (?) to:

v.y;
p->y;
(*q)->y;
(**r)->y;

So "->" only really helps when there is a single level of indirection.

The proposal to allow "." to dereference pointers /I think/ would allow:

v.y;
p.y;
q.y;
r.y;

Ie. dereferencing, no matter how many levels, would be completely
transparent (but in a similar manner to array indexing).

If the proposal is for it to only work for one level, then I don't know what
the pattern would look like for multiple indirection.

> And, in fact, if I am reading things that others have posted on the
> subject correctly, other languages, like Java, do exactly this.
>
> Finally, note that the basic argument of "If it isn't necessary, then it
> is bad" isn't necessarily convincing.  Some people have argued that even
> if "->" isn't necessary, it is still a good thing, because it makes the
> code easier to understand.  I.e., it is a "documentation aid".
> Personally, I favor this last argument.

Actually I'm warming to the idea of using solely ".", but only because C has
an otherwise ugly syntax when progressing between 0, 1 and N levels of
indirection (using 2 different forms when only "." is used, and 3 different
forms when "->" is used). (Unlike, say, Pascal, where you just have N
consecutive "^" symbols; very neat.)

-- 
bartc 

0
bc (2337)
10/17/2010 8:41:20 PM
felix@palmen-it.de (Felix Palmen) writes:
> * Keith Thompson <kst-u@mib.org>:
>> Regardless of how complex the type is, a typedef does nothing more that
>> create an alias for the existing type.  The definition is *always* "just
>> another type".
>
> IBTD. As I already said earlier, new types are /always/ defined by means
> of existing ones (at least in any language I know that supports type
> definitions). But as soon as the type is more complex than just one
> simple builtin type, I don't think "alias" really describes what's going
> on.
>
> | typedef struct {
> |   float speed;
> |   char *model;
> |   
> |   void (*accelerate)(void *this, float delta);
> |   void (*decelerate)(void *this, float delta);
> | } Car;
>
> Would you really call "Car" an alias?
>
> (finally ... a car example :D)

Yes, the name "Car" (created by the typedef) is nothing more than an
alias for the type "struct { ... }".

If you had left out the typedef keyword and the name "Car":

    struct {
        float speed;
        char *model;

        void (*accelerate)(void *this, float delta);
        void (*decelerate)(void *this, float delta);
    };

then you would have defined a new type, exactly the same type that was
defined by your original declaration.  The only difference is that
the "struct { ... };" form does not additionally create an alias
"Car" for that type.

It might be simpler to use an example where the struct has a tag.  This:

    typedef struct car {
        /* ... */
    } Car;

is equivalent to this:

    struct car {
        /* ... */
    };
    typedef struct car Car;

In both cases, we create a new type called "struct car", and then
an alias for the same type called "Car".

Your original example doesn't give a name to the created type,
but that's the only difference.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
0
Keith
10/18/2010 12:06:03 AM
* Keith Thompson <kst-u@mib.org>:
> felix@palmen-it.de (Felix Palmen) writes:
>> | typedef struct {
>> |   float speed;
>> |   char *model;
>> |   
>> |   void (*accelerate)(void *this, float delta);
>> |   void (*decelerate)(void *this, float delta);
>> | } Car;
>>
>> Would you really call "Car" an alias?
>>
>> (finally ... a car example :D)
> 
> Yes, the name "Car" (created by the typedef) is nothing more than an
> alias for the type "struct { ... }".

No. You cannot sensibly argument that a notation of "struct { ... }"
identifies a type -- it describes it. The description may be
unambiguous, so it would be possible to describe the type each and every
time you need it, but for /defining/ a type, it should get its own
identifier -- just like defining a function, a variable, etc.

>    struct car {
>        /* ... */
>    };
>    typedef struct car Car;

Another way to do it, this way you define a type called "struct car" --
one of the peculiarities of C I don't like. You need to use typedef if
you want to define your type in the "global" identifier namespace. But
at least, that's the reason typedef is perfectly sensible named, IMO.

> Your original example doesn't give a name to the created type,
> but that's the only difference.

It does, the name is "Car" (as opposed to "struct car"). Of course, if
you give it both names, one is obviously an alias for the other.

Regards,
Felix

-- 
 Felix Palmen       (Zirias)  + [PGP] Felix Palmen <felix@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
0
felix
10/18/2010 5:18:21 AM
Keith Thompson <kst-u@mib.org> writes:

> luser- -droog <mijoryx@yahoo.com> writes:
>> On Oct 16, 9:06 pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>>> "Jon" <jo...@spblocker.net> writes:
> [...]
>>> > The issue is not a define,
>>>
>>> I thought you were suggesting one.
>>>
>>> > but rather that "typedef" is a poor choice of
>>> > keyword for what it does in the C language. "alias" would have been much
>>> > better.
>>>
>>> I'd prefer a keyword that included "type" in it because alias is a very
>>> general word, but I agree that there might be a better word.  I don't
>>> agree (given the C language we have) that the #define you posted makes
>>> anything better.
>>
>>
>> #define typealias typedef
>>
>> ?
>
> I agree that "typedef" was not a good choice of name for the semantics.
> Perhaps "typealias" would have been better.
>
> But "typedef" is in the language, and it's not going away.  Every C
> programmer needs to understand that "typedef" doesn't define a type
> (just as "const" doesn't mean constant).

I think this is all about how you use words, again.  In one sense it
does define a type.  Particularly when used for things other than
structures.

What it does is it gives you a token that can then be used as the name
of a type.  In a sense, C starts off with int, char and the like.

If you do typedef like:
typedef char *(* FUNCT)(int *[]);
then in a sense you have now added FUNCT as a type to C - functions
taking an array of integer pointers and returning a character pointer.  
You can now use it just the way you would use "int" alone.

I think as  the language as evolved and got standardised, we've shifted
the meaning of type to a slightly different meaning - one in which
"struct fred *" is as much a type as "char" is.  But I think there was a
logic behind the meaning, and I think saying it doesn't "define a type"
is possibly confusing for some.

I say that because to me, when I first encountered typedef, it was quite
clear what it did.  It defined a new "high level" type that you could
use just like the built in ones.

> Adding an obfuscating macro *does not help*, any more than
>     #define BEGIN {
>     #define END }
>     #define IF if (
>     #define THEN ) {
> and so on.

Wholehearted agreement here.
-- 
Online waterways route planner            | http://canalplan.eu
Plan trips, see photos, check facilities  | http://canalplan.org.uk
0
Nick
10/18/2010 6:39:46 AM
On Sun, 17 Oct 2010, ClassCastException wrote:

> On Sat, 16 Oct 2010 22:55:46 +0000, Martin Gregorie wrote:
>
>> MS-DOS, like the other 8 bit OSen (FLEX, FLEX-09, CP/M, etc.), just had 
>> a flat list of file names which was OK because few of its users could 
>> afford disks big enough for the lack of directories to be a problem.
>
> It's about to happen again. In the mid-80s we reached the scaling limits 
> of flat file lists and went to hierarchical directories. Now we're 
> approaching the scaling limits of hierarchical directories. I haven't 
> seen a modern system that doesn't have some ludicrously long full-path- 
> names of files, highly deeply nested directory structures, and human 
> trouble navigating the wilderness of files and keeping track of what 
> files are for what purpose.

You should come and see mine. Nothing special, bog-standard Fedora 13, 
which follows big-standard unix filesystem layout. I have a home 
directory, in that i have subdirectories for different sorts of things 
(Documents, Pictures, Music, Code), in those i have subdirectories for 
projects, and in those i have files. A typical absolute path:

/home/tom/Code/ProspaceFile/ProspaceBuilder.java

Doesn't seem ludicrously long to me. Especially given that the /home/tom 
is often implicit.

Things that aren't my documents can live in other places. For instance, 
javac is at:

/usr/bin/javac

As are almost all the other programs i've installed with the package 
manager. Some things i've installed myself are slightly deeper; for 
example, the OpenJPA javadoc is at:

/usr/local/share/doc/apache-openjpa-2.0.1/javadoc/index.html

Even that isn't that long, really. I certainly don't have trouble 
navigating. I know:

* My stuff is in /home/tom/${appropriate subdirectory}
* System stuff is in /bin, /sbin, /etc, /lib, /var and so on
* Package-managed stuff is in /usr (/usr/bin, /usr/lib etc), and also /etc
   and /var
* System-wide stuff i've installed by hand is in /usr/local, except for
   some of it which is in /opt

There are some more obscure things, and Chrome goes in /opt despite being 
package-managed, but that's 99% of what i need to know.

If something is package-managed, i can ask the package manager about it. 
If i know the filename but not the location, i can ask locate.

> Applications come with numerous files; on Windows systems they tend to 
> be bundled with it in Program Files (with some libraries being 
> elsewhere, or else duplicated wastefully); on Unix systems all kinds of 
> config and other files get scattered to the four winds, /usr, /etc, 
> /bin, and ~/.appname.

True. But the package manager knows where they are (barring ~/.*, 
generally), and mostly, i don't care.

> Documents might end up anywhere, at least on Windows machines.

Yeah, that doesn't tend to happen to me. It also didn't tend to happen to 
me when i used Windows, from what i recall.

> Another tension is between organizing by program and organizing by higher
> level task.

No, because you just don't organise by program. That's a dumb idea which 
went out some time in the late 80s.

> Say someone's throwing together a report and presentation. The report is 
> made in Word, the presentation in PowerPoint, both using data from an 
> Excel spreadsheet, and some of the graphs were copied, pasted into 
> Photoshop, prettied up, and then embedded as .png files. Oh, and the 
> whole thing is also HTMLized using FrontPage and posted to the company 
> LAN as well as the PP presentation presented at the Friday afternoon 
> general staff meeting and the printed report handed to the boss 
> afterward in the hall outside the conference room. And the guys that 
> couldn't attend the meeting in person phone-conferenced with those that 
> were while consulting the copy on the LAN's internal website.
>
> So you've got Photoshopped pngs along with xls, doc, pp, and other 
> files, that logically are part of one project. The user wants to file 
> them as "2010 2nd quarter budget report" or whatever, under "2010 budget 
> reports", under "budget reports", ideally; the programs all would like 
> to keep track of their own files, docs with docs, xlses with xlses;

Do they? I don't recall any programs i used on Windows doing that.

> and Windows itself would dearly love it if you'd just shove the whole 
> mess in "My Documents" along with every single other file the user ever 
> creates,

So keep your project folders in My Documents. Even if Windows dumps you 
there rather than the last folder you used or whatever, your destination 
is a few clicks away.

> Add to that how every kind of browser, file sharing tool, or similar 
> client for downloadable content ends up with its own preferred 
> directories for storing received files, plus iTunes, plus various sync 
> folders for your phone and laptop, and so on, and so forth, and we're 
> rapidly heading straight back into file management hell.

I would agree that we need better management of that. For me, it's not too 
bad - Firefox and Chrome save things to ~/Downloads, rtorrent saves to 
wherever i tell it to, i don't use a tool for my phone or camera (they're 
mass storage devices - why on earth would i?), and i don't have any other 
downloaders. Well, unless you count sftp, ftp, and so on, but those put 
things where you tell them.

> What's our savior going to be? I'm beginning to suspect we're going to 
> soon see a wave of new file management tools, at first appearing as 
> third- party "knowledge manager" programs and eventually superseding 
> Explorer- style shells as those have superseded the old C:\ prompt. 
> These will provide their own nonhierarchical, link-based file management 
> ability, probably with the ability to easily convert any subnetwork of 
> stuff into web pages, or even acting as a web site itself; a 
> locally-hosted web app that can easily adapt to make some stuff 
> publishable remotely. Hyperlinks will creep into everything and become 
> easy to create via drag and drop; no copying and pasting (or worse, 
> memorizing and typing) long filenames.

Keep taking the medicine.

tom

-- 
90% mental, 25% effort, 8% mathematics
0
twic (2088)
10/18/2010 7:46:46 AM
On Oct 15, 3:28=A0pm, "BartC" <b...@freeuk.com> wrote:
> "Michael Foukarakis" <electricde...@gmail.com> wrote in message
>
> news:21ed201b-4880-484e-ae11-2f1e223ff8fc@j25g2000yqa.googlegroups.com...
>
>
>
> > On Oct 10, 2:04 am, August Karlstrom <fusionf...@gmail.com> wrote:
> >> 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 `=3D' 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 `=3D=3D'. In code comments it also makes the usage=
 of
> >> the mathematical `=3D' slightly ambiguous which forces people to use `=
=3D=3D'
> >> instead. UGLY is the word.
>
> >> It's a shame that a left arrow is not in the (7 bit) ASCII table. IMHO
> >> `:=3D' is second best to the left arrow.
>
> > I don't know. I learnt C pretty young, and I was able to distinguish
> > between '=3D' and '=3D=3D', thanks to three subtle notions:
>
> > a) They differ by one character.
> > b) I knew the quantitative difference between 1 (one) and 2 (two).
> > c) I was told they had different behaviour.
>
> Until you also use a second language where the meanings of "=3D" and "=3D=
=3D" are
> reversed. Yet (a), (b) and (c) are still true for each language.
>
> In fact, in the real world outside of C programming, "=3D" to mean equali=
ty is
> pretty much universal.

I don't understand what you mean by "real world". In case you mean
"outside of programming" (i.e. mathematics) you are right. If you mean
"languages other than C" you are entirely wrong, though. As I'm
writing this, I'm thinking that out of all the languages I know,
Erlang is probably the only one where '=3D' does not explicitly stand
for "assignment".

But that is besides the point. My point is that I think as humans we
have the capability to differentiate between symbols and their
meanings based on context. Whether those that don't should be
accomodated, I don't really care for that discussion (yet).
0
Michael
10/18/2010 7:49:54 AM
On Oct 15, 8:20=A0pm, Seebs <usenet-nos...@seebs.net> wrote:
> On 2010-10-15, Michael Foukarakis <electricde...@gmail.com> wrote:
>
> > I don't know. I learnt C pretty young, and I was able to distinguish
> > between '=3D' and '=3D=3D', thanks to three subtle notions:
>
> Oh, I can distinguish between them. =A0It's just that I'm much more likel=
y
> to get them wrong than I am more-distinct operators.

As is everyone else, I'm sure.

> Especially if I've
> recently been working in a language that uses '=3D' for comparison. =A0Ba=
sically,
> if you present me with an otherwise mostly correct piece of code that use=
s
> =3D where it should have been =3D=3D, it's quite possible for me to miss =
it,
> especially if there are other errors which are more obvious.
>
> I do not think C would have been a worse language had the assignment oper=
ator
> been more obviously distinct, such as :=3D, but it wasn't, so here we are=
..

Right. In my opinion, both '=3D' and ':=3D' differ by one character from
'=3D=3D' (oh god, that levenshtein distance function is taking hold of my
brain..), and for me it would be just as distinct if we exclude
mistypes from the equation (no pun intended).
0
Michael
10/18/2010 7:53:07 AM
felix@palmen-it.de (Felix Palmen) writes:
> * Keith Thompson <kst-u@mib.org>:
>> felix@palmen-it.de (Felix Palmen) writes:
>>> | typedef struct {
>>> |   float speed;
>>> |   char *model;
>>> |   
>>> |   void (*accelerate)(void *this, float delta);
>>> |   void (*decelerate)(void *this, float delta);
>>> | } Car;
>>>
>>> Would you really call "Car" an alias?
>>>
>>> (finally ... a car example :D)
>> 
>> Yes, the name "Car" (created by the typedef) is nothing more than an
>> alias for the type "struct { ... }".
>
> No.

Yes.

>     You cannot sensibly argument that a notation of "struct { ... }"
> identifies a type -- it describes it. The description may be
> unambiguous, so it would be possible to describe the type each and every
> time you need it, but for /defining/ a type, it should get its own
> identifier -- just like defining a function, a variable, etc.

Not all C types have simple names; in fact most of them don't.  We have
int, short, and char, but we also have long double, unsigned long long
int, char*, int[42], and struct { int x; double y; }.

To take a simpler example:

    typedef int arr[10];

This declaration makes "arr" an alias for the existing type
"int[10]", a type that otherwise wouldn't have a name of its own
other than "int[10]".  Consider:

    typedef int word;
    typedef int arr[10];
    typedef struct { /* ... */ } Car;

All three of these create an alias for an existing type.  The only
difference is complexity and the fact that, in at least the third
case, the type is created by the declaration (and would have been
created even without the "typedef" keyword and the "Car" identifier).

>>    struct car {
>>        /* ... */
>>    };
>>    typedef struct car Car;
>
> Another way to do it, this way you define a type called "struct car" --
> one of the peculiarities of C I don't like. You need to use typedef if
> you want to define your type in the "global" identifier namespace. But
> at least, that's the reason typedef is perfectly sensible named, IMO.

typedef is the *only* way that a type can have a name that's a single
identifier (as opposed to a keyword).

A digression: Many programmers (including me) prefer *not* to use
typedefs for structs.  I'd just declare
    struct car {
        /* ... */
    };
and then refer to the type as "struct car".  The type already has
a perfectly good name; it doesn't need another one.

But if you dislike having to repeat the "struct" keyword every time you
refer to the type, you can use a typedef, and even omit the tag if you
don't need to refer to the type name inside its declaration.  Keep in
mind that you can use the same identifier for the tag and the typedef.

End of digression.

>> Your original example doesn't give a name to the created type,
>> but that's the only difference.
>
> It does, the name is "Car" (as opposed to "struct car"). Of course, if
> you give it both names, one is obviously an alias for the other.

And if you don't give it both names, then "Car" is an alias for
an anonymous struct type.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
0
Keith
10/18/2010 3:12:42 PM
felix@palmen-it.de (Felix Palmen) writes:
> * Keith Thompson <kst-u@mib.org>:
>> felix@palmen-it.de (Felix Palmen) writes:
>>> | typedef struct {
>>> |   float speed;
>>> |   char *model;
>>> |   
>>> |   void (*accelerate)(void *this, float delta);
>>> |   void (*decelerate)(void *this, float delta);
>>> | } Car;
>>>
>>> Would you really call "Car" an alias?
>>>
>>> (finally ... a car example :D)
>> 
>> Yes, the name "Car" (created by the typedef) is nothing more than an
>> alias for the type "struct { ... }".
>
> No. You cannot sensibly argument that a notation of "struct { ... }"
> identifies a type -- it describes it. The description may be
> unambiguous, so it would be possible to describe the type each and every
> time you need it, but for /defining/ a type, it should get its own
> identifier -- just like defining a function, a variable, etc.

Another couple of points:

You can certainly argue that something that defines a type (such as a
struct declaration) *should* create an identifier for it, but the fact
is that, in C, it doesn't.  It usually doesn't make sense to create
a struct type without creating a name for it, either a tag or a typedef
name, but it's perfectly legal.  For example, you can write:

    struct { int x; int y; } obj;

and refer to obj.x and obj.y, but you've provided no way to refer to the
type of obj.  If you want that type to have its own name, you need to
give it one.  The same applies to union and enum types.

Finally, something I should have written earlier, a quote from the C
standard.  C99 6.7.7p3:

    A typedef declaration does not introduce a new type, only a
    synonym for the type so specified.

[...]

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
0
Keith
10/18/2010 3:22:59 PM
Nick <3-nospam@temporary-address.org.uk> writes:
> Keith Thompson <kst-u@mib.org> writes:
[...]
>> I agree that "typedef" was not a good choice of name for the semantics.
>> Perhaps "typealias" would have been better.
>>
>> But "typedef" is in the language, and it's not going away.  Every C
>> programmer needs to understand that "typedef" doesn't define a type
>> (just as "const" doesn't mean constant).
>
> I think this is all about how you use words, again.  In one sense it
> does define a type.  Particularly when used for things other than
> structures.

Perhaps the word on whose definition we disagree is "define".
To define something is to *create* it.  If you define a type,
then you have a type that would not have existed if you hadn't
defined it.  This is in contrast to "declaring" something; a
declaration can assert that something exists without creating it
(such as an extern object declaration).

> What it does is it gives you a token that can then be used as the name
> of a type.  In a sense, C starts off with int, char and the like.

Right, it gives you a *name*.  It defines that name (an identifier).
It doesn't define a type; the type already existed (if it didn't,
the typedef declaration wouldn't be able to refer to it).

> If you do typedef like:
> typedef char *(* FUNCT)(int *[]);
> then in a sense you have now added FUNCT as a type to C - functions
> taking an array of integer pointers and returning a character pointer.  
> You can now use it just the way you would use "int" alone.

Or you could omit the typedef and use *the same type* directly:

    void foo(char *(* argument)(int *[]));

The typedef is certainly convenient, but you can almost always get
by without it by referring to the original type.  (For syntactic
reasons, you'd need a typedef to use this type with the va_arg()
macro.)

> I think as  the language as evolved and got standardised, we've shifted
> the meaning of type to a slightly different meaning - one in which
> "struct fred *" is as much a type as "char" is.  But I think there was a
> logic behind the meaning, and I think saying it doesn't "define a type"
> is possibly confusing for some.

"struct fred *" has always been as much a type as "char" is.

I understand that saying typedef doesn't define a type may be
confusing for some.  But it's the truth: typedef doesn't define
a type.

> I say that because to me, when I first encountered typedef, it was quite
> clear what it did.  It defined a new "high level" type that you could
> use just like the built in ones.

Ok, but did you understand that this "new" type isn't distinct
from the original type?  Did you understand that, given:
    typedef int word;
"int" and "word" are quite literally *the same type*?

[...]

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
0
Keith
10/18/2010 3:32:11 PM
* Keith Thompson <kst-u@mib.org>:
> And if you don't give it both names, then "Car" is an alias for
> an anonymous struct type.

Well, as this applies to nearly anything you have written in response,
I'll just put it here:

You can either pretend you're a compiler and don't know anything more
abstract than your grammar (and the standard defining it) -- or you can
just apply some human abstraction to understand the /intention/ behind
C's language constructs and ask yourself in that context whether typedef
is a good name or not.

My decision is clear: the name is perfect.

Regards,
Felix

-- 
 Felix Palmen       (Zirias)  + [PGP] Felix Palmen <felix@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
0
felix4560 (61)
10/18/2010 3:39:13 PM
* Keith Thompson <kst-u@mib.org>:
> Finally, something I should have written earlier, a quote from the C
> standard.  C99 6.7.7p3:
> 
>    A typedef declaration does not introduce a new type, only a
>    synonym for the type so specified.

Oh and by the way .. even a standard can have some controversial points.

If it was really a synonym, the following should be interpreted the
same:

char * a, b, c;

and

typedef char * string
string a, b, c;

Regards,
Felix

-- 
 Felix Palmen       (Zirias)  + [PGP] Felix Palmen <felix@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
0
felix
10/18/2010 3:44:16 PM
On 2010-10-18 09:49, Michael Foukarakis wrote:
> I don't understand what you mean by "real world". In case you mean
> "outside of programming" (i.e. mathematics) you are right. If you mean
> "languages other than C" you are entirely wrong, though. As I'm
> writing this, I'm thinking that out of all the languages I know,
> Erlang is probably the only one where '=' does not explicitly stand
> for "assignment".

Pascal, Modula-2, Oberon, Ada and Eiffel comes to mind.

> But that is besides the point. My point is that I think as humans we
> have the capability to differentiate between symbols and their
> meanings based on context. Whether those that don't should be
> accomodated, I don't really care for that discussion (yet).

Whichever way you cut the mustard, we still need a symbol to test for 
equality and what would be more natural than to use a symbol which has 
already been in use for several hundred years (invented in 1557 by 
Welshman Robert Recorde).


/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
0
August
10/18/2010 3:48:46 PM
On 2010-10-18, Michael Foukarakis <electricdelta@gmail.com> wrote:
> Right. In my opinion, both '=' and ':=' differ by one character from
> '==' (oh god, that levenshtein distance function is taking hold of my
> brain..), and for me it would be just as distinct if we exclude
> mistypes from the equation (no pun intended).

I don't quite agree.  Doubled characters are easier to miss than other
added characters, in general.  Especially when the symbol is just "two
parallel lines", and all the extra character does is make them longer.
It's similarly easier to get confused by, say, _ vs. __ in the middle
of a long name, than it would be by _ vs. #_.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@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.
0
Seebs
10/18/2010 4:15:29 PM
felix@palmen-it.de (Felix Palmen) writes:
> * Keith Thompson <kst-u@mib.org>:
>> And if you don't give it both names, then "Car" is an alias for
>> an anonymous struct type.
>
> Well, as this applies to nearly anything you have written in response,
> I'll just put it here:
>
> You can either pretend you're a compiler and don't know anything more
> abstract than your grammar (and the standard defining it) -- or you can
> just apply some human abstraction to understand the /intention/ behind
> C's language constructs and ask yourself in that context whether typedef
> is a good name or not.
>
> My decision is clear: the name is perfect.

It's not a matter of applying or not applying "some human abstraction".
You and I are just apply *different* abstractions to the same construct.
And the one I'm using matches the one used by the C standard.

typedef does not define a type.  It defines a name for a type.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
0
Keith
10/18/2010 4:30:13 PM
felix@palmen-it.de (Felix Palmen) writes:
> * Keith Thompson <kst-u@mib.org>:
>> Finally, something I should have written earlier, a quote from the C
>> standard.  C99 6.7.7p3:
>> 
>>    A typedef declaration does not introduce a new type, only a
>>    synonym for the type so specified.
>
> Oh and by the way .. even a standard can have some controversial points.

I wasn't aware that this one was controversial.  You're the only
person I've ever seen who insists that typedef introduces a new
type after having had it explained.

> If it was really a synonym, the following should be interpreted the
> same:
>
> char * a, b, c;
>
> and
>
> typedef char * string
> string a, b, c;

That doesn't follow.  typedef doesn't act on tokens, it acts on types.
It's a semantic construct, not a macro.

"typedef char *string;" creates a synonym for the type char*. 
"string a, b, c;" creates three objects of type char*.

Given "typedef char *string;", do you argue that "char*" and "string"
are distinct types?

Or, to avoid irrelevant syntactic issues, consider this:

    typedef char *string1;
    typedef char *string2;

Do you argue that string1 and string2 are two distinct types?
If so, can you present a sample C program that demonstrates that
they're distinct, i.e., that the identifiers "string1" and "string2"
cannot be used entirely interchangeably?  (Preprocessor stringizing
doesn't count.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
0
Keith
10/18/2010 4:35:24 PM
Keith Thompson <kst-u@mib.org> writes:
> felix@palmen-it.de (Felix Palmen) writes:
>> * Keith Thompson <kst-u@mib.org>:
>>> And if you don't give it both names, then "Car" is an alias for
>>> an anonymous struct type.
>>
>> Well, as this applies to nearly anything you have written in response,
>> I'll just put it here:
>>
>> You can either pretend you're a compiler and don't know anything more
>> abstract than your grammar (and the standard defining it) -- or you can
>> just apply some human abstraction to understand the /intention/ behind
>> C's language constructs and ask yourself in that context whether typedef
>> is a good name or not.
>>
>> My decision is clear: the name is perfect.
>
> It's not a matter of applying or not applying "some human abstraction".
> You and I are just apply *different* abstractions to the same construct.
> And the one I'm using matches the one used by the C standard.
>
> typedef does not define a type.  It defines a name for a type.

What probably causes some confusion is that a typedef can be combined
with another declaration, so a single declaration (a) creates a
new type and (b) defines a synonym for that type.  These are still
distinct actions.  (a), which creates the type, is not a typedef;
(b) is a typedef, which does not create a type.

In fact the keyword "typedef" is syntactically treated as a storage
class specifier, which is certainly counterintuitive.  It was done that
way because "typedef" was a relatively late addition to the language.
The syntax for declaring and defining array, struct, union, and pointer
type had already been established.  When the need for type synonyms was
seen, the new feature had to be added without breaking existing
constructs.

If I were designing the C language from scratch today, I would
certainly do it differently.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
0
Keith
10/18/2010 4:47:53 PM
Keith Thompson <kst-u@mib.org> writes:

> felix@palmen-it.de (Felix Palmen) writes:
>> * Keith Thompson <kst-u@mib.org>:
>>> And if you don't give it both names, then "Car" is an alias for
>>> an anonymous struct type.
>>
>> Well, as this applies to nearly anything you have written in response,
>> I'll just put it here:
>>
>> You can either pretend you're a compiler and don't know anything more
>> abstract than your grammar (and the standard defining it) -- or you can
>> just apply some human abstraction to understand the /intention/ behind
>> C's language constructs and ask yourself in that context whether typedef
>> is a good name or not.
>>
>> My decision is clear: the name is perfect.
>
> It's not a matter of applying or not applying "some human abstraction".
> You and I are just apply *different* abstractions to the same construct.
> And the one I'm using matches the one used by the C standard.
>
> typedef does not define a type.  It defines a name for a type.


Amazing. Simply amazing.

Yet 99% of people will use it to "define a type".

-- 
"Avoid hyperbole at all costs, its the most destructive argument on
the planet" - Mark McIntyre in comp.lang.c
0
Richard
10/18/2010 5:35:56 PM
* Keith Thompson <kst-u@mib.org>:
> felix@palmen-it.de (Felix Palmen) writes:
>> If it was really a synonym, the following should be interpreted the
>> same:
>>
>> char * a, b, c;
>>
>> and
>>
>> typedef char * string
>> string a, b, c;
> 
> That doesn't follow.  typedef doesn't act on tokens, it acts on types.
> It's a semantic construct, not a macro.
> 
> "typedef char *string;" creates a synonym for the type char*. 
> "string a, b, c;" creates three objects of type char*.
> 
> Given "typedef char *string;", do you argue that "char*" and "string"
> are distinct types?

You didn't get the point. Not even close. Maybe you didn't want to.

-- 
 Felix Palmen       (Zirias)  + [PGP] Felix Palmen <felix@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
0
felix
10/18/2010 6:12:09 PM
* Keith Thompson <kst-u@mib.org>:
> What probably causes some confusion ...

Just try -- for a second -- to realize there is no confusion at all.
Then think about why people decided to give typedef its name. Probably
to confuse people, right?

-- 
 Felix Palmen       (Zirias)  + [PGP] Felix Palmen <felix@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
0
felix
10/18/2010 6:18:25 PM
felix@palmen-it.de (Felix Palmen) writes:
> * Keith Thompson <kst-u@mib.org>:
>> felix@palmen-it.de (Felix Palmen) writes:
>>> If it was really a synonym, the following should be interpreted the
>>> same:
>>>
>>> char * a, b, c;
>>>
>>> and
>>>
>>> typedef char * string
>>> string a, b, c;
>> 
>> That doesn't follow.  typedef doesn't act on tokens, it acts on types.
>> It's a semantic construct, not a macro.
>> 
>> "typedef char *string;" creates a synonym for the type char*. 
>> "string a, b, c;" creates three objects of type char*.
>> 
>> Given "typedef char *string;", do you argue that "char*" and "string"
>> are distinct types?
>
> You didn't get the point. Not even close. Maybe you didn't want to.

Then perhaps you could explain the point more clearly.  It's quite
possible that I'm missing something you're trying to say.

1. "typedef" does not define a type.

2. By "define a type", I mean "create a new type".

3. "typedef" creates a synonym for an existing type.  That existing type
may, in some cases, be created by the same declaration that includes the
typedef, but it's not created by the typedef itself.

4. Since "typedef" does not define a type, "typedef" was a poor name
choice.

Which, if any, of the above numbered statements do you disagree with,
and if so, why?

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
0
Keith
10/18/2010 6:57:14 PM
In article <i9i0ht$3di$4@news.eternal-september.org>,
Richard  <rgrdev_@gmail.com> wrote:
....
>> typedef does not define a type.  It defines a name for a type.
>
>
>Amazing. Simply amazing.
>
>Yet 99% of people will use it to "define a type".

The funny thing is that I am certain that at least 90% (probably 99%) of
working C programmers have had no contact with and no knowledge of the
sacred C standards documents.  They just get their job done and go home
at 5 to their families.

And they define types using typedef, with nary a care.

-- 
Faced with the choice between changing one's mind and proving that there is
no need to do so, almost everyone gets busy on the proof. 

    - John Kenneth Galbraith -

0
gazelle
10/18/2010 7:04:32 PM
In article <lnwrpf2ut1.fsf@nuthaus.mib.org>,
Keith Thompson  <kst-u@mib.org> wrote:
>felix@palmen-it.de (Felix Palmen) writes:
>> * Keith Thompson <kst-u@mib.org>:
>>> felix@palmen-it.de (Felix Palmen) writes:
>>>> If it was really a synonym, the following should be interpreted the
>>>> same:
>>>>
>>>> char * a, b, c;
>>>>
>>>> and
>>>>
>>>> typedef char * string
>>>> string a, b, c;
>>> 
>>> That doesn't follow.  typedef doesn't act on tokens, it acts on types.
>>> It's a semantic construct, not a macro.
>>> 
>>> "typedef char *string;" creates a synonym for the type char*. 
>>> "string a, b, c;" creates three objects of type char*.
>>> 
>>> Given "typedef char *string;", do you argue that "char*" and "string"
>>> are distinct types?
>>
>> You didn't get the point. Not even close. Maybe you didn't want to.
>
>Then perhaps you could explain the point more clearly.  It's quite
>possible that I'm missing something you're trying to say.
>
>1. "typedef" does not define a type.
>
>2. By "define a type", I mean "create a new type".

Most people use the term "create a new type" to mean "create a new type".

By your logic, the dictionary does not define words.  Which, I'm sure in
your twisted mind, it doesn't (as you - or one of your socks - will no
doubt explain that to me any minute now)...

-- 
> No, I haven't, that's why I'm asking questions. If you won't help me,
> why don't you just go find your lost manhood elsewhere.

CLC in a nutshell.

0
gazelle
10/18/2010 7:06:13 PM
* Keith Thompson <kst-u@mib.org>:
> Then perhaps you could explain the point more clearly.

I did, more than enough. As long as you refuse to think about the
/meaning/ of a typedef (to the programmer, that is .. YES that's one
abstraction level ABOVE your standards), this discussion ist just
pointless.

-- 
 Felix Palmen       (Zirias)  + [PGP] Felix Palmen <felix@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
0
felix4560 (61)
10/18/2010 7:09:15 PM
felix@palmen-it.de (Felix Palmen) writes:
> * Keith Thompson <kst-u@mib.org>:
>> Then perhaps you could explain the point more clearly.
>
> I did, more than enough. As long as you refuse to think about the
> /meaning/ of a typedef (to the programmer, that is .. YES that's one
> abstraction level ABOVE your standards), this discussion ist just
> pointless.

If you don't understand that typedef doesn't define a type, then you
don't understand typedef.

I agree, this is pointless (unless you're willing to explain just
what you're talking about).

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
0
Keith
10/18/2010 7:24:38 PM
* Keith Thompson <kst-u@mib.org>:
> felix@palmen-it.de (Felix Palmen) writes:
>> * Keith Thompson <kst-u@mib.org>:
>>> Then perhaps you could explain the point more clearly.
>>
>> I did, more than enough. As long as you refuse to think about the
>> /meaning/ of a typedef (to the programmer, that is .. YES that's one
>> abstraction level ABOVE your standards), this discussion ist just
>> pointless.
> 
> If you don't understand that typedef doesn't define a type, then you
> don't understand typedef.
> 
> I agree, this is pointless (unless you're willing to explain just
> what you're talking about).

*plonk*

-- 
 Felix Palmen       (Zirias)  + [PGP] Felix Palmen <felix@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
0
felix4560 (61)
10/18/2010 7:35:09 PM
Ben Bacarisse wrote:
> "Jon" <jomar@spblocker.net> writes:
>
>> "Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message
>> news:0.1380ee9f31ea3465db09.20101017030653BST.87ocatmv2a.fsf@bsb.me.uk...
>>> "Jon" <jomar@spblocker.net> writes:
>>>
>>>> "Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message
>>>> news:0.4ef395e0027b90f26249.20101016114759BST.87zkuemn1c.fsf@bsb.me.uk...
>>>>> "Jon" <jomar@spblocker.net> writes:
>>>>>
>>>>>> "Keith Thompson" <kst-u@mib.org> wrote in message
>>>>>> news:lnbp6wbx0g.fsf@nuthaus.mib.org...
>>>>>>> "Jon" <jomar@spblocker.net> writes:
>>>>>>>> Nick Keighley wrote:
>>>>>>>>> use typedef (which should be called typealias)
>>>>>>>>
>>>>>>>> #define Alias typedef
>>>>>>>>
>>>>>>>> If the preprocessor is not your friend, then C will be your
>>>>>>>> enemy. You're
>>>>>>>> welcome.
>>>>>>>
>>>>>>> If I'm reading code that uses typedef, I have to understand how
>>>>>>> typedef
>>>>>>> works.
>>>>>>>
>>>>>>> If I'm reading code that uses your "Alias" macro, I still have
>>>>>>> to understand how typedef works -- *and* that "Alias" means
>>>>>>> typedef.
>>>>>>>
>>>>>>> It doesn't help.
>>>>>>
>>>>>> Think of a new programmer. Is he likely to understand that
>>>>>> typedef means
>>>>>> alias in reality or likely to think that it means declaration of
>>>>>> a new
>>>>>> type? Therefore, "Alias" is better.
>>>>>
>>>>> A #define is particularly bad for new programmers
>>>>
>>>> The issue is not a define,
>>>
>>> I thought you were suggesting one.
>>
>> Pfft. I know better than to "suggest" a change to the ISO C standard
>> in this ng.
>
> Eh?  I know you didn't.  You suggested a #define.  I was commenting on
> only on that and, in particular, the value you claimed it would have
> for new programmers.
>

I know where you're coming from: "God created all things, therefore God 
must exist", and "If all you have or know is C, then everything looks 
like a thumb". "New programmer" does NOT mean "new *C* programmer". Why 
perpetuate "crazy" constructs unnecessarily? Yes, 'alias' is better than 
'typedef'. 


0
Jon
10/18/2010 7:42:47 PM
felix@palmen-it.de (Felix Palmen) writes:
> * Keith Thompson <kst-u@mib.org>:
>> felix@palmen-it.de (Felix Palmen) writes:
>>> * Keith Thompson <kst-u@mib.org>:
>>>> Then perhaps you could explain the point more clearly.
>>>
>>> I did, more than enough. As long as you refuse to think about the
>>> /meaning/ of a typedef (to the programmer, that is .. YES that's one
>>> abstraction level ABOVE your standards), this discussion ist just
>>> pointless.
>> 
>> If you don't understand that typedef doesn't define a type, then you
>> don't understand typedef.
>> 
>> I agree, this is pointless (unless you're willing to explain just
>> what you're talking about).
>
> *plonk*

Just out of curiosity, did anyone else understand the point he was
trying to make?

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
0
Keith
10/18/2010 7:53:09 PM
Keith Thompson wrote:
) Then perhaps you could explain the point more clearly.  It's quite
) possible that I'm missing something you're trying to say.
)
) 1. "typedef" does not define a type.
)
) 2. By "define a type", I mean "create a new type".
)
) 3. "typedef" creates a synonym for an existing type.  That existing type
) may, in some cases, be created by the same declaration that includes the
) typedef, but it's not created by the typedef itself.
)
) 4. Since "typedef" does not define a type, "typedef" was a poor name
) choice.
)
) Which, if any, of the above numbered statements do you disagree with,
) and if so, why?

None of the above.  I am assuming that in number 2 above, you mean
something specific by "create a new type".
I'm assuming that your point is that a type cannot be a "new" type
when it is _technically_ a synonym of another type.

My argument is that, even though it may be a _technical_ synonym,
it need not be an _abstract_ synonym.

For example:
  typedef int length;
  typedef int volume;

It doesn't matter if the compiler warns you about mixing them or not.
Length and volume are obviously different types, when viewed as
abstractions.  Which is what HLLs are for.

So, in closing, I disagree with what I assume is your definition for
"create a new type".


SaSW, Willem
-- 
Disclaimer: I am in no way responsible for any of the statements
            made in the above text. For all I know I might be
            drugged or something..
            No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
0
Willem
10/18/2010 7:55:17 PM
Keith Thompson <kst-u@mib.org> writes:

> felix@palmen-it.de (Felix Palmen) writes:
>> * Keith Thompson <kst-u@mib.org>:
>>> felix@palmen-it.de (Felix Palmen) writes:
>>>> If it was really a synonym, the following should be interpreted the
>>>> same:
>>>>
>>>> char * a, b, c;
>>>>
>>>> and
>>>>
>>>> typedef char * string
>>>> string a, b, c;
>>> 
>>> That doesn't follow.  typedef doesn't act on tokens, it acts on types.
>>> It's a semantic construct, not a macro.
>>> 
>>> "typedef char *string;" creates a synonym for the type char*. 
>>> "string a, b, c;" creates three objects of type char*.
>>> 
>>> Given "typedef char *string;", do you argue that "char*" and "string"
>>> are distinct types?
>>
>> You didn't get the point. Not even close. Maybe you didn't want to.
>
> Then perhaps you could explain the point more clearly.  It's quite
> possible that I'm missing something you're trying to say.
>
> 1. "typedef" does not define a type.

Of course it does. It's why its called TYPE DEF == typedef ....

Grow up.
0
Richard
10/18/2010 7:56:01 PM
Keith Thompson <kst-u@mib.org> writes:

> felix@palmen-it.de (Felix Palmen) writes:
>> * Keith Thompson <kst-u@mib.org>:
>>> felix@palmen-it.de (Felix Palmen) writes:
>>>> * Keith Thompson <kst-u@mib.org>:
>>>>> Then perhaps you could explain the point more clearly.
>>>>
>>>> I did, more than enough. As long as you refuse to think about the
>>>> /meaning/ of a typedef (to the programmer, that is .. YES that's one
>>>> abstraction level ABOVE your standards), this discussion ist just
>>>> pointless.
>>> 
>>> If you don't understand that typedef doesn't define a type, then you
>>> don't understand typedef.
>>> 
>>> I agree, this is pointless (unless you're willing to explain just
>>> what you're talking about).
>>
>> *plonk*
>
> Just out of curiosity, did anyone else understand the point he was
> trying to make?

Everyone did. Surely you are aware of your shortcomings when it comes to
common sense by now?

-- 
"Avoid hyperbole at all costs, its the most destructive argument on
the planet" - Mark McIntyre in comp.lang.c
0
Richard
10/18/2010 8:02:08 PM
"Richard" <rgrdev_@gmail.com> wrote in message 
news:i9i8oi$636$1@news.eternal-september.org...
> Keith Thompson <kst-u@mib.org> writes:

>> 1. "typedef" does not define a type.
>
> Of course it does. It's why its called TYPE DEF == typedef ....

It can be a convenient way of thinking about it.

But KT is right, it doesn't buy you anything other than a much more 
convenient syntax for specifying types.


-- 
bartc

 

0
BartC
10/18/2010 8:10:19 PM
"BartC" <bc@freeuk.com> writes:

> "Richard" <rgrdev_@gmail.com> wrote in message 
> news:i9i8oi$636$1@news.eternal-september.org...
>> Keith Thompson <kst-u@mib.org> writes:
>
>>> 1. "typedef" does not define a type.
>>
>> Of course it does. It's why its called TYPE DEF == typedef ....
>
> It can be a convenient way of thinking about it.
>
> But KT is right, it doesn't buy you anything other than a much more 
> convenient syntax for specifying types.

He's not right. He's totally confusing people with typically anal over
analysis.


-- 
"Avoid hyperbole at all costs, its the most destructive argument on
the planet" - Mark McIntyre in comp.lang.c
0
Richard
10/18/2010 8:20:31 PM
Willem <willem@turtle.stack.nl> writes:
> Keith Thompson wrote:
> ) Then perhaps you could explain the point more clearly.  It's quite
> ) possible that I'm missing something you're trying to say.
> )
> ) 1. "typedef" does not define a type.
> )
> ) 2. By "define a type", I mean "create a new type".
> )
> ) 3. "typedef" creates a synonym for an existing type.  That existing type
> ) may, in some cases, be created by the same declaration that includes the
> ) typedef, but it's not created by the typedef itself.
> )
> ) 4. Since "typedef" does not define a type, "typedef" was a poor name
> ) choice.
> )
> ) Which, if any, of the above numbered statements do you disagree with,
> ) and if so, why?
>
> None of the above.  I am assuming that in number 2 above, you mean
> something specific by "create a new type".

Yes.  The type doesn't exist before, or in the absence of, the
declaration.  It does exist after, or in the presence of, the
declaration.

For example, if I write:
    struct foo { int x; };
then the type "struct foo" exists.  If I don't, it doesn't.
The declaration creates the type.

> I'm assuming that your point is that a type cannot be a "new" type
> when it is _technically_ a synonym of another type.

Yes, except that I fail to see what the word "technically" adds to it.

> My argument is that, even though it may be a _technical_ synonym,
> it need not be an _abstract_ synonym.
>
> For example:
>   typedef int length;
>   typedef int volume;
>
> It doesn't matter if the compiler warns you about mixing them or not.
> Length and volume are obviously different types, when viewed as
> abstractions.  Which is what HLLs are for.
>
> So, in closing, I disagree with what I assume is your definition for
> "create a new type".

Ok, so the *intent* of a typedef is to create something that can be
treated as a distinct type, even if the compiler doesn't enforce the
distinction.  And if, given the above declarations, I write:

    length len = 10;
    volume vol = 20;
    int z = len + vol;

then my program is logically incorrect, even though there is no error
that a compiler is going to complain about.

If that was Felix Palmen's point, then I agree (and it would have
been nice if he'd simply said so, or at least answered my direct
questions, rather than plonking me.)

My point is simply that that's not what "typedef" really means *in the
language*.  And if you want to create a new type and have the compiler
enforce it for you, typedef won't do the job (but a struct will).

(Incidentally, I see that Kenny McCormack and Richard nolastname
have posted in this thread.  If I don't respond to what they say,
it's because I haven't read it.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
0
Keith
10/18/2010 8:43:48 PM
"Michael Foukarakis" <electricdelta@gmail.com> wrote in message 
news:116a3169-8228-45d1-a118-7b32634cd537@x42g2000yqx.googlegroups.com...
> On Oct 15, 3:28 pm, "BartC" <b...@freeuk.com> wrote:

>> In fact, in the real world outside of C programming, "=" to mean equality 
>> is
>> pretty much universal.
>
> I don't understand what you mean by "real world". In case you mean
> "outside of programming" (i.e. mathematics) you are right.

I meant outside of programming, even outside of mathematics.

> If you mean
> "languages other than C" you are entirely wrong, though. As I'm
> writing this, I'm thinking that out of all the languages I know,
> Erlang is probably the only one where '=' does not explicitly stand
> for "assignment".

There are plenty using ":=" (and various other forms) for assignment, such 
as all the Algol-based ones for a start.

But yes, the C-style seems to be winning out. And designers exposed to these 
languages will likely use "=" in new ones too.

It's a bit like the VHS vs. Betamax war; the better format lost (although 
personally I preferred V2000 as superior to both...)

> But that is besides the point. My point is that I think as humans we
> have the capability to differentiate between symbols and their
> meanings based on context.

You don't want to rely on context too much, otherwise you can end up with 
code like this (from a real language):

 if then then then=else; else else=then

But given this code snippet from an unknown language:

print a=b

what is your guess as to what it does? What about this:

print a:=b

?

-- 
Bartc 

0
BartC
10/18/2010 8:58:31 PM
Keith Thompson <kst-u@mib.org> writes:

> felix@palmen-it.de (Felix Palmen) writes:
>> * Keith Thompson <kst-u@mib.org>:
>>> felix@palmen-it.de (Felix Palmen) writes:
>>>> * Keith Thompson <kst-u@mib.org>:
>>>>> Then perhaps you could explain the point more clearly.
>>>>
>>>> I did, more than enough. As long as you refuse to think about the
>>>> /meaning/ of a typedef (to the programmer, that is .. YES that's one
>>>> abstraction level ABOVE your standards), this discussion ist just
>>>> pointless.
>>> 
>>> If you don't understand that typedef doesn't define a type, then you
>>> don't understand typedef.
>>> 
>>> I agree, this is pointless (unless you're willing to explain just
>>> what you're talking about).
>>
>> *plonk*
>
> Just out of curiosity, did anyone else understand the point he was
> trying to make?

Well I didn't.  The passing shot (quoted above) suggests that he was
making a point, disconnected from the C language, about how one should
think about a typedef'd type.  However, I don't think that was the point
he was making earlier in the thread.

-- 
Ben.
0
Ben
10/18/2010 9:24:09 PM
Keith Thompson <kst-u@mib.org> writes:

> felix@palmen-it.de (Felix Palmen) writes:
>> * Keith Thompson <kst-u@mib.org>:
>>> felix@palmen-it.de (Felix Palmen) writes:
>>>> * Keith Thompson <kst-u@mib.org>:
>>>>> Then perhaps you could explain the point more clearly.
>>>>
>>>> I did, more than enough. As long as you refuse to think about the
>>>> /meaning/ of a typedef (to the programmer, that is .. YES that's one
>>>> abstraction level ABOVE your standards), this discussion ist just
>>>> pointless.
>>> 
>>> If you don't understand that typedef doesn't define a type, then you
>>> don't understand typedef.
>>> 
>>> I agree, this is pointless (unless you're willing to explain just
>>> what you're talking about).
>>
>> *plonk*
>
> Just out of curiosity, did anyone else understand the point he was
> trying to make?

I think so, and I tried to explain it, but you didn't understand me
either!  It was to do - or at least, mine was - with the difference
between the current formal meaning of the word type and the sort of
informal meaning (more a "first-class type") that I suspect was floating
around when typedef came up - and the one that meant that typedef made
perfect sense to me and has never confused me since I encountered it.

It's that typedef creates a thing of the same status in C as an int or a
char.  These can easily be thought of as "types" in a say a string of
words and brackets - with the identifier name in the middle - isn't
likely to be.
-- 
Online waterways route planner            | http://canalplan.eu
Plan trips, see photos, check facilities  | http://canalplan.org.uk
0
3-nospam (285)
10/18/2010 9:37:01 PM
"Jon" <jomar@spblocker.net> writes:

> Ben Bacarisse wrote:
>> "Jon" <jomar@spblocker.net> writes:
>>
>>> "Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message
>>> news:0.1380ee9f31ea3465db09.20101017030653BST.87ocatmv2a.fsf@bsb.me.uk...
>>>> "Jon" <jomar@spblocker.net> writes:
>>>>
>>>>> "Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message
>>>>> news:0.4ef395e0027b90f26249.20101016114759BST.87zkuemn1c.fsf@bsb.me.uk...
>>>>>> "Jon" <jomar@spblocker.net> writes:
>>>>>>
>>>>>>> "Keith Thompson" <kst-u@mib.org> wrote in message
>>>>>>> news:lnbp6wbx0g.fsf@nuthaus.mib.org...
>>>>>>>> "Jon" <jomar@spblocker.net> writes:
>>>>>>>>> Nick Keighley wrote:
>>>>>>>>>> use typedef (which should be called typealias)
>>>>>>>>>
>>>>>>>>> #define Alias typedef
>>>>>>>>>
>>>>>>>>> If the preprocessor is not your friend, then C will be your
>>>>>>>>> enemy. You're
>>>>>>>>> welcome.
>>>>>>>>
>>>>>>>> If I'm reading code that uses typedef, I have to understand how
>>>>>>>> typedef
>>>>>>>> works.
>>>>>>>>
>>>>>>>> If I'm reading code that uses your "Alias" macro, I still have
>>>>>>>> to understand how typedef works -- *and* that "Alias" means
>>>>>>>> typedef.
>>>>>>>>
>>>>>>>> It doesn't help.
>>>>>>>
>>>>>>> Think of a new programmer. Is he likely to understand that
>>>>>>> typedef means
>>>>>>> alias in reality or likely to think that it means declaration of
>>>>>>> a new
>>>>>>> type? Therefore, "Alias" is better.
>>>>>>
>>>>>> A #define is particularly bad for new programmers
>>>>>
>>>>> The issue is not a define,
>>>>
>>>> I thought you were suggesting one.
>>>
>>> Pfft. I know better than to "suggest" a change to the ISO C standard
>>> in this ng.
>>
>> Eh?  I know you didn't.  You suggested a #define.  I was commenting on
>> only on that and, in particular, the value you claimed it would have
>> for new programmers.
>
> I know where you're coming from: "God created all things, therefore God 
> must exist", and "If all you have or know is C, then everything looks 
> like a thumb". "New programmer" does NOT mean "new *C* programmer". Why 
> perpetuate "crazy" constructs unnecessarily? Yes, 'alias' is better than 
> 'typedef'. 

I have no idea what this means, but I am not sure how much that matters.
I've expressed my view a clearly as I can and I don't think you've
misunderstood it, so there's little point in my saying more.  I may be
incapable of understanding your point of view so we might as well just
leave it that we disagree about something.

-- 
Ben.
0
Ben
10/18/2010 9:40:47 PM
Nick <3-nospam@temporary-address.org.uk> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> felix@palmen-it.de (Felix Palmen) writes:
>>> * Keith Thompson <kst-u@mib.org>:
>>>> felix@palmen-it.de (Felix Palmen) writes:
>>>>> * Keith Thompson <kst-u@mib.org>:
>>>>>> Then perhaps you could explain the point more clearly.
>>>>>
>>>>> I did, more than enough. As long as you refuse to think about the
>>>>> /meaning/ of a typedef (to the programmer, that is .. YES that's one
>>>>> abstraction level ABOVE your standards), this discussion ist just
>>>>> pointless.
>>>> 
>>>> If you don't understand that typedef doesn't define a type, then you
>>>> don't understand typedef.
>>>> 
>>>> I agree, this is pointless (unless you're willing to explain just
>>>> what you're talking about).
>>>
>>> *plonk*
>>
>> Just out of curiosity, did anyone else understand the point he was
>> trying to make?
>
> I think so, and I tried to explain it, but you didn't understand me
> either!  It was to do - or at least, mine was - with the difference
> between the current formal meaning of the word type and the sort of
> informal meaning (more a "first-class type") that I suspect was floating
> around when typedef came up - and the one that meant that typedef made
> perfect sense to me and has never confused me since I encountered it.
>
> It's that typedef creates a thing of the same status in C as an int or a
> char.  These can easily be thought of as "types" in a say a string of
> words and brackets - with the identifier name in the middle - isn't
> likely to be.

I'm not sure I understand you -- and if I do, I disagree.

I think that using the phrase "first-class type" is not helpful.  That
phrase has an established (though vague) meaning that's not particularly
similar to what you're talking about.

Maybe there's a confusion between a name and the thing the name refers
to?  For example, we can say that "int" is a type (referring to the
language-level abstract concept of an integer type with a certain
representation, operations, and so forth), or we can say that "int" is a
C keyword that *refers to* a type (unless it's preceded by "long" or
"unsigned").  "int" is the name of a type; "int" is a type.  Those are
two very different things, but we call them both "int" in informal
discussion.

My point, again, is that "typedef" doesn't create a type.  It creates a
name for a type.

Consider the following C code fragment:

    typedef int word;
    char *cp = 0;
    int  *ip = 0;
    word *wp = 0;

    cp = ip; /* constraint violation, LHS and RHS
                have incompatible types */
    cp = wp; /* constraint violation, LHS and RHS
                have incompatible types */
    ip = wp; /* valid, LHS and RHS have the same type */

How does this fit in with your idea that typedef "creates a thing
of the same status in C as an int or a char"?

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
0
kst-u (21963)
10/18/2010 10:06:37 PM
On 2010-10-18, Keith Thompson <kst-u@mib.org> wrote:
> If you don't understand that typedef doesn't define a type, then you
> don't understand typedef.

I've been watching this discussion with some interest, because I would
have said that it "defines" a type.  Sure, it just defines that type
to be identical to another type, but so what?

After "typedef char *str", the word "str" has become a type -- I can
consistently use it as though it were a type.  I can use it to declare
variables, I can use it as the return type or in the prototype of a
function, and so on.  I can pass it to sizeof.  In short, it acts just
like a type.  It has behavior equivalent to the behavior of, e.g.,
"float".

I think the key argument really does come down to the difference between:

	char *s, t;
and
	str s, t;

"str" is not just a thing which is substituted out for "char *" -- it's not
a macro.  It's a single identifier which now denotes one of the derived types.

I guess, the reason I tend to think of it as "defining" a type is that
the resulting type name behaves more like one of the built-in types than
it does like spelling out the derivationof a derived type.  Consider:

	typedef int (*foo)(int);

Now, after I've done this:
	int (*bar)(int);
	foo bar;

Note that in one of these, the name of the thing declared is buried inside
the declaration, while in the other, it's just an identifier following a
type name.  That feels a little like a definition.

.... Of course, now that I mention "definitions" and "macros", I suppose
there's a definite clash here with the semantics of #define.  :)

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@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.
0
Seebs
10/18/2010 11:29:27 PM
On 2010-10-18, Keith Thompson <kst-u@mib.org> wrote:
> Consider the following C code fragment:
>
>     typedef int word;
>     char *cp = 0;
>     int  *ip = 0;
>     word *wp = 0;
>
>     cp = ip; /* constraint violation, LHS and RHS
>                 have incompatible types */
>     cp = wp; /* constraint violation, LHS and RHS
>                 have incompatible types */
>     ip = wp; /* valid, LHS and RHS have the same type */
>
> How does this fit in with your idea that typedef "creates a thing
> of the same status in C as an int or a char"?

This is an interesting counterpoint.  However, it is certainly not
unheard of in C for multiple spellings of the same type to exist:

	int *ip = 0;
	signed int *sp = 0;
	ip = sp;

But "signed int" and "int" both have the trait that, put at the
beginning of a comma-separated list of identifiers, they declare
a large number of things all of which have the same type.  "char *"
does not have that trait, making it less like a primary type
and more like a derived type.

Typedef can turn a derived type into something that smells like
a primary type.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@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.
0
Seebs
10/18/2010 11:32:31 PM
On 10/19/10 12:29 PM, Seebs wrote:
> On 2010-10-18, Keith Thompson<kst-u@mib.org>  wrote:
>> If you don't understand that typedef doesn't define a type, then you
>> don't understand typedef.
>
> I've been watching this discussion with some interest, because I would
> have said that it "defines" a type.  Sure, it just defines that type
> to be identical to another type, but so what?

I guess then you have to consider whether given

typedef struct { int n; } X;

either

typedef struct { int n; } Y;

or

typedef X Y;

defines Y to be identical to X.

-- 
Ian Collins
0
Ian
10/18/2010 11:53:57 PM
Seebs <usenet-nospam@seebs.net> writes:
> On 2010-10-18, Keith Thompson <kst-u@mib.org> wrote:
>> If you don't understand that typedef doesn't define a type, then you
>> don't understand typedef.
>
> I've been watching this discussion with some interest, because I would
> have said that it "defines" a type.  Sure, it just defines that type
> to be identical to another type, but so what?

That depends on what you mean by "defines", and by "identical".
(Fortunately you avoided using the word "is", so we can avoid
the obvious jokes.)

I'm been assuming (well, stubbornly asserting) that to "define"
a type means to *create* a type.  typedef doesn't do that.

Is that inconsistent with your understanding of what "define" means?

As for "identical", well, there's identical, and there's identical.
For example, as you know, two of char, signed char, and unsigned char
have identical characteristics, but they're three distinct types.

> After "typedef char *str", the word "str" has become a type -- I can
> consistently use it as though it were a type.  I can use it to declare
> variables, I can use it as the return type or in the prototype of a
> function, and so on.  I can pass it to sizeof.  In short, it acts just
> like a type.  It has behavior equivalent to the behavior of, e.g.,
> "float".
>
> I think the key argument really does come down to the difference between:
>
> 	char *s, t;
> and
> 	str s, t;
>
> "str" is not just a thing which is substituted out for "char *" -- it's not
> a macro.  It's a single identifier which now denotes one of the derived types.

But that's just syntax.  It has little to do with the underlying
concept, beyond being what's used to express it.

    char *s, t;

is the syntax that expresses the concept "s is of type pointer-to-char,
t is of type char".  For purposes of this discussion, I'd say there's
no relevant difference between "char *s, t;" and "char *s; char t;".

> I guess, the reason I tend to think of it as "defining" a type is that
> the resulting type name behaves more like one of the built-in types than
> it does like spelling out the derivationof a derived type.  Consider:
>
> 	typedef int (*foo)(int);
>
> Now, after I've done this:
> 	int (*bar)(int);
> 	foo bar;
>
> Note that in one of these, the name of the thing declared is buried inside
> the declaration, while in the other, it's just an identifier following a
> type name.  That feels a little like a definition.

Right.  Typedef creates a *name*, not a type.

Consider this.  If typedef defines a type, then how do you describe
the distinction between this:

    struct foo { int x; };
    struct bar { int x; };

and this:

    struct foo { int x; };
    typedef struct foo bar;

?  I'd say that "struct bar { int x; };" defines a type (a struct type)
and a name for that type ("struct bar"), whereas "typedef struct foo
bar;" only defines a name ("foo") for an existing type (the one defined
on the previous line).

> ... Of course, now that I mention "definitions" and "macros", I suppose
> there's a definite clash here with the semantics of #define.  :)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
0
Keith
10/19/2010 12:21:16 AM
On 2010-10-19, Keith Thompson <kst-u@mib.org> wrote:
> I'm been assuming (well, stubbornly asserting) that to "define"
> a type means to *create* a type.  typedef doesn't do that.

> Is that inconsistent with your understanding of what "define" means?

Yes.

Here's the thing.  Let's say I tell you what I think a word means; I am
*defining* that word.  But I'm not *creating* a word -- I'm just telling you
what the word is.  (Self-referentially, the word in question would likely be
"define".)

I think... Hmm.  Here's the thing.  In C, when referring to functions
or variables, it's pretty clear that a declaration tells you that something
exists, and a definition creates it.  But in other contexts, a definition
just tells you what something is.  I think you're probably applying the
C variables-and-functions sense of "define" here, while I'm just using the
general English sense of "define".

> But that's just syntax.  It has little to do with the underlying
> concept, beyond being what's used to express it.

Perhaps, but it creates a difference in how the language behaves; I
can declare multiple items as pointers, with only one thing on the
line which logically implies pointerness.

> is the syntax that expresses the concept "s is of type pointer-to-char,
> t is of type char".  For purposes of this discussion, I'd say there's
> no relevant difference between "char *s, t;" and "char *s; char t;".

I think there's something about "char *s, t" that takes some thinking
about.  In that, "char" is the type, and "*s" and "t" are the things
declared -- the * is not part of the type used for the whole set of
declarations, it's part of an individual declaration.

Ugh.  My brain's fuzzy.  What I'm trying to get at is, the thing at the
left side of a declaration of multiple variables is the base type of the
whole set, but then individual variables can be derived in various ways
(pointers, arrays, etc.).  Without a typedef, there's nothing you can
put at the left side of a declaration of two objects which makes both of
them pointers.  You can only declare objects of base types, not derived
types.  After a typedef, somehow the thing you've typedefed starts
acting more like a base type.

> Right.  Typedef creates a *name*, not a type.

Oh, certainly.

But I don't think of "defining" as "creating".  Dictionaries don't create
words, they describe them.

> ?  I'd say that "struct bar { int x; };" defines a type (a struct type)
> and a name for that type ("struct bar"), whereas "typedef struct foo
> bar;" only defines a name ("foo") for an existing type (the one defined
> on the previous line).

Sure.  But that name is now a "type" for purposes of the language, so
what it did was define a type, but not create a type.  We're running into
the clash between plain-English "define" and variables-and-functions "define".

.... And come to think of it, in the struct case, it's used that way, where
"define" creates the type, and "declare" just tells you that it's there.

I think the thing is, I don't extend that usage beyond the specific
cases where the standard formalizes that distinction, so I fall back on the
plain English sense where "define" is used in the sense of "what dictionaries
do to words".

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@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.
0
Seebs
10/19/2010 12:30:55 AM
<snip whole discussion of typedef>

For the love of all, let's take a step back and sort this out.

First, I would have you all read:
  http://www.parashift.com/c++-faq-lite/proper-inheritance.html#faq-21.8
It does not matter if you have a PHD in math, religion, philosophy, or
general computer science. I don't care if the weight of all of the
dictionaries of the world are against me. The term "define a type" has
a specific definition in C, this is a C question in a C forum, and so
that's the definition which matters.

However, in order to be readable and to clear up any
misunderstandings, I'll try to avoid controversial terms where ever
possible.

The C compiler is a real computer program, so its memory is finite, so
it "understands" or "knows" only a finite number of types. The C
compiler has a built-in understanding of the built-in types, void,
char, short, int, long, float, double, and so on. It also has a built-
in understanding of other types, built recursively through the use of
production rules of a context free grammar. Pointers, signed,
unsigned, and so on. It does not list them all out because its memory
is finite, but the programmer does not "define", "declare", or
"introduce" these types - the user merely "references" / "uses" these
types.

Then there are aggregate types, those with the struct keyword. When
you write
  struct foo { int x; };
this tells the C compiler about a type. "It introduces a type" / "It
defines a type" / "It declares a type". The C compiler will internally
make a note. That note will contain (at least) 2 things:
  The name of the type, ex: "struct foo"
  The names, types, and layout of its members: ex: "{ int x; }"

When you write
  typedef struct foo bar;
this tells the C compiler about a new type alias. "It does not
introduce a type" / "it does not define a type" / "it does not declare
a type". The C compiler will not internally make a note like above.
Instead, it will make a much smaller note which contains (at least) 2
things:
  The name of the new alias, ex: "bar"
  The name of the referred-to type, ex: "struct foo"

Note that
  typedef struct foo { int x; } bar;
is /exactly/ equivalent to, and defined by the C standard as:
  struct foo { int x; };
  typedef struct foo bar;

The typedef keyword is not associated with "creating" / "defining" /
"introducing" / "declaring" types. It only "creates" / "defines" /
"declares" / "introduces" a name which is an alias for an "already
existing" / "already defined" / "already declared" / "already
introduced" type name. This alias is for most purposes entirely
equivalent to the aliased type name.

Finally, consider
  typedef char* baz;
  char* a, b;
  baz c, d;
Yes "b and "d" do have different types, but that's simply a fluke of
the declaration syntax of C. "a",  "c", and "d" still have the same
type. You can pass any of those three to the following function:
  void f(char* );
or
  void g(baz );
or
  typedef char* xxx;
  void h(xxx );
That is the primary important difference. "To define a type" is to
"create" / "define" / "declare" / "introduce" a new type and name
which is distinct from all other types and type names with regards to
the type checker. "typedef" does not do that. "typedef" "creates" /
"defines" / "declares" / "introduces" names which are not distinct
with regards to the type checker, and so by definition it does not
define new types. Thus typedef, from type-def, from type-definition,
is a misnomer. A much better name would be typealias.
0
Joshua
10/19/2010 1:19:08 AM
On Oct 18, 6:19=A0pm, Joshua Maurice <joshuamaur...@gmail.com> wrote:
> <snip whole discussion of typedef>
>
> For the love of all, let's take a step back and sort this out.
>
> First, I would have you all read:
> =A0http://www.parashift.com/c++-faq-lite/proper-inheritance.html#faq-21.8
> It does not matter if you have a PHD in math, religion, philosophy, or
> general computer science. I don't care if the weight of all of the
> dictionaries of the world are against me. The term "define a type" has
> a specific definition in C, this is a C question in a C forum, and so
> that's the definition which matters.

Err, actually
  http://www.parashift.com/c++-faq-lite/proper-inheritance.html#faq-21.11
is what I intended, though you may need to read more to get an idea of
its context.

My mistake.
0
10/19/2010 1:21:03 AM
In comp.lang.c Alexander <alvatov@gmail.com> wrote in part:
> Please share your oppinion on anything you do not like in
> the C or C++ or Java syntax (they're quite similar).


I'm shocked no-one has complained about the excessive requirement
for semicolons.  \n should imply end-of-statement unless escaped (\?)

Another pet peeve is no simple way to read or print largish
arrays in a single [slow] printf() call.  Something like
FORTRAN's implied DO loops.

-- Robert

0
Robert
10/19/2010 3:23:09 AM
On Mon, 18 Oct 2010 08:46:46 +0100, Tom Anderson wrote:

[massive snip]

Believe me, I've seen worse. And savvy users may not like programs trying 
to keep their own documents but that doesn't stop the programs themselves 
from trying. These days iTunes is easily the worst commonly-encountered 
offender but it's far from the only one.

Recently a friend asked me to help him get his iPhone contacts synching 
with his Outlook contacts. Boy was it a pain.

First, there are several places where Windows wants to keep contacts. 
Address Book comes with Windows and is one place (and the default iTunes 
synch target on Windows); Outlook has its own. Address Book keeps it all 
in a single .wab file in C:\Documents and Settings\$USERNAME\Application 
Data\Microsoft\Address Book\ (how's that long and deeply nested path grab 
you?!) and easily exports to .wab and CSV. iTunes doesn't even let you 
*see* the contacts, just synch them(!); the phone does let you see and 
edit contacts on the device. Where iTunes and Outlook keep their own 
copies I still have no idea. None of them is in My Documents or any of 
its subdirectories, though.

The first thing I did was ascertain that iTunes was synching the phone 
contacts with Address Book instead of Outlook. I backed up the Address 
Book .wab and told it to synch with Outlook instead -- and the Outlook 
contacts list, which was missing a bunch of information (basically only 
having the names and phone numbers and nothing else), clobbered the 
phone's instead of vice versa. Good thing I backed everything up, huh? So 
I told it to synch with Address Book again and it clobbered Address Book. 
Argh. Restored Address Book's contacts from the backup.

I spent quite a while trying to use the Address Book contacts directly to 
replace Outlook's. Address Book speaks wab. Outlook does not. Address 
Book exports to CSV, but only the stripped-down data Outlook already had 
-- probably how the Outlook contacts got set in the first place, Outlook 
was installed and it sucked the Address Book contacts out via CSV during 
setup.

Which made me suspect that Outlook was not treating the imported contacts 
as last modified whenever they'd been last modified in Address Book but 
as last modified when Outlook was installed. So they were viewed as the 
newest version by iTunes's synch.

Damn.

Long story short, I manually edited every contact in Address Book -- most 
of the entries had not had the Gender field set and had an obvious 
correct choice for it -- then backed it up again and resynched it with 
the iPhone. This restored the iPhone's contacts. Then I synched the phone 
with Outlook, and that filled in all the missing data in the Outlook 
contacts. Then I left the iTunes on his machine set to synch with Outlook 
rather than Address Book.

Problem solved, I think, but it took about two whole hours. If I could 
have simply gotten at an outlook.wab in some Outlook subdirectory of My 
Documents (or even Application Data) and a phone.wab in some visible, 
browseable file directory in the iPhone by browsing the iPhone as a mass 
storage device via USB, it would have taken two whole minutes, most of 
that watching a file copy dialog reporting its progress.

So what problems have we got here?

1. Everything likes to guard its contacts. Address Book at least leaves
   them where a tech-savvy user that has some passing familiarity with
   Windows can easily find them. iTunes and Outlook hide them better.
2. Devices that don't provide direct filesystem access via external tools
   suck.
3. Corollary of both 1 and 2: Apple sucks.
4. Applications that have the same sort of data not being able to share
   that data sucks; in particular, Address Book and Outlook only sharing
   a limited pidgin vocabulary in common.
5. Corollary of 1 and 4: Microsoft also sucks.

We have had standard vcard and address book formats for years. There 
really was no excuse for this.

I trust the lesson on the evils of applications trying to corral their 
created documents has now been taught sufficiently. :-)

>> Add to that how every kind of browser, file sharing tool, or similar
>> client for downloadable content ends up with its own preferred
>> directories for storing received files, plus iTunes, plus various sync
>> folders for your phone and laptop, and so on, and so forth, and we're
>> rapidly heading straight back into file management hell.
> 
> I would agree that we need better management of that. For me, it's not
> too bad - Firefox and Chrome save things to ~/Downloads, rtorrent saves
> to wherever i tell it to, i don't use a tool for my phone or camera
> (they're mass storage devices - why on earth would i?), and i don't have
> any other downloaders. Well, unless you count sftp, ftp, and so on, but
> those put things where you tell them.

There's part of it right there. Most of those have different defaults, 
pretty much all of them do at least let you change the target directory, 
and in practice you end up having to type ~/downloads (or whatever) into 
every damn thing if you want them all to save in the same place. What a 
pain. At least it's short; 12 characters including the newline to submit 
the entry.

As for your phone and camera it's nice when devices let themselves appear 
as USB mass storage to your PC's operating system. Too bad pretty much 
nothing from Apple will, nor will most digital cameras (but you can pop 
out the memory card and stick it directly in the computer if the computer 
speaks SD and recognizes SD cards bigger than 1GB).

Oh, and did I mention that Apple sucks?

I wonder if iTunes works in Wine, or if anyone's hacked up a Linux tool 
to access Apple's various iFoos. Without the latter I'm liable to go 
Android if I go to a touch-phone-with-apps.

I'm still waiting for a non-evil ebook device to be invented and then 
come to my attention. (The iPad? I bet the iTunes EULA starts with 
"Abandon hope, ye who enter here". The Kindle? And let Amazon brick my 
device or arbitrarily repossess books I bought? Can it even read pdfs of 
arbitrary non-big-publisher origin or .txt files or anything, or only 
books in some proprietary format from some official app store? Are there 
any more choices yet than those two -- preferably with the Kindle e-ink 
technology or something comparable? Hell, what I'd really like is an iPad 
sized, touchscreen for mouse actions enabled, *computer*, i.e. it runs 
the OS of your choice and is basically a PC-compatible laptop with an 
iPad-like form factor and a suitable kernel module [or windows .vxd, 
blech] for the virtual keyboard functionality. Oh, and supports plugging 
in a bog standard physical USB keyboard.)

>> What's our savior going to be? I'm beginning to suspect we're going to
>> soon see a wave of new file management tools, at first appearing as
>> third- party "knowledge manager" programs and eventually superseding
>> Explorer- style shells as those have superseded the old C:\ prompt.
>> These will provide their own nonhierarchical, link-based file
>> management ability, probably with the ability to easily convert any
>> subnetwork of stuff into web pages, or even acting as a web site
>> itself; a locally-hosted web app that can easily adapt to make some
>> stuff publishable remotely. Hyperlinks will creep into everything and
>> become easy to create via drag and drop; no copying and pasting (or
>> worse, memorizing and typing) long filenames.
> 
> Keep taking the medicine.

Excuse me?

0
10/19/2010 5:02:24 AM
On Tue, 19 Oct 2010 05:02:24 +0000, ClassCastException wrote:

> On Mon, 18 Oct 2010 08:46:46 +0100, Tom Anderson wrote:
> 
> [massive snip]
> 
> Believe me, I've seen worse. And savvy users may not like programs
> trying to keep their own documents but that doesn't stop the programs
> themselves from trying. These days iTunes is easily the worst
> commonly-encountered offender but it's far from the only one.
> 
> Recently a friend asked me to help him get his iPhone contacts synching
> with his Outlook contacts. Boy was it a pain.
> 
> First, there are several places where Windows wants to keep contacts.
> Address Book comes with Windows and is one place (and the default iTunes
> synch target on Windows); Outlook has its own. Address Book keeps it all
> in a single .wab file in C:\Documents and Settings\$USERNAME\Application
> Data\Microsoft\Address Book\ (how's that long and deeply nested path
> grab you?!) and easily exports to .wab and CSV. iTunes doesn't even let
> you *see* the contacts, just synch them(!); the phone does let you see
> and edit contacts on the device. Where iTunes and Outlook keep their own
> copies I still have no idea. None of them is in My Documents or any of
> its subdirectories, though.
> 
> The first thing I did was ascertain that iTunes was synching the phone
> contacts with Address Book instead of Outlook. I backed up the Address
> Book .wab and told it to synch with Outlook instead -- and the Outlook
> contacts list, which was missing a bunch of information (basically only
> having the names and phone numbers and nothing else), clobbered the
> phone's instead of vice versa. Good thing I backed everything up, huh?
> So I told it to synch with Address Book again and it clobbered Address
> Book. Argh. Restored Address Book's contacts from the backup.
> 
> I spent quite a while trying to use the Address Book contacts directly
> to replace Outlook's. Address Book speaks wab. Outlook does not. Address
> Book exports to CSV, but only the stripped-down data Outlook already had
> -- probably how the Outlook contacts got set in the first place, Outlook
> was installed and it sucked the Address Book contacts out via CSV during
> setup.
> 
> Which made me suspect that Outlook was not treating the imported
> contacts as last modified whenever they'd been last modified in Address
> Book but as last modified when Outlook was installed. So they were
> viewed as the newest version by iTunes's synch.
> 
> Damn.
> 
> Long story short, I manually edited every contact in Address Book --
> most of the entries had not had the Gender field set and had an obvious
> correct choice for it -- then backed it up again and resynched it with
> the iPhone. This restored the iPhone's contacts. Then I synched the
> phone with Outlook, and that filled in all the missing data in the
> Outlook contacts. Then I left the iTunes on his machine set to synch
> with Outlook rather than Address Book.
> 
> Problem solved, I think, but it took about two whole hours. If I could
> have simply gotten at an outlook.wab in some Outlook subdirectory of My
> Documents (or even Application Data) and a phone.wab in some visible,
> browseable file directory in the iPhone by browsing the iPhone as a mass
> storage device via USB, it would have taken two whole minutes, most of
> that watching a file copy dialog reporting its progress.
> 
> So what problems have we got here?
> 
> 1. Everything likes to guard its contacts. Address Book at least leaves
>    them where a tech-savvy user that has some passing familiarity with
>    Windows can easily find them. iTunes and Outlook hide them better.
> 2. Devices that don't provide direct filesystem access via external
> tools
>    suck.
> 3. Corollary of both 1 and 2: Apple sucks. 4. Applications that have the
> same sort of data not being able to share
>    that data sucks; in particular, Address Book and Outlook only sharing
>    a limited pidgin vocabulary in common.
> 5. Corollary of 1 and 4: Microsoft also sucks.
> 
> We have had standard vcard and address book formats for years. There
> really was no excuse for this.

And even that standard address book format has a problem just by not 
being "a directory full of separate vcard files". If it had been, and the 
operating system had been anything other than Windows, all the tedious 
manual editing could have been replaced by

for f in *.vcf; do touch $f; done

run in the appropriate directory.

Bah!

(Unix isn't 100% immune from that sort of stupidity, of course. It has 
mbox format, so none of your "work with a bunch of files" tools are 
useful when you want to "work with a bunch of emails". But it's a lot 
less prone to it, and it has shell.)
0
10/19/2010 5:17:14 AM
* Robert Redelmeier <redelm@ev1.net.invalid>:
> I'm shocked no-one has complained about the excessive requirement
> for semicolons.  \n should imply end-of-statement unless escaped (\?)

After years of (also) coding vb.net (< 4), I can't believe someone
actually wants that. In version 4, it got (IMHO) even a little more
weird in that you can omit the line end escape (_ in vb) where it's
obvious to the compiler that the statement is not yet complete.

A clear sign for end of statement that doesn't force you to format your
code in a predefined way really is much better.

Regards,
Felix

-- 
 Felix Palmen       (Zirias)  + [PGP] Felix Palmen <felix@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
0
felix
10/19/2010 5:29:56 AM
* Joshua Maurice <joshuamaurice@gmail.com>:
> Thus typedef, from type-def, from type-definition,
> is a misnomer. A much better name would be typealias.

This, again, is from the C grammar or compiler view. That's the wrong
way to think about it. The 'typedef' keyword is used by programmers to
define their types and a human being will most of the time define a
thing by giving it a name. Although typedef is not the only way to do
this (struct and enum will also create a name in their special
namespaces), it is ONE possible way and for many the preferred way.
Compilers do not care about natural language semantics of a keyword,
programmers do; 'typealias' would be much less obvious.

Regards,
Felix

-- 
 Felix Palmen       (Zirias)  + [PGP] Felix Palmen <felix@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
0
felix4560 (61)
10/19/2010 5:42:34 AM
Seebs <usenet-nospam@seebs.net> writes:

> Typedef can turn a derived type into something that smells like
> a primary type.

Thank you.  And that's a good enough reason for saying that it defines a
type.
-- 
Online waterways route planner            | http://canalplan.eu
Plan trips, see photos, check facilities  | http://canalplan.org.uk
0
Nick
10/19/2010 6:20:39 AM

"Felix Palmen" <felix@palmen-it.de> wrote in message
news:N3e8I4cbd2cd4T16a5@nexus.home.palmen-it.de...
> * Robert Redelmeier <redelm@ev1.net.invalid>:
>> I'm shocked no-one has complained about the excessive requirement
>> for semicolons.  \n should imply end-of-statement unless escaped (\?)
>
> After years of (also) coding vb.net (< 4), I can't believe someone
> actually wants that.

I've used such a scheme in a language project for many years, and it's
worked very well: although semicolon is generally used as a statement
separator, you have to search hundreds of lines of code to find a single
one.

In this syntax, end-of-line is interpreted as a semi-colon unless the last
symbol on the line was a comma. It uses \ line-continuations to join lines
as in C (and I'm briefly wandering why you need actually \ escapes in C,
outside of macros, since EOL is just white space anyway...)

> In version 4, it got (IMHO) even a little more
> weird in that you can omit the line end escape (_ in vb) where it's
> obvious to the compiler that the statement is not yet complete.

(That's interesting. I'm working on a new project which does just that: an
EOL is a semicolon unless it's obvious (to the programmer) that the last
symbol shouldn't be followed by a semicolon. But I haven't used it enough to
see how well it works, apart from uncovering some corner cases:

if            # obviously "if;" would be wrong

end if        # "if;" would be OK here

if
   a=b        # this style won't work unless "if\" was used

The main difficulty I found was in documenting the behaviour...

(Another scheme I came across compared the last symbol on one line, with the
first (significant) symbol on the next, and worked out if there should be a
semicolon in-between. I might have another look...))

> A clear sign for end of statement that doesn't force you to format your
> code in a predefined way really is much better.

Sure, but 99% of semicolons are completely obvious; so why bother to type
them? And since most code seems to be line-oriented, it's a shame for the 
language not to take advantage of that.


-- 
Bartc 

0
BartC
10/19/2010 10:14:25 AM
"Joshua Maurice" <joshuamaurice@gmail.com> wrote in message 
news:ac0f8582-94f5-4651-a0d5-1a00dea276e8@k22g2000yqh.googlegroups.com...
> <snip whole discussion of typedef>
>
> First, I would have you all read:
>  http://www.parashift.com/c++-faq-lite/proper-inheritance.html#faq-21.8

(Or even 21.11.) Any particular bit? Since this stuff on C++ is not very 
interesting.

> When you write
>  typedef struct foo bar;
> this tells the C compiler about a new type alias.

More like a macro, but a more elaborate one than a textual macro, because of 
C's convoluted, inside-out type-specs.

-- 
Bartc 

0
bc (2337)
10/19/2010 10:23:44 AM
"BartC" <bc@freeuk.com> wrote in message 
news:i9jrkb$ps0$1@news.eternal-september.org...
> "Joshua Maurice" <joshuamaurice@gmail.com> wrote in message 
> news:ac0f8582-94f5-4651-a0d5-1a00dea276e8@k22g2000yqh.googlegroups.com...
>> <snip whole discussion of typedef>
>>
>> First, I would have you all read:
>>  http://www.parashift.com/c++-faq-lite/proper-inheritance.html#faq-21.8
>
> (Or even 21.11.) Any particular bit? Since this stuff on C++ is not very 
> interesting.

Oh, I found it now (the link didn't go straight to 21.11).

But I'll read it later...

-- 
Bartc 

0
bc (2337)
10/19/2010 10:29:38 AM
"BartC" <bc@freeuk.com> wrote in message 
news:i9jr2f$nib$1@news.eternal-september.org...
> "Felix Palmen" <felix@palmen-it.de> wrote in message

[avoiding semicolons]
>> In version 4, it got (IMHO) even a little more
>> weird in that you can omit the line end escape (_ in vb) where it's
>> obvious to the compiler that the statement is not yet complete.
>
> (That's interesting. I'm working on a new project which does just that...
....
> if            # obviously "if;" would be wrong
....
> if
>   a=b        # this style won't work unless "if\" was used

(Actually that last example *would* work in this scheme. Although I don't 
know whether it was worth pointing that out...)

-- 
Bartc 

0
BartC
10/19/2010 10:40:43 AM
On Tue, 19 Oct 2010 05:17:14 +0000, ClassCastException wrote:

> (Unix isn't 100% immune from that sort of stupidity, of course. It has
> mbox format, so none of your "work with a bunch of files" tools are
> useful when you want to "work with a bunch of emails". But it's a lot
> less prone to it, and it has shell.)
>
There are mbox -> Mdir format converters around - mboxgrep for one - and 
at least almost every MUA can handle one or both those formats and almost 
all MTAs can write to those.

If there is a problem with *nix MUAs its the creeping microsoftism called 
IMAP, but at least its (usually) safely hidden behind a server such as 
Dovecot. If you're really stuck there's always JavaMail, which can read 
and write both mbox and Mdir with the appropriate provider plugins as 
well as handling the POP3, SMTP and IMAP protocols.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |
0
Martin
10/19/2010 11:32:16 AM
Felix Palmen <felix@palmen-it.de> wrote in part:
> * Robert Redelmeier <redelm@ev1.net.invalid>:
>> I'm shocked no-one has complained about the excessive requirement
>> for semicolons.  \n should imply end-of-statement unless escaped (\?)
> 
> After years of (also) coding vb.net (< 4), I can't believe
> someone actually wants that. In version 4, it got (IMHO)
> even a little more weird in that you can omit the line end
> escape (_ in vb) where it's obvious to the compiler that
> the statement is not yet complete.

Err ... if whitespace is good, then blackspace is in some sense bad.
Redundencies clutter the code without adding meaning.

> A clear sign for end of statement that doesn't force you to
> format your code in a predefined way really is much better.

Disagree.  Formatting conveys meaning.  When you wish to do
something clever, then that too should be flagged (escapes).


-- Robert

0
Robert
10/19/2010 11:46:55 AM
Robert Redelmeier <redelm@ev1.net.invalid> writes:

> In comp.lang.c Alexander <alvatov@gmail.com> wrote in part:
>> Please share your oppinion on anything you do not like in
>> the C or C++ or Java syntax (they're quite similar).
>
> I'm shocked no-one has complained about the excessive requirement
> for semicolons.  \n should imply end-of-statement unless escaped (\?)

OK. So you don't understand C. Fine....

>
> Another pet peeve is no simple way to read or print largish
> arrays in a single [slow] printf() call.  Something like
> FORTRAN's implied DO loops.
>
> -- Robert
>

-- 
"Avoid hyperbole at all costs, its the most destructive argument on
the planet" - Mark McIntyre in comp.lang.c
0
Richard
10/19/2010 11:49:05 AM
Rui Maciel wrote:
> Jon wrote:
> 
>> Try it and see. (I meant from the context of complete replacement of C
>> strings, by working at the library level cannot be done).
> 
> What leads you to believe that I, or anyone for that matter, never tried it?
> 
> 
> Rui Maciel

Rui: you're a cadillac in Den Uyl.

Low IQ, but that's no vice.

I have every confidence that you try::it.

Yugo, sister.
-- 
Uno
0
Uno
10/19/2010 12:17:09 PM
Seebs <usenet-nospam@seebs.net> writes:
> On 2010-10-19, Keith Thompson <kst-u@mib.org> wrote:
>> I'm been assuming (well, stubbornly asserting) that to "define"
>> a type means to *create* a type.  typedef doesn't do that.
>
>> Is that inconsistent with your understanding of what "define" means?
>
> Yes.

Ok.

> Here's the thing.  Let's say I tell you what I think a word means; I am
> *defining* that word.  But I'm not *creating* a word -- I'm just telling you
> what the word is.  (Self-referentially, the word in question would likely be
> "define".)
>
> I think... Hmm.  Here's the thing.  In C, when referring to functions
> or variables, it's pretty clear that a declaration tells you that something
> exists, and a definition creates it.  But in other contexts, a definition
> just tells you what something is.  I think you're probably applying the
> C variables-and-functions sense of "define" here, while I'm just using the
> general English sense of "define".

Yes, that's exactly what I'm doing.  And personally I think it makes
sense to be consistent about the "define" vs. "declare" distinction, but
it's not really worth arguing about, as long as we understand what we
actually mean.  I'll keep that in mind, and I'll probably try to avoid
using the word "define" when it's not clear what it's supposed to mean.

So here's the real point.  A typedef does not create a type; it merely
creates a new name for an existing type.  The name "typedef" could
easily imply, at least to some people, that "typedef" does create a new
and distinct type, but it doesn't -- at least not on the C language
level.

On the other hand, typedef can be used to create a new "type" that's
*logically* distinct, even if the compiler doesn't see it that way.
For example, size_t might be a typedef for unsigned long in a given
implementation, which means that a size_t object *really is* an
unsigned long object -- but the name "size_t" means something very
different from what the name "unsigned long" means (even aside from
the fact that it might be unsigned int on another implementation.
Similarly FILE might be a typedef for a struct type with an int
member called _fileno, but FILE is *logically* opaque.

As programmers, we often create and use abstractions that aren't
enforced or even understood by the compiler.  In the absence of helpful
diagnostics, we just need to maintain enough discipline to avoid
violating these abstractions.

Suppose a new version of the C standard added a "typecreate" keyword
that acts like typedef except that the new type is distinct from the old
one.  So, for example:

    struct foo { int x; };
    typedef struct foo foo1;
    typecreate struct foo foo2;

So struct foo and foo1 are different names for the same type, but
foo2 is a distinct type.  I'd probably say that typecreate defines
a new type and typedef doesn't.  You, I suppose, would say that
typecreate defines and creates a new type, whereas typedef defines
a new type but doesn't create one.

I still don't know whether this covers what Felix Palmen was trying to
say, but since he's decided to plonk me I'm not going to worry about it.

[big snip]

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
0
Keith
10/19/2010 5:34:04 PM
felix@palmen-it.de (Felix Palmen) writes:
> * Joshua Maurice <joshuamaurice@gmail.com>:
>> Thus typedef, from type-def, from type-definition,
>> is a misnomer. A much better name would be typealias.
>
> This, again, is from the C grammar or compiler view. That's the wrong
> way to think about it. The 'typedef' keyword is used by programmers to
> define their types and a human being will most of the time define a
> thing by giving it a name. Although typedef is not the only way to do
> this (struct and enum will also create a name in their special
> namespaces), it is ONE possible way and for many the preferred way.
> Compilers do not care about natural language semantics of a keyword,
> programmers do; 'typealias' would be much less obvious.

I guess Felix won't see this, but ...

I strongly disagree that "That's the wrong way to think about it."
It's a *different* way to think about it.

A typedef creates a new name for an existing type.  You can use that
new name as an abstraction, a name for a logical entity distinct
from the original type (as size_t is logically distinct from whatever
its base type is, for example).

But it's just as important to understand that the compiler doesn't
create a new type as it is to understand how to use typedef to
create a logical abstraction.

If nothing else, you need to know that if you accidentally mix your
abstraction with the type it's derived from, the compiler probably
isn't going to help you find the mistake.

For example, this program:

#include <stdio.h>
int main(void)
{
    printf("stdin->_fileno = %d\n", stdin->_fileno);
    printf("sizeof(int) = %u\n", sizeof(int));
    return 0;
}

compiles and runs with no diagnostics on my system, because FILE
and size_t are both typedefs.  The program is in some sense wrong
(or at least non-portable) but knowing why the compiler doesn't
catch the errors it requires an understanding of how typedef works
on the language level.

(Of course a compiler *could* recognize the use of typedefs and
print warnings when they're misused.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
0
Keith
10/19/2010 5:44:51 PM
On 2010-10-19, Keith Thompson <kst-u@mib.org> wrote:
> Yes, that's exactly what I'm doing.  And personally I think it makes
> sense to be consistent about the "define" vs. "declare" distinction, but
> it's not really worth arguing about, as long as we understand what we
> actually mean.  I'll keep that in mind, and I'll probably try to avoid
> using the word "define" when it's not clear what it's supposed to mean.

The problem is, we're already inconsistent about it -- #define is totally
unlike a "definition".

Come to think of it though... Does the standard actually call the thing
which reifies a struct type a "definition", or is that also a declaration?
I've seen people refer to the one that says what's in the struct as
a declaration, and the one that just says there's such a struct somewhere
as a "forward declaration".

> So here's the real point.  A typedef does not create a type; it merely
> creates a new name for an existing type.

I agree.  What it creates is a *term*.  It's defining a term, not defining
a type.  But the word "type" is also used, not just for the underlying
mapping of space to interpretation, but to the words used to denote them.
So it does create a word-for-a-mapping.

I think that's the other confusion; "type" is used both to refer to the
mapping of storage to meaning, and to the names we give those.  "typedef"
defines a new name for a mapping of storage to a meaning.  It doesn't matter
whether that mapping already had another name, or could only be spelled
out using the aggregate type mechainsms; we defined a new word for it.

> Suppose a new version of the C standard added a "typecreate" keyword
> that acts like typedef except that the new type is distinct from the old
> one.  So, for example:

>     struct foo { int x; };
>     typedef struct foo foo1;
>     typecreate struct foo foo2;

> So struct foo and foo1 are different names for the same type, but
> foo2 is a distinct type.  I'd probably say that typecreate defines
> a new type and typedef doesn't.  You, I suppose, would say that
> typecreate defines and creates a new type, whereas typedef defines
> a new type but doesn't create one.

Yes.  Because both of them are clearly defining a word which wasn't
previously meaningful and turning into a type -- in the sense of "a
thing which goes in the <type> slot of a declaration".

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@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.
0
Seebs
10/19/2010 6:01:23 PM
"BartC" <bc@freeuk.com> writes:
[...]
> In this syntax, end-of-line is interpreted as a semi-colon unless the last
> symbol on the line was a comma. It uses \ line-continuations to join lines
> as in C (and I'm briefly wandering why you need actually \ escapes in C,
> outside of macros, since EOL is just white space anyway...)
[...]

Macro definitions, as you mention, are the obvious place where
line-continuations are needed.

Prior to the introduction of string literal pasting in C89, it was
also commonly needed for very long string literals.

It might also be useful in some cases for automatically generated
code, where the generator might create logical lines longer than
the maximum physical line.  It might also make sense in some cases
to create extremely long identifiers.

Apart from that, you rarely *need* line continuations, but it would
be more difficult to restrict their use to cases that make sense
than to just allow them generally.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
0
Keith
10/19/2010 6:25:56 PM
Nick <3-nospam@temporary-address.org.uk> writes:
> Seebs <usenet-nospam@seebs.net> writes:
>> Typedef can turn a derived type into something that smells like
>> a primary type.
>
> Thank you.  And that's a good enough reason for saying that it defines a
> type.

That's a matter of opinion.  Smell isn't everything.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
0
Keith
10/19/2010 6:30:48 PM
On 2010-10-19, Keith Thompson <kst-u@mib.org> wrote:
> Nick <3-nospam@temporary-address.org.uk> writes:
>> Seebs <usenet-nospam@seebs.net> writes:
>>> Typedef can turn a derived type into something that smells like
>>> a primary type.

>> Thank you.  And that's a good enough reason for saying that it defines a
>> type.

> That's a matter of opinion.  Smell isn't everything.

True.

The more I think about it, the more I think the problem is that we have
multiple words which can be used in multiple senses:

* define as in "a declaration which provides an initial value is a definition"
  -> let's call this "create"
* define as in "a dictionary defines words"
  -> let's call this "label"

* type as in "the mapping between storage and interpretation"
  -> let's call this "mapping"
* type as in "the name that denotes such a mapping"
  -> let's call this "typename"

Given that, the statement "typedef defines a type" can be translated into
any of:
* typedef creates a mapping (false)
* typedef labels a mapping (true)
* typedef creates a typename (true)
* typedef labels a typename (false)

So it's true about half the time.  :P  I think "labels a typename" is an
incoherency in practice, so it's true of two of the three things I could
possibly mean by the original statement.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@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.
0
Seebs
10/19/2010 7:02:41 PM
Seebs <usenet-nospam@seebs.net> writes:
> On 2010-10-19, Keith Thompson <kst-u@mib.org> wrote:
>> Yes, that's exactly what I'm doing.  And personally I think it makes
>> sense to be consistent about the "define" vs. "declare" distinction, but
>> it's not really worth arguing about, as long as we understand what we
>> actually mean.  I'll keep that in mind, and I'll probably try to avoid
>> using the word "define" when it's not clear what it's supposed to mean.
>
> The problem is, we're already inconsistent about it -- #define is totally
> unlike a "definition".

Really?  It creates a new macro (one that didn't previously exist) and a
name for it.  A macro is a very different thing than, say, an object,
but it seems reasonably consistent.

> Come to think of it though... Does the standard actually call the thing
> which reifies a struct type a "definition", or is that also a declaration?
> I've seen people refer to the one that says what's in the struct as
> a declaration, and the one that just says there's such a struct somewhere
> as a "forward declaration".

The syntactic category for "struct foo { int x; }" is
"struct-or-union-specifier".  (There is a "struct-declaration",
but that refers to a member declaration such as "int x;".)

A "struct-or-union-specifier" is one kind of "type-specifier",
which matches "declaration-specifiers", which matches "declaration".

>> So here's the real point.  A typedef does not create a type; it merely
>> creates a new name for an existing type.
>
> I agree.  What it creates is a *term*.  It's defining a term, not defining
> a type.  But the word "type" is also used, not just for the underlying
> mapping of space to interpretation, but to the words used to denote them.
> So it does create a word-for-a-mapping.
> 
> I think that's the other confusion; "type" is used both to refer to the
> mapping of storage to meaning, and to the names we give those.  "typedef"
> defines a new name for a mapping of storage to a meaning.  It doesn't matter
> whether that mapping already had another name, or could only be spelled
> out using the aggregate type mechainsms; we defined a new word for it.

I don't entirely agree.  The word "int", consisting of the letters
'i', 'n', and 't', is not a type, it's a keyword.  It happens to
be the name of a type, but it is not itself a type.

When we say "int is a type", "int" doesn't refer to the syntactic
keyword, it refers to the thing that the name refers to.  It's a
distinction that we can and do ignore most of the time, but in
contexts like this it can be important.  It's very much like the
distiction between "numeral" and "number".

>> Suppose a new version of the C standard added a "typecreate" keyword
>> that acts like typedef except that the new type is distinct from the old
>> one.  So, for example:
>
>>     struct foo { int x; };
>>     typedef struct foo foo1;
>>     typecreate struct foo foo2;
>
>> So struct foo and foo1 are different names for the same type, but
>> foo2 is a distinct type.  I'd probably say that typecreate defines
>> a new type and typedef doesn't.  You, I suppose, would say that
>> typecreate defines and creates a new type, whereas typedef defines
>> a new type but doesn't create one.
>
> Yes.  Because both of them are clearly defining a word which wasn't
> previously meaningful and turning into a type -- in the sense of "a
> thing which goes in the <type> slot of a declaration".

Well, turning it into *a name for* a type, but we've already gone over
that.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
0
Keith
10/19/2010 7:08:45 PM
On Oct 18, 2:06=A0pm, gaze...@shell.xmission.com (Kenny McCormack)
wrote:
> In article <lnwrpf2ut1....@nuthaus.mib.org>,
> Keith Thompson =A0<ks...@mib.org> wrote:
>
>
>
>
>
> >fe...@palmen-it.de (Felix Palmen) writes:
> >> * Keith Thompson <ks...@mib.org>:
> >>> fe...@palmen-it.de (Felix Palmen) writes:
> >>>> If it was really a synonym, the following should be interpreted the
> >>>> same:
>
> >>>> char * a, b, c;
>
> >>>> and
>
> >>>> typedef char * string
> >>>> string a, b, c;
>
> >>> That doesn't follow. =A0typedef doesn't act on tokens, it acts on typ=
es.
> >>> It's a semantic construct, not a macro.
>
> >>> "typedef char *string;" creates a synonym for the type char*.
> >>> "string a, b, c;" creates three objects of type char*.
>
> >>> Given "typedef char *string;", do you argue that "char*" and "string"
> >>> are distinct types?
>
> >> You didn't get the point. Not even close. Maybe you didn't want to.
>
> >Then perhaps you could explain the point more clearly. =A0It's quite
> >possible that I'm missing something you're trying to say.
>
> >1. "typedef" does not define a type.
>
> >2. By "define a type", I mean "create a new type".
>
> Most people use the term "create a new type" to mean "create a new type".
>
> By your logic, the dictionary does not define words. =A0Which, I'm sure i=
n
> your twisted mind, it doesn't (as you - or one of your socks - will no
> doubt explain that to me any minute now)...
>

I'm not a sock, but I'll be more than happy to point out what you (and
several others) seem to be missing.

Which of the following lines of code actually *define* a new type?

    struct foo {
      int bar;
      double bletch;
    };

    typedef struct foo Foo;

Hint: it's not the typedef.

Even for something like

    typedef struct {
      int bar;
      double bletch;
    } Foo;

it is the *struct definition* that *defines* a new type; the *typedef*
associates a *name* with that type.

   typedef int MyInt;

associates the *name* MyInt with the existing type int.

   typedef char **MyPtr;

associates the *name* MyPtr with the existing type char **.

Und so weiter.

This isn't rocket science, guys.
0
John
10/19/2010 8:09:23 PM
On 2010-10-19, Keith Thompson <kst-u@mib.org> wrote:
> Really?  It creates a new macro (one that didn't previously exist) and a
> name for it.  A macro is a very different thing than, say, an object,
> but it seems reasonably consistent.

But it doesn't create a new thing, it just creates a new spelling for an
existing block of code.

> A "struct-or-union-specifier" is one kind of "type-specifier",
> which matches "declaration-specifiers", which matches "declaration".

So that's a declaration, not a definition, even though it defines...
argh.

> When we say "int is a type", "int" doesn't refer to the syntactic
> keyword, it refers to the thing that the name refers to.  It's a
> distinction that we can and do ignore most of the time, but in
> contexts like this it can be important.  It's very much like the
> distiction between "numeral" and "number".

But in:
	int x;
the word "int" is commonly referred to as a type.  Perhaps it shouldn't
be, but it is.  Similarly, in
	struct foo x;
the phrase "struct foo" is a type.

>> Yes.  Because both of them are clearly defining a word which wasn't
>> previously meaningful and turning into a type -- in the sense of "a
>> thing which goes in the <type> slot of a declaration".

> Well, turning it into *a name for* a type, but we've already gone over
> that.

Yeah, but same with the macro; the macro is really just a name for the
expansion of a hunk of code which was already typed somewhere.  :)

We're creating a new mapping from a name to a thing, such that the name
can now be used in places where we use types.  That is an awful lot like
creating a type.

We're also giving a definition of what a given thing is, and that thing
happens to denote a type.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@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.
0
Seebs
10/19/2010 8:16:07 PM
On Oct 18, 2:04=A0pm, gaze...@shell.xmission.com (Kenny McCormack)
wrote:
> In article <i9i0ht$3d...@news.eternal-september.org>,Richard =A0<rgrd...@=
gmail.com> wrote:
>
> ...
>
> >> typedef does not define a type. =A0It defines a name for a type.
>
> >Amazing. Simply amazing.
>
> >Yet 99% of people will use it to "define a type".
>
> The funny thing is that I am certain that at least 90% (probably 99%) of
> working C programmers have had no contact with and no knowledge of the
> sacred C standards documents. =A0They just get their job done and go home
> at 5 to their families.
>

And then a couple of years later people like me get called in to find
out why code that was working "perfectly" is suddenly barfing all over
the place after a system update, only to find instances of things
where the standard says, "hey, don't do that, it won't work the way
you think it will."

There's no excuse for not having at least a passing familiarity with
the DEFINITION OF THE LANGUAGE YOU ARE PROGRAMMING IN, particularly
the bits where it says "hey, don't do that."  It's more of an issue
for C than for, say, Fortran, because there's so goddamned much
misinformation about C out in the wild.  Couple that with the attitude
of "hurr hurr who needs to read the standard hurr" and you have the
recipe for buggy, unsafe systems.
0
jfbode1029 (228)
10/19/2010 8:17:34 PM
In article <26fc1c3e-518c-41ec-8bae-e6fd84d08432@j18g2000yqd.googlegroups.com>,
John Bode  <jfbode1029@gmail.com> wrote:
>
>Which of the following lines of code actually *define* a new type?
>
>    struct foo {
>      int bar;
>      double bletch;
>    };
>
>    typedef struct foo Foo;
>
>Hint: it's not the typedef.

Alternate interpretation: the first one creates a type and defines
"struct foo" to be a name of the new type. The second defines "Foo" to be a
name of the same type. Defining (a.k.a. naming) and creating don't need to be
done at the same time.

>
>Even for something like
>
>    typedef struct {
>      int bar;
>      double bletch;
>    } Foo;
>
>it is the *struct definition* that *defines* a new type; the *typedef*
>associates a *name* with that type.

Better yet, look at this one:

  struct {
    int x,y,z;
  } foo;

It created a type, obviously. It defined foo as an instance of that type. But
the type has no name, so has it been "defined"? Some say no. Others go so far
as to say that even with a struct tag, it still lacks a name since "real"
names must be in the global identifier namespace. Those people... have gone
too far and are addicted to unnecessary typedefs.

>
>   typedef int MyInt;
>
>associates the *name* MyInt with the existing type int.

Associating a name with a concept/entity is what "defining" actually is.

-- 
Alan Curry
0
pacman
10/19/2010 8:26:46 PM
Ben Bacarisse wrote:
> "Jon" <jomar@spblocker.net> writes:
>
>> Ben Bacarisse wrote:
>>> "Jon" <jomar@spblocker.net> writes:
>>>
>>>> "Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message
>>>> news:0.1380ee9f31ea3465db09.20101017030653BST.87ocatmv2a.fsf@bsb.me.uk...
>>>>> "Jon" <jomar@spblocker.net> writes:
>>>>>
>>>>>> "Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message
>>>>>> news:0.4ef395e0027b90f26249.20101016114759BST.87zkuemn1c.fsf@bsb.me.uk...
>>>>>>> "Jon" <jomar@spblocker.net> writes:
>>>>>>>
>>>>>>>> "Keith Thompson" <kst-u@mib.org> wrote in message
>>>>>>>> news:lnbp6wbx0g.fsf@nuthaus.mib.org...
>>>>>>>>> "Jon" <jomar@spblocker.net> writes:
>>>>>>>>>> Nick Keighley wrote:
>>>>>>>>>>> use typedef (which should be called typealias)
>>>>>>>>>>
>>>>>>>>>> #define Alias typedef
>>>>>>>>>>
>>>>>>>>>> If the preprocessor is not your friend, then C will be your
>>>>>>>>>> enemy. You're
>>>>>>>>>> welcome.
>>>>>>>>>
>>>>>>>>> If I'm reading code that uses typedef, I have to understand
>>>>>>>>> how typedef
>>>>>>>>> works.
>>>>>>>>>
>>>>>>>>> If I'm reading code that uses your "Alias" macro, I still have
>>>>>>>>> to understand how typedef works -- *and* that "Alias" means
>>>>>>>>> typedef.
>>>>>>>>>
>>>>>>>>> It doesn't help.
>>>>>>>>
>>>>>>>> Think of a new programmer. Is he likely to understand that
>>>>>>>> typedef means
>>>>>>>> alias in reality or likely to think that it means declaration
>>>>>>>> of a new
>>>>>>>> type? Therefore, "Alias" is better.
>>>>>>>
>>>>>>> A #define is particularly bad for new programmers

If the goal is to leave behind and deprecate C ASAP, it's a fine 
intermediary technique (they need know nothing of the define, only the 
"keyword" which will be the same after transition to the good GP language 
when it arrives, and it will). If the goal is to perpetuate the woefully 
inadequate constructs of C (for whatever reason, see end of this post), 
then it is "bad". If that is "bad" then, the descriptive adjective for 
the C programming language would likely be an expletive-derived word.
>>>>>>
>>>>>> The issue is not a define,
>>>>>
>>>>> I thought you were suggesting one.
>>>>
>>>> Pfft. I know better than to "suggest" a change to the ISO C
>>>> standard in this ng.
>>>
>>> Eh?  I know you didn't.  You suggested a #define.  I was commenting
>>> on only on that and, in particular, the value you claimed it would
>>> have for new programmers.
>>
>> I know where you're coming from: "God created all things, therefore
>> God must exist", and "If all you have or know is C, then everything
>> looks like a thumb". "New programmer" does NOT mean "new *C*
>> programmer". Why perpetuate "crazy" constructs unnecessarily? Yes,
>> 'alias' is better than 'typedef'.
>
> I have no idea what this means, but I am not sure how much that
> matters. I've expressed my view a clearly as I can and I don't think
> you've misunderstood it, so there's little point in my saying more.
> I may be incapable of understanding your point of view so we might as
> well just leave it that we disagree about something.

Keywords should be well-thought out and reasonably understandable at 
first sight. If you can't admit that "typedef" is a bad choice of keyword 
because it does nothing like "define a type" (and it's really *declaring* 
a type that most people think is happening) and that is what 99.9% of new 
programmers and probably half of existing programmers think it does, then 
there is really no point in discussing anything. Hence, I associated your 
stance in a more appropriate area: religion and naivete (and if not that, 
it must be politics or propaganda or job-security), and I don't play 
those games. 


0
Jon
10/19/2010 8:36:38 PM
Keith Thompson wrote:
> luser- -droog <mijoryx@yahoo.com> writes:
>> On Oct 16, 9:06� pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>>> "Jon" <jo...@spblocker.net> writes:
> [...]
>>>> The issue is not a define,
>>>
>>> I thought you were suggesting one.
>>>
>>>> but rather that "typedef" is a poor choice of
>>>> keyword for what it does in the C language. "alias" would have
>>>> been much better.
>>>
>>> I'd prefer a keyword that included "type" in it because alias is a
>>> very general word, but I agree that there might be a better word. �
>>> I don't agree (given the C language we have) that the #define you
>>> posted makes anything better.
>>
>>
>> #define typealias typedef
>>
>> ?
>
> I agree that "typedef" was not a good choice of name for the
> semantics. Perhaps "typealias" would have been better.
>
> But "typedef" is in the language, and it's not going away.  Every C
> programmer needs to understand that "typedef" doesn't define a type
> (just as "const" doesn't mean constant).
>
> Adding an obfuscating macro *does not help*, any more than
>    #define BEGIN {
>    #define END }
>    #define IF if (
>    #define THEN ) {
> and so on.

That is not nearly the same thing and that you posted that really shows 
that you are grasping for any little thing in some kind of attempt at 
<whatever> (see the bottom of my last post for some options for 
"<whatever>"). (Is what he did called "a strawman"? IOW, a lame 
"argument"?). 


0
Jon
10/19/2010 8:42:39 PM
Nick wrote:
> Keith Thompson <kst-u@mib.org> writes:
>
>> Adding an obfuscating macro *does not help*, any more than
>>     #define BEGIN {
>>     #define END }
>>     #define IF if (
>>     #define THEN ) {
>> and so on.
>
> Wholehearted agreement here.

Then you're as bone-headed as he is. (If you 2 are really just 
cognitively-challenged, then disregard the preceding assessment). 


0
Jon
10/19/2010 8:46:22 PM
Nick Keighley wrote:
> On 17 Oct, 03:06, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>> "Jon" <jo...@spblocker.net> writes:
>>> "Ben Bacarisse" <ben.use...@bsb.me.uk> wrote in message
>>> news:0.4ef395e0027b90f26249.20101016114759BST.87zkuemn1c.fsf@bsb.me.uk...
>>>> "Jon" <jo...@spblocker.net> writes:
>>>>> "Keith Thompson" <ks...@mib.org> wrote in message
>>>>> news:lnbp6wbx0g.fsf@nuthaus.mib.org...
>>>>>> "Jon" <jo...@spblocker.net> writes:
>>>>>>> Nick Keighley wrote:
>
>
>>>>>>>> use typedef (which should be called typealias)
>>
>>>>>>> #define Alias typedef
>>
>>>>>>> If the preprocessor is not your friend, then C will be your
>>>>>>> enemy.
>
> terrible advice.

It wasn't advice. It is a fact, lest a programmer be afflicted 
unnecesarrily with archaic notions of programming.

>
> Look, this whole thread is a contrafactual.

The parts by "The C Rah-Rah Crowd", yes.

> *if* we'd been sitting at
> Dennis Ritchie's right hand when he was designing C what would we have
> suggested to him?.

"alias" (or something at least something better than "typedef").

> There's no suggestion that any of these changes to
> C are actually real.

?

>
>>>>>>> You're welcome.
>>
>>>>>> If I'm reading code that uses typedef, I have to understand how
>>>>>> typedef works.
>>
>>>>>> If I'm reading code that uses your "Alias" macro, I still have to
>>>>>> understand how typedef works -- *and* that "Alias" means typedef.
>>
>>>>>> It doesn't help.
>>
>>>>> Think of a new programmer. Is he likely to understand that typedef
>>>>> means
>>>>> alias in reality or likely to think that it means declaration of
>>>>> a new type? Therefore, "Alias" is better.
>>
>>>> A #define is particularly bad for new programmers
>>
>>> The issue is not a define,
>>
>> I thought you were suggesting one.
>>
>>> but rather that "typedef" is a poor choice of
>>> keyword for what it does in the C language. "alias" would have been
>>> much better.
>>
>> I'd prefer a keyword that included "type" in it because alias is a
>> very general word, but I agree that there might be a better word. I
>> don't agree (given the C language we have) that the #define you
>> posted makes anything better.
>
> my original suggestion was "typealias" not "alias"

Which is a hundred times better than "typedef", but does seem to 
introduce compound words as keywords which is probably not necessary and 
probably not desireable. 


0
Jon
10/19/2010 8:57:36 PM
Felix Palmen wrote:
> * Keith Thompson <kst-u@mib.org>:
>> What probably causes some confusion ...
>
> Just try -- for a second -- to realize there is no confusion at all.
> Then think about why people decided to give typedef its name. Probably
> to confuse people, right?

Because they/he didn't analyze/think-about-it enough and certainly didn't 
consider higher-level issues such as programmer learning. A new 
programmer will have to understand this tangential thread and an 
inquisitive one will go back-and-forth like you and Keith are. Is anymore 
evidence needed as to why "typedef" was a bad choic? To most it is 
plainly obvious that is was a bad (and even incorrect, yes, a design 
flaw/defect) choice. 


0
Jon
10/19/2010 9:27:37 PM
Keith Thompson wrote:
> Finally, something I should have written earlier, a quote from the C
> standard.  C99 6.7.7p3:
>
>    A typedef declaration does not introduce a new type, only a
>    synonym for the type so specified.

#define synonym typedef

:) 


0
Jon
10/19/2010 9:30:15 PM
"Jon" <jomar@spblocker.net> writes:

> Nick wrote:
>> Keith Thompson <kst-u@mib.org> writes:
>>
>>> Adding an obfuscating macro *does not help*, any more than
>>>     #define BEGIN {
>>>     #define END }
>>>     #define IF if (
>>>     #define THEN ) {
>>> and so on.
>>
>> Wholehearted agreement here.
>
> Then you're as bone-headed as he is. (If you 2 are really just 
> cognitively-challenged, then disregard the preceding assessment). 

Absolutely.  Keith and I are at complete loggerheads apart from agreeing
that mangling the language is stupid.  If that makes up both boneheaded
and cognitively-challenged then so be it.

Mind you, if you are defining (or is it just naming?) me in that way,
with the same style, lucidity and common sense as the rest of your
recent postings, I will treat your assessment the same way.  That is,
I'll ignore it as complete gibberish.
-- 
Online waterways route planner            | http://canalplan.eu
Plan trips, see photos, check facilities  | http://canalplan.org.uk
0
3-nospam (285)
10/19/2010 9:32:29 PM
Ben Bacarisse wrote:
> Keith Thompson <kst-u@mib.org> writes:
>
>> felix@palmen-it.de (Felix Palmen) writes:
>>> * Keith Thompson <kst-u@mib.org>:
>>>> felix@palmen-it.de (Felix Palmen) writes:
>>>>> * Keith Thompson <kst-u@mib.org>:
>>>>>> Then perhaps you could explain the point more clearly.
>>>>>
>>>>> I did, more than enough. As long as you refuse to think about the
>>>>> /meaning/ of a typedef (to the programmer, that is .. YES that's
>>>>> one abstraction level ABOVE your standards), this discussion ist
>>>>> just pointless.
>>>>
>>>> If you don't understand that typedef doesn't define a type, then
>>>> you don't understand typedef.
>>>>
>>>> I agree, this is pointless (unless you're willing to explain just
>>>> what you're talking about).
>>>
>>> *plonk*
>>
>> Just out of curiosity, did anyone else understand the point he was
>> trying to make?
>
> Well I didn't.  The passing shot (quoted above) suggests that he was
> making a point, disconnected from the C language, about how one should
> think about a typedef'd type.  However, I don't think that was the
> point he was making earlier in the thread.

At some point, I think he was doing: "typedef operates like it does, 
therefore one must accept that 'typedef' has only the meaning as 
exhibited by its operation and not by its coincidental likeness to any 
English language word(s) or fragments thereof. That is to say, it's just 
like any random glyph used for a specific operation. The glyph could be a 
swastika but operate like "typedef" in C, and because it was chosen as 
the glyph, it is, by nature of being chosen, appropriate and correct and 
irrefutably the best choice." 


0
Jon
10/19/2010 9:42:46 PM
"Jon" <jomar@spblocker.net> writes:
<snip>
> Keywords should be well-thought out and reasonably understandable at 
> first sight. If you can't admit that "typedef" is a bad choice of
> keyword

You must have missed the part where I agreed with that.  About five
messages ago.
 
> because it does nothing like "define a type" (and it's really *declaring* 
> a type that most people think is happening) and that is what 99.9% of new 
> programmers and probably half of existing programmers think it does, then 
> there is really no point in discussing anything.

No, there's no point in discussing it if you read my comments about one
thing (the value of #define Alias typedef) as being about something else
(some imagined stance about what typedef does) nor if you miss or ignore
the parts where I agree with you.

> Hence, I associated your 
> stance in a more appropriate area: religion and naivete (and if not that, 
> it must be politics or propaganda or job-security), and I don't play 
> those games.

-- 
Ben.
0