Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 (Tek) 9/26/83; site tekecs.UUCP Path: utzoo!watmath!clyde!burl!mgnetp!ihnp4!houxm!hogpc!houti!ariel!vax135!cornell!uw-beaver!tektronix!orca!tekecs!patcl From: patcl@tekecs.UUCP Newsgroups: net.lang.mod2 Subject: Re: strings in Modula-2 Message-ID: <3973@tekecs.UUCP> Date: Sun, 19-Aug-84 01:56:44 EDT Article-I.D.: tekecs.3973 Posted: Sun Aug 19 01:56:44 1984 Date-Received: Wed, 15-Aug-84 00:35:30 EDT Organization: Tektronix, Wilsonville OR Lines: 35 >> ...The C style of strings (ie null terminated). >> could be easily be implemented, as well as the dynamic type. To solve >> the literal string problem you only need a routine (LiteralString?) to >> stuff the constant into the right structure. This doesn't solve the problem. The problem was not that literal strings and other (dynamic) strings cannot be used together -- certainly the programmer can explicitly provide the code, as a routine or inline, to copy values from one type of structure into another type of structure. The problem was how to avoid making the programmer do this, in the case of general library modules to support a varying-size string type. And it *is* a problem, because the programmer has to potentially code in this explicit conversion at *every* library routine call. A general "concatenate(s1, s2: string; VAR result: string)" illustrates the point. Certainly I'd like either s1, or s2, or both, to take either literal string constants, or string variables, as argument values. In C, there's no problem; an address is generated either way. To handle this situation in Modula-2, "string" must be ARRAY OF CHAR (or some user-defined array of char type), and yet the actual arguments to which s1 and s2 and result are bound must always of some *fixed size* array type (yes, I know, I could pass an open array declared in an enclosing procedure -- but that simply moves the problem to the next outer level). Since the result of a concatenate might be used as an input string sometime later, I end up declaring a maximal-sized string type and using it for all string variables at the outer level. What I would really *like* to do is have the ability (in the library module code) to dynamically allocate memory for result strings, and then return these dynamically created strings in such a way that they are compatible with all other strings -- currently not possible in Modula-2. Pat Clancy Tektronix {ucbvax,decvax,ihnp4,allegra,uw-beaver,hplabs}!tektronix!tekecs!patcl