#include "BLI_hash.hh"
#include "BLI_index_mask.hh"
#include "BLI_map.hh"
#include "BLI_math_base.h"
#include "BLI_parameter_pack_utils.hh"
#include "BLI_string_ref.hh"
#include "BLI_utility_mixins.hh"

Classes
class	blender::CPPType

Namespaces
namespace	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 , IdentityDefaultValue = 1 << 3 , BasicType = Hashable \| Printable \| EqualityComparable }

Functions
void	blender::register_cpp_types ()

Detailed Description

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:

If the data type is not known at run-time, #CPPType should be used.
If the data type is known to be one of a few, it depends on how performance sensitive the code is.
- If it it's a small hot loop, a template can be used to optimize for every type (at the cost of longer compile time, a larger binary and the complexity that comes from using templates).
- If the code is not performance sensitive, it usually makes sense to use #CPPType instead.
Sometimes a combination can make sense. Optimized code can be generated at compile-time for some types, while there is a fallback code path using #CPPType for all other types. #CPPType::to_static_type allows dispatching between both versions based on the type.

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, const 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.

Implementation Considerations

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:

If CPPType would be inherited once for every used C++ type, we would get a lot of classes that would only be instanced once each.
Methods like 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.
If it becomes necessary, we could pass the function pointers to C functions more easily than pointers to virtual member functions.

Definition in file BLI_cpp_type.hh.

Macro Definition Documentation

◆ BUFFER_FOR_CPP_TYPE_VALUE

#define BUFFER_FOR_CPP_TYPE_VALUE	(		type,
			variable_name )

Value:

  blender::DynamicStackBuffer<64, 64> stack_buffer_for_##variable_name((type).size(), \
                                                                       (type).alignment()); \
  void *variable_name = stack_buffer_for_##variable_name.buffer();

Definition at line 779 of file BLI_cpp_type.hh.

Referenced by blender::bke::CurvesGeometry::adapt_domain(), blender::bke::adapt_mesh_attribute_domain(), blender::fn::multi_function::tests::GenericAppendFunction::call(), blender::ed::space_node::create_inspection_string_for_default_socket_value(), blender::ed::space_node::create_inspection_string_for_generic_value(), blender::GVectorArray::extend(), blender::bke::AttributeFieldInput::get_varray_for_context(), blender::bke::EvaluateOnDomainInput::get_varray_for_context(), blender::nodes::LazyFunctionForReduceForeachGeometryElement::handle_generation_items_group(), blender::fn::make_field_constant_if_possible(), blender::ed::mesh::set_attribute::mesh_set_attribute_exec(), blender::nodes::node_geo_sample_index_cc::node_geo_exec(), blender::geometry::reverse_order(), blender::ed::curves::set_attribute_exec(), blender::ed::curves::set_attribute_invoke(), blender::GVMutableArrayImpl::set_by_copy(), and blender::ed::curves::validate_value().

Enumeration Type Documentation

◆ CPPTypeFlags

enum class CPPTypeFlags

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
IdentityDefaultValue
BasicType

Definition at line 88 of file BLI_cpp_type.hh.

Classes

Namespaces

Macros