From jan@swi.psy.uva.nl Sun Nov  4 14:08:03 2001
Received: from gollem.swi.psy.uva.nl (root@gollem [145.18.152.30])
	by swi.psy.uva.nl (8.11.2/8.11.2) with ESMTP id fA4D83t04647;
	Sun, 4 Nov 2001 14:08:03 +0100 (MET)
Received: (from jan@localhost)
	by gollem.swi.psy.uva.nl (8.11.3/8.11.3/SuSE Linux 8.11.1-0.5) id fA4D83802468;
	Sun, 4 Nov 2001 14:08:03 +0100
Date: Sun, 4 Nov 2001 14:08:03 +0100
Message-Id: <200111041308.fA4D83802468@gollem.swi.psy.uva.nl>
From: Jan Wielemaker <jan@swi.psy.uva.nl>
Subject: Re: [SWIPL] no copy semantics for PlTerm, in the C++ interface
To: Volker Wysk <post@volker-wysk.de>, prolog@swi.psy.uva.nl
In-Reply-To: Volker Wysk's message of Fri, 2 Nov 2001 21:46:44 +0100
Phone: +31 - 20 - 525 6121

> The class PlTerm in the C++ interface, SWI-cpp.h, contains this:
> 
>   int operator =(const PlTerm &t2)	/* term */
>   { return PL_unify(ref, t2.ref);
>   }
> 
> This is not correct copy semantics. You can't overwrite a PlTerm 
> object. You can't use PlTerm objects as values like this. For 
> instance, the Standard Template Library relies on correct copy 
> semantics. You couldn't store PlTerm's in STL containers, etc.
> 
> I suggest renaming the operator=() methods to unify().

I never claimed to be a C++ expert.  = has been redefined to allow
natural unification from C++.  I guess you'd like to see

   int operator =(const PlTerm &t2)	/* term */
   { return PL_put_term(ref, t2.ref);
   }

I think I agree to your proposal, also because = is a bit strange
and leads to

	return X = Y;

rather then the possibly someway clearer:

	return X.unify(Y);

Big problem is that there is a lot of code around that will break
if we change this.  Adding unify() is of course trivial.  The only
compatibility solution I can see is:

#define PL_UNIFY_WITH_IS 1
#include <SWI-cpp.h>

to be able to load old code.  

	Comments from C++ users and experts?

		--- Jan

