[SOLVED] Shorthand for assigning to record variable?

[mrguzgog]

I have a dynamic array of records and I'm adding a new one like this:

Code: [Select]

        SetLength(mainList, length(mainList) + 1);
        mainList[high(mainList)].x := x;
        mainList[high(mainList)].y := y;
        mainList[high(mainList)].v := v;

It's no so bad with only three record 'members' but it would be a bit tedious with more. Is there a shorthand way to achieve this? I don't like the idea of 'with..do' and don't want more overhead by putting creating a procedure/function to do it. Is there a form something like this, which is supported in some other languages?

Code: [Select]

mainList[high(mainList)] = (1, 2, 3);


[Thaddy]

A dynamic array of records is the wrong structure in this case, because adding elements leads to a reallocation which is really, really expensive.
A list or something is a far better structure to implement such things. But to answer your question:

Expand your record with a SetValues function like:

Code: Pascal  [Select][+][-]

1. program insertitems;
2. {$mode delphi}
3. type
4.   TItem = record
5.     x,y,v:integer;
6.    function SetValues(a,b,c:integer):TItem;
7.   end;
8.  
9.   function Titem.SetValues(a,b,c:integer):TItem;
10.   begin
11.     x:=a;
12.     y:=b;
13.     v :=c;
14.    Result := Self;
15.   end;
16.  
17. var
18.   it:Titem;
19.   Mainlist:Array of TItem;
20. begin
21.   Setlength(MainList, Length(Mainlist)+1);
22.   MainList[High(MainList)] := it.SetValues(1,2,3);
23. end.
24.  

[marcov]

No. There is only with.

In the case of records entirely made of constants you can do

Code: Pascal  [Select][+][-]

1. const  somename : TRecordType = (x:1;y:2,z:3);

and do

Code: Pascal  [Select][+][-]

1.    mainlist [ind]:=somename

The syntax you propose is dangerous. At the very least all values should be tagged with their identifiers (like in the somename declaration above)

[Thaddy]

No. There is only with.

@Marco:  my answer crossed yours , but of course there are advanced records as per the above example...
@mrguzgog: A list is probably a better structure unless you definitely need array order since it does a lot less reallocations.

Maybe this works for you:

Code: Pascal  [Select][+][-]

1. program listtest;
2. {$MODE DELPHI}
3. uses glinkedlist;  // from package flc-stl;
4.  
5. type
6.   Titem = record
7.   x,y,v:integer;
8.   function SetValues(const a,b,c:integer):Titem;
9.   end;
10.  
11.   function Titem.SetValues(const a,b,c:integer):Titem;
12.   begin
13.     x := a;
14.     y := b;
15.     v := c;
16.     Result := self;
17.   end;
18.  
19. var
20.  R:Titem;
21.  MainList:Tlinkedlist<Titem>;
22. begin
23.  mainlist :=Tlinkedlist<Titem>.create;
24.  try
25.    mainList.InsertLast(R.SetValues(1,2,3));
26.   // process some more, see glinkedlist
27.  finally
28.    mainlist.free;
29.  end;
30. end.
31.  
32.  

[marcov]

Thaddy, advanced records are fine for implementing such shorthands for the few cases where it is limiting, but why do you return a copy of that record ?

[Leledumbo]

don't want more overhead by putting creating a procedure/function to do it

inline procedure does not incure any overhead, apart from you need to write it.

Thaddy, advanced records are fine for implementing such shorthands for the few cases where it is limiting, but why do you return a copy of that record ?

He might have forgotten that records are value types

[Thaddy]

He might have forgotten that records are value types

The code is correct for its purpose. The copy is intentional. No leaks, no worries, behavior as expected.
But that list has some limitations I see.
I will write a better example based on the same structure.

[mrguzgog]

A dynamic array of records is the wrong structure in this case, because adding elements leads to a reallocation which is really, really expensive.
A list or something is a far better structure to implement such things.

Ok thanks. I'm familiar with ArrayList in Java and this looks pretty similar. I was doing it like this to get familiar with the way dynamic arrays work in fp.

I hadn't got as far as reading about 'advanced records' and wasn't aware that they could have methods - I like that, rather like D's structs. The record/object/class business seems a bit confusing but it seems I could just ignore objects (I mean 'object type' not instances of a class which are what I think of as objects!).

@marcov: Yes, I don't like that 'dangerous' syntax, it's all too easy to omit or misplace a value - the form you suggest with tags is something I've encountered before.

Thanks all for the replies.

P.S. Is there any downside to compiling in Delphi mode? Does standard fp code still work without modification provided I take account of the things specified here http://www.freepascal.org/docs-html/prog/progse74.html ?

EDIT. Hmm, 'uses glinkedlist' gives me a 'can't find unit' error and I don't see it here: http://wiki.freepascal.org/Data_Structures,_Containers,_Collections
Actually as I only need to add items on the end a vector will do - and that compiles ok.

[Thaddy]

P.S. Is there any downside to compiling in Delphi mode? Does standard fp code still work without modification provided I take account of the things specified here http://www.freepascal.org/docs-html/prog/progse74.html ?

Well, no, you can mix and match on a per unit basis.
I prefer mode delphi because I also work a lot with delphi, but mode objfpc is more strict. Some prefer that.

glinkedlist is in package fcl-stl; You need a recent fpc version for that.

[Leledumbo]

P.S. Is there any downside to compiling in Delphi mode?

No, other than Delphi restriction for certain features applies

Does standard fp code still work without modification provided I take account of the things specified here http://www.freepascal.org/docs-html/prog/progse74.html ?

Yes

EDIT. Hmm, 'uses glinkedlist' gives me a 'can't find unit' error and I don't see it here: http://wiki.freepascal.org/Data_Structures,_Containers,_Collections
Actually as I only need to add items on the end a vector will do - and that compiles ok.

There's no glinkedlist, check your units directory instead of imagining whether a unit exists or not

[mrguzgog]

There's no glinkedlist, check your units directory instead of imagining whether a unit exists or not

From Thaddy's example code:

Code: [Select]

uses glinkedlist;  // from package flc-stl;
I assumed that glinkedlist is part of flc-stl but it seems not. However GVector is and it compiles fine. Is glinkedlist something I'd need to manually add to my installation if I wanted to use it? I can't find any docs for GVector other than http://www.ioinformatics.org/oi/pdf/INFOL101.pdf which is just an outline but guessing from C++ docs works so far

I have another question that probably belongs in its own thread, but, as I mentioned it above...

Code: [Select]

type Location = record
...
end;
var
somevec:        TVector<Location>;

...works when compiling in {$MODE DELPHI} but  {$MODE OBJFPC} gives me ' Error: Generics without specialization cannot be used as a type for a variable'. Why is that?

[Leledumbo]

Is glinkedlist something I'd need to manually add to my installation if I wanted to use it?

No. It's something you have to CREATE, because it doesn't exist ATM.

I can't find any docs for GVector other than http://www.ioinformatics.org/oi/pdf/INFOL101.pdf which is just an outline but guessing from C++ docs works so far

The distributed FPC probably doesn't ship with fcl-stl docs. The source, however, does: http://svn.freepascal.org/svn/fpc/tags/release_3_0_0/packages/fcl-stl/doc/main.pdf

I have another question that probably belongs in its own thread, but, as I mentioned it above...

...works when compiling in {$MODE DELPHI} but  {$MODE OBJFPC} gives me ' Error: Generics without specialization cannot be used as a type for a variable'. Why is that?

Read the documentation, the two modes implement different generics syntax.

[Thaddy]

There's no glinkedlist, check your units directory instead of imagining whether a unit exists or not

What ?
What a load of bull
It is in packages/fcl-stl.... Maybe trunk, but it is there. It is compatible so if you need it, check it out from trunk. I thought it was back-ported to fixes.

[Leledumbo]

There's no glinkedlist, check your units directory instead of imagining whether a unit exists or not

What ?
What a load of bull
It is in packages/fcl-stl.... Maybe trunk, but it is there. It is compatible so if you need it, check it out from trunk. I thought it was back-ported to fixes.

Ah, yes it is in trunk:

Code: [Select]

$ svn log glinkedlist.pp
------------------------------------------------------------------------
r33311 | michael | 2016-03-22 04:01:38 +0700 (Sel, 22 Mar 2016) | 1 line

* Generic linked list class, donated by Denis Volodarsky (bug ID 24501)
------------------------------------------------------------------------


[mrguzgog]

The distributed FPC probably doesn't ship with fcl-stl docs. The source, however, does: http://svn.freepascal.org/svn/fpc/tags/release_3_0_0/packages/fcl-stl/doc/main.pdf
...
Read the documentation, the two modes implement different generics syntax.

Thank you for the link, that document actually answers all questions (how to declare TVector when using {$MODE OBJFPC}, and how to use TVector)