On Wed, Jul 15, 2009 at 4:14 AM, Gerhard Fiedler <lists@connectionbrazil.com
> wrote:

> 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).


Now I completely lost. Are you saying that a C compiler recognizes specific
function calls like printf and when you write printf("hello %s", "world");
it realizes that a puts("hello world"); would be much cheaper as part of the
optimization? Or you are talking about intrinsic functions within the
library where it still uses the printf function but makes all the code
optimizations as the library function was written in the place where it was
called from?


> > if strings were built into the language we might instead write:
> >
> >       str = "hello world" + string(j)
>
> See, in C++ for example, strings are /not/ built into the language, and
> you can write pretty much exactly this. (Not with the std::string, but
> if you extend it a bit, you can, so in the case of C++ it's not really a
> question whether or not it can be done with strings in a library but
> whether the library definition is sufficient.)


That's because of the operator '+' can be overloaded in a string type
object. In laguages like Pascal the string has a different structure than in
the ANSI C, so you have the actual length of the string at the very
beginning of the string  buffer (it is like a minimalistic buffer header).
That makes it possible to implement string manipulations faster and easier
-- therefore a string concatenation is an easy task by language definition.



> 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? Wait for a
> compiler upgrade? And what if that compiler upgrade doesn't handle the
> Unicode encoding I need?


I agree with you that in C++ they put these things in a way that it can be
extended easily -- especially if the string was handled by STL. In the other
hand on an x86 PC on the compiler side they only needed to change minor
things, like replacing "rep movsb"  to "rep movsw" and problem solved --
while in C++ these things are function calls to the overloaded functions
from the string class.



> 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.
> Since printf is a /standard/ library function, they can do this -- and I


I think that's a normal dead code elimination -- which you can do that with
either unused object code within a library or with intrinsic type of
functions within the object code. The first technique is rather old one --
in Turbo Pascal for example the linker never put a function from an object
file that was never been accessed to.

Also I am not sure with HiTech but in many embedded C compiler you can tell
which type of printf do you want to use within your application (there are
some minimalistic version, with some restricted version like no float types
and the full version). Hang on a minute, are you saying the HiTech
automatically chooses the smallest/fastest but still functional one when you
are compiling your application?

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