Agreed. A class should represent an interface rather than thinking in terms of their data members (which clients should not need to even know about).

In the vector 3D case though, the representation IS the interface.

You would use accessors for simple and obvious access functions if you think there may be a need for them later on though. (I've seen arguments saying it is easier to do a text search for an accessor rather than a member, however I dismiss that since you can comment out the member and the compile errors tell you where the member is used).

That's handled by the floating point specification, and adding checks is going to affect performance.

You could put debug only checks in, then you would use an accessor and inline it. I wouldn't do that for a vector class though. I have used it for things like verifying arguments are within expected ranges e.g. for inverse trig functions.

Again, not to be difficult here since I agree with your opinion on the subject completely, but if you want to look at it formally wasn't the concept of class invariants introduced to avoid cases where you can get unexpected or undefined behaviour? I'd assume that some floating point specifications would show undefined behaviour when doing operations on NaN values which would be an issue if you want to be really strict about your OO design.

And yes, checks would affect performance, but there will always be a difference between writing code which can be proven to be correct and writing highly performant code.

Floating point specs are perfectly well defined for operations involving NaNs and infinities. It wouldn't be much of a specification if they weren't! (Basically once you get to NaN or infinity values there is no going back to "real numbers").

For non-conforming implementations you need to check the compiler documentation (non conforming stuff usually only affects things like rounding modes and precision rather than behaviour of NaN and infinities though). If conformance is required you can usually enable it (and take a performance hit).

there will always be a difference between writing code which can be proven to be correct and writing highly performant code

I disagree. Highly performant code can and should be correct. Always.

there will always be a difference between writing code which can be proven to be correct and writing highly performant code

I disagree. Highly performant code can and should be correct. Always.

There is a very big difference between "The code should be correct" and "The code is proven to be correct".

In the second case it is impossible for a bug to exist in the code, in the first case testing hasn't discovered any bugs (yet).

There is a very big difference between "The code should be correct" and "The code is proven to be correct".

In the second case it is impossible for a bug to exist in the code, in the first case testing hasn't discovered any bugs (yet).

I don't see why performance has any bearings on it. If you can write crappy-debug code that is proven to be correct, and you know how to optimize, then you can write highly efficient and optimized code that is proven to be correct.

There is a very big difference between "The code should be correct" and "The code is proven to be correct".

In the second case it is impossible for a bug to exist in the code, in the first case testing hasn't discovered any bugs (yet).

I don't see why performance has any bearings on it. If you can write crappy-debug code that is proven to be correct, and you know how to optimize, then you can write highly efficient and optimized code that is proven to be correct.

Debugged code is not code which has been proven to be correct.

We're talking about a formal proof here, and formally proving that an algorithm or procedure is correct (ie. it generates a correct output for each input) is not a trivial task. You can debug the crap out of a piece of code, but if you haven't shown that this piece of code provides a correct output for every possible input then you haven't proven this code to be correct.

These kinds of proofs are very important when doing design by contract for example. In critical applications it's an absolute must that you have a guarantee that your code will behave correctly in any situation.

I understand, and I agree that it is not a trivial task, especially if you need high performance.

It doesn't mean you can't write high performance code that is always correct.

I understand, and I agree that it is not a trivial task, especially if you need high performance.

It doesn't mean you can't write high performance code that is always correct.

I was writing up a huge wall of text, but decided it wasn't worth it in the end.

Let me explain what I meant with my original statement:

The point I'm trying to make is that high performance is often paired together with designing with the hardware in mind, not the programmers.

You'll often be skipping over some checks (ie. invariant enforcements) or exposing some internal state to gain a performance boost while making the assumption that anyone using the code will be "smart" enough not to provide nonsense input values. This in turn will make it impossible to prove your code to be correct since you can't guarantee you'll conform to your class invariant at all times.

OK, I thought you were suggesting it's an impossible task.

You'll often be skipping over some checks (ie. invariant enforcements) or exposing some internal state to gain a performance boost

Yep, I agree.