From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,4873305131bf4d94 X-Google-Attributes: gid103376,public X-Google-Thread: 109fba,4873305131bf4d94 X-Google-Attributes: gid109fba,public X-Google-Thread: 1014db,4873305131bf4d94 X-Google-Attributes: gid1014db,public From: kaz@helios.crest.nt.com (Kaz Kylheku) Subject: Re: Porting Experiences (was Ada and Pascal etc ) Date: 1997/11/04 Message-ID: <63p0u1$uvm$1@helios.crest.nt.com>#1/1 X-Deja-AN: 287114807 References: <34557f2b.1934172@news.mindspring.com> <345E3ACD.A15@gsg.eds.com> <63mcmm$r3s$1@helios.crest.nt.com> <345F95D0.3984@gsg.eds.com> Organization: A poorly-installed InterNetNews site Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++ Date: 1997-11-04T00:00:00+00:00 List-Id: In article <345F95D0.3984@gsg.eds.com>, Shmuel (Seymour J.) Metz wrote: >Kaz Kylheku wrote: >> >> That depends on how you look at it. I'd say that it requires a little >> more thought and skill to write portably with types that have sizes >> that are not fully specified, but it's not impossible. >> >> C gives you a header, , which gives you the constants LONG_MIN >> and LONG_MAX. These tell you what the implementation's least and >> greatest values of type long are. These values are guaranteed to be >> at least -2^31+1 and 2^31-1 respectively. >> >> If you assume that the long type has a range that is no larger than this, >> you are OK. If you write your code under the assumption that the >> range is LONG_MIN to LONG_MAX, you are also OK. >> >> Sure, you might not be able to declare subtypes with more restricted ranges >> like in Ada, but that doesn't mean that portability has gone out the window! > >So the portable way to declare 33-bit integers is to declare them as There is no portable way to declare 33 bit integers. The current ISO standard only guarantees 32 bits for the largest integral types that C offers. >long and let them be 128 bits on some machines? I don't consider that a >viable option. Why not? It might not be the _cleanest_ option, but it's certainly viable. >To restate, there is no portable way to cause the >compiler to chose a size that is the best compromise between the problem >requirements and the natural byte sizes of the machine. Sure there is. Say we are talking about a signed quantity. You first identify the range that it shall require. If it is within -127 to 127, you may use a char type---IF it is important for you to save storage. Otherwise you use int. If the range is within -32767 to 32767, you use a short if saving storage is important. Otherwise you use int. If the range is outside -32767 to 32767 but within -2^32+1 to 2^32-1, you use the type long. Otherwise if you require a larger range, you are out of luck. To stay within the limits of strictly conforing C, you must emulate some higher precision arithmetic. So you see, it is quite easy to choose the appropriate type for a given range with just a few simple guidelines. Of course, it's probably a good idea to insulate yourself using typedef alias names in case your requirements change in the future. >In Ada I give a range of values and the compiler figures out whether to >use, e.g., words, half words or double words. In PL/I I give a number of How do you express the idea that storage is to be minimized? Just because your type requires only the range -50 to +50 doesn't necessarily mean that you want to pack it into a single byte! Or perhaps you _do_ want to pack it into a single byte. >bits (for binary) or a number of digits (for decimal) and the compiler The people who invented UNIX and C were no strangers to PL/I. :) Multics was written in it. You know where those /* */ comments come from. >figures it out. In C I have to play games with, e.g., multiple versions >of my headers. Unless and until the new standard passes, this aspect of You don't need to do any such thing if you understand the language. I've never had to play with multiple versions of a header or #ifdef nests. I have seen plenty of code that does just that. In each case, it was because the author hadn't learned to use the language properly. >C will remain a serious blot on the claims of portability. This simply isn't true. There may be blots on that claim, but this isn't one of them. It's an imagined problem that perhaps stems from your inexperience with that particular language. -- "In My Egotistical Opinion, most people's C programs should be indented six feet downward and covered with dirt." -- Blair P. Houghton