Gerhard Fiedler wrote:
> I resisted the temptation to quote all the stuff again... :)

It really has been confusing trying to figure out what exactly your point
is.

> Not quite. Firstly, I was talking about /standard/ libraries, where the
> compiler also "knows" what the functions are supposed to do (because
> it's defined in the same place where is defined what the compiler itself
> is supposed to do).

But that's exactly what intrinsic functions are, which you strongly claimed
you weren't talking about when I suggested that's what you might mean.  Now
I am (and I think Sergio too) really confused.  How is what you mean not
intrinsic functions?

> I agree that the lack of a built-in decent string type in C can be a
> pain, especially in terms of syntax. OTOH, I bet your strings are 8-bit
> strings. Now what if I need to handle Unicode strings?

Tell your customers to use ASCII like civilized people ;-)

> Wait for a
> compiler upgrade? And what if that compiler upgrade doesn't handle the
> Unicode encoding I need?

Note that you're no worse off if it doesn't support the character
representation you like.  The reverse can also be a pain, like Java where
everything is one of those unicode thingies.  Maybe that's nice if you want
to appease some illiterate in a distance jungle somewhere, but it's a hassle
if you want to send a stream of 8 bit characters to a microcontroller.  And
now even 65K glyphs are apparently not enough.  Is this nonsense ever going
to end?

>> And we even got rid of the huge printf library as a side effect.
>
> If that's a concern, HiTech for example parses all printf strings in the
> whole application and based on that decides what to include into printf.

There are usually several ways around a single problem, but I'm not sure
what exactly your point is here.

> Since printf is a /standard/ library function, they can do this -- and I
> still can override theirs with mine, or make theirs work with my own
> putch function. I don't know how exactly they do it, but it doesn't
> really matter whether they have a bunch of configuration parameters for
> a printf library function and the compiler sets the configuration
> parameters accordingly, or whether their printf function is implemented
> in the compiler itself. It doesn't matter because it's a standard
> library, and as long as their compiler behaves accordingly (and lets me
> override their function with my own if I want), it's all fine.

So it sounds like you want a bunch of intrinsic functions (which represent a
large amount of compiler work), but have any optimization defeated and your
own function called if you define one?

> It's the number of symbols and their structure that makes a feature set
> "over inflated". IMO it doesn't make a difference whether you have 5000
> symbols in a library and people think it's too much or whether you have
> 5000 symbols in a compiler and people think it's too much.

I think part of the point is that certain features, like the string handling
Sergio described, require a lot less special syntax when built in than they
would require special functions if "built in" that way.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist