Because of there are enough people that are using PolyVox with different languages - probably via SWIG - and it would make my D code cleaner (i'm so selfish )... I'm bringing this topic on.

How about:
a) modifying current API to be less templated
b) making additional C-API for polyvox?

It would stop all this problems with interfacing, make library usable from like 20 languages, and stop my eyes bleed because of not seeing things like CubicSurfaceExtractorWithNormalsSimpleVolumeMaterialDensityPair44

EDIT: changed to another real-life unwinded template

D (deal with it?)

http://d-programming-language.org/

Regardless of whether you're using D or not ( ), David and I have talked before about the best way to provide language bindings to PolyVox and indeed creating a C-style wrapper around all the functionality seemed to be one of the simplest ways. Unfortunately it hasn't happened yet since it could be a lot of work and maintenance as it is very easy to let it stop working when API changes are made to PolyVox.

There is little chance that PolyVox will be made less templated (at least in the areas you're talking about) since templates are essentially required to be able to give the kind of flexibility we have (at least while keeping the code sane and maintainable). To provide that same flexibility (or at least the same range of options) in any wrapper or C-interface necessarily requires those long, unwrapped class names you mentioned. Each user of the wrapper probably only uses one volume type so you can always typedef it away at your end.

In the world of wrapping SWIG is pretty much the only one-to-many wrapper generator out there and unfortunately it's not looking like the healthiest project out there and it still struggles with complex templates. I'm still waiting for someone to come along and write a wrapper generator with a proper C++ parser like clang but I'm not hearing much news on this front.

Providing usable wrappers is definitely something we want to provide but since neither David nor I are currently using them we appreciate use-cases and feature requests like this.

_________________
Matt Williams
Linux/CMake guy

I agree with the general sentiment of your post, in that PolyVox is a little complex to use. Templates can be confusing and ugly and they do cause issues for SWIG. However, they are also very powerful and bring a lot of flexibity.



Not really, I think use of templates is generally very beneficial. Actually, I think the use of template template parameters in the surface extractors (where you have to pass a volume type and a voxel type) might have gone too far, and I will look at allowing the voxel type to be retrieved from the volume instead. But apart from that I'm happy with them.



Would a simplified C++ wrapper be sufficient instead? A simplified C++ wrapper is easier to create because it's basically just some typedefs and simple wrappers for the most important classes.

But as milliams says, the long class names result from us trying to expose everything, and needing a unique name for each of the different classes. I think a simpified wrapper will only be useful if it exposes a reduced feature set. Perhaps we choose one volume type (SimpleVolume) and one voxel type (MaterialDensityPair88) and just expose this as a class called 'Volume'. Then simple 'extractSmoothSurface' and 'extractCubicSurface' functions to avoid messing around with the surface extractor classes.

I am quite in favour of this, but I don't want to write the SWIG part. If someone else can volenteer then great, but even without that it would be useful for less experienced C++ programmers. I will add it to the todo list...

Ok, I was feeling inspired so I tried making a simplified C++ wrapper. In principle it does work, and it makes the example code simpler and more readable. So I like this idea so far.

But I don't yet know what to do about the seperation of code. I could just add the new simplified classes to the PolyVox namespace, but then the new Volume class is in the same library as SimpleVolume, LargeVolume etc whereas it's actually quite different. And extractCubicSurface coexists with the CubicSurfaceExtractor, which is confusing.

I currently have three ideas:

1) Make a new PolyVoxBasic namespace for the simplified interface. Does this mean the existing classes should be moved to PolyVoxAdvanced, or just stay in PolyVox? The Region class will be needed by both simplified and normal code so where should this go? Should a user of PolyVoxBasic also have to include the normal/advanced namespace to access Region?

2) Maybe it should be a seperate library. But this doesn't actually solve the previous question, and is making the user build another library counter to the aim of making it simpler?

3) Perhaps some header/#define magic? Like you have to #define POLYVOX_BASIC or POLYVOX_ADVANCED and this controls what gets exposed. Both would be built into the library, and perhaps you can define both if you want. Region would be available if either was defined. Or maybe POLYVOX_BASIC is always defined, and POLYVOX_ADVANCED is required for more advanced functionality.

Ok, I'm really just brain storming now so sorry for rambling on...

I like templates too, but because they're absolutely not portable between languages they are pain in the ass when it's the only way to use functionality.


For me? sure! For most of people here too, so it might be the way.


Actually, I've been thinking about another way. Abandon the need of templates by making additional untyped methods/functions + some c-style callbacks. It won't look good, nor it won't be easy to use, but it would let to be flexible, and portable in the same time.

About method you proposed, I would have to use current API anyway, but for some people it might help.


I don't really understand SWIG usage, maybe because i had no time to read complete manual. I just made it work for me, and i'm trying to keep away from it, so i cannot offer my help here


Definitely alternative ways shouldn't be mixed, so PolyVoxBasic would better for me. IMO, current namespace shouldn't be touched. I see nothing wrong in having PolyVox and PolyVoxBasic, which keeps using PolyVox.

And i think this solution would be best of three mentioned because of 2) just no, lol 3) i think it would add some mess.

I must say, I don't kow exactly how to do this. I know you can use void* and c-functions to emulate generic behaviour but I'd have to do some research here, and I don't want to take that on at the moment. But we could add this in the future if anyone wants to look into it.

I guess the advantage would be that you could then interface with other languages without going through SWIG? Actually I quite like SWIG - it's a powerful tool but I just don't know much about it.



Can you elaborate on why? If it's the choice of volume or voxel types then I imagine this could be configured when compiling PolyVox. You would only get one type of volume and voxel type exposed though the simple interface, but at compile time you could choose which type it would be.



I've changed my mind... I don't think it's so bad if they sit side by side. They don't interfere with each other and it's just two ways of doing the same thing. So at least for now I'll just stick the typedefs and wrappers in the same namespace and in SimpleInterface.h. Let's see how it works out...

I got mixed feelings but great, it's good enough, thanks.

Ok, I've added SimpleInterface.h/cpp to Git. They just contain a couple of typedefs and wrapper functions to simplify C++ code and make access by SWIG easier. I've updated the BasicExample to use this interface and it does appear more friendly. This SimpleInterface can be expanded in the future, but for anything complex users will be expected to use the real PolyVox API.

I'm not adding a C API at this point, basically because I don't want to take on the work on writing and maintaining it. There's just other priorities. Maybe in the future though, if someone volunteers to do this.