FPC - wasted memory...
Author Message
FPC - wasted memory...

Dmytry Lavrov:

Quote:
> Heh,in comparation with MathLab,Pascal is like plain assembler ;-).()

You don't need to go so far (and spend so much money) to be able to
write things like...

type Matrix is array (Integer range <>, Integer range <>) of Field_elt ;

function "*"(l:Field_elt; A:Matrix) return Matrix is
l_A: Matrix(A'range(1),A'range(2));
begin
for i in A'range(1) loop
for j in A'range(2) loop
l_A(i,j):= l*A(i,j);
end loop;
end loop;
return l_A;
end "*";

function "*"(A,B:Matrix) return Matrix is
r: Field_elt;
AB: Matrix(A'range(1),B'range(2));
begin
if A'length(2)/=B'length(1) then raise constraint_error; end if;
for i in A'range(1) loop
for j in B'range(2) loop
r:= zero;
for k in B'range(1) loop
r:= r + A(i,k) * B(k,j);
end loop;
AB(i,j):= r;
end loop;
end loop;
return AB;
end "*";

NB: no need to destroy anything!
________________________________________________________
Gautier  --   http://www.*-*-*.com/

Sat, 17 Dec 2005 02:18:50 GMT
FPC - wasted memory...

Quote:

> > you are doing such things in c, but I know c is not Pascal :o)]

> > The garbage collector method will work, but imo its no different from
> > doing the a:=b*c; d:=a+e; a.destroy; thing. It's (imo) a workaround,
> > not a solution.

> Using refcounted interfaces might be a "better" solution. (for 1.1), but I
> haven't tried that.

> This worked very well for me (and even better in some circumstances)

I just came up with a possibly better approach which would avoid the
explicit destructors:

Set a limit to the number of temps that can be created.  It's somewhat
dangerous, but
if you knew (and you *really* have to *know*) that you will never use more
than, say,
16 temps in a given expression, then simply round robin usage of a temp
pool.   Of course
if you exceed the number of temps, Bad Things Happen.

(This method should not be used if you create other functions which may
create variables
within themselves while they themselves are part of expressions,  expecially
with recursive
functions!   There may be no way to predict the number of in-use temps.)

You would use separate Create and CreateTemp methods, as discussed
elsewhere, the
Create would create a new object (or grab one from the temp pool if you
like).  CreateTemp
would create a  new object if fewer than the max have been allocated and put
it in the list/array
of temps,  otherwise it would grab the least  recently used one, the
assumption being that the last
expression which used it has already been evaluated.

In fact, I'd say it would be safe to call the Purge or Cleanup method when
doing explicit
Creates as well, because you are not evaluating an expression at the time.

Rufus

-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----==  Over 80,000 Newsgroups - 16 Different Servers! =-----

Fri, 16 Dec 2005 23:15:42 GMT
FPC - wasted memory...

Quote:

> > you are doing such things in c, but I know c is not Pascal :o)]

> > The garbage collector method will work, but imo its no different from
> > doing the a:=b*c; d:=a+e; a.destroy; thing. It's (imo) a workaround,
> > not a solution.

> Using refcounted interfaces might be a "better" solution. (for 1.1), but I
> haven't tried that.

> This worked very well for me (and even better in some circumstances)

Again, I will talk c as my experience with operator overloading in
Pascal is zip. The trick there is to a) return instances, not
references, from all the overloads and b) to have the assignment (= in
c, := in Pascal) operator overloaded as well. When you overload the
assignment operator you don't have a return type but assign data to
the object itself. Therefore, you do never create any objects. The
only object thats created on the fly is the return object from the
operators. But because this is an instance, not a reference, you do
not create it yourself - the compiler does that. And because the
compiler creates it, the compiler is repsonsible of freeing it. Which
again happens after the whole expression is computed - just after we
have used our final assignment overload to store the result into an
object we have created ourselves.

The c compiler would work like this

a=b+c*d;

"c*d"; create temp1; temp1="c*d"; "b+temp1"; create temp2;
temp2="b+temp1"; free temp1; a=temp2; free temp2;

where "c*d" indicates that the result is stored in a temporary, local
variable.

I tried hard to get my Delphi compiler to return me object instances,
but failed. (anyone know how to do this?) Either my type declaration
was invalid, or the return type was invalid :( (tried to function
Something(): MyType^ and to declare type MyOtherType=MyType^ but it
wouldn't eat it)... As I have previously said, I don't think Pascal is
really compatible with operator overload in the "clean" way where ONLY
the constructor (and copy constructor) returns a pointer to a locally
created variable... Of course this could be done with records, if you
could operator overload on a record... Which you probably can't...

Ramblings over :p

/Nic

Sat, 17 Dec 2005 14:43:06 GMT
FPC - wasted memory...

Quote:
> Again, I will talk c as my experience with operator overloading in
> Pascal is zip. The trick there is to a) return instances, not
> references, from all the overloads and b) to have the assignment (= in
> c, := in Pascal) operator overloaded as well. variable.

It's inpossible to do right expressions calculating with references as
params if compiler have only "reference:=" : we can't replace "b:=a*1"
by "b:=a".

(solution is when compiler have "COPY:=" ,and does "REFERENCE:=" only
when right side is temp.But we should change compiler for it!)

General Solution Of All Problems With Existing Compiler ;-))) :

1:always use "a.newinstance" instead of "a":
(a.newinstance returns reference to copy of a.)

2: "+" operator should destroy it's params.(or reuse one param for
result)
It will work exactly as with static data types like integer.

and
a*(b+c)
should be
a.newinstance*(b.newinstance+c.newinstance),

+ will destroy 2 operand instances,and will create temp(or will re-use
one of papams for result)
* will destroy a.newinstance and temp,
and will return instance of result.

Here we can replace "b:=a.newinstance*1" by "b:=a.newinstance",

and in first solution we can't replace "b:=a*1" by "b:=a" because
"a*1" return instance,and "a" return reference.

It's seems to be simplest solution,and it's kills 2 problems.

If you don't like long "a.newinstance" you can create your "a.copy"

Quote:
> could operator overload on a record... Which you probably can't...

No, we can.
I'm using records.
Ucomplex also uses it.
Why we need CLASSES for it? Only because classes have matrix[n,m]
...;-)

and because for first view it seems to be possible to do abstract
algebra with classes data abstraction.But nexttime it cause a lot of
problems(IMHO)

Sat, 17 Dec 2005 17:12:42 GMT
FPC - wasted memory...

Quote:

>> > doing the a:=b*c; d:=a+e; a.destroy; thing. It's (imo) a workaround,
>> > not a solution.

>> Using refcounted interfaces might be a "better" solution. (for 1.1), but I
>> haven't tried that.

>> This worked very well for me (and even better in some circumstances)

> Again, I will talk c as my experience with operator overloading in
> Pascal is zip. The trick there is to a) return instances, not
> references, from all the overloads and b) to have the assignment (= in
> c, := in Pascal) operator overloaded as well.

I know that. (btw C++, not C) But Pascal has a more advanced dynamic,
reference based and mandatory destructed object type.

As said before you could try to use the old (static) TP based object model,
but I don't encourage it.

Still, if you allocate memory somewhere IN the object (a malloc or so)
you'll loose memory.

Quote:
> I tried hard to get my Delphi compiler to return me object instances,
> but failed. (anyone know how to do this?)

You can't.

Quote:
> As I have previously said, I don't think Pascal is really compatible with
> operator overload in the "clean" way where ONLY the constructor (and copy
> constructor) returns a pointer to a locally created variable...

The C++ way works, but static objects aren't nice in general. IMHO it looses
more on that side than that it wins with rarely used features like this.

The solution would be to use more expensive (in terms of performance)
constructs like reference counting. As said, this can probably done using
interfaces. I believe there is some Jedi STL'ish unit that demonstrates this

Quote:
> Of course this could be done with records, if you could operator overload
> on a record... Which you probably can't..

IIRC the operator overloading example in the manual is on records (complex,
two reals in a record)

Records are no problem, but you can't e.g. put a pointer to dynamic store in
the record, or you are back at the original problem.

Sat, 17 Dec 2005 17:23:44 GMT
FPC - wasted memory...

Quote:
> FPC implemented it first, but only for static types. It seems the newest
> Delphi also has something like that (I see it in the feature matrix), but
> I don't know if it has it in the same way.

Newest Delpi has some operators defined for a Variant type, and if you
subclass it you can create types which respond to operators. VERY SLOW:
NEVER USE IT!!! The Complex type implemented using it turn out orders of
magnitude slower than that in Python!!!

And this is not true that FPC implemented it first, there was a Pascal
compiler for mathematicians, which spit out C code, and was the first

Have to see whether this feature in GPC is somewhat better.

Another alternative would be to hang on a garbage collector. There is an
adaptation of Boehn's GC for Delphi, which relies upon MemoryManager
replacement interface. (yes, Delphi has some cool corners!) Does FPK or
GPC support something alike?

Now, may i advertise another language which gets it right? Sather. And,
as another alternative: D. C++ has also some workaround for such things
which would allow to avoid memory leaks automatically, but i'm not sure
i remember exactly.

BTW, why do you need dynamic types? You can use the old "object" and
allocate them on stack.

-i.

Thu, 22 Dec 2005 22:09:46 GMT
FPC - wasted memory...

Quote:

>> FPC implemented it first, but only for static types. It seems the newest
>> Delphi also has something like that (I see it in the feature matrix), but
>> I don't know if it has it in the same way.

> Newest Delpi has some operators defined for a Variant type, and if you
> subclass it you can create types which respond to operators. VERY SLOW:
> NEVER USE IT!!! The Complex type implemented using it turn out orders of
> magnitude slower than that in Python!!!

> And this is not true that FPC implemented it first, there was a Pascal
> compiler for mathematicians, which spit out C code, and was the first

I'm talking about the Borland dialects now.

Quote:
> Have to see whether this feature in GPC is somewhat better.

I doubt it. I used GPC for a while when I had a customer that had some SPARC
hardware a subset of the application had to run on. Except hardware support
it was (IMHO, but I'm biassed and this was 2-2 1/2 years ago) inferior in
most other aspects, including ease of setting up, documentation and
bug-ratio. But I needed the Borland dialect then.

Quote:
> Another alternative would be to hang on a garbage collector. There is an
> adaptation of Boehn's GC for Delphi, which relies upon MemoryManager
> replacement interface. (yes, Delphi has some cool corners!) Does FPK or
> GPC support something alike?

No. And the minute it does, I'll probably drop it. Total overkill to
introduce such far reaching technology that interferes with every aspect of
the language for some easier implementation of an IMHO minor feature like

Quote:
> Now, may i advertise another language which gets it right? Sather. And,
> as another alternative: D. C++ has also some workaround for such things
> which would allow to avoid memory leaks automatically, but i'm not sure
> i remember exactly.

I don't like D. I think trying to make a connection between D and C/C++ killed it.

I do have a somewhat list for what I want in a language. It is far from incomplete:
- Also I want a multi paradigm language, (and then I mean OOP and procedural) So no pure OOP, and
- preferably no GC (slower for languages as C++ and Delphi).
- But if it is a GC language, it _must_ have guaranteed calling of a custom destructor.
- preferably low level interfacing without the need for additional marshalling.
- Object model with features suitable for RAD implementation.
- solidly compiled.
- It doesn't have to be a totally mainstream language, but some community and 3rd party source
would be welcome. Because of this point I left Modula2. TP/FPC/Delphi still have critical
mass enough IMHO
- C/C++/Java like syntax is a slight minus. A bit larger source code size over all
kinds of unreadable interpunction-chars as language elements and operators.

I haven't found much, but haven't really searched. Maybe Ada would have fit
the bill, the language sounds nice, and it is one of the more popular little
languages, but currently my current investments in Delphi/FPC vastly outpace

I quickly looked up Sather, but it violates most of above points.

Quote:
> BTW, why do you need dynamic types?

RAD extensibility, better componentisable. Most static objects are used via
a pointer anyway, and that's ackward. I'm prepared to face simple set backs
as this detail for that.

Quote:
> You can use the old "object" and allocate them on stack.

I still can't use dynamic storage. Not with the TP static object either.

Sun, 25 Dec 2005 07:29:26 GMT
FPC - wasted memory...

Quote:
>> i remember exactly.

> I don't like D. I think trying to make a connection between D and C/C++ killed it.

> I do have a somewhat list for what I want in a language. It is far from incomplete:
> - Also I want a multi paradigm language, (and then I mean OOP and procedural) So no pure OOP, and
> - preferably no GC (slower for languages as C++ and Delphi).
> - But if it is a GC language, it _must_ have guaranteed calling of a custom destructor.
> - preferably low level interfacing without the need for additional marshalling.
> - Object model with features suitable for RAD implementation.
> - solidly compiled.
> - It doesn't have to be a totally mainstream language, but some community and 3rd party source
>    would be welcome. Because of this point I left Modula2. TP/FPC/Delphi still have critical
>    mass enough IMHO
> - C/C++/Java like syntax is a slight minus. A bit larger source code size over all
>   kinds of unreadable interpunction-chars as language elements and operators.

- multiple compilers available for the core platforms.

Sun, 25 Dec 2005 07:31:22 GMT
FPC - wasted memory...

Quote:

> >> FPC implemented it first, but only for static types. It seems the newest
> >> Delphi also has something like that (I see it in the feature matrix), but
> >> I don't know if it has it in the same way.

> > Newest Delpi has some operators defined for a Variant type, and if you
> > subclass it you can create types which respond to operators. VERY SLOW:
> > NEVER USE IT!!! The Complex type implemented using it turn out orders of
> > magnitude slower than that in Python!!!

> > And this is not true that FPC implemented it first, there was a Pascal
> > compiler for mathematicians, which spit out C code, and was the first

> I'm talking about the Borland dialects now.

> > Have to see whether this feature in GPC is somewhat better.

> I doubt it. I used GPC for a while when I had a customer that had some SPARC
> hardware a subset of the application had to run on. Except hardware support
> it was (IMHO, but I'm biassed and this was 2-2 1/2 years ago) inferior in
> most other aspects, including ease of setting up, documentation and
> bug-ratio. But I needed the Borland dialect then.

> > Another alternative would be to hang on a garbage collector. There is an
> > adaptation of Boehn's GC for Delphi, which relies upon MemoryManager
> > replacement interface. (yes, Delphi has some cool corners!) Does FPK or
> > GPC support something alike?

> No. And the minute it does, I'll probably drop it. Total overkill to
> introduce such far reaching technology that interferes with every aspect of
> the language for some easier implementation of an IMHO minor feature like

> > Now, may i advertise another language which gets it right? Sather. And,
> > as another alternative: D. C++ has also some workaround for such things
> > which would allow to avoid memory leaks automatically, but i'm not sure
> > i remember exactly.

> I don't like D. I think trying to make a connection between D and C/C++ killed it.

> I do have a somewhat list for what I want in a language. It is far from incomplete:
> - Also I want a multi paradigm language, (and then I mean OOP and procedural) So no pure OOP, and
> - preferably no GC (slower for languages as C++ and Delphi).
> - But if it is a GC language, it _must_ have guaranteed calling of a custom destructor.
> - preferably low level interfacing without the need for additional marshalling.
> - Object model with features suitable for RAD implementation.
> - solidly compiled.
> - It doesn't have to be a totally mainstream language, but some community and 3rd party source
>         would be welcome. Because of this point I left Modula2. TP/FPC/Delphi still have critical
>         mass enough IMHO
> - C/C++/Java like syntax is a slight minus. A bit larger source code size over all
>   kinds of unreadable interpunction-chars as language elements and operators.

> I haven't found much, but haven't really searched. Maybe Ada would have fit
> the bill, the language sounds nice, and it is one of the more popular little
> languages, but currently my current investments in Delphi/FPC vastly outpace

> I quickly looked up Sather, but it violates most of above points.

> > BTW, why do you need dynamic types?

> RAD extensibility, better componentisable. Most static objects are used via
> a pointer anyway, and that's ackward. I'm prepared to face simple set backs
> as this detail for that.

> > You can use the old "object" and allocate them on stack.

> I still can't use dynamic storage. Not with the TP static object either.

Heh, i'm also searched for good language(mainly for methods of multiple
objects, data abstraction for abstract algebra(that reqires  methods of