> > a "race" condition is something very important indeed.
> 
> A race appears when an exception is thrown and interrupts are 
> on, if there is more than one path to the exception handler 
> and/or there are unguarded 
> variables used by the throw mechanism. There is no inherent 
> mechanism in the try/throw/catch paradigm that guarantees it 
> to work other than in a single threaded environment.

I don't understand that. There is nothing in the t/t/c mechnism either
that prevents working in a multi-threaded environment. 

> Either 
> that or the task must be fully reentrant and that requires a 
> full stack frame of usually large size. Afaik no such thing exists 
> on PICs (excepting on the largest ones).

I don't see a problem on 12-bit, larger 14-bit, or 16-bit cores. And who
said this discussion was exclusively about PICs anyway?


> > Ever programmed in a language that had exception handling, so you 
> > could appreciate it?
> 
> Yes, C++ and a little of others. But I did not feel like abusing it.

It sounds like in your idea abusing == using. At least you have
experience with a language that has execptions, but I'd give your
opinion more weight if you had actualyy used exceptions for a year or so
and then decided it was not a good concept.

> C++ allows full virtual methods as you know. These need to be 

allows yes, but you are not forced to use them unless you want to use a
construct that is not available in C. so if you just want what can be
done in C there is no added disadvantage in C++.

> C++ instantiated at
> runtime i.e. a good part of the linker must be compiled into 
> the program.

Bullocks. virtual functions can be implemented by a single VFT per
class, a pointer to this VFT in each instance, and an extra indirection
for each (virtual!) function call. The linker need not be aware of this
at all.

> And 
> it has to be fully reentrant and thread-safe in an 
> interrupted environment with no memory protection.

What has to be "fully reentrant and thread safe"? 

> I think that C++ excels precisely at what is 'forbidden' on 
> micros due to limited resources. Other than that, you are 
> right. So basically you's use C++ without most convenient C++ 
> features. Whatever is good for you.

As an example: classes with non-virtual member functions add zero
overhead.

And what is limited? The smallest LPC ARM (LPC2101) costs 1.96 (Digikey
@ 100). It has 1k RAM and 8k FLASH (or better: 2k ARM instructions or 4k
Thumb instructions). That is plenty for a small program using a lot of
C++ features. I don't say that is always a wise way to do things, but
when development cost outweights unit cost it might well be.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: www.voti.nl/hvu
 
 

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