Subject: [ggl] namespaces, models and algorithms (was: namespaces and ADL)
From: Barend Gehrels (barend.gehrels)
Date: 2010-12-16 05:49:40
Hi Krzysztof,
Thanks for your comment.
> I actually think Hartmut has a point. boost::geometry::traits does not
> suggest it's an implementation detail, and I'd bet users may want
> to use
> them. I'd move all details down in to boost::geometry::detail::,
> namely boost::geometry::detail::traits,
> boost::geometry::detail::dispatch
>
>
> The namespace geometry::traits does look pretty public to me. Isn't it
> there for the user to specialize things?
Sure, it is traits is also public indeed.
Maybe I should have distinguished between:
- library users using already adapted geometries (only using
boost::geometry:: and boost::geometry::model:: (and cs::) )
- library users adapting their own geometries (also using
boost::geometry::traits)
> I think traits should not go into details, unless I wasn't suppose to
> specialize these traits, and should have achieved my goal some other
> way...
I do strongly agree that traits should not go into details.
> namespace boost { namespace geometry { namespace traits {
> /[... snapped most of it ...]/
> template < class T >
> struct access< geo<T>, 1 >
> {
> static inline T get( geo<T> const& p )
> {
> return p.lat();
> }
>
> static inline void set( geo<T>& p, T value )
> {
> p.set_lat(value);
> }
> };
>
> }}} // boost::geometry::traits
Well done, nice to see.
Regards, Barend
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/ggl/attachments/20101216/468b8556/attachment.html