Geometry Boost List: Re: [geometry] extensions

Subject: Re: [geometry] extensions
From: Krzysztof Czainski (1czajnik_at_[hidden])
Date: 2012-03-04 15:39:55

2012/3/4 Barend Gehrels <barend_at_[hidden]>

> On 9-2-2012 12:44, Krzysztof Czainski wrote:
>
>> Like promised, I present a proposition of functions new_projection() and
>> make_shared_projection(). They are useful, when:
>> - you have a small set of types of projections you'll use,
>> - you know the type of projection during it's creation, and later you
>> want to use it through an abstract base pointer,
>> - you want to avoid the overhead of factory: generating code for creating
>> a projection of every type you don't use, and selecting the type from a
>> string.
>>
>
> I think new_projection() is very useful. It wraps the call to the detail
> virtual forwarding class which is definitely necessary. Also the new
> typedefs are very useful, and make the new_projection (and other things)
> very convenient to use.
>
> 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 ;-)

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 ;-)

> I've not committed the changes yet - will do that tomorrow or so, at least
> the types and new_ version, and I created an example of it. That example
> conveniently makes conveniently use of the new typedefs.
>
> Thanks for your contributions!
>
> Barend
>

Cheers
Kris