Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uunet!microsoft!alonzo From: alonzo@microsoft.UUCP (Alonzo GARIEPY) Newsgroups: comp.lang.eiffel Subject: Re: class STRING model needs fixing Message-ID: <51017@microsoft.UUCP> Date: 20 Feb 90 00:06:02 GMT References: <48a5572e.12c9a@digital.sps.mot.com> Reply-To: alonzo@microsoft.UUCP (Alonzo GARIEPY) Organization: Microsoft Corp., Redmond WA Lines: 38 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.