[postgis-devel] getPoint2d_p

[Mark Cave-Ayland]

Paul Ramsey wrote:

> I'm looking at the simple distance calculating function, and I see this:

(lots cut)

> We're just reading, why the memcpy? Sure, it's pretty darn fast, hand
> optimized assembler by the gods of gcc and all that, but surely it
> would nicer to just get a pointer into a structure.
> 
> All this derives from having our point arrays stored in "uchar
> *serialized_pointlist" the primary advantage being ... ? Comments say
> that we don't have to worry about 2/3/4D. OK, I can see that. But...
> wouldn't an "double *pointlist" work even better? We could reference
> into it with accessors just as currently, but we wouldn't need the
> memcpy.

I'm fairly sure it was there to allow access to unaligned data (i.e. not 
on a word boundary).

> I'm still grasping at this stuff, deeper thoughts desperately wanted.
> 
> BTW, I'm doing a project that involves some simple computational
> geometry and implementing some extra primitives native to PostGIS, and
> building unit tests with cunit (I feel much more confident testing
> each little block of code along the way). Unfortunately I'm building
> against 1.3, which makes things well-nigh impossible. I think I might
> have to flip this project around and develop on 1.4 using liblwgeom,
> then back-port for the client, or I'll be spending all my time
> scabbing bits of liblwgeom into my framework instead of working on the
> actual code.
> 
> P.

Yup indeed. I've been a complete 1.4 convert for several months now, 
mainly because the debugging capability is so much superior. So I tend 
to do all the hard digging/tracing in trunk and then backpatch to 1.3 
when I'm done.


ATB,

Mark.

-- 
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063