On 18/07/2014 2:11 AM, pfultz2 wrote:
If you can do *that* with Boost.Fusion then perhaps you can show us the code that does it, and we discuss costs and benefits. Sure. You just access the field by using the key.
I know, but that's not what I asked. I want the syntax to be points->x.
Here is a quick-and-dirty example here(I haven't compiled it yet, but it should communicate the idea):
https://gist.github.com/pfultz2/cfc447c7ccfa8ac2e76f
So then you should be able to write:
table<person> persons;
for(const person& p:persons.where(at_keyfields::age(persons) == 60)) { ... }
Another idea is to generate the member in with the key, perhaps something like this:
#define QUINCE_GEN_KEY(name, ...) \ struct name : __VA_ARGS__ \ { \ template<class T> \ struct lazy \ { \ T name; \ }; \ };
Then you can use the fusion keys to compose a class that inherits from each lazy member, so you could still support accessing it using the `->` operator. I don't show an example here.
When you say "you can use the fusion keys to compose a class ...", do you mean that the user writes each such class by hand, or can you write something that will make it automatic? If you are telling me that Boost.Fusion can replace QUINCE_MAP_CLASS etc., then your challenge is to make it automatic. I need to see your code for this, before I can assess whether a dependence on Boost.Fusion will buy me a nett reduction in quince code.
However, the first approach I think is sufficient.
I mean, if I were to take the approach of implementing QUINCE_MAP_CLASS and QUINCE_MAP_CLASS_WITH_BASES by (a) using Boost.Fusion to define some kind of tuple, and then (b) using some other means to turn that tuple into the class I need, then I expect it would all be done in one place, _viz._ inside the definition of quince's private macro QUINCE_DEFINE_CLASS_MAPPER_WITH_BASES. So I would be introducing a dependency on Boost.Fusion for the sake of changing one point in my code. You wouldn't generate your mapper class using the preprocessor, you can just generate it using C++ template metaprogramming. Perhaps, you would use the preprocessor to generate the keys, but not the mapper or table class(as I show in my little example).
Likewise in quince, most of the work of QUINCE_MAP_CLASS etc. is done without macros, by something called typed_class_mapper_base (which the user never mentions). It's also perhaps worth pointing out that the whole implementation of QUINCE_MAP_CLASS and QUINCE_MAP_CLASS_WITH_BASES is a very small part of quince. On the other hand the mapper classes that they generate are referenced ubiquitously.
Boost.Fusion does a great job of handling product types, which an ORM would need. It seems unnecessary to reinvent the wheel here.
My philosophy is somewhat different. I don't believe that I should accept sacrifices (degraded EDSL, indirect implementation) for the sake of using Boost.Fusion. On the contrary, I think any such decision needs to be justified by benefits, to outweigh the negative of inter-library dependence. Again I cite http://www.boost.org/development/reuse.html . Cheers, --- Michael