David Heffernan

40 minutes ago, Vincent Parrett said:

More on my issue, removing the record constraint does allow it compile, but removes some compile time type safety  

Will it compile if you restore the constraint but specify the generic type explicitly instead of relying of type inference? 

24 minutes ago, Kas Ob. said:

In C/C++ it way easier to convert a simple bufferflow into security hole, let you take over the system in full if not only the application, parameters passed in registers and memory allocated buffer along with the way stack in Delphi preserve itself with the locals, makes it way harder to run code passed by a parameter, unlike C and many other languages there is many ways to do it, and it is easier and and even when you are expert programmer, the candidate code to be abused code can easily escape your eyes and mind, the stack is the cause in 90% of those security holes you see in an application/OS written in C/C++. while the stack is sacred and better protected against simple and complex abuse in Delphi, i am not saying it is impossible to do an abuse, but it is near impossible to predict the abuse outcome, mostly it will end up in AV at random address, defusing the greater lost by running hand crafted malicious code.

This is just not true.

1 hour ago, Kas Ob. said:

See, pascal/Delphi is more secure than C++ and C#, less than Rust

Security is not a property of the language. It's a property of the code. And the code is written by programmers. They determine how secure a piece of code is, not the choice of language.

1 hour ago, Kas Ob. said:

it is secure for many reason but mostly due the declaration of variables before using them when entering procedure

Hard to see how that brings security. 

21 minutes ago, Incus J said:

does Delphi have a repair option?

Yes. 

28 minutes ago, Mike Torrettinni said:

No, not using any of it, yet. Planning to do some profiling and benchmarking on real data and will see if there are any bottlenecks in this area.

If you don't have a performance bottleneck, make sure that you use a version of the code that is easy to read and maintain.

1 hour ago, Mike Torrettinni said:

Interesting stuff: asm, registries, aligning... it's like a black-box to me. Reading how little insignificant changes (order of functions calls) affect the performance, is kind of scary.

 

But it shows how real performance optimization is based on case by case. It's hard (or impossible) to make 1 super performant algorithm for all cases. Just from this thread we can see the differences on optimization for short vs long strings, or like @aehimself pointed out if we need to consider nested brackets, escaped chars, quoted chars...

 

Here I am thinking if increasing char pointer is faster than using integer iterator, while you guys are discussing condition branching and using stack and full set of registries 🙂

Do you have a performance bottleneck with this code?

14 hours ago, River_Forest said:

Is there an easy way to add scrollbars to the main window of my project? (I hope this is the right place to post this question. Also, as a user of the Community Edition, it appears that I don't have access to "Help," so I can't find the answer there.) I thought something might be listed in "Properties," but I'm not seeing it there.

You can get help in the community version I believe. But in any case it's all online. 

3 hours ago, Mike Torrettinni said:

I like all the buzz being created around Delphi.

There is no buzz. Where are all the new developers?

17 minutes ago, Anders Melander said:

if the job can be split into separate, largely independent, tasks. I think that applies here.

I'm less convinced that is so.

40 minutes ago, Sherlock said:

I didn't read the book, but I'm guessing that only applies when you add those programmers to the same problem. Luckily Delphi has a ton of problems, that could each feed a programmer for at least a month

The problem with that is the the problems tend to interact with each other.

50 minutes ago, Anders Melander said:

Sure, but how is that relevant?

Are you saying that they have enough resources or that more resources will lead to more problems?

I'm sure that they have plenty of problems besides resources but surely their ability to solve them isn't improved by this shortage?

The point of the book is that adding programmers won't necessarily result in a better output.

1 hour ago, Günther Schoch said:

I am sure that Marco and the team is clever enough to solve a lot more problems and enhance the product if they get more money

It's far from that simple. I take it that everybody has read this:

9 hours ago, Mahdi Safsafi said:

Not always a bad code ! sometime you need to make a lock/release. So you must call the inherited in between and finally free the Lock object. Sometime you need to perform a notification, ... Just take a look at the RTL/VCL, there're many destructor that call inherited in between.

9 hours ago, Mahdi Safsafi said:

I didnt say its a good practice. All what I said there are some situations where its implemented. 

I can't reconcile these two statements. 

9 minutes ago, Mahdi Safsafi said:

Just take a look at the RTL/VCL

That something may be done in the RTL/VCL doesn't mean it is good practise.

4 hours ago, Kas Ob. said:

might help in recovering from exception in the destructor

Nothing can save you at this point.

OK, Scaled = False does change things.

Destructors must not raise exceptions. My personal view is that if they do then the best course of action is to terminate the process.

If you remove PixelsPerInch from the DFM then you'll find that your form layouts break different devs modify forms if their machines use different font scaling (i.e. DPI) settings.

In my workplace we handle this by requiring all modifications of forms to be made using a common font scaling setting.  

8 hours ago, PeterPanettone said:

However, your employer has to pay for the time you need to write overloaded code. (Though I assume you're a fast writer).

In the OP you also write an implementation for each different type. So where is the saving? 

53 minutes ago, PeterPanettone said:

Why make double work? The employer would like it if you need only half the time.

It's not double the work. 

1 minute ago, dummzeuch said:

Yes

I would absolutely not want syntax like that. If that's the way you want to go you can do it today with generics.

In an ideal world I'd like to see the generality offered by C++ templates though. That would allow algorithmic programming that is just too painful with generics. 

3 hours ago, dummzeuch said:

Not necessarily. The compiler could generate a set of overloaded procedures for this.

You mean with the code from OP? 

This seems worse than method overloading to me. There you have compile time branching. Here you have to perform runtime type checking.

1 hour ago, Leif Uneus said:

Is it not enough to declare DefaultCW8087 et al. as threadvar?

I don't think so. You want to be able to define a default FPCR for new threads, so just making those vars threadvars doesn't achieve that.

But in any case, why have threadvars for something that is already part of the thread context? That makes no sense to me.

2 hours ago, Arnaud Bouchez said:

Fair enough.

😞

 

But FPC doesn't suffer from this race condition AFAIK:

    procedure Set8087CW(cw:word);
      begin
         default8087cw:=cw;
         asm
           fnclex
           fldcw cw
         end;
      end;

 

That's a different race though. At least when you call Set8087CW then you know what happens in your thread. But you can still end up modifying things in other threads I guess.