Geometry Boost List: Re: [geometry] extensions

Subject: Re: [geometry] extensions
From: Barend Gehrels (barend_at_[hidden])
Date: 2012-03-05 10:03:47

Hi Kris,

On 4-3-2012 21:39, Krzysztof Czainski wrote:
>
>
>     Maybe we can put the first version (with specific parameters) into
>     detail, and keep only the most simple version for users.
>
>
> Or in that case we could get rid of the first version all together ;-)

That makes sense, done.

>
>     The make_shared_projection will also be useful for some, but I
>     find it a bit of an overkill - make_shared was defined to avoid
>     "new" calls (if I understand correctly) but here is not really a
>     call to new. So
>     shared_ptr<ProjA> ptr;
>     ptr.reset(new_projection...)
>
>
>     would perfectly do the job.
>
>     So I'm not sure if it is that useful for the library itself. Any
>     opinions here?
>
> A call
> shared_ptr<ProjA> ptr( new_projection... )
> or
> shared_ptr<ProjA> ptr;
> ptr.reset( new_projection...)
> causes two separate memory allocations: one for the new projection, 
> and one for the reference count. The function make_shared<T> stores T 
> together with the reference count in the same memory segment, avoiding 
> one allocation - that's all. I'm used to using make_shared by default, 
> but perhaps make_shared is actually a minor optimization, and I 
> understand it may not be worth the complication in this case ;-)

Relative to the rest (the job of projecting itself) the optimization is 
indeed minimal. If we would provide this we would also add it to 
"create_new" of the factory, and to all other pointer-things we make 
(which are as minimal as possible, everything is pointer-less, for the 
projection it is an exception to get the initialization-by-string running).

So it is applied as it is now (I moved the geographic_point_type to a 
separate headerfile projection_point_type and changed it a bit but it 
still works as you intended). Sample p05_example is using the idea.

Regards, Barend