ahuttune@niksula.hut.fi (Ari Juhani Huttunen) (02/10/91)
While c++ has evolved, it has sometimes done this in a way that is
compatible with existing c language features and sometimes not. I think
c++ is a language clearly different from c and should not try to imitate
every mistake c has done. Others might not agree.
The point is, I see c++ as a successor to c and, as such, we will be using
it for a long time. This makes it necessary that it be as good as possible
and compatibility with c should not prevent this. The changes need not
be radical, but should such (radical) changes be deemed necessary, then
compatibility with c should not prevent the changes.
Now, I don't think these suggestions are going to change anything, but
I give them to you anyway.
1) I don't think comma-operator is necessary and it should be thrown out of
the language. After that you could change multi-dimensional array referencing
to array[x,y,z];. (How can you implement multi-dimensional arrays of
your own classes using the current array[x][y][z] syntax? I suppose there
is a way, but I can't think of a good one.)
2) Array indexing such as int array[2..5]; should be possible. There would
not have to be runtime checking, but the capability to change the lower
bound is convenient in many situations. first(array) and last(array) would
return the lower and upper bound respectively.
3) Complex number are a basic data type and should be included in the
language. There could well be data types such as complex int z, or
complex float z. Some examples of complex number constants: 1.5i2 that
means 1.5 + 2*i (i = imaginary), 0.5e-1i.45 .
4) Instead of smart pointers, use 'collected class X;'. I have been told
that smart pointers can be used for other things besides garbage collection,
but I understand this would be their main usage. I'm no expert on garbage
collection, but the customization of the garbage collector could perhaps
be given to some member functions. If these member functions are not
given, the compiler generates ones that use the 'standard' garbage collector.
--
___ ___ ___ ___ ___ ___ ___ ___ ___ ___ ___ ___ ___ ___ ___ ___
I I__I I__I I__I I__I I__I I__I I__I I__I I__I I__I I__I I__I I__I I__I I__I I_
Ari Huttunen A computer is like a house of cards. Not as reliable,
but it has an equal number of incompatible parts.
_______________________________________________________________________________wicklund@intellistor.com (Tom Wicklund) (02/14/91)
In <AHUTTUNE.91Feb10005558@silver-surfer.hut.fi> ahuttune@niksula.hut.fi (Ari Juhani Huttunen) writes: >1) I don't think comma-operator is necessary and it should be thrown out of >the language. After that you could change multi-dimensional array referencing >to array[x,y,z];. (How can you implement multi-dimensional arrays of >your own classes using the current array[x][y][z] syntax? I suppose there >is a way, but I can't think of a good one.) Multidimensional arrays can be simulated now using the () operator, however I agree that the comma operator doesn't have a lot of use other than shorthands (e.g. within a -for-). The sequence point uses don't gain anything over separate statements (somebody correct me if I'm wrong here, it only matters in a GOOD optimizing compiler and I've yet to see one of those). >3) Complex number are a basic data type and should be included in the >language. There could well be data types such as complex int z, or >complex float z. Some examples of complex number constants: 1.5i2 that >means 1.5 + 2*i (i = imaginary), 0.5e-1i.45 . Is there really a use for "complex int" other than completeness? Personally I'd rather not build complex into the language. If there's a compelling reason for adding "complex" to the language, there's a more compelling reason to provide those missing features for any class. Probably the most compelling reason for a new built-in type is that one doesn't have to explicitly include the class definition. This is a general problem which compilers should be able to solve so that class "complex" can look completely like a new type. The other reason for built-in complex numbers is to improve support for constants (e.g. 1.5i2.0). While this is nice, I'd rather make it easier to use a syntax like (1.5,2.0). Adding special syntax for complex now lets me argue for adding a list or set syntax into the language so that I can write (1 2 (4 5) 8) to represent a set of integers 1, 2, 8 and the set (4 5). One of my personal tests for a language is whether it breaks its own rules. For example, when introduced to Pascal I was told all of the reasons why functions must not have a variable number of arguments. Then they introduced the Read and Write "functions" since I/O under Pascal's restrictions is too painful. C and C++ are good at letting me do anything the language can do. C++ has different rules for built-in types than classes which can be annoying (do I write using built-in types and lose features of classes or do I encapsulate built-in types within a class and suffer poor code generator quality. In general, I'd like to see C++ move toward making a user-defined "complex" class closer to a built-in type and move built-in types closer to classes.
mat@mole-end.UUCP (Mark A Terribile) (02/14/91)
> ... I see c++ as a successor to c and ... we will be using it for a long > time. [it must] be as good as possible and compatibility with c should not > prevent this. ... but should such (radical) changes be deemed necessary, > then compatibility with c should not prevent the changes. Yes, well, let's all deem together ... > 1) I don't think comma-operator is necessary and it should be thrown out of > the language. After that you could change multi-dimensional array referencing > to array[x,y,z];. (How can you implement multi-dimensional arrays of > your own classes using the current array[x][y][z] syntax? I suppose there > is a way, but I can't think of a good one.) Oh, I think it's necessary. for( i = 0, j = last, d = 0 ; j >= 0 ; i++, j--, d += w( k ) ) { : : if( . . . ) { : continue; } : : } If those three expressions in the increment-part of the for( ; ; ) are the essential part of the step from one pass of the loop to the next, and if you take the comma operator out of the language, you also take away the ability to use the continue . That puts us back in Pascal-Land, where I really don't want to be. I've written about Pascal's circumlocutions, wherein one branch of an if-then-else is devoted to the problem to be solved and the other branch is devoted to setting up flags that will cause the loop to terminate properly, and just writing about it is unpleasant. Actually writing it is worse. > 2) Array indexing such as int array[2..5]; should be possible. There would > not have to be runtime checking, but the capability to change the lower > bound is convenient in many situations. first(array) and last(array) would > return the lower and upper bound respectively. Hey, this is C++. Program it! (This will become a little neater when we get templates.) > 3) Complex number are a basic data type and should be included in the > language. There could well be data types such as complex int z, or > complex float z. Some examples of complex number constants: 1.5i2 that > means 1.5 + 2*i (i = imaginary), 0.5e-1i.45 . I recognize that complex numbers have been written for C++ about one and one half times for each C++ programmer, but ANSI could do a real service by calling for a good version and one without significant run-time penalty. -- (This man's opinions are his own.) From mole-end Mark Terribile
jimad@microsoft.UUCP (Jim ADCOCK) (02/16/91)
In article <1991Feb13.233418.26399@intellistor.com> wicklund@intellistor.com (Tom Wicklund) writes: >C and C++ are good at letting me do anything the language can do. C++ >has different rules for built-in types than classes which can be >annoying (do I write using built-in types and lose features of classes >or do I encapsulate built-in types within a class and suffer poor >code generator quality. I claim that poor code generation has more to do with today's compilers than the C++ language. The issues of C++ quality code generation is quite a bit different that C quality code generation, and compiler vendors haven't figured that out yet. Where the C++ language does have problems in generating quality code is in the poor control over aliasing, due in turn to pointer definitions that pre-date optimizing compilers. If the capabilities of references were expanded somewhat, people could avoid using pointers in the more common situations, and compilers could generate better code.
fuchs@t500e0.telematik.informatik.uni-karlsruhe.de (Harald Fuchs) (02/16/91)
mat@mole-end.UUCP (Mark A Terribile) writes: >I recognize that complex numbers have been written for C++ about one and one >half times for each C++ programmer, but ANSI could do a real service by > calling >for a good version and one without significant run-time penalty. ... and one without changing the language! -- Harald Fuchs <fuchs@tmipi4.telematik.informatik.uni-karlsruhe.de> <fuchs@telematik.informatik.uni-karlsruhe.dbp.de> *gulp*
dgil@pa.reuter.COM (Dave Gillett) (02/18/91)
In <1991Feb13.233418.26399@intellistor.com> wicklund@intellistor.com (Tom Wicklund) writes: >One of my personal tests for a language is whether it breaks its own >rules. For example, when introduced to Pascal I was told all of the >reasons why functions must not have a variable number of arguments. >Then they introduced the Read and Write "functions" since I/O under >Pascal's restrictions is too painful. >C and C++ are good at letting me do anything the language can do. I agree with Tom about this principle. That's why I can hardly wait for iterators. As it stands, "for" and "while" statements usually contain predicates, expressions which are evaluated on each pass where (usually!) the loop body makes some contextual change which affects the evaluation of the predicate. What I'd really like to do is pass predicates to methods on collection classes, without having to build predicate functions for them, and I can't do that in C; it sure looks (from what I've seen) like iterators are going to make the most common cases available in C++, and I'm glad. Dave
stephens@motcid.UUCP (Kurt Stephens) (02/19/91)
A class "wrapper" can be made around any built-in type quite easily.
(I have a macro that does this quite nicely; I will post if anyone
is interested. It will be even easier with templates.)
The ability to use non-classed built-in types is a benfit.
It allows easy migration from C to C++. It allows compilers to do
optimizations. And allows the programmer access to machine representations.
I don't want the C++ kernal to check bounds on every array
I dereference, when I know what I'm doing. (How do you force bounds
checking on a moving pointer? ;^) If I want an array with
defineable bounds and bounds checking, I'll make a class.
If I want to use complex numbers, I'll get a class library.
Most programs don't need complex numbers.
Making "complex" a class, and adding runtime array bounds
checking, etc. leads to a more complicated language.
(C++ is complicated enough ;^) Simple languages can be extended by
adding libraries and such, but once you have standardized a big, complicated
language, you can't go back. The simplicty and elegance of the
C language is what allowed it to be so popular with imbedded systems
with small processors. You can get a C compilier for any processor.
It's almost a portable assembly language, which the world has needed
for a long time. C++ is a great language to do OOPD. Let's not blow
it with featurecide and big run-time overheads.
Look at what happend to Common Lisp when too many people
got there fingers in the pie. It has redundant primatives and features
that most people would never use. (I'm not bashing lisp in general)
However, I do like the idea of standardized class libraries.
The NIHCL is good step in that direction.
--
Kurt A. Stephens Foo Foo::Foo(){return Foo();}
stephens@void.rtsg.mot.com "When in doubt, recurse."budd@mist.CS.ORST.EDU (Tim Budd) (03/02/91)
Notice that there is nothing to stop a programmer from creating a new class complex, and creating a global variable ``i'' defined as sqrt(-1), and overriding the arithmetic operators. Ignoring issues of memory management (which can also be addressed), creating a new complex number is then no more complicated then saying 3 + 4*i I don't think may people would complain about having to enter the additional symbol ``*'', at least not after the third or 4th time they made the mistake of leaving it out. So I don't see a whole lot of sense in making complex numbers part of the language.