Re: 32 or 64 bit processor info in C


"Ian Collins" <ian-news@xxxxxxxxxxx> wrote in message news:58tgpjF2i6eqtU29@xxxxxxxxxxxxxxxxxxxxx
Richard Heathfield wrote:
Ian Collins said:

When ever C hits the real world, developers have added fixed size
types.
Now they are standardised. Good.

Whenever language designers specify fixed size types, they have to come
back later and specify some more. Bad.

If don't specify the type, everyone else who wants it has to add their
own, so we ended up with typedefs like U8, INT16 and just about every
other possible naming of fixed types. At least the standard now sets a
naming convention.

People should be taught that it is almost never necessary to write code like this.

Data is almost always either real numbers, strings, booleans, enumerated symbols, or indices into arrays (technically a subset of keys). So double or float, char *, and int should be basically all you need.
Almost always isn't alway always, and just occasionally you need an integer of a different type. But it is very occasionally.

A cynic like me might argue that once you admit the size_t and ptrdif_t gibberish into you code it is unreadable anyway and more gibberish won't make any difference.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

.

Relevant Pages

  • Re: 32 or 64 bit processor info in C
    ... Whenever language designers specify fixed size types, ... At least the standard now sets a ... naming convention. ...
    (comp.lang.c)
  • Re: 32 or 64 bit processor info in C
    ... Whenever language designers specify fixed size types, ... At least the standard now sets ... a naming convention. ...
    (comp.lang.c)
  • Re: 32 or 64 bit processor info in C
    ... Whenever language designers specify fixed size types, ... At least the standard now sets a ... naming convention. ...
    (comp.lang.c)
  • Re: Buffer overflows and asctime()
    ... struct tm members to be within their valid ranges is up to an user of ... There is no valid range for the year as specified in the standard. ... I wouldn't call it a defect, because the existence of a limit beyond which asctime() cannot be safely used is inferable from the description of asctime. ... I would consider it a substantial improvement for the standard to explicitly specify the limit. ...
    (comp.std.c)
  • Re: [fitsbits] Comments on image distortion conventions
    ... The document should specify default values for any coefficients that are absent from the header, but might be expected based upon the value of A_ORDER or B_ORDER. ... Presumably either the values would be taken to be zero or the convention should require that all keywords be present. ... The convention would appear to mis-use the CTYPEi reserved keyword in a way that at least technically violates the FITS standard. ... of including distortion in the pixel world coordinate transformation directly. ...
    (sci.astro.fits)