accessing array members in dictionary

[TRon]

waitwaitwait. Function high() works fine. The issue is in for loop. If I assign high() to a variable and use it in the loop, loop works fine. But direct use of high() in for loop gives an error. For loop doesn't like high() function with array nested in object nested further in dictionary. Don't know if I make sense.

Perfect sense because I figured it out as well. As a workaround I was going to propose to use a temp var for the low and high keys and use those for the actual loop. You figured it is only the high part so as a workaround you could indeed use that.

What a strange thing that my examples did not show that behaviour while your example clearly does. :looks at bottom of empty bottle:

[Weiss]

cheers. Thank you TRon. Get some rest,  .

[TRon]

Thank matey, and I will.

For sure to never trust a book by its cover is applicable here. It is at least enough to drive one completely insane 

Thank you for this very interesting showcase of behavioural difference. These don't come along that often.

[cdbc]

Hi
What I meant was this:

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

1.   TClassWithArray = class(TObject)
2.   private
3.     fValue : integer;
4.     farrayOfReal : array of real;
5.     GetReal(Index: ptrint): real;
6.     SetReal(Index: ptrint;aValue: real);
7.   public
8.     function CountOfArray: ptrint;
9.     property Reals[Index: ptrint]: real read GetReal write SetReal; default;
10.   end;
11.  
12. ....
13.  
14. function TClassWithArray.GetReal(Index: ptrint): real;
15. begin
16.   Result:= farrayOfReal[Index];
17. end;
18.  
19. procedure TClassWithArray.SetReal(Index: ptrint;aValue: real);
20. begin
21.   farrayOfReal[Index]:= aValue;
22. end;
23.  
24. function TClassWithArray.CountOfArray: ptrint;
25. begin
26.   Result:= length(farrayOfReal);
27. end;
28.  

This is just an example...
Regards Benny

[Weiss]

Benny, I totally understood what everybody was saying from beginning. The trouble was that I did not dig deep enough prior to asking questions. My classes do not have private area, I should have had free access to arrays and members without getters and setter methods. But I much appreciate your example, because I am still not comfortable with pointers. Thank you Benny.

[jamie]

You are killing yourself over this.

For String and Object pairs, why not simply use the TStringList ?

I too found issues using the Generics.Dictionary, it generates compiler errors of .LJxxxx something and basically not usable here.

 It appears things get erratic when code starts to get large. On top of that, I also find there are strange effects using some of the generics in the Generic.Collections unit, So I don't use it, I end up using the FPC generics and that seems to work ok.

 However, I will say this, the generics for the Delphi compiler seem not to have these issues. Go figure?

Jamie

[Weiss]

Hi Jamie. I hear you. I struggle from very beginning, should I or should I not use dictionaries. They are fun to use, though same functionality is just a few lines of code away.

[jamie]

That error message you get, I bet it shows at the end of the main source file in the status window.

 In any case, Generics are ok for some things, but I think they get too much hype in areas where straight line code works much better.

 You must remember that you are dealing with someone else's interpretation of how the code should work when using generics, you just simply provide the types for things like the Dictionary for example.

 The same could be true with TStringList but at least there, its code has been used and proven for some time now.
 

 If you want to test the FPC compiler for its ability to build complex generics, the Generic.Collections is a good one, although small in comparison of what it should be able to tackle.

  I believe there are those that have nothing better to do than see how complex they can make code look and tax the compiler for bugs and then go brag about it.

Jamie

[TRon]

What I meant was this:
...

aah, ok. Got you. Thank you for the elaborated example because in hindsight I completely misunderstood your initial hint.

I too found issues using the Generics.Dictionary, it generates compiler errors of .LJxxxx something and basically not usable here.

It appears things get erratic when code starts to get large. On top of that, I also find there are strange effects using some of the generics in the Generic.Collections unit, So I don't use it, I end up using the FPC generics and that seems to work ok.

However, I will say this, the generics for the Delphi compiler seem not to have these issues. Go figure?

Generics are perfectly use-able. That the current implementation generates wrong code under certain conditions has nothing to do with it. These must be mentioned when encountered so that they can be addressed (in this particular case of TS it already seem to have been taken care of).

Delphi has a team of paid developers while FPC has only a handful of them that are not being paid /et all/. In practice it boils down to one or two people working on generics and in case you have been keeping track you would know there are still many open cases regarding generics simply because there are many situations in which generics can be used and/or combined and that have not all been tested. When you factor in that feature that Delphi does support and FPC not while being in demand then things get messy pretty fast. It is about the war, not a single battle 

So yeah, you'll certainly and currently be able to find many cases where generics will fail and will fail on the front-end, back-end and in between.

Silencing them to death is and will not be very helpful. That goes for every new feature and addition of the compiler btw.