This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Big-endian Gcc on Intel IA32



On Wed, 19 Dec 2001, Bernard Dautrevaux wrote:
> >
> > (To the person suggesting how to do it in C++ - you _can_ get a subset of
> > this in C by the above "embed in a structure" trick).
>
> Just can't resist comment on this. In fact in C++ you can do a lot more; you
> can also define all the needed and meaningful operators on this type, so
> that you may, for example, add or subtract an int from it, but not add two
> of these or multiply them.

Agreed. And to do the same in C you need to start actually adding
syntactic elements, ie you can't just overload the "+" operator, you have
to manually add "my_add(a,b)".

The basic point I wanted to make was, however, the ease of retrofitting
and tracking (and, potentially fixing) existing code that depends on some
special "attribute". It gets even worse if you have multiple independent
attributes that can potentially be mixed (ie same type of element, but
different restrictions on the element).

It doesn't have to be in the compiler, of course. There are off-line tools
(both free and commercial) to track semantics, eg code viewers etc that
are able to track the flow of data through the system. And maybe that is
fundamentally the right approach.

Having a way of tagging data structures and getting the compiler to check
them statically at compile-time is historically useful, though. That is,
after all, exactly what function prototypes are - a "tag" on the function
that specifies what kinds of arguments it accepts (and one that you cannot
remove without quite explicit casting).

		Linus


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]