Hello FPC-Pascal,
you wrote> That's not a matter of support,
V> maybe a poorly placed moan there... was getting annoyed with Indy/XML not V> doing what I wanted.
V> i gave up trying to get XPath and XML Namespaces to work recently... whereas V> ive had XPath+Namespaces working in php in the past... V> in fairness it might be ok in FPC (although its not in the XML tutorial), V> ive been using RAD 2010 because Indy WebDAV wasnt working in Lazarus :(
Well, I can not help on that topic, simply not Indy, in the past I tried to compile Indy in Lazarus but it is terrible Windows and Delphi centric. I was able to do it but with some non clear changes so I do not know at all if everything works :-?
> code). So if you keep that information people will complaint about
> memory footprint and compiler not hidding internal program structures
> and other now complaint about it can not writeln a record :-?
V> indeed, i would be complaining about size/speed. V> thats a good point about what is known after compilation. does 'array of V> string' just become a blob of memory, with no type information?
An array of string yes, it have some information, the only one needed to be accessed :) But a record is a different beast, I'm quite sure that one of the fpc developers can give you more detailed information about the inners, but as a simple example at compile time a record like:
type RR = record
A1: integer;
B1: byte;
end;
and accesing it like:
var
MyRR: RR;
begin
MyRR.A1:=1000;
MyRR.B1:=10;
end;
In a language like PHP it is accessed just as the code looks like, it takes where the MyRR is located in memory, then access to field A1 and change the value. In a compiled language it is directly replaced for the field A1 position in stack and accessed. So pseudo code execution in php would be something like:
- Get MyRR address.
- Scan fields in MyARR looking for A1 field.
- Take the A1 memory address
- Check type of A1 and the type of the value to be written.
- They match (same type) so write the new value in A1.
In a compiled language (without runtime checks, like overflow, etc...):
- Store 1000 in stack position - X bytes. dot.
V> so the solution would be an overloaded ArrayToStr; V> - ArrayToStr(AArray: string)
V> - ArrayToStr(AArray: int), etc?
If you plan only to use those kind of arrays, yes.
> If you want to do something like that replace yout records with
> classes and put the fileds in the published section so you will have
> RTTI information about the class and you can write a generic writeln
> function for classes writting the published fields.
V> isn't there already something like this for writing .lfm files?
Yes, lfm files are based in the RTTI of each class.
Best regards,
José
