You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In Simple_object_pool, I specified default_user_allocator_malloc_free because it was slightly faster than the default. Now that we are increasing its use, I am worried that this choice may cause problems, and we should investigate what happens for out-of-memory. Supposedly, the default is based on new/delete and should throw an exception, whereas the malloc version may crash. In that case, it may be safer (particularly for the Python module) to go back to the default.
Other things to look at around there:
Pool_cell_constructor: just add to Simple_object_pool the functions we are missing to use it directly? (probably not the questionable operator= and swap though)
New_cell_constructor: just std::allocator?
Can we use simple_segregated_storage instead of pool in Simple_object_pool? (probably not worth it, I just mention it as a way to ensure we don't use the questionable parts of boost::pool)
The text was updated successfully, but these errors were encountered:
gudhi-devel/src/common/include/gudhi/Simple_object_pool.h
Line 26 in 1d4421c
In Simple_object_pool, I specified default_user_allocator_malloc_free because it was slightly faster than the default. Now that we are increasing its use, I am worried that this choice may cause problems, and we should investigate what happens for out-of-memory. Supposedly, the default is based on new/delete and should throw an exception, whereas the malloc version may crash. In that case, it may be safer (particularly for the Python module) to go back to the default.
Other things to look at around there:
The text was updated successfully, but these errors were encountered: