On Tue, Jan 27, 2015 at 12:17:22PM -0800, Alan Irwin wrote: > For reference the question was > > > Would you be willing to give your official permission to adapt your > > new approach for the needs of ephcom under the LGPL? > > On 2015-01-27 09:12-0500 Jim Dishaw wrote: > > > You have my permission though it probably is not really needed > because the algorithm is generic and you are going to be rewriting the > code. > > I agree it is a debatable point whether to ask permission in this > case, but I always like to be clear about such issues so thanks for > your permission. > > > If you make a generic allocator, then you will need to tweak the > pointer arithmetic to get the layout correct. I rely on the (float > **) and (float *) types to get the arithmetic correct. A generic > allocator would need a (UCHAR *) or something similar and if the base > type was not a byte, you need to adjust accordingly. > > Yes. > > I also think alignment issues must be considered. > >From the malloc man page: > > "The malloc() and calloc() functions return a pointer to the allocated > memory that is suitably aligned for any kind of variable." > > So that part is OK by definition with regard to alignment, i.e., > whatever is placed first in the memory area is guaranteed to > be aligned properly regardless of the size of the object. > > However, your code mallocs the combination of two different kinds of > objects so to guarantee correct alignment for the longer objects, > those have to be placed first in the memory area. So, for example, on > a 32-bit machine pointers typically (but not always) have a size of 4 > bytes which is obviously shorter than the 8 bytes used for doubles. So > your code would have had misalignment issues for that case (unless the > relevant dimension happened to be even), and to avoid such issues your > original code and my generalization of it need a test on the size of > objects to decide which to place first in the memory area. > > When I get these issues sorted out, I will follow up here with a reference > to the updated ephcom code in case someone here wants to use that > same approach for the PLplot 2D arrays.
The sane way round this is make two allocations, one for the array of pointers and one for all the data. This is still a lot more efficient than the current multiple allocation approach, but still always guarantees correct alignment etc. Andrew ------------------------------------------------------------------------------ Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
