David Heffernan

If FPC had given 9 that wouldn't have changed the conclusion

I never said anything about this specific case. I am referring to universal rules that can be applied, or in this case not because they don't exist. See the black and white cow argument.

That just tells you about this one piece of code and whichever compilers you happened to use. It doesn't prove a rule. If you look in a field and see that all the cows in that field are back and white, does that prove that all cows are black and white?

This code exhibits undefined behaviour. In an expression like a + b, a and b can be evaluated in either order. The language does not mandate that order. If you want to make your code well defined the. You need to evaluate the function on one statement, and then perform the addition in another. finalValue := ResultIsFive(index); Inc(finalValue, index);

No I don't think that is true.

AMD have their own tool I think. No idea how good it is.

This is all about the Unicode changes introduced 12 years ago in Delphi 2009. There are hundreds of posts about this. You aren't going to master this in minutes and with quick post here. You'll need to research this in depth. Start with Marco Cantù's Unicode whitepaper.

I'm using the latest vtune and didn't need to do anything with msdia140 and it all works perfectly.

No, it performs really well for me. Are you using the latest version? It loads quickly for me and does a good job of taking me to the parts of the code where the time is being spent.

It extremely hard to see past vtune

Oh for a library writer then yes, the calculations are different and there is much more justification for this

Because it clutters the code and you can find such bugs other ways which don't clutter the code.

I don't really see the value of this, if the input is contracted to be assigned. That makes it a programming error, your tests will AV and you will fix it. No need to clutter the code with if not Assigned tests.

The whole point of exceptions is that in a huge number of cases it is impossible to "deal with it" at the point where the error is raised. The code has been called by another function that excepts it to succeed. If it can fail, but return normally without an exception bubbling up, then you need to return information to the caller that the function has failed. And the caller may in turn be have its own caller that needs to know this. And we are right back to exception free code where errors are indicated by boolean or integer error code return values. Exceptions that bubble up the stack are only difficult to manage if you don't write your exception raising and handling code properly. For sure it is perfectly possible to write crappy exception code. But you are pointing the finger in the wrong place.

You described the correct construction pattern as a "problem" which is what confused me.

Don't you know that exceptions bubble up the call stack? If you try to handle them immediately then you've just got crappy error code type code. The entire point of exceptions is that you don't need to deal with them at the point where the error occurs.

No. The try finally here protects the lifetime management of the instantiated object, after the constructor has completed. An exception in the constructor will bubble up from here and never enter the try. This is a very very common misunderstanding.

No. Its pointless trying to handle exceptions in destructors. If that happens the process should terminate.

Again, can somebody explain what problem is caused by raising in a constructor. We all seem fine with TFileStream doing this, so all I can see is dogma.

I don't see the point of trying not to raise in a constructor as a design goal. Raise the exception at the point where you know it needs to be raised.

What do you think about TFileStream.Create raising an exception if the file can be opened in the requested mode for whatever reason? I cannot see the problem with this, or indeed any constructor raising. If you are going to admit exceptions in your program at all, you must be resilient to them. Why is it any different to get the exception raised in a constructor than anywhere else.

The advantage of moving that teardown call to the subject's destructor is that you don't need to test Assigned. If it raises an exception then you are still hosed.

In a destructor you do need to test Assigned on members if you call any method other than Free. That said, destructor must not raise exceptions. And its generally better to move the call to those teardown methods into the destructor of the class.

This is pertinent to some of the discussion here: https://stackoverflow.com/a/8550628/505088

I mean if you have a bunch of files that need to transformed once, then writing delphi code isn't the most efficient. You'd just use a scripting language to make the change and throw the code away. But if you have a Delphi product that needs to repeatedly perform this transformation then that's not going to be useful.