David Heffernan

Those libraries will be appallingly slow. In terms of the calculation side of it, it doesn't sound like you have a problem. Use double. 

As far as the IDE goes its not surprising that a program written using the Delphi rtl doesn't convert floats to decimal text correctly because the rtl doesn't. Or vice versa. Never has done and in spite of Emba being told more than a decade ago they haven't shown any inclination to address it. 

In my code I use dtoa and dragon4 to do these things so I can get correct values. 

12 hours ago, darnocian said:

Say in serialisation, you construct offsets relative to a certain address (say the start of the first record), and in deserialisation in another process, you convert back to pointers again. The key to it being useful is the layout and relative addressing.

I'm not talking about generalities. I'm talking about this specific topic. The OP already said that the pointer values that are streamed are ignored.

The problem at hand is that the code does naive blitting of internal records, and these records have different layouts for different targets.

2 hours ago, Lars Fosdal said:

Offsets may be helpful if the streamed order is not the same as the desired order, such as for a tree structure. Personally, I'd opt for identities and rebuild the structure after loading the stream. But, since OP doesn't share sufficient info about content and structure, this is all speculation.

What would offsets be helpful for given that the data streamed in those fields is never used

On 1/2/2024 at 8:24 PM, Gord P said:

The true value of 1/7 is 0.142857142857142857..., where 142857 repeats itself forever.

Not in IEEE 754 floating point data types that you are using.

Anyway I'm not actually sure what your actual problem is. Do you feel that there is an issue with the debugger? 

As for 80 bit floats I don't see any future for them. That idea died and everyone uses 64 bit double now. Is double insufficient for your needs? 

Streaming offsets doesn't seem helpful. The user isn't interested in streaming addresses. The addresses are initialised at runtime. They are only streamed because the code is, er, sloppy, and blits raw records rather than serialising. 

Are you running your IDE elevated? 

I'm just curious but why are you using AnsiString casts which produce behaviour dependent on the executing process locale? Did you mean to encode as UTF8? 

1 hour ago, kosovali said:

Or any other solutions? 

But what is the problem? You can't solve something until you know what the problem is.

As Lars says, streaming pointers seems, er, pointless.

Surely this could be done using regular expressions

On 1/2/2024 at 11:21 PM, Navid Madani said:

Value types are copied unless passed by reference. That can impact performance.

When performance is an issue, pass by reference then. Presumably you are happy to use value types like integer? Or do you shun all value types? 

On 1/2/2024 at 11:21 PM, Navid Madani said:

Interfaces can emulate data immutability and prevent bugs.

Prevent what bugs? Code with interfaces can have bugs too. So it's not some magic solution. 

On 1/2/2024 at 11:21 PM, Navid Madani said:

Interfaces can prevent memory leaks.

Code using interfaces can have leaks. 

On 1/2/2024 at 11:21 PM, Navid Madani said:

Interfaces obviate the need for try-finally blocks,

They are still there, the compiler writes them. 

On 1/2/2024 at 11:21 PM, Navid Madani said:

It is not always a simple case of memory allocation/de-allocation with records on the heap.

It's the exact same pattern as used with classes. It's well known and easy to follow. 

On 1/2/2024 at 11:21 PM, Navid Madani said:

There can be issues with access violations, and hard to detect bugs if record pointers are accessed but point to invalid data.

This is true. But it's simple enough to flow the rules and avoid this. 

3 hours ago, Navid Madani said:

For one, your records could be duplicated on assignments

So what would be the problem with that? That's what happens with vakue types. 

3 hours ago, Navid Madani said:

I would use interface references to access them and avoid memory leaks

Why would interfaces be needed to avoid memory leaks? 

26 minutes ago, Lars Fosdal said:

That solution was already proposed.

Actually, I think that this was the first mention of GetMem in the thread.

1 hour ago, JiyaHana said:

You can try with the GetMem function to dynamically allocate memory for the record.

Problem with this is that if the record has any managed types, then they won't be properly initialised/finalised when using GetMem/FreeMem. This is what New/Dispose brings.

3 hours ago, David Heffernan said:

I can't see why your code should fail. I suggest that you submit a bug report to Quality Portal.

3 hours ago, David Heffernan said:

This looks like a compiler bug to me.

This looks like a compiler bug to me.

not(a) or True

should be the same as:

not a or True

which in turn is the same as:

(not a) or True

because unary not has a higher precedence than or. See Expressions (Delphi) - RAD Studio (embarcadero.com)

I can't see why your code should fail. I suggest that you submit a bug report to Quality Portal.

30 minutes ago, Fr0sT.Brutal said:

MS finally listened to demands and now you can create self-sufficient C# apps (with all required DLLs located near the EXE). The same could be with Java, just use a starter that would set path to local JRE.

That's been possible for years

I opened Visual Studio the other day and made some edits to a C# module that implements an API interface for our software. We have interfaces in a variety of languages, C++, Python, C#, etc. 

I was blown away when VS offered me suggestions for the code I was writing. Clearly it's using some AI library to do this. Honestly, the quality of the suggested code blew my mind. I knew what I wanted to write, and so did VS. 

This is only going to get better and better, but it's already amazing. So far as I know, there's nothing remotely like this for us Delphi users. Or would we get this is we wrote our code in an editor like VS Code?? 

4 hours ago, Uwe Raabe said:

Ehm, what were your hope based on then? Random mutations of code caused by solar flares?

I had hope based on my QC reports from XE7 days. 

In any case it's a huge design mistake for Emba to implement windows themed menus as custom draw. Just let the bloody system draw it and then it will always be right!! Well, MDI excluded, but menus are getting deprecated any time soon. 

3 hours ago, Uwe Raabe said:

Can you list the corresponding QP issues. I would like to have a look at that to push it a bit.

I never submitted any. 

11 hours ago, Darian Miller said:

So what happens when you drag your window from a non-High DPI monitor to a High DPI monitor and vice-versa?   Do you get a lag and a bunch of flicker?

Ha ha ha. I think we all know the answer to this. 

They can't even do menus properly. Even for the standard  windows theme the menus are custom drawn and the Emba code gets it wrong in various mixed dpi scenarios. 

When I switched to Delphi 11.3 I'd hoped to avoid having to patch the VCL to suppress its custom drawn menus. Alas that hope was doomed. 

1 hour ago, pmcgee said:

I just meant this type of situation where the C declarations are impenetrable, and Delphi is so much clearer:

That's fair. But it's not the subject of this discussion. 

4 hours ago, pmcgee said:

But of the code below, the new / dispose is (imo) ugly code that is unsuited to 2023, and to the long-term goal of regaining wider recognition of Delphi as a modern and relevant language.

begin
  var p:PRec := New(p);
  try
    p.x := 5;
  finally
    Dispose(p);
  end;
end;

begin
  var o := TRecObject.Create;
  try
    o.r.x := 5;
  finally
    o.Free;
  end;
end

The two versions are identical, apart from the double dereference with the class wrapper version. That's the only part that seems ugly to me. 

2 hours ago, pmcgee said:

I don't agree. I don't think it is the generally accepted meaning of 'raw pointer'. 
Maybe you are thinking of 'void pointer' ?

This is correct. Raw pointer in C++ is directly analogous to typer pointer in Delphi. 

However a reference to a class instance is actually no different from a raw pointer. You have to manage allocation and deallocation of both. Which is my point. 

9 hours ago, pmcgee said:

Wouldn't this be better expressed as a class containing a record?

type
TMyRec = record ... end;

TMyRecC = class
    r : TMyRec;
end;

If C++ can declare "no raw pointers", then we certainly should avoid it in Delphi, right?
This way you can maintain the usual convention with TMyRecC.Create and .Free, have constructor & destructor ... or use an interface ... or create your own smart pointer class ...

How is this materially different? You still need to explicitly Free, and you need try/finally. The class is just extra baggage. For what gain? 

That's what I thought. What about the part that pointed out the futility of setting the flag without having the corresponding compiler support?