Good evening gentlefolks,
On 19/03/14 15:42, factor-talk-requ...@lists.sourceforge.net wrote: > Message: 1 > Date: Tue, 18 Mar 2014 16:44:07 +0100 > From: Bj?rn Lindqvist <bjou...@gmail.com> > Subject: Re: [Factor-talk] manual memory management and STRUCT: > To: factor-talk@lists.sourceforge.net > Message-ID: > <calg+76ern5tg6-3ug4u7mhgu5obpkkdsce4ub4fby81wmrp...@mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > 2014-03-18 14:12 GMT+01:00 Jon Harper <jon.harpe...@gmail.com>: >> In this case, it's more complicated then a single with-destructor scope, >> because I use the destructors to call libyaml's destroy function on the >> struct, so that the same memory can be reused between the calls to libyaml >> for this struct. So I really need to destroy it right away before the next >> call the libyaml, hence the nested with-destructors. >> >> I could allocate new memory for those structs every time and destroy them >> only at the end of the parsing. But in most cases, only one struct is needed >> at a given time, so I thought reusing them was a good thing. >> Jon > > I think you're falling for the premature optimization trap > here. Allocating memory is incredibly cheap so unless your code is > memory constrained there is no need to save on it. It's always better to > start with the simplest implementation you can get away with and then > if you run into performance problems start to optimize it. > > > -- > mvh/best regards Bj?rn Lindqvist > > More subtle problem is creating a situation where the intent can get lost. The intent is to use a single structure for the entire process. If at a later stage, you need two or more, this may have ramifications to the code you have already written. If you make the code agnostic to the number of structs, you can at alter stage determine what your real requirements are. As mentioned above, this can be a premature optimisation trap or it can be a case of being too clever when simpler code would be better. The latter process makes future changes including optimisations harder to do. I am not talking about algorithms here but interactions between different parts of the code that can be lost (including things like setting state in one place and using that state in another without there being a clear logical sequence). The KISS principle and OCCAM's RAZOR are both good principles to follow in situations like this. At any rate, my 5 cents worth (smaller currency unit we have in practise) Bruce Rennie ------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech _______________________________________________ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
