gnu@hoptoad.uucp (John Gilmore) (05/26/89)
I think C++ would be a lot better language if it was a superset of ANSI
C. I can get along with stealing a few identifiers as new keywords,
like "class". But the gross change that makes "struct foo {...};"
equivalent to "typedef struct foo {...} foo;" is too much to bear.
Surely the burden of incompatability is too high a price to pay, when
the solution is simple: either writing "struct/union/class/enum foo"
when you declare a "foo", or explicitly coding a typedef yourself in
the header file, if you like typedefs.
Is everyone writing C++ code that depends on this behaviour?
Or are people avoiding it? Is there any chance that the language
definition will be changed to eliminate it? Howabout compiler
warnings for depending on it?
If nobody in the C++ world is interested in this, perhaps there
should be a similar "C+" language that is less grossly hacked.
I don't normally read comp.lang.c++, so please send comments to me
by email, and I will summarize back to comp.lang.c++.
--
John Gilmore {sun,pacbell,uunet,pyramid,amdahl}!hoptoad!gnu gnu@toad.com
A well-regulated militia, being necessary to the security of a free State,
the right of the people to keep and bear arms, shall not be infringed.gamiddleton@watmath.waterloo.edu (Guy Middleton) (05/26/89)
In article <7435@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes: > [ complaints about "struct x { /*...*/ };" === > "typedef struct x { /*...*/ } x;" ] > > Is everyone writing C++ code that depends on this behaviour? > Or are people avoiding it? Is there any chance that the language > definition will be changed to eliminate it? Howabout compiler > warnings for depending on it? I always avoid this, in the hope that the language will someday be changed to do things the old way. I fear that it is a vain hope, however. -Guy Middleton, University of Waterloo gamiddleton@watmath.waterloo.edu
bright@Data-IO.COM (Walter Bright) (05/27/89)
In article <7435@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes: >But the gross change that makes "struct foo {...};" >equivalent to "typedef struct foo {...} foo;" is too much to bear. >Surely the burden of incompatability is too high a price to pay, when >the solution is simple: either writing "struct/union/class/enum foo" >when you declare a "foo", or explicitly coding a typedef yourself in >the header file. There's an even easier solution. I've proposed it to Bjarne, but he disliked it on the grounds that it would require some reediting of existing C++ code. The solution is to retain the separate tag name space for structs and unions, but use the regular name space for class names. Thus, if you declare a struct as 'struct A', you always have to use 'struct A' when referring to A. If you declare it as 'class A', then the typedef is created. For example: struct A { int abc; void fA(); }; class B { int def; void fB(); }; struct A var1; B var2; void struct A::fA() { abc = 3; } void B::fB() { def = 4; } I haven't explored all the ramifications of this, but it looks straightforward. I'm also of the opinion that if you use C++ features in an aggregate, it should be called a 'class'. If it only uses C features, it should be called 'struct'. I'd even support having the compiler enforce this. I'm interested in other's opinions on this.
ark@alice.UUCP (Andrew Koenig) (05/27/89)
In article <7435@hoptoad.uucp>, gnu@hoptoad.uucp (John Gilmore) writes: > I think C++ would be a lot better language if it was a superset of ANSI > C. I can get along with stealing a few identifiers as new keywords, > like "class". But the gross change that makes "struct foo {...};" > equivalent to "typedef struct foo {...} foo;" is too much to bear. Really? Exactly what about it is unbearable? > Surely the burden of incompatability is too high a price to pay, when > the solution is simple: either writing "struct/union/class/enum foo" > when you declare a "foo", or explicitly coding a typedef yourself in > the header file, if you like typedefs. Here's an example of why C++ does it the way it does. class Complex { private: double r, i; public: Complex(double rr = 0,double ii=0) { r = rr; i = ii; } // and so on }; It is much more convenient to be able to write Complex z (3, 4); z += Complex (1, -1); than it would be to write class Complex z (3, 4); z += class Complex (1, -1); Classes are the central concept in C++; it is important to make them as easy to use as possible. > Is everyone writing C++ code that depends on this behaviour? Absolutely. Changing it at this point would break essentially every non-trivial C++ program ever written. -- --Andrew Koenig ark@europa.att.com
kevin@claris.com (Kevin Watts) (05/27/89)
From article <26575@watmath.waterloo.edu>, by gamiddleton@watmath.waterloo.edu (Guy Middleton): > In article <7435@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes: >> [ complaints about "struct x { /*...*/ };" === >> "typedef struct x { /*...*/ } x;" ] I've never liked the typedef nonsense. C++'s approach is, IMHO, the way C should have behaved from the beginning. Since I've never yet had to convert any C code to C++, I've had no problems with compatability. Walter Bright's suggestion (struct as in C, class as in C++) seems like a reasonable compromise. It brings up a question: is there any penalty for using class where struct would do. How about a compiler flag or #pragma to control this behaviour? I expect there are going to be some strong opinions on both sides of this issue, and I don't think it's worth fighting about. -- Kevin Watts ! Any opinions expressed here are my own, and are not Claris Corporation ! neccessarily shared by anyone else. Unless they are kevin@claris.com ! patently absurd, in which case they're not mine either.
pcg@aber-cs.UUCP (Piercarlo Grandi) (05/28/89)
In article <7435@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes:
I think C++ would be a lot better language if it was a superset of ANSI
C.
Ugh! Do you really want to change the meaning of "const" to the regrettable
one it has in Ansi C? Let me say that often, in updating C, BS has been more
considerate than Ansi C (note that as BS says, C++ = C+extensions+classes,
where the extensions are things like const, inline, etc...).
But the gross change that makes "struct foo {...};"
equivalent to "typedef struct foo {...} foo;" is too much to bear.
Is everyone writing C++ code that depends on this behaviour?
Apparently everybody is. Have you ever seen "class complex c0,c1"? :-).
--
Piercarlo "Peter" Grandi | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth | UUCP: ...!mcvax!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.ukhenry@utzoo.uucp (Henry Spencer) (05/29/89)
In article <1997@dataio.Data-IO.COM> bright@dataio.Data-IO.COM (Walter Bright) writes: >The solution is to retain the separate tag name space for structs and >unions, but use the regular name space for class names.... This has always struck me as the obvious solution, but there will undoubtedly be occasional C++ programs that break if such a change is made. (There is no feature so stupid that you won't find it in at least one program within six months of its release.) >I'm also of the opinion that if you use C++ features in an aggregate, it >should be called a 'class'. If it only uses C features, it should be called >'struct'. I'd even support having the compiler enforce this. Sounds good to me; in fact, on thinking about it, I'd quietly assumed that this was the case already. -- Van Allen, adj: pertaining to | Henry Spencer at U of Toronto Zoology deadly hazards to spaceflight. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
henry@utzoo.uucp (Henry Spencer) (05/29/89)
In article <9395@alice.UUCP> ark@alice.UUCP (Andrew Koenig) writes: >> ... But the gross change that makes "struct foo {...};" >> equivalent to "typedef struct foo {...} foo;" is too much to bear. > >Really? Exactly what about it is unbearable? All the code it breaks. "struct foo foo;" is not at all uncommon when only one variable of a type is needed. >Here's an example of why C++ does it the way it does. > > class Complex { ... Note the word "class" here but "struct" above. >... Changing it at this point would break essentially >every non-trivial C++ program ever written. Note if the change only affects "struct", not "class". -- Van Allen, adj: pertaining to | Henry Spencer at U of Toronto Zoology deadly hazards to spaceflight. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
ark@alice.UUCP (Andrew Koenig) (05/29/89)
First of all, I should point out that I think the
ability to have a struct with the same name as an
object was put into C as a compatibility hack in
the first place -- C did not always have structures and
keeping their names separate from other names was a
good way to avoid breaking existing code. Old habits
die hard. Personally, I've always found things like
struct A A;
a little confusing.
However, if you're trying to translate C programs that
do this sort of thing into C++ programs, I think you
will find that C++ 2.0 is a lot more compatible with C
in this sense than previous versions.
For example, the following is legal in 2.0:
struct A { int a; };
extern void f(A);
struct A A; // `struct' optional here
main()
{
struct A b; // `struct' or `class' needed here
A.a = 3;
b = A;
f(A);
};
This works if `struct' is replaced by `class', too, provided
that the definition of A is changed slightly:
class A { public: int a; };
Otherwise A::a would be private and inaccessible to `main.'
None of this introduces any new differences between `struct'
and `class.' Instead, a class that does not have any constructors
is considered to be enough like C that the C++ translator will
go out of its way to allow C usages it would otherwise reject.
--
--Andrew Koenig
ark@europa.att.comscs@vax3.iti.org (Steve Simmons) (05/29/89)
C++ may have evolved from C, but is now a language in it's own right. C and it's good (and bad) qualities should be a guideline, not a straitjacket. For what one opinion is worth, I say violate C standards whenever they get in the way. Steve Simmons Just another midwestern boy scs@vax3.iti.org -- or -- ...!sharkey!itivax!scs "Think of c++ as an object-oriented assembler..."
shap@polya.Stanford.EDU (Jonathan S. Shapiro) (05/30/89)
I was going to stay out of this, but it is time it ended.
1. The struct foo => foo stuff *is* being used. Note that C++ *does*
correctly handle
typedef struct foo { ... } foo;
and
typedef struct foo foo;
so that this can be done portably.
People are relying on this behavior in both struct and class usage.
Inline and const are done better in C++ than in C. I will refrain
from diatribes about committees. Similarly for various other syntactic
nits.
The tradtional variable declaration
struct foo foo;
was simply gross. It isn't hard to change these (and the struct names)
to
struct foo_s foo;
which is both more readable and less error-prone in alteration.
C++ isn't C. If it was, I would program in Eiffel (blch).
'Nuff said.
Jon Shapiroshopiro@alice.UUCP (Jonathan Shopiro) (05/30/89)
In article <10213@claris.com>, kevin@claris.com (Kevin Watts) writes: > Walter Bright's suggestion (struct as in C, class as in C++) seems like a > reasonable compromise. It brings up a question: is there any penalty for > using class where struct would do? In C++, class and struct are identical, except that base classes and members of structs are public by default, and base classes and members of classes are private by default. In both cases the default can be overridden with the ``public'' and ``private'' (and ``protected'' for members) keywords. These choices have no runtime performance consequences whatsoever. In my opinion, this distinction between class and struct is easy to understand and use. I think the kinds of changes that have been suggested might make it easier to port code from C to C++, but they would make C++ itself harder to understand and use. Note: in the latest version of C++, a warning is generated if the base class of a class is private by default. Use the ``private'' keyword explicitly and the warning goes away. -- Jonathan Shopiro AT&T Bell Laboratories, Warren, NJ 07060-0908 research!shopiro (201) 580-4229
ejohanss@wang7.UUCP (ejohanss) (05/30/89)
In article <26575@watmath.waterloo.edu>, gamiddleton@watmath.waterloo.edu (Guy Middleton) writes: > In article <7435@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes: > > [ complaints about "struct x { /*...*/ };" === > > "typedef struct x { /*...*/ } x;" ] > > > > Is everyone writing C++ code that depends on this behaviour? > > Or are people avoiding it? Is there any chance that the language > > definition will be changed to eliminate it? Howabout compiler > > warnings for depending on it? > > I always avoid this, in the hope that the language will someday be changed to > do things the old way. I fear that it is a vain hope, however. > > -Guy Middleton, University of Waterloo gamiddleton@watmath.waterloo.edu I find this rather interesting. I always wondered why C added the apparent clumsiness of "typedef struct {...} foo;" I was really glad to see C++ "clean up" this problem. My vote goes to leaving C++ struct with it's current definition. And yes, I am writing code that counts on the current C++ struct definition. --- Eric Johansson ...!ima!wang7!ejohanss ...inews noise.... ...inews noise.... ...inews noise.... ...inews noise.... ...inews noise.... ...inews noise.... ...inews noise.... ...inews noise.... ...inews noise.... There! are you happy now??!
diamond@diamond.csl.sony.junet (Norman Diamond) (05/30/89)
In article <1997@dataio.Data-IO.COM> bright@dataio.Data-IO.COM (Walter Bright) writes: >There's an even easier solution. I've proposed it to Bjarne, but he >disliked it on the grounds that it would require some reediting of >existing C++ code. >The solution is to retain the separate tag name space for structs and >unions, but use the regular name space for class names. Thus, if you >declare a struct as 'struct A', you always have to use 'struct A' when >referring to A. If you declare it as 'class A', then the typedef is >created. Bjarne's stated reason for disliking this solution is in fact a strong reason for liking this solution. There is a lot more existing C code to be "inherited" than there is existing C++ code. Mind you, code that played games with structure tags (taking advantage of the separate name space) is ugly and maybe doesn't deserve such efforts, but in other contexts, Bjarne said that it was a high priority to maintain compatibility with existing ugliness. Walter Bright's suggestion suits the style of C and C++ very closely, and meets that high priority requirement much better than the present solution. It might be slightly more consistent not to even create the typedef for classes, and let the class writer also write the typedef. -- Norman Diamond, Sony Computer Science Lab (diamond%csl.sony.co.jp@relay.cs.net) The above opinions are my own. | Why are programmers criticized for If they're also your opinions, | re-implementing the wheel, when car you're infringing my copyright. | manufacturers are praised for it?
diamond@diamond.csl.sony.junet (Norman Diamond) (05/31/89)
In article <9395@alice.UUCP> ark@alice.UUCP (Andrew Koenig) writes: >Here's an example of why C++ does it the way it does. > class Complex { ... }; >It is much more convenient to be able to write > Complex z (3, 4); > z += Complex (1, -1); >than it would be to write > class Complex z (3, 4); > z += class Complex (1, -1); Very true. This is why C almost copied the "typedef" construct from Pascal. "typedef" is very important. Good C programmers use it and good C++ programmers would use it for an example like this. typedef class Complex Complex; class Complex { ... }; A minor pain for new code, just as in C, and no pain for its users. >> Is everyone writing C++ code that depends on this behaviour? >Absolutely. Changing it at this point would break essentially >every non-trivial C++ program ever written. Yes, just as C++ breaks every non-trival C program ever written. C++ should be fixed. -- Norman Diamond, Sony Computer Science Lab (diamond%csl.sony.co.jp@relay.cs.net) The above opinions are my own. | Why are programmers criticized for If they're also your opinions, | re-implementing the wheel, when car you're infringing my copyright. | manufacturers are praised for it?
ekrell@hector.UUCP (Eduardo Krell) (06/02/89)
In article <10308@socslgw.csl.sony.JUNET> diamond@csl.sony.junet (Norman Diamond) writes: >Yes, just as C++ breaks every non-trival C program ever written. Where does it say a C++ compiler should be able to compile C sources? Eduardo Krell AT&T Bell Laboratories, Murray Hill, NJ UUCP: {att,decvax,ucbvax}!ulysses!ekrell Internet: ekrell@ulysses.att.com
wjc@ho5cad.ATT.COM (Bill Carpenter) (06/02/89)
In article <11620@ulysses.homer.nj.att.com> ekrell@hector.UUCP (Eduardo Krell) writes: > Where does it say a C++ compiler should be able to compile C sources? Well, for example, on page 3 of "The C++ Programming Language", twice as a matter of fact. -- Bill Carpenter att!ho5cad!wjc or attmail!bill
ekrell@hector.UUCP (Eduardo Krell) (06/02/89)
In article <WJC.89Jun1232654@ho5cad.ho5cad.ATT.COM> wjc@ho5cad.ATT.COM (Bill Carpenter) writes: >Well, for example, on page 3 of "The C++ Programming Language", twice >as a matter of fact. It says "C is retained as a subset", but then in page 5 it says "both C and ANSI C are very close to being subsets of C++" and under the "Efficiency and Structure" heading (same page), it says "C++ was developed from the C programmingh language and with very few exceptions retains C as a subset". It's clear that you can't retain 100% compatibility with C. Even this doesn't compile: main(){ printf("hello, world\n"); } Eduardo Krell AT&T Bell Laboratories, Murray Hill, NJ UUCP: {att,decvax,ucbvax}!ulysses!ekrell Internet: ekrell@ulysses.att.com
jeffb@grace.cs.washington.edu (Jeff Bowden) (06/03/89)
In article <11623@ulysses.homer.nj.att.com> ekrell@hector.UUCP (Eduardo Krell) writes: >Even this doesn't compile: > >main(){ > printf("hello, world\n"); >} > But it does! Witness: % cat >t.cc main(){ printf("hello, world\n"); } % g++ t.cc % a.out hello, world % cp t.cc t.c % CC t.c CC t.c: "t.c", line 2: warning: undeclared function printf() called cc t..c -lC % a.out hello, world % -- "It has been discovered that C++ provides a remarkable facility for concealing the trivial details of a program - such as where its bugs are."
ekrell@hector.UUCP (Eduardo Krell) (06/03/89)
In article <JEFFB.89Jun2121446@grace.cs.washington.edu> jeffb@grace.cs.washington.edu (Jeff Bowden) writes: >But it does! Witness: But this changed in cfront 2.0: $ CC x.C CC x.C: "x.C", line 2: error: undefined function printf called 1 error Eduardo Krell AT&T Bell Laboratories, Murray Hill, NJ UUCP: {att,decvax,ucbvax}!ulysses!ekrell Internet: ekrell@ulysses.att.com
diamond@diamond.csl.sony.junet (Norman Diamond) (06/05/89)
Whatever the context was, in article <10308@socslgw.csl.sony.JUNET> I wrote: >>Yes, just as C++ breaks every non-trival C program ever written. In article <11620@ulysses.homer.nj.att.com> ekrell@hector.UUCP (Eduardo Krell) writes: >Where does it say a C++ compiler should be able to compile C sources? Well, guess where it says that C++ was intended to be upward compatible from C, and that compatibility with C was a major priority. If such compatibility was not desired, an entirely new language would have been designed. OK, let's have two languages, one upward compatible from C, and one with a nice clean new consistent syntax. I would prefer to use the second one (probably), but the name C++ belongs to the first one. -- Norman Diamond, Sony Computer Science Lab (diamond%csl.sony.co.jp@relay.cs.net) The above opinions are my own. | Why are programmers criticized for If they're also your opinions, | re-implementing the wheel, when car you're infringing my copyright. | manufacturers are praised for it?