operator overloading and counting references / creating / destoying anonymous instances

classic Classic list List threaded Threaded
35 messages Options
12
Reply | Threaded
Open this post in threaded view
|

operator overloading and counting references / creating / destoying anonymous instances

Bernd Kreuss
Hi,

I am just trying to wrap (parts of) the OpenSSL¹ bignum library (large
integer arithmetic) into something that makes using it look at least a
little bit more elegant than using the naked procedural C API  while
at the same time trying to not overdo it and not create a heavy code
monster instead of a lightweight wrapper.

The problem is: Each bignum needs to be allocated by OpenSSL and freed
when no longer needed. If I make a Pascal Object or Class representing
a bignum and overload the arithmetic operators and then have
expressions like (a+b)*(c+d) I would need to find a way to create and
destroy anonymous instances of bignums on the fly. I have tried making
use of Interface and TInterfacedObject and this seems to do what I
want: for example when witing A := A + B the + operator would return a
new instance and the reference counting would then automatically call
the destructor of A when it assigns the newly created number.

The question is: Isn't using interfaces only to get reference counting
complete overkill in this situation, isn't there a more lightweight
way of doing this (or something similar)? And also maybe does some
clever and elegant pattern exist that would enable me to simply reuse
the instance of A (if an initialized object exists already on the left
side of the assignment) instead of destroying it and creating a new
one? (OpenSSL would theoretically allow me to reuse the same allocated
number handle for the result of an operation, I could do BN_add(a,a,a)
without allocating more than one number handle)?

Bernd
_____
¹ I depend on OpenSSL already anyways, so I thought why not make use
of its bignum too when I need it.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: operator overloading and counting references / creating / destoying anonymous instances

Bernd Kreuss
2011/7/28 Bernd <[hidden email]>:
> And also maybe does some
> clever and elegant pattern exist that would enable me to simply reuse
> the instance of A (if an initialized object exists already on the left
> side of the assignment)

For example (pseudocode, not sure if this is allowed):

operator + (a,b: IBigNum):IBigNum;
begin
  if not assigned(Result) then
    Result := TBigNum.Create;
  BN_add(Result.BN, a.BN, b.BN);
end;

Am I allowed to access the Result in this way? I have done only a few
experiments and at one time it seemed I could indeed access values of
the fields of the object on the left side of the assignment through
the Result variable but I'm not sure whether this was only coincidence
or if this is actually allowed.

Bernd
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: operator overloading and counting references / creating / destoying anonymous instances

Bernd Kreuss
2011/7/28 Bernd <[hidden email]>:

> operator + (a,b: IBigNum):IBigNum;
> begin
>  if not assigned(Result) then
>    Result := TBigNum.Create;
>  BN_add(Result.BN, a.BN, b.BN);
> end;
>
> Am I allowed to access the Result in this way? I have done only a few
> experiments and at one time it seemed I could indeed access values of
> the fields

This was last night when I was experimenting with records and objects,
I just tried it again with interfaces and there it is always nil.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: operator overloading and counting references / creating / destoying anonymous instances

Bernd Kreuss
In reply to this post by Bernd Kreuss
2011/7/28 Bernd <[hidden email]>:
> I have tried making
> use of Interface and TInterfacedObject and this seems to do what I
> want: for example when witing A := A + B the + operator would return a
> new instance and the reference counting would then automatically call
> the destructor of A when it assigns the newly created number.

I have profiled it
http://imagebin.org/165317

procedure Loop(a,b: IFoo);
var
  I : Integer;
begin
  for i := 0 to 10000 do begin
    //BN_mul(b.Handle, a.Handle, a.Handle, b.Context);
    b := a * a;
  end;
end;

This creates and destroys an object of TFoo everytime and this in turn
will also create and free resources inside OpenSSL, its only spending
37% of the time doing actually useful work (BN_mul).

I think I'm not going to continue this route. I can't see any possible
way to make useful use of overloading these operators, other than
making a few lines in other places of the code look a little bit nicer
at the cost of degrading performance by a factor of 3 (for add instead
of mul its even factor 6).

Occasionally I hear other people mentioning operator overloading as a
must-have feature of any decent language but I wonder what real-world
problems they are actually solving with it. Are other compilers better
at dealing with these problems, is there room for improvement?

Bernd
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: operator overloading and counting references / creating / destoying anonymous instances

etrusco
On Thu, Jul 28, 2011 at 1:59 PM, Bernd <[hidden email]> wrote:

> 2011/7/28 Bernd <[hidden email]>:
>> I have tried making
>> use of Interface and TInterfacedObject and this seems to do what I
>> want: for example when witing A := A + B the + operator would return a
>> new instance and the reference counting would then automatically call
>> the destructor of A when it assigns the newly created number.
>
> I have profiled it
> http://imagebin.org/165317
>
> procedure Loop(a,b: IFoo);
> var
>  I : Integer;
> begin
>  for i := 0 to 10000 do begin
>    //BN_mul(b.Handle, a.Handle, a.Handle, b.Context);
>    b := a * a;
>  end;
> end;
>
> This creates and destroys an object of TFoo everytime and this in turn
> will also create and free resources inside OpenSSL, its only spending
> 37% of the time doing actually useful work (BN_mul).
>
> I think I'm not going to continue this route. I can't see any possible
> way to make useful use of overloading these operators, other than
> making a few lines in other places of the code look a little bit nicer
> at the cost of degrading performance by a factor of 3 (for add instead
> of mul its even factor 6).
>
> Occasionally I hear other people mentioning operator overloading as a
> must-have feature of any decent language but I wonder what real-world
> problems they are actually solving with it. Are other compilers better
> at dealing with these problems, is there room for improvement?
>
> Bernd

Implement += and *= operator to avoid allocating new objects?
You could also/instead override  TObject.NewInstance and FreeInstance
to implement a pool of objects.

-Flávio
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: operator overloading and counting references / creating / destoying anonymous instances

Mark Morgan Lloyd-5
In reply to this post by Bernd Kreuss
Bernd wrote:

> Hi,
>
> I am just trying to wrap (parts of) the OpenSSL¹ bignum library (large
> integer arithmetic) into something that makes using it look at least a
> little bit more elegant than using the naked procedural C API  while
> at the same time trying to not overdo it and not create a heavy code
> monster instead of a lightweight wrapper.
>
> The problem is: Each bignum needs to be allocated by OpenSSL and freed
> when no longer needed. If I make a Pascal Object or Class representing
> a bignum and overload the arithmetic operators and then have
> expressions like (a+b)*(c+d) I would need to find a way to create and
> destroy anonymous instances of bignums on the fly. I have tried making
> use of Interface and TInterfacedObject and this seems to do what I
> want: for example when witing A := A + B the + operator would return a
> new instance and the reference counting would then automatically call
> the destructor of A when it assigns the newly created number.
>
> The question is: Isn't using interfaces only to get reference counting
> complete overkill in this situation, isn't there a more lightweight
> way of doing this (or something similar)? And also maybe does some
> clever and elegant pattern exist that would enable me to simply reuse
> the instance of A (if an initialized object exists already on the left
> side of the assignment) instead of destroying it and creating a new
> one? (OpenSSL would theoretically allow me to reuse the same allocated
> number handle for the result of an operation, I could do BN_add(a,a,a)
> without allocating more than one number handle)?

I wonder if I could ask a silly question here, without displaying too
much ignorance.

I generally understand the significance of an interface in the Windows
context, where COM (or whatever today's name for it) is integrated
fairly deeply into the OS.

But what of other OSes like Linux? Does the use of interfaces as a way
of getting refcounted storage assume the presence of CORBA etc., and how
much overhead is there at program startup- does it demand that an ORB be
loaded into memory?

--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: operator overloading and counting references / creating / destoying anonymous instances

Jürgen Hestermann
In reply to this post by Bernd Kreuss


Bernd schrieb:
 > Occasionally I hear other people mentioning operator overloading as a
 > must-have feature of any decent language but I wonder what real-world
 > problems they are actually solving with it.

I think operator overloading is a pain. As you said: What is the
advantage? For me operators should be defined by the language only
(Pascal) so that everybody who reads the code imediately knows what
happens. Instead you now need additional information (that can be far
away from the code lines you review). That makes code obscure and less
clear. But now there is no way back. It's implemented. Pascal moves in C
direction...

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: operator overloading and counting references / creating / destoying anonymous instances

Sven Barth-2
In reply to this post by Mark Morgan Lloyd-5
Am 28.07.2011 23:04, schrieb Mark Morgan Lloyd:

> I wonder if I could ask a silly question here, without displaying too
> much ignorance.
>
> I generally understand the significance of an interface in the Windows
> context, where COM (or whatever today's name for it) is integrated
> fairly deeply into the OS.
>
> But what of other OSes like Linux? Does the use of interfaces as a way
> of getting refcounted storage assume the presence of CORBA etc., and how
> much overhead is there at program startup- does it demand that an ORB be
> loaded into memory?
>

While COM-interfaces in Delphi/FPC are designed to be Delphi compatible,
they do not rely on COM. Basically a IInterface or IUnknown is simply an
interface that contains calls for increasing/releasing a reference
count. You as the implementor of the interface need to provide the
implementation. So e.g. TInterfacedObject which implements IInterface
implements a reference counting mechanism where the object is freed when
the reference count reaches zero. In FPC/Delphi this reference count is
normally controlled by the compiler by calling the methods of IUnknown,
but in C/C++ these calls need to be done manually (AFAIK).

CORBA-interfaces as implemented by FPC are just plain interfaces without
any methods defined. Also the compiler does not generate code to
influence the reference count as it does with COM-interfaces.

Basically an interface in FPC/Delphi is something that allows you to use
certain methods (those provided by the interface) without knowing what
the implementing class does. The COM-interface just contain a bit more
compiler magic, but that's it.

So no, you don't need an ORB or something like that.

Regards,
Sven

PS: There is also a third kind of interfaces called dispinterface that
contain again more compiler magic and are indeed used with COM
automation (or XPCOM on non-Windows).
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: operator overloading and counting references / creating / destoying anonymous instances

Bernd Kreuss
In reply to this post by Bernd Kreuss
I have run across another even more severe problem: Although using
reference counted interfaces makes everything work without memory
leaks there is one problem that gives all the nice syntactic sugar a
really bad taste:

A := B

I am not allowed to overload the assignment of equal types. This means
in the above I would have created a reference to B instead of a copy.
If I now do an operation on A that does *not* create a new instance of
it I will also change the value that B is pointing to, so I am
*forced* to make new instances even if I could in some cases easily
avoid them. Otherwise the user of that unit would have many
WTF-moments when debugging the unexpected strange behavior in his code
and all the efforts of making it look and behave natural would
effectively be nullified by such a problem.

Bernd
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: operator overloading and counting references / creating / destoying anonymous instances

Mark Morgan Lloyd-5
In reply to this post by Sven Barth-2
Sven Barth wrote:

> Am 28.07.2011 23:04, schrieb Mark Morgan Lloyd:
>> I wonder if I could ask a silly question here, without displaying too
>> much ignorance.
>>
>> I generally understand the significance of an interface in the Windows
>> context, where COM (or whatever today's name for it) is integrated
>> fairly deeply into the OS.
>>
>> But what of other OSes like Linux? Does the use of interfaces as a way
>> of getting refcounted storage assume the presence of CORBA etc., and how
>> much overhead is there at program startup- does it demand that an ORB be
>> loaded into memory?
>>
>
> While COM-interfaces in Delphi/FPC are designed to be Delphi compatible,
> they do not rely on COM. Basically a IInterface or IUnknown is simply an
> interface that contains calls for increasing/releasing a reference
> count. You as the implementor of the interface need to provide the
> implementation. So e.g. TInterfacedObject which implements IInterface
> implements a reference counting mechanism where the object is freed when
> the reference count reaches zero. In FPC/Delphi this reference count is
> normally controlled by the compiler by calling the methods of IUnknown,
> but in C/C++ these calls need to be done manually (AFAIK).
>
> CORBA-interfaces as implemented by FPC are just plain interfaces without
> any methods defined. Also the compiler does not generate code to
> influence the reference count as it does with COM-interfaces.
>
> Basically an interface in FPC/Delphi is something that allows you to use
> certain methods (those provided by the interface) without knowing what
> the implementing class does. The COM-interface just contain a bit more
> compiler magic, but that's it.
>
> So no, you don't need an ORB or something like that.
>
> Regards,
> Sven
>
> PS: There is also a third kind of interfaces called dispinterface that
> contain again more compiler magic and are indeed used with COM
> automation (or XPCOM on non-Windows).

So if I understand you correctly, use of interfaces does not imply use
of OS or ORB facilities, but can permit it if required.

--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: operator overloading and counting references / creating / destoying anonymous instances

Henry Vermaak
In reply to this post by Jürgen Hestermann
On 29/07/11 06:39, Jürgen Hestermann wrote:
>
>
> Bernd schrieb:
>  > Occasionally I hear other people mentioning operator overloading as a
>  > must-have feature of any decent language but I wonder what real-world
>  > problems they are actually solving with it.
>
> I think operator overloading is a pain. As you said: What is the
> advantage? For me operators should be defined by the language only

It improves readability, making it more logical.  Say for instance you
are working on Galois fields and you have to do arithmetic on the
elements like this:

g1 + g2 / g3

If you don't have operator overloading, you have to do it with
functions, like this:

gf_add(g1, gf_div(g2, g3))

This is not very readable, I'm sure you will agree.  They have to be
used carefully, however.

> clear. But now there is no way back. It's implemented. Pascal moves in C
> direction...

Troll.  C has no operator overloading.

Henry
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: operator overloading and counting references / creating / destoying anonymous instances

Bernd Kreuss
In reply to this post by Jürgen Hestermann
2011/7/29 Jürgen Hestermann <[hidden email]>:

> Bernd schrieb:
>> Occasionally I hear other people mentioning operator overloading as a
>> must-have feature of any decent language but I wonder what real-world
>> problems they are actually solving with it.
>
> I think operator overloading is a pain. As you said: What is the advantage?
> For me operators should be defined by the language only (Pascal) so that
> everybody who reads the code imediately knows what happens. Instead you now
> need additional information (that can be far away from the code lines you
> review). That makes code obscure and less clear. But now there is no way
> back. It's implemented. Pascal moves in C direction...

I'm not condemning it per se. It has its uses. I can still overload at
least the comparison operators for example, I didn't want to rant
against operator overloading in general. I only think it is overrated
and often more complicated than useful.

If I have a type that can be created and deleted/overwritten on the
stack on the fly (record, object) without needing a destructor to free
additional resources then everything can be made to work as if it were
a natural part of the language and there would be no performance
penalty and everything would be fine.

My question was only if there are really many different real-world
examples that go beyond the complex numbers example and maybe some
simple linear algebra types, that can fit their entire data into a
record on the stack without needing any allocation/deallocation of
heap or external resources. Making a nice looking lightweight wrapper
around an external library would surely be very desirable but I can't
see any way to overcome the problems and these seem fundamental
problems to me. This seems to need some non-trivial optimizations that
might even need help from the compiler itself to make it really
effective.

With interfaces and their reference counting it can be made to work
but the cost of doing this seems so immense that I don't believe it is
justifiable in many real world applications (at least not in my
application).

Maybe if there were a way to make the compiler generate code to hook
into whenever a record is created/deleted/overwritten on the stack
this would allow some creative hacks around some of these problems but
with classes and interfaces alone I can't justify the immense overhead
that is associated with it.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: operator overloading and counting references / creating / destoying anonymous instances

Sven Barth-2
In reply to this post by Mark Morgan Lloyd-5
Am 29.07.2011 12:11, schrieb Mark Morgan Lloyd:

> Sven Barth wrote:
>> Am 28.07.2011 23:04, schrieb Mark Morgan Lloyd:
>>> I wonder if I could ask a silly question here, without displaying too
>>> much ignorance.
>>>
>>> I generally understand the significance of an interface in the Windows
>>> context, where COM (or whatever today's name for it) is integrated
>>> fairly deeply into the OS.
>>>
>>> But what of other OSes like Linux? Does the use of interfaces as a way
>>> of getting refcounted storage assume the presence of CORBA etc., and how
>>> much overhead is there at program startup- does it demand that an ORB be
>>> loaded into memory?
>>>
>>
>> While COM-interfaces in Delphi/FPC are designed to be Delphi
>> compatible, they do not rely on COM. Basically a IInterface or
>> IUnknown is simply an interface that contains calls for
>> increasing/releasing a reference count. You as the implementor of the
>> interface need to provide the implementation. So e.g.
>> TInterfacedObject which implements IInterface implements a reference
>> counting mechanism where the object is freed when the reference count
>> reaches zero. In FPC/Delphi this reference count is normally
>> controlled by the compiler by calling the methods of IUnknown, but in
>> C/C++ these calls need to be done manually (AFAIK).
>>
>> CORBA-interfaces as implemented by FPC are just plain interfaces
>> without any methods defined. Also the compiler does not generate code
>> to influence the reference count as it does with COM-interfaces.
>>
>> Basically an interface in FPC/Delphi is something that allows you to
>> use certain methods (those provided by the interface) without knowing
>> what the implementing class does. The COM-interface just contain a bit
>> more compiler magic, but that's it.
>>
>> So no, you don't need an ORB or something like that.
>>
>> Regards,
>> Sven
>>
>> PS: There is also a third kind of interfaces called dispinterface that
>> contain again more compiler magic and are indeed used with COM
>> automation (or XPCOM on non-Windows).
>
> So if I understand you correctly, use of interfaces does not imply use
> of OS or ORB facilities, but can permit it if required.
>

Simply spoken: yes (although I don't know of a CORBA ORB usage myself(!))

Regards,
Sven
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: operator overloading and counting references / creating / destoying anonymous instances

Florian Klämpfl
In reply to this post by Bernd Kreuss
Am 29.07.2011 12:00, schrieb Bernd:

> I have run across another even more severe problem: Although using
> reference counted interfaces makes everything work without memory
> leaks there is one problem that gives all the nice syntactic sugar a
> really bad taste:
>
> A := B
>
> I am not allowed to overload the assignment of equal types. This means
> in the above I would have created a reference to B instead of a copy.
> If I now do an operation on A that does *not* create a new instance of
> it I will also change the value that B is pointing to, so I am
> *forced* to make new instances even if I could in some cases easily
> avoid them.

No. Just check the ref. count if you plan to do an operation on A: if
it's >1, create a copy for A and operate on the copy.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: operator overloading and counting references / creating / destoying anonymous instances

Den Jean
In reply to this post by Bernd Kreuss
On Friday 29 July 2011 13:43:58 Bernd wrote:
> With interfaces and their reference counting it can be made to work
> but the cost of doing this seems so immense that I don't believe it is
> justifiable in many real world applications (at least not in my
> application).
The performance penalty was the same reason
why I abandoned the use of interfaces in the
qt4 binding, just look at the way I used it in the qt2 binding:
Though it was pretty nifty, people may not be aware of
the performance cost of such albeit nice abstractions.

http://qtforfpc.cvs.sourceforge.net/viewvc/qtforfpc/qte/demo/qteobjects.pas?revision=1.2&view=markup
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: operator overloading and counting references / creating / destoying anonymous instances

etrusco
In reply to this post by Henry Vermaak
On Fri, Jul 29, 2011 at 7:31 AM, Henry Vermaak <[hidden email]> wrote:

> On 29/07/11 06:39, Jürgen Hestermann wrote:
>>
>>
>> Bernd schrieb:
>>  > Occasionally I hear other people mentioning operator overloading as a
>>  > must-have feature of any decent language but I wonder what real-world
>>  > problems they are actually solving with it.
>>
>> I think operator overloading is a pain. As you said: What is the
>> advantage? For me operators should be defined by the language only
>
> It improves readability, making it more logical.  Say for instance you are
> working on Galois fields and you have to do arithmetic on the elements like
> this:
>
> g1 + g2 / g3
>
> If you don't have operator overloading, you have to do it with functions,
> like this:
>
> gf_add(g1, gf_div(g2, g3))
>
> This is not very readable, I'm sure you will agree.  They have to be used
> carefully, however.

That's the problem, you always have to be very careful.
They are easy to overlook in the code.
You can circumvent type-checking.
One more thing for the IDE to support (if it doesn't, you're royally screwed).
At least in *Pascal strings are native types, so one less problem (and
a big one in C++) to worry.

>> clear. But now there is no way back. It's implemented. Pascal moves in C
>> direction...
>
> Troll.  C has no operator overloading.
>
> Henry

Of course he meant C++.

-Flávio
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: operator overloading and counting references / creating / destoying anonymous instances

Jürgen Hestermann
In reply to this post by Henry Vermaak
Henry Vermaak schrieb:
 >> I think operator overloading is a pain. As you said: What is the
 >> advantage? For me operators should be defined by the language only
 > It improves readability, making it more logical.  

Just the opposite! It hides important imformation for the reading person.


 > Say for instance you are working on Galois fields and you have to do
arithmetic on the elements like this:
 > g1 + g2 / g3
 > If you don't have operator overloading, you have to do it with
functions, like this:
 > gf_add(g1, gf_div(g2, g3))
 > This is not very readable, I'm sure you will agree.  

No, I don't agree at all. The procedure call clearly shows me that a
complex calculation is done instead of an (atomic) add and division
command on numbers.

For me the basic operators should be just that: Basic operators.
Otherwise you have problems to interpret code.

For example, IMO the assignment :=  should just copy bytes, nothing
more. There can be additional range checks but it should not lead to
side effects you are not aware of. I had a hard time to find out that a
simple "A:=nil" on a dynamic array does more than just copying bytes to
the memory adress of A. As a side effect it uses the current pointer in
A and frees memory. But I had just read this data from a file so that
the pointer was garbage. I just wanted to init A. But what a surprise
that this atomic assignment command does more on dynamic arrays! If I
create pointers to types on my own, this does not happen.

Operator overloading weakens the meaning of the operators. It can be
just everything but you do not see it anymore.


 >> clear. But now there is no way back. It's implemented. Pascal moves
in C direction...
 > Troll.  C has no operator overloading.

I meant it in a more general spirit: Pascal was created to be clear and
unambiguous while C was an improved assembler which ignored any kind of
readability. Now all these obscure things creep into Pascal too so that
in this respect there is not much difference between current C(++) and
current Pascal compilers anymore.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: operator overloading and counting references / creating / destoying anonymous instances

Jürgen Hestermann
 > > Say for instance you are working on Galois fields and you have to
do arithmetic on the elements like this:
 > > g1 + g2 / g3
 > > If you don't have operator overloading, you have to do it with
functions, like this:
 > > gf_add(g1, gf_div(g2, g3))
 > > This is not very readable, I'm sure you will agree.
 > No, I don't agree at all. The procedure call clearly shows me that a
complex calculation
 > is done instead of an (atomic) add and division command on numbers.


And there is another advantage of using procedures/functions instead of
overloading operators:
You can search for the procedure to look what it actualy does.
How do you find the code that overloaded an operator?

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: operator overloading and counting references / creating / destoying anonymous instances

Florian Klämpfl
Am 30.07.2011 17:05, schrieb Jürgen Hestermann:

>> > Say for instance you are working on Galois fields and you have to do
> arithmetic on the elements like this:
>> > g1 + g2 / g3
>> > If you don't have operator overloading, you have to do it with
> functions, like this:
>> > gf_add(g1, gf_div(g2, g3))
>> > This is not very readable, I'm sure you will agree.
>> No, I don't agree at all. The procedure call clearly shows me that a
> complex calculation
>> is done instead of an (atomic) add and division command on numbers.
>
>
> And there is another advantage of using procedures/functions instead of
> overloading operators:
> You can search for the procedure to look what it actualy does.

Not if you use function/procedure overloading. Then the situation is
exactly the same as for operators.

> How do you find the code that overloaded an operator?


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: operator overloading and counting references / creating / destoying anonymous instances

Florian Klämpfl
In reply to this post by Bernd Kreuss
Am 29.07.2011 13:43, schrieb Bernd:
>
> With interfaces and their reference counting it can be made to work
> but the cost of doing this seems so immense that I don't believe it is
> justifiable in many real world applications (at least not in my
> application).

The automatic constructor/destructor concept of C++ causes the same
overhead. And the overhead for a function or operator overloading based
approach is the same imo. Or do you have any example where a function
based approach performs better? Overloaded operators are converted into
function calls, there is no real difference.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
12