[odb-users] reading value from default-constructed odb::nullable<T> causes undefined behaviour

[Boris Kolpackov]

Sten Kultakangas <ratkaisut at gmail.com> writes:

> Apparently, the functionality of odb::nullable<T> (where T is non-trivially
> constructible) has changed since commit 3795f78 ("Improve odb::nullable for
> C++11 and later") for the cases when the ODB_CXX11 macro is enabled.

Specifically, in C++11 it can be used with types that are not default-
constructible


> Since I don't know when the ODB_CXX11 macro was enabled by default, I am
> not sure whether this change affected the production code that uses version
> v2.5.0-b.27 or a later version. Could somebody confirm whether this
> affected all the versions from v2.5.0-b.27 onwards?

The ODB_CXX11 macro is defined when your C++ compiler is in the C++11 mode
or later, which, these days, is the case with the recent versions of all
the major compilers.


> Since calling get() of std::nullable<T> is a bad practice without checking
> for the value returned by the null() member function first, I suggest
> either throwing an exception or returning a default value of T, because
> undefined behaviour is hard to track.

Yes, that's true. By analogy with std::optional::value(), this function
should be checked. Though perhaps the better solution is to deprecate
odb::nullable in favor of std::optional (which we plan to support out
of the box in the next release of ODB). I've filed an issue to track
this:

https://github.com/codesynthesis-com/odb/issues/10

Thanks for the report.