RE: Dynamic arrays, What about using the Tcollection? Is there any dis-advantage? I know a lot of TP Programmers swear by them.

From: "Matt Emson"
Sent: Monday, February 10, 2003 3:41 PM
Subject: RE: [fpc-pascal]Classes/Objects/Pointers / Pointer Help

RE: Dynamic arrays, What about using the Tcollection? Is there any dis-advantage? I know a lot of TP Programmers swear by them.

No, if you mean the dynamic array stuff I used in my example. TP's TCollection (the one objects unit) works internally exactly like shown here, it just provides an OOP wrapper above an internal array of pointers for initialization, finalization, access and management - with all its advantages and disadvantages (e.g. performance, convenience, ...).

Compared to the Delphi style dynamic arrays (the terms 'object'/'class'/'dynamic array' have been a little bit overused in this thread lately imo :) following things could be interpreted as advantages (mostly syntactical stuff):
No method invocations by hand if any, you can use the (imo) more convenient brackets compared to calls. You get rid of the (ugly) '^' - character. It is more convenient (imo): Memory is automatically freed when dynamic array is set to nil or not used anymore. It is reference counted like ansistrings. You still have something like a 'constructor' though (SetLength() method). There are a few helper functions (like Copy(), Slice(), ...) for easy handling too. Regarding Performance: range checks and especially the array access etc. could be inlined, saving an indirect call for every access. [Don't know the FPC implementation]. There is partial compatibility to fixed size arrays (e.g. when passing arrays as parameters to methods). One (little) drawback: you should be aware that a variable of the kind of dynamic array is actually a pointer and not the real thing. Sometimes causes hard to trace problems if you simply replace all static arrays with dynamic ones in your code... ;-)

Probably I forgot one or two things, but it's quite a nice thing imo.

Regards,
Thomas

Hello, List!

The postings converning Classes/Objects/Pointers / Pointer Help I've read miss one point: There's need for uninitialized, static objects that are usable without calling a constructor.

We use static objects to build dynamic ones; but dynamic objects cannot be used to build static ones.

Let's assume an object-oriented system where power is switched ON and the contents of RAM are unknown. The software then must call a constructor, and store the result (the pointer to the first object instance in the system) in an object field, in order to work with the new object. But there's no object yet where that constructor's result might be stored = contradiction.

IOW, and informally, when there are no static, uninitialized objects, you have to withdraw the object-oriented approach from the hardware level up to higher, more "sophisticated" (?) levels. Object Pascal would then loose the ground under it's feet - it would no more be suited to program an operating system using OOP.

Let's stay on this n'th floor = static records, objects and interfaces, before looking at "higher" things such as dynamic allocation or virtual methods. I suggest, while still supporting all legacy code, to create a new, unified approach for records, objects and interfaces. I here use the term 'whole', but that's just a proposal.

***
type t_star_position = whole  // a record
  declination: real;
  rectascension: real;
  end;
type t_window = whole  // a static object
  x0, y0, x1, y1: integer;
  procedure clear(a_title: string);
  end;
type t_char_device = whole // an interface
  function char_available: boolean;
  function read_char: char;
  end;

I think this could be a new thread, so I renamed the subject.

Anton Tichawa.

----------

"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:

----------

Thomas Schatzl wrote

Regarding Performance: range checks and especially the array access etc. could be inlined, saving an indirect call for every access. [Don't know the FPC implementation].

Accesses are inlined, range checks are not.

Jonas

Anton Tichawa wrote

It's possible to make range checks inline, but at a first glance it seems to me that this would require reworking of very old (legacy?) parts of the compiler.

Not really, but it's simply a possibility to introduce bugs into code that works correctly. The gain is not really worth it at this time imho.

Jonas

Anton Tichawa wrote

What about a standard test application that uses every feature of Free Pascal,

Do you want to write that? :)

compares it's own results to standard results and produces a list of newly introduced bugs?

We already have a test suite (modules "tests" in cvs), but it doesn't test every possible feature.

Jonas

Michael Van Canneyt wrote

We have a test suite, with about 1000 test programs, which test every aspect of the compiler.

Make that "most aspects" :)

Jonas

We have a test suite, with about 1000 test programs, which test every aspect of the compiler.

Michael.

Not *every* but still quite a lot after all tests that Carl added, no ?

Michael.

Hello, List!

It's possible to make range checks inline, but at a first glance it seems to me that this would require reworking of very old (legacy?) parts of the compiler.

HTH

Anton Tichawa.

----------

"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:

----------

Hello, List!

Not really, but it's simply a possibility to introduce bugs into code that works correctly. The gain is not really worth it at this time imho.

What about a standard test application that uses every feature of Free Pascal, compares it's own results to standard results and produces a list of newly introduced bugs?

Anton Tichawa.

----------

"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:

----------

Hello, List!

Do you want to write that? :)

If nobody else does, I do. But I'd prefer doing it for linux only.

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:

----------

Yes, I think Carl did a good job there.

Marco van de Voort wrote

Yes, I think Carl did a good job there.

Well....not only Carl...I think you ALL (on the FPC team) are doing an EXCELLENT job. I'm exceedingly grateful to have this compiler, and, as a bonus, to also have access to communicate with its developers (that was impossible with Borland back in my TP days!!).

Thank you, Carl.
Thank you, Daniël.
Thank you, Florian.
Thank you, Jonas.
Thank you, Marco.
Thank you, Michael.
Thank you, Peter.
Thank you, Pierre.

And thank you to anyone else who contributed but is not named in the "author" list on the web site.

BTW, Michael, Peter and Pierre...where are your photos??

THANK YOU ALL for Free Pascal!!!! :)

Mark

I second this whole thing. You guys have really done an awful lot!

Regards,
Jim

Yes, thank you to all FPC Developers and answering our petty little problems :)

cheers
James

_______________________________________________ fpc-pascal maillist - http://lists.freepascal.org/mailman/listinfo/fpc-pascal