[odb-users] Mapping to nullptr_t in templated class interface

Henri Schwarz il1k3pepsi at gmail.com
Tue Jun 27 04:42:07 EDT 2017


Hi Boris,

I've solved the problem a little bit different but the essential hint was
marking the data member as transient. Within the interface class I'm using
a type alias to specify the type of the data member.

*template <typename T> *
*struct parent_interface {*

*using parent_type = std::shared_ptr<T>;*
*...*

*}*

Maybe I should rename the class to parent_policy or something, because the
getter and setter methods are implemented right in the place and the data
member belongs to the classes private members.

*{*

*...*

*parent_type const &get_parent() const {*

*return parent_;*



*}*

*void set_parent(parent_type const &parent) {*

*parent_ = parent;*





*}private:*



*#pragma db default(null)parent_type parent_;*

*}*

What did the trick was a full template specialization for the nullptr'ed
case where the data member is marked as transient.

*template <>*
*struct parent_interface<nullptr_t> {*

*...*

*private:*

*#pragma db transient*

*parent_type parent_ {nullptr};*

*}*

Now I can use the (badly named) interface classes in my persistent class
hierarchy. As a bonus the odb compiler produces less code compared to the
case where the interface classes only declare the getter and setter methods
as virtual and the inheriting classes override them.

class Level_1 : public parent_interface<nullptr_t>, public
child_interface<Level_2> { ... }  // compiles now

Kind regards,

Henri



2017-06-21 19:15 GMT+02:00 Boris Kolpackov <boris at codesynthesis.com>:

> Henri Schwarz <il1k3pepsi at gmail.com> writes:
>
> > But the odb compiler gives me an error "unable to map C++ type
> > '::parent_interface< ::std::nullptr_t >::parent_type' used in data member
> > 'parent' to a SQLite database type".
>
> You could mark the parent member in Level1 class (that derives from the
> nullptr'ed parent_interface) as transient. Probably no use storing it in
> the database since it is always NULL.
>
> Boris
>


More information about the odb-users mailing list