Jump to content
Wagner Landgraf

You RAD Studio 10.4 Sydney appreciated features and bug fixes

Recommended Posts

The new Error Insight is GREAT! It works really well!

After years of red squigglies for things that are not wrong, it is really nice to only see squigglies when something actually is wrong.

  • Like 6

Share this post


Link to post

Right now the quality portal is updated at a frenetic rate.  There was a very large number of fixes, I think more than in any other previous version, and I was quite pleased that quite a few of my reports have been resolved, some of the unexpectedly:

 

System.Threading got some attention with the famous Cancel and Wait issue resolved.

 

Issues I would like to see fixed now and consider critical are:

 

 

 

Edited by pyscripter
  • Like 1

Share this post


Link to post

I am pretty interested in hearing what are people thinking of implementing with Managed records.

 

-Tee-

Share this post


Link to post
6 hours ago, pyscripter said:

Right now the quality portal is updated at a frenetic rate.  There was a very large number of fixes, I think more than in any other previous version, and I was quite pleased that quite a few of my reports have been resolved, some of the unexpectedly:

 

System.Threading got some attention with the famous Cancel and Wait issue resolved.

 

Issues I would like to see fixed now and consider critical are:

 

 

 

On the plus side these can be readily fixed yourself for your programs. 

 

I mean, I've been running with a patched RTL for years that fixes all the design flaws in handling of floating point control flags. 

 

At least we have access to the RTL source code and so can apply fixes easily using code hooks. 

Share this post


Link to post
4 hours ago, Tommi Prami said:

I am pretty interested in hearing what are people thinking of implementing with Managed records.

 

-Tee-

I think there is a serious issue with the timing of finalization of temp managed records which now is ASAP unlike regular records.  Please see

 

Timing of finalization of temporary managed records

 

I would love to hear what the experts think about this.  @Stefan Glienke @David Heffernan @Marco Cantu etc.  

Edited by pyscripter

Share this post


Link to post

@pyscripter Looks weird given how other managed types lifetimes are being handled - but since we don't have precise language and design specs as always we can just guess.

 

Apart from that implementing smartpointer that way is wrong anyway because they break whenever there is an explicit or implicit assignment/copy going on.

Proper smartpointer need a shared block that holds a reference counter.

 

Shared<T> in Spring is implemented with several optimizations to avoid the overhead of object creation for this purpose using the all known "interface in record" approach and I challenge everyone to come up with a robust implementation using custom managed records to beat that.

Edited by Stefan Glienke
  • Like 1
  • Thanks 2

Share this post


Link to post
1 hour ago, pyscripter said:

I think there is a serious issue with the timing of finalization of temp managed records which now is ASAP unlike regular records. 

I actually prefer that finalization style over the way interfaces etc. are finalized. At least this is by design while the old style seems more like a side effect of an implementation detail.

 

I've always had a problem with this:

var
  Foo: IUnknown;
begin
  Foo := TInterfacedObject.Create as IUnknown;
  ...some code here...
  Foo := nil; // This doesn't destroy the object
  ...more code here...
end; // but this does

I've not tried it but from the comment by Chee Wee Chua on RSP-28520 is seems I could solve it with a managed record inside a local block.

Share this post


Link to post
17 minutes ago, Anders Melander said:

I actually prefer that finalization style over the way interfaces etc. are finalized. At least this is by design while the old style seems more like a side effect of an implementation detail.

 

I've always had a problem with this:


var
  Foo: IUnknown;
begin
  Foo := TInterfacedObject.Create as IUnknown;
  ...some code here...
  Foo := nil; // This doesn't destroy the object
  ...more code here...
end; // but this does

I've not tried it but from the comment by Chee Wee Chua on RSP-28520 is seems I could solve it with a managed record inside a local block.

Your example is not correct:

 

Try:

program Scope;
{$APPTYPE CONSOLE}

uses
  System.SysUtils,
  System.Classes;

type
  TTestScope = class(TInterfacedObject)
     destructor Destroy; override;
  end;

{ TTestScope }
destructor TTestScope.Destroy;
begin
  WriteLn('Gone');
  inherited;
end;

procedure Test;
var
  Foo: IUnknown;
begin
  Foo := TTestScope.Create as IUnknown;
  WriteLn('Do stuff');
  Foo := nil; // This does destroy the object
  WriteLn('Do more stuff');
end;

begin
  Test();
  ReadLn;
end.

Output:

 

Do stuff
Gone
Do more stuff

 

 

Edited by pyscripter
  • Like 3

Share this post


Link to post

@Anders Melander The general rule that has always applied is that managed types (strings, interfaces, records with managed fields, dynamic arrays, etc,) are finalized at the end of the scope in which they are introduced.  This included temp variables.

The newly introduced managed records breaks this rule.  Whether you like it better or not, it is inconsistent.

 

And a local block does not solve the problem.  The temp managed record will still self-destruct at the end of the statement it is used. 

Edited by pyscripter

Share this post


Link to post
6 hours ago, pyscripter said:

Your example is not correct

You're right. I tried to simplify the problem and simplified it so much that the problem didn't occur.

 

The actual problem I'm having is with factory methods that returns an interface; A common example is an implementation of the memento pattern that changes the current cursor and restores it when the memento is destroyed:

begin
  SaveCursor(crHourGlass);
  ...do stuff...
end; // Cursor is restored here

Works great, but occasionally I want to restore the cursor before the end of the block so I do like this:

var
  SavedCursor: ICursorRecall;
begin
  SavedCursor := SaveCursor(crHourGlass);
  ...do stuff...
  SaveCursor := nil;
  ...do more stuff...
end; // cursor is still restored here

It's been my understanding that this was caused by a hidden temporary variable that is created by the compiler when you call a function returning an interface, and I've just learned to live with it. The strange thing is that it doesn't always behave like this. Simple cases, like the example above, probably works as expected (i.e. nilling the reference destroys the object), but in more complex code the object is only destroyed when the reference goes out of scope.

Share this post


Link to post
Guest

Hide feeds!

 

This was a button in Tokyo and i had to press it each time i started the IDE (and restart and restart).

In Sydney it is a link in the bottom and the click on that link is persisted!

 

Neat-o.

 

/D

Share this post


Link to post

I like the record initialziation/finalization, but i was working on something i can use it for, and got this:

 

procedure THSNullableBooleanSerializer.Serialize(const AValue; const AWriter: IgoBsonBaseWriter);
var
  jsonvalue : THSNullableBoolean absolute AValue;
begin
    // do stuff
end;


[dcc32 Error] HESI.NullableTypes.pas(158): E2634 Declaring a managed record with absolute directive is not allowed

 

 

hmz, to bad ....

 

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×