ahuttune@niksula.hut.fi (Ari Juhani Huttunen) (02/15/91)
In article <1991Feb13.233418.26399@intellistor.com> wicklund@intellistor.com (Tom Wicklund) writes: >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). Array dimensioning using array(x,y,z) isn`t very NATURAL. Because if it were, we wouldn't perhaps need operators [] at all. Furthermore, I'm assuming that most instances of arrays will in the future be replaced by some (standard) library array-classes that could be associative etc. These at least should use array[x][y], if possible. If that is not possible, THEN I think a syntax change should be made. ( A change to array[x,y]. ) Another alternative is, of course, to allow a new operator for classes: class Example { int operator[][] (int x, int y); }; On second thought, perhaps this is the better alternative. As for the use of ',' in for loops, a special construct could be permitted. I.e. for( , , , ; , , , ; , , ,) that is equivalent to current usage. If you look at things closely, `,` doesn`t mean sequential evaluation in every context even now. The function calling and evaluation is one example, the other is initialization of 'int x,y,z;'. Surely this last command does not mean: first make 'int x', then evaluate command 'y', then evaluate 'z'. >Is there really a use for "complex int" other than completeness? Perhaps not. I withdraw this suggestion. >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. I agree that built-in and user-defined classes should behave similarly. If this means you should be able to say class RestrictedInt : public int { .... }; I wouldn't object. There is perhaps no need for this, but if everything behaves according to the same rules, you don't have to memorize so many 'exceptions to the rule'. -- ___ ___ ___ ___ ___ ___ ___ ___ ___ ___ ___ ___ ___ ___ ___ ___ 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. _______________________________________________________________________________