Hi All,

Does FPC support open arrays?
I get an error compiling something like this:

type
  m = array of integer;

but it works fine if I declare it inside a procedure or a function:

procedure OpenArray(var m: array of integer);

Thanks!

Jilani,

Although I've not been using FPC for some time now (just following the list), I think I can answer your question.

You can't declare an open array variable direcly in Pascal. The reason is memory allocation. Standard Pascal types - for example, integers and arrays - are allocated statically by the compiler. This means that the compiler has to know how much memory to allocate. Pointers and classes are dynamic types are allocated at runtime, and can be more flexible in this respect, but this does not directly solve your problem.

You need to be careful also when using open arrays as parameters. Open arrays are supported as parameters passed by reference only, because in this situation the compiler does not care about the structure size - only a pointer is passed. But this still has a strong limitation - you can't change the size of the array at runtime, unless you are willing to mess up with memory allocation yourself.

What solutions are available? There are a few directions you can go. The RTL has a collection class that can solve your problem, but the performance may suffer a little bit in some cases because of the overhead involved. If you need a high performance solution for simple arrays (for example, for number crunching), you can declare your arrays dinamically, but beware - you'll have to write your own memory management routines, and this is already implemented in the collection library.

Carlos Ribeiro

You are confusing two things. The first declaration is a dynamic array, the second an open array. FPC 1.0.x supports only the latter, 1.1 supports both.

Jonas

Carlos,

You can't declare an open array variable direcly in Pascal. The reason is memory allocation...

I thought it was possible to use open arrays the same way as implemented in Delphi 5. Thank you for the answer.

This is an dynamic array, and is supported only in 1.1 (the next big version currently in development)

but it works fine if I declare it inside a procedure or a function: procedure OpenArray(var m: array of integer);

This is an open array, and those are supported in both 1.0.x and 1.1.

So these are two different features (even though the syntax is similar)

This is a dynamic array, not an open array.
Dynamic arrays are supported in version 1.1.

but it works fine if I declare it inside a procedure or a function: procedure OpenArray(var m: array of integer);

This is an open array, and is supported in 1.0.6

Michael.

Will there also be sopport for conformant Arrays as they are defined in standard Pascal (ISO-7185)?

Not that I'm aware of (unless you plan to implement it ? ).

Marco van de Voort wrote

> Will there also be sopport for conformant Arrays as they are defined > in standard Pascal (ISO-7185)? Not that I'm aware of (unless you plan to implement it ? ).

No, I can't do it.

The point is just, that I'm still disappointed that FPC isn't compatible to any of the official Pascal standards and that it's not even trying to become compatible.

I'm very much drawn back and forth between FreePascal and GNU Pascal. Both have their advantages, but also their disadvantages. FreePascal has more commands, but GNU Pascal knows a much more elaborated syntax. FreePascal supports just one dialect, GNU Pascal knows different dialects including the standards. FreePascal has lots of systemspecific extentions, but programs written with them aren't portable, even not between the different variants of FreePascal itself. GNU Pascal tries to leave systemspecific things away, that means that programs are nearly always portable, but also that things are missing. GNU Pascal (the compiler itself) is very portable, while FreePascal is mainly targeted to PCs and porting to other platforms seems to take a lot of time. On the other hand GNU Pascal is hard to install, especially on non-Unix systems. GNU Pascal is the better Pascal, when you look at the source code of your programming, but FreePascal is the better compiler, when you look at the binary that comes out...

What I really want would be a mixture of both!

At the moment I try to use only what both have in common. But unfortunately that's not much. I have to avoid commands because of GPC and I have to use a simpler syntax because of FPC.

That's why I try to suggest that FPC should become more standard compatible, to be able to write more portable code.

Okay, I see that it's difficult to implement.
But what about things that look similar?

For example initialized variables...

FPC has this syntax:
const i: integer = 0;
But it's so very unlogical to use a "const" as variable. :-( (GPC accepts this syntax, but gives a warning)

Extended Pascal (ISO-10206) declares this syntax:
var i: integer value 0;
Much nicer, isn't it?

That at least looks very similar so I hope, at least that will be simpler for you to implement...

BTW. you might wonder why Extended Pascal uses "value" and not the equal-sign. That is because it also defines initialized types: type myint = integer value 0;
so that all variables that use this type are initialized. Here a second equal-sign would look strange.

Or what about String definitions:
FPC:
var s: string[255];
ISO-10206:
var s: string(255); {btw. not limited to 255}
Would it be so difficult to accept parantheses instead of brackets? GPC accepts both.

Try writing a compiler first instead of complaining about FPC's syntax :)

You are toying with the issue of syntax. There is nothing wrong with FPC's syntax, it's quite compatible with standard pascal and I disagree with most of what you say above. FPC to my knowledge was created as an alternative to Borland Pascal which only supported the 16-bit PC architecture. We need a pascal compiler to support 32bit.

FPC has this syntax: const i: integer = 0; But it's so very unlogical to use a "const" as variable. :-( (GPC accepts this syntax, but gives a warning)

What on earth would we want a more typed language ? Pascal is stongly typed enough as it is, and is quite comfortable to use. People like myself that have been using pascal for many many years will not be happy to find that pascal now has a new syntax.

cheers
James

True. There is pretty much no point in that, since the Pascal standards are effectively dead. (Borland 99.9% marketshare) Maybe we would do it if we had significantly more manpower, but we don't, and there isn't much hope on improvement.

I'm very much drawn back and forth between FreePascal and GNU Pascal. Both have their advantages, but also their disadvantages. FreePascal has more commands, but GNU Pascal knows a much more elaborated syntax.

Then I'd advise you to look more into the Delphi modes of FPC.

FreePascal supports just one dialect,

FPC supports both BP as Delphi syntax.

GNU Pascal knows different dialects including the standards.

But it doesn't implement them very well. To avoid this with FPC also, it was decided to not fragment until the manpower is there.

This is nonsense. Either one uses systemspecific extensions or not. This works for both FPC and GPC.

GNU Pascal (the compiler itself) is very portable, while FreePascal is mainly targeted to PCs and porting to other platforms seems to take a lot of time.

True, that is a fundamental problem. But note that this is also a reason for GPC being so unpredictable. Again it is FPC's philosophy of doing one thing right, before moving on.

Luckily, we are slowly moving away from that, and FPC runs decently on m68k already, and Sparc and PPC are in advanced stages of development.

On the other hand GNU Pascal is hard to install, especially on non-Unix systems.

And more importantly, harder to work on. The overal build process + system + patching is a lot more complex.

GNU Pascal is the better Pascal, when you look at the source code of your programming,

This is a matter of taste. I don't agree.

What I really want would be a mixture of both!

Then there is only one option. Work on either of them. Both projects have manpower shortage, the difference is how they handle that.

At the moment I try to use only what both have in common. But unfortunately that's not much. I have to avoid commands because of GPC and I have to use a simpler syntax because of FPC.

I wouldn't do that anyway. GPC hardly knows any Delphi dialect features, and those are the strong point of FPC (most of the development in language after 1997 deals with Delphi extensions).

That's why I try to suggest that FPC should become more standard compatible, to be able to write more portable code.

That wouldn't help either, since there is no true standard for the object orientated extensions anyway, only a draft that is interpreted differently by various people/companies.

And

var i : integer = 0;

in Delphi mode.

No. Why add a keyword "value" when an "=" is more logical? Bloat!

Ugly feature. I'm against it. A type doesn't have a value. I don't like pre-initalisation anyway, don't use it much in any variant.

This kind of baroque syntax is what makes some languages so tiresome.

Stringtypes (short, long and schemata based) are all fundamentally different. This is not just syntax, but a lot more.

Delphi's (ansi-) string type doesn't have a size, and is fully automatic.

Andreas K. Foerster wrote

GNU Pascal is the better Pascal, when you look at the source code of your programming, but FreePascal is the better compiler, when you look at the binary that comes out...

I suppose you have to pay that FPC is a Pascal->BIN compiler, whereas GPC is a Pascal->C compiler...
(also explaining why FPC supports less platforms, because the GCC guys are doing the job ;-))

Aitor

We only aim to be Delphi compatible. It is the de facto pascal standard, and is a usable implementation of pascal.

Most other standards are academic and not very usable.

FPC has 4 dialects:
- plain
- TP compatible
- Object pascal
- Objectpascal, delphi compatible.

FreePascal has lots of systemspecific extentions, but programs written with them aren't portable, even not between the different variants of FreePascal itself.

A. Which variants of FPC do you mean ?

B. It is in the nature of system specific things that they are not portable. Only the RTL and FCL are designed with as much portability as possible kept in mind.

All packages are system specific, and are used to make the compiler more usable on all platforms.

GNU Pascal tries to leave systemspecific things away, that means that programs are nearly always portable, but also that things are missing.

Exactly, thus severely limiting the usability.

GNU Pascal (the compiler itself) is very portable, while FreePascal is mainly targeted to PCs and porting to other platforms seems to take a lot of time.

We are working on this, but this is not an easy task.

Do not forget that GPC used GCC as a basis which already existed for more than 10 years when GPC was initially ported. So any comparison in this is meaningless. In 10 years we'll look where FPC and GPC are.

Portable code has nothing to do with standards.
We try implement the Delphi standard on all supported platforms.

What is so much nicer about this ?? We support the following:

var
  i: integer = 0;

Which is even much nicer.
'Nice' is largely a matter of taste, and hence is no argument.

That it is a standard is another matter.

If we decide finally to implement the ISO or ANSI pascal mode, then we may consider all this, but at this moment it is definitely not a priority.

FPC is an open source project. Feel free to grab a copy of CVS and implement it yourself. We'll be happy to include your changes. But our priorities lie elsewhere...

Michael.

Hello, List!

I aggree. Changes should be done carefully, because there is the risk of destroying existing (legacy?) software. What I'm doing is to use pascal 'as standard as possible', but to automatically create pascal files in cases where the standard requires too much typing.

Anton.

----------

"Adas Methode war, wie sich zeigen wird, Tagträume in offenbar korrekte Berechnungen einzuweben."

Doris Langley Moore: Ada, Countess of Lovelace (London 1977).

----------

Anton Tichawa
Volkertstrasse 19 / 20
A-1020 Wien
mobil: +43 664 52 07 907
email:

----------

Marco van de Voort wrote

True. There is pretty much no point in that, since the Pascal standards are effectively dead. (Borland 99.9% marketshare)

Well, well... and who needs HTML standards when anybody uses Microsoft products anyway... I hate that argument!!!

> FreePascal supports just one dialect, FPC supports both BP as Delphi syntax.

Okay, then I say "the dialects of just one company".

This is nonsense. Either one uses systemspecific extensions or not. This works for both FPC and GPC.

That's not what I said. I said GPC hasn't that much systemspecific extentions.
That can be seen as disadvantage or as advantage.

> What I really want would be a mixture of both! Then there is only one option. Work on either of them. Both projects have manpower shortage, the difference is how they handle that.

Well, may I port FPC units to GPC?
May I put them to their archive, even if no porting is necessary?

GPC hardly knows any Delphi dialect features, and those are the strong point of FPC (most of the development in language after 1997 deals with Delphi extensions).

Well, I never worked with Delphi. So maybe GPC is really better for me. BTW. the name FreeDelphi would fit better then.

var i : integer = 0; in Delphi mode.

Okay, I've overseen that.

James Mills wrote

it's quite compatible with standard pascal

Oh, there is still a lot missing, even from the unextended standard. For example conformant arrays, internal files, filebuffer variables, global GOTO's(?)
Procedure variables are implemented, but not in a compatible way.

Okay, that's of course difficult to implement. That's why I only mentioned differences, which I thought are more easy to implement.

and I disagree with most of what you say above.

Please be a little more precise.

FPC to my knowledge was created as an alternative to Borland Pascal

Okay.
As such it's a very good compiler.
But that dosn't mean, that it should keep their limitations. Borland Pascal also was never fully Pascal compatible. I think that's why they changed the name to Delphi.

People like myself that have been using pascal for many many years will not be happy to find that pascal now has a new syntax.

Hey, I don't want anything to be dropped, I want it to be extended!

HTML is used for interoperation on the web. It affects much more people. Totally different discussion.

The only reason to adapt the ISO standards is to gain access to ISO sources. Fact is, there aren't many, so it is no top priority. So while we are not 100% opposed to it, it is not scheduled, not even for the distant future, as long as there is work to do that _DOES_ have its merits. (like more processors, better optimizations, IDE's etc)

Actually the Object Pascal (Delphi language) was also implemented (though differently) by Apple.

It has. They are maybe not in the main distro. E.g. look at the Chief's packages, and you will find a lot of win32 stuff.

That can be seen as disadvantage or as advantage.

I fail to see the advantage. It's like saying that having no legs is an advantage because then they can't be hurt. I prefer walking though.

I've dealt with arguments like this my entire Modula-2 period, which is why I ultimately abandonned Modula2. The biggest problem, that all available sourcecode were very simple or theoretic algorithmic problems. No real applications, toolkits or so.

What good does a "pure" language + libraries do, when you can't work with them?

Most of the FPC stuff is GPL or LGPL. If you keep to those very small conditions, there will be no problem.

Frankly, that would depend on your history. If you have an extensive history in ANSI pascal, (and more importantly) a large ANSI codebase to work with in your field (some scientific disciplines have this), GPC may be better.

For new development, I'd use the more modern Delphi dialect (which GPC is also implementing bit by bit, but only slowly), and the more stable compiler (which IMHO is FPC)

BTW. the name FreeDelphi would fit better then.

No. The language is called "Object Pascal", Delphi is much more (RAD etc), besides we still have fundamental Borland Pascal mode. (or actually two, a strict one, and one with extensions)

Besides that, the term "Delphi" is probably copyrighted.

I suppose you have to pay that FPC is a Pascal->BIN compiler, whereas GPC is a Pascal->C compiler... (also explaining why FPC supports less platforms, because the GCC guys are doing the job ;-))

I'm quite sure that GPC is *not* a Pascal->C compiler, however it does use the GCC-backend to some extend, but this is - as I see it - an advantage compared to FPC.

Can FPC and GCC object files be linked together?

Best regards Preben

Can FPC and GCC object files be linked together?

It seems so... :-)

Best regards Preben

[ Charset ISO-8859-1 unsupported, converting... ]

In the simplest way it is (you don't have to program the backend). But life isn't about theory only regrettably.

The practical problems of being a GCC patch, is that it makes the overall system more complex. (as can seen by e.g. the complex buildsystem and instability and slow progress of GPC), and that the maintenance has to happen in a different language (C) than you are developping for (Pascal), which limits the amount of possible contributors.

Can FPC and GCC object files be linked together?

Yes, that is not the problem. There is still a problem though, specially on Unix. FPC can't directly use C headers.

In my understanding, Delphi is the "big box" with the IDE/RAD, toolkits, etc, whereas the language itself they use is ObjectPascal, so I don't think the name is wrong. FreeObjectPascal is a bit too much :) The only possible correspondence would be to call Lazarus FreeDelphi, but Delphi is for Windows only (under Linux it is Kylix, and Kylix 2.0 is now C++ as well), whereas Lazarus is available for more platforms...

Aitor

That is true.

If you search a Pascal to C converter, have a look at p2c. <ftp://ftp.debian.org/debian/dists/potato/main/source/devel/p2c_1.21.orig.tar.gz> But it doesn't have any of the Units - but it supports the Unit interface.

> I'm quite sure that GPC is *not* a Pascal->C compiler, however it does use > the GCC-backend to some extend, That is true.

I thought so. :-)

If you search a Pascal to C converter, have a must admit that I prefer ptoc instead, don't remember the URL, though...

Best regards Preben