On 11/16/11, Tomas Hajny wrote:
> Indeed - TP/BP 7.0 gives the same (error) result. Unit strings (which
> might be more appropriate than unit objects included by Bart) doesn't
> change the result either.
Getting really Off-Topic ;-)
PChar is defined in objects unit in TP6, there is no strings un
On 16 Nov 11, at 21:53, Bart wrote:
> On 11/16/11, Jonas Maebe wrote:
>
> > Again: length(pchar) is perfectly correct and will be translated into
> > strlen(pchar), just like in Delphi (and probably even like in TP).
>
> Couldn't resist;
>
> Turbo Pascal 6.0:
>
> Program Prog;
>
> uses object
On 11/16/11, Jonas Maebe wrote:
> Again: length(pchar) is perfectly correct and will be translated into
> strlen(pchar), just like in Delphi (and probably even like in TP).
Couldn't resist;
Turbo Pascal 6.0:
Program Prog;
uses objects;
var
pc: PChar;
Len: Integer;
begin
Len := Length(p
Am 16.11.2011 17:25, schrieb Jonas Maebe:
On 16 Nov 2011, at 17:15, Sven Barth wrote:
Am 16.11.2011 16:55, schrieb Rainer Stratmann:
But when having pchar I wonder why it generally is not possible to make
strings longer than 255 as it was possible in the previous compiler
version.
There was
Am 16.11.2011 17:25, schrieb Jonas Maebe:
On 16 Nov 2011, at 17:15, Sven Barth wrote:
Am 16.11.2011 16:55, schrieb Rainer Stratmann:
But when having pchar I wonder why it generally is not possible to make
strings longer than 255 as it was possible in the previous compiler
version.
There was
On 16 Nov 2011, at 17:15, Sven Barth wrote:
Am 16.11.2011 16:55, schrieb Rainer Stratmann:
But when having pchar I wonder why it generally is not possible to
make
strings longer than 255 as it was possible in the previous compiler
version.
There was never a change regarding this as far as
Am 16.11.2011 16:55, schrieb Rainer Stratmann:
But when having pchar I wonder why it generally is not possible to make
strings longer than 255 as it was possible in the previous compiler version.
There was never a change regarding this as far as I know.
For shortsting I accept strings not lo
On 16 Nov 2011, at 17:06, Martin wrote:
So why not use pos(#0, foo_pchar) ?
That will convert foo_pchar to a string type (which one probably
depends on the state of the {$h} switch) and then call pos() on it.
Again: length(pchar) is perfectly correct and will be translated into
strlen(
On 16/11/2011 16:06, Martin wrote:
As mentioned before by someone else: length does read a field from the
string, which does not exist in pchar (hence string can contain #0 and
pchar can not).
Ok, before someone comments on this:
pchar can contain #0
but for automatic string conversation t
Am 16.11.2011 17:06, schrieb Martin:
As mentioned before by someone else: length does read a field from the
string, which does not exist in pchar (hence string can contain #0 and
pchar can not).
Jonas mentioned in another mail in this thread (as an answer to Felipe)
that "Length(PChar)" is con
On 16/11/2011 15:55, Rainer Stratmann wrote:
-Sh- Is the same as {$h-} or {$longstrings off}. You need -Sh (provided
that there's no {$mode fpc/objfpc/tp/macpas} in the source file, since that
will disable them again).
With {$h+} it works.
But when having pchar I wonder why it generally is not p
On Wed, 16 Nov 2011, Rainer Stratmann wrote:
Am Monday 14 November 2011 22:00:28 schrieb Jonas Maebe:
On 13 Nov 2011, at 14:02, Rainer Stratmann wrote:
Am Sunday 13 November 2011 02:15:07 schrieb leledumbo:
It works when {$LONGSTRINGS ON} or {$H+} directive exists. I think the
compiler trea
Am Monday 14 November 2011 22:00:28 schrieb Jonas Maebe:
> On 13 Nov 2011, at 14:02, Rainer Stratmann wrote:
> > Am Sunday 13 November 2011 02:15:07 schrieb leledumbo:
> >> It works when {$LONGSTRINGS ON} or {$H+} directive exists. I think the
> >> compiler treats functions receiving array of char
Am 15.11.2011 10:39, schrieb Graeme Geldenhuys:
On 15/11/2011, Sven Barth wrote:
In this case the reason is simply backwards compatibilty (note: not Delphi
compatibilty :P ).
But that's my point. I really don't think anybody is writing TP style
programs any more. So wouldn't it make sense to
On 15/11/2011, Sven Barth wrote:
> In this case the reason is simply backwards compatibilty (note: not Delphi
> compatibilty :P ).
But that's my point. I really don't think anybody is writing TP style
programs any more. So wouldn't it make sense to change the default for
the vast majority or pro
Am 13.11.2011 17:49, schrieb Graeme Geldenhuys:
On 13/11/2011, leledumbo wrote:
I think the
compiler treats functions receiving array of char (or pointer to it) as
ShortString when none of the directives above exist.
Indeed, FPC defaults to ShortString if {$H+} is not specified. That is
proba
On 13 Nov 2011, at 14:02, Rainer Stratmann wrote:
> Am Sunday 13 November 2011 02:15:07 schrieb leledumbo:
>> It works when {$LONGSTRINGS ON} or {$H+} directive exists. I think the
>> compiler treats functions receiving array of char (or pointer to it) as
>> ShortString when none of the directive
On 13/11/2011, leledumbo wrote:
> I think the
> compiler treats functions receiving array of char (or pointer to it) as
> ShortString when none of the directives above exist.
Indeed, FPC defaults to ShortString if {$H+} is not specified. That is
probably the problem. I really don't know why this
Am Sunday 13 November 2011 02:15:07 schrieb leledumbo:
> It works when {$LONGSTRINGS ON} or {$H+} directive exists. I think the
> compiler treats functions receiving array of char (or pointer to it) as
> ShortString when none of the directives above exist.
No it does not work then.
I put already t
It works when {$LONGSTRINGS ON} or {$H+} directive exists. I think the
compiler treats functions receiving array of char (or pointer to it) as
ShortString when none of the directives above exist.
--
View this message in context:
http://free-pascal-general.1045716.n5.nabble.com/pchar-with-more-tha
20 matches
Mail list logo
