oesterle@wpi.wpi.edu (Shawn H. Oesterle) (03/21/90)
The following C data types have incremental sizes of 2^n bytes:
(unsigned) char, short, and long. Some compilers have data type
called 'long long' which is 64 bits long. If 128 bit computers
begin to emerge (if not already), we may have what is called a
"long long long", and for 256-bit computers, a "long long long
long", ad infinitum (maybe just have a "very long"). Where do we
stop? It would be nice to have a user definable size for a
numerical type. Suppose we call it 'maketype' where the size it
is a multiple of 8-bit data types the quantity has.
Defining the size of 'maketype' could take place by using the
sizeof keyword as the lvalue. For example:
void function(maketype mSomewhatBig) {
/* mTemporary is an integer value of an undefined size */
maketype mTemporary;
/* using a modified version of sizeof, mTemporary is
assigned the size of mSomewhatBig, which has previously
been given a definite size */
sizeof(mTemproary) = sizeof(mSomewhatBig);
.
.
.
}
In this example, it is clear that sizeof(maketype) could be
unknown at compile time:
void func2(int iNumber) {
maketype mTemp;
sizeof(mTemp) = iNumber;
.
.
.
}
The advantages of a user definable size for a data type would
make a particular algorithm less restrictive to a particular data
type size (The problem I am facing and why I am making all this
up in the first place). So in accordance with my hardly thought
out previous notion on the implementation of 'makesize' we have
following algorithm in a 'maketype' way:
/* compute the factorial of number x */
unsigned maketype factorial(unsigned maketype x) {
unsigned maketype tmp=1; /* temporary result */
unsigned maketype i; /* index */
/* the size for 'i' is defined to be equal to the size of 'x' */
sizeof(i) = sizeof(x);
for(i=1; i<=x; i++) {
tmp *= i;
}
return(tmp);
}
Do any programming languages have this ability?
--
/^\
"ne zorgas, estu fali<ca!" <- * -> Shawn Oesterle
\_/ oesterle@wpi.wpi.edukarl@haddock.ima.isc.com (Karl Heuer) (03/22/90)
In article <9918@wpi.wpi.edu> oesterle@wpi.wpi.edu (Shawn H. Oesterle) writes: >The following C data types have incremental sizes of 2^n bytes: >(unsigned) char, short, and long. On most implementations. >It would be nice to have a user definable size for a numerical type... I see three separate issues in your article. (a) If the hardware supports a lot of different sizes of integer, it could be nice to have a way to specify an explicit size instead of having to choose one of the keywords. One might use an extension of the bitfield syntax and write "int foo:64;" for this. Probably a bad idea, since bitfields are a hack anyway and since one usually doesn't want a particular bit-size. Subranges a la Pascal might be a better choice. > void function(maketype mSomewhatBig) { > maketype mTemporary; > sizeof(mTemporary) = sizeof(mSomewhatBig); > ... (b) It is sometimes useful to declare one object to be "the same type" as an existing one, when the name of that type is not readily available. But assigning to sizeof() makes my teeth hurt. Assuming mSomewhatBig has a known type at compile-time, a much simpler method is to use gcc's "typeof" keyword (a non-Standard extension): "typeof(mSomewhatBig) mTemporary;" > void func2(int iNumber) { > maketype mTemp; > sizeof(mTemp) = iNumber; > ... (c) Sometimes the type is not known at compile-time. (This may have also been your intent in the earlier example--did you intend it to allow an arbitrary integral type as parameter, i.e. a generic function?) The current example is even harder to implement: how do you generate code for "++mTemp" if you don't know the type of mTemp at compile time? You could keep the size information around at run time and switch on it, I guess. Or you could just implement BigNums as in some implementations of Lisp, in which case you don't even have to bother with assigning to sizeof(). (Just let the number grow on demand.) >So in accordance with my hardly thought out previous notion on the >implementation of 'makesize' we have following algorithm in a 'maketype' way: > /* compute the factorial of number x */ > unsigned maketype factorial(unsigned maketype x) { > unsigned maketype tmp=1; /* temporary result */ > unsigned maketype i; /* index */ > sizeof(i) = sizeof(x); > for(i=1; i<=x; i++) tmp *= i; > return(tmp); > } >Do any programming languages have this ability? If I correctly understand what you want, you could do this in C++. I assume that the failure to assign sizeof(tmp) means that you really want it to be a BigNum, and that you want factorial() to be an overloaded function so you can call it with different types. (Useless in this example, actually: you might as well have i and x be ints, since you won't be able to compute really huge factorials anyway.) You could do this in C++. >"ne zorgas, estu fali<ca!" XX X That should be "ne zorgu, estu feli<ca!", or simply "ne zorgu, feli<cu!". (Also, "^c" or "cx" is generally preferred rather than "<c".) Karl W. Z. Heuer (karl@ima.ima.isc.com or harvard!ima!karl), The Walking Lint
news@awdprime.UUCP (USENET News) (03/23/90)
In article <9918@wpi.wpi.edu> oesterle@wpi.wpi.edu (Shawn H. Oesterle) writes: >The following C data types have incremental sizes of 2^n bytes: >(unsigned) char, short, and long. Some compilers have data type Actually, it doesn't say anywhere that a short cannot be the same size as a long, additionally a long could very well be 128 bits (or whatever the size supported by the hardware is). Quoting from K&R2 (2.2 Data Types and Sizes): The intent is that short and long should provide different lengths of integers where practical; int will normally be the natural size for a particular machine. ... Each complier is free to choose appropriate sizes for its own hardware, subject only to the restriction that shorts and ints are at least 16 bits, longs are at least 32 bits, and short is no longer than int, which is no longer than long. >called 'long long' which is 64 bits long. If 128 bit computers true, some people have added 'long long'. In cases where you wanted to maximize precision (and have portable code) you would have to figure out the range (from standard headers or by computation) of the data type and make your function smart enough to use those values at run time. -- sanders For every message of the day, a new improved message will arise to overcome it. Reply-To: cs.utexas.edu!ibmaus!auschs!sanders.austin.ibm.com!sanders (ugh!)