RE: [DUG]: Delete a variable from a Dynamic Array

[Paul Heinz]

Title: Message

Kyley wrote: You make a good point in your argument. but in this case my comment was directly related to the issue. ie 20 items in a list. Everything you say is quite correct. every problem must be accessed for the correct answer. And in the case of this type of forum no one really has time to sit down and weigh up all the different points about a topic and write them down in an email (hence patronizing, or inaccurate etc etc) You would have to be permanently unemployed to have the time to write such lengthy comments and point out all the options of an argument to try and not look stupid or too biased, which would remove the answers value to some degree. And lets face it, all of this can be found in a website or book if you look around. True. >When you're dealing with databases in the gigabytes or entities in the hundreds of thousands, bypassing unnecessary abstraction layers >can make a big difference.   I hope you aren't loading all of them into memory at the same time :) Well, I wrote the database engine, so when it's doing index and table rebuilds (uncommon but important to optimise for) and data-mining analysis runs - large chunks of that database have to pass through memory and when memory is functioning like a secondary cache for disk, the cache footprint of each element becomes pretty critical to avoid any thrashing. >>All forms of abstraction have a performance cost. The job of a good software engineer is to know when to break them.   without trying to sound bad again :) breaking rules to gain performace cost is only going to hurt in the long run maintenance. computers double power every year continuously removing performance issues from the hardware. this only leaves performance and maintenance issues with the code (which probably has a far longer life) My own opinion is to go for code which will last and maintain longer and be simple to modify at need. (however you achieve this) the speed and management of objects against records just gets smaller everyday and you can't beat encapsulation if nothing else in an object.   I'm sure this will stir a few comments so fire away :)  Whilst it's true that computer double in power every 18 months, the customers are somehow on to this (OK - will the person who told them stand up :-) and their expectations of what computers can or should do seems to rise to more than make up for it :-(   As for maintenance (consistent abstract interfaces) vs performance (optimised actual code) - this is a hoary old chestnut in computer science and has generated more heat than light on many an occasion - so we're in good company chewing over it here :-)   A solution of sorts has emerged over the last 10 years - Generic programming frameworks (aka Templates) like the C++ STL. Pretty mind-bending stuff but an awesome concept when you get your head around it.   Nice abstract interface to methods, containers, and algorithms - pure optimised code out with any unnecessary abstraction removed.   Unfortunately, Delphi doesn't have integrated support for Generics or Templates (yet) - I wrote a stand-alone template processor and there are others who have played tricks with {$INCLUDE}. These can be quite useful for producing optimised containers as needed but it's nothing like directly having them in the language itself.   Delphi might 'inherit' (no pun intended :-) Generics from the Delphi for .NET initiative. Once C# has Generics support (it's only a draft proposal and reference implementation at this point), Borland's .NET tools will need to to offer support for them (at least in their C# compiler) and let's all hope it flows from their to Delphi for .NET and then from there to Delphi.   TTFN,   Paul.