Re: code portability

On 2006-08-04, Ian Collins <ian-news@xxxxxxxxxxx> wrote:
Andrew Poelstra wrote:
On 2006-08-03, Keith Thompson <kst-u@xxxxxxx> wrote:

Richard Heathfield <invalid@xxxxxxxxxxxxxxx> writes:

The introduction of long long int was, in my continued opinion, a mistake.
All the ISO guys had to do was - nothing at all! Any implementation that
wanted to support 64-bit integers could simply have made long int rather
longer than before - such a system would have continued to be fully
conforming to C90. And if it broke code, well, so what? Any code that
wrongly assumes long int is precisely 32 bits is already broken, and needs
fixing.

That's true, but 64 bits is the effective limit for this. The
following:
char 8 bits
short 16 bits
int 32 bits
long 64 bits
is a reasonable set of types, but if you go beyond that to 128 bits,
you're going to have to leave gaps (for example, there might not be
any 16-bit integer type).



1) This isn't really a problem; you can use a 32-bit variable to store
16-bit values; if you really need 16 bits you might need some debug
macros to artificially constrain the range.

Just beware of overflows!


Yes, that would require more than debug macros to fix, since you'd want
the overflow behavior to be the same whether or not you are debugging!
(It's a bit of a pain, I admit, but there aren't too many times when you
absolutely need an exact number of bits.)

2) If you've got a 128-bit processor, IMHO, you shouldn't be insisting
on using 8-bit types. That just sounds inefficient. [OT]

Unless your (possibly externally imposed) data happens to be 8 bit.


If I were ISO, I'd consider adding a new specifier to scanf and friends
to read a specified number of bytes (or probably bits, although that
could be a lot harder to implement) into an already defined type. So, if
you wanted to read 8 bits into an int (which is 32 bits on this particular
system), you'd do:
fscanf (fhandle, "%d8b", &charvar);

Since I'm not ISO, nor will they create such a change, I'd stick to
avoiding arbitrary data widths (in general, stick with text files as
long as you can spare the space), and don't worry about changing data
widths: most companies don't switch compilers too often.

If you have Data of a Certain Width imposed on you, you're probably
going to have to fiddle with stuff when changing compilers anyway,
so suddenly having long twice as wide should be an expected problem.

--
Andrew Poelstra <http://www.wpsoftware.net/projects>
To reach me by email, use `apoelstra' at the above domain.
"Do BOTH ends of the cable need to be plugged in?" -Anon.
.

Relevant Pages

  • Re: All programs are undefined, Re: Why this works???
    ... terms of the capabilities of a particular machine about whose details ISO ... void printat(const char *s, int x, int y, int bg, int fg) ... If this technique were not well-defined under the above circumstances, ... these programs were able to rely on the well-definedness of this technique ...
    (comp.lang.c)
  • Re: Number of weeks in year?
    ... >produce results incompatible with ISO 8601" ... >private int WeekNumber_Entire4DayWeekRule ... > StartWeekDayOfYear = StartWeekDayOfYear; ... > EndWeekDayOfYear = EndWeekDayOfYear; ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Garbage Collection - Stop Making Trash
    ... > as soon as the ECMA standard is ratified, it will be submitted to ISO. ... int main ... pointer, it cannot be moved by the GC and will not be garbage collected. ...
    (comp.lang.cpp)
  • Re: VS2005 doesnt like its own suggestions
    ... But first, about BOOL, INT etc. ... ISO C++ can stay the same and so could int and long. ... The non-morbid reasons, which I lean to believe are the prevalent ...
    (microsoft.public.vc.language)