The main motivation for this is that building error messages via string
concatenation is tedious and makes it hard to judge what the actual message
looks like when there are a lot of parts being inserted, to the extent that
I've been tempted to leave out some potentially useful information because the
code was getting unwieldy.
It also has some small functional benefits: bools are printed as true/false
rather than 1/0, and it is optimized for minimizing the compiled size.
Currently it cuts ~30 KB off librealm-object-store.dylib even with the addition
of new functionality.
constructors.
This avoids having to repeat the move constructor's logic in the move
assignment operator, and allows the copy assignment operator to compile
despite `TableViewBase`'s missing copy assignment implementation. the
copy assignment implementation can be defaulted once `TableViewBase` is
fixed.
The custom implementation was an attempt to ensure that
`m_has_used_table_view` and `m_wants_background_updates` had appropriate
intial values. Thomas pointed out that we can remove the reliance on the
initial values by ensure that `prepare_async` sets
`m_wants_background_updates`, removing the need for a custom copy
constructor.
* object-store/master:
Make Realm::is_closed() work on read-only instances
Fix for object store build issues on Android
Implement commit helper and realm notifier for Android (#69)
Build both dynamic and static libraries.
moving pegtl dependency as step 1 in install doc
update docu (install procedure)
`Realm`, and moving from a `Results` to not result in a use-after-free.
The compiler generated move-assignment operator resulted in `m_notifier`
being assigned to without first calling `CollectionNotifier::unregister`.
This left a retain cycle in place, causing the `Realm` and other objects
to leak.
`ResultsNotifier` keeps track of which `Results` it should update when a
new `TableView` becomes available. When `Results` move-assignment
operator and move-constructor transfer ownership of the
`ResultsNotifier` to a new instance they also need to update its target
so it won't attempt to update the moved-from `Results`.
The Xcode project generated by CMake doesn't create the dylib when built
as the dylib target does not contain any source files. Adding an empty
placeholder .cpp file to the target is sufficient to convince Xcode to
produce the dylib.