{"id":1245,"date":"2012-10-01T14:26:34","date_gmt":"2012-10-01T02:26:34","guid":{"rendered":"https:\/\/www.deltics.co.nz\/blog\/?p=1245"},"modified":"2012-10-01T14:33:35","modified_gmt":"2012-10-01T02:33:35","slug":"lazy-or-efficient","status":"publish","type":"post","link":"https:\/\/www.deltics.co.nz\/blog\/posts\/1245\/","title":{"rendered":"Lazy or Efficient ?"},"content":{"rendered":"[Estimated Reading Time: <\/span> 3<\/span> minutes]<\/span><\/span>

In his most recent post<\/a>, 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.<\/p>\n

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<\/strong> class itself, as the two things could easily be conflated when reading Chris’ post and the QC issue it refers to.<\/p>\n

<\/p>\n

The fact that TList<\/strong> 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<\/strong> class.<\/p>\n

At that point it became a contract – for good or bad.<\/p>\n

It was certainly never a compiler<\/em> implementation detail.<\/p>\n

This was what crystallised for me that Chris was talking about the overload selection made by the compiler<\/em>, 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.<\/p>\n

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.<\/p>\n

Indeed, I have taken advantage of this myself in the past to implement a super-fast mechanism for “cloning” TList<\/strong> instances by directly allocating the required memory in the destination list (setting the Count<\/strong> property) and then directly copying all<\/strong> list items in a single CopyMemory<\/strong> operation from one list to the other gratefully using their exposed List<\/strong> pointers.<\/p>\n

Even without going to the extra lengths of trying to suppressing the zeroing of the new items triggered by setting Count<\/strong> directly – which would have necessitated some real<\/em> dirty tricks – this is vastly<\/strong> more efficient than enumerating the items in one list and adding them to the other.<\/p>\n

But I digress…<\/p>\n

To draw a comparison from the physical world … ask yourself which is the more lazy:<\/p>\n