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, 5 insertions, 4 deletions

diff --git a/src/error.h b/src/error.h
index 62063ff..6801271 100644
--- a/src/error.h
+++ b/src/error.h
@@ -25,6 +25,7 @@
 #include <glib/gprintf.h>
 
 #include "sciteco.h"
+#include "memory.h"
 #include "string-utils.h"
 
 namespace SciTECO {
@@ -33,20 +34,20 @@ namespace SciTECO {
  * Thrown as exception to signify that program
  * should be terminated.
  */
-class Quit {};
+class Quit : public Object {};
 
 /**
  * Thrown as exception to cause a macro to
  * return or a command-line termination.
  */
-class Return {
+class Return : public Object {
 public:
 	guint args;
 
 	Return(guint _args = 0) : args(_args) {}
 };
 
-class Error {
+class Error : public Object {
 	GSList *frames;
 
 public:
@@ -54,7 +55,7 @@ public:
 	gint pos;
 	gint line, column;
 
-	class Frame {
+	class Frame : public Object {
 	public:
 		gint pos;
 		gint line, column;