Peter Vreman wrote:
Below are the number that i get when i compiled fppkg from r9259. These show
only 3% improvement.
But also small bits help and i'll apply the patches after some cleanups.
Looks like I was too optimistic in my first estimation :) Still, testing
the fppkg project
On 20/11/2007, Michael Van Canneyt [EMAIL PROTECTED] wrote:
to write code anyway, so it's no different from custom written code.
The only use for this is maybe storing DB persistence information.
Ok, maybe I should have made the context more clear as well. My
primary use for RTTI is in a
On Tue, 20 Nov 2007, Graeme Geldenhuys wrote:
On 20/11/2007, Michael Van Canneyt [EMAIL PROTECTED] wrote:
to write code anyway, so it's no different from custom written code.
The only use for this is maybe storing DB persistence information.
Ok, maybe I should have made the context
Thorsten Engler wrote:
Take a look here to get some idea about the uses for attributes in just the
core framework: http://msdn2.microsoft.com/en-us/library/2e39z096.aspx
What? Most sounds like poor hacks to get around compiler/linker limitations.
paste
On Tue, 20 Nov 2007, Thorsten Engler wrote:
Easy: look up the method in RTTI - you'll get the address.
Push all arguments on the stack (see Remobjects/Innerfuse
PascalScript on how to do this, you need some assembler for
it), and return result value.
2 days, tops.
You are
Op Tue, 20 Nov 2007, schreef Marco van de Voort:
calling convention)
No usable type information for published fields (only a name to offset
mapping is given, no type information at all)
And so on...
Note that all this can be remedied (and better) by a simple code generator
Thorsten Engler wrote:
Apart from the custom attributes and the Invoke, I don't see
what there is extra ?
No usable RTTI for records
No usable RTTI for arrays
No RTTI for private, protected and public(!) members (only published)
No usable RTTI for published methods (param and return types are
Easy: look up the method in RTTI - you'll get the address.
Push all arguments on the stack (see Remobjects/Innerfuse
PascalScript on how to do this, you need some assembler for
it), and return result value.
2 days, tops.
You are funny.
First, the RTTI can only give you the address of
I can only assume that you simply have no idea about how and for what
Attributes are used.
He's not alone :-) .
I used RTTI to avoid defining an additional constant array of strings to
have a unit output debug information for enumerated types. Otherwise I
never did see any use of this.
* Mattias Gaertner [EMAIL PROTECTED] [Tue, 20 Nov 2007
01:14:27 +0100]:
On Tue, 20 Nov 2007 00:08:20 +0300
Andrey Gusev [EMAIL PROTECTED] wrote:
* Andrey Gusev [EMAIL PROTECTED] [Fri, 16 Nov 2007 17:35:26 +0300]:
Can anybody explain to me, why dynamically created forms with
On 20 Nov 2007, at 09:41, Michael Van Canneyt wrote:
Easy: look up the method in RTTI - you'll get the address.
Push all arguments on the stack (see Remobjects/Innerfuse
PascalScript on
how to do this, you need some assembler for it), and return result
value.
And breaks every other FPC
Op Tue, 20 Nov 2007, schreef Marco van de Voort:
Apart from the custom attributes and the Invoke, I don't see
what there is extra ?
No usable RTTI for records
No usable RTTI for arrays
No RTTI for private, protected and public(!) members (only published)
No usable RTTI for
On Tue, 20 Nov 2007 12:40:41 +0300
Andrey Gusev [EMAIL PROTECTED] wrote:
* Mattias Gaertner [EMAIL PROTECTED] [Tue, 20 Nov 2007
01:14:27 +0100]:
On Tue, 20 Nov 2007 00:08:20 +0300
Andrey Gusev [EMAIL PROTECTED] wrote:
* Andrey Gusev [EMAIL PROTECTED] [Fri, 16 Nov 2007 17:35:26
Apart from the custom attributes and the Invoke, I don't see what
there is extra ?
Sorry, forgot: No RTTI whatsoever for pointer types.
Cheers,
Thorsten
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
Apart from the custom attributes and the Invoke, I don't see
what there is extra ?
No usable RTTI for records
No usable RTTI for arrays
No RTTI for private, protected and public(!) members (only published)
No usable RTTI for published methods (param and return types are just given
as
On Tue, 20 Nov 2007, Thorsten Engler wrote:
Apart from the custom attributes and the Invoke, I don't see
what there is extra ?
No usable RTTI for records
No usable RTTI for arrays
Granted.
No RTTI for private, protected and public(!) members (only published)
Private and protected
Private and protected are not your business in the first
place, exposing it through RTTI or whatever is bad design. Public, OK.
The class itself should have access to that information. It can then use it
to e.g. stream the contents of all/some of it's private fields to/from a
stream.
No
On Tue, 20 Nov 2007, Thorsten Engler wrote:
Private and protected are not your business in the first
place, exposing it through RTTI or whatever is bad design. Public, OK.
The class itself should have access to that information. It can then use it
to e.g. stream the contents of
I also think you don't recognize sarcasm/scepticism
when you encounter it.
IMHO, sarcasm should not be used in a forum, especially if non native
language members are to be considered. They are easily fooled involuntarily.
-Michael
___
fpc-devel
On Tue, 20 Nov 2007 14:17:14 +0300
Andrey Gusev [EMAIL PROTECTED] wrote:
* Mattias Gaertner [EMAIL PROTECTED] [Tue, 20 Nov 2007
10:55:49 +0100]:
On Tue, 20 Nov 2007 12:40:41 +0300
Andrey Gusev [EMAIL PROTECTED] wrote:
* Mattias Gaertner [EMAIL PROTECTED] [Tue, 20 Nov 2007
01:14:27
Sorry, I don't understand anything of this.
(I did not see any use for interfaces in my work yet, either.)
This seems to be a completely different world from mine (as a programmer
for mainly embedded projects).
I once used variants for a project that accessed a database.
-Michael
* Mattias Gaertner [EMAIL PROTECTED] [Tue, 20 Nov 2007
10:55:49 +0100]:
On Tue, 20 Nov 2007 12:40:41 +0300
Andrey Gusev [EMAIL PROTECTED] wrote:
* Mattias Gaertner [EMAIL PROTECTED] [Tue, 20 Nov 2007
01:14:27 +0100]:
On Tue, 20 Nov 2007 00:08:20 +0300
Andrey Gusev [EMAIL PROTECTED] wrote:
Hi,
I've included a program that shows the problem. I'm using FPC 2.2.0
under Linux on a Intel P4.
I've got a function PropertyMatch() which returns true or false if a
given property matches a specified value. All very simple.
But for some strange reason TypInfo.GetPropValue returns a boolean
* Andrey Gusev [EMAIL PROTECTED] [Tue, 20 Nov 2007 15:57:08 +0300]:
In what order files list (files node) do sort of filenames - it quite
unsorted in my opinion. (see snap).
For long filenames lists it must be problematic, to navigate through
they.
It is reasonable, to expect of sort ability
On Tue, 20 Nov 2007, Graeme Geldenhuys wrote:
Hi,
I've included a program that shows the problem. I'm using FPC 2.2.0
under Linux on a Intel P4.
I've got a function PropertyMatch() which returns true or false if a
given property matches a specified value. All very simple.
But for some
On 20/11/2007, Michael Van Canneyt [EMAIL PROTECTED] wrote:
It's hard to say whether this is an actual error or an incompatibility.
Well this 'error' has been around in tiOPF since I ported it to FPC
(about 3 years) and now it's really bugging me. :)
Looking at the code and the error, I'd say
On Tue, 20 Nov 2007, Graeme Geldenhuys wrote:
On 20/11/2007, Michael Van Canneyt [EMAIL PROTECTED] wrote:
It's hard to say whether this is an actual error or an incompatibility.
Well this 'error' has been around in tiOPF since I ported it to FPC
(about 3 years) and now it's really
On 20/11/2007, Michael Van Canneyt [EMAIL PROTECTED] wrote:
Fair enough. I'm not a fan of Variants either, but how else would I
write the PropertyMatch() function then? Yes I could do some extra
tests and use GetStrProp, GetIntProp, GetFloatProp etc.
This is IMHO the only correct way.
On 20/11/2007, Graeme Geldenhuys [EMAIL PROTECTED] wrote:
I've extended the PropertyMatch() function to test for tkBool types
(no variants) and do a writeln when it finds it. That parts seems to
work fine.
Here is the debug code I added to PropertyMatch() which successfully
compare the
On Tue, 20 Nov 2007, Graeme Geldenhuys wrote:
On 20/11/2007, Graeme Geldenhuys [EMAIL PROTECTED] wrote:
I've extended the PropertyMatch() function to test for tkBool types
(no variants) and do a writeln when it finds it. That parts seems to
work fine.
Here is the debug code I
Graeme Geldenhuys wrote:
On 20/11/2007, Graeme Geldenhuys [EMAIL PROTECTED] wrote:
I've extended the PropertyMatch() function to test for tkBool types
(no variants) and do a writeln when it finds it. That parts seems to
work fine.
Here is the debug code I added to PropertyMatch() which
31 matches
Mail list logo
