Lets see this code :

PROGRAM Essai;
{$MODE OBJFPC}
TYPE
 a = CLASS
     PUBLIC
      CONSTRUCTOR a1;
      x : Integer;
      DESTRUCTOR a2;
     END;
 CONSTRUCTOR a.a1;
 BEGIN
 END;
 DESTRUCTOR a.a2;
 BEGIN
 END;
VAR
 b : a;
BEGIN
 b.x := 10;
 write(b.x);
END.

As I learned in the documentation, b is a pointer that is not allocated :
"Remember that a class is a pointer to an object, so when you declare a variable of some class, the compiler just allocates a pointer, not the entire object."

documentation : Reference guide : Classes
then why this code is functional ?!
This is my problem : I am using a pointer which not allocated (Am I using a ghost memory ???!).
Please tell what's the problem (it is a bug ?).
Shifted Soul

Firstly, the class you define is not a valid Object Pascal class - if FPC compiles it, the FPC is wrong. You have to declare all variables in the varous sections *before* methods and properties. Delphi is very strict about this.

Secondly, you have to call a constructor to create an instance of the class before you can use it. This is similar (but not identical) to the way in which Turbo Pascal Objects worked when you create them on the heap.

Thirdly, 'Class' style objects follow a certain convention: Constructor called 'Create', Destructor called 'Destroy', which you must 'Override'. *Every* class style object inherits from 'TObject' whether you state this in its declaration or not. You do *not* call destroy directly, there is a method called 'free' which you must use.

Your code should look as follows:

       inherited Destroy;

    b := a.create; { You must create an instance... }

b.x := 10; write(b.x);

b.free; { YOU MUST CALL THE DESTRUCTOR, you do this with the 'free' method.}

END.

Try compiling this as a 'Delphi' compatible app.

If you wanted 'stack' based objects try:

That second example is untested.

To the FPC team: If anything I say about Object Pascal is untrue in FPC then I'm afraid that it's FPC that has it wrong. Delphi's implementation of the 'class' is a standard. You can't 'break' it. If you want to mess with this declaration, call it 'FPC_CLASS' or something.

Matt

you wrote

Firstly, the class you define is not a valid Object Pascal class - if FPC compiles it, the FPC is wrong.

It depends :), ever looked into:

Object-Oriented Extensions to Pascal
Technical Committee X3J9, Programming Language Pascal

The following DRAFT technical report was produced by the Technical Committee X3J9, Programming Language Pascal, a subcommitte of the Accredited Standards Committee, X3. The draft is public domain and can be freely used provided a reference to its source is made. Object-Oriented Extensions to Pascal
September 20, 1993

[...]

When I started the classes support I worked with this document.

Seeing as Borland essentialy 'popularized' the 'class' style construction in Object Pascal, following their conventions causes a whole heap less heartache for Delphi programmers. I think you'll find that the number of Delphi programmers outweighs the number of programmers using compilers with the specification below. To be honest, every Pascal compiler that I've seen pretty much goes down the Borland compatibility route. In fact, the only PC based compiler that I know of which implements any of the ANSI/ISO standards for Extended Pascal is the Prospero one, let alone this OO standard. That is pretty well unused. GPC may support parts of the ANSI/ISO standards, or even all of the Extended standard, but we all know how impractical GPC is.

I've tracked down a copy of the spec
(http://www.pascal-central.com/OOE-stds.html) and firstly it's out of date. It's almost 10 years old. Delphi wasn't even released at this point. Whilst I can see that Delphi borrows a lot from the spec, it also drops a lot of the blatant garbage, such as Abstract classes and Multiple Inheritence. Delphi is the defacto standard when it comes to Object Pascal, breaking the Borland standard is bad. It not only depreciates the usefulness of FPC, but it also alientates the very people that will come to use FPC from our knowlege of Delphi. Name me one single compiler that uses this full spec that is in popular ussage, and on an Intel or PowerPC platform.

I stand by my original comments. If you'd like a copy of the Borland Object Pascal Grammar, I can scan/OCR it for you. Failing that, it's in the back of the Delphi 5 Object Pascal Language Guide. The official Grammar for Class is as follows:

ClassType -> CLASS [ClassHeritage]
[ClassFieldList]
[ClassMethodList]
[ClassPropertyList]

          END

I think that speaks for itself.

Matt

Matt, I really don't understand why FPC lessening the strictness of Delphi's implementation of OOP is hurting anything. I mean, you can still declare fields before methods if you want, but it's not necessary. Maybe it would be a good idea to force this strictness in {$MODE DELPHI}, but I think it would be a bad idea to also force it in {$MODE OBJFPC}.

Also, I don't see the big problem with multiple inheritence and abstract classes.

On a side note, GPC is supposedly going to implement OOP (the variety described in the working draft) and treat .pp files as Pascal sources. But I've never tried GPC, primarily because it sounds like it would be hard to get set up but also because I feel it's hypocrisy to make a Pascal compiler with C.

Matt, I really don't understand why FPC lessening the strictness of

Delphi's

implementation of OOP is hurting anything.

Because no one uses the standard. If no one uses the standard, doesn't that tell you something about the standard? I.e. undesirable. I used to program in ADA, and to be honest it was a nightmare, mainly because some board somewhere had sat down and designed it. It was all over the place IMHO.

I mean, you can still declare fields before methods if you want, but it's not necessary.

Because Delphi is probably the most widely used Pascal compiler (Turbo Pascal given) today.

Maybe it would be a good idea to force this strictness in {$MODE DELPHI},

but I

think it would be a bad idea to also force it in {$MODE OBJFPC}.

One of the major problems with FPC is that it tries to do too many things. Too many cooks spoil the broth etc. If FPC focused on a standard (and the Borland standard is one I would like to see aimed for, that's both Turbo and Object Pascal) then the compiler would be stronger. Implementing standards that no one uses is a waste of time and resources. Implementing additional compatibility modes is not worthwhile. If we want to use GPC, we can download it etc. Besides, surely the Extended Pascal standard would be a better one to aim for.

The Object Pascal that Florian mentioned seems flakey and ugly to say the least. I also don't believe that FPC even meets it half way. Its pointless to implement half a standard.

Also, I don't see the big problem with multiple inheritence and abstract classes.

LOL!!! Why do you need to mark a class as abstract? If you have one single Abstract method in it, it in essence becomes an abstract class - that is to say, you shouldn't be able to create an instance of it. This is the way that both Delphi and Java do things, and it simplifies the language syntax greatly. As for multiple inheritence - it's just plain evil. Why do so many modern OO languages (Java, Delphi, VB.NET, C#, etc) have only single inheritence? The answer is that multiple inheritence breads inconsistency, overcomplexity and down right stupidity in most programmers. Look at the mess many get into in C++. In the field of OOPD, most of us feel nothing but contempt for multiple inheritence.

On a side note, GPC is supposedly going to implement OOP (the variety described in the working draft) and treat .pp files as Pascal sources.

GPC is next to useless in most normal ussage.

But I've never tried GPC, primarily because it sounds like it would be

hard to

get set up but also because I feel it's hypocrisy to make a Pascal

compiler

with C.

Save yourself the bother ;-) Dont..

Matt

You might be right if Delphi's standard was fixed. However it still fluctuates per version. Anything that doesn't break backwards compability could be in the next Delphi version. We saw that with Overloading :-)

Purely copying doesn't work. Tapping in into the sourcebase does. So it should eat Delphi programs, but shouldn't be limited by what Delphi can.

The implementation of the various forms of overloading by Borland is pretty much proof of that.

That is what it pretty much does. The extensions are only a few %%. As long as that balance remains sound, I don't see why that would spoil the "broth"

FPC 1.1 eats thousands (and sometimes already 10s of thousands!) lines of Delphi code without problems with the compiler (libraries are an entirely different chapter)

Implementing standards that no one uses is a waste of time and resources.

We don't have a legal version of the Delphi version. The original standard was available in paper and free to use.

Implementing additional compatibility modes is not worthwhile. If we want to use GPC, we can download it etc. Besides, surely the Extended Pascal standard would be a better one to aim for.

The extended standard is too much work. But the original standard is within reach. It only requires very few changes, and some RTL changes (that shouldn't be enabled standard, only under IFDEF)

Personally I think this is all academic. In practice FPC supports Delphi with a few extensions. The main probably are the libraries, and will remain for a very long time. The core team is increasingly getting occupied with the compiler, creating new targets, and maintaining the core RTL.

We need more donations to extend the libraries. Same with Lazarus, which is also need more contributors.

[GPC]

> On a side note, GPC is supposedly going to implement OOP (the variety > described in the working draft) and treat .pp files as Pascal sources. GPC is next to useless in most normal ussage.

They have one large advantage IMHO, and that is not the one everybody thinks it is: they can directly access C and C++ (and maybe even Java) headers.

If they ever get up to speed with FPC that could be a major disadvantage.

Not the first few years. They are pretty much in a kind of 0.99.5 or even earlier stage, but then multiprocessor and with a horrible compiler build process. Also GPC development seems to be stalling.

You might be right if Delphi's standard was fixed. However it still

fluctuates

per version. Anything that doesn't break backwards compability could be in the next Delphi version. We saw that with Overloading :-)

It more often *adds* features, rather than take them away. It still supports Objects (okay, so they are slightly broke), and Borland didn't promise support past V2.

Purely copying doesn't work. Tapping in into the sourcebase does. So it

should

eat Delphi programs, but shouldn't be limited by what Delphi can.

True, and I like the FPC line. I still don't see the point of supporting this standard that no other compiler supports in detriment to a standard that is widely used on a daily basis. The actual Object Pascal Language has changes fairly steadily over the years, but the pace has slowed down over the last few compiler versions. Not a great amount has changes since v4, the only major things in v6 have come about because of Kylix support.

The implementation of the various forms of overloading by Borland is

pretty

much proof of that.

I'm not entirely sure what you mean by that? Overlaying?? That changed quite a bit, but that mas more a performance related thing. Overloading hasn't changed syntactically since v4.

That is what it pretty much does. The extensions are only a few %%. As

long

as that balance remains sound, I don't see why that would spoil the

"broth"

I guess I just can't see why you'd need OBJFPC. It doesn't (from what I can see) add anything to the mix.

FPC 1.1 eats thousands (and sometimes already 10s of thousands!) lines of Delphi code without problems with the compiler (libraries are an entirely different chapter)

That's exactly what I want to hear :-) Now if I can only get my company's star programmer to take a look at the FPC source base, he might hack you in some support for interfaces. He seemed very interested in FPC until he found out about the lack of interfaces. He's the type of person, however, who has the ability to implement them.

We don't have a legal version of the Delphi version. The original standard was available in paper and free to use.

If you own a copy of Delphi you'll have it. It's in the OPL Ref guide.. it'll probably be a PDF.

The extended standard is too much work. But the original standard is

within

reach. It only requires very few changes, and some RTL changes (that

shouldn't

be enabled standard, only under IFDEF)

But if no one wants it, why implement it. You'll simply be doing it for the sake of doing it, rather than for a good reason. You all keep complaining about a lack of time - notice that this is going to eat into that time.

Matt

???? FPC 1.1 _has_ interfaces support and as yesterday I said, the DirectX8 D3D headers from Jedi compile and simple programs run fine. To compile the whole DirectX8 headers, the activex and the mmsystem units are missed, but I'am on the way ...

Quoting Florian Klaempfl :

I'll let him know, he'll be over the moon. He got all stary eyed, and started talking about writing a really cool RAD IDE in Free Pascal, until he mentioned interfaces. To be honest, I haven't really been keeping up with the 1.1 branch. It's not released as public, is it? It's therefore bleeding edge, and I'd rather use a stable release (or something similar.) I still use 1.02 on the Win32 platform.. I'm probably going to get 1.1 (and 1.04) today though, just for the hell of it :-)

you wrote

interfaces. To be honest, I haven't really been keeping up with the 1.1 branch. It's not released as public, is it?

It's available via cvs.

It's therefore bleeding edge, and I'd rather use a stable release (or something similar.)

1.1 is as stable as 1.0.x, if you use only the features which are available only in 1.0.x.

But the new features in 1.1 as the mentioned interfaces are considered as unstable. If they were really stable, we would release 1.2 :)

He got all stary eyed, and started talking about writing a really cool RAD IDE in Free Pascal,

Euh, did you mention lazarus.freepascal.org ? :-)

Full_Name wrote

I'll let him know, he'll be over the moon. He got all stary eyed, and started talking about writing a really cool RAD IDE in Free Pascal,

Please. please. please have him help with the Lazarus project if he wants to work on something like that. Currently the core developers for Lazarus have been very busy so Lazarus develoment has slowed to a crawl. We are in major need of additional help. Any help. :-)

Quoting "Michael A. Hess" :

I'll put it forward to him, but as he's the R&D guy for the entire company, I don't know whether it will still interest him. This was a conversation we had about two weeks ago ;-) He was writing a OO persistant DBMS layer for Delphi Classes for about 6 months. He seems to have dropped that now. He also has a nasty habbit of doing things like writing assembler directly into memory at runtime, and then executing it.. he wrote a piece of code that dynamically allocated/dispatched methods to an instance of an object from an interface (that wasn't part of the class) at runtime using this method. It was clever, but no one could really see a reason to use it...

 ITest = interface
    ['{77D52DDB-3EC3-4723-8919-00DFB6BF6418}']
    procedure DoSomething; stdcall;
    procedure DoSomethingElse; stdcall;
    procedure Another(test: integer); stdcall;
  end;
  TForm1 = class(TForm)
   {...}
  private
    { Private declarations }
    FIntFPtr         : Pointer;
    FTablePtr        : Pointer;
    FInvokationTable : PInvokationEntryArray;
    function GetITestToSelfOffset : Integer;
  public
    { Public declarations }
    procedure DoSomething; stdcall;
    procedure DoSomethingElse; stdcall;
    procedure Another(test: integer); stdcall;
  end;
  function CreateInvokationTable(Methods : array of pointer; Offset :
Integer) : PInvokationEntryArray;
procedure FreeInvokationTable(InvokationEntries : PInvokationEntryArray);
function CreateInterfaceVTable(Size : Integer;
  InvokationEntries : PInvokationEntryArray) : Pointer;
procedure FreeInterfaceVTable(VTable : Pointer);

...I won't give you the guts of the code, because my company owns it, but you could then do the following...

procedure TForm1.FormCreate(Sender: TObject);
begin
  //  Create Invokation Table
  FInvokationTable := CreateInvokationTable(,
    @TForm1._AddRef, @TForm1._Release, @TForm1.DoSomething,
    @TForm1.DoSomethingElse, @TForm1.Another], GetITestToSelfOffset);
  //  Initialize VTable Pointer
  FTablePtr := CreateInterfaceVTable(6, FInvokationTable);
  //  Initialize Interface Pointer, Interface Is A Pointer To A Pointer To
VTable
  FIntFPtr  := @FTablePtr;
end;

...and then do the following...

procedure TForm1.btnDoSomethingClick(Sender: TObject);
begin
  //  Invoke Method
  ITest(FIntFPtr).DoSomething;
end;

...Which should be impossible in the normal run of things.

Lazarus currently uses GTK+ doesn't it? That in itself probably will put him off. How is the Win32 API binding coming along?

Matt

Full_Name wrote

Lazarus currently uses GTK+ doesn't it? That in itself probably will put him off. How is the Win32 API binding coming along?

It has slowed along with the rest so any help with that is greatly appreciated.

Thanks for this referencem it was REALLY interesting. So as it seems that Delphi is not making up something really new, is there some kind of similar standard document that defines the INTERFACE/IMPLEMENTATION and in general the structure of Units as something "standard", and not just an invenction by Borland? (I think these are not part of the standard Pascal language, but I might be wrong! ;-))

Aitor

Well, the unit concept is no invention of Borland, is has been in fact adopted from the UCSD Pascal (and implemented in the descending implementation of HP Pascal and Apple Pascal as well), which AFAIK, was the first Pascal implementation to use such constructs. But to my knowledge, there was never an official "standard" for this, though i don't know the ANSI specs for Pascal and Extended Pascal to the full extend....

Ralf

At 8/26/01 03:49 PM, you wrote:

Ralf,

implementation to use such constructs. But to my knowledge, there was never an official "standard" for this, though i don't know the ANSI specs for Pascal and Extended Pascal to the full extent...

Extended Pascal (ISO/IEC 10206) -- available from
http://www.pascal-central.com/standards.html, -- defines them completely. Basically, there are two building blocks, an interface and an implementation, in the format:

-----------------------------------------------
module Name interface;
export
   Name = (x, y, z, a, b, c);
import
   i only (frange >= range);
   procedure SetState (NewState : LineState);
const
   x1 = 2;
type
   newtype = integer;
var
   variable : integer;

[procedures and functions]

end.
-----------------------------------------------

Apart from the slightly different wording at the beginning, the main difference compared to the Borland way are the export and import parts, which list all identifiers (variables, types, constants, procedure and function names) that are exported from or imported into the module. In both directions you can restrict the range and rename any identifier (for instance to avoid a name conflict with an identifier used inside the module).

The implementation is similar in format (with the obvious difference of 'implementation' in the first row) but might have two other sections at the end which deserve a closer look--both initialization and finalization code:

-----------------------------------------------
module Name implementation;
export
...
import
...
const
...
type
...
var
...

to begin do
   begin
   ...
   end;
to end do
   begin
   ...
   end;
end.
-----------------------------------------------

As for me, I consider Extended + OOP Pascal to be much better than any Borland or other attempt so far. Quite a pity we still don't have a good, fully compliant compiler...

Bye,
Gábor

------------------------------------------------------------------- Gabor DEAK JAHN -- Budapest, Hungary.
E-mail: