Geometry Boost List: Re: [geometry] type based tag dispatching for VTK output

Subject: Re: [geometry] type based tag dispatching for VTK output
From: Barend Gehrels (barend_at_[hidden])
Date: 2013-06-06 18:20:47

Hi Tomislav,

On 6-6-2013 17:15, Tomislav Maric wrote:
> Some notes and questions:
>
> #1 )
> Structures with static apply() methods implement the algorithms
> (strategies) for writing different geometries. Why is there a "detail"
> namespace at all, I mean, why do the strategies in the namespace
> "dispatch::" inherit from "detail::"?

It is not absolutely necessary. However, often code is shared between 
implementations for different geometry types, sometimes with slight 
variations (usual solved with templates).

If code is shared, it has of course to be somewhere else, in a central 
place, and that we choose namespace detail for that. Then it can be 
called (from apply in dispatch), which is sometimes done (e.g. if 
method-arguments are different) or just inherited.

> #2 )
> Why is the output done using the format manipulators with stream
> operators as friend functions? So that new stream operators don' t have
> to be registered for each geometry?

It is convenient to have them as manipulators, and the way it is now 
uses the same tag dispatching mechanism. Does that answer your question? 
I actually don't understand the "registered" part, the manipulator is 
not registering, it just giving functionality as:
std::cout << boost::geometry::wkt(my_geometry) << std::endl;

If it was just streaming (without manipulators), we could not supply 
various formats. We started with that (see "stream.hpp") but including 
that will often give compiler problems, anything not recognized 
otherwise will be tried to be matched in our tag-dispatching, which will 
fail...

> I've pushed VTK output with type based tag dispatching (I did the best I
> could at this point) using tags of boost.geometry up on
> "git_at_[hidden]/tmaric:boost-geometry-3d", so any input you can spare
> is very much appreciated.

Great but the address is wrong...

>
> Btw, we pushed the article on the geometrical two-phase flow simulation
> method (Volume of Fluid - VoF) to arXiv, you can get it there, if you
> want to see nice pictures and what I plan to use the boost.geometry 3D
> stuff for (see pages 10-12 for geometrical operations, and the result
> section for the geometry of the interface between fluids):
>
> http://arxiv.org/abs/1305.3417

Thanks for this, interesting (this one is right)

Regards, Barend