Allocation and memory management

[uentity]

Hi @hhenson!

I just noticed your last merged PR #209 and wondering what is the goal that you try to achieve? Do you want to enable creating shared pointers to this in object's constructor?

In terms of creating objects that are supposed to be managed via shared pointers the rule of thumb is to:

1. Make constructors of such objects protected/private, i.e. prohibit calling them directly.
2. Add factory function like create() that would take same args as constructors and return a shared pointer (or any other pointer-like object of our choice).

This approach has many benefits, and besides making code cleaner (avoid having to call make_shared() or make_arena_shared() everywhere) it allows to encapsulate memory management and actually implement advanced techniques behind the scene (like pool allocation).

What do you think?

[hhenson]

Hey A.G. So I love the observations. This is meant to be a first pass attempt to get an arena memory management approach reduce the cost of allocation when creating new graph instances (which happens a lot in maps, etc.). This not a beautiful as I had hoped, but at least should give an indication if this was worth doing or not. Once we have some performance reviews I was going to spend time to clean this up (if this approach to memory management proves worth while). If you feel up to it, feel free to clean this up. Regards Howard

…

On 5 Dec 2025, at 17:14, Alexander Gagarin ***@***.***> wrote: Hi @hhenson <https://github.com/hhenson>! I just noticed your last merged PR #209 <#209> and wondering what is the goal that you try to achieve? Do you want to enable creating shared pointers to this in object's constructor? In terms of creating objects that are supposed to be managed via shared pointers the rule of thumb is to: Make constructors of such objects protected/private, i.e. prohibit calling them directly. Add factory function like create() that would take same args as constructors and return a shared pointer (or any other pointer-like object of our choice). This approach has many benefits, and besides making code cleaner (avoid having to call make_shared() or make_arena_shared() everywhere) it allows to encapsulate memory management and actually implement advanced techniques behind the scene (like pool allocation). What do you think? — Reply to this email directly, view it on GitHub <#210>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AATPELFFFJWADJQWUM54UW34AGAL5AVCNFSM6AAAAACOE3WJUWVHI2DSMVQWIX3LMV43ERDJONRXK43TNFXW4OZZGIYTCOBYGQ>. You are receiving this because you were mentioned.