Re: [fpc-pascal] Compiling FPC for SPARC

2006-08-04 Thread Jonas Maebe


On 3 aug 2006, at 19:03, Jonas Maebe wrote:

on't bother with Solaris in 2.0.x, it won't work at all. None of  
the Solaris fixes from 2.1.1 have been merged


On a positive note, Sparc/Solaris works fine in 2.1.1


Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] Compiling FPC for SPARC

2006-08-04 Thread Mark Morgan Lloyd
Looking forward to getting that far :-)  I'm considering running up v8 in a
SPARCserver but right now I can do without the extra heat.

-- 
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  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


[fpc-pascal] Automatic objects

2006-08-04 Thread Lars Eriksen

Hello!

I've recently switched from Delphi to FP and never been exposed to 
TP-style objects before.


At first sight they seem very similar to Delphi-style classes. However, 
it seems it is possible to allocate them on the stack - very convenient.


Is it right to assume they are automatically deallocated when they go 
out of scope (e.g. no need to free them manually)?



___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] Automatic objects

2006-08-04 Thread Marco van de Voort
> Is it right to assume they are automatically deallocated when they go 
> out of scope (e.g. no need to free them manually)?

The space of the object is cleaned. However if the object uses dyn memory,
you will have to call the destructor (destroy) to make the object cleanup.

In general it is considered a good custom to destroy them.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] Automatic objects

2006-08-04 Thread Lars Eriksen

Marco van de Voort wrote:


The space of the object is cleaned. However if the object uses dyn memory,
you will have to call the destructor (destroy) to make the object cleanup.

In general it is considered a good custom to destroy them.


So no C++-style automatic deallocation (the destructor is called 
automatically) is done?


If not, do neither classes nor objects provide such functionality?
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] Automatic objects

2006-08-04 Thread Micha Nelissen
Marco van de Voort wrote:
>> Is it right to assume they are automatically deallocated when they go 
>> out of scope (e.g. no need to free them manually)?
> 
> The space of the object is cleaned. However if the object uses dyn memory,
> you will have to call the destructor (destroy) to make the object cleanup.

I think in theory it's possible for the compiler to automatically call
the destructor always when leaving the function (think implicit
exception handlers here), but I guess not so many people are using them
anymore in new code that it would be worth it. Would need a new keyword
or something too, as it's not backward-compatible obviously.

Micha
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] Automatic objects

2006-08-04 Thread Marco van de Voort
> Marco van de Voort wrote:
> 
> > The space of the object is cleaned. However if the object uses dyn memory,
> > you will have to call the destructor (destroy) to make the object cleanup.
> > 
> > In general it is considered a good custom to destroy them.
> 
> So no C++-style automatic deallocation (the destructor is called 
> automatically) is done?

No. Note that most local objects in C++ are strings and the like, but
strings and dynamic arrays are already first tier datatypes in FPC and
automatically managed.
 
> If not, do neither classes nor objects provide such functionality?

No. For classes it doesn't make sense anyway, since in the code a reference
could be passed to a different structure.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal