The main issue of 'type-less' standard C allocations is that there is no check on
allocated type possible.
This is a serious source of annoyance (and crashes) when making some
low-level structs non-trivial, as tracking down all usages of these
structs in higher-level other structs and their allocation is... really
painful.
MEM_[cm]allocN<T> templates on the other hand do check that the
given type is trivial, at build time (static assert), which makes such issue...
trivial to catch.
NOTE: New code should strive to use MEM_new (i.e. allocation and
construction) as much as possible, even for trivial PoD types.
Pull Request: https://projects.blender.org/blender/blender/pulls/135626
The general idea is to keep the 'old', C-style MEM_callocN signature, and slowly
replace most of its usages with the new, C++-style type-safer template version.
* `MEM_cnew<T>` allocation version is renamed to `MEM_callocN<T>`.
* `MEM_cnew_array<T>` allocation version is renamed to `MEM_calloc_arrayN<T>`.
* `MEM_cnew<T>` duplicate version is renamed to `MEM_dupallocN<T>`.
Similar templates type-safe version of `MEM_mallocN` will be added soon
as well.
Following discussions in !134452.
NOTE: For now static type checking in `MEM_callocN` and related are slightly
different for Windows MSVC. This compiler seems to consider structs using the
`DNA_DEFINE_CXX_METHODS` macro as non-trivial (likely because their default
copy constructors are deleted). So using checks on trivially
constructible/destructible instead on this compiler/system.
Pull Request: https://projects.blender.org/blender/blender/pulls/134771
Add a dedicated callback to duplicate the key for each type.
Keeping changes to the minimum necessary ones, the whole code and data
structure could use a serious update using C++ features, but this would
be totally out of scope of this fix.
Pull Request: https://projects.blender.org/blender/blender/pulls/134523
The general idea is to store an array of (type, data) pointers of all
PointerRNA ancestors of the current one.
This will help solving cases in our code where the owner (or sometimes
even the owner of the owner) of a random PointerRNA needs to be
accessed. Current solution mainly relies on linear search from the owner
ID, which is sub-optimal at best, and may not even be possible in case a
same data is shared between different owners.
This lead to refactoring quite a bit of existing PointerRNA creation code.
At a high level (i.e. expected usages outside of RNA internals):
* Add `RNA_pointer_create_with_parent` and
`RNA_pointer_create_id_subdata` to create RNA pointers with
ancestors info.
* `RNA_id_pointer_create` and `RNA_main_pointer_create` remain
unchanged, as they should never have ancestors currently.
* Add `RNA_pointer_create_from_ancestor` to re-create a RNA pointer
from the nth ancestor of another PointerRNA.
* Add basic python API to access this new ancestors data.
* Update internal RNA/bpy code to handle ancestors generation in most
common generic cases.
- The most verbose change here is for collection code, as the owner of the
collection property is now passed around, to allow collection items to get
a valid ancestors chain.
Internally:
* `PointerRNA` now has an array of `AncestorPointerRNA` data to store
the ancestors.
* `PointerRNA` now has constructors that take care of setting its data for
most usual cases, including handling of the ancestor array data.
* Pointer type refining has been fully factorized into a small utils,
`rna_pointer_refine`, that is now used from all code doing that operation.
* `rna_pointer_inherit_refine` has been replaced by
`rna_pointer_create_with_ancestors` as the core function taking care of
creating pointers with valid ancestors info.
- Its usage outside of `rna_access` has been essentially reduced to custom
collection lookup callbacks.
Implements #122431.
--------------
Some notes:
* The goal of this commit is _not_ to fully cover all cases creating
PointerRNA that should also store the ancestors' chain info. It only
tackles the most generic code paths (in bpyrna and RNA itself mainly).
The remaining 'missing cases' can be tackle later, as needs be.
* Performances seem to be only marginally affected currently.
* Currently `AncestorPointerRNA` only stores PointerRNA-like data.
This will help `StructPathFunc` callbacks to more efficiently generate
an RNA paths when calling e.g. `RNA_path_from_ID_to_property`, but will
not be enough info to build these paths without these callbacks. And some
cases may still remain fuzzy. We'd have to add thinks like a `PropertyRNA`
pointer, and for RNA collection ones, an index and string identifier, to store
a complete unambiguous 'RNA path' info. This is probably not needed, nor
worth the extra processing and memory footprint, for now.
Pull Request: https://projects.blender.org/blender/blender/pulls/122427
When using clangd or running clang-tidy on headers there are
currently many errors. These are noisy in IDEs, make auto fixes
impossible, and break features like code completion, refactoring
and navigation.
This makes source/blender headers work by themselves, which is
generally the goal anyway. But #includes and forward declarations
were often incomplete.
* Add #includes and forward declarations
* Add IWYU pragma: export in a few places
* Remove some unused #includes (but there are many more)
* Tweak ShaderCreateInfo macros to work better with clangd
Some types of headers still have errors, these could be fixed or
worked around with more investigation. Mostly preprocessor
template headers like NOD_static_types.h.
Note that that disabling WITH_UNITY_BUILD is required for clangd to
work properly, otherwise compile_commands.json does not contain
the information for the relevant source files.
For more details see the developer docs:
https://developer.blender.org/docs/handbook/tooling/clangd/
Pull Request: https://projects.blender.org/blender/blender/pulls/132608
These are useless now that PointerRNA has explicit default values, and
become a problem when real constructors are added to this struct. Simply
use the default empty value initialization instead.
Pull Request: https://projects.blender.org/blender/blender/pulls/130927
Match function and declaration names, picking names based on
consistency with related code & clarity.
Also changes for old conventions, missed in previous cleanups:
- name -> filepath
- tname -> newname
- maxlen -> maxncpy
Clang (at least on OSX) has optimization issues with the pointer
version, which seem to be 'fixed' by using references.
Note that using references here is not a bad thing anyway (none of these
pointers would ever be expected to be NULL).
Pull Request: https://projects.blender.org/blender/blender/pulls/124883
This commit moves generated `RNA_blender.h`, `RNA_prototype.h` and
`RNA_blender_cpp.h` headers to become C++ header files.
It also removes the now useless `RNA_EXTERN_C` defines, and just
directly use the `extern` keyword. We do not need anymore `extern "C"`
declarations here.
Pull Request: https://projects.blender.org/blender/blender/pulls/124469
Previous code would declare properties as `extern PropertyRNA`, but
implement them as type-refined data (e.g. `FloatPropertyRNA`).
This is fully illegal thing, it happened to work 'fine' so far for two
main reasons:
* C-linking does not do type-checks on extern data.
* Code using these publicly exposed data would always use them as
`PorpertyRNA *` pointers, and pass them to RNA API.
However, this (finally !) breaks when trying to move generated
`RNA_property.h` header to C++, since at least MSVC2022 does mangle the
type in the extern'ed symbol name, which makes linking fails epically.
This commit fixes the issue by only declaring `PointerRNA *` pointers in
the headers. These pointers are then defined in each implementation file
(the `rna_xxx_gen.cc` ones), and assinged to the address of a matching
local static variable. These static variables are type-refined, and
actually contain the property definition data.
Pull Request: https://projects.blender.org/blender/blender/pulls/124603
This significantly simplifies memory management, mostly by avoiding
the need to free the memory manually. It may also improve performance,
since std::string has an inline buffer that can prevent heap
allocations and it stores the size.
Pull Request: https://projects.blender.org/blender/blender/pulls/117695
NDEBUG is part of the C standard and disables asserts. Only this will
now be used to decide if asserts are enabled.
DEBUG was a Blender specific define, that has now been removed.
_DEBUG is a Visual Studio define for builds in Debug configuration.
Blender defines this for all platforms. This is still used in a few
places in the draw code, and in external libraries Bullet and Mantaflow.
Pull Request: https://projects.blender.org/blender/blender/pulls/115774
There are a couple of functions that create rna pointers. For example
`RNA_main_pointer_create` and `RNA_pointer_create`. Currently, those
take an output parameter `r_ptr` as last argument. This patch changes
it so that the functions actually return a` PointerRNA` instead of using
the output parameters.
This has a few benefits:
* Output parameters should only be used when there is an actual benefit.
Otherwise, one should default to returning the value.
* It's simpler to use the API in the large majority of cases (note that this
patch reduces the number of lines of code).
* It allows the `PointerRNA` to be const on the call-site, if that is desired.
No performance regression has been measured in production files.
If one of these functions happened to be called in a hot loop where
there is a regression, the solution should be to use an inline function
there which allows the compiler to optimize it even better.
Pull Request: https://projects.blender.org/blender/blender/pulls/111976
Listing the "Blender Foundation" as copyright holder implied the Blender
Foundation holds copyright to files which may include work from many
developers.
While keeping copyright on headers makes sense for isolated libraries,
Blender's own code may be refactored or moved between files in a way
that makes the per file copyright holders less meaningful.
Copyright references to the "Blender Foundation" have been replaced with
"Blender Authors", with the exception of `./extern/` since these this
contains libraries which are more isolated, any changed to license
headers there can be handled on a case-by-case basis.
Some directories in `./intern/` have also been excluded:
- `./intern/cycles/` it's own `AUTHORS` file is planned.
- `./intern/opensubdiv/`.
An "AUTHORS" file has been added, using the chromium projects authors
file as a template.
Design task: #110784
Ref !110783.
A lot of files were missing copyright field in the header and
the Blender Foundation contributed to them in a sense of bug
fixing and general maintenance.
This change makes it explicit that those files are at least
partially copyrighted by the Blender Foundation.
Note that this does not make it so the Blender Foundation is
the only holder of the copyright in those files, and developers
who do not have a signed contract with the foundation still
hold the copyright as well.
Another aspect of this change is using SPDX format for the
header. We already used it for the license specification,
and now we state it for the copyright as well, following the
FAQ:
https://reuse.software/faq/
Adds `rna_path.cc` and `RNA_path.h`.
`rna_access.c` is a quite big file, which makes it rather hard and
inconvenient to navigate. RNA path functions form a nicely coherent unit
that can stand well on it's own, so it makes sense to split them off to
mitigate the problem. Moreover, I was looking into refactoring the quite
convoluted/overloaded `rna_path_parse()`, and found that some C++
features may help greatly with that. So having that code compile in C++
would be helpful to attempt that.
Differential Revision: https://developer.blender.org/D15540
Reviewed by: Brecht Van Lommel, Campbell Barton, Bastien Montagne
After rB9b298cf3dbec, the `StructRNA` declarations can now be accessed via
`RNA prototypes.h`
Also, since all redundated declarations are now removed,
`_WM_MESSAGE_EXTERN_BEGIN` and `_WM_MESSAGE_EXTERN_END` are also no
longer needed.
Differential Revision: https://developer.blender.org/D14342
Lets `makesrna` generate a `RNA_prototypes.h` header with declarations for all
RNA properties. This can be included in regular source files when needing to
reference RNA properties statically.
This solves an issue on MSVC with adding such declarations in functions, like
we used to do. See 800fc17367. Removes any such declarations and the related
FIXME comments.
Reviewed By: campbellbarton, LazyDodo, brecht
Differential Revision: https://developer.blender.org/D13837
Use a shorter/simpler license convention, stops the header taking so
much space.
Follow the SPDX license specification: https://spdx.org/licenses
- C/C++/objc/objc++
- Python
- Shell Scripts
- CMake, GNUmakefile
While most of the source tree has been included
- `./extern/` was left out.
- `./intern/cycles` & `./intern/atomic` are also excluded because they
use different header conventions.
doc/license/SPDX-license-identifiers.txt has been added to list SPDX all
used identifiers.
See P2788 for the script that automated these edits.
Reviewed By: brecht, mont29, sergey
Ref D14069
Some of the message-bus macros are not safe to use in C++. This has come
up before, but no good solution was found. Now @LazyDodo, @HooglyBoogly
and I concluded this is the best duct tape "solution" for the moment.
The message-bus API should address this.
This reverts commit 9cce18a585.
rB9cce18a5858c broke the build in unforeseen ways, not easily fixable.
revert for now, so master will at least build again.
This replaces header include guards with `#pragma once`.
A couple of include guards are not removed yet (e.g. `__RNA_TYPES_H__`),
because they are used in other places.
This patch has been generated by P1561 followed by `make format`.
Differential Revision: https://developer.blender.org/D8466
Note this only changes cases where the variable was declared inside
the for loop. To handle it outside as well is a different challenge.
Differential Revision: https://developer.blender.org/D7320
