On Sat, 11 Oct 2008, Wouter van Ooijen wrote:

> >> for( member = 0; member < 3; member++ )
> >>     s.member = 0; // or s[member] = 0;
> > 
> > Correct, you cannot do this currently with C but there is ABSOLUTELY 
> > nothing to stop the language from evolving to be able to do it. It would 
> > not be hard to implement and the runtime overhead would be fairly small.
> 
> Sergio, you think implementation only. That's not where the problem is.
> 
> Accessing a run-time-calculated structure member would yield an address,
> no problem, but the type of the data found there would depend on the
> run-time calculation, so it would be impossible to do traditional
> compile-time type checking. That's why no compiled strongly typed
> language has this feature. Note that weakly typed (often interpreted) 
> languages can have a construct like this (and more): the Python 
> dictionary for instance stores any type of value, indexed by any type value.

There are many instances where compile time type checking is useful and 
many instances where the programmer beats it over the head with a rock. 
Providing a cleaner mechanism in which the compiler can at least play some 
usefull role must be a good thing.

In this case I belive that there would be an overall gain in letting the 
compiler help rather than having a programmer trying to do the job 
him/herself with pointers and casts.

The feature I describe would require that the compiler build a special 
table for each defined structure (not instance mind you) IF AND ONLY IF 
that structure is accessed using a non-constant member name. The special 
table could easily contain (amoungst other things) "get" and "set" methods 
for each member. Yes this sounds non-trivial but it would result in much 
more optimised code than if the programmer were to implement it 
him/herself.

I understand what you are saying about the "Python dictionary" but that 
needs to deal with dynamic structures. Extending C would involve using the 
existing C static structure mechanism meaning that the C compiler would be 
able to do a lot of compile time "pre-processing" (or pre-conversion) with 
little work left to be done at run time. It would be no worse than code 
written by a programmer and in many cases much better because the compiler 
could check for all the cases requiring conversion and only build the code 
specifically required. Consider how C++ deals with overloaded 'get' and 
'set' methods (for int, float, char *, etc.) It does not need to generate 
complex run time code to determin which function to call because it knows 
the type of the argument at compile time. Similarly it would know the type 
of assignment or value required (int, float, char *, etc) at compile time. 
The only problem would be that some types of conversion would be invalid 
and would need to be trapped at run time (still very little overhead). But 
this would be no worse than other run time errors for which the user does 
not bother guarding against (such as divide by 0, index outside array, 
invalid memory pointer, floating point NaNs etc).

Regards
Sergio Masci
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist