Thread View: comp.std.c++
2 messages
2 total messages
Started by Rod Burman
Wed, 06 Jan 1993 17:30
Extra COntant definitions
Author: Rod Burman
Date: Wed, 06 Jan 1993 17:30
Date: Wed, 06 Jan 1993 17:30
49 lines
2103 bytes
2103 bytes
It has just occured to me that since C++ is a strongly typed language it should provide intrinsic support for constants of all intrinsic types that is currently we have: 1 // int 1U // unsigned int 1L // long 1UL // unsigned long '\1' // unsigned char -- it is unsigned since only // octal and hex bit patterns are allowed and // by default they are unsigned -- this may be // shakey logic, it may be implimentation dependent // on whether char is signed/unsigned, I admit '\1'L // wide unsigned char -- see above comment "\1" // unsigned char[] "\1"L // unsigned wide char -- w_chart is scheduled to // be an intrinsic type in ANSI/ISO C++ This as I see it leaves room for: 1S // short 1US // unsigned short 1I // int -- this may not be really neccessary! 1UI // unsigned int '\1'S // signed char -- see I'm following the spirit of C // and confusing programmers nicely by using S for both // short and signed! '\1'U // unsigned char '\1'SL // signed wide char '\1'UL // unsigned wide char "\1"S // signed char[] "\1"U // unsigned char[] "\1"SL // signed wide char[] "\1"UL // unsigned wide cahr[] Ofcourse you can always have: (short) 1; // etc and this may be more portable since you can then have: (int16) 1; // etc where you typedef int16, etc to the correct type in some header somewhere which takes care of compiler/OS/machine dependecies, but shouldn't you be able to do the other way if you want? (Can any one send me the appropriate #define macro to convert 1INT32; to 1L or 1 depending on wether long is 32 or 64 bits?) Well just a though for the standards committee after all it shouldn't break any existing code should it?
Re: Extra COntant definitions
Author: Steve Clamage
Date: Thu, 07 Jan 1993 17:25
Date: Thu, 07 Jan 1993 17:25
85 lines
3177 bytes
3177 bytes
rodb@racerx.bridge.COM (Rod Burman) writes: >It has just occured to me that since C++ is a strongly typed language >it should provide intrinsic support for constants of all intrinsic types >that is currently we have: > 1 // int > 1U // unsigned int > 1L // long > 1UL // unsigned long OK so far. > '\1' // unsigned char ... No. This has type "char", a type distinct from both "signed char" and "unsigned char". It will usually have the same implementation as either signed or unsigned char, you are not allowed to assume which. Similarly, type int usually has the same implementation as either type short or type long, but is always a type distinct from both. Not all current C++ implementations have the required three character types. > '\1'L // wide unsigned char ... No. It will have whatever type the implementation chose for wide characters, and may be any signed or unsigned integral type. There is no "signed wide character" or "unsigned wide character" type, just plain "wide character", which may behave as either a signed or an unsigned type. > "\1" // unsigned char[] > "\1"L // unsigned wide char ... No to both. See above. >This as I see it leaves room for: > 1S // short > 1US // unsigned short ... etc. >Ofcourse you can always have: > (short) 1; // etc >and this may be more portable ... Well, I would say it is more general, rather than more portable. You could make a symmetry argument for the additional suffixes, but I don't see that they solve any problem. Although this would not break any existing code, it might create readability problems. For example, I don't like using the lower-case 'l' suffix, since 2l looks too much like 21. Similarly, some type faces make 'S' or 's' hard to distinguish at a glance from a '5', particularly when you are not expecting to see the letter 's'. Whenever a short value appears in an expression it is immediately promoted to type int. For example, let XX stand for any integer literal representable as a short, and XXs be that value with type short as you request. Let Z be a value of any scalar type. Then the three expressions XX + Z (short)XX + Z XXs + Z must always have exactly the same effect. The 's' suffix does not allow the compiler to take any shortcuts it could not take without the suffix. (The suffix can only be applied to a literal, so the compiler already knows whether the value is representable as a short.) The only place a "short" suffix could make a difference is in choosing an overloaded function: int foo(int); int foo(short); ... foo(XX) // calls foo(int) foo(XXs) // calls foo(short) Of course, we can always write foo((short)XX) // calls foo(short) for the rare cases when this arises. -- Steve Clamage, TauMetric Corp, steve@taumet.com
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads