From e5482f9e08abcf97a0c9971dd2b7ae08749988e8 Mon Sep 17 00:00:00 2001 From: Marcelo Matus Date: Wed, 21 Dec 2005 18:27:47 +0000 Subject: [PATCH] add -nodefault entry git-svn-id: https://swig.svn.sourceforge.net/svnroot/swig/trunk/SWIG@8022 626c5289-ae23-0410-ae9c-e8d60b6d4f22 --- CHANGES.current | 27 ++++++++++++++++++++++++++- 1 file changed, 26 insertions(+), 1 deletion(-) diff --git a/CHANGES.current b/CHANGES.current index 2ce1d7637..396ca1779 100644 --- a/CHANGES.current +++ b/CHANGES.current @@ -1,7 +1,6 @@ Version 1.3.28 (unreleased). =========================== - 12/17/2005: mmatus [Python] - Add the -aliasobj0/-noaliasobj0 options to use with @@ -69,6 +68,32 @@ Version 1.3.28 (unreleased). -modern -fastdispatch -dirvtable -nosafecstrings -fvirtual +12/09/2005: mmatus + The '-nodefault' flag (pragma and features) now only + disable the default constructor, but not the default + destructor. The reason is that ignoring the default + destructor generates memory leaks, impossible to + work around, in all the languages. Hence, is to risky + just to disable the destructor when the flag is mainly + used to ignore the default constructor. + + It should be noted that this is also the behavior for C, + i.e., the destructor is always generated. + + What about adding a -nodefaultdestructor? I am not sure, I + don't see a reason to do that as long as I don't a reason + to add a flag like -pleasegeneratememoryleaks. + + But don't worry, if needed, we can still generate memory + leaks, I mean, disable the destructor, by using + + %ignore Class::~Class(); + + Yes, is not as automatic as '-nodefault' or + '-nodefaultdestructor', but in this case I think that + forcing to do this manually and in a 'case by case' approach + is desirable. + 12/08/2005: mmatus