actually properly mention reference counting in src/README.md

This commit is contained in:
dzaima 2024-05-20 01:28:49 +03:00
parent f02f882801
commit 33f784106d

View File

@ -66,11 +66,11 @@ src/
## Base ## Base
`B` represents any BQN object. It's a 64-bit NaN-boxed value; some of the NaN-boxed values, determined by the top 16 bits, are heap-allocated (i.e. low 48 bits are a `Value*`), some aren't: `B`, a 64-bit NaN-boxed value, represents any BQN object. Some of the NaN-boxed types, determined by the top 16 bits, are heap-allocated (i.e. low 48 bits are a `Value*`), some aren't. The heap-allocated ones are reference-counted.
```C ```C
Type checks (all are safe to execute on any B object): Type checks (all are safe to execute on any B object):
test tag description heap-allocated test tag description heap-allocated
isF64(x) F64_TAG a number no isF64(x) N/A a number no
isC32(x) C32_TAG a character no isC32(x) C32_TAG a character no
isAtm(x) [many] !isArr(x) depends isAtm(x) [many] !isArr(x) depends
isVal(x) [many] heap-allocated yes isVal(x) [many] heap-allocated yes
@ -148,7 +148,7 @@ type field for heap-allocated objects:
See src/h.h for more basic operations See src/h.h for more basic operations
``` ```
An object can be allocated with `mm_alloc(sizeInBytes, t_something)`. The returned object starts with the structure of `Value`, so custom data must be after that. `mm_free` can be used to force-free an object regardless of its reference count. An object can be allocated with `mm_alloc(sizeInBytes, t_something)`. The returned object starts with the structure of `Value`, so custom data must be after that. `mm_free` can be used to force-free a heap-allocated object regardless of its reference count.
Any such allocation is guaranteed to have at least 1024 bytes readable & writable both before & after the allocation, though of course the read values should not affect any visible behavior, and writes need to write back exactly the data that was there before. Any such allocation is guaranteed to have at least 1024 bytes readable & writable both before & after the allocation, though of course the read values should not affect any visible behavior, and writes need to write back exactly the data that was there before.