Peter Gerwinski wrote:
> > s:='' should do the same. (BP optmizes this to just setting the length to 0,
> > I hope gpc does as well.)
>
> It does. (But better check it, too - I already was wrong once with
> statements of this type.;-)
Yes, it does. I checked it. It even does "s:='...'" where '...' is a constant
string with length<=14 without any loops or calls.
> > I think it should (at least with {$X+} or such), because it's the only way
> > to translate some kinds of procedures -- unless one wants to limit such
> > procedures to borland-like short strings.
>
> Long strings: "S.length:= ...". Short strings: "S [ 0 ]:= chr ( ... )".
^^^^^^
...or rather CurrentLength, as you said before. Then perhaps it would be
useful to allow the same syntax also for ShortStrings (additionally), just
as if ShortString[n] was declared as:
record
case boolean of
false:(CurrentLength:byte);
true:(string:array[0..n] of char);
end;
Also, it could be good to provide a (read-only) "pseudo field" Capacity.
(BTW: LongStrings' Capacity is always read-only, isn't it?)
BP 7.0 allows this via High(s) -- is something like BP's High and Low
functions (to give the lower and upper bounds of arrays and subrange types)
present or planned for gpc? Then the compiler could just translate
"s.Capacity" to "High(s)" in the case of ShortStrings.
These two things would make ShortStrings more similar to (and often
exchangeable with) LongStrings, without giving up BP compatibility.
> > The question is, should the #0 be added for short strings as well?
> > If Length=Capacity, it's impossible, but otherwise???
>
> We could increase the space allocated for a short string by 1, but this
> would break compatibility to UCSD and Borland Pascal. So better ignore
> this and live with "String [ 255 ]" having only a capacity of 254 in fact.
No, I guess this could break some programs, too.
BTW: The problem is also there for Length=Capacity<=255: either we'd have
Sizeof(String[n])=n+2 or (Capacity of String[n])=n-1 -- both could lead to
problems. So, perhaps better forget about the #0 with ShortStrings, and add
it when converting to other strings...
> > Isn't it good when non-standard compilers (BP) use non-standard syntax? :-)
>
> I would not call this "non-standard" since this - like many other things,
> e.g. Units - was not invented by Borland but by UCSD.
But UCSD was non-standard, too, wasn't it? Just out of curiosity, it doesn't
really matter to me.
--
Frank Heckenbach, Erlangen, Germany
heckenb(a)mi.uni-erlangen.de
Turbo Pascal: http://www.mi.uni-erlangen.de/~heckenb/programs.htm
Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm
Hi everyone!
Two questions about portability of properties of arrays:
Let's assume a:array[x..y] of t (not a packed array).
1. Is it safe to assume -- for all platforms, including possible future
ones -- that SizeOf(a) = ((Ord(y)-Ord(x)+1) * SizeOf(t)?
2. Is it safe to assume that
Integer(@a[p])-Integer(@a[q]) = (p-q) * SizeOf(t)?
(Is it generally allowed to cast a pointer into an integer,
in the first place?)
--
Frank Heckenbach, Erlangen, Germany
heckenb(a)mi.uni-erlangen.de
Turbo Pascal: http://www.mi.uni-erlangen.de/~heckenb/programs.htm
Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm
Christian Wendt wrote:
> PG>> not "impossible"- you only got to reinvent the wheel and write to
> PG>> $b80000... _big_ loss in portability & comfort (no easy to call writeln.
> PG>Nevertheless this will remain my preferred method in BO5. The fastest
> PG>thing you can imagine on the DOS platform.
> hmm. is the type of "file" specified in the ISO /Extended?
> would it be possible to define it similar to TP/BP?
> there's a list of procedures inwith the file "record" - they specify the
> functions to init/flush/writebuffer/readbuffer (theoretical you could do
> the same with an object...)
I assume you mean BP's TFDD (Text File Device Drivers). BTW: It's for "Text",
not for typed are untyped files (though there's actually no reason why it
shoudln't apply to them, too, except that BP's doesn't).
Indeed, I'd like to have something like this in gpc, too. I'm not at all
familiar with the internals of "Text" files (or other files) in gpc.
(ISTR, it has something to do with "bindable" variables, but I don't know
much about those, either.)
First a short explanation for those not familiar with BP:
Basically, TFDDs allow the programmer to assign procedures with the following
semantics to a "Text" variable to be used instead of file I/O:
Open: Input: File mode (Reset / Rewrite / Extend (aka Append))
Read: Input: Buffer size
Output: Actual size read (<= Buffer size); the value 0 signals an
EOF -- but perhaps it would be better to have a separate EOF
function (e.g. for things like serial ports that may have no
data at one time, but get some data later).
Data that were read (in the buffer)
Write: Input: Data in buffer
Size
Flush: (the same as Write, except that it should additionally "physically
flush the file", as far as that makes sense -- I can't remember any
examples where this did anything different than Write)
Close: -
All procedures also have an "error code" as Output to signal un-/successful
completion of the operation.
The TFDD can have a local data space (in BP: up to 16 bytes, AFAIR) -- local
to the file to distinguish different "instances" of files assigned to a
particular TFDD. (Here we see the similarities to objects...)
The big advantage is that one can do a Write[ln]/Read[ln] with all its
possibilites and have the data automatically "piped" to certain routines.
Sure, one could achieve the same in gpc with WriteStr/ReadStr and passing
the string to the routines, but
(a) it's not completely as easy (2 statements instead of one),
(b) managing the "local data" would require additional effort everywhere
this is used,
(c) it's not TP compatible...,
(d) a TFDD can be used transparently (e.g. a variable assigned to a TFDD can
be passed to any procedure that wants a "Text" file).
The particular syntax (and other things) BP uses for this is, IMHO, not very
nice (it was introduced after the "good days" of Borland, but before the
introduction of OOP, which could have simplified things), so I don't vote
for copying BP's mechanism. But any way to do such things would be good.
In fact, many of my units use TFDDs, and I can't see a "good" way of porting
programs that use them to gpc (only perhaps with heavy use of the preprocessor,
but I'd not like to do it like that). I'd not complain at all if it was done
with OOP (i.e. "Text" would be an object type, the "procedure" above would be
methods, the local data would be the fields of the object), the main thing is
that the object could be used in simple Read[ln]/Write[ln] statements.
Any chances to do something like this with reasonable effort?
--
Frank Heckenbach, Erlangen, Germany
heckenb(a)mi.uni-erlangen.de
Turbo Pascal: http://www.mi.uni-erlangen.de/~heckenb/programs.htm
Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm
According to Nils Bokermann:
> How do you want to compare structured variables? Compare member by
> member?
Yes. Except with types where we know that a simple byte compare
is sufficient.
> I knew a very fine programming language (ELAN) in which it was possible
> to define your own operator (`=', `<>' or whatever you wanted). Is it
> possible to have this as an extension to Pascal?
It's a PXSC extension which is already in GPC:
Operator = ( x, y: MyType ) result: Boolean;
begin (* MyType = MyType *)
result:= ( x.foo = y.foo ) and ( x.bar = y.bar ) or whatever;
end (* MyType = MyType *);
Greetings,
Peter
Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer
peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201]
maintainer GNU Pascal [970420] - http://home.pages.de/~gnu-pascal/ [970125]
According to Frank Heckenbach:
>
> s:='' should do the same. (BP optmizes this to just setting the length to 0,
> I hope gpc does as well.)
It does. (But better check it, too - I already was wrong once with
statements of this type.;-)
> I think it should (at least with {$X+} or such), because it's the only way
> to translate some kinds of procedures -- unless one wants to limit such
> procedures to borland-like short strings.
Long strings: "S.length:= ...". Short strings: "S [ 0 ]:= chr ( ... )".
> The question is, should the #0 be added for short strings as well?
> If Length=Capacity, it's impossible, but otherwise???
We could increase the space allocated for a short string by 1, but this
would break compatibility to UCSD and Borland Pascal. So better ignore
this and live with "String [ 255 ]" having only a capacity of 254 in fact.
> Currently the length could probably be changed by writing to
> s[1-SizeOf(Integer)] .. s[0] -- but I really don't want to try that... :-|
No. This will only work for lenghts below 256 and on big-endian machines.
Better cast the String to a record (read: cast a pointer to the String to
a pointer to a record).
> BTW: Does the standard require range checking (or does it say anything about
> it at all)?
Yes, AFAIK.
> And with {$X-} they don't work at all, you mean? Seems ok.
> And the same for packed records?
Yes.
> Isn't it good when non-standard compilers (BP) use non-standard syntax? :-)
I would not call this "non-standard" since this - like many other things,
e.g. Units - was not invented by Borland but by UCSD.
> BTW: String[n] with n>255 wouldn't work at all then?
Yes.
Greetings,
Peter
Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer
peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201]
maintainer GNU Pascal [970420] - http://home.pages.de/~gnu-pascal/ [970125]
According to Andreas Bauer:
>
> can you please explain me how to use the stdin/stdout with gpc?
> The compiler does not seem to know these.
The "legal" way is to use ordinary `read', `readln', `write', and
`writeln' operations. Note that `read' returns a space at the end
of a line, not a chr ( 10 ) or chr ( 13 ), and that `eoln ( Input )'
is `true' instead.
> It *does* work when stdin/stdout are connected to the terminal, but
> when using pipes it seems not to work.
It should work except that the first char is "eaten" by the GPC RTL.
See the thread "[BUG] GPC - a char killer?" on 7. and 11. April in
this list for reasons and a workaround.
Hope this helps,
Peter
Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer
peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201]
maintainer GNU Pascal [970420] - http://home.pages.de/~gnu-pascal/ [970125]
According to Christian Wendt:
>
> PG>The same stuff as in Borland's CRT, isn't it?
> Hmm. no - several stuff.
> move;
> declaration of byte...
> paramstr,paramcount
> (the date is 27.10.96) - seems to be an extract of tools/system.pas of BO5
We are speaking of different Units: You mean `bpcompat.pas' while
I am speaking of `bpcompat.zip' which contains `system.pas', `crt.pas',
etc.
> hmm. is the type of "file" specified in the ISO /Extended?
You mean the internal structure of the `file' type? No.
> would it be possible to define it similar to TP/BP?
> there's a list of procedures inwith the file "record" - they specify the
> functions to init/flush/writebuffer/readbuffer (theoretical you could do
> the same with an object...)
It's defined in a quite different way. The record contains a lot of
interesting information about the file, but no `hooks'. The actual
input/output is done via `ordinary' functions written in C.
But be invited to implement those `hooks' in the GPC RTS.
> PG>Of course. But a CRT Unit could use these sequences to access the
> PG>terminal in a portable way.
> Yes... transparent for the programmer...
Everything is transparent for the programmer since you have the
source code of everything. :-)
Peter
Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer
peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201]
maintainer GNU Pascal [970420] - http://home.pages.de/~gnu-pascal/ [970125]
According to Andreas Eckleder:
>
> ...i've got some problem with the library file of the actual (?!?)
> alphaversion of gnu-pascal...
(* Du meinst: "current" version? ;*) Obviously not - see below.
> [...]
>
> the other problem i realized with this alpha-version is that i couldn't
> manage to use the inline assembler.
> i only only got a message telling me function asm() not beeing existent.
This was a but in some old alpha versions of GPC which is fixed now.
The current version is gpc-970420 (see my signature).
BTW, the GPI file format changes with (almost) each version, so please
recompile your units after upgrading.
> because of this strong behavior i use the gpc2.0 compiler with the alpha-
> libraries...perhaps THIS is the reason why the function above doesn't
> work,
> but i am not quite sure about that...
(* That's what alpha versions are for: To find all bugs before releasing
it to the public. :*)
Please try again with gpc-970420 - or with gpc-9705?? ... perhaps this
weekend ...
Greetings,
Peter
Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer
peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201]
maintainer GNU Pascal [970420] - http://home.pages.de/~gnu-pascal/ [970125]
The African Chief wrote:
> >But how would you translate references to s[0] in BP then? I know, there
> >shouldn't be any in most programs, but sometimes it can be useful, e.g. for
> >efficiency. But it's ok for me if it's only enabled with {$X+}, see below.
>
> "s[0] := ..." is okay.
But you couldn't do that with long strings since their length isn't stored
in [0], but in .length. So there are cases where write access to .length is
needed, that's what I meant.
> I do that myself sometimes (but only to set the length to zero).
s:='' should do the same. (BP optmizes this to just setting the length to 0,
I hope gpc does as well.)
> "length(s) := ...."
> or "s.length := ..."
>
> - which shouldn't compile (if at all), when using "--borland-pascal".
I think it should (at least with {$X+} or such), because it's the only way
to translate some kinds of procedures -- unless one wants to limit such
procedures to borland-like short strings.
> >Does this mean strings will always have an additional trailing #0? Do the
> >string routines currently support this (i.e. automatically add a #0 at the
> >end; but they should not recognize #0 as a terminator, but only rely on the
> >length field)? That would be good, because it simplifies converting a string
> >into a CString a lot (just "CString(@s[1])", right?).
>
> Delphi 2 does this with long strings (I think). If we are going to do it,
> perhaps it should only be done for long strings as well?
>
> However, what happens when you want to add a string to
> the end of it? Check this example, and look at the ouput
> under Borland;
>
> program Fred;
> var
> s,s1:string[40];
> begin
> s := 'Fred Smith'+#0;
> s1 := s + 'is okay';
> writeln ( s1 );
> {prints "Fred Smith is okay" - where did the space before "okay"
> come from? I didn't want or put it there - viz; problem with trailing "#0"}
> end.
As Peter has already pointed out, an implicit #0 would not behave like this.
I suppose this would be achieved by having the length not include the #0.
So the internal representation of 'foo' would be something like:
Long string: Capacity:...; Length: 3; string: ('f','o','o',#0,...)
Short string: (#3,'f','o','o',#0,...)
The question is, should the #0 be added for short strings as well?
If Length=Capacity, it's impossible, but otherwise???
BTW: Your example raises the "problem" that if you have a string with one or
more #0 in it, and convert it to a CString, the CString will be shorter than
expected. But I think there's nothing to be done about it. If one wants to
convert a string to a CString, one just must not put any #0 in it...
Peter Gerwinski wrote:
> > But how would you translate references to s[0] in BP then? I know, there
> > shouldn't be any in most programs, but sometimes it can be useful, e.g. for
> > efficiency. But it's ok for me if it's only enabled with {$X+}, see below.
>
> That's one reason why `StortString's should be implemented - which will
> have "s[0]". But this job doesn't have high priority for me ...
As I said above, it would (currently) suffice for me if "s[0]:=..." could be
translated to "s.CurrentLength:=..." for long strings. But at the moment, it
can't be translated at all. The BP syntax "s[0]" is, IMHO, not very good, so
it should not be supported (emulated) for long strings.
> > Sounds good! {$X} is a local switch, isn't it (so one can turn it on and off
> > around code that needs it, and be safe from accidents elsewhere). It would be
> > even better than BP (where accidental writes to s[0] are not even detected
> > by range checking). :-)
>
> As long as GPC has no range checking at all ...
I know...
Currently the length could probably be changed by writing to
s[1-SizeOf(Integer)] .. s[0] -- but I really don't want to try that... :-|
BTW: Does the standard require range checking (or does it say anything about
it at all)?
> "CurrentLength"?
Why not.
> What about this: With (*$X+*), addresses of packed array members are
> only rejected if they don't lie on a byte boundary, and otherwise they
> work?
And with {$X-} they don't work at all, you mean? Seems ok.
And the same for packed records?
> Another idea, perhaps even better: let "String ( 255 )" or
> "LongString ( 255 )" denote an Extended Pascal (long) string, but
> "String [ 255 ]" or "ShortString [ 255 ]" an UCSD Pascal (short)
> string? Like this, both Extended Pascal and Borland Pascal programs
> will just compile. Needless to say that `--extended-pascal' will
> switch off "String [ 255 ]" and `--borland-pascal' will switch off
> "String ( 255 )" ...
Isn't it good when non-standard compilers (BP) use non-standard syntax? :-)
BTW: String[n] with n>255 wouldn't work at all then? Seems ok to me.
--
Frank Heckenbach, Erlangen, Germany
heckenb(a)mi.uni-erlangen.de
Turbo Pascal: http://www.mi.uni-erlangen.de/~heckenb/programs.htm
Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm
