I think, and this is more of an intuitive rather than an informed guess, that the current practical languages are still too low level and that may be one of big reasons why software development is so complex. And our software doesn’t even get faster or better, it just fits whatever performance:annoyance ratio is acceptable at the end of the day. Instead we are burying ourselves and those who will come later in what is essentially a deep math. It’s clear that right now big software has to be formal to live longer and stay healthy, but for me it feels like we’re losing something important on this way.Ĭomputers ought to be our helpers which could understand our plans and implement them properly. This webpage © 2000-2015 by Bob Swart (aka Dr.Bob - All Rights Reserved.This list, together with already mainstream features, turns a programmer’s learning curve into an uncompromising cliff. Those of us who still rely on the "old" Real type can use the compatibility compiler option.
However, be sure to check usage of the "old" Real in your code (for example when used as file or record fields). This also means that we can now publish the "new" Real (i.e.
Now, with Delphi 4, the Real type has been changed to 8-bytes, resulting in an identical type as Double. However, being 6-bytes and an out-cast, the (old) Real type was never recommened for use (in fact, in previous versions of Delphi you could not even publish Real type properties, and should always have used the Single (4-bytes), Double (8-bytes) or Extended (10-bytes) floating point types instead. The original 6-bytes (or 48-bits) Real type was a left-over from the Turbo Pascal times, but had to be supported by Delphi (as 6-bytes floating point type) for compatibility reasons - at least that's what I think the reason was.
Well, that's a topic for my Delphi 32-bits Efficiency session at BorCon, but for now it's enough to know that it's at least twice as slow.Ĭombining all this information with my previous Delphi integer types chart (from my " Porting Delphi 1.x code to 32-bits" paper, which needs to be updated for Delphi 4 right away), results in the following table: Since an Int64 is not a native machine integer, it has to be "simulated" by Delphi 4.Īnd that means it takes more time than simply working with a 32-bits integer. Of course, everything comes with a price. a signed 32-bits integer constant), then the compiler will automatically reserve an Int64 to hold this value. ShowMessage( 'Int64: '+IntToStr(MinInt64)+'.'+IntToStr(MaxInt64))Īnd even with the above dialog, it's hard to grasp how big these numbers are.Īnd once you define an integer constant that's too big to fit in an integer (i.e. Now that the "signed" Words are finally up-to-par with the unsigned integer types, Delphi 4 immediately introduces a new 64-bits integer type, called Int64, with a whopping range of -2^63.2^63 - 1 (I don't even know how much this is without executing the following program): 4,294,967,295).Īs a direct consequence, the native unsigned 32-bit machine Word type called Cardinal, previously with a (31-bits!) range of 0.2G-1, now also has this 32-bits range of 0.4G-1 (finally, I might say). I've already published detailed papers on Default Parameters, Method Overloading and Dynamic Arrays.īut there are some enhancements to native ObjectPascal types as well, especially when it comes to the built-in integer types Int64, LongWord and (changes to) Cardinal.ĭelphi 4 introduces a new 32-bits unsigned integer type, called LongWord, with a range of 0.2^32-1 (i.e. Dr.Bob on Delphi Language Enhancements Delphi Clinicīorland Delphi 4 features a number of Object Pascal language enhancements, as usual.