🚀 go-pugleaf

In article <48a5572e.12c9a@digital.sps.mot.com> shelley@atc.sps.mot.com (Norman K. Shelley) writes:
> Problem Statement: 
> 
> 2.) Eiffel needs a better model that reflects the unique features Eiffel 
> offers without sacrificing execution speed. Assertions heavily rely on 
> checking the length of the string. This is a function and not an attribute 
> thereby demanding much more CPU resources then should be required.

I'm not convinced that the speed performance of assertions is of primary 
concern.  Assertions will be turned off in high-performance versions of 
a program.  The speed and memory performance of production programs on 
production machines is more important.

Zero-terminated strings are convenient because they save memory and 
interface well with runtime libraries intended for use with C.  Many 
algorithms execute faster with zero-terminated strings because a separate 
index need not be maintained.  If your style of programming uses lengths 
and indexes more than pointers or iterators, counted strings are probably 
better.  

I tend to agree that Eiffel is such a lengths-and-indexes language, and that 
the use of zero-terminated strings isn't buying much performance except to 
avoid continual conversions when dealing with the operating system.  But 
conversion can require a very annoying amount of memory management.  The 
ideal would be a string type that has both a length attribute and zero- 
termination.  You can keep the length and termination updated all the time 
or calculate and cache one of them as necessary.  We have been using strings 
of this kind at Microsoft for years.

Zero terminated strings are a more primitive type, so it doesn't surprise
me that languages rely on the programmer to optimize the length calculation
themselves.  A little more support for compile time calculation would make
subclassing a viable solution to this kind of problem: constant objects could 
be fully constructed at compile time, making a programmer's classes equal in
performance to the built-in ones.

Alonzo Gariepy				// The opinions expressed above are not
alonzo@microsoft			// necessarily those of Microsoft Corp.