gillies@uiucdcsp.cs.uiuc.edu (04/14/88)
This comment is probably a little bit late, but I'm disgusted by the
number of string functions in XJ311 (as described in Harbison &
Steele, 2nd edition). There are 18 functions of the form "strMUMBLE"
in the standard. This seems absurd to me.
When I worked for Xerox, we had no less than three separate
implementations (representations) for strings, and PARC had a 4th type
(Ropes). We had C-type strings [completely defunct], something called
XStrings, and also NSStrings. The latter two string packages supported
internationalization, multi-byte characters, and length counters.
I believe that in ten years, when we throw all our mainframes and
glass TTYs out (except for the compute servers), the XJ311 designers
will stand with egg on their face. Their strings will be completely
defunct on technical (international/WYSWYG) workstations. These
machines will probably allow two-byte characters, and for reasons of
efficiency and functionality, all clients will reimplement C strings.
The efforts of compiler vendors will go to waste.
Given a choice, I'd make STRSPN, STRCSPN, STRPBRK, STRRPBRK, STRTOK,
and STRSTR bite the dust. C has switch statements and pointers in the
language to accomplish these things efficiently. Most future clients,
for reasons of efficiency or functionality, will throw out these
functions anyway. That would cut this mountain (18) of functions down
to a merge tidal wave (12).
Don Gillies {ihnp4!uiucdcs!gillies} U of Illinois
{gillies@p.cs.uiuc.edu}gwyn@brl-smoke.ARPA (Doug Gwyn ) (04/16/88)
In article <77200033@uiucdcsp> gillies@uiucdcsp.cs.uiuc.edu writes: >Given a choice, I'd make STRSPN, STRCSPN, STRPBRK, STRRPBRK, STRTOK, >and STRSTR bite the dust. C has switch statements and pointers in the >language to accomplish these things efficiently. Ok, show me how you can use switch statements and pointers to implement strstr() efficiently. The majority of the str*() functions have been in use for 10 years or more in a vast number of applications. Apparently you think each application should have to reinvent these particular wheels. What do you think libraries are for?
les@chinet.UUCP (Leslie Mikesell) (04/17/88)
In article <7697@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >In article <77200033@uiucdcsp> gillies@uiucdcsp.cs.uiuc.edu writes: >>Given a choice, I'd make STRSPN, STRCSPN, STRPBRK, STRRPBRK, STRTOK, >>and STRSTR bite the dust. C has switch statements and pointers in the >>language to accomplish these things efficiently. > >Ok, show me how you can use switch statements and pointers to implement >strstr() efficiently. Or strtok() where subsequent tokens are not parsed by the same function as the first one in a string. >more in a vast number of applications. Apparently you think each >application should have to reinvent these particular wheels. What >do you think libraries are for? Not to mention the additional unecessary code space when shared libraries are available. I'm surprised that this issue was not raised in the recent discussion knocking the use of [sf]printf(). Is no one using the shared libraries on SysVr3 and friends? Les Mikesell ...ihnp4!chinet!les
daveb@geac.UUCP (David Collier-Brown) (04/18/88)
In article <77200033@uiucdcsp> gillies@uiucdcsp.cs.uiuc.edu writes: | When I worked for Xerox, we had no less than three separate | implementations (representations) for strings, and PARC had a 4th type | (Ropes). We had C-type strings [completely defunct], something called | XStrings, and also NSStrings. The latter two string packages supported | internationalization, multi-byte characters, and length counters. | | I believe that in ten years, when we throw all our mainframes and | glass TTYs out (except for the compute servers), the XJ311 designers | will stand with egg on their face. Their strings will be completely | defunct on technical (international/WYSWYG) workstations. These | machines will probably allow two-byte characters, and for reasons of | efficiency and functionality, all clients will reimplement C strings. | The efforts of compiler vendors will go to waste. I think I understand why you want to disentangle C from its current implementation of strings, but I fail to see what (the size of?) the current suite of library functions has to do with it. Could you clarify, before you inadvertently get flamed? --dave ps: since C is **rather** low-level, it may prove inadvisable to build a string mechanism which hides its implementation from the programmer: instead, we may want to make it easy to build different representations for a higher-level language, using C for its implementation. I'm thinking of C++ (or maybe ++C). -- David Collier-Brown. {mnetor yunexus utgpu}!geac!daveb Geac Computers International Inc., | Computer Science loses its 350 Steelcase Road,Markham, Ontario, | memory (if not its mind) CANADA, L3R 1B3 (416) 475-0525 x3279 | every 6 months.