Re: Pascal vs C style string ?

Dave Gillespie <synaptx!thymus!daveg@uunet.uu.net>
Thu, 30 Jun 1994 19:38:42 GMT

          From comp.compilers

Related articles
[12 earlier articles]
Re: Pascal vs C style string ? larryr@pa.dec.com) (1994-06-28)
Re: Pascal vs C style string ? boehm@parc.xerox.com (1994-06-28)
Re: Pascal vs C style string ? cjmchale@dsg.cs.tcd.ie (1994-06-29)
Re: Pascal vs C style string ? nandu@cs.clemson.edu (1994-06-29)
Re: Pascal vs C style string ? Theo.Norvell@comlab.oxford.ac.uk (1994-06-30)
Re: Pascal vs C style string ? guerin@IRO.UMontreal.CA (1994-06-30)
Re: Pascal vs C style string ? synaptx!thymus!daveg@uunet.uu.net (Dave Gillespie) (1994-06-30)
Re: Pascal vs C style string ? nickh@harlequin.co.uk (1994-07-01)
Re: Pascal vs C style string ? mps@dent.uchicago.edu (1994-07-05)
| List of all articles for this month |
Newsgroups: comp.compilers
From: Dave Gillespie <synaptx!thymus!daveg@uunet.uu.net>
Keywords: C, Pascal, design
Organization: Compilers Central
References: 94-06-214 94-06-258
Date: Thu, 30 Jun 1994 19:38:42 GMT

Ciaran McHale writes:
> I used the p2c Pascal-to-C translator to help me port the code of a
> compiler from Turbo Pascal (on a PC) to C so that I could use it on a UNIX
> machine. [...] A Pascal statement such as:
> StringVar := StringVar + 'c'; { add a char to the end of the string }
> was translated into C code like the following:
> sprintf(StringVar, "%s%c", StringVar, 'c');


The actual code p2c produces is simpler, but similarly inefficient:


strcat(StringVar, "c");


My goal with p2c was to produce readable, maintainable, natural-looking
output. This is why I felt it important to use native C strings rather
than a special Pascal-style string library. C programmers who read the
translated programs will expect to see C string operations.


If "c" is a variable, the output from p2c looks more like this; it tries
to translate in terms of standard library routines whenever possible,
which leads to a somewhat clumsy use of "sprintf":


sprintf(StringVar + strlen(StringVar), "%c", c);


There would be other pitfalls in p2c's use of counted strings. Every time
a string must be passed to a system library function, as a file name, a
string to be printed, or whatever, it would need a clumsy extra step to
convert between the two string forms. The most common and simple uses of
strings would be muddied for the sake of optimizing rarer forms like the
ones above.


> Thus a statement-to-statement source translator generates
> inefficient code where string manipulation is concerned.


P2c actually does do much more than statement-to-statement analysis, but
it still tries to translate one Pascal statement into one C statement when
it can for the simple reason that, in a good translation, something that
feels like a single action to the Pascal programmer ought to map into a
single action in the C code. Fundamentally, this is the difference
between a compiler and a translator; the former produces output for the
computer to read, but the latter produces output meant for both humans and
computers.




When I program in C++ I use a string class that stores a length *and*
maintains a terminating null byte. None of the basic string functions
depend on the null terminator, but algorithms that know the string
contains printable text can take advantage of the terminator to simplify
their logic. This also helps a lot when passing C++ strings to C-style
libraries.


At present, p2c still uses C-style strings even when targetted to C++. An
obvious next step would be to teach it how to use a C++ string class; this
would make string operations even more readable, and often more efficient
as well.


-- Dave
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.