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