Your Rank: 49
Nullable Types. Great. If I had one wish: Disable comparisons with Nullable Types.
Ah, now it's clear! Thank you.
> 'So i cannot return an object created inside a function?' - Marco's not saying that.The first paragraph of "What is an Unsafe Reference?" says, as far I understand, exactly this. But the docs say Delphi can handle temporary objects.
http://docwiki.embarcadero.com/RADStudio/Seattle/en/Automatic_Reference_Counting_in_Delphi_Mobile_Compilers"A very interesting side effect of using ARC memory management is that the compiler can handle the lifetime of temporary objects returned by fu
I dont understand this Point: "A classic example is that of a function creating and returning an instance" So i cannot return an object created inside a function? And why "could" and "might"? ARC has typically a quite deterministic behaviour. What ar
Are there any new Delphi language Features?
No, I am not reading the value. In the list I save it as future interface. And this part is very fast. After that I loop over the list with calling .value on each element. And that takes the time. Another strange behaviour is, that when stepping through the list that calls .value the processor seems to use only (in sum) a single core....
Is there something I can do to see why a loop that calls TTask.Future every runis exactly as fast as a simple seriell loop without parallelization? The run itself is fast but inside I add every Object (result from the Future) as IFuture to a TObjectList and a loop over the list with calling .Value on the Object stops and takes exactly as long as...
> More regarding #1. The Delphi language itself is more than a decade behind in terms of features as well, and Xe8 offers ZERO language enhancements++ I was very disappointed as well. In XE7 at least a few tiny things were added. But in XE8 - nothing
I hope reference counting will come globally some day.
"you need it as interface" means that different objects can be created. They only have the interface in common.
But I think I understood.
- delete this 3 interface functions
- copy them from TInterfacedObject
- treat it like a "real" interface
- My Code was an object (without any interfaces).
- In a next step I needed to pass this object as an interface to a function.
So not to destroy my logic and memory menagement I added an interface and copied the necessary functions (addref, release, queryinterface) from TInterfacedPersistent (because direct inheritance was not possible).
- Now I additionally need the object inside the "main" program as an interface. So whtat to do?
So the conclusion would be: if you want to do something like in my example, don't use TInterfacedPersistent?
Nevertheless _Release is called. And TInterfacedPersistent's implementation of _Release decides not to do reference counting.
So _Release on a freed object will be called (but a pointer <> nil).
In my Version I have at least a nil pointer.
So what would be the way to destroy this correctly?
Is this Code save?
IFoo = interface procedure Hallo(); procedure Free(); end; TFoo = class(TInterfacedPersistent, IFoo) public procedure Hallo(); destructor Destroy(); override; end; ... procedure TForm1.btn1Click(Sender: TObject); var oFoo: IFoo; begin oFoo := TFoo.Create; oFoo.Free; oFoo := nil; // Calls _Release with a nil self. But TInterfacedPersistent._Release seems to handle this situation? end;
It seems it was the recently introduced debugger bug (I think only Win64).
It is a not really reproducable bug that seldom the debugger does weired control flow.
for i := 0 to ... starts with 1
if oPanel.Visible skips the block even if (and the inspector also says yes) it is visible
Sometimes a switch to 32 bit and back helps, sometimes a restart helps, ...
What is the difference between "InheritsFrom()" and "is"?
Until recently I thought they do the same, but now I have a case where InheritsFrom works, but "is" says False.