David Heffernan

55 minutes ago, Kas Ob. said:

yet it is safer than C++

It's not safer than C++, it's exactly the same as C++

51 minutes ago, Rollo62 said:

This has bubbled up to an official statement now, I like these fast reactions 👍

https://blogs.embarcadero.com/is-delphi-a-memory-safe-language/?utm_source=Eloqua&utm_medium=email&utm_content=Article-240311-Multicontent

This is so stupid. Delphi and C++ are exactly the same in this regard.

In 2147 people will still be suggesting setting DoubleBuffered true to solve flicker problems rather than fixing the actual problem 

Title bar panel is effectively VCL styles because theres no api for that, I think. So you probably just have to suck it up. 

20 hours ago, dormky said:

The TLabel was just for demonstration purposes, I'd like to be able to do that with all components...

Late information boo

You should report these as bugs to Embarcadero, but unfortunately they've been unable to provide a mechanism for reporting bugs for last past few months.

4 minutes ago, Dalija Prasnikar said:

I hate to be the one saying this... but ARC compiler was a step in that direction. You cannot have memory safety without automatic memory management.

I guess ARC per-se wasn't the big problem, it was more the attempt to support ARC compilers and non-ARC compilers with the same codebases??

56 minutes ago, alogrep said:

When I do

  records:=Nil, does it free all "names" (and fname, lname) of all recs as well as the recods array itself?

Yes. 

37 minutes ago, DelphiUdIT said:

The array should not to be freed setting a nil, you must use

Wrong. Setting a dynamic array to nil is identical to setting length to 0 and identical to passing it to Finalize. 

59 minutes ago, Lars Fosdal said:

That feels almost like you're advocating the use of FreeAndNil 😄

That doesn't help if you have multiple variables that refer to the same instance which I guess is a more likely scenario for double free.

17 hours ago, gioma said:

The first character of the data tells me what type of data I have to work with.

For this reason I have to separate the header from the rest of the message.

This sounds completely broken. What if the file starts with the sentinel value that indicates that you have a utf8 payload.

Why aren't you passing a separate header, and then the payload? And why are you passing utf16 at all. Isn't that just expensive. And if you must pass around utf16 please tell me that you are handling byte order correctly.

What's pretty astonishing is that the NSA thinks that Delphi is memory safe!  See White House urges developers to avoid C and C++, use 'memory-safe' programming languages | Tom's Hardware (tomshardware.com)

I guess the NSA don't know anything about Delphi.

obj := TObject.Create;
obj.Free;
obj.Free;

Take that, NSA!

1 hour ago, Kas Ob. said:

Lets agree to not agree on that, for me, just don't duck with the stack and the stack will not duck with you, is a moto.

Just let me know what you can do with C++ that you can't do with Delphi, in terms of safety 

5 minutes ago, Kas Ob. said:

Delphi is way more safer than C and C++

No it's not.

5 minutes ago, Kas Ob. said:

It is safer then C and C++ and you need to pay more for the extra work to make it comparable to Rust.

But for real most the switching to Rust is due the security not the memory safety per se.

Not really the point if a government agency will only accept work using tools that meet certain criterion. You can either follow the specification and have a chance of getting the work. Or argue about  the specification and be completely ignored. That's just reality.

12 minutes ago, Vandrovnik said:

Even native code may run slow, when compiler does not use registers efficiently, uses superfluous jumps etc.

Not according to Embarcadero. According to Embarcadero Delphi is blazing fast because it uses native code.

We all know that to be absolute marketing BS and in fact Delphi compilers produce shitty code that often runs very slowly. 

Yes, my original post was sarcasm.

18 minutes ago, Stefan Glienke said:

If it at least would produce binaries that are faster than what classic compiler for Windows produces ...

Delphi produces native code, and therefore is fast

1 minute ago, Brandon Staggs said:

Beg to differ. At the point you declare an instance of TRecA inside of TRecB, the compiler does not yet know how much memory a TrecA instance takes. 

 

type
  TRecA = record;
  TRecB = record
    FieldA: TRecA;
  end;
  TRecA = record
    FieldB: TRecB;
  end;

That's not my example. Nobody wants to do this with a value type because it's a non terminating recursion. Have a look at my example code to see what I'm actually talking about. 

1 hour ago, PeterBelow said:

Because classes are reference type and records are value types. A variable/field of a reference type will always have a a known size, sizeof(pointer). A value type does have the size defined by the type and that would be unknown at the point of the foreward declaration. A one-pass compiler cannot handle that.

None of that applies to my example above. 

3 minutes ago, dummzeuch said:

As I originally said: It depends on the use case.

 

My programs usually have only the main thread for the UI and possibly one or (very rarely more) worker threads that are independent of each other (no threadpool). In that case it does not matter whether the other threads continue to run or not.

An exception won't work because I only use this method when I don't want to run the executable inside the debugger in the first place, so there won't be a dubugger to catch that exception.

I don't really follow this. If you have to modify your code to add the message dialog, before you start debugging, then I'm not quite sure why you can't run with a debugger attached. If you are happy to attach the debugger later, why can't you attach it at the start?

3 hours ago, Cristian Peța said:

It's not a compiler problem, but record variables are not class variables and when you declare a record variable it is allocated automatically.

You enter into a infinite loop of circular allocation.

type
  TRecA = record;
  TRecB = record
    FieldA: TRecA;
  end;
  TRecA = record
    FieldB: TRecB;
  end;
  
var
  a: TRecA; //infinite circular allocation of memory

 

This isn't really a great example. The sort of thing that I want to do with records, but cannot, is this:

type
  A = record;
  B = record;
  
  A = record
    function foo: B;
  end;
  
  B = record
    function bar: A;
  end;

I can get round this using helpers right now, but I don't understand why I can't do this directly as above.

2 hours ago, dummzeuch said:

As for David Heffernan's  comment: I'm talking about debugging, not production code. I thought that was clear from the context.

If you are debugging then throwing an exception is the way to do it. Then the debugger freezes all threads. You surely don't want the other threads to continue running at this point.

24 minutes ago, dummzeuch said:

That depends on the use case. If you want to show the error in order to then connect the debugger to the running executable, that's a good way to do it.

Hardly, because you've now ruined your production program. 

Reporting error dialogs from thread pool threads sounds terrible. Stop doing it at all and then you don't need to think that one message box function is better than any other. 

11 minutes ago, mitch.terpak said:

But the odds for it going wrong are very low

hahahaha

Step 1 to solving the problem is to understabd why you are compiling delphi rtl libraries