[SOLVED] OOP and FPC

[Pascaluvr]

OK, I have remove all items that aren't being used at the moment.  These were initially coded for future use. 

The program still gives the same result - SIGSEGV when I close the form.

Code: [Select]

unit LLtest;

{$mode objfpc}{$H+}

interface

uses
  Classes, SysUtils, FileUtil, Forms, Controls, Graphics, Dialogs, StdCtrls,
  ComCtrls,
  LinkedList;

type

  { TForm1 }

  TForm1 = class(TForm)
    Button1: TButton;
    Button2: TButton;
    Button3: TButton;
    Memo1: TMemo;
    StatusBar1: TStatusBar;
    procedure Button1Click(Sender: TObject);
    procedure Button2Click(Sender: TObject);
    procedure Button3Click(Sender: TObject);
  private
    { private declarations }
  public
    { public declarations }
  end;

var
  Form1: TForm1;
  LL:    tLinkedList;

implementation

{$R *.lfm}

{ TForm1 }

procedure TForm1.Button1Click(Sender: TObject);
  begin
  LL.Destroy;
  Button1.Visible := False;
  Button3.Visible := True;
  ShowMessage('Class freed');
//  Form1.Close;
  end;

procedure TForm1.Button2Click(Sender: TObject);
  begin
  LL.AddItem;
  ShowMessage('ItemCount now: ' + IntToStr(LL.ItemCount) +
               ' ItemSize is: ' + IntToStr(LL.ItemSize));
  end;

procedure TForm1.Button3Click(Sender: TObject);
begin
  LL := tLinkedList.Create(100);
  Button3.Visible := False;
  Button1.Visible := True;
  ShowMessage('LL Created');
end;


end.


Code: [Select]

unit LinkedList;

{$mode objfpc}{$H+}

interface

uses
  Classes, SysUtils, cmem;

Type

  tLinkedList = Class
      ItemCount:            LongInt;
      ItemSize:             LongInt;
      Constructor Create(s: LongInt);
      Procedure AddItem;

  end;


implementation

Constructor tLinkedList.Create(s: LongInt);
  begin
  ItemCount := 0;
  ItemSize := s;
  end;


Procedure tLinkedList.AddItem;
  begin
  Inc(ItemCount);
  // Build the linked list
  end;

end.



[CaptBill]

hi CaptBill,

Item is not being used yet - it is the item that will be added to the LinkedList, but currently, if you look at addItem all it does is increment a counter.

I will take out everything that is not used to avoid confusion and post thge bare basics.

Ooops. I was looking at the create method and it looks like you had initialized them there and overlooked that, but I forgot to mention that to you.

Have you tried to trace it down using the debugger? Get any hints from there?

I don't know. Gotta be something simple.

[Pascaluvr]

I agree Capt - its gotta be something simple.  Once its sussed, the rest is easy - just standard Pascal stuff.  (will still have problems, but at least I will understand Them);

OK... yes I tried the debugger when I still had Form1.Close there... and it goes thru Lazarus routines to handle this and aborts in the process.

I have also tried adding HeapTrc to the unit... and yes, it actually abends in HeapTrc report.

So clearly there is some invalid pointer - and given that I removed my pointers - the pointer must be to tLinkedList.

But now that I have bare bones code ...  it should be easy.  And again, I agree, it must be something so simple that its too hard to see.

[CaptBill]

Perhaps you project files got corrupted somewhere along the line (????)

Save the code in a text file, close Lazarus, restart and then make a new project.

I have had times where an odd component on a form got somehow corrupted and had me pulling out my hair...it can happen

As simple as what you have it's worth at least a check.

[Carver413]

after renaming the destructor and testing the class without all the lcl crap the class tested fine

Code: [Select]

program project1;

{$mode objfpc}{$H+}

uses
  {$IFDEF UNIX}{$IFDEF UseCThreads}
  cthreads,
  {$ENDIF}{$ENDIF}
  Classes, LinkedList
  { you can add units after this };

{$R *.res}
 Var
  vLink:tLinkedList;
  w:         string = 'Test String';
begin
  vLink:=tLinkedList.Create(100);
  vLink.AddItem(@w[1]);
  vLink.Free;
end.   


Code: [Select]

unit LinkedList;

{$mode objfpc}{$H+}

interface

uses
  Classes, SysUtils, cmem;

Type
  ItemRec = Record
    Prev,
    Next:                 Pointer;
    Item:                 array of char;
  end;

  tLinkedList = Class(TObject)
      First,
      Last,
      Curr:                 ^ItemRec;
      ItemCount:            LongInt;
      ItemSize:             LongInt;
      Constructor Create(s: LongInt);
      Destructor Destroy; override;
      Procedure AddItem(Item: Pointer);

  end;


implementation

Constructor tLinkedList.Create(s: LongInt);
  begin
  First := Nil;           // I think I read somewhere that
  Last := Nil;            // variables in classes are auto-init
  Curr := nil;            // but I want to be sure
  ItemCount := 0;
  ItemSize := s;
  end;

Destructor tLinkedList.Destroy();
  begin
  if first = nil then exit;
  // Free the entries here
  end;

Procedure tLinkedList.AddItem(Item: Pointer);
  begin
  Inc(ItemCount);
  // Build the linked list
  end;

end.     
So the problem is not in the class but somewhere else

if you really want to work with linked lists then it should be an all class design and avoid using pointers they will only cause more problems

[Pascaluvr]

Yep, definitely worth a check... had the same myself, but unfortunately not this time

I think its a conspiracy of component programmers preventing the likes of us application programmers from gaining access to their secrets.  Maybe they want to maintain guru status and not have the likes of us making it look easy 

[Pascaluvr]

"if you really want to work with linked lists then it should be an all class design and avoid using pointers they will only cause more problems"

1)  How can you have linked lists without Pointers????

2)  I have never had problems with pointers - until now - because a class is really just a pointer.

Try using the trimmed version I loaded.  No Pointers (that you are scared of) just a simple Set variable and Increment variable.  The only pointer involved is the Class itself.

[99Percent]

Ok, I discovered the problem. Remove the mem unit from the uses clause of LinkedList.

I have no idea what the mem unit does, but it will cause your application to crash when you close it.

[Pascaluvr]

I can reproduce this problem to the very barebones. I simply added unit LinkedLIst to a form unit in the uses clause. No use of the class or declaration of LL and it wil stilll cause the SIGSEGV error  when closing the main form.

99% Thank you for confirming I'm not going nuts here!!!!!

Well, I am, but at least I have company.

I am still convinced its something stupid I have done and I (we) just can't see it.

I thank you for your efforts

[Pascaluvr]

Ok, I discovered the problem. Remove the mem unit from the uses clause of LinkedList.

I have no idea what the mem unit does, but it will cause your application to crash when you close it.

Thank you 99%.

The mem unit was for me to allocate memory for my linked list items.  I guess I will have to find another way.  But thats ok, there is always another way to do something

Thank you so much for your perseverance and solution.

I appreciate the efforts put in by all.

[99Percent]

Lol, I realized the problem 2 minutes after posting my original message, thats why I modified it.

I used to be a Turbo Pascal programmer myself and in those days you practically had to reinvent the wheel everyday. Nowadays its vastly better to try to find the code you want. For link lists there are many classes already built into Free Pascal library. there are lists for strings, integers, objects, you name it.

[CaptBill]

Phewww!!   
Glad that got solved...congrats.

It's always something simple like that.

But take note about pointers...you are actually using them behind the scenes where you generally need them. Especially when you are trying to learn OOP. They only add a layer of complexity when it is generally not needed anyway... the compiler is using them and managing them within the object model itself. If you introduce pointers you are breaking outside of the 'object model'. In fact that is where much of the magic with OOP is happening just behind the scenes.The FPC team has already addressed them for you, for the most part. Definitely confuses things when you are trying to learn OOP when there is no need.

Cheers 

[Pascaluvr]

Lol, I realized the problem 2 minutes after posting my original message, thats why I modified it.

I used to be a Turbo Pascal programmer myself and in those days you practically had to reinvent the wheel everyday. Nowadays its vastly better to try to find the code you want. For link lists there are many classes already built into Free Pascal library. there are lists for strings, integers, objects, you name it.

I agree 99%, for 99%(no pun intended) of things I want to do, someone has already written something, but there is part of me that always wants to know how to do it myself.  Probably in the future I will use what is already available, but there is a part of me that needs reassurance that I could write it myself if it wasn't available.  I will continue to write my LinkedList Class just as a selfTraining exercise.  Imagine if I had all these problems with something I really needed right now!!  I want to be forearmed for when I need something.

And yes, Turbo Pascal days....  I had more source code for 'myUtils' then I did for any application.

Thanks again

[Pascaluvr]

"But take note about pointers...you are actually using them behind the scenes where you generally need them. Especially when you are trying to learn OOP. They only add a layer of complexity when it is generally not needed anyway... "

I truly don't understand the problem people have with pointers.  Maybe its a problem within OOP, but I am just learning that.  In the real world I use them all the time.

For example, I use an Isam Database system that I created.  Sure I could probably use something else, but
1) I created it
2) The performance is fantastic
3) It is perfectly suited to my needs.

Man, this doesn't just have pointers, it has pointers to pointers to pointers.  When an Index control interval fills up and an index split is required, you need to access the previous, the next, the lower level, the higher level, etc. etc.  Working with pointers is not a problem.  In fact, you work with OOP, you are working with pointers, the only difference is that you don't use a ^ in the name. 

I'm not suggesting pointers are easy, but realistically, just taking the '^' out of a name does not reduce that complexity.

Thanks again for all your help

[CaptBill]

Sorry Pascaluvr,

That was intended for others mainly that are trying to get a handle on OOP.

But what I AM saying to YOU is that the pointer is the magic behind the scenes already working. Even if you are a pro, if you are not aware of how they are being implemented behind the scenes, you may be 'reinventing the wheel'...and typically using them is defeating the OOP... it is playing outside of 'scope'...so even a pro, like yourself needs to be aware that this is already happening. They are, generally, best left to the team to perfect/streamline.

That's not to mention one of the key goals of OOP... code simplification/readabilty... if you leave a company the next guy may not be at the same level of expertise. To sell to the companies they want the power that pointers have PLUS an easier way of using them. With FPC/Lazarus/OOP you get just that.

Not saying they are not important, quite the contrary. I just KNOW that the FPC /Lazarus team is handling them (probably better than you and I will ever understand them, haha) . The pointers I use are, like you pointed out--classes, objects, arrays etc....but keep within scope of OOP is all. Look at the generated code and they are right there to be passed to the compiler.

Cheers