diff options
author | Jacques Lucke <jacques@blender.org> | 2020-06-09 11:27:24 +0300 |
---|---|---|
committer | Jacques Lucke <jacques@blender.org> | 2020-06-09 11:27:24 +0300 |
commit | 9bb7d6ed68ef1aa0e6acc3e70901cb6b79c682d2 (patch) | |
tree | 843993222b8ee5c02451207404ceb113323ede6f /source | |
parent | d8678e02ecec9375bec1dcf1388c6fc8b4ce3ad2 (diff) |
BLI: put C++ data structures in "blender" namespace instead of "BLI"
We plan to use the "blender" namespace in other modules as well.
Diffstat (limited to 'source')
41 files changed, 186 insertions, 184 deletions
diff --git a/source/blender/blenkernel/intern/simulation.cc b/source/blender/blenkernel/intern/simulation.cc index 20386869ca9..8f08665ab8a 100644 --- a/source/blender/blenkernel/intern/simulation.cc +++ b/source/blender/blenkernel/intern/simulation.cc @@ -54,9 +54,9 @@ #include "DEG_depsgraph.h" #include "DEG_depsgraph_query.h" -using BLI::ArrayRef; -using BLI::float3; -using BLI::MutableArrayRef; +using blender::ArrayRef; +using blender::float3; +using blender::MutableArrayRef; static void simulation_init_data(ID *id) { diff --git a/source/blender/blenlib/BLI_allocator.hh b/source/blender/blenlib/BLI_allocator.hh index cf81b024277..d57703f71bc 100644 --- a/source/blender/blenlib/BLI_allocator.hh +++ b/source/blender/blenlib/BLI_allocator.hh @@ -19,9 +19,9 @@ /** \file * \ingroup bli * - * An `Allocator` can allocate and deallocate memory. It is used by containers such as BLI::Vector. - * The allocators defined in this file do not work with standard library containers such as - * std::vector. + * An `Allocator` can allocate and deallocate memory. It is used by containers such as + * blender::Vector. The allocators defined in this file do not work with standard library + * containers such as std::vector. * * Every allocator has to implement two methods: * void *allocate(size_t size, size_t alignment, const char *name); @@ -46,7 +46,7 @@ #include "BLI_math_base.h" #include "BLI_utildefines.h" -namespace BLI { +namespace blender { /** * Use Blender's guarded allocator (aka MEM_*). This should always be used except there is a @@ -99,6 +99,6 @@ class RawAllocator { } }; -} // namespace BLI +} // namespace blender #endif /* __BLI_ALLOCATOR_HH__ */ diff --git a/source/blender/blenlib/BLI_array.hh b/source/blender/blenlib/BLI_array.hh index 09eeb321abf..874cd6b215a 100644 --- a/source/blender/blenlib/BLI_array.hh +++ b/source/blender/blenlib/BLI_array.hh @@ -19,23 +19,23 @@ /** \file * \ingroup bli * - * A `BLI::Array<T>` is a container for a fixed size array the size of which is NOT known at + * A `blender::Array<T>` is a container for a fixed size array the size of which is NOT known at * compile time. * * If the size is known at compile time, `std::array<T, N>` should be used instead. * - * BLI::Array should usually be used instead of BLI::Vector whenever the number of elements is - * known at construction time. Note however, that BLI::Array will default construct all elements - * when initialized with the size-constructor. For trivial types, this does nothing. In all other - * cases, this adds overhead. If this becomes a problem, a different constructor which does not do - * default construction can be added. + * blender::Array should usually be used instead of blender::Vector whenever the number of elements + * is known at construction time. Note however, that blender::Array will default construct all + * elements when initialized with the size-constructor. For trivial types, this does nothing. In + * all other cases, this adds overhead. If this becomes a problem, a different constructor which + * does not do default construction can be added. * * A main benefit of using Array over Vector is that it expresses the intent of the developer * better. It indicates that the size of the data structure is not expected to change. Furthermore, * you can be more certain that an array does not overallocate. * - * BLI::Array supports small object optimization to improve performance when the size turns out to - * be small at run-time. + * blender::Array supports small object optimization to improve performance when the size turns out + * to be small at run-time. */ #include "BLI_allocator.hh" @@ -44,7 +44,7 @@ #include "BLI_memory_utils.hh" #include "BLI_utildefines.h" -namespace BLI { +namespace blender { template< /** @@ -341,6 +341,6 @@ class Array { } }; -} // namespace BLI +} // namespace blender #endif /* __BLI_ARRAY_HH__ */ diff --git a/source/blender/blenlib/BLI_array_ref.hh b/source/blender/blenlib/BLI_array_ref.hh index 34745c0af83..2a4d0b6e0df 100644 --- a/source/blender/blenlib/BLI_array_ref.hh +++ b/source/blender/blenlib/BLI_array_ref.hh @@ -20,26 +20,26 @@ /** \file * \ingroup bli * - * A `BLI::ArrayRef<T>` references an array that is owned by someone else. It is just a pointer and - * a size. Since the memory is not owned, ArrayRef should not be used to transfer ownership. The - * array cannot be modified through the ArrayRef. However, if T is a non-const pointer, the - * pointed-to elements can be modified. + * An `blender::ArrayRef<T>` references an array that is owned by someone else. It is just a + * pointer and a size. Since the memory is not owned, ArrayRef should not be used to transfer + * ownership. The array cannot be modified through the ArrayRef. However, if T is a non-const + * pointer, the pointed-to elements can be modified. * - * There is also `BLI::MutableArrayRef<T>`. It is mostly the same as ArrayRef, but allows the array - * to be modified. + * There is also `blender::MutableArrayRef<T>`. It is mostly the same as ArrayRef, but allows the + * array to be modified. * * An (Mutable)ArrayRef can refer to data owned by many different data structures including - * BLI::Vector, BLI::Array, BLI::VectorSet, std::vector, std::array, std::string, + * blender::Vector, blender::Array, blender::VectorSet, std::vector, std::array, std::string, * std::initializer_list and c-style array. * - * `BLI::ArrayRef<T>` should be your default choice when you have to pass a read-only array into a - * function. It is better than passing a `const Vector &`, because then the function only works for - * vectors and not for e.g. arrays. Using ArrayRef as function parameter makes it usable in more - * contexts, better expresses the intent and does not sacrifice performance. It is also better than - * passing a raw pointer and size separately, because it is more convenient and safe. + * `blender::ArrayRef<T>` should be your default choice when you have to pass a read-only array + * into a function. It is better than passing a `const Vector &`, because then the function only + * works for vectors and not for e.g. arrays. Using ArrayRef as function parameter makes it usable + * in more contexts, better expresses the intent and does not sacrifice performance. It is also + * better than passing a raw pointer and size separately, because it is more convenient and safe. * - * `BLI::MutableArrayRef<T>` can be used when a function is supposed to return an array, the size - * of which is known before the function is called. One advantage of this approach is that the + * `blender::MutableArrayRef<T>` can be used when a function is supposed to return an array, the + * size of which is known before the function is called. One advantage of this approach is that the * caller is responsible for allocation and deallocation. Furthermore, the function can focus on * its task, without having to worry about memory allocation. Alternatively, a function could * return an Array or Vector. @@ -64,7 +64,7 @@ #include "BLI_memory_utils.hh" #include "BLI_utildefines.h" -namespace BLI { +namespace blender { /** * References an array of type T that is owned by someone else. The data in the array cannot be @@ -625,6 +625,6 @@ void assert_same_size(const T1 &v1, const T2 &v2, const T3 &v3) #endif } -} /* namespace BLI */ +} /* namespace blender */ #endif /* __BLI_ARRAY_REF_HH__ */ diff --git a/source/blender/blenlib/BLI_color.hh b/source/blender/blenlib/BLI_color.hh index ff28ae2c076..432459c9998 100644 --- a/source/blender/blenlib/BLI_color.hh +++ b/source/blender/blenlib/BLI_color.hh @@ -21,7 +21,7 @@ #include "BLI_math_color.h" -namespace BLI { +namespace blender { struct Color4f { float r, g, b, a; @@ -87,6 +87,6 @@ struct Color4b { } }; -} // namespace BLI +} // namespace blender #endif /* __BLI_COLOR_HH__ */ diff --git a/source/blender/blenlib/BLI_dot_export.hh b/source/blender/blenlib/BLI_dot_export.hh index 8da0ed6df14..60353d7913f 100644 --- a/source/blender/blenlib/BLI_dot_export.hh +++ b/source/blender/blenlib/BLI_dot_export.hh @@ -34,7 +34,7 @@ #include <sstream> -namespace BLI { +namespace blender { namespace DotExport { class Graph; @@ -208,7 +208,7 @@ class NodePort { void to_dot_string(std::stringstream &ss) const; }; -class Edge : BLI::NonCopyable, BLI::NonMovable { +class Edge : blender::NonCopyable, blender::NonMovable { protected: AttributeList m_attributes; NodePort m_a; @@ -284,6 +284,6 @@ class NodeWithSocketsRef { }; } // namespace DotExport -} // namespace BLI +} // namespace blender #endif /* __BLI_DOT_EXPORT_HH__ */ diff --git a/source/blender/blenlib/BLI_dot_export_attribute_enums.hh b/source/blender/blenlib/BLI_dot_export_attribute_enums.hh index 8e61f46dc12..8fe1cda05f3 100644 --- a/source/blender/blenlib/BLI_dot_export_attribute_enums.hh +++ b/source/blender/blenlib/BLI_dot_export_attribute_enums.hh @@ -19,7 +19,7 @@ #include "BLI_string_ref.hh" -namespace BLI { +namespace blender { namespace DotExport { enum class Attr_rankdir { @@ -120,6 +120,6 @@ inline StringRef dirType_to_string(Attr_dirType value) } } // namespace DotExport -} // namespace BLI +} // namespace blender #endif /* __BLI_DOT_EXPORT_ATTRIBUTE_ENUMS_HH__ */ diff --git a/source/blender/blenlib/BLI_float2.hh b/source/blender/blenlib/BLI_float2.hh index da12dd7d206..94da5d18ad2 100644 --- a/source/blender/blenlib/BLI_float2.hh +++ b/source/blender/blenlib/BLI_float2.hh @@ -19,7 +19,7 @@ #include "BLI_float3.hh" -namespace BLI { +namespace blender { struct float2 { float x, y; @@ -81,6 +81,6 @@ struct float2 { } }; -} // namespace BLI +} // namespace blender #endif /* __BLI_FLOAT2_HH__ */ diff --git a/source/blender/blenlib/BLI_float3.hh b/source/blender/blenlib/BLI_float3.hh index 9678fa4b2d3..7ef4f1b4973 100644 --- a/source/blender/blenlib/BLI_float3.hh +++ b/source/blender/blenlib/BLI_float3.hh @@ -21,7 +21,7 @@ #include "BLI_math_vector.h" -namespace BLI { +namespace blender { struct float3 { float x, y, z; @@ -213,6 +213,6 @@ struct float3 { } }; -} // namespace BLI +} // namespace blender #endif /* __BLI_FLOAT3_HH__ */ diff --git a/source/blender/blenlib/BLI_float4x4.hh b/source/blender/blenlib/BLI_float4x4.hh index 36186d319c9..0abfb751ebf 100644 --- a/source/blender/blenlib/BLI_float4x4.hh +++ b/source/blender/blenlib/BLI_float4x4.hh @@ -20,7 +20,7 @@ #include "BLI_float3.hh" #include "BLI_math_matrix.h" -namespace BLI { +namespace blender { struct float4x4 { float values[4][4]; @@ -110,6 +110,6 @@ struct float4x4 { } }; -} // namespace BLI +} // namespace blender #endif /* __BLI_FLOAT4X4_HH__ */ diff --git a/source/blender/blenlib/BLI_hash.hh b/source/blender/blenlib/BLI_hash.hh index 029fa32553a..57d5f7f9d8a 100644 --- a/source/blender/blenlib/BLI_hash.hh +++ b/source/blender/blenlib/BLI_hash.hh @@ -20,8 +20,8 @@ /** \file * \ingroup bli * - * A specialization of `BLI::DefaultHash<T>` provides a hash function for values of type T. This - * hash function is used by default in hash table implementations in blenlib. + * A specialization of `blender::DefaultHash<T>` provides a hash function for values of type T. + * This hash function is used by default in hash table implementations in blenlib. * * The actual hash function is in the `operator()` method of DefaultHash<T>. The following code * computes the hash of some value using DefaultHash. @@ -30,8 +30,8 @@ * DefaultHash<T> hash_function; * uint32_t hash = hash_function(value); * - * Hash table implementations like BLI::Set support heterogeneous key lookups. That means that one - * can do a lookup with a key of type A in a hash table that stores keys of type B. This is + * Hash table implementations like blender::Set support heterogeneous key lookups. That means that + * one can do a lookup with a key of type A in a hash table that stores keys of type B. This is * commonly done when B is std::string, because the conversion from e.g. a StringRef to std::string * can be costly and is unnecessary. To make this work, values of type A and B that compare equal * have to have the same hash value. This is achieved by defining potentially multiple `operator()` @@ -57,7 +57,7 @@ * specialization to the DefaultHash struct. This can be done by writing code like below in * either global or BLI namespace. * - * template<> struct BLI::DefaultHash<TheType> { + * template<> struct blender::DefaultHash<TheType> { * uint32_t operator()(const TheType &value) const { * return ...; * } @@ -83,7 +83,7 @@ #include "BLI_string_ref.hh" #include "BLI_utildefines.h" -namespace BLI { +namespace blender { /** * If there is no other specialization of DefaultHash for a given type, try to call `hash()` on the @@ -206,6 +206,6 @@ template<typename T1, typename T2> struct DefaultHash<std::pair<T1, T2>> { } }; -} // namespace BLI +} // namespace blender #endif /* __BLI_HASH_HH__ */ diff --git a/source/blender/blenlib/BLI_hash_tables.hh b/source/blender/blenlib/BLI_hash_tables.hh index c171b26f770..93c887dedfa 100644 --- a/source/blender/blenlib/BLI_hash_tables.hh +++ b/source/blender/blenlib/BLI_hash_tables.hh @@ -33,7 +33,7 @@ #include "BLI_utildefines.h" #include "BLI_vector.hh" -namespace BLI { +namespace blender { /* -------------------------------------------------------------------- */ /** \name Constexpr Utility Functions @@ -345,6 +345,6 @@ struct DefaultEquality { } }; -} // namespace BLI +} // namespace blender #endif /* __BLI_OPEN_ADDRESSING_HH__ */ diff --git a/source/blender/blenlib/BLI_index_mask.hh b/source/blender/blenlib/BLI_index_mask.hh index 96ab8906bd4..4cd348215fe 100644 --- a/source/blender/blenlib/BLI_index_mask.hh +++ b/source/blender/blenlib/BLI_index_mask.hh @@ -41,7 +41,7 @@ #include "BLI_array_ref.hh" #include "BLI_index_range.hh" -namespace BLI { +namespace blender { class IndexMask { private: @@ -207,6 +207,6 @@ class IndexMask { } }; -} // namespace BLI +} // namespace blender #endif /* __BLI_INDEX_MASK_HH__ */ diff --git a/source/blender/blenlib/BLI_index_range.hh b/source/blender/blenlib/BLI_index_range.hh index 4a64ae16589..8a97facd9c0 100644 --- a/source/blender/blenlib/BLI_index_range.hh +++ b/source/blender/blenlib/BLI_index_range.hh @@ -20,7 +20,7 @@ /** \file * \ingroup bli * - * A `BLI::IndexRange` wraps an interval of non-negative integers. It can be used to reference + * A `blender::IndexRange` wraps an interval of non-negative integers. It can be used to reference * consecutive elements in an array. Furthermore, it can make for loops more convenient and less * error prone, especially when using nested loops. * @@ -35,10 +35,10 @@ * for (uint j : IndexRange(20)) { * for (uint k : IndexRange(30)) { * - * Some containers like BLI::Vector have an index_range() method. This will return the IndexRange - * that contains all indices that can be used to access the container. This is particularly useful - * when you want to iterate over the indices and the elements (much like Python's enumerate(), just - * worse). Again, I think the second example here is better: + * Some containers like blender::Vector have an index_range() method. This will return the + * IndexRange that contains all indices that can be used to access the container. This is + * particularly useful when you want to iterate over the indices and the elements (much like + * Python's enumerate(), just worse). Again, I think the second example here is better: * * for (uint i = 0; i < my_vector_with_a_long_name.size(); i++) { * do_something(i, my_vector_with_a_long_name[i]); @@ -64,7 +64,7 @@ namespace tbb { template<typename Value> class blocked_range; } -namespace BLI { +namespace blender { template<typename T> class ArrayRef; @@ -236,6 +236,6 @@ class IndexRange { } }; -} // namespace BLI +} // namespace blender #endif /* __BLI_INDEX_RANGE_HH__ */ diff --git a/source/blender/blenlib/BLI_linear_allocator.hh b/source/blender/blenlib/BLI_linear_allocator.hh index 8b77855bb07..e2bb3ce02cb 100644 --- a/source/blender/blenlib/BLI_linear_allocator.hh +++ b/source/blender/blenlib/BLI_linear_allocator.hh @@ -29,7 +29,7 @@ #include "BLI_utility_mixins.hh" #include "BLI_vector.hh" -namespace BLI { +namespace blender { template<typename Allocator = GuardedAllocator> class LinearAllocator : NonCopyable, NonMovable { private: @@ -215,6 +215,6 @@ template<typename Allocator = GuardedAllocator> class LinearAllocator : NonCopya } }; -} // namespace BLI +} // namespace blender #endif /* __BLI_LINEAR_ALLOCATOR_HH__ */ diff --git a/source/blender/blenlib/BLI_listbase_wrapper.hh b/source/blender/blenlib/BLI_listbase_wrapper.hh index 70f3135d9e3..a77e2d66458 100644 --- a/source/blender/blenlib/BLI_listbase_wrapper.hh +++ b/source/blender/blenlib/BLI_listbase_wrapper.hh @@ -20,16 +20,16 @@ /** \file * \ingroup bli * - * `BLI::ListBaseWrapper` is a typed wrapper for the ListBase struct. That makes it safer and more - * convenient to use in C++ in some cases. However, if you find yourself iterating over a linked - * list a lot, consider to convert it into a vector for further processing. This improves + * `blender::ListBaseWrapper` is a typed wrapper for the ListBase struct. That makes it safer and + * more convenient to use in C++ in some cases. However, if you find yourself iterating over a + * linked list a lot, consider to convert it into a vector for further processing. This improves * performance and debugability. */ #include "BLI_listbase.h" #include "DNA_listBase.h" -namespace BLI { +namespace blender { template<typename T> class ListBaseWrapper { private: @@ -110,6 +110,6 @@ template<typename T> class ListBaseWrapper { } }; -} /* namespace BLI */ +} /* namespace blender */ #endif /* __BLI_LISTBASE_WRAPPER_HH__ */ diff --git a/source/blender/blenlib/BLI_map.hh b/source/blender/blenlib/BLI_map.hh index 54e086cc36d..56ec5b7010c 100644 --- a/source/blender/blenlib/BLI_map.hh +++ b/source/blender/blenlib/BLI_map.hh @@ -20,16 +20,16 @@ /** \file * \ingroup bli * - * A `BLI::Map<Key, Value>` is an unordered associative container that stores key-value pairs. The - * keys have to be unique. It is designed to be a more convenient and efficient replacement for + * A `blender::Map<Key, Value>` is an unordered associative container that stores key-value pairs. + * The keys have to be unique. It is designed to be a more convenient and efficient replacement for * `std::unordered_map`. All core operations (add, lookup, remove and contains) can be done in O(1) * amortized expected time. * - * Your default choice for a hash map in Blender should be `BLI::Map`. + * Your default choice for a hash map in Blender should be `blender::Map`. * - * BLI::Map is implemented using open addressing in a slot array with a power-of-two size. Every - * slot is in one of three states: empty, occupied or removed. If a slot is occupied, it contains - * a Key and Value instance. + * blender::Map is implemented using open addressing in a slot array with a power-of-two size. + * Every slot is in one of three states: empty, occupied or removed. If a slot is occupied, it + * contains a Key and Value instance. * * Benchmarking and comparing hash tables is hard, because many factors influence the result. The * performance of a hash table depends on the combination of the hash function, probing strategy, @@ -38,7 +38,7 @@ * that allow it to be optimized for a specific use case. * * A rudimentary benchmark can be found in BLI_map_test.cc. The results of that benchmark are there - * as well. The numbers show that in this specific case BLI::Map outperforms std::unordered_map + * as well. The numbers show that in this specific case blender::Map outperforms std::unordered_map * consistently by a good amount. * * Some noteworthy information: @@ -64,7 +64,7 @@ * - The method names don't follow the std::unordered_map names in many cases. Searching for such * names in this file will usually let you discover the new name. * - There is a StdUnorderedMapWrapper class, that wraps std::unordered_map and gives it the same - * interface as BLI::Map. This is useful for benchmarking. + * interface as blender::Map. This is useful for benchmarking. */ #include <unordered_map> @@ -75,7 +75,7 @@ #include "BLI_map_slots.hh" #include "BLI_probing_strategies.hh" -namespace BLI { +namespace blender { template< /** @@ -1097,11 +1097,12 @@ class Map { }; /** - * A wrapper for std::unordered_map with the API of BLI::Map. This can be used for benchmarking. + * A wrapper for std::unordered_map with the API of blender::Map. This can be used for + * benchmarking. */ template<typename Key, typename Value> class StdUnorderedMapWrapper { private: - using MapType = std::unordered_map<Key, Value, BLI::DefaultHash<Key>>; + using MapType = std::unordered_map<Key, Value, blender::DefaultHash<Key>>; MapType m_map; public: @@ -1162,6 +1163,6 @@ template<typename Key, typename Value> class StdUnorderedMapWrapper { } }; -} // namespace BLI +} // namespace blender #endif /* __BLI_MAP_HH__ */ diff --git a/source/blender/blenlib/BLI_map_slots.hh b/source/blender/blenlib/BLI_map_slots.hh index dd6d706e2af..9ea2c4cad89 100644 --- a/source/blender/blenlib/BLI_map_slots.hh +++ b/source/blender/blenlib/BLI_map_slots.hh @@ -20,7 +20,7 @@ /** \file * \ingroup bli * - * This file contains slot types that are supposed to be used with BLI::Map. + * This file contains slot types that are supposed to be used with blender::Map. * * Every slot type has to be able to hold a value of type Key, a value of type Value and state * information. A map slot has three possible states: empty, occupied and removed. @@ -37,7 +37,7 @@ #include "BLI_memory_utils.hh" -namespace BLI { +namespace blender { /** * The simplest possible map slot. It stores the slot state and the optional key and value @@ -356,6 +356,6 @@ template<typename Key, typename Value> struct DefaultMapSlot<Key *, Value> { using type = IntrusiveMapSlot<Key *, Value, PointerKeyInfo<Key *>>; }; -} // namespace BLI +} // namespace blender #endif /* __BLI_MAP_SLOTS_HH__ */ diff --git a/source/blender/blenlib/BLI_memory_utils.hh b/source/blender/blenlib/BLI_memory_utils.hh index 2f7b27240f3..de9fc956bfb 100644 --- a/source/blender/blenlib/BLI_memory_utils.hh +++ b/source/blender/blenlib/BLI_memory_utils.hh @@ -25,7 +25,7 @@ #include "BLI_utildefines.h" -namespace BLI { +namespace blender { /** * Call the default constructor on n consecutive elements. For trivially constructible types, this @@ -249,6 +249,6 @@ template<size_t Size, size_t Alignment> class alignas(Alignment) AlignedBuffer { } }; -} // namespace BLI +} // namespace blender #endif /* __BLI_MEMORY_UTILS_HH__ */ diff --git a/source/blender/blenlib/BLI_optional.hh b/source/blender/blenlib/BLI_optional.hh index aeef0e7e151..b5f98d6fa97 100644 --- a/source/blender/blenlib/BLI_optional.hh +++ b/source/blender/blenlib/BLI_optional.hh @@ -29,7 +29,7 @@ #include <algorithm> #include <memory> -namespace BLI { +namespace blender { template<typename T> class Optional { private: @@ -184,6 +184,6 @@ template<typename T> class Optional { } }; -} /* namespace BLI */ +} /* namespace blender */ #endif /* __BLI_OPTIONAL_HH__ */ diff --git a/source/blender/blenlib/BLI_probing_strategies.hh b/source/blender/blenlib/BLI_probing_strategies.hh index 9fa402d4244..29ebe28aff9 100644 --- a/source/blender/blenlib/BLI_probing_strategies.hh +++ b/source/blender/blenlib/BLI_probing_strategies.hh @@ -21,8 +21,8 @@ * \ingroup bli * * This file implements different probing strategies. Those can be used by different hash table - * implementations like BLI::Set and BLI::Map. A probing strategy produces a sequence of values - * based on an initial hash value. + * implementations like blender::Set and blender::Map. A probing strategy produces a sequence of + * values based on an initial hash value. * * A probing strategy has to implement the following methods: * - Constructor(uint32_t hash): Start a new probing sequence based on the given hash. @@ -56,7 +56,7 @@ #include "BLI_sys_types.h" -namespace BLI { +namespace blender { /** * The simplest probing strategy. It's bad in most cases, because it produces clusters in the hash @@ -245,6 +245,6 @@ using DefaultProbingStrategy = PythonProbingStrategy<>; // clang-format on -} // namespace BLI +} // namespace blender #endif /* __BLI_PROBING_STRATEGIES_HH__ */ diff --git a/source/blender/blenlib/BLI_set.hh b/source/blender/blenlib/BLI_set.hh index d991c97a629..5bdf99360cb 100644 --- a/source/blender/blenlib/BLI_set.hh +++ b/source/blender/blenlib/BLI_set.hh @@ -20,15 +20,15 @@ /** \file * \ingroup bli * - * A `BLI::Set<Key>` is an unordered container for unique elements of type `Key`. It is designed to - * be a more convenient and efficient replacement for `std::unordered_set`. All core operations - * (add, remove and contains) can be done in O(1) amortized expected time. + * A `blender::Set<Key>` is an unordered container for unique elements of type `Key`. It is + * designed to be a more convenient and efficient replacement for `std::unordered_set`. All core + * operations (add, remove and contains) can be done in O(1) amortized expected time. * - * In most cases, your default choice for a hash set in Blender should be `BLI::Set`. + * In most cases, your default choice for a hash set in Blender should be `blender::Set`. * - * BLI::Set is implemented using open addressing in a slot array with a power-of-two size. Every - * slot is in one of three states: empty, occupied or removed. If a slot is occupied, it contains - * an instance of the key type. + * blender::Set is implemented using open addressing in a slot array with a power-of-two size. + * Every slot is in one of three states: empty, occupied or removed. If a slot is occupied, it + * contains an instance of the key type. * * Benchmarking and comparing hash tables is hard, because many factors influence the result. The * performance of a hash table depends on the combination of the hash function, probing strategy, @@ -37,7 +37,7 @@ * points that allow it to be optimized for a specific use case. * * A rudimentary benchmark can be found in BLI_set_test.cc. The results of that benchmark are - * there as well. The numbers show that in this specific case BLI::Set outperforms + * there as well. The numbers show that in this specific case blender::Set outperforms * std::unordered_set consistently by a good amount. * * Some noteworthy information: @@ -59,7 +59,7 @@ * - The method names don't follow the std::unordered_set names in many cases. Searching for such * names in this file will usually let you discover the new name. * - There is a StdUnorderedSetWrapper class, that wraps std::unordered_set and gives it the same - * interface as BLI::Set. This is useful for benchmarking. + * interface as blender::Set. This is useful for benchmarking. * * Possible Improvements: * - Use a branchless loop over slots in grow function (measured ~10% performance improvement when @@ -78,7 +78,7 @@ #include "BLI_probing_strategies.hh" #include "BLI_set_slots.hh" -namespace BLI { +namespace blender { template< /** Type of the elements that are stored in this set. It has to be movable. Furthermore, the @@ -684,11 +684,12 @@ class Set { }; /** - * A wrapper for std::unordered_set with the API of BLI::Set. This can be used for benchmarking. + * A wrapper for std::unordered_set with the API of blender::Set. This can be used for + * benchmarking. */ template<typename Key> class StdUnorderedSetWrapper { private: - using SetType = std::unordered_set<Key, BLI::DefaultHash<Key>>; + using SetType = std::unordered_set<Key, blender::DefaultHash<Key>>; SetType m_set; public: @@ -763,6 +764,6 @@ template<typename Key> class StdUnorderedSetWrapper { } }; -} // namespace BLI +} // namespace blender #endif /* __BLI_SET_HH__ */ diff --git a/source/blender/blenlib/BLI_set_slots.hh b/source/blender/blenlib/BLI_set_slots.hh index 21493524bd8..15f56f2450e 100644 --- a/source/blender/blenlib/BLI_set_slots.hh +++ b/source/blender/blenlib/BLI_set_slots.hh @@ -20,7 +20,7 @@ /** \file * \ingroup bli * - * This file contains different slot types that are supposed to be used with BLI::Set. + * This file contains different slot types that are supposed to be used with blender::Set. * * Every slot type has to be able to hold a value of the Key type and state information. * A set slot has three possible states: empty, occupied and removed. @@ -35,7 +35,7 @@ #include "BLI_memory_utils.hh" #include "BLI_string_ref.hh" -namespace BLI { +namespace blender { /** * The simplest possible set slot. It stores the slot state and the optional key instance in @@ -410,6 +410,6 @@ template<typename Key> struct DefaultSetSlot<Key *> { using type = IntrusiveSetSlot<Key *, PointerKeyInfo<Key *>>; }; -} // namespace BLI +} // namespace blender #endif /* __BLI_SET_SLOTS_HH__ */ diff --git a/source/blender/blenlib/BLI_stack.hh b/source/blender/blenlib/BLI_stack.hh index 4645535876d..81b8b192efd 100644 --- a/source/blender/blenlib/BLI_stack.hh +++ b/source/blender/blenlib/BLI_stack.hh @@ -20,7 +20,7 @@ /** \file * \ingroup bli * - * A `BLI::Stack<T>` is a dynamically growing FILO (first-in, last-out) data structure. It is + * A `blender::Stack<T>` is a dynamically growing FILO (first-in, last-out) data structure. It is * designed to be a more convenient and efficient replacement for `std::stack`. * * The improved efficiency is mainly achieved by supporting small buffer optimization. As long as @@ -34,8 +34,8 @@ * when it grows. This stack implementation does not have to copy all previously pushed elements * when it grows. * - * BLI::Stack is implemented using a double linked list of chunks. Each chunk contains an array of - * elements. The chunk size increases exponentially with every new chunk that is required. The + * blender::Stack is implemented using a double linked list of chunks. Each chunk contains an array + * of elements. The chunk size increases exponentially with every new chunk that is required. The * lowest chunk, i.e. the one that is used for the first few pushed elements, is embedded into the * stack. */ @@ -44,7 +44,7 @@ #include "BLI_array_ref.hh" #include "BLI_memory_utils.hh" -namespace BLI { +namespace blender { /** * A StackChunk references a contiguous memory buffer. Multiple StackChunk instances are linked in @@ -385,6 +385,6 @@ class Stack { } }; -} /* namespace BLI */ +} /* namespace blender */ #endif /* __BLI_STACK_HH__ */ diff --git a/source/blender/blenlib/BLI_string_ref.hh b/source/blender/blenlib/BLI_string_ref.hh index 6a569bee1aa..3c670c4f2b8 100644 --- a/source/blender/blenlib/BLI_string_ref.hh +++ b/source/blender/blenlib/BLI_string_ref.hh @@ -20,13 +20,13 @@ /** \file * \ingroup bli * - * A `BLI::StringRef` references a const char array owned by someone else. It is just a pointer and - * a size. Since the memory is not owned, StringRef should not be used to transfer ownership of the - * string. The data referenced by a StringRef cannot be mutated through it. + * A `blender::StringRef` references a const char array owned by someone else. It is just a pointer + * and a size. Since the memory is not owned, StringRef should not be used to transfer ownership of + * the string. The data referenced by a StringRef cannot be mutated through it. * * A StringRef is NOT null-terminated. This makes it much more powerful within C++, because we can * also cut off parts of the end without creating a copy. When interfacing with C code that expects - * null-terminated strings, `BLI::StringRefNull` can be used. It is essentially the same as + * null-terminated strings, `blender::StringRefNull` can be used. It is essentially the same as * StringRef, but with the restriction that the string has to be null-terminated. * * Whenever possible, string parameters should be of type StringRef and the string return type @@ -34,7 +34,7 @@ * return it when the string exists only in the scope of the function. This convention makes * functions usable in the most contexts. * - * BLI::StringRef vs. std::string_view: + * blender::StringRef vs. std::string_view: * Both types are certainly very similar. The main benefit of using StringRef in Blender is that * this allows us to add convenience methods at any time. Especially, when doing a lot of string * manipulation, this helps to keep the code clean. Furthermore, we need StringRefNull anyway, @@ -49,7 +49,7 @@ #include "BLI_array_ref.hh" #include "BLI_utildefines.h" -namespace BLI { +namespace blender { class StringRef; @@ -345,6 +345,6 @@ inline StringRef StringRefBase::substr(uint start, uint size) const return StringRef(m_data + start, size); } -} // namespace BLI +} // namespace blender #endif /* __BLI_STRING_REF_HH__ */ diff --git a/source/blender/blenlib/BLI_timeit.hh b/source/blender/blenlib/BLI_timeit.hh index e9f121ec654..711a7f16ab4 100644 --- a/source/blender/blenlib/BLI_timeit.hh +++ b/source/blender/blenlib/BLI_timeit.hh @@ -23,7 +23,7 @@ #include "BLI_sys_types.h" -namespace BLI { +namespace blender { namespace Timeit { using Clock = std::chrono::steady_clock; @@ -55,8 +55,8 @@ class ScopedTimer { }; } // namespace Timeit -} // namespace BLI +} // namespace blender -#define SCOPED_TIMER(name) BLI::Timeit::ScopedTimer scoped_timer(name) +#define SCOPED_TIMER(name) blender::Timeit::ScopedTimer scoped_timer(name) #endif /* __BLI_TIMEIT_HH__ */ diff --git a/source/blender/blenlib/BLI_utility_mixins.hh b/source/blender/blenlib/BLI_utility_mixins.hh index 31d28792865..61444e36725 100644 --- a/source/blender/blenlib/BLI_utility_mixins.hh +++ b/source/blender/blenlib/BLI_utility_mixins.hh @@ -21,7 +21,7 @@ #ifndef __BLI_UTILITY_MIXINS_HH__ #define __BLI_UTILITY_MIXINS_HH__ -namespace BLI { +namespace blender { /** * A type that inherits from NonCopyable cannot be copied anymore. @@ -53,6 +53,6 @@ class NonMovable { NonMovable &operator=(const NonMovable &other) = default; }; -} // namespace BLI +} // namespace blender #endif /* __BLI_UTILITY_MIXINS_HH__ */ diff --git a/source/blender/blenlib/BLI_vector.hh b/source/blender/blenlib/BLI_vector.hh index 052cee23028..8042a2a554e 100644 --- a/source/blender/blenlib/BLI_vector.hh +++ b/source/blender/blenlib/BLI_vector.hh @@ -20,7 +20,7 @@ /** \file * \ingroup bli * - * A `BLI::Vector<T>` is a dynamically growing contiguous array for values of type T. It is + * A `blender::Vector<T>` is a dynamically growing contiguous array for values of type T. It is * designed to be a more convenient and efficient replacement for `std::vector`. Note that the term * "vector" has nothing to do with a vector from computer graphics here. * @@ -31,10 +31,10 @@ * * The improved efficiency is mainly achieved by supporting small buffer optimization. As long as * the number of elements in the vector does not become larger than InlineBufferCapacity, no memory - * allocation is done. As a consequence, iterators are invalidated when a BLI::Vector is moved + * allocation is done. As a consequence, iterators are invalidated when a blender::Vector is moved * (iterators of std::vector remain valid when the vector is moved). * - * `BLI::Vector` should be your default choice for a vector data structure in Blender. + * `blender::Vector` should be your default choice for a vector data structure in Blender. */ #include <algorithm> @@ -55,7 +55,7 @@ #include "MEM_guardedalloc.h" -namespace BLI { +namespace blender { template< /** @@ -143,7 +143,7 @@ class Vector { { this->reserve(size); this->increase_size_by_unchecked(size); - BLI::uninitialized_fill_n(m_begin, size, value); + blender::uninitialized_fill_n(m_begin, size, value); } /** @@ -164,7 +164,7 @@ class Vector { uint size = values.size(); this->reserve(size); this->increase_size_by_unchecked(size); - BLI::uninitialized_copy_n(values.data(), size, m_begin); + blender::uninitialized_copy_n(values.data(), size, m_begin); } /** @@ -456,7 +456,7 @@ class Vector { void append_n_times(const T &value, uint n) { this->reserve(this->size() + n); - BLI::uninitialized_fill_n(m_end, n, value); + blender::uninitialized_fill_n(m_end, n, value); this->increase_size_by_unchecked(n); } @@ -511,7 +511,7 @@ class Vector { void extend_unchecked(const T *start, uint amount) { BLI_assert(m_begin + amount <= m_capacity_end); - BLI::uninitialized_copy_n(start, amount, m_end); + blender::uninitialized_copy_n(start, amount, m_end); m_end += amount; UPDATE_VECTOR_SIZE(this); } @@ -844,6 +844,6 @@ class Vector { template<typename T, uint InlineBufferCapacity = 20> using ScopedVector = Vector<T, InlineBufferCapacity, GuardedAllocator>; -} /* namespace BLI */ +} /* namespace blender */ #endif /* __BLI_VECTOR_HH__ */ diff --git a/source/blender/blenlib/BLI_vector_set.hh b/source/blender/blenlib/BLI_vector_set.hh index 7e6a7de6ee6..a3155a3a9fd 100644 --- a/source/blender/blenlib/BLI_vector_set.hh +++ b/source/blender/blenlib/BLI_vector_set.hh @@ -20,8 +20,8 @@ /** \file * \ingroup bli * - * A `BLI::VectorSet<Key>` is an ordered container for elements of type `Key`. It has the same - * interface as `BLI::Set` with the following extensions: + * A `blender::VectorSet<Key>` is an ordered container for elements of type `Key`. It has the same + * interface as `blender::Set` with the following extensions: * - The insertion order of keys is maintained as long as no elements are removed. * - The keys are stored in a contiguous array. * @@ -35,9 +35,9 @@ * the keys are stored in a set. With a VectorSet, one can get an ArrayRef containing all keys * without additional copies. * - * BLI::VectorSet is implemented using open addressing in a slot array with a power-of-two size. - * Other than in BLI::Set, a slot does not contain the key though. Instead it only contains an - * index into an array of keys that is stored separately. + * blender::VectorSet is implemented using open addressing in a slot array with a power-of-two + * size. Other than in blender::Set, a slot does not contain the key though. Instead it only + * contains an index into an array of keys that is stored separately. * * Some noteworthy information: * - Key must be a movable type. @@ -66,7 +66,7 @@ #include "BLI_probing_strategies.hh" #include "BLI_vector_set_slots.hh" -namespace BLI { +namespace blender { template< /** @@ -752,6 +752,6 @@ class VectorSet { } }; -} // namespace BLI +} // namespace blender #endif /* __BLI_VECTOR_SET_HH__ */ diff --git a/source/blender/blenlib/BLI_vector_set_slots.hh b/source/blender/blenlib/BLI_vector_set_slots.hh index 13d6acb05c5..25148866b6c 100644 --- a/source/blender/blenlib/BLI_vector_set_slots.hh +++ b/source/blender/blenlib/BLI_vector_set_slots.hh @@ -20,7 +20,7 @@ /** \file * \ingroup bli * - * This file contains slot types that are supposed to be used with BLI::VectorSet. + * This file contains slot types that are supposed to be used with blender::VectorSet. * * Every slot type has to be able to hold an integer index and state information. * A vector set slot has three possible states: empty, occupied and removed. @@ -39,7 +39,7 @@ #include "BLI_sys_types.h" -namespace BLI { +namespace blender { /** * The simplest possible vector set slot. It stores the index and state in a signed integer. If the @@ -166,6 +166,6 @@ template<typename Key> struct DefaultVectorSetSlot { using type = SimpleVectorSetSlot<Key>; }; -} // namespace BLI +} // namespace blender #endif /* __BLI_VECTOR_SET_SLOTS_HH__ */ diff --git a/source/blender/blenlib/intern/BLI_index_range.cc b/source/blender/blenlib/intern/BLI_index_range.cc index 0fa87cf854d..31b969ec0b3 100644 --- a/source/blender/blenlib/intern/BLI_index_range.cc +++ b/source/blender/blenlib/intern/BLI_index_range.cc @@ -22,7 +22,7 @@ #include "BLI_index_range.hh" #include "BLI_vector.hh" -namespace BLI { +namespace blender { static Vector<Array<uint, 0, RawAllocator>, 1, RawAllocator> arrays; static uint current_array_size = 0; @@ -57,4 +57,4 @@ ArrayRef<uint> IndexRange::as_array_ref() const return ArrayRef<uint>(current_array + m_start, m_size); } -} // namespace BLI +} // namespace blender diff --git a/source/blender/blenlib/intern/dot_export.cc b/source/blender/blenlib/intern/dot_export.cc index 96de4056fc5..f08fb02ec21 100644 --- a/source/blender/blenlib/intern/dot_export.cc +++ b/source/blender/blenlib/intern/dot_export.cc @@ -18,7 +18,7 @@ #include "BLI_dot_export.hh" -namespace BLI { +namespace blender { namespace DotExport { /* Graph Building @@ -302,4 +302,4 @@ NodeWithSocketsRef::NodeWithSocketsRef(Node &node, } } // namespace DotExport -} // namespace BLI +} // namespace blender diff --git a/source/blender/blenlib/intern/timeit.cc b/source/blender/blenlib/intern/timeit.cc index bab8fd81746..7938784da67 100644 --- a/source/blender/blenlib/intern/timeit.cc +++ b/source/blender/blenlib/intern/timeit.cc @@ -16,7 +16,7 @@ #include "BLI_timeit.hh" -namespace BLI { +namespace blender { namespace Timeit { void print_duration(Nanoseconds duration) @@ -33,4 +33,4 @@ void print_duration(Nanoseconds duration) } } // namespace Timeit -} // namespace BLI +} // namespace blender diff --git a/source/blender/depsgraph/intern/builder/deg_builder_rna.cc b/source/blender/depsgraph/intern/builder/deg_builder_rna.cc index 9fa663b9b6d..94f58427251 100644 --- a/source/blender/depsgraph/intern/builder/deg_builder_rna.cc +++ b/source/blender/depsgraph/intern/builder/deg_builder_rna.cc @@ -365,7 +365,7 @@ RNANodeIdentifier RNANodeQuery::construct_node_identifier(const PointerRNA *ptr, RNANodeQueryIDData *RNANodeQuery::ensure_id_data(const ID *id) { unique_ptr<RNANodeQueryIDData> &id_data = id_data_map_.lookup_or_add( - id, [&]() { return BLI::make_unique<RNANodeQueryIDData>(id); }); + id, [&]() { return blender::make_unique<RNANodeQueryIDData>(id); }); return id_data.get(); } diff --git a/source/blender/depsgraph/intern/depsgraph_type.h b/source/blender/depsgraph/intern/depsgraph_type.h index 7016d07ae72..f6901395897 100644 --- a/source/blender/depsgraph/intern/depsgraph_type.h +++ b/source/blender/depsgraph/intern/depsgraph_type.h @@ -53,13 +53,13 @@ struct CustomData_MeshMasks; namespace DEG { /* Commonly used types. */ -using BLI::ArrayRef; -using BLI::Map; -using BLI::Set; -using BLI::StringRef; -using BLI::StringRefNull; -using BLI::Vector; -using BLI::VectorSet; +using blender::ArrayRef; +using blender::Map; +using blender::Set; +using blender::StringRef; +using blender::StringRefNull; +using blender::Vector; +using blender::VectorSet; using std::deque; using std::map; using std::pair; diff --git a/source/blender/depsgraph/intern/node/deg_node_component.h b/source/blender/depsgraph/intern/node/deg_node_component.h index ca37401d200..2d13300d69f 100644 --- a/source/blender/depsgraph/intern/node/deg_node_component.h +++ b/source/blender/depsgraph/intern/node/deg_node_component.h @@ -206,7 +206,7 @@ void deg_register_component_depsnodes(); } // namespace DEG -namespace BLI { +namespace blender { template<> struct DefaultHash<DEG::ComponentNode::OperationIDKey> { uint32_t operator()(const DEG::ComponentNode::OperationIDKey &key) const @@ -219,4 +219,4 @@ template<> struct DefaultHash<DEG::ComponentNode::OperationIDKey> { } }; -} // namespace BLI +} // namespace blender diff --git a/source/blender/freestyle/intern/blender_interface/BlenderStrokeRenderer.h b/source/blender/freestyle/intern/blender_interface/BlenderStrokeRenderer.h index ee29519c849..21505f47ae2 100644 --- a/source/blender/freestyle/intern/blender_interface/BlenderStrokeRenderer.h +++ b/source/blender/freestyle/intern/blender_interface/BlenderStrokeRenderer.h @@ -56,7 +56,7 @@ class BlenderStrokeRenderer : public StrokeRenderer { { } vector<StrokeRep *> strokes; - BLI::Map<Material *, int> materials; + blender::Map<Material *, int> materials; int totvert; int totedge; int totpoly; diff --git a/source/blender/functions/FN_cpp_type.hh b/source/blender/functions/FN_cpp_type.hh index df6da7a3f47..d580ce54f1d 100644 --- a/source/blender/functions/FN_cpp_type.hh +++ b/source/blender/functions/FN_cpp_type.hh @@ -72,9 +72,9 @@ namespace FN { -using BLI::IndexMask; -using BLI::StringRef; -using BLI::StringRefNull; +using blender::IndexMask; +using blender::StringRef; +using blender::StringRefNull; class CPPType { public: @@ -538,7 +538,7 @@ template<typename T> void construct_default_cb(void *ptr) } template<typename T> void construct_default_n_cb(void *ptr, uint n) { - BLI::default_construct_n((T *)ptr, n); + blender::default_construct_n((T *)ptr, n); } template<typename T> void construct_default_indices_cb(void *ptr, IndexMask index_mask) { @@ -551,7 +551,7 @@ template<typename T> void destruct_cb(void *ptr) } template<typename T> void destruct_n_cb(void *ptr, uint n) { - BLI::destruct_n((T *)ptr, n); + blender::destruct_n((T *)ptr, n); } template<typename T> void destruct_indices_cb(void *ptr, IndexMask index_mask) { @@ -583,11 +583,11 @@ void copy_to_initialized_indices_cb(const void *src, void *dst, IndexMask index_ template<typename T> void copy_to_uninitialized_cb(const void *src, void *dst) { - BLI::uninitialized_copy_n((T *)src, 1, (T *)dst); + blender::uninitialized_copy_n((T *)src, 1, (T *)dst); } template<typename T> void copy_to_uninitialized_n_cb(const void *src, void *dst, uint n) { - BLI::uninitialized_copy_n((T *)src, n, (T *)dst); + blender::uninitialized_copy_n((T *)src, n, (T *)dst); } template<typename T> void copy_to_uninitialized_indices_cb(const void *src, void *dst, IndexMask index_mask) @@ -608,7 +608,7 @@ template<typename T> void relocate_to_initialized_cb(void *src, void *dst) } template<typename T> void relocate_to_initialized_n_cb(void *src, void *dst, uint n) { - BLI::initialized_relocate_n((T *)src, n, (T *)dst); + blender::initialized_relocate_n((T *)src, n, (T *)dst); } template<typename T> void relocate_to_initialized_indices_cb(void *src, void *dst, IndexMask index_mask) @@ -632,7 +632,7 @@ template<typename T> void relocate_to_uninitialized_cb(void *src, void *dst) } template<typename T> void relocate_to_uninitialized_n_cb(void *src, void *dst, uint n) { - BLI::uninitialized_relocate_n((T *)src, n, (T *)dst); + blender::uninitialized_relocate_n((T *)src, n, (T *)dst); } template<typename T> void relocate_to_uninitialized_indices_cb(void *src, void *dst, IndexMask index_mask) diff --git a/source/blender/functions/intern/cpp_types.cc b/source/blender/functions/intern/cpp_types.cc index 3435c9c6eca..6e548d65192 100644 --- a/source/blender/functions/intern/cpp_types.cc +++ b/source/blender/functions/intern/cpp_types.cc @@ -26,15 +26,15 @@ namespace FN { MAKE_CPP_TYPE(bool, bool) MAKE_CPP_TYPE(float, float) -MAKE_CPP_TYPE(float3, BLI::float3) -MAKE_CPP_TYPE(float4x4, BLI::float4x4) +MAKE_CPP_TYPE(float3, blender::float3) +MAKE_CPP_TYPE(float4x4, blender::float4x4) MAKE_CPP_TYPE(int32, int32_t) MAKE_CPP_TYPE(uint32, uint32_t) MAKE_CPP_TYPE(uint8, uint8_t) -MAKE_CPP_TYPE(Color4f, BLI::Color4f) -MAKE_CPP_TYPE(Color4b, BLI::Color4b) +MAKE_CPP_TYPE(Color4f, blender::Color4f) +MAKE_CPP_TYPE(Color4b, blender::Color4b) MAKE_CPP_TYPE(string, std::string) diff --git a/source/blender/modifiers/intern/MOD_mask.cc b/source/blender/modifiers/intern/MOD_mask.cc index c6de980d674..2fe3195583a 100644 --- a/source/blender/modifiers/intern/MOD_mask.cc +++ b/source/blender/modifiers/intern/MOD_mask.cc @@ -66,12 +66,12 @@ #include "BLI_listbase_wrapper.hh" #include "BLI_vector.hh" -using BLI::Array; -using BLI::ArrayRef; -using BLI::IndexRange; -using BLI::ListBaseWrapper; -using BLI::MutableArrayRef; -using BLI::Vector; +using blender::Array; +using blender::ArrayRef; +using blender::IndexRange; +using blender::ListBaseWrapper; +using blender::MutableArrayRef; +using blender::Vector; static void requiredDataMask(Object *UNUSED(ob), ModifierData *UNUSED(md), diff --git a/source/blender/modifiers/intern/MOD_simulation.cc b/source/blender/modifiers/intern/MOD_simulation.cc index 5ccf945b5a6..d55900dc7a9 100644 --- a/source/blender/modifiers/intern/MOD_simulation.cc +++ b/source/blender/modifiers/intern/MOD_simulation.cc @@ -64,7 +64,7 @@ #include "MOD_modifiertypes.h" #include "MOD_ui_common.h" -using BLI::float3; +using blender::float3; static void updateDepsgraph(ModifierData *md, const ModifierUpdateDepsgraphContext *ctx) { |