> On Thu, 27 Sep 2007 12:38:13 +0200 (CEST)
> > > Pointer(AnsiString) <> Pointer(PChar(AnsiString))
> > >
> > > To get a no-op typecase you can use:
> > > MyPChar:=PChar(Pointer(AnsiString));
> >
> > Is this delphi compat, and if yes, what is this exactly for?
>
> I don't know.
>
> The change b
Mattias Gaertner wrote:
On Thu, 27 Sep 2007 12:38:13 +0200 (CEST)
[EMAIL PROTECTED] (Marco van de Voort) wrote:
[EMAIL PROTECTED] (Marco van de Voort) wrote:
A cast is really a cast. IOW the cast pchar(ansistring) is mostly
a no-op. Traditional C code then usually treats the #0 as end of
strin
On Thu, 27 Sep 2007 12:38:13 +0200 (CEST)
[EMAIL PROTECTED] (Marco van de Voort) wrote:
> > [EMAIL PROTECTED] (Marco van de Voort) wrote:
> > > A cast is really a cast. IOW the cast pchar(ansistring) is mostly
> > > a no-op. Traditional C code then usually treats the #0 as end of
> > > string.
>
On Thu, 27 Sep 2007, Marco van de Voort wrote:
> > [EMAIL PROTECTED] (Marco van de Voort) wrote:
> > > A cast is really a cast. IOW the cast pchar(ansistring) is mostly a
> > > no-op. Traditional C code then usually treats the #0 as end of
> > > string.
> >
> > PChar(AnsiString) was a no-op ty
> [EMAIL PROTECTED] (Marco van de Voort) wrote:
> > A cast is really a cast. IOW the cast pchar(ansistring) is mostly a
> > no-op. Traditional C code then usually treats the #0 as end of
> > string.
>
> PChar(AnsiString) was a no-op typecast in the past and is nowadays a
> function. It checks whe
On Wed, 26 Sep 2007 16:29:20 +0200 (CEST)
[EMAIL PROTECTED] (Marco van de Voort) wrote:
> > Am Mittwoch, den 26.09.2007, 13:24 +0200 schrieb Marco van de Voort:
> > > > >
> > > > > Ansistrings (and thus {$longstrings on}) work fine.
> > > >
> > > > Ah, okay. The Fog is lifting fastly. :)
> > > >
> Am Mittwoch, den 26.09.2007, 13:24 +0200 schrieb Marco van de Voort:
> > > >
> > > > Ansistrings (and thus {$longstrings on}) work fine.
> > >
> > > Ah, okay. The Fog is lifting fastly. :)
> > >
> > > And AnsiStrings are pretty much compatible to C's char*. Very handy.
> >
> > Yes, though ans
On 26 Sep 2007, at 15:12, Marc Santhoff wrote:
And AnsiStrings are pretty much compatible to C's char*. Very handy.
Yes, though ansistrings may contain #0's.
Interesting, how will a cast handle this case?
Will it change the intermediate #0 to something else or will the
resulting pchars be
Am Mittwoch, den 26.09.2007, 13:24 +0200 schrieb Marco van de Voort:
> > > On 26 Sep 2007, at 11:56, Marc Santhoff wrote:
> > > ansistring rather than for shortstring. Separately from that there is
> > > also a type called "longstring" which is basically a shortstring but
> > > with a 4 byte le
> > On 26 Sep 2007, at 11:56, Marc Santhoff wrote:
> > ansistring rather than for shortstring. Separately from that there is
> > also a type called "longstring" which is basically a shortstring but
> > with a 4 byte length field. It's this longstring which has not been
> > implemented properl
Am Mittwoch, den 26.09.2007, 12:55 +0200 schrieb Jonas Maebe:
> On 26 Sep 2007, at 11:56, Marc Santhoff wrote:
>
> >> Longstrings were never completely implemented nor tested, so no one
> >> really knows what works and what doesn't. It would be better if the
> >> compiler simply gave an error for
On 26 Sep 2007, at 12:03, Marco van de Voort wrote:
Am Mittwoch, den 26.09.2007, 11:34 +0200 schrieb Marco van de Voort:
The field is a pointer to the ansistring. Which is basically a
pchar with a
TAnsirec record on negative offset of the ptr value.
Thanks, that's what I assumed and could
On 26 Sep 2007, at 11:56, Marc Santhoff wrote:
Longstrings were never completely implemented nor tested, so no one
really knows what works and what doesn't. It would be better if the
compiler simply gave an error for them at compile time.
That's irritating, because "rtl.pdf" from the 2.0.4 re
> Am Mittwoch, den 26.09.2007, 11:34 +0200 schrieb Marco van de Voort:
> > The field is a pointer to the ansistring. Which is basically a pchar with a
> > TAnsirec record on negative offset of the ptr value.
>
> Thanks, that's what I assumed and could not proof.
>
> Is this the case for any occur
Am Mittwoch, den 26.09.2007, 11:34 +0200 schrieb Marco van de Voort:
> > > > set up?
> > >
> > > Longstrings are not working correctly. You should use ansistrings or
> > > shortstrings.
> >
> > Okay, good to know. Besides I'm using fpc 2.0.4, what is it that's not
> > working?
> >
> > And back t
Am Mittwoch, den 26.09.2007, 11:38 +0200 schrieb Jonas Maebe:
> On 26 Sep 2007, at 11:18, Marc Santhoff wrote:
>
> >> Longstrings are not working correctly. You should use ansistrings or
> >> shortstrings.
> >
> > Okay, good to know. Besides I'm using fpc 2.0.4, what is it that's not
> > working?
On 26 Sep 2007, at 11:18, Marc Santhoff wrote:
Longstrings are not working correctly. You should use ansistrings or
shortstrings.
Okay, good to know. Besides I'm using fpc 2.0.4, what is it that's not
working?
Longstrings were never completely implemented nor tested, so no one
really know
> > > set up?
> >
> > Longstrings are not working correctly. You should use ansistrings or
> > shortstrings.
>
> Okay, good to know. Besides I'm using fpc 2.0.4, what is it that's not
> working?
>
> And back to the original question: how is the memory layout using
> AnsiString then?
The field i
Am Mittwoch, den 26.09.2007, 09:30 +0200 schrieb Michael Van Canneyt:
>
> On Wed, 26 Sep 2007, Marc Santhoff wrote:
>
> > Hi,
> >
> > having this definition:
> >
> >
> > {$mode objfpc}
> > {$longstrings on}
> > type
> > cmpstr = record
> > ID: integer;
> > Name: str
On Wed, 26 Sep 2007, Marc Santhoff wrote:
> Hi,
>
> having this definition:
>
>
> {$mode objfpc}
> {$longstrings on}
> type
> cmpstr = record
> ID: integer;
> Name: string;
> Value: single;
> end;
>
> var
> buf: array [0..MAX] of cm
Hi,
having this definition:
{$mode objfpc}
{$longstrings on}
type
cmpstr = record
ID: integer;
Name: string;
Value: single;
end;
var
buf: array [0..MAX] of cmpstr;
How does the memory layout of the buffer look like?
I tri
21 matches
Mail list logo
