Re: [fpc-pascal] flexible record design
Spir wrote: > I need the simplest and most efficient version, because the type I'm now > designing will be the elementary building block of a rather big system. If you design your class hierarchy well, it ought to be possible to switch the base later on. Personally, I reinvented the wheel by creating my own list framework that suits my needs. If you're interested I'd be happy to share it, although really my first comment ought to trump much interest therein. Cheers, David ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re[2]: [fpc-pascal] stuck with untyped pointer
Hello FPC-Pascal, Saturday, May 29, 2010, 12:34:38 AM, you wrote: >> TObject is the base class, it inherits from nobody. To make the whole >> weel run a base class must exists which provide basic functionality >> like Create/Destroy and other methods/events like "ClassName", >> "InheritsFrom"; so if no class is specified it automatically inherits >> from TObject. AN> I see, and I suspected it was for these reasons, but allow me to say AN> this is some sort of helper functions one might not need. AN> "InhritsFrom", just like Delphi's "Is" (don't know if FPC has the same AN> keyword, anyway) are things that can be dealt with the RTTI... The classes in Pascal are more like "MFC" framework in MSVC. Most functions does not eat a single byte of memory, RTTI are much more memory expensive (maybe somebody corrects me?). >> Pure class in the same idea does not exists in Pascal as in C, or at >> least they do not exists a few time ago. AN> classes in C are just mere structures, with no inheritance capability AN> (i.e no VMT, AFAIK). I'm talking about C99, not C with classes AN> and-or-the-like-extensions to the language. AN> In C++ no base class exists. I can define a "class TMyClass" descending AN> from nothing, and have nothing else than it, as my _base_ class. In Pascal that's a "Object" not a "Class". There was a recent thread about the differences and why Classes are more used than objects. AN> P.S. AN> I'll probably read/reply tomorrow (ok, later today, GMT + 3...), as now AN> I'm tired and wishing to go to bed ;-) Have nice dreams... -- Best regards, José ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re[2]: [fpc-pascal] stuck with untyped pointer
Hello FPC-Pascal, Saturday, May 29, 2010, 12:03:46 AM, you wrote: >> 3) Variable name "val" (Use Value instead, there is a function called >> val). s> Naming problems in object pascal... I could not use "value" s> because it's the name of a method that returns a value, lol! So, I s> used "val". But now I cannot use "val". Will end up with "v". You can use "val" as you can use "struct" as a constructor, but you lost some precision about the intention of the code. When you code in Pascal you should (not must) follow the background idea, like using Create as constructor as you are inheriting from TObject. If a function returns a "Value" usually this method is called "GetValue", Pascal have properties so you do not need to fake functions as they where variables (usual in C code). s> Should we only use single-letter var names to be sure? The only one convention that most people uses is to prefix with F all variables to be accesed by properties, well, and call the events "On". s> Pascal is already problematic with names because of (1) many s> keywords Hmmm... Pascal only have around 30-35 keywords, am I wrong ? s> (2) loads of builtin funcs and procs Hmmm... well, yes. s> (3) case-insensitivity. At least for me this is not a problem at all, at least it avoids things like: A=HWND((A==NULL) ? hwnd : hWND; (its real code, except the "A" which I do not recall the real name). s> But the object layer brings the biggest issue with the implicit s> "self" causing names external to a method to clash with local s> names. Hmmm... I think that this should not happend. Is the case in your posted example ? s> Worse: the compiler _sometimes_ blocks when var names conflict with s> slot names (I have not yet understood when/why it does or not). s> No offense intended, but I consider this as a language-design s> error. (symptom: lexical paralysis ; cause: namespace leak) Var names "slot" names ? Which is a "slot name" ? Can you post a brief example ? -- Best regards, José ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] stuck with untyped pointer
TObject is the base class, it inherits from nobody. To make the whole weel run a base class must exists which provide basic functionality like Create/Destroy and other methods/events like "ClassName", "InheritsFrom"; so if no class is specified it automatically inherits from TObject. I see, and I suspected it was for these reasons, but allow me to say this is some sort of helper functions one might not need. "InhritsFrom", just like Delphi's "Is" (don't know if FPC has the same keyword, anyway) are things that can be dealt with the RTTI... Pure class in the same idea does not exists in Pascal as in C, or at least they do not exists a few time ago. classes in C are just mere structures, with no inheritance capability (i.e no VMT, AFAIK). I'm talking about C99, not C with classes and-or-the-like-extensions to the language. In C++ no base class exists. I can define a "class TMyClass" descending from nothing, and have nothing else than it, as my _base_ class. Not talking about "visual" C/C++ compliers here (which can indeed hide something to ease the RTTI engine help the programmer, somehow), just pure GCC. If I am wrong, please correct me, as this is what I have always had the idea it worked (and _should_ work, FWIW...) Cheers, A. P.S. I'll probably read/reply tomorrow (ok, later today, GMT + 3...), as now I'm tired and wishing to go to bed ;-) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re[2]: [fpc-pascal] stuck with untyped pointer
Hello FPC-Pascal, Saturday, May 29, 2010, 12:09:50 AM, you wrote: >> Struct is declared as "class" so it inherits from TObject if not other >> class is especified. AN> is that true? I don't mean not to trust you, but is the compiler AN> assuming that, or is it a FPC rule? IMO a class is a class, and doesn't AN> inherit from anything else. Unless specified. BTW, From who does TObject AN> inherit then? TObject is the base class, it inherits from nobody. To make the whole weel run a base class must exists which provide basic functionality like Create/Destroy and other methods/events like "ClassName", "InheritsFrom"; so if no class is specified it automatically inherits from TObject. AN> Just asking, I never declare anything as a pure class, or if I do I AN> don't care if it descends from TObject or not, actually... Pure class in the same idea does not exists in Pascal as in C, or at least they do not exists a few time ago. -- Best regards, José ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: ISO Standard Pascal I/O
Me: > ... nextcharacter := input^ ... Does FPC not support this standard Pascal > feature? Jonas: > No, it does not. FPC mainly supports Borland-style Pascal dialects, and they > are not ISO Standard/Extended Pascal compliant. I can live with that, but it would save newcomers a lot of trouble if the documentation were a bit more upfront about what FPC is not. Just saying it implements "some", or "most" of the features of dialect X is a recipe for frustration. > PS: please use a descriptive mail subject in the future. Sorry, netiquette got obscured by red mist :-) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] stuck with untyped pointer
Hi, Struct is declared as "class" so it inherits from TObject if not other class is especified. is that true? I don't mean not to trust you, but is the compiler assuming that, or is it a FPC rule? IMO a class is a class, and doesn't inherit from anything else. Unless specified. BTW, From who does TObject inherit then? Just asking, I never declare anything as a pure class, or if I do I don't care if it descends from TObject or not, actually... If Struct was declared as "Object" that would be another story. no doubt on this. Cheers, A. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] stuck with untyped pointer
On Fri, 28 May 2010 23:07:35 +0200 José Mejuto wrote: > 3) Variable name "val" (Use Value instead, there is a function called > val). Naming problems in object pascal... I could not use "value" because it's the name of a method that returns a value, lol! So, I used "val". But now I cannot use "val". Will end up with "v". Should we only use single-letter var names to be sure? Pascal is already problematic with names because of (1) many keywords (2) loads of builtin funcs and procs (3) case-insensitivity. But the object layer brings the biggest issue with the implicit "self" causing names external to a method to clash with local names. Like if there were no local scope at all. Indeed, the names one would need to use, because they make sense for a given class, are precisely the ones that clash with data or method attributes. Worse: the compiler _sometimes_ blocks when var names conflict with slot names (I have not yet understood when/why it does or not). No offense intended, but I consider this as a language-design error. (symptom: lexical paralysis ; cause: namespace leak) Denis PS: Tricks to work around these problems welcome :-) How do you solve that? (One I won't use because I find it ugly is ___prefixing or postfixing___ all var names, or ___both___.) vit esse estrany ☣ spir.wikidot.com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re[2]: [fpc-pascal] stuck with untyped pointer
Hello FPC-Pascal, Friday, May 28, 2010, 11:24:44 PM, you wrote: AN> I have no more suggestions but the one about deriving your TStruct from AN> TObject, as almost everything in the LCL (and/or VCL, I guess I name AN> them right) is a descendant of it. Struct is declared as "class" so it inherits from TObject if not other class is especified. If Struct was declared as "Object" that would be another story. -- Best regards, José ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] stuck with untyped pointer
ok, now the code fragments look more clear. I have no more suggestions but the one about deriving your TStruct from TObject, as almost everything in the LCL (and/or VCL, I guess I name them right) is a descendant of it. Again. maybe it's not the best thing you'll like to do, but this way IMHO you'll save yourself a lot of frustration ;-) Cheers, A. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] stuck with untyped pointer
Hello FPC-Pascal,
Friday, May 28, 2010, 6:57:42 PM, you wrote:
s>
s> program __essai__;
s> {$mode objfpc}{$H+}
s> uses
s> Classes, SysUtils;
s> type Struct= Class
s> val: Integer;
s> constructor struct(i:Integer);
s> function text : String;
s> end;
Apart the memory leaks wich are quite sure on purpose, you are using a
loudspeaker calling for problems in the future:
1) Constructor with the same name as class name. If you write in code:
procedure Struct.DoSomething;
var
n: Struct;
begin
n:=Struct(0);
end;
Which should the compiler do ? Create a new object n calling the Struct
constructor using 0 as parameter, or cast zero to n ?
2) 2 constructors, one works the other simply does nothing. You can
not "hide" the constructor "Create" as you are inheriting from
TObject.
3) Variable name "val" (Use Value instead, there is a function called
val).
--
Best regards,
José
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] {SOLVED} stuck with untyped pointer
Hello, It was a stupid naming issue: since I couldn't use "new", I had called the Struct constructor "struct" (found it logical, since it returns a struct). But because of case insensibility, I guess, when I wanted to cast back a pointer to Struct, the compiler denoted the constructor instead -- I guess. Anyway, changed Struct.struct to Struct.clone and all runs fine. The kind of bug that could render crazy :-) Thank you for your help. Denis vit esse estrany ☣ spir.wikidot.com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] stuck with untyped pointer
On Fri, 28 May 2010 20:51:10 +0300
Alberto Narduzzi wrote:
> >i := self.names.indexOf(name);
> >val := Struct(self.values[i]);
> > raises "got untyped expected Struct". Sure, that's why I'm trying to
> > cast... Without casting to Struct, the compiler indeed throws "got pointer
> > expected Struct". I'm very surprised since I already did this.
>
> in first place, you can omit self within the object's methods, as it's
> implicitly there.
Right. Just personal preference for expliciteness. (Even if I don't like magic
names.)
> second, the property Values[] expects a string inside "[]" and not a
> number, so you may want to use val := Values[name];
No. Sorry, I was not clear enough. Self here is a Struct, and Struct is custom
class type. Its .values attribute is a TFPList holding objects, which also
happen to be Struct-s; but they could be any kind of pointed thingies. .names
is a TStringList. (*)
My issue is I cannot cast a value (thus a struct) back to its Struct type. The
compiler refuses.
But I can do exactly the same operation, for any reason, with the simpler case
appended to the previous post.
> third, Values return a string (the rightmost part of the "=" if you read
> the items property (or directly l[n])), so you cannot cast it to "Struct".
... see above, and the example. It *is* a Struct.
> I think you intend to do something like:
>
> Var
> MyStruct: Struct;
> MyList: TStringList;
> I: Integer;
>
> (...)
>
> MyList := TStringList.Create();
>
> (...)
>
> For I := 0 To 10 Do
> Begin
>MyStruct := Struct.struct(I);
>MyList.AddObject(Format('struct no. %d', [I]), TObject(MyStruct));
> End;
>
> {cannot remember whether the casting to TObject is necessary or not, or
> any syntax error I might have done, because I'm typing it out of my
> mind, after a year or so I haven't written any pascal code... anyway, I
> suggest you derive your Struct from TObject. And for a matter of
> readability, I also suggest you name it TStruct instead of plainly
> Struct, but this is a matter of taste}
>
> (...)
Yes, thank you for this example. I will probably do this later. But as of now,
since I did not now TStringList implements the "associated object" features, I
use a // TFPList of objects; instead of a TStringList's .Object attribute. hope
it's clear. It's exactly the same scheme, in fact, and I doubt there is any
loss & again at using the one or the other.
> you can now retrieve the objects you added with:
>
> For I := 0 To Pred(MyList.ItemsCount) Do
> Begin
>MyStruct := Struct(MyList.Objects[I]);
This is precisely what the compiler refuses in my case. To be fully explicite,
the above translates in my case (since both container and the values are
structs):
MyStructValue := Struct.(StructContainer.values[I]);
>...do whatever you like with your struct variable here...
> End;
>
> If you need to retrieve your objects using the "names" you need to do
> something like:
>
> I := MyList.IndexOfName("struct no. 6");
> If(I >= 0)
>MyStruct := Struct(MyList.Objects[I]);
Yes, this is the code you commented on top of this post:
> >i := self.names.indexOf(name);
> >val := Struct(self.values[i]);
> bear in mind that free-ing MyList does not free the instances of Struct
> you have created and inserted; so you need to do it manually, in another
> for-cycle, for example...
>
> For I := 0 To Pred(MyList.ItemsCount) Do
> Begin
>MyStruct := Struct(MyList.Objects[I]);
>MyStruct.Free;
> End;
Yes, thank you for this warning. And, believe it or not, this is precisely in
the destructor that the compiler refuses my casting. The reason there is no
test. The whole .free methoid reads (untested since the compiler blocks):
destructor Struct.free;
{ Free values before freeing the structure itself. }
var i: Integer;
val : Struct;
begin
self.names.destroy;
for i:=0 to self.count-1 do begin
val := Struct(self.values[i]);
val.free;
val := nil;
end;
self.values.destroy;
inherited; // useless???
end;
> Or you can descend from TStringList (don't know if this is the best
> thing you could do, but...), and add a property ObjectValues, with a
> proper Getter and Setter expecting a string instead of an integer; like:
No, this does not match my case. I'd rather have a linked list for names since
it is only traversed, to find the index of a value (so the method could follow
pointers, instead of computing them like for an array).
But I keep the code below, thank you, as an example or property implementation
(haven't written any yet).
> property ObjectValues[const AName:String]: TObject Read GetObjectValue
> write SetObjectValue;
>
> Function TMyStringList.GetObjectValue(const AName:String):TObject;
> Var I:Integer;
> Begin
>Result := Nil;
>I := IndexOfName(AName);
>If (I >= 0) Then
> Result := Objects[I];
> End;
>
> Procedure TMyStringList.SetObjectValue(const AName:Str
Re: [fpc-pascal] Re: fpc-pascal Digest, Vol 71, Issue 69
Roger Bailey schrieb: OK, I give up. How do you handle standard input and output files in FPC? When I write something like: nextcharacter := input^ I get "error: 1: Illegal qualifier". Does FPC not support this standard Pascal feature? I have never seen such a syntax before. Shouldn't this be done via READ (and WRITE)? They apply to standard input and output when giving no file name as first parameter. So with var c : char; read(c); should read the next character from standard input I think. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] stuck with untyped pointer
i := self.names.indexOf(name);
val := Struct(self.values[i]);
raises "got untyped expected Struct". Sure, that's why I'm trying to cast... Without
casting to Struct, the compiler indeed throws "got pointer expected Struct". I'm very
surprised since I already did this.
in first place, you can omit self within the object's methods, as it's
implicitly there.
second, the property Values[] expects a string inside "[]" and not a
number, so you may want to use val := Values[name];
third, Values return a string (the rightmost part of the "=" if you read
the items property (or directly l[n])), so you cannot cast it to "Struct".
I think you intend to do something like:
Var
MyStruct: Struct;
MyList: TStringList;
I: Integer;
(...)
MyList := TStringList.Create();
(...)
For I := 0 To 10 Do
Begin
MyStruct := Struct.struct(I);
MyList.AddObject(Format('struct no. %d', [I]), TObject(MyStruct));
End;
{cannot remember whether the casting to TObject is necessary or not, or
any syntax error I might have done, because I'm typing it out of my
mind, after a year or so I haven't written any pascal code... anyway, I
suggest you derive your Struct from TObject. And for a matter of
readability, I also suggest you name it TStruct instead of plainly
Struct, but this is a matter of taste}
(...)
you can now retrieve the objects you added with:
For I := 0 To Pred(MyList.ItemsCount) Do
Begin
MyStruct := Struct(MyList.Objects[I]);
...do whatever you like with your struct variable here...
End;
If you need to retrieve your objects using the "names" you need to do
something like:
I := MyList.IndexOfName("struct no. 6");
If(I >= 0)
MyStruct := Struct(MyList.Objects[I]);
or more rapidly, if you are sure the "name" exists, with
MyStruct := Struct(MyList.Objects[MyList.IndexOfName("struct no. 6")]);
bear in mind that free-ing MyList does not free the instances of Struct
you have created and inserted; so you need to do it manually, in another
for-cycle, for example...
For I := 0 To Pred(MyList.ItemsCount) Do
Begin
MyStruct := Struct(MyList.Objects[I]);
MyStruct.Free;
End;
If you intended to retrieve your objects directly with Names[] and
Values[] then forget it. Unless you descend from TStrings and write the
property accordingly (and all the other virtual methods, of course)
Or you can descend from TStringList (don't know if this is the best
thing you could do, but...), and add a property ObjectValues, with a
proper Getter and Setter expecting a string instead of an integer; like:
property ObjectValues[const AName:String]: TObject Read GetObjectValue
write SetObjectValue;
Function TMyStringList.GetObjectValue(const AName:String):TObject;
Var I:Integer;
Begin
Result := Nil;
I := IndexOfName(AName);
If (I >= 0) Then
Result := Objects[I];
End;
Procedure TMyStringList.SetObjectValue(const AName:String; AObject:TObject);
Var I:Integer;
Begin
I := IndexOfName(AName);
If (I >= 0) Then
Objects[I] := AObject;
End;
As I said, take all this with a grain of salt, as I may have written
mistakes and/or forgot something.
Just my 2c, hope this helps.
Cheers, A.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] ISO Standard Pascal I/O
On 28 May 2010, at 19:27, Roger Bailey wrote: > OK, I give up. How do you handle standard input and output files in FPC? When > I write something like: > > nextcharacter := input^ > > I get "error: 1: Illegal qualifier". Does FPC not support this standard > Pascal feature? No, it does not. FPC mainly supports Borland-style Pascal dialects, and they are not ISO Standard/Extended Pascal compliant. If you want to write ISO Pascal programs, GPC (http://www.gnu-pascal.de/gpc/h-index.html) is probably better suited to your needs. Jonas PS: please use a descriptive mail subject in the future.___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: fpc-pascal Digest, Vol 71, Issue 69
OK, I give up. How do you handle standard input and output files in FPC? When I write something like: nextcharacter := input^ I get "error: 1: Illegal qualifier". Does FPC not support this standard Pascal feature? The documentation is extremely unhelpful in this area. The LRG just says "The default Input, Output and StdErr file types are defined in the system unit", and the system unit describes a record structure that doesn't seem to contain a field that might be a file buffer. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] stuck with untyped pointer
On Fri, 28 May 2010, spir ☣ wrote:
Hello,
While waiting for more information about how to use "associated objects" with TStringList, I
started to implement // lists for names (TString) and values (TFPList). This builds a kind of flexible record
type, I called "Struct" because the name "Record" is not available ;-)
Values are in in fact Struct-s themselves. All works fine when storing data,
but I cannot get it back. Precisely,
i := self.names.indexOf(name);
val := Struct(self.values[i]);
raises "got untyped expected Struct". Sure, that's why I'm trying to cast... Without
casting to Struct, the compiler indeed throws "got pointer expected Struct". I'm very
surprised since I already did this.
So, I quickly wrote a simpler test case wrapping structure, just putting
objects in a TFPList and casting back: all works fine:
If you want this, I suggest you look at fpjson. it does all this for you. It
has an extensive testsuite, so plenty of code to peep at.
Michael.
program __essai__;
{$mode objfpc}{$H+}
uses
Classes, SysUtils;
type Struct= Class
val: Integer;
constructor struct(i:Integer);
function text : String;
end;
constructor Struct.struct(i:Integer);
begin
inherited;
self.val := i;
end;
function Struct.text : String;
begin
result := '<' +intToStr(self.val)+ '>';
end;
var
s: Struct;
l: TFPList;
begin
s := Struct.struct(1);
writeln(s.text);
l := TFPList.create;
l.add(s);
s := Struct(l[0]);//
writeln(s.text);
end.
=== output ===
<1>
<1>
Thank you,
Denis
vit esse estrany ☣
spir.wikidot.com
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] stuck with untyped pointer
Hello,
While waiting for more information about how to use "associated objects" with
TStringList, I started to implement // lists for names (TString) and values
(TFPList). This builds a kind of flexible record type, I called "Struct"
because the name "Record" is not available ;-)
Values are in in fact Struct-s themselves. All works fine when storing data,
but I cannot get it back. Precisely,
i := self.names.indexOf(name);
val := Struct(self.values[i]);
raises "got untyped expected Struct". Sure, that's why I'm trying to cast...
Without casting to Struct, the compiler indeed throws "got pointer expected
Struct". I'm very surprised since I already did this.
So, I quickly wrote a simpler test case wrapping structure, just putting
objects in a TFPList and casting back: all works fine:
program __essai__;
{$mode objfpc}{$H+}
uses
Classes, SysUtils;
type Struct= Class
val: Integer;
constructor struct(i:Integer);
function text : String;
end;
constructor Struct.struct(i:Integer);
begin
inherited;
self.val := i;
end;
function Struct.text : String;
begin
result := '<' +intToStr(self.val)+ '>';
end;
var
s: Struct;
l: TFPList;
begin
s := Struct.struct(1);
writeln(s.text);
l := TFPList.create;
l.add(s);
s := Struct(l[0]);//
writeln(s.text);
end.
=== output ===
<1>
<1>
Thank you,
Denis
vit esse estrany ☣
spir.wikidot.com
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] flexible record design
On Fri, 28 May 2010, spir ☣ wrote: On Fri, 28 May 2010 16:03:28 +0200 (CEST) Michael Van Canneyt wrote: TStrings provides an abstract interface. It allows you to associate an object with each string in the list. This means you can do a L.Strings[i]:=Key; L.Objects[i]:=MyObject; Or, in 1 statement: L.AddObject(Key,MyObject); And you can retrieve it with I:=L.IndexOf(MyKey); If (I=-1) then // no mykey in list else MyObject:=L.Objects[i]; Thank you very much, that's what I needed to understand. If I get it right, using the Objects property is analog to what I intended to do with a TStringList for names // to a TFPList for values. However, it does not actually implement this; it just provides a common API for a string list with associated objects. TStringList actually implements - in a simplistic way - the functionality to store the strings, and the associated objects. All right, now I get it. Just a point about doc: Some methods implemented in TStringList, but virtual in TString, are listed in the interface of TStringList at http://www.freepascal.org/docs-html/rtl/classes/tstringlist.html. But the ones dealings with associated objects aren't listed there (including the Objects property). This feature is also not mentionned in the description. So, I thought TStringList simply does not implement this functionality. Another point: in the description of TList and TFPList is written that the notification system (not implemented on TFPList) is slows down some mechanisms. Is there a version of TStringList without this feature. I need the simplest and most efficient version, because the type I'm now designing will be the elementary building block of a rather big system. TStringList doesn't have the notification mechanism. Michael.___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] flexible record design
On Fri, 28 May 2010 16:03:28 +0200 (CEST) Michael Van Canneyt wrote: > TStrings provides an abstract interface. It allows you to associate an > object with each string in the list. > > This means you can do a > >L.Strings[i]:=Key; >L.Objects[i]:=MyObject; > > Or, in 1 statement: > >L.AddObject(Key,MyObject); > > And you can retrieve it with >I:=L.IndexOf(MyKey); >If (I=-1) then > // no mykey in list >else > MyObject:=L.Objects[i]; Thank you very much, that's what I needed to understand. If I get it right, using the Objects property is analog to what I intended to do with a TStringList for names // to a TFPList for values. > However, it does not actually implement this; it just provides a common > API for a string list with associated objects. > > TStringList actually implements - in a simplistic way - the functionality > to store the strings, and the associated objects. All right, now I get it. Just a point about doc: Some methods implemented in TStringList, but virtual in TString, are listed in the interface of TStringList at http://www.freepascal.org/docs-html/rtl/classes/tstringlist.html. But the ones dealings with associated objects aren't listed there (including the Objects property). This feature is also not mentionned in the description. So, I thought TStringList simply does not implement this functionality. Another point: in the description of TList and TFPList is written that the notification system (not implemented on TFPList) is slows down some mechanisms. Is there a version of TStringList without this feature. I need the simplest and most efficient version, because the type I'm now designing will be the elementary building block of a rather big system. Denis vit esse estrany ☣ spir.wikidot.com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpweb fcgi: auto shutdown feature
On Fri, 28 May 2010, Bee Jay wrote: Hi all, After a bit studying fpWeb package, especially the FCGI application, I have a feature request to it. Would you (Joost? Michael?) please add auto shutdown (after some idle time) feature to TFCGIApplication? If you had looked at ExtPascal's FCGI implementation, it offers this feature. This feature is to prevent the FCGI app keep always running when it actually does nothing (idle). For some situations, this feature is usefull and handy. I saw the CGI gateway already able to execute local FCGI app if it fails to connect to it. I know I should supply a patch for this. But I'm not that confident to do it because I don't think I already got a good grasp to the code. The class hirarchy and dependency is quite complex, at least to me. I'm afraid I'm gonna mess them up. :D Or, if you don't have time to do it, please give me some lights about how to implement this feature correctly (how and where). For any response, I thank you in advance. :) Unless Joost does it first, I'll have a look at it next week. But it will be under control of an option, and this option will be 'off' by default. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] fpweb fcgi: auto shutdown feature
Hi all, After a bit studying fpWeb package, especially the FCGI application, I have a feature request to it. Would you (Joost? Michael?) please add auto shutdown (after some idle time) feature to TFCGIApplication? If you had looked at ExtPascal's FCGI implementation, it offers this feature. This feature is to prevent the FCGI app keep always running when it actually does nothing (idle). For some situations, this feature is usefull and handy. I saw the CGI gateway already able to execute local FCGI app if it fails to connect to it. I know I should supply a patch for this. But I'm not that confident to do it because I don't think I already got a good grasp to the code. The class hirarchy and dependency is quite complex, at least to me. I'm afraid I'm gonna mess them up. :D Or, if you don't have time to do it, please give me some lights about how to implement this feature correctly (how and where). For any response, I thank you in advance. :) -Bee- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] flexible record design
On Fri, 28 May 2010, spir ☣ wrote: On Fri, 28 May 2010 12:25:59 +0200 Felipe Monteiro de Carvalho wrote: I would like to know the underlying structure of TString (linked list, "flexible-ised" dynamic array, what else?). TStrings provides no storage. I think that TStringList should be what you are looking for. See it's code instead. I know about TStringList. But it does not provide associated values & objects. The reason why I ask about what these things are (supposed to be) in the interface of TStrings. I have a better idea about values, now. Seem to be strings as well (the name "value" is a bit misleading imo), so not what I need at all. But I'm still digging to try and find out what object association is *intended* to be, its purpose and possible implementation. In other word, what's the actual aim of this virtual interface? The doc reads: "Indexed access to the objects associated with the strings in the list. [...] Objects provides indexed access to the objects associated to the strings in the list. Index is a zero-based index and must be in the range of 0 to Count-1. Setting the objects property will not free the previously associated object, if there was one. The caller is repsonsible for freeing the object that was previously associated to the string. TStrings does not implement any storage for objects. Reading the Objects property will always return Nil, Setting the property will have no effect. It is the responsability of the descendent classes to provide storage for the associated objects." This is not stupid enough for me. I don't know what to do with this. TStrings provides an abstract interface. It allows you to associate an object with each string in the list. This means you can do a L.Strings[i]:=Key; L.Objects[i]:=MyObject; Or, in 1 statement: L.AddObject(Key,MyObject); And you can retrieve it with I:=L.IndexOf(MyKey); If (I=-1) then // no mykey in list else MyObject:=L.Objects[i]; However, it does not actually implement this; it just provides a common API for a string list with associated objects. TStringList actually implements - in a simplistic way - the functionality to store the strings, and the associated objects. The 'Values' property is for Name=Value pairs, where both are strings. (used commonly in .ini files) That means that if you do L.Add(mykey+'='+myvalue); or, alternatively L.Values[mykey]=myvalue; you can retrieve myvalue with MyValue:=L.Values[mykey]; The objects are not used in this case, the list contains items of the form Name=Value. This is not very performant, but works easily for small amounts of values. For large amounts of data, you should use hash lists, as implemented in the contnrs unit. Michael.___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] flexible record design
On Fri, 28 May 2010 12:25:59 +0200 Felipe Monteiro de Carvalho wrote: > > I would like to know the underlying structure of TString (linked list, > > "flexible-ised" dynamic array, what else?). > > TStrings provides no storage. > > I think that TStringList should be what you are looking for. See it's > code instead. I know about TStringList. But it does not provide associated values & objects. The reason why I ask about what these things are (supposed to be) in the interface of TStrings. I have a better idea about values, now. Seem to be strings as well (the name "value" is a bit misleading imo), so not what I need at all. But I'm still digging to try and find out what object association is *intended* to be, its purpose and possible implementation. In other word, what's the actual aim of this virtual interface? The doc reads: "Indexed access to the objects associated with the strings in the list. [...] Objects provides indexed access to the objects associated to the strings in the list. Index is a zero-based index and must be in the range of 0 to Count-1. Setting the objects property will not free the previously associated object, if there was one. The caller is repsonsible for freeing the object that was previously associated to the string. TStrings does not implement any storage for objects. Reading the Objects property will always return Nil, Setting the property will have no effect. It is the responsability of the descendent classes to provide storage for the associated objects." This is not stupid enough for me. I don't know what to do with this. Denis vit esse estrany ☣ spir.wikidot.com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] flexible record design
Hello, 2010/5/28 spir ☣ : > Side-question: What is the purpose of introducing unimplemented methods? > Sub-classes can extend a super-class anyway, no? Is it just an incentive to > implement those methods? TStrings is a an abstract class, which means that you shouldn't use it directly. It only provides guidelines for implementing a TStrings like class. > I would like to know the underlying structure of TString (linked list, > "flexible-ised" dynamic array, what else?). TStrings provides no storage. I think that TStringList should be what you are looking for. See it's code instead. -- Felipe Monteiro de Carvalho ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] flexible record design
Hello, I'm looking for a "convenient" way to implement a type for kinds of flexible records. "Best" means simple and efficient. A flexible record is a kind of set of name:value symbol, but completely modifyable at runtime. The necessary untyped aspect of the question is handled by values beeing pointers. Compared to a mapping *collection*, these objects have some specificity: * conceptually, each one forms a single, whole, data unit -- as opposed to a set of data. * Keys are all names (thus, a subset of string), and rather short. * The number of symbols is typically small; these object are defined by hand! As opposed to extremely varying & possibly huge numbers of collection items. The most important operation for such an object is value lookup. Some trials have shown me that data structures with sophisticated algorithms such as radix tries or hash table are counter productive (they are severely outperformed by simple sequences up to > 100 items). --> http://groups.google.com/group/pilud/browse_thread/thread/9d7992f97c976cef# The simplest method may be to create a tool type for name:value symbols, and put this into a TFPList. Lookup is thus traversing the sequence, checking the name until found, returning the value. Another way would be to hold // sequences for names and values. Lookup should be faster, since names are not hidden in symbol structure. Once a name's index is known, the matching value can be reached using this index. I guess the name sequence could be at best a linked list, since it's only traversed; while values, which are only indexed, should be held in a flexible array (TFPList) for direct indexing. Comments? But I'm a bit troubled by the documentation about TStrings. TStrings declares interface methods to deal with "associated objects" (not implemented) and "value parts", eg: function AddObject(); virtual; Add a string and associated object to the list. property ValueFromIndex: String; [rw] Return the value part of a string based on it's index. The description of the type reads: "... It also allows an arbitrary object to be associated with each string. It also introduces methods to manage a series of name=value settings, as found in many configuration files..." Side-question: What is the purpose of introducing unimplemented methods? Sub-classes can extend a super-class anyway, no? Is it just an incentive to implement those methods? I would like to know the underlying structure of TString (linked list, "flexible-ised" dynamic array, what else?). What is actually a name:value association? How does it work and how is one supposed to use it? The _name_ of the feature perfectly fits my needs :-) but can I use it for my flexible record type? Associated objects are not implemented at all (all methods virtual). How is one supposed to design such a feature? Associate a // list of objects (maintaining matching indexes)? But if a TString is an array, lookup is probably slower than necessary (since it's a plain traversal), or am I wrong on this? Thank you for your patience with a newcomer :-) Denis vit esse estrany ☣ spir.wikidot.com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC bug or brain bug ?
> It is allowed in Delphi and TP because they allow declaring typed constants > of objects. Exactly what I wanted to use. I'll have to use constructors so. Thank you for your help. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
