fixed glib warnings about using g_mem_set_vtable() and revised memory limiting

 * we were basing the glib allocators on throwing std::bad_alloc just like
   the C++ operators. However, this always was unsafe since we were throwing
   exceptions across plain-C frames (Glib).
   Also, the memory vtable has been deprecated in Glib, resulting in
   ugly warnings.
 * Instead, we now let the C++ new/delete operators work like Glib
   by basing them on g_malloc/g_slice.
   This means they will assert and the application will terminate
   abnormally in case of OOM. OOMs cannot be handled properly anyway, so it is
   more important to have a good memory limiting mechanism.
 * Memory limiting has been completely revised.
   Instead of approximating undo stack sizes using virtual methods
   (which is unprecise and comes with a performance penalty),
   we now use a common base class SciTECO::Object to count the memory
   required by all objects allocated within SciTECO.
   This is less precise than using global replacement new/deletes
   which would allow us to control allocations in all C++ code including
   Scintilla, but they are only supported as of C++14 (GCC 5) and adding compile-time
   checks would be cumbersome.
   In any case, we're missing Glib allocations (esp. strings).
 * As a platform-specific extension, on Linux/glibc we use mallinfo()
   to count the exact memory usage of the process.
   On Windows, we use GetProcessMemoryInfo() -- the latter implementation
   is currently UNTESTED.
 * We use g_malloc() for new/delete operators when there is
   malloc_trim() since g_slice does not free heap chunks properly
   (probably does its own mmap()ing), rendering malloc_trim() ineffective.
   We've also benchmarked g_slice on Linux/glib (malloc_trim() shouldn't
   be available elsewhere) and found that it brings no significant
   performance benefit.
   On all other platforms, we use g_slice since it is assumed
   that it at least does not hurt.
   The new g_slice based allocators should be tested on MSVCRT
   since I assume that they bring a significant performance benefit
   on Windows.
 * Memory limiting does now work in batch mode as well and is still
   enabled by default.
 * The old UndoTokenWithSize CRTP hack could be removed.
   UndoStack operations should be a bit faster now.
   But on the other hand, there will be an overhead due to repeated
   memory limit checking on every processed character.

1 files changed, 7 insertions, 7 deletions

diff --git a/src/interface.h b/src/interface.h
index e841680..9805a42 100644
--- a/src/interface.h
+++ b/src/interface.h
@@ -25,6 +25,7 @@
 
 #include <Scintilla.h>
 
+#include "memory.h"
 #include "undo.h"
 #include "error.h"
 
@@ -59,14 +60,14 @@ extern sig_atomic_t sigint_occurred;
  * base-class implementations to interface.cpp.
  */
 template <class ViewImpl>
-class View {
+class View : public Object {
 	inline ViewImpl &
 	impl(void)
 	{
 		return *(ViewImpl *)this;
 	}
 
-	class UndoTokenMessage : public UndoTokenWithSize<UndoTokenMessage> {
+	class UndoTokenMessage : public UndoToken {
 		ViewImpl &view;
 
 		unsigned int iMessage;
@@ -86,8 +87,7 @@ class View {
 		}
 	};
 
-	class UndoTokenSetRepresentations : public
-	      UndoTokenWithSize<UndoTokenSetRepresentations> {
+	class UndoTokenSetRepresentations : public UndoToken {
 		ViewImpl &view;
 
 	public:
@@ -153,14 +153,14 @@ protected:
  * user interface at runtime.
  */
 template <class InterfaceImpl, class ViewImpl>
-class Interface {
+class Interface : public Object {
 	inline InterfaceImpl &
 	impl(void)
 	{
 		return *(InterfaceImpl *)this;
 	}
 
-	class UndoTokenShowView : public UndoTokenWithSize<UndoTokenShowView> {
+	class UndoTokenShowView : public UndoToken {
 		ViewImpl *view;
 
 	public:
@@ -171,7 +171,7 @@ class Interface {
 	};
 
 	template <class Type>
-	class UndoTokenInfoUpdate : public UndoTokenWithSize< UndoTokenInfoUpdate<Type> > {
+	class UndoTokenInfoUpdate : public UndoToken {
 		const Type *obj;
 
 	public: