Re: range vs precisionC

"jacob navia" <jacob@xxxxxxxxxxxxxxxx> wrote in message
news:444369af$0$29196$8fcfb975@xxxxxxxxxxxxxxxxxx

P.J. Plauger a écrit :

Well, it kinda does now. TR18037 (Embedded C) defines a well thought
out addition to C for fixed point arithmetic. It'll be included in
our next release, though only the EDG front end supports the language
part. It's intended primarily for DSPs, but it's generally useful.

After reading that proposal, I was struck by the fact that since quite a
long time we are turning around the problem of defining SUBTYPES for the
language.

Consider this:

int a;

and

volatile int a;

The second is a SUBTYPE of integer, i.e. an integer with special
characteristics, in this case that is volatile.

const and volatile are more in the line of *access qualifiers*. Once
you extract the r-value, an int is an int. (In this sense, access
qualifiers are partway toward storage class specifiers like static
and register.)

In the same manner, fixed point could be understood as a subtype of
double/float, etc, where the implementation changes.

Uh, no it's not. Except possibly in the broad sense that integers are
a special case of floating-point. But that viewpoint doesn't win you
much.

This is even more obvious when further down in the proposal there is the
definition of address spaces, and we have declarations like:

_X char a,b,c;

(page 38)

This declaration means that the characters a,b, and c are stored in an
address space named _X.

Yep. Technology like that has been kicking around for decades.

Recently, Microsoft decided to standardize the different __declspec(foo)
declarations that sprinkle the windows headers, and decided to adopt a
standard annotation system for declaring variables. At the same time, gcc
has its __attribute__ construct that does the same thing .

What is needed now, I think, is to realize that subtypes (and all those ad
hoc implementations) are a real NEED for the language, and that we should
try to address THIS problem rather than defining a new ad hoc solution for
each specific need. What is needed is a general syntax that allows
compiler to ignore subtype specifications when not supported but would
allow standadization of annotations so that they would be compatible, in
the sense that

#pragma

is used.

Proposals are always welcome.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com


.

Relevant Pages

  • Re: Why is this not an error in Visual C?
    ... says that when an old-style function definition is processed, ... That is, I think, `int fint x; ... Concerning the compatibility of function ... All declarations in the same scope that refer to the same object or function ...
    (comp.lang.c)
  • Re: Why is this not an error in Visual C?
    ... int foo ... What we're looking for to describe MSVC as broken is a constraint ... involve declarations of incompatible types. ... compatibility and of a composite type, ...
    (comp.lang.c)
  • Re: Why is this not an error in Visual C?
    ... says that when an old-style function definition is processed, ... That is, I think, `int fint x; ... Concerning the compatibility of function ... All declarations in the same scope that refer to the same object or function ...
    (comp.lang.c)
  • Re: cooking the spaghetti
    ... I find your code layout to be jarring. ...     int main ... latter is probably a throwback to K&R C, where parameter declarations ... int main{ ...
    (comp.lang.c)
  • Re: PEP 358 and operations on bytes
    ... sequences of int, and for various array.array subtypes? ... regexps work on byte arrays. ...
    (comp.lang.python)