> On Mar 9, 2018, at 11:19 PM, Sven Barth via fpc-pascal
> wrote:
>
> Because this way the user is aware that they are something special and are
> not supposed to be called manually.
>
That makes sense.
Why can’t the compiler use a similar method to call a function when a stack
based con
Am 09.03.2018 16:41 schrieb "Ryan Joseph" :
> On Mar 9, 2018, at 4:51 PM, Sven Barth via fpc-pascal <
fpc-pascal@lists.freepascal.org> wrote:
>
> Objects share roughly as much code with records as classes do as
internally classes and objects share most of their code.
>
I’ll be curious what Maci
> On Mar 9, 2018, at 4:51 PM, Sven Barth via fpc-pascal
> wrote:
>
> Objects share roughly as much code with records as classes do as internally
> classes and objects share most of their code.
>
I’ll be curious what Maciej says about management operators in objects then.
Classes don’t hav
> On Mar 9, 2018, at 4:13 PM, Ryan Joseph wrote:
>
> type
> TDataObject = object
> v: array[0..2] of integer;
> end;
>
> procedure TestObjectCopy;
> var
> obj: TDataObject;
> data: array[0..2] of integer;
> i: integer;
> begin
> for i := 0 to 2
Am 09.03.2018 10:14 schrieb "Ryan Joseph" :
>
>> 4) Move() on an object copies memory like a record (as a record does, so
this is good). Does that mean they laid out in memory just like records?
>
> Yes, although I believe there is a hidden VMT field.
Not sure how they look in memory but that co
> On Mar 9, 2018, at 3:55 PM, Michael Van Canneyt
> wrote:
>
> Hence my proposal to 'clean this up’.
A good idea if they would be used. If objects had a couple minor things I
personally could replace some records in certain parts of code and get real
benefits. Someone on the compiler team w
On Fri, 9 Mar 2018, Ryan Joseph wrote:
On Mar 9, 2018, at 1:53 PM, Sven Barth via fpc-pascal
wrote:
They are broken, deprecated and essentially dead in Delphi, but in FPC we've
always cared for them as well.
Overloads and generics are already supported and support for helpers could be e
> On Mar 9, 2018, at 1:53 PM, Sven Barth via fpc-pascal
> wrote:
>
> They are broken, deprecated and essentially dead in Delphi, but in FPC we've
> always cared for them as well.
> Overloads and generics are already supported and support for helpers could be
> easily added. Only major featur
Am 09.03.2018 05:14 schrieb "Ryan Joseph" :
> On Mar 9, 2018, at 10:32 AM, Michael Van Canneyt
wrote:
>
> Why don't you use objects ? No-one has obsoleted this, and you get what
you
> want: an object that can be allocated on the stack or on the heap.
Object is just for backwards compatibility
> On Mar 9, 2018, at 10:32 AM, Michael Van Canneyt
> wrote:
>
> Why don't you use objects ? No-one has obsoleted this, and you get what you
> want: an object that can be allocated on the stack or on the heap.
Object is just for backwards compatibility right? Does it support new features
like
On Fri, 9 Mar 2018, Ryan Joseph wrote:
On Mar 9, 2018, at 3:55 AM, Graeme Geldenhuys
wrote:
My first question
What is a managed record?
My second question
Why would I need it?
My third question.
What is different compared to a "normal record"
and compared to
> On Mar 9, 2018, at 3:55 AM, Graeme Geldenhuys
> wrote:
>
> My first question
> What is a managed record?
>
> My second question
> Why would I need it?
>
> My third question.
> What is different compared to a "normal record"
> and compared to FPC's Object data ty
On 2018-03-08 03:13, Ryan Joseph wrote:
So in the trunk we have managed records now which is a brilliant
addition and long overdue. Some questions these bring up:
My first question
What is a managed record?
My second question
Why would I need it?
My third question.
> On Mar 8, 2018, at 8:28 PM, Sven Barth via fpc-pascal
> wrote:
>
> This is not an oversight, but an explicit design decision of the language.
Do you recall what the history was of this choice? I can remember using the
“new" keyword on objects but I don’t remember much more (I didn’t go ful
Am 08.03.2018 12:51 schrieb "Ryan Joseph" :
> On Mar 8, 2018, at 5:42 PM, Sven Barth via fpc-pascal <
fpc-pascal@lists.freepascal.org> wrote:
>
> You are supposed to use try...finally for this. The finally-block is
always executed when the try-block is left no matter if it's by reaching
the end,
> On Mar 8, 2018, at 5:42 PM, Sven Barth via fpc-pascal
> wrote:
>
> You are supposed to use try...finally for this. The finally-block is always
> executed when the try-block is left no matter if it's by reaching the end,
> calling exit or by an exception.
>
But my greater point is why ar
Am 08.03.2018 09:44 schrieb "Ryan Joseph" :
2) We need to remember to call Free() at the end of the function and take
precaution to not exit early and leak memory (maybe even using a goto to
break out of nested loops or nested functions, who knows).
You are supposed to use try...finally for this
Am 08.03.2018 08:33 schrieb "Maciej Izak" :
No, this doesn't beg the question, because Object Pascal classes are
> designed in the principle to reduce on the heap. Changing this would not
> only mean quite some changes in the compiler/RTL with no real gain, but it
> would also change a core aspec
On 03/08/2018 10:16 AM, Ryan Joseph wrote:
>
>
>
> I know this is how it is and not likely to change I’m just pointing it out.
In MSElang objects and classes have been unified, they can be allocated
on stack or on heap. They also have hooks for initialization and
finalization which can be used
> On Mar 8, 2018, at 4:00 PM, Maciej Izak wrote:
>
> Small ad of mORMot (main author Arnaud Bouchez aka ab) :
>
> with SynCommons module you have nice utils for such things:
>
> procedure MyProc;
> var
> list: TList;
> begin
> with TAutoFree.One(list, TList.Create) do
> begin
> lis
2018-03-08 9:13 GMT+01:00 Ryan Joseph :
> The more efficient approach would clearly be something like:
>
> procedure MyProc;
> var
> list: stack TList; // assume this allocates us on the stack like a
> record
> begin
> list.Clear; // there’s no Create call so init the class some ho
> On Mar 8, 2018, at 3:12 PM, Michael Van Canneyt
> wrote:
>
> You can still use objects.
I guess I can go back to objects and use pointers to objects when I want
classes? I don’t know if objects even have all the same functionality of
classes, and aren’t they for backwards compatibility an
> On Mar 8, 2018, at 2:43 PM, Ryan Joseph wrote:
>
> In many cases I don’t actually need anything on the heap and a record could
> be used instead but because of limitations on records in Pascal I need a full
> class. Doing the ARC route is just solving a problem I created by the fact I
> us
2018-03-08 9:12 GMT+01:00 Michael Van Canneyt :
> You can still use objects.
+1. in most of cases this is enough
--
Best regards,
Maciej Izak
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/list
> On Mar 8, 2018, at 2:20 PM, Maciej Izak wrote:
>
> Management operators are almost unusable without default field/default
> property. How it works you can see here :
>
> https://github.com/maciej-izak/PascalSmartPointers
>
> the examples can be tested with NewPascal for now. The simplified
On Thu, 8 Mar 2018, Ryan Joseph wrote:
On Mar 8, 2018, at 1:48 PM, Sven Barth via fpc-pascal
wrote:
You could use an include file containing both the declaration and implementation controlled by compiler defines together with a macro for the type name.
That’s a nice trick. If those re
> On Mar 8, 2018, at 1:48 PM, Sven Barth via fpc-pascal
> wrote:
>
> You could use an include file containing both the declaration and
> implementation controlled by compiler defines together with a macro for the
> type name.
That’s a nice trick. If those records get adopted something “man
2018-03-08 7:48 GMT+01:00 Sven Barth via fpc-pascal <
fpc-pascal@lists.freepascal.org>:
> You could use an include file containing both the declaration and
> implementation controlled by compiler defines together with a macro for the
> type name.
>
Very improper and totally bad approach. This is
2018-03-08 4:13 GMT+01:00 Ryan Joseph :
> 1) Given the example below we have a template for a standard ref counted
> record. Shouldn’t there be some “meta record” type that implements this
> automatically? I’m thinking about adding this to some types but the idea of
> recreating this same template
Am 08.03.2018 04:44 schrieb "Ryan Joseph" :
1) Given the example below we have a template for a standard ref counted
record. Shouldn’t there be some “meta record” type that implements this
automatically? I’m thinking about adding this to some types but the idea of
recreating this same template eve
So in the trunk we have managed records now which is a brilliant addition and
long overdue. Some questions these bring up:
1) Given the example below we have a template for a standard ref counted
record. Shouldn’t there be some “meta record” type that implements this
automatically? I’m thinking
31 matches
Mail list logo
