Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!elroy.jpl.nasa.gov!swrinde!zaphod.mps.ohio-state.edu!ub!csn!arrayb!wicklund From: wicklund@intellistor.com (Tom Wicklund) Newsgroups: comp.lang.c++ Subject: Re: complex float z = 1.0i2.2; Message-ID: <1991Feb13.233418.26399@intellistor.com> Date: 13 Feb 91 23:34:18 GMT References: Distribution: comp Organization: Intellistor Lines: 53 In 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.