Support explicit insertion of boost::none

[bjoernpollex]

It would be useful to support explicitly inserting NULL values by writing boost::none, like this:

db << "INSERT INTO foo(field) VALUES (?)" << boost::none;

Currently this does not work because boost::none is a special type, and not automatically converted to any of the overloads for boost::optional.

[Killili]

Sounds interessting, never thought about that way to do it.
But i would like to have that in the library without having a new Boost dependent feature.

db << "INSERT INTO foo(field) VALUES (?)" << sqlite3::null;

This would be a nice thing to have.

[bjoernpollex]

Sure, that works just as well.

[Killili]

I added that as a extension because it has limited use to the normal user and does not require changes to the main header to work.
See pull request #51 for source and example.

First i tried to make the null_value more intelligent and able to store the data is the value was not null but that would duplicate the functionality boost::optional already has and we have support for that already. Thats why this is such a simplistic approach.

@aminroosta if you are happy with this too, plz pull.

[aminroosta]

@Killili Thanks for #51,i have a different approach in my mind. take a look at #52 and then we will choose which one to go forward with.

[Killili]

Thats elegant and gets rid of boost::optional in one go, i like it.

[aminroosta]

Cool, i will update readme in #52 and then merge.

[bjoernpollex]

Hm, I agree that this solution is quite elegant, but deprecating boost::optional doesn't seem optimal to me. std::unique_ptr does dynamic memory allocation, which boost::optional does not. boost::optional also has other useful functions, such as delegating assignment and equality comparison operators. I'd prefer to keep it in. At some point this library can maybe deprecate it in favor of the upcoming std::optional.

[aminroosta]

Is std::optional coming to C++17 ?

[Killili]

So we deprecate boost but let it in till then, but its non the less deprecated.

[arude]

std::optional is part of Fundamentals v1 which was done about 1 year ago which suggests that it should make it into C++17.

[aminroosta]

If std::optional is going to be part of C++17 then i think we should deprecate both boost and unique_ptr approaches for a while and eventually drop them when we migrate to only supporting C++17

[Killili]

I dont see why we should depricate the unique_ptr stuff its a valid alternative to the optional stuff. And i would prefer it over the other. But we might add to the deprecation text of boost::optional that it will be replaced by std::optional when its available.

[aminroosta]

According to std::optional reference.

Any instance of optional<T> at any given point in time
either contains a value or does not contain a value.
If an optional contains a value, the value is guaranteed
to be allocated as part of the optional object footprint,
i.e. no dynamic memory allocation ever takes place.
Thus, an optional object models an object, not a pointer,
even though the operator*() and operator->() are defined.

[Killili]

Thats what @bjoernpollex said. And he has a valid point in that its usefull and should be in there. But i dont fear a simple new ;). On the other hand thats true for unique_ptr, too if you think about it. The space for the pointer is allocated at instanciation and might never contain anything other then the nullptr ;)

[aminroosta]

I'm happy with the way we are handling null values right now. :-)
Lets come back to this when we actually have a compiler which supports std::optional<T>.

[bjoernpollex]

I agree, right now both ways work and are useful for different scenarios.