On Mon, 30 Apr 2018, Anthony Walter wrote:
Okay, I found a nice work around to allow for circular references on record
types:
record helpers
type
JSValue = record
...
end;
JSObject = record
...
end;
JSValueHelper = record helper for JSValue
function AsObject: JSObject;
end;
JS
Okay, I found a nice work around to allow for circular references on record
types:
record helpers
type
JSValue = record
...
end;
JSObject = record
...
end;
JSValueHelper = record helper for JSValue
function AsObject: JSObject;
end;
JSObjectHelper= record helper for JSObje
Thanks for replying. I'd like to chime in with a few thoughts..
I believe manged types beyond string, dynamic array, and interface as
important. In my use case worked around the problem by using records with
private interface as I already mentioned. This solution is less than
optimal as it require
On Mon, 30 Apr 2018, Maciej Izak wrote:
I can imagine that checking such a field will be more fast than actually
calling a routine. This is just a thought, if you had already considered
such a thing, I would like to hear why you discarded it, for my education.
this is exactly what is done i
2018-04-30 20:56 GMT+02:00 Michael Van Canneyt :
> There is no agression. There is critique.
>
> Maybe the others were satisfied with your solution I am not. So I brought
> it
> again to everyone's attention.
There is difference between rudeness and critique. You are just rude, for
someone from
On Mon, 30 Apr 2018, Maciej Izak wrote:
2018-04-30 14:59 GMT+02:00 Michael Van Canneyt :
Maybe because your solution is simply not convincing and I wish to try and
find a solution just a little harder ?
Allow me to exaggerate the point a little:
A bunch of changes are introduced, things ar
2018-04-30 14:59 GMT+02:00 Michael Van Canneyt :
>
> Maybe because your solution is simply not convincing and I wish to try and
> find a solution just a little harder ?
>
> Allow me to exaggerate the point a little:
>
> A bunch of changes are introduced, things are rammed through our throat
> which
2018-04-30 15:05 GMT+02:00 Mattias Gaertner :
> Does that mean fpc 3.0.x had an unneeded overhead for classes without
> managed types and 3.1 fixes this?
>
No, small unneeded overhead exist in both.
The situation is different when managed types are used. FPC has similar
solution for RTTI like De
On Mon, 30 Apr 2018 14:43:02 +0200
Maciej Izak wrote:
>[...]
> With FastRTTI additional call to int_initialize is omitted when
> possible. Furthermore
> with FastRTTI all code is executed faster (much faster than in 3.0.x)
> because all info about managed fields (for classes, objects and records)
On Mon, 30 Apr 2018, Maciej Izak wrote:
2018-04-30 13:53 GMT+02:00 Michael Van Canneyt :
You mean that a constructor call for a program that does not uses
pointers/management operators also gets slower ?
Can we solve this _without_ additional tricks ?
Because the fact that a feature you do
2018-04-30 13:53 GMT+02:00 Michael Van Canneyt :
>
> You mean that a constructor call for a program that does not uses
> pointers/management operators also gets slower ?
>
> Can we solve this _without_ additional tricks ?
>
> Because the fact that a feature you do not use slows down your code is no
On Mon, 30 Apr 2018, Maciej Izak wrote:
2018-04-30 13:15 GMT+02:00 Anthony Walter :
Okay great. Thanks for the information. I'll experiment with the smart
pointers and their potential performance impact. In the interim I've
created a solution using the approach of records containing private
2018-04-30 13:15 GMT+02:00 Anthony Walter :
> Okay great. Thanks for the information. I'll experiment with the smart
> pointers and their potential performance impact. In the interim I've
> created a solution using the approach of records containing private
> reference counted interfaces. Here is
Okay great. Thanks for the information. I'll experiment with the smart
pointers and their potential performance impact. In the interim I've
created a solution using the approach of records containing private
reference counted interfaces. Here is an example of my JSContext record:
1. JSContex
2018-04-29 21:26 GMT+02:00 Anthony Walter :
> I wanted to know from the people who make decision about what to merge,
> what's the status of rolling his enhancements at following location into
> FPC trunk?
>
The key part of smart pointers (management operators) is already in trunk
(as Sven said).
15 matches
Mail list logo
