[odb-users] possible solution to 'friend' declaration, pragma
setters and getters
boris at codesynthesis.com
Fri Oct 21 06:08:28 EDT 2011
Brown, Matt C <Brown223 at llnl.gov> writes:
> #pragma db object(Foo) construct(Foo(id))... <not really sure how to handle this>)
> #pragma db member(Foo::id_) set(set_id) get(id) id auto
> #pragma db member(Foo::val_) set(set_val) get(val)
Yes, we have plans to support something like this. The current name for
this feature is "virtual member": I have described the basic idea behind
virtual members in this post:
Though the default-construction idea is new.
> I obviously left the 'construct' case ambiguous.
The construct pragma would most likely provide an expression that would
be equivalent to default-construction. So, in your case, it would be:
#pragma db object(Foo) construct(Foo (0))
Though it may be useful to allow passing the object id, e.g.:
#pragma db object(Foo) construct(Foo (?))
> And there are plenty of more complicated cases (for instance, what if
> there is a set_all(int id, int val) function, and you want to somehow
> use that).
Supporting something like this would be difficult since we would first
need to extract all the data members and then pass them in one go to
the initialization function. What we could do instead is to allow the
user to extract the data into a temporary that can then be used to
initialize the object. For example:
// If a temporary is used, then in the 'construct' and 'set' pragmas,
// 'this' refers to the temporary, not the object.
#pragma db object(Foo) temporary(FooData) construct(Foo (this->id, this->val))
#pragma db member(Foo::id_) set(this->id) get(this->id ()) id auto
#pragma db member(Foo::val_) set(this->val) get(this->val ())
Though, as you can see, this complicates things significantly, so I am not
sure we should support this.
> In case you're curious, I'm trying to mash-up google protocol buffers and
> odb. Protobuf also uses code generation. While it is probably possible to
> modify its code generator to include the necessary odb hooks (i.e. friend
> declaration, pragmas, etc).
If I remember correctly, last time I checked, generated protobuffer objects
all had default c-tors and public data members. I believe some folks are
successfully using ODB with protobuffers by simply adding pragmas out-of-
> In general, I think adding this feature would make it MUCH simpler to add
> 'native' support for new 3rd-party types.
Yes, I agree.
> For instance, if I wanted to add support for something like QRect (a simple
> rectangle class from qt), right now I'd have to go write a specialization
> for each database type, and teach odb how to find it (i.e. options
You can only use this approach if you can squeeze QRect into a single
database column (the value_traits templates are there to add support
for new simple (i.e., single-column) values). I think QRect will be
more naturally mapped to a composite value, for which you would need
the virtual member feature.
More information about the odb-users