[fpc-devel]Proposal for audo-destructors

[netsurfer]

Hello.

Absence of automatic construction/destruction of 
classes is very painfull and it can significantly 
degrade the
development process (i.e. smart pointers and RAII are 
impossible). It's one of the greatest flaws of Pascal 
relatevly to
C   (the second thing are Templates of cource). Are 
there any plans for serious language extensions in 
this way for post
2.0 releases of FPC ?

P.S. The simpliest proposal for syntax for auto 
construction/destruction could be like (maybe with 
some restrictions
 on constructors/destructors):

 Procedure Something;
 Var T:tMyClass;Auto;
 Begin   - T auto created here
...
If ... Then Exit; - T auto destructed here
...
 End;- T auto destructed here

 P.P.S. The auto modifier should affect only stack 
variables.
There's no great need of this for global vars.


-- 
Sergey Kosarevsky
[Linderdaum Team]
http://linderdaum.gamedot.ru
[EMAIL PROTECTED]

___
fpc-devel maillist  -  [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel]Translation language file: danish

[Tomas Hajny]

From:   Christian Iversen [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject:[fpc-devel]Translation language file: danish
Send reply to:  [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
Date sent:  Sun, 12 Sep 2004 11:10:16 +0200


Hi Christian

 To day ago, I got bored, and so I wrote a danish language file for fpc
 :)
 
 I just need a little help before it's complete.
 
 The meaning of the following entries escape me:

I'll only comment one of them, because that's what I know for sure...


 *O2Dw_PM-program

This is an OS/2-specific option (i.e. only valid for targets OS2 and 
EMX) - Presentation Manager (PM) is a GUI (windowing) subsystem of 
OS/2. This option is currently regarded as deprecated and only kept 
for compatibility with older versions, it's superseded with -WG (and 
thus equivalent to use of $APPTYPE GUI within program source).

Tomas


___
fpc-devel maillist  -  [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel]Proposal for audo-destructors

[Marco van de Voort]

 Absence of automatic construction/destruction of 
 classes is very painfull and it can significantly 
 degrade the
 development process (i.e. smart pointers and RAII are 
 impossible).

Very painfull is a bit exaggerated :-)

 It's one of the greatest flaws of Pascal relatevly to C (the second thing
 are Templates of cource).

C doesn't do that. I assume you mean C++.

 Are there any plans for serious language
 extensions in this way for post 2.0 releases of FPC ?

No. There is a big resistance against such features, mostly because
the benefits are superficial, and the idea is unpascallike.

Moreover it will be a Delphi incompability.
 
 P.S. The simpliest proposal for syntax for auto construction/destruction
 could be like (maybe with some restrictions
  on constructors/destructors):
 
  Procedure Something;
  Var T:tMyClass;Auto;
  Begin   - T auto created here
 ...
 If ... Then Exit; - T auto destructed here
 ...
  End;- T auto destructed here
 
  P.P.S. The auto modifier should affect only stack 
 variables.
 There's no great need of this for global vars.

I don't like it. Either go the full way (like e.g. with ansistrings) or
don't go there at all. This is a hack.

___
fpc-devel maillist  -  [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel]Proposal for audo-destructors

[Nico Aragón]

Hello,

On Sun, 12 Sep 2004 13:02:52 +0200, Marc Weustink
[EMAIL PROTECTED] wrote:

  Procedure Something;
  Var T:tMyClass;Auto;
  Begin   - T auto created here
 ...
 If ... Then Exit; - T auto destructed here
 ...
  End;- T auto destructed here

  P.P.S. The auto modifier should affect only stack
variables.
 There's no great need of this for global vars.

Again, what if you assign T to a global var or a class member ?

Why would you want to do that?

You still can declare var T: MyClass if you plan to use T as a local
reference. Obviously you only declare variables as automatic when you
want to bind its lifecycle to the current procedure.


--
saludos,
  
  Nico Aragón

NOTE: na-list address only works for messages coming from lists.
Please, write to nico at the same domain for direct email.

___
fpc-devel maillist  -  [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel]Proposal for audo-destructors

[Nico Aragón]

Hello,

On Sun, 12 Sep 2004 13:07:24 +0200 (CEST), [EMAIL PROTECTED] (Marco van
de Voort) wrote:

 Absence of automatic construction/destruction of 
 classes is very painfull and it can significantly 
 degrade the
 development process (i.e. smart pointers and RAII are 
 impossible).

Very painfull is a bit exaggerated :-)

Sometimes, it's. F.i.:

  procedure CopyFile(SourceFileName, TargetFileName: string);
  var
  s, t: TStream;
  begin
  s := TFileStream.Create(SourceFileName, fmOpenRead);
  try
  t := TFileStream.Create(TargetFileName, fmCreate);
  try
  t.CopyFrom(s);
  finally
  t.Free;
  end;
  finally
  s.Free;
  end;
  end;

Imagine you could write:

  procedure CopyFile(SourceFileName, TargetFileName: string);
  auto
  s, t: TStream;
  begin
  s := TFileStream.Create(SourceFileName, fmOpenRead);
  t := TFileStream.Create(TargetFileName, fmCreate);
  t.CopyFrom(s);
  end;

Eight lines instead of sixteen and much clearer. The compiler would
internally translate it to something like:

  procedure CopyFile(SourceFileName, TargetFileName: string);
  var
  s, t: TStream;
  begin
  // -- Start initialization block ---
  s := nil;
  t := nil;
  try
  // -- End initialization block -

  s := TFileStream.Create(SourceFileName, fmOpenRead);
  t := TFileStream.Create(TargetFileName, fmCreate);
  t.CopyFrom(s);

  // -- Start finalization block -
  finally
  s.Free;
  t.Free;
  end;
  // -- End finalization block ---
  end;

I guess it's much alike to what happens with AnsiStrings.

 Are there any plans for serious language
 extensions in this way for post 2.0 releases of FPC ?

No. There is a big resistance against such features, mostly because
the benefits are superficial, and the idea is unpascallike.

What I like of Pascal is clarity. I feel much more pascal-like the
eight lines version than the sixteen lines one. 

And you can still declare normal variables with explicit
destruction. It's not like Java and other languages that forces you to
use automatically disposed variables. You can choose.

I wonder what big resistance means exactly. It could be that none of
FPC developers wants to spend his time with this feature. But what if
someone implemented it as a patch? Would it be rejected?

Another option: would it be possible to plug in the compiler to add
user extensions?

Moreover it will be a Delphi incompability.

* You aren't forced to use this feature. You can be compatible simply
not using it. 
* There are other FPC features that aren't present in Delphi like
overloaded operators. 
* It's better to be incompatible because you have more features than
because you have less features. 
* Delphi is going to implement something like this anyway to keep its
compatibility with its .NET version.

 P.S. The simpliest proposal for syntax for auto construction/destruction
 could be like (maybe with some restrictions
  on constructors/destructors):
 
  Procedure Something;
  Var T:tMyClass;Auto;
  Begin   - T auto created here
 ...
 If ... Then Exit; - T auto destructed here
 ...
  End;- T auto destructed here
 
  P.P.S. The auto modifier should affect only stack 
 variables.
 There's no great need of this for global vars.

I don't like it. Either go the full way (like e.g. with ansistrings) or
don't go there at all. This is a hack.

Why? Its implementation is straight-forward, simpler than ansistrings'
and eliminates all that distracting memory plumbing code. 



--
saludos,
  
  Nico Aragón

NOTE: na-list address only works for messages coming from lists.
Please, write to nico at the same domain for direct email.

___
fpc-devel maillist  -  [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-devel

RE: [fpc-devel]Proposal for audo-destructors

[Kalabukhov Alex]

Do you need second C++ with pascal syntax? :)

Auto-destructors? It's very simple!!! :)

(**)

unit uGC;

interface

type
  IAutoObject = interface
function GetObject: TObject;
property AObject: TObject read GetObject;
  end;

  TAutoObject = class(TInterfacedObject, IAutoObject)
  private
FObj: TObject;
  public
constructor Create(Object_: TObject); virtual;
destructor Destroy; override;
function GetObject: TObject;
  end;

  function IObject(Object_: TObject): IAutoObject;

implementation

constructor TAutoObject.Create(Object_: TObject);
begin
  FObj := Object_;
end;

destructor TAutoObject.Destroy;
begin
  if FObj  nil then
FObj.Free;
  inherited;
end;

function TAutoObject.GetObject: TObject;
begin
  Result := FObj;
end;

function IObject(Object_: TObject): IAutoObject;
begin
  Result := TAutoObject.Create(Object_);
end;

end.

(**)

Example:

var
  Tmp: TMyClass;
begin
  Tmp := IObject(TMyClass.Create).AObject as TMyObject;
end;


Absence of automatic construction/destruction of 
classes is very painfull and it can significantly 
degrade the
development process (i.e. smart pointers and RAII are 
impossible). It's one of the greatest flaws of Pascal 
relatevly to
C   (the second thing are Templates of cource). Are 
there any plans for serious language extensions in 
this way for post
2.0 releases of FPC ?



___
fpc-devel maillist  -  [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel]Proposal for audo-destructors

[Michael . VanCanneyt]

On Sun, 12 Sep 2004, Vincent Snijders wrote:

 Nico Aragón wrote:
 
  Hello,
  
  On Sun, 12 Sep 2004 13:07:24 +0200 (CEST), [EMAIL PROTECTED] (Marco van
  de Voort) wrote:
  
  
 Absence of automatic construction/destruction of 
 classes is very painfull and it can significantly 
 degrade the
 development process (i.e. smart pointers and RAII are 
 impossible).
 
 Very painfull is a bit exaggerated :-)
  
  
  Sometimes, it's. F.i.:
  
procedure CopyFile(SourceFileName, TargetFileName: string);
var
s, t: TStream;
begin
s := TFileStream.Create(SourceFileName, fmOpenRead);
try
t := TFileStream.Create(TargetFileName, fmCreate);
try
t.CopyFrom(s);
finally
t.Free;
end;
finally
s.Free;
end;
end;
 
 Except in the original proposal, constructor were to be compiler 
 generated too. That is impossible in this example, since the constructor 
 has parameters.
 
  Imagine you could write:
  
procedure CopyFile(SourceFileName, TargetFileName: string);
auto
s, t: TStream;
begin
s := TFileStream.Create(SourceFileName, fmOpenRead);
t := TFileStream.Create(TargetFileName, fmCreate);
t.CopyFrom(s);
end;

It is not so easy. What about the following code:

   procedure CreateIOStream(Var AStream : TStream);
   auto
  t: TStream;
   begin
  s := TFileStream.Create(SourceFileName, fmOpenRead);
  // Something
  AStream:=S;
   end;

Here the assignment is explicit, but it could be implicit as well.
It's not possible to solve this kind of issue without some form 
of reference counting.

The matter has been discussed several times by the FPC core group, at great
length. No satisfying solution on which everyone agreed was reached. 

Michael.

___
fpc-devel maillist  -  [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel]Translation language file: danish

[Jonas Maebe]

On 12 sep 2004, at 11:10, Christian Iversen wrote:
parser_e_generic_methods_only_in_methods=03072_E_methods can be only 
in other
methods called direct with type identifier of the class
I don't know what this one means either. From the source of the 
compiler, it seems this message is written out if you use inherited 
outside a method (e.g. in a normal procedure or function).

parser_e_self_in_non_message_handler=03146_E_Self can only be an 
explicit
parameter in methods which are message handlers
It means that you can only declare a method which has a parameter 
called self in case that method is declared as a message handler.

execinfo_f_cant_process_executable=09028_F_Can't post process 
executable $1
The postprocessing (not post processing, that's what they do at the 
post office :) only happens under Win32 (currently), and consists of 
updating some fields in the executable header (such stack reserve and 
commit size).

execinfo_x_stackreserve=09033_X_Reserveret stakstørrelse: $1 bytes
execinfo_x_stackcommit=09034_X_Brugt stakstørrelse: $1 bytes
http://bobmoore.mvps.org/Win32/w32tip55.htm
unit_u_no_reload_is_caller=10049_U_Ingen genindlæsning, $1 er kalder
unit_u_flag_for_reload=10051_U_Indstillinger for genindlæsning: $1
unit_u_second_compile_unit=10054_U_Compilerer allerede $1, starter 
anden
compilering
These are kind of complex to explain, they have to do with whether or 
not the compiler will recompile units and why.

Jonas
___
fpc-devel maillist  -  [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel]Proposal for audo-destructors

[Marco van de Voort]

 On Sun, 12 Sep 2004 13:07:24 +0200 (CEST), [EMAIL PROTECTED] (Marco van
 de Voort) wrote:
 
   procedure CopyFile(SourceFileName, TargetFileName: string);
   var
   s, t: TStream;
   begin
   s := TFileStream.Create(SourceFileName, fmOpenRead);
   try
   t := TFileStream.Create(TargetFileName, fmCreate);
   try
   t.CopyFrom(s);
   finally
   t.Free;
   end;
   finally
   s.Free;
   end;
   end;
 
 Imagine you could write:
 
   procedure CopyFile(SourceFileName, TargetFileName: string);
   auto
   s, t: TStream;
   begin
   s := TFileStream.Create(SourceFileName, fmOpenRead);
   t := TFileStream.Create(TargetFileName, fmCreate);
   t.CopyFrom(s);
   end;

(besides MVC's comments):

This is an exception already, but worse  the example is crafted so that
there is no discrimination where the error source is. This is rare.
Typically, a skeleton source as above would have EXCEPT clausules that
improve errorhandling.

This kind of constructs are extremely common in e.g. Java, but there nearly
everything is an object (strings inclusive)
 
 I guess it's much alike to what happens with AnsiStrings.

Ansistrings don't work with exceptions. 
 
 
 No. There is a big resistance against such features, mostly because
 the benefits are superficial, and the idea is unpascallike.
 
 What I like of Pascal is clarity. I feel much more pascal-like the
 eight lines version than the sixteen lines one. 

Clarity is not the same as terseness. Pascal is also consistency and safety.
There is too much that can go wrong with this kind of mechanisms, and too
little to be truely gained.

MvC already refered to earlier what if's we had on core about this kind of
functionality. (the one that only shortens a certain syntax, aka syntactic
sugar)

It was deemed a better solution to have the IDE (e.g. Lazarus) autogenerate
the above skeleton from the compiler.

 And you can still declare normal variables with explicit
 destruction. It's not like Java and other languages that forces you to
 use automatically disposed variables. You can choose.

No you can't. The safety of the automated type depends on the possibilities.
It would require a lot of extra checks and changes to make this even halfway
safe. 
 
 I wonder what big resistance means exactly. It could be that none of
 FPC developers wants to spend his time with this feature. But what if
 someone implemented it as a patch? Would it be rejected?

I think so, yes. 

 Another option: would it be possible to plug in the compiler to add
 user extensions?

Not really. Not for language related stuff. Maybe stuff like optimization
could be some what pluggable, but I doubt it. I think it would also
immensely increase (the already quite high) mem requirements.

 Moreover it will be a Delphi incompability.
 
 * You aren't forced to use this feature. You can be compatible simply
 not using it. 

No, but I'm supposed to provide support and help with bugreports. This
is an ugly can of worms for unsuspecting users. Even intermediate programmers
could fall easily for this (since an auto near the top is easily missed).

 * There are other FPC features that aren't present in Delphi like
 overloaded operators. 

However they nearly _all_ improve functionality, not merely cut a bit of
typing.

The only two exceptions is the exit(x) extension and the use of ^basetype;
as array (Cish). However these are extremely common.

 * It's better to be incompatible because you have more features than
 because you have less features. 

No. More features is not better in languages. 
(and neither in Word Processors btw. Exhibit A: Word). A syntax must be
orthogonal, systematic and intuitive.

Shorter syntax also isn't automatically better (Examples enough, C, Perl are
known for their terse and unreadable syntaxes)

 * Delphi is going to implement something like this anyway to keep its
 compatibility with its .NET version.

Delphi.NET is IMHO a project relatively unrelated to Delphi, since it 
breaks code running since TP3.

Delphi.NET is more the Java way, and totally different rules apply to it,
whether you like or dislike it. See also 
http://www.freepascal.org/faq.html#dotnet

for a short (but still unpolished) summary.
 
 I don't like it. Either go the full way (like e.g. with ansistrings) or
 don't go there at all. This is a hack.
 
 Why? Its implementation is straight-forward, simpler than ansistrings'

Yes, but ansistrings are safe. This isn't. Moreover ansistrings have an
important issue that couldn't be done earlier ((nearly) unbounded strings,
that are very native). This only saves typing.

 and eliminates all that distracting memory plumbing code. 

No. It only saves that in a few exotic cases. If you want to have that all,
you need to change languages, and go to something truely automated. Be it
Oberon (aka Component Pascal for the .NETies), Smalltalk, Java, C# or
Delphi.NET)

However then you pay the price in 

Re: [fpc-devel]Proposal for audo-destructors

[Jonas Maebe]

On 12 sep 2004, at 15:56, Marco van de Voort wrote:
I guess it's much alike to what happens with AnsiStrings.
Ansistrings don't work with exceptions.
Sure they do, that's why you can turn them off using 
{$IMPLICITEXCEPTIONS OFF}. The same goes for class constructors afaik 
(which is why we turn them off in the compiler for speed reasons, but 
it can cause memory leaks in case something goes wrong).

Jonas
___
fpc-devel maillist  -  [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel]Generic Types in FPC

[Peter Vreman]

 According to Robert Love's blog Delphi will provide generic types
 support. Will FPC support the feature in the same way?

 Delphi Syntax for Generic Types will be:

 type
   TFooT = class
   private
data1: T;
   public
 function SomMethod(param1: INteger; Param2 :T) : Integer;
   end;

 function TFooT.SomeMethod(...);
 begin
 end;

 var
   Foo : TFooInteger;

Maybe in the far-far future and only when it is really needed for
compatibility.

First the focus is on a stable multiplatform compiler with compatibility
upto delphi 7. Things like packages support is much more important than
all these new features, which are not even in a released delphi.



___
fpc-devel maillist  -  [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel]Proposal for audo-destructors

[Nico Aragón]

Hello,

On Sun, 12 Sep 2004 15:28:40 +0200 (CEST), [EMAIL PROTECTED]
wrote:

procedure CopyFile(SourceFileName, TargetFileName: string);
auto
s, t: TStream;
begin
s := TFileStream.Create(SourceFileName, fmOpenRead);
t := TFileStream.Create(TargetFileName, fmCreate);
t.CopyFrom(s);
end;

It is not so easy. What about the following code:

   procedure CreateIOStream(Var AStream : TStream);
   auto
  t: TStream;
   begin
  s := TFileStream.Create(SourceFileName, fmOpenRead);
  // Something
  AStream:=S;
   end;

This code is wrong. If you use auto, your goal is to schedule the
variable for destruction when the current function is left. If you
want the variable to survive outside, then you should declare it as
normal var.

The question would be how should the compiler react to this error. I
think that issuing a warning would be a sensible choice, because it's
sort of symmetrical to variable 'foo' might not have been
initialized.

Borland way, since the first versions of TP has been to allow
programmers to shoot theirselves in the foot... if they're really
decided to do so and explicitily state it. 

Here the assignment is explicit, but it could be implicit as well.

A direct assignment (to global variable or output parameter) would be
easy to detect and warn the programmer. If you use Move or something
like that, then you're badly begging to shoot yourself in the foot :-)

I can only think of a case, that's really difficult (not impossible)
to track: a local variable that is assigned to a global one by means
of a call to a function. 

It's not possible to solve this kind of issue without some form 
of reference counting.

Reference counting is more complex. You have written the
implementation for ansistring anyway. It would be nice to have it
extended to objects too.

The matter has been discussed several times by the FPC core group, at great
length. No satisfying solution on which everyone agreed was reached. 

I would really appreciate some comments on my question about patches
that would implement optional, unofficial or pluggable features.
I would like very much to be able to build extensions for particular
idioms. I understand that not everybody will like this possibility.
The question is if core developers would dislike it so much as to
prefer to keep it off the official code.

It's also possible to implement extensions using some kind of
preprocessor. But then a lot of code would be duplicated because the
preprocessor must do a considerably more complex job than macro
substitution... much like what the compiler itself does later.

I'm not asking just out of curiosity. I have some ideas and code and
would like to know if/how could fit with FPC.



--
saludos,
  
  Nico Aragón

NOTE: na-list address only works for messages coming from lists.
Please, write to nico at the same domain for direct email.

___
fpc-devel maillist  -  [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel]Proposal for audo-destructors

[Peter Vreman]

The matter has been discussed several times by the FPC core group, at
 great
length. No satisfying solution on which everyone agreed was reached.

 I would really appreciate some comments on my question about patches
 that would implement optional, unofficial or pluggable features.
 I would like very much to be able to build extensions for particular
 idioms. I understand that not everybody will like this possibility.
 The question is if core developers would dislike it so much as to
 prefer to keep it off the official code.

 It's also possible to implement extensions using some kind of
 preprocessor. But then a lot of code would be duplicated because the
 preprocessor must do a considerably more complex job than macro
 substitution... much like what the compiler itself does later.

 I'm not asking just out of curiosity. I have some ideas and code and
 would like to know if/how could fit with FPC.

Plugin support for the parser is impossible, everything is too much
dependent on other parts. Only assembler/linker etc. could maybe made an
plugin.

Patches for bugs and compatibility issues are always welcome. Patches for
new constructs will only be applied when everybody agrees on the syntax
and behaviour.





___
fpc-devel maillist  -  [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel]Proposal for audo-destructors

[Nico Aragón]

Hello,

On Sun, 12 Sep 2004 17:38:22 +0200 (CEST), Peter Vreman
[EMAIL PROTECTED] wrote:

Plugin support for the parser is impossible, everything is too much
dependent on other parts. Only assembler/linker etc. could maybe made an
plugin.

Would it be feasible to write a different parser that outputs some
intermediate format to pass to code generator?



--
saludos,
  
  Nico Aragón

NOTE: na-list address only works for messages coming from lists.
Please, write to nico at the same domain for direct email.

___
fpc-devel maillist  -  [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel]Proposal for audo-destructors

[Marco van de Voort]

 On Sun, 12 Sep 2004 17:38:22 +0200 (CEST), Peter Vreman
 [EMAIL PROTECTED] wrote:
 
 Plugin support for the parser is impossible, everything is too much
 dependent on other parts. Only assembler/linker etc. could maybe made an
 plugin.
 
 Would it be feasible to write a different parser that outputs some
 intermediate format to pass to code generator?

It would boil down to rewriting most of the compiler, except the real
assembler/linker parts, since a lot of core dataformats would change.


___
fpc-devel maillist  -  [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel]Proposals for IDE and language

[netsurfer]

Proposals for IDE

1) FP IDE dosn't allow to save classes chart to a file 
or even copy it as
   text to clipboard. Having a classes chart for 
compiled code sometimes is
   of great use.

2) Besides simple text search  replace it would be 
convinient to have some
   tools for making simple code refactoring. I.e. 
rename method/proc, 
   rename var/field (with complete update in all 
project's files).

Proposal for Pascal language:

   Are there any objections to implementation 
of Final directive for methods ?

___
fpc-devel maillist  -  [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel]Proposal for audo-destructors

[Nico Aragón]

Hello,

On Sun, 12 Sep 2004 20:38:52 +0400, [EMAIL PROTECTED] wrote:

Again, what if you assign T to a global var or a 
class member ?

Why would you want to do that?

You still can declare var T: MyClass if you plan to 
use T as a local
reference. Obviously you only declare variables as 
automatic when you
want to bind its lifecycle to the current procedure.

The problem actualy is not in automated destructors, 
but in that the Class
types are actually pointers in Delphi OO model. That 

IIRC, at binary level everything is in place:

var
  x: TSomeClass;
  { I don't know if following line would compile,
but it could be hardcoded }
  y: array[1..SomeClass.InstanceSize] of Byte;
begin
  x := SomeClass.InitInstance(@y);
  x.Create(params...);
  ...



--
saludos,
  
  Nico Aragón

NOTE: na-list address only works for messages coming from lists.
Please, write to nico at the same domain for direct email.

___
fpc-devel maillist  -  [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel]Proposal for audo-destructors

[Marco van de Voort]

 The problem actualy is not in automated destructors, 
 but in that the Class
 types are actually pointers in Delphi OO model. That 
 IS the hack, that makes some
 tasty stuff impossible (RAII)

Afaik RAII is simply that automated stuff is guaranteed finalised in a
predicatable time? (unlike e.g. Java where the GC can defer disposing an
object forever)

One can perfectly code in FPC such that way. Of course one should write
sensible code, but a few automated types won't help with that.

IMHO the C++ way is not safer this way either, since there are numerous
gotcha's. It mainly improves the amount of code one has to write, not
safety. However a sound alternative is to put this into the IDE.

IIRC smartpointers were added to C++ drafts to get a better security rating
according to American military standards. 

 or unconvinient (programmer has not to forget destructor).

Programmer must not forget to declare auto either. If you really want to
avoid human mistakes, automated code analysis systems is a wiser way to go.

 Just have a look at classes and pointers to classes in C.

Yes. BP did that too, (static objects are still possible in FPC that way)
luckily Delphi improved on that.

 The problem is that we have no similiar functionality for first ones in
 Pascal

As said, IMHO we don't need it. It is a feature for a different kind of
language. Ok, C++ added it, but C++ pretty much added everything they could
find :-) That's aggregation, not design.



___
fpc-devel maillist  -  [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel]Proposal for audo-destructors

[Nico Aragón]

Hello,

On Sun, 12 Sep 2004 18:45:53 +0200 (CEST), [EMAIL PROTECTED] (Marco van
de Voort) wrote:

 Would it be feasible to write a different parser that outputs some
 intermediate format to pass to code generator?

It would boil down to rewriting most of the compiler, except the real
assembler/linker parts, since a lot of core dataformats would change.

A pity. FPC source code could be generated by external parser after
translating extra features, but it would bad for debugger support,
etc. It seems that I must look elsewhere. 

Thank you again for clarifications.


--
saludos,
  
  Nico Aragón

NOTE: na-list address only works for messages coming from lists.
Please, write to nico at the same domain for direct email.

___
fpc-devel maillist  -  [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-devel