XC Best practices - When XC won't cut it

[Folknology]

Ok I'm not trying to start a XC vs C flame war here, rather I am trying to seek some constructive criticism to the following premise:

Would it be safe to assume that the only real need to drop down into C from XC would be pointer manipulation?

Having examined lots of the sample code and embarked on a best design practice exercise for XC, I have some valid reasons for asking.

Feedback and experiences please.
regards
Al

[rp181]

I have been using C instead of XC for calculation intensive stuff (for float support). Also good to use existing libraries. I generally try to have the XC program a launcher that starts C programs, unless it uses IO.

[Jamie]

Ok I'm not trying to start a XC vs C flame war here, rather I am trying to seek some constructive criticism to the following premise:
Quote:
Would it be safe to assume that the only real need to drop down into C from XC would be pointer manipulation?

Having examined lots of the sample code and embarked on a best design practice exercise for XC, I have some valid reasons for asking.

I'm not an expert on this but as far as I understand C is an inherently unsafe language because of its poorly defined semantics. This is related to issues such of the use of pointers. Although XC is based on C, it has omitted many unsafe features in an attempt to provide better defined semantics and a more secure language. For instance, a strong typing system helps compile-time thread disjointness checks to be performed. By 'dropping down' into C you would just be circumventing this security and potentially introducing more problems into your program. I guess if you really had to, you could use inline assembly to access lower-level functions of the hardware.