diff options
Diffstat (limited to 'TODO')
| -rw-r--r-- | TODO | 26 |
1 files changed, 0 insertions, 26 deletions
@@ -39,19 +39,6 @@ Known Bugs: regex support, UNIX regex (unportable) or some other library. Perhaps allowing us to interpret the SciTECO matching language directly. - * the glib allocators are fundamentally broken: - throwing exceptions is unsafe from C-linkage callbacks. - We should abandon the custom allocators and rely on - SciTECO's memory limiting. - All C++ allocations could be based on g_malloc/g_slice so we - assert on OOM. Instead we improve memory limiting using platform-specific - API like malloc_info(). Since the remaining platforms are only obscure - ones, the overloaded C++ operators should be sufficient to count the - bulk of memory used. Since the necessary sized delete operators are - only available beginning with C++14, there'd have to be yet another - fallback that stores the memory chunk size at the beginning of the - heap object. - The UndoToken::get_size() workaround can be removed. * It is still possible to crash SciTECO using recursive functions, since they map to the C++ program's call stack. It is perhaps best to use another ValueStack as a stack of @@ -257,19 +244,6 @@ Optimizations: However, this would mean to make some more Cmdline methods public. The implementations of the States' commandline editing handlers could all be concentrated in cmdline.cpp. - * C++14 is supported by GCC 5 and supports new() and delete() - operators with a size argument. Replacing these operators - with versions using g_slice_alloc() and g_slice_free() should - speed up things, especially Q-Register handling and the undo - stack. - This compiler capability should be checked by the build system. - C++11 already allows sized allocators in a class. - Testing shows that this does not speed up things on Linux - and prevents freeing memory on command line termination - (it would be glibc-specific), so it should probably depend on - HAVE_MALLOC_TRIM. On all other platforms, it could be assumed - to be beneficial or at least not hurt. - Best is to test its effect on MSVCRT. * String::append() could be optimized by ORing a padding into the realloc() size (e.g. 0xFF). However, this has not proven effective on Linux/glibc |