In his most recent post, Chris Rolliston points out a gotcha resulting from a change in the VCL with XE3. The post itself is quite interesting and makes some valid and significant observations. However, in the follow up comments Chris makes the observation that the old code was lazy, relied on a compiler detail and should have been “properly” re-written, rather than replacing reliance on one compiler detail with another.
I think it is worth highlighting that Chris’ observations here are – I believe – directed at the use of untyped pointers and dynamic arrays, not the use of the pointer exposed by the TList class itself, as the two things could easily be conflated when reading Chris’ post and the QC issue it refers to.
The fact that TList is implemented as a pointer to an array of pointers ceased to be a private implementation detail the day that that internal pointer (strongly typed I might add) was exposed through the public interface of the TList class.
At that point it became a contract – for good or bad.
It was certainly never a compiler implementation detail.
This was what crystallised for me that Chris was talking about the overload selection made by the compiler, and thus identified the comparison of untyped pointers and dynamic arrays as the subject of the comment, rather than the use of the list pointer in the code per se.
Otherwise I think it goes without saying that writing code that takes advantage of a contracted interface in the most optimal fashion – especially (but not necessarily only) when runtime efficiency is required – imho is not “lazy”, it’s efficient.
Indeed, I have taken advantage of this myself in the past to implement a super-fast mechanism for “cloning” TList instances by directly allocating the required memory in the destination list (setting the Count property) and then directly copying all list items in a single CopyMemory operation from one list to the other gratefully using their exposed List pointers.
Even without going to the extra lengths of trying to suppressing the zeroing of the new items triggered by setting Count directly – which would have necessitated some real dirty tricks – this is vastly more efficient than enumerating the items in one list and adding them to the other.
But I digress…
To draw a comparison from the physical world … ask yourself which is the more lazy:
- Getting in your car and driving 3 km on public highways to get to a shop
- Using a footpath – less obvious to a habitual car driver and perhaps less well known generally – that takes you directly to the same shop after just a 300 m walk
Is it “lazy” to take the quicker, but physically more demanding, option of walking via the footpath ?
I would say it is more lazy to get in the car and drive the more obvious but less efficient route.
And if you use your car on the basis that the council might close the footpath and leave you stranded at the shop with no way to get home, then I would say you are not just trying to justify your own laziness but are paranoid to boot! 🙂
The key here is that the footpath is official, is on the map and does not involve hacking your way with a machette through thick bush obscuring the route across private property.
It may be poorly lit and make you nervous in the dark, but carrying a flashlight can help in that situation (comment your code!). 🙂
On the other hand ….
Adding overloads to an existing class with thousands if not millions of lines of existing, dependent code without – apparently – taking the time to consider the impact of those overloads on that existing code, that is not just lazy but downright inconsiderate!