Replace coral::callable with coral::closure #9

kayomn · 2023-02-23T16:11:17+01:00

kayomn commented

2023-02-23 16:11:17 +01:00

Deprecates and removes coral::callable for handling type erasure of functions and functors in favor of coral::closure.

As mentioned in #7, this has a number of benefits.

Memory layout drops from 32 to 16 bytes on x86-64 and 8 bytes under 32-bit compilation.
No more redundant copying of bits before they are executed.
Reduced copying and less L-values will give the compiler an easier time optimizing out the pointer indirections.

client.resources().read_file("myfile.txt", [&](coral::reader & file) {
	...
});

The new preferred mechanism for creating functors that coral::closure will accept is to pass a direct R-value to the function so that the potential for memory corruption is reduced. For most use cases, this has - and will continue to be - the standard when using functions with closures.

auto do_thing {[=](int value) {
	...
}};

my_list.for_each(&do_thing);

To remain compatible with the previous functor erasure semantics, a compatibility constructor is supplied that accepts a functor pointer. This still modifies the callsite slightly, however the risk of not making value-to-pointer semantics explicit far outweighed the value of accepting and L-value reference without warning.

Closes #7.

Deprecates and removes `coral::callable` for handling type erasure of functions and functors in favor of `coral::closure`. As mentioned in #7, this has a number of benefits. 1. Memory layout drops from 32 to 16 bytes on x86-64 and 8 bytes under 32-bit compilation. 2. No more redundant copying of bits before they are executed. 3. Reduced copying and less L-values will give the compiler an easier time optimizing out the pointer indirections. ```cpp client.resources().read_file("myfile.txt", [&](coral::reader & file) { ... }); ``` The new preferred mechanism for creating functors that `coral::closure` will accept is to pass a direct R-value to the function so that the potential for memory corruption is reduced. For most use cases, this has - and will continue to be - the standard when using functions with closures. ```cpp auto do_thing {[=](int value) { ... }}; my_list.for_each(&do_thing); ``` To remain compatible with the previous functor erasure semantics, a compatibility constructor is supplied that accepts a functor pointer. This still modifies the callsite slightly, however the risk of not making value-to-pointer semantics explicit far outweighed the value of accepting and L-value reference without warning. Closes #7.

kayomn added the

performance

label 2023-02-23 16:11:17 +01:00

kayomn self-assigned this 2023-02-23 16:11:17 +01:00

kayomn added 2 commits 2023-02-23 16:11:17 +01:00