This adds a generic string search library in `BLI_string_search.h`.
The library has a simple to use C api that allows it's users to
filter and sort a set of possible search results based on some
query string.
Reviewers: Severin
Differential Revision: https://developer.blender.org/D8825
The code to detect non-trivial coplanar intersection sometimes
falsely said there wasn't one. This caused some coplanar intersections
to be missed. Also added a test for this case.
This was reported for the "Add Node" search functionality, but is
relevant in other searches as well.
So e.g. when searching for "Separate XYZ", typing "sep", then " " (with
the intention to type "X" next) would clear the search field. Now use
the same method (matching against all search words) as in F3 searching
('menu_search_update_fn') in other searches as well [searching IDs,
property objects, finding nodes,...]
This should give a much nicer search experience in general.
Note: this does not touch other searches in the Dopesheet, Outliner,
Filebrowser or User Preferences that have other search implementations.
Maniphest Tasks: T78084
Differential Revision: https://developer.blender.org/D8232
This is for design task T67744, Boolean Redesign.
It adds a choice of solver to the Boolean modifier and the
Intersect (Boolean) and Intersect (Knife) tools.
The 'Fast' choice is the current Bmesh boolean.
The new 'Exact' choice is a more advanced algorithm that supports
overlapping geometry and uses more robust calculations, but is
slower than the Fast choice.
The default with this commit is set to 'Exact'. We can decide before
the 2.91 release whether or not this is the right choice, but this
choice now will get us more testing and feedback on the new code.
Using C++ exceptions in Blender is difficult, due to the large
number of C functions in the call stack. However, C++ data
structures in blenlib should at least try to be exception safe,
so that they can be used if someone wants to use exceptions
in some isolated area.
This patch improves the exception safety of the Vector, Array
and Stack data structure. This is mainly achieved by reordering
some lines and doing some explicit exception handling.
I don't expect performance of common operations to be affected
by this change.
The three containers are supposed to provide at least the
basic exception guarantee for most methods (except for e.g.
`*_unchecked` methods). So, resources should not leak when
the contained type throws an exception.
I also added new unit tests that test the exception handling
in various cases.
The new reverse iterators behave as the reverse iterators for contains from
the standard library. Have a look at the tests to see how to use them.
Using them will hopefully become easier with ranges in C++20.
A Vector can now be constructed from two iterators, which is very common
in the standard library.
New Vector.insert methods allow adding elements in the middle of a vector.
These methods should not be used often in practice, because they has a linear running time.
New Vector.prepend methods allow adding elements to the beginning of a vector.
These methods are O(n) as well.
Mainly caused by moving tests to source folder, which brings
new compiler flags.
Also, no need to extend include directories (to the non-existing paths,
btw) since this is done by the CmakeList.txt which is in the blenlib folder.
The file was including BKE. It was a required fix for another
compilation error a while back. It is a bad level include, and
seems is not needed anymore.
Since C++17 there is also std::string_view, which is similar to StringRef.
This commit does a couple of things:
* New implicit conversions between StringRef and std::string_view.
* Support std::string_view in blender::DefaultHash.
* Support most of the methods that std::string_view has.
* Add StringRef::not_found which can be used instead of -1 in some places.
* Improve/fix the description at the top of BLI_string_ref.hh.
And make them part of the blender_test runner. The one exception is blenlib
performance tests, which we don't want to run by default. They remain in their
own executable.
Differential Revision: https://developer.blender.org/D8498
This is a convenience wrapper for `Map<Key, Vector<Value>>`.
It does not provide any performance benefits (yet). I need this
kind of map in a couple of places and before I was duplicating
the lookup logic in many places.