Yes, exactly as e.g. BLI_file_attributes
is handled.
Note that other functions, like BLI_expand_tilde
, are fully defined in the .mm
file for OSX, and not defined at all in the C file for this platform.
Since these new functions also share very…
This is indeed expected behavior, the Action ID is used by the Object, not using the Object, so it is unaffected by the remapping of usages from old object to new one.
Couldn't this use instead cob = BLI_ghash_popkey(collection->runtime.gobject_hash, ob, NULL);
? Then there is no need for an extra lookup below in the call to collection_gobject_hash_remove_object(collection, ob);
Agree with @Sergey, also found some more points to address, as noted below.
This may leak in case ob_new
is NULL but cob
is not, depending on calling code...
This is not a proper English sentence... ;)
These asserts remove almost all benefit of using the mapping for debug builds... and are totally redundant if BLI_ASSERT_COLLECION_GOBJECT_HASH_IS_VALID
is actually checking things? Same for the others below.
I would actually move this check as part of collection_gobject_hash_ensure
itself? Would be much less verbose, and make more sense to me?