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

Subject: Re: [geometry] type based tag dispatching for VTK output
From: Tomislav Maric (tomislav.maric_at_[hidden])
Date: 2013-06-07 04:05:17

Hi Barend,

On 06/07/2013 12:20 AM, Barend Gehrels wrote:
> 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.
>
Clear, thank you.
>
>> #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;
>

Usually I would define a generic "operator<<" for a Geometry template
parameter, but without tag dispatching, I would need to specialize it (I
used the word "register" wrong probably) for every geometry explicitly,
which creates a bunch of "operator<<" all over the code. In OpenFOAM
(the code I'm working with), the "OStream<<" is not generic, you need to
overload it for each type. Tag dispatching + manipulators keeps the io
in one place (per format), I like that much better.

> 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...
>
>

Thank you, I think I get it now.

>> 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...

Ah, sorry about that, here is the link: 
"git_at_[hidden]:tmaric/boost-geometry-3d", the new test application
is called "write-test-type-tags", I kept the old stuff in the repo since
I am still learning.

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

Btw, I got an official O.K. to try and optimize that code using
boost.geometry, which is great since I'll have more time to learn. I'll
start working on the multi-polygon concept of polyhedron, and see where
it leads.

Best regards,
Tomislav

>
> Regards, Barend
>
> _______________________________________________
> Geometry mailing list
> Geometry_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/geometry