Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-pascal / 2013-04

String type compatibility

17 messages · 8 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Xiangrong Fang

Hi,

In the following program:

program worksheet;
{$mode objfpc}{$H+}
type
  TWorksheet = packed object
  private
    FProp: string[5];
    //FProp: Integer;
  public
    property Prop: ShortString read FProp;
    //property Prop: Integer read FProp;
  end;
begin
end.

I got an error while compile:

worksheet.lpr(9,42) Error: Incompatible types: got "TWorksheet.ShortString"
expected "ShortString"

I wonder who defined "TWorksheet.ShortString"? Why string[5] is not compatible with ShortString?

Thanks!

Reply by email

Marco van de Voort
to Xiangrong Fang

In our previous episode, Xiangrong Fang said:

Show quoted text 6 lines
worksheet.lpr(9,42) Error: Incompatible types: got "TWorksheet.ShortString" expected "ShortString" I wonder who defined "TWorksheet.ShortString"? Why string[5] is not compatible with ShortString?

Shortstring, is an alias for shortstring[255] the maximum size. Use getters and setters if you want to make this work.

Reply by email

Xiangrong Fang
to Marco van de Voort

2013/4/3 Marco van de Voort

Shortstring, is an alias for shortstring[255] the maximum size. Use getters and setters if you want to make this work.

Thanks, however, I am just defining getter. So, to make this work, I need to define things like:

type
  MyProp = string[5];

then use it in class, right? I thought it is should be compatible...

BTW, recently there are many discussions about language features, now I would like to ask one question, why the following is not supported in pascal:

procedure SomeThing(AParam: array[0..10] of Integer);

or

procedure SomeThing(Aparam: string[10]);

But you have to define a custom type first?

Reply by email

leledumbo
to Xiangrong Fang
BTW, recently there are many discussions about language features, now I

would like to ask one question, why the following is not supported in pascal:

procedure SomeThing(AParam: array[0..10] of Integer);

or

procedure SomeThing(Aparam: string[10]);

But you have to define a custom type first?

Delphi compatibility and something else (should be documented on the wiki, but I forgot on which release).

View this message in context: http://free-pascal-general.1045716.n5.nabble.com/String-type-compatibility-tp5713952p5713955.html Sent from the Free Pascal - General mailing list .

Reply by email

Mark Morgan Lloyd
to leledumbo
leledumbo wrote 14 lines
> BTW, recently there are many discussions about language features, now I would like to ask one question, why the following is not supported in pascal: procedure SomeThing(AParam: array[0..10] of Integer); or procedure SomeThing(Aparam: string[10]); But you have to define a custom type first? Delphi compatibility and something else (should be documented on the wiki, but I forgot on which release).

I wonder if I could ask a related question. I was looking at some parser code yesterday that I wrote years ago, and that still compiles with TP5, TopSpeed and so on. It's got a couple of underlying string[255] declarations: is there a 16-bit Unicode equivalent which uses this syntax?

Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]

Reply by email

Noah Silva
to Mark Morgan Lloyd

Hi,

If you want a 16bit version, then probably WideString? UTF8String is better for many purposes though. (Though in FPC is is currently just an alias to AnsiString).

Thank you,
Noah Silva

2013/4/3 Mark Morgan Lloyd

Show quoted text 33 lines
leledumbo wrote: > BTW, recently there are many discussions about language features, now I >> > would like to ask one question, why the following is not supported in > pascal: > > procedure SomeThing(AParam: array[0..10] of Integer); > > or > procedure SomeThing(Aparam: string[10]); > > But you have to define a custom type first? > > Delphi compatibility and something else (should be documented on the wiki, > but I forgot on which release). > I wonder if I could ask a related question. I was looking at some parser code yesterday that I wrote years ago, and that still compiles with TP5, TopSpeed and so on. It's got a couple of underlying string[255] declarations: is there a 16-bit Unicode equivalent which uses this syntax? -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ______________________________**_________________ fpc-pascal maillist - http://lists.freepascal.org/**mailman/listinfo/fpc-pascal<http://lists.freepascal.org/mailman/listinfo/fpc-pascal>

Reply by email

Sven Barth
to Mark Morgan Lloyd: I wonder if I could ask a related question. I was looking at some parser code yesterday…
Mark Morgan Lloyd wrote 22 lines
leledumbo wrote: >> BTW, recently there are many discussions about language features, now I > would like to ask one question, why the following is not supported in > pascal: > > procedure SomeThing(AParam: array[0..10] of Integer); > > or > procedure SomeThing(Aparam: string[10]); > > But you have to define a custom type first? > > Delphi compatibility and something else (should be documented on the > wiki, > but I forgot on which release). I wonder if I could ask a related question. I was looking at some parser code yesterday that I wrote years ago, and that still compiles with TP5, TopSpeed and so on. It's got a couple of underlying string[255] declarations: is there a 16-bit Unicode equivalent which uses this syntax?

No, because all newer string types are not restricted in size (if you don't consider 2GB as a restriction :) ).

Regards,
Sven

Reply by email

Sven Barth
to leledumbo: would like to ask one question, why the following is not supported in pascal: procedure…
leledumbo wrote 14 lines
> BTW, recently there are many discussions about language features, now I would like to ask one question, why the following is not supported in pascal: procedure SomeThing(AParam: array[0..10] of Integer); or procedure SomeThing(Aparam: string[10]); But you have to define a custom type first? Delphi compatibility and something else (should be documented on the wiki, but I forgot on which release).

It's because in Pascal you need to declare types first.

Regards,
Sven

Reply by email

Mark Morgan Lloyd
to Sven Barth: No, because all newer string types are not restricted in size (if you don't consider 2GB…
Sven Barth wrote 10 lines
Am 03.04.2013 12:11, schrieb Mark Morgan Lloyd: > I wonder if I could ask a related question. I was looking at some > parser code yesterday that I wrote years ago, and that still compiles > with TP5, TopSpeed and so on. It's got a couple of underlying > string[255] declarations: is there a 16-bit Unicode equivalent which > uses this syntax? > No, because all newer string types are not restricted in size (if you don't consider 2GB as a restriction :) ).

Thanks, I thought that was probably the case but thought it worth asking.

Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]

Reply by email

Sven Barth
to Xiangrong Fang
Xiangrong Fang wrote 5 lines
> It's because in Pascal you need to declare types first. But why array[0..10] of Integer, or string[255] are not "types"? Remember that you can use "open array" in function params anyway.

They are types, but anonymous ones.

Also do not confuse open arrays with dynamic arrays. Open arrays can only be used for function/procedure parameters and you can pass dynamic arrays, static arrays or array constructors ( e.g. [10, 2, 4]), but you can only pass dynamic arrays to dynamic array parameters (which can only be done if you use a declared dynamic array type). Also you can't return "open arrays".

Regards,
Sven

Reply by email

Jonas Maebe
to Xiangrong Fang: But why array[0..10] of Integer, or string[255] are not "types"? Remember that you can…
Xiangrong Fang wrote
> It's because in Pascal you need to declare types first. But why array[0..10] of Integer, or string[255] are not "types"?

They are type definitions. Parameter lists cannot contain type definitions, only previously defined types. The main reason is that defining the same structured type multiple types results in different types. E.g.:

***
unit tt7;
interface
type
   ta = array[0..10] of Integer;
   tb = array[0..10] of Integer;
procedure test(a: ta);
procedure test(b: tb);
implementation
procedure test(a: ta);
begin
end;
procedure test(b: tb);
begin
end;
end.
***

The compiler can match the interface and implementation definitions based on the fact that the type definitions match (note, "type definitions" and not "type names" — i.e., you can add "type tc = ta" and change the "a: ta" into "a: tc" only in the implementation, and it will still compile because the type definitions still match).

However, if you would have

procedure "test(a: array[0..10])"

in the interface, there would be no way for the compiler to match the implementation to the interface because in both cases a new definition would be created. This is a fundamental aspect of how Pascal's type system works.

Remember that you can use "open array" in function params anyway.

An "open array" is a special case. It even can only appear inside parameter lists, and there is no way to define a standalone "open array" type.

Jonas

Reply by email

Jonas Maebe
to leledumbo
leledumbo wrote
Just a side little question: AFAIK the standard allows such a definition inside parameter, so we're not ISO compatible at this point?

If that is indeed true, then we are not.

Jonas

Reply by email

Marco van de Voort
to Florian Klämpfl

In our previous episode, Florian Kl?mpfl said:

> Just a side little question: AFAIK the standard allows such a definition > inside parameter, so we're not ISO compatible at this point? Can you point out where the standard allows this?

The standard doesn't support UCSD strings, but J&W (and afaik the standard too) support array definition in arguments lists afaik.

Reply by email