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.

Again, what if you assign T to a global var or a class member ? So in your example:

  Procedure Something;
  Var T:tMyClass;Auto;
  Begin   <- T auto created here
     GlobalT := T; <- What would this do ?
    ...
     If ... Then Exit; <- T auto destructed here
     ...
  End;    <- T auto destructed here

IMO if you want such behaviour, you can use interfaces.

Marc

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.

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

Hello,

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.

Hello,

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.

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.

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

Except in the original proposal, constructor were to be compiler generated too. That is impossible in this example, since the constructor has parameters.

Vincent.

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;

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.

(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.

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 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 speed, startup time, memory footprint, runtime versionitis and non native feel of the avg GUI. (read: Swing, but all have this kind of, since they try to hide the native OS too much)

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

Hello,

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.

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.

Hello,

This is for me very natural code. It was written by heart, but I have a lot of very similar code.

Typically, a skeleton source as above would have EXCEPT clausules that improve errorhandling.

This was indeed an example. But again, the code is reallistic, and the behaviour of a possible exception ("file not found 'c:\aaa.txt'") is very acceptable and similar to other classes that I have written myself.

> I guess it's much alike to what happens with AnsiStrings. Ansistrings don't work with exceptions.

Then, what happens with locally allocated strings if an exception raises in the middle of a function? If there is no code to catch the abnormal exit, the memory will be leaked!

I'm afraid you're right here. I didn't pretend it to be safe.

I'm sorry to read that (see my response to MvC) but thank you for the clarification. There are still ways to ease memory management without compiler support, but other improvements need plug-in support... or a rewrite :-(

No. More features is not better in languages.

I guess it's a matter of opinions :-)

I meant that sooner or later Borland will update its native code compiler, and then much of the features introduced in .NET version will be ported.

Fully automated language usually don't allow explicit memory life-cycle control. I think that having both options to choose from is not asking for too much.

Hello,

"Peter Vreman" 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?

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 IS the hack, that makes some
tasty stuff impossible (RAII) or unconvinient
(programmer has not to forget destructor).
Just have a look at "classes" and "pointers to
classes" in C . The problem is that
we have no similiar functionality for first ones in Pascal. That what i exactly meant
in my first post.

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

Hello,

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...);
  ...

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.

Hello,

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.

what do you think about this, instead?

   procedure CopyFile(SourceFileName, TargetFileName: string);
   begin
       TFileStream.Create(TargetFileName, fmCreate).
           CopyFrom(TFileStream.Create(SourceFileName, fmOpenRead));
   end;

I love how C++ can create anonymous objects with the lifetime of the expression that invokes their constructor. The "with" construct, moreover, lets you perform multiple operations on the temporary object, and, borrowing from C#, it can be extended to declare variables in mid-function:

with <var1>: <type1> [ = <init1> ], <var2>: <type2> [ = <init2> ] do [...]

You can just take the source code and do what you want with it and release it as AragonPascal or whatever. I already know somebody does it, try looking in google for "elaya" compiler. It is based on FPC sources as well and proposes a lot of great idioms. Although if FPC team would understand that there are plenty of people who are interested in FPC not because it's free and multiplatform, but because it allows new language features - maybe something can be done about it, at least the preprocessing interface or something. For instance I would like to use russian characters as identificator names, someone wants macros and templates, someone something else...

Yash

You can use custom variants for this, however, these aren't implemented yet completly in the fpc rtl.

The problem is maintance of such code. You can easily hack such stuff in the compiler but somebody has look after bug reports, check the testsuite results regularly if there is something broken etc.

Hello,

"Yakov Sudeikin" wrote

You can just take the source code and do what you want with it and release it as AragonPascal or whatever.

Thank you for your interest. But I'm writting something more alike a text editor than a compiler. I will need some "compiler type" code to do syntax highlightning, code completion and so on, but it seems easier to write the needed parts from scratch.