Re: Machine English, Danish, Norwegian, Swedish, Dutch.
- From: Marco van de Voort <marcov@xxxxxxxx>
- Date: Sun, 8 Apr 2007 15:19:18 +0000 (UTC)
On 2007-04-06, Quas.co.ua <Quas@xxxxxxxxxxxxxxxx> wrote:
Size, clarity and optimization options. E.g. ansistrings are refcounted, andSame I did in interpreter of my last implemented language completely
don't need to be (de)allocated explicitely
written on C,
with actually
unsigned char[]
type.
But those features were useless against preferences of PHP made (for the
moment) with simpler features.
When Pascal was implemented machines could keep in memory few pages of text
today even in machine I was able to obtain in this country
with 128MB may be kept a longer text than even professional TV-news editors
read in a month.
True. But not every string that is processed is GUI related, and judged by human
speeds.
Take the simple example of search. You access a lot of strings, but the GUI
is only presented a subset.
But it seems the Pascal and C both have some common problems in their
recent implementation in modern computing,
Like?
Even in the developer's system TurboPascal 5.0 type "string" areIf you strongly need pascal style syntax for strings
why not implement some sort of preprocessor?
Because that doesn't yield e.g. the optimization, and the abilities to use
them in complex expressions safely.
attached in "*.tpu",
No they are not. They are in language, though helpers in libs (the .TPUs may
be called)
Yes Pascal has more restrictions than C, which made Pascal more safe,
but
the type "string" itself is not one of such restrictions for safety, it is
possible to make a type "array of bytes" in Pascal.
The point is that for routine work you don't have to. Specially if the base
string type scales pretty good performance wise. Than the pointer level
string handling is isolated in a few string routines deep in the RTL.
A preprocessor is an ugly hack at best. It's a last desperate resort, not somethingC compiler with a respective preprocessor may work together not worse
you want.
than Pascal compiler alone.
This is not true. Both have things the other can't. Pascal has a few more
types (e.g. sets,strings) and a module system which require in compiler
support.
The C preprocessor can also be (ab)used to do textsubsitutions.
Special symbols "CR", "LF", "TAB" perhaps also change the meanings ofWell, I'm not familiar with delphi but ability to have some special
characters was widely used, For example Russian terminal code set for DOS
was not able to be used with UNIX-like OS because some characters were
matched with terminal control codes (and there were characters not used in
Ukrainian spelling) So the problem is not new.
This is totally beside the point. This because codepages change the meaning
of values, while I'm talking about not having certain values ( character 0)
available in a C string.
values of "ASCII".
No they don't. They have well defined meanings.
If you need not only to put a message in string data type,Only a basic C string emulation. But it is clumsy, as you show above, and
don't you use other sort of data structures in Pascal as well as in C?
should be avoided.
What exactly should be avoided?
Having to code out significant portions of string routines manually on
basically a manually allocated pointer level.
.
- Follow-Ups:
- Re: Machine English, Danish, Norwegian, Swedish, Dutch.
- From: Quas.co.ua
- Re: Machine English, Danish, Norwegian, Swedish, Dutch.
- References:
- Re: Machine English, Danish, Norwegian, Swedish, Dutch.
- From: Quas.co.ua
- Re: Machine English, Danish, Norwegian, Swedish, Dutch.
- From: Marco van de Voort
- Re: Machine English, Danish, Norwegian, Swedish, Dutch.
- From: Quas.co.ua
- Re: Machine English, Danish, Norwegian, Swedish, Dutch.
- Prev by Date: Re: Machine English, Danish, Norwegian, Swedish, Dutch.
- Next by Date: Vista insecurity
- Previous by thread: Re: Machine English, Danish, Norwegian, Swedish, Dutch.
- Next by thread: Re: Machine English, Danish, Norwegian, Swedish, Dutch.
- Index(es):
Relevant Pages
|