Blender
V3.3
|
#include "BLI_hash.hh"
#include "BLI_index_mask.hh"
#include "BLI_map.hh"
#include "BLI_math_base.h"
#include "BLI_string_ref.hh"
#include "BLI_utility_mixins.hh"
Go to the source code of this file.
Classes | |
struct | blender::CPPTypeParam< T, Flags > |
class | blender::CPPType |
struct | blender::CPPType::type_tag< T > |
Namespaces | |
blender | |
Macros | |
#define | BUFFER_FOR_CPP_TYPE_VALUE(type, variable_name) |
Enumerations | |
enum class | CPPTypeFlags { None = 0 , Hashable = 1 << 0 , Printable = 1 << 1 , EqualityComparable = 1 << 2 , BasicType = Hashable | Printable | EqualityComparable } |
The CPPType
class allows working with arbitrary C++ types in a generic way. An instance of #CPPType wraps exactly one type like int
or std::string
.
With #CPPType one can write generic data structures and algorithms. That is similar to what C++ templates allow. The difference is that when using templates, the types have to be known at compile time and the code has to be instantiated multiple times. On the other hand, when using #CPPType, the data type only has to be known at run-time, and the code only has to be compiled once. Whether #CPPType or classic c++ templates should be used depends on the context:
Under some circumstances, #CPPType serves a similar role as #std::type_info. However, #CPPType has much more utility because it contains methods for actually working with instances of the type.
Every type has a size and an alignment. Every function dealing with C++ types in a generic way, has to make sure that alignment rules are followed. The methods provided by a #CPPType instance will check for correct alignment as well.
Every type has a name that is for debugging purposes only. It should not be used as identifier.
To check if two instances of #CPPType represent the same type, only their pointers have to be compared. Any C++ type has at most one corresponding #CPPType instance.
A #CPPType instance comes with many methods that allow dealing with types in a generic way. Most methods come in three variants. Using the default-construct methods as an example:
default_construct(void *ptr)
: Constructs a single instance of that type at the given pointer.default_construct_n(void *ptr, int64_t n)
: Constructs n instances of that type in an array that starts at the given pointer.default_construct_indices(void *ptr, IndexMask mask)
: Constructs multiple instances of that type in an array that starts at the given pointer. Only the indices referenced by mask
will by constructed.In some cases default-construction does nothing (e.g. for trivial types like int). The default_value
method provides some default value anyway that can be copied instead. What the default value is, depends on the type. Usually it is something like 0 or an empty string.
Concepts like inheritance are currently not captured by this system. This is not because it is not possible, but because it was not necessary to add this complexity yet.
One could also implement CPPType itself using virtual methods and a child class for every wrapped type. However, the approach used now with explicit function pointers to works better. Here are some reasons:
default_construct
that operate on a single instance have to be fast. Even this one necessary indirection using function pointers adds a lot of overhead. If all methods were virtual, there would be a second level of indirection that increases the overhead even more.Definition in file BLI_cpp_type.hh.
Definition at line 785 of file BLI_cpp_type.hh.
|
strong |
Different types support different features. Features like copy constructability can be detected automatically easily. For some features this is harder as of C++17. Those have flags in this enum and need to be determined by the programmer.
Enumerator | |
---|---|
None | |
Hashable | |
Printable | |
EqualityComparable | |
BasicType |
Definition at line 85 of file BLI_cpp_type.hh.