Re: [fpc-devel] Templates / Generics
Mattias Gaertner wrote: This page looks only like the start of a proposal. Neither complete nor official. Why do you think, that D2006 will have generics? D2006 D11=D2007 How will Delphi handle the following case with overloads and different types: unit test; interface type ListT = class data : T; constructor(aData: T); procedure dump; end; implementation procedure show(i:integer);overload; begin end; procedure show(s:string);overload; begin end; constructor ListT(aData: T); begin Data := aData; end; procedure ListT.Dump; begin Show(Data); end; end. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
Peter Vreman wrote: Mattias Gaertner wrote: This page looks only like the start of a proposal. Neither complete nor official. Why do you think, that D2006 will have generics? D2006 D11=D2007 How will Delphi handle the following case with overloads and different types: If it is handled as a kind of macro, then it is no problem. The type of data is known at compile time. If the generic is precompiled (which is maybe necesary if you need access to privates) then I fear some runtime logic has to be added to call the correct procedure. IE. something like case TypeInfo(Data) of StringType: Show(Data); IntegerType: Show(Data); end; Marc unit test; interface type ListT = class data : T; constructor(aData: T); procedure dump; end; implementation procedure show(i:integer);overload; begin end; procedure show(s:string);overload; begin end; constructor ListT(aData: T); begin Data := aData; end; procedure ListT.Dump; begin Show(Data); end; end. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
Marc Weustink wrote: Peter Vreman wrote: How will Delphi handle the following case with overloads and different types: If the generic is precompiled (which is maybe necesary if you need access to privates) then I fear some runtime logic has to be added to call the correct procedure. IE. something like case TypeInfo(Data) of StringType: Show(Data); IntegerType: Show(Data); end; The whole idea of Generics is to avoid this :-) Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
Peter Vreman wrote: How will Delphi handle the following case with overloads and different types: The restriction to use generic types only in (assignment to)/(passing to procedure) of the same generic type is too big a restriction ? If you want to do this, one should instantiate it first .. ? Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
Micha Nelissen wrote: Marc Weustink wrote: Peter Vreman wrote: How will Delphi handle the following case with overloads and different types: If the generic is precompiled (which is maybe necesary if you need access to privates) then I fear some runtime logic has to be added to call the correct procedure. IE. something like case TypeInfo(Data) of StringType: Show(Data); IntegerType: Show(Data); end; The whole idea of Generics is to avoid this :-) I mean generated by the compiler, not by the user Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
On Friday 04 November 2005 09:25, Micha Nelissen wrote: Marc Weustink wrote: If the generic is precompiled (which is maybe necesary if you need access to privates) then I fear some runtime logic has to be added to call the correct procedure. IE. something like case TypeInfo(Data) of StringType: Show(Data); IntegerType: Show(Data); end; The whole idea of Generics is to avoid this :-) At user level, yes. But as a compiler-writer you'd gotta make it work somehow. Vinzent. -- public key: http://www.t-domaingrabbing.ch/publickey.asc pgp8YjRx3wBer.pgp Description: signature ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
Peter Vreman wrote:
Mattias Gaertner wrote:
This page looks only like the start of a proposal. Neither complete nor
official.
Why do you think, that D2006 will have generics?
D2006 D11=D2007
How will Delphi handle the following case with overloads and different types:
unit test;
interface
type
ListT = class
data : T;
constructor(aData: T);
procedure dump;
end;
implementation
procedure show(i:integer);overload;
begin
end;
procedure show(s:string);overload;
begin
end;
constructor ListT(aData: T);
begin
Data := aData;
end;
procedure ListT.Dump;
begin
Show(Data);
end;
end.
It will be eaten, but as soon as you instanziate with non-integer/non-string you
get an error, see also C++:
#include string
using namespace std;
void show(int i)
{
}
void show(string s)
{
}
templatetypename T class test
{
public:
T data;
void p()
{
show(data);
}
};
testint mytest1;
testint * mytest2;
int main()
{
mytest1.p();
mytest2.p();
}
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics Syntax
Daniël Mantione wrote: Op Thu, 3 Nov 2005, schreef Mattias Gaertner: Here is a proposal of the syntax: type TGenericClassT,F = class public procedure Add(Item: T; Flag: F); end; This syntax is almost impossible to implement since in one of your other mails the symbols to mark the parameters appear in regular source code: begin generictypeAinteger.create end. It will be very hard for the parser to see the difference in advance between: variableinteger(another_var) generic_typeinteger Only when the symbol is parsed the result is known. Maybe the parser may be able lookup the type first and make a decision based on that, but it would be in the middle of a recursive expression parse designed for infix operators. Also in C++ this sometimes causes trouble where you need to change your code notation so the compiler eats it. I don't know if this proposal suffers from this mess, but we should avoid at all cost to import it into Pascal. On the wiki pages some of my remarks got lost (or I didn't write them down) but when I first looked at the notation style it looks very unpascalish for me. I like more to add a new keyword for it, like the samples wiht generic or template) BTW, what woud be the problem with type TMySpecificClass = TGenericClass(TObject, Integer); var MSC: TMySpecificClass; begin MSC := TMySpecificClass.Create Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics Syntax
Daniël Mantione wrote: Op Thu, 3 Nov 2005, schreef Mattias Gaertner: Here is a proposal of the syntax: type TGenericClassT,F = class public procedure Add(Item: T; Flag: F); end; This syntax is almost impossible to implement since in one of your other mails the symbols to mark the parameters appear in regular source code: begin generictypeAinteger.create end. It will be very hard for the parser to see the difference in advance between: I wouldn't allow specialization in the procedure body. That's unpascalish, you can' do ((^char)(p))^:=#0; but you need to define a pchar in a type section and do pchar(p)^:=#0; By forbidding that we can come back to the ... . variableinteger(another_var) generic_typeinteger Only when the symbol is parsed the result is known. Maybe the parser may be able lookup the type first and make a decision based on that, but it would be in the middle of a recursive expression parse designed for infix operators. Also in C++ this sometimes causes trouble where you need to change your code notation so the compiler eats it. I don't know if this proposal suffers from this mess, but we should avoid at all cost to import it into Pascal. Daniël ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Re: Templates / Generics Syntax
Op Thu, 3 Nov 2005, schreef Mattias Gaertner: Here is a proposal of the syntax: type TGenericClassT,F = class public procedure Add(Item: T; Flag: F); end; This syntax is almost impossible to implement since in one of your other mails the symbols to mark the parameters appear in regular source code: begin generictypeAinteger.create end. It will be very hard for the parser to see the difference in advance between: variableinteger(another_var) generic_typeinteger Only when the symbol is parsed the result is known. No, already after the second token after the opening . It must either be a ,, or the closing bracket. Assuming that you disallow something like generic_typegeneric_type2... Even that limitation can be overcome by disallowing directly nested generic use specification. Something like type TGeneric2 = generic_type2...; generic_typeTGeneric2 ... could be allowed however. Maybe the parser may be able lookup the type first and make a decision based on that, but it would be in the middle of a recursive expression parse designed for infix operators. Simply use a second, third, ... lookahead token for the case. Also in C++ this sometimes causes trouble where you need to change your code notation so the compiler eats it. I don't know if this proposal suffers from this mess, but we should avoid at all cost to import it into Pascal. From: Mattias Gaertner [EMAIL PROTECTED] On Thu, 3 Nov 2005 19:59:40 +0100 (CET) Daniël Mantione [EMAIL PROTECTED] wrote: Right. I didn't think of that. What about edged brackets? type TGenericClass[T,F] = class public procedure Add(Item: T; Flag: F); end; procedure TGenericClass.Add(Item: T; Flag: F); // Note: No redundant [T,F] after TGenericClass. begin end; type TListOfComponent = TGenericList[TComponent]; Analog: type TGenericListClass[T] = class of TGenericList[T]; type PGenericRecord[T] = ^TGenericRecord[T]; procedure GenericProc[T](Param: T); begin end; I think this has a similar problem to the other one. Consider this: my_procedure[... where my_procedure isn't an instantiation of a method using the generic but a function returing an array of something. Not completely sure whether this is a problem though... depends on the implementation. Regards, Thomas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Templates / Generics Syntax
On Fri, 04 Nov 2005 12:56:03 +0100 Thomas Schatzl [EMAIL PROTECTED] wrote: Op Thu, 3 Nov 2005, schreef Mattias Gaertner: Here is a proposal of the syntax: type TGenericClassT,F = class public procedure Add(Item: T; Flag: F); end; This syntax is almost impossible to implement since in one of your other mails the symbols to mark the parameters appear in regular source code: begin generictypeAinteger.create end. It will be very hard for the parser to see the difference in advance between: variableinteger(another_var) generic_typeinteger Only when the symbol is parsed the result is known. No, already after the second token after the opening . It must either be a ,, or the closing bracket. .. or '.'. E.g. genericunit.type Assuming that you disallow something like generic_typegeneric_type2... Even that limitation can be overcome by disallowing directly nested generic use specification. Something like type TGeneric2 = generic_type2...; generic_typeTGeneric2 ... could be allowed however. I second that. We should try to avoid anonymous types (genericgenerictype). It's bad programming style. [...] From: Mattias Gaertner [EMAIL PROTECTED] On Thu, 3 Nov 2005 19:59:40 +0100 (CET) Daniël Mantione [EMAIL PROTECTED] wrote: Right. I didn't think of that. What about edged brackets? type TGenericClass[T,F] = class public procedure Add(Item: T; Flag: F); end; procedure TGenericClass.Add(Item: T; Flag: F); // Note: No redundant [T,F] after TGenericClass. begin end; type TListOfComponent = TGenericList[TComponent]; Analog: type TGenericListClass[T] = class of TGenericList[T]; type PGenericRecord[T] = ^TGenericRecord[T]; procedure GenericProc[T](Param: T); begin end; I think this has a similar problem to the other one. Consider this: my_procedure[... where my_procedure isn't an instantiation of a method using the generic but a function returing an array of something. You mean for example: function my_function: TList; where TList has a default indexed property. Ok, so (! !) would be better. But see other mails, about where Delphi goes. It seems they will use the syntax. Not completely sure whether this is a problem though... depends on the implementation. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics Syntax
On Fri, 04 Nov 2005 10:47:42 +0100 Marc Weustink [EMAIL PROTECTED] wrote: Daniël Mantione wrote: Op Thu, 3 Nov 2005, schreef Mattias Gaertner: Here is a proposal of the syntax: type TGenericClassT,F = class public procedure Add(Item: T; Flag: F); end; This syntax is almost impossible to implement since in one of your other mails the symbols to mark the parameters appear in regular source code: begin generictypeAinteger.create end. It will be very hard for the parser to see the difference in advance between: variableinteger(another_var) generic_typeinteger Only when the symbol is parsed the result is known. Maybe the parser may be able lookup the type first and make a decision based on that, but it would be in the middle of a recursive expression parse designed for infix operators. Also in C++ this sometimes causes trouble where you need to change your code notation so the compiler eats it. I don't know if this proposal suffers from this mess, but we should avoid at all cost to import it into Pascal. On the wiki pages some of my remarks got lost (or I didn't write them down) but when I first looked at the notation style it looks very unpascalish for me. I like more to add a new keyword for it, like the samples wiht generic or template) BTW, what woud be the problem with type TMySpecificClass = TGenericClass(TObject, Integer); What about proc generics: GenericProc(TObject) This can be ambigious. var MSC: TMySpecificClass; begin MSC := TMySpecificClass.Create Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
On Fri, 04 Nov 2005 08:38:03 +0100 [EMAIL PROTECTED] wrote: Alexey Barkovoy wrote: Delphi 11 .Net 2.0 will support Generics. Maybe Delphi 11 Win32. This page looks only like the start of a proposal. Neither complete nor official. Why do you think, that D2006 will have generics? Not Delphi 2006, but Delphi 2007 Thanks for the hint. Although the interesting question is: Will Delphi get generics this decade and how will they work? It seems, they want the same syntax as their C compilers and their .NET code. So, there is a good chance, that it will be the notation, which gives additional trouble for the parser. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics Syntax
Marc Weustink wrote: BTW, what woud be the problem with type TMySpecificClass = TGenericClass(TObject, Integer); Or: code type TGenericCollection = generic(T: TCollectionItem) class(TComponent) ...implement TCollection and use T end; TCollection = TGenericCollection of (TCollectionItem); TFieldDefs = TGenericCollection of (TFieldDef); /code And: code type TGenericList = generic(T: PtrInt) class(TObject) ...implement TList and use PtrInt size for code generation end; TList = TGenericList of (Pointer); /code Combining some of the wiki ideas, and has no evil characters :-). Probably TFieldDefs adds functionality to TCollection, but it was first example I came up with. Implementation of TGenericCollection can be compiled as if (T: TCollectionItem) were used. Would this solve the circular dependency ? It seems so to me, because one knows at least as much as in current implementation of these classes, but I'm no compiler engineer. Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics Syntax
On Fri, 04 Nov 2005 13:44:55 +0100 Marc Weustink [EMAIL PROTECTED] wrote: Mattias Gaertner wrote: On Fri, 04 Nov 2005 10:47:42 +0100 Marc Weustink [EMAIL PROTECTED] wrote: Daniël Mantione wrote: Op Thu, 3 Nov 2005, schreef Mattias Gaertner: Here is a proposal of the syntax: type TGenericClassT,F = class public procedure Add(Item: T; Flag: F); end; This syntax is almost impossible to implement since in one of your other mails the symbols to mark the parameters appear in regular source code: begin generictypeAinteger.create end. It will be very hard for the parser to see the difference in advance between: variableinteger(another_var) generic_typeinteger Only when the symbol is parsed the result is known. Maybe the parser may be able lookup the type first and make a decision based on that, but it would be in the middle of a recursive expression parse designed for infix operators. Also in C++ this sometimes causes trouble where you need to change your code notation so the compiler eats it. I don't know if this proposal suffers from this mess, but we should avoid at all cost to import it into Pascal. On the wiki pages some of my remarks got lost (or I didn't write them down) but when I first looked at the notation style it looks very unpascalish for me. I like more to add a new keyword for it, like the samples wiht generic or template) BTW, what woud be the problem with type TMySpecificClass = TGenericClass(TObject, Integer); What about proc generics: GenericProc(TObject) This can be ambigious. How would you have declared the proc, and how do you call it. I don't see a problem yet. GenericProc(TObject)(some params) you mean ? Example: procedure MyProc(T); // generic procedure without parameters ver i: T; begin ... end; procedure MyProc(T: TClass); // non generic procedure begin end; Call MyProc(TObject); What will happen? Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics Syntax
Micha Nelissen wrote: Marc Weustink wrote: BTW, what woud be the problem with type TMySpecificClass = TGenericClass(TObject, Integer); Or: code type TGenericCollection = generic(T: TCollectionItem) class(TComponent) ...implement TCollection and use T end; TCollection = TGenericCollection of (TCollectionItem); TFieldDefs = TGenericCollection of (TFieldDef); /code And: code type TGenericList = generic(T: PtrInt) class(TObject) ...implement TList and use PtrInt size for code generation end; TList = TGenericList of (Pointer); /code Combining some of the wiki ideas, and has no evil characters :-). Probably TFieldDefs adds functionality to TCollection, but it was first example I came up with. Implementation of TGenericCollection can be compiled as if (T: TCollectionItem) were used. Would this solve the circular dependency ? It seems so to me, because one knows at least as much as in current implementation of these classes, but I'm no compiler engineer. Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel Are the () required? Why not TSomeList = TGenericList of Pointer; ? Ales ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics Syntax
Example: procedure MyProc(T); // generic procedure without parameters ver i: T; begin ... end; procedure MyProc(T: TClass); // non generic procedure begin end; Call MyProc(TObject); What will happen? Mattias Sky will reign fire: procedure (var T); begin // generic or not?? end; ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics Syntax
Ales Katona wrote: Micha Nelissen wrote: Marc Weustink wrote: BTW, what woud be the problem with type TMySpecificClass = TGenericClass(TObject, Integer); Or: code type TGenericCollection = generic(T: TCollectionItem) class(TComponent) ...implement TCollection and use T end; TCollection = TGenericCollection of (TCollectionItem); TFieldDefs = TGenericCollection of (TFieldDef); /code And: code type TGenericList = generic(T: PtrInt) class(TObject) ...implement TList and use PtrInt size for code generation end; TList = TGenericList of (Pointer); /code Combining some of the wiki ideas, and has no evil characters :-). Probably TFieldDefs adds functionality to TCollection, but it was first example I came up with. Implementation of TGenericCollection can be compiled as if (T: TCollectionItem) were used. Would this solve the circular dependency ? It seems so to me, because one knows at least as much as in current implementation of these classes, but I'm no compiler engineer. Micha Are the () required? Why not TSomeList = TGenericList of Pointer; ? You can have more types code type TList = TGenericList of (Pointer, Pointer); /code Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics Syntax
Micha Nelissen wrote: code type TGenericCollection = generic(T: TCollectionItem) class(TComponent) ...implement TCollection and use T end; TCollection = TGenericCollection of (TCollectionItem); TFieldDefs = TGenericCollection of (TFieldDef); /code So generic procs could look like: code function generic(T: TTreeItem) MyFunc(A: T): T; begin // do something with the tree item end; /code My restrictions won't allow implementing generic Max and Min, I guess. That really needs macro-alike stuff (for the compiler implementation). The syntax could look like: code function generic(T) Max(A, B: T): T; begin if A B then Result := B else Result := A; end; /code Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics Syntax
On Friday 04 November 2005 13:00, Micha Nelissen wrote: Combining some of the wiki ideas, and has no evil characters :-). I don't understand the fuzz about using . It's not even close to being C(++)-ish, because it was used for describing discrete range types _at least_ in Ada's generics back in 1983[*] already. Perhaps someone should take a look at those, because these are also quite different from C++-templates. Vinzent. [*] That would be the same year the term C++ just appeared first in history of programming languages then, and this particular C++ didn't even have templates yet. -- public key: http://www.t-domaingrabbing.ch/publickey.asc pgp3kje8Y8SWV.pgp Description: signature ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics Syntax
Mattias Gaertner wrote: On Fri, 04 Nov 2005 13:44:55 +0100 Marc Weustink [EMAIL PROTECTED] wrote: Mattias Gaertner wrote: On Fri, 04 Nov 2005 10:47:42 +0100 Marc Weustink [EMAIL PROTECTED] wrote: Daniël Mantione wrote: Op Thu, 3 Nov 2005, schreef Mattias Gaertner: Here is a proposal of the syntax: type TGenericClassT,F = class public procedure Add(Item: T; Flag: F); end; This syntax is almost impossible to implement since in one of your other mails the symbols to mark the parameters appear in regular source code: begin generictypeAinteger.create end. It will be very hard for the parser to see the difference in advance between: variableinteger(another_var) generic_typeinteger Only when the symbol is parsed the result is known. Maybe the parser may be able lookup the type first and make a decision based on that, but it would be in the middle of a recursive expression parse designed for infix operators. Also in C++ this sometimes causes trouble where you need to change your code notation so the compiler eats it. I don't know if this proposal suffers from this mess, but we should avoid at all cost to import it into Pascal. On the wiki pages some of my remarks got lost (or I didn't write them down) but when I first looked at the notation style it looks very unpascalish for me. I like more to add a new keyword for it, like the samples wiht generic or template) BTW, what woud be the problem with type TMySpecificClass = TGenericClass(TObject, Integer); What about proc generics: GenericProc(TObject) This can be ambigious. How would you have declared the proc, and how do you call it. I don't see a problem yet. GenericProc(TObject)(some params) you mean ? Example: procedure MyProc(T); // generic procedure without parameters ver i: T; begin ... end; Therefor I propose it to use the generic keyword - generic procedure MyProc(T); // generic procedure without parameters var i: T; begin ... end; procedure MyProc(T: TClass); // non generic procedure begin end; This should give a duplicate Identifier error. or when we usae a syntax similar Micha proposes (I changed the of): code type TGenericProc = generic(T) of procedure(param, param) ... use T end; TObjectProc = TGenericProc(TObject) generic(T) procedure MyGenericProc(...) begin end; /code code type TGenericCollection = generic(T: TCollectionItem) of class(TComponent) ...implement TCollection and use T end; TCollection = TGenericCollection(TCollectionItem); TFieldDefs = TGenericCollection(TFieldDef); /code And: code type TGenericList = generic(T: PtrInt) of class(TObject) ...implement TList and use PtrInt size for code generation end; TList = TGenericList(Pointer); /code Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics Syntax
types _at least_ in Ada's generics back in 1983[*] already. Perhaps someone should take a look at those, because these are also quite different from C++-templates. Vinzent. [*] That would be the same year the term C++ just appeared first in history of programming languages then, and this particular C++ didn't even have templates yet. The evil is in - using characters instead of modifiers. - worse, recycling already used characters. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Does FPC support XML encoding ?
Hi all, does fpc xml support encoding ??? I have a document with ?xml version=1.0 encoding=UTF-8? and an application which runs on a system with CP1251 locale. The text is read from the xml file but is not properly shown. How can I make it show properly ??? Delphi does this automatically ? TIA ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Thread support for windows ?
Hi, what is the CThreads unit replacement in Windows Do I need to use thread driver under Win32 or it is needed only for Linux? TIA. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics Syntax
Micha Nelissen wrote: code type TGenericCollection = generic(T: TCollectionItem) class(TComponent) ...implement TCollection and use T end; TCollection = TGenericCollection of (TCollectionItem); TFieldDefs = TGenericCollection of (TFieldDef); /code So generic procs could look like: code function generic(T: TTreeItem) MyFunc(A: T): T; begin // do something with the tree item end; /code My restrictions won't allow implementing generic Max and Min, I guess. That really needs macro-alike stuff (for the compiler implementation). The syntax could look like: code function generic(T) Max(A, B: T): T; begin if A B then Result := B else Result := A; end; /code I did some tests with g++. It looks like it parses the template 'normally' and don't handle it like a macro. When instantiating the template the generic type is replaced. I don't know if that is possible with FPC. The parser relies a lot on types being available. Writing a special parser for generics is possible. It can then store a simple expression/statement tree that will generate a full node tree when the generic is instantiated. But that means that it must be known that ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics Syntax
On Friday 04 November 2005 13:27, Marco van de Voort wrote: [] The evil is in - using characters instead of modifiers. - worse, recycling already used characters. Alright, I completely understand at least the first part, so perhaps they should simply not be overused. :-) Just for the fun and for those who don't know it yet, the previously given example in Ada95-syntax: -- 8 -- snip -- procedure Gen_Test is - package Show is procedure Do_It (i : Integer); procedure Do_It (s : String); end Show; package body Show is procedure Do_It (i : Integer) is begin null; end Do_It; procedure Do_It (s : String) is begin null; end Do_It; end Show; - - generic type T () is private; procedure Dump (Value : T); procedure Dump (Value : T) is use Show; begin Do_It (Value); end Dump; - - procedure My_Dump is new Dump (Integer); procedure My_Dump is new Dump (String); - begin -- Gen_Test My_Dump (42); My_Dump (foobar); end Gen_Test; pgp0x2VjCjF7F.pgp Description: signature ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
On Friday 04 November 2005 10:33, Vinzent Hoefler wrote: On Friday 04 November 2005 09:25, Micha Nelissen wrote: Marc Weustink wrote: If the generic is precompiled (which is maybe necesary if you need access to privates) then I fear some runtime logic has to be added to call the correct procedure. IE. something like case TypeInfo(Data) of StringType: Show(Data); IntegerType: Show(Data); end; The whole idea of Generics is to avoid this :-) At user level, yes. But as a compiler-writer you'd gotta make it work somehow. Yes, somehow, and not like that ;-) -- Regards, Christian Iversen ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics Syntax
Peter Vreman wrote: Expiriment, feed g++ code with errors in the statements. With macro's those errors won't be show until the macro is used. But with templates this is diffent: Smart indeed :) This is more important than the syntactical sugar. The rules where to declare generics and how/when they are parsed must be known. The syntax can be added in the end. Yes I understand, that's why I wanted to invent some syntax that's useful but easier to implement than full-blown semi-macro stuff, I added: Implementation of TGenericCollection can be compiled as if (T: TCollectionItem) were used. This should mean the current parser for the implementation is good enough. Would this solve the circular dependency ? It seems so to me, because one knows at least as much as in current implementation of these classes, but I'm no compiler engineer. And this should mean no 'weird' things can happen with interface-implementation semi-cycles. Are more rules needed than these ? Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] GetAppConfigDir under Unices
On Fri, 4 Nov 2005, dannym wrote: Hi, Am Freitag, den 04.11.2005, 05:46 +0100 schrieb Michalis Kamburelis: Hi I just tested SysUtils.GetAppConfigDir under Linux and I see that it returns GetHomeDir + ApplicationName (when Global = false). Shouldn't it rather return GetHomeDir + '.' + ApplicationName ? Config directories in user's home dir traditionally start with '.' to be somewhat hidden. I would expect GetAppConfigDir to follow this practice. actually by now it is (among others) GetHomeDir + '/.config/' + ApplicationName, according to the Desktop Base Directory Spec $XDG_CONFIG_HOME defines the base directory relative to which user specific configuration files should be stored. If $XDG_CONFIG_HOME is either not set or empty, a default equal to $HOME/.config should be used. http://standards.freedesktop.org/basedir-spec/basedir-spec-0.6.html I guess someone died the death of a thousand dotfiles, and figured that it can't continue like that :) Hm. Do you know a distro that uses this ? SuSE definitely doesn't. The .config directory doesn't even exist. Also, most existing apps don't adhere to this, but use the scheme as outlined in FPC. so..; Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] GetAppConfigDir under Unices
Hi, Am Freitag, den 04.11.2005, 17:26 +0100 schrieb Michael Van Canneyt: On Fri, 4 Nov 2005, dannym wrote: Hi, Am Freitag, den 04.11.2005, 05:46 +0100 schrieb Michalis Kamburelis: Hi I just tested SysUtils.GetAppConfigDir under Linux and I see that it returns GetHomeDir + ApplicationName (when Global = false). Shouldn't it rather return GetHomeDir + '.' + ApplicationName ? Config directories in user's home dir traditionally start with '.' to be somewhat hidden. I would expect GetAppConfigDir to follow this practice. actually by now it is (among others) GetHomeDir + '/.config/' + ApplicationName, according to the Desktop Base Directory Spec $XDG_CONFIG_HOME defines the base directory relative to which user specific configuration files should be stored. If $XDG_CONFIG_HOME is either not set or empty, a default equal to $HOME/.config should be used. http://standards.freedesktop.org/basedir-spec/basedir-spec-0.6.html I guess someone died the death of a thousand dotfiles, and figured that it can't continue like that :) Hm. Do you know a distro that uses this ? SuSE definitely doesn't. The .config directory doesn't even exist. I doubt that that is dictated by a distro. The spec is pretty recent, so I guess not many apps use it yet. However, - xfce 4.2 does use it - the spec was written by a kde guy, and a quick search turned up http://wiki.kde.org/tiki-index.php?page=Environment+Variables (not too sure if they really use it, as I don't use kde) - there are too many dotfiles in the way in $HOME :) So, for new apps / new major versions, IMO adhering to the spec would be a better idea. For minor revisions of existing apps, yes, no use in breaking people's existing config files / making things break for them when they downgrade the app again. Note that gnome and kde use a different level of indirection (.gnome2 / .kde) since ancient times, otherwise (everything directly in $HOME) one would drown in a ocean of dotfiles already :) Also, most existing apps don't adhere to this, but use the scheme as outlined in FPC. so..; Michael. cheers, Danny ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
This is evaluated by the pre-compiler run during compile time. When you use the template with e.g. var bl: ListString; then procedure show(s:string) is taken. Peter Vreman wrote: Mattias Gaertner wrote: This page looks only like the start of a proposal. Neither complete nor official. Why do you think, that D2006 will have generics? D2006 D11=D2007 How will Delphi handle the following case with overloads and different types: unit test; interface type ListT = class data : T; constructor(aData: T); procedure dump; end; implementation procedure show(i:integer);overload; begin end; procedure show(s:string);overload; begin end; constructor ListT(aData: T); begin Data := aData; end; procedure ListT.Dump; begin Show(Data); end; end. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
At 18:17 4-11-2005, you wrote: This is evaluated by the pre-compiler run during compile time. When you use the template with e.g. var bl: ListString; then procedure show(s:string) is taken. But what if the bl: ListString is called from an other unit? The Show(string) is then not visible anymore? Peter Vreman wrote: Mattias Gaertner wrote: This page looks only like the start of a proposal. Neither complete nor official. Why do you think, that D2006 will have generics? D2006 D11=D2007 How will Delphi handle the following case with overloads and different types: unit test; interface type ListT = class data : T; constructor(aData: T); procedure dump; end; implementation procedure show(i:integer);overload; begin end; procedure show(s:string);overload; begin end; constructor ListT(aData: T); begin Data := aData; end; procedure ListT.Dump; begin Show(Data); end; end. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel Peter ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
On Fri, 04 Nov 2005 20:28:15 +0100 Florian Klaempfl [EMAIL PROTECTED] wrote: - instantiation steps which require code generation are done after main program compilation based on information saved in the unit files, this has some advantages: If there are errors in some template, won't this cause hard to read error messages when they're spit out at final end of compilation ? Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] OpenGL and glut bugs in Freepascal 2.1.1runningwith Mac Os X Tiger ?
- Original Message - From: Adriaan van Os [EMAIL PROTECTED] To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Thursday, November 03, 2005 10:48 AM Subject: Re: [fpc-devel] OpenGL and glut bugs in Freepascal 2.1.1runningwith Mac Os X Tiger ? Nexus wrote: snip An unhandled exception occurred at $903E68B8 : EInvalidOp : Invalid floating point operation snip So it first seems to be some error in the fpu code generation of the compiler. But the strange things is, after running a C-Program which uses glut and open gl everything just works fine. So maybe there is something wrong in the open gl / glut initialization part or some incompatibilities with Mac OS X 10.4 snip Just a guess - could this be the same problem as discussed in the [fpc-devel] MacOSX: EXC_ARITHMETIC in PerformHIConversion thread, where Jonas Maebe wrote: Are these exceptions by default disabled by gcc ? The FPC runtime explicitly turns them on by default (since they are required for detecting errors), while libc doesn't. It is independent of the compiler used. So, if I understand it correct, you wont get a aritmic exeption in FPC anymore when this is turned on ? The invalid fpu operation exceptions are turned on in the FPC system unit initialisation code. If you add the code I posted, they are turned off again and so you won't get them (not due to buggy code in the Carbon framework and not anywhere else either). Regards, Adriaan van Os ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel Thank you very much for your help (all of you). You were absolutely right. It seems to be the same problem as discussed in the [fpc-devel] MacOSX: EXC_ARITHMETIC in PerformHIConversion thread. I ran the programs with Mac OS X 10.3 and they were running just fine. They just crash with Mac OS X 10.4.x. It seems to be the same bug in the Carbon framework under Mac OS X 10.4.x mentioned in this thread, which causes to generate invalid floating point operation exceptions in some cases. By disabling these exceptions as mentioned in the EXEC_ARITHMETIC thread with asm mtfsfi 6,1 end; everything works now with Mac OS X 10.4 as it should. But two questions remain: 1.) Why are the fpc applications running fine after running some open gl applications written in c ? (maybe i didn't get it yet, sorry) 2.) It does not sound very safe to turn of the floating point exceptions forever (or at least until Mac OS X 10.5). Is there any possibility to create some clean workaround without needing the divine intervention of the apple fixing the carbon libs in 10.4 ? Thanks again ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] OpenGL and glut bugs in Freepascal 2.1.1runningwith Mac Os X Tiger ?
On 04 Nov 2005, at 22:23, Matthias Krenzer wrote: 1.) Why are the fpc applications running fine after running some open gl applications written in c ? (maybe i didn't get it yet, sorry) Since we don't know what the bug in the Carbon framework is, that's hard to guess. And for some people, C programs in which the fpu overflow exceptions are enabled crash as well. 2.) It does not sound very safe to turn of the floating point exceptions forever (or at least until Mac OS X 10.5). There's nothing unsafe about it (except if you want your program to crash if it produces an fpu overflow). Is there any possibility to create some clean workaround without needing the divine intervention of the apple fixing the carbon libs in 10.4 ? Since no one has a clue what causes the problem (except that it seems to have something to do with fonts and possibly language settings), I'm not sure how we could make another workaround than disabling the exceptions. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Threads patch PS
I forgot to mention it's against 2.0.1 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] win32 patch for threads
Ales Katona wrote:
This patch fixes a bug in win32 threads. Warning: created in win32 :)
(no idea about lineendings)
Aplied, also for wince and netware.
Ales
Index: rtl/win32/tthread.inc
===
--- rtl/win32/tthread.inc (revision 1647)
+++ rtl/win32/tthread.inc (working copy)
@@ -97,7 +97,7 @@
{ TThread }
-function ThreadProc(ThreadObjPtr: Pointer): Integer;
+function ThreadProc(ThreadObjPtr: Pointer): Integer; stdcall;
var
FreeThread: Boolean;
Thread: TThread absolute ThreadObjPtr;
Index: rtl/inc/threadh.inc
===
--- rtl/inc/threadh.inc (revision 1647)
+++ rtl/inc/threadh.inc (working copy)
@@ -26,7 +26,7 @@
type
PEventState = pointer;
PRTLEvent = pointer; // Windows=thandle, other=pointer to record.
- TThreadFunc = function(parameter : pointer) : ptrint;
+ TThreadFunc = function(parameter : pointer) : ptrint; stdcall;
trtlmethod = procedure of object;
// Function prototypes for TThreadManager Record.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
What is Chrome? Some examples of Generics:
http://www.remobjects.com/articles/?id={A1D08EE3-0D9E-4828-AFB3-B2C1E772186E}
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
