Reference counting is implemented by https://talloc.samba.org/talloc/doc/html/group__talloc__ref.html#ga1d70927673b42a6d2e42823307280502 https://talloc.samba.or

Reference counting is implemented by https://talloc.samba.org/talloc/doc/html/group__talloc__ref.html#ga1d70927673b42a6d2e42823307280502 https://talloc.samba.org/talloc/doc/html/group__talloc__ref.... or https://talloc.samba.org/talloc/doc/html/group__talloc__ref.html#ga573831a64a47a33cce8c80bde085e158 https://talloc.samba.org/talloc/doc/html/group__talloc__ref.... (talloc calls this "adding a parent" - note it does do quite a bit more than just incrementing an integer.) You're right that talloc has a memory overhead relative to smart pointers or a free_foo() function; talloc'ing up an int is very inefficient. Note that you can add a talloc-integrated "destructor" at zero marginal cost, so e.g. an array of a million pointers to individually-allocated int's could let talloc manage the vector and free the int's in the destructor. (That is, you can de-talloc part of a talloc'ed memory hierarchy.) Additionally, malloc also has a runtime and memory cost; like talloc's, this cost is high enough to discourage arrays of pointers to individually allocated int's and low enough that it doesn't matter for arrays of int's. The one time I played around with talloc (for a network daemon), I didn't really run into any allocations where I'd hesitate to use talloc but not to use malloc. (I forgot the numbers; a quick Google suggests that talloc adds 96 bytes to malloc's 16 bytes of overhead.) That said, just being disciplined about memory usage seems to work decently well, too. (For expert programmers with good tools, usually; it's a hard problem.)