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?

Only peripherally related to the main point of this thread but:

 I know (hope?) that that comment was included for its provocative value
rather than being intended asa racist / jest plain iggerant comment. To
characterise those whose languages require, for whatever reason, more than 8
binary bits to represent them as
- illiterate
- far away (and thus by implication unimportant)
- jungle (savage/ unworthy ...)

is rather closer to ad hominem attacj than useful comment. I'm not overly
into PC stuff (nothing to do with IBM)(& despite impressions formed to the
contrary by some :-)) BUT you risk rejecting an awful lot of people and
knowledge and usefulness and more if you genuinely suggest sticking to 8
bits because the mother tongue jest happens to manage OK with that many, or
even less. (If you can't express it in Baudot it's not worth saying? :-)
)(Or Ogham). Sure, needing to use extra bits to accomodate material that you
have no interest in is a pain, but largely not a major problem with modern
systems * except in systems so small that they can probably afford to not
deal with such codes. (* Nobody should ever need more trhan 640 kB of
memory**).


    Russell

** Claims to the contrary notwithstanding, Gates denies ever having said it.









2009/7/15 Olin Lathrop <olin_piclist@embedinc.com>

> 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
>
>
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist